Schnittstellenfür ERP und CRM
Verbinden Sie Ihre Systeme mit klaren Datenflüssen und überprüfbaren Übergaben.
Wo bleibt die Übergabe hängen?
Lokales Beispiel mit vereinbarten Feldern. Es werden keine Daten an ein System übertragen.
Lokales Beispiel ohne Verbindung zu einem echten System.
Welche Übergabe verursacht heute doppelte Arbeit?
SYNQ entwickelt Schnittstellen für Geschäftsdaten zwischen ERP, CRM und den dazugehörigen Anwendungen. Wir klären, welche Informationen übertragen werden, welches System sie führen soll und wie Ihr Team mit Fehlern umgeht. So entsteht ein abgegrenzter Datenfluss, dessen Ergebnis Sie fachlich prüfen können.
Ein gewonnener Auftrag steht im CRM, doch die Sachbearbeitung legt ihn im ERP erneut an. Dabei müssen Kundennummer, Angebotsstand und Leistungsumfang zusammenpassen. Eine Schnittstelle kann diese Übergabe übernehmen, sofern beide Systeme die erforderlichen Daten und Zugänge bereitstellen.
Beginnen Sie mit einer solchen konkreten Übergabe. Notieren Sie Auslöser, Häufigkeit, beteiligte Personen und heutige Nacharbeit. Ein Datensatz, der nur einmal im Jahr benötigt wird, rechtfertigt einen anderen Aufwand als ein Vorgang, der täglich durch mehrere Hände geht. Für seltene Übertragungen kann ein kontrollierter Export genügen. Auch eine bestehende Standardanbindung sollte zuerst auf ihre fachliche Passung geprüft werden.
Unser Fokus liegt auf Datenflüssen rund um Kunden, Angebote, Aufträge und operative Bearbeitung. Welche Produkte sich anbinden lassen, prüfen wir anhand ihrer Dokumentation, Zugangsbedingungen und Versionen. Die Existenz einer API allein bestätigt noch nicht, dass sie alle benötigten Aktionen unterstützt.
Welcher Integrationsweg passt zu Ihrer Übergabe?
Eine vorhandene Anbindung, eine Datei oder eine eigens entwickelte Verbindung können denselben Ausgangspunkt haben. Entscheidend ist, ob der Weg Ihre Felder, Freigaben und Fehlerfälle abbildet.
Prüfen Sie zuerst, ob ein vorhandenes CRM-Modul im ERP den Ablauf bereits unterstützt. Eine gemeinsame Anwendung kann Übergaben innerhalb des Produkts vereinfachen. Getrennte Systeme können sinnvoll bleiben, wenn Ihr Team deren besondere Funktionen benötigt. Vergleichen Sie die fachliche Passung zusammen mit Datenpflege, Einführungsaufwand und laufender Betreuung.
| Weg | Wann er infrage kommt | Was vorher geklärt sein muss |
|---|---|---|
| Vorhandene Standardanbindung | Sie unterstützt die benötigten Vorgänge und Felder. | Übertragene Angebotsversion, Änderungsregeln, Fehleransicht und Wartung bei Herstellerupdates. |
| Kontrollierter Datei-Export und -Import | Eine zeitversetzte Übergabe mit überschaubarer Häufigkeit genügt. | Dateiformat, sichere Ablage, zuständige Person und Abgleich der tatsächlich übernommenen Vorgänge. |
| Direkte API-Verbindung | Ein klar begrenzter Datenfluss benötigt eigene Zuordnungs- oder Freigaberegeln. | Verfügbare Lese- und Schreibaktionen, Zugriffsgrenzen, Wiederholungen und Pflege beider API-Versionen. |
| Middleware oder Low-Code-Plattform | Eine vermittelnde Anwendung soll mehrere Datenflüsse koordinieren. | Unterstützte Aktionen statt bloßer Produktlogos, Anpassungsgrenzen, Fehlerbehandlung, Betreiber und laufende Gebühren. |
Vier mögliche Wege für die Übergabe eines freigegebenen Angebots. Die Eignung hängt von den beteiligten Produkten und Ihrem Ablauf ab.
Welcher Ausgangspunkt passt zu Ihnen?
Prüfen Sie zuerst, welche Anforderungen sich mit der vorhandenen Konfiguration und den verfügbaren Zugängen abbilden lassen.
Daten übertragen. Fehler sichtbar behandeln.
Eine Kunden-ID fehlt. Sehen Sie, weshalb die Übertragung anhält und wie der korrigierte Datensatz weitergeht.
Felder zuordnen
- CRM-Feld
- account.external_id
- ERP-Feld
- customer_number
- Kunden-ID
- Nicht gesetzt
- Übertragung
- Vorbereitet
Jedes Zielfeld braucht eine benannte Quelle und eine Übertragungsregel.
Fehlende Angabe erkennen
- CRM-Feld
- account.external_id
- ERP-Feld
- customer_number
- Kunden-ID
- Nicht gesetzt
- Übertragung
- Zur Prüfung
Der Auftrag wird nicht stillschweigend angelegt. Der Fehler bleibt dem Datensatz zugeordnet.
Zuordnung korrigieren
- CRM-Feld
- account.external_id
- ERP-Feld
- customer_number
- Kunden-ID
- K-204
- Übertragung
- Erneuter Versuch
Ein Verantwortlicher ergänzt die Zuordnung. Die Ereignis-ID bleibt gleich.
Ergebnis bestätigen
- CRM-Feld
- account.external_id
- ERP-Feld
- customer_number
- Kunden-ID
- K-204
- Übertragung
- Bestätigt
Die Antwort des Zielsystems schließt den Vorgang. Ein wiederholter Versuch darf keinen zweiten Auftrag erzeugen.
Illustrativer Interface-Entwurf mit Beispieldaten. Keine Verbindung zu einem echten System.
Führendes System, Felder und Richtung festlegen
Für jeden Datenbereich braucht es eine klare Verantwortung. Das CRM könnte Ansprechpartner und Vertriebsaktivitäten führen; das ERP könnte Auftragsnummer und Bearbeitungsstatus vergeben. Welche Aufteilung passt, hängt von Ihren Abläufen ab. Legen Sie fest, wo eine Information geändert werden darf und wohin die Änderung weitergegeben wird.
Ein Feldmapping ordnet Quell- und Zielfelder zu. Es enthält außerdem Datentypen, Pflichtangaben, erlaubte Werte und Regeln für fehlende Informationen. „Kunde“ reicht als Beschreibung nicht: Welche eindeutige Kennung verbindet dieselbe Firma in beiden Systemen? Was passiert, wenn eine Firma mehrere Rechnungsadressen hat?
Das folgende Beispiel zeigt, warum die fachliche Zuordnung vor der Übertragung stehen muss.
| CRM-Eingang | Prüfung | ERP-Ziel |
|---|---|---|
| Firma C-104 | Eindeutige Zuordnung vorhanden? | Debitor K-208 |
| Angebot A-031, Version 2 | Diese Version freigegeben? | Auftragspositionen |
| Projektbeginn offen | Ist das Datum im Ziel Pflicht? | Übertragung ggf. zurückhalten |
Ein Feldmapping prüfen
Fiktive Kennungen: CRM-K001 und ERP-C001 bezeichnen denselben Kunden. Die Zuordnung muss vereinbart sein.
Wählen Sie zuerst das passende Zielfeld.
Illustratives Feldmapping mit fiktiven Kennungen. Gleich benannte Informationen sind erst nach einer vereinbarten Zuordnung übertragbar.
Wenn Sie die führenden Kundeninformationen zunächst strukturieren müssen, beschreibt unsere Seite zur individuellen CRM-Software die Arbeit mit Kontakten, Verkaufschancen und Übergaben.
Im ERP liegen häufig die operativen Abläufe rund um Ressourcen, Einkauf, Waren oder Leistungen und Abrechnung. Das CRM führt den Kunden- und Vertriebskontext. Welche Aufgabe Ihr jeweiliges System tatsächlich übernimmt, wird anhand des konkreten Vorgangs festgelegt.
So wird aus einem CRM-Auftrag ein geprüfter ERP-Datensatz
Für einen Pilotfall vereinbaren wir einen klaren Startpunkt, etwa die fachliche Freigabe einer Angebotsversion. Der Datenfluss liest die vereinbarten Felder, prüft ihre Zuordnung und übergibt sie über den verfügbaren technischen Zugang. Anschließend wird das Ergebnis mit dem erwarteten Vorgang im Zielsystem abgeglichen.
Technischer Zugang und fachliche Prüfung
Eine technische Empfangsbestätigung beantwortet dabei eine andere Frage als die fachliche Abnahme. Wurde der richtige Kunde zugeordnet? Sind Menge, Einheit und Angebotsversion erhalten? Ist der Vorgang im gewünschten Bearbeitungsstatus angekommen? Diese Kriterien gehören in den Test, ebenso Stornierungen, Änderungen und doppelte Nachrichten.
Änderungen in zwei Richtungen
Bei zwei Übertragungsrichtungen benötigen Sie zusätzlich Regeln für konkurrierende Änderungen. Ein neuer Wert darf einen anderen Wert nicht allein deshalb überschreiben, weil er später übertragen wurde. Welche Information Vorrang hat, muss fachlich begründet und technisch umsetzbar sein.
Weiterarbeit im ERP
Die Bearbeitung nach der Übergabe bleibt Teil Ihres ERP-Ablaufs von Auftrag bis Abrechnung. Die Schnittstelle überträgt den vereinbarten Kontext; sie ersetzt keine fehlenden Freigabe- oder Bearbeitungsregeln.
Weitere Datenflüsse mit einem klaren Ergebnis.
Die Kundenreise reicht von der ersten Anfrage bis zur Betreuung nach dem Auftrag. Website, Shop oder Portal brauchen dabei jeweils bestimmte Informationen; sie benötigen keinen vollständigen Zugriff auf CRM und ERP.
Ein Website-Formular kann eine Anfrage an das CRM übergeben. Dort folgen Qualifizierung und Angebot. Erst die freigegebene Vereinbarung geht in die operative Bearbeitung; freigegebene Leistungen oder Lieferungen bilden später die Grundlage für die Abrechnung. Für jeden Übergang werden Quelle, Empfänger und fachliche Bestätigung einzeln festgelegt.
Auftragsstatus zurück in den Kundenkontext.
Ein möglicher Rückweg beginnt mit einem geänderten Bearbeitungsstatus im ERP. Auftragsreferenz, Status und Änderungszeitpunkt werden dem passenden Vorgang im CRM zugeordnet. Die Kundenbetreuung sieht damit den letzten bestätigten Stand und kann zugehörige Dokumente oder offene Servicevorgänge einordnen. Bei einem Kundenportal kommen die Prüfung des Kundenkontos und der sichtbar erlaubten Felder hinzu. Eine interne Notiz ist keine freigegebene Kundeninformation.
Berichtsdaten gemeinsam auswerten.
Für einen Vertriebsbericht können offene Chancen aus dem CRM und angenommene Aufträge aus dem ERP zu einem vereinbarten Stichtag zusammengeführt werden. Kundenkennung, Währung und Zeitraum müssen zusammenpassen; bereits angenommene Aufträge dürfen nicht zusätzlich als offene Chance zählen. Die Datenverantwortlichen gleichen Summen und Zuordnungen mit den Quellen ab. Ein solcher Analyseabzug in ein Berichtssystem oder Data Warehouse legt selbst keinen Auftrag an. Eine Prognose braucht darüber hinaus bewertete Chancen, erwartete Abschlussdaten und nachvollziehbare Annahmen.
Wie aktuell müssen die Daten sein?
Legen Sie für jeden Datenfluss fest, wie alt eine Information höchstens sein darf. Ein täglicher Bericht hat einen anderen Bedarf als die Prüfung vor einer verbindlichen Auftragszusage.
Für einen Bericht legen Sie fest, wie alt die verwendeten Daten höchstens sein dürfen.
Je nach System kann ein Ereignis eine Übertragung auslösen, etwa über einen Webhook. Alternativ fragt die Verbindung Änderungen in vereinbarten Abständen ab. Auch eine Ereignismeldung kann verspätet eintreffen oder ausfallen. Deshalb gehören letzter erfolgreicher Abgleich, erkennbare veraltete Daten und das Verhalten bei einer Unterbrechung zum Konzept. „Echtzeit“ sollte erst zugesagt werden, wenn die benötigte Verzögerungsgrenze mit den beteiligten Systemen geprüft wurde.
Fehler sichtbar machen und kontrolliert wiederholen
Eine nicht erreichbare Anwendung und eine unbekannte Kundennummer verlangen unterschiedliche Reaktionen. Bei einer vorübergehenden technischen Störung kann eine begrenzte Wiederholung sinnvoll sein. Ein fachlich ungültiger Datensatz benötigt dagegen eine Korrektur oder Entscheidung.
Wiederholungen müssen außerdem gegen doppelte Geschäftsvorgänge abgesichert werden. Hat das Ziel den Auftrag bereits gespeichert, aber keine Antwort geliefert, darf ein neuer Versuch nicht unbemerkt einen zweiten Auftrag erzeugen. Microsoft beschreibt dieses Risiko und die Unterscheidung vorübergehender Fehler im Retry-Entwurfsmuster.
- Eingang: Angebotsversion A-031/2 soll übertragen werden.
- Prüfung hält an: Die Kundenzuordnung fehlt; kein Auftrag wird freigegeben.
- Klärung: Eine zuständige Person bestätigt die Zuordnung zu K-208.
- Kontrollierter neuer Versuch: Die Vorgangskennung wird geprüft, die Übertragung ausgeführt und das Zielergebnis abgeglichen.
Illustrativer Fehlerablauf. Die Korrektur eines fachlichen Problems geht der erneuten Übertragung voraus; der Verlauf zeigt keine gemessene Systemleistung.
Zum Betriebsumfang gehört deshalb eine verständliche Fehleransicht: betroffener Vorgang, Ursache, letzter Versuch und zuständige Person. Welche Meldungen automatisch behandelt werden dürfen und welche ein Mensch freigeben muss, wird vor dem Start festgelegt.
Zugänge, Dokumentation und Zuständigkeiten klären
Wir stimmen ab, welche technischen Identitäten die Verbindung verwendet, welche Aktionen sie ausführen dürfen und wie Zugangsdaten verwaltet werden. Ein Testzugang sollte die Prüfung ermöglichen, ohne unkontrolliert Produktivdaten zu verändern. Für Protokolle wird festgelegt, welche Informationen zur Fehlersuche benötigt werden und wer sie einsehen darf.
Dokumentierte Grundlagen
Zur vereinbarten Übergabe können Feldmapping, unterstützte Versionen, Testfälle, Betriebsanleitung und Zuständigkeitsliste gehören. Benennen Sie auch die Verantwortlichen der angebundenen Systeme. Änderungen an deren Zugängen, Datenfeldern oder Schnittstellen müssen beim Betrieb der Verbindung berücksichtigt werden.
Optionale Dokumentverarbeitung
Falls Eingangsdokumente zunächst interpretiert werden müssen, ist das ein gesonderter Verarbeitungsschritt. Eine KI-Integration mit anschließender Prüfung kann dafür untersucht werden; strukturierte Daten lassen sich häufig bereits mit festen Regeln übertragen.
Betrieb und Änderungen
Zum Betriebsmodell gehören außerdem der Ort der Verarbeitung, beauftragte Dienste und die Zuständigkeit für Updates. Bei Cloud- oder SaaS-Produkten sind auch Anbieteränderungen und Zugriffsbedingungen zu berücksichtigen. Begrenzen Sie übertragene Daten und Protokolle auf ihren Zweck, vereinbaren Sie Aufbewahrung und Löschung und schützen Sie Übertragung und Betriebszugriff. Zugangsschlüssel gehören nicht ins Fehlerprotokoll. Die konkrete Ausgestaltung stimmen Sie mit Ihrer IT und den für Datenschutz verantwortlichen Personen ab.
Mit einem prüfbaren Pilotumfang beginnen
Ein geeigneter Einstieg umfasst einen Datenfluss, eine klar abgegrenzte Vorgangsart und dokumentierte Ausnahmefälle. Vor der Umsetzung klären wir vorhandene Dokumentation, Testmöglichkeiten, Datenqualität und den erwarteten Aktualisierungsrhythmus. Daraus ergeben sich Umfang und Voraussetzungen eines Angebots.
Umfang und laufenden Aufwand trennen
Der Aufwand hängt unter anderem von den zugänglichen Funktionen, Zuordnungsregeln, Übertragungsrichtungen und erforderlichen Fehlerbehandlungen ab. Einrichtung und Tests sollten getrennt vom laufenden Betrieb, späteren Änderungen und möglichen Gebühren der beteiligten Anbieter beschrieben werden. Ohne diese Informationen lässt sich kein belastbarer Festpreis nennen.
Die heutige Übergabe konkret zeigen
Für die erste Abstimmung helfen Systemnamen mit Version, eine anonymisierte Beispieldatei und die Beschreibung der heutigen Übergabe. Ergänzen Sie, wer das Ergebnis fachlich abnehmen kann. Damit lässt sich prüfen, ob eine vorhandene Verbindung reicht oder eine individuelle Schnittstelle sinnvoll ist.
Mitwirkung und Betreuung vereinbaren
Planen Sie dafür interne Mitwirkung ein: Der Fachbereich entscheidet über Feldregeln und prüft das Geschäftsergebnis, die Systemverantwortlichen klären Zugänge und Änderungen. Eine benannte Person übernimmt offene Fehler im Alltag. Zur Einführung kann eine Einweisung anhand eines fehlerhaften und eines erfolgreichen Vorgangs gehören, ergänzt um eine kurze Betriebsanleitung. Legen Sie diese Aufgaben und den späteren Betreuungsumfang ausdrücklich fest, besonders wenn intern nur wenig IT-Kapazität verfügbar ist.
Die passende Verbindung weiterdenken.
Ihr Ablauf ist der Ausgangspunkt.
Bringen Sie einen konkreten Vorgang und Ihre offenen Fragen mit. Daraus lässt sich der nächste sinnvolle Umfang ableiten.
Projekt besprechen