Gå til indholdet

Forbind CRM og ERP: fastlæg datakilden for hvert felt

En gennemarbejdet felttabel fastlægger kilder og skriveretninger. Kontakt, faktureringsadresse og kontostatus fordeles tydeligt mellem CRM og ERP.

Tobias Krüger2 min. læsetid
Grønt adressefelt med stedmarkør og en fane med tandhjulssymbol.

Fastlæg før en CRM–ERP-kobling, hvor de enkelte værdier ændres og bekræftes. En kunde kan findes i begge systemer, mens felterne har forskellige ansvarlige kilder. Det skaber en datakontrakt for implementeringen: identitet, feltbetydning, førende kilde og tilladt skriveretning.

Genkend samme post entydigt

Et fiktivt softwarefirma kobler CRM-kunden C-204 til ERP-kundekontoen D-630. Koblingen skal forblive stabil gennem disse referencer; et lignende firmanavn er ikke nok. Microsoft beskriver eksempelvis alternative nøgler i Dataverse, som kan identificere rækker gennem entydige kolonneværdier. Hvilke nøgler de konkrete systemer tilbyder, hører til den tekniske afklaring.

I eksemplet bekræfter den førende kilde den gyldige feltværdi. Det andet system kan vise den eller sende et ændringsønske. Feltnavne og værdier i tabellen er et eget design til eksemplet, ikke en udbyders API-felter.

Udfyld kilde og retning for hvert felt

Felt

Eksempelværdi

Førende kilde og retning

Ændring i det andet system

Projektkontakt technicalContactEmail

projekt@example.invalid

CRM → ERP, som teknisk kontakt.

Kun visning i ERP.

Faktureringsadresse billingAddress

Werkstraße 8, Beispielstadt

ERP → CRM.

Registrér et ændringsønske i CRM.

Kontostatus billingAccountState

active

ERP → CRM.

En salgsstatus i CRM ændrer ikke denne værdi.

Retningen fastlægges pr. felt; en generel regel om, at CRM er førende, ville ikke vise denne fordeling. Microsofts dual-write-dokumentation viser envejs og tovejs koblinger mellem kolonner; den konkrete datakontrakt bestemmer den passende retning her.

Behandl en anden indtastning som et ændringsønske

Hvis salg melder den nye adresse Werkstraße 12, Beispielstadt i CRM, skal der først oprettes et åbent ønske. Det autoriserede ERP-team gennemgår det og bekræfter ændringen, hvis den er passende. Kun den bekræftede ERP-værdi sendes tilbage. Ønsket og bekræftet adresse kræver derfor forskellige statusser.

Hvis overførslen fejler, skal CRM holde det åbne ønske og den senest bekræftede version adskilt. At sende arbejde til grænsefladen er ikke en bekræftelse fra målsystemet. Tidspunkt og resultat for behandlingen skal kunne spores på sagen.

Kontrollér tre overførsler med forventede resultater

Kontrollér aftalen før brug i et egnet testmiljø:

  • En kontaktadresse ændret til projekt-neu@example.invalid i CRM vises som teknisk kontakt i ERP.

  • En anmodning om adresseændring ændrer i første omgang ikke den bekræftede værdi Werkstraße 8, Beispielstadt. Efter ERP-godkendelse vises den nye adresse også i CRM.

  • Sætter ERP kontostatus til blocked, viser CRM den. En ændring af salgsstatus ophæver ikke blokeringen.

Resultaterne kontrollerer forskellige felter og skriverettigheder. En teknisk vellykket overførsel af en enkelt post dækker ikke alle tre regler fuldt ud.

Kilder

Skrevet af

  • Tobias KrügerRedaktør for systemintegrationTobias Krüger beskæftiger sig hos ASES med samspillet mellem forskellige softwaresystemer. I sine artikler forklarer han integrationen af ERP, CRM og webshops samt håndteringen af fejl i dataudvekslingen.

Følg ASES

Læs videre

Alle artikler

Snitflader & integration med ASES

ERP, CRM og webshop forbundet ordentligt