Wie Daten zuverlässig zwischen CRM und ERP fließen.

Der Vertrieb legt einen neuen Kontakt im CRM an. Nach einer Zusage tippt eine andere Person die Angaben noch einmal in das ERP. Dort entsteht der Auftrag. Eine Kundennummer und später ein Rechnungsstatus müssen anschließend zurück ins CRM.

Schon kleine Unterschiede führen zu Fragen: Welche Anschrift stimmt? Wurde der Auftrag bereits übertragen? Darf der Vertrieb die Rechnungsanschrift ändern? Wer merkt, dass die Übertragung fehlgeschlagen ist?

Eine technische Verbindung kann die doppelte Eingabe verringern. Sie funktioniert aber nur zuverlässig, wenn vorher die fachliche Verantwortung geklärt ist.

Ein CRM unterstützt Beziehungen, Kontakte, Verkaufschancen und Kommunikation. Ein ERP organisiert je nach Einsatz zum Beispiel Produkte, Aufträge, Lieferungen, Leistungen oder Rechnungen. Beide Programme können Daten zum selben Geschäftsvorgang enthalten, brauchen aber nicht alle dieselben Einzelheiten.

Ohne Regeln werden Kunden und Ansprechpersonen mehrfach gepflegt. Status werden von Hand übertragen. Unterschiede fallen erst spät auf. Einfach alle technisch verfügbaren Felder in beide Richtungen zu kopieren, macht die Lösung unnötig kompliziert.

Für jede Information muss deshalb der Zweck klar sein. Das CRM braucht vielleicht nur den Rechnungsstatus und nicht alle Rechnungsdetails. Weniger unnötige Kopien erleichtern Datenschutz und Wartung.

Ein Interessent entsteht zuerst im CRM. Dort pflegt der Vertrieb Kontakt und Gesprächsstand. Nach einer Freigabe wird der Kunde an das ERP übertragen. Das ERP vergibt eine feste Debitorennummer und sendet sie zurück.

Damit ist nicht eines der Programme für alle Kundendaten verantwortlich. Die Verantwortung wird je Datenobjekt oder Gruppe von Feldern festgelegt. Das führende System ist jeweils das Programm, in dem eine Information verbindlich angelegt oder geändert wird.

Jeder Datensatz braucht außerdem eine stabile Kennung, die beide Programme zuordnen können. Ein Name oder eine E-Mail-Adresse genügt häufig nicht. Beides kann sich ändern oder mehrfach vorkommen. Dürfen beide Programme dieselbe Angabe ändern, braucht es eine klare Regel für Konflikte.

Eine Übertragung in nur eine Richtung ist einfacher: Ein Programm ist Quelle, das andere empfängt eine Kopie. Eine Übertragung in beide Richtungen kann nötig sein. Sie erzeugt aber mehr Konflikte und Fehlerfälle. Nutzen Sie sie nur für Angaben, die wirklich in beiden Programmen bearbeitet werden müssen.

Auch der Zeitpunkt folgt dem Arbeitsablauf:

• ereignisbasiert: Eine Änderung löst die Übertragung zeitnah aus.
• zeitgesteuert: Änderungen werden zu festen Zeiten gesammelt übertragen.
• manuell ausgelöst: Eine berechtigte Person startet den Übergang.
• abfragebasiert: Das Zielprogramm fragt regelmäßig oder bei Bedarf nach Änderungen.

Echtzeit ist nicht immer besser. Ein täglich benötigter Status kann in einem stabilen geplanten Lauf genügen. Eine sofort nötige Freigabe braucht dagegen eine zeitnahe Rückmeldung.

Eine dokumentierte API ist ein häufiger Weg. Ein Webhook oder anderes Ereignis kann melden, dass sich etwas geändert hat. Danach können die nötigen Daten über eine API abgerufen werden. Unter passenden Bedingungen kann auch ein geschützter Dateiimport oder eine vorhandene Middleware sinnvoll sein.

Ein direkter Zugriff auf die Datenbank ist besonders vorsichtig zu prüfen. Er kann Regeln und Zugriffsrechte des Programms umgehen und nach einem Update brechen. Herstellervorgaben, Sicherheit und Betrieb müssen ausdrücklich berücksichtigt werden.

Die Wahl richtet sich nach Stabilität, Schutz, Datenmenge, benötigter Geschwindigkeit, Unterstützung durch den Hersteller und späterer Wartung. Ein schneller Import ist langfristig keine gute Lösung, wenn Fehler unbemerkt bleiben.

Eine gute Integration beantwortet mehr als die Frage, wo Kundendaten abgerufen werden. Klären Sie:

