KI-Readiness beginnt bei den Daten Datenplattform statt Systemwechsel: Warum SupplyX sein TMS behielt

Anbieter zum Thema

Fivetran Germany GmbH

Als SupplyX sein Transportmanagement-System (TMS) ersetzen wollte, zeigte die Analyse den eigentlichen Engpass: fragmentierte Daten und uneinheitliche Prozesse. Ein Praxisbericht über die Datenarbeit, die jeder produktiven KI vorausgeht.

Wenn ein zentrales IT-System in die Jahre kommt, liegt die vermeintliche Lösung oft nahe: ein neues System muss her. So begann das Projekt bei SupplyX, dem Supply-Chain- und Seefracht-Dienstleister der Otto Group. Das TMS, die zentrale Software zur Steuerung von Transporten, sollte ersetzt werden.

Die Analyse führte jedoch zu einem anderen Befund. Ein Austausch hätte kaum wirtschaftlichen Nutzen gebracht und die geplante Transformation eher erschwert. Der Engpass lag nicht im TMS selbst, sondern darunter: in fragmentierten Daten, uneinheitlichen Prozessen und schwer nutzbaren Informationen. Im Projekt zeigte sich: Automatisierung und KI scheitern selten zuerst an der Technologie, sondern daran, ob die Datenbasis trägt.

Erste Fehlannahme: Man müsse die Daten nur zusammenführen

Eine zentrale Annahme erwies sich früh als falsch: Die Datenquellen seien weitgehend standardisiert und müssten nur zusammengeführt werden. Tatsächlich hatte jede Quelle eigene Logiken, Formate und Schwächen. Wichtige Felder wie Frachtführer, Buchungsnummern oder Container-IDs waren leer oder falsch belegt. Ein einziger Kunde tauchte in den Stammdaten unter 16 verschiedenen Bezeichnungen auf.

Einige Quellen lieferten weder ein verlässliches Schema noch ausreichende Dokumentation. Testdaten halfen nur begrenzt, weil viele Sonderfälle erst im laufenden Betrieb sichtbar wurden. Die Aufgabe bestand also nicht nur in technischer Anbindung, sondern darin, aus unsauberen Quellen eine belastbare Grundlage zu schaffen. Ein reiner Systemwechsel hätte dieses Problem nicht gelöst.

Kommentar von Alexander Zschaler, Fivetran

KI-Readiness ist Daten-Readiness

Rohdaten bleiben roh, und das aus gutem Grund

Aus diesem Befund folgte die zentrale Architekturentscheidung: Statt ein System gegen ein anderes auszutauschen, entstand eine Datenplattform neben dem laufenden Betrieb. Ihr Leitgedanke ist die Trennung von Daten und Anwendung. Standardsoftware bleibt dort im Einsatz, wo sie Standardprozesse abbildet. Differenzierende Prozesse entstehen auf einer eigenen Datenschicht.

Technisch werden Rohdaten zunächst unverändert gespeichert. Erst danach werden sie bereinigt, angereichert und für konkrete Anwendungsfälle aufbereitet. Daten schon beim Eingang in ein einheitliches Modell zu zwingen, wurde verworfen: Bei heterogenen Quellen würde diese Schicht zu oft brechen.

Die Datenaufnahme archiviert Informationen deshalb unverändert, die Logik liegt nachgelagert. Das macht die Verarbeitung stabiler, testbarer und wiederholbar. Eine Streaming-Infrastruktur steht zwar bereit, kommt aber bewusst nicht zum Einsatz: Für die Container-Freistellung, also die Freigabe eines Containers zur Abholung am Hafen oder Terminal, genügt eine Verarbeitung im Minutentakt. Verknüpfungen, Korrekturen und Entitätsauflösung laufen in einer nachgelagerten, SQL-basierten Schicht. So lässt sich die Logik schnell anpassen, auf historische Daten erneut anwenden und mit weiteren Datenquellen verknüpfen, ohne die Eingangsschicht zu verändern. Das reduziert die Systemkomplexität.

Bei SupplyX wurde diese Logik in einer Google-Cloud-Umsetzung realisiert, mit BigQuery, Cloud Pub/Sub, Cloud Functions und Python. Entscheidend ist das Prinzip: Rohdaten bleiben erhalten, Verarbeitung wird reproduzierbar, Anwendungen greifen auf eine konsolidierte Sicht zu.

