Saisonale Nachfrageprognose

Das echte Ausmaß des Problems

Saisonale Nachfrage ist der klassische Blindfleck mittelständischer Produktion. Jedes Jahr die gleichen Fehler: Zu viel produzieren bei den falschen Produkten, zu wenig bei den richtigen.

Warum ist das so schwer zu prognostizieren?

Saisonale Nachfrage ist nicht einfach “Winter kalt → mehr Heißgetränke”. Es ist ein Cluster aus:

• Kalender: Weihnachten, Ostern, Schulferien, Feiertage (Karfreitag, Pfingsten variieren)
• Wetter: Temperatur ist ein großer Treiber für Getränke, Eiscreme, Grillprodukte
• Soziale Events: Oktoberfest, Karneval, lokale Volksfeste
• Aktionshistorie: Was hat letztes Jahr funktioniert? War eine Anzeige dabei?
• Markttrends: TikTok-Trends (der “Pink Gin Boom”), Gesundheitsfokus, vegane Produkte

Ein Planer im Kopf kann vier, maximal fünf dieser Faktoren gleichzeitig berücksichtigen. ML-Modelle analysieren alle zehn und erkennen die Wechselwirkungen dazwischen.

Die Kosten fehlerhafter Prognosen:

• Überproduktion: Du produzierst 40.000 Kasten zu viel Apfelschorle, weil es nicht so kalt wurde wie erwartet. Das landet im Abverkauf mit 40 Prozent Rabatt. 40.000 × 12 Euro × 0,4 = 192.000 Euro Verlust. Oder es läuft ab (Fruchtsaftgetränke haben kurze Haltbarkeit) — dann ist es Totalverlust.
• Engpässe: Du produzierst 60.000 Kasten zu wenig Bier, weil das Oktoberfest früher starke Nachfrage brachte als erwartet. Lieferverzögerungen, verlorene Umsätze, wütende Kunden, die zur Konkurrenz wechseln.

Bei einem mittelständischen Getränkehersteller (100–200 Mio. EUR Umsatz) summiert sich das auf 3–8 % der Jahres-Marge, nur wegen Planungsfehlern.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ MAPE = Mean Absolute Percentage Error — je niedriger, desto genauer die Prognose.

Quellen: Nestlé Fallstudie (2023) — 10–15% Genauigkeitsverbesserung mit ML; Branchenberichte zu EazyStock und ähnlichen Forecasting-Tools; eigene Implementierungen in 5 Lebensmittelbetrieben (2024–2026).

Einschätzung auf einen Blick

Zeitersparnis — mittel (3/5)
Ein Prognosesystem spart nicht die tägliche Planungszeit — es liefert die Prognose, aber ein Mensch muss sie prüfen, validieren und taktisch anpassen (“das Event wurde verschoben, die Prognose ist veraltet”). Die reine Zeitersparnis bleibt marginal, 10 bis 15 Prozent weniger Planungsaufwand. Der Hauptnutzen liegt nicht in der Zeit, sondern in besseren Entscheidungen, die Kosten senken. Im Vergleich zu HACCP-Dokumentation (4 Stunden täglich am Protokoll eingespart) ist das ein Nachteil. Daher 3, nicht 4.

Kosteneinsparung — hoch (4/5)
Das ist der Kernvorteil. 30.000 bis 50.000 Euro für die Einrichtung, dann Jahr für Jahr 40.000 bis 150.000 Euro Marge durch weniger Überproduktion und weniger Engpässe. Eine Saison mit besseren Prognosen zahlt sich aus. Im Vergleich zu Haltbarkeitsprognose (ebenfalls mit messbarem ROI) liegt der Prognose-Vorteil sogar etwas höher — der Hebel durch vermiedene Überproduktion ist größer als der Hebel durch reduzierten Abfall. Daher 4.

Schnelle Umsetzung — niedrig (2/5)
Das ist der klassische Fallstrick: Allein für die Datenintegration brauchst du 10 bis 16 Wochen. Wo liegen die Verkaufsdaten? Wie standardisiert sind sie? Wie vollständig sind die historischen Zeitreihen? Bei einer Umsetzung auf der grünen Wiese (neues ERP, neue Datenbank) sind es 20 Wochen und mehr. Erst danach kannst du trainieren. Dann musst du eine volle Saison abwarten, bevor du bewerten kannst, ob die Prognose funktioniert — du kannst nicht im Januar testen, ob die Winterprognose gut ist. Das ist deutlich langsamer als Nährwertberechnung (4 bis 8 Wochen), aber nicht so zäh wie Haltbarkeitsprognose (6 bis 8 Monate). Daher 2.

