Die Integration von CRM und ERP wird fast immer als Verbindungsproblem beschrieben, und sie ist fast nie eines. Beide Systeme haben dokumentierte Schnittstellen. Für beide gibt es fertige Konnektoren. Die Schwierigkeit liegt darin, dass Vertrieb und Finanzwesen jahrelang dasselbe Geschäft in zwei verschiedenen Vokabularen beschrieben haben, und die Integration ist der Ort, an dem diese beiden Vokabulare sich einigen müssen.

In dem Moment, in dem jemand fragt, ob ein zweimal konvertierter Lead ein Konto erzeugen soll oder zwei, hört das Projekt auf, ein technisches zu sein. Genau dieses Gespräch, über dreißig Felder hinweg wiederholt, ist die eigentliche Arbeit.

Fangen Sie hier an: Bevor Sie einen Konnektor oder eine Plattform auswählen, halten Sie schriftlich fest, welches System jedes gemeinsame Feld besitzt und was geschieht, wenn beide Seiten es bearbeiten. Integrationen, die diesen Schritt überspringen, sind schnell gebaut und produzieren danach jahrelang doppelte Datensätze, abweichende Summen und Berichte, denen niemand traut.

Warum CRM- und ERP-Daten nie ganz zusammenpassen

Die beiden Systeme wurden für unterschiedliche Zwecke entworfen, und ihre Datenmodelle bilden das ehrlich ab.

Ein CRM ist um das Werben um Umsatz herum gebaut. Seine zentralen Objekte sind Personen, Verkaufschancen und Aktivitäten, und es duldet Ungenauigkeit, weil ein halb bekannter Interessent immer noch festhaltenswert ist. Ein ERP ist um das Festhalten von Verpflichtungen herum gebaut. Seine zentralen Objekte sind Debitoren, Aufträge, Rechnungen und Hauptbuchkonten, und es duldet nichts, weil sein Ergebnis am Ende stimmen muss.

Die Folgen zeigen sich sofort. Eine einzige Organisation ist im CRM ein Konto und im ERP drei Kundenstämme, weil sie über drei Tochtergesellschaften mit unterschiedlichen Zahlungszielen einkauft. Eine Menge von eins bedeutet im CRM eine Lizenz und im ERP eine Position mit zwölf Monatsraten. Eine vom Vertrieb berechnete Angebotssumme weicht um ein paar Pfund von der Rechnungssumme ab, weil Steuer und Rundung im Finanzsystem zu Hause sind und im anderen nur genähert wurden.

Nichts davon ist ein Fehler. Es sind zwei zutreffende Modelle desselben Geschäfts. Integration heißt, Feld für Feld zu entscheiden, welches Modell gewinnt, und diese Entscheidung verlangt Menschen aus beiden Abteilungen im selben Raum. Wer anbietet, mit dem Bauen zu beginnen, bevor das geschehen ist, verschiebt den schwierigsten Teil auf den Zeitpunkt, an dem er am teuersten zu ändern ist.

Die vier Integrationsmethoden

Es gibt nur vier gebräuchliche Ansätze, und der richtige hängt vor allem davon ab, wie viele Systeme Sie haben und wie viel Geld im Spiel ist.

Punkt zu Punkt. Sie schreiben eine direkte Verbindung zwischen den beiden Systemen. Das ist für ein einzelnes Paar die schnellste und günstigste Möglichkeit, und es funktioniert einwandfrei, solange Sie tatsächlich nur zwei Systeme haben. Das Problem kommt mit dem dritten. Jedes weitere System vervielfacht die Zahl der Verbindungen, und eine Landschaft aus sechs auf diese Weise verbundenen Systemen lässt sich nicht mehr gefahrlos ändern.

Integrationsplattform. Ein gehostetes Middleware-Produkt sitzt zwischen Ihren Systemen und liefert fertige Konnektoren, Werkzeuge zur Feldzuordnung, Wiederholungslogik und Überwachung. Es nimmt Ihnen viel undifferenzierte Arbeit ab und gibt auch Nicht-Entwicklern Einblick in das, was tatsächlich fließt. Die Kehrseiten sind Lizenzkosten, die mit dem Volumen steigen, Grenzen dabei, wie weit sich die fertigen Konnektoren an ungewöhnliche Anforderungen biegen lassen, und eine neue Anbieterabhängigkeit an kritischer Stelle.

