Mit Ihrer Supply Chain zu plaudern, behebt das Problem nicht
Alle paar Tage taucht eine neue Demo auf: Man tippt eine Frage in klarem English – “What if demand spikes in Germany?”, “What if we shut down this plant?”, “What if we switch suppliers?” – und ein Assistent antwortet selbstsicher mit einem überarbeiteten Plan, einer kurzen Erklärung und einer geordneten Liste der nächsten Schritte. Das Angebot ist unwiderstehlich: supply chain, endlich konversationell gemacht. Planung, endlich reibungslos. Optimierung, endlich zugänglich.
In meinem Buch Introduction to Supply Chain (siehe Kapitel 6, insbesondere die Teile, die sich mit “general intelligence” und dem Erbe der OR beschäftigen) argumentierte ich, dass supply chain eine Disziplin ist, die immer wieder schicke Benutzeroberflächen fälschlicherweise mit Fortschritt verwechselt. Dieses Argument ist jetzt von Bedeutung, da große Sprachmodelle (LLMs) von ernsthaften Forschern und Anbietern als das fehlende Puzzleteil positioniert werden, das endlich die Mathematik mit der Praxis und die Planung mit der Realität verbindet.
Was die Community tatsächlich entwickelt
Die OR-Community war bemerkenswert konsequent in dem, was sie von LLMs erwartet: ein universeller Übersetzer zwischen menschlicher Intention und mathematischer Maschinerie.
Die NL4Opt-Wettbewerbsreihe bei NeurIPS verfolgt explizit das Ziel, die “accessibility and usability of optimization solvers” zu erhöhen, indem Laien Probleme in natürlicher Sprache formulieren können, wonach die Modellierungsartefakte (einschließlich LP- und MIP-Modellierungscode) generiert werden, die die Solver verarbeiten. Dies ist keine Randidee; es wird in Benchmark-Aufgaben, Datensätzen, Evaluationsmetriken und preisgetriebenen Wettbewerbsstrukturen formalisiert.
OptLLM überführt dieselbe Idee aus der Forschung in einen End-to-End-Workflow: Der Nutzer formuliert ein Optimierungsproblem in natürlicher Sprache; das System wandelt es in mathematische Formulierungen und Programmiercode um; dann ruft es einen externen Solver auf und iteriert in einem mehrstufigen Dialog, um das Modell zu verfeinern. Anders gesagt: English → math → code → solver → Ergebnisse → English, wobei das LLM den Zyklus orchestriert.
Das INFORMS’ 2024 TutORials-Kapitel von Wasserkrug, Boussioux und Sun bietet einen breiteren, beruflich ausgerichteten Rahmen: LLMs können die Erstellung und den Einsatz von OR/MS-Lösungen beschleunigen, indem sie (i) die Entwicklungszeit verkürzen und gleichzeitig die Lösungsqualität verbessern, (ii) strukturierte Daten aus unstrukturiertem Text extrahieren, ohne eigens angepasste NLP-Modelle zu entwickeln (wobei sie explizit die Nachfrageprognose als motivierenden Anwendungsfall nennen) und (iii) Schnittstellen in natürlicher Sprache ermöglichen, sodass Geschäftsanwender flexibel mit analytischen Modellen interagieren können. Das Kapitel fällt nicht nur durch seinen Optimismus auf, sondern auch durch die Betonung einer verantwortungsvollen Nutzung: LLMs werden als mächtige Werkzeuge präsentiert, die jedoch einer Steuerung und Rechenschaftspflicht bedürfen.
Inzwischen integriert auch der Bereich Learning-to-Optimize LLMs – nicht nur als “interfaces”, sondern als Komponenten im Solver-Ökosystem selbst. Der Anspruch eines “foundation model” hat in MILP Einzug gehalten: Microsoft-Forscher schlagen vor, ein einzelnes Modell über diverse MILP-Klassen zu trainieren und stellen MILP‑Evolve vor, ein LLM-basiertes evolutionäres Framework, das große, vielfältige MILP-Problemklassen “with an unlimited amount of instances” generiert und Aufgaben wie das Lernen von Branching sowie das Angleichen von MILP-Instanzen an Beschreibungen in natürlicher Sprache unterstützt. Eine Umfrage aus dem Jahr 2025 zu LLMs für evolutionäre Optimierung geht noch einen Schritt weiter und kategorisiert aufkommende Paradigmen: LLMs als eigenständige Optimierer, LLMs, die in Optimierungsalgorithmen eingebettet sind, und LLMs, die auf höherer Ebene für die Algorithmenauswahl und -generierung genutzt werden – wobei explizit auf “self-evolving agentic ecosystems” für die Optimierung hingewiesen wird.
Im Bereich des supply chain planning stimmen die Vorschläge fast perfekt mit der OR-Agenda überein – allerdings mit einem anderen Fokus: nicht “make solvers accessible”, sondern “make planners fast.”
Das 2025 veröffentlichte Stück von MIT Sloan Executive Education zu LLMs im supply chain planning ist repräsentativ. Es beschreibt, wie Planer komplexe What-if-Fragen in natürlicher Sprache stellen; das LLM übersetzt die Anfrage in mathematische Anpassungen und liefert für Menschen verständliche Erkenntnisse. Es wird behauptet, dass etwas, das früher “days” des Hin-und-Her mit Ingenieuren benötigte, in “minutes” erledigt werden könne, und das Versprechen wird bis hin zu “real-time” Störungen erweitert: Planer können “dynamically adjust mathematical models”, ohne sich auf IT-Teams zu verlassen, und die Optimierung erneut ausführen, um überarbeitete Pläne in klarer Sprache zu erhalten. Derselbe Artikel gibt – beinahe beiläufig – zu, dass die zentrale Schwierigkeit in der Validierung liegt – also darin, sicherzustellen, dass die von der KI generierten Anpassungen den realen Geschäftsbedingungen entsprechen.
Simchi-Levi, Mellou, Menache und Pathuri (2025) machen die These der “democratization” explizit: Planer und Führungskräfte verbringen derzeit zu viel Zeit damit, Ergebnisse zu verstehen, Szenarien durchzuspielen und Modelle zu aktualisieren, sodass LLMs die “supply chain technology” demokratisieren können, indem sie Verständnis und Interaktion “without human-in-the-loop” erleichtern und die Entscheidungszeit von “days and weeks” auf “minutes and hours” reduzieren.
Das OptiGuide-Projekt von Microsoft Research befindet sich genau an dieser Schnittstelle zwischen OR und Planung: Es zielt darauf ab, die Entscheidungsfindung zu demokratisieren, indem es Optimierung mit generativer KI kombiniert, und behauptet, in der Produktion eingesetzt zu werden, damit cloud supply chain planners “what if”-Fragen beantworten und umsetzbare Empfehlungen erhalten.
Die Softwareanbieter sind – wenig überraschend – auf dieselben Themen konvergiert: Copilots, agents, Abfragen in natürlicher Sprache und schnellere Entscheidungen.
SAP positioniert Joule als einen generativen AI-Copilot, der in seine Unternehmensanwendungen integriert ist, einschließlich supply chain, und SAPs IBP-spezifische Seiten heben den konversationellen Zugang zu Produktdokumentationen (eine reibungslosere Methode, um Hilfestellungen zu suchen und abzurufen) sowie die Integration von Joule mit SAP IBP hervor. SAPs eigene Community-Releasenotes für IBP erwähnen die Integration von Joule als eine Innovation in dieser Release-Linie.
Oracles Ankündigungen aus dem Jahr 2025 betonen “AI agents”, die in Oracle Fusion Cloud Applications eingebettet sind. Für supply chain erklärt Oracle, dass diese Agents Prozesse automatisieren, die Planung und das Fulfillment optimieren und die Entscheidungsfindung beschleunigen; es werden sogar Agents wie ein Exceptions-and-Notes Planning Advisor aufgezählt, der Warnungen und Notizen zusammenfasst. Oracles Readiness-Dokumentation beschreibt zudem einen “Supply Chain Planning Process Advisor” Agenten, der mit LLMs + RAG entwickelt wurde, um die Fragen der Planer zu Verantwortlichkeiten, täglichen Aufgaben und Eskalationsprozessen zu beantworten – basierend auf von Kunden hochgeladenen Unternehmensdokumenten.
Die ICON 2025-Pressemitteilung von Blue Yonder präsentiert “AI agents” und einen “supply chain knowledge graph” und behauptet, dass die Agents es Unternehmen ermöglichen, mit Maschinengeschwindigkeit zu sehen, zu analysieren, zu entscheiden und zu handeln, und dass agentic AI in Planung und Umsetzung durchdrungen ist.
Kinaxis beschreibt agentische und generative AI-Fähigkeiten, die die Barrieren zur Interaktion mit supply chain Daten senken – man befragt einen “digital twin” in natürlicher Sprache und erhält Antworten – und seine öffentlichen Materialien sowie unabhängige Analystenberichte beschreiben ein Multi-Agenten-Framework, das darauf abzielt, die Abhängigkeit von IT zu reduzieren und Planern die direkte Interaktion mit operativen Daten zu ermöglichen.
o9 verfolgt dieselbe Storyline mit unterschiedlicher Markenbildung: “GenAI agents” plus ein Enterprise-Knowledge-Graph, der sich zu einem “large knowledge model” entwickelt, positioniert als ein Quantensprung in Produktivität und Expertise für Planungsfunktionen.
Über all dem steht Gartner, das die Kategoriesprache liefert. In einer Pressemitteilung vom August 2025 prognostiziert Gartner die rasche Verbreitung von AI-Assistenten und aufgabenspezifischen AI-Agents in Unternehmensanwendungen, umreißt “Stages” der agentischen AI-Evolution und warnt davor, dass ein weit verbreitetes Missverständnis darin besteht, Assistenten als “agents” zu bezeichnen – ein Missverständnis, das als “agentwashing” tituliert wird.
Also, ja: Es wird wirklich gearbeitet. Benchmarks, Frameworks, Agentenarchitekturen, Integrationen und jede Menge produktionsorientierte Ingenieurskunst sind am Werk. Die Frage lautet nicht, ob LLMs in supply chain Tools integriert werden können – das ist bereits der Fall. Die Frage ist, ob diese Integration die tatsächlichen Gründe anspricht, weshalb die Entscheidungsfindung in supply chain hartnäckig mittelmäßig bleibt.
Warum ich nicht davon überzeugt bin, dass die Schnittstelle der Engpass ist
Die OR-Community hat in einem Punkt recht: Optimierung lässt sich nur schwer präzise ausdrücken. Auch die Planungsgemeinschaft hat in einem Punkt recht: Die Menschen verschwenden Zeit damit, Fragen in Tabellenkalkulationen, E-Mails, Meetings, Tickets und ad-hoc Modelländerungen zu übersetzen. Ein LLM kann diese Reibung verringern. Es kann den Weg verkürzen zwischen “I wonder…” und “here is a computed answer”, genau wie es das MIT Sloan-Stück beschreibt.
Doch supply chains scheitern nicht, weil Planer keinen schnelleren Weg finden, Fragen zu stellen.
Jahrzehnte an Solvern, Modellierungssprachen und akademischem Fortschritt gibt es bereits. Die in NL4Opt verankerte Behauptung – “make solvers usable by non-experts via natural language” – setzt voraus, dass das Haupthindernis in der Unfähigkeit der Nutzer liegt, Probleme zu formulieren. Das ist eine tröstliche Geschichte für Forscher, denn sie verwandelt ein chaotisches organisatorisches Versagen in ein Übersetzungsproblem. Und sie ist in supply chain weitgehend falsch.
Was die realweltliche Übernahme behindert, ist nicht, dass Menschen Einschränkungen nicht eintippen können. Es ist vielmehr, dass die Einschränkungen, die Ziele und die Datensemantik routinemäßig falsch sind – oder, genauer gesagt, auf wirtschaftlich relevante Weise falsch. Man kann Berge von Modellierungscode generieren und trotzdem Unsinn optimieren.
Das ist keine neue Kritik. Russell Ackoff argumentierte bereits 1979, dass OR “contextually naive” geworden sei und dass dessen Anwendung zunehmend auf Probleme beschränkt sei, die relativ unempfindlich gegenüber ihrer Umgebung sind. Supply chains sind das Gegenteil von umgebungsunempfindlich. Sie werden dominiert von Volatilität, Substitutionseffekten, fehlenden Daten, verzögertem Feedback und Anreizen, die das Verhalten verändern, sobald man mit dem “optimizing” beginnt.
Die LLM-Agenda in OR neigt dazu, eine brutale Asymmetrie zu unterschätzen: Ein Modell zu schreiben ist leichter, als es zu validieren. OptLLM kann Formulierungen und Code generieren und anschließend im Dialog iterieren. Doch die eigentliche Schwierigkeit besteht nicht darin, ein weiteres mathematisches Objekt zu erstellen – es geht darum sicherzustellen, dass dieses Objekt den tatsächlichen wirtschaftlichen Abwägungen, betrieblichen Zwängen und der Messrealität des Unternehmens entspricht. Ein LLM kann einen plausiblen Zwang erzeugen; es kann jedoch nicht zertifizieren, dass dieser Zwang dem entspricht, was Ihr Lager tatsächlich um 3 Uhr morgens während einer Promotion mit dem realen Mitarbeitereinsatz, den tatsächlichen Verpackungsrichtlinien, den echten Auffüllregeln und den realen Ausfallmodi widerfährt.
Im Bereich der Planung wird dieselbe Asymmetrie noch gefährlicher, da der kulturelle Reflex darin besteht, dem Plan zu vertrauen. Der MIT Sloan-Artikel lobt, dass Planer “dynamically adjust mathematical models” können, ohne auf IT angewiesen zu sein. Simchi-Levi und seine Coautoren rahmen dies als Abschaffung der Notwendigkeit von Data-Science-Teams und Technologieanbietern im Prozess. Dies wird als Ermächtigung verkauft. Ich sehe es als Umgehung der genau jener Reibung, die früher ein unkontrolliertes Modelldriften verhinderte.
Wenn es einfach ist, das Modell zu ändern, wird die Organisation das Modell ständig anpassen. Nicht weil es klug ist, sondern weil es psychologisch befriedigt. Jede Störung lädt zu einer neuen Ausnahme ein. Jede Frage eines Executives führt zu einem neuen Szenario. Jedes Meeting lädt zu einer neuen Anpassung ein, um der Intuition jemandes gerecht zu werden. Man erzielt zwar schnellere Abläufe – aber auch eine schnellere Entropie.
Anbieter haben sich verständlicherweise zu “agents” entwickelt, die zusammenfassen, erklären und anleiten. Oracles Planning Process Advisor ist im Wesentlichen eine LLM+RAG-Schicht über Richtlinien und Verfahren: Er beantwortet Fragen basierend auf den von Ihnen hochgeladenen Dokumenten und integriert diese Chat-Erfahrung in Workflow-Seiten. Die Positionierung von SAPs Joule in IBP hebt ähnlich die konversationelle Suche und dokumentationsbasierte Antworten hervor. Diese Features steigern die Produktivität: Sie reduzieren die Zeit, die mit der Suche nach dem richtigen Prozessdokument verschwendet wird. Aber sie verbessern nicht maßgeblich die Qualität der Entscheidungen. Sie sind bestenfalls ein besseres Hilfesystem.
Dann kommen wir zur großangelegten “agentic” Story. Blue Yonder kündigt mehrere AI agents an, die in Planung und Ausführung integriert sind, mit dem Ziel, eine kontinuierliche Optimierung und Entscheidungsfindung mit Maschinengeschwindigkeit zu erreichen. Kinaxis beschreibt agentische Frameworks, AI agents, die in Echtzeit überwachen und handeln, sowie die Interaktion in natürlicher Sprache mit einem digital twin. Gartner prognostiziert eine Welt, die von diesen Dingen erfüllt ist, warnt jedoch, dass vieles von dem, was als Agents verkauft wird, in Wirklichkeit Assistenten sind – “agentwashing.”
Die Ironie besteht darin, dass Gartners Warnung keine Randbemerkung ist; sie ist die zentrale Tatsache. Die meisten dieser “agents” sind lediglich Wrapper. Sie liegen auf bestehenden Workflows auf, automatisieren Teilaspekte der Interaktion und verschönern die Schnittstelle. Sie beheben nicht die ökonomische Logik der Entscheidungen, noch lösen sie die grundlegenden Probleme der Datenintegrität, Unsicherheit und Anreize. Sie können die Verzögerung bei der Entscheidungsfindung im engen Sinne reduzieren, indem jemand schneller klicken kann – jedoch nicht im tieferen Sinne, dass das Unternehmen weniger Fehler macht.
Selbst die substantielleren akademischen Integration – LLM + network optimization, mit Dashboards und rollenbewussten Erklärungen – rahmen die Kernschwierigkeit als das “bridging the gap” zwischen OR-Ergebnissen und dem Verständnis der Stakeholder ein, indem sie Ergebnisse in natürliche Sprache und kontextuelle KPIs übersetzen. Wiederum: Nützlich. Aber sie bewahren die Annahme: Das Modell ist korrekt; die Menschen müssen es nur verstehen. In supply chain ist das Modell oft das Problem.
Wenn ich also höre “LLMs will democratize optimization”, übersetze ich das mit: “Wir werden die Produktion von Pseudo-Modellen demokratisieren.” Wenn ich höre “LLMs will let planners update models without IT”, übersetze ich es mit: “Wir werden die Rate beschleunigen, mit der fragile Modelle gepatcht, unpatcht und erneut gepatcht werden.” Und wenn ich höre “agentic AI will orchestrate end-to-end workflows”, frage ich: Auf welches Ziel soll orchestriert werden, nach welchen Semantiken und mit welcher Verantwortlichkeit?
Wo LLMs wirklich nützlich sein können
Das alles ist kein Argument dafür, LLMs zu ignorieren. Es ist ein Argument dagegen, so zu tun, als wäre Konversation ein Ersatz für Kompetenz.
Das OR/MS TutORials-Kapitel betont zu Recht, dass LLMs die Erstellung von Entscheidungsanwendungen beschleunigen, unstrukturierten Text in strukturierte Signale umwandeln und Interaktionsschichten in natürlicher Sprache bereitstellen können – und gleichzeitig auf eine verantwortungsvolle Nutzung bestehen. Genau hier glänzen LLMs: Nicht als Entscheidungsmaschine, sondern als Produktivitätsmultiplikator für die Ingenieure und Analysten, die die eigentliche Entscheidungsmaschine entwickeln.
Wenn du LLMs einsetzt, um Klebecode schneller zu schreiben, Tests zu generieren, Dokumentationen zu entwerfen, unordentliche Geschäftsregeln aus Verträgen und SOPs in strukturierte Darstellungen zu überführen, verbesserst du den Teil der Pipeline, der tatsächlich ein Engpass ist: die langsame, teure und fehleranfällige Entwicklung von Daten und Logik. Wenn du LLMs nutzt, um Prüfern, Führungskräften und Operateuren zu helfen, zu verstehen, warum eine berechnete Entscheidung getroffen wurde – indem Erklärungen erzeugt werden, die auf nachvollziehbaren Belegen basieren – kannst du die Akzeptanz verbessern, ohne die Kontrolle abzugeben.
Selbst die „Demokratisierung“-Aussage kann produktiv umformuliert werden. Der Anspruch von OptiGuide, dass es in der Produktion für cloud supply chain Planer eingesetzt wurde, die Was-wäre-wenn-Fragen beantworten, ist nicht trivial. Aber der Wert liegt nicht darin, dass ein Planer mit einem Optimierer chatten kann. Der Wert liegt darin, dass ein Unternehmen mit einem ernsthaften Optimierungsfundament eine sicherere, benutzerfreundlichere Schnittstelle entwickeln kann – eine, die die richtigen Stellschrauben und Erklärungen offenlegt, anstatt jedem zu erlauben, beiläufig die zugrundeliegende Mathematik umzuschreiben.
Und ja, die Solver-Lern-Agenda – Foundation Models für MILP, learned branching und so weiter – könnte zu echten algorithmischen Verbesserungen führen. Aber supply chain wird von diesen Verbesserungen nur profitieren, wenn der Rest des Stacks gesund ist: korrekte Semantik, wirtschaftliche Ziele, robustes Umgehen mit Unsicherheiten und eine Ausführungsschleife, die Empfehlungen zuverlässig in Maßnahmen umsetzt.
Mit anderen Worten, behandle LLMs so, wie du jedes mächtige, aber fehlbare Werkzeug behandelst: als Beschleuniger für die Menschen, die Systeme entwickeln, und nicht als Lackschicht auf defekten Prozessen. Betrachte sie als Mittel, um die Kosten strenger Verfahren zu senken, nicht als Möglichkeit, Strenge zu überspringen.
Supply chain ist nicht wortlos. Es mangelt nur an guten Entscheidungen. LLMs sind außergewöhnlich darin, Worte zu produzieren. Sie können uns dabei helfen, bessere Systeme schneller zu entwickeln. Aber wenn wir Beredsamkeit mit Korrektheit verwechseln, werden wir einfach nur Fehler in besserer Prosa – und mit höherer Geschwindigkeit – erhalten.
