Eine Überprüfung von "Wie generative KI die Supply Chain verbessert"

Joannes Vermorel

Die Harvard Business Review hat kürzlich im Rahmen ihrer Ausgabe von Januar-Februar 2025 Wie generative KI die Supply Chain verbessert¹ von Ishai Menache (Microsoft), Jeevan Pathuri (Microsoft), David Simchi-Levi (Professor, MIT) und Tom Linton (McKinsey) veröffentlicht. Wie der Titel vermuten lässt, liefert der Artikel eine Reihe von Beispielen, die angeblich veranschaulichen, wie LLMs (große Sprachmodelle) zur Supply Chain Management beitragen können. Angesichts der Liste der Eliteorganisationen (Microsoft, McKinsey, MIT und sogar Harvard), die an der Veröffentlichung dieses Artikels beteiligt sind, könnte man einige tiefgreifende Einblicke erwarten - die Art von Einblicken, die sorgfältig darlegen, wie ein brillantes Stück Technologie - LLMs - zur Verbesserung der Lieferketten beitragen wird.

Stattdessen erhalten wir einen mittelmäßigen Beitrag. Genauer gesagt ist er faul, übertrieben und zutiefst fehlgeleitet - ein Stück, das zufällig auf einem technologischen Schlagwort reitet. Die gesamte Prämisse des Artikels kann wie folgt zusammengefasst werden: LLMs können sowohl Code von relevanter Supply Chain generieren als auch erklären. Die Autoren nehmen dabei eine sogenannte Gadgetoid-Sichtweise auf das Thema ein. Die Gadgetoid-Sichtweise besteht darin, bei der Entdeckung eines neuen technischen Geräts dieses hastig an ein bestehendes System anzubringen. Dies geschieht in der Regel ohne jegliche Berücksichtigung der Einschränkungen des Geräts oder der Änderungen, die das System mit sich bringen würde. Das Ergebnis ist, dass dieser Ansatz unweigerlich Gadgets hervorbringt - amüsante Werkzeuge von begrenztem Interesse - und keinerlei Geschäftswert.

An die verschiedenen beteiligten Organisationen:

• Microsoft: Sie haben viele talentierte Ingenieure an Bord. Sie sollten sich an höhere Standards halten.

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

• MIT und Harvard: Sie sollten Stimmen der Vernunft sein und nicht den Unsinn von Technologieanbietern verstärken.

Lassen Sie uns sofort klären, dass ich zwar zustimme, dass LLMs zur Verbesserung der Lieferketten eingesetzt werden können, sie aber auch eine vollständige Ablenkung sein können - je nachdem, wie das Vorhaben angegangen wird. Dieser Punkt ist genau das grundlegende Problem, das den zu überprüfenden Artikel plagt. Ein eng verwandter Artikel von Microsoft² leidet ebenfalls unter diesem Problem; jedoch wird sich meine Überprüfung der Klarheit halber auf den Harvard-Artikel konzentrieren.

Bevor wir uns mit dem Kern der technologischen Unsinnigkeiten befassen, wollen wir auf ein bemerkenswertes ethisches Problem hinweisen. Dieser Artikel ist nichts weiter als ein dünn verschleierter Werbeartikel für Microsoft Cloud Supply Chain. Microsoft ist natürlich frei, seine Dienste auf jede Art und Weise zu bewerben, die es für angemessen hält, aber die Einbindung von Harvard (über die Veröffentlichung) und MIT (über die Mitautorenschaft) in einen Werbeartikel stößt bei mir auf Widerstand. Zumindest sollte der Artikel darauf hinweisen, dass die Mitautoren offensichtliche Interessenkonflikte haben. Die Akademie sollte keine verdeckte Werbeaktivität von Technologieanbietern billigen, egal wie groß und einflussreich sie auch sein mögen.

