Quantitative Supply Chain - Vorlesung 5.3

00:00 Einführung
02:55 Der Fall der Lieferzeiten
09:25 Reale Lieferzeiten (1/3)
12:13 Reale Lieferzeiten (2/3)
13:44 Reale Lieferzeiten (3/3)
16:12 Der bisherige Verlauf
19:31 ETA: 1 Stunde von jetzt an
22:16 CPRS (Zusammenfassung) (1/2)
23:44 CPRS (Zusammenfassung) (2/2)
24:52 Kreuzvalidierung (1/2)
27:00 Kreuzvalidierung (2/2)
27:40 Glättung der Lieferzeiten (1/2)
31:29 Glättung der Lieferzeiten (2/2)
40:51 Kombination der Lieferzeit (1/2)
44:19 Kombination der Lieferzeit (2/2)
47:52 Quasi-saisonale Lieferzeit
54:45 Log-logistisches Lieferzeitmodell (1/4)
57:03 Log-logistisches Lieferzeitmodell (2/4)
01:00:08 Log-logistisches Lieferzeitmodell (3/4)
01:03:22 Log-logistisches Lieferzeitmodell (4/4)
01:05:12 Unvollständiges Lieferzeitmodell (1/4)
01:08:04 Unvollständiges Lieferzeitmodell (2/4)
01:09:30 Unvollständiges Lieferzeitmodell (3/4)
01:11:38 Unvollständiges Lieferzeitmodell (4/4)
01:14:33 Nachfrage über die Lieferzeit (1/3)
01:17:35 Nachfrage über die Lieferzeit (2/3)
01:24:49 Nachfrage über die Lieferzeit (3/3)
01:28:27 Modularität von prädiktiven Techniken
01:31:22 Fazit
01:32:52 Bevorstehende Vorlesung und Fragen des Publikums

Beschreibung

Lieferzeiten sind ein grundlegender Aspekt in den meisten Supply-Chain-Situationen. Lieferzeiten können und sollten genauso wie die Nachfrage prognostiziert werden. Probabilistische Prognosemodelle, die speziell für Lieferzeiten entwickelt wurden, können verwendet werden. Es werden eine Reihe von Techniken vorgestellt, um probabilistische Lieferzeitprognosen für Supply-Chain-Zwecke zu erstellen. Die Kombination dieser Prognosen, Lieferzeit und Nachfrage, ist ein Eckpfeiler der prädiktiven Modellierung in der Supply Chain.

Vollständiges Transkript

Willkommen zu dieser Reihe von Supply-Chain-Vorlesungen. Ich bin Joannes Vermorel und heute werde ich “Prognose von Lieferzeiten” präsentieren. Lieferzeiten und allgemein alle anwendbaren Verzögerungen sind ein grundlegender Aspekt der Supply Chain, wenn es darum geht, Angebot und Nachfrage auszugleichen. Man muss die involvierten Verzögerungen berücksichtigen. Zum Beispiel, betrachten wir die Nachfrage nach einem Spielzeug. Die richtige Vorhersage des saisonalen Nachfragehöhepunkts vor Weihnachten spielt keine Rolle, wenn die Waren im Januar eintreffen. Die Lieferzeiten bestimmen genauso wie die Nachfrage die Feinheiten der Planung.

Lieferzeiten variieren; sie variieren stark. Das ist eine Tatsache und ich werde gleich einige Beweise präsentieren. Auf den ersten Blick ist diese Aussage jedoch verwirrend. Es ist nicht klar, warum die Lieferzeit überhaupt so stark variieren sollte. Wir haben Fertigungsprozesse, die mit weniger als einem Mikrometer Toleranz arbeiten können. Darüber hinaus können wir als Teil des Fertigungsprozesses eine Wirkung, wie z.B. die Anwendung einer Lichtquelle, auf eine Mikrosekunde genau kontrollieren. Wenn wir die Materietransformation bis zum Mikrometer und bis zur Mikrosekunde kontrollieren können, sollten wir mit ausreichender Hingabe den Fluss der Nachfrage mit einem vergleichbaren Maß an Präzision kontrollieren können. Oder vielleicht auch nicht.

Diese Denkweise könnte erklären, warum Lieferzeiten in der Supply-Chain-Literatur so wenig geschätzt werden. Supply-Chain-Bücher und folglich auch Supply-Chain-Software erkennen die Existenz von Lieferzeiten kaum an, außer wenn sie als Eingabeparameter für ihr Lagermodell eingeführt werden. Für diese Vorlesung gibt es drei Ziele:

Wir möchten die Bedeutung und die Natur von Lieferzeiten verstehen. Wir möchten verstehen, wie Lieferzeiten prognostiziert werden können, insbesondere mit einem speziellen Interesse an probabilistischen Modellen, die uns die Unsicherheit umfassen lassen. Wir möchten Lieferzeitprognosen mit Nachfrageprognosen kombinieren, auf eine Art und Weise, die für Supply-Chain-Zwecke interessant ist.

Laut der gängigen Supply-Chain-Literatur sind Lieferzeiten kaum mehr als ein paar Fußnoten wert. Diese Aussage mag als übertriebene Übertreibung erscheinen, aber ich fürchte, das ist sie nicht. Laut Google Scholar, einer spezialisierten Suchmaschine für wissenschaftliche Literatur, liefert die Suche nach “Nachfrageprognose” für das Jahr 2021 10.500 Ergebnisse. Eine oberflächliche Inspektion der Ergebnisse zeigt, dass tatsächlich die große Mehrheit dieser Einträge die Prognose der Nachfrage in allen möglichen Situationen und Märkten behandeln. Die gleiche Suche, ebenfalls für das Jahr 2021, auf Google Scholar nach “Lieferzeitprognose” liefert 71 Ergebnisse. Die Ergebnisse für die Lieferzeitprognose-Suche sind so begrenzt, dass es nur wenige Minuten dauert, um ein ganzes Jahr Forschung zu überblicken.

Es stellt sich heraus, dass es nur etwa ein Dutzend Einträge gibt, die sich tatsächlich mit der Prognose von Lieferzeiten befassen. Die meisten Übereinstimmungen finden sich tatsächlich in Ausdrücken wie “Prognose langer Lieferzeiten” oder “Prognose kurzer Lieferzeiten”, die sich auf eine Prognose der Nachfrage beziehen und nicht auf eine Prognose der Lieferzeit. Es ist möglich, diese Übung mit “Nachfragevorhersage” und “Lieferzeitvorhersage” und ähnlichen Ausdrücken und anderen Jahren zu wiederholen. Diese Variationen liefern ähnliche Ergebnisse. Ich überlasse es dem Publikum, das als Übung durchzuführen.

Daher haben wir als grobe Schätzung etwa tausendmal mehr Artikel über die Prognose der Nachfrage als über die Prognose der Lieferzeit. Supply Chain-Bücher und Supply Chain-Software folgen diesem Beispiel und lassen die Lieferzeit als Bürger zweiter Klasse und als belanglose technische Einzelheit zurück. Die in dieser Vortragsreihe vorgestellten Supply Chain-Mitarbeiter erzählen jedoch eine andere Geschichte. Diese Mitarbeiter mögen fiktive Unternehmen repräsentieren, aber sie spiegeln Supply Chain-Archetypen wider. Sie erzählen uns von der Art der Situation, die als typisch angesehen werden sollte. Schauen wir uns an, was diese Mitarbeiter uns in Bezug auf Lieferzeiten erzählen.

Paris ist eine fiktive Modemarke, die ihr eigenes Einzelhandelsnetzwerk betreibt. Paris bestellt bei ausländischen Lieferanten, wobei die Lieferzeiten lang sind und manchmal mehr als sechs Monate betragen. Diese Lieferzeiten sind nur unvollkommen bekannt, und dennoch muss die neue Kollektion zum richtigen Zeitpunkt im Geschäft eintreffen, wie es die mit der neuen Kollektion verbundene Marketingaktion definiert. Die Lieferzeiten der Lieferanten erfordern eine angemessene Vorhersage; mit anderen Worten, sie erfordern eine Prognose.

Amsterdam ist ein fiktives FMCG-Unternehmen, das sich auf die Produktion von Käse, Sahne und Butter spezialisiert hat. Der Reifungsprozess des Käses ist bekannt und kontrolliert, aber er variiert mit Abweichungen von einigen Tagen. Doch genau diese wenigen Tage sind die Dauer der intensiven Werbeaktionen, die von den Einzelhandelsketten ausgelöst werden, die zufällig der Hauptvertriebskanal von Amsterdam sind. Diese Herstellungszeiten erfordern eine Prognose.

Miami ist ein fiktives Luft- und Raumfahrt-MRO. MRO steht für Wartung, Reparatur und Überholung. Jeder Verkehrsflugzeug benötigt jährlich Tausende von Teilen, um weiterhin fliegen zu können. Ein einziges fehlendes Teil kann dazu führen, dass das Flugzeug am Boden bleibt. Die Reparaturdauer für ein reparierbares Teil, auch als TAT (Turnaround-Zeit) bezeichnet, definiert, wann das rotierende Teil wieder einsatzbereit wird. Die TAT variiert jedoch von Tagen bis Monaten, abhängig vom Umfang der Reparaturen, die zum Zeitpunkt des Ausbaus des Teils aus dem Flugzeug nicht bekannt sind. Diese TATs erfordern eine Prognose.

San Jose ist ein fiktives E-Commerce-Unternehmen, das eine Vielzahl von Wohnmöbeln und Accessoires vertreibt. Im Rahmen seines Service bietet San Jose für jede Transaktion ein Lieferdatum an. Die Lieferung selbst hängt jedoch von Drittanbieterunternehmen ab, die bei weitem nicht perfekt zuverlässig sind. Daher benötigt San Jose eine fundierte Schätzung des Lieferdatums, das für jede Transaktion zugesagt werden kann. Diese fundierte Schätzung ist implizit eine Prognose der Lieferzeit.

Schließlich ist Stuttgart ein fiktives Unternehmen für den Automobil-Ersatzteilmarkt. Es betreibt Filialen, die Autoreparaturen durchführen. Den niedrigsten Einkaufspreis für die Autoteile erhält man von Großhändlern, die lange und etwas unregelmäßige Lieferzeiten anbieten. Es gibt zuverlässigere, aber teurere und näher gelegene Lieferanten. Die Auswahl des richtigen Lieferanten für jedes Teil erfordert eine ordnungsgemäße vergleichende Analyse der jeweiligen Lieferzeiten, die mit verschiedenen Lieferanten verbunden sind.

Wie wir sehen können, erfordert jede einzelne vorgestellte Supply Chain-Mitarbeiterin oder jeder Mitarbeiter die Vorwegnahme von mindestens einer und häufig mehreren Lieferzeiten. Während man argumentieren könnte, dass die Prognose der Nachfrage mehr Aufmerksamkeit und Anstrengung erfordert als die Prognose der Lieferzeiten, werden letztendlich beide für nahezu alle Supply Chain-Situationen benötigt.

Werfen wir also einen Blick auf einige tatsächliche Lieferzeiten in der realen Welt. Auf dem Bildschirm sind drei Histogramme zu sehen, die durch Zusammenstellung beobachteter Lieferzeiten für drei mechanische Teile erstellt wurden. Diese Teile werden vom selben Lieferanten in Westeuropa bestellt. Die Bestellungen kommen von einem Unternehmen, das ebenfalls in Westeuropa ansässig ist. Die x-Achse gibt die Dauer der beobachteten Lieferzeiten in Tagen an, und die y-Achse gibt die Anzahl der Beobachtungen in Prozent an. Im Folgenden werden alle Histogramme die gleichen Konventionen verwenden, wobei die x-Achse mit Dauern in Tagen und die y-Achse mit der Häufigkeit verbunden sind. Aus diesen drei Verteilungen können wir bereits einige Beobachtungen machen.

Zunächst sind die Daten spärlich. Wir haben nur einige Dutzend Datenpunkte, und diese Beobachtungen wurden über mehrere Jahre gesammelt. Diese Situation ist typisch; wenn das Unternehmen nur einmal im Monat bestellt, dauert es fast ein Jahrzehnt, um über 100 Beobachtungen von Lieferzeiten zu sammeln. Was auch immer wir also in Bezug auf Statistik tun, sollte auf kleine Zahlen ausgerichtet sein, nicht auf große Zahlen. Tatsächlich werden wir selten das Privileg haben, mit großen Zahlen umzugehen.

Zweitens sind die Lieferzeiten unregelmäßig. Wir haben Beobachtungen von wenigen Tagen bis zu einem Viertel. Obwohl es immer möglich ist, eine durchschnittliche Lieferzeit zu berechnen, wäre es unklug, sich auf irgendeinen Durchschnittswert für eines dieser Teile zu verlassen. Es ist auch klar, dass keine dieser Verteilungen auch nur annähernd normal ist.

Drittens haben wir drei Teile, die in Größe und Preis einigermaßen vergleichbar sind, und dennoch variieren die Lieferzeiten stark. Es mag verlockend sein, diese Beobachtungen zusammenzufassen, um die Daten weniger spärlich zu machen, aber es ist offensichtlich unklug, dies zu tun, da dabei Verteilungen vermischt würden, die stark voneinander abweichen. Diese Verteilungen haben nicht den gleichen Mittelwert, Median oder sogar das gleiche Minimum oder Maximum.

