Gå til innholdet

Koble CRM og ERP: fastsett datakilden for hvert felt

En utfylt felttabell fastsetter kilder og skriveretninger. Kontakt, fakturaadresse og kontostatus fordeles tydelig mellom CRM og ERP.

Tobias Krüger2 min lesetid
Grønt adressefelt med stedsmarkør og en fane med tannhjulsymbol.

Fastsett før en CRM–ERP-kobling hvor enkeltverdier endres og bekreftes. En kunde kan finnes i begge systemer, mens feltene har ulike ansvarlige kilder. Det gir en datakontrakt for gjennomføringen: identitet, feltbetydning, førende kilde og tillatt skriveretning.

Identifiser samme post entydig

Et fiktivt programvareselskap kobler CRM-kunden C-204 til kundekontoen i ERP D-630. Koblingen skal være stabil gjennom disse referansene; et lignende firmanavn er ikke nok. Microsoft beskriver for eksempel alternative nøkler i Dataverse som identifiserer rader gjennom unike kolonneverdier. Hvilke nøkler de konkrete systemene tilbyr, hører til den tekniske forundersøkelsen.

I eksemplet bekrefter den førende kilden den gyldige feltverdien. Det andre systemet kan vise den eller sende en endringsforespørsel. Feltnavn og verdier i tabellen er et eget modellforslag for eksemplet, ikke en leverandørs API-felt.

Fyll inn kilde og retning for hvert felt

Felt

Eksempelverdi

Førende kilde og retning

Endring i det andre systemet

Prosjektkontakt technicalContactEmail

projekt@example.invalid

CRM → ERP, som teknisk kontakt.

Bare visning i ERP.

Fakturaadresse billingAddress

Werkstraße 8, Beispielstadt

ERP → CRM.

Registrer en endringsforespørsel i CRM.

Kontostatus billingAccountState

active

ERP → CRM.

En salgsstatus i CRM endrer ikke denne verdien.

Retningen bestemmes per felt; en generell regel om at CRM er førende ville ikke gjengi denne fordelingen. Microsofts dual-write-dokumentasjon viser enveis og toveis kolonnekoblinger; den konkrete datakontrakten bestemmer hva som passer her.

Behandle en annen inntasting som en endringsforespørsel

Hvis salg oppgir den nye adressen Werkstraße 12, Beispielstadt i CRM, skal det først opprettes en åpen forespørsel. Det autoriserte ERP-teamet vurderer den og bekrefter endringen hvis den er passende. Bare den bekreftede ERP-verdien sendes tilbake. Ønsket og bekreftet adresse trenger derfor ulike statuser.

Hvis overføringen mislykkes, må CRM holde den åpne forespørselen og sist bekreftede versjon atskilt. Å sende arbeid til grensesnittet er ikke en bekreftelse fra målsystemet. Tidspunkt og resultat skal kunne spores på saken.

Kontroller tre overføringer med forventede resultater

Kontroller avtalen før bruk i et egnet testmiljø:

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

  • En adresseforespørsel lar først den bekreftede verdien Werkstraße 8, Beispielstadt stå uendret. Etter ERP-godkjenning vises den nye adressen også i CRM.

  • Setter ERP kontostatus til blocked, viser CRM det. En endring av salgsstatus opphever ikke sperren.

Resultatene kontrollerer ulike felt og skriverettigheter. En teknisk vellykket overføring av én post dekker ikke alle tre reglene fullt ut.

Kilder

Skrevet av

  • Tobias KrügerRedaktør for systemintegrasjonTobias Krüger jobber hos ASES med samspillet mellom ulike programvaresystemer. I artiklene sine forklarer han hvordan ERP, CRM og nettbutikker kobles sammen, og hvordan man håndterer feil i datautvekslingen.

Følg ASES

Les videre

Alle artikler

API-er og integrasjon med ASES

ERP, CRM og nettbutikk ryddig koblet sammen