• Anmeldung und Rechte: Wie weist sich die Verbindung aus und welche möglichst kleinen Rechte hat sie?
• Zuordnung und Prüfung: Welches Feld und welcher Wert entsprechen einander? Welche Angaben sind Pflicht?
• Schutz vor Doppelungen: Wie verhindert eine Wiederholung doppelte Kunden oder Buchungen?
• Konflikte: Welche Änderung gilt und wann muss ein Mensch entscheiden?
• Wiederholungen: Welche vorübergehenden Fehler dürfen später erneut versucht werden?
• Überwachung: Wie wird ein Ausfall bemerkt und wie werden unnötige geschützte Daten in Protokollen vermieden?
• Datenschutz und Löschung: Warum werden Daten übertragen und wie wirken Korrektur oder Löschung in beiden Programmen?

Testen Sie diese Regeln auch mit wirklichen Fehlerfällen und nicht nur mit einem erfolgreichen Beispieldatensatz.

Eine Schnittstelle kann erreichbar sein und trotzdem falsche Angaben erhalten. Umgekehrt kann ein gültiger Datensatz wegen einer kurzen Störung nicht übertragen werden. Beide Fälle brauchen unterschiedliche Reaktionen.

Bei einer vorübergehenden technischen Störung kann die Übertragung kontrolliert wiederholt werden. Eine falsche Postleitzahl, unbekannte Produktnummer oder widersprüchliche Zuordnung muss dagegen fachlich geklärt werden. Nach mehreren erfolglosen Versuchen darf ein Vorgang nicht still verschwinden. Er braucht eine sichtbare Aufgabe.

Legen Sie fest: Wer wird informiert? Wer darf Daten korrigieren? Wie wird der Vorgang erneut gestartet? Wie lässt sich später nachvollziehen, was passiert ist?

• Beide Programme gelten für dieselbe Information als verbindlich.
• Datensätze besitzen keine stabile gemeinsame Kennung.
• Änderungen in beide Richtungen haben keine Konfliktregel.
• Fehler werden zwar gespeichert, aber niemand erhält eine Aufgabe.
• Tests laufen direkt mit unkontrollierten echten Daten.
• Datenqualität wird erst beim ersten Import untersucht.
• Es fehlt ein Plan für Rückfall und Neustart nach einem Ausfall.
• Änderungen an API oder Datenmodell werden nicht überwacht.

Ein erfolgreicher Verbindungstest zeigt nur, dass zwei Programme miteinander sprechen können. Er zeigt noch nicht, dass der vollständige Datenfluss fachlich richtig, sicher und dauerhaft betreibbar ist.

Beginnen Sie mit einem fachlichen Ereignis. Beispiel: Ein Auftrag ist im CRM freigegeben. Welche Daten braucht das ERP nun? Wer trägt die Verantwortung? Welche Rückmeldung benötigt das CRM?

Legen Sie danach Datenobjekte, führende Quellen, gemeinsame Kennungen, Richtung, Zeitpunkt und Fehlerfälle fest. Erst dann prüfen Sie technische Zugänge, Rechte, Datenmenge und Grenzen im Betrieb.

Testen Sie in einer kontrollierten Umgebung mit typischen und fehlerhaften Fällen. Planen Sie Überwachung, Dokumentation, Datenübernahme und feste Zuständigkeiten. Eine Integration ist erst fertig, wenn auch der Fehlerweg im laufenden Betrieb funktioniert.

CRM: Ein Programm für Kontakte, Kundenbeziehungen, Verkaufschancen und Kommunikation.

ERP: Ein Programm für zentrale betriebliche Abläufe wie Produkte, Aufträge, Leistungen oder Rechnungen.

Integration: Die kontrollierte Verbindung von Programmen und Daten.

Führendes System: Das Programm, in dem eine bestimmte Information verbindlich gepflegt wird.

Mapping: Die dokumentierte Zuordnung von Feldern und Bedeutungen zwischen zwei Programmen.

API: Ein festgelegter technischer Zugang für den Datenaustausch.

Webhook: Eine automatische Nachricht eines Programms, dass ein bestimmtes Ereignis eingetreten ist.

Middleware: Eine technische Zwischenschicht, die Programme verbindet und den Datenaustausch steuert.

Idempotenz: Eine Schutzregel, durch die ein wiederholter Aufruf nicht versehentlich doppelte Datensätze oder Buchungen erzeugt.

Monitoring: Die laufende Überwachung, ob die Verbindung arbeitet und wo Fehler auftreten.

Eine gute CRM-ERP-Verbindung beginnt bei Verantwortung und fachlichen Ereignissen. Danach werden Daten, gemeinsame Kennungen, Zuordnung, Richtung, Zeitpunkt und Fehlerfälle festgelegt. Die Technik kann API, Ereignis, Datei oder Middleware nutzen. Erst ein sichtbarer und verantworteter Fehlerweg macht aus einer bloßen Übertragung eine dauerhaft betreibbare Integration.