Werfen wir einen Blick auf eine zweite Gruppe von Lieferzeiten. Diese Dauern spiegeln die Zeit wider, die benötigt wird, um drei verschiedene Flugzeugteile zu reparieren. Die erste Verteilung scheint zwei Modi plus einen Schwanz zu haben. Wenn eine Verteilung zwei Modi aufweist, deutet dies in der Regel auf das Vorhandensein einer versteckten Variable hin, die diese beiden Modi erklärt. Zum Beispiel könnte es zwei verschiedene Arten von Reparaturen geben, von denen jede Art mit einer eigenen Lieferzeit verbunden ist. Die zweite Verteilung scheint einen Modus plus einen Schwanz zu haben. Dieser Modus entspricht einer relativ kurzen Dauer von etwa zwei Wochen. Es könnte sich um einen Prozess handeln, bei dem das Teil zuerst inspiziert wird und manchmal als funktionsfähig ohne weitere Eingriffe eingestuft wird, daher eine viel kürzere Lieferzeit. Die dritte Verteilung scheint vollständig verteilt zu sein, ohne offensichtlichen Modus oder Schwanz. Hier könnten mehrere Reparaturprozesse im Spiel sein, die zusammengefasst werden. Die Spärlichkeit der Daten, mit nur drei Dutzend Beobachtungen, macht es schwierig, mehr zu sagen. Wir werden uns später in diesem Vortrag erneut mit dieser dritten Verteilung befassen.

Schließlich werfen wir einen Blick auf zwei Lieferzeiten, die die Versandverzögerungen von Taiwan an die US-Westküste widerspiegeln, entweder per Luft oder per Schiff. Es ist nicht überraschend, dass Frachtflugzeuge schneller sind als Frachtschiffe. Die zweite Verteilung deutet darauf hin, dass eine Seelieferung manchmal ihr ursprüngliches Schiff verpassen und dann mit dem nächsten Schiff verschickt werden könnte, wodurch sich die Verzögerung fast verdoppelt. Das gleiche Phänomen könnte auch bei der Luftfracht auftreten, obwohl die Daten so begrenzt sind, dass es nur eine wilde Vermutung ist. Wir möchten darauf hinweisen, dass es im Hinblick auf Lieferzeiten nicht ungewöhnlich ist, nur auf ein paar Beobachtungen zugreifen zu können. Diese Situationen sind häufig. Es ist wichtig zu bedenken, dass wir in diesem Vortrag nach Werkzeugen und Instrumenten suchen, mit denen wir mit den uns vorliegenden Lieferzeitdaten arbeiten können, auch wenn es nur eine Handvoll Beobachtungen sind, und nicht mit den Lieferzeitdaten, die wir gerne hätten, wie Tausende von Beobachtungen. Die kurzen Lücken in beiden Verteilungen deuten auch auf ein zyklisches Muster an bestimmten Wochentagen hin, obwohl die vorliegende Histogrammvisualisierung nicht geeignet ist, um diese Hypothese zu validieren.

Aus dieser kurzen Übersicht über reale Lieferzeiten können wir bereits einige der zugrunde liegenden Phänomene erkennen, die im Spiel sind. Tatsächlich sind Lieferzeiten stark strukturiert; Verzögerungen treten nicht ohne Grund auf, und diese Gründe können identifiziert, aufgeschlüsselt und quantifiziert werden. Allerdings werden die Details der Lieferzeitzerlegung häufig nicht in den IT-Systemen erfasst, zumindest noch nicht. Selbst wenn eine umfangreiche Zerlegung der beobachteten Lieferzeit vorhanden ist, wie dies in bestimmten Branchen wie der Luftfahrt der Fall sein kann, bedeutet dies nicht, dass Lieferzeiten perfekt vorhergesagt werden können. Teilsegmente oder Phasen innerhalb der Lieferzeit werden voraussichtlich ihre eigene unvermeidbare Unsicherheit aufweisen.

Diese Reihe von Lieferkettenvorlesungen präsentiert meine Ansichten und Erkenntnisse sowohl über das Studium als auch über die Praxis der Lieferkette. Ich versuche, diese Vorlesungen etwas unabhängig voneinander zu halten, aber sie ergeben mehr Sinn, wenn sie in der richtigen Reihenfolge angesehen werden. Der Rest dieser Vorlesung basiert auf Elementen, die zuvor in dieser Reihe eingeführt wurden, obwohl ich in einer Minute eine Auffrischung geben werde.

Das erste Kapitel ist eine allgemeine Einführung in das Gebiet und das Studium der Lieferkette. Es klärt die Perspektive, die in diese Vorlesungsreihe einfließt. Wie Sie bereits vermutet haben, weicht diese Perspektive erheblich von dem ab, was als Mainstream-Perspektive auf die Lieferkette betrachtet würde.

Das zweite Kapitel stellt eine Reihe von Methoden vor. Tatsächlich überwindet die Lieferkette naive Methoden. Lieferketten bestehen aus Menschen, die eigene Interessen haben; es gibt keine neutrale Partei in der Lieferkette. Dieses Kapitel behandelt diese Komplikationen, einschließlich meines eigenen Interessenkonflikts als CEO von Lokad, einem Unternehmen für Unternehmenssoftware, das sich auf die Vorhersage von Supply Chain-Optimierung spezialisiert hat.

Das dritte Kapitel stellt eine Reihe von Lieferketten-“Personas” vor. Diese Personas sind fiktive Unternehmen, die wir heute kurz besprochen haben, und sie sollen Archetypen von Lieferketten-Situationen darstellen. Der Zweck dieser Personas besteht darin, sich ausschließlich auf die Probleme zu konzentrieren und die Präsentation von Lösungen zu verschieben.

Das vierte Kapitel behandelt die Hilfswissenschaften der Lieferkette. Diese Wissenschaften befassen sich nicht direkt mit der Lieferkette, sollten aber als wesentlich für eine moderne Praxis der Lieferkette betrachtet werden. Dieses Kapitel umfasst eine Fortschreitung durch die Abstraktionsebenen, angefangen von der Computertechnik bis hin zu Cybersicherheitsfragen.

Das fünfte und aktuelle Kapitel ist der prädiktiven Modellierung gewidmet. Prädiktive Modellierung ist eine allgemeinere Perspektive als die Vorhersage; es geht nicht nur um die Vorhersage der Nachfrage. Es geht um die Gestaltung von Modellen, die zur Schätzung und Quantifizierung zukünftiger Faktoren der relevanten Lieferkette verwendet werden können. Heute gehen wir auf Lieferzeiten ein, aber allgemein gesprochen verdient alles, was nicht mit einem vernünftigen Maß an Sicherheit bekannt ist, eine Vorhersage.

Das sechste Kapitel erklärt, wie optimierte Entscheidungen unter Verwendung von prädiktiven Modellen berechnet werden können, und genauer gesagt, probabilistische Modelle, die im fünften Kapitel eingeführt wurden. Das siebte Kapitel kehrt zu einer weitgehend nicht-technischen Perspektive zurück, um die tatsächliche unternehmensinterne Durchführung einer quantitativen Lieferkette zu diskutieren.

Heute konzentrieren wir uns auf Lieferzeiten. Wir haben gerade gesehen, warum Lieferzeiten wichtig sind, und wir haben gerade eine kurze Reihe von realen Lieferzeiten überprüft. Daher werden wir mit Elementen der Lieferzeitmodellierung fortfahren. Da ich eine probabilistische Perspektive einnehmen werde, werde ich den Continuous Rank Probability Score (CRPS), eine Metrik zur Bewertung der Güte einer probabilistischen Vorhersage, kurz wieder einführen. Ich werde auch Kreuzvalidierung und eine Variante der Kreuzvalidierung vorstellen, die für unsere probabilistische Perspektive geeignet ist. Mit diesen Werkzeugen werden wir unser erstes nicht-naives probabilistisches Modell für Lieferzeiten einführen und bewerten. Lieferzeitdaten sind spärlich vorhanden, und der erste Punkt auf unserer Agenda besteht darin, diese Verteilungen zu glätten. Lieferzeiten können in eine Reihe von Zwischenphasen zerlegt werden. Daher benötigen wir, sofern einige zerlegte Lieferzeitdaten verfügbar sind, etwas, um diese Lieferzeiten unter Beibehaltung des probabilistischen Aspekts wieder zusammenzusetzen.

Dann werden wir differenzierbares Programmieren wieder einführen. Differenzierbares Programmieren wurde bereits in dieser Vorlesungsreihe verwendet, um die Nachfrage vorherzusagen, kann aber auch zur Vorhersage von Lieferzeiten verwendet werden. Wir werden dies tun, indem wir mit einem einfachen Beispiel beginnen, das den Einfluss des chinesischen Neujahrs auf Lieferzeiten erfasst, ein typisches Muster, das beim Import von Waren aus Asien beobachtet wird.

Anschließend werden wir ein parametrisches probabilistisches Modell für Lieferzeiten einführen, das die log-logistische Verteilung nutzt. Auch hier wird differenzierbares Programmieren dabei helfen, die Parameter des Modells zu erlernen. Wir werden dieses Modell dann erweitern, indem wir unvollständige Lieferzeitbeobachtungen berücksichtigen. Tatsächlich liefern uns selbst noch nicht abgeschlossene Bestellungen Informationen über die Lieferzeit.

Schließlich bringen wir eine probabilistische Lieferzeitprognose und eine probabilistische Nachfrageprognose in einer einzigen Bestandssituation Auffüllung zusammen. Dies wird die Gelegenheit sein, zu demonstrieren, warum Modularität ein wesentliches Anliegen ist, wenn es um die Vorhersagemodellierung geht, wichtiger sogar als die Feinheiten der Modelle selbst.

In Vorlesung 5.2 über probabilistische Vorhersagen haben wir bereits einige Werkzeuge vorgestellt, um die Qualität einer probabilistischen Vorhersage zu bewerten. Die üblichen Genauigkeitsmetriken wie mittlerer quadratischer Fehler oder mittlerer absoluter Fehler gelten nur für Punktprognosen, nicht für probabilistische Prognosen. Doch nur weil unsere Prognosen probabilistisch werden, wird die Genauigkeit im allgemeinen Sinne nicht irrelevant. Wir benötigen nur ein statistisches Instrument, das mit der probabilistischen Perspektive kompatibel ist.

Unter diesen Instrumenten gibt es den Continuous Rank Probability Score (CRPS). Die Formel wird auf dem Bildschirm angezeigt. Der CRPS ist eine Verallgemeinerung der L1-Metrik, das heißt des absoluten Fehlers, aber für Wahrscheinlichkeitsverteilungen. Der übliche Geschmack des CRPS vergleicht eine Verteilung, hier F genannt, mit einer Beobachtung, hier X genannt. Der Wert, der aus der CRPS-Funktion erhalten wird, ist homogen zur Beobachtung. Wenn X zum Beispiel eine Lieferzeit in Tagen ist, dann wird der CRPS-Wert ebenfalls in Tagen angegeben.

Der CRPS kann für den Vergleich von zwei Verteilungen verallgemeinert werden. Dies wird auf dem Bildschirm durchgeführt. Es handelt sich nur um eine geringfügige Variation der vorherigen Formel. Das Wesentliche dieser Metrik bleibt unverändert. Wenn F die wahre Lieferzeitverteilung ist und F_hat eine Schätzung der Lieferzeitverteilung ist, dann wird der CRPS in Tagen angegeben. Der CRPS spiegelt die Differenz zwischen den beiden Verteilungen wider. Der CRPS kann auch als minimale Energiemenge interpretiert werden, die benötigt wird, um die gesamte Masse von der ersten Verteilung so zu transportieren, dass sie die genaue Form der zweiten Verteilung annimmt.

Wir haben jetzt ein Instrument, um zwei eindimensionale Wahrscheinlichkeitsverteilungen zu vergleichen. Dies wird in Kürze interessant, wenn wir unser erstes probabilistisches Modell für Lieferzeiten einführen.

Eine Metrik zur Messung der Güte einer probabilistischen Prognose zu haben, reicht nicht aus. Die Metrik misst die Güte anhand der uns vorliegenden Daten. Was wir jedoch wirklich wollen, ist die Fähigkeit, die Güte unserer Prognose anhand von Daten zu bewerten, die uns nicht vorliegen. Tatsächlich interessieren uns die zukünftigen Lieferzeiten, nicht die bereits in der Vergangenheit beobachteten Lieferzeiten. Unsere Fähigkeit, ein Modell zu erstellen, das gut auf Daten funktioniert, die uns nicht vorliegen, wird als Generalisierung bezeichnet. Die Kreuzvalidierung ist eine allgemeine Modellvalidierungstechnik, die genau dazu dient, die Fähigkeit eines Modells zur guten Generalisierung zu bewerten.

In ihrer einfachsten Form besteht die Kreuzvalidierung darin, die Beobachtungen in eine kleine Anzahl von Teilmengen aufzuteilen. Für jede Iteration wird eine Teilmenge beiseite gelegt und als Testteilmenge bezeichnet. Das Modell wird dann auf der Grundlage der anderen Datenteilmengen, die als Trainingsmengen bezeichnet werden, generiert oder trainiert. Nach dem Training wird das Modell gegen die Testteilmenge validiert. Dieser Vorgang wird eine bestimmte Anzahl von Malen wiederholt, und die durchschnittliche Güte über alle Iterationen stellt das endgültige kreuzvalidierte Ergebnis dar.

