Ratgeber · Architektur & Integration

ERP/CRM-Integration ohne Systembruch

Die meisten KI-Lösungen scheitern nicht am Modell, sondern an der Integration. Im Mittelstand sind ERP, CRM, DMS und Spezialtools über Jahre gewachsen, oft mit Eigenanpassungen, oft mit historischen Datenströmen. Eine neue KI-Komponente muss sich seitlich einfügen, ohne diese Bestandsprozesse zu brechen — sonst kostet die Einführung mehr, als die Lösung jemals einspart.

Dieser Ratgeber beschreibt die Praxisregeln für KI-Integration in gewachsene Systemlandschaften: API-first, ohne Plattform-Lock-in, mit klarer Pflege-Verantwortung nach Go-Live.

Kurzantwort

KI-Integration in gewachsene ERP-/CRM-Landschaften gelingt ohne Systembruch, wenn drei Regeln befolgt werden: API-first (Kommunikation über dokumentierte Schnittstellen, nicht direkt in Datenbanken), Anbieter-Abstraktion (Modelle hinter einer eigenen Schicht, damit später wechselbar), und klare Pflege-Verantwortung nach Go-Live (eine konkrete Person, ein klarer Plan für Schnittstellen-Updates). Wer eine dieser drei weglässt, baut Folge-Schmerz ein.

1. API-first: nicht direkt in die Datenbank greifen

Die häufigste Versuchung in der Praxis: „Wir schreiben einfach direkt in die ERP-Datenbank. Das geht am schnellsten." Das geht tatsächlich am schnellsten — und brechen lässt sich beim nächsten ERP-Update am sichersten.

Stattdessen: die KI-Komponente kommuniziert ausschließlich über die dokumentierten Schnittstellen des ERP/CRM. REST-APIs, Webservices, SOAP wo nötig, EDI für externe Geschäftspartner, strukturierte Import-Formate (XML, CSV) für Bulk-Vorgänge. Diese Schnittstellen sind vom Hersteller versioniert, getestet und mit Update-Pfaden versehen.

Das gilt auch dann, wenn eine direkte DB-Anbindung technisch möglich wäre und die Schnittstellen langsamer sind. Der Geschwindigkeits-Nachteil wird durch Stabilität, Auditierbarkeit und Update-Sicherheit deutlich überkompensiert.

2. Anbieter-Abstraktion: Modelle wechselbar halten

Der KI-Markt ist 2025/2026 in Bewegung. Modelle werden quartalsweise besser, Anbieter ändern Preise, neue Anbieter tauchen auf, alte verschwinden. Wer seine KI-Lösung fest gegen einen einzelnen Anbieter baut, bindet sich operativ — und zahlt jeden Preis-Update, jeden Funktions-Cut, jeden Politikwechsel mit.

