Blogartikel

Wann Bestellvorschlägen vertrauen, und wann besser selbst entscheiden

Bestellvorschläge sparen Zeit, solange man weiß, wann man ihnen vertrauen kann. Wer pauschal freigibt, riskiert Fehlbestellungen. Wer jeden Vorschlag manuell prüft, verliert den Effizienzgewinn. Die Antwort liegt dazwischen: Ein strukturiertes Urteilsvermögen für die Fälle, die wirklich Aufmerksamkeit brauchen. Dieser Artikel zeigt vier Vertrauens-Dimensionen und vier Warnsignale, die manuellen Eingriff erfordern, und das Prinzip, das beides verbindet.

Wer in der Disposition täglich mit Bestellvorschlägen arbeitet, kennt die Grundfrage: Freigeben oder anpassen? Für eine einzige Bestellung ist diese Frage leicht zu beantworten. Bei zwanzig Vorschlägen bis Mittag ist sie es nicht mehr. Weder blindes Vertrauen noch pauschales Misstrauen ist die richtige Haltung. BCG (2026) stellt in der Supply-Chain-Planungsstudie fest, dass Unternehmen, die Planungssysteme ohne ausreichende Prozessreife einsetzen, keinen Nutzen aus ihrer Technologie ziehen, weil ihre Teams weder wissen, wann sie dem System vertrauen, noch wann sie eingreifen sollen. 

Ein Bestellvorschlag ist, wie der Name sagt, ein Vorschlag: Eine systemseitig berechnete Empfehlung für Zeitpunkt und Menge einer Bestellung. Er ist so gut wie seine Grundlage. Wer diese Grundlage kennt, kann schnell und sicher entscheiden, ohne jeden Vorschlag tief zu analysieren. 

Dieser Artikel beschreibt vier Bedingungen, unter denen Bestellvorschlägen vertraut werden kann, vier Warnsignale, die manuellen Eingriff erfordern, und das Prinzip des Management by Exception als strukturierten Rahmen für die Dispositionspraxis. 

Unter welchen Bedingungen können Sie dem Bestellvorschlag vertrauen? 

Zuverlässige Bestellvorschläge entstehen nicht zufällig. Sie setzen vier Bedingungen voraus. Wer diese Bedingungen bei einem konkreten Artikel kennt, weiß ohne vertiefte Analyse, ob der Vorschlag eine belastbare Grundlage hat. 

Saubere Datenbasis: Geschichte spiegelt Realität 

Die Grundlage jedes Bestellvorschlags ist die Absatzhistorie des Artikels. Wenn diese Geschichte die tatsächliche Nachfrage korrekt abbildet, hat der Vorschlag eine belastbare Grundlage. Wenn sie es nicht tut, weil Stockout-Perioden als Nullnachfrage gebucht sind, weil Promotions nicht als solche markiert sind oder weil ein ERP-Wechsel die Zeitreihe gebrochen hat, dann rechnet das System auf einer verzerrten Basis und erzeugt systematisch falsche Vorschläge. 

Das ist keine Frage der Systemqualität, sondern der Datenqualität. Ein gutes System mit schlechten Daten liefert schlechte Vorschläge. Wie die Datenbasis geprüft und bereinigt wird, beschreibt der Artikel zu KI-Absatzprognosen und Datenqualität

Prüffrage: Wann wurden die Absatzdaten der A-Artikel zuletzt auf systematische Lücken oder Verzerrungen geprüft? 

Aktuelle Dispositionsparameter: Das System kennt die heutige Realität 

Dispositionsparameter sind die systemseitig hinterlegten Steuerungsgrößen, die die Berechnungsgrundlage eines Bestellvorschlags bilden: Sicherheitsbestand (die Mindestmenge, die immer verfügbar sein soll), Wiederbeschaffungszeit (wie lange es dauert, bis eine Bestellung eintrifft) und Mindestbestellmenge (die kleinste Einheit, in der bestellt werden kann). 

Wenn diese Parameter mit der heutigen Realität übereinstimmen, ist der Vorschlag rechnerisch korrekt. Wenn sie es nicht tun, weil die Wiederbeschaffungszeit eines Lieferanten vor sechs Monaten von zehn auf sieben Tage gesunken ist und das im ERP nicht aktualisiert wurde, oder weil der Sicherheitsbestand pauschal für eine ganze Warengruppe gilt und den Einzelartikel nicht trifft, dann ist der Vorschlag strukturell falsch, nicht weil das System schlecht rechnet, sondern weil es auf falschen Grundlagen rechnet. Wie häufig Dispositionsparameter veralten und wie man gegensteuert, beschreibt der Artikel zu Dispositionsparametern und Bestellvorschlägen

