CRM-ERP-Integration praxisnah planen und umsetzen

Im Vertrieb gilt das Angebot als gewonnen, in der Buchhaltung existiert der Auftrag noch nicht. Der Kunde hat seine Lieferadresse im CRM geändert, aber das ERP verwendet weiterhin den alten Datensatz. Der Außendienst verspricht eine Lieferzeit, die niemand anhand des aktuellen Lagerstands geprüft hat. Danach beginnt die Suche in E-Mails, Excel-Dateien und zwei Systemen, die eigentlich zusammenarbeiten sollten.

Genau dort zeigt sich, ob eine CRM-ERP-Integration operativ trägt oder nur Daten kopiert. Eine belastbare Verbindung synchronisiert nicht einfach Tabellen. Sie legt fest, welches System für welches Feld führend ist, wer Änderungen auslösen darf, wie Konflikte behandelt werden und wie Finanz- und Serviceprozesse nachvollziehbar bleiben. Mit sauberer Integration können KI-Agenten später Angebote prüfen, Aufträge vorbereiten, Abweichungen erklären oder Serviceteams mit belastbaren Kundendaten versorgen. Ohne klare Datenhoheit automatisieren sie dagegen nur bestehende Fehler.

Warum die CRM-ERP-Integration über Effizienz entscheidet

Ein typisches mittelständisches Unternehmen arbeitet mit einem CRM für Leads, Kontakte und Angebote sowie einem ERP für Aufträge, Lager, Einkauf und Buchhaltung. Der Vertrieb erfasst einen Kunden im CRM. Wird der Auftrag gewonnen, überträgt jemand die Daten manuell ins ERP. Die Buchhaltung ergänzt Zahlungsbedingungen, der Innendienst prüft Preise, und der Außendienst wartet auf Informationen, die längst verfügbar sein sollten.

Der Fehler liegt nicht bei einzelnen Mitarbeitenden. Das Unternehmen hat einen Prozess gebaut, in dem Menschen als Schnittstelle zwischen Systemen arbeiten. Jede zusätzliche Übergabe erzeugt eine neue Möglichkeit für doppelte Kunden, veraltete Preise, fehlende Pflichtfelder oder einen Auftrag, der zwar verkauft, aber nicht erfüllbar ist. Viele Unternehmen besitzen beide Systeme, aber kein gemeinsames Datenmodell. Die technische Ursache ist meist dieselbe: Verantwortlichkeiten sind nicht im Datenmodell verankert. Wie sich solche Prozesse grundsätzlich automatisieren lassen, beschreibt unser Beitrag zur Prozessautomatisierung mit KI.

Der operative Nutzen entsteht an den Übergaben

Eine Integration wird dann wertvoll, wenn sie einen konkreten Handgriff entfernt oder eine Entscheidung verbessert. Nach der Freigabe eines Angebots kann das CRM einen Auftrag im ERP anstoßen. Das ERP liefert den bestätigten Status zurück. Vertrieb und Service sehen dadurch nicht nur, was versprochen wurde, sondern auch, ob Auftrag, Lieferung und Rechnung tatsächlich weiterlaufen.

Für mobile Teams ist die Aktualität entscheidend. Wenn der Außendienst live auf Verfügbarkeit, Kundenstatus und offene Aufträge zugreifen kann, während zentrale Stammdaten im ERP geführt bleiben, sinkt die Zahl der Rückfragen. Entscheidend ist nicht die Unternehmensgröße, sondern der Prozess: Wer arbeitet mit welchen Informationen, und wie aktuell müssen sie sein?

KI kann auf dieser Grundlage mehr als Text erzeugen. Ein Agent kann prüfen, ob ein Kunde im ERP gesperrt ist, ob der gewünschte Artikel verfügbar ist und ob ein Rabatt innerhalb der definierten Regeln liegt. Er kann einen Auftrag vorbereiten, die Freigabe aber an eine Rolle oder einen Schwellenwert binden. KI ersetzt dabei keine Governance. Sie macht gute Governance nutzbar.

Vor der Architektur kommen drei Entscheidungen

