00:00:00 Lokads Gründungsgeschichte und frühe Jahre
00:02:31 Missverständnisse über die Optimierung der Supply Chain
00:04:31 Existierende Supply Chain Theorien funktionierten nicht
00:06:32 Das Paradoxon von Prognosefehlern
00:08:33 Wie “Nichts prognostizieren” die Konkurrenz schlug
00:10:25 Die Herausforderung, etablierte Ideen abzulehnen
00:12:00 Umstellung auf probabilistische Prognosen
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 Technische Probleme bei der Einführung von KI in Unternehmen
00:35:00 Der Einfluss von COVID-19 auf Lieferketten
00:42:49 LLMs sind textbasiert, nicht mathematisch
00:50:25 Die parallele Entwicklung der Finanzbranche
01:09:00 Q&A und abschließende Bemerkungen
Zusammenfassung
Joannes Vermorel, CEO und Gründer von Lokad, hielt einen Vortrag auf Französisch und teilte seine Erfahrungen im Supply Chain Management. Vermorel erzählte von der Gründung von Lokad nach seinem Abschluss an der École Normale Supérieure und dem Wechsel des Fokus von Bioinformatik auf Supply Chain Herausforderungen. Er diskutierte die Entwicklung von Envision, der Programmiersprache von Lokad, und die Entwicklung des Unternehmens seit 2007. Vermorel kritisierte traditionelle Supply Chain Theorien, indem er sie mit Astrologie verglich, und betonte die Bedeutung, Konsens zu hinterfragen. Er hob den Erfolg von Lokad mit probabilistischen Methoden und den Einfluss von COVID-19 auf die Supply Chain Robotisierung hervor. Vermorel sagte das Ende traditioneller Rollen voraus und ermutigte die Studierenden, die Revolution der Branche voranzutreiben.
Erweiterte Zusammenfassung
In einem Vortrag vor Studenten auf Französisch teilte Joannes Vermorel, CEO und Gründer von Lokad, seine Erfahrungen und Einblicke in die Welt des Supply Chain Managements und die Entwicklung seines Unternehmens. Vermorel begann damit, sich vorzustellen und die Ursprünge von Lokad zu erzählen, einem Unternehmen, das er direkt nach seinem Abschluss an der École Normale Supérieure gründete. Anfangs versuchte Vermorel, eine Arbeit in Bioinformatik zu verfolgen, erkannte jedoch bald, dass das Feld bereits mit talentierten Personen gesättigt war. Durch Zufall stieß er auf die Herausforderungen des Supply Chain Managements, die zu seinem neuen Fokus wurden.
Vermorel drückte seine Überraschung und Freude darüber aus, Studenten von Centrale zu sehen, die Envision, eine von ihm für die Optimierung der Supply Chain erstellte Programmiersprache, nutzen. Er erzählte von der Entwicklung von Envision und merkte an, dass der erste Compiler, den er schrieb, schnell durch eine überlegene Version ersetzt wurde, die von Victor Nicolet, dem CTO von Lokad, erstellt wurde. Envision hat sich seitdem erheblich weiterentwickelt, und das Unternehmen steht kurz vor der Veröffentlichung von Version 6.
Der Weg von Lokad begann im Jahr 2007, wobei das Unternehmen offiziell 2008 gegründet wurde. Envision wurde jedoch erst 2013, fünf Jahre nach der Gründung von Lokad, eingeführt. Vermorel erklärte, dass die Entscheidung, eine neue Programmiersprache zu erstellen, getroffen wurde, nachdem alle anderen Alternativen ausgeschöpft waren. Anfangs glaubte er, dass die Supply Chain ein etabliertes Feld mit jahrzehntelanger Literatur und zahlreichen Wettbewerbern wie SAP, Oracle, IBM und Microsoft sei. Er dachte, der Schlüssel zum Erfolg wäre die Neupackung bestehender Supply Chain-Theorien in Webanwendungen, die die Umstellung von Client-Server-Anwendungen auf Cloud-Lösungen nutzen würden.
Trotz seines anfänglichen Vertrauens entdeckte Vermorel bald, dass die etablierten Theorien und Modelle nicht wie erwartet funktionierten. Er erzählte von einer besonders absurden Erfahrung im Jahr 2011, als Lokad einen Benchmark gewann, indem es null Prognosen einreichte, die die Konkurrenten um 20% in Genauigkeit übertrafen. Diese Erfahrung veranlasste Vermorel, die Gültigkeit traditioneller Supply Chain-Theorien in Frage zu stellen und sie eher mit Astrologie als mit Astronomie zu vergleichen.
Vermorel betonte die Bedeutung der Herausforderung des Konsenses in der Wissenschaft und wies darauf hin, dass die Geschichte voll von Beispielen für weit verbreitete, aber letztendlich falsche Überzeugungen ist. Er kam zu dem Schluss, dass die Supply Chain selbst ein legitimes Feld sei, die klassischen Theorien, auf denen sie beruht, jedoch fehlerhaft seien. Diese Erkenntnis veranlasste ihn, alternative Ansätze zu erkunden, wie beispielsweise voreingenommene Prognosen und Quantilvorhersagen, die sich als effektiver erwiesen.
Lokads Ansatz entwickelte sich weiter, um probabilistische und programmatische Methoden zu umfassen, und wandte sich von traditionellen Modellen ab, die die Komplexitäten realer Supply Chain-Probleme nicht bewältigen konnten. Vermorel betonte die Bedeutung einer robusten Programmiersprache, die auf diese Herausforderungen zugeschnitten ist, und kritisierte den Einsatz von Allzwecksprachen wie Python, die oft zu gescheiterten Initiativen aufgrund verschiedener technischer Probleme führten.
Der Vortrag berührte auch die Auswirkungen der COVID-19-Pandemie, die die Robotisierung von Supply Chains beschleunigte. Vermorel merkte an, dass Lokads Lösungen sich in großem Maßstab als wirksam erwiesen haben, indem sie Lagerbestände im Wert von Milliarden von Euro mit minimalem menschlichem Eingriff verwalteten. Diese Veränderung spiegelt den Übergang in der Finanzbranche wider, wo der Handel überwiegend algorithmisch geworden ist.
Vermorel diskutierte die Zukunft des Supply Chain Managements und prognostizierte, dass die traditionellen Rollen von Lagermanagern und Nachfrageplanern obsolet werden würden, da immer mehr Unternehmen automatisierte entscheidungsbasierte Optimierungsprozesse übernehmen. Er ermutigte die Studenten, proaktiv an dieser Revolution teilzuhaben, anstatt sie nur zu beobachten.
In Beantwortung von Studentenfragen erklärte Vermorel, dass Unternehmen mit einem starken technologischen Fokus die Lösungen von Lokad internalisieren könnten, während andere wahrscheinlich weiterhin diese Dienstleistungen auslagern würden. Er ging auch auf die Grenzen großer Sprachmodelle (LLMs) wie ChatGPT ein und wies auf deren Mangel an Lern- und Gedächtniskapazitäten hin.
Vermorel schloss mit einem Rückblick auf die Irrationalität der Märkte und die Beharrlichkeit gescheiterter Projekte in der Supply Chain-Branche. Er teilte Anekdoten von Wettbewerbern, die trotz früherer Misserfolge wiederholt beträchtliche Mittel aufbrachten und betonte die chaotische Natur des Marktes. Trotz dieser Herausforderungen drückte Vermorel Stolz auf die Leistungen von Lokad und den unerwarteten Erfolg von Envision unter Studenten von renommierten Institutionen wie Centrale aus. Er lud die Studenten ein, in Betracht zu ziehen, sich Lokad anzuschließen, und betonte die laufenden Bemühungen des Unternehmens um Rekrutierung.
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 habe das Unternehmen gegründet, als ich die Schule beendet habe. Ich war an der École Normale Supérieure, habe mit einem Doktor in Bioinformatik begonnen, aber am Ende haben so viele interessante Dinge in der Bioinformatik gemacht, dass sie mich wahrscheinlich nicht gebraucht haben. Und durch Zufall bin ich auf diese Supply-Chain-Probleme gestoßen. Ich bin sehr glücklich zu sehen, dass Sie heute Envision benutzt haben. Es ist für mich etwas Besonderes, mich vor Studenten der Centrale zu sehen, die über diese Sprache sprechen. Das hätte ich mir damals, als ich Envision erstellt habe, vor etwa zwölf Jahren, nie vorstellen können.
Ich habe den ersten Envision-Compiler geschrieben, dann hat Victor Nicolet, Lokads CTO, ihn verworfen und schnell den zweiten Compiler geschrieben, der viel besser war. Und jetzt verwenden Sie im Grunde genommen Version 5, während Version 6 kurz vor der Veröffentlichung steht. Die Sprache hat sich stark weiterentwickelt. Aber woran Sie gearbeitet haben - das Stück, das Sie gesehen haben - war überhaupt nicht der Ausgangspunkt von Lokad. Es kam tatsächlich ziemlich spät. Lokad ist ein Projekt, das 2007 begann und 2008 gegründet wurde, während Envision etwa aus dem Jahr 2013 stammt. Als Envision ankam, war das Unternehmen also bereits etwa fünf Jahre alt.
Die Idee, eine Sprache zu erstellen, kam, nachdem wir alle anderen Alternativen erschöpft hatten; es war nicht der Plan des visionären Gründers von Anfang an - einfach dass alles andere, was wir versucht hatten, gescheitert war.
Um Ihnen eine Vorstellung davon zu geben, was an der Supply Chain so überraschend ist: Als ich Lokad 2008 gründete, war meine Ansicht, dass die Supply Chain ein etabliertes Feld sei. Immerhin gibt es 60 oder 70 Jahre Literatur darüber, buchstäblich Millionen von Papieren. Wenn Sie “Supply Chain Management” bei Amazon eingeben, erhalten Sie - ich habe nachgeschaut - etwa 10.000 Bücher zum Thema. Im Laufe der Jahrzehnte wurden viele weitere veröffentlicht, aber diese 10.000 sind diejenigen, die derzeit noch zum Verkauf stehen. Es ist ein sehr dokumentiertes Feld.
Als ich anfing, sah ich große Wettbewerber mit großen Namen: SAP, Oracle, IBM, sogar Microsoft - große Player in der Supply Chain. Wenn Sie den Gesamtumsatz Ihrer Wettbewerber zusammenzählen, sind es eine halbe Billion Dollar. Das ist signifikant. Meine ursprüngliche Intuition - die sich als völlig falsch herausstellte - war, dass ich die etablierten Supply-Chain-Theorien nehmen und einfach in eine Web-App verpacken könnte. Es war 2008, und alle Unternehmenssoftware wechselte von sogenannten “dicken Client”-Apps, die auf Ihrem PC installiert sind, zu “dünnen Client”-Apps, d.h. Web-Apps. Es gab also die Möglichkeit, die Supply-Chain-Software als Web-App neu aufzubauen, möglicherweise mit Cloud-Hosting. Lokad ist sehr früh in die Cloud umgezogen. Das könnte uns einen Vorsprung gegenüber großen Unternehmen verschaffen, die immer noch auf älteren, schwereren Client-basierten Systemen sind. 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 - habe ich sie gelesen, all diese 1.000-seitigen Bände, die von zwei oder drei Professoren mit all den Gleichungen geschrieben wurden.
Ich habe dann diese Ansätze codiert - und nichts hat funktioniert. Interessanterweise hat das Lokad nicht daran gehindert zu wachsen oder Kunden zu haben. Man würde denken, dass man als Startup Geld verdienen muss, um ein Produkt zu haben, das tatsächlich funktioniert, aber in der Unternehmenssoftware können Sie etwas verkaufen, das überhaupt nicht funktioniert, und trotzdem Kunden finden. Es 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 zu versuchen, es zu lösen. Dieses Budget muss nicht riesig sein - insbesondere wenn Ihr Produkt tatsächlich nicht funktioniert -, aber für ein Startup können diese Summen sehr groß erscheinen. Wenn ein Riese wie Carrefour 100.000 Euro auf den Tisch legt “nur um zu sehen”, ist das nichts für Carrefour, aber für ein kleines Unternehmen ist das viel.
Also, unter Ausnutzung dieser Asymmetrie begann ich und versuchte, diese standardmäßigen Supply-Chain-Theorien umzusetzen: Zeitreihen Prognosen, Sicherheitsbestand, Optimierung des Servicelevels usw. Nichts davon hat funktioniert; überhaupt nichts. Wir hatten diese eher schizophrenen Diskussionen mit Kunden: Sie sagten: “Sie müssen die Sicherheitsbestand-Formel falsch codiert haben”, also gingen wir zurück, nahmen buchstäblich die Werte aus den Tabellen in den Lehrbüchern, überprüften die Parameter erneut - und es war genau wie angegeben. Die Theorie wurde also korrekt umgesetzt, aber das Ergebnis war völliger Unsinn.
Ich denke, der Gipfel des Unsinn kam im Sommer 2011. Wir nahmen an einem großen RFP 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, soweit ich mich erinnere, betraf zehn Supermärkte, 5.000 SKUs pro Supermarkt, mit der Notwendigkeit, ein paar Tage im Voraus zu prognostizieren, da diese Supermärkte vielleicht zwei oder drei Mal pro Woche aufgefüllt wurden. Der Kunde verwendete ein Backtesting Fehlerkriterium für tägliche Produktprognosen auf Produktebene für jeden Laden - im Grunde genommen absoluter Fehler zwischen Prognose und tatsächlichem Wert. Lokad gewann diesen Benchmark - um 20% genauere Genauigkeit, und zerschmetterte absolut die Konkurrenz. Mein Geheimnis? Ich schickte Nullen zurück. Null für alles. Dank meiner “Nullprognose” habe ich auch alle anderen in der Berechnungsgeschwindigkeit geschlagen: Das Zurücksenden von Nullen ist extrem schnell. Und ich erzielte eine 20% bessere Prognosegenauigkeit als die anderen. Noch besser, wenn Sie null Nachfrage prognostizieren, füllen Sie den Laden nicht auf, sodass der Laden in zwei Wochen leer ist, was Ihrer Prognose zu 100% entspricht. Ich war der König der Statistik.
Offensichtlich war das völliger Unsinn. Aber wenn Sie den Ansatz berücksichtigen, der von allen Supply-Chain-Lehrbüchern und dem Standardprozess des Kunden empfohlen wird, führte dies zu völligem Unsinn. Die Schlussfolgerung, die ich daraus zog, war ziemlich beunruhigend. Wir hatten ein profitables, wachsendes Unternehmen, aber ich musste erkennen, dass ich möglicherweise auf ein Schema gestoßen war. Sie können etwas starten, Geld verdienen, aber es ist reiner Unsinn. Vielleicht sind Sie anfangs einfach zu unerfahren, um es zu erkennen. Aber wenn Sie es erst einmal erkennen, machen Sie weiter? Wenn Sie abschließen und feststellen, dass das, was Sie tun, Unsinn ist, machen Sie weiter? Das löste tiefgreifende Fragen aus. Könnte Supply Chain einfach Astrologie sein - wie die Wahrsagerei, nicht die Astronomie?
Schließlich kam ich zu dem Schluss, dass Supply Chain als Feld real ist, aber dass die Standard-Supply-Chain-Theorie im Grunde genommen Astrologie ist. Das war der Fehler. Es ist sehr schwer zu akzeptieren, dass 70 Jahre Forschung, über eine Million Artikel, Tausende von Professoren, alle falsch liegen könnten. Stellen Sie sich die intellektuelle Arroganz vor, die dafür nötig ist. Wenn Sie vier verschiedene Ärzte sehen, von denen jeder Ihnen die gleiche Diagnose mitteilt, wann sagen Sie, dass sie alle falsch liegen und Sie richtig liegen? Aber Wissenschaft funktioniert nicht auf Konsens. Tausend Menschen können sich auf etwas einigen und trotzdem falsch liegen. Die Geschichte der Wissenschaft ist voll von Beispielen: extrem breiter Konsens über Ideen, die sich als verrückt herausstellten. Einige, die die Geschichte der Wissenschaft studieren, sagen sogar, dass die Hälfte von dem, was eine Gesellschaft zu einem bestimmten Zeitpunkt glaubt, falsch ist; der schwierige Teil ist zu wissen, welche Hälfte.
So kam Lokad schließlich zu diesem Schluss aus dem Benchmark: Der Mainstream-Weg war Unsinn. Wir mussten nach etwas anderem suchen. Unser großer Durchbruch kam Anfang 2012, als wir voreingenommene Prognosen mit dem sogenannten Quantil-Prognosen angingen. Zu der Zeit hatten meine Kunden 50 Mitarbeiter Vollzeit beschäftigt, nur um Voreingenommenheit zu beseitigen. Also fragten sie mich: “Warum zum Teufel würden Sie eine voreingenommene Prognose wollen, wenn wir Leute bezahlen, um sie zu entzerren?” Sie waren ziemlich alarmiert, weil die neue Methode so viel Voreingenommenheit hinzufügte, dass sie sie nie manuell entfernen könnten. Aber wenn ich es “Quantil-Prognose” nenne, klingt es wissenschaftlicher als “voreingenommene Prognose”. In Wirklichkeit ist eine Quantil-Prognose jedoch nur eine voreingenommene Prognose.
Wir haben diesen Ansatz mit unserem ersten E-Commerce-Kunden ausprobiert. Über Nacht wechselten wir von absurden Ergebnissen - wie der Prognose von Null für alles - zu etwas Mittelmäßigem, aber zumindest einigermaßen sinnvoll. Das mag nicht erstaunlich klingen, aber der Schritt von totaler Absurdität zu bloßer Mittelmäßigkeit war ein großer Fortschritt.
Das führte uns dann dazu, alle in Lehrbüchern gefundenen Annahmen der Supply Chain zu überdenken - jede Grundlage in Frage zu stellen, die sich als sehr wackelig, im Grunde falsch herausstellte. Die Quantil-Prognose ist nur die einfache Version davon. Es ist ein statistisches Werkzeug, das sich speziell mit Extremen befasst. Wirtschaftlich gesehen sind in der Supply Chain die Extreme der Bereich, in dem das Geld verloren geht: unerwartet hohe Nachfrage, die einen Lagerbestand verursacht, unerwartet niedrige Nachfrage, die Überbestände verursacht, unerwartet lange Durchlaufzeiten, die Ihre Pläne ruinieren, usw. Es ist nie der Mittelwert der Verteilung, der Ihnen wirklich schadet; es sind die Ränder. Eine Quantil-Prognose ist ein Werkzeug, das sich auf diese Extreme konzentriert. Eine verbesserte Version ist die probabilistische Prognose - an der Sie gearbeitet haben - bei der Sie eine vollständige Wahrscheinlichkeitsverteilung erhalten. 2012 begannen wir mit Quantil-Prognosen, weil es einfacher in Bezug auf Mathematik, Statistik und Berechnung war. Die Handhabung einer Wahrscheinlichkeitsverteilung über Millionen von SKUs ist viel aufwändiger als die Erstellung einer einzelnen Prognosezahl pro SKU.
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 für die Umsetzung des neuen Ansatzes. Davor war die Idee von Lokad, Standard-Supply-Chain-Software mit Menüs, Schaltflächen und Optionen zu entwickeln, wie es in Unternehmenssoftware üblich ist. Aber aus Sicht des Softwareherstellers war es Chaos: Je mehr Funktionalitäten hinzukamen, desto schwieriger wurde das Datenmapping von der Umgebung des Kunden zu Ihren Datenstrukturen.
Warum? Weil die Datenarchitekturen der Kunden immer einzigartig sind. Das ERP eines Kunden könnte beispielsweise 10.000 Tabellen haben, jede mit 50 Feldern, viele undokumentiert, die auf ungewöhnliche Weise verwendet werden. Tatsächlich könnten sie zwei oder drei ERPs haben, plus ein WMS, plus eine E-Commerce-Plattform… Das Ökosystem ist kompliziert. Keine zwei Unternehmen haben die gleichen Datendefinitionen. Selbst 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ätigt hat, Datum, an dem Sie sie bestätigt haben, Datum, an dem der Zahlungsanbieter sie autorisiert hat, Datum, an dem die Bestellung versandt wurde, usw. Multiplizieren Sie das mit tausend anderen potenziellen Datenfeldern.
Wenn Sie ein “klassisches” Stück Software mit festen Definitionen für Produkt, SKU, Varianten, Lieferanten, Standort usw. erstellen, entsprechen diese Definitionen selten der Realität des Kunden. Selbst innerhalb der Bekleidungsbranche könnte ein Unternehmen Varianten rein als Farbe und Größe definieren, während ein anderes auch die Stoffzusammensetzung einschließt. Oder im Lebensmittelhandel könnte “Ablaufdatum” bedeuten, an welchem Tag es absolut nicht verkauft werden kann, oder an welchem Tag es nicht im Geschäft ausgestellt werden kann. Es gibt unendlich viele Feinheiten.
Deshalb stellte sich heraus, dass die standardmäßigen Supply-Chain-Theorien unzureichend waren. Wir brauchten etwas Neues: einen programmatischen Ansatz. Dies ist etwas, mit dem sich Lehrbücher zur Supply Chain nie befassen. Vorgefertigte Modelle helfen nicht, weil die reale Welt nie perfekt zu diesen Modellen passt. Es gibt immer etwas - Mindestbestellmenge, Verfallsbeschränkungen, Versandzeitplanbeschränkungen. Die Beschränkungen jedes Unternehmens sind einzigartig. Also erkannten wir, dass die Lösung programmatisch ist, nicht eine statische Formel. Die Frage lautete also: Was ist das richtige Programmierparadigma für die Supply Chain?
Im Jahr 2012 könnten die Leute sagen: “Warum nicht einfach Python verwenden?” Tatsächlich war das damals genau das, was alle meine amerikanischen E-Commerce-Kunden taten. Fast jede Datenwissenschaftsinitiative, die ich zu dieser Zeit sah, scheiterte aufgrund von Python (oder es hätte auch Java, C# oder später Julia sein können - es ist dasselbe Problem). Das Muster war folgendes: In drei Wochen erstellt ein Datenwissenschaftsteam einen beeindruckenden Prototyp für ein bestimmtes 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, bricht das Projekt ab, das war’s.
Warum ist es gescheitert? Tod durch tausend Schnitte: NullReferenceException, OutOfQuotaException, Probleme mit Nebenläufigkeit, inkompatible Pakete, Sicherheitsverletzungen, 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 riesig ist. Wenn Sie beispielsweise aus Ihrem Code auf das Dateisystem schreiben können, können Sie versehentlich die Umgebung beschädigen, die Ihren Code hostet - leicht zu tun, wenn Sie gleichzeitig Gigabyte an Daten verarbeiten. Vielleicht ist eine Datei von einem Prozess gesperrt oder eine Festplatte ist voll, und so weiter. Diese Dinge passieren unweigerlich mitten in der Nacht, ohne dass jemand da ist, um es sofort zu beheben. Dann, am Morgen, ist der Kunde wütend, weil er erwartet hatte, dass das System um 2 Uhr morgens fertig wird, aber um Mitternacht abgestürzt ist.
In Datenwissenschaftsdemos haben Sie normalerweise einen Aufpasser, der das Skript startet, sodass sie es reparieren können, wenn es abstürzt. Aber die Automatisierung der Supply Chain in der realen Welt muss jeden Tag unbeaufsichtigt laufen. Selbst die Laufzeiten können von 20 Minuten bis zu zwei Stunden schwanken, was die Produktion unterbricht. Das war das Problem im Jahr 2012: Diese Datenwissenschaftsinitiativen würden in der Produktion aufgrund der breiten Komplexität von allgemeinen Programmiersprachen scheitern, nicht aufgrund der Supply-Chain-Logik selbst.
All das führte Lokad dazu zu erkennen, dass wir eine programmatische Umgebung benötigten, die sicher und spezialisiert genug war, um groß angelegte tägliche Operationen ohne fragile Überwachung zu bewältigen. Außerdem, als wir erkannten, dass wir auch fortgeschrittene Prognosen (probabilistisch, Quantil usw.) durchführen mussten, wurde Envision eingerichtet, um diese Workflows als Bürger erster Klasse zu behandeln. Wenn Sie beispielsweise differenzierbares Programmieren für maschinelles Lernen möchten, betten Sie in einer allgemeinen Programmiersprache eine weitere “Mini-Sprache” wie PyTorch ein. Dann haben Sie Python plus einen Teil des PyTorch-Codes, und es ist einfach, Fehler zu machen, weil Ihr PyTorch-Code im Wesentlichen ein nicht kompilierter 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 Funktionen mit Kompilierungsprüfungen behandeln.
Lokads Ansatz entwickelte sich parallel zu Fortschritten wie dem Deep Learning, bei dem Sie nicht mehr nur eine Bibliothek vorgefertigter Modelle haben, sondern Ihr eigenes Modell programmatisch erstellen. TensorFlow ist im Wesentlichen eine Sprache zur Konstruktion von Berechnungsgraphen. Sie sind nicht auf einen “Katalog” von Modellen beschränkt; Sie bauen Strukturen. Envision kann diese Ideen ebenfalls nativ integrieren. Wir haben beispielsweise kürzlich an stochastischer Optimierung gearbeitet. Weiß hier jemand, was das ist? Es handelt sich um die mathematische Optimierung einer Funktion, deren Ergebnis unsicher ist - wie die Entscheidung, wie viele Einheiten gekauft werden sollen, wenn die zukünftige Nachfrage unbekannt ist. Das ist eine klassische Herausforderung in der Supply Chain. Sie haben einfachere Versionen mit minimalen Einschränkungen gesehen, aber echte Unternehmen haben eine Vielzahl von Einschränkungen: Mindestbestellmengen, Containerfüllraten, Kategoriebeschränkungen oder komplizierte Kalender. Darüber hinaus ist Ihre Kosten/Nutzen-Funktion unsicher. Daher handelt es sich um fortgeschrittene programmatische Konzepte.
Insgesamt hat Envision ständig Funktionen hinzugefügt. Heute stehen wir auch an der Schwelle zu einer weiteren Revolution: großen Sprachmodellen (LLMs). Sie sind wahrscheinlich mit ChatGPT vertraut. Vielleicht verwenden einige von Ihnen es, um Ihre Hausaufgaben zu machen. (Ich bewerte Sie nicht, also können Sie es zugeben!) Oder sogar für die Pro-Version bezahlen. Der interessante Teil für uns ist, dass Lokad eine Schreibkultur hat, was für ein Supply-Chain-Unternehmen ziemlich ungewöhnlich ist. Wir verlassen uns auf Text auf zwei Ebenen. Erstens haben wir den Envision-Code selbst, der buchstäblich “codiert”, was wir tun. Wir möchten keinen Prozess, der empfohlene Bestellungen in Excel generiert und dann von Hand geändert wird. Unser Ziel ist es, dass die endgültigen Zahlen automatisch generiert werden, ohne manuelle Änderungen. Und wenn Änderungen erforderlich sind - manchmal sind sie das, anfangs -, werden diese Änderungen in einem Workflow erfasst, damit wir mit dem Kunden diskutieren können: “Warum haben Sie das geändert, was generiert wurde? Was könnten wir ändern, damit manuelle Bearbeitungen nicht mehr erforderlich sind?” Oder manchmal sehen wir, dass die Änderungen tatsächlich nicht hilfreich waren, sodass wir auch dieses Wissen integrieren können.
Dann haben wir ein zweites Textartefakt, das JPM oder Joint Process Manual, das das “Warum” erklärt. Es ist unser Referenzdokument für Übergaben und um dem Kunden einen Gesamtüberblick über die Initiative in einfacher Sprache zu geben - ohne dass er den Envision-Code direkt lesen muss. Wir haben also eine Code-Ebene, die “was” beschreibt, und eine separate Dokumentenebene, die “warum” erklärt.
Das passt ziemlich gut zu LLMs, weil LLMs Text verarbeiten. Sie sind nicht so gut mit rein numerischen Daten. Wenn Sie eine riesige Tabelle in ChatGPT werfen, erhalten Sie keine sinnvolle Regression. ChatGPT kann nur ein Stück Python-Code generieren, das die Regression durchführen würde. LLMs selbst sind nur riesige Modelle zur Vorhersage des nächsten Tokens; sie sind nicht für Arithmetik ausgelegt. Daher die Witze über ChatGPT, die bei einfacher Mathematik versagen. Aber wenn Sie ihnen Code oder textbasierte Anweisungen geben, sind sie ziemlich gut in der Manipulation und Generierung.
Das ist also der Stand von Lokad: Wir haben fortschrittliche Supply-Chain-Automatisierungen, die monatelang ohne menschliches Eingreifen laufen können - etwas, das während der Lockdowns von 2020-2021 bewiesen wurde, als viele unserer Kunden ihre Angestellten im Büro nach Hause schickten. In der Zwischenzeit musste die Supply Chain weiterhin funktionieren, da die Arbeiter in Lagern und LKWs weiterhin aktiv waren. Lokad funktionierte bereits weitgehend remote, sodass unsere Supply-Chain-Wissenschaftler von zu Hause aus arbeiten konnten. Das war der eigentliche Stresstest: zu sehen, wie unsere Rezepte ohne tägliche Überwachung funktionieren 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 hat es überraschend gut funktioniert. Keiner unserer Kunden ist daran gestorben - niemand ist verschwunden. Das wirft die Frage auf: Wenn Sie Ihre Supply Chain 12 oder 14 Monate lang ohne 500 Angestellte im Büro betreiben können, brauchen Sie sie dann überhaupt zurück? Dies war ein Experiment, das wir sonst nie hätten durchführen können, da Unternehmen normalerweise Angst haben, einem automatisierten System vollständig zu vertrauen. Aber die Lockdowns zwangen sie effektiv dazu, sich auf Automatisierung zu verlassen, was bewies, dass wir massive Supply Chains mit minimalem oder sogar ohne manuelles Eingreifen betreiben können. Natürlich diskutieren wir weiterhin Möglichkeiten zur Verbesserung der numerischen Rezepte; es gibt keine Null-Zusammenarbeit. Aber man sieht nicht mehr große Teams, die täglich Excel-Änderungen an jedem SKU in jedem Geschäft vornehmen.
Wenn ich also versuche zu sehen, wohin die Welt der Supply Chain steuert: Für mich ähnelt es dem Wandel, der vor 20 Jahren im Finanzwesen stattfand, als der Handel elektronisch wurde. Menschliche Händler, die früher die Morgenzeitung lasen, entschieden per Hand, ob sie eine Aktie kaufen oder verkaufen sollten - das wurde durch Quants mit großen automatisierten Portfolios ersetzt. Ich sehe die gleiche Transformation in der Supply Chain. Wir haben diesen alten Traum verwirklicht - die Mechanisierung von Supply-Chain-Entscheidungen. Das war die ursprüngliche Ambition der Operationsforschung (dem “Vorfahren” der Supply Chain) in den 1940er, 50er und 60er Jahren. Im Laufe der Zeit wurde die “Operationsforschung” zu einer eigenen Teildisziplin, die sich auf Solver konzentrierte, aber wenn man sich die frühe Vision ansieht, ist es genau das, was die Supply Chain will: Mathematik, numerische Optimierung, Ressourcenzuweisung. Wir haben vor fast zehn Jahren eine Version davon bei Lokad erreicht. Die Lockdowns waren unser echter Beweis, dass es im großen Maßstab funktioniert, sogar über ein Jahr ohne direkte Überwachung.
Einige unserer Kunden lassen das System heute vollständig von selbst laufen. Zum Beispiel können wir Cdiscount, einen großen französischen E-Commerce-Händler, nennen: Wir verwalten den Lagerbestand für sie vollautomatisch, ohne manuelles Eingreifen. Das hindert jedoch nicht daran, laufend darüber zu diskutieren, wie man die Rezepte verbessern kann, aber der tägliche Ansatz “plus oder minus Einheiten” ist vorbei. Das endete 2020 und funktioniert immer noch.
Als Ergebnis glaube ich, dass wir am Ende einer Ära stehen, in der weltweit etwa fünf Millionen Menschen damit beschäftigt sind, täglich tausend SKUs in Excel durchzugehen, um zu entscheiden, ob sie mehr bestellen, produzieren, Lagerbestände verschieben, Preise ändern usw. Alle möglichen Berufsbezeichnungen - Lagermanager, Bedarfsplaner, Supply Planner, Category Manager, S&OP-Analyst - reduzieren sich auf die gleiche tägliche Routine: einen Teil der SKUs durchgehen. Mit großen Budgets könnten das 100 SKUs pro Person sein; mit kleineren Budgets vielleicht 5.000 SKUs pro Person. So oder so glaube ich, dass dies ein Ende hat.
Warum jetzt? Weil jahrzehntelang niemand all diese Entscheidungen automatisieren konnte. Aber sobald eine bestimmte Anzahl von Unternehmen zeigt, dass es möglich ist, werden andere folgen. Es ist extrem kostspielig, große manuelle Planungsteams zu unterhalten, außerdem ist es schwierig, strategisch umzusteuern, wenn man Hunderte von Planern in verschiedenen Ländern neu schulen muss, von denen jeder daran gewöhnt ist, 20 Jahre lang die gleiche tägliche Tabellenkalkulationsroutine durchzuführen. Eine Änderung dauert sehr lange. Aber wenn Sie rein programmatisch vorgehen können, können Sie schnell umlenken.
Das steht bevor: Der gleiche Wandel, den wir im Bankwesen gesehen haben. Früher haben Menschen den ganzen Tag manuell gehandelt; jetzt ist es größtenteils automatisiert. Ich sehe die gleiche Mechanisierung auch für die Supply Chain kommen, und ich glaube, dass sie lange vor Ihrem Ruhestand Standardpraxis sein wird - wenn Sie nach 61 Jahren Arbeit in den Ruhestand gehen oder wie auch immer sich die Gesetze ändern. Sie werden immer noch auf viele Unternehmen stoßen, die in älteren Methoden stecken geblieben sind, aber diese Revolution ist im Gange.
Also meine Botschaft ist, dass Sie entweder ein aktiver Treiber dieses Wandels sein können oder nur ein Passagier. Da Sie Studenten des Central sind, haben Sie wahrscheinlich das Potenzial, aktive Treiber zu sein, anstatt nur Beobachter.
Gut, vielleicht können wir jetzt zu den Fragen übergehen. Ich habe Ihnen eine 50-minütige Monolog aufgezwungen, also wenn Sie Fragen zu alldem haben, bitte nur zu.
Student: Ja, bedeutet das, dass diese Unternehmen von Lösungen wie Lokad abhängig werden, oder können sie ähnliche Technologien intern entwickeln?
Joannes Vermorel: Beides ist möglich. Wenn es sich um ein technikaffines Unternehmen handelt - wie zum Beispiel ein sehr großer E-Commerce-Anbieter - schicken sie manchmal Teams zu uns, um von uns geschult zu werden, mit dem Ziel, die Art von Praktiken zu internalisieren, die Lokad anwendet. Wenn ein Unternehmen eine starke Technikkultur hat und bereits viel intern entwickelt, können sie es sicherlich tun. Aber wenn ihre Kultur lautet “Wir lagern alles aus, was zu knifflig ist”, dann werden sie wahrscheinlich auslagern. Insgesamt denke ich, dass die meisten sich für spezialisierte Anbieter entscheiden werden, ob das nun Lokad oder andere sind. Natürlich bin ich voreingenommen - ich möchte glauben, dass Lokad zu diesen Lösungen gehören wird - aber auf jeden Fall bin ich überzeugt, dass die Revolution stattfindet, auf die eine oder andere Weise.
Student: Sie haben gesagt, dass LLMs Ingenieure nicht ersetzen würden, nur diejenigen, die keine LLMs verwenden. Welcher Faktor begrenzt KI so, dass sie Ingenieure, die selbst LLMs verwenden, nicht ersetzen kann? Mit anderen Worten, was hindert KI daran, Ingenieure zu übertreffen, die selbst KI verwenden?
Joannes Vermorel: Wenn ich die definitive Antwort wüsste, wäre sie tausend Milliarden Dollar wert. Im Laufe der Jahrzehnte gab es viele Durchbrüche in der künstlichen Intelligenz, die jedes Mal eine Facette dessen aufdeckten, was Intelligenz ist - was wir nicht vollständig verstanden hatten. Immer wieder erkennen wir, dass wir uns geirrt haben, was “echte” Intelligenz ausmacht.
Wenn Sie zum Beispiel im Jahr 1940 gefragt hätten, was überlegene Intelligenz zeigt, hätten sie vielleicht gesagt: “Jemand, der eine Matrix diagonalisieren kann.” Die École Polytechnique hatte sogar eine Abteilung für die Diagonalisierung von Matrizen, die als Höhepunkt intellektueller Leistung angesehen wurde. Heute kann ein einfacher Computeralgorithmus eine Matrix diagonalisieren; das betrachten wir überhaupt nicht als intelligent.
Wir hatten zwanzig solcher Episoden in der Geschichte der KI, jedes Mal entdeckten wir, dass etwas, von dem wir dachten, dass es “Intelligenz” sei, es nicht ist. Große Sprachmodelle haben derzeit einige gravierende Mängel - wie zum Beispiel, dass sie während des Gebrauchs tatsächlich nichts lernen. Sie sind statische Modelle. Sie können ihnen eine Eingabe geben, sie geben Ihnen eine Fortsetzung, und das war’s. Wenn Sie dieselbe Eingabe erneut verwenden, erhalten Sie dieselbe Fortsetzung. Sie lernen nicht aus dem Gespräch. Sie können Feinabstimmungen vornehmen, ja, aber das ist ein externer Prozess. Tag für Tag gibt es kein Gedächtnis oder keine anhaltende Verbesserung. Ein Mensch, der eine Übung macht, lernt etwas; ein LLM nicht. Sie können das gleiche Szenario 200 Mal wiederholen, und es sammelt kein Wissen an.
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 betrachten Sie selbstfahrende Autos: Sie fahren Millionen von virtuellen oder realen Meilen, um zu lernen, was ein Mensch in 20 Stunden Unterricht beherrscht. Warum so viele Daten für “Intelligenz”?
Also spüren wir, dass etwas Grundlegendes fehlt, aber wir wissen nicht genau was. Vielleicht wird die nächste Iteration 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, wir sollten den gesamten LLM-Ansatz über Bord werfen und etwas anderes tun. Ich bin mir da nicht so sicher; vielleicht können wir LLMs anpassen, um die Probleme zu lösen. Da noch niemand eine Lösung hat, wissen wir es einfach nicht.
Wie auch immer, das sind tiefe Einschränkungen, die verhindern, dass ein LLM einen Menschen vollständig ersetzt, selbst in relativ einfachen Jobs. Ja, LLMs werden Ingenieure ersetzen, die sich entscheiden, sie nicht zu verwenden; aber sie werden nicht unbedingt die Ingenieure ersetzen, die sie verwenden - diese Personen werden unverzichtbar bleiben.
Student: Früher hast du erwähnt, dass Lokad profitabel geblieben ist, obwohl das Produkt anfangs nicht funktioniert hat. Wie ist das möglich? Habt ihr Finanzierung oder Subventionen erhalten? Oder habt ihr andere Dienstleistungen angeboten?
Joannes Vermorel: Nein, keine Subventionen oder externe Finanzierung. Lass mich erklären: Der Supply-Chain-Markt ist irgendwie verrückt. Typische Geschäftspläne von Wettbewerbern seit den 1980er Jahren sehen so aus: Schritt 1, viel Geld sammeln - zig Millionen. Schritt 2, Markanteil durch Fokussierung auf einen bestimmten Bereich wie Luftfahrt für zwei oder drei Jahre gewinnen. Schritt 3, 200 Verkäufer einstellen, 20% des Marktes erobern und schließlich implodieren. Spülen und wiederholen.
Wir sehen das ständig. Selbst Giganten wie Nike standen 2004 fast vor dem Bankrott aufgrund eines bekannten Software-Fiaskos in der Lieferkette mit einem unserer Wettbewerber. Das “Nike-Desaster” ist auf ihrer Wikipedia-Seite dokumentiert. Sie haben praktisch neun Monate der Produktion von Nike vermasselt. In der Zwischenzeit hat derselbe Anbieter viele Kunden verärgert, wurde übernommen und der Übernehmer musste am Ende 250 Millionen Dollar Schadensersatz zahlen. Meine Erfahrung ist, dass man in der Unternehmenssoftware, selbst wenn man mittelmäßig ist, normalerweise nicht verklagt wird, also müssen diese Typen wirklich schrecklich gewesen sein. Aber trotz dieser Erfolgsbilanz haben sie einfach ein neues Unternehmen gegründet - dieselben Leute - und weitere eine halbe Milliarde Dollar eingesammelt. Der Markt lernt nie dazu.
Viele unserer Kunden kommen tatsächlich zu uns, nachdem sie eine halbe Dutzend desaströse Versuche mit Lieferkettenprojekten mit verschiedenen Anbietern unternommen haben. Die Automatisierung der Lieferkette ist ein alter Traum; die zugrunde liegenden Daten sind seit den 80er oder 90er Jahren digitalisiert, also versuchen sie es seit Jahrzehnten. Es ist normal, dass große Unternehmen eine Reihe gescheiterter Projekte in ihrem Schrank haben.
Das ist die Umgebung, in der wir arbeiten. Es gibt eine enorme Trägheit. Die Leute vergessen. Der Bedarf bleibt bestehen, also versuchen sie es immer wieder. Der Markt mag aus der Ferne rational erscheinen, aber er ist langsam darin, diese Probleme zu beheben - insbesondere in einem undurchsichtigen Bereich wie der Unternehmenssoftware. Sie können sogar eine katastrophale Implementierung haben, und der Kunde könnte Ihnen trotzdem eine glänzende Fallstudie geben, weil der Manager, der Ihr Produkt gewählt hat, nicht beschuldigt werden möchte. Ironischerweise kann ein Fiasko in der Marketingnarrative als Erfolg dargestellt werden. So chaotisch kann es werden.
Joannes Vermorel: Noch weitere Fragen? Erscheint euch alles, was ich beschrieben habe, normal, rational - wie ihr es aus der Geschäftswelt erwartet habt?
Gut. Nun, auf jeden Fall vielen Dank für die Zeit, die ihr damit verbracht habt, Envision-Skripte zu codieren. Ich bin sehr stolz darauf, Central-Studenten zu sehen, die die Ärmel hochkrempeln und Envision verwenden. Ich hätte mir wirklich nie vorstellen können, als ich vor über einem Jahrzehnt den ersten Compiler geschrieben habe, dass ich eines Tages Central-Studenten damit arbeiten sehen würde. Es war damals ein riskanter Einsatz; es war nicht in unserem Geschäftsplan vorgesehen, euch vor Envision zu setzen, aber ich bin begeistert, dass es passiert ist. Und wenn euch Rémi oder Basil noch nicht gesagt haben: Lokad stellt ein, nur damit ihr Bescheid wisst!
