Ein Menü über 100 Standorte hinweg zu ändern, sollte keine Woche dauern

Bei den meisten Gastronomie- und Hotelunternehmen mit mehreren Standorten umfasst der Projektplan für die „Aktualisierung der Frühlingskarte im gesamten Betrieb“ vier Seiten und drei Wochen.

Woche eins ist für das Menu-Engineering-Tool reserviert: Kalkulation, Allergenprüfung, Fotografie, Freigabe durch den Executive Chef. Woche zwei gehört der Rollout-Koordination: E-Mails an die General Manager, Schulungsunterlagen für die Küchenbrigaden, FAQ-Dokumente für das Servicepersonal. Woche drei bringt die eigentliche technische Bereitstellung: Export der neuen Speisekarte aus dem Menu-Engineering-Tool, Upload in das Portal des EPOS-Anbieters, Pushing auf jede einzelne Kasse, separates Aktualisieren des Website-CMS, erneute separate Synchronisierung mit der Online-Bestellplattform, Sicherstellen, dass die Tablets für das In-Room-Dining dieselbe Speisekartenversion erhalten, und schließlich das Hoffen und Bangen, dass die QR-Bestellbildschirme in den Biergärten auf die richtige Speisekarten-Datei verweisen.

Während des Rollouts zeigen verschiedene Kassen am selben Standort möglicherweise stundenlang unterschiedliche Speisekartenversionen an. Auf der Website stehen vielleicht Preise, die nicht mit der Kasse übereinstimmen. Über den Online-Bestellkanal werden womöglich Gerichte beworben, die die Küche längst gestrichen hat. Und das Tablet im Hotelzimmer zeigt eventuell immer noch die Karte der letzten Saison, weil niemand wusste, dass es separat aktualisiert werden musste.

Das ist keine Übertreibung. Das ist die operative Realität in jedem Multi-Site-Gastronomieunternehmen mit veralteter Systemarchitektur. Der Food & Beverage Director hat es als unvermeidbaren Aufwand akzeptiert. Das IT-Team bringt für Speisekarten-Rollouts schon lange keine Begeisterung mehr auf. Und das Kundenserviceteam verfügt über Leitfäden für den Umgang mit den unvermeidlichen Beschwerden nach dem Motto „Aber auf der Website stand £14“.

In diesem Artikel geht es darum, warum das nicht so sein muss – und wie eine Architektur aussieht, bei der es anders läuft.

Der architekturbedingte Grund, warum Speisekarten-Rollouts so langsam sind

Die Langsamkeit hat eine fundamentale Ursache: In den meisten Systemarchitekturen wird die Speisekarte in jedem System dupliziert, das Zugriff darauf benötigt. Das EPOS hat seine eigene Kopie. Das CMS hat seine Kopie. Die Online-Bestellplattform hat ihre Kopie. Das In-Room-Tablet hat seine Kopie. Der QR-Bestellbildschirm hat seine Kopie. Das Menu-Engineering-Tool hat seine Kopie. Jede Kopie befindet sich in einer anderen Datenbank mit einem anderen Schema und gehört einem anderen Anbieter.

Wenn sich die Speisekarte ändert, muss jede einzelne Kopie aktualisiert werden. Jedes Update ist ein separater Vorgang. Jeder Vorgang birgt eigene Fehlerquellen. Die Integrationsschicht, die eigentlich für die Synchronisierung sorgen sollte, existiert nur teilweise, arbeitet mit eigener Latenz und fällt geräuschlos aus – worauf man erst zwei Tage später durch Kundenbeschwerden aufmerksam wird.

Diese Architektur hat historische Gründe. Jedes System wurde separat gekauft, zu einem anderen Zeitpunkt, aus einem anderen Grund. Das Menu-Engineering-Tool war die jüngste Neuanschaffung. Das EPOS war eine Beschaffungsentscheidung aus dem Jahr 2018. Das CMS stammt von noch davor. Jeder Anbieter hat sein eigenes Speisekartenmodell entwickelt, weil er musste: Sein Produkt benötigt eine Speisekartenstruktur, um zu funktionieren, und keiner konnte sich darauf verlassen, dass die Struktur eines anderen Anbieters verfügbar ist.