Klären Sie zuerst, welche Prozesse wirklich synchron laufen müssen. Kundenstammdaten und Aufträge brauchen oft eine andere Aktualität als historische Verkaufsdaten. Danach definieren Sie die führenden Systeme je Objekt und Feld. Erst dann entscheiden Sie, ob eine direkte API-Verbindung, Middleware oder ein zentraler Integrations-Layer passt.

Standardannahmen aus reinen SaaS-Landschaften funktionieren im Mittelstand oft nicht. Häufig trifft ein Cloud-CRM auf ein On-Premise-ERP, eine lokale Buchhaltung und gewachsene Individuallösungen. Die Integration muss diese Realität abbilden, nicht ein idealisiertes Zielbild.

Architektur und Connector-Strategie richtig wählen

Die Architekturentscheidung sollte nicht mit der Frage beginnen, welcher Connector gerade verfügbar ist. Sie beginnt mit der Landschaft: Cloud-CRM, On-Premise-ERP, proprietäre Datenbank, lokale Buchhaltung, mobile Endgeräte und möglicherweise mehrere Gesellschaften. Eine direkte Verbindung kann für einen kleinen, stabilen Prozess sinnvoll sein. Sie wird problematisch, sobald weitere Systeme, unterschiedliche Schreibrechte oder komplexe Fehlerpfade dazukommen.

Vier Muster im direkten Vergleich

Punkt zu Punkt verbindet CRM und ERP unmittelbar. Das ist überschaubar, wenn wenige Objekte fließen und beide Systeme stabile APIs besitzen. Die Logik sitzt jedoch oft direkt in der Verbindung. Ändert sich ein Endpunkt, müssen Mapping, Fehlerbehandlung und Tests meist gemeinsam angepasst werden.

Middleware oder iPaaS trennt die Systeme durch eine Vermittlungsschicht. Dort lassen sich Transformationen, Routing, Wiederholungen und Protokollierung zentral verwalten. Der Preis ist zusätzliche Plattform-Governance. Teams müssen Datenflüsse, Zugangsdaten und Betriebsverantwortung sauber organisieren.

Ein MCP-Layer (Model Context Protocol) ergänzt die klassische Integration um kontrollierten Zugriff für KI-Agenten. Ein Agent erhält nicht pauschal Zugriff auf eine Datenbank, sondern auf definierte Werkzeuge mit Rollen, Protokollierung und erlaubten Aktionen. Das ist besonders relevant, wenn ein Agent CRM-Daten lesen, im ERP einen Auftrag vorbereiten und eine Freigabe anfordern soll.

Custom Connectoren kommen dort ins Spiel, wo Standardadapter fehlen, etwa bei BMD, DATEV, Navision, Exact, weclapp oder proprietären Systemen.

Für ältere Systeme ist eine API nicht immer vorhanden. Dann kann ein Connector über Datenbankzugriff, gesicherte Exporte oder einen lokalen Dienst arbeiten. Direkter Datenbankzugriff ist kein Freibrief zum Schreiben. Finanzrelevante Tabellen sollten nur über kontrollierte Geschäftslogik oder freigegebene Transaktionen verändert werden.

Bei ereignisgetriebenen Prozessen entscheidet die Semantik über die Stabilität. Ein Auftrag darf nicht mehrfach angelegt werden, nur weil ein Ereignis erneut zugestellt wurde. Auch kleine Eingabekanäle gehören ins Architekturdiagramm: Wenn Mitarbeitende Informationen per Sprache oder Chat erfassen, muss klar sein, ob daraus ein CRM-Aktivitätseintrag, eine Aufgabe oder ein ERP-relevanter Datensatz entsteht.

Ein MCP-Layer wie Supercenter, die Plattform, die wir entwickeln und pflegen, kann den Zugriff auf verschiedene Systeme zentral kontrollieren, statt jeden KI-Agenten direkt mit CRM, ERP und Legacy zu verbinden. Das reduziert Lock-in nicht automatisch. Es schafft aber einen sinnvolleren Ort für Richtlinien, Werkzeuge, Protokolle und Freigaben, sofern Schnittstellen und Datenmodelle dem Unternehmen gehören. Mehr zu den ERP-seitigen Schnittstellen beschreibt unser Beitrag zu KI in ERP-Systemen.