Haftungsausschluss: Der aufmerksame Leser wird erkannt haben, dass auch ich einen Interessenkonflikt habe. Ja, ich leite ein Unternehmen für Supply Chain Software und habe daher ein persönliches Interesse daran, dem Unsinn entgegenzuwirken, den Microsoft, McKinsey, MIT und Harvard verbreiten. Meine Karten liegen jetzt auf dem Tisch.

Lassen Sie uns nun mit einer Überprüfung der in dem Artikel gemachten Behauptungen fortfahren.

Planer überwachen auch monatlich Änderungen im Bedarfsplan, die als Bedarfsdrift bezeichnet werden, um sicherzustellen, dass der überarbeitete Plan alle Kundenanforderungen erfüllt und innerhalb der Budgetrichtlinien liegt […] Die auf LLM-Technologie basierende Technologie erledigt dies jetzt automatisch. Sie generiert automatisch einen E-Mail-Bericht, der angibt, wer welche Änderung vorgenommen hat und aus welchem Grund.

Kurz gesagt können LLMs Mitarbeiter bei Routinearbeiten automatisieren. Es gibt jedoch zwei offensichtliche Einwände. Erstens sind LLMs für die Ausführung dieser Art von rollenbasierter Richtlinie völlig unnötig. Eine einfache Programmiersprache und einige imperative Anweisungen reichen aus. Darüber hinaus wird sowieso programmatische Verbindungen benötigt, um auf die Daten zuzugreifen und die E-Mail zu senden. In solchen Situationen stellen LLMs garantiert eine massive technische Komplikation dar, die keine greifbaren Vorteile bietet. Tatsächlich sind LLMs sehr langsam und sehr teuer; etwa 10 Größenordnungen schlechter als eine kurze Liste von Regeln. Sie sind ein Werkzeug, das als letzter Ausweg verwendet werden sollte, wenn alles andere fehlgeschlagen ist. Dies ist hier eindeutig nicht der Fall.

Zweitens ist die oben genannte Routinearbeit völlig unnötig. Das Unternehmen sollte diese Art von sinnlosen Aufgaben[^Bürokratien] eliminieren. Bürokratien sind schon schlimm genug, aber Technokratien sind schlimmer. Wenn überkomplizierte Technologien mitgebracht werden, ist garantiert, dass die Bürokratie in ihren dysfunktionalen Wegen weiter verankert wird. Lokad, mein Unternehmen, hat diese Art von Routinearbeit seit mehr als einem Jahrzehnt umstrukturiert und benötigt nichts so Kompliziertes und Kostenintensives wie LLMs.

Diese Verträge legen die Einzelheiten des vom OEM gezahlten Preises, die Qualitätsanforderungen, die Lieferzeiten und die Widerstandsfähigkeitsmaßnahmen fest, die die Lieferanten ergreifen müssen, um die Lieferung sicherzustellen. Nachdem die LLM-Daten aus Tausenden von Verträgen eingespeist wurden, konnte ein OEM Preisnachlässe identifizieren, auf die er Anspruch hatte, weil er eine bestimmte Volumenschwelle überschritten hatte.

Es ist zwar wahr, dass Unternehmen routinemäßig daran scheitern, einige der vertraglichen Klauseln mit ihren Lieferanten anzuwenden, die ihnen zugute kommen würden, aber die Identifizierung der relevanten vertraglichen Bestimmungen ist nur ein winziger Teil der Herausforderung - sagen wir 1% oder möglicherweise noch weniger. Darüber hinaus kann dies mit einem Tool wie ChatGPT ohne jegliche Vorbereitung angegangen werden. Alles, was erforderlich ist, ist das Verfassen einer Abfrage und das wiederholte Einreichen aller PDFs über die Benutzeroberfläche. Diese Art von Trivia gehört zu einem LinkedIn-Beitrag mit dem Titel “Die 10 Dinge, die ich heute mit ChatGPT gemacht habe” und nicht zu einer Harvard-MIT-Veröffentlichung.