Die Kreuzvalidierung wird im Zusammenhang mit der Prognose von Zeitreihen selten verwendet, aufgrund der zeitlichen Abhängigkeit zwischen den Beobachtungen. Tatsächlich geht die Kreuzvalidierung, wie gerade vorgestellt, davon aus, dass die Beobachtungen unabhängig voneinander sind. Wenn Zeitreihen involviert sind, wird stattdessen das Backtesting verwendet. Backtesting kann als eine Form der Kreuzvalidierung angesehen werden, die die zeitliche Abhängigkeit berücksichtigt.

Die Kreuzvalidierungstechnik bietet zahlreiche Varianten, die eine Vielzahl von potenziellen Aspekten widerspiegeln, die berücksichtigt werden müssen. Wir werden diese Varianten nicht im Rahmen dieser Vorlesung untersuchen. Ich werde eine spezifische Variante verwenden, bei der bei jeder Aufteilung die Trainings- und Testteilmenge ungefähr die gleiche Größe haben. Diese Variante wird eingeführt, um die Validierung eines probabilistischen Modells zu behandeln, wie wir gleich mit einigem Code sehen werden.

Lassen Sie uns eine der realen Lieferzeiten noch einmal betrachten, die wir zuvor auf dem Bildschirm gesehen haben. Links ist das Histogramm mit den dritten Verteilungen der Reparaturzeiten in der Luftfahrt verbunden. Dies sind dieselben Beobachtungen wie zuvor, und das Histogramm wurde lediglich vertikal gestreckt. Dadurch haben die beiden Histogramme links und rechts die gleiche Skala. Für das linke Histogramm haben wir etwa 30 Beobachtungen. Es ist nicht viel, aber es ist bereits mehr als das, was wir häufig bekommen werden.

Das Histogramm auf der linken Seite wird als empirische Verteilung bezeichnet. Es handelt sich buchstäblich um das rohe Histogramm, wie es aus den Beobachtungen erhalten wurde. Das Histogramm hat einen Eimer für jede Dauer, die in einer ganzzahligen Anzahl von Tagen ausgedrückt wird. Für jeden Eimer zählen wir die Anzahl der beobachteten Lieferzeiten. Aufgrund der Spärlichkeit sieht die empirische Verteilung wie ein Barcode aus.

Hier besteht ein Problem. Wenn wir genau zwei beobachtete Lieferzeiten von genau 50 Tagen haben, macht es dann Sinn zu sagen, dass die Wahrscheinlichkeit, entweder 49 Tage oder 51 Tage zu beobachten, genau null ist? Das tut es nicht. Offensichtlich gibt es eine Vielzahl von Dauern; wir haben einfach nicht genügend Datenpunkte, um die tatsächliche zugrunde liegende Verteilung zu beobachten, die höchstwahrscheinlich viel glatter ist als diese barcodeartige Verteilung.

Daher gibt es bei der Glättung dieser Verteilung eine unendliche Anzahl von Möglichkeiten, diese Glättungsoperation durchzuführen. Einige Glättungsmethoden mögen gut aussehen, sind aber statistisch nicht korrekt. Als guten Ausgangspunkt möchten wir sicherstellen, dass ein glattes Modell genauer ist als das empirische Modell. Es stellt sich heraus, dass wir bereits zwei Instrumente eingeführt haben, den CRPS und die Kreuzvalidierung, mit denen wir dies tun können.

In einer Minute werden die Ergebnisse angezeigt. Der mit der Barcode-Verteilung verbundene CRPS-Fehler beträgt 1,6 Tage, während der mit der glatten Verteilung verbundene CRPS-Fehler 1,4 Tage beträgt. Diese beiden Zahlen wurden durch Kreuzvalidierung ermittelt. Der niedrigere Fehler zeigt, dass die Verteilung auf der rechten Seite in Bezug auf den CRPS die genaueste der beiden ist. Der Unterschied von 0,2 zwischen 1,4 und 1,6 ist nicht so groß; jedoch ist die entscheidende Eigenschaft hier, dass wir eine glatte Verteilung haben, die bestimmte Zwischendauern nicht willkürlich mit einer Wahrscheinlichkeit von null verlässt. Dies ist vernünftig, da unser Verständnis der Reparaturen uns sagt, dass diese Dauern höchstwahrscheinlich auftreten würden, wenn Reparaturen wiederholt werden. Der CRPS spiegelt nicht die wahre Tiefe der Verbesserung wider, die wir gerade durch die Glättung der Verteilung erreicht haben. Zumindest bestätigt die Senkung des CRPS, dass diese Transformation aus statistischer Sicht vernünftig ist.

Schauen wir uns nun den Quellcode an, der diese beiden Modelle erstellt und diese beiden Histogramme anzeigt. Insgesamt wird dies in 12 Zeilen Code erreicht, wenn wir die Leerzeilen ausschließen. Wie üblich in dieser Vortragsreihe ist der Code in Envision geschrieben, der domänenspezifischen Programmiersprache von Lokad, die sich der prädiktiven Optimierung von Lieferketten widmet. Es gibt jedoch keine Magie; diese Logik könnte auch in Python geschrieben worden sein. Aber für die Art von Problemen, die wir in diesem Vortrag betrachten, ist Envision prägnanter und eigenständiger.

Lassen Sie uns diese 12 Zeilen Code überprüfen. In den Zeilen 1 und 2 lesen wir eine Excel-Tabelle ein, die eine einzelne Spalte mit Daten enthält. Die Tabelle enthält 30 Beobachtungen. Diese Daten werden in einer Tabelle namens “H” gesammelt, die eine einzelne Spalte namens “days” hat. In Zeile 4 erstellen wir eine empirische Verteilung. Die Variable “R” hat den Datentyp “ranvar” und auf der rechten Seite der Zuweisung ist die Funktion “ranvar” ein Aggregator, der Beobachtungen als Eingabe nimmt und das Histogramm mit dem Datentyp “ranvar” darstellt. Als Ergebnis ist der Datentyp “ranvar” für eindimensionale Ganzzahlverteilungen bestimmt. Wir haben den Datentyp “ranvar” in einem früheren Vortrag dieses Kapitels eingeführt. Dieser Datentyp garantiert einen konstanten Speicherbedarf und eine konstante Berechnungszeit für jede Operation. Der Nachteil des “ranvar” als Datentyp besteht darin, dass eine verlustbehaftete Kompression erfolgt, obwohl der durch die Kompression verursachte Datenverlust für Lieferkettenzwecke vernachlässigbar ist.

In Zeile 5 glätten wir die Verteilung mit der integrierten Funktion “smooth”. Unter der Haube ersetzt diese Funktion die ursprüngliche Verteilung durch eine Mischung von Poisson-Verteilungen. Jeder Eimer des Histogramms wird in eine Poisson-Verteilung mit einem Mittelwert gleich der ganzzahligen Position des Eimers umgewandelt, und schließlich weist die Mischung jedem Poisson-Verteilung eine Gewichtung zu, die proportional zum Gewicht des Eimers selbst ist. Eine andere Möglichkeit, zu verstehen, was diese “smooth” Funktion tut, besteht darin, dass sie jede einzelne Beobachtung durch eine Poisson-Verteilung mit einem Mittelwert gleich der Beobachtung selbst ersetzt. Alle diese Poisson-Verteilungen, eine pro Beobachtung, werden dann gemischt. Mischen bedeutet, die jeweiligen Werte der Histogrammeimer zu mitteln. Die “ranvar” Variablen “R” und “S” werden vor den Zeilen 14 und 15 nicht mehr verwendet, wo sie angezeigt werden.

In Zeile 7 beginnen wir einen Monte Carlo-Block. Dieser Block ist eine Art Schleife und wird 100 Mal ausgeführt, wie durch die 100 Werte angegeben, die direkt nach dem Schlüsselwort Monte Carlo erscheinen. Der Monte Carlo-Block soll unabhängige Beobachtungen sammeln, die gemäß einem Prozess generiert werden, der einen Grad an Zufälligkeit beinhaltet. Sie fragen sich vielleicht, warum es in Envision eine spezielle Monte Carlo-Konstruktion gibt, anstatt einfach eine Schleife zu haben, wie es bei Mainstream-Programmiersprachen üblich ist. Es stellt sich heraus, dass eine dedizierte Konstruktion erhebliche Vorteile bietet. Erstens garantiert sie, dass die Iterationen wirklich unabhängig sind, bis hin zu den zur Ableitung der Pseudorandomness verwendeten Seeds. Zweitens bietet sie ein explizites Ziel für die automatisierte Verteilung der Arbeitslast auf mehrere CPU-Kerne oder sogar auf mehrere Maschinen.

In Zeile 8 erstellen wir einen zufälligen Vektor von booleschen Werten in der Tabelle “H”. Mit dieser Zeile erzeugen wir unabhängige zufällige Werte, sogenannte Abweichungen (wahr oder falsch), für jede Zeile der Tabelle “H”. Wie üblich bei Envision werden die Schleifen durch Array-Programmierung abstrahiert. Mit diesen booleschen Werten teilen wir die Tabelle “H” in zwei Gruppen auf. Diese zufällige Aufteilung wird für den Kreuzvalidierungsprozess verwendet.

In den Zeilen 9 und 10 erstellen wir zwei “ranvars” namens “A” und “B”. Wir verwenden wieder den “ranvar” Aggregator, wenden aber diesmal einen Filter mit dem Schlüsselwort “when” direkt nach dem Aggregator-Aufruf an. “A” wird nur mit den Zeilen generiert, in denen der Wert in “a” wahr ist; für “B” ist es das Gegenteil. “B” wird nur mit den Zeilen generiert, in denen der Wert in “a” falsch ist.

In den Zeilen 11 und 12 sammeln wir die interessanten Zahlen aus dem Monte Carlo-Block. In Envision kann das Schlüsselwort “sample” nur innerhalb eines Monte Carlo-Blocks platziert werden. Es wird verwendet, um die Beobachtungen zu sammeln, die während vieler Iterationen des Monte Carlo-Prozesses gemacht werden. In Zeile 11 berechnen wir den durchschnittlichen Fehler, ausgedrückt in CRPS-Begriffen, zwischen zwei empirischen Verteilungen: einer Teilmenge aus dem ursprünglichen Satz von Vorlaufzeiten. Das Schlüsselwort “sample” gibt an, dass die Werte über die Monte Carlo-Iterationen gesammelt werden. Der Aggregator “AVG”, der für “Durchschnitt” auf der rechten Seite der Zuweisung steht, wird verwendet, um eine einzige Schätzung am Ende des Blocks zu erzeugen.

In Zeile 12 tun wir etwas fast Identisches wie in Zeile 11. Dieses Mal wenden wir jedoch die “smooth” Funktion auf den “ranvar” “B” an. Wir möchten beurteilen, wie nahe die glatte Variante der naiven empirischen Verteilung ist. Es stellt sich heraus, dass sie, zumindest in CRPS-Begriffen, näher ist als ihre ursprünglichen empirischen Gegenstücke.

In den Zeilen 14 und 15 stellen wir die Histogramme und die CRPS-Werte dar. Diese Zeilen erzeugen die Abbildungen, die wir in der vorherigen Folie gesehen haben. Dieses Skript liefert uns unsere Basis für die Qualität der empirischen Verteilung unseres Modells. Obwohl dieses Modell, das “Barcode”-Modell, naiv ist, ist es dennoch ein Modell und ein probabilistisches dazu. Daher liefert uns dieses Skript auch ein besseres Modell, zumindest im Sinne des CRPS, durch eine glatte Variante der ursprünglichen empirischen Verteilung.

Je nachdem, wie vertraut Sie mit Programmiersprachen sind, mag es im Moment vielleicht viel erscheinen. Ich möchte jedoch darauf hinweisen, wie einfach es ist, eine vernünftige Wahrscheinlichkeitsverteilung zu erzeugen, selbst wenn wir nicht mehr als ein paar Beobachtungen haben. Obwohl wir 12 Zeilen Code haben, stellen nur die Zeilen 4 und 5 den eigentlichen Modellierungsteil der Übung dar. Wenn wir nur an der glatten Variante interessiert wären, könnte der “ranvar” “S” mit einer einzigen Zeile Code geschrieben werden. Es ist also buchstäblich ein Einzeiler in Bezug auf den Code: Zuerst eine ranvar-Aggregation anwenden und dann einen glatten Operator anwenden, und wir sind fertig. Der Rest ist nur Instrumentierung und Anzeige. Mit den richtigen Werkzeugen kann probabilistische Modellierung, ob es sich um Vorlaufzeit oder etwas anderes handelt, äußerst einfach gemacht werden. Es gibt keine große Mathematik, keinen großen Algorithmus, keine großen Softwarekomponenten. Es ist einfach und bemerkenswert.

Wie bekommt man eine Lieferung, die sechs Monate zu spät ist? Die Antwort ist offensichtlich: einen Tag nach dem anderen. Spaß beiseite, Vorlaufzeiten können in der Regel in eine Reihe von Verzögerungen zerlegt werden. Zum Beispiel kann eine Lieferanten-Vorlaufzeit in eine Wartezeit zerlegt werden, während die Bestellung in eine Warteschlange gestellt wird, gefolgt von einer Fertigungsverzögerung, während die Ware produziert wird, und schließlich gefolgt von einer Transitverzögerung, während die Ware versendet wird. Wenn Vorlaufzeiten zerlegt werden können, ist es auch interessant, sie wieder zusammenzusetzen.