ROI-Sicherheit — mittel (3/5)
Der ROI hängt von drei Unsicherheiten ab: (1) Wie gut sind deine historischen Daten? Wenn sie fragmentiert oder lückenhaft sind, trainiert das Modell auf Rauschen. (2) Wie stabil ist dein Geschäftsmodell? Wenn du gerade einen großen Neukunden gewonnen hast, ist die Historie nur bedingt repräsentativ. (3) Werden externe Faktoren berücksichtigt? Wetter, Events, Aktionen — wenn das System diese nicht richtig gewichtet, ist die Prognose nicht besser als vorher. Im Gegensatz zu Allergenkennzeichnung (wo der Compliance-Gewinn eindeutig ist) bleibt der Prognose-ROI probabilistisch. Daher 3, nicht 4.

Skalierbarkeit — mittel-hoch (4/5)
Das System lernt für eine Produktkategorie (z.B. “Biere”), danach lässt es sich beliebig auf andere Kategorien übertragen (Radler, Wein, Spirituosen) — jede bekommt ihr eigenes Modell, aber die Infrastruktur bleibt wiederverwendbar. Das skaliert wie ein Softwaresystem. Aber: Neue geografische Märkte (z.B. Einstieg in Österreich) brauchen neue Daten und neues Training — das ist nicht umsonst. Jede neue Saison braucht ein erneutes Training. Daher nicht 5, sondern 4 — Wachstum ist möglich, aber nicht reibungslos.

Richtwerte — stark abhängig von Datenqualität, Geschäftsmodell-Stabilität und externen Marktfaktoren.

Was ein Prognosemodell konkret macht

Ein Nachfrageprognose-System ist im Kern ein Machine Learning-Modell, das historische Absatzdaten analysiert und externe Treiber einbezieht, um die wahrscheinliche Nachfrage für die nächsten Wochen und Monate zu berechnen.

Das System arbeitet in vier Schritten:

1. Datensammlung: Historische Absatzdaten + externe Treiber
Das Modell braucht:

• Interne Daten: Wöchentliche oder tägliche Verkaufszahlen pro Produktkategorie (mindestens 24 Monate, besser 36+ Monate)
• Wetterdaten: Temperatur, Niederschlag (historisch und Vorhersage), weil die Getränkenachfrage stark temperaturabhängig ist (Eis bei 25+ Grad, Heißgetränke bei unter 10 Grad)
• Kalender: Feiertage, Schulferien, Wochenende gegenüber Wochentag
• Event-Daten: Oktoberfest, Karneval, lokale Volksfeste, Jahrmärkte
• Aktionshistorie: Wann gab es Anzeigen? Rabatte? Probierproben? Was war die Reaktion?

All diese Daten werden zusammengeführt in eine strukturierte Zeitreihe.

2. Feature Engineering: “Welche Variablen zählen wirklich?”
Nicht alle Daten sind gleich wichtig. Ein ML-Modell für Getränke kann etwa feststellen:

• Temperatur ist der stärkste Treiber (für Bier: -0,8 Korrelation — je wärmer, desto mehr Bier)
• Schulferien sind weniger wichtig als erwartet (weil viele in Urlaub fahren, nicht zu Hause trinken)
• Aktionen wirken am Wochenende stärker als unter der Woche

Das Modell lernt, welche Kombination von Variablen die beste Prognose ergibt.

3. Training und Validierung
Das Modell wird auf 24 Monaten Daten trainiert (die “Trainingsmenge”) und danach auf 3 Monaten geprüft (die “Testmenge”), die es noch nie gesehen hat. Ziel: MAPE (Fehler) unter 20 Prozent. Wenn das funktioniert, wird das Modell produktiv eingesetzt.

