1. Die Zuständigkeit liegt beim Feld, nicht beim System
Die Aussage „Das CRM führt die Kundendaten“ ist für eine Schnittstellenspezifikation zu ungenau. Ein Kundenkonto enthält vertriebliche Einschätzungen, rechtliche Stammdaten, Abrechnungsinformationen und operative Statuswerte. Diese Informationen entstehen in unterschiedlichen Prozessen. So kann der Vertrieb im CRM die Betreuung eines Kunden festlegen, während die Buchhaltung im ERP eine freigegebene Rechnungsanschrift verwaltet. Beide Systeme sind dann maßgeblich – aber nicht für dieselben Felder.
Die Zuständigkeit kann sich außerdem mit dem Geschäftsstatus ändern. Bei einem Interessenten darf beispielsweise der Vertrieb die Firmierung pflegen. Nach der Anlage als Rechnungsempfänger können Änderungen einen Prüfprozess benötigen. Definieren Sie deshalb je Feld, wer Änderungen anstoßen darf, wer sie freigibt und welches System den verbindlichen Wert veröffentlicht. Schreibberechtigungen und Schnittstellen müssen diese Regel gemeinsam durchsetzen; eine gesperrte Eingabemaske verhindert keine unzulässige Änderung über eine API.
- Objekt und Feld: Welche Information wird tatsächlich synchronisiert?
- Geschäftsstatus: Gilt die Regel für Interessenten, aktive Kunden oder gesperrte Konten?
- Schreib- und Freigaberecht: Wer darf eine Änderung vorschlagen und verbindlich machen?
- Übertragungsrichtung: Welches System liefert den freigegebenen Wert an welches Ziel?
- Konfliktverantwortung: Wer entscheidet, wenn keine automatische Regel greift?
2. Eine Feldhoheitsmatrix ersetzt pauschale Synchronisationsregeln
Halten Sie die Entscheidungen in einer Feldhoheitsmatrix fest. Diese ist keine bloße Liste technischer Feldzuordnungen: Sie beschreibt auch die Bedeutung der Daten. Eine „Adresse“ kann den Unternehmenssitz, einen Besuchsort, einen Warenempfänger oder die Rechnungsanschrift bezeichnen. Werden diese Bedeutungen nicht getrennt, überschreibt die Integration möglicherweise korrekte Informationen mit ebenfalls korrekten, aber anders gemeinten Informationen.
Ein mögliches Modell lautet: Das CRM führt die Vertriebszuordnung, das ERP die freigegebene Rechnungsanschrift und den Kreditstatus. Das CRM zeigt diese ERP-Werte nur an; Korrekturen werden als Änderungsantrag übergeben. Dieses Modell ist ein Beispiel, keine allgemeine Vorgabe. Entscheidend ist, dass die Zuordnung zum tatsächlichen Prozess passt. Dokumentieren Sie zusätzlich, ob ein leeres Feld „unbekannt“, „nicht anwendbar“ oder „bewusst gelöscht“ bedeutet. Ein fehlendes Attribut in einer Änderungsnachricht darf nicht versehentlich als Löschauftrag wirken.
3. Identitäten klären, bevor Werte übertragen werden
Auch die beste Konfliktregel hilft nicht, wenn die Schnittstelle den falschen Kunden aktualisiert. Verwenden Sie stabile technische Kennungen und eine dokumentierte Zuordnung zwischen CRM- und ERP-Datensätzen. Firmenname, E-Mail-Adresse oder Postanschrift eignen sich nicht als alleinige dauerhafte Verknüpfung: Sie können sich ändern, mehrfach vorkommen oder von mehreren Kontakten genutzt werden. Automatische Ähnlichkeitssuchen können bei der Erstzuordnung unterstützen, sollten unsichere Treffer aber nicht ungeprüft verbinden.
Legen Sie außerdem fest, was die beiden Systeme unter einem Kunden verstehen. Ein CRM-Unternehmensdatensatz kann mehrere ERP-Debitorenkonten betreffen, etwa für unterschiedliche rechtliche Einheiten. Auch mehrere Lieferorte sind nicht automatisch mehrere Kunden. Solche Beziehungen benötigen ein ausdrückliches Datenmodell. Für Zusammenführungen muss feststehen, welche Kennung bestehen bleibt, wie Verknüpfungen umgehängt werden und wie spätere Nachrichten mit einer alten Kennung behandelt werden. Andernfalls kann ein bereits bereinigtes Duplikat durch die Synchronisation erneut entstehen.
4. Konflikte nach Fachlogik lösen, nicht nach Uhrzeit
„Der letzte Schreibzugriff gewinnt“ wirkt einfach, ist aber fachlich oft ungeeignet. Eine verspätete Übertragung kann eine ältere Information später eintreffen lassen. Unterschiedliche Systemuhren erschweren Zeitvergleiche zusätzlich. Selbst ein korrekt bestimmter jüngster Änderungszeitpunkt sagt nicht, ob die Änderung zulässig war. Stammt eine Anschrift aus einem freigegebenen ERP-Prozess, sollte eine spätere ungeprüfte CRM-Eingabe diesen Wert nicht allein wegen ihres Zeitstempels verdrängen.
Prüfen Sie stattdessen Herkunft, Berechtigung und Version. Eine Änderung kann beispielsweise nur angenommen werden, wenn sie sich auf die noch aktuelle Version des Zielobjekts bezieht. Ist diese inzwischen fortgeschritten, wird der Vorgang als Konflikt behandelt. Versionsnummern unterschiedlicher Systeme lassen sich dabei nicht ohne gemeinsame Regel miteinander vergleichen. Änderungen an fachlich unabhängigen Feldern können unter passenden Bedingungen zusammengeführt werden; Änderungen innerhalb einer zusammengehörigen Anschrift sollten dagegen nicht blind feldweise vermischt werden.
- Maßgebliches System: Ein zulässiger Wert aus der festgelegten Quelle wird übernommen.
- Veraltete Grundlage: Eine Änderung mit überholtem Versionsbezug wird zurückgewiesen oder zur Prüfung gestellt.
- Unabhängige Änderungen: Eine Zusammenführung ist nur erlaubt, wenn fachliche Abhängigkeiten ausgeschlossen sind.
- Widerspruch am selben Feld: Eine benannte Rolle erhält beide Werte samt Herkunft und Änderungsverlauf zur Entscheidung.
5. Wiederholungen und Teilfehler als Normalfall behandeln
Eine Integration muss damit umgehen, dass Nachrichten mehrfach eintreffen, Verbindungen ausfallen oder eine Antwort nach erfolgreicher Verarbeitung verloren geht. Die erneute Übertragung desselben Vorgangs darf dann keinen zweiten Kunden oder zusätzlichen Änderungsantrag erzeugen. Dafür braucht es eine stabile Vorgangskennung und eine Verarbeitung, die Wiederholungen erkennt beziehungsweise ohne zusätzliche Wirkung ausführt. Eine Herkunftsmarkierung hilft zudem, Rückkopplungsschleifen zu verhindern, bei denen beide Systeme ihre jeweils übernommenen Änderungen erneut aussenden.
Planen Sie auch unterschiedliche Ankunftsreihenfolgen und Teilerfolge ein. Eine Kontaktänderung kann vor der zugehörigen Unternehmensanlage eintreffen; ein Kunde kann angelegt sein, während die Adressübertragung scheitert. Solche Fälle benötigen Abhängigkeiten, definierte Zwischenzustände und einen kontrollierten Wiederanlauf. Vorübergehende Verbindungsfehler lassen sich erneut versuchen. Inhaltliche Ablehnungen, etwa wegen eines ungültigen Pflichtwerts, gehören dagegen in eine Klärungsliste. Ein regelmäßiger Soll-Ist-Abgleich sollte zusätzlich erkennen, wenn Datensätze fehlen oder verbindliche Werte auseinanderlaufen.
6. Löschung, Sperre und Zusammenführung getrennt regeln
Ein gelöschter CRM-Datensatz ist nicht automatisch ein Auftrag, sämtliche zugehörigen ERP-Daten zu entfernen. Vertriebliche Inaktivität, operative Sperre, Dublettenbereinigung und datenschutzrechtliche Löschung verfolgen unterschiedliche Zwecke. Modellieren Sie diese Vorgänge getrennt und stimmen Sie Lösch- und Aufbewahrungsregeln mit den zuständigen Fachstellen ab. Eine Synchronisationsregel ersetzt weder die Prüfung bestehender Aufbewahrungspflichten noch die Entscheidung, welche Daten für welchen Zweck weiterhin verarbeitet werden dürfen.
Technisch muss verhindert werden, dass eine verzögerte Nachricht einen bereits entfernten Datensatz wieder anlegt. Dafür kann eine Löschmarkierung oder ein gesonderter Status nötig sein, gegen den eingehende Nachrichten geprüft werden. Auch solche Markierungen brauchen einen definierten Umfang, Zugriffsschutz und eine begründete Aufbewahrungsdauer. Regeln Sie außerdem, ob gesperrte Kunden noch Stammdatenänderungen erhalten dürfen und wie zusammengeführte Konten angesprochen werden. „Nicht mehr aktiv“ ist ohne diese Unterscheidungen kein ausreichend präziser Schnittstellenstatus.
KOSTENLOSES KI-RANKING
Passende CRM-Anbieter finden
Starten Sie den neutralen Vergleich in wenigen Minuten – kostenlos und unverbindlich.
Unverbindlich & schnell