Katalog / Prognose- und Vorhersage-Anwendungsfälle / PRED-001

Bedarfsprognose (Handel, Fertigung, Großhandel)

Prognostizieren Sie den künftigen Absatzbedarf je Produkt, Standort und Periode (mit Unsicherheitsbereichen) aus Absatzhistorie, Preisen, Aktionen, Kalender und externen Signalen, als Grundlage für Nachschub-, Produktions- und S&OP-Planung.

Jede Nachschubbestellung, jeder Produktionsplan und jede Einkaufsentscheidung beruht auf einer Bedarfsprognose – und in vielen Unternehmen ist diese Prognose noch immer eine Tabelle mit den Zahlen des Vorjahres plus Bauchgefühl. Die ML-basierte Bedarfsprognose lernt aus Tausenden verwandter Zeitreihen gleichzeitig, nutzt Preise, Aktionen, Feiertage und Wetter als Einflussgrößen und erzeugt probabilistische Prognosen (Bereiche statt Einzelwerte), aus denen die Bestandsoptimierung Bestellmengen ableiten kann. Seit 2024/2025 stehen mit vortrainierten Zeitreihen-Foundation-Modellen (Chronos-2, TimesFM, TiRex, Moirai) ohne eigenes Training solide Basisprognosen zur Verfügung (Zero-Shot). Das senkt die Einstiegshürde für den Mittelstand.

Problem & Nutzen

  • Heute: Disponenten schreiben die Historie im ERP fort (gleitende Durchschnitte, einfache exponentielle Glättung) oder in Excel und korrigieren dann manuell für Aktionen und Ereignisse. Die Folgen: Fehlbestände und entgangene Verkäufe bei Schnelldrehern, Überbestände und Abschriften (Frischware, Mode, Ersatzteile) bei Langsamdrehern, Peitscheneffekte (Bullwhip) in der vorgelagerten Lieferkette und viel Disponentenzeit für Routine-Zeitreihen.
  • KI-Nutzen: Globale Modelle, die über alle Produkte hinweg trainiert werden, lernen gemeinsame Muster (Saisonalität, Aktionsreaktion, Kannibalisierung), behandeln neue Produkte über Ähnlichkeit und skalieren auf Hunderttausende Zeitreihen. Disponenten wechseln vom Eintippen von Zahlen zum Prüfen von Ausnahmen.
  • Gemessene Ergebnisse (von Anbietern berichtet, nicht unabhängig geprüft): Blue Yonder berichtet, dass der britische Lebensmittelhändler Morrisons die Regalverfügbarkeit über 29.000+ Produkte in rund 500 Filialen mit Blue Yonder Demand um 30 % verbessert hat [9]; RELEX berichtet von 34,7 % weniger entgangenen Verkäufen und rund 50 % weniger Zeitaufwand für den Filialnachschub bei Grupo Vinoteca [10]; der deutsche Anbieter paretos berichtet von +50 % Prognosegenauigkeit bei Faller Packaging und einer Halbierung der Fehlbestände bei HelloFresh [11]. Solche Zahlen hängen stark von der Ausgangslage ab – messen Sie immer gegen Ihren eigenen aktuellen Prozess.