Bus und Stapelaustausch

Nachrichtenbus oder ereignisgetrieben. Systeme veröffentlichen Ereignisse, und Interessierte abonnieren sie. Das passt zu größeren Landschaften, liefert von selbst eine Prüfspur und entkoppelt die Systeme, sodass der Ausfall eines einzelnen die übrigen nicht anhält. Es verlangt mehr ingenieurtechnische Reife als die Alternativen und ist für ein Unternehmen, das genau zwei Systeme verbindet, überdimensioniert.

Geplanter Dateiaustausch. Unmodern, weiterhin weit verbreitet und manchmal genau richtig. Nächtliche Exporte und Importe sind einfach, nachvollziehbar und leicht erneut einzuspielen. Für Finanzdaten, die ohnehin täglich abgestimmt werden, sind sie völlig angemessen, und für alles, was ein Vertriebsmitarbeiter unmittelbar nach dem Speichern sehen will, völlig unangemessen.

Den meisten mittelgroßen Unternehmen dient eine Plattform für die Routineflüsse am besten, ergänzt um etwas eigenen Code für die zwei oder drei Fälle, die die Plattform schlecht abbildet. Reinheit in die eine wie in die andere Richtung kostet meist mehr als die Mischung.

Wer welches Feld besitzt

Die Hoheit über die Stammdaten ist die Entscheidung, die über den Erfolg der Integration bestimmt, also treffen Sie sie ausdrücklich und schreiben Sie sie auf.

Das tragfähige Muster ist eine einzige Hoheit je Feld, nicht je Datensatz. Der Vertrieb besitzt den Namen des Ansprechpartners, die Telefonnummer und die Phase der Verkaufschance. Das Finanzwesen besitzt das Kreditlimit, die Zahlungsbedingungen, die Rechnungsanschrift und alles, was im Hauptbuch auftaucht. Jedes Feld fließt nur in eine Richtung, und das empfangende System zeigt es schreibgeschützt an, damit niemand Zeit damit verschwendet, einen Wert zu bearbeiten, der heute Nacht überschrieben wird.

Schreibgeschützte Felder in einer Oberfläche sind unbeliebt und trotzdem die richtige Antwort. Die Alternative sind zwei Menschen, die denselben Wert an zwei Stellen bearbeiten, beide überzeugt, im Recht zu sein, und ein Synchronisationslauf, der einen davon still verwirft.

Die Identitätszuordnung verdient eigene Aufmerksamkeit. Die beiden Systeme teilen sich zu Beginn keinen gemeinsamen Schlüssel, also muss etwas entscheiden, dass Acme Ltd auf der einen Seite und ACME LIMITED auf der anderen dieselbe Firma sind. Unscharfer Abgleich über Name, Postleitzahl und Handelsregisternummer bringt Sie den größten Teil des Weges, der Rest braucht menschliche Prüfung. Bauen Sie diese Prüfliste bewusst, denn die Alternative ist ein automatischer Abgleich, der zwei tatsächlich verschiedene Kunden still verschmilzt, was viel schwerer aufzulösen ist als ein Rückstand.

Nach dem Abgleich speichern Sie die Zuordnung. Eine Tabelle mit beiden Schlüsseln, gepflegt von der Integration selbst, ist mehr wert als jede noch so kluge Logik zum wiederholten Zuordnen.

Was tatsächlich schiefgeht

Die Fehlerbilder wiederholen sich gleichmäßig genug, um dafür planen zu können.

Duplikate vermehren sich still. Ein in einem System angelegter Datensatz kommt im anderen an, wird dort angelegt und läuft als neuer Datensatz zurück. Ohne gespeicherte Zuordnung und ohne idempotente Verarbeitung wird aus einem Kunden über ein Wochenende hinweg vier. Das ist der mit Abstand häufigste Integrationsfehler dieser Art.

SaaS-Plattformen erzwingen Grenzen, die Sie nicht eingeplant haben. Cloud-Produkte für CRM und ERP begrenzen die Zahl der API-Aufrufe je Zeitraum, und diese Grenzen hängen an Ihrer Lizenzstufe, nicht an Ihrem Bedarf. Eine Integration, die je Datensatz einen Aufruf macht, verbraucht das Kontingent zum Monatsabschluss, also genau dann, wenn es darauf ankommt. Nutzen Sie Massenschnittstellen für Volumen, bündeln Sie, wo es geht, und rechnen Sie die erwartete Zahl der Aufrufe vor dem Bauen aus statt nach dem ersten Ausfall.

