Vor einem Jahr kam einer unserer E-Commerce-Kunden mit einem Problem zu uns, das ich nur zu gut kenne. Der Shop wickelt einige Hundert Bestellungen pro Tag ab, und in der Operations-Abteilung tippen Menschen die Daten von Hand zwischen drei Systemen hin und her: der Verkaufsplattform, dem CRM und dem ERP. Ein Klassiker. Als Web Systems, ein software house aus Łódź, das seit 2006 tätig ist, war uns klar: Mit Pflastern kommt man hier nicht weiter. Es brauchte eine saubere Integration über API. Das Projekt umfasste die Verbindung von drei eigenständigen Systemen, durch die Bestellungen, Lagerbestände, Kundenhistorie, Rechnungen und Versandstatus laufen. Wir haben uns für REST API entschieden, weil kein fertiges Plugin die besondere Geschäftslogik dieses Kunden abbilden konnte. Seit der Einführung ist ein Jahr vergangen. Wir haben viele Erkenntnisse gesammelt und, ehrlich gesagt, einige davon hätte ich gern früher gehabt.
Spis treści
Warum wir uns für eine Integration über API und gegen fertige Plugins entschieden haben
Klar, der erste Reflex ist die Suche nach etwas Fertigem. Wir haben drei populäre Konnektoren getestet, die die E-Commerce-Plattform mit dem ERP des Kunden verbinden. Jeder scheiterte an einer anderen Stelle. Einer kam mit dem Mapping eigener Bestellfelder nicht zurecht. Der zweite verlangte Handarbeit bei der Synchronisation von Retouren. Der dritte? Er funktionierte nach einem ERP-Update nicht mehr, weil der Plugin-Hersteller den Support eingestellt hatte. Und jetzt? Bei mehreren Hundert Transaktionen am Tag von einem externen Plugin-Anbieter abhängig zu sein, ist schlicht ein Risiko, das wir uns nicht leisten konnten.
Der Kunde brauchte eine vollständige Synchronisation in beide Richtungen. Eine Bestellung im Shop landet sofort im ERP. Ändert sich der Lagerbestand im ERP, wird die Website unmittelbar aktualisiert. Dazu sammelte das CRM Kontakthistorie, Reklamationen und Kaufpräferenzen, und all das floss in Segmentierung und personalisierte Angebote ein. Kein fertiges Plugin bekam diesen dreiseitigen Fluss ohne Kompromisse hin. Ich habe es geprüft. Mehrfach.
- Eigene Bestellstatus: Der Kunde nutzte sieben eigene Abwicklungsstufen, die kein Konnektor erkannte
- Eigene B2B-Rabatte: Individuelle Preislisten für Großhandelspartner mussten aus dem ERP in den Shop synchronisiert werden
- Synchronisation mehrerer Lager: drei Standorte mit getrennten Beständen, die als ein einheitliches Sortiment erscheinen mussten
- Automatische Rechnungserstellung: Im ERP erzeugte Dokumente mussten in das Kundenkonto im Shop zurückfließen
- Abwicklung von Retouren und Korrekturen: ein Prozess, der eine gleichzeitige Aktualisierung in drei Systemen erfordert
Tipp 1: Bevor Sie die Integration überhaupt starten, kartieren Sie die Datenflüsse zwischen den Systemen. Zeichnen Sie ein Diagramm: Welche Daten entstehen wo, wohin gehen sie, wie oft ändern sie sich. Ohne diese Karte bringt Ihnen auch das beste API nichts, weil Sie nicht wissen, was Sie eigentlich synchronisieren. Ich habe das selbst erlebt.
Architektur der Integration: eine Zwischenschicht statt Punkt-zu-Punkt-Verbindungen
Der häufigste Fehler beim Verbinden mehrerer Systeme? Direkte Verbindungen zwischen ihnen zu bauen. Der Shop ruft das CRM-API auf, das CRM fragt das ERP ab, das ERP aktualisiert den Shop, und schon haben Sie ein hübsches Geflecht aus Abhängigkeiten, in dem der Ausfall eines Elements den Rest mitreißt. Wir sind einen anderen Weg gegangen. Eine dedizierte Middleware als zentraler Kommunikations-Hub. Jedes System spricht nur mit dieser Zwischenschicht, nie direkt mit den anderen.
Das ist klassische separation of concerns, nur auf Infrastrukturebene. Der Shop macht seine Arbeit: Bestellungen annehmen, Produkte anzeigen. Das CRM kümmert sich um die Kundenbeziehungen. Das ERP steuert Lager, Finanzen und Logistik. Und die Middleware? Sie transformiert Daten, stellt Ereignisse in eine Warteschlange und behandelt Fehler. Ändert sich das Datenformat in einem System, wird nur die Zwischenschicht angepasst. Nicht alle verbundenen Dienste. Glauben Sie mir, das macht in der Wartung einen riesigen Unterschied.
Wir haben zwei Ansätze für die Synchronisation erwogen. Die Systeme in festen Abständen abfragen oder eine ereignisgesteuerte Architektur, bei der jede Änderung sofort eine Benachrichtigung erzeugt. Am Ende wurde es ein Hybrid. Bestellungen und Statusänderungen laufen ereignisgesteuert über Webhooks, denn hier zählt Tempo. Lagerbestände werden alle fünf Minuten abgefragt, weil das ERP des Kunden für Lageroperationen keine Webhooks unterstützte. Das war der Kompromiss. Und wissen Sie was? Es läuft seit einem Jahr stabil.
Tipp 2: Logging und Monitoring ab Tag null. Erfassen Sie jeden API-Aufruf, die Antwortzeit, die übertragenen Daten und die Fehlercodes. Ich habe das am eigenen Leib getestet: Nach drei Monaten ohne Logs wird Debugging zum Kaffeesatzlesen. Sie sehen die Wirkung, aber Sie haben keine Ahnung, wann und warum etwas schiefging.
Die größten technischen Probleme in den ersten drei Monaten
Das erste ernsthafte Kopfzerbrechen? Unterschiede in den Datenformaten. Das ERP speicherte Daten als DD.MM.YYYY, der Shop nutzte ISO 8601, und das CRM Unix-Zeitstempel. Produkt-IDs waren im ERP numerisch, im Shop alphanumerisch. Preise im ERP enthielten die Steuer, der Shop arbeitete mit Nettobeträgen. Jeder dieser Unterschiede ist eine eigene Transformationsregel in der Middleware. Anfangs kostete das deutlich mehr Zeit als geplant. Aber so ist es nun einmal: Solche Dinge zeigen sich erst in der Praxis.
Das zweite Problem trat bei höherem Verkehr auf. Rate Limiting auf der ERP-Seite. Und da ging der Spaß los, denn der Systemhersteller dokumentierte die Limits für API-Aufrufe nicht. In der technischen Spezifikation stand kein Wort über Beschränkungen. Bei einigen Dutzend Bestellungen am Tag lief alles glatt. Als der Verkehr aber auf einige Hundert Transaktionen sprang, kamen HTTP-429-Fehler. Wir mussten eine Warteschlange mit exponentiellem Backoff einführen. Kurios: Von den Limits erfuhren wir erst aus den Fehlermeldungen.
Die dritte Kategorie sind Datenkonflikte. Eine Kundin ändert ihre Adresse im Shop-Konto. Im selben Moment aktualisiert ein Berater dieselben Daten im CRM. Und nun? Welcher Eintrag gewinnt? Ohne klare Strategie zur Konfliktlösung entstanden dabei Inkonsistenzen, die das Operations-Team erst beim Versand entdeckte. Frustrierend.
- Falsches Mapping der Mengeneinheiten: Das ERP zählte in Stück, der Shop in Sammelpackungen
- Verbindungs-Timeouts bei großen Preislisten-Updates mit Tausenden Produkten
- Doppelte Bestellungen, wenn ein fehlgeschlagener API-Aufruf wiederholt wurde
- Fehlende Idempotenz der ERP-Endpunkte: Dieselbe Anfrage zweimal gesendet erzeugte zwei Dokumente
- Auseinanderlaufende Produktkategorien zwischen Shop und ERP nach manueller Bearbeitung in einem der Systeme
Sicherheit und Autorisierung in der Kommunikation zwischen Systemen
Drei Systeme bedeuten drei mögliche Angriffsvektoren. Über das API laufen personenbezogene Kundendaten, Finanzinformationen, Bestelldetails und Lagerbestände. Ein Leck bei irgendeinem dieser Punkte zieht rechtliche und Image-Folgen nach sich. Im Ernst, da gibt es nichts zu lachen. Und jedes System verlangte einen anderen Ansatz bei der Autorisierung. Der Shop bot OAuth 2.0, das ERP nutzte statische API-Schlüssel, das CRM unterstützte beide Modelle. Drei Mechanismen, null Standardisierung.
OAuth 2.0 überall dort, wo es möglich war: automatische Token-Erneuerung, feingranulare Berechtigungen, sehr gut. Für das ERP mit seinen statischen Schlüsseln haben wir eine zusätzliche Proxy-Schicht gebaut, die den Zugriffsbereich einschränkt und jeden Aufruf protokolliert. Die gesamte Kommunikation läuft über verschlüsselte TLS-Verbindungen, Tokens und Schlüssel liegen in einem eigenen Tresor. Nie im Quellcode. Nie im Repository.
Tipp 3: API-Schlüssel im Code oder im Git-Repository? Nein. Einfach nein. Umgebungsvariablen und Tresore wie HashiCorp Vault, auch in kleinen Projekten. Ein einziger Schlüssel, der in ein öffentliches Repository gelangt, kann deutlich mehr kosten als eine Stunde Konfiguration. Ich habe solche Fälle bei anderen Firmen gesehen und, nun ja, angenehm war das nicht.
Wir haben eine Rotation der Schlüssel alle 90 Tage eingeführt, dazu ein Monitoring nicht autorisierter Aufrufe. Das System alarmiert uns, wenn Anfragen von unbekannten IP-Adressen kommen oder wenn die Zahl der Autorisierungsfehler einen Schwellenwert überschreitet. Zweimal haben uns diese Mechanismen geholfen, Versuche unbefugten Zugriffs zu erkennen, bevor Schaden entstand. Denn die Sicherheit einer API-Integration ist nichts, was man einmal einstellt und dann vergisst. Es ist ein fortlaufender Prozess: Prüfungen, Updates, Wachsamkeit.
Was sich nach einem Jahr geändert hat: die messbaren Effekte der Integration
Die größte Veränderung, die alle sofort gespürt haben: Schluss mit dem Abtippen von Daten. Vor der Integration verbrachten zwei Personen aus dem Operations-Team zusammen rund vier Stunden am Tag damit, Informationen zwischen den Systemen zu kopieren. Vier Stunden. Jeden Tag. Nach einem Jahr automatischer Synchronisation ist diese Zeit auf etwa eine Viertelstunde täglich gesunken, vor allem für die Prüfung von Ausnahmen und Sonderfällen. Das Team konnte sich endlich um die Aufgaben kümmern, die wirklich einen menschlichen Kopf brauchen.
Die Abwicklungszeit der Bestellungen ist im Schnitt um 40 Prozent gesunken. Früher wartete eine Bestellung auf die manuelle Eingabe ins ERP, dann auf die Lagerprüfung, dann auf die Rechnung. Und heute? Der gesamte Ablauf läuft automatisch innerhalb weniger Sekunden nach der Bestellung. Der Kunde erhält die Bestätigung mit der Rechnungsnummer fast sofort. Das Ergebnis? Bessere Shop-Bewertungen, mehr wiederkehrende Käufer. Ganz einfach.
Analysen von Gartner zufolge bildet ein daten- und modellbasierter Ansatz das Fundament für den Aufbau skalierbarer Geschäftslösungen. Eine sauber definierte Architektur erlaubt es einer Organisation, ihre Abläufe mit minimalen Konflikten zu skalieren, erleichtert das Einarbeiten neuer Teammitglieder und erhöht die Gesamtqualität und Widerstandsfähigkeit des Systems.
Und die Wartungskosten? Sie fielen höher aus als geplant, um rund 30 Prozent. Wir hatten nicht vorhergesehen, wie oft das ERP sein API aktualisiert und damit Änderungen in unserer Middleware erzwingt. Dazu kam die Zeit für Monitoring und die Reaktion auf Vorfälle. Unter dem Strich bleibt die Bilanz trotzdem positiv: Die Investition hat sich im achten Monat amortisiert, vor allem durch geringere Personalkosten und den Wegfall von Fehlern bei der manuellen Dateneingabe. Wir bereuen nichts.
FAQ: die häufigsten Fragen zur Integration von Shop, CRM und ERP
Wie lange dauert die Integration von Shop, CRM und ERP über API?
Nach unserer Erfahrung dauert ein typisches Projekt zur Integration von drei Systemen 8 bis 16 Wochen, von der Anforderungsanalyse bis zum Start in der Produktion. Es hängt von der Qualität der API-Dokumentation der beteiligten Systeme, der Komplexität der Abläufe und der Verfügbarkeit von Testumgebungen ab. Interessant dabei: Am längsten dauert meist nicht die Programmierung, sondern das Abstimmen der Geschäftsregeln. Was soll passieren, wenn die Daten in zwei Systemen sich widersprechen? Wer gewinnt? Solche Diskussionen können sich über Wochen ziehen. Ich empfehle, zusätzlich zwei bis vier Wochen für Lasttests und Stabilisierung einzuplanen.
Erfordert eine API-Integration Änderungen am bestehenden Online-Shop?
In der Regel muss man den Shop selbst nicht anfassen. Die meisten modernen E-Commerce-Plattformen haben ein ausgebautes API, das Daten lesen und schreiben kann, ohne im Quellcode zu wühlen. Änderungen können nötig werden, wenn der Shop eigene Felder oder Prozesse nutzt, die das API standardmäßig nicht nach außen gibt. Dann bauen wir Erweiterungen auf der Shop-Seite, der Kern der Plattform bleibt jedoch unangetastet. So sind spätere Updates der Plattform kein Problem.
Was passiert, wenn eines der verbundenen Systeme vorübergehend nicht erreichbar ist?
Die Zwischenschicht puffert die Ereignisse in einer Warteschlange und wiederholt die Zustellung der Daten nach konfigurierbaren Regeln. Das ERP ist für einige Minuten ausgefallen? Die Bestellungen warten in der Warteschlange und gehen automatisch raus, sobald die Verbindung zurück ist. Bei längeren Unterbrechungen schickt das System Warnungen an das technische Team. Oberste Priorität: Es dürfen keine Daten verloren gehen. Deshalb schreibt der Warteschlangen-Mechanismus die Ereignisse auf die Festplatte, nicht nur in den Arbeitsspeicher. Wir haben das mit simulierten Ausfällen über mehrere Stunden getestet und kein einziges Ereignis verloren.
Fazit: Lohnt sich die Integration von Shop, CRM und ERP über API
Nach zwölf Monaten in der Produktion? Ja, eindeutig. Aber mit offenen Augen für die Wartungskosten. Die Integration über API hat reale Zeitersparnis gebracht, menschliche Fehler beseitigt und die Bearbeitung der Bestellungen beschleunigt. Auf der anderen Seite verlangte sie mehr laufende Wartungsarbeit als angenommen. Vor allem wegen der API-Updates der externen Systeme und der wachsenden Datenmenge.
Die wichtigste Lehre aus diesem Jahr ist einfach. Eine API-Integration ist kein Projekt mit Enddatum. Sie ist ein lebendiger Teil der Infrastruktur, der Monitoring, Updates und laufende Anpassung braucht. Sie als abgeschlossene Aufgabe zu behandeln? Der direkte Weg zu einer schleichend sinkenden Qualität der Synchronisation und zu wachsenden technischen Schulden. Das haben wir am eigenen Leib erfahren.
Wenn Sie über die Integration Ihres Online-Shops mit CRM, ERP oder anderen Systemen nachdenken, teilen wir gern unsere Erfahrung. Bei Web Systems planen und realisieren wir seit Jahren API-Integrationen, die Automatisierung von Geschäftsprozessen und E-Commerce-Lösungen, die zu den tatsächlichen Anforderungen passen. Schreiben Sie uns, erzählen Sie von Ihrem Projekt, und wir helfen Ihnen, eine Architektur zu wählen, die nicht nur am Tag der Einführung funktioniert, sondern auch in einem und in drei Jahren.