Varianten

  • Lebensmittel- und Frischehandel: tägliche Prognosen je Filiale und Artikel, kurze Haltbarkeit, starke Wetter- und Feiertagseffekte, sporadischer Bedarf bei Langsamdrehern; oft kombiniert mit Abschriftenpreisen (OPT-004) und der Reduzierung von Lebensmittelabfällen (VIS-033).
  • Mode und Saisonware: wenig oder keine Historie je Artikel → Prognose über Attribute und ähnliche Vorgänger; Vorab-Einkaufsplanung plus Neuprognose während der Saison; Trendsignale siehe PRED-034, Retouren siehe PRED-020.
  • E-Commerce: Prognosen je Lager und Tag einschließlich Retouren und Marketingkampagnen.
  • Großhandel / B2B-Vertrieb: unregelmäßige Bestellmuster weniger großer Kunden; Nutzung des Auftragsbestands, von EDI-Prognosen und kundenspezifischen Verträgen; sporadischer Ersatzteilbedarf (Croston/TSB).
  • Fertigung / Konsumgüter (CPG): Monats- bis Wochenprognosen auf Produktfamilienebene für S&OP und MRP; Demand Sensing korrigiert den kurzfristigen Horizont mit Aufträgen, Lieferungen und Kassendaten; Effekte von Handelsaktionen siehe OPT-016.
  • Pharma / Medizinprodukte: regulierte Versorgung, ausschreibungsgetriebener Bedarf, Meldung von Lieferengpässen.
  • Gastronomie und Bäckereien (KMU): tägliche Produktionsmengen je Filiale aus Kassendaten + Wetter – ein klassisches erstes Projekt für kleine Unternehmen.
  • Privatnutzung: außer für Hobby- und Nebenerwerbshändler (z. B. Marktplatz-Shops), die die Prognosefunktionen ihres Shops oder Lagerwerkzeugs nutzen, nicht relevant.

So funktioniert es

  1. Datenübernahme (ERP/Kasse/Webshop/EDI, tägliche Stapelverarbeitung)
  2. Bereinigung (Fehlbestandskorrektur
  3. „wahrer Bedarf“, Ausreißer, Retouren, Produktnachfolger)
  4. Feature Store (Kalender, Feiertage, Schulferien, Preis/Aktion, Wetter, Ereignisse)
  5. Segmentierung (schnell / langsam / sporadisch / neue Artikel — ABC/XYZ)
  6. Modellebene: statistische Basisverfahren + globales Gradient Boosting + Zeitreihen-Foundation-Modell
  7. Backtesting & Modellauswahl je Segment, Ensembling
  8. hierarchische Abstimmung (Artikel
  9. Kategorie
  10. Gesamt; Filiale
  11. Region)
  12. probabilistische Ausgabe (Quantile P10/P50/P90)
  13. Prüfung der Ausnahmen durch Disponenten + LLM-generierte Erklärungen (Mensch-in-der-Schleife (Human-in-the-Loop))
  14. Konsensprognose
  15. Nachschub / MRP / S&OP (OPT-005, OPT-008)
  • Modellfamilien: statistische Verfahren (AutoETS, AutoARIMA, Theta, MSTL, Croston/TSB für sporadischen Bedarf); globales ML (LightGBM/XGBoost auf Lag-, Rolling- und Kalender-Features – das Arbeitspferd der modernen Handelsprognose); Deep Learning (DeepAR, TFT, N-HiTS); und vortrainierte Foundation-Modelle, die ohne Training oder feingetunt (Feintuning) eingesetzt werden. Ensembles über diese Familien hinweg sind meist am robustesten.
  • Probabilistische Prognosen sind unverzichtbar: Sicherheitsbestand und Servicegrade werden aus Quantilen abgeleitet, nicht aus dem Mittelwert.
  • Mensch-in-der-Schleife: Disponenten korrigieren bei bekannten Ereignissen (Listungsänderungen, Aktionen von Wettbewerbern); verfolgen Sie den Forecast Value Added (FVA), um zu sehen, ob manuelle Korrekturen helfen oder schaden.
  • LLM-Ebene (optional): erklärt Prognoseänderungen in natürlicher Sprache, beantwortet „Warum ist Woche 48 so hoch?“ und verarbeitet unstrukturierte Signale (Kunden-E-Mails, Nachrichten) – die numerische Prognose selbst sollte bei Zeitreihen- bzw. Tabellenmodellen bleiben.

Datenaufbereitung

Die Bedarfsprognose braucht eine saubere Absatzhistorie je Artikel und Standort sowie Preise, Aktionen, Lagerbestände und Stammdaten. In einem KMU liegen diese Daten typischerweise im ERP, im Webshop oder in der Kasse, in Excel-Aktionsplänen und in den Köpfen der Disponenten.

Typische Lücken: - Fehlbestände, die als Absatz null erfasst sind (verdeckter Bedarf). - Geänderte Artikelnummern, doppelte oder ersetzte Artikel. - Nicht dokumentierte Aktionen und Preisänderungen. - Mehrere Vertriebskanäle in getrennten Systemen. - Fehlende oder veraltete Produkthierarchien.

