Eine Rezension von "How Generative AI Improves Supply Chain Management"

Joannes Vermorel

Das Harvard Business Review hat als Teil der Januar-Februar 2025 Ausgabe kürzlich How Generative AI Improves Supply Chain Management¹ von Ishai Menache (Microsoft), Jeevan Pathuri (Microsoft), David Simchi-Levi (Professor, MIT) und Tom Linton (McKinsey) veröffentlicht. Wie der Titel andeutet, liefert der Artikel eine Reihe von Beispielen, die angeblich veranschaulichen, wie LLMs (large language models) zur supply chain management beitragen können. Angesichts der Liste der angesehenen Organisationen (Microsoft, McKinsey, MIT und sogar Harvard), die an der Veröffentlichung dieses Beitrags beteiligt waren, könnte man tiefgehende, aufschlussreiche Ansichten erwarten – solche, die sorgfältig darlegen, wie ein brillantes Technologieprodukt – LLMs – zur Verbesserung von supply chains beiträgt.

Stattdessen erhalten wir einen mittelmäßigen Beitrag. Genauer gesagt: er ist faul, überspitzt und zutiefst fehlgeleitet – ein Beitrag, der zufällig auf einem technologischen Buzzword aufspringt. Das gesamte Grundprinzip des Artikels lässt sich zusammenfassen als LLMs können sowohl Code von supply chain Relevanz generieren als auch erklären. Die Autoren verfolgen, was ich normalerweise als eine gadgetoid Herangehensweise an das Thema bezeichne. Dieser gadgetoid Ansatz besteht darin, bei der Entdeckung eines neuartigen Technologieprodukts das Teil übereilt an ein bestehendes System anzudocken. Dies geschieht typischerweise ohne jegliche Berücksichtigung der Limitierungen des Produkts oder der Änderungen, die am System vorgenommen würden. Infolgedessen produziert dieser Ansatz zwangsläufig Gadgets – amüsante Werkzeuge von begrenztem Interesse – und keinerlei geschäftlichen Mehrwert.

An die beteiligten Organisationen:

• Microsoft: Ihr habt viele talentierte Ingenieure an Bord. Ihr müsst euch an höhere Standards halten.

• McKinsey: Leitet potenzielle Kunden nicht in Richtungen, die garantiert Zeit- und Geldverschwendung sind.

• MIT und Harvard: Ihr solltet vernünftige Stimmen sein und nicht den Unsinn von Tech-Anbietern verstärken.

Lasst uns sofort klarstellen, dass, obwohl ich zustimme, dass LLMs zur Verbesserung von supply chains eingesetzt werden können, LLMs auch eine völlige Ablenkung sein können – je nachdem, wie das Vorhaben angegangen wird. Dieser Punkt ist genau das grundlegende Problem, das den rezensierten Artikel plagt. Ein eng verwandtes Papier von Microsoft² leidet ebenfalls unter diesem Problem; wenn auch der Klarheit halber wird sich meine Rezension auf den Harvard-Artikel konzentrieren.

Bevor wir uns dem grundlegenden technologischen Unsinn zuwenden, wollen wir auf ein bemerkenswertes ethisches Problem hinweisen. Dieser Artikel ist nichts anderes als ein kaum verschleiertes Werbestück für Microsoft Cloud Supply Chain. Microsoft steht es natürlich frei, seine Dienstleistungen in jeder gewünschten Form zu bewerben, aber Harvard (durch Veröffentlichung) und MIT (als Co-Autoren) in ein Promotionsstück einzubinden, stört mich. Mindestens sollte der Artikel darauf hinweisen, dass die Co-Autoren offensichtliche Interessenkonflikte haben. Die Wissenschaft sollte keine verdeckte Werbeaktivität von Tech-Anbietern dulden, egal wie groß und einflussreich sie sind.