Prüffrage: Wann wurden die Dispositionsparameter Ihrer A-Artikel zuletzt aktualisiert? 

Stabiler Artikelcharakter: Reguläre Artikel mit ausreichender Nachfragehistorie 

Bestellvorschläge sind bei bestimmten Artikeltypen zuverlässig und bei anderen strukturell überfordert. A- und B-Artikel mit stabiler, vorhersehbarer Nachfrage und ausreichend Absatzhistorie sind der Bereich, für den statistische und KI-gestützte Planungsmodelle entwickelt wurden. Hier stimmen Vorschläge in der Regel, wenn Datenbasis und Parameter aktuell sind. 

C-Artikel mit sporadischer Nachfrage, Neuartikel ohne eigene Absatzhistorie und Auslaufartikel, deren Nachfragemuster sich gerade verändert, gehören zu den Ausnahmen, bei denen Vorschläge systematisch unzuverlässig sind, nicht wegen schlechter Kalibrierung, sondern wegen strukturell fehlender oder nicht mehr repräsentativer Datenbasis. 

Kein bekannter externer Kontext, der den Vorschlag überholt 

Bestellvorschläge berechnen sich auf Basis der Vergangenheit und der hinterlegten Parameter. Was das System nicht kennt, fließt nicht ein. Wenn kein externer Einfluss bekannt ist, der die nächste Periode von der Vergangenheit abweichen lässt, ist der Vorschlag in diesem Punkt zuverlässig. Sobald ein solcher Kontext bekannt ist, ändert sich das. Die vier Warnsignale im nächsten Abschnitt sind genau diese Kontexte. 

Vier Situationen, in denen ein Bestellvorschlag manuell geprüft werden muss 

Diese Warnsignale entstehen nicht aus Systemversagen, sondern aus Situationen, für die das System keine ausreichenden Informationen hat. Der Disponent weiß mehr als das System. Genau das ist der Grund für manuellen Eingriff, nicht Misstrauen gegen die Technologie, sondern Einbringen von Kontextwissen. 

Warnsignal 1: Bevorstehende Aktion oder Sonderereignis 

Das System weiß, was in der Vergangenheit passiert ist. Es weiß nicht, was in zwei Wochen geplant ist. Eine Promotionaktion bei einem Schlüsselkunden, ein Messe-Auftritt, eine kurzfristige Großbestellung, ein saisonaler Anlass, der in diesem Jahr früher liegt als in der Absatzhistorie: Keiner dieser Kontexte fließt automatisch in den Bestellvorschlag ein, wenn er nicht explizit eingepflegt wurde. 

Wenn solche Ereignisse bekannt sind, muss der Vorschlag nicht als falsch abgelehnt, sondern aktiv angepasst werden. Die Anpassung ist kein Systemfehler, sie ist der Moment, in dem das Wissen des Disponenten den Wert des Systems steigert. 

Prüffrage: Gibt es in den nächsten vier Wochen externe Ereignisse, die die Nachfrage verändern werden und die das System noch nicht kennt? 

Warnsignal 2: Neuartikel oder Auslaufartikel 

Für Neuartikel hat das System keine eigene Absatzhistorie. Was es als Vorschlag ausgibt, basiert auf Defaultwerten oder auf Parametern verwandter Artikel, die möglicherweise keine gute Näherung sind. Der Vorschlag klingt konkret, ist aber eine Schätzung auf dünner Grundlage. 

Auslaufartikel sind das spiegelbildliche Problem: Die Absatzhistorie ist vorhanden, aber nicht mehr repräsentativ. Das System sieht stabile oder leicht fallende Nachfrage und extrapoliert sie in eine Zukunft, die für den Artikel nicht mehr existiert. Wenn der Auslaufentscheid gefallen ist, aber das System noch nicht informiert wurde, generiert es weiter reguläre Bestellvorschläge für einen Artikel, dessen Bedarf bereits wegfällt. 

Wie mit Neuartikeln und Auslaufartikeln methodisch umgegangen wird, beschreibt der Artikel zu Prognosen bei Neuartikeln und Auslaufprodukten

