00:00:00 Lokads Gründungsgeschichte und frühe Jahre
00:02:31 Missverständnisse über Supply Chain Optimierung
00:04:31 Bestehende Supply Chain Theorien funktionierten nicht
00:06:32 Das Paradoxon fehlgeschlagener Prognosen
00:08:33 Wie “keine Prognose” die Konkurrenten schlug
00:10:25 Die Herausforderung, etablierte Ideen abzulehnen
00:12:00 Der Wandel zur probabilistischen Prognose
00:14:07 Die Bedeutung extremer Nachfrageszenarien
00:16:32 Die Komplexität der Integration von Unternehmensdaten
00:20:55 Warum Supply Chain Modelle auf dem Papier scheitern
00:27:30 Ingenieurprobleme bei der Einführung von Unternehmens-KI
00:35:00 Der Einfluss von COVID-19 auf Supply Chains
00:42:49 LLMs basieren auf Text, nicht auf Mathematik
00:50:25 Die parallele Entwicklung der Finanzbranche
01:09:00 Fragen und Antworten sowie abschließende Bemerkungen
Zusammenfassung
Joannes Vermorel, CEO und Gründer von Lokad, hielt einen Vortrag auf Französisch, in dem er seinen Weg im Supply Chain management darlegte. Vermorel berichtete, wie er Lokad gründete, nachdem er die École Normale Supérieure abgeschlossen und seinen Fokus von der Bioinformatik auf Supply Chain Herausforderungen verlagert hatte. Er sprach über die Entwicklung von Envision, Lokads Programmiersprache, und die Entwicklung des Unternehmens seit 2007. Vermorel kritisierte traditionelle Supply Chain Theorien, indem er sie mit Astrologie verglich, und betonte die Wichtigkeit, den Konsens in Frage zu stellen. Er hob Lokads Erfolg mit probabilistischen Methoden hervor und den Einfluss von COVID-19 auf die Supply Chain Robotisierung hervor. Vermorel prognostizierte, dass traditionelle Rollen obsolet werden, und forderte die Studierenden auf, die Revolution der Branche voranzutreiben.
Erweiterte Zusammenfassung
In einem auf Französisch gehaltenen Vortrag teilte Joannes Vermorel, CEO und Gründer von Lokad, seinen Werdegang und seine Einsichten in die Welt des Supply Chain management und die Entwicklung seines Unternehmens. Vermorel begann damit, sich vorzustellen und die Ursprünge von Lokad zu schildern, einem Unternehmen, das er direkt nach seinem Abschluss an der École Normale Supérieure gründete. Zunächst versuchte Vermorel, eine Dissertation in Bioinformatik zu schreiben, stellte jedoch bald fest, dass das Feld bereits von talentierten Fachleuten übersättigt war. Zufällig stieß er auf die Herausforderungen des Supply Chain management, die zu seinem neuen Schwerpunkt wurden.
Vermorel drückte seine Überraschung und Freude darüber aus, Studierende der Centrale zu sehen, die Envision verwenden – eine Programmiersprache, die er für die Supply Chain Optimierung entwickelt hatte. Er berichtete über die Entwicklung von Envision und erwähnte, dass der erste von ihm geschriebene Compiler schnell durch eine überlegene Version ersetzt wurde, die von Victor Nicolet, Lokads CTO, entwickelt wurde. Seither hat sich Envision stark weiterentwickelt, und das Unternehmen steht kurz vor der Veröffentlichung von Version 6.
Lokads Weg begann im Jahr 2007, wobei das Unternehmen offiziell 2008 gegründet wurde. Envision wurde jedoch erst 2013 eingeführt, fünf Jahre nach der Gründung von Lokad. Vermorel erklärte, dass die Entscheidung, eine neue Programmiersprache zu entwickeln, getroffen wurde, nachdem alle anderen Alternativen ausgeschöpft waren. Anfangs glaubte er, dass Supply Chain ein etabliertes Feld sei – mit Jahrzehnten an Literatur und zahlreichen Konkurrenten wie SAP, Oracle, IBM und Microsoft. Er nahm an, dass der Schlüssel zum Erfolg darin bestünde, bestehende Supply Chain Theorien in Webanwendungen umzusetzen und den Übergang von Client-Server-Anwendungen zu cloudbasierten Lösungen zu nutzen.
Trotz seines anfänglichen Selbstvertrauens stellte Vermorel bald fest, dass die etablierten Theorien und Modelle nicht wie erwartet funktionierten. Er berichtete von einer besonders absurden Erfahrung im Jahr 2011, bei der Lokad einen Benchmark gewann, indem es null Prognosen abgab – was zu einer um 20% besseren Genauigkeit als bei den Konkurrenten führte. Diese Erfahrung veranlasste Vermorel, die Gültigkeit traditioneller Supply Chain Theorien in Frage zu stellen, indem er sie eher mit Astrologie als mit Astronomie verglich.
Vermorel betonte die Wichtigkeit, den wissenschaftlichen Konsens zu hinterfragen, und wies darauf hin, dass die Geschichte voller Beispiele für weit verbreitete, aber letztlich falsche Überzeugungen sei. Er kam zu dem Schluss, dass, obwohl Supply Chain als Feld legitim ist, die klassischen Theorien, die ihm zugrunde liegen, fehlerhaft sind. Diese Erkenntnis veranlasste ihn, alternative Ansätze zu erforschen – wie voreingenommene Prognosen und Quantilvorhersagen –, die sich als effektiver erwiesen.
Lokads Ansatz entwickelte sich weiter hin zu probabilistischen und programmatischen Methoden, weg von herkömmlichen Modellen, die die Komplexität realer Supply Chain Probleme nicht bewältigen konnten. Vermorel hob die Bedeutung einer robusten Programmiersprache hervor, die speziell auf diese Herausforderungen zugeschnitten ist, und kritisierte den Einsatz allgemeiner Programmiersprachen wie Python, der oft zu gescheiterten Initiativen aufgrund verschiedener technischer Probleme führte.
Der Vortrag ging auch auf die Auswirkungen der COVID-19-Pandemie ein, die die Robotisierung von Supply Chains beschleunigte. Vermorel stellte fest, dass Lokads Lösungen in großem Maßstab wirkten, indem sie Lagerbestände im Wert von Milliarden Euro mit minimaler menschlicher Intervention verwalteten. Dieser Wandel spiegelt den Übergang in der Finanzbranche wider, in der der Handel überwiegend algorithmisch erfolgt.
Vermorel diskutierte die Zukunft des Supply Chain management und prognostizierte, dass die traditionellen Rollen von Lagerverwaltern und demand planners obsolet werden würden, da immer mehr Unternehmen automatisierte decision-making Prozesse übernehmen. Er forderte die Studierenden auf, diese Revolution proaktiv voranzutreiben, anstatt sie nur passiv zu beobachten.
Als Antwort auf Fragen der Studierenden erklärte Vermorel, dass Unternehmen mit starkem technologischem Fokus Lokads Lösungen möglicherweise intern implementieren würden, während andere diese Dienste vermutlich weiterhin outsourcen. Er ging auch auf die Einschränkungen großer Sprachmodelle (LLMs) wie ChatGPT ein und wies auf deren fehlende Lern- und Gedächtnisfähigkeiten hin.
Vermorel schloss seinen Vortrag mit Überlegungen zur Irrationalität der Märkte und der Beharrlichkeit gescheiterter Projekte in der Supply Chain Branche ab. Er erzählte Anekdoten über Wettbewerber, die trotz wiederholter Misserfolge immer wieder beträchtliche Summen aufbringen konnten, und hob die chaotische Natur des Marktes hervor. Trotz dieser Herausforderungen äußerte Vermorel seinen Stolz auf Lokads Erfolge und den unerwarteten Triumph von Envision bei Studierenden prestigeträchtiger Institutionen wie der Centrale. Er lud die Studierenden ein, einen Einstieg bei Lokad in Betracht zu ziehen, und betonte dabei die fortlaufenden Rekrutierungsbemühungen des Unternehmens.
Vollständiges Transkript
Die Originalrede auf Französisch wurde ins Englische übersetzt.
Joannes Vermorel: Lassen Sie mich mich vorstellen: Ich bin Joannes Vermorel, Gründer von Lokad. Ich gründete das Unternehmen, als ich die Schule beendet hatte. Ich war an der École Normale Supérieure, begann eine Promotion in Bioinformatik, aber letztlich machten so viele Leute interessante Dinge in der Bioinformatik, dass sie mich wahrscheinlich nicht brauchten. Und zufällig stieß ich auf diese supply chain Probleme. Ich freue mich sehr, dass ihr heute Envision verwendet. Es ist etwas Besonderes für mich, vor Studierenden der Centrale zu stehen und über diese Sprache zu sprechen. Das hätte ich mir vor etwa zwölf Jahren, als ich Envision erschuf, nie vorstellen können.
Ich schrieb den ersten Envision-Compiler, dann warf Victor Nicolet – Lokads CTO – diesen weg und schrieb rasant den zweiten Compiler, der wesentlich besser war. Und jetzt nutzt ihr im Grunde Version 5, während Version 6 kurz vor der Veröffentlichung steht. Die Sprache hat sich stark weiterentwickelt. Aber das, woran ihr gearbeitet habt – das Stück, das ihr gesehen habt – entspricht überhaupt nicht dem Ursprung von Lokad. Es kam nämlich ziemlich spät. Lokad ist ein Projekt, das 2007 begann und 2008 offiziell gegründet wurde, während Envision etwa aus dem Jahr 2013 stammt. Als Envision also erschien, war das Unternehmen bereits ungefähr fünf Jahre alt.
Die Idee, eine eigene Sprache zu entwickeln, entstand, nachdem wir alle anderen Alternativen ausgeschöpft hatten; es war nicht von Anfang an der Plan eines visionären Gründers – schlichtweg, weil alles andere, was wir versuchten, gescheitert war.
Um euch eine Vorstellung davon zu geben, was am supply chain so überraschend ist: Als ich 2008 Lokad ins Leben rief, war meine Ansicht, dass supply chain ein gut etabliertes Feld sei. Schließlich existieren 60 oder 70 Jahre Literatur darüber – buchstäblich Millionen von Publikationen. Wenn man auf Amazon “supply chain management” eingibt, erhält man – ich habe nachgesehen – etwa 10.000 Bücher, die derzeit zu diesem Thema erhältlich sind. Über die Jahrzehnte wurden zwar viele weitere veröffentlicht, aber diese 10.000 sind es, die noch verkauft werden. Es ist ein extrem gut dokumentiertes Feld.
Als ich anfing, sah ich große Konkurrenten mit namhaften Marken: SAP, Oracle, IBM, sogar Microsoft – führende Akteure im supply chain. Wenn man den Gesamtumsatz der Wettbewerber zusammenrechnet, beträgt er eine halbe Billion Dollar. Das ist beachtlich. Meine ursprüngliche Intuition – die sich letztlich als völlig falsch herausstellte – war, dass ich die etablierten supply chain Theorien nehmen und einfach in eine Web-App umwandeln könnte. Es war 2008, und alle enterprise software wechselten von sogenannten “thick client”-Apps, die man auf dem PC installiert, zu “thin client”, also Web-Apps. So bot sich die Gelegenheit, die supply chain Software als Web-App neu zu konzipieren – möglicherweise mit Cloud-Hosting. Lokad setzte sehr früh auf die Cloud. Das könnte uns gegenüber großen Unternehmen, die noch ältere, schwerere clientbasierte Systeme verwenden, einen Vorteil verschaffen. Und da es buchstäblich ganze Bücher gibt, die erklären, wie man supply chains optimiert – wie das MIT-Handbuch, das Stanford-Handbuch, das Caltech-Handbuch – las ich sie, all diese 1.000-seitigen Werke, die von zwei oder drei Professoren mit sämtlichen Gleichungen verfasst wurden.
Ich programmierte dann diese Ansätze – und nichts funktionierte. Interessanterweise hinderte das Lokad nicht daran, zu wachsen oder Kunden zu gewinnen. Man könnte meinen, dass ein Startup ein funktionierendes Produkt benötigt, um Geld zu verdienen, aber in der enterprise software kann man auch etwas verkaufen, das gar nicht funktioniert, und dennoch Kunden finden. Das mag seltsam klingen, aber so ist es. Die Realität ist: Wenn ein Unternehmen ein großes Problem lösen möchte, gibt es ein Budget, um es anzugehen. Dieses Budget mag nicht riesig sein – vor allem, wenn dein Produkt tatsächlich nicht funktioniert – aber für ein Startup können diese Summen enorm wirken. Wenn ein Riese wie Carrefour 100.000 Euro “nur um es auszuprobieren” auf den Tisch legt, ist das für Carrefour unbedeutend, aber für ein kleines Unternehmen viel.
Also, indem ich diese Asymmetrie ausnutzte, begann ich, diese standard supply chain Theorien umzusetzen: time-series Prognosen, safety stock Bestandsicherung, Service-Level-Optimierung usw. Nichts davon funktionierte – gar nichts. Wir führten mit Kunden teils fast schizophrene Diskussionen: Sie meinten, „Du musst die Sicherheitsbestand-Formel falsch implementiert haben“, woraufhin wir die Werte aus den Tabellen der Lehrbücher prüften und die Parameter kontrollierten – und alles stimmte exakt. Die Theorie war also korrekt implementiert, aber das Ergebnis war totaler Quatsch.
Ich denke, der Gipfel des Quatsches kam im Sommer 2011. Wir nahmen an einer großen Ausschreibung mit einem halben Dutzend Softwareanbietern teil, von denen die Hälfte europäisch und die andere Hälfte amerikanisch war. Lokad war unter den Europäern. Der Fall, wie ich mich erinnere, betraf etwa zehn Supermärkte, 5.000 SKUs pro Supermarkt, mit der Notwendigkeit, einige Tage im Voraus zu prognostizieren, da diese Supermärkte vielleicht zwei- oder dreimal pro Woche aufgefüllt wurden. Der Kunde verwendete ein backtesting Fehlerkriterium für tägliche, produktbezogene Prognosen für jeden Laden – im Wesentlichen den absoluten Fehler zwischen Prognose und Ist-Wert. Lokad gewann diese Benchmark letztlich – mit 20% bessere Prognose besserer Genauigkeit als die anderen. Meine Geheimmethode? Ich sandte Nullen zurück. Null für alles. Dank meiner „Null-Prognose“ übertraf ich auch alle anderen in der Berechnungsgeschwindigkeit: Nullen zurückzugeben ist extrem schnell. Und ich erzielte eine um 20% bessere Prognose als die anderen.
Offensichtlich war das völliger Quatsch. Aber wenn man den in sämtlichen supply chain Lehrbüchern empfohlenen Ansatz und den standardisierten Prozess des Kunden betrachtet, führte das zu absoluter Absurdität. Die Schlussfolgerung, die ich daraus zog, war ziemlich beunruhigend. Wir hatten ein profitables, wachsendes Unternehmen, aber ich musste erkennen, dass ich womöglich nur über ein System gestolpert war. Man kann etwas gründen, es verdient Geld, und trotzdem ist es reiner Quatsch. Vielleicht ist man anfangs einfach zu unerfahren, um das zu erkennen. Aber sobald man es erkennt, macht man dann weiter? Wenn man seinen Abschluss macht und bemerkt, dass das, was man tut, Unsinn ist – fährt man dann fort? Das löste tiefgreifende Selbstbefragung aus. Könnte supply chain einfach Astrologie sein – so wie Wahrsagerei, nicht Astronomie?
Schließlich kam ich zu dem Schluss, dass supply chain als Feld real ist, die standard supply chain Theorie jedoch im Grunde Astrologie darstellt. Das war der Haken. Es ist kaum zu glauben, dass 70 Jahre Forschung, über eine Million Publikationen und Tausende von Professoren alle falsch liegen könnten. Man stelle sich nur die intellektuelle Arroganz vor, die dafür nötig wäre. Wenn man vier verschiedene Ärzte aufsucht, die alle dieselbe Diagnose stellen, wann sagt man, dass sie alle falsch liegen und man selbst Recht hat? Doch Wissenschaft funktioniert nicht über Konsens. Tausend Menschen können sich einig sein und trotzdem irren. Die Wissenschaftsgeschichte ist voller Beispiele: ein extrem breiter Konsens über Ideen, der sich als verrückt herausstellte. Einige, die die Wissenschaftsgeschichte studieren, behaupten sogar, dass die Hälfte dessen, was eine Gesellschaft zu einem bestimmten Zeitpunkt glaubt, falsch ist – und die Schwierigkeit besteht darin, herauszufinden, welche Hälfte das ist.
So kam Lokad nach dem Benchmark zu dem Schluss: der Mainstream-Ansatz war Unsinn. Wir mussten nach etwas anderem suchen. Unser großer Durchbruch kam Anfang 2012, als wir uns nach voreingenommenen Prognosen umschauten – und zwar mit dem, was als Quantilprognosen bekannt ist. Zu der Zeit hatte ich Kunden, die 50 Mitarbeiter in Vollzeit beschäftigten, nur um die Verzerrung zu beseitigen. Also fragten sie mich: “Warum um alles in der Welt sollte man eine voreingenommene Prognose wollen, wenn wir doch Leute dafür bezahlen, sie unvoreingenommen zu machen?” Sie waren ziemlich beunruhigt, denn die neue Methode fügte so viel Verzerrung hinzu, dass sie diese niemals manuell entfernen könnten. Aber wenn ich es “Quantilprognose” nenne, klingt es wissenschaftlicher als “voreingenommene Prognose.” In Wirklichkeit ist eine Quantilprognose jedoch nur eine voreingenommene Prognose.
Wir haben diesen Ansatz bei unserem ersten E-Commerce-Kunden ausprobiert. Über Nacht wechselten wir von absurden Ergebnissen – etwa einer Prognose von Null für alles – zu etwas Mittelmäßigem, aber zumindest einigermaßen Sinnvollem. Das mag nicht grandios klingen, aber der Sprung von völliger Absurdität zu bloßer Mittelmäßigkeit war ein großer Fortschritt.
Das brachte uns dazu, alle in Lehrbüchern zu findenden supply chain Annahmen noch einmal zu überdenken – jede Grundlage in Frage zu stellen, die sich als sehr wackelig und im Grunde falsch herausstellte. Quantilprognose ist nur die einfache Version davon. Es ist ein statistisches Werkzeug, das speziell auf Extremwerte abzielt. Ökonomisch gesehen, in der supply chain, sind es die Extremwerte, bei denen das Geld verloren geht: unerwartet hohe Nachfrage, die zu einem Fehlbestand führt, unerwartet niedrige Nachfrage, die zu Überbeständen führt, unerwartet lange Durchlaufzeiten, die Ihre Pläne zunichte machen, usw. Es ist nie das Zentrum der Verteilung, das Ihnen wirklich schadet; es sind die Ausläufer. Eine Quantilprognose ist ein Werkzeug, das sich auf diese Extremwerte konzentriert. Eine verbesserte Version ist die probabilistische Vorhersage – an der Sie gearbeitet haben – bei der Sie eine vollständige Wahrscheinlichkeitsverteilung erhalten. Bereits 2012 begannen wir mit Quantilprognosen, weil sie in Bezug auf Mathematik, Statistik und Rechenleistung einfacher waren. Das Verarbeiten einer Wahrscheinlichkeitsverteilung über Millionen von SKUs ist weitaus aufwändiger, als für jedes SKU eine einzelne Prognosezahl zu erzeugen.
In der Zwischenzeit erwies sich Envision – das ursprünglich für etwas ganz anderes entwickelt wurde, ein internes Projekt mit dem Codenamen “Priceforge” für die Preisgestaltung – als perfekt, um den neuen Ansatz umzusetzen. Vorher war Lokads Idee, Standard-supply chain Software mit Menüs, Schaltflächen und Optionen zu entwickeln, wie sie in Unternehmenssoftware üblich ist. Aber aus der Sicht des Softwareanbieters war es ein Chaos: Je mehr Funktionalität hinzugefügt wurde, desto mehr wurde das Zuordnen von Daten aus der Kundenumgebung zu Ihren Datenstrukturen zu einem ingenieurstechnischen Albtraum.
Warum? Weil die Datenarchitekturen der Kunden immer einzigartig sind. Das ERP eines Kunden könnte 10.000 Tabellen haben, jede mit 50 Feldern, von denen viele nicht dokumentiert sind und auf ungewöhnliche Weise verwendet werden. Tatsächlich könnten sie zwei oder drei ERPs haben, dazu ein WMS, und eine E-Commerce-Plattform… Das Ökosystem ist komplex. Keine zwei Unternehmen haben dieselben Datendefinitionen. Sogar etwas scheinbar Einfaches wie “Bestelldatum” kann 20 verschiedene Definitionen haben: Datum, an dem der Datensatz erstellt wurde, Datum, an dem der Kunde die Bestellung bestätigte, Datum, an dem Sie sie bestätigten, Datum, an dem der Zahlungsdienstleister sie autorisierte, Datum, an dem die Bestellung versandt wurde, und so weiter. Multiplizieren Sie das mit tausend weiteren potenziellen Datenfeldern.
Wenn Sie eine “klassische” Software mit festgelegten Definitionen für Produkt, SKU, Varianten, Lieferant, Standort usw. erstellen, passen diese Definitionen selten zur Realität des Kunden. Sogar im Bereich Bekleidung definiert ein Unternehmen Varianten möglicherweise ausschließlich als Farbe und Größe, während ein anderes auch die Stoffzusammensetzung einbezieht. Oder im Lebensmitteleinzelhandel kann “Verfallsdatum” bedeuten, dass das Produkt ab einem bestimmten Tag absolut nicht mehr verkauft oder in den Läden ausgestellt werden darf. Es gibt endlose Feinheiten.
Daher erwiesen sich die Standardtheorien der supply chain als unzureichend. Wir brauchten etwas Neues: einen programmatischen Ansatz. Dies wird in supply chain Lehrbüchern nie behandelt. Fertige Modelle helfen nicht, da die reale Welt nie perfekt zu diesen Modellen passt. Es gibt immer etwas – Mindestbestellmengen, Verfallsbeschränkungen, Versandzeitplan-Einschränkungen. Die Einschränkungen jedes Unternehmens sind einzigartig. So erkannten wir, dass die Lösung programmatisch ist und nicht auf einer statischen Formel beruht. Die Frage wurde dann: Was ist das richtige programmierparadigma für supply chain?
Im Jahr 2012 könnte man gesagt haben: “Warum nicht einfach Python verwenden?” Tatsächlich war das damals genau das, was all meine amerikanischen E-Commerce-Kunden taten. Fast jede Data-Science-Initiative, die ich zu der Zeit sah, scheiterte aufgrund von Python (oder es hätte auch Java, C# oder später Julia sein können – das Problem bleibt dasselbe). Das Muster war: In drei Wochen baut ein Data-Science-Team einen beeindruckenden Prototyp für ein supply chain Problem. Dann wollen sie es in Produktion bringen, und ein Jahr später ist es immer noch nicht in Produktion; das Management verliert die Geduld, streicht das Projekt – und damit ist es.
Warum scheiterte es? Tod durch tausend Schnitte: NullReferenceException, OutOfQuotaException, Konkurrenzenprobleme, inkompatible Pakete, Sicherheitslücken, Ransomware in Ihrer Umgebung und so weiter. Nichts davon hängt direkt mit dem supply chain Problem selbst zusammen. Das grundlegende Problem ist, dass wenn Sie eine allgemeine Programmiersprache in einer großen Produktionsumgebung verwenden, Ihre Angriffsfläche für Probleme enorm ist. Beispielsweise können Sie, wenn Sie von Ihrem Code aus auf das Dateisystem schreiben, versehentlich die Umgebung, die Ihren Code hostet, beschädigen – was leicht passieren kann, wenn Sie parallel Gigabytes an Daten verarbeiten. Vielleicht ist eine Datei von einem Prozess gesperrt oder eine Festplatte ist voll, und so weiter. Diese Dinge passieren unvermeidlich mitten in der Nacht, ohne dass jemand vor Ort ist, um das Problem sofort zu beheben. Dann, am Morgen, ist der Kunde wütend, weil er erwartete, dass das System um 2 Uhr morgens fertig wäre, es aber bereits um Mitternacht abgestürzt ist.
Bei Data-Science-Demos haben Sie in der Regel eine Aufsichtsperson, die das Skript startet, sodass, wenn es abstürzt, es behoben wird. Aber die supply chain Automatisierung in der realen Welt muss jeden Tag unbeaufsichtigt laufen. Sogar die Laufzeiten können von 20 Minuten bis zu zwei Stunden schwanken, was die Produktion stört. Das war das Problem im Jahr 2012: Diese Data-Science-Initiativen scheiterten in der Produktion aufgrund der weitreichenden Komplexität allgemeiner Programmiersprachen und nicht wegen der supply chain Logik selbst.
All das veranlasste Lokad zu erkennen, dass wir eine programmatische Umgebung benötigen, die sicher und spezialisiert genug ist, um groß angelegte tägliche Abläufe ohne fragiles Aufpassen zu bewältigen. Außerdem, als wir erkannten, dass wir auch fortgeschrittene Prognosen (probabilistisch, quantilbasiert usw.) durchführen mussten, wurde Envision so eingerichtet, dass diese Arbeitsabläufe als erstklassige Funktionen behandelt werden. Beispielsweise, wenn Sie differenzierbares Programmieren für maschinelles Lernen wünschen, betten Sie in einer allgemeinen Programmiersprache eine weitere “Mini-Sprache” wie PyTorch ein. Dann haben Sie Python plus einen Haufen PyTorch-Code, und es ist leicht, Fehler zu machen, da Ihr PyTorch-Code im Wesentlichen ein unkompilierter String ist. Das Gleiche gilt für das Mischen von SQL-Abfragen in Ihrem Python-Code. Es sind alles Strings, sodass Sie Ihre Tippfehler erst zur Laufzeit entdecken. Envision hingegen kann diese Funktionalitäten als integrierte Features mit Kompilierungsprüfungen behandeln.
Lokads Ansatz entwickelte sich parallel zu Fortschritten wie Deep Learning – bei dem man nicht mehr nur über eine Bibliothek vorgefertigter Modelle verfügt, sondern sein eigenes Modell programmatisch zusammenstellt. TensorFlow ist im Wesentlichen eine Sprache zum Erstellen von Rechengraphen. Sie sind nicht auf einen “Katalog” von Modellen beschränkt; Sie bauen Strukturen auf. Envision kann diese Ideen ebenfalls nativ integrieren. Beispielsweise haben wir kürzlich an stochastischer Optimierung gearbeitet. Weiß jemand hier, was das ist? Es handelt sich um die mathematische Optimierung einer Funktion, deren Ergebnis unsicher ist – etwa die Entscheidung, wie viele Einheiten eingekauft werden sollen, wenn die zukünftige Nachfrage unbekannt ist. Das ist eine klassische supply chain Herausforderung. Sie haben einfachere Versionen mit minimalen Einschränkungen gesehen, aber reale Unternehmen haben eine Vielzahl von Beschränkungen: Bestellminima, Container-Füllraten, Kategorieeinschränkungen oder komplizierte Kalender. Zudem ist Ihre Kosten-Nutzen-Funktion unsicher. Das sind fortgeschrittene programmatische Konzepte.
Alles in allem fügte Envision ständig neue Funktionen hinzu. Heute stehen wir zudem an der Schwelle zu einer weiteren Revolution: großen Sprachmodellen (LLMs). Wahrscheinlich kennen Sie ChatGPT. Vielleicht nutzen einige von Ihnen es, um Hausaufgaben zu machen. (Ich bewerte Sie nicht, also können Sie es zugeben!) Oder zahlen sogar für die Pro-Version. Der interessante Aspekt für uns ist, dass Lokad eine Schreibkultur besitzt, was für ein supply chain Unternehmen ziemlich ungewöhnlich ist. Wir verlassen uns auf Text auf zwei Ebenen. Zunächst haben wir den Envision-Code selbst, der wörtlich das “Was” unserer Tätigkeit kodiert. Wir wollen keinen Prozess, der empfohlene Bestellungen in Excel generiert, die dann manuell modifiziert werden. Unser Ziel ist es, dass die endgültigen Zahlen automatisch ohne manuelle Änderungen erzeugt werden. Und falls Änderungen erforderlich sein sollten – was anfangs manchmal der Fall ist – werden diese Änderungen in einem Workflow erfasst, sodass wir mit dem Kunden besprechen können: “Warum haben Sie das, was generiert wurde, verändert? Was könnten wir ändern, damit manuelle Anpassungen nicht mehr notwendig sind?” Oder manchmal stellen wir fest, dass die Änderungen gar nicht hilfreich waren, sodass wir dieses Wissen ebenfalls einfließen lassen können.
Dann haben wir ein zweites Textartefakt, das JPM oder Joint Process Manual, welches das “Warum” erklärt. Es ist unser Referenzdokument für Übergaben und dafür, dem Kunden einen Gesamtüberblick über die Initiative in einfacher Sprache zu geben – ohne dass er den Envision-Code direkt lesen muss. So haben wir eine Code-Ebene, die das “Was” beschreibt, und eine separate Dokumentationsebene, die das “Warum” erklärt.
Das passt sehr gut zu LLMs, da LLMs Text verarbeiten. Mit rohen numerischen Daten sind sie nicht so gut. Wenn Sie eine riesige Tabelle in ChatGPT einfügen, erhalten Sie keine sinnvolle Regression. ChatGPT kann nur ein Stück Python-Code generieren, der die Regression durchführen würde. LLMs selbst sind nur riesige Vorhersagemodelle für das nächste Token; sie sind nicht für arithmetische Operationen gebaut. Daher die Witze darüber, dass ChatGPT grundlegende Mathematik nicht beherrscht. Aber wenn Sie ihnen Code oder textbasierte Anweisungen geben, sind sie recht gut im Manipulieren und Generieren.
So steht Lokad: Wir verfügen über fortschrittliche supply chain Automatisierungen, die monatelang ohne menschliches Eingreifen laufen können – etwas, das sich während der Lockdowns 2020–2021 bewährt hat, als viele unserer Kunden ihre Büroangestellten nach Hause schickten. In der Zwischenzeit musste die supply chain trotzdem laufen, weil die Arbeiter in den Lagern und bei den Trucks weiterhin aktiv waren. Lokad funktionierte bereits weitgehend remote, sodass unsere Supply Chain Scientists von zu Hause aus weiterarbeiten konnten. Das war der eigentliche Stresstest: zu sehen, wie unsere Rezepte ohne tägliche Überwachung laufen würden. In einigen Fällen hatten große Kunden buchstäblich Hunderte von Planern, Managern oder Analysten, die plötzlich nicht mehr da waren, aber ihre supply chain musste dennoch funktionieren.
Und für uns funktionierte es überraschend gut. Keiner unserer Kunden “starb” daran – niemand verschwand. Das wirft die Frage auf: Wenn Sie Ihre supply chain 12 oder 14 Monate lang ohne 500 Büroangestellte betreiben können, brauchen Sie sie dann überhaupt wieder? Dies war ein Experiment, das wir sonst nie hätten durchführen können, da Unternehmen in der Regel Angst haben, einem automatisierten System voll zu vertrauen. Aber die Lockdowns zwangen sie effektiv dazu, sich auf Automatisierung zu verlassen, was beweist, dass wir massive supply chains mit minimalem oder gar keinem manuellen Eingriff betreiben können. Natürlich diskutieren wir weiterhin Möglichkeiten, die numerischen Rezepte zu verbessern; es ist nicht so, dass überhaupt keine Zusammenarbeit stattfindet. Aber man sieht nicht mehr, wie große Teams täglich Excel-Anpassungen an jeder SKU in jedem Geschäft vornehmen.
Wenn ich versuche, zu erkennen, wohin sich die supply chain Welt entwickelt: für mich ähnelt sie dem Wandel, der vor 20 Jahren im Finanzwesen stattfand, als der Handel elektronisch wurde. Menschliche Trader, die einst die Morgenzeitung lasen und per Hand Aktien kauften oder verkauften, wurden durch Quants mit großen automatisierten Portfolios ersetzt. Ich sehe denselben Mechanisierungsprozess für supply chain auf dem Weg, und ich glaube, dass es zur Standardpraxis wird, lange bevor Sie in Rente gehen – sei es nach 61 Arbeitsjahren oder wie auch immer sich die Gesetze ändern. Sie werden immer noch auf viele Unternehmen stoßen, die an älteren Methoden festhalten, aber diese Revolution ist im Gange.
Eine Reihe unserer Kunden lässt das System heute völlig selbstständig laufen. Zum Beispiel können wir Cdiscount nennen, einen großen französischen E-Commerce-Händler: Wir verwalten deren Filialbestände vollständig automatisch, ohne manuelle Eingriffe. Das hält jedoch nicht die laufenden Diskussionen darüber auf, wie man die Rezepte verbessert, aber der tägliche “Plus oder Minus Einheiten”-Ansatz ist beendet. Das endete im Jahr 2020, und es funktioniert auch heute noch.
Daher denke ich, dass wir am Ende einer Ära stehen, in der weltweit etwa fünf Millionen Menschen damit beschäftigt sind, täglich in Excel durch tausend SKUs zu gehen, um zu entscheiden, ob sie order more, mehr produzieren, Inventar verschieben, Preise ändern usw. Alle möglichen Berufsbezeichnungen – inventory manager, demand planner, supply planner, category manager, S&OP analyst – reduzieren sich auf dieselbe tägliche Routine: das Durchgehen einer Menge SKUs. Bei großen Budgets könnten das 100 SKUs pro Person sein; bei kleineren Budgets vielleicht 5.000 SKUs pro Person. So oder so, ich glaube, das geht zu Ende.
Warum jetzt? Weil jahrzehntelang niemand all diese Entscheidungen automatisieren konnte. Aber sobald eine gewisse Anzahl von Unternehmen zeigt, dass es machbar ist, werden andere nachziehen. Es ist extrem kostenintensiv, große manuelle Planungsteams zu unterhalten, und es ist schwierig, strategisch umzuschwenken, wenn Sie Hunderte von Planern in mehreren Ländern neu schulen müssen, die seit 20 Jahren an der gleichen täglichen Tabellenkalkulationsroutine gewöhnt sind. Das zu ändern geht sehr langsam. Aber sobald Sie rein programmatisch vorgehen können, lässt sich schnell umsteuern.
Das steht bevor: derselbe Wandel, den wir im Bankwesen gesehen haben. Früher handelten die Leute den ganzen Tag manuell; heute ist es größtenteils automatisiert. Ich sehe denselben Mechanisierungsprozess für supply chain auf dem Weg, und ich glaube, dass es zur Standardpraxis wird, lange bevor Sie in Rente gehen – sei es nach 61 Arbeitsjahren oder wie auch immer sich die Gesetze ändern. Sie werden immer noch auf viele Unternehmen stoßen, die an älteren Methoden festhalten, aber diese Revolution ist im Gange.
Meine Botschaft ist also, dass Sie entweder ein aktiver Motor dieses Wandels sein können oder einfach nur Mitfahrer. Da Sie Central-Studenten sind, haben Sie wahrscheinlich das Potenzial, aktive Gestalter zu sein, anstatt nur Beobachter.
In Ordnung, vielleicht können wir zu den Fragen übergehen. Ich habe euch einen 50-minütigen Monolog verpasst, also, wenn ihr Fragen dazu habt, nur zu.
Student: Ja, bedeutet das also, dass diese Unternehmen von Lösungen wie Lokad abhängig werden, oder können sie ähnliche Technologien intern entwickeln?
Joannes Vermorel: Beide Möglichkeiten sind möglich. Wenn es sich um ein technikaffines Unternehmen handelt – wie ein sehr großer E-Commerce-Anbieter – schicken sie manchmal Teams, die von uns geschult werden, mit der Idee, die von Lokad angewandten Methoden zu internalisieren. Hat ein Unternehmen eine starke Technologiekultur und entwickelt bereits viel intern, kann es das sicherlich. Aber wenn ihre Kultur lautet „Wir lagern alles aus, was zu knifflig ist“, dann werden sie wahrscheinlich auslagern. Insgesamt denke ich, dass die meisten auf spezialisierte Anbieter setzen werden, sei es Lokad oder andere. Natürlich bin ich voreingenommen – ich würde gerne glauben, dass Lokad zu diesen Lösungen gehört – aber jedenfalls bin ich überzeugt, dass die Revolution in die eine oder andere Richtung stattfindet.
Student: Du hast gesagt, dass LLMs Ingenieure nicht ersetzen würden, sondern nur diejenigen, die LLMs nicht nutzen. Welcher Faktor begrenzt die KI so, dass sie nicht die Ingenieure ersetzen kann, die LLMs nutzen? Anders ausgedrückt: Was hindert die KI daran, Ingenieure zu übertreffen, die selbst KI einsetzen?
Joannes Vermorel: Wenn ich die endgültige Antwort wüsste, wäre sie tausend Milliarden Dollar wert. Über die Jahrzehnte gab es viele Durchbrüche in der künstlichen Intelligenz, die jeweils eine Facette dessen offenbarten, was Intelligenz ist – etwas, das wir nicht vollständig verstanden hatten. Immer wieder erkennen wir, dass wir uns geirrt haben, was „wirkliche“ Intelligenz ausmacht.
Zum Beispiel, wenn man 1940 gefragt hätte, was überlegene Intelligenz zeigt, hätte man geantwortet: „Jemand, der eine Matrix diagonalisieren kann.“ Die École Polytechnique hatte sogar eine Abteilung für das Diagonalisieren von Matrizen, was als Höhepunkt intellektueller Leistung galt. Heute kann ein einfacher Computeralgorithmus eine Matrix diagonalisieren; das sehen wir überhaupt nicht als intelligent an.
Wir hatten in der Geschichte der KI zwanzig solcher Episoden, bei denen wir jedes Mal entdeckten, dass etwas, von dem wir dachten, es sei Intelligenz, es nicht ist. Large Language Models haben derzeit einige auffällige Mängel – etwa dass sie während der Nutzung tatsächlich nichts lernen. Sie sind statische Modelle. Man gibt ihnen eine Eingabeaufforderung, sie liefern eine Fortsetzung, und das war’s. Wiederholt man dieselbe Eingabeaufforderung, erhält man dieselbe Fortsetzung. Sie lernen nicht aus dem Gespräch. Man kann zwar ein Fine-Tuning durchführen, aber das ist ein externer Prozess. Tagtäglich gibt es kein Gedächtnis oder eine beständige Verbesserung. Ein Mensch, der eine Übung macht, lernt etwas dazu; ein LLM tut das nicht. Man kann dasselbe Szenario 200 Mal wiederholen, und es sammelt kein Wissen.
Ein weiterer seltsamer Aspekt ist die enorme Menge an Daten, die LLMs benötigen. Ein Kind lernt in etwa drei Jahren sprechen, mit höchstens vielleicht 1.000 Stunden Zuhören. Ein LLM muss anscheinend das gesamte Internet lesen – Milliarden von Tokens. Oder man betrachtet selbstfahrende Autos: Sie fahren Millionen von virtuellen oder realen Meilen, um etwas zu lernen, was ein Mensch in 20 Stunden Unterricht meistert. Warum so viele Daten für „Intelligenz“?
Wir haben also das Gefühl, dass etwas Fundamentales fehlt, aber wir wissen nicht genau, was. Vielleicht wird die nächste Generation von LLMs oder ein völlig neuer Ansatz diese Mängel beheben, aber wir sind uns nicht sicher, ob das morgen oder in 20 oder 50 Jahren der Fall sein wird. Einige Leute, wie Yann LeCun, sagen, dass wir den gesamten LLM-Ansatz verwerfen und etwas anderes machen sollten. Ich bin da nicht so überzeugt; vielleicht können wir LLMs anpassen, um die Probleme zu beheben. Da noch niemand eine Lösung gefunden hat, wissen wir es einfach nicht.
Jedenfalls sind dies grundlegende Einschränkungen, die verhindern, dass ein LLM einen Menschen vollständig ersetzt, selbst in relativ einfachen Jobs. Also ja, LLMs werden Ingenieure ersetzen, die sich entscheiden, sie nicht zu nutzen; aber sie werden nicht unbedingt die Ingenieure ersetzen, die sie nutzen – diese Personen bleiben unersetzlich.
Student: Früher hast du erwähnt, dass Lokad profitabel blieb, obwohl das Produkt anfangs nicht funktionierte. Wie ist das möglich? Habt ihr Finanzmittel oder Subventionen erhalten? Oder habt ihr andere Dienstleistungen angeboten?
Joannes Vermorel: Nein, keine Subventionen oder externen Finanzmittel. Lassen Sie mich erklären: Der supply chain Markt ist ziemlich verrückt. Typische Geschäftspläne von Konkurrenten seit den 1980er Jahren gehen folgendermaßen vor: Schritt 1, sammle Unmengen an Geld – Dutzende Millionen. Schritt 2, erobere Marktanteile, indem man sich auf eine bestimmte Branche konzentriert, wie etwa aviation, für zwei oder drei Jahre. Schritt 3, stelle 200 Vertriebsmitarbeiter ein, erobere 20% des Marktes und implodiere schließlich. Von vorn beginnen.
Man sieht das ständig. Sogar Giganten wie Nike standen 2004 fast vor dem Bankrott aufgrund eines bekannten supply chain Software-Fiaskos mit einem unserer Konkurrenten. Die „Nike-Katastrophe“ ist auf ihrer Wikipedia-Seite dokumentiert. Im Grunde haben sie neun Monate der Nike-Produktion ruiniert. In der Zwischenzeit hat derselbe Anbieter viele Kunden verpfuscht, wurde aufgekauft, und der Aufkäufer zahlte letztlich 250 Millionen Dollar an Schadensersatz. Meine Erfahrung ist, dass man im Bereich Enterprise-Software, selbst wenn man mittelmäßig ist, normalerweise nicht verklagt wird, sodass diese Jungs wirklich schrecklich gewesen sein müssen. Aber trotz dieser Bilanz haben sie einfach ein neues Unternehmen gegründet – dieselben Leute – und weitere fünfhundert Millionen Dollar eingesammelt. Der Markt lernt nie.
Viele unserer Kunden kommen tatsächlich zu uns, nachdem sie ein halbes Dutzend katastrophaler Versuche bei supply chain Projekten mit verschiedenen Anbietern unternommen haben. Supply chain automation ist ein alter Traum; die zugrunde liegenden Daten wurden bereits in den 80er oder 90er Jahren digitalisiert, sodass sie es seit Jahrzehnten versuchen. Es ist normal, dass große Unternehmen einen Stapel gescheiterter Projekte in ihrem Schrank haben.
Das ist das Umfeld, in dem wir operieren. Es herrscht enorme Trägheit. Die Leute vergessen. Der Bedarf bleibt, also versuchen sie es immer wieder. Der Markt mag aus der Ferne rational erscheinen, aber er ist langsam darin, diese Probleme zu beheben – besonders in einem undurchsichtigen Bereich wie Enterprise-Software. Man kann sogar eine katastrophale Implementierung haben, und dennoch könnte der Kunde Ihnen eine glänzende Fallstudie präsentieren, weil der Manager, der Ihr Produkt ausgewählt hat, nicht verantwortlich gemacht werden möchte. Ironischerweise kann ein Fiasko also als Erfolg in der Marketing-Erzählung dargestellt werden. So chaotisch kann es werden.
Joannes Vermorel: Noch weitere Fragen? Erscheint alles, was ich beschrieben habe, normal, rational – so wie ihr es von der Geschäftswelt erwartet habt?
In Ordnung. Jedenfalls vielen Dank an euch alle für die Zeit, die ihr damit verbracht habt, Envision-Skripte zu programmieren. Ich bin sehr stolz zu sehen, dass die Central-Studenten die Ärmel hochkrempeln und Envision nutzen. Ich hätte niemals gedacht, als ich vor über einem Jahrzehnt den ersten Compiler schrieb, dass ich eines Tages Central-Studenten damit arbeiten sehen würde. Es war damals ein riskantes Spiel; es stand nicht in unserem Geschäftsplan, euch vor Envision zu bringen, aber ich freue mich, dass es passiert ist. Und falls Rémi oder Basil es euch noch nicht gesagt haben: Lokad stellt ein, nur damit ihr es wisst!
