Datenfragmentierung ist eines dieser Probleme, das leicht zu erkl\u00e4ren und \u00fcberraschend schwer zu l\u00f6sen ist. Die Daten existieren in ERPs, Supplier-Portalen, Carrier-Updates und Warehouse-Logs. Sie bewegen sich nur nicht. Zus\u00e4tzlich ist der Versuch, sie zum Flie\u00dfen zu bringen, ohne vorher zu definieren, wie der Prozess eigentlich ablaufen soll, ein weiterer Grund, warum Integrationsprojekte so lange dauern.<\/p>\n\n\n\n
Nehmen wir ein typisches Szenario, welches viele Operations Teams kennen: ein neuer saisonaler Lieferantenvertrag, genau die Best\u00e4nde, die das Unternehmen gebraucht hat. Bestellungen gehen raus, Best\u00e4tigungen kommen zur\u00fcck. 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\u00e4ge. Jedes System hat seinen Job gemacht. Keines davon hat das andere verstanden.<\/p>\n\n\n\n
Und das ist noch der einfachere Fall. Viele saisonale oder kurzfristige Partner arbeiten komplett mit Excel. Es gibt keine Schnittstellen, keine standardisierten Datenfl\u00fcsse. Die Zusammenarbeit dauert vielleicht nur eine Saison, der Aufwand f\u00fcr die Anbindung ist aber derselbe.<\/p>\n\n\n\n
Supply Chain Teams haben nicht zu wenig Daten. Sie haben ein ERP, das Best\u00e4nde 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.<\/p>\n\n\n\n
CSV<\/a> wurde in den fr\u00fchen 1970er Jahren entwickelt, um Daten zwischen Computersystemen zu \u00fcbertragen. EDI-Standards<\/a> wie X12 und EDIFACT wurden in den sp\u00e4ten 1970er und 1980er Jahren von Standardisierungsgremien entwickelt, um den Austausch von Gesch\u00e4ftsdokumenten \u00fcber langsame Netzwerke hinweg zuverl\u00e4ssig zu machen. Das erste kommerzielle TMS erschien in den fr\u00fchen 1990er Jahren. JSON-APIs<\/a> kamen sp\u00e4ter noch dazu, gepr\u00e4gt durch die Anforderungen des Webs.<\/p>\n\n\n\n Keine dieser Formate wurde entwickelt, um miteinander zu sprechen. Ihr Aufeinandertreffen in modernen Lieferketten ist ein Zufall der Geschichte.<\/p>\n\n\n\n Ein wichtiger Punkt wird oft \u00fcbersehen: Das Problem ist nicht nur, dass die Technologien nicht miteinander sprechen. Selbst wenn sie es t\u00e4ten, k\u00e4mpfen Teams trotzdem damit, weil der Prozess selbst nicht durchg\u00e4ngig entworfen ist: was wird wann aktualisiert und wie mit Ausnahmen umgegangen wird, ist oft nur in den K\u00f6pfen der Menschen vorhanden.<\/p>\n\n\n\n Es ist die Kombination aus unklaren Prozessen und fragmentierter Technologie, die Anbindung und Datenfluss zu einem dreiw\u00f6chigen Prozess statt zu ein paar Stunden macht.<\/p>\n\n\n\n Dazu kommen Workarounds. Jede Supply Chain tr\u00e4gt eine Schicht an Integrationslogik, die niemand vollst\u00e4ndig 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\u00e4ndig versteht. Diese Strukturen wachsen \u00fcber die Zeit.<\/p>\n\n\n\n Wenn ein Lieferant mitten in der Saison ein Feld \u00e4ndert, brechen diese Workarounds. Das Operations Team muss dann eine dreiw\u00f6chige Verz\u00f6gerung erkl\u00e4ren: eine verpasste Verkaufschance und neue Fragen dazu, wo die Verantwortung liegt.<\/p>\n\n\n\n Der \u00fcbliche 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\u00fcr die die IT sowohl besser aufgestellt als auch direkter verantwortlich ist. Anforderungen aus der Supply Chain werden oft zur\u00fcckgestellt, weil die Warteschlange lang ist und der Impact meist erst sichtbar wird, wenn etwas kaputtgeht.<\/p>\n\n\n\n Es gibt auch eine Wissensl\u00fccke, 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\u00e4ftslogik dahinter, zum Beispiel warum ein bestimmter Lieferant Best\u00e4tigungen 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 \u00dcbersetzung verlangsamt alles.<\/p>\n\n\n\n Wenn eine Supply Chain in der Lage ist, jedes Format zu verarbeiten \u2013 EDI, XML, JSON, Flat File \u2013 und es automatisch in eine einheitliche Arbeitsschicht zu normalisieren, ver\u00e4ndern sich einige Dinge.<\/p>\n\n\n\n Die Anbindung eines neuen Lieferanten wird zu einer einfachen Konfiguration. Der Lieferant muss seine Arbeitsweise nicht \u00e4ndern. Die Systeme m\u00fcssen nicht neu aufgebaut werden. Die \u00dcbersetzung passiert fast automatisch \u2013 Felder werden gemappt, Formate konvertiert, Logik angewendet \u2013 ohne jedes Mal individuellen Code zu schreiben.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Noch wichtiger ist der langfristige Effekt: Eine Supply Chain, die Ver\u00e4nderungen als normalen Teil des Betriebs aufnehmen kann. Neue Partner, neue Formate, Updates bestehender Partner \u2013 ohne IT-Ticket.<\/p>\n\n\n\nWie Integrationsprojekte in der Praxis aussehen<\/h2>\n\n\n\n
Die Vorteile von frei flie\u00dfenden Daten<\/h2>\n\n\n\n