Nun, die eigentliche Herausforderung besteht aus zwei Teilen: Instrumentierung und Beziehung. Auf der Instrumentierungsseite sind die bürokratischen Schritte zur Ausgabe von Bestellungen und Zahlungen in den meisten Unternehmen, die etwas haben, das als “Supply Chain” qualifiziert, weitgehend automatisiert. Daher wird die Bewältigung von Randfällen ohne umfangreiche unterstützende Instrumentierung alles komplizieren und verzögern.

Darüber hinaus ist es naiv zu glauben, dass das Unternehmen eine vertragliche Klausel aktivieren kann, die jahrelang ignoriert wurde, ohne Konsequenzen. Oftmals hat der Lieferant dieses nachlässige Verhalten des Kunden bereits in seine Preise integriert, und das Herumkritteln an Randvertragsbedingungen wird entsprechend beantwortet - möglicherweise durch eine Preiserhöhung.

Im Allgemeinen sollten Rabatte und Preisnachlässe als Teil der regulären transaktionalen Geschäftssysteme verwaltet werden. Dies ist keine Raketenwissenschaft, sondern einfaches CRUD[^CRUD]. Nochmals, die Einführung eines LLMs, wo einige imperative Regeln ausreichen würden, ist technologisch unsinnig.

Ein LLM ermöglicht es Planern, detaillierte Fragen zu stellen. Hier sind ein paar Beispiele: “Wie hoch wären die zusätzlichen Transportkosten, wenn die Gesamtnachfrage nach Produkten um 15% steigen würde?” […] So kann ein LLM solche Fragen genau und effizient beantworten. Viele Optimierungsaufgaben werden in Form von mathematischen Programmen geschrieben […] Ein LLM […] übersetzt eine menschliche Abfrage in einen mathematischen Code, der eine kleine Änderung am ursprünglichen mathematischen Modell darstellt, das zur Erstellung des Plans verwendet wurde.

Dies ist Wunschdenken. Bis heute ist der Prozentsatz der Unternehmen, die eine “vereinheitlichte monolithische Codebasis” zur Ableitung ihrer Entscheidungen in der Lieferkette nutzen, praktisch Null (mehr dazu unten). Stattdessen haben Unternehmen eine Vielzahl von Tabellenkalkulationen. Anders als das schöne Bild, das die Autoren zeichnen, gibt es keine “mathematischen Programme”, mit denen die LLMs interagieren können. Während LLMs konzeptionell eine unordentliche Ansammlung von halb veralteten Tabellenkalkulationen bearbeiten und verbessern könnten, handelt es sich bis auf Weiteres um reine Spekulation. Selbst hochmoderne LLMs würden Schwierigkeiten haben, eine einzige große Tabelle zu bearbeiten - die passive Code-Duplizierung, die Tabellenkalkulationen mit sich bringen, ist für LLMs überhaupt nicht günstig -, aber das Verständnis von Hunderten, wenn nicht Tausenden von Tabellen bleibt zu diesem Zeitpunkt reine Science-Fiction.

Nun, es gibt tatsächlich einige Unternehmen, die von einer vereinheitlichten monolithischen Codebasis profitieren, um Entscheidungsprozesse in der Lieferkette zu steuern - nämlich die Kunden von Lokad. Wenn die Autoren, wie wir, tatsächlich Erfahrung in dieser Angelegenheit hätten, wüssten sie, dass diese Codebasen erheblich sind; typischerweise Zehntausende von Codezeilen, obwohl wir eine DSL (domänenspezifische Sprache)³ verwenden, die auf die Lieferkette spezialisiert ist. Diese DSL ist übrigens etwa 10-mal kürzer als Python oder Java für diese Art von Aufgaben. Es gibt leider keinen Shortcut: Für jede interessante Entscheidung gibt es Dutzende von Tabellen, die Hunderte von Feldern abdecken und an der Berechnung beteiligt sind. Während es denkbar ist, dass weitere Verbesserungen unserer DSL die Anzahl der Codezeilen weiter reduzieren können, werden diese Codebasen niemals klein sein.

