Datenmigration in der Warenwirtschaft: Warum Restaurant-Implementierungen ins Stocken geraten

Wo eine Warenwirtschaftsmigration tatsächlich ins Stocken gerät

Die Datenmigration der Warenwirtschaft im Restaurant bezeichnet den Vorgang, Betriebsdaten von einer alten auf eine neue Plattform zu übertragen: Artikel, Lieferanten, Preise, Rezepte, Einkaufshistorie und Benutzerrollen. Ins Stocken gerät dieser Prozess, wenn die Daten nicht vollständig ankommen und dies niemandem auffällt – bis das neue System bereits live ist und Zahlen liefert, denen das Team nicht vertraut.

Eine Gruppe mit 4 Standorten hat die schlimmste Variante davon erlebt. Die Einrichtung auf der bisherigen Plattform dauerte 3 Monate und brachte keinen realisierten Nutzen. Erschwerend hinzu kam, dass zwei große Lieferanten ihre Artikelcodes mitten im Wechsel änderten – mit Auswirkungen auf rund 70 % des Wareneinsatzes. Genau dieses Scheitern soll dieser Leitfaden verhindern. Es lässt sich fast immer auf einen von zwei Blockadepunkten zurückführen.

Der erste liegt an der Schnittstelle zum alten System. Die Massenübernahme von Artikeln und Lieferanten scheitert am Go-Live, was manuelle Nacherfassung erzwingt, bevor irgendjemand arbeiten kann. Die Exportfenster sind kurz: Eine Gruppe hatte lediglich 48 Stunden Zeit, ihre Daten aus der bestehenden Plattform abzuziehen, bevor der Zugang gesperrt wurde – zu wenig Zeit, um sie auch zu bereinigen. Importierte Datensätze schlagen lautlos fehl: Werden etwa Sichtbarkeitsflags für Artikel beim Laden falsch gesetzt, verschwinden Produkte einfach aus dem Bestellprozess, bis jemand nachforscht. Dieses Problem ähnelt den Integrationslücken bei der Kassenanbindung, die die Bestandsgenauigkeit untergraben: Die Daten scheinen vorhanden, sind jedoch still und leise fehlerhaft.

Der zweite Blockadepunkt ist subtiler und tritt auf, nachdem die Daten technisch importiert wurden. Die Datensätze sind vorhanden, aber fehlerhaft – Inventuren, Kosten und Berichte ergeben keinen Sinn. Das Team glaubt dann, die Plattform sei defekt, obwohl das eigentliche Problem in den Daten selbst liegt. Welchem der beiden Szenarien Sie gegenüberstehen, bestimmt, wie Sie es beheben – klären Sie das, bevor Sie irgendetwas anderes anfassen.

Legen Sie den Migrationsumfang schriftlich fest, bevor Sie sich festlegen

Der entscheidende Schritt, der einen reibungslosen Wechsel von einem ins Stocken geratenen unterscheidet, ist die schriftliche Festlegung des Migrationsumfangs, bevor Sie einen Termin verbindlich vereinbaren. Eine große Multi-Standort-Gruppe hat genau das getan: Sie definierte schriftlich die 7 Datensatztypen, die sie übernehmen wollte, und verlangte dann eine clientseitige Validierung mit bestätigtem Datenverlust von null vor dem Go-Live. Dieser schriftliche Umfang ist der Vertrag, den Sie Ihrem Anbieter gegenüber geltend machen können – und die Validierung ist der Schritt, den die meisten Betreiber überspringen.

Die Liste des Umfangs ist nicht lang, aber jeder Punkt muss ausdrücklich benannt werden, sonst fällt er unter den Tisch:

• Historische Transaktionen, damit Ihre Berichte einen Vergleichszeitraum haben
• Rezepte einschließlich verschachtelter Teilrezepte (eine Gruppe übernahm 500 Rezepte mit bis zu 4 Ebenen für Vorbereitungs- und Halbfertigprodukte)
• Preise und Lieferantendaten – die Daten, die sich während der Migration am wahrscheinlichsten ändern
• Bestellungen und Wareneingangsnachweise, damit offene Verbindlichkeiten nicht verloren gehen
• Benutzerrollen, damit die richtigen Personen ab Tag eins handeln können

Vereinbaren Sie auch, wer welche Vorlage ausfüllt. Die Dateneingabe für Rezepte liegt in der Regel in der Verantwortung des Kunden und nicht des Anbieters. Eine Gruppe, die das anders annahm, verlor eine Woche, als sie es herausfand – deshalb ist die Rezeptkonfiguration so oft der eigentliche Engpass beim Onboarding. Führen Sie die Validierung dann als verbindliche Hürde durch, nicht als Formalität: Zählen Sie, was das alte System verlassen hat, zählen Sie, was angekommen ist, und verweigern Sie den Go-Live, bis beide Zahlen übereinstimmen oder jede Abweichung erklärt ist. Das verwandelt „Wir glauben, es ist rübergekommen" in „Wir haben bestätigt, dass es so ist."