Wenn Quellen einander korrigieren

Die wichtigste Komponente der Plattform war anfangs nicht in dieser Tiefe geplant: ein Korrekturmechanismus, der Hinweise aus verschiedenen Quellen gegeneinander prüft, statt einer einzelnen Quelle blind zu vertrauen.

Ist im Datensatz ein falscher Frachtführer hinterlegt, liegen aber Sendungsverfolgungsdaten unter einem anderen Carrier-Code vor, wird dieser Hinweis stärker gewichtet und der Carrier-Code korrigiert. Ist eine Container-ID wegen der Prüfziffer ungültig, wird sie mit gültigen IDs derselben Sendung abgeglichen und als möglicher Tippfehler erkannt. Fehler und Widersprüche, die früher manuell recherchiert und nachgepflegt wurden, lassen sich so während der Verarbeitung automatisch erkennen, korrigieren und dokumentieren.

Werte werden nicht einfach überschrieben; Korrekturen werden mit Quelle, Beleg und Zeitstempel ergänzt. So entsteht ein Prüfprotokoll, aus dem ersichtlich bleibt, warum ein Wert angepasst wurde. Neue Quellen oder Regeln lassen sich als weitere Hinweisgeber ergänzen, ohne das Gesamtsystem umzubauen.

Gerade diese quellenübergreifende Korrektur zeigt, warum die Datenplattform der richtige Hebel war: Auch ein neues TMS bliebe zunächst eine einzelne Systemsicht. Es könnte Widersprüche zwischen mehreren Quellen nicht automatisch auflösen.

Der Engpass wandert vom Daten- zum Prozessproblem

Mit der konsolidierten Datenbasis zeigte sich die nächste Annahme: Wenn alle Daten an einem Ort liegen, lassen sich Anwendungen digitalisieren. Auch das war zu einfach gedacht. Automatisierung setzt nicht nur verfügbare Daten voraus, sondern auch standardisierte Prozesse.

Der erste Anwendungsfall machte das deutlich: die Container-Freistellung im Nachlauf, also beim Weitertransport vom Hafen zum Lager. Für diese Freigabe mussten zuvor Informationen aus mehreren Systemen und von verschiedenen Reedereien manuell zusammengetragen werden, jeweils mit eigenen Kommunikationswegen und Abläufen.

Bevor automatisiert werden konnte, mussten diese Wege in einen einheitlichen Prozess überführt werden. Der Engpass verschob sich also vom Daten- zum Prozessthema. Heute stellt die Plattform dem Sachbearbeiter die nötigen Informationen zum richtigen Zeitpunkt bereit. Er prüft und bestätigt den Vorgang. Das spart nach Projektangaben rund zwei Minuten pro Container. Bei mehreren tausend Containern im Jahr entsteht daraus ein messbarer Effekt.

Kommentar von Srinivasaa HG, Wipro

KI-Initiativen stehen und fallen mit der Datenreife

Der zweite Anwendungsfall ist die eigentliche Bewährungsprobe

Der größere Effekt zeigt sich nach dem ersten Anwendungsfall. Die Container-Freistellung erforderte zwei neue Fähigkeiten: das Einlesen von E-Mails und die Verarbeitung von Dokumenten. Beide wurden zur Grundlage weiterer Anwendungen: Dokumentenmanagement, automatisierte Dokumentenverarbeitung, das Auslesen von Sendungsdaten aus Spediteur-Mails und intelligente Weiterleitung mithilfe eines Sprachmodells.

Das Muster ist immer gleich: Ein Anwendungsfall macht eine Fähigkeit nötig; diese wird zur Grundlage für weitere Anwendungen und reduziert Integrationsarbeit.