Datenmodell abgleichen und Datenhoheit je Feld definieren

Die wichtigste Integrationsfrage lautet nicht: „Welche Felder können wir synchronisieren?“ Sie lautet: Wer darf dieses Feld ändern, und welches System setzt den verbindlichen Wert? Ein CRM kann eine Telefonnummer gut verwalten. Ein ERP sollte typischerweise über Auftragsstatus, Rechnungen und Finanzdaten bestimmen. Bei Preisen, Rabatten oder Lieferadressen hängt die Antwort vom Prozess ab.

Vom Objekt zur einzelnen Eigenschaft

Beginnen Sie mit einem begrenzten Prozess, etwa „Opportunity zu Auftrag“. Listen Sie nicht nur Objekte auf, sondern deren Felder:

• Kunde: Das CRM kann Interessenten verwalten. Das ERP vergibt die verbindliche Kundennummer, sobald ein Geschäftspartner angelegt wurde.
• Kontakt: Das CRM führt Kommunikationsdaten. Das ERP erhält nur jene Kontaktdaten, die für Lieferung, Rechnung oder rechtliche Dokumente benötigt werden.
• Produkt: Das ERP führt Artikelnummer, Verkaufspreis, Steuerlogik und Verfügbarkeit. Das CRM darf diese Werte anzeigen, aber nicht frei überschreiben.
• Auftrag: Das ERP führt Auftragsnummer, Status, Positionen und Rechnungsbezug. Das CRM zeigt den Status für Vertrieb und Service.
• Notizen: Das CRM führt Gesprächsnotizen. Sie gehören nicht ungeprüft in Finanz- oder Auftragsfelder.

Diese Matrix muss auch Ausnahmen abbilden. Ein Key Account kann individuelle Preise haben. Eine Adresse kann im CRM vorerfasst, aber erst nach einer Prüfung im ERP freigegeben werden. Ein Feld kann in einem System führend sein, während das andere nur eine lesende Kopie erhält.

Konflikte sind Teil des Designs

Bidirektionale Synchronisation ohne Konfliktregeln ist keine stabile Integration. Definieren Sie für jedes gemeinsam genutzte Feld Priorität, Zeitstempel, Validierung und Eskalation. Bei einem abweichenden Zahlungsziel darf der Prozess nicht stillschweigend den zuletzt geschriebenen Wert übernehmen. Er sollte den Konflikt markieren und an die zuständige Rolle geben.

CRM-ERP-Kombinationen sind selten standardisiert und verursachen oft erheblichen Konfigurationsaufwand. Effizienzgewinne entstehen deshalb nicht automatisch durch das Einschalten eines Connectors, sondern durch klare Regeln.

Praktische Regel: Wenn niemand den führenden Wert eines Feldes benennen kann, ist das Feld noch nicht integrationsreif.

Fehlerbehandlung gehört in dieselbe Governance. Ein ungültiger Steuerwert, eine fehlende Kundennummer oder ein nicht verfügbares Produkt darf nicht als unverständlicher API-Fehler im Hintergrund verschwinden. Der Prozess braucht eine verständliche Fehlermeldung, eine Wiederholungslogik, eine verantwortliche Person und eine nachvollziehbare Historie.

Sicherheit, Governance und Compliance sauber aufsetzen

Eine funktionierende Verbindung kann trotzdem ein Kontrollproblem sein. Das passiert, wenn das CRM Finanzfelder schreiben darf, ein KI-Agent mit einem technischen Vollzugang arbeitet oder Änderungen an Kundendaten nicht nachvollziehbar bleiben. In einer hybriden Landschaft müssen technische Berechtigungen, fachliche Freigaben und lokale Prozesse zusammenpassen.

Schreibrechte nicht pauschal vergeben

