Eine Restaurantgruppe mit fünf Standorten sah 2018 im Backoffice deutlich anders aus als dieselbe Gruppe heute. Vor fünf Jahren war die Standardkonfiguration eine Sammlung von Tools, die jeweils ein einzelnes Problem lösten. Ein Kassensystem im Service. Buchhaltungssoftware im Büro. Eine Tabellenkalkulation für den Lagerbestand. Ein oder zwei Lieferantenportale für Bestellungen. Vielleicht noch ein separates Rezeptkalkulations-Tool, das jemand aktualisierte, wenn die Zeit es erlaubte. Keines dieser Systeme kommunizierte mit den anderen, und die Aufgabe, sie zusammenzuführen, fiel auf denjenigen, der den Daten am nächsten war.
Diese Konfiguration wird gerade aufgebrochen. In ganz Europa bauen Restaurantgruppen ihren Restaurant Tech-Stack rund um eine kleinere Zahl von Systemen neu auf, die Daten automatisch teilen. Der Trend geht klar in Richtung Konsolidierung: weniger Tools, tiefere Integrationen, weniger manueller Abgleich. Die Motivation dahinter ist einleuchtend. Das alte Modell erzeugt Margenverlusten an Stellen, die niemand im Blick hat, und die Kosten der Fragmentierung lassen sich immer schwerer rechtfertigen, seit die Integrationsmöglichkeiten gereift sind.
Das Backoffice der 2020er Jahre, das die meisten Gruppen noch haben
Der typische Betreiber mehrerer Standorte arbeitet noch immer mit fünf oder sechs Systemen, die nicht miteinander verbunden sind: ein Kassensystem für Umsätze, Buchhaltungssoftware für Rechnungen und Berichte, ein Inventurprozess in einer Tabellenkalkulation oder einer separaten App, eine Rezeptkalkulation, die oft manuell und veraltet ist, eine Bestellabwicklung über Lieferantenportale und E-Mail sowie ein Reporting-Layer, den meist jemand mit Excel zusammenbaut, der die Geduld dafür aufbringt.
Jedes Tool funktioniert nach seiner eigenen Logik. Das Problem liegt in den Schnittstellen zwischen ihnen. Umsatzdaten aus dem Kassensystem fließen nicht in das Rezeptsystem, sodass das Bild des tatsächlichen Verbrauchs nie sauber mit dem Verkauften übereinstimmt. Rechnungspositionen liegen in der Buchhaltungssoftware, erreichen aber nie die Rezeptkalkulation. Wenn ein Lieferant die Preise erhöht, gibt die Rezeptkarte noch immer die Zahlen aus dem Vorquartal an. Inventuren liefern eine Abweichung, aber diese lässt sich nicht auf das konkrete Gericht oder den Lieferanten zurückführen, der sie verursacht hat. Der Betreiber hat am Ende fünf verschiedene Wahrheiten und keine konsolidierte Übersicht.
Das ist der Hospitality Tech-Stack, den die meisten Gruppen aus einem Jahrzehnt der Einzellösungen geerbt haben. Er funktionierte, als Restaurants einen einzigen Standort betrieben und der Inhaber die Lücken aus dem Gedächtnis überbrückte. Über fünf oder fünfzehn Standorte hinweg funktioniert er nicht mehr.
Wie eine gute Integration aussieht
Das Muster, das sich bei Betreibern abzeichnet, die ihren Stack neu aufgebaut haben, ist einheitlich. Sie behalten zwei Anker und verbinden alles andere um sie herum. Das Kassensystem bleibt. Die Buchhaltungssoftware bleibt. Lagerbestand, Rezeptkalkulation, Lieferantenpreisdaten und Reporting wandern in eine Schicht, die von beiden Ankern liest und bei Bedarf zurückschreibt.
Der Wandel zielt darauf ab, die Lücken zwischen den Ankern zu schließen, sodass Daten in eine Richtung fließen, anstatt dreimal manuell erfasst zu werden. Die Anker selbst bleiben, wo sie sind. Betreiber haben bereits Jahre an Prozessen rund um Kassensystem und Buchhaltung aufgebaut, und der Neuaufbau lässt beides unangetastet, während er die Verbindungsschicht darunter einzieht.
Ein vernetzter Stack bedeutet: Eine in der Buchhaltung verarbeitete Rechnung aktualisiert auch die Rezeptkosten. Ein über das Kassensystem erfasster Umsatz zieht den theoretischen Lagerbestand entsprechend ab. Eine Inventur liefert eine Abweichung, die sich auf eine konkrete Zutat, einen konkreten Lieferanten und ein konkretes Gericht zurückverfolgen lässt. Restaurant Software-Konsolidierung ist der operative Ausdruck dieser Idee: weniger Systeme, mehr Verbindungen, weniger manueller Abgleich.
Warum Kassensystem und Buchhaltung bleiben
Beide Anker rechtfertigen ihren Platz aus demselben Grund. Sie sind ausgereifte Systeme, die hochvolumige Transaktionsdaten zuverlässig verarbeiten, und sie sitzen an den Punkten, an denen Geld in das Unternehmen fließt und es verlässt.
Das Kassensystem ist der Ort, an dem Umsätze erfasst werden und an dem das Personal in jeder Schicht arbeitet. Es ist zumutbar, ein Küchenteam gebeten, auch die Inventur in einem separaten System zu führen. Es ist nicht zumutbar, Umsätze in einem anderen System zu erfassen als dem, das es bereits kennt. Das Kassensystem ist nicht verhandelbar, und der kluge Schritt ist, rund um es zu integrieren, anstatt es zu ersetzen.
Bei der Buchhaltungssoftware gilt dasselbe von der anderen Seite. Rechnungen, Zahlungen, Lohnbuchhaltung und Steuerreporting liegen bereits dort, und die Finanzteams haben Jahre an Prozessen rund um ihre gewählte Plattform aufgebaut. Der vollständige Wechsel zu einem restaurantspezifischen Tool lohnt die Unterbrechung selten, besonders wenn eine Kassensystem-Buchhaltungs-Integration die meisten operativen Vorteile liefert, ohne diesen Schritt zu erzwingen.
Was sich ändert, ist das, was zwischen den beiden Ankern liegt. Die Verbindungsschicht ist der Ort, an dem die Konsolidierung tatsächlich stattfindet.
Warum der Lagerbestand das Bindegewebe ist
Der Lagerbestand ist die Schicht, die jeden anderen Teil des Stacks berührt. Er hängt von Rezepten ab, die von Lieferantenpreisen abhängen, die über die Buchhaltung eingehen. Er erzeugt Abweichungen, die nur Sinn ergeben, wenn sie mit Umsätzen aus dem Kassensystem abgeglichen werden. Wird der Lagerbestand sauber aufgebaut, zieht er den Rest des Restaurant-Inventar-Software-Stacks fast automatisch in eine einheitliche Ansicht.
Drei Dinge machen das möglich. Erstens die automatisierte Rechnungsverarbeitung, damit Lieferantenpreise und eingekaufte Mengen ohne manuelle Eingabe ins System fließen. Zweitens die Kassensystem-Integration, damit der theoretische Verbrauch anhand der tatsächlichen Umsätze berechnet werden kann. Drittens eine Rezeptkalkulation, die sich in Echtzeit aktualisiert, wenn sich Lieferantenpreise ändern, anstatt eingefroren zu bleiben, bis jemand Zeit findet, sie zu überarbeiten.
Wenn diese drei Teile verbunden sind, erhält der Betreiber eine Übersicht, die der alte Stack nie liefern konnte. Er sieht, was eingekauft wurde, was verkauft wurde, was hätte verbraucht werden sollen, und was tatsächlich gezählt wurde. Die Lücke zwischen diesen Zahlen ist der Ort, an dem Marge verloren geht, und zum ersten Mal wird sie nachvollziehbar.
Deshalb betrachten so viele Gruppen den Lagerbestand heute als Integrations-Hub und nicht mehr als Nebenprozess. Sobald der Lagerbestand sauber mit Kassensystem und Buchhaltung verbunden ist, ergibt sich der Rest des Reporting-Layers weitgehend von selbst. Wie sich das über mehrere Standorte hinweg auswirkt, lesen Sie in unserem Leitfaden zur Wareneinsatzkontrolle für Restaurantgruppen.
Was wegfällt
Die Teile, die aus dem modernen Stack verschwinden, sind genau die, die nur existierten, weil die anderen Tools nicht miteinander kommunizieren wollten.
Der größte Teil ist der manuelle Abgleich. Die Arbeit, Rechnungssummen aus der Buchhaltung zu entnehmen, sie mit einer Tabellenkalkulation der erwarteten Zutatenkosten zu vergleichen und Rezeptkarten dann einzeln zu aktualisieren, hat früher jemanden einen halben Tag pro Woche gekostet. Mit einer Restaurant-Technologie-Integration zwischen Buchhaltung und Rezeptschicht entfällt diese Arbeit vollständig.
Der zweite Teil sind die standortspezifischen Tabellenkalkulationen. Eine Gruppe mit acht Standorten pflegte früher acht Versionen derselben Kostentabelle, jede von einem anderen Manager in einem anderen Rhythmus aktualisiert. Wenn der Inventur-Layer aus einer einzigen Quelle zieht, werden diese Tabellen nicht mehr erstellt. Konsolidiertes Reporting wird zum Nebeneffekt der Integration, nicht zum eigenen Projekt. Betreiber, die komplett von tabellenbasierter Kalkulation wegwollen, finden in unserem Artikel eine Übersicht, warum Inventarsoftware Excel ersetzt.
Der dritte Teil ist das Wechseln zwischen Lieferantenportalen. Betreiber loggten sich früher jede Woche in drei oder vier Lieferantenportale ein, um Preise zu prüfen, und übertrugen das Ergebnis dann in eine Tracking-Tabelle. Wenn Rechnungsdaten automatisch in den Inventur-Layer fließen, werden die Portale zur Reserve, nicht mehr zum täglichen Ziel. Die Lieferantenpreisentwicklung erklärt sich von selbst, und die Arbeit des Lieferantenpreis-Trackings verschiebt sich vom Datensammeln zum Handeln.
Der vierte Teil ist die doppelte Dateneingabe, und sie ist die am stillsten teuerste. Im alten Stack musste eine einzige Information oft an zwei oder drei Stellen erfasst werden: im Kassensystem, in der Inventartabelle, im Rezept-Tool. Jede Eingabe war eine Fehlerquelle. Ein konsolidierter Stack beseitigt diese Fehlerquellen durch sein Grundprinzip.
Was das für Gruppen bedeutet, die noch am alten Stack festhalten
Der Trend ist weniger ein Maßstab und mehr ein Signal dafür, wo sich die operative Lücke vergrößert. Gruppen, die ihren Stack neu aufgebaut haben, erzielen sauberere Abweichungszahlen, reagieren schneller auf Lieferantenpreisänderungen und verbringen weniger Zeit mit dem Abgleich von Daten. Gruppen, die das nicht getan haben, führen noch immer dieselbe manuelle Arbeit durch wie ihre Teams vor fünf Jahren und nehmen denselben Margenabbau an denselben Stellen hin.
Der Neuaufbau ist selten ein einzelnes Projekt. Die meisten Betreiber kommen schrittweise dorthin. Sie beginnen damit, Buchhaltung und Inventur zu verbinden, fügen dann die Kassensystem-Integration hinzu und verlagern anschließend die Rezeptkalkulation in dieselbe Schicht. Ein sinnvoller erster Schritt für Gruppen, die das in Betracht ziehen, ist ein Blick darauf, wie ihr aktuelles Wareneinsatz-Tracking-System Daten zwischen Tools weitergibt, und die Identifikation der Stellen, an denen Informationen doppelt erfasst oder zwischen Tabellen kopiert werden.
An diesen Stellen entsteht der Verlust. Sie zu schließen ist das, wofür der moderne Stack gebaut ist.
An welchen Stellen in Ihrem Stack wechseln Sie noch immer zwischen Tools, die eigentlich miteinander kommunizieren sollten?