Blogartikel
Automatische Disposition im Getränkehandel: Warum sie bei Volksfest und Hitze versagt
Ein Bestellvorschlag, der bei normaler Auslastung stimmt, ist kein Beweis dafür, dass das System funktioniert. Im Getränkefachgroßhandel entscheidet sich die Qualität der automatischen Disposition in den Momenten, die wirtschaftlich am stärksten ins Gewicht fallen: beim Volksfest am ersten Augustwochenende, bei der Hitzewelle Mitte Juli, in den ersten Wochen der Außengastronomie-Saison. Genau dann versagt das ERP-Planungsmodul strukturell, nicht weil es schlecht ist, sondern weil es für diese Situationen nicht gebaut wurde.
Out-of-Stock bei Bier oder alkoholfreien Getränken (AFG) am Volksfest-Wochenende ist im Getränkefachgroßhandel kein Betriebsunfall. Es ist ein strukturell vorhersehbares Versagen, das sich jede Saison wiederholt und in vielen Betrieben branchentypische Out-of-Stock-Quoten von rund 20 Prozent bei Wein, Sekt und Spirituosen erzeugt. Diese Quote ist kein Studienwert, sondern ein Erfahrungswert aus dem GFGH, aber sie zeigt das Muster: Die automatische Disposition über das ERP-Planungsmodul ist für stabile, historisch ableitbare Nachfrage entwickelt. Im GFGH ist wetter- und eventgetriebene Nachfrage kein Ausnahmefall, sondern der Kern des Saisongeschäfts. Die Fraunhofer-IML-Forschung zum Machine Learning in der Bedarfsplanung beschreibt diese Grenze klassischer ERP-Planung als strukturell. Dieser Artikel zeigt drei Versagensszenarien, ihre strukturellen Ursachen und drei Lösungsansätze, die ohne Systemwechsel auskommen.
Automatische Disposition im GFGH: drei Situationen, in denen das ERP-Planungsmodul strukturell versagt
Das ERP-Planungsmodul ist der integrierte Planungsbaustein des GFGH-ERP, der Bestellvorschläge auf Basis historischer Abverkaufsdaten und hinterlegter Dispositionsparameter berechnet. Es arbeitet mit Durchschnittswerten, lernt aus der Vergangenheit und extrapoliert sie in die Zukunft. Das funktioniert gut, wenn die Zukunft der Vergangenheit ähnelt. Im GFGH tut sie das selten. Volksfeste variieren, Sommer sind unterschiedlich heiß, neue Events entstehen, alte fallen weg. Drei Situationen zeigen, wo die Systemgrenze liegt.
Volksfest und Stadtfest: was das ERP nicht weiß
Das ERP-Planungsmodul kennt keinen Veranstaltungskalender. Es kennt nur vergangene Abverkäufe. Wenn ein Volksfest in der Absatzhistorie enthalten ist, mittelt das System es mit den Normalwochen. Der Bestellvorschlag für das nächste Fest liegt damit systematisch zu niedrig, weil der historische Spitzenwert vom Durchschnitt heruntergerechnet wurde. Wenn ein Volksfest neu ist oder vom Veranstalter an einen anderen Standort verschoben wurde, fehlt jede Lernbasis. Der Bestellvorschlag ignoriert das Event vollständig.
Die operative Konsequenz ist immer dieselbe: Out-of-Stock bei Fassbier, Gebinde und AFG am Veranstaltungswochenende. Eine Nachbestellung mit einer Wiederbeschaffungszeit (WBZ, der Zeitspanne zwischen Bestellauslösung und Wareneingang) von zwei bis drei Tagen kommt zu spät. Das Fest läuft, der Kunde reklamiert, im schlimmsten Fall wechselt er für den nächsten Auftrag zum Wettbewerb. Die Reaktion fällt typischerweise auf den Disponenten zurück, obwohl die Ursache eine Stufe höher liegt: im System, das vom Fest nichts weiß. Wie sich der Veranstaltungskalender als strukturierter Dispositionsinput nutzen lässt, behandelt der Artikel zur Wetterprognose im GFGH in einem verwandten Anwendungsfall.
Die Prüffrage: Hat Ihr ERP-Planungsmodul Kenntnis über die lokalen Veranstaltungskalender der nächsten vier Wochen, oder basiert der aktuelle Bestellvorschlag ausschließlich auf historischen Werten?
Hitzewelle: wenn der Temperatursprung den Durchschnitt bricht
Eine Temperaturschwelle bezeichnet einen Wert, ab dem die Nachfrage nach bestimmten Getränkekategorien sprunghaft steigt. Das ERP-Planungsmodul kennt solche Schwellen nicht. Es mittelt historische Juli-Abverkäufe über alle Temperaturlagen. Das Ergebnis passt für einen durchschnittlichen Juli, nicht für eine Hitzewelle mit mehreren Tagen über 30 Grad. Eine sprunghafte Nachfragesteigerung bei Bier, Wasser und AFG ist nicht linear extrapolierbar. Das Modell unterschätzt die Spitze systematisch.
Das Problem hat eine zweite Hälfte, die oft übersehen wird. Nach der Hitzewelle bricht die Nachfrage ein, oft drastisch, weil die Außengastronomie ihre Bestände aufgefüllt hat und die Privathaushalte ihre Bevorratung erst abbauen. Das System hat für die Folgewoche aber weiterhin hohe Werte prognostiziert, weil die jüngsten Tage mit hohen Abverkäufen im Durchschnitt liegen. Der Disponent hat zwei Versagensmomente nacheinander zu kompensieren: zuerst die Unterprognose im Peak, dann die Überprognose im Tal. Als Orientierungswerte für Temperaturschwellen gelten branchentypisch Werte um 26 Grad für Bier und 30 Grad für AFG, exakte Werte hängen aber von Region und Sortiment ab und müssen unternehmensspezifisch ermittelt werden.
Die Prüffrage: Wie hoch war Ihre manuelle Korrekturrate an Bestellvorschlägen in den letzten drei Hitzewochen?
Saisonspitze April bis Oktober: wenn der Saisonindex fehlt oder veraltet ist
ERP-Planungsmodule brauchen einen gepflegten Saisonindex, um die Saisonkurve eines Artikels korrekt abzubilden. Der Saisonindex ist der Faktor, der den saisonalen Anteil der Nachfrage von der Grundlast trennt. Im GFGH ist er für die meisten A-Artikel ausgeprägt: Sommerbier hat im Juli ein anderes Niveau als im Februar, Glühwein im Dezember ein anderes als im Mai. Wenn dieser Index nach ERP-Einführung nicht aktualisiert wird, entsteht Parameterdrift, also die schleichende Abweichung der hinterlegten Werte von der realen Nachfrage.
Die Konsequenz ist eine systematische Unterbestellung in der Hochsaison und eine systematische Überbestellung in der Nebensaison. Genau dieses Muster führt zu der eingangs erwähnten Out-of-Stock-Quote von rund 20 Prozent bei Wein, Sekt und Spirituosen in der Hochsaison, die in vielen inhabergeführten GFGH-Betrieben als branchentypischer Erfahrungswert bekannt ist. Der Verlust ist nicht nur der entgangene Umsatz, sondern auch das gebundene Kapital in der Nebensaison-Überbestockung. Wie Parameterdrift im Detail entsteht und wo er sich noch zeigt, behandelt der Artikel zu Dispositionsparametern.
Die Prüffrage: Wann wurde der Saisonindex Ihrer A-Artikel im ERP zuletzt überprüft, und entspricht er dem tatsächlichen Saisonmuster der letzten zwei Jahre?
Warum das kein Pflegeproblem ist: die strukturelle Grenze der ERP-nativen Disposition im GFGH
Die naheliegende Reaktion auf Systemversagen ist Mehrarbeit: Parameter öfter pflegen, Bestellvorschläge öfter manuell korrigieren, Saisonindizes öfter aktualisieren. Das hilft, bis zu einem Punkt. Drei strukturelle Grenzen zeigen, warum manuelle Nachpflege das Problem nicht löst.
Das Skalierungsproblem: manuelle Korrektur bei 3.000 bis 8.000 SKUs
Parameter-Nachpflege auf Artikelebene skaliert nicht. Bei 5.000 aktiven Artikeln und 15 Lieferantenbestellungen pro Woche in der Saison bleibt keine Zeit für systematische Pflege. Der Disponent korrigiert die wichtigsten Artikel aus Erfahrung, die Masse läuft auf veralteten Parametern. Sichtbar wird das nicht beim einzelnen Bestellvorschlag, sondern in der Summe der Fehlbestellungen, in den Quartalsreports und in der Reklamationsstatistik.
Die strukturelle Folge: Selbst ein engagierter Disponent kann nur einen Teil des Sortiments aktiv pflegen. Der Rest läuft mechanisch durch, oft auf Parametern, die seit der ERP-Einführung nicht angefasst wurden. Wie sich dieses Volumenproblem im GFGH ausdrückt, behandelt der Artikel zur Disposition-Skalierung im Getränkefachgroßhandel.
Das Timing-Problem: WBZ trifft auf kurzfristige Ereignisse
Die Wiederbeschaffungszeit bei Bier und AFG liegt typischerweise bei zwei bis drei Tagen, bei Importware und Spezialitäten länger. Ein Volksfest kündigt sich oft mehr als zwei Wochen vorher an, aber das ERP reagiert nicht automatisch auf diese Information. Eine Hitzewelle kündigt sich 24 bis 48 Stunden vorher an, was für eine reguläre Nachbestellung auf Normalbasis zu kurz ist.
Die Lösung liegt nicht in schnellerer Reaktion, sondern in früherer Antizipation. Das System müsste das Volksfest schon vor zwei Wochen einplanen können, damit die WBZ überhaupt reicht. Genau das leistet das ERP-Planungsmodul strukturell nicht: Es weiß weder vom Volksfest noch vom Wetter, weil ihm der Input fehlt. Schnelleres Korrigieren am Bestelltag löst dieses Timing-Problem nicht, es verlagert es nur auf den Disponenten und seine Reaktionsfähigkeit.
Das Lernproblem: das ERP lernt nicht, es extrapoliert
ERP-Planungsmodule lernen nicht aus Abweichungen. Ein Out-of-Stock beim Volksfest wird nicht als Lernimpuls verarbeitet. Schlimmer noch: Wenn ein Artikel über das Wochenende ausverkauft war, bucht das System keine Nachfrage, weil keine Ware abverkauft werden konnte. Im ERP erscheint die Phase als Nullnachfrage, obwohl der Bedarf vorhanden war. Dieses Muster heißt Stockout-Verzerrung.
Der Fehler verstärkt sich: Beim nächsten Volksfest plant das ERP mit einer Absatzhistorie, die den eigentlichen Bedarf systematisch unterschätzt, weil der vorherige Stockout als Nullnachfrage gilt. Der Bestellvorschlag wird beim nächsten Mal noch niedriger, der nächste Out-of-Stock ist programmiert. So perpetuiert sich der Fehler ohne menschliches Zutun.
Die Prüffrage: Werden Out-of-Stock-Perioden in Ihrem ERP als solche erfasst, oder erscheinen sie als Nullnachfrage in der Absatzhistorie?
Was über manuelle Korrektur hinausgeht: drei Ansätze für eine ereignisfähige Disposition
Das ERP-Planungsmodul durch ein besseres zu ersetzen ist eine Option, aber nicht der einzige Weg. Drei Ansätze zeigen, wie GFGH-Betriebe die strukturelle Lücke schließen, ohne das bestehende System aufzugeben.
Veranstaltungskalender als strukturierter Dispositionsinput
Der Minimalansatz ohne Systemwechsel ist ein gepflegter Veranstaltungskalender für die nächsten acht Wochen als Pflichtfeld in der wöchentlichen Dispositionsroutine. Für jedes bekannte Event wird die Bestellmenge manuell kalkuliert, die WBZ rückgerechnet, der späteste Bestellzeitpunkt definiert. Das ist kein Systemersatz, sondern ein Prozess, der das System dort ergänzt, wo es strukturell blind ist.
Praktisch heißt das: Eine geteilte Tabelle mit Standort, Datum, geschätzter Besucherzahl und betroffenen Kategorien reicht für den Anfang. Lokale Tourismusämter, Stadtmarketinggesellschaften und die Außendienstmitarbeiter kennen die meisten relevanten Termine. Der Aufwand liegt nicht in der Datenerhebung, sondern in der Disziplin, den Kalender konsequent zu pflegen und in den wöchentlichen Dispositionsrhythmus einzubauen.
Temperaturschwellen-Kalibrierung: eigene Schwellenwerte aus historischen Daten ableiten
Statt pauschaler Hitzezuschläge nach Gefühl lassen sich unternehmensspezifische Temperaturschwellen ableiten. Methodisch werden die historischen Abverkaufsdaten der letzten drei Sommer mit Temperaturdaten korreliert, die vom Deutschen Wetterdienst (DWD) und der Zentralanstalt für Meteorologie und Geodynamik (ZAMG) kostenlos verfügbar sind. Das Ergebnis sind eigene Schwellenwerte für Bier, AFG und Wasser: ab welcher Temperatur steigt die Nachfrage um wie viel Prozent.
Mit diesen Schwellen wird ein wöchentlicher Wetter-Check zum festen Dispositionsschritt. Wenn die Fünf-Tages-Prognose die eigene Bierschwelle überschreitet, wird die Bestellmenge angepasst. Das ist ein methodischer Schritt, kein Systemprojekt, und er nutzt externe Signale (Daten außerhalb des ERP wie Wetter, Events oder Feiertage) als strukturellen Input, ohne dass das ERP technisch dafür ausgelegt sein müsste. Die McKinsey-Analyse zu AI in Distribution Operations beschreibt diese Integration externer Signale als zentralen Hebel für die Distributionsplanung.
Wenn das ERP an seine Grenze stößt: wann eine Erweiterung sinnvoll ist
Manuelle Ergänzung hat ihre Grenze. Wenn die Event-Frequenz und die Sortimentskomplexität so hoch sind, dass manuelle Korrekturen mehr Zeit kosten als sie einsparen, ist eine technische Erweiterung des Planungsstacks zu evaluieren. Als Orientierungsschwelle, kein belegter Benchmark, gilt: Wenn mehr als 30 Prozent der Saisonbestellvorschläge manuell korrigiert werden müssen, ist das ein Signal für strukturellen Handlungsbedarf.
Was eine solche Erweiterung leisten muss, lässt sich unabhängig vom Anbieter benennen. Externe Signale wie Wetter und Veranstaltungskalender müssen native Planungsvariablen sein, nicht nachträglich eingelesene Daten. Die automatische Parametrisierung muss Parameterdrift verhindern, statt sie nur sichtbar zu machen. Und der Bestellvorschlag muss erklärbar bleiben, damit der Disponent ihn prüfen und überstimmen kann, wenn er lokale Information hat, die das System nicht kennt. Wann es überhaupt sinnvoll ist, Bestellvorschlägen zu vertrauen, und wann nicht, behandelt der Artikel zum Umgang mit Bestellvorschlägen.
Das nächste Volksfest kommt bestimmt
Das ERP-Planungsmodul versagt bei Volksfesten, Hitzewellen und Saisonspitzen nicht wegen mangelnder Pflege. Es versagt strukturell, weil es für diese Situationen nicht entwickelt wurde. Wer das versteht, hört auf, das Symptom zu behandeln, und beginnt, die Ursache zu adressieren.
Drei Sofortschritte lohnen sich, unabhängig davon, ob am Ende ein Systemwechsel steht oder nicht. Erstens den Veranstaltungskalender der nächsten acht Wochen als Pflichtfeld in die wöchentliche Dispositionsroutine aufnehmen, beginnend mit den Großevents im Einzugsgebiet. Zweitens die Abverkaufsdaten der letzten drei Sommer mit Temperaturdaten korrelieren, um eigene Schwellenwerte für Bier und AFG abzuleiten. Drittens die manuelle Korrekturrate der Saisonbestellvorschläge messen, als Indikator dafür, ob die strukturelle Lücke noch durch Erfahrung kompensierbar ist oder ob sie bereits Mitarbeiterkapazität verschlingt, die woanders fehlt.
Das nächste Volksfest kommt bestimmt. Und die nächste Hitzewelle auch. Die Frage ist nicht, ob das ERP dann wieder versagt, sondern ob Sie einen Prozess haben, der das auffängt.
Weiterführende Quellen
Fraunhofer IML: Potenziale des Machine Learning in der Bedarfsplanung
Fraunhofer IML: Dynamische Bestandsdisposition und robustes Service-Level-Management
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
McKinsey: Harnessing the Power of AI in Distribution Operations
FAQ
Warum liefert mein ERP-Planungsmodul schlechte Bestellvorschläge bei Volksfesten?
Weil das ERP keinen Veranstaltungskalender kennt. Es rechnet auf Basis historischer Abverkäufe und hinterlegter Parameter. Ein Volksfest, das in der Historie enthalten ist, wird mit Normalwochen gemittelt und damit unterschätzt. Ein neues oder verschobenes Volksfest ist im System gar nicht vorhanden. In beiden Fällen liegt der Bestellvorschlag systematisch zu niedrig. Die Wiederbeschaffungszeit für Bier und AFG von zwei bis drei Tagen reicht dann nicht mehr aus, um den Fehler zu korrigieren, bevor das Fest beginnt.
Was ist eine Temperaturschwelle, und wie nutze ich sie für die Disposition?
Eine Temperaturschwelle ist ein konkreter Temperaturwert, ab dem die Nachfrage nach bestimmten Getränkekategorien sprunghaft steigt. Branchentypisch liegen Schwellen für Bier bei rund 26 Grad, für AFG bei rund 30 Grad. Die exakten Werte hängen vom eigenen Sortiment und der Region ab und sollten aus den eigenen Abverkaufsdaten der letzten drei Sommer abgeleitet werden. In der Praxis wird die Fünf-Tages-Wetterprognose mit den eigenen Schwellen abgeglichen. Liegt die Prognose über der Bierschwelle, wird die Bestellmenge entsprechend angepasst.
Was ist Stockout-Verzerrung, und warum macht sie den nächsten Bestellvorschlag schlechter?
Stockout-Verzerrung entsteht, wenn ein Artikel über Tage nicht lieferbar war. Das ERP bucht in dieser Zeit keine Nachfrage, weil keine Ware abverkauft werden konnte. Im System erscheint die Phase als Nullnachfrage, obwohl der Bedarf vorhanden war. Beim nächsten Bestellvorschlag arbeitet das System mit einer Absatzhistorie, die den tatsächlichen Bedarf systematisch unterschätzt. Der nächste Bestellvorschlag wird dadurch zu niedrig, der nächste Out-of-Stock ist programmiert. So perpetuiert sich der Fehler ohne menschliches Zutun, bis die Stockout-Perioden im ERP als solche markiert werden.
Ab wann sollte ich über eine Erweiterung der automatischen Disposition nachdenken?
Wenn die manuelle Korrekturrate der Bestellvorschläge in der Saison strukturell über 30 Prozent liegt, ist das ein Signal. Dieser Wert ist ein Orientierungsrichtwert, kein Benchmark. Entscheidend ist, ob die manuelle Korrektur mehr Zeit kostet als sie einspart, und ob der Disponent mit der Korrekturmasse überhaupt noch alle relevanten Artikel erreicht. Wenn beides verneint wird, ist eine Erweiterung des Planungsstacks zu evaluieren. Externe Signale wie Wetter und Events müssen darin native Planungsvariablen sein, nicht nachträglich eingelesene Daten.
Wie leite ich eigene Temperaturschwellen für meinen GFGH-Betrieb ab?
Methodisch werden die Abverkaufsdaten der letzten drei Sommer auf Artikel- oder Kategorieebene mit Tagesdurchschnittstemperaturen korreliert. Die Wetterdaten sind vom Deutschen Wetterdienst und der ZAMG kostenlos verfügbar. Aus der Korrelation ergibt sich für jede Kategorie ein Schwellenbereich, ab dem die Nachfrage signifikant steigt, sowie ein Mengenfaktor pro Grad Celsius. Diese Werte ersetzen pauschale Hitzezuschläge nach Gefühl und schaffen eine reproduzierbare Grundlage für die wöchentliche Dispositionsanpassung.
Was ist Parameterdrift, und wie erkenne ich ihn im ERP?
Parameterdrift bezeichnet die schleichende Abweichung der hinterlegten Dispositionsparameter von der realen Nachfrage. Lieferzeiten verlängern sich, Saisonmuster verschieben sich, Mindestbestellmengen werden angehoben, aber im ERP stehen weiter die alten Werte. Erkennbar wird er an steigenden Out-of-Stock-Quoten oder wachsendem Überbestand ohne offensichtliche Ursache. Im GFGH zeigt er sich besonders deutlich am Saisonindex der A-Artikel, der oft seit der ERP-Einführung nicht mehr aktualisiert wurde. Das wirksamste Gegenmittel ist ein fester Überprüfungsrhythmus, der die Parameter der Top-Artikel quartalsweise mit der Realität abgleicht.
