Probabilistische Prognose der Durchlaufzeit

Die genaue Schätzung zukünftiger Durchlaufzeiten ist für eine exakte Schätzung des Bestandsbedarfs zur Erfüllung der künftigen Nachfrage ausschlaggebend. Lokads Prognose-Engine bietet auch den Modus Prognose der Durchlaufzeit, der besonders für Durchlaufzeiten erstellt wurde. In der Tat müssen Durchlaufzeiten, genauso prognostiziert werden, wie der Bedarf. Durchlaufzeiten zeigen auch verschiedene statistische Muster wie etwa Saisonalität oder den Einfluss des Wochentags. Die von Lokads Prognose-Engine erstellten Vorhersagen der Durchlaufzeit sind probabilistisch und stellen die Wahrscheinlichkeiten aller Dauern der Durchlaufzeit in Tagen dar. In diesem Abschnitt gehen wir auf die Syntax ein, die für die Berechnung der Prognosen der Durchlaufzeit durch Lokad verwendet wird.

Allgemeine Syntax

Der Prognose-Engine hat eine besondere Funktion, eine Aufruf-Funktion (call function), wie sie in Envisions Terminologie bekannt ist. Die Syntax lautet, wie folgt:

// "PO" steht für PurchaseOrders
Leadtime = forecast.leadtime(
  category: C1, C2, C3, C4
  hierarchy: H1, H2, H3, H4
  supplier: Supplier
  offset: 0
  present: (max(Orders.Date) by 1) + 1  
  leadtimeDate: PO.Date
  leadtimeValue: PO.ReceivedDate - PO.Date + 1
  leadtimeSupplier: PO.Supplier)

Im Gegensatz zu den gewöhnlichen Funktionen, haben Aufruf-Funktionen benannte Argumente statt Positionsargumente. Diese benannten Argumente eignen sich für komplexe Funktionen viel besser, da sie den Quellcode viel leserlicher gestalten, auf Kosten einer eingeschränkteren Ausführlichkeit. Diese Argumente verhalten sich wie gewöhnliche Funktionsargumente, daher sind sie für Envision-Ausdrücke zulässig.

Die Funktion gibt einen Vektor Leadtime zurück, der dem Typ Distribution entspricht (siehe auch Algebra der Verteilungen). Verteilungen sind ein erweiterter Datentyp, der Funktionen darstellt $p: \mathbb{Z} \to \mathbb{R}$. Genauer gesagt, gibt der Prognose-Engine Zufallsvariablen zurück, also Verteilungen, die positiv sind und eine Masse gleich 1 besitzen. In diesem Fall stellt $p(k)$ die Wahrscheinlichkeit der Durchlaufzeit, die $k$ Tagen zugeordnet ist, dar. Jedem Artikel, im Sinne von Envision, wird seine eigene Verteilung zugeordnet.

Die gesamte forecast.leadtime-Syntax enthält viele Argumente, doch nur zwei davon sind zwingend:

• present: ein skalarer Datumswert
• leadtimeDate: ein Datumsvektor mit einer Artikel-Affinität
  

Der present-Wert stellt das Datum dar, das als erstes prognostiziert werden soll, wenn man davon ausgeht, dass die Daten bis zum vorherigen Tag vollständig vorliegen. In der Praxis schließen manche Geschäfte beispielsweise sonntags. Sollte also das früheste Datum, das im Dataset vorliegt, der Samstag sein, wäre es nicht ganz eindeutig, ob die Vorhersage am Sonntag oder am Montag starten sollte. In der veranschaulichenden Syntax weiter oben, benutzen wir max(Orders.Date) + 1, da wir davon ausgehen, dass Beobachtungen zu jedem Tag vorliegen und dass die Eingabedaten frisch vom vorherigen Tag sind.

