.jpeg)
Restaurantsoftware-Rollout an mehreren Standorten: Jeden Standort in Betrieb nehmen
Wo Multi-Standort-Rollouts tatsächlich stocken
Ein Multi-Standort-Software-Rollout stockt, wenn ein Problem, das an einem Standort unsichtbar blieb, sich an jedem anderen Standort wiederholt. Vier Ursachen erklären den Großteil davon: Widerstand bei der Einführung im Standort, eine unvollständige Integration oder Datenabhängigkeit, eine fehlende Freigabe und ein unsauberer Artikelstamm. Jede Ursache hat eine andere Lösung, daher ist die erste Aufgabe die Diagnose, nicht ein neuer Zeitplan.
Die allgemeine Abfolge vom Pilotprojekt zur vollständigen Einführung ist in unserem Leitfaden zum Rollout von Bestandsverwaltungssoftware in einer Gruppe beschrieben. Dieser Leitfaden setzt dort an, wo jener aufhört. Er behandelt die spezifischen Punkte, an denen ein Rollout nach dem Go-Live ins Stocken gerät, und den richtigen Schritt für jeden davon. Das Signal unterscheidet sich je nach Haltepunkt, ebenso der erste Schritt:
| Haltepunkt | Erkennbares Signal | Erster Schritt |
|---|---|---|
| Einführungswiderstand | Ein Standort verwendet still seine alte Bestellmethode nach dem Go-Live | Routine auf Bestellvorlagen abbilden, zunächst einen Standort testen |
| Integration oder Daten | Go-Live wartet auf ein POS-System, einen Logistikdienstleister oder ein Exportformat | Abhängigkeit sequenzieren, an einem Standort validieren, Übergangslösung nutzen |
| Entscheidungsbefugnis | Das Projekt pausiert auf Freigabe eines Direktors oder Franchisegebers | Klären, wer genehmigt, bevor der Zeitplan feststeht |
| Unsauberer Artikelstamm | Doppelte Artikel aus dem Referentiel und aus Rechnungen | Duplikate entfernen und eine Artikelliste standardisieren, bevor sie kopiert wird |
Der Standort, der seine Bestellroutine nicht aufgibt
Der häufigste Stillstand ist leise.
- Die alte Routine. Ein Standortteam hat eine Bestellroutine, der es vertraut.
- Die neue Suche. Das neue System fordert es auf, jeden Artikel zu suchen, anstatt dieser Routine zu folgen.
- Der Stillstand. Der neue Weg fühlt sich langsamer an, also bestellt das Team weiterhin auf die alte Art, und der Rollout hört auf, sich auszubreiten.
Eine Casual-Dining-Gruppe pausierte ihren weiteren Rollout monatelang aus diesem Grund. Sie testete den neuen Workflow an einem einzigen Standort neben der alten Methode, bevor sie weitermachte.
Bilden Sie die Routine auf das System ab, anstatt das Team zu bitten, sie aufzugeben.
- Bestellvorlagen. Supys Bestell- und Anfrage-Vorlagen geben jedem Standort und Lieferanten eine vorkonfigurierte Artikelliste.
- Vorlage laden. „Vorlage laden" füllt die üblichen Artikel in eine Bestellung vor, sodass ein Standort seiner vertrauten Abfolge mit einem Tippen folgt.
- Nur-Vorlagen-Berechtigungen. Berechtigungen können einen Standortbenutzer auf Vorlagen beschränken, damit die feste Routine zum schnellen Weg wird.
Testen Sie zunächst einen Standort parallel zur alten Methode, beweisen Sie, dass die Vorlage schneller ist, und stellen Sie sie dann am nächsten Standort vor.
Wenn der Go-Live auf ein anderes System wartet
Ein Rollout stockt auch an einer Abhängigkeit, die die Software nicht selbst lösen kann.
- Logistik. Ein Drittanbieter-Logistikdienstleister verteilt noch manuell Bestände.
- Point of Sale. Ein POS-System wurde noch nicht ausgewählt.
- Rechnungsformat. Der Rechnungsexport eines Lieferanten verwendet ein Format, das das neue System nicht lesen kann.
Jede davon blockiert den Go-Live, bis jemand sie abschließt, und ein Projektplan allein bringt das nicht in Bewegung.
- Zuerst sequenzieren. Reihen Sie die Abhängigkeit vor dem Rollout ein, nicht währenddessen.
- An einem Standort validieren. Prüfen Sie die Verbindung an einem Standort.
- Lange Wartezeiten überbrücken. Wo die Abhängigkeit Wochen dauert, nutzen Sie eine temporäre Übergangslösung, damit der restliche Go-Live weiterläuft.
Eine Gruppe stieß auf die manuelle Zuteilung eines Logistikdienstleisters und Artikelcode-Abweichungen. Eine temporäre Integration erhielt den Fortschritt aufrecht, während die Abhängigkeit gelöst wurde, und der Go-Live verschob sich um Wochen, statt komplett zu stocken.
Supy verbindet sich mit über 75 Integrationen in den Bereichen POS, Buchhaltung und ERP-Systeme. Die meisten Abhängigkeiten entsprechen einer unterstützten Verbindung statt eines individuellen Aufbaus, also bestätigen Sie die für Ihr Unternehmen benötigte, bevor Sie den Termin festlegen.
Die Freigabe, die niemand gesichert hat
Manche Rollouts stocken an einer Entscheidung, nicht an einem System. Das Projekt wartet ohne Wiederaufnahmedatum, weil die am Rollout beteiligten Personen nicht die benötigte Freigabe erteilen können.
- Keine Direktorengenehmigung. Ein Direktor hat das Projekt noch nicht genehmigt.
- Verzögerte Voraussetzung. Eine Voraussetzung wie die POS-Systemwahl hat sich verzögert.
- Beschaffung durch die Zentrale. Die Beschaffung liegt bei der Zentrale des Franchisegebers, nicht beim einzelnen Standort.
Klären Sie, wer die Entscheidungsgewalt hat, bevor Sie sich auf einen Zeitplan festlegen. Wenn die Befugnis über dem Standort liegt, verlagern Sie die Entscheidung frühzeitig auf die Gruppen- oder Hauptverwaltungsebene. Ein einzelner Standort wird dann nie gebeten, etwas zu genehmigen, das er nicht kontrolliert.
Behandeln Sie die Freigabe als Voraussetzung im Plan, namentlich und mit Datum versehen, nicht als Überraschung, die auf halbem Weg auftaucht. Sobald das System live ist, halten klare Freigaberegeln diese Befugnis sichtbar, damit ein Standort sie nicht still umgehen kann.
Die Artikelliste, die sich über Standorte hinweg vervielfältigt
Ein unsauberer Artikelstamm ist der Stillstand, der sich am schnellsten verbreitet, weil jeder neue Standort ihn erbt. Ein Duplikat stammt aus dem zentralen Referentiel und eines aus einer Lieferantenrechnung, und zusammen verhindern sie die Einrichtung von Zentralküche und Rezept.
Inkonsistente Eingaben erzeugen dann Abweichungen bei Inventuren an jedem Standort gleichzeitig. Kopieren Sie diese Liste auf einen neuen Standort, und Sie kopieren das Chaos mit. Bereinigen Sie eine Artikelliste, bevor Sie sie replizieren.
- Deduplizierungsdurchlauf. Führen Sie einen Deduplizierungsdurchlauf durch, der entscheidet, welche Duplikate zusammengeführt werden sollen.
- Neuer-Artikel-Standard. Standardisieren Sie, wie neue Artikel erstellt werden, damit die nächste Rechnung das Problem nicht wieder aufmacht.
- Excel-Massenbearbeitung. Lieferantenartikel-Listen exportieren zur Massenbearbeitung nach Excel und lassen sich reimportieren, was die Bereinigung zu einem einzigen Durchgang statt eines Artikel-für-Artikel-Aufwands macht.
Wiederverwendbare Inventurvorlagen lassen sich dann in Regalreihenfolge über Standorte klonen. Paralleles Zählen ermöglicht mehreren Mitarbeitern, einen Standort gleichzeitig zu zählen und die Ergebnisse zusammenzuführen, was die Zählzeit um mehr als die Hälfte reduziert, sobald der Stamm bereinigt ist. Erst standardisieren, dann replizieren.
Finden Sie Ihren Haltepunkt, bevor Sie den Zeitplan anpassen.
- Alte Routine. Wenn ein Standort seine alte Routine beibehält, erstellen Sie eine Bestellvorlage und testen Sie einen Standort.
- Warten auf ein System. Wenn der Go-Live auf ein anderes System wartet, sequenzieren Sie diese Abhängigkeit und validieren Sie sie an einem einzelnen Standort.
- Pausiertes Projekt. Wenn das Projekt pausiert, klären Sie, wer es genehmigt, und verlagern Sie die Entscheidung auf die richtige Ebene.
- Doppelte Artikel. Wenn immer wieder dieselben doppelten Artikel auftauchen, deduplizieren und standardisieren Sie zunächst eine Stammliste.
Ein gestoppter Rollout lässt sich fast immer auf eine dieser vier Ursachen zurückführen, und jede lässt sich an einem einzelnen Standort beheben, bevor sie sich auf den Rest ausbreitet.
