Blogartikel
Demand-Planning-Software: Was mittelständische Betriebe wirklich brauchen
Demand-Planning-Software gibt es in vielen Varianten, vom einfachen Excel-Ersatz bis zur vollintegrierten Planungssuite. Der Mittelstand braucht weder das eine noch das andere. Er braucht eine Lösung, die seinen Planungsprozess verbessert, ohne ein IT-Großprojekt zu werden. Dieser Artikel liefert fünf Auswahlkriterien, die SCM-Leiter und Geschäftsführer anwenden können, bevor sie in eine Evaluationsrunde gehen, ohne IT-Jargon und ohne Anbieterranking.
Drei Anbieter haben präsentiert, alle klingen überzeugend, und die Entscheidung fällt schwerer als vorher. Das ist die typische Situation, in der SCM-Leiter und Geschäftsführer im FMCG-Mittelstand stecken, wenn sie eine Demand Planning Software evaluieren. Die BVL-Trendstudie 2025/26 zeigt, dass die Softwareadoption im Mittelstand steigt, während die PWC Digital Supply Chain Survey 2025 als häufigste Hürde nicht die Technik nennt, sondern die unklare Anforderung. Genau hier liegt das Problem: Die Entscheidung ist keine Funktionsfrage, sondern eine Prozessfrage. Welches Planungsproblem soll die Software lösen, und ist die eigene Organisation bereit dafür? Dieser Artikel liefert fünf Auswahlkriterien, jedes mit konkreten Prüffragen, mit denen sich die Funktionen trennen lassen, die den Planungsprozess wirklich verbessern, von denen, die nur im Verkaufsgespräch gut klingen.
Was eine Demand-Planning-Lösung für den Mittelstand wirklich leisten muss
Eine Demand-Planning-Software ist eine spezialisierte Lösung, die den Prozess der Absatzprognose und Bedarfsplanung systematisiert, typischerweise über statistische Methoden, externe Datensignale und kollaborative Planungsfunktionen. Anders als ein integriertes ERP-Planungsmodul ist sie auf diese eine Aufgabe spezialisiert. Drei Kernfunktionen entscheiden darüber, ob eine Lösung den Planungsprozess tatsächlich verbessert oder nur digitalisiert, was vorher manuell falsch lief.
Kernfunktion 1: die Forecast Engine und ihre Methodenvielfalt
Die Forecast Engine ist die Kernkomponente, die auf Basis historischer Daten und externer Signale die Absatzprognose berechnet. Ihre Qualität entscheidet über den Wert der gesamten Lösung. Eine brauchbare Engine beherrscht mehrere statistische Methoden, von der exponentiellen Glättung über Holt-Winters bis ARIMA, ergänzt sie um maschinelles Lernen für Artikel mit hoher Variabilität und integriert externe Treiber wie Wetter, Promotions und Feiertage.
Die Abgrenzung ist einfach: Eine Engine, die nur historische Durchschnitte fortschreibt, ist kein Mehrwert gegenüber Excel, sie ist Excel mit anderer Oberfläche. Welche Prognosemethode zu welchem Nachfragemuster passt, behandelt der Artikel zu Absatzprognose-Methoden im Mittelstand. Die Fraunhofer-IML-Forschung zum Machine Learning in der Bedarfsplanung beschreibt die Methodenvielfalt als zentrales Qualitätsmerkmal.
Die Prüffrage: Welche Methoden wählt das System automatisch, und kann der Planer die Methodenwahl nachvollziehen oder übersteuern?
Kernfunktion 2: Erklärbarkeit, warum diese Prognose
Erklärbarkeit ist die Fähigkeit des Systems, für jede Prognose nachvollziehbar darzustellen, welche Faktoren zu welchem Wert geführt haben. Sie ist kein technisches Detail, sondern die Voraussetzung für Akzeptanz. Disponenten überschreiben Prognosen, die sie nicht verstehen, auch wenn diese richtig sind. Diese manuelle Überschreibung einer systemgenerierten Prognose durch den Planer heißt Forecast Override und ist kein Systemversagen, sondern ein legitimer Prozessschritt, solange sie bewusst erfolgt und dokumentiert wird. Problematisch wird sie erst, wenn sie zur Gewohnheit wird: Eine Lösung, deren Prognosen als Black Box erscheinen, erzeugt eine hohe Override-Rate aus Misstrauen statt aus besserem Wissen und verliert damit ihren Nutzen.
Die Mindestanforderung lautet: Der Planer sieht pro Artikel, welche Faktoren die Prognose beeinflusst haben, also Wetter, Aktion, Saisonindex und Trendkomponente. Diese Treiber-Ansicht macht aus einer Zahl eine nachvollziehbare Empfehlung und verwandelt einen reflexhaften Override in eine begründete Entscheidung. Wann sich Vertrauen in eine systemgenerierte Prognose lohnt und wann der manuelle Eingriff berechtigt ist, behandelt der Artikel zum Umgang mit Bestellvorschlägen.
Die Prüffrage: Kann der Planer für einen beliebigen Artikel nachvollziehen, warum das System diesen Wert prognostiziert hat?
Kernfunktion 3: ERP-Integration, Daten rein und raus
Eine Demand-Planning-Lösung braucht den bidirektionalen Datenaustausch mit dem ERP: Abverkaufsdaten und Lagerbestände werden gelesen, Prognosen und Bestellvorschläge zurückgeschrieben. Das minimale technische Anforderungsprofil umfasst eine API oder einen strukturierten Datei-Export, eine tägliche Synchronisierung und konsistente Mengeneinheiten zwischen beiden Systemen.
Die häufigste Fehlerquelle liegt nicht in der Software, sondern in den Stammdaten und Einheiten dahinter. Welche Fallstricke eine ERP-Anbindung verzögern und wie sich der Aufwand vorab klären lässt, behandelt der Artikel zur ERP-SCM-Schnittstelle. Die Frage an den Anbieter sollte konkret sein, nicht generisch.
Zwei technische Eigenschaften gehören in dieser Phase mitgeprüft, auch wenn sie selten im Verkaufsgespräch betont werden. Die erste ist die Skalierbarkeit, also die Fähigkeit der Software, mit wachsendem Sortiment, mehr Nutzern und komplexeren Anforderungen umzugehen, ohne dass die Prognosequalität oder die Geschwindigkeit leidet. Sie ist ein Argument für die Zukunftssicherheit: Eine Lösung, die heute für 3.000 Artikel passt, sollte auch bei 10.000 nicht an eine Grenze stoßen. Die zweite ist die Betriebsart. Bei On-Premise läuft die Software auf den eigenen Servern des Betriebs, bei Cloud auf den Servern des Anbieters mit Zugriff über den Browser. Für Betriebe mit besonderen Anforderungen an Datenschutz oder Datenhoheit ist diese Unterscheidung relevant und sollte früh geklärt werden, weil sie den Integrations- und Wartungsaufwand spürbar beeinflusst.
Die Prüffrage: Welche ERP-Systeme hat der Anbieter bereits angebunden, und was ist der Integrationsaufwand für Ihr konkretes System?
Was Demand-Planning-Software nicht sein muss und welche Funktionen oft überschätzt werden
Im Verkaufsgespräch klingen viele Funktionen überzeugend. Im Betrieb zeigt sich, welche den Planungsprozess wirklich verbessern und welche nur Implementierungsaufwand erzeugen, ohne genutzten Mehrwert. Drei Punkte verdienen besondere Aufmerksamkeit.
Überschätzte Funktion 1: Szenarioplanung ohne S&OP-Prozess
Szenarioplanung, also das Durchrechnen alternativer Nachfrageverläufe, ist ein mächtiges Werkzeug, aber nur, wenn ein Prozess existiert, der die Szenarien bewertet und in Entscheidungen übersetzt. Dieser Prozess ist S&OP, das Sales & Operations Planning. Ohne ihn werden Szenarien berechnet, aber nicht genutzt, ein Feature ohne Wirkung.
Die sinnvolle Reihenfolge ist deshalb umgekehrt zur Verkaufslogik: erst den Abstimmungsprozess etablieren, dann die Szenariofunktion evaluieren. Wie sich ein S&OP-Prozess im Mittelstand ohne Großkonzern-Aufwand einführen lässt, behandelt der Artikel zu S&OP im Mittelstand.
Überschätzte Funktion 2: IBP-Fähigkeiten ohne Prozessreife
Viele Lösungen bewerben Funktionen für Integrated Business Planning (IBP), also die vollständige Integration von Absatz-, Finanz- und Kapazitätsplanung. Im Mittelstand ohne eigene Planungsabteilung erzeugen diese Fähigkeiten Implementierungsaufwand, der nicht durch Planungsnutzen gedeckt ist.
Das Entscheidungskriterium ist die Prozessreife. Wenn Demand Planning und S&OP noch nicht etabliert sind, ist IBP verfrüht. Eine Software kann keine Planungsreife ersetzen, sie kann nur eine vorhandene unterstützen. Was Demand Planning als Prozess überhaupt voraussetzt, behandelt der Artikel zu Demand Planning im Mittelstand.
Unterschätzte Anforderung: Time-to-Value und Implementierungsrealismus
Time-to-Value bezeichnet die Zeitspanne vom Vertragsabschluss bis zum ersten messbaren Planungsnutzen. Sie wird im Verkaufsgespräch oft beschönigt, ist aber im Mittelstand das kritischste Kriterium, besonders gegenüber langwierigen ERP-Projekten. Als Orientierungswert, keine Garantie, sind 8 bis 16 Wochen realistisch, sofern die Datenbasis sauber und IT-Kapazität verfügbar ist. Schlechte Daten, parallele IT-Projekte oder fehlende interne Kapazität verlängern diesen Zeitraum erheblich.
Die ehrliche Time-to-Value ist eine mit expliziten Annahmen. Ein Anbieter, der einen Zeitwert nennt, ohne nach der Datenqualität und der IT-Kapazität zu fragen, beschreibt einen Idealfall, nicht den eigenen.
Die Prüffrage: Was ist die realistische Time-to-Value, mit welchen ausgesprochenen Annahmen über Datenbasis und IT-Kapazität?
Demand-Planning-Software evaluieren: fünf Fragen vor der Entscheidung
Die Entscheidung für eine Lösung beginnt nicht im Verkaufsgespräch, sondern mit fünf Fragen an den eigenen Planungsprozess. Wer sie beantwortet, bevor er die erste Demo ansieht, evaluiert mit einem Maßstab statt mit einem Bauchgefühl.
Frage 1: Welches Planungsproblem soll die Software lösen?
Vor jeder Evaluierung steht die konkrete Problembeschreibung. Ist die Override-Rate zu hoch? Bindet die manuelle Planung zu viel Zeit? Sind die Saisonprognosen schlecht? Fehlen externe Signale wie Wetter oder Promotions? Ohne eine klare Antwort klingt jede Software gut, weil es keinen Maßstab gibt, an dem sie scheitern könnte.
Die Prüffrage: Können Sie das Planungsproblem, das Sie lösen wollen, in zwei Sätzen beschreiben, ohne Softwarebegriffe zu verwenden?
Frage 2: Ist die eigene Datenbasis bereit?
Jede Demand-Planning-Software ist nur so gut wie die Daten, mit denen sie arbeitet. Die Mindestanforderung sind 24 Monate bereinigte Absatzhistorie für die A-Artikel, mit gekennzeichneten Stockouts und Promotions und einem aktuellen Artikelstamm. Wer Software kauft, bevor die Daten sauber sind, zahlt für eine Lösung, die auf verzerrter Grundlage rechnet.
Die Datenbasis ist damit kein technisches Vorgeplänkel, sondern die Voraussetzung jeder sinnvollen Evaluierung. Welche Rolle die Datenqualität für KI-gestützte Prognosen spielt, behandelt der Artikel zur Datenbasis für KI-Absatzprognosen.
Frage 3: Welche ERP-Systeme müssen angebunden werden, und mit welchem Aufwand?
Die technische Anforderung gehört konkret formuliert, bevor das erste Anbietergespräch stattfindet: welches ERP, welche Datenfelder, welcher Synchronisierungsrhythmus. Mit dieser Präzision lässt sich ein Anbieter belastbar einschätzen, eine generische Integrationsfrage dagegen führt zu einer generischen Antwort. Hilfreich ist es, vom Anbieter nicht nur die Liste der grundsätzlich unterstützten ERP-Systeme zu verlangen, sondern den konkreten Aufwand für das eigene System, idealerweise belegt durch eine vergleichbare Referenzanbindung. Der Artikel zur ERP-SCM-Schnittstelle beschreibt, welche Angaben dafür nötig sind und warum der Aufwand selten in der Schnittstelle selbst, sondern in den Daten dahinter liegt.
Die Prüffrage: Ist dokumentiert, welches ERP mit welchen Datenfeldern in welchem Rhythmus angebunden werden muss, bevor Sie den ersten Anbieter ansprechen?
Frage 4: Wer nutzt die Software, und ist die Organisation bereit?
Das Änderungsmanagement ist der am häufigsten unterschätzte Faktor. Eine Software entfaltet nur dann Wirkung, wenn die Disponenten ihr vertrauen und ein Prozess die Prognosen tatsächlich nutzt. Fehlt die Veränderungsbereitschaft, wird die Lösung eingeführt, aber die Override-Rate bleibt hoch, und der erhoffte Nutzen tritt nicht ein. Die kollaborative Planung, also die Funktion, mit der mehrere Rollen gemeinsam auf einer Prognose arbeiten, hilft nur, wenn diese Rollen den Prozess auch leben.
Die Prüffrage: Wer im Betrieb wird die Software täglich nutzen, und wurden diese Personen in die Evaluierung einbezogen?
Frage 5: Was ist die realistische Time-to-Value?
Die fünfte Frage schließt den Kreis zur Implementierung. Der Orientierungswert von 8 bis 16 Wochen gilt unter optimalen Bedingungen und verlängert sich bei schlechter Datenbasis, parallelen IT-Projekten oder fehlender interner Kapazität. Statt sich auf eine genannte Zahl zu verlassen, lohnt die Frage nach Referenzimplementierungen mit vergleichbarer Betriebsgröße und gleichem ERP-System. Die BCG-Studie Supply Chain Planning 2026 betont, dass die Systemwahl zur Prozessreife passen muss und ein schneller, messbarer Nutzen das tragfähigere Kriterium ist als der Funktionsumfang.
Die richtige Frage schlägt die längste Funktionsliste
Demand-Planning-Software kauft man nicht für Funktionen, sondern für das, was sie im eigenen Planungsprozess verändert. Wer das nicht klärt, kauft Features, die er nicht nutzt, und unterschätzt den Aufwand, den er tatsächlich trägt. Die fünf Fragen verschieben den Blick von der Software zurück auf den eigenen Prozess, und genau dort fällt die Entscheidung.
Drei Sofortschritte lohnen sich vor jedem Anbietergespräch. Erstens das Planungsproblem in zwei Sätzen beschreiben, ohne Softwarebegriffe. Zweitens den Datenbasis-Check durchführen: Sind 24 Monate bereinigte Absatzhistorie für die A-Artikel vorhanden? Drittens die ERP-Anforderungen definieren, also welches System, welche Datenfelder und welcher Rhythmus, bevor das erste Gespräch stattfindet.
Wer mit einem klaren Problembild, einer sauberen Datenbasis und definierten ERP-Anforderungen in die Evaluierung geht, braucht keine Produktmatrix. Er braucht drei Demos und die richtigen Fragen. Die Software, die danach übrig bleibt, ist nicht die mit den meisten Funktionen, sondern die, die das eigene Problem löst.
Weiterführende Quellen
Fraunhofer IML: Potenziale des Machine Learning in der Bedarfsplanung
BVL (2025): Trends und Strategien in Logistik und Supply Chain Management 2025/26
BCG (2026): Supply Chain Planning 2026: Why AI Alone Isn't Enough
FAQ
Was ist Demand-Planning-Software, und was unterscheidet sie vom ERP-Planungsmodul?
Demand-Planning-Software ist eine spezialisierte Lösung, die den Prozess der Absatzprognose und Bedarfsplanung systematisiert, über statistische Methoden, externe Datensignale und kollaborative Funktionen. Der Unterschied zum ERP-Planungsmodul liegt in der Spezialisierung: Das ERP-Modul ist in ein großes Gesamtsystem integriert und für stabile Nachfrage mit hinterlegten Parametern ausgelegt. Eine Demand-Planning-Lösung ist auf die Prognose spezialisiert und beherrscht meist mehrere Methoden, maschinelles Lernen und die Integration externer Treiber. Für FMCG-Sortimente mit Saisonalität und Aktionseinfluss ist diese Spezialisierung oft der entscheidende Unterschied.
Was ist eine Forecast Engine, und woran erkenne ich eine gute?
Die Forecast Engine ist die Kernkomponente, die aus historischen Daten und externen Signalen die Absatzprognose berechnet. Eine gute Engine erkennt man an drei Merkmalen: Sie beherrscht mehrere statistische Methoden und wählt sie passend zum Nachfragemuster aus, sie ergänzt diese um maschinelles Lernen für Artikel mit hoher Variabilität, und sie integriert externe Treiber wie Wetter, Promotions und Feiertage. Das wichtigste Ausschlusskriterium: Eine Engine, die nur historische Durchschnitte fortschreibt, bietet keinen Mehrwert gegenüber einer gut gepflegten Excel-Tabelle.
Was ist Erklärbarkeit in Demand-Planning-Software, und warum ist sie wichtig?
Erklärbarkeit ist die Fähigkeit des Systems, für jede Prognose nachvollziehbar zu machen, welche Faktoren zu welchem Wert geführt haben, etwa Wetter, Aktion, Saisonindex oder Trend. Sie ist wichtig, weil sie über die Akzeptanz beim Disponenten entscheidet. Eine Prognose, die als Black Box erscheint, wird überschrieben, auch wenn sie richtig ist. Damit verliert die Software ihren Nutzen, und die Override-Rate bleibt hoch. Die Mindestanforderung ist eine Treiber-Ansicht pro Artikel, die aus einer reinen Zahl eine nachvollziehbare Empfehlung macht.
Was ist Time-to-Value, und wie realistisch sind die Versprechen der Anbieter?
Time-to-Value ist die Zeitspanne vom Vertragsabschluss bis zum ersten messbaren Planungsnutzen. Als Orientierungswert sind 8 bis 16 Wochen realistisch, allerdings nur bei sauberer Datenbasis und verfügbarer IT-Kapazität. Anbieterversprechen sind dann belastbar, wenn sie mit expliziten Annahmen verbunden sind. Ein genannter Zeitwert ohne Rückfrage zur Datenqualität und IT-Kapazität beschreibt einen Idealfall, nicht die konkrete Situation. Die verlässlichste Einschätzung liefert die Frage nach Referenzimplementierungen mit vergleichbarer Betriebsgröße und gleichem ERP-System.
Welche Datenbasis brauche ich, bevor ich Demand-Planning-Software einführe?
Die Mindestanforderung sind 24 Monate bereinigte Absatzhistorie für die A-Artikel. Bereinigt bedeutet: Stockout-Perioden sind als solche gekennzeichnet und erscheinen nicht als Nullnachfrage, Promotionszeiträume sind markiert, und der Artikelstamm ist aktuell. Ohne diese Grundlage rechnet auch die beste Software auf verzerrten Daten und liefert systematisch falsche Prognosen. Die Datenbereinigung ist deshalb kein nachgelagerter Schritt, sondern die Voraussetzung jeder sinnvollen Einführung. Wer die Daten erst nach dem Kauf bereinigt, zahlt für eine Lösung, die er noch nicht nutzen kann.
Was ist der Unterschied zwischen Demand Planning und IBP?
Demand Planning ist die strukturierte Vorausschätzung der Kundennachfrage. Integrated Business Planning (IBP) geht weiter und integriert die Absatzplanung mit der Finanz- und Kapazitätsplanung zu einem gemeinsamen Prozess. IBP ist mächtig, aber anspruchsvoll in der Einführung und setzt eine hohe Prozessreife voraus. Im Mittelstand ohne eigene Planungsabteilung erzeugen IBP-Funktionen meist Implementierungsaufwand, der nicht durch Nutzen gedeckt ist. Solange Demand Planning und S&OP nicht etabliert sind, ist IBP verfrüht. Die sinnvolle Reihenfolge ist Prozess zuerst, dann die passende Werkzeugtiefe.
Wie erkenne ich im Verkaufsgespräch, ob eine Lösung für meinen Betrieb passt?
Indem Sie mit konkreten eigenen Anforderungen ins Gespräch gehen statt mit offenen Fragen. Beschreiben Sie Ihr Planungsproblem in zwei Sätzen ohne Softwarebegriffe, nennen Sie Ihr ERP-System und die anzubindenden Datenfelder, und fragen Sie nach Referenzimplementierungen Ihrer Größenordnung. Eine passende Lösung lässt sich an konkreten Antworten erkennen, eine unpassende an generischen. Bitten Sie außerdem darum, die Erklärbarkeit an einem Ihrer eigenen Artikel zu sehen, nicht an einem Demo-Datensatz. Wer mit klarem Problembild, sauberer Datenbasis und definierten ERP-Anforderungen ins Gespräch geht, braucht keine Produktmatrix, sondern drei Demos und die richtigen Fragen.
