CRM und ERP verbinden: Wann lohnt sich die Integration?

Ein Vertriebsmitarbeiter legt einen neuen Kunden im CRM an. Sobald daraus ein Auftrag wird, erfasst ein Kollege dieselben Daten noch einmal im ERP oder in der Buchhaltungssoftware. Ändert sich später die Lieferadresse oder der Auftragsstatus, beginnt die Suche: Welches System enthält den aktuellen Stand? Und wer muss die Änderung noch manuell übertragen?

Genau an diesem Punkt kann es sinnvoll sein, CRM und ERP zu verbinden. Eine Integration lohnt sich vor allem dann, wenn dieselben Daten regelmäßig in mehreren Systemen benötigt werden, manuelle Übertragungen Zeit kosten oder Fehler direkte Auswirkungen auf Vertrieb, Auftragsabwicklung und Kundenservice haben.

Dafür muss nicht zwangsläufig eine große Individualsoftware entstehen. Häufig genügt eine klar abgegrenzte Schnittstelle für einen einzelnen Prozess. Entscheidend ist weniger, wie viele Systeme technisch verbunden werden könnten, sondern welcher Datenfluss im Alltag tatsächlich einen messbaren Aufwand verursacht.

CRM und ERP erfüllen unterschiedliche Aufgaben

Ein CRM unterstützt in erster Linie die Arbeit mit Interessenten und Kunden. Dort liegen beispielsweise Ansprechpartner, Gesprächsnotizen, Verkaufschancen, Angebote, Aktivitäten und Wiedervorlagen. Für den Vertrieb soll erkennbar sein, was mit einem Kunden besprochen wurde und welcher nächste Schritt ansteht.

Ein ERP steuert dagegen operative Abläufe. Je nach System gehören dazu Artikel, Preise, Lagerbestände, Einkauf, Aufträge, Lieferungen, Rechnungen oder Produktionsdaten. Es beantwortet andere Fragen: Ist die Ware verfügbar? Wurde der Auftrag freigegeben? Wann kann geliefert werden? Ist die Rechnung bereits erstellt?

Diese Trennung ist sinnvoll. Problematisch wird sie, wenn beide Systeme dieselben Informationen benötigen, aber nicht zuverlässig austauschen. Eine Integration soll sie nicht zu einem einzigen System machen, sondern relevante Daten am richtigen Arbeitsort verfügbar halten.

Welche Daten zwischen CRM und ERP fließen sollten

Nicht jede Information muss in beide Richtungen übertragen werden. Ein guter Datenfluss beginnt mit der Frage: Wer benötigt welche Information, zu welchem Zeitpunkt und für welchen Arbeitsschritt?

Typische Beispiele sind:

• Kunden- und Ansprechpartnerdaten aus dem CRM für die Auftragserstellung im ERP
• Artikel, Preise und Verfügbarkeiten aus dem ERP für Angebote im CRM
• gewonnene Verkaufschancen aus dem CRM als neuer Auftrag im ERP
• Auftrags-, Liefer- oder Bearbeitungsstatus aus dem ERP zurück an das CRM
• Rechnungs- und Zahlungsstatus aus der Buchhaltung für Vertrieb oder Kundenservice

Dabei sollte nicht vorschnell „alles mit allem“ synchronisiert werden. Der Vertrieb benötigt vielleicht den Lieferstatus, aber keine internen Lagerbuchungen. Das ERP braucht eine korrekte Rechnungsadresse, jedoch nicht jede Gesprächsnotiz.

Auch Echtzeit ist nicht automatisch notwendig. Ein Lagerbestand, der für die verbindliche Zusage an einen Kunden verwendet wird, kann zeitkritisch sein. Eine nächtliche Aktualisierung von Klassifizierungen oder statistischen Feldern reicht dagegen häufig aus. Je höher die Anforderungen an Aktualität und Verfügbarkeit sind, desto aufwendiger werden Entwicklung, Betrieb und Fehlerbehandlung.

CRM und ERP verbinden: Diese Möglichkeiten gibt es

Manuelle Übertragung

Bei wenigen Vorgängen kann es vertretbar sein, Daten von Hand zu übertragen. Mit steigender Zahl wächst jedoch der Aufwand, und der Übertragungsstand bleibt schwer nachvollziehbar. Für häufige oder zeitkritische Daten ist das keine belastbare Dauerlösung.

CSV- oder Excel-Import

CSV- oder Excel-Dateien eignen sich für gelegentliche Sammelübertragungen, etwa bei einer Datenbereinigung oder einem monatlichen Abgleich. Für laufende Prozesse sind sie nur eingeschränkt geeignet: Exporte, Prüfungen und Fehlerbearbeitung bleiben manuell, während schnell mehrere Dateistände entstehen.

Vorgefertigte Konnektoren

Ein Standardkonnektor ist häufig die wirtschaftlichste Lösung, wenn beide Systeme unterstützt werden und der gewünschte Ablauf nahe am vorgesehenen Standard liegt. Er kann beispielsweise Kontakte, Produkte oder Aufträge anhand fester Regeln übertragen.

