Demand Forecasting im Einzelhandel: Prognosen bis zur Filiale

Demand Forecasting im Einzelhandel bedeutet: Der zukünftige Absatz wird pro Filiale und Artikel auf Basis vorhandener Daten vorhergesagt. Das Ergebnis ist eine erwartete Absatzmenge je Filiale, Artikel und Tag, idealerweise mit einer Spanne, wie sicher die Prognose ist. Diese Prognose speist Bestellvorschläge, Nachschub-Signale und Personaleinsatzplanung.

Der Kernbegriff kommt aus der englischen Supply-Chain-Literatur; die deutschsprachigen Synonyme Nachfrageprognose und Bedarfsplanung bezeichnen dasselbe Objekt. Wichtig ist die Abgrenzung: Der Forecast sagt die Nachfrage voraus. Die eigentliche Bestellentscheidung kommt danach. Die Bestellmenge folgt aus der Prognose plus Servicegrad, Lieferzeit und Restbestand. Preis-Optimierung und Aktions-Wirkungsmessung nutzen denselben Forecast als Input und bleiben eigene Verfahren. Die Warenwirtschaft wird dadurch nicht ersetzt. Sie bekommt nur eine bessere Grundlage für Bestellungen und Bestände.

Wie sich die Bedarfsprognose in das Gesamtbild der Kundenintelligenz einordnet und wie die weiteren Retail-Use-Cases (Dynamic Pricing, On-Shelf-Availability, Trade-Promotion-Effectiveness) darauf aufbauen, zeigen wir im Überblick zu Customer Intelligence auf dem Lakehouse.

Ob ein Retail-Forecast gut wird, entscheidet sich meistens an den Daten, nicht am Modellnamen. Kassendaten allein reichen nicht. Sie zeigen, was passiert ist, aber nicht die Aktion nächste Woche, das Wetter am Samstag oder den Feiertag im Nachbarbundesland.

Die tragfähige Basis ist die POS-Historie: Absatz je Store, SKU und Tag als Delta-Tabelle, ergänzt um abgeleitete Größen (gleitende Mittelwerte, Wochenrhythmus, Jahresvergleich, Absatz relativ zur Warengruppe). Sie ist die Basis. Der eigentliche Zusatznutzen entsteht durch weitere Signale. Die Wirkung entsteht dort, wo externe Signale die Nachfrage erklären, die die Historie allein nicht sieht: Aktionen, Wetter, Feiertage, Preis-Änderungen und Bestand.

Ein Beleg dafür, wie stark diese externen Signale tragen, liefert der belgische Fleischwarenhändler Meat&More. Mit einer Feature-Basis aus Aktions-, Preis-, Wetter- und Sortiments-Signalen hat der Betrieb Store-Level-Forecasts bis 14 Tage voraus mit einer Fehlerrate unter 5 Prozent auf 60 Prozent der Produkte erreicht. Solche Ergebnisse entstehen nicht durch ein einzelnes Feature. Entscheidend ist, dass Aktionen, Preise, Wetter und Sortiment zum richtigen Zeitpunkt sauber verfügbar sind.

Der Feature Store ist selten der auffälligste Teil der Lösung, aber oft der wichtigste für einen stabilen Betrieb. Dort liegen die wichtigsten Feature-Gruppen als eigene Delta-Tabellen: Aktionen, Wetter, Feiertage, Preise, Bestände und Store-Merkmale. Training und spätere Prognose greifen auf dieselbe Feature-Logik zu. Für jede Zeile werden nur die Informationen genutzt, die zu diesem Zeitpunkt bereits bekannt gewesen wären. Ergebnis: keine Verschiebung zwischen Training und Betrieb, kein Leaken zukünftiger Information, keine überraschend gute Testmetrik, die produktiv wegbricht.

Der zweite Nutzen: Feature-Tabellen bekommen Owner. Der Aktions-Kalender gehört dem Kategorien-Team, die POS-Silber-Schicht dem Datenteam, die Wetter-Features dem Plattform-Team. Feature Engineering in Unity Catalog macht diese Zuständigkeit sichtbar, die Lineage-Ansicht zeigt für jedes Modell, welche Feature-Tabellen es liest und welche Änderungen es beeinflussen. Governance entsteht damit direkt an den Daten: Es ist sichtbar, wem ein Feature gehört, woher es kommt und welche Modelle es nutzen. Wie POS-, Aktions- und Wettersignale sauber ins Lakehouse kommen, klären wir im Überblick zu Auto Loader für den kontinuierlichen Ingest.

