WMS-Integration bei Constellation Cold Logistics: von direkten Schreibzugriffen auf die Datenbank zu einem Datenmodell

Eine Dateifreigabe, direkt in die Datenbank geschrieben

Ausgangspunkt war eine gemeinsame SFTP-Dateifreigabe auf einem lokalen, an AS/400 gebundenen Server. Alle Kunden lieferten ihre Dateien am selben Ort ab, und die Dateien wurden abgeholt und direkt in die Datenbanktabellen geschrieben, Nachricht für Nachricht. Es gab keine gemeinsame Schicht und keine gemeinsame Struktur. Die Eigenheiten jedes Kunden steckten in dem Code, der seine Dateien in die Tabellen schrieb, und für einen neuen Kunden wurde alles noch einmal gebaut. Einige Kunden nutzten gar kein EDI.

Das versteckte Problem

Nicht nur das Datenmodell war undokumentiert. Die Leitungen dahinter waren es auch.

• Jede neue Kundenverbindung warf dieselben Fragen auf: Holen wir die Datei ab, oder liefert der Kunde sie? SFTP oder eine API, von der wir selbst abrufen müssen? Und welches Format steckt eigentlich in der Datei?
• Das Wissen lag bei einzelnen Personen, nicht in der Dokumentation. Die ursprünglichen Integrationen waren von wenigen, sehr erfahrenen Leuten gebaut worden, und wenn sie gehen, nehmen sie das Wissen um das Warum mit.
• Alte Kundenprofile wurden als Vorlagen aufbewahrt, nur damit das nächste Onboarding etwas zum Kopieren hatte.
• Die AS/400-Tabellen, in die alles geschrieben wurde, waren genauso undokumentiert wie die Dateien, die hereinkamen.

Das ist, als würde man ein Haus ohne Baupläne erben, in dem die Hälfte der Rohre in den Wänden steckt. Bevor man neue Rohre verlegen kann, muss man herausfinden, wo die alten tatsächlich verlaufen.

Ein internes Modell pro Nachrichtentyp

Kern der Lösung ist ein kanonisches Datenmodell, auf Englisch Canonical Data Model oder CDM, für jeden Nachrichtentyp: Aufträge, Versandavise, Wareneingänge, Bestandskorrekturen und weitere. Es ist ein standardisiertes internes Format, über das Constellation selbst die volle Kontrolle hat. Das Modell wurde aus großen Mengen echter Produktionsdaten über alle Kunden hinweg abgeleitet und mithilfe von KI analysiert, damit es für alle trägt und nicht nach den Eigenheiten eines einzelnen Kunden geformt ist. Es legt die Felder fest, die mindestens vorhanden sein müssen, damit ein Kunde überhaupt angebunden werden kann.

Stellen Sie es sich wie eine gemeinsame Arbeitssprache in der Diplomatie vor. Statt dass jedes Land einen Dolmetscher für jedes andere Land braucht, hat jedes Land einen Dolmetscher: aus der eigenen Sprache in die gemeinsame und zurück. Kommt ein neues Land hinzu, kommt ein Dolmetscher hinzu. Die anderen bleiben, wie sie sind.

So sieht ein Auftrag im Modell aus

Zwei Ebenen in den Positionen, Palette und darunter Packstück, sorgen dafür, dass die Rückverfolgbarkeit auf der Ebene ansetzen kann, die der einzelne Kunde für die Rückverfolgung nutzt. Onboarding heißt genau das, und zwar einmalig: die Felder des Kunden auf das Modell abbilden, eingehend und ausgehend. Alle nachgelagerten Schritte gibt es bereits.

So senden es die Kunden, und so verlangt es das Modell

Jede Nachricht ist nachverfolgbar, und jede Eigenheit ist gekapselt

Jede Nachricht im Modell trägt ihre eigenen Metadaten: Quellsystem, Modellversion, Status und Zeitstempel. Geht etwas schief, etwa durch fehlerhafte Daten von einem Kunden, ein fehlendes Feld oder eine fehlgeschlagene Lieferung, lässt es sich genau auf die Nachricht, den Kunden und die Stelle in der Kette zurückführen. Dass sich nachweisen und nachverfolgen lässt, was mit den Daten geschehen ist, statt sie nur zu bewegen, war einer der wichtigsten Gründe, warum sich Constellation für Lobster als Zwischenschicht entschieden hat.

• Kundenspezifische Logik liegt im eigenen Profil des Kunden, nicht verstreut im Kernprozess. Die Sonderregel eines Kunden kann den Flow eines anderen nicht durcheinanderbringen, und der Kern bleibt lesbar.
• Ein neuer Kunde ist eine Mapping-Aufgabe: sein Format zum Modell und zurück, plus der Transport. Der Rest des Flows existiert bereits, mit definierten Pflichtfeldern.
• Keine Bindung an ein Lagersystem. Heute ist es Infor WMS. Wird es gewechselt, ändert sich nur das Mapping vom Modell zum Lagersystem, und ein zusätzliches Lagersystem aus einem Zukauf ist eine Ergänzung, keine Migration.

Das Ziel: Onboarding in rund zwei Monaten

Früher bedeutete das Onboarding eines einzelnen Kunden monatelanges Hin und Her, typischerweise sechs bis acht Monate. Mit dem Modell liegt das Ziel für eine neue Verbindung bei rund zwei Monaten, und der erste Kunde wird derzeit nach dem neuen Modell angebunden. Geplant sind weitere dänische Kundenverbindungen und danach die anderen Länder des Konzerns. Das erste Lager soll laut Plan im November 2026 auf Infor WMS in Betrieb gehen, und nach monatelangen Tests funktionieren sowohl die Standardprozesse als auch die Ausnahmen drumherum.

Weg vom lokalen Server, hin zu APIs

Alles bisher Beschriebene ist gebaut und in Betrieb. Das Folgende zeigt die Richtung, nicht den Lieferumfang.

• Die Kunden ziehen von der AS/400-gebundenen Dateifreigabe zu Lobster um: mindestens SFTP, gehostet in Lobster, und HTTP direkt für Kunden, die eine API nutzen können. Es geht nicht darum, SFTP abzuschaffen, denn Lobster beherrscht fast jedes Protokoll, sondern darum, vom lokalen Server wegzukommen.
• Das Modell und die Berichte werden als externe APIs bereitgestellt, mit dem eigenen OAuth2-Dienst von Lobster und der Zugriffssteuerung im API Manager, sodass die Kunden ihre Daten selbst abrufen können, wann sie wollen.
• Onboarding über den Trading Partner Manager, in dem Partnereinrichtung, Transport und Zugänge an einer Stelle zusammenkommen, sodass die Anbindung eines API-fähigen Kunden zum Einrichtungsschritt wird statt zum Entwicklungsprojekt.
• Nicht alle Kunden brauchen eine vollständige EDI-Anbindung oder haben die Kapazität dafür. Die Vision ist ein WebEDI-Portal für kleinere Kunden, in dem Auftrags- und Bestandsdaten im Browser sichtbar sind, ohne dass EDI eingerichtet werden muss.

Die Lösung war von Anfang an für mehrere Lager und mehrere Länder gedacht; die Trennung pro Kunde ist Teil der Struktur und kein nachträglicher Zusatz. Jeder Zukauf im Konzern bringt seine eigenen Systeme und seine eigene Version von AS/400 mit, genau wie damals Dänemark. Das hier entwickelte Muster ist keine dänische Lösung, sondern eine wiederverwendbare Blaupause für den nächsten Zukauf.