4. Einführung und laufende Anpassung
Das System gibt wöchentliche Prognosen aus: “Nächste Woche prognostiziere ich 145.000 Kasten Bier (Vertrauensintervall: 130.000–160.000).” Die Planerin validiert: “Das ergibt Sinn, Wetter ist warm, Wochenende ist Volksfest.” Oder: “Das ist zu hoch — Event wurde verschoben.” Dann wird der Plan angepasst. Nach Ablauf der Woche werden echte Verkaufszahlen mit der Prognose verglichen, und das Modell wird (monatlich oder quartalsweise) mit neuen Daten nachtrainiert, damit es nicht veraltet.

Konkrete Werkzeuge — was wann passt

EazyStock — Die fokussierte Lösung (wenn Nachfrageplanung im Vordergrund steht, Bestandsoptimierung integriert)
EazyStock ist eine Nachfrageplanungs-Plattform speziell für Lebensmittelhersteller und -einzelhändler. Bindet sich an die meisten ERP-Systeme (SAP, NetSuite) an, berücksichtigt Saisonalität, Wetterdaten, Aktionshistorie. Kostet ca. 20.000 bis 60.000 Euro Einrichtung, dann 3.000 bis 8.000 Euro pro Monat. Einführung in 10 bis 14 Wochen. Sehr food-spezifisch, gute Oberfläche, guter Support.

DataRobot — Die AutoML-Lösung (wenn du flexibles Modell-Engineering brauchst und Budget hast)
DataRobot ist eine AutoML-Plattform, die automatisch verschiedene ML-Modelle trainiert (ARIMA, XGBoost, LSTMs) und das beste auswählt. Kostet ca. 40.000 bis 100.000 Euro pro Jahr. Sinnvoll, wenn ihr mehrere Prognoseaufgaben habt (nicht nur Nachfrage, sondern auch Bestandsverweildauer etc.). Weniger food-spezifisch, aber flexibler.

Azure Machine Learning — Die Cloud-Integration (wenn Microsoft-Umgebung, hybride Workloads)
Azure ML ist eine vollständige ML-Plattform in der Cloud. Kostet ca. 2.000 bis 5.000 Euro pro Monat. Sinnvoll, wenn ihr bereits Azure nutzt und eigene Data-Science-Kompetenz habt. Die Einstiegshürde ist höher, die Langzeitflexibilität größer.

Python mit scikit-learn und Prophet (Open Source) — Die selbstgebaute Lösung (wenn interne Data-Science-Kompetenz vorhanden, Budget begrenzt)
Mit Python und gängigen ML-Bibliotheken (scikit-learn für Regression, Prophet für Zeitreihen) könnt ihr ein Prognosemodell selbst bauen. Kosten: 40.000 bis 80.000 Euro für die Entwicklung (6 bis 8 Wochen), danach nur Hosting (ca. 500 Euro pro Monat). Nachteil: Ihr müsst das System selbst warten und weiterentwickeln.

Datenschutz und Datenhaltung

Nachfrageprognose berührt typischerweise keine personenbezogenen Daten — nur aggregierte Absatzzahlen, Wetter und Kalender. DSGVO ist nicht zentral.

Relevant sind aber:

Geschäftsgeheimnisse:
Deine Absatzzahlen und Prognosemodelle sind Geschäftsgeheimnisse. Das System muss in einer Private Cloud oder vor Ort laufen, nicht in einer Mehrmandanten-SaaS. DataRobot und Azure ML bieten EU-Hosting an.

Datenspeicherung:
Historische Absatzdaten umfassen typischerweise 36+ Monate — das ist viel Speicher. Halte sie in einer EU-Region (nicht USA), um Compliance einfach zu halten.

Was es kostet — realistisch gerechnet

Szenario 1: EazyStock (empfohlen für Food-Spezialist)

• Einrichtung und Datenintegration: 25.000–35.000 Euro (12–14 Wochen)
• Laufend pro Monat: 4.000–6.000 Euro Lizenz + 500 Euro Support
• Jahr 1 gesamt: 30.000 + (4.500 × 12) = 84.000 Euro
• Jahr 2+: 54.000 Euro (Lizenz + Support)

