Kurzantwort: Um ERP und CRM zu verbinden, legen Sie zuerst einen konkreten Datenfluss fest. Entscheiden Sie pro Feld, welches System den gültigen Stand führt, wann übertragen wird und wie die Rückmeldung sichtbar wird. Prüfen Sie anschließend vorhandene Integrationen und unterstützte Importe. Eine individuelle Schnittstelle schließt die verbleibende Lücke.
Ein typischer Anlass: Das Vertriebsteam pflegt einen Vorgang im CRM, die Auftragsbearbeitung übernimmt Angaben erneut ins ERP. Die erste Frage ist, welche freigegebenen Daten tatsächlich übergeben werden sollen. Unser Angebot zur Schnittstellenentwicklung beschreibt den Projektweg; dieser Artikel hilft, die Übergabe abzugrenzen.
Eine führende Quelle pro Information festlegen
Ein vollständiger bidirektionaler Abgleich ist eine weitreichende Anforderung. Beginnen Sie mit den Informationen, die für den gewählten Vorgang gebraucht werden. Folgende Zuordnung ist ein mögliches Planungsbeispiel, keine allgemeine Regel für jedes Unternehmen:
| Information | Mögliche führende Quelle | Vereinbarte Verwendung |
|---|---|---|
| Ansprechpartner | CRM | Zum freigegebenen Vorgang übergeben |
| Kundennummer | ERP | Im CRM zuordnen und bei Übergaben verwenden |
| Artikel und Einheiten | ERP | Vor der Auftragserstellung abgleichen |
| Gewähltes Angebot | CRM | Den ausdrücklich freigegebenen Stand übertragen |
| Auftragsnummer und Status | ERP | An denselben CRM-Vorgang zurückmelden |
Wenn ein Feld in beiden Systemen geändert werden darf, braucht es eine Konfliktregel. Klären Sie, wer einen widersprüchlichen Stand entscheidet. Eine laufende Synchronisierung ohne diese Entscheidung kann die fachliche Unklarheit nur häufiger weiterreichen.
Vorhandene Integration, CSV oder API?
Kurzantwort: Wählen Sie den Übertragungsweg anhand des benötigten Ablaufs und der unterstützten Funktionen Ihrer Systeme. Eine API ist kein Selbstzweck; ein CSV-Import ist kein automatischer Beleg für eine ungeeignete Lösung.
| Weg | Wann er ein Prüfkandidat ist | Was vor der Entscheidung offen sein muss |
|---|---|---|
| Unterstützte Herstellerintegration | Der benötigte Vorgang wird bereits abgedeckt | Eigene Felder, Richtung, Rückmeldung und Wartungszuständigkeit |
| CSV-Import und Export | Eine geplante Datenübernahme genügt | Dateiformat, Zuordnung, Prüfung und Wiederholung |
| Individuelle API-Verbindung | Vorgänge oder Rückmeldungen brauchen einen gezielten Austausch | Dokumentation, Berechtigungen, Lizenz und Fehlerverhalten |
| Kombination | Verschiedene Informationen brauchen unterschiedliche Aktualität | Zuständigkeit und Status jedes einzelnen Übergabeschritts |
Lassen Sie denselben Beispielvorgang über jeden passenden Weg durchspielen. Für den Vergleich zählen auch abgelehnte Datensätze und die Arbeit nach einer Störung. Fehlt eine dokumentierte API, klären Sie mit dem Systemverantwortlichen die unterstützten Import- und Exportmöglichkeiten.
Beispiel: Ein CRM-Vorgang wird zum ERP-Auftrag
Illustratives Beispiel, kein Kundenprojekt: Der Vorgang „CRM-Beispiel-42“ enthält einen Kunden, zwei Positionen und einen gewünschten Termin. Das Vertriebsteam gibt den geprüften Stand zur Übergabe frei. Das ERP soll daraus einen Auftrag anlegen und seine Nummer zurückmelden.
- Freigabe erkennen: Nur der vereinbarte Status löst die Übergabe dieses Stands aus.
- Angaben prüfen: Kundenzuordnung, Artikel, Mengen und Pflichtfelder passen zum ERP.
- Übernahme ausführen: Die freigegebenen Angaben werden über den gewählten Zugang übertragen.
- Rückmeldung zuordnen: Auftragsnummer oder Ablehnung wird am ursprünglichen CRM-Vorgang sichtbar.
- Ausnahme bearbeiten: Bei einem unklaren Ergebnis prüft die zuständige Person, was bereits übernommen wurde.
Ein Fehlerstatus braucht eine Zuständigkeit. Das Team muss erkennen, ob Angaben zu korrigieren sind, ein Zugang fehlt oder eine vorübergehende Störung vorliegt. Googles API-Leitlinie AIP-193 beschreibt strukturierte Fehlerantworten. Unsere Empfehlung für den betrieblichen Ablauf ist, daraus eine verständliche Ursache und einen passenden nächsten Schritt abzuleiten.
Wiederholung und Änderung getrennt behandeln
Microsoft erläutert im Retry-Pattern, warum ein fehlendes Ergebnis nicht beweist, dass eine Aktion ausgeblieben ist: Ein Dienst kann die Anfrage bearbeiten, während seine Rückmeldung verloren geht. Ein erneuter Versuch kann dann eine Aktion doppelt auslösen.
Für das Auftragsbeispiel vereinbaren wir deshalb diese Gegenproben:
| Fall | Zu prüfendes Verhalten |
|---|---|
| Derselbe freigegebene Stand kommt erneut | Dem ursprünglichen Vorgang zuordnen; keinen zweiten Auftrag erzeugen |
| ERP übernimmt, die Antwort fehlt | Ergebnis abgleichen oder zur Klärung geben, bevor erneut angelegt wird |
| Der Kunde ändert später die Menge | Eine ausdrücklich erlaubte Änderung prüfen; nicht als bloße Wiederholung behandeln |
| Ein Artikel ist unbekannt | Vorgang mit nachvollziehbarer Ursache zur Bearbeitung geben |
| Der Zugang zum ERP fällt aus | Stand sichtbar halten und eine begrenzte Wiederaufnahme ermöglichen |
Ob das ERP stabile Vorgangskennungen, geeignete Abfragen oder einen sicheren Wiederholungsmechanismus unterstützt, gehört zur Machbarkeitsprüfung. Eine lokale Kennung allein garantiert keinen Schutz vor einer doppelten Anlage im Zielsystem. Die Änderungsregel klärt zusätzlich, welche übernommenen Daten wann noch geändert werden dürfen.
Was Sie für den Projektstart vorbereiten können
Für das erste Gespräch hilft eine kurze Beschreibung statt eines vollständigen Datenexports:
- Namen und Versionen der beteiligten Systeme sowie Ihre technischen Ansprechpartner.
- Einen Vorgang mit Ausgangszustand, Freigabe und gewünschter Rückmeldung.
- Die benötigten Felder und ihre jeweilige führende Quelle.
- Zwei oder drei heute bekannte Fehler- oder Änderungsfälle.
- Anforderungen an Aktualität, Nachvollziehbarkeit und laufende Betreuung.
Die Details zu Zugängen und Beispieldaten klären wir anschließend über einen vereinbarten Weg. Der bezahlte Discovery-Sprint bei NLD kostet 4.900 € netto und dauert 5 Arbeitstage. Er liefert eine Live-Demo, eine Bewertung und eine Entscheidungsempfehlung. Der produktive Anschluss an ERP und CRM ist ein gesonderter Build, den Sie optional beauftragen können.
Wenn der Engpass schon bei einem PDF-Anhang beginnt, betrachten Sie zunächst die KI-Dokumentenverarbeitung. Wenn Kunden den übertragenen Projektstand sehen sollen, ist die Kundenportalplanung der nächste Schritt. Ihren ERP-/CRM-Datenfluss mit Simon besprechen.
Quellen und weiterführende Dokumente
- Retry pattern: Wiederholungen und IdempotenzMicrosoft Learn
- AIP-193: ErrorsGoogle API Improvement Proposals
Häufige Fragen
Kurz und direkt beantwortet.
Was bedeutet es, ERP und CRM zu verbinden?
Eine Verbindung übergibt festgelegte Informationen zwischen den Systemen, zum Beispiel einen freigegebenen CRM-Vorgang an das ERP und die ERP-Auftragsnummer zurück. Für jedes Feld werden führende Quelle, Übertragungsrichtung, Auslöser und Rückmeldung festgelegt.
Brauchen wir eine API oder reicht ein CSV-Import?
Ein unterstützter CSV-Import kann für geplante Übernahmen ausreichen. Eine API kommt infrage, wenn einzelne Vorgänge, Rückmeldungen oder häufigere Aktualisierungen gebraucht werden. Prüfen Sie zuerst vorhandene Integrationen, die nötige Aktualität und die Möglichkeiten beider Systeme.
Wie lassen sich doppelte Aufträge bei einer Wiederholung vermeiden?
Eine Wiederholung muss einem bereits bearbeiteten Vorgang zugeordnet werden können. Ob das Zielsystem passende Schlüssel oder Abgleichmöglichkeiten bietet, wird vor dem Build geprüft. Bei einer unklaren Antwort darf ein erneuter Versuch nicht blind einen neuen Auftrag anlegen. Ein geänderter Vorgang benötigt zusätzlich eine eigene Änderungsregel.
Braucht die Verbindung zwischen ERP und CRM KI?
Für die Übertragung vorhandener strukturierter Daten reichen häufig Importfunktionen, Feldzuordnung und nachvollziehbare Regeln. KI wird erst als eigener Prüfkandidat relevant, wenn Informationen aus wechselnden Dokumenten oder Freitext vorbereitet werden müssen.