Warenwirtschaftssystem-Migration für Restaurants: Multi-Standort-Plan – zuerst ein Standort

Den Plan an einem Standort beweisen, bevor die gesamte Gruppe wechselt

Ein Migrationsplan für das Warenwirtschaftssystem eines Restaurants funktioniert am besten, wenn ein Standort zuerst live geht und der Rest der Gruppe dem Weg folgt, den dieser Standort bereits erprobt hat. Verschieben Sie die Rezepte, Lieferantendaten, Artikelliste und Preise eines einzigen Standorts, betreiben Sie ihn zwei Wochen live, und klonen Sie dann diese Konfiguration auf jeden anderen Standort. Multi-Standort-Gruppen, die den Wechsel so sequenzieren, begegnen beim Go-live deutlich weniger Überraschungen.

Klein anfangen, weil der Wechsel zu groß wirkt, um ihn zu beginnen, wenn Rezepte, Preise, Kalkulationen und Lieferantendaten alle auf einmal verschoben werden müssen. Ein Pilotstandort reduziert diesen Umfang auf etwas, das ein Team abschließen und prüfen kann. Er bringt auch Zuordnungslücken und Schulungslücken ans Licht, solange nur ein einzelner Standort vom Ergebnis abhängt – nicht der gesamte Betrieb.

Klonierbare Konfiguration ist das, was einen Standort auf die Gruppe skaliert. Supy erstellt eine Inventurvorlage einmal und klont sie auf jeden Standort. Die Artikelliste wird ein einziges Mal übertragen und bleibt über alle Standorte hinweg konsistent, anstatt Filiale für Filiale neu aufgebaut zu werden. Der Pilotstandort wird zur Vorlage, die der nächste Standort erbt. Ein schrittweiser Multi-Standort-Rollout macht aus einem bewährten Standort eine wiederholbare Route für alle anderen.

Die Artikelliste zuordnen, bevor irgendetwas verschoben wird

Ordnen Sie jeden Artikel zu, bevor Daten verschoben werden, denn ein Artikel, der nicht sauber zugeordnet wird, verschwindet nach dem Wechsel aus der Bestellung. Die Artikelliste ist das Rückgrat der Migration: Beschaffung, Inventur und Kalkulation lesen alle daraus, sodass eine Lücke hier überall nachgelagert auftaucht. Sie nach dem Go-live zu beheben bedeutet, fehlende Artikel zu verfolgen, während der Standort bereits bestellt.

Der Massenimport verschiebt Daten schnell – genau das ist der Grund, warum die Validierung nicht übersprungen werden kann. Eine Restaurant-Warenwirtschaftsplattform wie Supy importiert den vollständigen Katalog und die Preisliste eines Standorts in einem nachvollziehbaren Schritt aus einer Tabellenkalkulation. Etwa 1.200 Artikel- und Preiszeilen werden gemeinsam verschoben statt Zeile für Zeile. Ihr Team übernimmt den nächsten Schritt: die Bestätigung, dass jeder Artikel zugeordnet wurde. Beim ersten Import schaffen das vielleicht 40 nicht, und jeder davon fällt aus der Bestellung heraus, bis jemand ihn mit dem richtigen Datensatz verknüpft.

Behalten Sie die Zuordnungsentscheidung bei Ihrem eigenen Team. Das System verschiebt und erfasst die Daten – es entscheidet nicht für Sie, welcher Legacy-Artikel welchem neuen wird. Dieses Urteilsvermögen ist der Ort, wo das eigentliche Wissen steckt. Ein Plan, der die Zuordnung einem Import-Assistenten überlässt, ist der Plan, der beim Go-live Artikel verliert.

Rezepte zuerst einrichten, weil Warenbuchung und Kostenkalkulation darauf warten

Richten Sie Rezepte ein, bevor irgendetwas von ihnen liest. Die Rezepteinrichtung ist der häufigste Onboarding-Blocker, weil Kassenbestandsabzug und Kostenkalkulation nur funktionieren, sobald das Rezept hinter jedem Gericht stimmt. Ein Gericht, das ohne korrektes Rezept verkauft wird, bucht nichts ab und kostet nichts im neuen System – die Zahlen bleiben leer, bis die Rezepte vorhanden sind. Der tiefere Grund, warum die Rezepteinrichtung das Onboarding blockiert, ist, dass jeder nachgelagerte Bericht seine Fehler erbt.

