Warum Forecasting in der Frischeproduktion an der Disposition scheitert, nicht am Modell
WISSEN / 03
Ein technisch sauberes Modell ist noch kein laufendes System. Über die Lücke zwischen Theorie-WAPE und IST-WAPE — und warum der Disponenten-Override ein Trainings-Signal ist, kein Fehler.
Wenn ein Forecasting-Projekt scheitert, sucht man den Fehler meist im Modell. Hat es die richtigen Daten? Den passenden Algorithmus? Genug Historie? Diese Fragen sind berechtigt — aber sie treffen selten den wahren Grund. In der Praxis scheitert Bedarfsforecasting in der Frischeproduktion fast nie an der Mathematik. Es scheitert daran, dass die fertigen Prognosen im Tagesgeschäft nicht ankommen.
Das Modell rechnet — und im Tagesgeschäft passiert nichts
Der typische Verlauf eines technisch sauber aufgesetzten Projekts ist ernüchternd. Das Modell läuft, die Prognosen liegen pünktlich vor, die Werte sind präzise — und in der Disposition ändert sich nichts. Die Vorschläge werden zur Kenntnis genommen und dann beiseitegelegt. Geplant wird weiter wie zuvor, aus Erfahrung und Bauchgefühl.
Das ist kein Zeichen von Sturheit, sondern eine rationale Reaktion. Ein Disponent trägt die Verantwortung dafür, dass das Lager nicht überläuft und nichts ausgeht. Solange er einem neuen System nicht vertraut, wäre es fahrlässig, seine bewährte Praxis dafür aufzugeben. Genau hier liegt der entscheidende Punkt, den technikgetriebene Projekte übersehen: Eine erfolgreiche Implementierung endet nicht, wenn das Modell rechnet. Sie endet, wenn der Disponent dem Werkzeug so weit vertraut, dass er danach handelt. Alles davor ist Aufwand ohne Wirkung.
Theorie und Praxis sind zwei verschiedene Zahlen
Aus dieser Lücke folgt eine Unterscheidung, die in den seltensten Reportings auftaucht, aber für ein ehrliches Bild unverzichtbar ist: die zwischen der theoretischen und der tatsächlichen Prognosegüte.
Die theoretische Güte misst, wie gut die vom System ausgegebenen Forecasts sind — die Zahlen, wie sie das Modell liefert. Die tatsächliche Güte misst, was am Ende wirklich disponiert wurde, nachdem der Disponent die Vorschläge geprüft und an vielen Stellen angepasst hat. In der Praxis liegt die tatsächliche Güte fast immer schlechter als die theoretische, weil nicht jeder Vorschlag unverändert übernommen wird.
Es ist verlockend, diese Differenz zu verstecken und nur die schönere theoretische Zahl zu zeigen. Das wäre ein Fehler. Die Differenz ist kein Defekt, den man kaschieren müsste — sie ist die Realität des Betriebs, und sie ist die eigentlich interessante Information. Denn sie sagt genau, wie weit das System und die Menschen, die es bedienen, noch auseinanderliegen. Wer nur die theoretische Zahl betrachtet, optimiert ein Modell, das niemand benutzt.
Der Override ist ein Signal, kein Rauschen
Damit zur entscheidenden Frage: Was tut man mit den Stellen, an denen der Disponent die Prognose überschreibt? Die naheliegende, technisch gedachte Antwort wäre, härter auf die Modell-Outputs zu pochen — das System hat schließlich recht gerechnet. Diese Antwort ist falsch.
Ein Disponent überschreibt einen Vorschlag selten aus Willkür. Er tut es, weil er etwas weiß, das das Modell nicht weiß: dass ein Großkunde nächste Woche eine Aktion fährt, dass eine Sorte ausläuft, dass das letzte Mal bei ähnlicher Wetterlage die Nachfrage einbrach. Dieses Kontextwissen ist genau das, was in keiner Verkaufshistorie steht. Der Override ist deshalb kein Störsignal, das man unterdrücken sollte — er ist die wertvollste Rückmeldung, die das System bekommen kann.
Der richtige Umgang damit kehrt die übliche Logik um: Statt die Eingriffe des Disponenten als Abweichung zu behandeln, die es zu minimieren gilt, wertet man sie systematisch aus. Wo wird häufig überschrieben, und warum? Welches Wissen steckt dahinter, und lässt es sich ins Modell überführen? So wird aus jedem Eingriff ein Lernschritt, und das System nähert sich Woche für Woche der Realität an — nicht, indem es den Menschen verdrängt, sondern indem es von ihm lernt.
Was daraus für die Einführung folgt
Wenn der eigentliche Engpass nicht das Modell ist, sondern das Vertrauen und die Zusammenarbeit, dann verschiebt sich, worauf es bei der Einführung ankommt. Die Übergabe, die Schulung und die laufende Begleitung sind dann nicht Beiwerk, das man nach dem technischen Aufbau noch obendrauf legt — sie sind der Teil, der über Erfolg oder Misserfolg entscheidet.
Das Ziel ist nie, den Disponenten zu ersetzen. Es ist, ihm ein Werkzeug zu geben, das ihm die mechanische Routinearbeit abnimmt, damit er seine Erfahrung für die Entscheidungen einsetzen kann, die kein Algorithmus trifft. Ein gutes System macht den Disponenten schlagkräftiger, nicht überflüssig. Genau dann wird aus einem rechnenden Modell ein laufendes System — eines, dem im Tagesgeschäft tatsächlich gefolgt wird.
Wie dieser Weg in einem realen Projekt über vier Jahre verlaufen ist — vom anfänglichen Misstrauen bis zur gemeinsamen Weiterentwicklung — beschreibt die Case Study. Die Grundlagen zur Messung selbst stehen im Beitrag zur Dispoqualität.