CRM und ERP verbinden: Architektur, Daten und typische Fehler

Wenn Sie CRM und ERP verbinden wollen, geht es selten um Technik allein. Es geht um eine Lücke im Ablauf: Der Vertrieb pflegt Kunden, Angebote und Chancen im CRM. Die Auftragsabwicklung, Lagerhaltung und Rechnungsstellung laufen im ERP oder in der Warenwirtschaft. Dazwischen sitzt in vielen mittelständischen Unternehmen ein Mensch, der Daten von links nach rechts überträgt. Das funktioniert, solange die Mengen klein sind. Es hört auf zu funktionieren, sobald das Geschäft wächst.

Dieser Beitrag beschreibt, wie eine tragfähige Verbindung zwischen beiden Systemen aussieht: welche Datenobjekte überhaupt fließen müssen, wie Sie die Richtung festlegen, welche Architekturen es gibt und welche Fehler in der Praxis am häufigsten für Ärger sorgen.

Warum die Lücke zwischen CRM und ERP so teuer ist

Die Kosten einer fehlenden Integration sind selten in einer Zahl sichtbar. Sie verteilen sich auf viele kleine Stellen:

• Doppelte Erfassung. Kundenstammdaten entstehen zweimal, mit zwei Schreibweisen und zwei Wahrheiten.
• Zeitverzug. Ein gewonnenes Angebot wird erst am nächsten Tag zum Auftrag, weil jemand es übertragen muss.
• Fehlerkosten. Zahlendreher in Mengen, Preisen oder Adressen fallen erst in der Auslieferung oder der Buchhaltung auf.
• Blinde Flecken. Der Vertrieb sieht nicht, ob eine Rechnung offen ist. Die Abwicklung sieht nicht, was gerade im Zulauf ist.
• Auswertungen, die niemand glaubt. Wenn zwei Systeme unterschiedliche Umsätze ausweisen, wird über Zahlen diskutiert statt über Entscheidungen.

Der eigentliche Schaden entsteht nicht durch die Minuten, die das Übertragen kostet, sondern durch das Misstrauen gegenüber den eigenen Daten. Genau hier setzt eine CRM-Integration an: nicht als Selbstzweck, sondern damit Vertriebs- und Abwicklungsdaten dieselbe Realität beschreiben.

Schritt eins: Welche Datenobjekte fließen überhaupt?

Bevor irgendjemand über Schnittstellen spricht, gehört auf den Tisch, welche Objekte zwischen den Systemen wandern sollen. In der Praxis sind es meist diese:

• Kunde oder Firma inklusive Adressen, Ansprechpartnern und Zahlungsbedingungen
• Angebot mit Positionen, Mengen und Preisen
• Auftrag als Ergebnis eines angenommenen Angebots
• Artikel oder Leistung mit Nummern, Bezeichnungen und Preislogik
• Rechnung und Zahlungsstatus als Rückkanal in Richtung Vertrieb
• Bestand oder Verfügbarkeit, wenn der Vertrieb belastbar zusagen soll

Nicht alles davon muss synchronisiert werden. Für jedes Objekt sollten Sie sich zwei Fragen stellen: Wer braucht es wirklich, und was passiert, wenn es nicht aktuell ist? Ein Bestandswert, der zehn Minuten alt ist, ist meist unproblematisch. Ein Auftragsstatus, der einen Tag alt ist, kann ein Kundengespräch peinlich machen.

Schritt zwei: Source of Truth je Datenobjekt festlegen

Die wichtigste Entscheidung einer Integration ist keine technische. Sie lautet: Welches System hat bei welchem Datenobjekt recht?

Diese Festlegung nennt man Source of Truth, also die führende Quelle. Sie wird pro Objekt getroffen, nicht pauschal pro System. Ein typisches Bild sieht so aus:

• Kundenstammdaten: führend im CRM, solange der Vertrieb sie anlegt. Sobald ein Kunde abgerechnet wird, führen häufig die kaufmännischen Stammdaten im ERP, weil dort Steuer- und Zahlungsdaten hängen.
• Angebot und Chance: führend im CRM.
• Auftrag, Lieferung, Rechnung: führend im ERP.
• Artikelstamm und Preise: führend im ERP.
• Kommunikationshistorie: führend im CRM.

Ohne diese Festlegung bauen Sie eine Integration, die im Konfliktfall raten muss. Und Konflikte treten garantiert auf: Zwei Personen ändern dieselbe Adresse in zwei Systemen innerhalb weniger Minuten. Wenn nicht vorher entschieden ist, wer gewinnt, entscheidet der Zufall der Reihenfolge.

