Wenn mehr als 100 Hotels gleichzeitig ihr PMS wechseln, ist die Software selbst selten das größte Problem. Shiji Senior Project Manager Alfredo Goldin hat einen solchen Rollout mit durchschnittlich sieben Properties pro Tag begleitet – und spricht über Governance, Task Forces und das, was wirklich schiefläuft.
Sieben Hotels pro Tag. Das klingt nach einer Zahl aus einem Pitch-Deck, nicht aus der Realität. Aber genau das war das Tempo, mit dem ein Großkunde von Shiji sein PMS auf über 100 Properties ausgerollt hat. Wer schon mal eine einzelne Immobilie migriert hat, weiß: Ein Go-Live-Tag ist nie ein ruhiger Tag. Bei sieben gleichzeitig potenziert sich das – und zwar nicht linear.
Was hält so ein Rollout zusammen? Laut Alfredo Goldin, Senior Project Manager bei Shiji, ist die Antwort keine technische: Es ist Struktur.
Die Software ist nicht das Problem
Das klingt kontraintuitiv, wenn man gerade Hunderttausende Euro in ein neues System investiert. Aber die Realität großer PMS-Migrationen sieht so aus: Die Software funktioniert. Was nicht funktioniert, sind die Strukturen drumherum.
Datenmigration ist das klassische Beispiel. Jahre alter Reservierungsdaten, Gästeprofile mit doppelten Einträgen, Ratencodes, die niemand mehr versteht – das alles muss vor dem Umzug bereinigt werden. Wer das unterschätzt, landet am Go-Live-Tag mit einem sauberen neuen System, das mit schmutzigen alten Daten gefüttert wird.
- Datenmigration beginnt zu spät oder ohne dediziertes Team
- Integrations-Tests mit Channel Manager, RMS und POS werden auf die letzte Woche verschoben
- Schulungen finden zu früh statt – Personal hat das System bis Go-Live wieder vergessen
- Kein klarer Eskalationspfad, wenn Properties Probleme melden
- Zu wenig Puffer zwischen einzelnen Rollout-Wellen
Governance: Wer entscheidet was – und wie schnell?
Bei einem Rollout über 100+ Hotels entstehen täglich neue Entscheidungsbedarfe. Property A hat einen Sonderfall bei der Ratenstruktur. Property B meldet, dass die Schnittstelle zum lokalen Kassensystem nicht funktioniert. Property C hat kurz vor Go-Live den IT-Kontakt verloren.
Wenn jede dieser Fragen denselben Entscheidungsweg nimmt – Hotelier meldet an regionalen Manager, der meldet an zentrales Projektteam, das wartet auf Vendor-Feedback – bremst das den ganzen Rollout. Goldin beschreibt strukturierte Governance als das zentrale Gegenmodell: klare Eskalationspfade, definierte Entscheidungskompetenzen auf jeder Ebene, und keine Ticket-Warteschlangen bei zeitkritischen Problemen.
Entscheidungsgeschwindigkeit ist bei Massen-Rollouts genauso wichtig wie technische Stabilität.Task Forces: Dedizierte Teams für den Ernstfall
Großprojekte scheitern oft nicht am Plan, sondern daran, dass niemand Zeit hat, den Plan umzusetzen. Das reguläre Team läuft schon auf Anschlag. Kommt eine Migration dazu, frisst sie alle Puffer weg.
Shijis Ansatz bei diesem Projekt: dedizierte Task Forces, die ausschließlich für den Rollout zuständig sind. Kein Parallelgeschäft, keine anderen Tickets. Ihre einzige Aufgabe ist es, Properties durch den Go-Live zu bringen – und danach stabilisieren.
- Task Force 1: Datenmigration und Vorab-Validierung pro Property
- Task Force 2: Integrations-Tests (Channel Manager, POS, Revenue Management)
- Task Force 3: Go-Live-Support und Vor-Ort-Intervention
- Task Force 4: Post-Live-Monitoring und Eskalation in den ersten 72 Stunden
Onsite-Intervention: Wann Remote nicht mehr reicht
Nicht jedes Problem lässt sich per Screen-Sharing lösen. Gerade in der Hotellerie, wo das Front-Desk-Team unter Hochdruck arbeitet und keine Zeit hat, einem Remote-Support-Agenten zu erklären, was auf dem Bildschirm passiert, ist physische Präsenz oft schneller als jede Fernwartung.
Goldin beschreibt Vor-Ort-Interventionen als kalkulierten Teil des Rollout-Plans – nicht als Notfall-Reaktion. Bestimmte Property-Typen oder Rollout-Phasen werden von Anfang an mit Onsite-Ressourcen eingeplant. Das ist teurer. Aber es ist günstiger als ein Go-Live, der scheitert.
Was Hoteliers vor einer Großmigration wissen sollten
Die Entscheidung für ein neues PMS fällt im Boardroom. Die Konsequenzen trägt das Front Desk. Dieser Spalt zwischen Entscheidung und Umsetzung ist eine der häufigsten Ursachen für gescheiterte Rollouts – weil die Menschen, die täglich mit dem System arbeiten, zu spät eingebunden werden.
Die eigentliche Lektion
Ein PMS-Rollout über 100+ Properties in diesem Tempo funktioniert nicht trotz Struktur, sondern wegen ihr. Was Goldin beschreibt, ist im Kern kein Tech-Projekt – es ist ein Change-Management-Projekt mit einer Software-Komponente.
Wer als Hotelier oder Kettenbetreiber eine große Migration plant, sollte die Frage früh stellen: Haben wir die Governance dafür? Nicht die Lizenzen, nicht das Budget – die Governance. Eskalationspfade, dedizierte Kapazitäten, klare Verantwortlichkeiten. Das ist das Fundament, auf dem alles andere aufbaut.
- Datenmigration mindestens 8 Wochen vor Go-Live starten
- Dedizierte Task Forces für Rollout – kein Parallelbetrieb mit anderen Projekten
- Eskalationspfade schriftlich dokumentieren, bevor der erste Go-Live startet
- Front-Desk-Teams früh einbinden – nicht erst bei der Schulung
- Onsite-Support für komplexe Properties von Anfang an einplanen
- Post-Live-Monitoring-Fenster definieren (mind. 72 Stunden nach Go-Live)