Warnsignal 3: Lieferantenveränderung oder geänderte Konditionen 

Neue Wiederbeschaffungszeiten nach einem Lieferantenwechsel, geänderte Mindestbestellmengen nach einer Verhandlung, eine vorübergehende Liefereinschränkung: All das verändert die Berechnungsgrundlage des Bestellvorschlags, ohne dass das System davon weiß, solange die Parameter nicht aktualisiert sind. 

In diesem Fall stimmt die Berechnungslogik, aber sie rechnet mit falschen Eingangswerten. Der Vorschlag ist intern konsistent und trotzdem falsch. Das ist das tückische an veralteten Parametern: Der Fehler ist nicht sichtbar, weil er nicht als Systemfehler erscheint, sondern als reguläres Ergebnis. 

Warnsignal 4: Extrem hohe oder ungewöhnlich niedrige Vorschlagsmenge 

Wenn ein Vorschlag mehr als doppelt so hoch oder weniger als halb so hoch ist wie die typische Bestellmenge der letzten Wochen, ist das ein Signal. Nicht jede solche Abweichung ist ein Fehler: Saisonalität, bevorstehende Lieferprobleme oder eine Änderung des Planungshorizonts können legitime Ursachen sein. Aber jede Abweichung in dieser Größenordnung verdient einen Blick. 

Eine einfache Plausibilitätsprüfung reicht: Gibt es eine nachvollziehbare Erklärung für die Abweichung? Wenn ja, freigeben. Wenn nicht, prüfen. Der Aufwand für diese Prüfung ist gering. Der Schaden durch eine unkontrolliert freigegebene Extremmenge nicht. 

Management by Exception: Wie Disponenten das System arbeiten lassen und trotzdem die Kontrolle behalten 

Management by Exception (MbE) ist das Steuerungsprinzip, bei dem der Disponent nur dort eingreift, wo das System außerhalb definierter Grenzen liegt. Es ist kein Kontrollverzicht. Es ist der Entschluss, die eigene Aufmerksamkeit dort zu konzentrieren, wo sie echten Unterschied macht. 

Ampellogik: Vorschläge nach Eingriffsbedarf klassifizieren 

Die einfachste Umsetzung von MbE in der Dispositionspraxis ist eine Ampellogik: Vorschläge werden in drei Kategorien eingeteilt, auf Basis der vier Vertrauens-Dimensionen und der vier Warnsignale. 

  • Grün bedeutet: Freigeben. A- und B-Artikel mit sauberer Datenbasis, aktuellen Parametern, stabiler Nachfrage und keinem bekannten externen Kontext. Diese Kategorie soll den Großteil der täglichen Vorschläge ausmachen.  

  • Gelb bedeutet: Kurz prüfen. Vorschläge mit einer Abweichung von mehr als 20 Prozent gegenüber dem Vorwochenwert, Artikel, bei denen eine Lieferantenänderung bekannt ist, oder Artikel, die in der letzten Periode ungewöhnliche Nachfragemuster gezeigt haben.  

  • Rot bedeutet: Zwingend manuell. Neuartikel, Auslaufartikel, Vorschläge bei bekannten bevorstehenden Aktionen und Extremmengen ohne nachvollziehbare Erklärung. 

Die Kriterien für diese Einteilung muss der Disponent definieren. Systeme können die Ampellogik technisch unterstützen, aber die inhaltliche Entscheidung, was Gelb und was Rot bedeutet, liegt beim Team. 

Override-Rate als Diagnosewerkzeug, nicht als Leistungskennzahl 

Die Override-Rate ist der prozentuale Anteil der Bestellvorschläge, die manuell verändert werden. Sie ist ein wichtiger Indikator, aber oft werden ihre Signale falsch gelesen. 

Eine hohe Override-Rate muss nicht bedeuten, dass der Disponent zu wenig vertraut. Sie kann bedeuten, dass das System ein Problem hat: Veraltete Parameter, schlechte Datenbasis, systematisch falsch kalibriertes Modell. In diesem Fall ist die hohe Rate ein Signal für ein Systemproblem, nicht für ein Verhaltensproblem des Disponenten. 