Verschieben Sie die Rezeptkosten in großen Mengen, prüfen Sie sie dann manuell. Supy exportiert und importiert Rezeptpreise über eine Tabellenkalkulation, sodass rund 300 Rezepte ihre Kosten in einem Durchgang übertragen statt einzeln einzutippen. Ihr Team bestätigt dennoch jeden Ertrag und jede Portion gegen das Live-Menü, weil ein Massenimport das überträgt, was das alte System enthielt – einschließlich dessen, was darin bereits falsch war.

Lieferantendaten und Preise als eine Einheit verschieben

Verschieben Sie die Daten und Preise jedes Lieferanten gemeinsam, niemals getrennt – sonst kalkuliert die erste Bestellung nach dem Go-live gegen eine Lücke. Lieferantendatensätze enthalten die Packungsgrößen und Einheitspreise, von denen die Kalkulation abhängt. Ein Lieferant, der ohne Preise ankommt, lässt jedes verknüpfte Rezept falsch kalkuliert. Verpackungsformate erschweren das über eine Gruppe hinweg. Dieselbe Zutat kommt als Karton in einer Zentralküche und als Sack in einer anderen an – beide müssen zu einem Basisartikel aufgelöst werden.

Supy verknüpft die SKUs und Verpackungen jedes Lieferanten mit einem einzigen Basisartikel, unterstützt Massen-Zutatenaustauch und pflegt die Versionshistorie der Datensätze. Eine Packungsgröße oder ein Preis, der sich mitten in der Migration ändert, bleibt nachverfolgbar statt verloren. Ein Basisartikel hinter mehreren Lieferantenformaten verhindert, dass dasselbe Produkt in der Gruppe als drei Artikel gezählt wird.

Ein Validierungsfenster vor dem Go-live einplanen, keinen harten Cut-over

Planen Sie ein Validierungsfenster statt eines Wechsels in einer einzigen Nacht. Eine Legacy-Plattform gibt oft nur ein kurzes Fenster zum Datenexport – manchmal 48 Stunden – und ein kurzes Fenster treibt ungeprüfte Datensätze direkt ins Go-live. Betreiben Sie das neue System zwei Wochen parallel zum alten: Nehmen Sie die Inventur am Pilotstandort ab, gleichen Sie sie mit den alten Datensätzen ab, und beheben Sie die Zuordnung, bevor Sie die Bestellung umstellen. Der Zweck des Fensters ist es, fehlerhafte Artikel zu finden, solange das alte System noch zum Abgleich zur Verfügung steht.

Ein Validierungsfenster schützt auch den Go-live selbst, weil jeder im Fenster gefundene Fehler einer ist, dem der nächste Standort nicht begegnet. Bevor der Rest der Gruppe folgt, arbeiten Sie diese kurze Checkliste am Pilotstandort ab:

• Artikelliste abgeglichen. Alle 1.200 Artikel- und Preiszeilen wurden importiert, und die 40, die nicht zugeordnet werden konnten, sind behoben – kein Artikel fällt aus der Bestellung heraus.
• Rezepte kalkulieren korrekt. Jedes der 300 Rezepte bucht Bestand ab und meldet eine Kalkulation gegen das Live-Menü.
• Lieferanten und Verpackungen verknüpft. Jede Lieferanten-SKU und Packungsgröße ist einem Basisartikel zugeordnet, mit angehängten Preisen.
• Zwei Live-Wochen hinter sich. Der Pilotstandort hat zwei Wochen auf dem neuen System betrieben, und seine Inventur-Zählungen stimmen mit dem Regal überein.

Diese vier abhaken, und der nächste Standort erbt eine Route, die bereits funktioniert. Die Gruppe migriert einen bewährten Standort nach dem anderen, und der gesamte Betrieb erreicht das Go-live ohne den Stress, den ein einziger harter Cut-over auf jeden Standort gleichzeitig ausübt.