Die Lösung ist eine eigene Abstraktionsschicht zwischen Anwendung und Modellanbieter. Die Anwendung spricht mit einer internen Schnittstelle (z. B. „Extrahiere Felder aus diesem Beleg"). Hinter dieser Schnittstelle steht der konkrete Anbieter — und kann später getauscht werden, ohne dass die ERP-/CRM-Integration angefasst werden muss.

Diese Disziplin kostet rund 10 Prozent zusätzlichen Implementierungsaufwand. Und sie spart Größenordnungen in der späteren Migration. Im Mittelstand ist sie nicht optional — sie ist die einzige Versicherung gegen Anbieter-Politik, die niemand kontrolliert.

3. Datenfluss-Hygiene: Master-Daten kennen ihren Ort

Eine integrierte KI-Lösung berührt fast immer Master-Daten: Lieferanten, Kunden, Artikel, Konten. Hier gilt eine strenge Regel: jede Master-Daten-Entität hat ein und nur ein führendes System. Die KI-Komponente liest dort und schreibt nur in nicht-führende Systeme oder in ihr eigenes Audit-Log.

Konkretes Beispiel: Wenn die KI einen neuen Lieferanten erkennt, der noch nicht im ERP existiert, legt sie ihn nicht selbst an. Sie eskaliert mit Begründung an den Menschen, der ihn nach Standardprozess im ERP anlegt. Erst danach kann die KI weiter verarbeiten. Diese Disziplin verhindert, dass über die KI-Schiene Master-Daten entstehen, die das Stammdaten-Team nie gesehen hat — und die später für Inkonsistenzen sorgen.

Praxisregel: Die KI ist ein Konsument von Stammdaten und ein Erzeuger von Bewegungsdaten. Sie ist nie ein Erzeuger von Stammdaten.

4. Pflege-Verantwortung: vor Go-Live geklärt

Schnittstellen leben. ERP-Hersteller veröffentlichen Quartals-Updates, CRM-Anbieter ändern API-Versionen, Cloud-Plattformen deprecaten Endpunkte. Wenn niemand diese Änderungen verfolgt und vorab im Staging-System testet, lernt das Unternehmen davon im Ausfall — und das ist der teurere Weg.

Drei Modelle sind im Mittelstand üblich:

Modell A: Interne IT übernimmt vollständig

Funktioniert, wenn die interne IT bereits Schnittstellen-Pflege als laufende Aufgabe etabliert hat. Voraussetzung: dokumentierte Schnittstellen, klare Test-Strategie, ausreichend Zeitanteil.

Modell B: Externer Partner via Managed Services

Der Implementierungspartner übernimmt nach Go-Live die laufende Schnittstellen-Pflege im Rahmen eines Service-Vertrags. Übliche Form: monatliche Pauschale, definierte SLAs für Reaktion und Behebung, monatlicher Ops-Report.

Modell C: Hybrid

Interne IT trägt die operative Verantwortung, der externe Partner steht als Backup bereit (z. B. für Eskalationen oder spezielle Updates). Das ist das in DACH-KMU häufigste Modell.

5. Welche Systeme in der Praxis gut integrierbar sind

Im DACH-Mittelstand sind diese Systeme verbreitet und in der Regel gut integrierbar (alle mit dokumentierten Schnittstellen, alle mit aktiven Update-Pfaden):

ERP

SAP S/4HANA, SAP Business One, Microsoft Dynamics 365, Oracle NetSuite, Sage 100, Sage X3, BMD, Microsoft Dynamics NAV (Legacy).

CRM

HubSpot, Salesforce, Microsoft Dynamics 365 Sales, Pipedrive, Zoho. Alle mit etablierten REST-APIs und Webhook-Mechanismen.

Buchhaltung (DACH-spezifisch)

DATEV, BMD, Lexware Office, sevDesk, Buchhaltungsbutler. Strukturierte Import-Formate (DATEV-CSV, ASCII-Schnittstellen) sind verbreitet.

Schwieriger werden

Alte Eigenentwicklungen ohne dokumentierte APIs, stark angepasste Branchenlösungen, Excel-basierte „ERPs". Hier hilft eine ETL-Brücke, ist aber kostenintensiver.

Wann eine ERP-/CRM-Integration sauber gelingt — und wann nicht

Sauber möglich, wenn

• Zielsystem hat dokumentierte API oder Schnittstelle
• Master-Daten haben ein klares führendes System
• Anwender im ERP/CRM merken keine Änderung in ihrer Arbeitsumgebung
• Pflege-Verantwortung nach Go-Live ist vor Projektstart benannt
• Anbieter-Abstraktion ist in der Architektur eingeplant

Schwierig oder nicht möglich, wenn

• Zielsystem hat keine offene Schnittstelle
• Master-Daten existieren in mehreren konkurrierenden Quellen
• Direkter DB-Schreibzugriff wird als „schneller Weg" verkauft
• Niemand übernimmt nach Go-Live die Schnittstellen-Pflege
• Modell-Aufrufe sind hart in die Anwendung verdrahtet

Häufige Fragen zur ERP-/CRM-Integration

Was bedeutet „Integration ohne Systembruch" konkret?

Bestehende Bestands- und Buchungsprozesse laufen ungestört weiter — die KI-Lösung wird seitlich an die offenen Schnittstellen angedockt und füttert die Zielsysteme über die Wege, die ohnehin schon definiert sind (REST-APIs, EDI, strukturierter Import). Anwender im ERP/CRM merken keine Änderung an ihrer Arbeitsumgebung, nur an der Bearbeitungszeit pro Vorgang.

Welche ERP-/CRM-Systeme lassen sich heute gut anbinden?

Im DACH-Mittelstand verbreitet: SAP S/4HANA, SAP Business One, BMD, DATEV, Microsoft Dynamics 365, Sage 100/X3, Oracle NetSuite, HubSpot, Salesforce, Pipedrive. Alle bieten dokumentierte REST-APIs oder Webservices. Schwieriger werden ältere Eigenentwicklungen oder stark angepasste Branchenlösungen — hier kann eine ETL-Brücke nötig sein.

Wie verhindert man Plattform-Lock-in bei der KI-Integration?

API-first-Architektur: Die KI-Komponente kommuniziert über generische Schnittstellen mit Standard-Formaten, nicht über proprietäre SDKs einzelner Anbieter. Das Modell selbst (LLM, OCR, Klassifikation) wird hinter einer eigenen Abstraktionsschicht gekapselt, sodass ein späterer Anbieter-Wechsel möglich bleibt. Diese Disziplin kostet ~10 Prozent Mehraufwand in der Implementierung und spart Größenordnungen in der späteren Migration.

Wer betreibt die Schnittstelle nach Go-Live?

Diese Frage muss vor Projektstart geklärt sein. Drei Modelle sind üblich: (1) interne IT übernimmt vollständig, (2) externer Implementierungspartner pflegt im Rahmen eines Managed-Services, (3) Hybrid — interne Verantwortung mit externer Backup-Bereitschaft bei Vorfällen. Wer die Antwort offenlässt, riskiert, dass nach Go-Live niemand reagiert, wenn das Zielsystem updated wird.

Was passiert, wenn das ERP/CRM ein Major-Update bekommt?

Schnittstellen-Verträge (API-Versionen, Datenformate) ändern sich gelegentlich. Eine saubere Integration ist gegen das genutzte API-Versionsschema gebaut, mit dokumentierten Tests und einer Roadmap-Verbindung zum Anbieter-Update-Plan. Im Idealfall passieren Anpassungen vorab im Staging-System, bevor das Produktiv-Update kommt. Wer das nicht plant, lernt es im Ausfall — und das ist immer der teurere Weg.

Integration in Ihre Systemlandschaft prüfen?

Eine kostenlose KI-Potenzialanalyse bewertet die Integrierbarkeit Ihrer konkreten Systemlandschaft: welche Schnittstellen existieren, wo sind die Engstellen, und welche Architektur passt.

KI-Potenzialanalyse anfragen