Welche Daten braucht Demand Forecasting wirklich?

Welche Daten braucht Demand Forecasting wirklich?

Demand Forecasting braucht im Kern historische Abverkäufe und Auftragseingänge; Saisonalität und Preisaktionen können als zusätzliche Einflüsse einbezogen werden. Aus diesen Daten wird erwarteter Bedarf abgeleitet, um Einkauf, Produktion und Bestände auszurichten. Ein Forecast ist dabei eine Planungsgrundlage, keine sichere Vorhersage der Zukunft.

Das Wichtigste in Kürze

• Historische Abverkäufe und Auftragseingänge bilden den Datenkern eines Demand Forecasts.
• Saisonalität und Preisaktionen können berücksichtigt werden, wenn ihr Bezug zur Datenreihe nachvollziehbar ist.
• Die Datensicht sollte zur konkreten Planungsentscheidung passen.
• Das konkrete Planungsproblem bestimmt, welche Daten zuerst geprüft werden.
• Ein Forecast macht Unsicherheit planbar, hebt sie aber nicht auf.

Die datenbasierte Prognose künftiger Nachfrage analysiert historische Abverkäufe und Auftragseingänge und kann Saisonalität oder Preisaktionen berücksichtigen. Daraus lässt sich erwarteter Bedarf für Einkauf, Produktion und Bestände ableiten.

Für Shopify- und DTC-Marken beginne ich in meiner Praxis mit der Frage, welche Datenreihe für die anstehende Entscheidung relevant ist. Ich grenze dafür Produkt, Kanal, Zeitraum und Planungszweck ab. Fehlt diese Zuordnung, behandle ich die Aussagekraft der Reihe vorsichtig, statt daraus eine präzise operative Ableitung zu machen.

Abverkäufe und Auftragseingänge prüfe ich getrennt, wenn beide Reihen dieselbe Einkaufs- oder Bestandsentscheidung beeinflussen könnten und nicht klar ist, ob ein Auftrag bereits in den Abverkäufen enthalten ist. In meiner praktischen Prüfung ist eine ungeklärte Mischung der Reihen ein Anlass, mögliche Doppelzählungen zu klären. Welche Geschäftsvorfälle die jeweilige Reihe umfasst, dokumentiere ich deshalb für den konkreten Anwendungsfall, statt eine allgemeingültige Definition vorauszusetzen.

Saisonalität und Preisaktionen beziehe ich nur ein, wenn ihr Bezug zu Produkt und Zeitraum nachvollziehbar ist. Sind diese Einflüsse nicht zuordenbar, halte ich die daraus entstehende Unsicherheit fest. Mein belastbarer Start bleibt klein: klar abgegrenzte Kernreihen und eine benannte Planungsentscheidung.

Welches Planungsproblem sollen Ihre Daten zuerst lösen?

Forecasting-Daten müssen zuerst dem Planungsproblem zugeordnet werden: Absatzprognose, Bestandssteuerung, Einkauf, Replenishment, PO-Management und Planung über mehrere Märkte verlangen unterschiedliche Datensichten. Teams sollten daher vor jeder Systementscheidung festlegen, welche operative Entscheidung vorbereitet wird und welche Produkt-, Kanal-, Lagerort- und Stammdaten dafür zusammengeführt werden müssen.

Das ist der Punkt, an dem viele Teams zu früh über Software sprechen. Eine Absatzprognose beantwortet etwa die Frage nach erwarteter Nachfrage je Produkt und Zeitraum. Bestandssteuerung braucht zusätzlich eine Sicht darauf, wo Ware liegt. Einkauf und PO-Management benötigen eine Planung, die zu den jeweiligen operativen Abläufen passt. Internationale Märkte, D2C und B2B bringen weitere Unterschiede bei Checkout-Regeln und Prozessen mit.

Die konkrete Datenarchitektur für Planung verbindet dafür Produktdaten, Lagerorte, ERP-Stammdaten, Verkaufskanäle, Checkout-Logik, Zahlungsbedingungen und Rollenrechte. Erst wenn diese Bausteine zum Geschäftsmodell passen, lohnt sich der Vergleich von Funktionen, Integrationen und Preislogik.

Ich würde die Prüfung als Entscheidungspfad aufsetzen. Erstens: Welche Entscheidung verursacht heute Reibung, etwa ein Reorder für einen Artikel oder die Verteilung auf Lagerorte? Zweitens: Auf welcher Granularität fällt diese Entscheidung, also Produkt, Variante, Kanal oder Markt? Drittens: Welche Quelle liefert für diese Granularität die maßgebliche Information? Viertens: Wer darf die Annahmen ändern und die Bestellung freigeben?

Ein hartes Ausschlusskriterium liegt vor, wenn Produktdaten und Lagerorte nicht verlässlich zusammengeführt werden können, die Entscheidung aber eine lagerortspezifische Steuerung verlangt. Dann ist ein gemeinsamer Forecast für diese Aufgabe ungeeignet. Unterschiedliche Darstellungswünsche im Reporting sind dagegen Präferenzen: Sie verändern die Arbeitsweise, verhindern aber nicht zwingend eine fachlich nutzbare Planung.