Eine niedrige Override-Rate bei gleichzeitig schlechten Bestandsergebnissen, also häufigen Out-of-Stocks oder hohen Überbeständen, bedeutet das Gegenteil: Die Disponenten übernehmen fehlerhafte Vorschläge, ohne sie ausreichend zu hinterfragen. Wie manuellen Eingriff in Prognosen sinnvoll gesteuert werden kann, beschreibt der Artikel zu Forecast Overrides und KI-Planereingriff

Der nützliche Indikator ist nicht der absolute Wert der Override-Rate, sondern ihr Trend: Wenn sie steigt, ohne dass die Ergebnisqualität sich verbessert, hat das System ein Problem. Wenn sie fällt, ohne dass die Bestandsergebnisse schlechter werden, verbessert sich das Systemvertrauen auf einer richtigen Grundlage. 

Systemvertrauen aufbauen: Wie lange das dauert, und wie man es beschleunigt 

Systemvertrauen entsteht durch Erfahrung: Welche Vorschläge haben in der Vergangenheit tatsächlich gestimmt? Für welche Artikel hat das System regelmäßig richtig gelegen, und bei welchen regelmäßig nicht? 

Der strukturierte Weg dahin: A-Artikel über drei Monate systematisch beobachten. Vorschlag dokumentieren, tatsächlichen Bedarf dokumentieren, Abweichung messen. Nach diesem Zeitraum lässt sich für jeden Artikel ein Freigabemuster ableiten: Bei welchen Artikeln und unter welchen Bedingungen lag das System dauerhaft richtig? Diese Artikel wechseln in die grüne Kategorie. Bei welchen lagen sie regelmäßig daneben? Diese bleiben gelb oder rot, bis das zugrunde liegende Problem, ob Datenbasis, Parameter oder Artikelcharakter, behoben ist. 

Wichtig für die Interpretation: Wenn ein Artikel dauerhaft in der Abweichung liegt, ist das kein Argument gegen das Prinzip des Systemvertrauens, sondern ein Hinweis auf ein spezifisches Problem. Der nächste Schritt ist nicht, den Vorschlag dauerhaft manuell zu übersteuern, sondern die Ursache der Abweichung zu beheben. Veraltete Parameter, eine lückenhafte Datenbasis oder ein ungeeignetes Prognosemodell für den Artikelcharakter sind die häufigsten Ursachen. Wer diese Fragen für seine A-Artikel beantwortet hat, hat die Grundlage für ein strukturiertes Freigabeverfahren gelegt.  

Fazit 

Blindes Vertrauen in Bestellvorschläge ist genauso riskant wie systematisches Misstrauen. Wer weiß, wann das System recht hat und wann nicht, arbeitet effizienter als beide. 

Drei Schritte für sofort: Für alle A-Artikel prüfen, wann Dispositionsparameter und Datenbasis zuletzt aktualisiert wurden. Eine einfache Ampellogik definieren, welche Fälle grün, gelb und rot sind, und das Team darauf einigen. Und die Override-Rate monatlich messen, als Indikator für Systemqualität, nicht als Beurteilungsgröße für Disponentenverhalten. Wer diese drei Maßnahmen eingeführt hat, hat Management by Exception nicht als Konzept, sondern als Praxis. 


Weiterführende Quellen 

  1. BCG (2026): Supply Chain Planning 2026: Why AI Alone Isn't Enough 

  2. Fraunhofer IML: Dynamische Bestandsdisposition und Service-Level-Management 

  3. BVL (2025): Trends und Strategien in Logistik und Supply Chain Management 2025 

  4. PWC (2025): Digital Trends in Operations Survey 

FAQs

Was ist Management by Exception in der Disposition?

Management by Exception (MbE) ist ein Steuerungsprinzip, bei dem der Disponent nicht jeden Bestellvorschlag gleich intensiv prüft, sondern nur dort eingreift, wo das System außerhalb definierter Toleranzgrenzen liegt. Die Grundidee: Der Großteil der Vorschläge, bei Artikeln mit stabiler Nachfrage, sauberer Datenbasis und aktuellen Parametern, wird direkt freigegeben. Eingriff und manuelle Prüfung konzentrieren sich auf die Ausnahmen: Neuartikel, Auslaufartikel, bevorstehende Aktionen, ungewöhnliche Vorschlagsmengen. MbE ist kein Kontrollverzicht. Es ist der Entschluss, Aufmerksamkeit und Kapazität dort einzusetzen, wo sie tatsächlich den Unterschied machen.

