Die Kiste mit drei Namen

TL;DR

• KI, Forecasting und automatische Bestellungen brauchen gepflegte Artikel, Einheiten, Rezepturen und Standorte.
• Ein führender Artikelstamm verhindert, dass Einkauf, Küche, Kasse und Reporting denselben Rohstoff unterschiedlich behandeln.
• Rezepturen müssen Verkauf in Verbrauch übersetzen, sonst bleibt der Umsatz vom Warenbestand getrennt.
• Vor dem nächsten Toolkauf reicht ein kleiner Test mit kritischen Artikeln, Rollen und Exporten.

Im Lager steht Rucola. Auf dem Lieferschein heißt er „Rucola Bund“. In der Küche sagt jemand nur „Rucola“. In der Kasse steckt er im „Salat grün“. In der Rezeptur steht „20 g Blatt“.

Für Menschen ist das kein Drama. Für Software schon.

Der Teller kommt sauber raus. Aber später wandert der Fehler weiter. Rezeptkosten stimmen nicht. Der Bestand läuft schief. Der Einkauf bestellt nach Gefühl. Im Monatsreport sieht die Marge aus, als hätte das System ein Problem.

Oft hat es das auch. Nur sitzt das Problem nicht im Dashboard. Es sitzt im Artikelstamm.

Das Backoffice rückt nach vorn

US-Fachmedien schauen 2026 stärker hinter die glänzende Bestelloberfläche. Nation’s Restaurant News berichtete im März über Restaurant-Technologie, die praktischer, profitabler und stärker auf Back-of-house-Prozesse ausgerichtet wird. Der dazugehörige Technology Outlook von Informa basiert auf fast 500 befragten Foodservice-Operatoren.

53 Prozent der Befragten priorisieren POS-Systeme für Investitionen 2026, nach 40 Prozent im Vorjahr. Inventory Management zählt ebenfalls dazu. Informa nennt Integration als nächste große Aufgabe: Online Ordering, Inventory Management und Data Analysis müssen in bestehende POS-, KDS- und Backoffice-Landschaften passen.

Auch die National Restaurant Association Show 2026 in Chicago zeigte diese Breite: mehr als 2.200 Aussteller, 900 Produktkategorien, Lösungen von POS bis Back-of-house, dazu KI-fähige Geräte und Automation.

Das ist US-Kontext, kein DACH-Benchmark. Als Signal reicht es: Der nächste Effizienzsprung hängt selten nur am neuen Tool. Er hängt daran, ob die alten Felder sauber genug sind.

Ein Artikel muss führen

Ein guter Artikelstamm beantwortet zuerst: Was ist dieser Artikel eindeutig?

Nicht: Wie nennt ihn der Lieferant diese Woche? Nicht: Wie steht er zufällig in der Kasse? Nicht: Wie ruft ihn die Küche im Service? Sondern: Welche gemeinsame Wahrheit nutzt der Betrieb, wenn Einkauf, Lager, Rezeptur, Kasse und Reporting miteinander sprechen sollen?

Dazu gehören Name, interne ID, Warengruppe, Einkaufseinheit, Lagereinheit, Rezeptureinheit, Packungsgröße, Lieferant, Preisgültigkeit, Steuerlogik, Kostenstelle, Standortfreigabe und bei Bedarf Allergenbezug.

Fourth und HotSchedules empfehlen in ihrer Master-Data-Logik, Produktnamen zukunftsfähig und nicht zu lieferanten- oder markenspezifisch anzulegen. „Burrata 125 g“ ist robuster als „Burrata Luigi“, wenn morgen ein anderer Lieferant dieselbe Spezifikation liefert.

Für Hotels wird daraus schnell mehr als ein Küchenproblem. Dieselbe Sahne läuft ins Frühstück, in die Bar, ins Bankett und ins à-la-carte-Restaurant. Lokal können Preise, Lieferanten oder Kostenstellen anders sein. Der Kern muss trotzdem derselbe bleiben. Sonst vergleichen Einkauf, Inventur und Reporting später verschiedene Wahrheiten.

Doppelte Artikel wirken harmlos. Bis ein Rohstoff dreimal gezählt und einmal gar nicht kalkuliert wird.

Rezeptur spricht in Mengen

Der Bon sagt: ein Cheeseburger. Die Warenwirtschaft muss daraus Bun, Patty, Käse, Sauce, Zwiebel, Verpackung und vielleicht Pommes machen. Genau dort beginnt die Übersetzung.