ROI-Szenario: Ein mittelständischer Getränkehersteller (150 Mio. Euro Umsatz) verliert etwa 3 bis 5 Prozent Marge durch Planungsfehler (4,5 bis 7,5 Mio. Euro Gesamtmarge × 0,05 = 225.000 bis 375.000 Euro Verlust pro Jahr). Mit besseren Prognosen könnt ihr 40 bis 60 Prozent davon einsparen = 90.000 bis 225.000 Euro zurückgewinnen. Jahr 1 Kosten: 84.000 Euro. Nutzen (konservativ): 90.000 Euro. Amortisation nach 11 Monaten. Jahr 2 Kosten: 54.000 Euro. Nutzen: 90.000 Euro. ROI in Jahr 2: 67 Prozent.

Szenario 2: DataRobot (für höhere Flexibilität)

• Einrichtung und Modelltraining: 20.000–30.000 Euro (8–10 Wochen)
• Laufend pro Jahr: 60.000 Euro (DataRobot-Lizenz) + 2.000 Euro Support
• Jahr 1 gesamt: 25.000 + 62.000 = 87.000 Euro
• Jahr 2+: 62.000 Euro

ROI: Gleich wie bei EazyStock, aber mit Flexibilität für mehrere Prognose-Anwendungen (nicht nur Nachfrage, sondern auch Abwanderung, Bestandsverweildauer etc.).

Szenario 3: Python-Eigenentwicklung

• Entwicklung (Data Scientist, 10 Wochen): 50.000–70.000 Euro
• Laufend: 500–1.000 Euro Hosting + 15 Prozent einer Entwicklerstelle für Retraining = 12.000 Euro pro Jahr
• Jahr 1 gesamt: 60.000 + 12.000 = 72.000 Euro
• Jahr 2+: 12.000 Euro

ROI: Schnellere Amortisation, aber langfristig fragil, sobald die Entwicklerin den Betrieb verlässt und niemand das System weiter pflegen kann.

Ehrliche Rechnung: Was oft schiefgeht

• Schlechte Datenqualität: Absatzzahlen sind womöglich nicht sauber (Retouren nicht abgezogen, Aktionen nicht markiert). Das Modell lernt auf Rauschen, die Prognose wird nicht besser als die alte Excel-Methode.
• Große Marktveränderungen: Neue Konkurrenz, Wechsel des Distributors, Änderung des Geschäftsmodells — plötzlich ist die historische Zeitreihe nicht mehr repräsentativ. Das Modell muss neu trainiert werden (2 bis 4 Wochen).
• Zu hohe Erwartungen: “Mit KI sollte die Prognose auf 5 Prozent Fehler sinken.” Realistisch: 15 bis 20 Prozent Fehler. Das ist besser als vorher 25 bis 35 Prozent, aber nicht magisch genau.

Realistische Erwartung: Nach 6 Monaten erste greifbare Verbesserung (bessere Klassifizierung der Bestände), nach einer kompletten Saison steht fest, ob der ROI real ist.

Drei typische Einstiegsfehler

Fehler 1: Alles einbeziehen wollen — 200 Variablen statt 20
Die Versuchung ist groß: Marketingbudget, Social-Media-Engagement, Konkurrenzpreise, Influencer-Reichweite, Mondphase (?). Das führt zu Overfitting — das Modell lernt Muster in den Trainingsdaten, die es nicht verallgemeinern kann. Im Betrieb ist die Prognose dann schlecht. Was hilft: Mit 10 bis 15 Variablen starten (Temperatur, Kalender, Wetter, Aktionen), dann iterativ erweitern.

Fehler 2: Nicht auf externe Faktoren reagieren
Das Modell sagt “nächste Woche 150.000 Kasten”, aber ein großes Event wurde gerade abgesagt. Oder die Konkurrenz hat eine neue Produktlinie gestartet und nimmt Marktanteile. Das Modell weiß davon nichts und kann nicht reagieren. Was hilft: Die Prognose ist eine Eingabe, keine Ausgabe. Ein Mensch muss sie validieren und für externe Schocks korrigieren.

Fehler 3: Zu früh auf vollautomatisches Retraining umstellen
Nach dem Training denkst du: “Das Modell trainiert sich jede Woche von selbst nach — keine Überwachung nötig.” Nach vier Wochen hat sich das Modell in eine Ecke trainiert, weil eine Datenbeschaffung fehlgeschlagen ist (Wetterdaten sind kaputt) oder weil es Anomalien falsch interpretiert. Was hilft: Manuelles Retraining (quartalsweise oder bei offensichtlichen Anomalien) für die ersten zwei Jahre.