Nochmals, LLMs könnten konzeptionell eine komplexe Codebasis bearbeiten und verbessern, während sie von einem nicht-technischen Beitragenden geleitet werden. Wir befinden uns jedoch wieder im Science-Fiction-Territorium. LLMs haben sich bereits als fantastische Produktivitätswerkzeuge für fähige Programmierer erwiesen. Mit anderen Worten, wenn Sie bereits wissen, wie man programmiert, können Ihnen LLMs helfen, schneller zu programmieren. Doch das ist nicht das, was die Autoren des Artikels sagen. Ihre Behauptung ist genau die, dass LLMs verwendet werden können, um nicht-technischen Beitragenden technische Beiträge zu ermöglichen. Basierend auf dem aktuellen Stand der Technik von LLMs ist diese Behauptung unweigerlich falsch, außerhalb der Grenzen winziger Sandkästen, die die massive Umgebungs-Komplexität realer Lieferketten nicht widerspiegeln.

Planer können die LLM-Technologie nutzen, um die mathematischen Modelle der Struktur einer Lieferkette und der Geschäftsanforderungen zu aktualisieren, um die aktuelle Geschäftsumgebung widerzuspiegeln. Darüber hinaus kann ein LLM Planer über eine Änderung der Geschäftsbedingungen informieren.

Die Autoren halten an der Science-Fiction fest. Diese Behauptung ist technisch nicht von “ein LLM kann Patches für ein Code-Repository auf GitHub erstellen, basierend auf von nicht-technischen Benutzern eingereichten Tickets” zu unterscheiden. Es wäre fantastisch, wenn dies möglich wäre, aber gegenwärtige LLMs sind bei ernsthaften Anfragen noch lange nicht in der Lage, eine solche Leistung zuverlässig zu erbringen. Bei der Vorstellung von Anwendungsfällen für eine neue Technologie ist es entscheidend, die Grenzen dieser Technologie genau zu vermitteln. Die vier Co-Autoren scheinen sich der aktuellen Möglichkeiten von LLMs völlig bewusst zu sein; das heißt, ich habe den Verdacht, dass sie es nicht sind. Stattdessen erhalten wir Werbeschwätzerei von Menschen, die sich sehr wohl darüber im Klaren sind, was sie tun - was zweifellos noch schlimmer ist.

Die Notwendigkeit, den Lieferplan zu ändern, kann auch durch die auf LLM-Technologie basierende Technologie verursacht werden. Zum Beispiel kann es nach der Analyse von Versanddaten eines bestimmten Lieferanten einen Alarm auslösen, dass sich die Vorlaufzeit des Lieferanten in den letzten Monaten erheblich erhöht hat.

Die Feststellung, ob eine Vorlaufzeit abnormal ist, ist absolut nicht das, was ein LLM tun kann. Ein LLM kann jedoch aufgefordert werden, ein Stück Code zu schreiben, um diese Analyse durchzuführen. Wir sind wieder bei dem LinkedIn-Beitrag “Top 10 Dinge, die ich heute mit ChatGPT gemacht habe”. Warum dort aufhören und nicht direkt die Bestelllogik aktualisieren, wo die Vorlaufzeitinformationen verwendet werden? Genau das schlagen die Autoren später im Artikel vor.

Wir stellen uns vor, dass in den nächsten Jahren die auf LLM-Technologie basierende Technologie Szenarien für end-to-end Entscheidungsfindung unterstützen wird.

Wenn die Autoren mit “Unterstützung” meinen, dass sie “Programmierer produktiver machen” - wobei diese Programmierer für die Codierung der end-to-end Entscheidungsfindung verantwortlich sind - dann ist dies bereits möglich - tatsächlich tut Lokad dies schon seit einiger Zeit. Wenn wir jedoch die menschlichen Programmierer aus dem Bild entfernen, wird diese Aussage zu etwas Ähnlichem wie “Wir stellen uns vor, dass in den nächsten Jahren LLM-basierte Technologien KI (künstliche Intelligenz) erreichen werden”.

