Großhandel · Systemintegration · ERP
Zwei Systeme, die einander nicht kannten.
Für ein mittelständisches Großhandelsunternehmen wurde die Datenhoheit zwischen ERP und einer über Jahre gewachsenen Eigenentwicklung neu geschnitten — nachdem die Klärung zeigte, dass der geplante bidirektionale Abgleich nicht tragfähig war.
- Branche
- Großhandel
- Projektdauer
- ca. 3 Monate
- Projekttyp
- Systemintegration
- Ergebnis
- rund 22 Std./Woche
Die Aufgabe
Zwei Systeme, ein Datenbestand — und keine Instanz, die entscheidet.
Das Unternehmen betrieb neben seinem ERP eine über Jahre gewachsene Eigenentwicklung für die Auftragsabwicklung. Beide Systeme waren für sich funktionsfähig und beide wurden täglich genutzt.
Das Problem lag dazwischen: Artikel- und Kundendaten wurden an zwei Stellen gepflegt. Wenn die Bestände auseinanderliefen, gab es keine technische Instanz, die entschied, welcher Wert gilt — es galt, was zuletzt jemand von Hand korrigiert hatte.
Nicht die Systeme waren das Problem, sondern die fehlende Antwort auf die Frage, welches von beiden recht hat.
Die kritische Frage
Bidirektionaler Abgleich klingt nach der Lösung. Er ist zuerst eine Annahme.
Der naheliegende Plan war ein bidirektionaler Abgleich: beide Systeme schreiben, beide lesen, Änderungen fließen in beide Richtungen. Technisch ist das die aufwendigste Variante — und sie steht und fällt mit einer Eigenschaft der vorhandenen Schnittstelle.
Denn ein beidseitiger Schreibzugriff braucht eine verlässliche Konfliktauflösung. Ohne sie gewinnt in der Praxis der jeweils letzte Schreibvorgang, und Abweichungen fallen nicht auf, weil beide Systeme plausible Werte zeigen. Deshalb wurde diese Frage vor dem Entwicklungsstart geklärt und nicht im Projektverlauf.
Trägt die vorhandene ERP-Schnittstelle einen bidirektionalen Abgleich — oder muss die Datenhoheit anders geschnitten werden?
Die Klärung
Die Antwort war: so nicht.
Die Analyse der Systemlandschaft und der tatsächlich vorhandenen Schnittstellen ergab, dass sich ein verlässlicher bidirektionaler Abgleich damit nicht umsetzen lässt. Nicht, weil die Übertragung technisch unmöglich wäre, sondern weil die Garantien fehlten, die ein beidseitiger Schreibzugriff braucht.
Ein darauf aufgebautes System hätte funktioniert — bis zum ersten gleichzeitigen Zugriff. Danach wäre stille Datenabweichung entstanden: kein Fehler, keine Meldung, nur zwei Systeme mit unterschiedlichen Wahrheiten. Genau der Zustand, der vorher von Hand korrigiert wurde, nur schneller und weniger sichtbar.
Eine Integration, die Daten überträgt, aber Konflikte nicht auflöst, verlagert das Problem nur aus der Tabelle in die Datenbank.
Die Lösung
Datenhoheit neu geschnitten statt Abgleich erzwungen.
Statt den bidirektionalen Abgleich gegen die Schnittstelle zu erzwingen, wurde die Zuständigkeit zwischen den Systemen neu aufgeteilt. Das ERP blieb führendes System für Stammdaten — Artikel, Kunden, Preise. Die Eigenentwicklung übernahm ausschließlich Prozessdaten, also den Teil, für den sie ohnehin gebaut worden war.
Damit entfällt die Konfliktfrage, statt gelöst werden zu müssen: Für jedes Datum gibt es genau ein System, das es ändern darf. Dazu kam ein nachvollziehbarer Abgleich, der Abweichungen sichtbar macht, anstatt sie im Hintergrund zu überschreiben.
- 01ERP (führend für Stammdaten)
- 02Schnittstelle
- 03Abgleich mit Protokoll
- 04Eigenentwicklung (Prozessdaten)
- 05Auftragsabwicklung
Die belastbarste Integration ist oft die, die eine Frage gar nicht erst entstehen lässt.
Das Ergebnis
Rund 22 Stunden pro Woche, die vorher in Nacharbeit gingen.
Mit der neu geschnittenen Datenhoheit entfällt die Doppelpflege — und mit ihr die manuellen Schritte, die sie nach sich zog: Abweichungen suchen, Stände vergleichen, von Hand korrigieren und anschließend prüfen, ob die Korrektur im anderen System angekommen ist. In Summe rund 22 Stunden pro Woche.
Der zweite Teil des Ergebnisses ist weniger sichtbar: Die Entscheidung gegen den bidirektionalen Abgleich fiel in der Klärung, nicht nach Monaten Entwicklung. Der teure Teil dieses Fehlers ist nie entstanden.
- Analyse der Systemlandschaft und der vorhandenen Schnittstellen
- Zielarchitektur und Schnitt der Datenhoheit
- Datenmodell
- Umsetzung der Integration
- Nachvollziehbarer Abgleich statt stiller Überschreibung
- Produktiver Betrieb
Eine Woche Klärung hat hier mehr gespart als jede Optimierung danach möglich gemacht hätte.
Weitere Referenzen
Weitere anonymisierte Projekte.
Ihr Vorhaben
Müssen bei Ihnen zwei Systeme zuverlässig zusammenarbeiten?
Ob eine Integration trägt, entscheidet sich an den Eigenschaften der vorhandenen Schnittstellen — nicht am Aufwand, der hineingesteckt wird. Diese Frage lässt sich vor dem Entwicklungsstart klären.