CRM en ERP koppelen: de gegevensbron per veld bepalen
Een uitgewerkte veldtabel bepaalt bronnen en schrijfrichtingen. Contactbeheer, factuuradres en rekeningstatus krijgen een duidelijke plaats in CRM en ERP.
Bepaal vóór een CRM–ERP-koppeling waar afzonderlijke waarden worden gewijzigd en bevestigd. Een klant kan in beide systemen bestaan, terwijl velden verschillende verantwoordelijken hebben. Dat vormt een datacontract voor de uitvoering: identiteit, veldbetekenis, leidende bron en toegestane schrijfrichting.
Hetzelfde record eenduidig herkennen
Een fictief softwarebedrijf koppelt CRM-klant C-204 aan ERP-klantrekening D-630. De koppeling moet via deze referenties stabiel blijven; een vergelijkbare bedrijfsnaam is onvoldoende. Microsoft beschrijft voor Dataverse bijvoorbeeld alternatieve sleutels die rijen via unieke kolomwaarden kunnen herkennen. Welke sleutels de concrete systemen bieden, hoort bij de technische beoordeling.
In dit voorbeeld bevestigt de leidende bron de geldige veldwaarde. Het andere systeem kan die tonen of een wijzigingsverzoek sturen. Veldnamen en waarden in de tabel zijn een eigen ontwerp voor dit voorbeeld, geen API-velden van een aanbieder.
Bron en richting per veld invullen
Veld | Voorbeeldwaarde | Leidende bron en richting | Wijziging in het andere systeem |
|---|---|---|---|
Projectcontact |
| CRM → ERP, als technisch contact. | Alleen tonen in ERP. |
Factuuradres |
| ERP → CRM. | In CRM een wijzigingsverzoek vastleggen. |
Rekeningstatus |
| ERP → CRM. | Een verkoopstatus in CRM wijzigt deze waarde niet. |
De richting wordt per veld bepaald; een algemene regel «CRM is leidend» zou deze verdeling niet weergeven. Microsofts dual-write-documentatie toont eenrichtings- en tweerichtingskolomkoppelingen; het concrete datacontract bepaalt welke richting hier past.
Een andere invoer als wijzigingsverzoek behandelen
Meldt verkoop in CRM het nieuwe adres Werkstraße 12, Beispielstadt, dan moet eerst een open verzoek ontstaan. Het bevoegde ERP-team beoordeelt dat en bevestigt zo nodig de wijziging. Alleen de bevestigde ERP-waarde stroomt terug. Gewenst en bevestigd adres hebben dus aparte statussen nodig.
Mislukt de overdracht, dan moet CRM het open verzoek en de laatst bevestigde versie onderscheidbaar houden. Werk naar de interface sturen is geen bevestiging van het doelsysteem. Verwerkingstijd en resultaat moeten bij de handeling herleidbaar zijn.
Drie overdrachten met verwachte resultaten controleren
Controleer de afspraak vóór gebruik in een geschikte testomgeving:
Een contactadres dat in CRM in
projekt-neu@example.invalidis gewijzigd, verschijnt als technisch contact in ERP.Een adresverzoek laat de bevestigde waarde
Werkstraße 8, Beispielstadteerst intact. Na ERP-goedkeuring verschijnt het nieuwe adres ook in CRM.Zet ERP de rekeningstatus op
blocked, dan toont CRM die status. Een wijziging van de verkoopstatus heft de blokkering niet op.
De resultaten controleren verschillende velden en schrijfrechten. Eén record technisch succesvol overdragen dekt deze drie regels niet volledig af.
Bronnen
Verder lezen
Alle artikelen
Koppelingen & integratie met ASES
ERP, CRM en webshop netjes gekoppeld