Legen Sie Rollen nicht nur auf Systemebene fest. Der Vertrieb darf einen Gesprächsstatus ändern, aber nicht zwingend Zahlungsbedingungen. Die Buchhaltung darf Rechnungsdaten bearbeiten, während der Service den Rechnungsstatus lesen kann. Ein Agent sollte dieselben Grenzen einhalten und zusätzlich nur jene Aktionen ausführen, die sein konkretes Werkzeug erlaubt.

Für bidirektionale Prozesse bewährt sich eine Trennung zwischen Vorschlag, Prüfung und Verbuchung. Ein Agent kann einen Auftrag aus einer freigegebenen Opportunity vorbereiten. Die eigentliche Buchung erfolgt über einen kontrollierten ERP-Service und wird protokolliert. Dadurch bleibt die Finanztransaktion im dafür vorgesehenen System.

Audit und lokale Anschlussfähigkeit

Revisionssicherheit bedeutet mehr als ein Logfile mit technischen Fehlermeldungen. Protokollieren Sie ursprünglichen Wert, neuen Wert, Identität des Auslösers, Zeitpunkt, Quelle, Freigabe und Ergebnis. Bei automatisierten Aktionen muss erkennbar sein, welcher Agent welches Werkzeug mit welchem Kontext verwendet hat. Die Details beschreibt unser Beitrag zum Audit-Log-Management.

Österreichische Unternehmen müssen außerdem ihre lokale Systemrealität berücksichtigen. Migrationen aus On-Premise-Umgebungen in die Cloud laufen parallel zu bestehenden BMD-, Sage- oder Dynamics-Installationen. FinanzOnline-Anbindungen, Datenschutz, EU-Datenresidenz und branchenspezifische Vorgaben gehören deshalb in die Betriebsplanung. Prüfen Sie vor der Umsetzung, welche Portale, Zertifikate und Exportformate betroffen sind. Ein zentraler MCP-Layer kann Zugriffe bündeln und Systeme weniger direkt exponieren, aber er nimmt dem Unternehmen die Verantwortung für Berechtigungen, Aufbewahrung und fachliche Freigaben nicht ab.

Ein Governance-Rahmen für ERP, CRM und KI hilft, Rollen, Kontrollen und Nachweise als dauerhaftes Betriebsmodell statt als einmalige Projektaufgabe zu behandeln.

Testen, ausrollen und in den Betrieb übergeben

Eine Integration ist nicht fertig, wenn der erste Datensatz erfolgreich übertragen wurde. Im produktiven Betrieb zählen Sonderfälle: ein bereits vorhandener Kunde, eine geänderte Adresse, ein abgelehnter Rabatt, ein ERP-Ausfall, eine doppelte Nachricht oder ein Auftrag, der im ERP angenommen, aber im CRM nicht aktualisiert wurde.

Beginnen Sie mit einem Prozessvertrag. Darin stehen die beteiligten Systeme, die führenden Felder, erlaubte Zustände, erwartete Reaktionszeiten, Fehlerwege und Abnahmekriterien. Für einen Auftrag kann das bedeuten: Eine Opportunity darf nur bei definiertem Status übertragen werden, Pflichtfelder müssen validiert sein, die ERP-Auftragsnummer muss zurückkommen, und ein Fehler muss einer benannten Rolle zugewiesen werden.

Testdaten müssen reale Ausnahmen enthalten

Ein sauberer Testkatalog umfasst nicht nur den Idealpfad. Verwenden Sie anonymisierte oder eigens erzeugte Datensätze für doppelte Firmen, mehrere Lieferadressen, Sonderpreise, fehlende Steuerinformationen, gesperrte Kunden und abweichende Produktnummern. Prüfen Sie danach nicht nur den Inhalt, sondern auch Nebenwirkungen in Buchhaltung, Lager, Service und Reporting.

Technische Tests decken Mapping und API-Verträge ab. Prozess- und Rechtetests zeigen, ob eine Person oder ein Agent tatsächlich nur erlaubte Aktionen ausführen kann. Last- und Wiederholungstests prüfen, ob Nachrichten sicher erneut verarbeitet werden. Ein manuell ausgelöster Wiederholungsversuch darf keinen zweiten Auftrag erzeugen.

