ERP anbinden, ohne das System zu gefährden

„ERP anbinden” klingt nach einer technischen Detailfrage. In der Praxis ist es die Frage, die über den Erfolg eines Digitalisierungsprojekts entscheidet — denn das ERP ist meistens das System, das niemand versehentlich beschädigen will. Es steckt selten im Rampenlicht eines Projekts, entscheidet aber am Ende darüber, ob eine neue Website, ein neuer Onlineshop oder ein neues Kundenportal überhaupt mit echten, aktuellen Daten arbeitet — oder mit einer Kopie, die schon am Tag nach dem Launch veraltet ist.

Warum ERP-Anbindungen anders sind als normale Integrationen

Ein ERP-System ist oft älter als die Website, die es füttern soll, läuft geschäftskritisch und wird selten neu gestartet, ohne dass jemand nervös wird. Eine Anbindung, die bei einem SaaS-Tool einfach neu synchronisiert, wenn etwas schiefgeht, kann bei einem ERP doppelte Bestellungen, falsche Lagerbestände oder inkonsistente Rechnungen bedeuten. Robustheit ist hier keine Kür.

Hinzu kommt, dass ERP-Systeme selten für den heutigen Anwendungsfall gebaut wurden. Viele laufen seit zehn oder fünfzehn Jahren, wurden über die Jahre um Module erweitert, und ihre Schnittstellen — sofern überhaupt vorhanden — spiegeln oft eher die interne Struktur des Systems als das, was eine moderne Website eigentlich braucht. Eine Anbindung muss diese Lücke schließen, ohne das ERP selbst anzufassen.

Was eine Anbindung robust macht

Wiederholungen mit Rückgrat. Ein Netzwerkfehler darf nicht dazu führen, dass eine Bestellung entweder verloren geht oder doppelt ankommt. Retries mit Idempotenz-Schlüsseln sorgen dafür, dass dieselbe Anfrage zweimal ankommen darf, ohne zweimal zu wirken — das System erkennt an einem eindeutigen Schlüssel, dass es eine Anfrage schon verarbeitet hat, und verwirft die Wiederholung, statt sie erneut auszuführen.

Warteschlangen statt direkter Aufrufe. Wenn das ERP kurzzeitig nicht antwortet, soll die Website trotzdem weiterlaufen. Eine Queue puffert Anfragen und liefert sie nach, statt dass ein Formular einfach fehlschlägt, weil ein anderes System gerade langsam ist. Für den Kunden im Onlineshop macht das den Unterschied zwischen einer Bestellung, die durchgeht und im Hintergrund nachsynchronisiert wird, und einer Fehlermeldung, die ihn zum Abbruch bringt.

Überwachung, die vor dem Kunden merkt. Ein Alarm, der auslöst, wenn eine Synchronisation drei Mal hintereinander fehlschlägt, ist billiger als ein Kunde, der anruft, weil seine Bestellung nirgends auftaucht. Monitoring ist an dieser Stelle kein Luxus für später, sondern der Unterschied zwischen einem Vorfall, der intern bemerkt wird, und einem, der erst über eine Kundenbeschwerde ans Licht kommt.

Runbooks statt Heldentum. Wenn etwas ausfällt, sollte die Antwort in einem Dokument stehen, nicht im Kopf einer einzigen Person. Was zu tun ist, wenn die Warteschlange sich staut oder das ERP nicht erreichbar ist, gehört aufgeschrieben, bevor es passiert — inklusive der Frage, wer benachrichtigt wird und wie ein Rückstand nachgeholt wird, sobald das System wieder erreichbar ist.

Validierung vor der Übernahme. Daten, die aus einem ERP kommen, sind nicht automatisch sauber — falsche Artikelnummern, veraltete Preise, Formate, die sich über die Jahre leicht verschoben haben. Eine Anbindung, die jeden Datensatz ungeprüft übernimmt, trägt diese Fehler einfach weiter, statt sie abzufangen.

Wenn es keine API gibt

Nicht jedes System, das angebunden werden soll, hat eine offene Schnittstelle. Ältere ERP- und Warenwirtschaftssysteme bieten manchmal nur Datei-Exporte, planbare CSV-Abzüge oder — im letzten Fall — eine dokumentierte Browser-Automatisierung, die eine Oberfläche bedient, die eigentlich für Menschen gebaut wurde. Keine dieser Lösungen ist elegant, aber alle drei sind besser als eine manuelle Doppelerfassung, die irgendwann jemand vergisst.

Situation	Übliche Lösung
ERP hat eine REST-API	direkte Anbindung mit Queue und Retries
ERP hat nur Datei-Export	geplante Import-Jobs, Validierung vor Übernahme
Kein Export, nur Oberfläche	dokumentierte Browser-Automatisierung als letzte Option
Hohe Kritikalität	zusätzliches Monitoring, Runbook, Rollback-Pfad

Was wir schon angebunden haben

Wir haben Shopify- und WooCommerce-Shops an Warenwirtschaft angebunden, Zahlungsflüsse über Stripe abgewickelt, ERP- und CRM-Systeme verschiedener Anbieter verbunden, Telematik- und eSIM-Carrier-APIs integriert und MQTT-Sensornetzwerke an Auswertungssysteme angeschlossen — etwa für Estegre, unser eigenes IoT-Monitoring, und TrackBil, unser GPS-Tracking-System. Beide laufen nach denselben Prinzipien, die wir Kunden empfehlen: Warteschlangen, Wiederholungen, Überwachung. Bei IoT- und Telematik-Anbindungen kommt eine zusätzliche Schwierigkeit dazu, die ERP-Projekte nicht kennen: Sensoren und Geräte senden nicht auf Zuruf, sondern in ihrem eigenen Takt, oft mit Lücken, wenn eine Verbindung kurz ausfällt. Dieselbe Queue- und Retry-Logik, die eine ERP-Bestellung absichert, sichert dort einen fehlenden Messwert ab, der später nachgeliefert wird.

Wie ein solches Projekt bei uns anfängt

Bevor wir eine Zeile Code für eine Anbindung schreiben, prüfen wir, was das ERP tatsächlich anbietet — Dokumentation ist bei älteren Systemen oft lückenhaft oder schlicht nicht vorhanden, und der einzige verlässliche Weg ist ein Testaufruf gegen eine Kopie oder Testumgebung des Systems. Erst danach lässt sich seriös sagen, ob eine direkte Anbindung, ein Datei-Austausch oder eine der selteneren Optionen die richtige ist.

Ein Rollback-Pfad ist kein Nachgedanke

Jede Anbindung an ein geschäftskritisches System braucht einen Weg zurück, falls etwas grundlegend schiefläuft — eine Möglichkeit, die Synchronisation anzuhalten, ohne dass währenddessen Bestellungen verloren gehen, und einen klaren Punkt, ab dem nachgeholt wird, was während des Stopps liegen geblieben ist. Diesen Pfad erst zu entwerfen, wenn er gebraucht wird, ist zu spät; er gehört von Anfang an zur Architektur, nicht zur Fehlerbehebung im Ernstfall.

Die Regel, nach der wir Anbindungen bauen

Eine Integration, die beim ersten Netzwerkfehler Daten verliert oder verdoppelt, ist keine Integration — sie ist ein Risiko mit einer Benutzeroberfläche.

Wer ein ERP oder CRM anbinden will und nicht weiß, ob es eine API gibt oder nur eine Exportfunktion, bekommt die Antwort schneller in einem Gespräch als durch Ausprobieren. Details zum Vorgehen stehen bei Integrationen.