Multi-Brand-Restaurantgruppen: Warum eine Datenbank pro Marke scheitert

Worüber eine Multi-Brand-Restaurantgruppe tatsächlich entscheidet

Die Bestandsstruktur einer Multi-Brand-Gruppe ist die Summe der Entscheidungen darüber, wie viele getrennte Datenbanken Sie betreiben und wo die Grenzen zwischen ihnen verlaufen. Die eigentliche Frage lautet nicht ein System oder viele. Sie lautet, welche Marken sich eine Datenbank teilen und welche ihre eigene bekommen, und die meisten Gruppen beantworten sie mit der falschen Regel.

Der erste Impuls ist, jeder Marke ihre eigene Datenbank zu geben, weil sich die Marken separat anfühlen. In der Praxis läuft eine Gruppe auf drei Ebenen. Die Gruppe ist das oberste Konto, in dem das Reporting zusammenläuft. Jedes Outlet ist eine Marke oder Einheit, die eigene Lieferantenbeziehungen, Bestände und Kostenstellen führt. Jeder Standort ist ein physischer Ort unter einem Outlet. Ein Dashboard auf Gruppenebene aggregiert alle Outlets, sodass Sie Wareneinsatz und Abweichung markenübergreifend aus einer Ansicht vergleichen können, ohne sie in dieselbe Datenbank zwingen zu müssen.

Genau dieser letzte Punkt macht den Reflex "eine Datenbank je Marke" teuer. Getrenntes Reporting erfordert keine getrennten Datenbanken. Sie erhalten den markenübergreifenden Vergleich aus der Gruppenebene, unabhängig davon, wie die darunterliegenden Datenbanken geschnitten sind, und das gibt Ihnen die Freiheit, sie entlang der Achse zu ziehen, die tatsächlich Arbeit spart.

Warum eine Datenbank pro Marke unter ihrer eigenen Wartung zusammenbricht

Eine Datenbank pro Marke scheitert, weil gemeinsam genutzte Daten in jeder Datenbank gepflegt werden müssen, die sie enthält. Eine Lieferantenpreisänderung, eine neue Gebindegröße, eine umbenannte Zutat: Jede Bearbeitung wird per Hand in jeder Markendatenbank wiederholt, die diesen Artikel führt. Je mehr Marken Sie aufteilen, desto häufiger führen Sie dieselbe Änderung erneut aus.

Nehmen Sie eine Gruppe mit sechs Marken, die überwiegend bei denselben Lieferanten einkaufen. Bei einer Datenbank pro Marke sind es bei einer einzigen Preisänderung eines gemeinsamen Lieferanten sechs manuelle Aktualisierungen. Fassen Sie die Marken, die sich Lieferanten teilen, in drei Datenbanken zusammen, und dieselbe Änderung sind zwei Aktualisierungen. Der Aufwand skaliert nicht damit, wie sorgfältig Sie die Marken getrennt haben. Er skaliert damit, wie viele Datenbanken dieselben Lieferanten- und Produktstammdaten wiederholen.

Das ist der Einwand, den Gruppen sich meist selbst vor Augen führen, sobald sie den Alltag durchspielen. Die Marken sehen unabhängig aus, ihr Einkauf ist es nicht, und die Datenbankstruktur muss dem Einkauf folgen, nicht dem Markenschema. Ein Basisartikel mit den je Lieferant verknüpften Gebindegrößen, der über die Outlets hinweg synchron gehalten wird, zahlt sich nur dann aus, wenn die Outlets, die ihn teilen, in derselben Datenbank sitzen.

Die eigentliche Trennung: Überschneidung von Lieferanten und Produkten, nicht die Zahl der Marken

Trennen Sie Datenbanken entlang zweier Achsen: wie stark Lieferanten und Produkte sich überschneiden und ob die Marken im selben Land und derselben rechtlichen Einheit sitzen. Konsolidieren Sie Marken, die sich Lieferanten und Produkte teilen; trennen Sie, wo sie es wirklich nicht tun, und trennen Sie über Ländergrenzen hinweg wegen Steuern und Währung. Die Zahl der Marken geht in diese Regel nie ein.

Lesen Sie sie als vier Situationen. Hohe Überschneidung in einem Land ist eine klare Konsolidierung: Führen Sie diese Marken gemeinsam und pflegen Sie jeden Artikel nur einmal. Geringe Überschneidung in einem Land ist eine saubere Trennung nach Konzept, weil das Erzwingen unverwandter Artikel in ein gemeinsames Mapping später eigene Aufräumarbeit erzeugt. Verschiedene Länder trennen fast immer, denn Steuern, Währung und rechtliche Einheit ziehen eine harte Linie; wo Konzepte innerhalb eines Landes trotzdem Lieferanten teilen, ist eine Datenbank pro Land mit diesen zusammengeführten Konzepten meist die Form, die sich einspielt.