Hinweis: Der aufmerksame Leser wird bemerkt haben, dass auch ich einen Interessenkonflikt habe. Ja, ich betreibe ein supply chain Softwareunternehmen und habe daher ein berechtigtes Interesse daran, dem Unsinn, den Microsoft, McKinsey, MIT und Harvard verbreiten, entgegenzuwirken. Meine Karten liegen nun offen auf dem Tisch.

Lasst uns nun mit der Rezension der vom Artikel aufgestellten Behauptungen fortfahren.

Planer überwachen auch monatlich Änderungen im Bedarfsplan, genannt demand drift, um sicherzustellen, dass der überarbeitete Plan alle Kundenanforderungen erfüllt und im Rahmen der Budgetvorgaben bleibt […] LLM-basierte Technologie übernimmt nun all dies. Sie erstellt automatisch einen E-Mail-Bericht, in dem detailliert aufgeführt wird, wer welche Änderung vorgenommen hat und warum.

Zusammengefasst können LLMs Mitarbeiter bei Routinearbeiten automatisieren. Es gibt jedoch zwei offensichtliche Einwände. Erstens, LLMs sind völlig unnötig, um derartige rollenbasierte Vorgaben umzusetzen. Eine einfache Programmiersprache und ein paar imperative Anweisungen genügen. Außerdem wird ohnehin eine programmatische Infrastruktur benötigt, um auf die Daten zuzugreifen und die E-Mail zu versenden. In diesen Fällen stellen LLMs mit Sicherheit eine massenhafte technische Komplikation dar, die keinen greifbaren Nutzen liefert. Tatsächlich sind LLMs sehr langsam und sehr kostspielig; etwa 10 Größenordnungen schlechter als eine kurze Liste von Regeln. Sie sind ein Werkzeug, das nur als letztes Mittel eingesetzt werden sollte, wenn alles andere versagt hat. Dies ist hier eindeutig nicht der Fall.

Zweitens, die oben angesprochene Routinearbeit ist völlig überflüssig. Das Unternehmen sollte diese Art von sinnlosen Aufgaben³ eliminieren. Bürokratien sind schon schlimm genug, aber Technokratien sind schlimmer. Die Einführung überkomplizierter Technologien garantiert, dass die Bürokratie in ihren dysfunktionalen Mustern weiter verfestigt wird. Lokad, mein Unternehmen, beseitigt solche Routinearbeiten seit mehr als einem Jahrzehnt, und das erfordert keineswegs etwas so Kompliziertes und Kostspieliges wie LLMs.

Diese Verträge legen die Details des vom OEM gezahlten Preises, Qualitätsanforderungen, Lieferzeiten und die Resilienzmaßnahmen fest, die Lieferanten ergreifen müssen, um die Versorgung sicherzustellen. Nachdem dem LLM Daten aus Tausenden von Verträgen zugeführt worden waren, konnte ein OEM Preissenkungen identifizieren, auf die er Anspruch hatte, wenn ein bestimmter Volumenschwellenwert überschritten wurde.

Obwohl es zutrifft, dass Unternehmen routinemäßig dabei scheitern, einige der vertraglichen Klauseln gegenüber ihren Lieferanten anzuwenden, die ihnen zugutekommen würden, stellt das Identifizieren der relevanten Vertragsbedingungen nur einen mikroskopisch kleinen Teil der Herausforderung dar – sagen wir 1% oder möglicherweise noch weniger. Darüber hinaus kann dies mit einem Werkzeug wie ChatGPT ohne jegliche Vorbereitung bewältigt werden. Alles, was es braucht, ist, eine Anfrage zu formulieren und die PDFs wiederholt über die Benutzeroberfläche hochzuladen. Solcherlei Trivia gehört eher zu einem LinkedIn-Beitrag mit dem Titel “The 10 things I did with ChatGPT today” und nicht zu einer Harvard-MIT-Publikation.