Halten Sie die Festlegung schriftlich fest, in einer schlichten Tabelle: Datenobjekt, führendes System, Richtung, Aktualisierungsintervall, Verhalten im Konfliktfall. Diese Tabelle ist später wertvoller als jede Systemdokumentation.

Schritt drei: Richtung und Auslöser bestimmen

Aus der Source of Truth ergibt sich die Richtung. Drei Muster kommen in der Praxis vor:

Einwegsynchronisation. Ein System schreibt, das andere liest. Das ist das robusteste Muster und sollte immer die erste Wahl sein. Beispiel: Angenommene Angebote wandern aus dem CRM ins ERP, aber Auftragsdaten wandern nie zurück in die Angebotsstruktur.

Bidirektionale Synchronisation mit klarer Feldaufteilung. Beide Systeme schreiben, aber auf unterschiedliche Felder. Der Vertrieb pflegt den Ansprechpartner, die Buchhaltung die Zahlungsbedingungen. Technisch aufwendiger, aber beherrschbar, solange die Felder disjunkt sind.

Echte bidirektionale Synchronisation auf denselben Feldern. Beide Seiten dürfen dasselbe Feld ändern. Das braucht eine Konfliktregel, Zeitstempel und in der Regel ein Protokoll, das nachvollziehbar macht, welcher Wert warum gewonnen hat. Dieses Muster sollte man nur wählen, wenn es fachlich wirklich nötig ist.

Dazu kommt der Auslöser: Wird die Übertragung durch ein Ereignis angestoßen, etwa den Statuswechsel eines Angebots, oder läuft sie in festen Intervallen? Ereignisgesteuert ist schneller und sparsamer, setzt aber voraus, dass das Quellsystem Ereignisse bereitstellt. Intervallbasiert ist einfacher, dafür immer etwas hinterher. Beides ist legitim, die Entscheidung folgt dem Prozess, nicht der Mode.

Schritt vier: Architektur wählen

Für die Verbindung selbst gibt es mehrere Wege. Welcher passt, hängt von Anzahl der Systeme, Datenvolumen und Fehlertoleranz ab.

• Direkte Verbindung über die APIs beider Systeme. Wenig Zwischenschichten, gut geeignet bei zwei Systemen und überschaubarer Logik. Nachteil: Jede weitere Verbindung erhöht die Zahl der Punkt-zu-Punkt-Verbindungen überproportional.
• Integrationsplattform (iPaaS). Vorgefertigte Konnektoren, visuelle Ablaufsteuerung, schneller Start. Gut, wenn die Anforderungen den Standardfällen entsprechen. Grenzen zeigen sich bei komplexer Mapping-Logik und bei laufenden Kosten pro Vorgang.
• Eigene Integrationsschicht. Ein schlanker Dienst, der Daten entgegennimmt, prüft, übersetzt und weiterreicht, inklusive Warteschlange und Wiederholung. Aufwendiger im Aufbau, dafür voll kontrollierbar und unabhängig vom Preismodell eines Anbieters.
• Dateibasierter Abgleich in Intervallen. Wirkt altmodisch, ist aber bei Systemen ohne brauchbare Schnittstelle oft die einzige verlässliche Option.

Welche Variante wann trägt, haben wir ausführlicher in der Übersicht zur API-Integration beschrieben. Die Kurzfassung: Die Technologie folgt dem Prozess, nicht umgekehrt.

Für die ERP-Seite gilt zusätzlich eine Realitätsprüfung. Nicht jedes System stellt saubere Schnittstellen bereit, manche nur eingeschränkte oder kostenpflichtige. Was Ihr konkretes System kann, welche Grenzwerte gelten und welche Datenmodelle dahinterstehen, klärt eine technische Vorabprüfung. Mehr dazu auf der Seite zur ERP-Integration.

Typische Fehler, die Integrationen scheitern lassen

Fehler 1: Die Integration wird gebaut, bevor der Prozess geklärt ist. Wenn niemand sagen kann, was fachlich passieren soll, wenn ein Kunde in beiden Systemen leicht unterschiedlich heißt, wird diese Frage stillschweigend vom Entwicklungsstand beantwortet. Das rächt sich.

Fehler 2: Datenqualität wird als Nebensache behandelt. Dubletten, leere Pflichtfelder und uneinheitliche Formate sind vor der Integration ein Ärgernis. Danach sind sie ein Störfall, weil sie automatisiert vervielfältigt werden. Ein Datenprofiling vorab ist keine Kür.