Eine sinnvolle Gegenprüfung, auf die Betreiber landen, ist eine Datenbank für die Kernmarke plus eine zusammengefasste Datenbank für die Konzepte, die alles gemeinsam haben. Sie folgt derselben Überschneidungslogik aus der anderen Richtung, weshalb sie standhält. Wenn sich Ihre vorgeschlagene Struktur nicht durch Lieferanten- und Produktüberschneidung oder eine Ländergrenze rechtfertigen lässt, ist es eine Struktur auf Basis von Markenidentität, und sie wird Sie in der Wartung kosten.

Die Zentralküche ist ein eigener Standorttyp und zugleich Lieferant Ihrer Outlets

Eine gruppeneigene Zentralküche oder Bäckerei ist kein Lieferant, den Sie von außen andocken, und sie ist auch nicht nur ein weiteres Outlet. In Supy ist sie ein eigener Standorttyp, der neben Ihren Outlets verwaltet wird, aber mit anderer Funktionalität. Sie betreiben sie als Standort mit eigenem Bestand, eigener Produktion und eigenem Bestellwesen, und sie agiert als Lieferant gegenüber den Marken, die sie versorgt: Sie nimmt deren Bestellungen entgegen, bestellt in deren Namen, versendet gegen Lieferscheine und stellt mit Aufschlag in Rechnung. Beide Rollen sind erstklassig ausgelegt, ein Standort, den Sie innerhalb der Gruppe verwalten, und ein Lieferant Ihrer Outlets, was ein reines Outlet genau nicht sein kann.

Wenn Sie sie als reines Outlet einrichten, das Bestand nur zum Einstandswert transferiert, verbergen Sie zwei Dinge, die Sie brauchen: den tatsächlichen Landed Cost beim empfangenden Outlet und die Marge, die die Zentralküche intern erwirtschaftet. Weil sie ein verwalteter Standort und zugleich ein Lieferant ist, hält das Abrechnen der belieferten Standorte mit einem Aufschlag beides sichtbar, während die Küche wie jeder andere Standort in dasselbe Gruppen-Reporting einläuft. Verkauft sie zusätzlich an Restaurants außerhalb der Gruppe, läuft dieser externe Bestellfluss getrennt vom internen, sodass die gruppeninterne Beziehung sauber bleibt.

Echte Bestandsbewegungen, die kein Verkauf sind, etwa das kurzfristige Ausleihen einer Kiste zwischen zwei Standorten, gehören weiterhin in einen Standortwechsel, den der empfangende Standort annimmt, bevor sich sein Bestand aktualisiert. Der Test ist einfach: Wenn eine Seite die andere mit Aufschlag berechnet, ist es die Zentralküche als Lieferant; wenn Bestand nur zum Einstandswert bewegt wird, ist es ein Transfer.

Entscheiden Sie über die Bestandsstruktur der Gruppe vor dem Onboarding, nicht währenddessen

Legen Sie die Struktur als schriftlich fixierten Satz von Entscheidungen fest, bevor das Onboarding beginnt. Der teuerste Nacharbeitspunkt in einem Gruppen-Rollout ist nicht die Datenmigration. Es ist die Erkenntnis mitten in der Migration, dass zwei Marken dieselben Artikel unterschiedlich benennen und kategorisieren, oder dass niemand vereinbart hat, wie die Zentralküche modelliert wird, und dass Sie umbenennen, neu klassifizieren und neu mappen müssen, während die Uhr läuft.

Diese Punkte im Voraus zu dokumentieren bedeutet, dass das Implementierungsteam von der tatsächlichen Struktur ausgeht, statt an jedem Standort grundlegende Strukturfragen erneut zu stellen. Halten Sie den Finance Lead als Entscheider neben den Operations in der Schleife, denn die Datenbankgrenzen sind zugleich die Grenzen der Auswertungen, in denen dieser Bereich später lebt.

Die Entscheidung in vier Prüfungen

Bevor Sie eine Struktur festlegen, ziehen Sie jede vorgeschlagene Datenbanktrennung durch vier Prüfungen. Wenn eine Trennung nicht mindestens eine der ersten beiden besteht, ist sie an der Markenidentität gezogen und sollte zusammengeführt werden.

Strukturieren Sie die Gruppe nach dieser Logik, und die Plattform bildet ab, wie das Geschäft tatsächlich einkauft und kocht, nicht wie das Markenschema zufällig aussieht. Für das Gesamtbild, was sich verändert, wenn eine Gruppe wächst, siehe unseren Leitfaden zu Multi-Unit-Restaurantmanagement, erkunden Sie, wie eine einzige Plattform für Restaurant-Warenwirtschaft mehrere Marken abbildet, und wenn Sie eine schnelle Ausgangsgröße wollen, wo jedes Konzept steht, bevor Sie beginnen, liefert Ihnen unser kostenloser Wareneinsatz-Rechner eine Startzahl.