Pilotbetrieb mit dem Außendienst

Die Live-Anbindung mobiler Teams ist ein guter Belastungstest, weil sie Aktualität, Netzqualität und Bedienbarkeit zusammenbringt. Für einen Pilotbetrieb sollte das Team bewusst mit echten Varianten arbeiten: Produktalternativen, Liefertermine, Kundenänderungen und nachträgliche Korrekturen.

Führen Sie den Rollout schrittweise durch. Starten Sie mit einer klar abgegrenzten Einheit oder einem Prozess, beobachten Sie Fehlerbilder und erweitern Sie erst nach stabiler Abnahme. Parallel braucht der Betrieb ein Monitoring mit verständlichen Alarmen:

• Datenfluss: Welche Nachrichten stehen aus, wurden abgewiesen oder mehrfach zugestellt?
• Feldqualität: Welche Pflichtfelder fehlen, welche Werte verletzen Regeln?
• Geschäftsprozess: Wie viele Aufträge warten auf Prüfung oder bleiben in einem Zwischenstatus?
• Berechtigungen: Welche Schreibversuche wurden blockiert?
• Agentenaktionen: Welche Vorschläge wurden angenommen, geändert oder abgelehnt?

In der Übergabe müssen Runbooks, Mapping-Dokumentation, Zugangspflichten, Eskalationswege und Testfälle vorhanden sein. Definieren Sie außerdem, wer API-Änderungen bewertet und wer ein Modell oder Agentenwerkzeug freigibt. Mehr Automatisierung senkt den Betriebsaufwand nur, wenn Zustände, Daten und Verantwortlichkeiten sauber verbunden sind.

Fazit und nächste Schritte

Eine belastbare CRM-ERP-Integration beginnt nicht mit einem Mapping-Workshop und auch nicht mit einem KI-Pilot. Sie beginnt mit einer Entscheidung über Datenhoheit. Danach folgen Prozessgrenzen, Architektur, Connectoren, Sicherheitsmodell, Tests und ein kontrollierter Rollout.

Die Reihenfolge ist entscheidend:

• Governance festlegen: Bestimmen Sie für jedes relevante Feld das führende System, erlaubte Schreibrollen, Ausnahmen und den Konfliktweg.
• Prozess priorisieren: Starten Sie mit einem klaren Ablauf wie Opportunity zu Auftrag, Kundenanlage oder Serviceauskunft. Vermeiden Sie den Versuch, sofort alle Datenobjekte zu verbinden.
• Landschaft bewerten: Trennen Sie Cloud-APIs, On-Premise-Systeme, proprietäre Datenbanken und lokale Finanzprozesse. Wählen Sie Punkt zu Punkt nur dort, wo die Abhängigkeit vertretbar bleibt.
• Connectoren schützen: Kapseln Sie Legacy-Zugriffe, validieren Sie Eingaben und halten Sie die Integrationslogik aus unkontrollierten Datenbankänderungen heraus.
• KI begrenzen: Geben Sie Agenten definierte Werkzeuge für Lesen, Vorschlagen und Ausführen. Finanzielle oder irreversible Aktionen brauchen Freigaben und Audit-Trails.
• Betrieb vorbereiten: Vereinbaren Sie Monitoring, Wiederholungen, Support, API-Änderungsmanagement und regelmäßige Datenqualitätsprüfungen vor dem Go-live.

Was nicht funktioniert, ist eine bidirektionale Vollsynchronisation ohne Feldverantwortung. Ebenso riskant ist ein Agent mit Zugang zu allen Tabellen, der Geschäftslogik selbst erraten soll. Und ein einmaliger Migrationstag löst keine laufende Datenqualität, wenn danach weiterhin unklare Regeln gelten.

Die zentrale Entscheidung lautet nicht, wie schnell Daten fließen. Sie lautet, wer für jeden Wert verantwortlich ist, bevor Daten automatisch fließen.

Sprechen Sie mit uns

Wenn Sie Ihre CRM-ERP-Landschaft bewerten und Agenten sicher in ERP, CRM und Backoffice einsetzen möchten, sprechen Sie mit uns.