Jannik Semmelhaack, Founder & CEO von VOIDS, formulierte am 14. August 2026 seine Haltung zum Wechsel von Intuition zu dokumentierten Planungsentscheidungen so:

"Das ist der Unterschied, wenn du aufhörst, nach Bauchgefühl zu bestellen."

— Jannik Semmelhaack, Founder & CEO, VOIDS – AI-driven Demand Planning · Quelle

Die Aussage ersetzt keine Datenprüfung. Sie beschreibt aber den praktischen Anspruch: Eine Bestellung braucht nachvollziehbare Eingaben, eine benannte Annahme und eine Person, die die Entscheidung verantwortet. Genau dort wird aus einer Prognosekurve operative Planung.

So läuft der Ablauf von Daten zu einem Demand Forecast

In meiner Einkaufs- und Bestandsplanung beginne ich mit historischen Abverkäufen und Auftragseingängen. Saisonalität oder Preisaktionen beziehe ich ein, wenn sie der betrachteten Datenreihe zugeordnet werden können. Daraus leite ich erwarteten Bedarf ab, an dem ich Einkauf, Produktion und Bestände ausrichte.

Zuerst grenze ich die Datenreihe ab: Ich lege fest, welches Produkt, welcher Kanal, welcher Zeitraum und welcher Planungszweck betrachtet werden. So behandle ich etwa eine Aktion auf Kanalebene nicht automatisch als allgemeinen Produkttrend. Die Abgrenzung gibt mir zugleich eine Grundlage, spätere Anpassungen nachzuvollziehen.

Danach analysiere ich historische Abverkäufe und Auftragseingänge. Saisonalität und Preisaktionen berücksichtige ich nur, wenn ihr Bezug zu Produkt und Zeitraum dokumentiert ist. Ich arbeite dabei bewusst in dieser Reihenfolge: erst die vorhandenen Daten verständlich machen, dann die erwartete Nachfrage ableiten.

Im nächsten Schritt überführe ich die Prognose in die operative Planung. Für den Einkauf prüfe ich, welcher erwartete Bedarf in eine Bestellung einfließen soll. Für Bestände prüfe ich, welche Mengen für die jeweilige Planung relevant sind. Ohne diese Anschlussfrage bleibt ein Forecast für mich Analyse statt Vorbereitung einer Handlung.

Abschließend nutze ich die Nachfrageprognose als Planungsgrundlage für Einkauf, Produktion oder Bestand. Sie ersetzt keine Freigabeentscheidung. Wenn Preisaktionen oder neue Marktprozesse die Vergleichbarkeit einschränken, dokumentiere ich die Annahme, den Zeitpunkt und die verantwortliche Person.

Ich springe nicht von einer aggregierten Nachfragezahl direkt zur Bestellung. Erfolgt die Bestellung auf Varianten- oder Lagerortebene, prüfe ich, ob die Datensicht diese Ebene unterstützt. Andernfalls behandle ich die Zahl nur als groben Überblick, nicht als präzise Antwort auf die operative Frage.

Beispiele: Welche Datenkombination passt zu welcher Forecasting-Frage?

Sinnvolle Datenkombinationen richten sich nach der jeweiligen Forecasting-Frage: Für eine Absatzprognose genügen historische Abverkäufe und Auftragseingänge als Kern. Für saisonale oder aktionsbezogene Planung müssen Saisonalität beziehungsweise Preisaktionen eindeutig ergänzt werden. Bestands- und Einkaufsfragen benötigen darüber hinaus konsistente Produkt-, Lagerort-, ERP- und Verkaufskanaldaten.

Beispiel 1: Erwartete Nachfrage eines Artikels planen

Ein Team möchte die erwartete Nachfrage eines Artikels für einen kommenden Zeitraum einschätzen. Es startet mit historischen Abverkäufen und Auftragseingängen, getrennt nach dem Verkaufskanal, der geplant werden soll. Diese Kombination ist passend, weil sie direkt zur Absatzprognose führt. Werden Kanäle zusammengefasst, obwohl sie unterschiedlich geplant werden, verliert das Team die Grundlage für eine kanalbezogene Entscheidung.

Beispiel 2: Eine Preisaktion im Datenverlauf einordnen

Bei einer Preisaktion ergänzt das Team die Absatz- und Auftragsdaten um die klar gekennzeichnete Aktion und ihren Zeitraum. Der Zweck ist nicht, aus einem einzelnen Ausschlag eine dauerhafte Nachfrageannahme abzuleiten. Der Zweck ist, den Ausschlag bei der Planung als besonderen Einfluss sichtbar zu halten. Fehlt die Zuordnung, sollte die Aktion nicht stillschweigend wie ein normaler Vergleichswert behandelt werden.