Aufbereitungsschritte: 1. Auftrags- und Versandhistorie aus dem ERP exportieren (siehe PREP-005) und die Kanäle über einen gemeinsamen Artikelschlüssel zusammenführen. 2. Fehlbestandszeiträume und einmalige Ereignisse kennzeichnen und als unzuverlässig markieren. 3. Aktions- und Preiskalender aus Tabellenkalkulationen in saubere Tabellen überführen (PREP-011). 4. Stammdaten und Hierarchien bereinigen und Kennzahlendefinitionen mit der Fachabteilung abstimmen (PREP-012). 5. Einen Hold-out-Zeitraum als Testdaten zurückhalten (PREP-018).

Planen Sie dafür 30–50 % des Projektaufwands ein, überwiegend für die Vereinheitlichung der Artikel und die Aktionshistorie. Führen Sie zuerst die Prüfung aus GUIDE-003 durch; die Zuordnung und Lückenanalyse aus PREP-001 und PREP-002 zeigt schnell, ob zwei bis drei Jahre nutzbare Historie vorhanden sind. Werkzeuge: ERP-Export, Power Query, dbt oder DuckDB, reines Python (pandas).

Umsetzungswege

Welcher Weg für wen

  • KMU (A): Prognosemodule in ERP-, Bestandsplanungs- und Shop-Werkzeugen sind ausgereift, in der EU hostbar und für KMU bepreist; der Nachschub ist ein Standardprozess.
  • Großunternehmen (B): Die Prognose ist zentral für S&OP und läuft über Millionen von Zeitreihen; eine Pipeline auf der eigenen Datenplattform mit Cloud- oder offenen Modellen ist günstiger und besser steuerbar als Lizenzen pro Nutzer.
  • Entwickler (C): Open-Source-Bibliotheken (z. B. Nixtla statsforecast, LightGBM) laufen auf HW1 und bieten volle Kontrolle über Features und Hierarchien.

Weg A — Kaufen (für die meisten KMU empfohlen)

  • Planungssuiten für die Lieferkette (Großunternehmen): SAP IBP (Absatzplanung mit ML/Demand Sensing), Blue Yonder Demand, RELEX Solutions (Finnland, EU), o9 Solutions, Kinaxis, Oracle SCM Cloud, Microsoft Dynamics 365 Supply Chain Management (Bedarfsprognose).
  • Handelsspezialisiert: RELEX (EU), Blue Yonder, SAP for Retail, Slimstock Slim4 (Niederlande, EU), Inform add*ONE (Deutschland, EU), DynaSys / Board (EU).
  • KI-Planung mit Mittelstandsfokus: paretos (Heidelberg, Deutschland – Inferenz in der EU gehostet, Freigabe durch Disponenten vor dem Rückschreiben ins ERP) [11]; Bestandsoptimierungswerkzeuge mit integrierter Prognose für KMU-ERP-Systeme.
  • KMU / Kleinstunternehmen: in ERP- und Shopsysteme eingebaute Prognose (z. B. Microsoft Dynamics 365 Business Central, Shopify-/Marktplatz-Bestandsapps), oft ausreichend für < 1.000 Artikel.
  • Wählen Sie A, wenn: die Prognose direkt in Nachschub und Bestellung fließen muss, die Disponenten eine Oberfläche für manuelle Korrekturen brauchen und die Prozesse standardisiert sind. Prüfen Sie: EU-Hosting, ERP-Schnittstelle (SAP, Dynamics, proAlpha, abas), probabilistische Ausgabe, Aktionsbehandlung, Erklärbarkeit.