Wenn wir in einer hoch deterministischen Welt leben würden, in der die Zukunft genau vorhergesehen werden könnte, dann wäre das Zusammensetzen von Vorlaufzeiten nur eine Frage der Addition. Um auf das gerade erwähnte Beispiel zurückzukommen, wäre das Zusammenstellen der Bestellvorlaufzeit die Summe der Wartezeit in Tagen, der Fertigungsverzögerung in Tagen und der Transitverzögerung in Tagen. Doch wir leben nicht in einer Welt, in der die Zukunft genau vorhergesagt werden kann. Die realen Vorlaufzeitverteilungen, die wir am Anfang dieses Vortrags vorgestellt haben, unterstützen diese Aussage. Vorlaufzeiten sind unvorhersehbar, und es gibt wenig Grund zu der Annahme, dass sich dies in den kommenden Jahrzehnten grundlegend ändern wird.

Daher sollten zukünftige Vorlaufzeiten als Zufallsvariablen betrachtet werden. Diese Zufallsvariablen erfassen und quantifizieren die Unsicherheit anstatt sie abzulehnen. Konkret bedeutet dies, dass jede Komponente der Vorlaufzeit auch einzeln als Zufallsvariable modelliert werden sollte. Um auf unser Beispiel zurückzukommen, ist die Bestellvorlaufzeit eine Zufallsvariable, und sie wird als Summe von drei Zufallsvariablen erhalten, die jeweils mit der Wartezeit, der Fertigungsverzögerung und der Transitverzögerung verbunden sind.

Die Formel für die Summe von zwei unabhängigen, eindimensionalen, ganzzahligen Zufallsvariablen wird auf dem Bildschirm dargestellt. Diese Formel besagt lediglich, dass wenn wir eine Gesamtdauer von Z Tagen haben und wenn wir K Tage für die erste Zufallsvariable X haben, dann müssen wir Z minus K Tage für die zweite Zufallsvariable Y haben. Diese Art der Addition wird allgemein in der Mathematik als Faltung bezeichnet.

Obwohl es scheint, dass es eine unendliche Anzahl von Termen in dieser Faltung gibt, kümmern wir uns in der Praxis nur um eine endliche Anzahl von Termen. Erstens haben alle negativen Dauern eine Wahrscheinlichkeit von null; negative Verzögerungen würden tatsächlich bedeuten, dass man in der Zeit zurückreist. Zweitens werden die Wahrscheinlichkeiten für große Verzögerungen so klein, dass sie für praktische Zwecke in der Supply Chain zuverlässig als Nullen approximiert werden können.

Lassen Sie uns diese Faltungen in die Praxis umsetzen. Betrachten wir eine Transitzeit, die in zwei Phasen unterteilt werden kann: eine Versandverzögerung, gefolgt von einer Zollabfertigungsverzögerung. Wir möchten diese beiden Phasen mit zwei unabhängigen Zufallsvariablen modellieren und dann die Transitzeit durch Addition dieser beiden Zufallsvariablen wieder zusammensetzen.

Auf dem Bildschirm werden die Histogramme links vom Skript rechts erzeugt. In Zeile 1 wird die Versandverzögerung als Faltung einer Poisson-Verteilung plus einer Konstanten modelliert. Die Poisson-Funktion gibt einen “ranvar” Datentyp zurück; das Hinzufügen von drei bewirkt eine Verschiebung der Verteilung nach rechts. Der resultierende “ranvar” wird der Variablen “C” zugewiesen. Dieser “ranvar” wird in Zeile 3 angezeigt. Er ist links als oberstes Histogramm zu sehen. Wir erkennen die Form einer Poisson-Verteilung, die um einige Einheiten nach rechts verschoben wurde, in diesem Fall um drei Einheiten. In Zeile zwei wird die Zollabfertigung als Mischung aus einer Dirac-Funktion bei null und einer Poisson-Verteilung bei fünf modelliert. Die Dirac-Funktion bei null tritt achtzig Prozent der Zeit auf; das ist, was diese Konstante 0,8 bedeutet. Sie spiegelt Situationen wider, in denen die Waren die meiste Zeit nicht einmal vom Zoll inspiziert werden und ohne nennenswerte Verzögerung durchgehen. Alternativ werden zwanzig Prozent der Zeit die Waren beim Zoll inspiziert und die Verzögerung wird als Poisson-Verteilung mit einem Mittelwert von fünf modelliert. Der resultierende ranvar wird der Variablen D zugewiesen. Dieser ranvar wird in Zeile vier angezeigt und ist links als mittleres Histogramm zu sehen. Dieser asymmetrische Aspekt spiegelt wider, dass der Zoll die meiste Zeit keine Verzögerung hinzufügt.

Schließlich berechnen wir in Zeile fünf C plus D. Diese Addition ist eine Faltung, da sowohl C als auch D ranvars sind, keine Zahlen. Dies ist die zweite Faltung in diesem Skript, da bereits in Zeile eins eine Faltung stattgefunden hat. Der resultierende ranvar wird angezeigt und ist links als drittes und unterstes Histogramm sichtbar. Dieses dritte Histogramm ähnelt dem ersten, nur dass der Schwanz sich viel weiter nach rechts erstreckt. Noch einmal sehen wir, dass wir mit wenigen Zeilen Code nicht-triviale realweltliche Effekte wie Verzögerungen bei der Zollabfertigung angehen können.

Es könnten jedoch zwei Kritikpunkte an diesem Beispiel vorgebracht werden. Erstens sagt es nicht, woher die Konstanten stammen; in der Praxis möchten wir diese Konstanten aus historischen Daten lernen. Zweitens mag die Poisson-Verteilung den Vorteil der Einfachheit haben, aber sie ist möglicherweise keine sehr realistische Form für die Modellierung von Vorlaufzeiten, insbesondere in Fällen mit Fat Tails. Daher werden wir diese beiden Punkte nacheinander behandeln.

Um Parameter aus Daten zu lernen, werden wir ein Programmierparadigma wieder aufgreifen, das wir bereits in dieser Vortragsreihe eingeführt haben, nämlich das differenzierbare Programmieren. Wenn Sie die vorherigen Vorträge in diesem Kapitel noch nicht gesehen haben, lade ich Sie ein, sie nach dem Ende des vorliegenden Vortrags anzusehen. Das differenzierbare Programmieren wird in diesen Vorträgen ausführlicher behandelt.

Das differenzierbare Programmieren ist eine Kombination aus zwei Techniken: stochastischer Gradientenabstieg und automatische Differentiation. Der stochastische Gradientenabstieg ist eine Optimierungstechnik, die die Parameter eine Beobachtung nach der anderen in die entgegengesetzte Richtung der Gradienten verschiebt. Die automatische Differentiation ist eine Kompilierungstechnik, ähnlich dem Compiler einer Programmiersprache. Sie berechnet die Gradienten für alle Parameter, die in einem allgemeinen Programm vorkommen.

Lassen Sie uns das differenzierbare Programmieren anhand eines Vorlaufzeitproblems veranschaulichen. Dies dient entweder als Auffrischung oder als Einführung, abhängig von Ihrer Vertrautheit mit diesem Paradigma. Wir möchten den Einfluss des chinesischen Neujahrs auf die Vorlaufzeiten von Importen aus China modellieren. Tatsächlich verlängern sich die Vorlaufzeiten, da die Fabriken für zwei oder drei Wochen zum chinesischen Neujahr geschlossen sind. Das chinesische Neujahr ist zyklisch und findet jedes Jahr statt. Es ist jedoch nicht streng saisonal, zumindest nicht im Sinne des gregorianischen Kalenders.

In den Zeilen eins bis sechs stellen wir einige simulierten Bestellungen mit vier Beobachtungen vor, jeweils mit einem Bestelldatum und einem Empfangsdatum. In der Praxis würden diese Daten nicht fest codiert sein, sondern wir würden diese historischen Daten aus den Systemen des Unternehmens laden. In den Zeilen acht und neun berechnen wir, ob die Vorlaufzeit mit dem chinesischen Neujahr zusammenfällt. Die Variable “T.overlap_CNY” ist ein boolescher Vektor; sie gibt an, ob die Beobachtung vom chinesischen Neujahr beeinflusst wird oder nicht.

In Zeile 12 führen wir einen “autodiff”-Block ein. Die Tabelle T wird als Beobachtungstabelle verwendet und es gibt 1000 Epochen. Das bedeutet, dass jede Beobachtung, also jede Zeile in der Tabelle T, tausendmal besucht wird. Ein Schritt des stochastischen Gradientenabstiegs entspricht einer Ausführung der Logik innerhalb des “autodiff”-Blocks.

In den Zeilen 13 und 14 werden zwei skalare Parameter deklariert. Der “autodiff”-Block wird diese Parameter lernen. Der Parameter A spiegelt die Baseline-Vorlaufzeit ohne den Effekt des chinesischen Neujahrs wider, und der Parameter B spiegelt die zusätzliche Verzögerung durch das chinesische Neujahr wider. In Zeile 15 berechnen wir X, die Vorhersage der Vorlaufzeit unseres Modells. Dies ist ein deterministisches Modell, kein probabilistisches; X ist eine Punkt-Vorlaufzeitprognose. Die rechte Seite der Zuweisung ist einfach: Wenn die Beobachtung mit dem chinesischen Neujahr zusammenfällt, geben wir die Baseline plus die Neujahrskomponente zurück; andernfalls geben wir nur die Baseline zurück. Da der “autodiff”-Block immer nur eine einzelne Beobachtung auf einmal nimmt, bezieht sich in Zeile 15 die Variable T.overlap_CNY auf einen Skalarwert und nicht auf einen Vektor. Dieser Wert entspricht der ausgewählten Zeile als Beobachtungszeile innerhalb der Tabelle T.

Die Parameter A und B sind in die Exponentialfunktion “exp” eingewickelt, was ein kleiner Trick des differenzierbaren Programmierens ist. Tatsächlich neigt der Algorithmus, der den stochastischen Gradientenabstieg steuert, dazu, relativ konservativ zu sein, wenn es um die inkrementellen Variationen der Parameter geht. Wenn wir also einen positiven Parameter lernen möchten, der größer als beispielsweise 10 werden kann, beschleunigt das Einwickeln dieses Parameters in einen exponentiellen Prozess die Konvergenz.

In Zeile 16 geben wir einen mittleren quadratischen Fehler zwischen unserer Vorhersage X und der beobachteten Dauer in Tagen (T.days) zurück. Auch innerhalb dieses “autodiff”-Blocks ist T.days ein Skalarwert und kein Vektor. Da die Tabelle T als Beobachtungstabelle verwendet wird, wird der Rückgabewert als Verlust behandelt, der durch den stochastischen Gradientenabstieg minimiert wird. Die automatische Differentiation propagiert die Gradienten vom Verlust rückwärts zu den Parametern A und B. Schließlich zeigen wir in Zeile 19 die beiden Werte an, die wir gelernt haben, nämlich A und B, die Baseline und die Neujahrskomponente unserer Vorlaufzeit.

Damit schließen wir unsere Wiedereinführung des differenzierbaren Programmierens als vielseitiges Werkzeug zur Erkennung statistischer Muster ab. Von hier aus werden wir die “autodiff”-Blöcke mit komplexeren Situationen erneut besuchen. Lassen Sie uns jedoch noch einmal darauf hinweisen, dass hier eigentlich nichts wirklich Kompliziertes passiert, auch wenn es sich vielleicht ein wenig überwältigend anfühlen mag. Wahrscheinlich ist das komplizierteste Stück Code in diesem Skript die zugrunde liegende Implementierung der Funktion “ChineseYearStart”, die in Zeile acht aufgerufen wird und Teil der Envision-Standardbibliothek ist. Mit nur wenigen Zeilen Code führen wir ein Modell mit zwei Parametern ein und lernen diese Parameter. Auch hier ist diese Einfachheit bemerkenswert.

Vorlaufzeiten weisen häufig eine fette Schwanzverteilung auf, das heißt, wenn eine Vorlaufzeit abweicht, weicht sie stark ab. Daher ist es interessant, Verteilungen anzunehmen, die dieses fette Schwanzverhalten reproduzieren können. Die mathematische Literatur präsentiert eine umfangreiche Liste solcher Verteilungen, und einige wenige würden unserem Zweck dienen. Das Durchsuchen der mathematischen Landschaft würde jedoch Stunden dauern. Lassen Sie uns nur darauf hinweisen, dass die Poisson-Verteilung keinen fetten Schwanz hat. Daher werde ich heute die log-logistische Verteilung wählen, die eine fette Schwanzverteilung ist. Die Hauptbegründung für diese Wahl der Verteilung ist, dass die Lokad-Teams Vorlaufzeiten für mehrere Kunden mit log-logistischen Verteilungen modellieren. Es funktioniert gut mit einer minimalen Anzahl von Komplikationen. Wir sollten jedoch im Hinterkopf behalten, dass die log-logistische Verteilung keineswegs ein Allheilmittel ist und es zahlreiche Situationen gibt, in denen Lokad Vorlaufzeiten anders modelliert.

