Ein Rezept, drei Systeme: ERP, Kassensystem und CalcMenu synchron halten

Drei Systeme, ein Datenbestand

Ein grosser Multi-Outlet-Betrieb im Food-Service — ein Resort mit mehreren Restaurants und Bars, ein Stadion mit Verkaufsständen, eine Kreuzfahrtreederei mit einem Dutzend Gastronomiebereichen — läuft typischerweise auf drei getrennten Systemen, die sich alle auf dieselben zugrunde liegenden Fakten stützen müssen. Ein ERP (häufig etwas wie JD Edwards) verantwortet den Einkauf: Artikelnummern, Mengeneinheiten und Preise für alles, was bei Lieferanten bestellt wird. Eine POS-Plattform (häufig etwas wie Oracle Simphony) verantwortet die Kasse: was verkauft wird, zu welchem Preis, in welchem Outlet. Und ein Rezeptverwaltungssystem wie CalcMenu verantwortet das Lebensmittel selbst: Rezepte, Kalkulation, Nährwerte und Allergene.

Keines dieser drei Systeme ist falsch darin, für seinen eigenen Bereich die führende Datenquelle zu sein. Das Problem entsteht, wenn niemand für die Beziehung zwischen ihnen zuständig ist — und am Ende jemand denselben Warenartikel manuell zwei- oder dreimal erfasst, mit dem unvermeidlichen Auseinanderdriften, das darauf folgt.

Was die Schnittstelle tatsächlich leisten muss

Man ist schnell versucht, sich “eine ERP-Schnittstelle” als eine einzige Leitung vorzustellen. In der Praxis muss sie zwei unterschiedliche Probleme in zwei unterschiedlichen Richtungen lösen:

Einkaufsdaten hereinholen. Im ERP liegen die eingekauften Artikel — Artikelnummern, Einheiten und Preise. Eine Schnittstelle, die diesen Export einliest und mit den Artikelstammdaten in CalcMenu abgleicht, sorgt dafür, dass ein Küchenteam Einkaufsdaten, die anderswo bereits existieren, nie noch einmal von Hand erfasst; die Daten fliessen einmal ein und steuern die Kosten-, Nährwert- und Allergenwerte jedes Rezepts, das den Artikel verwendet. Eine typische Stolperfalle: ERPs führen oft eine Basiseinheit (Kilogramm, Liter) getrennt von einer Bestelleinheit (Stück, Karton, Tablett) mit eigenem Preis. Die Schnittstelle muss beide Einheiten und das Umrechnungsverhältnis dazwischen übertragen — sonst lässt sich ein nach Gewicht kalkuliertes Rezept nicht mit einem nach Karton eingekauften Bestand abgleichen.

Rezeptkosten hinausschicken. Auf der POS-Seite braucht die Kasse nicht das Rezept, wie CalcMenu es sieht, sondern die tatsächlichen Kosten pro verkaufter Portion, zugeordnet zu einem bestimmten Outlet. Sobald Chargenrezepte im Spiel sind, ist das eine andere Zahl als die Kosten pro Rezeptausbeute — die Exportlogik muss deshalb auf die Portionsdefinition des Kassensystems ausgelegt sein, nicht auf die von CalcMenu.

Für Betriebe mit mehreren verbundenen Outlets, die sich eine Küche oder ein Lager teilen, kommt häufig noch ein dritter Baustein hinzu: die Liste der transferfähigen Produkte im ERP mit dem abgleichen, was im Rezeptsystem tatsächlich noch aktiv ist, damit ein ausgelisteter Artikel nicht weiterhin als gültige Option für Warenbewegungen zwischen Standorten auftaucht.

Warum sie von Anfang an erweiterbar gebaut sein muss

Eine solche Schnittstelle ist nie wirklich “fertig”. Konventionen für Mengeneinheiten werden nachträglich vereinheitlicht. Die POS-Exportlogik wird korrigiert, sobald auffällt, dass sie auf der falschen Kostenbasis gerechnet hat. Ausgelistete Produkte brauchen eine eigene Behandlung, damit sie nicht mehr dort auftauchen, wo sie nicht mehr hingehören. Und irgendwann wechselt das Rezeptsystem selbst auf eine neue Plattform — was bedeutet, dass die Schnittstelle mitziehen muss, statt von Grund auf neu gebaut zu werden. Eine Schnittstelle, die als eine einzige starre Leitung konzipiert ist, bricht beim ersten dieser Ereignisse; eine Schnittstelle mit einer klaren Mapping-Schicht zwischen den Systemen fängt jede Änderung als kleines, klar abgegrenztes Update ab.

Der Nutzen, konkret

Richtig umgesetzt, nimmt diese Art von Integration einen konkreten, wiederkehrenden Kostenfaktor weg, statt bloss ein Feature um seiner selbst willen hinzuzufügen:

1. Keine doppelte Erfassung von Warendaten. Artikelnummern, Einheiten und Preise existieren einmal im ERP und fliessen automatisch in die Rezeptkalkulation ein.
2. Das Kassensystem spiegelt den tatsächlichen Food-Cost, nicht eine veraltete Schätzung. Menu Engineering und Rentabilitätsanalysen arbeiten mit aktuellen Kosten pro Portion statt mit einer Tabelle, die jemand letztes Quartal aktualisiert hat.
3. Warentransfers zwischen Outlets hängen nicht davon ab, dass jemand daran denkt, das ERP von Hand zu pflegen.
4. Die Integration übersteht Veränderungen, statt daran zu zerbrechen — Neugestaltungen der Mengeneinheiten, Korrekturen der POS-Exportlogik und Plattformwechsel auf der Rezeptverwaltungsseite werden zu schrittweisen Updates statt zu neu zu verhandelnden Projekten.

Dieses Muster taucht überall dort auf, wo ein Multi-Outlet-Betrieb seinen Food-Service auf einem Enterprise-Backoffice aufbaut: Resorts, Kreuzfahrtreedereien, Airline-Catering und Hotelgruppen mit mehreren Marken stossen alle darauf, sobald sie eine Handvoll Outlets überschreiten. Mehr dazu, wie die Integrationsschicht von CalcMenu dasselbe Prinzip über verschiedene ERP- und POS-Plattformen hinweg anwendet, finden Sie unter POS-Systemintegrationen.

---

Betreiben Sie Food-Service über mehrere Outlets hinweg auf einer ERP- und POS-Landschaft und haben genug davon, dieselben Warendaten doppelt zu erfassen? Vereinbaren Sie ein 15-minütiges Gespräch: Termin buchen.