Systeme verbinden, die nicht miteinander sprechen
Shop, Warenwirtschaft, CRM: Jedes System hält sich für die Wahrheit. Vier Fragen entscheiden, ob aus der Verbindung eine Integration wird oder eine Fehlerquelle mit Zeitplan.
Drei Systeme, die dieselben Kunden und dieselben Produkte kennen — und jedes hält seine Version für die richtige. Integrationsprojekte scheitern selten an Technik. Die Schnittstellen sind dokumentiert, die Werkzeuge sind da, die Verbindung steht meistens in der ersten Woche.
Sie scheitern an vier Fragen, die vorher niemand beantwortet hat. Diese vier Fragen sind keine Formalität vor dem eigentlichen Projekt — sie sind das eigentliche Projekt. Was danach kommt, ist Umsetzung.
Frage 1: Wer führt welche Wahrheit?
Nicht „welches System ist führend", sondern je Feld: Wer darf die Lieferadresse ändern? Wer den Bestand? Wer den Preis? Wer den Kundennamen, wenn er in drei Systemen unterschiedlich geschrieben steht?
Ohne diese Festlegung überschreiben sich Systeme gegenseitig, und das Ergebnis hängt davon ab, welcher Abgleich zuletzt lief. Das ist der Fehler, der am spätesten auffällt und am teuersten ist — meistens bei einer Reklamation, wenn eine Adresse plötzlich wieder die alte ist.
Die praktische Form dieser Festlegung ist eine Tabelle mit drei Spalten: Objekt, Feld, führendes System. Sie ist langweilig, sie passt auf zwei Seiten, und sie erspart mehr Diskussionen als jedes Architekturdiagramm.
Frage 2: Wie oft wird abgeglichen?
Sofort, im Takt oder auf Abruf? Jede Antwort hat Konsequenzen, und keine ist per se richtig:
| Betriebsart | Bedeutet | Kostet |
|---|---|---|
| Sofort (ereignisgesteuert) | Das Zielsystem muss immer erreichbar sein | Aufwand für Wiederholung und Warteschlange |
| Im Takt (zeitgesteuert) | Es gibt ein Fenster, in dem Daten auseinanderlaufen | Ehrlichkeit in der Anzeige |
| Auf Abruf | Jemand löst aus | Verlässlichkeit hängt an einem Menschen |
Der mittlere Fall wird am häufigsten gewählt und am seltensten zu Ende gedacht. Ein Zeitfenster, in dem Daten auseinanderlaufen, ist kein Fehler, sondern eine Entscheidung — und sie gehört in die Anzeige. „Bestand von vor 15 Minuten" ist ehrlicher als eine Zahl ohne Zeitangabe, und es erspart dem Kundenservice die Erklärung, warum das Lager etwas anderes sagt als der Shop.
Frage 3: Was passiert bei Konflikt?
Zwei Systeme, zwei verschiedene Werte. Wer gewinnt?
Die Antwort muss vor dem ersten Abgleich feststehen und dokumentiert sein. „Der zuletzt geschriebene Wert gewinnt" ist eine brauchbare Antwort — aber nur, wenn alle wissen, dass es eine ist. Wenn sie sich aus der Reihenfolge der Bausteine ergibt, ist sie keine Entscheidung, sondern ein Zufall mit Konsequenzen.
Frage 4: Wer merkt den Ausfall?
Die Frage, die über den Betrieb entscheidet. Eine Kette, die still stehenbleibt, wird nicht am selben Tag bemerkt, sondern wenn sich ein Kunde meldet. Bis dahin sind zwei Tage Bestellungen nicht im ERP, und niemand hat etwas falsch gemacht — es ist nur nichts passiert.
:::achtung{titel="Warum „wir sehen es im Protokoll" nicht reicht"} Ein Protokoll wird gelesen, wenn man bereits weiß, dass etwas kaputt ist. Es ist ein Werkzeug für die Ursachensuche, kein Meldeweg. Der Meldeweg braucht einen Empfänger mit Namen, einen Kanal, den diese Person tatsächlich liest, und eine Nachricht, die sagt, was nicht geht — nicht einen Stacktrace. :::
Was dazu in die Dokumentation gehört, steht in Schnittstellen dokumentieren, bevor sie brechen.
Die fünf Stolperstellen aus der Praxis
Unterschiedliche Kennungen. Der Shop kennt Artikelnummern, die Warenwirtschaft interne IDs, das CRM E-Mail-Adressen. Ohne eine eindeutige Zuordnung je Objekt wird jede Verbindung zur Rätselaufgabe — und jede Fehlersuche zur Archäologie.
Teilerfolge. Eine Bestellung wird übertragen, die Positionen nicht. Das Zielsystem hat dann einen unvollständigen Datensatz und meldet keinen Fehler, weil formal alles funktioniert hat. Übertragungen sollten vollständig gelingen oder vollständig scheitern.
Doppelte Lieferung. Netzwerke sind unzuverlässig, Wiederholungen sind normal. Das Zielsystem muss erkennen, dass es diesen Vorgang schon kennt — sonst entstehen doppelte Bestellungen und doppelte Rechnungen.
Zeitzonen und Formate. Klassiker, immer noch aktuell: Datum ohne Zeitzone, Komma statt Punkt, führende Nullen, die verschwinden, weil eine Tabelle die Artikelnummer für eine Zahl hält.
Fehlende Ereignisse. Wenn ein System nicht meldet, dass sich etwas geändert hat, muss die Integration regelmäßig nachsehen — und das kostet in jedem Abrechnungsmodell. Welche Ereignisse Shopware von sich aus liefert, steht in Webhooks in Shopware 6.
Wie wir vorgehen
Sechs Schritte, in dieser Reihenfolge
- 1Datenlandkarte — welche Objekte, welche Systeme, welche Felder. Auf Papier, bevor jemand eine Zugangsdatei anlegt.
- 2Wahrheiten festlegen — je Feld ein führendes System, schriftlich, gegengelesen von jemandem aus dem Fachbereich.
- 3Kleinsten nützlichen Fall bauen — eine Richtung, ein Objekt. Nicht „die Bestellübergabe", sondern „eine bezahlte Bestellung ohne Sonderfälle".
- 4Fehlerfälle nachstellen — Ausfall des Zielsystems, doppelte Lieferung, ungültige Daten, Zeitüberschreitung.
- 5Meldeweg einrichten, bevor produktiv geschaltet wird — nicht danach.
- 6Erweitern — Sonderfälle, zweite Richtung, weitere Objekte.
Schritt 4 wird am häufigsten übersprungen, weil im Normalfall alles funktioniert. Er ist der Unterschied zwischen einer Integration, die zwei Jahre läuft, und einer, die alle drei Wochen jemanden beschäftigt.
Bevor die erste Strecke produktiv geht
- Für jedes übertragene Feld ist festgelegt, welches System führt.
- Der Konfliktfall ist entschieden und aufgeschrieben.
- Eine doppelte Lieferung erzeugt keinen zweiten Datensatz.
- Ein Teilerfolg ist ausgeschlossen: ganz oder gar nicht.
- Es gibt einen Meldeweg mit Empfänger, nicht nur ein Protokoll.
- Jemand kann sagen, woran man erkennt, dass die Strecke seit gestern steht.
Was eine Integration nicht leistet
Sie macht schlechte Daten nicht besser. Wenn im Shop drei Schreibweisen derselben Marke stehen, stehen nach der Integration drei Schreibweisen in drei Systemen — nur schneller und an mehr Stellen. Datenqualität ist die Voraussetzung, nicht das Ergebnis; warum das so ist, steht in Datenqualität als Voraussetzung jeder Integration.
Und sie ersetzt keine Prozessentscheidung. Die Frage, wer bei einer geänderten Lieferadresse recht hat, ist eine Frage an das Unternehmen, nicht an die Software. Wer sie an die Technik delegiert, bekommt eine Antwort — nur nicht unbedingt die, die er gewollt hätte.
Wenn Sie vor einem solchen Projekt stehen: Wir fangen mit der Datenlandkarte an, nicht mit der Schnittstelle. Das dauert ein bis zwei Termine und beantwortet meistens schon, ob das Vorhaben so tragfähig ist, wie es geplant war. Mehr dazu unter App- und Plugin-Entwicklung.