Bei SupplyX führt die Plattform heute Daten aus zahlreichen Quellsystemen zusammen. Monatlich verarbeitet sie E-Mails und Dokumente in zehntausender Größenordnung. Auf dieser Basis korrigiert und protokolliert sie fehlerhafte oder widersprüchliche Datensätze quellenübergreifend. Wie tragfähig diese Basis ist, zeigte sich bei der Eröffnung eines Standorts in Vietnam: Die Teams dort griffen auf dieselbe Datenbasis zu wie die Kollegen in Hamburg, ohne den technischen Unterbau vor Ort nachbauen zu müssen. Selbst wenn ein Partner Sendungsdaten nur als Excel-Datei per E-Mail schickt, kann daraus eine nutzbare Datenquelle werden.

Der wirtschaftliche Nutzen reicht über einzelne Automatisierungen hinaus. Ein Grund liegt in der Systemlandschaft selbst: ERP, TMS, WMS (Warehouse Management System für die Lagerverwaltung) und andere Systeme führen ähnliche Daten oft unterschiedlich. Aufwendig wird es, wenn ein neues System eingeführt wird oder ein bestehendes ein neues Release erhält: Datenmodelle, Schnittstellen und Altdaten müssen geprüft, zugeordnet oder migriert werden. Wenn Daten jedoch von der einzelnen Software entkoppelt und in einer gemeinsamen, konsolidierten Datenschicht vorliegen, greifen Anwendungen auf dieselbe verlässliche Datengrundlage zu. Dadurch reduziert sich der Aufwand im IT-Systembetrieb deutlich. Nach interner Bewertung von SupplyX ergeben sich daraus Einsparungen im siebenstelligen Bereich. Zugleich entsteht die Grundlage für KI-gestützte Services, mit denen SupplyX seinen Kunden zusätzliche Optimierungen anbieten und sich im Wettbewerb differenzieren kann.

SupplyX-CDO Jörn von der Fecht beschreibt den Weg als schrittweise Transformation: Die cloudbasierte Daten- und IT-Infrastruktur ermögliche es, internen Teams wie auch Kunden kontinuierlich und schnell neue Lösungen und Optimierungen bereitzustellen.

KI ist kein Sonderfall, sondern ein Datenprodukt

Künstliche Intelligenz (KI) spielte im Projekt dort eine Rolle, wo sie konkreten Nutzen erzeugt: beim Auslesen von Frachtdokumenten wie dem Konnossement, also dem Frachtbrief im Seeverkehr, beim Zuordnen uneindeutiger Kundennamen und beim Verknüpfen von Dokumenten mit Sendungen. Außerdem senkt KI die Kosten für Prototypen und interne Werkzeuge.

Der entscheidende Punkt liegt nicht im Modell. KI-Ergebnisse werden wie andere Datenprodukte behandelt. Bevor sie produktiv genutzt werden, müssen sie gegen verlässliche Vergleichsdaten geprüft werden, eine sogenannte Ground Truth. Ein manuell geprüfter Testdatensatz hilft, Modellqualität zu bewerten; Prüfprotokolle machen nachvollziehbar, welche Information wodurch entstanden ist.

Auch Governance gehört dazu. Nach dem Prinzip der geringstmöglichen Autonomie bekommt jede Anwendung nur so viele Rechte, wie für den konkreten Fall nötig sind. Aus einem KI-Prototyp wird erst dann eine produktive Anwendung, wenn Datenmodell, Datenqualität und Referenzwerte stimmen. KI-Fähigkeit beginnt nicht beim Modell, sondern bei der Datenfähigkeit des Unternehmens.

Fazit: Ohne belastbare Daten bleibt KI ein Prototyp

Standardsoftware bleibt richtig für Standardprozesse, bei denen Stabilität zählt und Differenzierung keine Rolle spielt. Wo ein Unternehmen sich unterscheiden will, entscheidet die Datenschicht darunter. Nur verlässliche, nachvollziehbare und anwendungsfähige Daten schaffen die Basis für Automatisierung und KI.

Über den Autor

Mathias Sinn ist Co-Founder und Managing Director von RAIN – Rapid Innovation in Berlin. Seit über 20 Jahren begleitet er Unternehmen bei digitaler Transformation, datengetriebenen Geschäftsmodellen und der Entwicklung skalierbarer MVPs in komplexen Organisationen. Zuvor war er unter anderem Managing Director bei Neue Digitale/Razorfish sowie Co-Founder von Hi-Res! Berlin und arbeitete für internationale Marken wie Audi, BMW und McDonald's.

(ID:50908438)