KI in der Lieferkette: Warum der Plattformwechsel die eigentliche Vorarbeit ist
Prognosemodelle scheitern selten am Modell. Sie scheitern daran, dass derselbe Artikel in der Historie drei Nummern hat, die Wiederbeschaffungszeit im Kopf des Einkaufs steht und der Bestand nur nachts abgeglichen wird. Wir zeigen, welche vier Reifegrade zwischen Daten und Entscheidung liegen, welche sieben Anwendungsfälle nach einem Umstieg realistisch sind — und in welcher Projektphase Sie die Datenmängel ohne Zusatzbudget beheben.
Der Anruf kommt meistens in dieser Reihenfolge. Zuerst die Frage nach einem Werkzeug für Nachfrageprognosen — welches man nehmen soll, was es kostet, ob es sich an Shopify anbinden lässt. Dann, ein paar Sätze später, der eigentliche Satz: “Wir haben letztes Jahr zweimal die Hauptartikel leerlaufen lassen und gleichzeitig ein Lager voll Ware, die keiner will.”
Das zweite Problem ist real. Das erste ist noch nicht die Lösung dafür.
Denn ein Prognosemodell rechnet auf der Verkaufshistorie, die Sie ihm geben. Wenn in dieser Historie derselbe Artikel unter drei Nummern läuft, weil er 2023 den Lieferanten gewechselt hat, wenn die Wiederbeschaffungszeit nirgends gepflegt ist und wenn der Black Friday nicht als Aktion markiert wurde, dann liefert auch ein exzellentes Modell exzellent falsche Zahlen. Und zwar solche, die plausibel aussehen.
Für Unternehmen, die ohnehin vor einem Plattformwechsel stehen, ist das eine gute Nachricht. Die Vorarbeit, die dieses Thema braucht, fällt in einem Migrationsprojekt sowieso an. Man muss sie nur bewusst machen, statt sie als lästigen Nebenschauplatz der Datenübernahme abzuhaken.
Was diese Systeme tatsächlich brauchen
Künstliche Intelligenz in der Lieferkette klingt nach einer Technologiefrage. In der Praxis ist sie zu großen Teilen eine Frage von Datenherkunft und Systemgrenzen.
Die Systeme, um die es geht, tun im Kern drei Dinge: Sie erkennen Muster in Verkaufs- und Bestandsdaten, sie vergleichen einen aktuellen Zustand mit einem erwarteten, und sie fassen unstrukturierte Informationen — Lieferantenmails, Auftragsbestätigungen, Frachtpapiere — in etwas Lesbares zusammen. Alle drei brauchen dieselbe Grundlage: Daten, die vollständig sind, konsistent benannt und einem gemeinsamen Vorgang zuzuordnen.
Genau hier liegt der Bruch in gewachsenen Landschaften. Der Bestand liegt in der Warenwirtschaft, der Verkauf im Shop, die Sendungsdaten beim Dienstleister, die Wiederbeschaffungszeit in einer Tabelle auf einem Laufwerk. Jedes System für sich ist gepflegt. Nur bezieht sich keines auf das andere.
Reifegrade
Vier Stufen — und die, auf der fast alle hängen bleiben
Jede Stufe setzt die darunter voraus. Werkzeuge werden in der Regel für Stufe drei und vier gekauft, während die Datenlage auf Stufe eins steht. Der Sprung, der dazwischen fehlt, ist keine Frage der Technologie, sondern der Systemgrenzen — und genau die verschieben sich beim Plattformwechsel ohnehin.
-
Erfassung
meist vorhandenBestände, Bestellungen, Lieferzeiten und Retouren entstehen überhaupt als Datensatz — nicht als Notiz, nicht als Mailanhang.
Setzt voraus Ein System, in dem jede Bestandsbewegung einen Zeitstempel und eine eindeutige Artikelnummer bekommt.
-
Verknüpfung
die eigentliche LückeDieselbe Bestellung ist in Shop, Warenwirtschaft und Versand als derselbe Vorgang erkennbar — über eine gemeinsame Kennung.
Setzt voraus Ein Artikelstamm mit einer führenden Quelle und eine Bestell-ID, die alle Systeme unverändert weiterreichen.
-
Prognose
wird zuerst gekauftAus zwei bis drei Jahren verknüpfter Historie entsteht eine Vorhersage, die besser ist als der Dreimonatsdurchschnitt.
Setzt voraus Mindestens vier Quartale sauber datierter Verkäufe je Artikel — inklusive Retouren am richtigen Datum.
-
Automatisierung
wird zuerst gekauftDie Prognose löst etwas aus: Nachbestellvorschlag, Umlagerung, Warnung an den Einkauf, Sperrung eines Artikels.
Setzt voraus Definierte Schwellen, ein dokumentierter Eskalationsweg und eine Person, die widersprechen darf.
Die Lücke zwischen Stufe eins und zwei ist der Grund, warum Prognosewerkzeuge in gewachsenen Landschaften enttäuschen. Sie rechnen korrekt — nur auf einer Historie, in der derselbe Artikel unter drei Bezeichnungen geführt wird.
Der Sprung von Stufe eins auf Stufe zwei ist der teure. Er ist auch der, den niemand gerne verkauft, weil er keine Oberfläche hat und in keiner Demo gut aussieht. Aber ohne ihn ist alles darüber Dekoration.
Die sieben Anwendungsfälle — und wann sie dran sind
In der Fachliteratur finden Sie regelmäßig dieselben sieben Einsatzfelder. Das ist keine Schwäche der Liste; sie ist tatsächlich vollständig. Was in der Liste fehlt, ist die Frage, die für Umsteiger:innen entscheidend ist: Wie viel Historie setzt das voraus, und wann habe ich die nach einem Systemwechsel?
Denn am Umschalttag beginnt Ihre saubere Datenhistorie bei null. Alles davor stammt aus einem anderen System mit anderen Definitionen — es ist nicht wertlos, aber es ist nicht ohne Weiteres fortschreibbar.
Anwendungsfälle
Sieben Einsatzfelder, sortiert nach dem, was sie voraussetzen
Die Reihenfolge ist keine Wertung, sondern eine Terminplanung. Oben stehen die Fälle, die im Wesentlichen mit den Daten auskommen, die ein neuer Shop ab dem ersten Tag selbst erzeugt. Unten die, für die Sie Historie brauchen — und die deshalb erst dann sinnvoll starten, wenn im neuen System genug davon zusammengekommen ist.
-
Bestellungen intelligent verteilen
Aus welchem Lager oder welcher Filiale eine Bestellung rausgeht — nach Verfügbarkeit, Auslastung und Splitkosten statt nach Entfernung.
-
Fulfillment automatisieren
Bestellinformationen fließen ohne Handgriff weiter, Bestände aktualisieren sich, Statuswechsel lösen den nächsten Schritt aus.
-
Einkaufsunterlagen auswerten
Lieferantenmails, Auftragsbestätigungen und Rechnungen zusammenfassen, Abweichungen zur Bestellung markieren.
-
Lieferengpässe früh erkennen
Die schleichende Verlängerung von Lieferzeiten sichtbar machen, bevor daraus ein leeres Regal wird.
-
Transport und Routen optimieren
Routen, Zeitfenster und Kapazitäten gegeneinander rechnen — bei eigener Auslieferung oder eigenem Fuhrpark.
-
Nachfrage prognostizieren
Saison, Aktionen, Preisänderungen und regionale Unterschiede zusammen betrachten statt Dreimonatsdurchschnitt fortschreiben.
-
Bestände dynamisch steuern
Meldebestände und Bestellmengen bewegen sich mit Nachfrage und Wiederbeschaffungszeit, statt fest im Stammsatz zu stehen.
Die oberen drei Fälle sind der realistische Umfang für das erste Jahr nach einem Plattformwechsel. Wer stattdessen mit der Nachfrageprognose beginnt, arbeitet auf einer Historie, die zu diesem Zeitpunkt aus zwei Systemen mit zwei Zählweisen stammt.
Die Aufteilung hat eine praktische Konsequenz für die Budgetplanung. Die drei oberen Fälle sind im Wesentlichen Konfigurations- und Integrationsarbeit: Order-Routing über mehrere Standorte, automatisierte Weitergabe von Bestellinformationen an Lager und Versand, Dokumentenauswertung im Einkauf. Sie funktionieren ab dem ersten Tag im neuen System, weil sie mit dem aktuellen Zustand arbeiten und nicht mit Vergangenheit.
Die unteren beiden — Nachfrageprognose und dynamische Bestandssteuerung — sind das, wonach in der Regel gefragt wird. Sie sind auch die, die vier Quartale Vorlauf brauchen. Wer sie im dritten Monat nach dem Go-Live startet, misst hauptsächlich die Migration.
Die Datenmängel, die niemand meldet
Zwischen “wir haben Daten” und “diese Daten tragen eine Entscheidung” liegt eine Reihe von Mängeln, die im Tagesgeschäft unsichtbar sind. Sie sind unsichtbar, weil Menschen sie ausgleichen: Die Einkäuferin weiß, dass Artikel 4471 und Artikel 8802 dasselbe Produkt sind. Der Lagerleiter weiß, dass der Bestand um 14 Uhr nicht stimmt. Niemand schreibt das auf, weil es im Kopf schneller geht.
Ein Modell hat diesen Kopf nicht.
Datenschulden
Sechs Mängel, die niemanden stören — bis ein Modell darauf rechnet
Keiner dieser Punkte fällt im Tagesgeschäft auf. Menschen gleichen sie unbewusst aus, ein Modell nicht. Die untere Zeile jeder Karte ist der Grund, warum dieses Thema in ein Migrationsprojekt gehört und nicht danach: In diesen Phasen fasst ohnehin jemand die Daten an.
-
Derselbe Artikel, drei Nummern
Über die Jahre ist ein Produkt neu angelegt worden statt gepflegt — bei Lieferantenwechsel, Verpackungsänderung oder Sortimentsumbau.
Merkt man an Die Verkaufshistorie eines Bestsellers bricht scheinbar ein und beginnt woanders neu.
Artikelstamm-Bereinigung vor dem Datenexport
-
Wiederbeschaffungszeit steht nirgends
Wie lange ein Lieferant tatsächlich braucht, weiß der Einkauf im Kopf. Im System steht entweder nichts oder ein Wert von 2019.
Merkt man an Meldebestände sind Bauchwerte. Bei Ausfall der zuständigen Person ist das Wissen weg.
Lieferantenstammdaten beim Aufsetzen der Warenwirtschaft
-
Bestände nur über Nacht abgeglichen
Der Abgleich zwischen Lager und Shop läuft als Nachtlauf. Tagsüber verkauft der Shop gegen einen Stand von gestern.
Merkt man an Überverkäufe an Aktionstagen, Stornos am Folgetag, verzerrte Verfügbarkeitsdaten in der Historie.
Schnittstellendesign, bevor die Integration gebaut wird
-
Retouren zum falschen Datum
Gutschriften werden zum Erstattungsdatum gebucht statt zum ursprünglichen Bestelldatum — oder umgekehrt, je nach System.
Merkt man an Nettoabsatzkurven, die zwei bis sechs Wochen gegen die Realität verschoben sind.
Definitionsabgleich vor dem ersten Reporting-Aufbau
-
Kein Feld für Lagerort
Filiale, Zentrallager und Dienstleisterbestand laufen in einer Summe. Woher ein Stück kam, ist im Nachhinein nicht rekonstruierbar.
Merkt man an Order-Routing lässt sich nicht bewerten, weil es keine Vergangenheit gibt, gegen die man rechnen könnte.
Standortmodell beim Aufsetzen der Bestandsführung
-
Aktionen sind nicht markiert
Rabattaktionen, Newsletter-Peaks und Messeverkäufe stehen als normale Bestellungen in der Historie.
Merkt man an Jedes Modell hält den Black-Friday-Ausschlag für ein wiederkehrendes Nachfragemuster.
Kampagnenkennzeichnung bei der Datenmigration
Die rechte Spalte jeder Karte ist der Grund, warum wir dieses Thema im Kickoff einer Migration ansprechen und nicht im Betrieb danach. Wenn ohnehin jemand den Artikelstamm exportiert, ist die Bereinigung ein Arbeitspaket. Ein Jahr später ist sie ein eigenes Projekt mit eigenem Budget und eigener Rechtfertigung.
Am häufigsten unterschätzt wird dabei der dritte Punkt, der Nachtlauf beim Bestandsabgleich. Er ist in gewachsenen Setups so verbreitet, dass er als normal gilt. Für die Kundschaft bedeutet er Überverkäufe an Aktionstagen; für Ihre Datenlage bedeutet er, dass die Verfügbarkeitshistorie systematisch falsch ist. Wie ein sauberer Datenfluss zwischen Warenwirtschaft und Shop stattdessen aussieht, haben wir in ERP-Integrationsmustern für Shopify im Detail aufgeschrieben.
Was der Wechsel auf Shopify konkret verändert
Ein Plattformwechsel löst diese Themen nicht automatisch. Er verschiebt aber zwei Dinge, die vorher strukturell im Weg standen.
Der Bestand bekommt einen Ort. In Shopify sind Lagerorte ein eigenes Konzept, nicht ein Zahlenfeld am Produkt. Filiale, Zentrallager und Dienstleisterbestand sind getrennt geführt und in Summe abfragbar. Damit wird Order-Routing überhaupt erst bewertbar — vorher gab es keine Vergangenheit, gegen die man eine Entscheidung hätte prüfen können. Für Häuser mit mehreren Standorten ist das der unterschätzteste Effekt des Umstiegs, und er ist eng verwandt mit dem, was wir unter Unified Commerce beschrieben haben.
Bestandsbewegungen werden abfragbar statt exportierbar. Der Unterschied zwischen einer nächtlichen CSV und einer Schnittstelle, die auf Veränderungen reagiert, ist nicht Bequemlichkeit. Er entscheidet, ob ein nachgelagertes System auf einem Stand von jetzt oder von gestern arbeitet. Das gilt für Prognosewerkzeuge genauso wie für den Verfügbarkeitshinweis auf der Produktseite.
Was der Wechsel dagegen nicht löst: Ihre Lieferantenstammdaten. Ihre Artikelnummernhistorie. Ihre Kampagnenkennzeichnung. Das sind Ihre Daten, und sie kommen so mit, wie Sie sie übergeben. Die Datenmigration ist der einzige Moment, in dem sie ohne laufenden Betrieb angefasst werden können.
Die Reihenfolge, die funktioniert
Aus Projekten, in denen dieses Thema am Ende getragen hat, lässt sich eine Reihenfolge ableiten. Sie beginnt nicht bei der Auswahl eines Werkzeugs.
Erstens: den Engpass benennen, nicht das Werkzeug. “Wir wollen KI im Einkauf” ist kein Anwendungsfall. “Wir binden 180.000 Euro in Ware, die länger als neun Monate liegt” ist einer. Aus dem zweiten Satz lässt sich ableiten, welche Daten gebraucht werden; aus dem ersten nicht.
Zweitens: prüfen, welche Daten dieser Engpass braucht. Für eine Nachfrageprognose sind das saubere Verkaufszahlen je Artikel über mehrere Quartale plus richtig datierte Retouren. Für Order-Routing sind es Bestände je Standort, Versandkosten und Auslastung. Diese Listen sind kurz, und sie sind sehr unterschiedlich. Es lohnt sich, sie aufzuschreiben, bevor man Angebote einholt.
Drittens: ein Erfolgsmaß festlegen, das vorher existiert. Prognosegenauigkeit, Fehlbestandstage, Lagerumschlag, Kosten je Bestellung — welche Kennzahl auch immer passt, sie muss vor dem Start gemessen worden sein. Sonst ist nach zwölf Monaten nicht entscheidbar, ob sich etwas verbessert hat. Dieselbe Systematik gilt für die Bewertung des Umstiegs insgesamt; wir haben sie beim Bruttowarenwert nach dem Plattformwechsel durchgespielt.
Viertens: mit einer Warengruppe anfangen. Nicht mit dem Sortiment. Eine Gruppe mit stabiler Nachfrage und überschaubarer Artikelzahl, gegen die bisherige Methode gerechnet, über ein Quartal. Das ist billig genug, um es abzubrechen.
Fünftens: den Widerspruch organisieren. Jede automatisierte Empfehlung braucht eine Stelle, an der ein Mensch sie überstimmen kann, und einen Schwellenwert, ab dem er es muss. Bei Bestellungen über einem bestimmten Betrag, bei Abweichungen über einem bestimmten Prozentsatz, bei Artikeln mit langer Wiederbeschaffungszeit. Ohne diese Regel entsteht entweder blindes Vertrauen oder — häufiger — stilles Ignorieren des ganzen Systems.
Wo Sie ansetzen, je nach Situation
| Ihre Situation | Der erste Handgriff |
|---|---|
| Migration in Planung | Artikelstamm-Bereinigung als eigenes Arbeitspaket in den Projektplan, nicht in die Datenübernahme |
| Mehrere Lager oder Filialen | Standortmodell vor dem Go-Live festlegen — nachträglich ist es eine Bestandskorrektur |
| Bestandsabgleich läuft nachts | Beim Schnittstellendesign klären, welche Bewegungen ereignisbasiert laufen müssen |
| Hohe Retourenquote | Retourendatierung in altem und neuem System vergleichen und die Verschiebung notieren |
| Einkauf plant nach Bauchwerten | Wiederbeschaffungszeiten je Lieferant einmalig erheben und im Stammsatz pflegen |
| Starke Aktionsspitzen im Jahr | Kampagnenkennzeichnung in die Migration aufnehmen, damit die Historie lesbar bleibt |
| Prognosewerkzeug bereits im Einsatz | Prüfen, auf welcher Historie es rechnet — und ob die den Systemwechsel überstanden hat |
| Wenige Artikel tragen den Großteil des Umsatzes | Mit genau diesen anfangen; dort ist der Effekt am größten und die Datenlage am besten |
Wenn die Daten aus mehreren Systemen zusammenlaufen sollen, statt einzeln angebunden zu werden, ist die Customer Data Platform der verwandte Baustein auf der Kundenseite — dieselbe Logik, andere Datenachse. Und wenn ein Standardwerkzeug den Fall nicht abbildet, hilft die Abwägung in Wann brauchen Sie eigene Shopify-Apps.
Checkliste
Datencheck vor dem Umschalten
Zehn Punkte, die vor dem Go-Live geklärt sein sollten, damit Ihre Lieferkettendaten später etwas tragen. Ihre Häkchen bleiben in diesem Browser gespeichert.
0 von 10 erledigt
Der Reiz an diesem Thema ist, dass es klingt wie eine Investitionsentscheidung, und in Wirklichkeit eine Aufräumentscheidung ist. Die Werkzeuge sind verfügbar, bezahlbar und ausreichend gut. Was fehlt, ist fast immer die Grundlage, auf der sie arbeiten sollen — und die entsteht nicht durch eine Anschaffung, sondern durch einige Wochen unspektakuläre Arbeit an Stammdaten und Schnittstellen.
Ein Plattformwechsel ist die einzige Gelegenheit, diese Arbeit zu machen, während sowieso alles offen liegt. Danach wird sie teuer, weil sie im laufenden Betrieb stattfinden muss.
Wenn Sie einen Umstieg vor sich haben und wissen wollen, welche Ihrer Lieferkettendaten die Systemgrenze in verwertbarem Zustand überstehen: Lassen Sie uns sprechen — wir sehen uns Artikelstamm, Bestandsführung und Schnittstellen an und sagen Ihnen, was davon vor dem Go-Live angefasst werden sollte.