Behandeln Sie die Eröffnungsinventur als Migrationsschritt, nicht als erste Inventur

Bei der Eröffnungsinventur sind zwei Betreiber unabhängig voneinander in dieselbe Falle getappt: Sie betrachteten sie als erste reguläre Inventur statt als den Schritt, der das neue System mit realen Mengenangaben befüllt. So durchgeführt liefert sie fehlerhafte Zahlen ohne Aussagekraft – und jeder darauf aufbauende Bericht erbt den Fehler. Behandeln Sie sie als letzten Abschnitt der Migration, und sie bewirkt das Gegenteil: Sie erhalten einen verlässlichen Ausgangssaldo.

Hilfreich ist es außerdem, das gesamte Go-Live anhand einer Bereitschafts-Checkliste zu strukturieren statt anhand eines einzigen Datums. Eine Enterprise-Gruppe, die sich auf einen festen Launch vorbereitete, forderte genau das an und erhielt eine Checkliste mit 8 Bereichen – drei davon hatte sie nicht eingeplant. Der Wert einer Checkliste liegt darin, dass sie jedem Bereich einen Verantwortlichen und einen Zeitpunkt zuweist, sodass nichts von der Annahme abhängt, dass sich schon jemand darum kümmern werde.

Gehen Sie mit unvollständigen Daten live – und korrigieren Sie sie anschließend

Das Warten auf perfekte Daten ist der häufigste Grund, warum eine Migration zu einem monatelangen Stillstand wird – und es ist kostspielig: Eine Gruppe mit 4 Standorten, die rund $300 pro Standort und Monat zahlt, kann $3.600 in einem 3-monatigen Setup ausgeben, bevor die Plattform eine einzige aussagekräftige Zahl liefert. Die Betreiber, die das vermeiden, gehen an ihrem Zieldatum live – mit Daten, die sie als unvollständig kennen – und korrigieren sie im laufenden Betrieb.

Eine Gruppe, die in einem neuen Markt eröffnete, hat das bewusst so gemacht. Ihre Stammartikel und Rezepte enthielten Fehler aus einem überstürzten Setup, mehrere Lieferanten stellten handgeschriebene Rechnungen ohne Artikelcodes aus, und es gab keine verlässliche Einkaufshistorie. Anstatt den Start zu verschieben, ging das Team am Zieldatum live, korrigierte Stammartikel und Rezepte laufend, erfasste Einträge rückwirkend, sobald Inventuren und Rechnungen eintrafen, und hielt die frühen Inventuren bewusst einfach, um Korrekturen zu erleichtern. Das System erbrachte seinen Nutzen ab dem ersten Tag, statt untätig auf Perfektion zu warten.

Der letzte Schritt ist, die Tür hinter sich zu schließen. Während einer Umstellungsphase erhalten in der Regel alle vollständigen Zugriff, und niemand überprüft das später – so kommt es, dass Mitarbeiter von der Beschaffung festgelegte Preise beim Wareneingang überschreiben oder Datensätze löschen, die sie nicht anfassen sollten. Setzen Sie rollengerechte Berechtigungen in der ersten Woche, nicht im ersten Quartal, und verlassen Sie sich auf eine Warenwirtschaftsplattform für Restaurants, die Zugriffsrechte nach Rolle und Standort einschränkt, anstatt allen dieselben Rechte zu gewähren.

Noch ein wichtiger Hinweis für eine andere Art von Änderung: Wenn es sich bei Ihrer Migration um eine rechtliche oder markenbezogene Umstrukturierung handelt und nicht um einen Plattformwechsel, bleibt der Warenbestand jeder Einheit eigenständig erhalten, und die Betriebshistorie wird ohne manuelle Re-Migration bewahrt. Für diesen Fall brauchen Sie dieses Handbuch nicht. Bei einem echten Plattformwechsel schon.

Bestimmen Sie daher zuerst, in welchem Szenario Sie sich befinden, bevor Sie irgendetwas planen. Wenn Ihre Daten nicht vollständig angekommen sind, befinden Sie sich beim ersten Blockadepunkt: Stoppen Sie den Go-Live, und validieren Sie die migrierten Datensätze gegen die Quelldaten, bevor Sie live gehen – denn ein unbemerkt verlorener Datensatz, der erst im zweiten Monat auffällt, kostet weitaus mehr als ein verzögerter Start. Wenn die Daten vorhanden sind, die Zahlen aber falsch aussehen, befinden Sie sich beim zweiten Blockadepunkt: Prüfen Sie, ob die Eröffnungsinventur als Migrationsschritt durchgeführt wurde, und arbeiten Sie sich von dort aus vor. In jedem Fall: Halten Sie den Umfang schriftlich fest, machen Sie die verlustfreie Validierung zur Hürde, und gehen Sie an Ihrem Zieldatum live – mit einem Plan, den Rest im laufenden Betrieb zu korrigieren, anstatt für ein Setup zu zahlen, das während des Wartens keinen Nutzen bringt.