Weg B — Auf Cloud-KI-Diensten aufbauen

  • Verwaltete Prognosedienste: Google BigQuery ML AI.FORECAST mit eingebautem TimesFM (in allen von BigQuery unterstützten Regionen verfügbar, sodass EU-Standorte nutzbar sind) und ARIMA_PLUS_XREG [6]; Azure Machine Learning AutoML-Prognose (ARIMA, Prophet, LightGBM/XGBoost, TCN, Ensembles, „Many Models“ für Tausende Zeitreihen) [8]; Amazon SageMaker Canvas / AutoGluon auf SageMaker – beachten Sie: Amazon Forecast ist seit dem 29. Juli 2024 für Neukunden geschlossen [7]; Nixtla TimeGPT API mit exogenen Variablen [12]; Databricks / Snowflake ML mit offenen Bibliotheken.
  • Orchestrierung: dbt oder Spark für Features, MLflow für die Modellverwaltung, zeitgesteuerte Stapelaufträge (Airflow, Dagster, Azure Data Factory), Ergebnisse per API oder Flatfile zurück ins ERP.
  • LLMs (EU-Region): Mistral, Claude, Gemini oder GPT über EU-Endpunkte für Prognosekommentare und einen Disponenten-Chat auf den Prognosetabellen (siehe DATA-001).
  • Wählen Sie B, wenn: die Daten bereits in einer Cloud-Datenplattform liegen und ein Datenteam vorhanden ist.

Weg C — Selbst betreiben (Open Source)

  • Bibliotheken: Nixtla StatsForecast (schnelle AutoARIMA/ETS/Theta/MSTL, Croston/TSB; Apache-2.0) [5], MLForecast (LightGBM-basierte globale Modelle), NeuralForecast; AutoGluon-TimeSeries (ein fit() über statistische, LightGBM-, DeepAR/TFT- und Chronos-Modelle mit Ensembling) [4]; Darts, sktime, GluonTS; hierarchische Abstimmung mit HierarchicalForecast.
  • Foundation-Modelle mit offenen Gewichten: Amazon Chronos-2 (120M, Apache-2.0, multivariat und Kovariaten-fähig, Okt. 2025) und Chronos-Bolt [1][2]; Google TimesFM 2.5 (200M, Gewichte unter Apache-2.0; die Gewichte von TimesFM 3.0 ab Aug. 2026 sind nicht kommerziell – Produktivnutzung nur über Google Cloud) [3]; TiRex (35M, xLSTM, NXAI, Linz, Österreich – EU; NXAI-Community-Lizenz, Bedingungen prüfen) [13]; Salesforce Moirai 2.0 (Gewichte unter CC-BY-NC-4.0, nicht kommerziell) [14].
  • Hardware: HW1 genügt – statistische und LightGBM-Modelle laufen auf CPU-Servern; die kleinen Foundation-Modelle (9–200M Parameter) laufen auf CPU oder einer bescheidenen GPU. HW2 hilft beim Feintuning und bei sehr großen Zahlen von Artikel × Standort. Betriebsaufwand: Datenpipelines und Monitoring dominieren, nicht die Inferenz.

Weg D — Eigenes Training

Ein vollständig eigenes Deep-Learning-Modell übertrifft ein abgestimmtes LightGBM + Foundation-Modell- Ensemble selten. Lohnend ist das Feintuning eines Foundation-Modells (Chronos-2, TimesFM 2.5) auf der eigenen Historie bei großen Sortimenten oder eigene Features/Modelle für besondere Bedarfsmechanismen (Ausschreibungsgeschäft, wettergetriebene Getränke, Attributmodelle in der Mode). Erforderlich sind 2+ Jahre saubere Tages-/Wochenhistorie, Fehlbestandskennzeichen und Aktionsaufzeichnungen; der Hauptaufwand liegt in der Datenbereinigung, nicht in der Modellierung.

