Tägliche, wöchentliche oder monatliche Datenaggregationen - Software zur Bestandsoptimierung

Tägliche, wöchentliche oder monatliche Datenaggregationen


Startseite » Ressourcen » Hier

Die Vorstellung einer täglichen, wöchentlichen oder monatlichen Datenaggregation bereitet mehrere subtile Probleme. Dies fängt bereits mit den entsprechenden Definitionen von Tag, Woche oder Monat an. Dieser Artikel beschäftigt sich mit dem vom Lokad übernommenen Ansatz zur Handhabung dieser Aggregationen, vom Dateneingang (historische Daten) bis hin zur Datenausgabe (Prognosen). Zudem vermitteln wir praxisnahe Leitlinien zum Umgang mit verschiedenen Datenaggregationen.


Terminologie: Posten und Bestellung

Die Begriffe Posten und Bestellung beziehen sich auf das Eingangsdatenformat von Lokad. In diesem Beitrag sollten diese Begriffe gemäß der Definition von Lokad verstanden werden. Ein Posten repräsentiert ein zu prognostizierendes Ziel. Ein Posten kann ja nach Kontext ein Artikel, ein Produkt, eine SKU oder ein Barcode sein. Eine Bestellung repräsentiert die Menge eines Postens zu einem bestimmten Zeitpunkt in der Vergangenheit. Eine Bestellung kann je nach Kontext ein Verkauf, eine Lieferung, ein Verbrauch sein.

Aggregationen gemäß der Definition von Lokad

Lokad stützt sich auf folgende Vorgaben:

  • Die Tage beginnen um 00h00 Morgens; somit deckt jeder tägliche Prognosewert einen Zeitraum ab, der um 00h00 beginnt und um 23h59:59 endet.
  • Die Wochen beginnen Montags; somit deckt jeder wöchentliche Prognosewert einen Zeitraum ab, der mit einem Montag (einschließlich) beginnt und mit einem Sonntag (einschließlich) endet.
  • Monate beginnen am 1. eines jeden Monats; somit deckt jeder monatliche Prognosewert einen Zeitraum ab, der am ersten Tag des Monats beginnt und am letzten Tag des Monats endet.

Diese Vorgaben können nicht in Lokad geändert werden. Wir befassen uns jedoch im folgenden mit anderen Vorgaben, die in bestimmten Unternehmen erforderlich sind.

Toleranz gegenüber Datenmustern bei der Aggregation von Eingangsdaten

Lokad versucht bei der Verarbeitung historischer Daten tolerant zu sein. Obwohl wir die Anwendung einer täglichen Aggregation empfehlen, d. h. die Zusammenfassung aller Bestellungen für einen bestimmten Posten oder einen bestimmten Tag zu einem einzelnen Tageswert, akzeptiert Salecast andere Szenarien.

Aufgeschlüsselte, historische Rohdaten

Die tägliche Aggregation reduziert den Umfang der in Lokad hochzuladenden Datenmenge. Diese Reduzierung bringt keinerlei Nachteile, was die Prognosegenauigkeit betrifft, mit sich. Ist jedoch das Datenvolumen von Anfang an relativ klein, ist der erreichbare Vorteil eher irrelevant. Somit kann Lokad auch eine vollständig aufgeschlüsselte Datenhistorie mit einer Zeile pro Geschäftsgang verarbeiten. In diesem Fall werden tägliche Mengen als die Summe der Bestellwerte für einen bestimmten Posten oder Tag berechnet.

Wöchentliche oder monatliche voraggregierte Datenhistorie

Manchmal werden die täglich aggregierten historischen Daten nicht dort im Unternehmenssystem archiviert, wo die Eingangsdaten herstammen: Nur die wöchentlich oder monatlich angesammelten Daten bleiben erhalten. Lokad kann wöchentliche oder monatliche voraggregierte Bestellungen verarbeiten.

Werden die Daten wöchentlich gesammelt, sollte Lokad auf klassische wöchentliche Prognosen beschränkt werden. Tägliche, monatliche oder Quantil-Prognosen sollten nicht angewandt werden, da die statistischen Ergebnisse nichts sagend währen. Ähnlich verhält es sich bei der monatlichen Datenaggregation. Lokad sollte hier auf klassische monatliche Prognosen beschränkt werden.

Der Hauptnachteil von voraggregierten Daten sind die dadurch entstehenden Einschränkungen hinsichtlich der Natur der Prognosen, die erstellt werden können. Ein weiterer Nachteil ist ein geringer Genauigkeitsverlust. Lokad kann tägliche Muster nutzen, um sogar wöchentlich oder monatliche Prognosen zu verfeinern.

Wann beginnen Prognosen?

Um eine Prognose zu erstellen, definiert Lokad einen Grenzwert, der die Gegenwart darstellt, d. h. den Starttermin der Prognosen. Um diesen Grenzwert zu berechnen, muss Lokad einen datenorientierten Standpunkt annehmen: die Prognosen beginnen da, wo die historischen Daten enden. Enden die historischen Daten beispielsweise am 15. Mai (einschließlich), beginnen die täglichen Prognosen am nachfolgenden Tag, dem 16. Mai.

Der datenorientierte Standpunkt ist praktisch, insbesondere für Benchmarks. Die Daten können an einem beliebigen Zeitpunkt in der Vergangenheit trunkiert werden und Lokad erstellt Prognosen, die bereits mit den (nicht trunkierten) historischen Daten verglichen werden können, da die Prognosen selbst Teil der Vergangenheit sind.