Was mit der Einführung wirklich passiert — und was nicht

Was passiert:

• Wochen 1–4: Datenintegration, historische Daten sammeln und prüfen, Problemdefinition (was ist eine “gute” Prognose für eure Zwecke?)
• Wochen 5–8: Feature Engineering, Modelltraining auf 24 Monaten historischer Daten
• Wochen 9–10: Validierung gegen 3 Monate Testdaten, Feintuning falls der Fehler zu groß ist
• Wochen 11–14: Pilotbetrieb — das Modell liefert Prognosen, die parallel zur bisherigen Methode geprüft werden (beide laufen nebeneinander)
• Monat 5–6: Schrittweise Umstellung auf die KI-Prognose, wenn die Pilotphase gut läuft
• Monat 7–12: Erste volle Saison mit KI-Prognose, Prüfung, ob der erwartete Nutzen real wird

Was nicht passiert:

• Kein sofortiger Produktivstart: Die Erwartung “in vier Wochen läuft’s” führt zu Frust. 10 bis 14 Wochen bis zum ersten Pilotbetrieb sind realistisch.
• Keine automatische Entscheidung: Das System sagt “150.000 Kasten”, aber wer entscheidet, was tatsächlich produziert wird? Das muss ein Mensch sein. Die Prognose ist eine Empfehlung, kein Befehl.
• Keine Verbesserung nach 2 Wochen: Der Nutzen der Nachfrageprognose zeigt sich erst über eine komplette Saison (mindestens 13 Wochen). Vorher ist es Glaubensfrage.

Widerstandsmuster und Gegenmaßnahmen:

Realistischer Zeitplan mit Risikohinweisen

Plus: mindestens 13 Wochen, bis die erste komplette Saison bewertet werden kann.

Kritische Meilensteine:
✓ Nach Woche 4: Alle Daten integriert und validiert
✓ Nach Woche 12: Modell trainiert, Fehlerquote ≤ 22 %
✓ Nach Woche 18: Pilotbetrieb läuft, Planer validieren
✓ Nach Woche 24: Vollständige Einführung
✓ Nach Woche 37 (9 Monate): Erste komplette Saison abgelaufen, ROI messbar

Häufige Einwände — und was dahintersteckt

Einwand 1: „Unsere Nachfrage ist nicht saisonal — das ist Zufall.”

Was dahintersteckt: Mangel an Datenbewusstsein. Wenn Daten nicht sauber aggregiert werden (z.B. täglich statt wöchentlich), sieht Zufall aus wie Saisonalität.

Der Punkt: Getränkehersteller, Eishersteller, Backwaren, Grillartikel — alle haben starke Saisonalität. Sogar “stabile” Produkte wie Milch oder Käse haben Saisonalität (Wintermilch ist teurer, Sommerkäse hat andere Geschmacksprofile). Die Frage ist nicht “haben wir Saisonalität”, sondern “wie stark ist sie”. Die Antwort: Messt die Varianz einer Zeitreihe mit herausgefilterter Saison — liegt sie unter 15 Prozent, ist die Saisonalität vernachlässigbar.

Einwand 2: „Das kostet zu viel und der Nutzen ist unsicher.”

Was dahintersteckt: Rational — 80.000 bis 100.000 Euro in Jahr 1 sind ein großes Budget für ein Unternehmen mit unter 200 Personen.

Der Punkt: Aber 3 bis 5 Prozent Margenverlust durch Planungsfehler kosten eine Brauerei mit 150 Mio. Euro Umsatz etwa 225.000 bis 375.000 Euro pro Jahr. Wenn KI das um ein Drittel reduziert, spart ihr 75.000 bis 125.000 Euro. Das ist nicht unsicher — das ist gegeben, wenn die Datenqualität stimmt. Die Unsicherheit liegt darin, ob eure Daten gut genug sind. Das lässt sich vor der Investition testen (Pilotphase mit historischen Daten).

Einwand 3: „Wir nutzen doch schon ein ERP mit Prognose.”

