Demand Forecasting in Python leicht gemacht mit futureEXPERT
08.01.2025
Du hast jede Menge Daten, die darauf warten, in die Zukunft zu blicken? Dann ist futureEXPERT genau dein Tool! Starte einfach deine Python-Umgebung und schon kann es losgehen. Lass uns gemeinsam in die Welt des Forecastings eintauchen.
Was erwartet dich?
In diesem Blogbeitrag zeigen wir dir einen Anwendungsfall aus der Praxis, wie er uns schon häufig begegnet ist: Demand Forecasting als Schlüssel für eine effiziente, datenbasierte Planung. Unser Ziel ist es, Vorhersagen auf Monatsbasis zu erstellen, wie sie oft für die Produktionsplanung benötigt werden – und das mit einem ausreichend langen Horizont von mindestens einem Jahr. Dabei legen wir den Fokus auf die mittelfristige Planung.
Die Ausgangsdaten stammen häufig aus ERP-Systemen und liegen in Form einzelner Aufträge oder auf Tagesbasis vor. Daher beginnen wir mit der Aggregation zu Monatszeitreihen. Besonderheiten wie z.B. nicht-negative, ganzzahlige Werte und mögliche Packungsgrößen müssen wir auch berücksichtigen. Eine ganze Menge Anforderungen… – Ob futureEXPERT diese alle erfüllen kann?
Wir zeigen dir nun, wie du mit der Python-Bibliothek futureEXPERT Daten einliest, ein passendes Modell konfigurierst und aussagekräftige Visualisierungen erstellst. Klingt interessant? Dann lass uns loslegen!
Inhalt:
- CHECK-IN: Von Rohdaten zu Zeitreihen, die Ausgangsbasis für datenbasierte Forecasts
- FORECAST: Von der Datenhistorie zu Demand Forecasts für die Zukunft
- Demand Forecasts unter der Lupe: Was steckt in den Ergebnissen?
- Fazit: Demand Forecasting mit Python ist wirklich ein Kinderspiel mit der richtigen Toolbox
CHECK-IN: Von Rohdaten zu Zeitreihen, die Ausgangsbasis für datenbasierte Vorhersagen
Der bequemste Weg, um Daten über den CHECK-IN aufzubereiten, geht über das Frontend:
Abbildung 1: Upload des ERP-Datenabzugs im Frontend futureNOW.
Die grafische Oberfläche hilft uns bei der Definition des korrekten Datenformats. Probleme, die üblicherweise beim Einlesen neuer Daten entstehen, können wir so von Anfang an aus dem Weg räumen. Wir haben es schließlich alle schon erlebt, dass wir erst nach einer langen Berechnungszeit darauf aufmerksam gemacht werden, dass Datumsformat oder Dezimaltrennzeichen nicht stimmen und der ganze Prozess wiederholt werden muss. Die Plausibilitätsprüfungen werfen bei inkonsistenter Datendefinition bereits in diesem ersten Schritt Fehlermeldungen und beheben das Problem damit frühzeitig.
Abbildung 2: Datenspalten definieren
Nachdem wir unsere Datei ausgewählt haben, definieren wir, welche Art von Information in welcher Spalte enthalten ist. Jeder der Spalten weisen wir eine der drei Kategorien zu: Datum, Wert oder Gruppierung. Wir brauchen eine Datumsspalte, um die Bedarfe zeitlich zuzuordnen. In unserem Fall haben wir nur die Wertespalte “DEMAND”. Optionale Gruppierungsvariablen ermöglichen die Berücksichtigung von hierarchischen Strukturen. Für unseren Demand-Forecasting-Fall ist die Spalte mit den Materialnummern besonders relevant, da wir den Bedarf auf Artikelebene vorhersagen möchten.
Abbildung 3: Rohdaten-Vorbereitung überprüfen
Bevor wir zum letzten Schritt kommen, können wir anhand einer Übersicht noch überprüfen, ob die Daten unseren Erwartungen entsprechen. Wir sehen so zum Beispiel die Anzahl der Einträge pro Datum oder ob alle Materialien korrekt übernommen wurden. In unserer Datei finden wir historische Demand-Daten von 17 Materialien, von denen eines ausgeschlossen werden soll. Dazu kommen wir nachher. Die Plausibilitätsüberprüfung erlaubt uns, Vorgehensweisen für die eventuell gefundenen Fälle zu treffen. Wenn wir beispielsweise Werte mit falschem Format vorfinden oder solche, die eine vorher definierte untere oder obere Schranken unter- bzw. überschreiten, können wir entscheiden, wie wir damit umgehen möchten. Da wir in unserem Fall keine negativen Bedarfe auf Monatsbasis haben, in den Rohdaten allerdings einzelne negative Werte aufgrund von Stornierungen vorkommen können, stellen wir hier bewusst keine Schranken ein, sondern behandeln dies in einem späteren Schritt.
Abbildung 4: Zeitreihen-Datensatz vorbereiten
Bei unseren Daten handelt es sich um einen Datenabzug eines ERP-Systems, welches die Bedarfe einzelner Kunden und Regionen auf Tagesbasis bereitstellt. Wir möchten den monatlichen Demand auf Materialebene vorhersagen. Daher müssen wir diese Einstellungen für die zeitliche Granularität und die Datenebene vornehmen. Außerdem wollen wir für das Material C011414576 keine Vorhersagen erstellen, da es ein ausgelaufenes Material ist, das in der Planung keine Rolle mehr spielt. Als Variable für die vorherzusagenden Werte wählen wir “Demand” und treffen die Entscheidung, wie die einzelnen Beobachtungen pro Datum und Material aggregiert werden: Durch Summe als Aggregationsfunktion erhalten wir bei der Zeitreihen-Aufbereitung die Summe der Bedarfe pro Monat und Material – genau das, was uns im Demand Planning interessiert. Für die Fälle, in denen es in einem Monat für ein Material überhaupt keinen Demand gegeben hat, legen wir außerdem fest, dass diese mit 0 aufgefüllt werden sollen. Nun können wir die Berechnung der Zeitreihen starten. Weil wir letztendlich mit Python-Code in einem Jupyter-Notebook arbeiten wollen, nutzen wir die Möglichkeit, die aufbereiteten Daten ganz einfach in unseren Python-Code zu übertragen. Hierfür kopieren wir die “Version ID” – eine eindeutige und genau zu unseren aufbereiteten Daten gehörige ID – mit der wir dann im futureEXPERT weiterarbeiten können, um Demand Forecasts zu erzeugen.
from futureexpert import *
client = ExpertClient(user='my_username', password='my_password')
ts_check_in_results = client.check_in_time_series(
raw_data_source='../example-data/demand_planning_data.csv',
file_specification=FileSpecification(delimiter=';', decimal='.'),
data_definition=DataDefinition(
date_columns=checkin.DateColumn(name='DATE', format='%d.%m.%Y', name_new = 'Date'),
value_columns=[checkin.ValueColumn(name='DEMAND', name_new='Demand')],
group_columns=[checkin.GroupColumn(name="CUSTOMER", name_new='Customer'),
checkin.GroupColumn(name="MATERIAL", name_new="Material"),
checkin.GroupColumn(name="REGION", name_new="Region")]),
config_ts_creation=TsCreationConfig(
time_granularity='monthly',
start_date="2007-10-01",
end_date="2024-06-01",
value_columns_to_save=['Demand'],
grouping_level=["Material"],
missing_value_handler="setToZero",
filter=[checkin.FilterSettings(type='exclusion', variable='Material', items=['C011414576'])]))
Alternativ könnten wir den CHECK-IN auch direkt im Python-Client aufrufen. Die Konfiguration stellen wir entweder direkt im Code ein oder verwenden die fertig vorbereitete Config-Datei, die wir aus dem Frontend heruntergeladen haben.
FORECAST: Von der Datenhistorie zu Demand Forecasts für die Zukunft
Weiter geht’s nun mit der Forecast-Berechnung. Vor dem Start des FORECASTs nehmen wir noch spezifische Einstellungen vor. Die einzelnen Config-Klassen helfen uns dabei, sinnvolle Einstellungen für das Preprocessing, das Forecasting selbst und die Methodenselektion zu treffen. Wir könnten uns zwar auf die Voreinstellungen verlassen, möchten hier aber insbesondere ein paar fürs Demand Forecasting besonders hilfreiche Settings nutzen.
fc_report_config = ReportConfig(
title='Monthly Demand Forecast on Material Level',
preprocessing=PreprocessingConfig(remove_leading_zeros=True,
detect_outliers=True,
replace_outliers=True,
detect_changepoints=True,
detect_quantization=True),
forecasting=ForecastingConfig(fc_horizon=18,
lower_bound=0,
use_ensemble=True,
confidence_level=0.75,
round_forecast_to_integer=True),
method_selection=MethodSelectionConfig(number_iterations=18,
refit=True,
step_weights={3:1, 4:1, 5:0.5, 6:0.5},
additional_accuracy_measures=['me', 'mae']))
forecast_identifier = client.start_forecast(version=ts_check_in_results.version_id, config=fc_report_config)
Preprocessing
Beim Preprocessing legen wir fest, dass führende Nullen entfernt werden sollen. In unserem Fall entsprechen diese Nullen fehlenden Werten, die die Ergebnisse vom FORECAST verzerren könnten. Solche Effekte treten im Demand Forecasting häufig auf, beispielsweise wenn ein Produkt kurz vor der Markteinführung steht, aber bereits im ERP-System erfasst ist.
Wir stellen sicher, dass Ausreißer in den Daten erkannt und vor dem Modelltraining durch geeignete Werte ersetzt werden. Zusätzlich läuft die Detektion von Strukturänderungen, wie beispielsweise Levelshifts, mit.
Die Erkennung von quantisierten Werten zeigt, ob die Bedarfswerte in der Historie bestimmten Mustern folgen, also fast ausschließlich als Vielfache eines gewissen Werts auftreten. Dies kann auf spezielle Logistikanforderungen hinweisen, wie etwa Packungsgrößen, in denen das Produkt erhältlich ist, oder auf ein charakteristisches Bestellverhalten einzelner Kunden. Solche Erkenntnisse fließen direkt in die Forecast-Erstellung ein und liefern eine optimale Basis für realistische und praktikable Planungen.
Forecasting
Wir möchten die Nachfrage für die nächsten 18 Monate prognostizieren. Wir wissen, dass unsere Werte nie kleiner als 0 sein können und ganzzahlig sein müssen, da die Materialien in ganzen Stückzahlen bestellt werden. Deswegen wählen wir 0 als untere Grenze für die Forecasts und lassen die Forecasts auf ganze Zahlen runden. Zusätzlich setzen wir das Konfidenzniveau für die Prognoseintervalle auf 75 %.
Method Selection
Auch für die Methodenselektion stehen diverse Einstellungsmöglichkeiten zur Verfügung. Das Modul FORECAST sucht aus einer Vielzahl möglicher Methoden – von klassischen statistischen Verfahren bis zu modernen Machine-Learning-Algorithmen – jeweils die Methode aus, welche die besten Ergebnisse für die vorliegende Zeitreihe erzielt. Nicht alle Vorhersageschritte möchten wir dabei gleichwertig in die Bewertung der einzelnen Modelle einbeziehen:
An der Planung der kommenden zwei Monate können wir nichts mehr ändern, da die Produktion einen entsprechenden Vorlauf benötigt. Somit ist die Prognosegüte der Demand Forecasts für diese Monate für uns hier irrelevant. Besonders wichtig allerdings sind die Prognosen für den dritten und vierten Monat, wohingegen die Schritte fünf und sechs weniger stark einfließen sollen. Alle anderen Monate wollen wir bei der Methodenauswahl nicht berücksichtigen, auch wenn wir für diese Monate natürlich trotzdem Vorhersagen erzeugen wollen.
Damit das Ranking der Methoden diese besondere Gewichtung bestimmter Vorhersageschritte berücksichtigt, definieren wir den Parameter step_weights entsprechend. Jeder relevante Schritt erhält das Gewicht, mit dem er in die Berechnung des Rankings eingehen soll. Jeder nicht aufgeführte Schritt erhält das Gewicht 0 und wird somit bei der Selektion ignoriert. In den Standardeinstellungen würden übrigens alle Vorhersageschritte gleich gewichtet in die Modellselektion einfließen.
Bei den Gütemaßen, welche zur Modellselektion verwendet werden sollen, verlassen wir uns auf die Voreinstellung, welche für unterschiedliche Zeitreihentypen jeweils ein geeignetes Maß heranzieht (MSE und PIS). Da uns darüber hinaus noch weitere Gütemaße interessieren, lassen wir zusätzlich ME und MAE durch den Parameter additional_accuracy_measures berechnen.
Demand Forecasts unter der Lupe: Was steckt in den Ergebnissen?
Die Ergebnisse sind alle nach wenigen Minuten abrufbar und der FORECAST läuft bis dahin im Hintergrund. In dieser Zeit findet zunächst ein ausführliches Preprocessing der Zeitreihen statt, wobei u.a. Saison, Trend, fehlende Werte und Ausreißer erkannt sowie datenbasiert geeignete Ersatzwerte bestimmt werden. Basierend auf den Merkmalen der Zeitreihen erfolgt eine Vorauswahl geeigneter Methoden, von denen bis zu ca. 30 Methoden trainiert, optimiert und gegeneinander getestet werden. In unserem Fall werden, zusätzlich zum Forecast für die Zukunft, im Backtesting 18 historische Forecasts erzeugt. Eine umfassende Plausibilitätsprüfung mit etwa zehn Checks sortiert ungeeignete Verfahren aus. Schließlich erfolgt ein Ranking der Methoden basierend auf Gütemaßen, wobei Fallback-Methoden für Sonderfälle sicherstellen, dass wir auch bei ungünstigen Bedingungen verlässliche Ergebnisse erhalten.
Von den Ergebnissen interessieren uns nun die drei besten Modelle pro Zeitreihe und die Backtesting-Ergebnisse.
results = client.get_fc_results(
id=forecast_identifier, include_backtesting=True, include_k_best_models=3)
Wir erhalten eine Liste von ForecastResult-Objekten. Jedes Element der Liste beinhaltet eine Vielzahl von Ergebnissen für jede unserer 16 Zeitreihen: Neben den Forecasts selbst finden wir darin andere wertvolle Ergebnisse wie die historischen Forecasts für das Backtesting, eine Übersicht zu den im Preprocessing veränderten Werten in den Zeitreihen (z. B. Ausreißer) und vieles mehr.
Überblick über Zeitreihen-Charakteristika und Modell-Ergebnisse
Einen ersten Überblick über die Ergebnisse verschaffen wir uns, indem wir die Python-Funktion export_result_overview_to_pandas aufrufen: Wir erhalten eine übersichtliche Zusammenfassung von wichtigen Zeitreihen-Charakteristika sowie Modell-Ergebnissen in Tabellenform:
from futureexpert.forecast import export_result_overview_to_pandas
export_result_overview_to_pandas(results)
Abbildung 5: Modell-Ergebnisse und Zeitreihen-Charakteristika
Hierin erkennen wir mit einem Blick viele wichtige Informationen zu unseren Materialien und dabei vor allem eins: Es handelt sich um ein sehr diverses Set: sporadische, geklumpte und glatte Zeitreihentypen, einige mit saisonalen Mustern, mit und ohne Trend, … Eine Zeitreihe weist einen Ausreißer auf und bei einigen konnten aus der Historie quantisierte Werte herausgelesen werden: Mit einem kurzen Blick können wir bestätigen, dass dies in unserem Fall plausibel ist, da die entsprechenden Materialien nur jeweils in bestimmten Packungsgrößen bestellbar sind. Genauso unterschiedlich wie die Zeitreihen sind die Vorhersagemethoden, die jeweils als am besten identifiziert wurden: Dreimal hat es ein Machine-Learning-Verfahren (SVM, Glmnet) auf den ersten Platz geschafft, fünfmal eine klassische statistische Prognosemethode (TBATS, Exponentielle Glättung), sechsmal ein besonders für sporadische Zeitreihen entwickelter/geeigneter Ansatz (Croston, InterpolID, MedianPattern) und einmal liefert sogar ein Ensemble den final besten Forecast.
Viele unserer Zeitreihen weisen eine Saison auf, meist handelt es sich dabei um eine Jahressaison, d.h. sie hat die Länge 12. Lediglich bei drei Zeitreihen konnte unser FORECAST keine saisonalen Muster erkennen. Während bei den wenigsten Zeitreihen ein globaler Trend zu erkennen ist, also ein Trend über die gesamte betrachtete Historie hinweg, finden wir oftmals einen “recent Trend”, also einen Trend in der jüngeren Vergangenheit.
Bedarfsprognosen mit glattem Bedarfsmuster in der Historie
Jetzt aber zum wirklich spannenden Teil: Wie wird denn der Demand in der Zukunft aussehen?
Einen guten Eindruck der Forecasts selbst erhalten wir, indem wir diese plotten lassen. Dabei beschränken wir uns auf die Daten der letzten acht Jahre (96 Datenpunkte) und wollen jeweils das beste Modell betrachten.
from futureexpert import plot
for ts in results:
plot.plot_forecast(ts,
plot_last_x_data_points_only=96,
ranks=[1],
plot_prediction_intervals=False,
plot_outliers=True,
plot_change_points=True)
Wir werfen nun einen Blick auf die Demand Forecasts ausgewählter Materialien und schauen, inwiefern sich die oben getroffenen Einstellungen auswirken.
Beispiel 1: Zeitreihen mit jährlicher Saisonalität und globalem Trend
Abbildung 6: Forecast mit TBATS und globalem Trend
futureEXPERT erkennt, ob in den Daten ein globaler Trend vorliegt – wie in diesem Beispiel ein Anstieg. Wir haben es hier mit einer glatten Zeitreihe mit saisonalem Nachfragemuster zu tun, welches sich auch im Demand Forecast widerspiegelt.
Beispiel 2: Kürzliche Trends erkennen
Abbildung 7: Recent Trend
Wir spüren nicht nur globale Trends auf: Bei diesem Material hat unser FORECAST-Modul im Preprocessing erkannt, dass nach einem kleinen Niveauanstieg in 2022 ein Abwärtstrend vorliegt, obwohl über den gesamten Zeitraum global betrachtet kein Trend zu erkennen ist. Dieser Abwärtstrend wird in den Forecasts konsequent weitergeführt.
Beispiel 3: Levelshifts identifizieren
Abbildung 8: Levelshift
Bei diesem Material hat die Changepoint Detection einen Levelshift im Januar 2022 identifiziert. FORECAST berücksichtigt diesen Anstieg und erzeugt Forecast entsprechend auf diesem Niveau.
Beispiel 4: Ensemble Forecast
Abbildung 9: Ensemble Forecast
Der finale Demand Forecast dieses Materials setzt sich zusammen aus mehreren Prognosemodellen, einem sogenannten Ensemble. In diesem Fall handelt es sich um die Ergebnisse 17 verschiedener Verfahren und somit eine Mischung aus statistischen Prognosemethoden wie ARIMA oder Machine-Learning-Algorithmen wie SVM und Random Forecast. Die Prognosen der 17 Methoden fließen dabei mit gleicher Gewichtung ein, da dies i.d.R. zu den stabilsten Ergebnissen führt. Damit schlechte oder unplausible Ergebnisse das Ensemble nicht negativ beeinflussen, werden diese automatisch aussortiert. Die genaue Auflistung der inkludierten Modelle finden wir in dem Feld method_specific_details des Models.
Hier gibt es noch eine weitere Besonderheit, denn in der Historie hat die Quantization Detection eine Packungsgröße von 78 erkannt. Dieses Wissen wird auch in den Forecasts angewandt: Die Vorhersagewerte sind alle Vielfache von 78.
Bedarfsprognosen mit sporadischem Bedarfsmuster in der Historie
Beispiel 5: Croston-Vorhersage berücksichtigt erkannte Paketgrößen
Abbildung 10: Croston Forecast
Beispiel 6: Kurze Zeitreihen
Bei dieser sporadischen Demand-Historie haben wir ebenfalls eine – dieses Mal deutlich kleinere – Packungsgröße festgestellt, nämlich 6. Wir können das mit bloßem Auge recht gut erkennen: Anfang 2025 sagen wir einen etwas höheren Demand vorher als in den anderen Fällen. Hierbei ziehen wir unser Wissen über die Prognosemethode Croston heran: Entweder erzeugt Croston einen konstanten Forecast oder ein sporadisches Nachfragemuster mit identischer Demand-Höhe. Wenn das wie hier nicht der Fall ist, muss vor der Rückgabe der Forecasts eine Anpassung im Sinne der Quantisierung stattgefunden haben.
Abbildung 11: Forecast einer kurzen Bedarfs-Zeitreihe
Wie wir es eingestellt haben, hat der FORECAST außerdem die führenden Nuller bei diesem neu eingeführten Material vor dem Modelltraining entfernt. Damit können wir sicherstellen, dass das Training nicht verfälscht wird: Es könnte sonst z. B. ein vermeintlicher Aufwärtstrend in den Forecasts des Demands fortgeschrieben werden. Das führt aber natürlich insgesamt dazu, dass die Zeitreihen-Historie (korrekterweise) nur sehr kurz ist.
Dadurch ergibt sich eine andere Herausforderung: Ein Backtesting ist notwendig, um die Genauigkeit einer Prognose einschätzen zu können. Diese Zeitreihe ist allerdings zu kurz, um solche Berechnungen zu erlauben. Zum Glück ist futureEXPERT auch in der Lage, mit sehr kurzen Zeitreihen umzugehen. Es werden vom FORECAST automatisch passende Forecasting-Methoden als Fallback verwendet, denen wir auch ohne Backtesting vertrauen können.
Beispiel 7: Bedarfsschwankungen und Phasen niedrigen Bedarfs
Abbildung 12: InterpolID Forecast
Neben solchen strukturellen Veränderungen bezüglich einer plötzlichen Veränderung des Niveaus (Levelshifts) wie im zweiten Beispiel können wir auch unterschiedliche Verteilungen hinsichtlich der Nachfrage und auffällige Phasen ungewöhnlich geringer Bedarfe ermitteln. Für diese Zeitreihe wird zwischen Oktober 2020 und April 2022 eine im Vergleich zur restlichen Historie stark reduzierte Anzahl von Nachfrage-Beobachtungen detektiert. Nutzen können wir diese Erkenntnis für die Erzeugung der Forecasts jedoch nicht, wenn wie hier der Zeitraum mitten in der Datenhistorie liegt. Anders sieht es aus, wenn ein solcher auffälliger Zeitraum erst kurz zurückliegt:
Beispiel 8: Ausreißer und auslaufende Produkte
Abbildung 13: Forecast mit einem Ausreißer in der Zeitreihe
Nach einer etwa einjährigen Phase erhöhter Bedarfe ab Mitte 2021 scheint es sich bei diesem Material um einen sogenannten “Phase-out-Artikel” zu handeln. Die Change Point Detection hat hier ab Ende 2023 einen Strukturbruch des Typs “few observations” erkannt: Dieses Material wird seitdem nur noch wenig nachgefragt und der Bedarf ist auf nahe Null zurückgegangen. Die als am besten identifizierte Prognosemethode InterpolID spiegelt das Auslaufen des Artikels auch wider, indem nur sehr kleine Bedarfswerte für die nächsten Monate vorhergesagt werden.
Zusätzlich erkennen wir hier im Plot, dass in der Datenhistorie im Januar 2020 ein Ausreißer vorlag - ein guter Gegencheck, dass die automatisierte Erkennungslogik hier funktioniert hat. Diesen Ausreißer haben wir datenbasiert ersetzt: Der grüne Punkt zeigt den Ersatzwert an - sieht sehr sinnvoll aus. Somit ist der Ausreißer beim Training der Modelle nicht berücksichtigt und konnte das Ergebnis nicht verzerren.
Beispiel 9: Berücksichtigung des Trends im Bedarf bei InterpolID-Vorhersage
Abbildung 14: InterpolID Forecast mit Trend
Die von prognostica selbst entwickelte Methode InterpolID beruht auf den gleichen Prinzipien wie Croston, kann aber zusätzlich Saisonalitäten und Trends erkennen und berücksichtigen. Wir sehen in diesem Beispiel, dass der Trend, der ca. 2021 startet, in den Demand Forecasts fortgesetzt wird.
Fazit: Demand Forecasting mit Python ist wirklich ein Kinderspiel mit der richtigen Toolbox
In diesem Blogbeitrag haben wir gesehen, wie leicht es ist, Demand Forecasts mit Python dank futureEXPERT zu erstellen. Durch automatisierte Trenderkennung, Analyse saisonaler Muster und robuste Plausibilitätprüfung können wir schnell und genau den Bedarf für unsere Materialien vorhersagen - und das mit minimalem Aufwand: Einfach die Daten definieren und den Vorhersagehorizont festlegen und schon kann der FORECAST die Ergebnisse berechnen. Wenn wir aber wollen, können wir Vieles auch individuell konfigurieren, beispielsweise Details zur Methodenauswahl. Die Ergebnisse sprechen für sich: Sei es die Erkennung von Strukturbrüchen, die Berücksichtigung von Packungsgrößen oder die Identifizierung von auslaufenden Produkten – futureEXPERT liefert uns die entscheidenden Informationen, um unser Demand Planning zu optimieren.
Haben wir dein Interesse geweckt? Dann registriere dich HIER, um deinen Zugang zu future zu erhalten.