CRM und ERP verbinden: die Datenquelle je Feld festlegen
Eine ausgefüllte Feldtabelle legt Quelle und Schreibrichtung fest. So lassen sich Kontaktpflege, Rechnungsadresse und Kontostatus sauber zwischen CRM und ERP verteilen.
Legen Sie vor einer CRM–ERP-Anbindung fest, wo einzelne Werte geändert und bestätigt werden. Ein Kunde kann in beiden Systemen vorkommen, während seine Felder unterschiedliche Zuständigkeiten haben. Daraus entsteht ein Datenvertrag für die Umsetzung: Identität, Feldbedeutung, führende Quelle und zulässige Schreibrichtung.
Den gleichen Datensatz eindeutig erkennen
Ein fiktives Softwareunternehmen verbindet den CRM-Kunden C-204 mit dem ERP-Kundenkonto D-630. Die Zuordnung soll dauerhaft über diese Referenzen bestehen; ein ähnlicher Firmenname reicht nicht. Microsoft beschreibt für Dataverse beispielsweise alternative Schlüssel, die Datensätze über eindeutige Spaltenwerte identifizieren können. Welche Schlüssel die konkreten Systeme bereitstellen, gehört zur technischen Vorprüfung.
„Führend“ bedeutet im folgenden Beispiel: Dieses System bestätigt den gültigen Feldwert. Das andere System kann ihn anzeigen oder einen Änderungswunsch übermitteln. Die Feldnamen und Werte der Tabelle sind ein eigener Entwurf für dieses Beispiel, keine API-Felder eines Anbieters.
Quelle und Richtung pro Feld ausfüllen
Feld | Beispielwert | Führende Quelle und Richtung | Änderung im anderen System |
|---|---|---|---|
Projektkontakt |
| CRM → ERP, als technischer Kontakt. | Im ERP nur anzeigen. |
Rechnungsanschrift |
| ERP → CRM. | Im CRM einen Änderungswunsch erfassen. |
Kontostatus |
| ERP → CRM. | Ein Vertriebsstatus im CRM ändert diesen Wert nicht. |
Die Richtung wird pro Feld festgelegt; eine pauschale Vorgabe „CRM führt“ würde diese Aufteilung nicht abbilden. Microsofts Dual-write-Dokumentation zeigt einseitige und zweiseitige Spaltenzuordnungen; welche Richtung hier fachlich passt, entscheidet der konkrete Datenvertrag.
Eine abweichende Eingabe als Änderungswunsch behandeln
Meldet der Vertrieb im CRM die neue Anschrift Werkstraße 12, Beispielstadt, soll zunächst ein offener Wunsch entstehen. Das berechtigte ERP-Team prüft ihn und bestätigt gegebenenfalls die Änderung. Erst der bestätigte ERP-Wert fließt zurück. Gewünschte und bestätigte Anschrift brauchen deshalb unterscheidbare Zustände.
Scheitert die Übertragung, muss das CRM den offenen Wunsch und den zuletzt bestätigten Stand erkennbar halten. Ein Auftrag an die Schnittstelle ist noch keine Bestätigung des Zielsystems. Der Zeitpunkt und das Ergebnis der Verarbeitung sollen am Vorgang nachvollziehbar sein.
Drei Übergaben mit erwartetem Ergebnis prüfen
Prüfen Sie die Vereinbarung vor dem Einsatz in einer geeigneten Testumgebung:
Eine im CRM geänderte Kontaktadresse
projekt-neu@example.invaliderscheint im ERP beim technischen Kontakt.Ein Adresswunsch verändert den bestätigten Wert
Werkstraße 8, Beispielstadtzunächst nicht. Nach ERP-Freigabe erscheint die neue Anschrift auch im CRM.Setzt das ERP den Kontostatus auf
blocked, zeigt das CRM diesen Zustand. Eine Änderung des Vertriebsstatus hebt ihn nicht auf.
Die Ergebnisse prüfen unterschiedliche Felder und Schreibrechte. Eine technisch erfolgreiche Übertragung eines einzelnen Datensatzes deckt diese drei Regeln nicht vollständig ab.
Quellen
Weiterlesen
Alle Beiträge
Schnittstellen & Integration mit ASES
ERP, CRM und Shop sauber verbunden