Nun, die eigentliche Herausforderung ist zweifach: Instrumentierung und Beziehung. Auf der Seite der Instrumentierung sind die administrativen Schritte zur Auslösung von Bestellungen und Zahlungen in den meisten Unternehmen, die etwas betreiben, das als “supply chain” qualifiziert, weitgehend automatisiert. Daher wird es, sofern keine umfassende unterstützende Instrumentierung vorhanden ist, die Behandlung von Randfällen verkomplizieren und alles verzögern.

Zudem, auf der Beziehungsebene, wenn eine vertragliche Klausel über Jahre hinweg ignoriert wurde, ist es naiv zu glauben, dass das Unternehmen die Klausel ohne Konsequenzen aktivieren kann. Häufig hat der Lieferant dieses nachlässige Verhalten des Kunden bereits in seine Preise eingepreist, und das Herumfeilen an Randklauseln wird mit gleicher Münze zurückgezahlt – oder möglicherweise mit einer Preiserhöhung.

Allgemeiner sollten Rabatte und Preisnachlässe als Teil der regulären transaktionalen Geschäftssysteme verwaltet werden. Das ist keine Raketenwissenschaft, sondern schlichtes altes CRUD⁴. Noch einmal, einen LLM einzusetzen, wo ein paar imperative Regeln ausreichen würden, ist technologisch unsinnig.

Ein LLM ermöglicht es Planern, detaillierte Fragen zu stellen. Hier einige Beispiele: “Was wären die zusätzlichen Transportkosten, wenn die gesamte Produktnachfrage um 15% steigen würde?” […] So kann ein LLM Fragen wie diese präzise und effizient beantworten. Viele Optimierungsaufgaben werden in Form von mathematischen Programmen formuliert […] Ein LLM […] übersetzt eine menschliche Anfrage in einen mathematischen Code, der eine kleine Änderung am ursprünglichen mathematischen Modell darstellt, das zur Erstellung des Plans verwendet wurde.

Das ist Wunschdenken. Bis heute ist der Prozentsatz der Unternehmen, die über eine “unified monolithic codebase” zur Ableitung ihrer supply chain decisions verfügen, nahezu null (mehr dazu unten). Stattdessen verfügen die Unternehmen über einen Ozean von Tabellenkalkulationen. Anders als das schöne Bild, das die Autoren zeichnen, gibt es keine “mathematischen Programme”, mit denen die LLMs interagieren könnten. Zwar könnten LLMs konzeptionell ein chaotisches Bündel halb veralteter Tabellenkalkulationen bearbeiten und verbessern, doch bis das Gegenteil bewiesen ist, bleibt dies reine Spekulation. Selbst modernste LLMs hätten Schwierigkeiten, eine einzige große Tabelle zu bearbeiten – die passive Code-Duplizierung, die Tabellenkalkulationen mit sich bringen, ist für LLMs überhaupt nicht förderlich – aber das Verarbeiten von Hunderten, wenn nicht Tausenden von Blättern bleibt vorerst reine Science-Fiction.

Nun, es gibt in der Tat einige wenige Unternehmen, die von einer unified monolithic codebase profitieren, die Entscheidungsprozesse im Bereich supply chain steuert – nämlich die Kunden von Lokad. Hätten die Autoren, wie wir, tatsächlich jegliche Erfahrung in diesem Bereich, wüssten sie, dass diese Codebasen enorm sind; typischerweise umfassen sie zehntausende von Codezeilen, obwohl wir eine DSL (domain-specific language)⁵ verwenden, die speziell für supply chain entwickelt wurde. Übrigens ist diese DSL etwa 10-fach prägnanter als Python oder Java für diese Art von Aufgabe. Leider gibt es keinen Trick: Für jede relevante Entscheidung sind Dutzende von Tabellen, die Hunderte von Feldern abdecken, an der Berechnung beteiligt. So sehr es denkbar ist, dass weitere Verbesserungen unserer DSL die Anzahl der Codezeilen weiter reduzieren könnten, diese Codebasen werden niemals klein sein.