Vor der Entscheidung sollte geprüft werden, welche Felder und Prozesse tatsächlich abgedeckt sind. Ein Konnektor kann auf dem Papier beide Systeme verbinden, aber dennoch an eigenen Preisregeln, kundenspezifischen Feldern oder besonderen Freigaben scheitern. Wichtig sind außerdem Protokolle, Wiederholungsmechanismen und eine nachvollziehbare Behandlung von Fehlern.

Middleware oder iPaaS

Middleware- und iPaaS-Lösungen vermitteln zwischen mehreren Anwendungen. Datenflüsse lassen sich oft schneller konfigurieren als bei einer vollständig eigenen Entwicklung. Für überschaubare Abläufe und gut dokumentierte Schnittstellen kann das ein sinnvoller Einstieg sein.

Zu berücksichtigen sind laufende Gebühren, mögliche Limits und die Abhängigkeit von der Plattform. Komplexe Geschäftsregeln werden in grafischen Abläufen nicht automatisch leichter wartbar.

Individuelle API-Integration

Eine individuelle API-Integration ist sinnvoll, wenn spezielle Regeln gelten, mehrere Systeme beteiligt sind oder Fehler zuverlässig erkannt und bearbeitet werden müssen. Sie kann genau festlegen, wann Daten übertragen, geprüft, ergänzt oder zurückgewiesen werden.

Das macht sie nicht pauschal zur besten Lösung. Entwicklung, Tests, Monitoring und Wartung müssen wirtschaftlich zum Prozess passen. Ein geeigneter Standardkonnektor ist oft vorzuziehen.

Mehr zum technischen Vorgehen finden Sie unter API-Entwicklung und Integration.

Welches System ist für welche Daten führend?

Eine der wichtigsten Entscheidungen lautet: Welches System darf einen bestimmten Wert verbindlich ändern? Ohne diese Festlegung können beide Anwendungen dieselben Daten gegenseitig überschreiben.

Die Antwort muss nicht für einen vollständigen Datensatz gelten. Sie kann feldweise unterschiedlich ausfallen. Das CRM kann beispielsweise für Ansprechpartner, Telefonnummern und Vertriebszuordnungen führend sein. Das ERP kann gleichzeitig die verbindliche Rechnungsadresse, Kundennummer oder Zahlungsbedingung verwalten.

Beispiel: CRM, ERP und Buchhaltung bei einem Händler

Ein mittelständischer Händler nutzt ein CRM für Kunden und Verkaufschancen, ein ERP für Lager und Aufträge sowie eine Buchhaltungssoftware für Rechnungen.

Nach einer gewonnenen Verkaufschance soll automatisch ein Auftrag im ERP entstehen. Dort wird der Lagerbestand geprüft. Anschließend fließt der Auftragsstatus zurück in das CRM. Nach der Rechnungsstellung soll dort zusätzlich sichtbar sein, ob die Rechnung offen oder bezahlt ist.

Eine mögliche Rollenverteilung sieht so aus:

• Interessenten und Ansprechpartner: Das CRM ist führend, solange es um Vertriebskontakte und Kommunikation geht.
• Artikel und Lagerbestand: Das ERP ist führend. Das CRM zeigt diese Informationen nur an und darf sie nicht verändern.
• Auftrag und Lieferstatus: Das ERP ist führend, weil dort die operative Bearbeitung stattfindet.
• Rechnung und Zahlungsstatus: Die Buchhaltungssoftware ist führend. CRM und ERP erhalten nur die für ihre Nutzer benötigten Statusinformationen.
• Kundenstammdaten: Die Verantwortung wird pro Feld festgelegt. Änderungen an steuerlich oder abrechnungsrelevanten Daten können beispielsweise im ERP freigegeben werden, während neue Ansprechpartner weiterhin aus dem CRM kommen.

So ist für jedes wichtige Datenfeld klar, wo der verbindliche Stand liegt.

Typische Fehler in Integrationsprojekten

Viele Probleme entstehen nicht durch die API selbst, sondern durch fehlende Entscheidungen rund um den Prozess.

Ein häufiger Fehler ist eine unkontrollierte Synchronisation in beide Richtungen. Wenn CRM und ERP dieselbe Adresse ändern dürfen, kann ein älterer Stand einen neueren überschreiben. Ebenso kritisch ist es, Daten zu übertragen, bevor Dubletten, uneinheitliche Kundennummern oder unvollständige Pflichtfelder bereinigt wurden.

Auch die Fehlerbehandlung wird oft zu spät geplant. Eine Meldung „Import fehlgeschlagen“ hilft wenig, wenn Datensatz, Ursache und erneuter Start unklar bleiben. Nötig sind Protokolle, verständliche Fehlermeldungen, Monitoring und klare Zuständigkeiten.

Weitere typische Schwächen sind:

• alle Prozesse gleichzeitig umsetzen zu wollen
• Sonderfälle erst nach dem Start zu betrachten
• fehlende Regeln für doppelte Datensätze
• Rechte und Datenschutz nur oberflächlich zu prüfen
• Testsysteme oder realistische Testdaten nicht einzuplanen
• Betrieb, Updates und Wartung nach der Entwicklung offenzulassen

Ändert ein Anbieter später API, Felder oder Berechtigungen, muss der Datenfluss erneut geprüft werden.

Welche Faktoren Aufwand und Kosten bestimmen

Der Aufwand hängt nicht allein von der Zahl der Systeme ab. Gut dokumentierte Anwendungen mit klaren APIs können leichter zu verbinden sein als ein Altsystem mit unvollständigem Datenexport.

Kosten entstehen vor allem durch die Anzahl der Datenflüsse, individuelle Geschäftsregeln, Datenqualität, erforderliche Aktualität, Zugriffsrechte, Testmöglichkeiten und gewünschte Ausfallsicherheit. Hinzu kommen laufende Aufwände für Hosting, Protokollierung, Überwachung und Anpassungen bei Systemupdates.

Vor der Umsetzung sollte der wirtschaftliche Nutzen geklärt werden: Wie oft werden Daten doppelt erfasst, welche Fehler treten auf und was passiert bei einem mehrstündigen Ausfall?

Bei OnLouis gilt daher: Nicht jedes Unternehmen braucht Individualsoftware. Wenn bestehende Anwendungen grundsätzlich passen, ist eine gezielte Integration häufig wirtschaftlicher als ein Neubau. Ein ergänzendes internes Werkzeug wird erst dann interessant, wenn Mitarbeiter zusätzlich prüfen, freigeben, priorisieren oder komplexe Sonderfälle bearbeiten müssen. Dazu passt der Ansatz einer Individualsoftware für KMU, die einen klar abgegrenzten Prozess ergänzt, statt funktionierende Systeme vollständig zu ersetzen.

So starten Sie mit einem überschaubaren Pilotprozess

Ein sinnvoller Einstieg ist ein Prozess mit erkennbarem Nutzen und klaren Grenzen. Häufig eignet sich die Übergabe einer gewonnenen Verkaufschance aus dem CRM an das ERP.

Der Pilot kann in sechs Schritten aufgebaut werden:

1. Prozess auswählen: Beschreiben Sie den heutigen Ablauf vom Auslöser bis zum Ergebnis. Konzentrieren Sie sich zunächst auf einen wiederkehrenden Vorgang.
2. Daten und Verantwortlichkeiten festlegen: Dokumentieren Sie benötigte Felder und bestimmen Sie für jedes Feld das führende System.
3. Datenqualität prüfen: Bereinigen Sie Dubletten, uneinheitliche Formate und fehlende Pflichtangaben vor der Synchronisation.
4. Übertragungsregeln definieren: Legen Sie Auslöser, Häufigkeit, Prüfungen, Duplikaterkennung und Verhalten bei Fehlern fest.
5. Sonderfälle testen: Prüfen Sie unter anderem fehlende Artikel, geänderte Adressen, stornierte Aufträge, bereits vorhandene Kunden und vorübergehend nicht erreichbare Systeme.
6. Betrieb organisieren: Bestimmen Sie, wie Fehler sichtbar werden, wer sie bearbeitet und wie fehlgeschlagene Vorgänge erneut verarbeitet werden.

Nach dem Pilot lässt sich anhand realer Erfahrungen entscheiden, ob weitere Prozesse folgen sollen.

Fazit: Integration dort einsetzen, wo sie Arbeit abnimmt

CRM und ERP zu verbinden lohnt sich, wenn wiederkehrende manuelle Übertragungen, unterschiedliche Datenstände oder fehlende Statusinformationen den Arbeitsalltag spürbar belasten. Nicht jeder Prozess braucht Echtzeit, und nicht jede Verbindung muss individuell entwickelt werden.

Für einfache Standardabläufe kann ein vorhandener Konnektor genügen. Middleware eignet sich für überschaubare Datenflüsse zwischen mehreren Anwendungen. Eine individuelle API-Integration wird interessant, wenn besondere Regeln, hohe Zuverlässigkeit oder eine nachvollziehbare Fehlerbehandlung erforderlich sind.

Nicht sinnvoll ist eine Integration, wenn nur sehr wenige Datensätze übertragen werden, ein beteiligtes System bald ersetzt wird oder der zugrunde liegende Prozess noch ständig wechselt. Dann sollte zuerst der Ablauf geklärt werden.

Sie müssen zu Beginn noch nicht wissen, welche technische Lösung passt. In einem unverbindlichen Erstgespräch kann OnLouis gemeinsam mit Ihnen erfassen, welche Systeme beteiligt sind, wo heute der größte manuelle Aufwand entsteht und welcher erste Integrationsschritt wirtschaftlich sinnvoll wäre.