Stand der Technik (2026)

  • Globale Gradient-Boosting-Modelle (LightGBM auf Lag-, Kalender-, Preis- und Aktions-Features) sind bei reichhaltigen Handelsdaten das etablierte Arbeitspferd im Produktivbetrieb. Der Referenz-Benchmark ist der M5-Wettbewerb: 42.840 hierarchische, überwiegend sporadische Walmart-Zeitreihen mit Preis-, Aktions- und Ereignis-Einflussgrößen, rund 100.000 Einreichungen [15][16].
  • Zeitreihen-Foundation-Modelle haben sich schnell weiterentwickelt: Chronos-2 (Okt. 2025) führte Group Attention für In-Context-Learning über verwandte Zeitreihen und Kovariaten ein und meldet unter den vortrainierten Modellen Spitzenergebnisse bei fev-bench, GIFT-Eval und Chronos Benchmark II, mit den größten Gewinnen bei Aufgaben mit Kovariaten [1][2]; TimesFM ging auf 2.5 (16k Kontext, Kovariaten über XReg) und 3.0 (nativ multivariat & Kovariaten) [3]; TiRex meldet Spitzenwerte bei GIFT-Eval über kurze und lange Horizonte mit nur 35M Parametern [13]. Benchmarks: GIFT-Eval (97 Datensatzkonfigurationen, 7 Domänen, mit Kennzeichnung für Testdaten-Leckage) und fev-bench [17].
  • Praktische Folge: Foundation-Modelle liefern eine starke Zero-Shot-Basis für neue Produkte und Produkte mit kurzer Historie sowie für KMU ohne Data-Science-Team; im aktionslastigen Handel bleiben Ensembles mit Feature-reichen LightGBM-Modellen wichtig.
  • Agentische Planung: Suiten ergänzen LLM-Copiloten (z. B. Erklärung von Prognoseabweichungen, Szenariofragen) – nützlich für die Akzeptanz, nicht für die Genauigkeit.
  • Grenzen & Fehlerbilder: Fehlbestände zensieren den Bedarf (Prognosen lernen „kein Absatz“ als „kein Bedarf“, wenn nicht korrigiert wird); Strukturbrüche (Pandemie, neuer Wettbewerber, Preisschocks) zerstören Muster; neue Produkte und Aktionen bleiben am schwierigsten; MAPE ist bei sporadischen Artikeln irreführend (nutzen Sie WAPE/MASE, Bias und Quantilverlust); Siege in öffentlichen Benchmarks garantieren keine Siege auf Ihren Daten; prüfen Sie die Lizenzen der Modellgewichte vor dem Produktiveinsatz.

Gemeinsame Bausteine & Kombinationen

  • Gleicher Zeitreihen-Stack (Zeitreihen + Tabellen-ML, HW1): PRED-002 Absatzprognose, PRED-007 Energielast, PRED-008 Preisprognose, PRED-011 Personalbedarf, PRED-016 Liquiditätsprognose, PRED-019 Mobilitätsbedarf – ein Feature Store, ein Backtesting-Framework und ein Foundation-Modell-Dienst (Chronos-2 / TimesFM) können alle bedienen.
  • Nachgelagerte Entscheidungsebene (Optimierungslöser): OPT-005 Bestandsoptimierung & Nachschub (verarbeitet die Quantile), OPT-002 Produktionsfeinplanung/APS, OPT-008 S&OP und Netzwerkdesign, OPT-004 dynamische Preise & Abschriften, OPT-016 Aktionsplanung, OPT-017 Sortimentsplanung.
  • Eingaben aus Nachbarbereichen: PRED-017 Wetterprognosen als Einflussgrößen, PRED-034 Trendsignale, PRED-020 Retourenquoten, DATA-003 Stammdatenbereinigung, ANOM-011 Lieferantenrisiko.
  • Oberfläche für Disponenten: DATA-001 dialogbasierte BI und DATA-024 FP&A-Copilot teilen sich die LLM-Ebene; VIS-033 Lebensmittelabfall-Erfassung liefert Abfall-Rückmeldungen für die Frischeprognose.

Aufwand, Kosten & Kennzahlen

  • Weg A: 3–9 Monate für die Einführung einer Suite inkl. ERP-Integration und Datenbereinigung; Lizenzen meist nach Volumen (Artikel × Standort) oder Umsatzband.
  • Weg B/C: 2–4 Monate für eine erste Produktivpipeline mit einer Data Scientistin bzw. einem Data Scientist/Ingenieur; die Rechenkosten sind niedrig (CPU-Stapelaufträge), die Datentechnik ist der Hauptkostenfaktor.
  • Weg D: zusätzlich 1–3 Monate; nur für große Sortimente.
  • Kennzahlen: Prognosegenauigkeit (WAPE, MASE) und Bias je Segment gegenüber der aktuellen Ausgangslage; Forecast Value Added manueller Korrekturen der Disponenten; Regalverfügbarkeit / Servicegrad; entgangene Verkäufe; Reichweite / Lagerumschlag; Abschriften und Abfall; Disponentenzeit je Artikel.