Ein Notebook zeigt, dass ein Forecast funktionieren kann. Ein produktiver Forecast braucht aber Versionierung, Freigabe, Retraining und Monitoring: genau das leistet das MLflow Model Registry auf Databricks. Der Unterschied zeigt sich in Phasen mit hoher Last: Weihnachten, Black Week, Aktionswochen oder Ferienbeginn. Das registrierte Modell wird laut Zeitplan neu trainiert, die Ergebnisse laufen ins Backtesting, die Registry entscheidet über Freigabe.

Für den Betrieb sind vier Dinge wichtig.

Was die Lifecycle-Disziplin operativ bedeutet, zeigt der Umstieg der H&M Group von einem On-Prem-Hadoop-Cluster auf das Databricks-Lakehouse: 70 Prozent geringere operative Kosten und Time-to-Market von einem Jahr auf wenige Wochen. Der Effekt entsteht aus geordnetem Betrieb: registrierte Modelle, geplante Retrainings, verlässliches Rollout.

Die Metriken müssen zur Geschäftsfrage passen. WAPE (Weighted Absolute Percentage Error) je Warengruppe und Filial-Cluster ist üblicher Standard; MAPE verzerrt bei niedrigen Absätzen und darf nicht als einzige Größe stehen. Wichtiger als jede Prozent-Verbesserung im WAPE ist der Segment-Blick: sinkt der Fehler auf Frischwaren, während er auf Long-Tail-Artikeln steigt? Fängt das Modell Aktionswochen, überschätzt aber die Nicht-Aktions-Wochen? Für die Freigabe reichen technische Metriken nicht. Zusätzlich sollten Out-of-Stock-Quote und Abschriften je Warengruppe betrachtet werden. Der aggregierte Gesamtwert reicht dafür nicht.

Demand Forecasting ist nur ein Teil des Retail-Prozesses. Er ersetzt weder das Warenwirtschaftssystem noch die Preis-Entscheidung noch die Regalverfügbarkeit. Ohne klare Abgrenzung entsteht schnell ein Forecast, der zwar technisch funktioniert, aber im Prozess nicht hilft.

Die Warenwirtschaft (SAP, Microsoft, Odoo als Handels-Backbone) bleibt Bestellabwicklung, Wareneingang, Inventur und Kassenanbindung. Der Forecast verbessert den Bestellvorschlag. Die eigentliche Bestellung, Bestandsführung und Abwicklung bleiben in der Warenwirtschaft. Die Bestellmenge folgt aus Prognose, Restbestand, Servicegrad und Lieferzeit. SaaS-Forecast-Werkzeuge wie SAP IBP, o9 Solutions, RELEX oder Blue Yonder sind eigenständige Lösungen mit eigener Datenkopie und eigener Governance-Welt. Sie tragen für Ketten ohne eigenes Lakehouse; wo Kassen- und Aktionsdaten bereits im Lakehouse liegen und die Datenhoheit dort bleiben soll, wird die Kopie zum Nachteil.

Pricing ist ein eigener Use Case. Wie derselbe Forecast als Input für dynamische Preis-Entscheidungen weitergenutzt wird, führen wir aus im Überblick zu Dynamic Pricing auf dem Lakehouse. On-Shelf Availability setzt noch früher an: Ist der Artikel überhaupt im Regal verfügbar? Wie Store-Signale und Nachbestell-Trigger dort ineinandergreifen, klären wir im Überblick zu On-Shelf Availability als Regal-Signal. Und die Wirkung der Aktion selbst ist die dritte Achse. Wie Aktions-Effekte gemessen und in die Feature-Konstruktion zurückgespielt werden, zeigen wir im Überblick zu Trade Promotion Effectiveness. Wo Loyalty- und Kunden-Signale in denselben Feature-Layer einfließen, ordnen wir im Überblick zu Customer 360 auf dem Lakehouse ein.

Ein Forecast kann die Marktleitung unterstützen, aber nicht ersetzen. In fast jedem Projekt zeigen sich dieselben Grenzen:

Die Größenordnung der Wirkung liegt zwischen den Extremen. Die Referenz-Werte aus Meat&More (Fehlerrate unter 5 Prozent auf 60 Prozent des Sortiments), aus Albert Heijn (3,6 Millionen Kilogramm weniger Lebensmittelabfall im ersten Jahr) und aus den DS-STREAM-Fällen (15 bis 30 Prozent geringere Bestände) markieren die Bandbreite. Sie tragen als Referenz-Größenordnungen für einen sauber gebauten Store-SKU-Forecast, ohne dass sich daraus ein Versprechen ableiten ließe. Der Nutzen entsteht am Regal, in der Bestellliste und am Aktions-Freitag. Eine bessere WAPE-Zahl allein bringt noch keinen Nutzen. Entscheidend ist, ob weniger Ware fehlt, weniger abgeschrieben wird und Bestellentscheidungen besser werden.