CRM und ERP verbinden: So entsteht ein durchgängiger Datenfluss.

CRM und ERP betrachten häufig dieselben Geschäftsvorgänge aus unterschiedlicher Perspektive. Im CRM stehen Beziehungen, Aktivitäten, Verkaufschancen und Kommunikation im Vordergrund. Das ERP organisiert je nach Einsatz unter anderem Produkte, Aufträge, Lieferung, Leistung oder Abrechnung.

Ohne abgestimmten Datenfluss werden Kunden und Ansprechpartner mehrfach gepflegt, Status manuell übertragen und Abweichungen erst spät sichtbar. Eine technische Verbindung allein löst das nicht. Zuerst muss klar sein, welches System welche Information fachlich verantwortet und welches Ereignis eine Übertragung auslöst.

Eine Systemintegration ist deshalb zugleich Prozess- und Datenmodellierungsaufgabe. Sie verbindet nicht nur Endpunkte, sondern Entscheidungen und Verantwortlichkeiten.

Als allgemeine Beispiele können Kunden, Ansprechpartner, Produkte, Preise, Angebote, Aufträge, Rechnungen, Status oder Dokumentverweise zwischen CRM und ERP relevant sein. Welche Objekte tatsächlich übertragen werden, hängt vom konkreten Prozess und den Funktionen beider Systeme ab.

Nicht jede technisch verfügbare Information sollte automatisch synchronisiert werden. Für jedes Objekt sind Zweck, benötigte Felder, Aktualität, Schutzbedarf und Empfänger zu klären. Ein CRM benötigt möglicherweise nur einen Abrechnungsstatus, nicht aber vollständige Rechnungsdetails. Datensparsamkeit reduziert Komplexität und begrenzt unnötige Kopien.

Auch Begriffe müssen vereinheitlicht werden. „Kunde“, „Account“, „Debitor“ oder „Organisation“ können fachlich unterschiedlich gemeint sein. Ein Mapping dokumentiert diese Bedeutung, statt nur ähnlich benannte Felder zu verbinden.

Die Frage nach dem führenden System wird nicht pauschal für die gesamte Integration beantwortet. Sie wird je Datenobjekt oder sogar je fachlich zusammengehöriger Attributgruppe entschieden. Ein Interessent kann zunächst im CRM entstehen; eine freigegebene Debitorennummer wird später im ERP erzeugt und zurückgegeben.

Führend bedeutet: In diesem System wird eine Information verbindlich angelegt oder geändert. Andere Systeme erhalten eine Kopie für ihren Zweck. Dafür braucht jedes Objekt eine stabile systemübergreifende Identität. Namen oder E-Mail-Adressen sind allein meist keine verlässlichen technischen Schlüssel, weil sie sich ändern oder mehrfach vorkommen können.

Wenn beide Systeme dieselbe Information unabhängig verändern dürfen, ist eine Konfliktstrategie notwendig. Ohne sie entstehen konkurrierende Wahrheiten und die zuletzt übertragene Änderung gewinnt möglicherweise zufällig.

Eine einseitige Übertragung ist einfacher zu verstehen: Ein System ist Quelle, das andere Empfänger. Bidirektionale Synchronisation kann erforderlich sein, erhöht aber Konflikt- und Fehlerfälle. Sie sollte nur für Daten verwendet werden, die tatsächlich in beiden Systemen bearbeitet werden müssen.

Auch der Zeitpunkt folgt dem Prozess:

• ereignisbasiert: Eine fachliche Änderung löst die Übertragung zeitnah aus.
• zeitgesteuert: Änderungen werden in definierten Intervallen gebündelt.
• manuell ausgelöst: Eine berechtigte Person startet einen kontrollierten Übergang.
• abfragebasiert: Das Ziel holt Änderungen regelmäßig oder bei Bedarf ab.

„Echtzeit“ ist kein Selbstzweck. Wenn ein Status einmal täglich benötigt wird, kann ein stabiler geplanter Lauf sinnvoller sein. Für eine unmittelbare Freigabeentscheidung kann dagegen zeitnahe Verarbeitung fachlich notwendig sein.

Eine dokumentierte REST-API ist ein häufiger Integrationsweg, aber nicht die einzige Möglichkeit. Webhooks oder Events können Änderungen melden, während eine API die zugehörigen Daten bereitstellt. Bei geeigneten Rahmenbedingungen können Dateiimporte über einen abgesicherten Übertragungsweg oder vorhandene Middleware-Funktionen sinnvoll sein.

Ein direkter Datenbankzugriff erfordert besondere Vorsicht. Er kann Geschäftslogik, Berechtigungen und unterstützte Schnittstellen eines Produkts umgehen und bei Updates brechen. Wenn er überhaupt betrachtet wird, müssen Herstellervorgaben, Transaktionsverhalten, Datenmodell und Betriebsrisiko ausdrücklich geprüft werden.