Auf dem Bildschirm haben wir die Wahrscheinlichkeitsdichtefunktion der log-logistischen Verteilung. Dies ist eine parametrische Verteilung, die von zwei Parametern, Alpha und Beta, abhängt. Der Alpha-Parameter ist der Median der Verteilung und der Beta-Parameter bestimmt die Form der Verteilung. Auf der rechten Seite kann eine kurze Reihe von Formen durch verschiedene Beta-Werte erhalten werden. Obwohl diese Dichtefunktion einschüchternd aussehen mag, ist sie buchstäblich Lehrmaterial, genau wie die Formel zur Berechnung des Volumens einer Kugel. Sie können versuchen, diese Formel zu entschlüsseln und auswendig zu lernen, aber das ist nicht einmal notwendig; Sie müssen nur wissen, dass es eine analytische Formel gibt. Sobald Sie wissen, dass die Formel existiert, dauert es weniger als eine Minute, um sie online wiederzufinden.

Unser Ziel ist es, die log-logistische Verteilung zu nutzen, um ein probabilistisches Vorlaufzeitmodell zu lernen. Um dies zu tun, werden wir das Log-Likelihood minimieren. Tatsächlich haben wir in der vorherigen Vorlesung in diesem fünften Kapitel gesehen, dass es mehrere Metriken gibt, die für die probabilistische Perspektive geeignet sind. Vor kurzem haben wir den CRPS (Continuous Ranked Probability Score) erneut besprochen. Hier überprüfen wir das Log-Likelihood, das eine bayesianische Perspektive annimmt.

Kurz gesagt, gibt uns die log-logistische Verteilung bei gegebenen zwei Parametern die Wahrscheinlichkeit, jede Beobachtung in dem empirischen Datensatz zu beobachten. Wir möchten die Parameter lernen, die diese Wahrscheinlichkeit maximieren. Der Logarithmus, daher das Log-Likelihood anstelle des einfachen Likelihoods, wird eingeführt, um numerische Unterläufe zu vermeiden. Numerische Unterläufe treten auf, wenn wir sehr kleine Zahlen verarbeiten, die sehr nahe bei Null liegen; diese sehr kleinen Zahlen spielen nicht gut mit der in moderner Computertechnik üblichen Gleitkommadarstellung zusammen.

Daher wenden wir zur Berechnung des Log-Likelihoods der log-logistischen Verteilung den Logarithmus auf ihre Wahrscheinlichkeitsdichtefunktion an. Der analytische Ausdruck wird auf dem Bildschirm angezeigt. Dieser Ausdruck kann implementiert werden, und genau das wird in den drei Codezeilen unten gemacht.

In Zeile eins wird die Funktion “L4” eingeführt. L4 steht für “Log-Likelihood der log-logistischen Verteilung” - ja, das sind viele L’s und viele Logarithmen. Diese Funktion hat drei Argumente: die beiden Parameter alpha und beta sowie die Beobachtung x. Diese Funktion gibt den Logarithmus des Likelihoods zurück. Die Funktion L4 ist mit dem Schlüsselwort “autodiff” dekoriert; das Schlüsselwort gibt an, dass diese Funktion durch automatische Differentiation differenziert werden soll. Mit anderen Worten, Gradienten können rückwärts vom Rückgabewert dieser Funktion zu ihren Argumenten, den Parametern alpha und beta, fließen. Technisch gesehen fließt der Gradient auch rückwärts durch die Beobachtung x; da wir jedoch die Beobachtungen während des Lernprozesses unveränderlich halten werden, haben die Gradienten keine Auswirkungen auf die Beobachtungen. In Zeile drei erhalten wir die wörtliche Transkription der mathematischen Formel direkt über dem Skript.

Lassen Sie uns nun die Dinge mit einem Skript zusammenfügen, das die Parameter eines probabilistischen Vorlaufzeitmodells auf der Grundlage der log-logistischen Verteilung lernt. In den Zeilen eins und drei generieren wir unseren simulierten Trainingsdatensatz. In realen Umgebungen würden wir anstelle von simulierten Daten historische Daten verwenden. In Zeile eins erstellen wir eine “ranvar”, die die ursprüngliche Verteilung repräsentiert. Für die Übung möchten wir diese Parameter, alpha und beta, zurücklernen. Die log-logistische Funktion ist Teil der Standardbibliothek von Envision und gibt eine “ranvar” zurück. In Zeile zwei erstellen wir die Tabelle “H”, die 1.000 Einträge enthält. In Zeile drei ziehen wir 1.000 Abweichungen, die zufällig aus der ursprünglichen Verteilung “R” ausgewählt wurden. Dieser Vektor “H.days” repräsentiert den Trainingsdatensatz.

In Zeile sechs haben wir einen “autodiff”-Block; hier findet das Lernen statt. In den Zeilen sieben und acht deklarieren wir zwei Parameter, alpha und beta, und um numerische Probleme wie Division durch Null zu vermeiden, werden Grenzen auf diese Parameter angewendet. Alpha muss größer als 0,01 bleiben und beta muss größer als 1,0 bleiben. In Zeile neun geben wir den Verlust zurück, der das Gegenteil des Log-Likelihoods ist. Tatsächlich minimieren “autodiff”-Blöcke die Verlustfunktion konventionell, und daher möchten wir die Wahrscheinlichkeit maximieren, daher das Minuszeichen. Die Funktion “log_likelihood.logistic” ist Teil der Standardbibliothek von Envision, aber unter der Haube ist es nur die Funktion “L4”, die wir in der vorherigen Folie implementiert haben. Es gibt also keine Magie hier; es ist alles automatisierte Differentiation, die den Gradienten rückwärts vom Verlust zu den Parametern alpha und beta fließen lässt.

In den Zeilen 11 und 12 werden die ursprüngliche Verteilung und die gelernte Verteilung geplottet. Die Histogramme sind auf 200 begrenzt; diese Begrenzung macht das Histogramm etwas lesbarer. Dazu kommen wir gleich. Falls Sie sich über die Leistung des “autodiff”-Teils dieses Skripts wundern, dauert es weniger als 80 Millisekunden, um auf einem einzelnen CPU-Kern ausgeführt zu werden. Differentiable Programmierung ist nicht nur vielseitig, sondern nutzt auch die von moderner Computertechnik bereitgestellten Ressourcen gut.

Auf dem Bildschirm haben wir die beiden Histogramme, die von unserem Skript erstellt wurden und die wir gerade überprüft haben. Oben die ursprüngliche Verteilung mit ihren beiden ursprünglichen Parametern, Alpha und Beta, jeweils 80 und 4. Unten die gelernte Verteilung mit zwei durch differentiable Programmierung gelernten Parametern. Diese beiden Spitzen ganz rechts sind mit den abgeschnittenen Schwänzen verbunden, da diese Schwänze ziemlich weit reichen. Übrigens kommt es zwar selten vor, aber es kann vorkommen, dass bestimmte Waren mehr als ein Jahr nach der Bestellung geliefert werden. Dies ist nicht für jede Branche der Fall, sicherlich nicht für Milchprodukte, aber für mechanische Teile oder Elektronik kommt es gelegentlich vor.

Obwohl der Lernprozess nicht exakt ist, erhalten wir Ergebnisse innerhalb von einem Prozent der ursprünglichen Parameterwerte. Dies zeigt zumindest, dass diese Maximierung der Log-Likelihood durch differentiable Programmierung in der Praxis funktioniert. Die log-logistische Verteilung mag angemessen sein oder auch nicht; es hängt von der Form der Lead-Time-Verteilung ab, mit der Sie konfrontiert sind. Wir können jedoch praktisch jede alternative parametrische Verteilung wählen. Alles, was dazu erforderlich ist, ist ein analytischer Ausdruck der Wahrscheinlichkeitsdichtefunktion. Es gibt eine Vielzahl solcher Verteilungen. Sobald Sie eine Formel aus einem Lehrbuch haben, erledigt eine einfache Implementierung durch differentiable Programmierung normalerweise den Rest.

Lead-Zeiten werden nicht erst beobachtet, wenn die Transaktion abgeschlossen ist. Während die Transaktion noch läuft, wissen Sie bereits etwas; Sie haben bereits eine unvollständige Beobachtung der Lead-Zeit. Nehmen wir an, vor 100 Tagen haben Sie eine Bestellung aufgegeben. Die Ware ist noch nicht eingetroffen, aber Sie wissen bereits, dass die Lead-Zeit mindestens 100 Tage beträgt. Diese Dauer von 100 Tagen stellt die untere Grenze für eine noch nicht vollständig beobachtete Lead-Zeit dar. Diese unvollständigen Lead-Zeiten sind häufig sehr wichtig. Wie ich zu Beginn dieses Vortrags erwähnt habe, sind Lead-Time-Datensätze häufig spärlich. Es ist nicht ungewöhnlich, einen Datensatz zu haben, der nur eine Handvoll Beobachtungen enthält. In solchen Situationen ist es wichtig, das Beste aus jeder Beobachtung zu machen, einschließlich derjenigen, die noch in Bearbeitung sind.

Betrachten wir das folgende Beispiel: Wir haben insgesamt fünf Bestellungen. Drei Bestellungen wurden bereits mit Lead-Zeit-Werten geliefert, die sehr nahe bei 30 Tagen lagen. Die letzten beiden Bestellungen sind jedoch seit 40 bzw. 50 Tagen ausstehend. Gemäß den ersten drei Beobachtungen sollte die durchschnittliche Lead-Zeit etwa 30 Tage betragen. Die letzten beiden Bestellungen, die noch unvollständig sind, widerlegen jedoch diese Hypothese. Die beiden ausstehenden Bestellungen von 40 und 50 Tagen deuten auf eine deutlich längere Lead-Zeit hin. Daher sollten wir die letzten Bestellungen nicht einfach verwerfen, weil sie unvollständig sind. Wir sollten diese Informationen nutzen und unsere Überzeugung in Richtung längerer Lead-Zeiten aktualisieren, vielleicht 60 Tage.

Lassen Sie uns unser probabilistisches Lead-Zeit-Modell noch einmal überdenken, diesmal jedoch unvollständige Beobachtungen berücksichtigen. Mit anderen Worten, wir möchten uns mit Beobachtungen befassen, die manchmal nur eine untere Grenze für die endgültige Lead-Zeit darstellen. Um dies zu tun, können wir die kumulative Verteilungsfunktion (CDF) der log-logistischen Verteilung verwenden. Diese Formel wird auf dem Bildschirm angezeigt; auch dies ist Lehrmaterial. Die CDF der log-logistischen Verteilung profitiert von einem einfachen analytischen Ausdruck. Im Folgenden werde ich diese Technik als “bedingte Wahrscheinlichkeitstechnik” bezeichnen, um mit zensierten Daten umzugehen.

Basierend auf diesem analytischen Ausdruck der CDF können wir die Log-Likelihood der log-logistischen Verteilung überdenken. Das Skript auf dem Bildschirm bietet eine überarbeitete Implementierung unserer vorherigen Implementierung in L4. In Zeile eins haben wir praktisch die gleiche Funktionsdeklaration. Diese Funktion nimmt ein zusätzliches viertes Argument an, einen booleschen Wert namens “is_incomplete”, der, wie der Name schon sagt, angibt, ob die Beobachtung unvollständig ist oder nicht. In den Zeilen zwei und drei, wenn die Beobachtung vollständig ist, fallen wir wieder auf die vorherige Situation mit der regulären log-logistischen Verteilung zurück. Daher rufen wir die Log-Likelihood-Funktion auf, die Teil der Standardbibliothek ist. Ich hätte den Code der vorherigen Implementierung in L4 wiederholen können, aber diese Version ist prägnanter. In den Zeilen vier und fünf drücken wir die Log-Likelihood aus, dass letztendlich eine Lead-Zeit größer als die aktuelle unvollständige Beobachtung “X” beobachtet wird. Dies wird durch die CDF und genauer gesagt den Logarithmus der CDF erreicht.

Wir können nun unsere Einrichtung mit einem Skript wiederholen, das die Parameter der log-logistischen Verteilung lernt, diesmal jedoch in Anwesenheit unvollständiger Lead-Zeiten. Das Skript auf dem Bildschirm ist fast identisch mit dem vorherigen. In den Zeilen eins bis drei generieren wir die Daten; diese Zeilen haben sich nicht geändert. Beachten Sie, dass H.N ein automatisch generierter Vektor ist, der implizit in Zeile zwei erstellt wird. Dieser Vektor nummeriert die generierten Zeilen, beginnend bei eins. Die vorherige Version dieses Skripts verwendete diesen automatisch generierten Vektor nicht, aber jetzt erscheint der H.N-Vektor am Ende von Zeile sechs.

Die Zeilen fünf und sechs sind tatsächlich die wichtigen. Hier zensieren wir die Lead-Zeiten. Es ist, als ob wir pro Tag eine Lead-Zeitbeobachtung machen und die Beobachtungen abschneiden, die zu aktuell sind, um informiert zu werden. Das bedeutet zum Beispiel, dass eine 20-tägige Lead-Zeit, die vor sieben Tagen begonnen hat, als unvollständige siebentägige Lead-Zeit erscheint. Am Ende von Zeile sechs haben wir eine Liste von Lead-Zeiten generiert, bei denen einige der aktuellen Beobachtungen (diejenigen, die über das aktuelle Datum hinaus enden würden) unvollständig sind. Der Rest des Skripts bleibt unverändert, außer in Zeile 12, wo der H.is_complete-Vektor als viertes Argument der Log-Likelihood-Funktion übergeben wird. Somit rufen wir in Zeile 12 die differenzierbare Programmierfunktion auf, die wir gerade vor einer Minute eingeführt haben.