Insbesondere die klassischen täglichen Prognosen und Quantil-Prognosen verhalten sich ähnlich: die Prognose beginnt immer am Tag nach der jüngsten Bestellung aus dem Eingabedatensatz.

Im Fall von klassischen wöchentlichen oder monatlichen Prognosen ist die Situation etwas schwieriger. Angenommen die historischen Daten (sprich die Bestellungen laut Lokad Terminologie) enden am 15. Mai: Sollten die Prognosen am 1. Mai oder am 1. Juni beginnen? Für Lokad beginnen die Prognosen am 1. Mai. Da die Daten für den Monat Mai jedoch erst teilweise vorhanden sind, trunkiert Lokad die Daten zum letzen Tag im April, so dass eine reguläre (*) klassische monatliche Prognose für Mai erstellt werden kann.

(*) Rein theoretische wäre es möglich ein Prognosemodell zu erstellen, das in der Lage ist die für diesen Teilzeitraum vorhandenen Daten zu nutzen. Dies erfordert jedoch eine komplexe Prognosefunktion, die derzeit noch nicht von Lokad unterstützt wird.

Wöchentliche oder monatliche Datenaggregation

Im Fall von monatlichen (oder wöchentlichen) Datenaggregationen, kann das von Lokad durchgeführte trunkieren der Daten zu unbeabsichtigten Ergebnissen führen. Angenommen uns liegt eine monatlich aggregierte Bestellhistorie for, mit einer einzigen Bestellung an jedem Monatsersten. Der 1. Mai 2013 steht z. B. in diesem Fall für das letzte Datum der historischen Daten. Somit interpretiert Lokad den Monat Mai als nur teilweise beobachtet und der Monat Mai wird trunkiert. Folglich beginnen die Prognosen am 1. Mai. Da der Datenpunkt für den 1. Mai den ganzen Monat Mai repräsentiert, erhalten wir nicht das gewünschte Ergebnis.

Um das Trunkieren von Daten zu vermeiden, wird empfohlen, eine einzelne Bestellzeile mit der Bestellmenge Null für das Datum einzugeben, das den letzten Tag des aktuellen Monats repräsentiert. In diesem Fall erkennt Lokad durch die Einfügen einer Bestellzeile vom 31. Mai den Abschluss des Monats Mai und den 1. Juni als Prognosestart. Ähnlich kann durch Einfügen einer Bestellzeile mit einer Bestellmenge von Null das gleiche Problem bei wöchentlichen Prognosen gelöst werden.

Das Hinzufügen einer derartigen “Schein-”Bestellzeile hätte negative Auswirkungen auf Quantil-Prognosen, die gleichzeitig mit klassischen Prognosen in Lokad erstellt werden. Für die Praxisanwendung gilt deshalb: Werden Daten monatlich aggregiert, sollten keine Quantil-Prognosen für den Datensatz erstellt werden.

Bereinigung zukunftsbezogener Daten, eine Ausnahme vom datenorientierten Ansatz

Es gibt eine Ausnahme des datenorientierten Ansatzes: Im Rahmen eines Gesundheitschecks filtert Lokad Bestellungen heraus, die weiter als 1 Woche in die Zukunft reichen (die Zukunft wird anhand der Serverzeit des Lokad betreibenden Rechners definiert).

Tatsächlich können wir regelmäßig beobachten, dass einige unserer Kunden Artefakte aus Ihren Systemen extrahieren, die in ferner Zukunft liegen. Diese Zeilen sind üblicherweise keine tatsächlichen Umsätze oder Sendungen, sondern die Ergebnisse aus Tests, die irgendwann vom System des Unternehmens durchgeführt wurden.

Aus betriebswirtschaftlicher Sicht macht es offensichtlich wenig Sinn sich auf historische Daten zu verlassen, die eigentlich gar noch nicht existieren. Somit trunkiert Lokad diese Daten im Rahmen einer Datenbereinigung und setzt die Prognoseerstellung anschließend fort.

Alternative monatliche oder wöchentliche Aggregation

Für Lokad beginnt der monatliche Zeitraum immer am ersten Tag des Monats. Einige Unternehmen benötigen jedoch einen anderen Ansatz, z. B. den Beginn des Zeitraums zum 25. des Monats. In solchen Fällen empfehlen wir ein Voraggregieren der Bestellhistorie hin zum Zielzeitraum. Im vorherigen Beispiel würde der Zeitraum vom 25. Mai bis zum 24. Juni in einer einzelnen Bestellzeile aggregiert werden. Diese Zeile repräsentiert den individuellen monatlichen Wert für den Artikel und sollte als 1. Tag des Monats vor dem ursprünglichen Zeitraum (hier: 1. Mai) angeordnet werden. Somit erstellt Lokad Prognosen ab dem 1. Tag des Monats, die in den ursprünglichen Ansatz (z. B. den 25. des Monats) zurückübersetzt werden können.

Es ist wichtig ein Datum zu verwenden, das dem Zeitraum voransteht, da ansonsten Teil der resultierenden Daten der Zukunft zugeordnet werden können und basierend auf dem Ansatz, dass zukünftige Daten trunkiert werden sollten (siehe Datenbereinigung), von Lokad trunkiert werden.