Menschen & Veränderung

Beteiligen Sie: die Geschäftsleitung (Budget, Servicegradziele), die Abteilungsleitung Supply Chain oder Einkauf als Prozessverantwortliche, die Disponenten als tägliche Nutzer, die IT für den ERP-Export, die Dateneigner für Artikel- und Aktionsdaten sowie wichtige Lieferanten, wenn Prognosen mit ihnen geteilt werden. Beziehen Sie die Disponenten von Anfang an ein: Sie kennen die Aktionen und Ausnahmen, die das Modell nicht sehen kann.

Betriebsrat: kommt darauf an. Eine reine Prognose auf Artikelebene richtet sich nicht an Beschäftigte. Sie wird nach §87 Abs. 1 Nr. 6 BetrVG mitbestimmungspflichtig, wenn manuelle Korrekturen oder die Prognosegenauigkeit je Person protokolliert werden; nach dem Bundesarbeitsgericht (BAG) genügt die objektive Eignung zur Überwachung. Informieren Sie den Betriebsrat trotzdem nach §90 Abs. 1 Nr. 3 BetrVG, weil sich Arbeitsabläufe der Planung ändern. Nur relevant, wenn ein gewählter Betriebsrat besteht; öffentliche Stellen beteiligen den Personalrat.

Datenschutz: überwiegend nicht personenbezogene Daten, daher ist eine Datenschutz-Folgenabschätzung (DSFA) meist nicht nötig. Beziehen Sie dennoch die/den Datenschutzbeauftragte(n) ein, wenn Daten auf Kundenebene genutzt werden oder ein externer Dienst Daten verarbeitet (AVV, Art. 28 DSGVO).

KI-Kompetenz: unterstützen Sie die Disponenten mit einer kurzen Schulung zu probabilistischen Prognosen und Bias (GUIDE-006).

Typische Bedenken: „Das Modell ersetzt mein Urteil“ und „Die Prognose ist falsch“. Begegnen Sie beiden mit einem Disponenten-in-der-Schleife-Design: Die Disponentin bzw. der Disponent kann korrigieren, und die Genauigkeit wird gegen den alten Prozess gemessen. Starten Sie mit einer Produktgruppe als Pilot (GUIDE-009) und kommunizieren Sie offen (GUIDE-008).

Risiken, Regulierung & Compliance

  • KI-Verordnung (AI Act): minimales Risiko – Bedarfsprognose ist nicht in Anhang III aufgeführt; „kritische Infrastruktur“ umfasst Sicherheitskomponenten bei der Verwaltung von Versorgungsnetzen und Verkehr, nicht die kaufmännische Versorgungsplanung [18]. Die Pflicht zur KI-Kompetenz (Art. 4) gilt; keine Transparenzpflicht nach Art. 50 für interne Prognosen. Die Einstufung kann sich nur ändern, wenn das Ergebnis für Entscheidungen über Personen genutzt wird (z. B. Personaleinsatzplanung → siehe PRED-011 und HR-Regeln).
  • DSGVO: aggregierte Absatzdaten sind keine personenbezogenen Daten; Kundenkarten- oder kundenbezogene Bestellhistorien sind es – vor der Modellierung aggregieren oder Zweckbindung und einen AVV mit dem Anbieter anwenden.
  • Wettbewerbsrecht: Der Austausch von Prognosen oder Bedarfsdaten mit Wettbewerbern oder innerhalb einer Einkaufsgemeinschaft kann kartellrechtliche Fragen aufwerfen – halten Sie den Datenaustausch innerhalb von Kooperationsvereinbarungen zwischen Lieferant und Händler.
  • Branchenregeln: Pharma/Medizinprodukte (Meldung von Lieferengpässen), Lebensmittel (Haltbarkeit, Abfallmeldung), GoBD für Prüfpfade, wenn Prognosen automatische Bestellungen auslösen.
  • Geschäftsrisiken: übermäßiges Vertrauen in automatische Bestellungen, unbemerkte Ausfälle der Datenpipeline, Modelldrift nach Strukturbrüchen. Gegenmaßnahmen: Überwachung von Bias und Fehler je Segment, Bestellobergrenzen und Freigabeschwellen, Rückfall auf statistische Basisverfahren, regelmäßige Backtests.

