Slotting ist angewandte Ökonomie, nicht Lagerwissen
Warehouse slotting wird üblicherweise als ein Akt des gesunden Menschenverstandes dargestellt. Platziere die schnellen Artikel in der Nähe des Weges, halte zerbrechliche Güter fern von Gefahren und erschwere die Auffüllung nicht unnötig. All das ist zwar sinnvoll, aber keines davon reicht aus. Ein vorderer Pick Face ist ein knapper Vermögenswert, und jede Zuweisung dieses Vermögenswertes schließt eine anderweitige Nutzung derselben Arbeitskraft, desselben Raums und Bestands aus. Sobald dies deutlich wird, erscheint Slotting als das, was es ist: eine Abfolge wirtschaftlicher Entscheidungen, die im Lager getroffen werden. Die Kommissionierung zählt zudem zu den ressourcenintensivsten Aktivitäten im Lager, weshalb kleine Fehler bei der Platzierung sich in den Arbeitskosten so deutlich bemerkbar machen.
Ich habe die umfassendere Version dieses Arguments in Introduction to Supply Chain dargelegt, insbesondere in den Kapiteln 1, 5, 6 und 8. Supply chain Software sollte Datensätze verarbeiten, unter Unsicherheit schlussfolgern und Entscheidungen treffen, die anhand von Gewinn und Verlust beurteilt werden können, statt anhand prozeduraler Korrektheit. Slotting verdient dieselbe Behandlung. Ziel ist es, Kandidatenplatzierungen nach dem erwarteten wirtschaftlichen Ertrag zu bewerten, nachdem Reisezeit, Stau, Zerbrechlichkeit und Auffüllungsaufwand alle in Münzen bepreist wurden.
Reisezeit ist der offensichtliche Faktor in der Gleichung. Die Kommissionierung bindet Arbeitskraft, und die Lagerzuweisung interagiert eng mit der Routenplanung. Ein Standort, der den Weg für eine beliebte SKU verkürzt, kann die Route der gesamten Welle verlängern oder mehr Querverkehr in den falschen Gang zwingen. Die Reisezeit fließt in die Bewertung ein, aber die Gesamtrechnung ist umfangreicher. Wissenschaftliche Arbeiten zu Lagerzuweisung und Picker Routing haben die beiden Probleme aus gutem Grund als eng gekoppelt behandelt.
Stau gehört ebenso dazu. Dasselbe gilt für Zerbrechlichkeit. Ein Slotting-Plan kann unter durchschnittlicher Nachfrage einwandfrei wirken und sich im Bruchteil einer Sekunde auflösen, sobald einige stark nachgefragte Artikel gleichzeitig einen Ausschlag erleben, eine Auffüllung zu spät erfolgt oder zwei Gänge gleichzeitig gesättigt sind. Die Verluste äußern sich in Überstunden, manuellen Eingriffen, gehetzten Auffüllungen und verpassten Abfahrten. Es sind routinemäßige Verluste, keine spektakulären – genau deshalb blenden deterministische Planungen sie gerne aus. Jedes System, das Stau als nachträglichen Gedanken oder Zerbrechlichkeit als Pech betrachtet, lässt einfach Geld auf dem Tisch liegen.
Die Auffüllkosten schließen den Kreis. Jeder vordere Slot ist auch ein Versprechen zukünftiger interner Arbeit. Ein Standort, der Sekunden am Pick Face einspart und gleichzeitig die Anzahl der Auffüllberührungen verdoppelt, mag ein schlechter Handel sein. Oracle macht diesen Zusammenhang deutlich: Mit seiner Reslotting Workbench richtet es Standorte anhand von Item-Velocity-Rankings neu aus und generiert Auffüllaufgaben aus Diskrepanzen. Microsoft beschreibt eine ähnliche Kette über Einheitmaß-Tiers, Vorlagen, Direktiven und Auffüllaufgaben, sobald der Slotting-Plan festgelegt wurde. Beide Produktlinien erkennen die Kopplung an. Keine der öffentlichen Beschreibungen zeigt einen wirtschaftlichen Motor, der diese gekoppelte Effekte unter Unsicherheit bewertet.
Unsicherheit ist das ganze Problem. Die Bestellungen von morgen sind nicht bekannt. Ebenso wenig wie die Co-Picks, Gangkonflikte, Unterbrechungen bei der Auffüllung, Aufgabendauern oder Schadensfälle von morgen. Wenn ein Slotting-System auf Punktprognosen oder auf ABC-Klassen vertraut, als wären sie ausreichend, werden gerade die Ausschläge geglättet, die die Kosten verursachen. Der Durchschnitt ist eine höfliche Fiktion. Lager zahlen am Ende den Preis in den Extremen. Derselbe Fehler tritt überall in der supply chain auf: Eine Punktprognose führt zu präziser Arithmetik und schlechten Zusagen, weil sie die Form der Zukunft auslöscht.
Eine ordnungsgemäße Slotting-Engine benötigt daher probabilistische Prognosen – nicht nur des Nachfragevolumens, sondern auch der Bestellzusammensetzung, der Co-Picks, des Auffüllzeitpunkts und der Reibungsverluste bei der Arbeitskraft. Anschließend braucht sie eine Entscheidungsroutine, die diese Verteilungen tatsächlich verarbeitet und Bewegungen nach dem erwarteten, risikoangepassten Ertrag bewertet. Ich habe wenig Geduld mit dieser Fachsprache. “Stochastische Optimierung” ist eine passende Bezeichnung. Die Substanz ist einfacher als der Ausdruck: Verteilungen gehen hinein, wirtschaftlich bewertete Bewegungen kommen heraus. Sobald die Unsicherheit aus der Problemstellung entfernt wird, erscheint das Wort “Optimierung” als bloß dekorativ.
Was die Software tatsächlich macht
Sobald dieser Mindeststandard übernommen wird, wird die Marktsprache in vielen Bereichen leichter verständlich. SAP EWM beschreibt Slotting als die Bestimmung von Lagerparametern, die in den Produktstamm zurückgeschrieben werden, wobei Zustandsdatensätze das Ergebnis steuern. Die Machine-Learning-Variante von SAP wird als ein Weg beschrieben, Slotting-Regeln automatisch aus der Lagerkonfiguration und den Produktstammdaten abzuleiten. Das mag den Einrichtungsaufwand reduzieren. Es liest sich jedoch immer noch wie die Regelgenerierung für ein Master-Daten-System, nicht wie ein probabilistischer Optimierer, der die nächstbeste Nutzung eines knappen Pick Faces ermittelt.
Oracle ist ebenso explizit. Sein aktuelles Material konzentriert sich auf Item-Velocity-Rankings, Diskrepanzen in der Rangfolge, KPI-Anzeigen, Filterung, Sortierung und die Generierung von Auffüllaufgaben. Microsoft dreht sich um Nachfragekonsolidierung, Vorlagelinien, Direktivcodes und Auffüllstrategien wie Wellen-Nachfragemengen und maximale Standortkapazitäten. Dies sind Werkzeuge zur Aufrechterhaltung eines Slotting-Regimes. Es handelt sich nicht um Darlegungen feingranularer stochastischer Abwägungen zwischen konkurrierenden Platzierungen.
Die fortschrittlicheren Lageranbieter verdienen eine differenziertere Betrachtung. Manhattan spricht von einem relativen Wert für jede potenzielle Platzierung und vom Vergleich von Millionen von Bewegungsmöglichkeiten unter benutzerkonfigurierten Strategien. Blue Yonder spricht von Nachfragesignalen, Reiswegen, kontinuierlicher Optimierung, Bewegungen mit höchstem Wert und der Integration mit Auffüll- und Arbeitsplanung. Lucas spricht von machine-learning Empfehlungen, die auf SKU-Velocity, Affinität, Pick-Pfaden, prognostizierten Aufgabenzeiten und rückzahlungsorientierten Bewegungen beruhen. Dies kommt der Realität näher. Zumindest erkennt die Sprache ein Ranking an, statt bloßer Dateneingabe.
Dennoch hören die öffentlichen Beschreibungen dort auf, wo der schwierige Teil beginnt. Auf den von mir geprüften Seiten erklärt keiner dieser Anbieter die Wahrscheinlichkeitsverteilungen, die die Slotting-Entscheidung antreiben, das wirtschaftliche Ziel, mit dem Reisezeit gegen Stau und Auffüllung abgewogen wird, oder die Art und Weise, wie Zerbrechlichkeit bestraft wird. Blue Yonder bewirbt probabilistische Prognosen an anderer Stelle in seiner Planungssuite, was ein nützliches Signal technischer Kompetenz ist, aber seine Slotting-Seite gibt nicht preis, ob diese Verteilungen in die Slotting-Engine integriert sind. Öffentliche Belege sind das, was ein Käufer vor dem Ende des Verkaufszyklus einsehen kann, und das ist der Maßstab, den ich anlege.
Das Gerede von “Millionen” oder “Milliarden” verdient wenig Ehrfurcht. Die Anzahl potenzieller Bewegungen sagt fast nichts über die Entscheidungsqualität aus. Der schwierige Teil besteht nicht darin, Möglichkeiten aufzuzählen, sondern darin, jeder Möglichkeit unter Unsicherheit einen fundierten wirtschaftlichen Wert zuzuordnen. Ein Suchraum ist billig. Ein korrektes Ranking ist teuer. Wenn das Marketing mit der Größe des Suchraums oder mit Schlagworten wie “Milliarden von Entscheidungen” aufwartet, heißt das in der Regel, dass die Bewertung weitaus schwerer zu erklären ist.
Das technische Indiz
Es gibt einen weiteren Hinweis, der älter ist als der aktuelle AI-Trend. Wenn ein Produkt um Formulare, Stammdaten, Workflows, Vorlagelinien und tägliche Bestätigungen organisiert ist, verkündet es seine Herkunft. Es ist in erster Linie ein Hauptbuch. Das ist das richtige Design, um Bestandsbewegungen aufzuzeichnen, jedoch nicht der geeignete Schwerpunkt für anspruchsvolle numerische Suchen. Seit Jahren behaupte ich, dass umfangreiche Optimierung nicht im Hauptbuch angesiedelt sein sollte, weil Systeme zur Aufzeichnung und Systeme der Intelligenz die Architektur in entgegengesetzte Richtungen ziehen. Das Indiz zeigt sich in den öffentlichen Materialien selbst: Produktstamm-Aktualisierungen, Zustandsdatensätze, durchsuchbare Workbenches, KPI-Ansichten, Vorlagen, Direktiven und bürokratische Einrichtungsobjekte allenthalben.
Könnte ein Anbieter einen ernsthaften Optimierer an einen relationalen, CRUD-schweren Kern anhängen? Theoretisch ja. In der Praxis fast nie. Die Datenbank gewinnt, die Formulare vervielfachen sich und der Optimierer wird zu einem dekorativen Anbau. SAP HANA ist eine relationale Datenbank, die darauf ausgelegt ist, Transaktionen und Analysen gemeinsam auszuführen. Manhattan Active läuft auf Cloud SQL for MySQL. Beide Technologien sind als transaktionale Substrate respektabel. Ihre Präsenz zeigt mir, dass ein großer Teil des Entwicklungsaufwands in erster Linie in der transaktionalen Zuverlässigkeit verankert ist. Das schränkt stark ein, was ich bereit bin zu glauben, wenn dieselbe Produktfamilie später autonome Optimierung beansprucht, ohne die Entscheidungslogik offen zu legen.
Die öffentlichen Materialien lesen sich dementsprechend. SAP schreibt Slotting-Ergebnisse in den Produktstamm. Oracle stellt eine Workbench-UI mit durchsuchbaren Feldern und KPI-Ansichten in den Vordergrund. Microsoft dreht sich um Vorlagen, Direktiven und Auffüllstrategien. Manhattans öffentliche WMS-Geschichte betont eine cloud-native Microservices-Plattform, während ein Google Cloud-Fall die gleiche Active-Familie beschreibt, die auf Cloud SQL for MySQL läuft. Nichts davon macht die Software unbrauchbar. Es erklärt, warum so viele Enterprise-Produkte in der Dateneingabe und Prozesseinhaltung brillieren, während sie nur wenig über die feingranulare Logik aussagen, welche den knappen Vermögenswert tatsächlich allokiert.
Umfassendere Planungssuiten umgehen in der Regel die Frage des Pick Faces vollständig. RELEX betont öffentlich machine-learning Prognosen, probabilistische Planung für Auffüllungen und KI-gesteuerte Planogramme. Kinaxis legt den Fokus auf Orchestrierung, Szenarioanalysen, Bestandsanalysen und Dashboards. o9 hebt AI/ML-Prognosen und eine End-to-End-Planungsplattform mit Schlagworten zu synchronisierten, optimierten Entscheidungen hervor. Diese Fähigkeiten mögen in ihren jeweiligen Domänen wertvoll sein. Sie entsprechen jedoch – nach den von mir geprüften öffentlichen Aufzeichnungen – nicht einer Warehouse slotting Engine, die einzelne Platzierungen nach stochastischem wirtschaftlichem Ertrag bewertet.
Was würde mich überzeugen? Wenig Aufhebens, um es zunächst mal ganz einfach auszudrücken. Ich würde nach Verteilungen statt nach Punktwerten suchen, nach expliziten wirtschaftlichen Strafen statt nach KPI-Stellvertretern, nach einem Entscheidungsprotokoll, das zeigt, warum eine Bewegung eine andere übertroffen hat, und nach einer Engine, die Aktionen ausgibt, die nur wenig einer bürokratischen Nachbearbeitung bedürfen. Die Software sollte unmissverständlich darlegen, welche Unsicherheiten modelliert, welche bepreist und welche außer Betracht gelassen werden. Fehlt dies, ist “AI-powered slotting” in der Regel nur ein Empfehlungsscreen mit besserem Branding.
Slotting verdient die gleiche Ernsthaftigkeit wie Preisgestaltung, Einkauf und Bestandsallokation. Ein Pick Face ist Kapital in physischer Form. Die Frage ist, wer heute dieses Kapital erhält und welche Optionen verloren gehen, wenn es gebunden wird. Diese Frage gehört zur Ökonomie unter Unsicherheit. Alles andere schmückt lediglich die bürokratische Hülle darum herum.