Fehler 3: Nur der Gutfall wird getestet. Eine Integration ist erst fertig, wenn sie auch dann sauber reagiert, wenn das Zielsystem nicht erreichbar ist, ein Grenzwert überschritten wird oder ein Datensatz abgelehnt wird. Ohne Warteschlange, Wiederholungslogik und Protokoll ist jede Störung ein manueller Notfall.

Fehler 4: Doppelte Buchungen durch fehlende Idempotenz. Wird ein Auftrag zweimal übertragen, weil eine Antwort verloren ging, darf im Zielsystem trotzdem nur ein Auftrag entstehen. Das erreicht man über eindeutige Schlüssel, nicht über Hoffnung.

Fehler 5: Niemand merkt, wenn die Verbindung stillsteht. Der häufigste stille Ausfall ist ein abgelaufener Zugangsschlüssel. Ohne Überwachung und Benachrichtigung fällt das erst auf, wenn ein Kunde nachfragt.

Fehler 6: Der Wechsel aller Altdaten wird unterschätzt. Bestandsdaten aus zwei Systemen zusammenzuführen ist ein eigenes Vorhaben mit eigener Methodik. Eine Struktur dafür finden Sie im Beitrag zur Datenmigration von CRM und ERP.

Wie ein realistischer Ablauf aussieht

Ein Integrationsvorhaben zwischen CRM und ERP folgt in der Regel dieser Reihenfolge:

1. Prozess aufnehmen. Wer macht heute was, an welcher Stelle bricht der Ablauf?
2. Systemlandkarte und Datenobjekte klären. Welche Systeme sind beteiligt, welche Objekte fließen?
3. Source of Truth und Richtung festlegen. Schriftlich, pro Objekt.
4. Technische Prüfung. Welche Schnittstellen existieren, welche Grenzwerte, welche Authentifizierung, welche Datenmodelle?
5. Architektur entscheiden. Direkt, Plattform oder eigene Schicht.
6. Erst einen Pfad end-to-end bauen. Ein Objekt, eine Richtung, produktiv nutzbar, statt monatelang alles gleichzeitig.
7. Fehlerfälle testen. Ausfall, Ablehnung, Wiederholung, Duplikat.
8. Migrieren, in Betrieb nehmen, überwachen.

Der siebte und achte Punkt sind die, die in gescheiterten Projekten fehlen.

Häufige Fragen

Muss ich CRM oder ERP austauschen, um beide zu verbinden?

In den meisten Fällen nicht. Entscheidend ist, ob die vorhandenen Systeme brauchbare Schnittstellen bereitstellen und ob die Datenmodelle sich sinnvoll aufeinander abbilden lassen. Ein Austausch ist eine strategische Entscheidung und sollte nicht als Nebenwirkung einer Integration passieren.

Wie schnell müssen Daten synchron sein?

Das entscheidet der Prozess, nicht die Technik. Für Auftragsdaten ist eine Übertragung innerhalb von Sekunden bis Minuten meist sinnvoll, für Auswertungsdaten reicht oft ein nächtlicher Abgleich. Je enger die Vorgabe, desto aufwendiger Betrieb und Fehlerbehandlung.

Was kostet eine Integration zwischen CRM und ERP?

Der Aufwand wird von wenigen Treibern bestimmt: Anzahl der Systeme und Datenobjekte, Qualität der vorhandenen Schnittstellen, Zustand der Altdaten, Komplexität der Übersetzungslogik und das gewünschte Betriebsmodell. Ein belastbarer Rahmen entsteht erst nach einer technischen Prüfung. Wer ohne diese Prüfung einen Festpreis nennt, kalkuliert einen Puffer oder eine Nachforderung ein.

So gehen Sie den nächsten Schritt

CRM und ERP zu verbinden ist kein Werkzeugkauf, sondern eine Reihe von Entscheidungen: welche Objekte fließen, wer führt, was passiert im Fehlerfall. Wenn diese Entscheidungen sauber getroffen sind, wird die Umsetzung überraschend geradlinig.

Einen Überblick über Vorgehen, Architekturmuster und Betrieb finden Sie auf der Seite zur Software-Implementierung und Systemintegration. Wenn Sie wissen möchten, was in Ihrer konkreten Systemlandschaft möglich ist, lassen Sie im Erstgespräch Ihre Systemlandschaft prüfen.