Die Auswahl berücksichtigt Stabilität, Sicherheit, Datenvolumen, Latenz, Herstellerunterstützung und Wartbarkeit. Ein kurzfristig schneller Import kann dauerhaft teuer werden, wenn Fehler nicht erkannt oder Änderungen am Quellsystem nicht kontrolliert übernommen werden.

Eine belastbare Integration beantwortet mehr als „Welcher Endpunkt liefert Kunden?“. Zum technischen Scope gehören:

• Authentifizierung und Autorisierung: Wie weist sich die Integration aus und welche minimalen Rechte besitzt sie?
• Mapping und Validierung: Wie werden Felder, Werte und Pflichtregeln übersetzt und geprüft?
• Idempotenz: Wie wird verhindert, dass eine Wiederholung doppelte Objekte oder Buchungen erzeugt?
• Konflikte: Welche Änderung gewinnt und wann ist eine manuelle Entscheidung erforderlich?
• Retries und Warteschlangen: Welche Fehler sind vorübergehend und mit welchem Abstand wird wiederholt?
• Monitoring und Logging: Wie werden Ausfälle erkannt, ohne unnötig sensible Inhalte in Protokollen zu speichern?
• Datenschutz und Löschung: Welche Daten werden aus welchem Zweck übertragen und wie wirken Korrektur oder Löschung systemübergreifend?

Diese Punkte werden mit realen Fehlerfällen getestet, nicht nur mit einem erfolgreichen Beispieldatensatz.

Eine Schnittstelle kann technisch erreichbar sein und trotzdem fachlich ungültige Daten erhalten. Umgekehrt kann ein korrektes Objekt wegen einer vorübergehenden Störung nicht übertragen werden. Diese Fälle benötigen unterschiedliche Reaktionen.

Vorübergehende technische Fehler können kontrolliert wiederholt werden. Eine fehlerhafte Postleitzahl, unbekannte Produktnummer oder widersprüchliche Zuordnung braucht dagegen fachliche Klärung. Nach mehreren erfolglosen Versuchen sollte ein Vorgang nicht still verschwinden, sondern in einen sichtbaren Klärungsweg gelangen.

Die Zuständigkeit gehört in das Integrationskonzept: Wer erkennt die Störung? Wer darf Daten korrigieren? Wie wird die Übertragung erneut angestoßen? Wie lässt sich später nachvollziehen, was passiert ist?

Integrationsprobleme entstehen häufig aus ungeklärter Verantwortung, nicht aus der Syntax eines API-Aufrufs. Besonders kritisch sind:

• beide Systeme gelten für dieselben Daten als führend,
• Objekte besitzen keine stabilen systemübergreifenden IDs,
• bidirektionale Änderungen haben keine Konfliktstrategie,
• Fehler werden nur protokolliert, aber niemand wird verantwortlich informiert,
• Tests erfolgen direkt mit unkontrollierten Produktivdaten,
• Datenqualität wird erst beim ersten Import untersucht,
• ein Rückfall- oder Wiederanlaufkonzept fehlt,
• Änderungen an APIs oder Datenmodellen werden nicht überwacht.

Ein erfolgreicher Verbindungstest belegt nur, dass Systeme kommunizieren können. Er belegt noch nicht, dass der vollständige fachliche Datenfluss korrekt, sicher und betreibbar ist.

Wir beginnen mit dem vollständigen Ablauf: Welches Ereignis entsteht in welchem System? Welche Daten werden für den nächsten Schritt benötigt? Wer trägt die Verantwortung? Danach werden Datenobjekte, führende Quellen, IDs, Richtungen und Fehlerfälle definiert.

Erst dann folgt die technische Prüfung von APIs, Berechtigungen, Volumen und Betriebsgrenzen. Umsetzung und Tests verwenden kontrollierte Umgebungen und repräsentative Fälle. Die Implementierung ergänzt Monitoring, Dokumentation, Migration und klare Zuständigkeiten für den produktiven Betrieb.

Das Vorgehensmodell hält fachliche und technische Entscheidung zusammen. Damit wird nicht nur eine Schnittstelle geliefert, sondern ein durchgängiger Prozess über Systemgrenzen hinweg.

Eine CRM-ERP-Verbindung beginnt mit Datenverantwortung und Prozessereignissen. Danach werden Objekte, IDs, Mapping, Richtung, Zeitpunkt und Fehlerfälle definiert. Die technische Lösung kann APIs, Events, Dateien oder Middleware nutzen; entscheidend sind unterstützte, sichere und wartbare Wege. Monitoring und klar zugewiesene Klärungsprozesse machen aus einer Datenübertragung eine betreibbare Integration.