Schließlich werden auf dem Bildschirm die beiden Histogramme von diesem überarbeiteten Skript erzeugt. Die Parameter werden immer noch mit hoher Genauigkeit erlernt, während wir uns jetzt in der Anwesenheit zahlreicher unvollständiger Lead-Zeiten befinden. Um zu validieren, dass der Umgang mit unvollständigen Zeiten keine unnötige Komplikation war, habe ich das Skript erneut ausgeführt, diesmal jedoch mit einer modifizierten Variation mit der dreifachen Überladung der Log-Likelihood-Funktion (diejenige, die wir anfangs verwendet haben und angenommen haben, dass alle Beobachtungen vollständig sind). Für Alpha und Beta erhalten wir die am unteren Rand des Bildschirms angezeigten Werte. Wie erwartet stimmen diese Werte überhaupt nicht mit den ursprünglichen Werten von Alpha und Beta überein.

In dieser Reihe von Vorlesungen ist dies nicht das erste Mal, dass eine Technik eingeführt wurde, um mit zensierten Daten umzugehen. In der zweiten Vorlesung dieses Kapitels wurde die Verlustmaskierungstechnik eingeführt, um mit Fehlbeständen umzugehen. Tatsächlich möchten wir in der Regel zukünftige Nachfrage vorhersagen, nicht zukünftige Verkäufe. Fehlbestände führen zu einer nach unten gerichteten Verzerrung, da wir nicht alle Verkäufe beobachten können, die stattgefunden hätten, wenn der Fehlbestand nicht aufgetreten wäre. Die bedingte Wahrscheinlichkeitstechnik kann verwendet werden, um mit zensierter Nachfrage umzugehen, wie es bei Fehlbeständen der Fall ist. Die bedingte Wahrscheinlichkeitstechnik ist etwas komplexer als die Verlustmaskierung, daher sollte sie wahrscheinlich nicht verwendet werden, wenn die Verlustmaskierung ausreicht.

Im Fall von Vorlaufzeiten ist die Datenknappheit die Hauptmotivation. Wir haben möglicherweise so wenig Daten, dass es entscheidend sein kann, das Beste aus jeder einzelnen Beobachtung zu machen, auch aus den unvollständigen. Tatsächlich ist die bedingte Wahrscheinlichkeitstechnik mächtiger als die Verlustmaskierung, da sie unvollständige Beobachtungen nutzt, anstatt sie einfach zu verwerfen. Wenn zum Beispiel eine Einheit auf Lager ist und diese eine Einheit verkauft wird, dann deutet dies auf einen Fehlbestand hin. Die bedingte Wahrscheinlichkeitstechnik nutzt immer noch die Information, dass die Nachfrage größer oder gleich eins war.

Hier erhalten wir einen überraschenden Vorteil der probabilistischen Modellierung: Sie bietet uns eine elegante Möglichkeit, mit Zensur umzugehen, einem Effekt, der in zahlreichen Supply-Chain-Situationen auftritt. Durch bedingte Wahrscheinlichkeit können wir ganze Klassen systematischer Verzerrungen eliminieren.

Vorlaufzeitprognosen sind in der Regel dazu gedacht, mit Nachfrageprognosen kombiniert zu werden. Betrachten wir nun eine einfache Bestandsauffüllungssituation, wie sie auf dem Bildschirm dargestellt ist.

Wir bieten ein einziges Produkt an und der Bestand kann durch Nachbestellung von einem einzigen Lieferanten aufgefüllt werden. Wir suchen eine Prognose, die unsere Entscheidung unterstützt, ob wir von dem Lieferanten nachbestellen sollen oder nicht. Wir können jetzt nachbestellen, und wenn wir dies tun, werden die Waren zum Zeitpunkt der “ersten Ankunft” eintreffen. Später haben wir eine weitere Gelegenheit zur Nachbestellung. Diese spätere Gelegenheit tritt zu einem Zeitpunkt ein, der als “nächste Bestellung” bezeichnet wird, und in diesem Fall werden die Waren zum Zeitpunkt der “zweiten Ankunft” eintreffen. Der als “Verantwortungsfenster” angegebene Zeitraum ist der Zeitraum, der für unsere Nachbestellungsentscheidung relevant ist.

Tatsächlich wird alles, was wir beschließen nachzubestellen, nicht vor der ersten Vorlaufzeit eintreffen. Daher haben wir bereits die Kontrolle über die Bedienung der Nachfrage für alles verloren, was vor der ersten Ankunft passiert. Dann, da wir eine spätere Gelegenheit zur Nachbestellung haben werden, ist es nicht mehr unsere Verantwortung, die Nachfrage nach der zweiten Ankunft zu bedienen; dies ist die Verantwortung der nächsten Nachbestellung. Daher sollte die Nachbestellung, mit der Absicht, die Nachfrage über die zweite Ankunft hinaus zu bedienen, bis zur nächsten Nachbestellmöglichkeit verschoben werden.

Um die Nachbestellungsentscheidung zu unterstützen, sollten zwei Faktoren prognostiziert werden. Erstens sollten wir den erwarteten Lagerbestand zum Zeitpunkt der ersten Ankunft prognostizieren. Wenn zum Zeitpunkt der ersten Ankunft noch viel Bestand vorhanden ist, gibt es keinen Grund, jetzt nachzubestellen. Zweitens sollten wir die erwartete Nachfrage für die Dauer des Verantwortungsfensters prognostizieren. In einem realen Setup müssten wir auch die Nachfrage über das Verantwortungsfenster hinaus prognostizieren, um die Lagerhaltungskosten der bestellten Waren zu bewerten, da es möglicherweise Restbestände gibt, die in spätere Perioden übergehen. Aus Gründen der Kürze und des Timings werden wir uns heute jedoch auf den erwarteten Lagerbestand und die erwartete Nachfrage im Hinblick auf das Verantwortungsfenster konzentrieren.

Dieses Skript implementiert die Faktoren oder Prognosen des Verantwortungsfensters, die wir gerade besprochen haben. Es nimmt eine probabilistische Vorlaufzeitprognose und eine probabilistische Nachfrageprognose als Eingabe und liefert zwei Verteilungen von Wahrscheinlichkeiten zurück, nämlich den Lagerbestand bei Ankunft und die berechtigte Nachfrage im Rahmen des Verantwortungsfensters.

In den Zeilen eins und zwei stellen wir die Zeitleisten ein, die am 1. Januar beginnen und am 1. März enden. In einem Vorhersageszenario wäre diese Zeitleiste nicht fest codiert. In Zeile vier wird ein vereinfachtes probabilistisches Nachfragemodell eingeführt: eine Poisson-Verteilung, die Tag für Tag für die gesamte Dauer dieser Zeitleiste wiederholt wird. Die Nachfrage beträgt im Durchschnitt ein Stück pro Tag. Ich verwende hier ein vereinfachtes Modell für die Nachfrage, um die Klarheit zu erhöhen. In einem realen Szenario würden wir zum Beispiel ein ESSM (Ensemble State Space Model) verwenden. Zustandsraummodelle sind probabilistische Modelle und wurden in der allerersten Vorlesung dieses Kapitels eingeführt.

In Zeile fünf wird ein weiteres vereinfachtes probabilistisches Modell eingeführt. Dieses zweite Modell ist für Vorlaufzeiten gedacht. Es handelt sich um eine Poisson-Verteilung, die um sieben Tage nach rechts verschoben ist. Die Verschiebung erfolgt durch eine Faltung. In Zeile sechs definieren wir den anfänglichen Lagerbestand. In Zeile sieben definieren wir den Bestellzyklus. Dieser Wert wird in Tagen ausgedrückt und kennzeichnet, wann die nächste Nachbestellung erfolgen wird.

Von Zeile 9 bis 16 haben wir einen Monte Carlo-Block, der die Kernlogik des Skripts darstellt. In dieser Vorlesung haben wir bereits einen anderen Monte Carlo-Block eingeführt, um unsere Kreuzvalidierungslogik zu unterstützen. Hier verwenden wir dieses Konstrukt erneut, aber für einen anderen Zweck. Wir möchten zwei Zufallsvariablen berechnen, die jeweils den Lagerbestand bei Ankunft und die berechtigte Nachfrage widerspiegeln. Die Algebra der Zufallsvariablen ist jedoch nicht ausdrucksstark genug, um diese Berechnung durchzuführen. Daher verwenden wir stattdessen einen Monte Carlo-Block.

In der dritten Vorlesung dieses Kapitels habe ich darauf hingewiesen, dass es eine Dualität zwischen probabilistischer Prognose und Simulationen gibt. Der Monte Carlo-Block veranschaulicht diese Dualität. Wir beginnen mit einer probabilistischen Prognose, wandeln sie in eine Simulation um und wandeln schließlich die Ergebnisse der Simulation wieder in eine andere probabilistische Prognose um.

Werfen wir einen Blick auf das Kleingedruckte. In Zeile 10 generieren wir eine Trajektorie für die Nachfrage. In Zeile 11 generieren wir das Ankunftsdatum für die erste Bestellung, unter der Annahme, dass wir heute bestellen. In Zeile 12 generieren wir das Ankunftsdatum für die zweite Bestellung, unter der Annahme, dass wir einen Bestellzyklus von jetzt an bestellen. In Zeile 13 berechnen wir den verbleibenden Lagerbestand am ersten Ankunftsdatum. Es handelt sich um den anfänglichen Lagerbestand abzüglich der für die Dauer der ersten Vorlaufzeit beobachteten Nachfrage. Das Maximum von Null besagt, dass der Lagerbestand nicht ins Negative gehen kann. Mit anderen Worten, wir nehmen an, dass wir keinen Rückstand haben. Diese Annahme ohne Rückstand könnte geändert werden. Der Rückstand-Fall bleibt dem Publikum als Übung überlassen. Als Hinweis: Differentiable Programming kann verwendet werden, um den Prozentsatz der nicht bedienten Nachfrage zu bewerten, der erfolgreich in Rückstände umgewandelt wird, abhängig davon, wie viele Tage es bis zur erneuten Verfügbarkeit des Lagerbestands gibt.

Zurück zum Skript, in Zeile 14 berechnen wir die berechtigte Nachfrage, die die Nachfrage ist, die während des Verantwortungsfensters auftritt. In den Zeilen 15 und 16 sammeln wir zwei interessante Zufallsvariablen mit dem Schlüsselwort “sample”. Im Gegensatz zum ersten Envision-Skript dieser Vorlesung, das sich mit der Kreuzvalidierung befasste, möchten wir hier Verteilungen von Wahrscheinlichkeiten aus diesem Monte Carlo-Block sammeln, nicht nur Durchschnittswerte. In den Zeilen 15 und 16 ist die Zufallsvariable, die auf der rechten Seite der Zuweisung erscheint, ein Aggregator. In Zeile 15 erhalten wir eine Zufallsvariable für den Lagerbestand bei Ankunft. In Zeile 16 erhalten wir eine weitere Zufallsvariable für die Nachfrage, die innerhalb des Verantwortungsfensters auftritt.

In den Zeilen 18 und 19 werden diese beiden Zufallsvariablen angezeigt. Lassen Sie uns nun für einen Moment innehalten und dieses gesamte Skript überdenken. Die Zeilen eins bis sieben dienen lediglich der Einrichtung der Mock-Daten. Die Zeilen 18 und 19 zeigen nur die Ergebnisse an. Die eigentliche Logik findet nur in den acht Zeilen zwischen den Zeilen 9 und 16 statt. Tatsächlich befindet sich die gesamte eigentliche Logik in gewisser Weise in den Zeilen 13 und 14.

Mit nur wenigen Zeilen Code, weniger als 10, unabhängig von der Zählweise, kombinieren wir eine probabilistische Vorhersage der Lieferzeit mit einer probabilistischen Nachfragevorhersage, um eine Art hybride probabilistische Vorhersage der tatsächlichen Bedeutung der Lieferkette zu erstellen. Beachten Sie, dass hier nichts wirklich von den spezifischen Eigenschaften der Lieferzeitvorhersage oder der Nachfragevorhersage abhängt. Einfache Modelle wurden verwendet, aber auch anspruchsvollere hätten verwendet werden können. Es hätte nichts geändert. Die einzige Voraussetzung ist, dass zwei probabilistische Modelle vorhanden sind, damit es möglich wird, diese Trajektorien zu generieren.

Schließlich auf dem Bildschirm die Histogramme, wie sie vom Skript erzeugt wurden. Das obere Histogramm repräsentiert den Lagerbestand bei Ankunft. Es besteht eine ungefähre Wahrscheinlichkeit von 30%, dass der anfängliche Lagerbestand null beträgt. Mit anderen Worten, es besteht eine 30%ige Wahrscheinlichkeit, dass bis zum letzten Tag vor dem ersten Ankunftsdatum ein Lagerbestandsmangel aufgetreten ist. Der durchschnittliche Lagerbestand könnte etwa fünf Einheiten betragen. Wenn wir diese Situation jedoch anhand des Durchschnitts beurteilen würden, würden wir die Situation ernsthaft missverstehen. Eine probabilistische Vorhersage ist unerlässlich, um die anfängliche Lagerbestandssituation angemessen widerzuspiegeln.

