Datenfragmentierung ist eines dieser Probleme, das leicht zu erklären und überraschend schwer zu lösen ist. Die Daten existieren in ERPs, Supplier-Portalen, Carrier-Updates und Warehouse-Logs. Sie bewegen sich nur nicht. Zusätzlich ist der Versuch, sie zum Fließen zu bringen, ohne vorher zu definieren, wie der Prozess eigentlich ablaufen soll, ein weiterer Grund, warum Integrationsprojekte so lange dauern.
Nehmen wir ein typisches Szenario, welches viele Operations Teams kennen: ein neuer saisonaler Lieferantenvertrag, genau die Bestände, die das Unternehmen gebraucht hat. Bestellungen gehen raus, Bestätigungen kommen zurück. Alles sieht gut aus. Dann vergehen drei Wochen und die Sendungen haben sich nicht bewegt. Der Lieferant hat Informationen via EDI gesendet. Der 3PL hat Flat Files geliefert. Der Carrier hat JSON-Updates bereitgestellt. Das ERP wartete auf strukturierte Tabelleneinträge. Jedes System hat seinen Job gemacht. Keines davon hat das andere verstanden.
Und das ist noch der einfachere Fall. Viele saisonale oder kurzfristige Partner arbeiten komplett mit Excel. Es gibt keine Schnittstellen, keine standardisierten Datenflüsse. Die Zusammenarbeit dauert vielleicht nur eine Saison, der Aufwand für die Anbindung ist aber derselbe.
Datensilos in der Supply Chain: Warum niemand das Gesamtbild hat
Supply Chain Teams haben nicht zu wenig Daten. Sie haben ein ERP, das Bestände verfolgt, ein TMS zur Sendungsverfolgung, Lieferanten, die EDI oder PDFs senden, und Carrier, die API-Updates bereitstellen. Jedes dieser Systeme erfasst relevante Informationen, nur eben in seiner eigenen Struktur.
CSV wurde in den frühen 1970er Jahren entwickelt, um Daten zwischen Computersystemen zu übertragen. EDI-Standards wie X12 und EDIFACT wurden in den späten 1970er und 1980er Jahren von Standardisierungsgremien entwickelt, um den Austausch von Geschäftsdokumenten über langsame Netzwerke hinweg zuverlässig zu machen. Das erste kommerzielle TMS erschien in den frühen 1990er Jahren. JSON-APIs kamen später noch dazu, geprägt durch die Anforderungen des Webs.
Keine dieser Formate wurde entwickelt, um miteinander zu sprechen. Ihr Aufeinandertreffen in modernen Lieferketten ist ein Zufall der Geschichte.
Ein wichtiger Punkt wird oft übersehen: Das Problem ist nicht nur, dass die Technologien nicht miteinander sprechen. Selbst wenn sie es täten, kämpfen Teams trotzdem damit, weil der Prozess selbst nicht durchgängig entworfen ist: was wird wann aktualisiert und wie mit Ausnahmen umgegangen wird, ist oft nur in den Köpfen der Menschen vorhanden.
Es ist die Kombination aus unklaren Prozessen und fragmentierter Technologie, die Anbindung und Datenfluss zu einem dreiwöchigen Prozess statt zu ein paar Stunden macht.
Dazu kommen Workarounds. Jede Supply Chain trägt eine Schicht an Integrationslogik, die niemand vollständig dokumentiert hat, wie Skripte von Personen, die das Unternehmen inzwischen verlassen haben, oder Excel-Makros, die zwei Systeme auf eine Weise verbinden, die niemand mehr vollständig versteht. Diese Strukturen wachsen über die Zeit.
Wenn ein Lieferant mitten in der Saison ein Feld ändert, brechen diese Workarounds. Das Operations Team muss dann eine dreiwöchige Verzögerung erklären: eine verpasste Verkaufschance und neue Fragen dazu, wo die Verantwortung liegt.
Wie Integrationsprojekte in der Praxis aussehen
Der übliche Ansatz ist klar: System A mit System B verbinden, Felder mappen, testen und live schalten. Allerdings konkurrieren Integrationsanfragen aus der Supply Chain mit Infrastruktur-Upgrades, Security-Patches und Kernsystem-Arbeiten, für die die IT sowohl besser aufgestellt als auch direkter verantwortlich ist. Anforderungen aus der Supply Chain werden oft zurückgestellt, weil die Warteschlange lang ist und der Impact meist erst sichtbar wird, wenn etwas kaputtgeht.
Es gibt auch eine Wissenslücke, die den Prozess auf eine weniger offensichtliche Weise verlangsamt. Eine Integration zwischen zwei Systemen zu bauen bedeutet nicht nur, technische Formate zu verstehen, sondern auch die Geschäftslogik dahinter, zum Beispiel warum ein bestimmter Lieferant Bestätigungen in zwei separaten Nachrichten sendet, was ein Statuscode im Kontext des Workflows eines 3PL bedeutet, welche Felder verpflichtend sind und welche inkonsistent gepflegt werden. Dieser Kontext liegt bei den Operations Teams, nicht in der IT. Die Übersetzung verlangsamt alles.
Die Vorteile von frei fließenden Daten
Wenn eine Supply Chain in der Lage ist, jedes Format zu verarbeiten – EDI, XML, JSON, Flat File – und es automatisch in eine einheitliche Arbeitsschicht zu normalisieren, verändern sich einige Dinge.
Die Anbindung eines neuen Lieferanten wird zu einer einfachen Konfiguration. Der Lieferant muss seine Arbeitsweise nicht ändern. Die Systeme müssen nicht neu aufgebaut werden. Die Übersetzung passiert fast automatisch – Felder werden gemappt, Formate konvertiert, Logik angewendet – ohne jedes Mal individuellen Code zu schreiben.
Sendungsverfolgung wird nutzbar. Wenn ein Carrier ein Update sendet, landet es sofort in der Planungsschicht, nicht erst nach manueller Aufbereitung und E-Mail-Zusammenfassungen. Der Unterschied in der Praxis ist erheblich: Entscheidungen basieren auf aktuellen Informationen, nicht auf dem Stand vom Vortag.
Noch wichtiger ist der langfristige Effekt: Eine Supply Chain, die Veränderungen als normalen Teil des Betriebs aufnehmen kann. Neue Partner, neue Formate, Updates bestehender Partner – ohne IT-Ticket.
Für Modehändler mit saisonalen Einkäufen über mehrere Lieferanten verändert das die Flexibilität innerhalb eines Quartals. Für Lebensmittelhändler mit frischen Lieferketten verändert es, was zuverlässige Lieferung im Tagesgeschäft bedeutet.
Ein vernetztes Gesamtsystem
Bevor das nächste Integrationsprojekt geplant wird, lohnt sich eine grundlegendere Frage: Geht es darum, zwei Systeme zu verbinden, oder darum, das gesamte Netzwerk interoperabel zu machen?
Die erste Herangehensweise führt zu einzelnen Verbindungen, die funktionieren, bis sich etwas ändert. Die zweite führt zu einer Architektur, in der neue Partner, neue Formate und neue Datenquellen ohne Neuentwicklung aufgenommen werden können.
Entscheidend ist ein flexibles Integrationstool, welches schnell konfigurierbar ist und Lieferanten einfach integriert, sei es ein EDI-Feed, eine JSON-API oder eine manuell gepflegte Tabelle.
Die Fragmentierung lässt sich nicht dauerhaft umgehen. Sie muss gezielt gelöst werden.
FAQ
F: Warum dauert die Anbindung neuer Lieferanten so lange?
A: Meist liegt es an zwei Faktoren: unterschiedliche technische Systeme und fehlende klare Prozesse. Selbst wenn einzelne Systeme funktionieren, entstehen Verzögerungen, wenn Abläufe nicht eindeutig definiert sind.
F: Warum kann IT nicht einfach die Integrationen bauen, die Supply Chain Teams brauchen?
A: Die IT kann das grundsätzlich, arbeitet jedoch parallel an vielen anderen Themen wie Infrastruktur und Sicherheit. Zudem fehlt oft das Detailwissen über die operativen Abläufe, das für eine korrekte Umsetzung notwendig ist.
F: Was bedeutet „Process-first, tech-enabled”?
A: Zuerst wird festgelegt, wie der Ablauf funktionieren soll. Danach wird Technologie eingesetzt, um diesen Ablauf umzusetzen und zu automatisieren.
F: Welche Systeme müssen typischerweise integriert werden?
A: ERP-Systeme, TMS-Systeme, Lieferantenportale, Carrier-Systeme und Warehouse-Management-Systeme. Integration sollte diese Systeme in eine gemeinsame Sprache bringen.
F: Welche Vorteile bringt moderne Supply Chain Execution?
A: Schnellere Anbindung (Stunden statt Wochen), weniger Fehler, Echtzeit-Transparenz, weniger Abhängigkeit von IT im Tagesgeschäft und eine Supply Chain, die Veränderungen problemlos aufnehmen kann.