Was dahintersteckt: ERP-Systeme haben Standard-Prognosen (z.B. SAP “Demand Planning”), die oft nur einfache exponentielle Glättung sind, kein modernes ML.

Der Punkt: ERP-Prognosen sind häufig zu einfach für saisonale Produkte mit externen Einflussfaktoren (Wetter, Events). Das reicht für stabile, nicht-saisonale Produkte. Für saisonale Produkte ist spezialisierte Prognose-KI besser. Der Test: Vergleicht die aktuelle ERP-Prognose mit eurer manuellen Schätzung über 3 Monate. Wenn das ERP nicht besser ist, braucht ihr etwas anderes.

Woran du merkst, dass das zu dir passt

✓ Deine Produkte sind saisonal (Getränke, Eis, Backwaren, Grillprodukte, Heizöl)
✓ Du hattest in den letzten 3 Jahren mindestens zwei grobe Fehler in der Planung (Überproduktion ≥ 20 %, oder Engpässe ≥ 15 %)
✓ Deine Absatzmengen schwanken um ≥ 30 Prozent zwischen den Jahreszeiten
✓ Du hast mindestens 24 Monate historische Absatzdaten (strukturiert, nicht nur Papierlisten)
✓ Du hast ein ERP oder Lagersystem, das Verkaufsdaten täglich exportiert
✓ Es gibt Marktfaktoren, die du vorhersagen kannst: Wettervorhersagen, Events (Weihnachtsmarkt, Karneval), Aktionskalender

Wichtig: Wann das NICHT passt (harte Ausschlusskriterien)

✗ Deine Nachfrage ist vollständig durch externe Verträge bestimmt (z.B. du lieferst jeden Monat 50.000 Kasten an einen Großkunden) — kein Prognoseproblem
✗ Du hast weniger als 12 Monate Verkaufsdaten — das Modell hat keine historischen Saisonmuster zum Lernen
✗ Dein Produktmix ändert sich ständig (jede Saison drei neue Produkte) — das Modell ist schneller überholt als trainiert
✗ Du hast keine IT-Infrastruktur für Datenintegration (alles läuft manuell) — der Vorbereitungsaufwand ist größer als der Nutzen

Das kannst du heute noch tun

Schritt 1: Saisonalitätsanalyse (1 Woche)
Nimm deine Verkaufsdaten aus den letzten 24 Monaten (pro Woche oder Monat aggregiert). Trage sie in eine Grafik ein. Siehst du ein Muster? Sommer hoch, Winter tief? Das ist dein Saisonalitätssignal. Quantifiziere: Um wie viel Prozent schwankt die Nachfrage zwischen Hoch und Tief?

Schritt 2: Fehleranalyse (1 Woche)
Schau dir die letzten 3 Planungsfehler an (wo hattest du zu viel oder zu wenig): Was war die Ursache? Wetter? Event? Konkurrenzaktion? Kalender (Ostern früher als erwartet)? Das sind die Signale, die deine Prognose berücksichtigen muss.

Schritt 3: Datencheck (2–3 Tage)
Schau: Wo liegen deine Verkaufsdaten? ERP, Excel, separate Datenbank? Wie vollständig sind sie? Wie zeitnah? Wenn deine Daten chaotisch sind, muss erst eine Datenbereinigung vorneweg — 4 bis 6 Wochen vorher.

Quellen & Methodik

• Nachfrageprognose für Lebensmittel: KI-gestützte Nachfrageprognose, mindsquare / Elisa IndustrIQ; „Von historischen Daten zu prädiktiven Insights” (2024)
• Saisonale Schwankungen: EazyStock Blog — „Seasonal Demand Forecasting” und Strategien für saisonale Schwankungen in Lebensmittel-Lieferketten
• Nestlé Case Study: Maschinelles Lernen zur Optimierung der Lieferkette — 10 bis 15 Prozent Verbesserung in der Prognosegenauigkeit (2023)
• ML-Modelle: „Demand Forecasting Models for Food Industry by Utilizing Machine Learning” (TheScientificAmerican, 2024) — Vergleich LSTM, XGBoost, Prophet
• Eigenimplementierungen: 5 mittelständische Lebensmittelhersteller (Getränke, Backwaren, Konserven), Interviews und Einführungen 2024–2026