Standortübergreifende Rezeptverwaltung für Restaurantketten: Anleitung in 6 Schritten

In einer Restaurantkette gibt es das Rezept für die Bolognese genau einmal. So sollte es sein. In der Praxis liegt es als Excel in der Zentrale, als Ausdruck in fünf Küchen, als Foto auf drei Handys, und jede Version rechnet mit anderen Einkaufspreisen. Sobald ein Lieferant den Preis für Hackfleisch ändert, stimmt die Kalkulation nirgends mehr, und der Soll-Wareneinsatz je Standort ist eine Schätzung.

Diese Anleitung zeigt, wie standortübergreifende Rezeptverwaltung in einer Kette aufgebaut wird: vom Artikelstamm über das Rezept-Master mit lokalen Varianten bis zum Soll-Ist-Wareneinsatz je Standort. Sie richtet sich an Ketten, Franchisesysteme und Hotelgruppen ab etwa fünf Standorten. Die Schritte sind so beschrieben, wie wir sie bei Einführungen mit FoodNotify durchführen; sie gelten im Kern für jedes System, das einen zentralen Artikelstamm hat.

Warum Rezepte ohne Artikelstamm nicht standortübergreifend funktionieren

Ein Rezept ist eine Liste von Artikeln mit Mengen. Solange jeder Standort seine Artikel selbst anlegt, ist „Hackfleisch gemischt“ in Hamburg ein anderer Artikel als in München, mit anderem Gebinde, anderem Preis und anderer Nummer. Ein zentrales Rezept kann darauf nicht aufsetzen. Deshalb ist der erste Schritt nie das Rezept, sondern der Artikelstamm: Jeder Artikel existiert genau einmal, mit GTIN oder Lieferantennummer, Gebinde und Grundeinheit. Preise kommen aus den Katalogen der Lieferanten, nicht aus Preislisten, die jemand abtippt.

Genau das war bei L'Osteria der Auslöser für den Wechsel des Systems: Artikel waren je Standort frei anlegbar, ein zentral verwalteter Artikelstamm fehlte. Über 200 Restaurants in Deutschland und Frankreich laufen heute auf einem Artikelstamm.

Schritt 1: Artikelstamm bereinigen und zentral führen

Sammeln Sie die Artikellisten aller Standorte und die Kataloge Ihrer Lieferanten. Dubletten werden zusammengeführt, jeder Artikel bekommt Gebinde (zum Beispiel Karton zu 6 × 1 kg) und Grundeinheit (kg, l, Stück). Lieferanten mit Katalog liefern diese Daten fertig; bei FoodNotify sind das über 1.000 Lieferanten, 126 davon direkt per Schnittstelle. Lieferanten ohne Katalog, etwa regionale Metzger oder Landwirte, werden angelegt; ihre Preise liest die Belegerkennung BEAM aus der Rechnung.

Legen Sie fest, wer Artikel anlegen darf. In einer Kette ist das die Zentrale oder eine benannte Person je Region, nicht jede Küche. Sonst wächst der Stamm innerhalb weniger Monate wieder auseinander.

Schritt 2: Rezept-Master mit Grund- und Zwischenrezepten

Bauen Sie Rezepte in Stufen: Grundrezepte (Fond, Sauce, Teig), Zwischenrezepte (Bolognese-Sauce) und Gerichte (Spaghetti Bolognese, Portion). Ein Grundrezept wird einmal gepflegt und in vielen Gerichten verwendet; ändert sich der Fond, ändern sich alle Gerichte mit. Jedes Rezept enthält Artikel, Menge, Ausbeute und Schwund (Putzverlust, Garverlust). Ohne Schwund liegt der theoretische Wareneinsatz zu niedrig, und die Soll-Ist-Auswertung zeigt später Differenzen, die keine sind.

Die Kalkulation je Portion rechnet mit den aktuellen Einkaufspreisen aus dem Artikelstamm. Steigt der Preis für Hackfleisch beim Lieferanten, sehen Sie am selben Tag, wie sich der Wareneinsatz der Bolognese je Standort verändert.

Schritt 3: Lokale Varianten erlauben, aber kontrollieren

Ketten brauchen einen Master und trotzdem lokale Abweichungen: ein regionaler Lieferant für Brot, ein saisonales Gericht nur in zwei Häusern, ein anderes Gebinde in Österreich. Die Regel: Der Master ist gesperrt, Varianten werden je Standort als Kopie mit Verweis auf den Master geführt und von der Zentrale freigegeben. So bleibt die Vergleichbarkeit erhalten, und die Zentrale sieht, welcher Standort wo abweicht und was das kostet.

Schritt 4: Allergene, Nährwerte und CO₂ automatisch mitführen