Woran erkenne ich, ob ein Bestellvorschlag auf einer schlechten Datenbasis basiert?

Direkt sichtbar ist das selten. Drei indirekte Indikatoren helfen: Erstens eine hohe Override-Rate bei bestimmten Artikeln oder Warengruppen, also systematisch häufige manuelle Anpassungen in eine Richtung. Zweitens ein MAPE über 25 Prozent über mehrere Perioden, also eine große durchschnittliche Abweichung zwischen Prognose und tatsächlichem Bedarf. Drittens bekannte Ereignisse in der Datenhistorie wie ein ERP-Wechsel, COVID-Perioden oder vergangene Aktionen ohne Kennzeichnung. Wenn alle drei Signale zusammentreffen, liegt das Problem fast immer in der Datenbasis, nicht im Algorithmus.

Was ist eine Override-Rate, und welcher Wert ist normal?

Die Override-Rate gibt an, wie viel Prozent der systemseitig generierten Bestellvorschläge vom Disponenten manuell verändert werden, bevor sie freigegeben werden. Einen allgemein gültigen Normalwert gibt es nicht, weil er stark vom Artikelmix, der Systemreife und der Branche abhängt. Aussagekräftig ist der Trend: Steigende Override-Rate bei gleichbleibenden Bestandsergebnissen signalisiert ein Systemproblem. Sinkende Override-Rate bei gleichbleibend guten Ergebnissen signalisiert wachsendes berechtigtes Systemvertrauen. Eine hohe Rate allein ist kein Problem, wenn die Eingriffe auf echtem Kontextwissen basieren. Sie ist ein Problem, wenn sie auf strukturell falschen Systemvorschlägen basiert, die niemand bemerkt hat.

Wann darf ich einen Bestellvorschlag einfach freigeben?

Wenn vier Bedingungen gleichzeitig erfüllt sind: Die Absatzdaten des Artikels sind aktuell und nicht durch bekannte Ereignisse wie Stockouts oder unmarkierte Promotions verzerrt. Die Dispositionsparameter wurden in den letzten sechs Monaten überprüft und entsprechen der heutigen Lieferanten- und Bestandssituation. Der Artikel ist ein regulärer A- oder B-Artikel mit ausreichend stabiler Nachfragehistorie. Und es gibt keinen bekannten externen Kontext, also keine bevorstehende Aktion, Lieferantenveränderung oder geplante Auslistung, der die nächste Periode von der Vergangenheit abweichen lässt. Sind alle vier Punkte erfüllt, ist direkte Freigabe die richtige Entscheidung.

Was passiert, wenn ich Bestellvorschläge systematisch zu hoch oder zu niedrig anpasse?

Systematische Abweichungen in eine Richtung haben zwei mögliche Ursachen. Entweder hat das System ein echtes Problem, zum Beispiel veraltete Parameter oder eine schlechte Datenbasis, und der Disponent korrigiert auf Basis besserer Informationen. Oder der Disponent hat eine Bias, also eine systematische Tendenz zur Über- oder Unterschätzung, die nicht durch tatsächlich bessere Informationen gerechtfertigt ist. Der erste Fall ist legitim und sollte zum Anlass genommen werden, das zugrunde liegende Systemproblem zu beheben. Der zweite Fall ist ein strukturelles Problem, das Bestandsergebnisse systematisch verschlechtert. Die Unterscheidung lässt sich treffen, indem Override-Entscheidungen und deren Begründungen dokumentiert und im Nachhinein mit dem tatsächlichen Bedarf abgeglichen werden.

Wie baue ich Systemvertrauen in der Disposition auf?

Systemvertrauen entsteht durch strukturierte Erfahrung, nicht durch Überzeugungsarbeit. Der praktische Weg: A-Artikel für drei Monate systematisch beobachten. Für jeden Artikel den Bestellvorschlag dokumentieren, den tatsächlichen Bedarf nach der Periode erfassen und die Abweichung messen. Nach drei Monaten lässt sich für jeden Artikel ein klares Muster ableiten: Bei welchen Artikeln und unter welchen Bedingungen lag das System dauerhaft richtig? Diese Artikel wechseln in die grüne Kategorie der direkten Freigabe. Artikel, bei denen das System regelmäßig daneben lag, bleiben in der Prüfkategorie, bis das zugrunde liegende Problem, ob Datenbasis oder Parameter, behoben ist.