Erste Schritte

  1. 2–3 Jahre Absatzhistorie je Artikel und Standort mit Fehlbestandskennzeichen, Preisen und Aktionen extrahieren; die Genauigkeit (WAPE, Bias) des heutigen Prozesses als Ausgangswert messen.
  2. Das Sortiment segmentieren (ABC/XYZ, sporadisch, neue Artikel) und einen schnellen Vergleich mit StatsForecast-Basisverfahren, LightGBM (MLForecast) und Chronos-2 / TimesFM 2.5 im Zero-Shot-Betrieb durchführen, z. B. in AutoGluon-TimeSeries.
  3. Parallel 1–2 Werkzeuge nach Weg A mit denselben Daten testen, wenn Prognosen direkt in die Bestellung einfließen sollen.
  4. Mit einer Warengruppe oder einem Werk live gehen, mit Prüfung der Ausnahmen durch die Disponenten; Quantile in den Nachschub einspeisen (OPT-005).
  5. Genauigkeit, Servicegrad und Bestand monatlich verfolgen; Einflussgrößen (Wetter, Ereignisse) schrittweise ergänzen.

Quellen

  1. Amazon Science — Chronos forecasting repository (Chronos-2, Chronos-Bolt, licence, benchmark claims) — https://github.com/amazon-science/chronos-forecasting
  2. Ansari et al. — "Chronos-2: From Univariate to Universal Forecasting" (arXiv 2510.15821) — https://arxiv.org/abs/2510.15821
  3. Google Research — TimesFM repository (2.5 / 3.0, licences, BigQuery) — https://github.com/google-research/timesfm
  4. AutoGluon — Time Series Forecasting documentation — https://auto.gluon.ai/stable/tutorials/timeseries/index.html
  5. Nixtla — StatsForecast repository — https://github.com/Nixtla/statsforecast
  6. Google Cloud — BigQuery built-in TimesFM model / AI.FORECAST — https://docs.cloud.google.com/bigquery/docs/timesfm-model
  7. AWS Machine Learning Blog — Transition your Amazon Forecast usage to Amazon SageMaker Canvas — https://aws.amazon.com/blogs/machine-learning/transition-your-amazon-forecast-usage-to-amazon-sagemaker-canvas/
  8. Microsoft Learn — Overview of forecasting methods in AutoML (Azure Machine Learning) — https://learn.microsoft.com/en-us/azure/machine-learning/concept-automl-forecasting-methods
  9. Blue Yonder — Morrisons customer story — https://blueyonder.com/customers/morrisons
  10. RELEX Solutions — Resources / customer stories (Grupo Vinoteca) — https://www.relexsolutions.com/resources/
  11. paretos — Socrates AI decision system (Heidelberg, customer results) — https://www.paretos.com/
  12. Nixtla — TimeGPT exogenous variables documentation — https://www.nixtla.io/docs/forecasting/exogenous-variables
  13. NXAI — TiRex repository — https://github.com/NX-AI/tirex
  14. Salesforce AI Research — Uni2TS / Moirai repository — https://github.com/SalesforceAIResearch/uni2ts
  15. Makridakis, Spiliotis, Assimakopoulos — "M5 accuracy competition: Results, findings, and conclusions", IJF 38(4), 2022 — https://ideas.repec.org/a/eee/intfor/v38y2022i4p1346-1364.html
  16. University of Nicosia IFF — M5 Competition overview — https://www.unic.ac.cy/iff/research/forecasting/m5-competition/
  17. Salesforce AI Research — GIFT-Eval benchmark — https://github.com/SalesforceAIResearch/gift-eval
  18. AI Act Annex III (high-risk areas), based on Regulation (EU) 2024/1689 — https://artificialintelligenceact.eu/annex/3/