Das untere Histogramm repräsentiert die Nachfrage im Verantwortungsfenster. Es besteht eine ungefähre Wahrscheinlichkeit von 10%, dass null Nachfrage besteht. Dieses Ergebnis könnte ebenfalls überraschend wahrgenommen werden. Tatsächlich haben wir diese Übung mit einer stationären Poisson-Nachfrage von durchschnittlich einer Einheit pro Tag begonnen. Wir haben sieben Tage zwischen den Bestellungen. Wenn es nicht für die variierende Lieferzeit wäre, hätte es weniger als eine 0,1%ige Wahrscheinlichkeit gegeben, über sieben Tage keine Nachfrage zu haben. Das Skript beweist jedoch, dass dieses Ereignis viel häufiger auftritt. Der Grund dafür ist, dass ein kleines Verantwortungsfenster auftreten kann, wenn die erste Lieferzeit länger als üblich ist und die zweite Lieferzeit kürzer als üblich ist.

Wenn über das Verantwortungsfenster hinweg keine Nachfrage besteht, besteht die Wahrscheinlichkeit, dass der Lagerbestand zu einem bestimmten Zeitpunkt recht hoch wird. Je nach Situation kann dies kritisch sein oder auch nicht, aber es könnte zum Beispiel kritisch sein, wenn es eine Lagerkapazitätsgrenze gibt oder wenn der Bestand verderblich ist. Nochmals, die durchschnittliche Nachfrage, wahrscheinlich um acht, gibt keinen zuverlässigen Einblick in das Aussehen der Nachfrage. Denken Sie daran, dass wir diese stark asymmetrische Verteilung aus einer anfänglichen stationären Nachfrage, einer Einheit pro Tag im Durchschnitt, erhalten haben. Dies ist der Effekt der variierenden Lieferzeit in Aktion.

Dieses einfache Setup demonstriert die Bedeutung von Lieferzeiten bei der Bestandsauffüllung. Aus Sicht der Lieferkette ist es bestenfalls eine praktische Abstraktion, Lieferzeitvorhersagen von Nachfragevorhersagen zu isolieren. Die tägliche Nachfrage ist nicht das, was uns wirklich interessiert. Was wirklich interessiert, ist die Zusammensetzung der Nachfrage mit der Lieferzeit. Wenn andere stochastische Faktoren vorhanden wären, wie Rückstände oder Rücksendungen, wären diese Faktoren ebenfalls Teil des Modells gewesen.

Das vorliegende Kapitel dieser Vortragsreihe trägt den Titel “Prädiktives Modellieren” anstelle von “Nachfrageprognose”, wie es in gängigen Lehrbüchern zur Lieferkette üblich wäre. Der Grund für diesen Kapiteltitel sollte im Verlauf dieses Vortrags allmählich offensichtlich geworden sein. Tatsächlich möchten wir aus Sicht der Lieferkette die Entwicklung des Lieferketten-Systems prognostizieren. Die Nachfrage ist sicherlich ein wichtiger Faktor, aber nicht der einzige. Andere variable Faktoren wie die Lieferzeit müssen ebenfalls prognostiziert werden. Noch wichtiger ist, dass all diese Faktoren letztendlich gemeinsam prognostiziert werden müssen.

Tatsächlich müssen wir diese prädiktiven Komponenten zusammenbringen, um einen entscheidungsbasierten Optimierungsprozess zu unterstützen. Daher kommt es nicht darauf an, nach einem Modell für die Nachfrageprognose zu suchen, das das endgültige Ziel darstellt. Diese Aufgabe ist letztendlich ein aussichtsloses Unterfangen, da die zusätzliche Genauigkeit auf Kosten des Unternehmensgewinns erzielt wird. Mehr Raffinesse bedeutet mehr Undurchsichtigkeit, mehr Fehler, mehr Rechenressourcen. Als Faustregel gilt: Je raffinierter das Modell, desto schwieriger wird es, dieses Modell erfolgreich mit einem anderen Modell zu kombinieren. Es kommt darauf an, eine Sammlung von prädiktiven Techniken zusammenzustellen, die nach Belieben kombiniert werden können. Das ist es, worum es bei Modularität im Hinblick auf prädiktives Modellieren geht. In diesem Vortrag wurden eine halbe Dutzend Techniken vorgestellt. Diese Techniken sind nützlich, da sie kritische Aspekte der realen Welt wie unvollständige Beobachtungen behandeln. Sie sind auch einfach; keines der heute vorgestellten Codebeispiele umfasste mehr als 10 Zeilen tatsächlicher Logik. Am wichtigsten ist, dass diese Techniken modular sind, wie Lego-Steine. Sie funktionieren gut zusammen und können nahezu endlos neu kombiniert werden.

Das Endziel des prädiktiven Modellierens für die Lieferkette besteht darin, solche Techniken zu identifizieren. Jede Technik sollte für sich genommen eine Gelegenheit bieten, ein vorhandenes prädiktives Modell zu überarbeiten, um dieses Modell zu vereinfachen oder zu verbessern.

Zusammenfassend lässt sich sagen, dass die Lieferzeit trotz ihrer weitgehenden Ignoranz in der akademischen Gemeinschaft prognostiziert werden kann und sollte. Durch die Überprüfung einer kurzen Reihe von realen Lieferzeitverteilungen haben wir zwei Herausforderungen identifiziert: Erstens variieren die Lieferzeiten; zweitens sind die Lieferzeiten spärlich. Daher haben wir Modellierungstechniken eingeführt, die geeignet sind, mit Lieferzeitbeobachtungen umzugehen, die sowohl spärlich als auch unregelmäßig sind.

Diese Lieferzeitmodelle sind probabilistisch und stellen in hohem Maße eine Fortsetzung der Modelle dar, die im Verlauf dieses Kapitels schrittweise eingeführt wurden. Wir haben auch gesehen, dass die Wahrscheinlichkeitsperspektive eine elegante Lösung für das Problem unvollständiger Beobachtungen bietet, das ein nahezu allgegenwärtiger Aspekt in der Lieferkette ist. Dieses Problem tritt immer dann auf, wenn Bestände ausverkauft sind und wenn Bestellungen ausstehen. Schließlich haben wir gesehen, wie man eine probabilistische Lieferzeitprognose mit einer probabilistischen Nachfrageprognose kombiniert, um das prädiktive Modell zu erstellen, das wir zur Unterstützung eines späteren Entscheidungsprozesses benötigen.

Der nächste Vortrag findet am 8. März statt. Es wird ein Mittwoch zur gleichen Tageszeit sein, 15 Uhr Pariser Zeit. Der heutige Vortrag war technisch, aber der nächste wird größtenteils nicht-technisch sein, und ich werde den Fall des Supply Chain Scientist diskutieren. Tatsächlich behandeln gängige Lehrbücher zur Lieferkette die Lieferkette so, als ob Prognosemodelle und Optimierungsmodelle aus dem Nichts entstehen und funktionieren würden, ohne ihre “Wetware”-Komponente zu beachten - das heißt, die verantwortlichen Personen. Daher werden wir uns genauer mit den Aufgaben und Verantwortlichkeiten des Supply Chain Scientists befassen, einer Person, die erwartet wird, die quantitative Supply Chain Initiative anzuführen.

Nun werde ich mit den Fragen fortfahren.

Frage: Was ist, wenn jemand seinen Bestand für weitere Innovationen oder aus anderen Gründen als Just-in-Time oder anderen Konzepten behalten möchte?

Dies ist in der Tat eine sehr wichtige Frage. Das Konzept wird typischerweise durch die wirtschaftliche Modellierung der Lieferkette behandelt, die wir in dieser Vortragsreihe technisch als “wirtschaftliche Treiber” bezeichnen. Sie fragen, ob es besser ist, einem Kunden heute nicht zu dienen, weil es zu einem späteren Zeitpunkt die Möglichkeit gibt, dieselbe Einheit einer anderen Person zu dienen, die aus irgendeinem Grund wichtiger ist. Im Wesentlichen sagen Sie, dass es mehr Wert gibt, indem Sie einen anderen Kunden später bedienen, vielleicht einen VIP-Kunden, als einen Kunden heute zu bedienen.

Das kann der Fall sein und es kommt vor. Zum Beispiel in der Luftfahrtindustrie, nehmen wir an, Sie sind ein MRO (Wartung, Reparatur und Überholung) Anbieter. Sie haben Ihre üblichen VIP-Kunden - die Fluggesellschaften, die Sie regelmäßig mit Langzeitverträgen bedienen, und sie sind sehr wichtig. Wenn dies der Fall ist, möchten Sie sicherstellen, dass Sie diese Kunden immer bedienen können. Aber was ist, wenn eine andere Fluggesellschaft anruft und nach einer Einheit fragt? In diesem Fall könnten Sie diese Person bedienen, haben aber keinen Langzeitvertrag mit ihnen. Also, was Sie tun werden, ist den Preis so anzupassen, dass er sehr hoch ist, um sicherzustellen, dass Sie genug Wert erhalten, um den möglichen Lagerbestandsausfall auszugleichen, mit dem Sie möglicherweise zu einem späteren Zeitpunkt konfrontiert sind. Das Fazit für diese erste Frage ist, dass es meiner Meinung nach nicht wirklich eine Frage der Prognose, sondern eher eine Frage der ordnungsgemäßen Modellierung der wirtschaftlichen Treiber ist. Wenn Sie den Bestand erhalten möchten, möchten Sie ein Modell generieren - ein Optimierungsmodell -, bei dem die rationale Antwort nicht darin besteht, den Kunden zu bedienen, der nach einer Einheit fragt, während Sie noch Bestand in Reserve haben.

Übrigens ist eine weitere typische Situation dafür, wenn Sie Kits verkaufen. Ein Kit ist eine Zusammenstellung vieler Teile, die zusammen verkauft werden, und Sie haben nur noch ein Teil übrig, das nur einen kleinen Bruchteil des Gesamtwerts des Kits wert ist. Das Problem ist, dass Sie, wenn Sie diese letzte Einheit verkaufen, Ihr Kit nicht mehr zum vollen Preis zusammenbauen und verkaufen können. Daher könnten Sie in einer Situation sein, in der Sie die Einheit nur für den Fall behalten möchten, dass Sie das Kit zu einem späteren Zeitpunkt verkaufen können, möglicherweise mit einiger Unsicherheit. Aber auch hier geht es um die wirtschaftlichen Treiber, und das wäre der Weg, wie ich mit dieser Situation umgehen würde.

Frage: In den letzten Jahren sind die meisten Verzögerungen in der Lieferkette auf Krieg oder Pandemie zurückzuführen, was sehr schwer vorherzusagen ist, da wir zuvor keine solchen Situationen hatten. Wie ist Ihre Meinung dazu?

Meine Meinung ist, dass Vorlaufzeiten schon immer variiert haben. Ich bin seit 2008 in der Welt der Lieferkette tätig und meine Eltern haben bereits 30 Jahre vor mir in der Lieferkette gearbeitet. Soweit wir uns erinnern können, waren Vorlaufzeiten unbeständig und variabel. Es passiert immer etwas, sei es ein Protest, ein Krieg oder eine Änderung der Zölle. Ja, die letzten Jahre waren außergewöhnlich unbeständig, aber Vorlaufzeiten haben sich bereits stark verändert.

Ich stimme zu, dass niemand vorgeben kann, den nächsten Krieg oder die nächste Pandemie vorhersagen zu können. Wenn es möglich wäre, diese Ereignisse mathematisch vorherzusagen, würden die Menschen sich nicht an Kriegen beteiligen oder in die Lieferkette investieren; sie würden einfach an der Börse spielen und reich werden, indem sie Marktbewegungen antizipieren.

Die Quintessenz ist, dass man sich auf das Unerwartete vorbereiten kann. Wenn Sie nicht zuversichtlich in die Zukunft schauen, können Sie tatsächlich die Variationen in Ihren Prognosen erhöhen. Es ist das Gegenteil davon, Ihre Prognose genauer machen zu wollen - Sie behalten Ihre durchschnittlichen Erwartungen bei, erhöhen jedoch einfach den Schwanz, damit die Entscheidungen, die Sie aufgrund dieser probabilistischen Prognosen treffen, widerstandsfähiger gegenüber Variationen sind. Sie haben Ihre erwarteten Variationen größer gemacht als das, was Sie derzeit sehen. Die Quintessenz ist, dass die Vorstellung, dass Dinge leicht oder schwer vorherzusagen sind, aus einer Punktprognose-Perspektive stammt, bei der Sie das Spiel so spielen möchten, als ob es möglich wäre, eine präzise Vorahnung der Zukunft zu haben. Das ist nicht der Fall - es gibt keine präzise Vorahnung der Zukunft. Das Einzige, was Sie tun können, ist, mit Wahrscheinlichkeitsverteilungen zu arbeiten, die eine große Streuung aufweisen und Ihre Unwissenheit über die Zukunft manifestieren und quantifizieren.

