00:28 Einführung
00:43 Robert A. Heinlein
03:03 Bisherige Geschichte
06:52 Eine Auswahl von Paradigmen
08:20 Statische Analyse
18:26 Array-Programmierung
28:08 Hardware-Mischbarkeit
35:38 Probabilistisches Programmieren
40:53 Differenzierbares Programmieren
55:12 Versionierung von Code+Daten
01:00:01 Sichere Programmierung
01:05:37 Abschließend: Werkzeuge sind auch in der Supply Chain wichtig
01:06:40 Bevorstehende Vorlesung und Fragen aus dem Publikum
Beschreibung
Während die herkömmliche supply chain theory in Unternehmen insgesamt Schwierigkeiten hat, sich durchzusetzen, hat ein Werkzeug – nämlich Microsoft Excel – beträchtlichen operativen Erfolg erzielt. Die Neuimplementierung der numerical recipes der herkömmlichen supply chain theory mittels spreadsheets ist trivial, doch in der Praxis – trotz des Bewusstseins für die Theorie – ist es nicht so gekommen. Wir zeigen, dass spreadsheets durch die Übernahme von programming paradigms, die sich als überlegen erwiesen haben, um supply chain Ergebnisse zu liefern, erfolgreich waren.
Vollständiges Transkript
Hallo zusammen, willkommen zu dieser Reihe von supply chain Vorlesungen. Ich bin Joannes Vermorel, und heute präsentiere ich meine vierte Vorlesung: Programmierparadigmen für Supply Chain.
Also, wenn ich gefragt werde: “Herr Vermorel, was sind Ihrer Meinung nach die interessantesten Bereiche im Hinblick auf supply chain Wissen?” ist eine meiner häufigsten Antworten in der Regel Programmierparadigmen. Und dann – nicht allzu häufig, aber häufig genug – reagiert die Person, mit der ich spreche, mit: “Programmierparadigmen, Herr Vermorel? Wovon reden Sie überhaupt? Wie soll das auch nur annähernd relevant für die jeweilige Aufgabe sein?” Solche Reaktionen erinnern mich unweigerlich an dieses absolut unglaubliche Zitat von Robert A. Heinlein, der als der Dekan der Science-Fiction-Autoren gilt.
Heinlein hat ein fantastisches Zitat über den kompetenten Menschen, das die Bedeutung von Kompetenz in verschiedenen Bereichen hervorhebt – insbesondere in der supply chain, wo wir es mit komplexen Problemen zu tun haben. Diese Probleme sind fast so herausfordernd wie das Leben selbst, und ich glaube, dass es sich wirklich lohnt, die Idee der Programmierparadigmen zu erkunden, da sie Ihrer supply chain großen Mehrwert bringen könnte.
Bisher haben wir in der ersten Vorlesung gesehen, dass supply chain Probleme komplex sind. Wer von optimalen Lösungen spricht, verfehlt den Kern der Sache; es gibt nichts, was auch nur annähernd optimal ist. In der zweiten Vorlesung habe ich die Quantitative Supply Chain skizziert – eine Vision mit fünf wesentlichen Anforderungen an Exzellenz im supply chain Management. Diese Anforderungen reichen für sich allein nicht aus, können aber nicht umgangen werden, wenn man Großartigkeit erreichen will.
In der dritten Vorlesung habe ich die Softwareproduktlieferung im Kontext der supply chain Optimierung erörtert. Ich argumentierte, dass supply chain Optimierung ein Softwareprodukt erfordert, das auf kapitalistische Weise richtig angegangen wird, aber ein solches Produkt findet man nicht im Regal. Es gibt zu viel Diversität, und die Herausforderungen liegen weit jenseits der Technologien, die uns derzeit zur Verfügung stehen. Daher wird es notgedrungen etwas vollkommen Maßgeschneidertes sein. Wenn es also ein Softwareprodukt ist, das maßgeschneidert für das Unternehmen oder die betreffende supply chain sein soll, stellt sich die Frage, welche Werkzeuge geeignet sind, um dieses Produkt tatsächlich bereitzustellen. Das führt mich zum heutigen Thema: Das richtige Werkzeug beginnt mit den passenden Programmierparadigmen, denn wir werden dieses Produkt so oder so programmieren müssen.
Bisher benötigen wir programmatische Fähigkeiten, um die Optimierungsseite des Problems anzugehen – was nicht mit dem Management-Aspekt zu verwechseln ist. Wie in meiner vorangegangenen Vorlesung gezeigt, war Microsoft Excel bislang der Gewinner. Von sehr kleinen bis zu sehr großen Unternehmen ist es allgegenwärtig und wird überall eingesetzt. Selbst in Firmen, die Millionen von Dollar in hochintelligente Systeme investiert haben, herrscht Excel vor – und warum? Weil es die richtigen Programmier-Eigenschaften besitzt. Es ist sehr ausdrucksstark, agil, zugänglich und wartbar. Allerdings ist Excel nicht das Endziel. Ich bin fest davon überzeugt, dass wir noch viel mehr erreichen können, aber dazu benötigen wir die richtigen Werkzeuge, die passende Denkweise, Einsichten und Programmierparadigmen.
Programmierparadigmen mögen dem Publikum übermäßig obskur erscheinen, aber es handelt sich tatsächlich um ein Forschungsfeld, das in den letzten fünf Jahrzehnten intensiv untersucht wurde. In diesem Bereich wurde eine enorme Menge an Arbeit geleistet. Es ist nicht einem breiten Publikum bekannt, aber es gibt ganze Bibliotheken, die mit hochwertiger Arbeit gefüllt sind, die von unzähligen Experten geleistet wurde. Heute werde ich also eine Reihe von sieben Paradigmen vorstellen, die Lokad übernommen hat. Wir haben keine dieser Ideen erfunden; wir haben sie von denjenigen übernommen, die sie vor uns entwickelt haben. All diese Paradigmen wurden in Lokads Softwareprodukt implementiert, und nach fast einem Jahrzehnt produktiven Einsatzes von Lokad, unter Nutzung dieser Paradigmen, bin ich überzeugt, dass sie für unseren operativen Erfolg bislang von absolut entscheidender Bedeutung waren.
Gehen wir diese Liste mittels statischer Analyse durch. Das Problem hierbei ist die Komplexität. Wie geht man in der supply chain mit Komplexität um? Sie werden auf Unternehmenssysteme stoßen, die Hunderte von Tabellen mit jeweils Dutzenden von Feldern enthalten. Wenn Sie ein so einfaches Problem wie die Inventar-replenishment in einem warehouse betrachten, gibt es so viele Faktoren zu berücksichtigen. Es können MOQs, Preisstaffelungen, Nachfrageprognosen, Prognosen von lead times und allerlei Rückläufe eine Rolle spielen. Es gibt Einschränkungen beim Regalplatz, Begrenzungen der Annahmekapazität und Verfallsdaten, die einige Ihrer Chargen obsolet machen. So endet man mit Unmengen an Aspekten, die bedacht werden müssen. In der supply chain ist die Devise “move fast and break things” schlichtweg nicht die richtige Einstellung. Wenn Sie unbeabsichtigt Waren im Wert von einer Million Dollar bestellen, die Sie überhaupt nicht benötigen, ist das ein sehr kostspieliger Fehler. Man kann nicht ein piece of software haben, das die supply chain steuert, routinemäßige Entscheidungen trifft und bei einem Fehler Millionen kostet. Wir müssen etwas mit einem sehr hohen Grad an Korrektheit by design haben. Wir wollen Fehler nicht erst in der Produktion entdecken.
Wenn es um supply chain Optimierung geht, handelt es sich nicht um das übliche Problem. Wenn Sie gerade eine massive, fehlerhafte Bestellung an einen Lieferanten übermittelt haben, können Sie diesen nicht eine Woche später anrufen und sagen: “Oh, mein Fehler, nein, vergessen Sie das, wir haben so etwas nie bestellt.” Solche Fehler werden sehr teuer. Statische Analyse heißt das, weil es darum geht, ein Programm zu untersuchen, ohne es auszuführen. Die Idee ist, dass Sie ein Programm haben, das mit Anweisungen, Schlüsselwörtern und allem geschrieben ist – und ohne es auszuführen – bereits feststellen können, ob das Programm Probleme aufweist, die nahezu sicher Ihre Produktion, insbesondere die supply chain Produktion, negativ beeinflussen würden. Die Antwort lautet ja. Diese Techniken existieren, sind implementiert und von außerordentlichem Wert.
Um ein Beispiel zu geben, sehen Sie auf dem Bildschirm einen Envision-Screenshot. Envision ist eine domänenspezifische Programmiersprache, die von Lokad fast ein Jahrzehnt lang entwickelt wurde und der predictive optimization der supply chain gewidmet ist. Was Sie hier sehen, ist ein Screenshot des Code-Editors von Envision, einer Web-App, die Sie online zur Codebearbeitung nutzen können. Die Syntax wird stark von Python beeinflusst. In diesem kleinen Screenshot, der nur vier Zeilen umfasst, verdeutliche ich die Idee, dass wenn Sie ein umfangreiches Logikstück für die Inventarauffüllung in einem Lager schreiben und dabei wirtschaftliche Variablen wie Preisstaffelungen einführen, Sie erkennen, dass diese Preisstaffelungen keinerlei Beziehung zu den vom Programm gelieferten Endergebnissen – den nachzufüllenden Mengen – haben. Hier liegt ein offensichtliches Problem vor. Sie haben eine wichtige Variable, nämlich Preisstaffelungen, eingeführt, die logischerweise keinen Einfluss auf das Endergebnis haben. Damit haben wir ein Problem, das durch statische Analyse erkannt werden kann. Es ist offensichtlich, denn wenn Variablen in den Code eingeführt werden, die keinerlei Einfluss auf den Output des Programms haben, erfüllen sie überhaupt keinen Zweck. In diesem Fall stehen wir vor zwei Optionen: Entweder handelt es sich um toten Code, und das Programm sollte nicht kompilieren (man sollte diesen toten Code entfernen, um Komplexität zu reduzieren und keine zufällige Komplexität anzuhäufen), oder es war ein echter Fehler und eine wichtige wirtschaftliche Variable hätte in die Berechnung einfließen müssen, wurde aber aufgrund von Ablenkung oder aus einem anderen Grund vergessen.
Statische Analyse ist absolut grundlegend, um einen gewissen Grad an Korrektheit by design zu erreichen. Es geht darum, Probleme bereits zur Compile-Zeit, also bereits beim Schreiben des Codes, zu beheben – noch bevor die Daten berührt werden. Wenn Probleme beim Ausführen auftreten, ist die Wahrscheinlichkeit groß, dass sie nachts passieren, wenn der nächtliche Batch-Prozess die Lagerauffüllung steuert. Das Programm wird voraussichtlich zu ungewöhnlichen Zeiten laufen, wenn niemand darauf achtgibt – daher möchte man nicht, dass es abstürzt, während niemand hinschaut. Es sollte genau dann abstürzen, wenn noch aktiv am Code gearbeitet wird.
Statische Analyse hat viele Zwecke. Zum Beispiel verwenden wir bei Lokad statische Analyse für die WYSIWYG-Bearbeitung von dashboards. WYSIWYG steht für “what you see is what you get.” Stellen Sie sich vor, Sie erstellen ein Dashboard für das Reporting, mit Liniendiagrammen, Balkendiagrammen, Tabellen, Farben und verschiedenen Stileffekten. Sie möchten dies visuell tun, anstatt den Stil Ihres Dashboards über den Code anzupassen, was sehr umständlich wäre. Alle von Ihnen vorgenommenen Einstellungen werden wieder in den Code eingefügt – und das geschieht durch statische Analyse.
Ein weiterer Aspekt bei Lokad, der vielleicht nicht von zentraler Bedeutung für die gesamte supply chain ist, aber für die Durchführung des Projekts sicherlich entscheidend, war der Umgang mit einer Programmiersprache namens Envision, die wir entwickeln. Wir wussten von Anfang an – vor fast einem Jahrzehnt –, dass Fehler passieren würden. Wir hatten keine Kristallkugel, um von Beginn an die perfekte Vision zu haben. Die Frage war, wie wir sicherstellen können, dass wir diese Designfehler in der Programmiersprache selbst so bequem wie möglich beheben können. Hier diente mir Python als warnendes Beispiel.
Python, das keine neue Sprache ist, wurde erstmals 1991 veröffentlicht – vor fast 30 Jahren. Die Migration von Python 2 zu Python 3 dauerte für die gesamte Community fast ein Jahrzehnt und war ein albtraumhafter Prozess, der für die beteiligten Unternehmen sehr schmerzhaft war. Ich empfand, dass der Sprache selbst nicht genügend Konstrukte zur Verfügung standen. Sie war nicht so konzipiert, dass man Programme von einer Version in eine andere migrieren könnte. Es war tatsächlich außerordentlich schwierig, dies vollständig automatisiert zu bewerkstelligen – und das liegt daran, dass Python nicht mit Blick auf statische Analyse entwickelt wurde. Wenn Sie eine Programmiersprache für supply chain haben, möchten Sie eine, die in puncto statischer Analyse erstklassig ist, denn Ihre Programme werden lange bestehen. Supply chains haben nicht den Luxus zu sagen: “Warten Sie drei Monate; wir schreiben gerade den Code um. Warten Sie auf uns; die Kavallerie kommt.” Es ist, als müsse man einen Zug reparieren, während er mit voller Geschwindigkeit auf den Schienen fährt – man hat nicht die Möglichkeit, das System anzuhalten, denn es hält niemals an.
Das zweite Paradigma ist die Array-Programmierung. Wir möchten die Komplexität in den Griff bekommen, da dies ein großes, wiederkehrendes Thema in supply chains ist. Wir streben eine Logik an, bei der bestimmte Klassen von Programmierfehlern nicht auftreten. Zum Beispiel setzen Sie sich exponenziell schwierigen Problemen aus, wenn Schleifen oder Verzweigungen explizit von Programmierern geschrieben werden. Es wird äußerst schwierig, wenn willkürliche Schleifen geschrieben werden, um Garantien über die Berechnungsdauer zu erhalten. Obwohl dies wie ein Nischenproblem erscheinen mag, ist das in der supply chain Optimierung nicht ganz der Fall.
In der Praxis, nehmen wir an, Sie haben eine retail chain. Um Mitternacht werden alle Verkäufe des gesamten Netzwerks vollständig konsolidiert, und die Daten werden gesammelt und an ein Optimierungssystem übergeben. Dieses System hat exakt ein 60-Minuten-Fenster, um Prognosen, Bestandsoptimierung und Umlagerungsentscheidungen für jedes einzelne Geschäft des Netzwerks durchzuführen. Sobald dies erledigt ist, werden die Ergebnisse an das Lagerverwaltungssystem übermittelt, damit mit der Vorbereitung aller Sendungen begonnen werden kann. Die Lkw werden beladen, vielleicht um 5:00 Uhr morgens, und bis 9:00 Uhr öffnen die Geschäfte – die Ware ist bereits angeliefert und in den Regalen platziert.
Allerdings haben Sie ein sehr strenges Timing, und wenn Ihre Berechnung über dieses 60-Minuten-Fenster hinausgeht, setzen Sie die gesamte supply chain execution aufs Spiel. Sie wollen nicht erst in der Produktion feststellen, wie lange die Dinge tatsächlich dauern. Wenn Sie Schleifen haben, in denen die Nutzer entscheiden können, wie viele Iterationen durchgeführt werden, ist es sehr schwierig, einen Nachweis über die Dauer Ihrer Berechnung zu erbringen. Bedenken Sie, dass es hier um supply chain optimization geht. Sie haben nicht den Luxus, eine Peer-Review durchzuführen und alles doppelt zu überprüfen. Manchmal, bedingt durch die Pandemie, werden in einigen Ländern die Geschäfte geschlossen, während andere recht unregelmäßig – meist mit einer 24-Stunden-Vorwarnung – wieder öffnen. Sie müssen schnell reagieren.
Also, Array-Programmierung ist die Idee, dass Sie direkt mit Arrays arbeiten können. Wenn wir uns den Codeausschnitt hier ansehen, handelt es sich um Envision-Code, das DSL von Lokad. Um zu verstehen, was vor sich geht, müssen Sie begreifen, dass, wenn ich “orders.amounts” schreibe, dabei eine Variable entsteht und “orders” tatsächlich eine Tabelle im Sinne einer relationalen Tabelle ist, wie in Ihrer Datenbank. Zum Beispiel wäre hier in der ersten Zeile “amounts” eine Spalte der Tabelle. In Zeile eins sage ich wörtlich, dass ich für jede einzelne Zeile der orders-Tabelle einfach die “quantity” nehme, welche eine Spalte ist, und sie mit “price” multipliziere, um so eine dritte Spalte zu erzeugen, die dynamisch generiert wird, nämlich “amount”.
Übrigens wird der moderne Begriff für Array-Programmierung heutzutage auch als Data Frame Programming bezeichnet. Das Fachgebiet ist ziemlich alt; es reicht drei oder vier Jahrzehnte zurück, vielleicht sogar vier oder fünf. Es war als Array-Programmierung bekannt, auch wenn heutzutage die Leute normalerweise eher mit dem Konzept der Data Frames vertraut sind. In Zeile zwei wenden wir einen Filter an, genau wie in SQL. Wir filtern die Daten nach Datum, und zufällig enthält die orders-Tabelle ein Datum. Dieses wird gefiltert, und ich sage “date that is greater than today minus 365”, also Tage. Wir behalten die Daten vom letzten Jahr, und dann schreiben wir “products.soldLastYear = SUM(orders.amount)”.
Nun, das Interessante ist, dass wir einen sogenannten natural join zwischen products und orders haben. Warum? Weil jede Orderzeile genau mit einem Produkt verknüpft ist und ein Produkt mit null oder mehreren Orderzeilen verbunden sein kann. In dieser Konfiguration können Sie direkt sagen: “Ich möchte etwas auf Produktebene berechnen, das einfach die Summe von allem ist, was auf der orders-Ebene passiert”, und genau das wird in Zeile neun gemacht. Vielleicht fällt Ihnen auf, dass die Syntax sehr schlicht ist; es gibt kaum Nebenwirkungen oder technische Besonderheiten. Ich behaupte, dass dieser Code nahezu vollständig frei von zufälligen Nebeneffekten ist, wenn es um Data Frame Programming geht. Dann, in den Zeilen 10, 11 und 12, stellen wir einfach eine Tabelle in unserem Dashboard zur Anzeige, was sehr bequem möglich ist: “LIST(PRODUCTS)” und dann “TO(products)”.
Es gibt viele Vorteile der Array-Programmierung für supply chains. Erstens eliminiert sie ganze Klassen von Problemen. In Ihren Arrays werden keine Off-by-One-Fehler auftreten. Es wird viel einfacher sein, die Berechnungen zu parallelisieren und sogar zu verteilen. Das ist sehr interessant, weil es bedeutet, dass Sie ein Programm schreiben können, das nicht nur auf einer lokalen Maschine, sondern direkt auf einer Flotte von Maschinen in der Cloud ausgeführt wird – und übrigens genau das wird bei Lokad gemacht. Diese automatische Parallelisierung ist von enormem Interesse.
Sehen Sie, so funktioniert es: Wenn Sie supply chain optimization betreiben, sind Ihre typischen Verbrauchsmuster in Bezug auf Rechenhardware sehr intermittierend. Wenn ich auf das Beispiel zurückkomme, das ich bezüglich des 60-Minuten-Fensters für die Einzelhandelsnetzwerke während der Ladenauffüllung erwähnt habe, bedeutet das, dass es eine Stunde pro Tag gibt, in der Sie Rechenleistung für alle Ihre Berechnungen benötigen, während Sie in den übrigen 23 Stunden diese nicht brauchen. Was Sie also wollen, ist ein Programm, das, wenn es gestartet wird, sich auf viele Maschinen verteilt und diese, sobald es fertig ist, wieder freigibt, sodass andere Berechnungen durchgeführt werden können. Die Alternative wäre, viele Maschinen zu mieten und den ganzen Tag zu bezahlen, sie jedoch nur zu 5 % zu nutzen – was sehr ineffizient ist.
Die Idee, die Rechenleistung schnell und vorhersagbar auf viele Maschinen zu verteilen und sie anschließend wieder freizugeben, erfordert die Cloud in einer Multi-Tenant-Konfiguration sowie eine Reihe weiterer Dinge, die Lokad umsetzt. Aber vor allem bedarf es der Kooperation der Programmiersprache selbst. Dies ist mit einer generischen Programmiersprache wie Python schlicht nicht machbar, da sich die Sprache nicht für einen derart intelligenten und relevanten Ansatz eignet. Das ist mehr als nur ein Trick; es geht buchstäblich darum, Ihre IT-Hardwarekosten um den Faktor 20 zu senken, die Ausführung massiv zu beschleunigen und ganze Klassen potenzieller Fehler in Ihrer supply chain auszuschließen. Das verändert das Spiel.
Array-Programmierung existiert bereits in vielen Bereichen, beispielsweise in NumPy und pandas in Python, die so populär für das data scientist Segment des Publikums sind. Aber meine Frage an Sie ist: Wenn es so wichtig und nützlich ist, warum sind diese Dinge nicht erstklassige Bürger der Sprache selbst? Wenn alles, was Sie tun, über NumPy kanalisiert wird, sollte NumPy ein erstklassiger Bürger sein. Ich würde sagen, es geht sogar noch besser als NumPy. NumPy bezieht sich lediglich auf Array-Programmierung auf einer Maschine, aber warum nicht Array-Programmierung auf einer Flotte von Maschinen durchführen? Es ist viel leistungsfähiger und angemessener, wenn Sie eine Cloud mit zugänglicher Hardware-Kapazität haben.
Also, was wird der Engpass in der supply chain optimization sein? Es gibt dieses Zitat von Goldratt, das besagt: “Any improvement brought beside the bottleneck in a supply chain is an illusion,” und dem stimme ich voll und ganz zu. Realistisch betrachtet wird, wenn wir supply chain optimization betreiben, der Engpass die Menschen sein – und zwar insbesondere die Supply Chain Scientists, die – leider für Lokad und meine Kunden – nicht an Bäumen wachsen.
Der Engpass sind die Supply Chain Scientists, also die Menschen, die in der Lage sind, die numerischen Rezepte zu erstellen, welche alle Strategien des Unternehmens sowie das adversarische Verhalten der Wettbewerber berücksichtigen und all diese Intelligenz in etwas Mechanisches umsetzen, das in großem Maßstab ausgeführt werden kann. Die Tragödie der naiven Art, Data Science zu betreiben, als ich mit meiner Promotion begann – die ich übrigens nie abschloss – bestand darin, dass ich sah, wie buchstäblich jeder im Labor Data Science betrieb. Die meisten schrieben Code für irgendein fortgeschrittenes Machine Learning-Modell, drückten die Eingabetaste und warteten dann. Wenn Sie einen großen Datensatz haben, sagen wir 5–10 Gigabyte, wird dies nicht in Echtzeit ablaufen. Das gesamte Labor war somit mit Menschen gefüllt, die ein paar Zeilen Code schrieben, Enter drückten und sich dann einen Kaffee holten oder im Internet etwas lasen. Dadurch war die Produktivität extrem niedrig.
Als ich mein eigenes Unternehmen gründete, hatte ich fest im Sinn, dass ich nicht am Ende eine Armee von superintelligenten Menschen bezahlen wollte, die den Großteil ihres Tages damit verbringen, Kaffee zu trinken und darauf zu warten, dass ihre Programme fertiglaufen, um dann Ergebnisse zu erhalten und weitermachen zu können. Theoretisch könnten sie viele Dinge gleichzeitig parallelisieren und Experimente durchführen, aber in der Praxis habe ich das nie wirklich gesehen. Intellektuell, wenn Sie dabei sind, eine Lösung für ein Problem zu finden, möchten Sie Ihre Hypothese testen und benötigen das Ergebnis, um fortzufahren. Es ist sehr schwierig, bei hochkomplexen technischen Aufgaben zu multitasken und mehrere intellektuelle Pfade gleichzeitig zu verfolgen.
Es gab jedoch auch einen Silberstreifen am Horizont. Data scientists und jetzt Supply Chain Scientists bei Lokad schreiben nicht am Ende tausend Zeilen Code und fordern dann “please run”. Sie fügen normalerweise zwei Zeilen zu einem tausend Zeilen langen Skript hinzu und bitten dann um dessen Ausführung. Dieses Skript wird gegen exakt dieselben Daten ausgeführt, die sie vor ein paar Minuten bereits verarbeitet haben. Es folgt nahezu exakt derselben Logik, abgesehen von diesen beiden Zeilen. Wie können Sie also Terabytes an Daten in Sekunden statt in mehreren Minuten verarbeiten? Die Antwort lautet: Wenn Sie bei der vorherigen Ausführung des Skripts alle Zwischenschritte der Berechnung aufgezeichnet und auf einem Speichermedium abgelegt haben (typischerweise Solid-State Drives oder SSDs), die sehr günstig, schnell und praktisch sind.
Beim nächsten Ausführen Ihres Programms wird das System feststellen, dass es sich um nahezu dasselbe Skript handelt. Es wird einen Diff durchführen und erkennen, dass der Berechnungsgraph fast identisch ist, abgesehen von ein paar Details. In Bezug auf die Daten ist er üblicherweise zu 100 % identisch. Manchmal gibt es ein paar Änderungen, aber nahezu nichts. Das System wird automatisch diagnostizieren, dass nur wenige Elemente neu berechnet werden müssen, sodass Sie die Ergebnisse in Sekunden erhalten. Dies kann die Produktivität Ihres Supply Chain Scientist dramatisch steigern. Sie können von Nutzern, die Enter drücken und 20 Minuten auf das Ergebnis warten, zu solchen übergehen, die Enter drücken und 5 oder 10 Sekunden später das Ergebnis erhalten und weitermachen.
Ich spreche von etwas, das super obskur erscheinen mag, in der Praxis jedoch einen 10-fachen Einfluss auf die Produktivität hat. Das ist enorm. Was wir hier tun, ist also, einen cleveren Trick anzuwenden, den Lokad nicht erfunden hat. Wir ersetzen eine rohe Rechenressource, nämlich Rechenleistung, durch eine andere, nämlich Speicher und Speicherplatz. Wir haben die grundlegenden Rechenressourcen: Rechenleistung, Speicher (entweder flüchtig oder persistent) und Bandbreite. Dies sind die fundamentalen Ressourcen, für die Sie bezahlen, wenn Sie Ressourcen auf einer Cloud-Computing-Plattform mieten. Sie können tatsächlich eine Ressource durch eine andere ersetzen, und das Ziel ist, den größtmöglichen Nutzen daraus zu ziehen.
Wenn Leute sagen, dass Sie In-Memory Computing verwenden sollten, würde ich sagen, das ist Unsinn. Denn wenn man von In-Memory Computing spricht, bedeutet das, dass man einen Design-Schwerpunkt auf eine Ressource im Vergleich zu allen anderen legt. Aber nein, es gibt immer Kompromisse, und das Interessante ist, dass Sie eine Programmiersprache und -umgebung haben können, die diese Kompromisse und Perspektiven leichter umsetzbar macht. In einer herkömmlichen Allzweck-Programmiersprache ist dies zwar möglich, aber Sie müssen es manuell erledigen. Das bedeutet, dass die Person, die dies umsetzt, ein professioneller Softwareingenieur sein muss. Ein Supply Chain Scientist wird diese Low-Level-Operationen mit den grundlegenden Rechenressourcen Ihrer Plattform nicht selbst durchführen. Dies muss auf der Ebene der Programmiersprache selbst entwickelt werden.
Nun, sprechen wir über probabilistisches Programmieren. In der zweiten Vorlesung, in der ich die Vision für die quantitative supply chain vorstellte, war meine erste Anforderung, dass wir alle möglichen Zukünfte in Betracht ziehen müssen. Die technische Antwort auf diese Anforderung ist probabilistic forecasting. Sie möchten sich mit Zukünften auseinandersetzen, in denen Wahrscheinlichkeiten ins Spiel kommen. Alle Zukünfte sind möglich, aber sie sind nicht alle gleich wahrscheinlich. Sie benötigen eine Algebra, mit der Sie Berechnungen unter Unsicherheit durchführen können. Eine meiner großen Kritiken an Excel ist, dass es außerordentlich schwierig ist, Unsicherheit in einer Tabelle darzustellen, egal ob es sich um Excel oder eine modernere, cloud-basierte Variante handelt. In einer Tabelle ist es sehr schwierig, Unsicherheit darzustellen, da man etwas Besseres als Zahlen braucht.
In diesem kleinen Ausschnitt illustriere ich die Algebra zufälliger Variablen, die eine native Funktion von Envision ist. In Zeile eins generiere ich eine diskrete Poisson-Verteilung mit einem Mittelwert von 2 und weise diese der Variablen X zu. Dann mache ich dasselbe für eine weitere Poisson-Verteilung, Y. Anschließend berechne ich Z als das Produkt von X mal Y. Dieser Vorgang, also die Multiplikation zufälliger Variablen, mag sehr bizarr erscheinen. Warum benötigt man so etwas aus der Perspektive der supply chain?
Nehmen wir an, Sie sind im automobilen Aftermarket und verkaufen Bremssättel. Die Kunden kaufen Bremssättel nicht einzeln; sie kaufen entweder zwei oder vier. Die Frage ist also: Wenn Sie eine Prognose erstellen möchten, wollen Sie möglicherweise die Wahrscheinlichkeiten vorhersagen, mit denen Kunden tatsächlich erscheinen, um eine bestimmte Art von Bremssätteln zu kaufen. Das wird Ihre erste zufällige Variable sein, die Ihnen die Wahrscheinlichkeit angibt, null, eine, zwei, drei, vier etc. Einheiten Nachfrage für die Bremssättel zu beobachten. Anschließend haben Sie eine weitere Wahrscheinlichkeitsverteilung, die darstellt, ob die Kunden zwei oder vier Bremssättel kaufen. Vielleicht ist es 50–50 oder vielleicht kaufen 10 Prozent zwei und 90 Prozent vier. Tatsache ist, dass Sie beide Perspektiven haben, und wenn Sie den tatsächlichen Gesamtverbrauch von Bremssätteln ermitteln möchten, müssen Sie die Wahrscheinlichkeit, dass ein Kunde für diesen Bremssättel erscheint, mit der Wahrscheinlichkeitsverteilung des Kaufs von entweder zwei oder vier multiplizieren. Somit benötigen Sie diese Multiplikation dieser beiden unsicheren Größen.
Hier nehme ich an, dass die beiden zufälligen Variablen unabhängig sind. Übrigens ist diese Multiplikation von Zufallsvariablen in der Mathematik als diskrete Faltung bekannt. Auf dem Screenshot können Sie das von Envision generierte Dashboard sehen. In den ersten drei Zeilen führe ich diese zufällige algebraische Berechnung durch, und dann stelle ich in den Zeilen vier, fünf und sechs diese Ergebnisse auf der Webseite, im vom Skript generierten Dashboard, zur Anzeige. Ich plotte beispielsweise A1, B2 – ganz wie in einem Excel-Raster. Die Lokad-Dashboards sind ähnlich wie Excel-Raster organisiert, mit Positionen, die den Spalten B, C usw. und den Zeilen 1, 2, 3, 4, 5 entsprechen.
Sie können sehen, dass die diskrete Faltung, Z, dieses sehr bizarr wirkende, extrem stachelige Muster aufweist, das in supply chains, in denen Kunden Packs, Losgrößen oder Mehrfachkäufe tätigen, tatsächlich sehr häufig vorkommt. In solchen Fällen ist es in der Regel besser, die Ursachen der multiplikativen Ereignisse, die mit dem Los oder Pack verbunden sind, zu zerlegen. Sie benötigen eine Programmiersprache, die diese Fähigkeiten als erstklassige Funktionen zur Verfügung stellt. Genau darum geht es beim probabilistischen Programmieren, und so haben wir es in Envision implementiert.
Nun wollen wir über differentiable programming sprechen. Ich muss hier einen Vorbehalt anbringen: Ich erwarte nicht, dass das Publikum wirklich versteht, was vor sich geht, und dafür entschuldige ich mich. Es liegt nicht an mangelnder Intelligenz; es ist einfach so, dass dieses Thema eine ganze Vorlesungsreihe verdient. Tatsächlich, wenn Sie sich den Plan der kommenden Vorlesungen ansehen, gibt es eine ganze Reihe, die sich differentiable programming widmet. Ich werde sehr schnell vorgehen, und es wird ziemlich kryptisch, also entschuldige ich mich im Voraus.
Lassen Sie uns mit dem hier interessierenden supply chain Problem fortfahren, nämlich der Kannibalisierung und Substitution. Diese Probleme sind sehr interessant und vermutlich der Punkt, an dem time series Forecasting, das allgegenwärtig ist, auf die brutalste Weise scheitert. Warum? Weil oft Kunden oder Interessenten zu mir kommen und fragen, ob wir zum Beispiel 13-Wochen-Vorausprognosen für bestimmte Artikel wie Rucksäcke erstellen können. Ich würde sagen, ja, das können wir, aber offensichtlich hängt, wenn wir einen Rucksack nehmen und die Nachfrage für dieses Produkt prognostizieren wollen, das Ergebnis massiv davon ab, was Sie mit Ihren anderen Rucksäcken machen. Wenn Sie nur einen Rucksack haben, werden Sie vielleicht die gesamte Nachfrage nach Rucksäcken auf dieses eine Produkt konzentrieren. Wenn Sie 10 verschiedene Varianten einführen, wird es offensichtlich zu massiven Kannibalisierungen kommen. Sie werden den Gesamtumsatz nicht um den Faktor 10 erhöhen, nur weil Sie die Anzahl der Referenzen um 10 vervielfacht haben. Also finden eindeutig Kannibalisierung und Substitution statt. Diese Phänomene sind in supply chains weit verbreitet.
Wie analysiert man Kannibalisierung oder Substitution? Der Weg, wie wir es bei Lokad machen – und ich behaupte nicht, dass es der einzige Weg ist, aber er funktioniert definitiv – ist in der Regel, den Graphen zu betrachten, der Kunden und Produkte verbindet. Warum ist das so? Weil Kannibalisierung auftritt, wenn Produkte um dieselben Kunden miteinander konkurrieren. Kannibalisierung spiegelt buchstäblich wider, dass ein Kunde ein Bedürfnis hat, aber Vorlieben besitzt und sich unter den Produkten, die zu seiner Affinität passen, für genau ein Produkt entscheidet. Das ist das Wesen der Kannibalisierung.
Wenn Sie das analysieren möchten, müssen Sie nicht die Zeitreihen der Verkäufe untersuchen, denn diese Informationen werden von vornherein nicht erfasst. Sie möchten den Graphen analysieren, der die historischen Transaktionen zwischen Kunden und Produkten verbindet. Es stellt sich heraus, dass diese Daten in den meisten Unternehmen leicht verfügbar sind. Für E-Commerce ist das selbstverständlich. Jede verkaufte Einheit ist einem Kunden zugeordnet. Im B2B ist es dasselbe. Selbst im B2C im Einzelhandel haben heutzutage die meisten Einzelhandelsketten loyalty Programme, bei denen sie einen zweistelligen Prozentsatz der Kunden kennen, die mit ihren Karten erscheinen, sodass man weiß, wer was kauft. Nicht bei 100 % des Verkehrs, aber das braucht man auch nicht. Wenn Sie 10 % und mehr Ihrer historischen Transaktionen haben, bei denen das Kunden-Produkt-Paar bekannt ist, reicht das für diese Art der Analyse aus.
In diesem relativ kleinen Ausschnitt werde ich eine Affinitätsanalyse zwischen Kunden und Produkten im Detail erläutern. Das ist buchstäblich der grundlegende Schritt, den Sie unternehmen müssen, um jegliche Art von Kannibalisierungsanalyse durchzuführen. Schauen wir uns an, was in diesem Code passiert.
Von Zeile eins bis fünf ist das sehr alltäglich; ich lese einfach eine Flachdatei ein, die eine Transaktionshistorie enthält. Ich lese eine CSV-Datei ein, die vier Spalten hat: Datum, Produkt, Kunde und Menge. Etwas sehr Grundlegendes. Ich benutze nicht einmal alle diese Spalten, aber das macht das Beispiel etwas konkreter. In der Transaktionshistorie gehe ich davon aus, dass die Kunden für all diese Transaktionen bekannt sind. Es ist also sehr alltäglich; ich lese einfach Daten aus einer Tabelle ein.
Dann, in den Zeilen sieben und acht, erstelle ich lediglich die Tabelle für Produkte und die Tabelle für Kunden. In einer echten Produktionsumgebung würde ich diese Tabellen typischerweise nicht erstellen; ich würde sie aus anderen Flachdateien an anderer Stelle einlesen. Ich wollte das Beispiel super einfach halten, also extrahiere ich einfach eine Produkttabelle aus den in der Transaktionshistorie beobachteten Produkten und mache dasselbe für die Kunden. Sehen Sie, es ist nur ein Trick, um es super einfach zu halten.
Nun, die Zeilen 10, 11 und 12 beinhalten Latin spaces, und das wird etwas undurchsichtiger. Zuerst, in Zeile 10, erstelle ich eine Tabelle mit 64 Zeilen. Die Tabelle enthält nichts; sie ist lediglich dadurch definiert, dass sie 64 Zeilen hat, und das war’s. Also ist dies wie ein Platzhalter, eine triviale Tabelle mit vielen Zeilen und keinen Spalten. So ist sie allein nicht besonders nützlich. Dann ist “P” im Grunde ein kartesisches Produkt, eine mathematische Operation, die alle Paare erzeugt. Es ist eine Tabelle, in der Sie eine Zeile für jede Zeile in den Produkten und jede Zeile in der Tabelle “L” haben. Somit hat diese Tabelle “P” 64 weitere Zeilen als die Produkttabelle, und ich mache dasselbe für die Kunden. Ich erweitere diese Tabellen einfach durch diese zusätzliche Dimension, nämlich die Tabelle “L”.
Dies wird meine Grundlage für meine Latin spaces sein, was genau das ist, was ich lernen werde. Was ich lernen möchte, ist, dass es für jedes Produkt einen Latin space gibt, der ein Vektor von 64 Werten ist, und für jeden Kunden einen Latin space von ebenfalls 64 Werten. Wenn ich die Affinität zwischen einem Kunden und einem Produkt wissen möchte, will ich einfach das Skalarprodukt zwischen den beiden berechnen können. Das Skalarprodukt ist einfach die elementweise Multiplikation aller Elemente dieser beiden Vektoren, gefolgt von der Summe. Es mag sehr technisch klingen, aber es ist lediglich elementweise Multiplikation plus Summe – das ist das Skalarprodukt.
Diese Latin spaces sind nur ein schick klingender Fachausdruck für die Schaffung eines Raums mit Parametern, die etwas konstruiert sind, den ich einfach lernen möchte. Die gesamte differentiable programming Magie geschieht in nur fünf Zeilen, von Zeile 14 bis 18. Ich habe ein Schlüsselwort, “autodiff”, und “transactions”, das besagt, dass dies eine relevante Tabelle, eine Beobachtungstabelle, ist. Ich werde diese Tabelle Zeile für Zeile verarbeiten, um meinen Lernprozess durchzuführen. In diesem Block deklariere ich einen Satz von Parametern. Die Parameter sind die Dinge, die man lernen möchte, wie Zahlen, aber man kennt die Werte noch nicht. Diese werden einfach zufällig initialisiert, mit zufälligen Zahlen.
Ich führe “X”, “X*” und “Y” ein. Ich werde nicht detailliert darauf eingehen, was “X*” genau macht; vielleicht später in den Fragen. Ich gebe einen Ausdruck zurück, der meine Loss-Funktion darstellt, und das ist die Summe. Die Idee von Collaborative Filtering oder Matrixzerlegung besteht darin, Latin spaces zu erlernen, die zu allen Kanten in Ihrem bipartiten Graph passen. Ich weiß, es ist etwas technisch, aber was wir tun, ist buchstäblich sehr einfach, supply chain-bezogen. Wir lernen die Affinität zwischen Produkten und Kunden.
Ich weiß, dass es wahrscheinlich sehr undurchsichtig erscheint, aber bleiben Sie dran, und es wird weitere Vorlesungen geben, in denen ich Ihnen eine fundiertere Einführung dazu gebe. Das Ganze wird in fünf Zeilen erledigt, und das ist wirklich bemerkenswert. Wenn ich sage, fünf Zeilen, dann täusche ich Sie nicht, indem ich sage: “Schauen Sie, es sind nur fünf Zeilen, aber ich rufe tatsächlich eine Drittanbieter-Bibliothek von gigantischer Komplexität auf, in der ich sämtliche Intelligenz verberge.” Nein, nein, nein. In diesem Beispiel gibt es buchstäblich keine Machine-Learning-Magie außer den beiden Schlüsselwörtern “autodiff” und “params”. “Autodiff” wird verwendet, um einen Block zu definieren, in dem differentiable programming stattfindet, und übrigens, das ist ein Block, in dem ich alles programmieren kann – buchstäblich kann ich unser Programm einfügen. Dann verwende ich “params”, um meine Probleme zu deklarieren, und das war’s. Sehen Sie also, es findet keine undurchsichtige Magie statt; es gibt keine ein Million Zeilen umfassende Bibliothek im Hintergrund, die all die Arbeit für Sie erledigt. Alles, was Sie wissen müssen, steht buchstäblich auf diesem Bildschirm, und das ist der Unterschied zwischen einem Programmierparadigma und einer Bibliothek. Das Programmierparadigma gibt Ihnen Zugang zu scheinbar unglaublich ausgefeilten Fähigkeiten, wie zum Beispiel der Kannibalisierungsanalyse mit nur wenigen Zeilen Code, ohne auf massive Drittanbieter-Bibliotheken zurückzugreifen, die die Komplexität verbergen. Es hebt das Problem auf eine wesentlich einfachere Ebene, sodass etwas, das super kompliziert erscheint, in nur wenigen Zeilen gelöst werden kann.
Nun ein paar Worte dazu, wie differenzierbares Programmieren funktioniert. Es gibt zwei Erkenntnisse. Eine ist die automatische Differentiation. Für diejenigen von Ihnen, die das Privileg einer ingenieurwissenschaftlichen Ausbildung genossen haben, gibt es zwei Methoden, Ableitungen zu berechnen. Es gibt die symbolische Ableitung – zum Beispiel, wenn Sie x² haben, berechnen Sie die Ableitung nach x, und das ergibt 2x. Das ist eine symbolische Ableitung. Dann gibt es die numerische Ableitung, also wenn Sie eine Funktion f(x) haben, die Sie differenzieren möchten, gilt: f ‘(x) ≈ (f(x + ε) - f(x))/ε. Das ist die numerische Ableitung. Beide Methoden sind für das, was wir hier vorhaben, ungeeignet. Die symbolische Ableitung bringt Komplexitätsprobleme mit sich, da Ihre Ableitung ein Programm sein könnte, das weitaus komplexer ist als das ursprüngliche Programm. Die numerische Ableitung ist numerisch instabil, sodass Sie zahlreiche Probleme mit der numerischen Stabilität haben werden.
Die automatische Differentiation ist eine fantastische Idee aus den 70er Jahren, die in den letzten Jahrzehnten von der breiten Öffentlichkeit wiederentdeckt wurde. Es ist die Vorstellung, dass man die Ableitung eines beliebigen Computerprogramms berechnen kann – was schlichtweg verblüffend ist. Noch erstaunlicher ist, dass das Programm, das die Ableitung repräsentiert, dieselbe Rechenkomplexität wie das ursprüngliche Programm aufweist – das ist beeindruckend. Differenzierbares Programmieren ist schlichtweg eine Kombination aus automatischer Differentiation und den Parametern, die Sie lernen möchten.
Wie lernt man also? Wenn Sie die Ableitung besitzen, können Sie Gradienten zurückführen, und mittels stochastischem Gradientenabstieg nehmen Sie kleine Anpassungen an den Werten der Parameter vor. Durch das Feintuning dieser Parameter konvergieren Sie schrittweise über viele Iterationen des stochastischen Gradientenabstiegs zu Parametern, die sinnvoll sind und das ermöglichen, was Sie lernen oder optimieren möchten.
Differenzierbares Programmieren kann für Lernprobleme verwendet werden, wie jenes, das ich veranschauliche, bei dem ich die Affinität zwischen meinen Kunden und meinen Produkten ermitteln möchte. Es kann auch für numerische Optimierungsprobleme eingesetzt werden, etwa zur Optimierung unter Nebenbedingungen, und als Paradigma ist es sehr skalierbar. Wie Sie sehen, wurde dieser Aspekt in Envision zu einem erstklassigen Bürger gemacht. Übrigens sind bezüglich der Envision-Syntax noch einige Dinge in Arbeit, also erwarten Sie noch nicht exakt diese Funktionen; wir verfeinern noch einige Aspekte. Aber das Wesentliche ist vorhanden. Ich werde nicht auf die Details der noch in Entwicklung befindlichen Punkte eingehen.
Lassen Sie uns nun zu einem weiteren Problem übergehen, das für die Produktionsbereitschaft Ihres Setups relevant ist. Typischerweise begegnen Sie in der supply chain-Optimierung Heisenbugs. Was ist ein Heisenbug? Es handelt sich um eine ärgerliche Art von Fehler, bei dem eine Optimierung durchgeführt wird und unsinnige Ergebnisse liefert. Zum Beispiel hatten Sie eine Batch-Berechnung für die Lagerauffüllung über Nacht und stellen am Morgen fest, dass einige dieser Ergebnisse unsinnig waren und kostspielige Fehler verursachten. Sie möchten nicht, dass dieses Problem erneut auftritt, also führen Sie Ihren Prozess einfach noch einmal aus. Doch beim erneuten Ausführen des Prozesses ist das Problem verschwunden. Sie können den Fehler nicht reproduzieren, und der Heisenbug tritt nicht mehr auf.
Es mag wie ein seltsamer Randfall klingen, aber in den ersten Jahren bei Lokad traten diese Probleme wiederholt auf. Ich habe viele supply chain-Initiativen gesehen – besonders im Bereich Data Science – die an ungelösten Heisenbugs scheiterten. Es traten Fehler in der Produktion auf, man versuchte, die Probleme lokal zu reproduzieren, es gelang jedoch nicht, sodass die Fehler nie behoben wurden. Nach ein paar Monaten im Panikmodus wurde das gesamte Projekt in der Regel stillschweigend eingestellt, und die Leute kehrten zur Nutzung von Excel-Tabellen zurück.
Wenn Sie vollständige Replizierbarkeit Ihrer Logik erreichen möchten, müssen Sie den Code und die Daten versionieren. Die meisten im Publikum, die Softwareingenieure oder Data Scientists sind, kennen vermutlich die Idee, den Code zu versionieren. Allerdings sollten Sie auch sämtliche Daten versionieren, damit Sie, wenn Ihr Programm ausgeführt wird, genau wissen, welche Version von Code und Daten verwendet wird. Es kann vorkommen, dass Sie das Problem am nächsten Tag nicht reproduzieren können, weil sich die Daten durch neue Transaktionen oder andere Faktoren verändert haben und somit die ursprünglich den Fehler auslösenden Bedingungen nicht mehr vorhanden sind.
Sie wollen sicherstellen, dass Ihre Programmierumgebung die Logik und die Daten exakt so repliziert, wie sie zu einem bestimmten Zeitpunkt in der Produktion vorhanden waren.
Dies erfordert eine vollständige Versionierung von allem. Noch einmal: Die Programmiersprache und der Programmier-Stack müssen zusammenarbeiten, um dies zu ermöglichen. Es ist realisierbar, ohne dass das Programmierparadigma ein erstklassiger Bürger Ihres Stacks ist, aber dann muss der Supply Chain Scientist äußerst sorgfältig mit allem umgehen, was er tut und wie er programmiert. Andernfalls wird er seine Ergebnisse nicht reproduzieren können. Dies setzt Supply Chain Scientists, die ohnehin schon unter erheblichem Druck der supply chain stehen, enorm unter Druck. Sie möchten nicht, dass diese Fachleute sich mit zufälliger Komplexität auseinandersetzen müssen, etwa der Unfähigkeit, ihre eigenen Ergebnisse zu replizieren. Bei Lokad nennen wir dies eine “time machine”, mit der Sie zu jedem beliebigen Zeitpunkt in der Vergangenheit alles replizieren können Mehr erfahren.
Ein weiteres Anliegen ist der Anstieg von Ransomware und Cyberangriffen auf supply chains. Diese Angriffe sind massiv störend und können sehr kostspielig sein. Beim Implementieren softwaregestützter Lösungen müssen Sie bedenken, ob Sie Ihr Unternehmen und die supply chain dadurch anfälliger für Cyberangriffe und Risiken machen. Aus dieser Perspektive sind Excel und Python nicht ideal. Diese Komponenten sind programmierbar, was bedeutet, dass sie eine Vielzahl von Sicherheitslücken mit sich bringen können.
Wenn Sie ein Team von Data Scientists oder Supply Chain Scientists haben, die sich mit supply chain Problemen befassen, können sie sich den sorgfältigen, iterativen Peer-Review-Prozess von Code, wie er in der Softwareindustrie üblich ist, nicht leisten. Falls sich über Nacht ein Tarif ändert oder ein Lagerhaus überflutet wird, benötigen Sie eine schnelle Reaktion. Sie können nicht Wochen damit verbringen, Codespezifikationen, Reviews usw. zu erstellen. Das Problem besteht darin, dass Sie Programmierfähigkeiten an Menschen weitergeben, die standardmäßig das Potenzial haben, dem Unternehmen versehentlich Schaden zuzufügen. Es kann noch schlimmer sein, wenn ein absichtlich abtrünniger Mitarbeiter existiert – aber selbst wenn man das beiseite lässt, bleibt das Problem, dass jemand versehentlich einen inneren Teil der IT-Systeme offenlegt. Denken Sie daran, dass supply chain Optimierungssysteme definitionsgemäß Zugriff auf große Mengen an Daten im gesamten Unternehmen haben. Diese Daten sind nicht nur ein Vermögenswert, sondern auch eine Verbindlichkeit.
Was Sie wollen, ist ein Programmierparadigma, das sicheres Programmieren fördert. Sie möchten eine Programmiersprache, in der es ganze Klassen von Dingen gibt, die Sie nicht tun können. Zum Beispiel: Warum sollte es eine Programmiersprache geben, die Systemaufrufe für supply chain Optimierungszwecke ausführen kann? Python kann Systemaufrufe durchführen, ebenso wie Excel. Aber warum sollten Sie überhaupt ein programmierbares System mit solchen Fähigkeiten wollen? Es ist, als würde man sich eine Waffe kaufen, um sich selbst in den Fuß zu schießen.
Sie möchten etwas, bei dem ganze Klassen oder Features fehlen, weil Sie diese für supply chain Optimierung nicht benötigen. Sind diese Funktionen vorhanden, werden sie zu einer massiven Verbindlichkeit. Wenn Sie programmierbare Fähigkeiten einführen, ohne die Werkzeuge, die von vornherein sicheres Programmieren erzwingen, erhöhen Sie das Risiko von Cyberangriffen und Ransomware – was die Situation noch verschlimmert.
Natürlich ist es immer möglich, dies zu kompensieren, indem man die Größe des Cybersecurity-Teams verdoppelt, aber das ist sehr kostspielig und nicht ideal, wenn man mit dringenden supply chain Situationen konfrontiert ist. Sie müssen schnell und sicher handeln – ohne Zeit für die üblichen Prozesse, Reviews und Genehmigungen. Sie wünschen sich zudem sicheres Programmieren, das alltägliche Probleme wie Nullverweis-Ausnahmen, Out-of-Memory-Fehler, Off-by-One-Schleifen und Seiteneffekte beseitigt.
Zusammengefasst: Das richtige Werkzeug ist entscheidend. Es gibt ein Sprichwort: “Bring kein Schwert zu einem Schusswechsel mit.” Sie benötigen die passenden Werkzeuge und Programmierparadigmen – nicht nur jene, die Sie an der Universität gelernt haben. Sie brauchen etwas Professionelles und Produktionsreifen, das den Anforderungen Ihrer supply chain gerecht wird. Zwar mag es möglich sein, mit minderwertigen Werkzeugen gewisse Ergebnisse zu erzielen, aber das wird nie großartig sein. Ein fantastischer Musiker kann zwar mit einem Löffel Musik machen, doch mit einem richtigen Instrument gelingt ihm weitaus mehr.
Nun kommen wir zu den Fragen. Bitte beachten Sie, dass es etwa 20 Sekunden Verzögerung gibt, sodass es eine gewisse Latenz im Stream gibt zwischen dem Video, das Sie sehen, und dem Zeitpunkt, zu dem ich Ihre Fragen lese.
Frage: Was ist mit dynamischer Programmierung im Hinblick auf Operations Research?
Die dynamische Programmierung – trotz des Namens – ist kein Programmierparadigma. Es handelt sich vielmehr um eine algorithmische Technik. Die Idee ist, dass Sie, wenn Sie eine algorithmische Aufgabe durchführen oder ein bestimmtes Problem lösen wollen, dieselbe Unteroperation sehr häufig wiederholen. Dynamische Programmierung ist ein spezifischer Fall des Raum-Zeit-Kompromisses, den ich bereits erwähnt habe – man investiert etwas mehr in den Speicher, um bei der Berechnung Zeit zu sparen. Es war eine der frühesten algorithmischen Techniken, die bis in die 60er und 70er Jahre zurückreichen. Es ist eine gute Methode, aber der Name ist etwas unglücklich, denn an sich ist daran nichts wirklich Dynamisches, und es geht nicht primär ums Programmieren, sondern um das Konzept von Algorithmen. Für mich qualifiziert es sich daher trotz des Namens nicht als Programmierparadigma, sondern als eine spezifische algorithmische Technik.
Frage: Johannes, würden Sie bitte einige Referenzbücher nennen, die jeder gute supply chain Ingenieur haben sollte? Leider bin ich neu in diesem Bereich, und mein aktueller Schwerpunkt liegt auf Data Science und System Engineering.
Ich habe eine sehr gemischte Meinung zur vorhandenen Literatur. In meiner ersten Vorlesung habe ich zwei Bücher vorgestellt, von denen ich glaube, dass sie der Höhepunkt akademischer Studien im Bereich supply chain sind. Wenn Sie zwei Bücher lesen möchten, können Sie diese Bücher lesen. Allerdings habe ich stets Probleme mit den Büchern, die ich bisher gelesen habe. Im Grunde präsentieren manche Menschen Sammlungen von Spielzeug-Rezepten in Zahlenform für idealisierte supply chain, und ich bin der Meinung, dass diese Bücher das supply chain Thema nicht aus dem richtigen Blickwinkel betrachten und völlig verfehlen, dass es sich um ein bösartiges Problem handelt. Es gibt eine umfangreiche, sehr technische Literatur mit Gleichungen, Algorithmen, Theoremen und Beweisen – aber ich finde, sie verfehlt den eigentlichen Kern.
Dann gibt es noch einen anderen Stil von supply chain Management-Büchern, die eher im Beratungsstil gehalten sind. Diese erkennt man leicht daran, dass sie alle zwei Seiten Sportanalogien verwenden. Diese Bücher enthalten allerlei vereinfachte Diagramme, wie 2x2-Varianten von SWOT-(Stärken, Schwächen, Chancen, Risiken)-Diagrammen, die ich als minderwertige Denkansätze bewerte. Das Problem bei diesen Büchern ist, dass sie tendenziell besser verstehen, dass supply chain eine bösartige Herausforderung ist. Sie begreifen viel besser, dass es ein von Menschen gespieltes Spiel ist, in dem allerlei bizarre Dinge passieren können, und dass man in mancher Hinsicht clever sein kann – dafür gebe ich ihnen Anerkennung. Dennoch liegt der Haken: Diese Bücher, die typischerweise von Beratern oder Professoren wirtschaftswissenschaftlicher Fakultäten verfasst werden, sind nicht besonders umsetzbar. Die Botschaft reduziert sich auf “Sei ein besserer Führer”, “Sei klüger”, “Hab mehr Energie” – und das ist für mich nicht umsetzbar. Es liefert keine Elemente, die man in etwas hochgradig Wertvolles, wie es Software vermag, umwandeln kann.
Ich komme also zurück zur ersten Vorlesung: Lesen Sie die beiden Bücher, wenn Sie möchten, aber ich bin mir nicht sicher, ob es die investierte Zeit wert ist. Es ist gut zu wissen, was andere geschrieben haben. Auf der Beratungsseite der Literatur ist mein Favorit wahrscheinlich die Arbeit von Katana, die ich in der ersten Vorlesung nicht erwähnt habe. Nicht alles ist schlecht – manche haben mehr Talent, auch wenn sie etwas beratungsorientierter sind. Schauen Sie sich die Arbeit von Katana an; er hat ein Buch über dynamic supply chains. Ich werde das Buch in den Referenzen aufführen.
Frage: Wie nutzen Sie Parallelisierung, wenn Sie mit Kannibalisierung oder Assortment-Entscheidungen zu tun haben, bei denen das Problem nicht leicht parallelisierbar ist?
Warum ist es nicht leicht parallelisierbar? Der stochastische Gradientenabstieg ist ziemlich trivial parallelisierbar. Es gibt stochastische Gradienten-Schritte, die in zufälliger Reihenfolge ausgeführt werden können, und es können mehrere Schritte gleichzeitig erfolgen. Daher glaube ich, dass alles, was vom stochastischen Gradientenabstieg angetrieben wird, relativ einfach parallelisierbar ist.
Beim Umgang mit Kannibalisierung ist es schwieriger, mit einer anderen Art der Parallelisierung umzugehen – nämlich mit der Frage, was zuerst kommen sollte. Wenn ich dieses Produkt zuerst einführe und dann eine Prognose erstelle, verändert das Hinzufügen eines weiteren Produkts die Situation. Die Lösung besteht darin, einen Ansatz zu haben, der die gesamte Landschaft frontal in Angriff nimmt. Man sagt nicht: “Zuerst führe ich dieses Produkt ein und erstelle die Prognose; dann füge ich ein weiteres Produkt hinzu und wiederhole die Prognose, wobei ich die erste anpasse.” Stattdessen machen Sie alles gleichzeitig, frontal, alles auf einmal. Hierfür brauchen Sie weitere Programmierparadigmen. Die Programmierparadigmen, die ich heute vorgestellt habe, können dafür einen langen Weg ebnen.
Bei Assortment-Entscheidungen stellen diese Probleme keine großen Schwierigkeiten für die Parallelisierung dar. Gleiches gilt, wenn Sie ein weltweites Einzelhandelsnetz besitzen und das Assortment für all Ihre Geschäfte optimieren möchten. Sie können Berechnungen für alle Geschäfte parallel durchführen. Sie sollten es nicht sequenziell handhaben, indem Sie das Assortment für ein Geschäft optimieren und dann zum nächsten übergehen – das ist der falsche Weg. Stattdessen können Sie das Netzwerk parallel optimieren, alle Informationen verbreiten und dann den Vorgang wiederholen. Es gibt allerlei Techniken, und die richtigen Werkzeuge können Ihnen dabei erheblich helfen, dies wesentlich einfacher zu gestalten.
Frage: Verwenden Sie einen Graph-Datenbankansatz?
Nein, nicht im technischen, kanonischen Sinne. Es gibt viele Graph-Datenbanken auf dem Markt, die von großem Interesse sind. Was wir intern bei Lokad verwenden, ist eine komplette vertikale Integration durch einen einheitlichen, monolithischen Compiler-Stack, um sämtliche traditionellen Elemente, die in einem klassischen Stack zu finden wären, vollständig zu eliminieren. So erreichen wir eine sehr gute Rechenleistung – nahezu hardware-nah. Nicht, weil wir fantastischerweise geniale Programmierer sind, sondern weil wir so gut wie alle herkömmlichen Schichten entfernt haben. Lokad verwendet buchstäblich gar keine Datenbank. Wir haben einen Compiler, der sich um alles kümmert – bis hin zur Organisation der Datenstrukturen für die Persistenz. Das mag etwas ungewöhnlich klingen, aber es ist viel effizienter, es auf diese Weise zu handhaben, und so arbeitet man wesentlich harmonischer mit der Tatsache, dass man ein Skript für eine Flotte von Maschinen in der Cloud kompiliert. Ihre Zielplattform in Bezug auf die Hardware ist nicht eine einzelne Maschine, sondern eine ganze Flotte.
Frage: Was halten Sie von Power BI, das auch Python-Codes und verwandte Algorithmen wie Gradientenabstieg, Greedy usw. ausführt?
Das Problem, das ich mit allem habe, was mit Business Intelligence zu tun hat – Power BI ist da nur ein Beispiel – ist, dass es ein Paradigma besitzt, das ich als unzureichend für supply chain erachte. Sie sehen alle Probleme als einen Hyperwürfel, in dem Sie lediglich Dimensionen aufschneiden und zerkleinern. Im Kern liegt ein Ausdrucksproblem, das sehr einschränkend ist. Wenn Sie am Ende Power BI mit Python dazwischen verwenden, brauchen Sie Python, weil der Ausdrucksreichtum des Hyperwürfels sehr gering ist. Um den Ausdrucksreichtum wieder zu erlangen, fügen Sie Python in der Mitte hinzu. Erinnern Sie sich jedoch an meine vorherige Bemerkung zu den Schichten: Der Fluch moderner enterprise software liegt darin, dass zu viele Schichten vorhanden sind. Jede einzelne zusätzliche Schicht führt zu Ineffizienzen und Fehlern. Wenn Sie Power BI plus Python verwenden, entsteht eine zu hohe Anzahl an Schichten. Sie haben dann Power BI, das auf anderen Systemen aufsetzt – das heißt, es gibt bereits mehrere Systeme vor Power BI. Darüber hinaus liegt Power BI wiederum auf einer eigenen Schicht, und darüber kommt Python. Aber agiert Python eigenständig? Nein, sehr wahrscheinlich nutzen Sie Python-Bibliotheken wie Pandas oder NumPy. So türmen sich Schichten in Python auf, und am Ende haben Sie Dutzende von ihnen. Fehler können in jeder dieser Schichten auftreten – die Situation wird also ziemlich alptraumhaft.
Frage: Wie können die Ergebnisse einer kollaborativen Filteranalyse in den Nachfrageprognose-Algorithmus für jedes Produkt, zum Beispiel Rucksäcke, integriert werden?
Es tut mir leid, aber dieses Thema werde ich in der nächsten Vorlesung behandeln. Kurz gesagt: Sie sollten dies nicht in einen bestehenden Prognosealgorithmus einspeisen. Stattdessen benötigen Sie etwas, das wesentlich nativer integriert ist. Sie verwerfen also die alte Methode der Prognose und greifen zu etwas radikal Anderem, das daraus Nutzen zieht. Das würde den Rahmen für heute sprengen.
Ich denke, das war’s für diese Vorlesung. Vielen Dank an alle, die teilgenommen haben.
Die nächste Vorlesung findet am Mittwoch, dem 6. Januar, zur gleichen Zeit, am gleichen Wochentag statt. Ich werde mir etwas Weihnachtsurlaub gönnen, daher wünsche ich allen frohe Weihnachten und ein glückliches neues Jahr. Unsere Vorlesungsreihe setzen wir im nächsten Jahr fort. Vielen Dank.