Anpassungen driften. Jemand ergänzt am Dienstag im CRM ein neues Pflichtfeld, und am Mittwoch weist die Integration Datensätze zurück, weil sie es nicht füllt. Ein Änderungsprozess, der beide Systeme und die Integration dazwischen umfasst, ist unglamourös und verhindert die meisten dieser Vorfälle.

Probleme, die erst nach dem Go-live auftauchen

Testsysteme lügen und werden dann zurückgesetzt. Testumgebungen sind häufig vor Monaten gezogene Kopien mit anderer Konfiguration und anderen Datenmengen. Schlimmer noch: Ein Zurücksetzen der Testumgebung löscht oft die Integrationskonfiguration, was Teams mitten im Test bemerken. Dokumentieren Sie den Wiederaufbau beim ersten Mal.

Zeitverhalten erzeugt Scheinprobleme. Wenn das CRM sofort und das ERP nächtlich synchronisiert, meldet ein Vertriebsmitarbeiter einen Fehler, der in Wahrheit nur die Verzögerung ist. Vereinbaren Sie je Fluss die Latenz, sagen Sie sie den Anwendern deutlich, und zeigen Sie in der Oberfläche einen Zeitstempel der letzten Aktualisierung. Die meisten Beschwerden über Integrationen sind Beschwerden über unerklärte Verzögerung.

Anbieter-Upgrades zerlegen Konnektoren. Beide Plattformen aktualisieren nach eigenem Plan, und verwaltete Pakete ändern gelegentlich ihr Verhalten. Abonnieren Sie die Abkündigungshinweise beider Anbieter und halten Sie ein Wartungsbudget für die Arbeit bereit, die daraus entsteht. Die weiter gefassten Muster gelten für jedes fremde System, und unser Leitfaden zur Integration fremder APIs behandelt die Praktiken, die sie eingrenzen.

Was die CRM- und ERP-Integration kostet

Die Kosten schwanken enorm mit der Zahl der einbezogenen Objekte, deshalb ist die nützliche Einteilung die nach Anspruch statt nach System.

Ein einseitiger Fluss über ein einziges Objekt, etwa das Übergeben gewonnener Verkaufschancen als Kundenaufträge ins ERP, läuft typischerweise von 8.000 bis 20.000 Pfund einschließlich Feldzuordnung, Fehlerbehandlung und Test. Eine beidseitige Synchronisation von Konten und Kontakten, mit Zuordnung und Prüfliste, landet üblicherweise zwischen 25.000 und 60.000 Pfund. Eine vollständige Integration der Landschaft über Konten, Kontakte, Artikel, Preise, Aufträge, Rechnungen und Zahlungen hinweg ist ein Programm und kein Projekt, beginnt häufig bei rund 75.000 Pfund und steigt mit der Zahl der beteiligten kundenspezifischen Objekte.

Rechnen Sie Plattformlizenzen hinzu, wenn Sie Middleware einsetzen; sie werden meist nach Volumen oder Zahl der Konnektoren berechnet und werden zu dauerhaften Betriebskosten. Rechnen Sie jährlich zehn bis zwanzig Prozent der Baukosten für Wartung hinzu, weil beide Anbieter ihre Produkte weiter verändern werden.

Die Ersparnis, auf die es ankommt, liegt nicht im Bauen. Sie liegt in der Begrenzung des Umfangs. Die meisten Organisationen, die alles integrieren, stellen fest, dass ein Drittel der Flüsse nie genutzt wird, und jeder davon muss trotzdem gepflegt werden. Beginnen Sie mit den zwei oder drei Flüssen, die echte Handarbeit beseitigen, weisen Sie deren Nutzen nach, und erweitern Sie dann. Unser Leitfaden zu Kosten individueller Softwareentwicklung zeigt, wie sich das in ein größeres Budget einfügt, und unser Leitfaden zu Eigenbau oder Zukauf lohnt sich zuerst, wenn Sie die Systeme selbst noch auswählen.

Damit es dem Alltag standhält

