Foto: Google Gemini · AI-generated
Fragen Sie einen Gastronomen nach seinem Bestand. Sie bekommen eine Zahl. Die Zahl stimmt nicht, und alle wissen das.
Das ist keine Schlamperei. Das passiert, wenn Software für Kartons auf Lebensmittel losgelassen wird.
Die meisten Warenwirtschaftssysteme beruhen auf einer Annahme: Was Sie einkaufen, verkaufen Sie auch. 40 Stück gekauft, 12 verkauft, 28 übrig. Für Handyhüllen stimmt dieses Modell. Für fast alles in einer Küche nicht.
Sie verkaufen nie das, was Sie eingekauft haben
Sie kaufen einen 20-Kilo-Sack Mehl. Sie verkaufen Croissants.
Zwischen diesen beiden Tatsachen liegen ein Rezept, eine Ausbeute und ein Mensch. Aus dem Sack wird Teig. Etwas Teig bleibt auf der Arbeitsfläche. Ein paar Croissants verbrennen. Die Portion wiegt theoretisch 62 Gramm und praktisch das, was die Hand des Bäckers sagt.
Der Bestand lässt sich also nicht in der Einkaufseinheit zählen. Er muss doppelt modelliert werden: als das, was Sie gekauft haben, und als das, was Sie verkaufen — mit einem Rezept als Umrechnung dazwischen. Liegt diese Umrechnung um drei Prozent daneben, liegen Ihre Wareneinsatzkosten um drei Prozent daneben. Bei jedem Artikel, jeden Tag, unbemerkt.
Deshalb scheitert “die Bestandsführung bauen wir später dazu” so oft. Rezepturen sind kein Modul, das man auf den Bestand setzt. Sie sind das, was den Bestand überhaupt aussagekräftig macht.
Bestand hat eine Uhr
Der zweite Unterschied ist der schwierigere. Eine Handyhülle verdirbt nicht. Sahne schon.
Eine Menge allein ist damit keine Tatsache mehr. Zwölf Liter Sahne mit Ablauf Donnerstag und zwölf Liter mit Ablauf nächsten Monat sind zwei verschiedene Bestände. Ein System, das daraus “24” macht, hat genau die Information weggeworfen, die entscheidet, was heute Abend gekocht wird.
Verderblichkeit verändert das Datenmodell, nicht nur die Auswertung. Jede Charge braucht eine eigene Identität und ein eigenes Datum, Bewegungen müssen je Charge geführt werden, und das System muss “was läuft zuerst ab” genauso leicht beantworten wie “wie viel ist da”. Das nachträglich in ein Design einzubauen, das eine Zahl pro Artikel annahm, bedeutet meist, den Kern neu zu schreiben. Deshalb passiert es meist nicht.
Die Zahl ist eine Erzählung über die Vergangenheit
Bestand wird nicht gemessen, sondern hergeleitet. Sie zählen am Sonntag und vertrauen dem System bis zur nächsten Zählung.
Alles dazwischen entsteht aus Ereignissen: Wareneingänge, Verkäufe, Verderb, Umlagerungen. Fehlt einer dieser Ereignisströme oder widerspricht er den anderen, driftet die hergeleitete Zahl ab. Auffallen wird es erst, wenn die körperliche Zählung ihr widerspricht.
Deshalb ist die Kasse wichtiger, als sie aussieht. Als wir Dinifi gebaut haben — eine mobile-first Kassen- und Bestellplattform für die Gastronomie, die auf Handhelds, iPads im Laden und Menü-Displays läuft — war der interessante Teil die Konsistenz: Jedes Gerät musste dasselbe Ereignis gleich erfassen. Ein Verkauf am Handheld und derselbe Verkauf an der Theke dürfen nicht zu zwei verschiedenen Tatsachen werden. Passiert das doch, ist die Bestandszahl dahinter bereits Fiktion.
Mehrere Standorte vervielfachen alles
Und jetzt das Ganze über mehrere Standorte und Gesellschaften hinweg.
Geek ERP, das wir für eine Hotellerie- und Gastronomiegruppe in den VAE gebaut haben, hatte genau diese Form: Allokation, Bestellwesen, Bestand und Abrechnung über mehrere Unternehmen einer Gruppe, jedes mit eigener Struktur und eigenen Kostenstellen. Die schwierige Frage war nie “wie viel haben wir”, sondern “wem gehört es, wo liegt es, und welche Gesellschaft trägt die Kosten”. Umlagerungen zwischen Standorten sind der unangenehme Fall: Eine Bewegung muss an einer Stelle abgehen und an einer anderen zugehen, ohne kurzzeitig doppelt oder gar nicht zu existieren.
Bevor Sie Prognosen einkaufen
Vorausschauende Disposition und Bedarfsprognosen sind real und sie funktionieren. Sie sitzen aber auf allem oben Genannten auf.
Eine Prognose ist nur so gut wie die Verbrauchshistorie dahinter. Und diese Verbrauchshistorie entsteht genau aus Rezepturen, Chargenverfolgung und verlässlicher Ereigniserfassung. Steht das wacklig, behebt eine Prognose das Problem nicht — sie kleidet es ein und gibt ihm ein Konfidenzintervall.
Die Reihenfolge entscheidet also. Rezeptur modellieren. Dem Bestand eine Uhr geben. Dafür sorgen, dass alle Geräte sich einig sind, was passiert ist. Danach prognostizieren.
Nichts davon ist exotische Technik. Es ist Individualentwicklung, weil dieses Geschäft tatsächlich anders geformt ist als Standard-Warenwirtschaft — und so zu tun, als wäre es das nicht, erzeugt genau den Bestandsbericht, den am Ende alle stillschweigend ignorieren.
Wenn Sie Systeme für Lebensmittel und Gastronomie bauen oder ablösen, sprechen wir darüber.