Oracle beschreibt in seiner Restaurant-Inventory-Dokumentation Menu Item Linking als Grundlage dafür, dass verkaufte Menüartikel den Bestand korrekt reduzieren. Ein Menüartikel kann mit mehreren Inventory Items oder Rezepturen verbunden sein. Selbst Modifier können Mengenlogik haben: Bei „NO Ketchup“ lässt sich eine negative Menge hinterlegen, damit Ketchup nicht fälschlich verbraucht wird.

Das klingt technisch, ist aber Alltag. Hafermilch als Aufpreis im Cappuccino sollte den Barbestand bewegen. Extra-Käse braucht eine Menge statt nur einen Button. Kleine, mittlere und große Pommes dürfen dieselbe Rezeptur nutzen, aber mit unterschiedlichen Faktoren.

Beim Frühstücksbuffet gibt es keinen Bon pro Scheibe Brot. Also braucht der Betrieb Produktionsmengen, Verbrauchskorrekturen und eine brauchbare Restelogik. Bankettmenüs starten mit Planmengen und brauchen später einen Ist-Abgleich.

Oracle kennt bei nicht gebuchten Verkäufen Fehler wie „menu item not assigned to item or recipe“. Der Umsatz ist da. Der Verbrauch findet keine Adresse.

Rechte sind keine Nebensache

Stammdatenpflege ist nicht einfach Adminarbeit. Sie ist Betriebsschutz.

Wer darf neue Artikel anlegen? Wer ändert Lieferantenpreise? Wer gibt Rezepturen frei? Wer verbindet POS-Menüpunkte mit Rezepturen? Wer sendet Bestellungen? Wer sieht Margendaten? Wer darf standortübergreifend ändern?

Restaurant365 beschreibt Berechtigungen nach Screens, Locations und Informationsarten. Rollen wie Restaurant Manager, Shift Lead oder Above Store Manager werden unterschiedlich gedacht.

Das passt zur Praxis. Eine Schichtleitung soll vielleicht Inventuren zählen und Waste Logs erfassen. Sie muss deshalb keine zentralen Einkaufspreise für alle Häuser ändern können.

Zu enge Rechte bremsen. Zu weite Rechte machen kleine Fehler groß. Besser ist eine klare Linie: erfassen, prüfen, freigeben, auswerten.

Der Export zeigt es

Ein Stammdatensatz ist erst brauchbar, wenn er die Reise durch die Systeme übersteht. POS verkauft. Rezeptur reduziert Bestand. Einkauf sieht Bedarf. Buchhaltung bekommt Steuer und Kostenstelle. Reporting zeigt Wareneinsatz, Marge, Waste und Abweichungen.

Restaurant365 beschreibt POS-Integration als Verbindung zwischen Kasse, Operations und Accounting. Detaillierte POS-Daten fließen in Sales Reporting, Menu Engineering, Recipe Costing und Analytics. FoodNotify beschreibt eine ähnliche Anbieterlogik für Orders, Recipes, Inventory und importierte Verkäufe.

Für Betriebe heißt das: Demo-Dashboards kurz anschauen, danach einen echten Export laufen lassen.

Kommt Rucola noch als derselbe Artikel an? Bleiben Mengen, Kostenstellen und Standorte sauber? Oder wird aus einem Bund plötzlich ein Kilo, aus Barverbrauch Frühstückskosten und aus einem Bestseller ein ungeklärter Restposten?

Erst zehn Artikel

Niemand muss 5.000 Artikel an einem Montagmorgen retten. Ein kleiner Test reicht.

Nehmen Sie zehn kritische Artikel: einen teuren Rohstoff, einen Bestseller, einen Barartikel, ein Frühstücksprodukt, ein Bankettgericht. Suchen Sie doppelte Namen. Prüfen Sie Einkaufseinheit, Rezeptureinheit, Packungsgröße, Yield, Modifier und Standortlogik.

Dann lassen Sie zwei Exporte laufen: POS zur Warenwirtschaft und POS zu Buchhaltung oder Reporting. Testen Sie drei Rollen: Service, Küchenleitung, F&B oder Einkauf. Wer darf was sehen, ändern und freigeben?

Neue Software kann viel bringen. KI, Forecasting und automatische Bestellungen werden stärker, wenn sie saubere Daten bekommen. Der Zauber beginnt selten im Dashboard. Er beginnt dort, wo „Rucola Bund“ und „20 g Blatt“ endlich miteinander bekannt sind.

Weitere Bilder