Beispiel 3: Einkauf oder Bestand über mehrere Datenquellen steuern

Für eine Einkaufs- oder Bestandsfrage reichen Produktverkäufe allein nicht aus, wenn die operative Entscheidung einen Lagerort oder ERP-Stammdaten betrifft. Dann müssen Produktdaten, Lagerorte, ERP-Stammdaten und Verkaufskanäle konsistent zusammenarbeiten. Auch Checkout-Logik, Zahlungsbedingungen und Rollenrechte können für die Architektur relevant sein, wenn diese Prozesse Teil des Geschäftsmodells sind.

Die Zuordnung von Planungsproblem und Datenarchitektur hilft, diese Fälle auseinanderzuhalten. D2C, B2B und internationale Märkte folgen nicht automatisch derselben Datenlogik. Eine Datenkombination ist deshalb ungeeignet, wenn sie eine erforderliche operative Dimension ausblendet. Sie ist nicht deshalb falsch, weil sie weniger Kennzahlen enthält.

Für die Nachfragebasis bleiben Abverkäufe, Auftragseingänge, Saisonalität und Preisaktionen die benannten Kategorien. Zusätzliche Datenfelder sollten Teams erst aufnehmen, wenn sie eine konkrete Planungsfrage klären und zuverlässig zugeordnet werden können.

Mini-Studie: Welche Suchdaten wurden ausgewertet?

Die Mini-Studie umfasst Google-Search-Console-Leistungsdaten dieser Organisation (gsc_performance) im Zeitraum 2026-06-05/2026-09-02. Ausgezählt wurden alle 14247 Query-/Seiten-Zeilen mit Datum zwischen diesen beiden Tagen, ohne Gewichtung und ohne Hochrechnung über das Fenster hinaus. Die Auswertung dokumentiert ausschließlich diese Datengrundlage und dieses Zeitfenster.

Die Tabelle hält die beschreibenden Eckdaten fest. Sie enthält keine Aussage darüber, wie sich Suchverhalten vor dem 5. Juni 2026 oder nach dem 2. September 2026 entwickelt hat. Ebenso lässt sich aus der Zeilenzahl keine Ursache für eine Suche oder eine spätere Geschäftsentscheidung ableiten.

Für die praktische Datenarbeit ist die Einschränkung selbst nützlich: Ein Datenausschnitt wird erst durch Datensatz, Zeitfenster, Methode und Stichprobe prüfbar. Dieselbe Disziplin sollte auch für operative Forecasting-Daten gelten. Wer eine Zahl in eine Bestellentscheidung übernimmt, sollte Herkunft, Zeitraum und Aggregation benennen können.

Risiken und Grenzen von Forecasting-Daten richtig einordnen

Forecasting ist begrenzt, wenn die Datenarchitektur nicht zum Planungsproblem passt oder die für die Entscheidung relevanten Datenbereiche nicht konsistent zusammenarbeiten. Ein Forecast bleibt eine Planungsgrundlage und ersetzt weder die Prüfung der Datenarchitektur noch die Verantwortung für Einkaufs- und Bestandsentscheidungen.

Die erste Grenze liegt in der Passung zur Entscheidung. Vor Funktionen, Integrationen oder Preislogik sollte geklärt sein, ob Absatzprognose, Bestandssteuerung, Einkauf, Replenishment, PO-Management oder die Planung über mehrere Märkte unterstützt werden soll. Erst danach lässt sich beurteilen, welche Datensicht erforderlich ist.

Die zweite Grenze ist die Konsistenz der Datenarchitektur. Für Commerce-, E-Commerce- und Operations-Teams können Produktdaten, Lagerorte, ERP-Stammdaten, Verkaufskanäle, Checkout-Logik, Zahlungsbedingungen und Rollenrechte relevant sein. Die Prüfung der Datenarchitektur steht deshalb vor der Bewertung von Funktionen und Integrationen.

Mehrere Geschäftsmodelle und Märkte können unterschiedliche Datenlogiken, Checkout-Regeln und operative Prozesse haben. Wenn diese Unterschiede für die Planungsentscheidung relevant sind, sollte die Architektur sie konsistent abbilden. Andernfalls ist vor einer zusammengeführten Planung zu klären, welche Entscheidung mit der vorhandenen Datensicht tatsächlich unterstützt werden kann.

Auch beim KI-gestützten Demand Forecasting in Lieferketten bleibt Forecasting eine Planungsgrundlage und ersetzt weder die Prüfung der Datenarchitektur noch die Verantwortung für Einkaufs- und Bestandsentscheidungen.

FAQ: Welche Grenzen hat Demand Forecasting?

Wenn Sie Preisangaben von VOIDS prüfen möchten, finden Sie diese auf der Pricing-Seite von VOIDS. Zuvor sollten Sie das eigene Planungsproblem und die dafür relevanten Datenbereiche benennen.