Nochmal: LLMs könnten konzeptionell eine komplexe Codebasis bearbeiten und verbessern, wenn sie von einem nicht-technischen Mitwirkenden gesteuert werden. Allerdings bewegen wir uns damit wieder im Bereich Science-Fiction. LLMs haben sich bereits als fantastische Produktivitätswerkzeuge für kompetente Programmierer erwiesen. Anders ausgedrückt, wenn man bereits programmieren kann, helfen LLMs, schneller zu programmieren. Doch genau das behaupten die Autoren des Artikels nicht. Ihre These lautet vielmehr, dass LLMs eingesetzt werden können, um nicht-technischen Mitarbeitern technische Beiträge leisten zu lassen. Basierend auf dem aktuellen Stand der LLM-Technologie ist diese These durchweg falsch, außer in winzigen Sandkästen, die nicht die immense, allgegenwärtige Komplexität realer supply chains widerspiegeln.

Planer können LLM-Technologie nutzen, um die mathematischen Modelle der Struktur einer supply chain und die Geschäftsanforderungen an die aktuelle Geschäftsumgebung anzupassen. Weiterhin kann ein LLM die Planer über Änderungen der Geschäftsbedingungen informieren.

Die Autoren bestehen weiterhin auf Science-Fiction. Diese Behauptung ist technisch nicht von der Aussage zu unterscheiden, dass “ein LLM Patches an ein Code-Repository auf GitHub auslösen kann, basierend auf von nicht-technischen Nutzern eingereichten Tickets”. Es wären fantastische Neuigkeiten, wenn das möglich wäre, aber auch die heutigen LLMs sind bei Weitem nicht in der Lage, eine derartige Leistung zuverlässig für ernsthafte Anfragen zu erbringen. Wenn man Anwendungsfälle für eine neuartige Technologie präsentiert, ist es entscheidend, die Grenzen dieser Technologie präzise zu vermitteln. Die vier Co-Autoren scheinen völlig unachtsam gegenüber dem aktuellen Stand der LLM-Technologie zu sein; allerdings habe ich so meine Vermutung, dass dem nicht so ist. Stattdessen erhalten wir Werbegetue von Personen, die sich ihrer Handlungen sehr bewusst sind – was wohl noch viel schlimmer ist.

Der Bedarf, den Versorgungsplan zu ändern, könnte auch durch LLM-basierte Technologie getrieben werden. Zum Beispiel kann es nach der Analyse von Versanddaten eines bestimmten Lieferanten einen Alarm auslösen, dass sich die Lieferzeit des Lieferanten in den letzten Monaten signifikant erhöht hat.

Das Erkennen, ob eine lead time abnormal ist, gehört absolut nicht zu den Fähigkeiten eines LLM. Ein LLM kann jedoch angeregt werden, ein Stück Code zu schreiben, um diese Analyse durchzuführen. Wir sind zurück beim LinkedIn-Beitrag “Top 10 things I did with ChatGPT today”. Warum dabei aufhören und nicht direkt die Bestelllogik aktualisieren, in der die Lieferzeitinformationen verwendet werden? Genau das schlagen die Autoren später im Artikel vor.

Wir stellen uns vor, dass in den nächsten Jahren LLM-basierte Technologie End-to-End-Entscheidungsszenarien unterstützen wird.

Wenn mit unterstützen gemeint wäre, die Programmierer produktiver zu machen – wobei diese Programmierer für das Codieren von End-to-End-Entscheidungen verantwortlich sind – dann ist dies bereits möglich – tatsächlich ist es etwas, das Lokad schon seit einiger Zeit tut. Entfernt man jedoch die menschlichen Programmierer aus dem Bild, wird diese Aussage eher zu “Wir stellen uns vor, dass in den nächsten Jahren LLM-basierte Technologien AGI (artificial general intelligence) erreichen werden”.

Die Autoren, die stark auf dem Buzzword “Gen AI” reiten, ignorieren völlig, dass LLMs möglicherweise eigene Einschränkungen haben. Hier ist, was die Autoren in ihrem abschließenden Abschnitt “Overcoming Barriers” vorbringen:

Einführung und Schulung. Die Nutzung eines LLM zur Optimierung von supply chains erfordert eine sehr präzise Sprache […] Jede Interpretation führt zu unterschiedlichen Entscheidungen.

Nein, das ist schlichtweg falsch – es sei denn, “sehr präzise Sprache” wird als “Programmiersprache” verstanden (da diese de facto sehr präzise sind). Um eine supply chain mithilfe eines LLM zu optimieren, benötigt man einen menschlichen Ingenieur, der in der Lage ist, den Code vollständig eigenständig zu schreiben, wenn auch langsamer. In absehbarer Zukunft wird durch keine Trainingsmaßnahme – außer der Beherrschung von Programmierung – der Nutzer in die Lage versetzt, supply chain Optimierungen mit Unterstützung von LLMs durchzuführen.

Dem CEO oder dem supply chain Director zu sagen, dass er lediglich sein Team darin schulen muss, eine “präzise Sprache” zu verwenden, ist völlig irreführend. Die Art von Trainingsworkshops, die aus dieser Sichtweise resultieren würden, sind garantiert eine komplette Zeitverschwendung für alle Beteiligten.

Verifikation. LLM-Technologie kann gelegentlich ein falsches Ergebnis liefern. Daher besteht eine allgemeine Herausforderung darin, die Technologie “innerhalb der Schienen” zu halten – nämlich Fehler zu identifizieren und zu beheben.

Auch wenn LLMs von Haus aus probabilistisch sind, wird dieses Problem durch die semantische Unsicherheit in supply chain Systemen in den Schatten gestellt. Anders ausgedrückt: Es ist sehr wahrscheinlich, dass ein LLM die richtige Antwort auf das falsche Problem liefert. Die Erfahrung von Lokad zeigt, dass oft der einzige Weg, zu überprüfen, ob eine gegebene Implementierung (die eine supply chain Entscheidung steuert) korrekt ist, darin besteht, einen begrenzten Experimentier-Test durchzuführen⁶. Rückmeldungen aus der realen Welt sind keine Option. Wissen kann nicht aus dem Nichts heraufbeschworen werden – selbst LLMs auf AGI-Niveau stünden vor diesem Hindernis.

Hier tappen die Autoren in das Ausfüllen. Sie machen eine korrekte – wenn auch triviale – Aussage über die Natur von LLMs, ohne auch nur zu versuchen, zu ermitteln, ob das Problem eine Kernfrage darstellt oder nicht. Hätten die Autoren tatsächlich reale supply chains mit LLMs gemanagt, hätten sie, wie wir, erkannt, dass dieses Problem nur ein kleines Problem in einer langen Liste von viel größeren – und wesentlich einflussreicheren – Problemen ist.

Abschließend gilt Brandolinis Gesetz: Die Menge an Energie, die benötigt wird, um Bullshit zu widerlegen, ist um eine Größenordnung größer als diejenige, die erforderlich ist, um ihn zu produzieren. Dieser Artikel ist so schlecht, dass er von ChatGPT geschrieben worden sein könnte – und vielleicht wurde er es, wer weiß es. Basierend auf meinen beiläufigen Beobachtungen werden täglich Dutzende ebenso schlechter Artikel über Gen-AI und SCM produziert. Die Bekanntheit der Autoren veranlasste mich, diese Überprüfung zusammenzustellen. Betrachtet man das Ganze, ist es nicht das erste Mal, dass ein Anbieter verspricht, einen Bereich zu revolutionieren, obwohl er nichts Substanzielles zu bieten hat. Doch wenn derselbe Anbieter dies zweimal⁷ in zwei aufeinanderfolgenden Jahren innerhalb desselben Bereichs macht, mag das übertrieben sein. Andererseits sollte die Wissenschaft zumindest versuchen, kritisch zu denken, anstatt fröhlich auf den Buzzword-Zug aufzuspringen.