So hat am Ende jeder Betreiber mit einer fragmentierten Systemlandschaft fünf oder sechs „Speisekarten“, die alle dieselben Gerichte beschreiben. Und jeder Betreiber hat einen (formellen oder informellen) Arbeitsablauf entwickelt, um diese fünf oder sechs Speisekarten synchron zu halten. Und jeder Betreiber hat akzeptiert, dass diese Synchronisierung manchmal fehlschlägt.

Was sich ändert, wenn es nur eine führende Speisekarte gibt

Die mDOS-Architektur verfolgt einen anderen Ansatz. Es gibt genau eine Speisekarte. Sie wird einmalig für das gesamte Unternehmen verwaltet, mitsamt ihren Kategorien und Gerichten. Jeder Standort wird ihr einfach zugewiesen: keine Kopie der Speisekarte, sondern lediglich eine Zuweisung, ergänzt durch optionale Überschreibungen für standortspezifische Unterschiede.

Dies ist ein grundlegend anderes Datenmodell. Es gibt keine Duplizierung. Die Website, das EPOS, das In-Room-Tablet, der QR-Bildschirm und der Online-Bestellkanal greifen alle auf dieselben Datensätze zu. Eine Änderung an einem Gericht erfordert keine Synchronisierung pro Ausgabekanal, da es nur eine einzige Kopie gibt.

Da jeder Ausgabekanal aus dieser zentralen Quelle liest, spiegelt sich eine Änderung an der Speisekarte überall dort sofort wider, wo die Karte als Nächstes abgerufen wird (beim Laden einer Seite oder beim Abfragen der Speisekarte durch ein Terminal). Es gibt keine Kopie, die verteilt oder zwischen Anbietern abgeglichen werden muss. Für die eine Änderung, die mitten im Service greifen muss, ohne auf ein erneutes Abrufen zu warten (das Ausbuchen bzw. „86’ing“ eines ausverkauften Gerichts), überträgt ein Live-Broadcast-Kanal die Änderung in Echtzeit an jeden verbundenen Ausgabekanal (siehe den Abschnitt zum Ausbuchen weiter unten).

Gemessene Latenz vom Klick des Anwenders auf „Speichern“ im Menü-Builder bis zur Live-Schaltung der Änderung auf jedem verbundenen Ausgabekanal im gesamten Betrieb: ca. 200 milliseconds im 95th percentile.

Das ist kein theoretischer Wert. Ein einziger Datenbank-Schreibvorgang, der über einen einzigen WebSocket-Kanal verteilt wird, führt dazu, dass jede Kasse an jedem Standort innerhalb einer halben Sekunde den neuen Status anzeigt. Es gibt kein Zeitfenster für Versionsabweichungen. Es gibt keinen Upload-Schritt pro Terminal. Es gibt kein Warten.

Das Überschreibungssystem, das die Skalierbarkeit im gesamten Betrieb ermöglicht

Eine naiv umgesetzte Architektur nach dem Prinzip „Eine Speisekarte“ würde erzwingen, dass jeder Standort identisch ist. Das Landhotel mit dem Degustationsmenü für £180 und die Weinbar in der Innenstadt mit den Kleinigkeiten für £14 müssten völlig getrennte Speisekarten führen, was den Vorteil der Zentralisierung zunichtemachen würde.

mDOS löst dies durch das Überschreibungssystem. Die Basisspeisekarte wird einmalig auf Unternehmensebene definiert. Die Zuweisung jedes Standorts enthält einen kleinen Satz von Überschreibungen, die jedes Feld jedes Artikels ändern können: Preis, Name, Beschreibung, Verfügbarkeit, Allergene, Kennzeichnungen zur Ernährungsweise, Kalorien, Bild, Getränkeart, ABV, Roomservice-Verfügbarkeit, Roomservice-Preis, Modifier-Gruppen, Preise für Modifier-Optionen, Kategorieplatzierung, Zeitfenster-Verfügbarkeit oder die Sichtbarkeit ganzer Kategorien.

Der Resolver läuft rein clientseitig, nachdem die Speisekarte geladen wurde. Die Auflösungskaskade lautet Basis → Gruppe → Standort, wobei die Überschreibung des Standorts auf jeder Feldebene Priorität hat. Der Überschreibungssatz liegt typischerweise unter 1KB pro Standort. Die Auflösungslatenz liegt im sub-millisecond-Bereich.