Die Autoren, die hartnäckig auf dem Buzzword “Gen AI” reiten, ignorieren völlig, dass LLMs möglicherweise eigene Einschränkungen haben. Hier ist das, was die Autoren in ihrem abschließenden Abschnitt “Überwindung von Barrieren” vorschlagen:

Einführung und Schulung. Die Optimierung von Lieferketten mit Hilfe eines LLM 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 effektiv sehr präzise sind). Um eine Lieferkette mit Hilfe eines LLM zu optimieren, benötigen Sie einen menschlichen Ingenieur, der in der Lage ist, die Codierung vollständig alleine durchzuführen, wenn auch langsamer. In absehbarer Zukunft wird kein Training, außer dem Erlernen der Programmierung, Benutzer in die Lage versetzen, Lieferkettenoptimierungen mit Unterstützung von LLMs durchzuführen.

Dem CEO oder dem Leiter der Lieferkette zu sagen, dass er sein Team lediglich darauf trainieren muss, eine “präzise Sprache” zu verwenden, ist völlig irreführend. Die Art von Schulungen, die sich aus dieser Sicht ergeben würden, wären garantiert eine komplette Zeitverschwendung für alle Beteiligten.

Überprüfung. LLM-Technologie kann gelegentlich eine falsche Ausgabe erzeugen. Eine allgemeine Herausforderung besteht daher darin, die Technologie “innerhalb der Schienen” zu halten - d.h. Fehler zu identifizieren und sich davon zu erholen.

Obwohl LLMs von Natur aus probabilistisch sind, wird dieses Problem von der semantischen Unsicherheit überschattet, die die Lieferketten-Systeme durchdringt. Mit anderen Worten, das LLM wird Ihnen sehr wahrscheinlich die richtige Antwort auf das falsche Problem geben. Die Erfahrung von Lokad zeigt, dass häufig der einzige Weg, um zu überprüfen, ob eine bestimmte Implementierung (die eine Lieferkettenentscheidung steuert) korrekt ist, ein begrenzter experimenteller Test⁴ ist. Rückmeldung aus der realen Welt ist keine Option. Wissen kann nicht aus dem Nichts herbeigezaubert werden - selbst LLMs auf AGI-Niveau würden immer noch mit dieser Hürde konfrontiert werden.

Hier sind die Autoren dabei, Lücken zu füllen. Sie machen eine richtige - aber triviale - Aussage über die Natur von LLMs, ohne auch nur zu versuchen, herauszufinden, ob das Problem ein Kernanliegen ist oder nicht. Hätten die Autoren tatsächlich LLMs zur Verwaltung von realen Lieferketten eingesetzt, hätten sie, wie wir, erkannt, dass dieses Anliegen ein kleines Problem auf einer langen Liste von viel größeren - und viel wirkungsvolleren - Problemen ist.

Abschließend gilt hier Brandolinis Gesetz: Die Menge an Energie, die benötigt wird, um Bullshit zu widerlegen, ist um eine Größenordnung größer als die, die benötigt wird, um ihn zu produzieren. Dieser Artikel ist so schlecht, dass er von ChatGPT geschrieben worden sein könnte - und vielleicht wurde er das auch, soweit ich weiß. Basierend auf meinen oberflächlichen Beobachtungen werden jeden Tag dutzende genauso schlechte Artikel über Gen-AI und SCM produziert. Die Bekanntheit der Autoren hat mich dazu motiviert, diese Rezension zu verfassen. Wenn man sich zurückzieht, wäre es nicht das erste Mal, dass ein Anbieter verspricht, eine Domäne zu revolutionieren, ohne etwas Substanzielles anzubieten. Aber derselbe Anbieter tut dies zweimal⁵ hintereinander innerhalb derselben Domäne könnte jedoch übertrieben sein. Andererseits sollte die Wissenschaft zumindest versuchen, kritisches Denken anzuwenden, anstatt freudig auf den Buzzword-Zug aufzuspringen.