Es wird erwartet, dass leadtimeDate und leadtimeValue zur selben Tabelle, in der eine Artikelaffinität, also Id, * in der Terminologie Envisions, eingetragen ist, gehören. Die Daten stellen die Anfangstage (einschließlich) der Beobachtungen der Durchlaufzeiten dar. Es wird erwartet, dass die Werte in Tagen ausgedrückt werden. Teile von Tagen werden nicht unterstützt. Diese Tabelle enthält die eigentliche Historie der Durchlaufzeiten, der Vorhersage des Prognose-Engines.

Wenn leadtimeValue ausgelassen wird, werden die fortlaufenden Dauern zwischen den Daten der leadtimeDate stattdessen als Werte für die Durchlaufzeiten verwendet. Durch dieses Verhalten sollen die Bestelldurchlaufzeiten prognostiziert werden, die gewöhnlich separat von der Prognose von Lieferdurchlaufzeiten berechnet werden.

Idealerweise sollte die Historie so lang wie möglich sein. Doch in der Praxis sind die Vorteile von Daten über fünf Jahren eingeschränkt. Der Prognose-Engine kann sowohl mit kurzen als auch mit langen Historien zu den Durchlaufzeiten arbeiten. Bei längeren Historien werden ältere Daten einfach statistisch irrelevant.

Abgesehen von diesen Pflichtargumenten kann die Genauigkeit der Prognosen durch weitere Daten deutlich gesteigert werden. In den folgenden Abschnitten gehen wir näher darauf ein.

Kategorien und Hierarchie

Aus der Sicht des Prognose-Engines spielen Kategorien und Hierarchie eine ähnliche Rolle: sie helfen dem Prognose-Engine mit wenigen historischen Daten umzugehen.

Siehe auch Prognosen mit Attributen.

Lieferanten

Die Wahl des Lieferanten spielt oft eine wichtige Rolle bei der Schätzung der Durchlaufzeit. Die Daten der Lieferanten können dem Prognose-Engine auf zwei Arten mitgeteilt werden, die sich gegenseitig ergänzen.

Zuerst kann die Historie der Beobachtungen der Durchlaufzeiten nach Lieferanten kategorisiert werden. Dafür ist das leadtimeSupplier-Argument gedacht. Wenn dieses Argument vorhanden ist, nutzt der Prognose-Engine diese Information, um zu überprüfen, ob einem bestimmten Lieferanten Durchlaufzeiten zugeordnet sind oder nicht. Daten über die Lieferanten bieten eine Granularität der Information, die durch einfach Artikelhierarchie oder -Kategorien nicht erlangt werden kann, da im Laufe der Zeit Artikel von verschiedenen Lieferanten bezogen werden können.

Als zweites kann man den Prognose-Engine darüber informieren, welche Lieferanten für die nächste Lieferung berücksichtigt werden sollen. Dafür ist das supplier-Argument gedacht. Wenn dieses Argument vorhanden ist, kann der Prognose-Engine im Vorfeld berücksichtigen, dass sich die Durchlaufzeiten bei einem bestimmten Artikel ändern können, da der Lieferant gewechselt wurde. Natürlich kann der Prognose-Engine diese Information nur nutzen, wenn die Historie der Durchlaufzeiten selbst ordentlich, wie oben beschrieben, nach Lieferanten kategorisiert ist.

Durchlaufzeit Offsets

Standardmäßig beginnt die Vorhersage beim Tag present. Doch unter manchen Umständen kann es sinnvoll sein, eine Vorhersage, die einen Tag später beginnt, zu berechnen. Beispielsweise kann das Anfangsdatum bei saisonalität Durchlaufzeiten einen wichtigen Einfluss auf die Verteilung des Wertes haben. Solche Fälle kann man mit den offset-Eigenschaften lösen. Diese optionale Eigenschaft erwartet einen Vektor aus Zahlen der items-Tabelle. Der Wert dieses Vektors stellt die Offsets oder Verschiebung in Tagen ausgedrückt dar, der für die Prognose der Durchlaufzeit berücksichtigt wird. Wenn beispielsweise ein Offset-Wert von 10 gewählt wird, ist der erste Tag der Prognose der Durchlaufzeit present + 10. Wenn offset ausgelassen wird, wird er als Null betrachtet.