Anstatt Entscheidungen fein abzustimmen, die kritisch von der genauen Ausführung des genauen Plans abhängen, berücksichtigen und planen Sie eine interessante Variation, um Ihre Entscheidungen robuster gegenüber diesen Variationen zu machen. Dies gilt jedoch nur für die Art von Variation, die Ihre Lieferkette nicht zu stark beeinflusst. Sie können beispielsweise längere Vorlaufzeiten der Lieferanten bewältigen, aber wenn Ihr Lager bombardiert wurde, wird Sie keine Prognose in dieser Situation retten.

Frage: Können wir diese Histogramme erstellen und den CRPS zum Beispiel in Microsoft Excel berechnen, indem wir Excel-Add-Ins wie itsastat oder ähnliche verwenden?

Ja, das können Sie. Einer von uns bei Lokad hat tatsächlich eine Excel-Tabelle erstellt, die ein probabilistisches Modell für eine Bestandsauffüllungssituation darstellt. Der Knackpunkt des Problems ist, dass Excel keinen nativen Histogramm-Datentyp hat. In Excel haben Sie nur Zahlen - eine Zelle, eine Zahl. Es wäre elegant und einfach, einen Wert zu haben, der ein Histogramm ist, bei dem Sie ein vollständiges Histogramm in einer Zelle haben. Soweit ich weiß, ist dies jedoch in Excel nicht möglich. Wenn Sie jedoch bereit sind, etwa 100 Zeilen zu verwenden, um das Histogramm darzustellen, können Sie eine Verteilung in Excel implementieren und einige probabilistische Modellierung durchführen. Wir werden den Link zum Beispiel im Kommentarbereich veröffentlichen.

Beachten Sie, dass dies eine relativ mühsame Aufgabe ist, da Excel nicht ideal für diese Aufgabe geeignet ist. Excel ist eine Programmiersprache und Sie können damit alles tun, sodass Sie nicht einmal ein Add-In benötigen, um dies zu erreichen. Es wird jedoch etwas umständlich sein, also erwarten Sie nichts Superordentliches.

Frage: Die Vorlaufzeit kann in Komponenten wie Bestellzeit, Produktionszeit, Transportzeit usw. unterteilt werden. Wie würde sich dieser Ansatz ändern, wenn man eine detailliertere Kontrolle über die Vorlaufzeiten haben möchte?

Zunächst müssen wir darüber nachdenken, was es bedeutet, mehr Kontrolle über die Vorlaufzeit zu haben. Möchten Sie die durchschnittliche Vorlaufzeit reduzieren oder die Variabilität der Vorlaufzeit reduzieren? Interessanterweise habe ich viele Unternehmen gesehen, die erfolgreich die durchschnittliche Vorlaufzeit reduzieren, aber dafür etwas mehr Vorlaufzeitvariation in Kauf nehmen. Im Durchschnitt ist die Vorlaufzeit kürzer, aber ab und zu ist sie viel länger.

In dieser Vorlesung führen wir eine Modellierungsübung durch. An sich gibt es keine Handlung; es geht nur um Beobachtung, Analyse und Vorhersage. Wenn wir jedoch die Vorlaufzeit zerlegen und die zugrunde liegende Verteilung analysieren können, können wir probabilistische Modellierung verwenden, um festzustellen, welche Komponenten am stärksten variieren und welche die größten negativen Auswirkungen auf unsere Lieferkette haben. Mit diesen Informationen können wir “Was-wäre-wenn”-Szenarien durchspielen. Nehmen wir zum Beispiel einen Teil Ihrer Vorlaufzeit und fragen: “Was wäre, wenn der Schwanz dieser Vorlaufzeit etwas kürzer wäre oder der Durchschnitt etwas kürzer wäre?” Sie können dann alles neu zusammensetzen, Ihr Vorhersagemodell für Ihre gesamte Lieferkette erneut ausführen und die Auswirkungen bewerten.

Mit diesem Ansatz können Sie stückweise über bestimmte Phänomene nachdenken, einschließlich unregelmäßiger Phänomene. Es wäre nicht so sehr eine Änderung des Ansatzes, sondern eine Fortsetzung dessen, was wir getan haben, die uns zu Kapitel 6 führt, das sich mit der Optimierung tatsächlicher Entscheidungen auf der Grundlage dieser probabilistischen Modelle befasst.

Frage: Ich glaube, dies bietet die Möglichkeit, unsere Vorlaufzeiten in SAP neu zu berechnen, um einen realistischeren Zeitrahmen zu bieten und unser System-Pull-In und Pull-Out zu minimieren. Ist das möglich?

Haftungsausschluss: SAP ist ein Konkurrent von Lokad im Bereich der Optimierung von Lieferketten. Meine erste Antwort lautet nein, SAP kann das nicht. Die Realität ist, dass SAP vier verschiedene Lösungen hat, die sich mit der Optimierung von Lieferketten befassen, und es hängt davon ab, von welchem Stack Sie sprechen. All diese Stacks haben jedoch gemeinsam, dass sie auf Punktprognosen ausgerichtet sind. Alles in SAP wurde unter der Annahme entwickelt, dass Prognosen genau sein werden.

Ja, SAP hat einige Parameter, die eingestellt werden können, wie die Normalverteilung, von der ich am Anfang dieser Vorlesung gesprochen habe. Die beobachteten Vorlaufzeitverteilungen waren jedoch nicht normalverteilt. Nach meinem Kenntnisstand verwenden die gängigen SAP-Setups für die Optimierung von Lieferketten eine Normalverteilung für Vorlaufzeiten. Das Problem ist, dass die Software im Kern von einer weitgehend falschen mathematischen Annahme ausgeht. Sie können sich von einer weitgehend falschen Annahme, die direkt in den Kern Ihrer Softwarearchitektur geht, nicht erholen, indem Sie einen Parameter einstellen. Theoretisch ist dies möglich, aber in der Praxis birgt es so viele Probleme, dass die Frage ist, warum Sie das wirklich tun möchten?

Um eine probabilistische Perspektive anzunehmen, müssen Sie vollständig dabei sein, d.h. Ihre Prognosen sind probabilistisch und Ihre Optimierungsmodelle nutzen ebenfalls probabilistische Modelle. Das Problem hierbei ist, dass selbst wenn wir die probabilistische Modellierung für etwas bessere Vorlaufzeiten optimieren könnten, der Rest des SAP-Stacks wieder auf Punktprognosen zurückfallen würde. Egal was passiert, wir werden diese Verteilungen auf Punkte reduzieren. Die Idee, dass Sie dies durch einen Durchschnitt annähern könnten, ist problematisch und einfach falsch. Technisch gesehen könnten Sie Vorlaufzeiten optimieren, aber danach werden Sie auf so viele Probleme stoßen, dass es möglicherweise nicht den Aufwand wert ist.

Frage: Es gibt Situationen, in denen Sie die gleichen Teile von verschiedenen Lieferanten bestellen. Diese Informationen sind wichtig für die Vorlaufzeitprognose. Führen Sie die Vorlaufzeitprognose nach Artikel durch oder gibt es Situationen, in denen Sie von der Gruppierung von Artikeln in Familien profitieren?

Das ist eine äußerst interessante Frage. Wir haben zwei Lieferanten für den gleichen Artikel. Die Frage ist, wie ähnlich sich die Artikel und die Lieferanten sind. Zunächst müssen wir uns die Situation ansehen. Wenn ein Lieferant nebenan ist und der andere Lieferant auf der anderen Seite der Welt ist, müssen Sie diese Dinge wirklich getrennt betrachten. Aber nehmen wir die interessante Situation an, dass die beiden Lieferanten ziemlich ähnlich sind und es sich um den gleichen Artikel handelt. Sollten Sie diese Beobachtungen zusammenfassen oder nicht?

Das Interessante ist, dass Sie durch differenzierbare Programmierung ein Modell erstellen können, das dem Lieferanten und dem Artikel ein gewisses Gewicht gibt und die Lernmagie ihre Magie wirken lässt. Es wird feststellen, ob wir mehr Gewicht auf die Artikelkomponente der Vorlaufzeit oder auf die Lieferantenkomponente legen sollten. Es könnte sein, dass zwei Lieferanten, die ziemlich ähnliche Produkte liefern, eine gewisse Voreingenommenheit haben, bei der ein Lieferant im Durchschnitt etwas schneller ist als der andere. Aber es gibt Artikel, die definitiv mehr Zeit in Anspruch nehmen, und wenn Sie Artikel auswählen, ist es nicht ganz klar, dass ein Lieferant schneller ist als der andere, weil es wirklich davon abhängt, welche Artikel Sie betrachten. Sie haben höchstwahrscheinlich sehr wenig Daten, wenn Sie alles bis auf jeden Lieferanten und jeden Artikel disaggregieren. Daher ist das Interessante und was ich hier empfehlen würde, durch differenzierbare Programmierung zu entwickeln. Wir könnten tatsächlich versuchen, diese Situation in einer späteren Vorlesung zu überdenken, eine Situation, in der Sie einige Parameter auf der Teilebene und einige Parameter auf der Lieferantenebene festlegen. Sie haben also eine Gesamtzahl von Parametern, die nicht die Anzahl der Teile mal die Anzahl der Lieferanten ist; das wäre die Anzahl der Teile plus die Anzahl der Lieferanten oder vielleicht plus die Anzahl der Lieferanten mal Kategorien oder etwas Ähnliches. Sie explodieren nicht die Anzahl Ihrer Parameter; Sie fügen nur einen Parameter hinzu, ein Element, das eine Affinität zum Lieferanten hat, und das ermöglicht Ihnen eine Art dynamische Mischung, die von Ihren historischen Daten gesteuert wird.

Frage: Ich glaube, die bestellte Menge und welche Produkte zusammen bestellt werden, könnten auch die Vorlaufzeit am Ende beeinflussen. Könnten Sie die Komplexität erläutern, alle Variablen in dieser Art von Problem einzubeziehen?

Im letzten Beispiel hatten wir zwei Arten von Dauer: den Bestellzyklus und die Vorlaufzeit selbst. Der Bestellzyklus ist interessant, weil er nur unsicher ist, soweit wir die Entscheidung noch nicht getroffen haben. Es ist grundsätzlich etwas, das Sie zu jedem beliebigen Zeitpunkt entscheiden können, daher ist der Bestellzyklus vollständig intern und von Ihnen selbst gemacht. Dies ist nicht das einzige in der Supply Chain, was so ist; Preise sind genauso. Sie haben eine Nachfrage, Sie beobachten die Nachfrage, aber Sie können tatsächlich den Preis wählen, den Sie möchten. Einige Preise sind offensichtlich unklug, aber es ist dasselbe - es liegt in Ihrer Hand.

Der Bestellzyklus liegt in Ihrer Hand. Nun, was Sie sagen, ist, dass es Unsicherheit darüber gibt, zu welchem genauen Zeitpunkt die nächste Bestellvorlaufzeit liegt, weil Sie nicht genau wissen, wann Sie bestellen werden. Tatsächlich haben Sie vollkommen recht. Was passiert ist, dass, wenn Sie die Kapazität haben, dieses probabilistische Modell umzusetzen, plötzlich, wie im sechsten Kapitel dieser Vorlesungsreihe diskutiert, möchten Sie nicht sagen, dass der Bestellzyklus sieben Tage beträgt. Stattdessen möchten Sie eine Nachbestellungsrichtlinie übernehmen, die die Rendite für Ihr Unternehmen maximiert. Daher können Sie die Zukunft so planen, dass Sie, wenn Sie jetzt bestellen, eine Entscheidung treffen können und dann Ihre Richtlinie Tag für Tag anwenden können. Irgendwann in der Zukunft machen Sie eine Nachbestellung, und jetzt haben Sie eine Art “Schlange, die ihren Schwanz frisst”-Situation, weil die beste Bestellentscheidung für heute von der Entscheidung der nächsten Bestellentscheidung abhängt, die Sie noch nicht getroffen haben. Diese Art von Problem wird als Richtlinienproblem bezeichnet und ist ein sequenzielles Entscheidungsproblem. Im Kern möchten Sie tatsächlich eine Art Richtlinie erstellen, ein mathematisches Objekt, das Ihren Entscheidungsprozess steuert.

Das Problem der Richtlinienoptimierung ist ziemlich kompliziert, und ich beabsichtige, dies im sechsten Kapitel zu behandeln. Aber das Fazit ist, dass wir, wenn wir zu Ihrer Frage zurückkehren, zwei unterschiedliche Komponenten haben. Wir haben die Komponente, die unabhängig von dem, was Sie tun, variiert, die Vorlaufzeit, die Ihre Lieferanten-Vorlaufzeit ist, und dann haben Sie die Bestellzeit, die etwas ist, das wirklich intern von Ihrem Prozess gesteuert wird und als Optimierungsfrage behandelt werden sollte.

Zusammenfassend sehen wir eine Konvergenz von Optimierung und prädiktiver Modellierung. Am Ende sind die beiden so ziemlich dasselbe, weil es Wechselwirkungen zwischen den Entscheidungen gibt, die Sie treffen, und dem, was in der Zukunft passiert.

Das war es für heute. Vergessen Sie nicht, am 8. März zur gleichen Zeit, es wird ein Mittwoch sein, um 15 Uhr. Vielen Dank und bis zum nächsten Mal.