Was das operationell bedeutet: Eine Gruppe mit 50 Standorten kann eine einzige „Frühlingskarte“-Definition mit 50 standortspezifischen Überschreibungssets nutzen. Diese regeln lokale Preise, regionale Zutatenanpassungen, standortspezifische Verfügbarkeitsfenster und individuelle Fotografie. Eine Änderung der Basiskarte (z. B. das Entfernen eines gestrichenen Gerichts) wird sofort auf alle 50 Standorte übertragen. Eine Änderung an der Überschreibung eines einzelnen Standorts (z. B. eine Preiserhöhung für das Steak im Londoner Betrieb) betrifft nur diesen Standort, ohne die Basis zu verändern.

Die herkömmliche Alternative sind 50 separate Speisekarten-Dateien, die alle manuell gepflegt werden müssen und bei jeder Änderung der Basis einzeln aktualisiert werden müssen. Abweichungen zwischen ihnen sind unvermeidlich. Der administrative Aufwand ist erheblich. Das Fehlerrisiko ist permanent präsent.

Die Veröffentlichungssperre nach Natasha's Law

In Großbritannien verpflichtet die Food Information Regulation (gemeinhin bekannt als Natasha's Law) Gastronomiebetriebe dazu, vollständige Allergeninformationen für alle vor Ort zubereiteten und verpackt verkauften Lebensmittel bereitzustellen. Verstöße ziehen erhebliche behördliche Strafen und in extremen Fällen eine strafrechtliche Haftung nach sich.

Die meisten Speisekarten-Systeme in der Gastronomie regeln die Allergen-Compliance im Anwendungscode. Der Menü-Builder zeigt eine Warnung an, wenn Allergene fehlen. Der Veröffentlichungs-Workflow prüft auf Vollständigkeit. Das Schulungsmaterial erinnert das Personal daran, Allergene vor der Veröffentlichung zu überprüfen. All dies kann von unkonzentrierten oder entschlossenen Bedienern umgangen werden.

mDOS regelt dies auf der Datenbankebene. Jede Speisekarte enthält einen Allergenstatus. Positionen, die noch auf eine Verifizierung warten, können nicht veröffentlicht werden: Eine Datenbankregel bricht den Veröffentlichungsvorgang ab, sobald ein unverifiziertes Gericht enthalten ist. Die Verifizierung erfordert eine explizite Aktion: Ein angemeldeter Benutzer mit der entsprechenden Rolle markiert die Position als verifiziert, und die Datenbank zeichnet für den Audit-Trail auf, wer sie wann verifiziert hat.

Das ist keine Entscheidung des UX-Designs. Es ist eine architektonische Entscheidung. Die Datenbank verweigert die Veröffentlichung unverifizierter Positionen – unabhängig davon, über welche Schnittstelle die Veröffentlichung versucht wird, welcher Benutzer sie durchführt oder was der Anwendungscode für akzeptabel hält. Die Compliance-Sperre kann nicht umgangen werden, da sie auf der Ebene unterhalb der Anwendung erzwungen wird.

Für Betreiber mehrerer Standorte ist dies bei Audits von entscheidender Bedeutung. Prüfbehörden kann die Sperre direkt auf Datenbankebene nachgewiesen werden. Kein Richtliniendokument, kein Schulungszertifikat, sondern die tatsächliche Datenbankregel, die nicht-konforme Veröffentlichungen verhindert. Die Compliance-Haltung wandelt sich von einer prozeduralen zu einer architektonischen.

Echtzeit-Streichung („86'ing“): Der operative Moment der Wahrheit

Einführungen neuer Speisekarten sind das geplante Szenario. Das ungeplante Szenario (und das operativ entscheidendste) ist die Streichung während des laufenden Service („86'ing“). Der Küche geht eine Zutate aus. Das Gericht muss sofort von der Karte genommen werden. An jedem Verkaufspunkt muss der Verkauf unverzüglich gestoppt werden.

In einer fragmentierten Systemlandschaft ist dies ein manueller Prozess. Der Küchenchef informiert den Restaurantleiter. Der Restaurantleiter geht zu jeder Kasse und aktualisiert sie. Die Website zeigt das Gericht so lange an, bis jemand daran denkt, es dort zu aktualisieren. Der Online-Bestellkanal nimmt weiterhin Bestellungen entgegen, die die Küche nicht erfüllen kann. Die QR-Bildschirme im Biergarten zeigen es weiterhin an.

mDOS verarbeitet das Ausblenden mit einem einzigen Schalter. Der Restaurantleiter tippt in der Menüverwaltungs-Oberfläche beim Gericht auf „Nicht verfügbar“. Das Update markiert die Speise mit einem Zeitstempel als nicht verfügbar, und ein Live-Broadcast-Kanal für Ihr Unternehmen überträgt die Änderung nahezu verzögerungsfrei an jede verbundene Oberfläche: Jede Kasse blendet das Gericht aus, jeder QR-Bildschirm graut es aus, jede Online-Bestellschnittstelle markiert es als ausverkauft, jedes Tablet im Zimmer verbirgt es.

Die Küche erhält keine weitere Bestellung für das gestrichene Gericht. Der Küchenchef muss sich nicht beim nächsten Tisch entschuldigen. Die Servicekraft muss nicht verlegen in die Küche zurückkehren. Dem Gast bleibt die Enttäuschung erspart, etwas zu bestellen, das nicht serviert werden kann.

Für hochfrequentierte Betriebe (geschäftige Freitagabende, ausgebuchte Abendservices, Stoßzeiten an Touristenhotspots) ist dies von enormer Bedeutung. Jede Minute Verzögerung zwischen „gestrichen“ und „tatsächlich überall gestrichen“ ist eine Minute, in der sich Probleme anhäufen. mDOS reduziert diese Latenz auf eine halbe Sekunde.

Was das für den F&B-Director bedeutet

Für den Food and Beverage Director einer Gruppe mit mehreren Standorten war die Speisekartenverwaltung bisher eine der operativ frustrierendsten Einschränkungen in seiner Rolle. Die technische Realität hat die Handlungsmöglichkeiten stark begrenzt. Saisonal bedingte Menü-Refreshes sind vierteljährliche Großprojekte, deren Einführung drei Wochen dauert. Anpassungen unter der Saison sind organisatorisch aufwendig. Sie erfordern Abstimmungen mit der IT, dem Betrieb, dem Marketing und dem Brand-Team. Bis die Anpassung schließlich umgesetzt ist, ist die Gelegenheit bereits verstrichen.

In einer einheitlichen Architektur kann der F&B-Director Menüänderungen genau so umsetzen, wie er es möchte. Die Frühlingskarte geht am Montagmorgen in allen 200 Betrieben gleichzeitig live. Eine unterwöchige Anpassung basierend auf den ersten Verkaufsdaten wird am Mittwochnachmittag veröffentlicht. Eine zeitlich begrenzte Werbeaktion startet am Freitag mit standortspezifischen Überschreibungen für regionale Preise. Die Technologie ist nicht länger der Flaschenhals für die Arbeit des F&B-Bereichs.

Für Investoren und Käufer, die mDOS als geistiges Eigentum (IP) bewerten, ist die architektonische Ausgereiftheit des Speisekartenverwaltungs-Subsystems ein klares Indiz. Die meiste Gastronomie-SaaS behandelt die Menüverwaltung als peripheres Feature: eine einfache Bearbeitungsmaske über der Speisekartentabelle eines Anbieters mit begrenzter Verteilungslogik. mDOS behandelt sie als Kern-Subsystem mit derselben Präzision wie die Payment-Engine: kanonisches Single-Source-Datenmodell, atomare Operationen, broadcast-basierte 86-Verteilung, Compliance-Sperren auf Datenbankebene. Die hier gezeigte Entwicklungstiefe lässt auf die technische Qualität des gesamten Systems schließen.

---

Das Subsystem für die Speisekartenverwaltung übernimmt die Auflösung von Basis- und Überschreibungswerten, die broadcast-basierte 86-Verteilung sowie die Allergen-Verifizierungssperre nach Natasha's Law. Die technische Dokumentation ist unter einer beidseitigen Geheimhaltungsvereinbarung (NDA) erhältlich.