Eine dauerhafte Integration erkennt man an ihren betrieblichen Eigenschaften, nicht an ihrem Funktionsumfang.

Jeder Fluss sollte beobachtbar sein, das heißt, jemand kann in unter einer Minute und ohne Datenbankzugriff beantworten, ob ein bestimmter Auftrag im ERP angekommen ist. Fehlgeschlagene Datensätze sollten in einer Warteschlange landen, in der man sie korrigieren und erneut einspielen kann, statt in einer Logdatei zu verschwinden. Alarme sollten eine verantwortliche Person erreichen und zwischen einer vorübergehenden Störung und einem echten Datenproblem unterscheiden.

Vor allem sollte es einen Abgleichlauf geben, der planmäßig Anzahlen und Summen zwischen den Systemen vergleicht und Unterschiede meldet. Das Finanzwesen baut sich einen informell, wenn Sie keinen förmlich bauen, und deren Fassung wird eine Tabellenkalkulation sein.

Bringen Sie Ihre Systeme zum Reden

Mecanik liefert CRM- und ERP-Integration im Rahmen unserer individuellen Softwareentwicklung . Wir beginnen mit der Hoheitskarte statt mit dem Konnektor, weil dort die Streitfragen wohnen und dort die Kosten entschieden werden.

Wir bauen die Zuordnungslogik, den Speicher für Querverweise, die Warteschlange zum erneuten Einspielen und den Abgleichlauf standardmäßig, und wir arbeiten gern mit der Middleware, die Sie bereits lizenziert haben, statt auf einer bestimmten Plattform zu bestehen. Ist Ihre Integration Teil eines größeren Wachstumsvorhabens, zeigt unser Playbook zur Skalierung im E-Commerce , wie diese Systeme bei steigendem Bestellvolumen zusammenspielen.

Sagen Sie uns, welche zwei Systeme Sie verbinden und welche drei Dinge Sie nicht mehr von Hand tun wollen, und wir schneiden den Umfang von dort aus zu.

Siehe auch: Software-Lizenzmodelle: Leitfaden für Unternehmen 2026 , KI-Integration fur KMU in Großbritannien , OpenAI-API-Integration: GPT in eine bestehende App , Entwicklung von Medizin- und Gesundheitswebsites im UK 2026 .

Häufig gestellte Fragen

Wie lange dauert eine CRM- und ERP-Integration? Ein einzelner einseitiger Fluss dauert typischerweise drei bis sechs Wochen einschließlich Feldzuordnung und Test. Eine beidseitige Synchronisation von Konten und Kontakten dauert meist zwei bis vier Monate, vor allem weil Identitätszuordnung und Hoheitsentscheidungen Beiträge aus Vertrieb und Finanzwesen verlangen.

Was ist der häufigste Fehler bei der CRM- und ERP-Integration? Nicht vor dem Bauen zu entscheiden, welches System jedes Feld besitzt. Ohne diese Entscheidung bearbeiten beide Systeme weiterhin dieselben Werte, die Synchronisation überschreibt Änderungen unvorhersehbar, und die Anwender verlieren binnen Wochen nach dem Go-live das Vertrauen in die Daten.

Brauche ich eine Integrationsplattform oder eigenen Code? Die meisten mittelgroßen Organisationen nutzen eine Plattform für die Routineflüsse und etwas eigenen Code für die Fälle, die die Konnektoren schlecht abbilden. Eigener Code allein ist bei genau zwei Systemen vernünftig, während eine Plattform ihre Lizenzkosten ab vier Systemen verdient.

Warum entstehen nach einer Integration doppelte Datensätze? Meist weil kein Querverweis zwischen den Schlüsseln der beiden Systeme gespeichert wird, sodass ein in einem System angelegter Datensatz beim Rücklauf als neuer importiert wird. Speichern Sie beide Schlüssel in einer Zuordnungstabelle und machen Sie jede Verarbeitung idempotent.

Wie viel sollte ich für die laufende Wartung einplanen? Rechnen Sie jährlich mit zehn bis zwanzig Prozent der ursprünglichen Baukosten. Beide Anbieter aktualisieren ihre Plattformen unabhängig voneinander, Konnektoren werden abgekündigt, und Konfigurationsänderungen in einem der beiden Systeme können Flüsse zerlegen, die am Vortag noch liefen.