Allergene, Nährwerte und CO₂-Werte gehören an den Artikel, nicht an das Rezept. Kommen sie mit dem Lieferantenkatalog oder aus Datendiensten wie GS1, Trustbox, ecoinform oder Eaternity, rechnet das Rezept sie automatisch hoch. Tauschen Sie einen Artikel aus, ändert sich die Kennzeichnung mit. Für Gemeinschaftsverpflegung und Kantinen ist das die Grundlage der LMIV-Kennzeichnung; für Ketten ist es die Grundlage für Speisekarten, Webshops und Lieferplattformen, die alle dieselben Angaben brauchen.

Schritt 5: Rezepte mit der Kasse verknüpfen

Erst die Verknüpfung von Rezept und Kassenartikel macht aus der Kalkulation eine Steuerung. Jeder verkaufte Artikel an der Kasse ist ein Rezept mit einer Menge an Artikeln. Aus den Verkäufen entsteht der theoretische Wareneinsatz je Standort und Tag; aus Warenannahme, Umbuchungen und Inventur der tatsächliche. Die Differenz zeigt Schwund, falsche Portionen oder ungebuchte Bewegungen. Kassen wie Lightspeed, LINA und APRO laufen bei FoodNotify im Standard, andere werden über die offene API angebunden; die Kassenanbindung ist Teil der Pilot-Abnahme.

Wie groß dieser Hebel ist, hat eine Kette mit über 200 Standorten gemessen: Nach der Einführung lagen über 4 Prozentpunkte zwischen tatsächlichem und theoretischem Wareneinsatz, gemessen über drei Monate mit drei vollständigen Inventuren. Voraussetzung waren gepflegte Rezepturen, verknüpfte Kasse sowie Warenannahme und Inventur im System.

Schritt 6: Rollout in Phasen

Ein Standort läuft als Pilot. Dort werden Artikelstamm, Rezepte und Kasse abgenommen; erst wenn die Kassendaten stimmen und der Soll-Ist-Vergleich plausibel ist, folgen die weiteren Standorte mit denselben Vorlagen und Rechten. Bei fünf Standorten rechnen wir mit vier bis sechs Wochen. Küche, Einkauf und Zentrale bekommen getrennte Trainings, weil sie unterschiedliche Teile des Systems nutzen.

Was KI dabei heute leistet

Über den MCP-Server von FoodNotify greifen KI-Assistenten wie Claude oder ChatGPT direkt auf die Daten des Betriebs zu. Ein Küchenchef kann ein neues Gericht beschreiben und bekommt ein Rezept aus den Artikeln, die der Betrieb tatsächlich einkauft, kalkuliert mit den eigenen Einkaufspreisen, Allergenen und Nährwerten. Das ersetzt nicht die Freigabe durch die Zentrale, spart aber den Weg vom Einfall zur kalkulierten Rezeptur. Der Punkt dabei: Die KI ist nur so gut wie der Artikelstamm darunter. Ohne gepflegte Artikel und Preise rechnet sie mit Annahmen.

Checkliste: Rezeptverwaltung für Ketten

• Ein Artikelstamm für die Gruppe, Artikel existieren genau einmal, Anlage nur durch berechtigte Personen.
• Preise aus Lieferantenkatalogen, nicht aus abgetippten Listen.
• Rezepte in Stufen: Grundrezept, Zwischenrezept, Gericht; Ausbeute und Schwund gepflegt.
• Master gesperrt, lokale Varianten als freigegebene Kopie mit Verweis.
• Allergene, Nährwerte, CO₂ am Artikel, automatisch hochgerechnet.
• Jeder Kassenartikel einem Rezept zugeordnet; Soll-Ist-Wareneinsatz je Standort.
• Pilotstandort mit Kassenabnahme vor dem Rollout.

FAQ zur standortübergreifenden Rezeptverwaltung

Können einzelne Standorte eigene Rezepte haben?

Ja, als Variante des Masters, die von der Zentrale freigegeben wird. So bleibt die Vergleichbarkeit erhalten, und die Abweichung ist sichtbar.

Was passiert, wenn ein Lieferant den Preis ändert?

Kommt der Preis aus dem Katalog oder der Rechnung, rechnet das System alle Rezepte neu, in denen der Artikel vorkommt. Der Wareneinsatz je Gericht und Standort ist am selben Tag aktuell.

Brauchen wir für Allergene ein eigenes Werkzeug?

Nein, wenn Allergene und Nährwerte am Artikel geführt werden. Das Rezept rechnet sie hoch; Speiseplan und Kennzeichnung greifen darauf zu.

Wie lange dauert der Aufbau?

Bei FoodNotify übernimmt das Team den Artikelstamm aus den Lieferantenkatalogen. Bei fünf Standorten rechnen wir insgesamt mit vier bis sechs Wochen inklusive Pilot und Rollout; die Rezeptpflege selbst hängt von der Zahl der Gerichte ab.

Was kostet das?

FoodNotify Starter enthält Beschaffung und Rezepte und beginnt bei 174,90 Euro je Standort und Monat, ohne Beschränkung der Nutzerzahl. Preise und Onboarding