CAFM: Cutover-, Go Live- und Rollout-Konzept

letzte Migration, Validierung, Freeze-Phasen

Zunächst werden Stammdaten (Mitarbeiter, Anlagen, Orte etc.) in Vorabläufen migriert und geprüft. Im finalen Cutover-Zeitfenster geht es um alle seit der letzten Migration hinzugekommenen Bewegungsdaten. Typisch ist eine Freeze-Phase: Vor dem letzten Import werden keine neuen Einträge mehr im Altsystem gemacht, um einen konsistenten Endzustand zu erhalten. In diesem Zeitraum erstellt das IT-Team ein vollständiges Backup und schaltet das Altsystem auf „Read-Only“. Anschließend werden die Delta-Daten (beispielsweise offene Bestellungen, Forderungen, Wartungsaufträge) in das neue CAFM-System übertragen.

Nach Abschluss der Migration steht die Datenvalidierung an. Mittels automatischer Prüfroutinen wird sichergestellt, dass alle Datensätze vollständig und konsistent übernommen wurden. Das neue System sollte auf Basis von Testläufen in einer Staging-Umgebung validiert werden („Dry Run“). Dabei werden Datenintegrität und Geschäftsprozesse simuliert, Inkonsistenzen (z. B. Dubletten, fehlende Werte) identifiziert und korrigiert. Nur ein sauberes, konsistentes Datenfundament garantiert einen erfolgreichen Go-Live. Nach Go-Live wird oft noch ein letzter Abgleich gefahren: Salden und Kennzahlen des Altsystems müssen mit dem neuen System „auf den Cent“ übereinstimmen (Generalproben‑Check).

Vor dem eigentlichen Live-Schalten wird eine detaillierte Checkliste abgearbeitet, um den reibungslosen Betrieb sicherzustellen.

• System- und Infrastruktur-Check: Alle Server, Netzwerkkomponenten und Hardware sind einsatzbereit; notwendige Lizenzen sind installiert. Das Monitoring (Performance, Log- und Fehlersysteme) wurde konfiguriert und getestet.

• Benutzerzugänge: Es wurden alle Benutzerkonten, Gruppen und Berechtigungen angelegt. Administrator-, Key-User- und Standard-User-Zugänge wurden in einer Onboarding-Liste angelegt und geprüft.

• Stammdaten und Migration: Die Testmigration wurde erfolgreich abgeschlossen; Stammdaten wurden freigegeben und auf Vollständigkeit geprüft. Alle Bewegungsdaten sind nachgeführt.

• Schnittstellen: Alle Integrationen (z. B. zu ERP, SAP, Telefonie, IoT-Geräten) sind eingerichtet und in Testläufen geprüft. Auf den neuen Schnittstellen (Input/Output) darf es keine Fehler oder unterbrochenen Datenflüsse geben.

• Backup-Plan: Ein finales System-Backup ist erfolgt und ein Wiederherstellungsplan liegt vor (Notfallkonzept). Damit kann der Ursprungszustand bei Bedarf wiederhergestellt werden.

• Smoke-Tests: Am Go-Live-Tag werden die Basisfunktionen getestet: Können sich Benutzer einloggen, Druckaufträge senden und E-Mails versenden? Solche abschließenden Rauchtests prüft die IT vor der Freigabe.

• Kommunikation/SUPPORT: Ein Kommunikationsplan steht: Alle Stakeholder (Geschäftsführung, Fachabteilungen, IT) sind über Go-Live-Termine informiert und wissen, an wen sie sich bei Problemen wenden. Supportkanäle (Helpdesk, Key-User, ggf. Hotline) sind definiert. Für die ersten Tage ist ein klarer Eskalationspfad etabliert.

• Monitoring: Relevante Überwachungswerkzeuge wurden aktiviert. Ein Dashboard oder Ticket-System ist eingerichtet, damit auftretende Fehler früh erkannt und verfolgt werden kann.

• Freigaben: Abschließende Sign-offs (z. B. UAT‑Abnahme der Fachbereiche) liegen vor. Mit diesen Abnahmefreigaben ist die Go/No‑Go-Entscheidung getroffen.

In vielen Projekten wird das System nicht sofort bei allen Anwendern live geschaltet, sondern schrittweise eingeführt. Beispielsweise kann an einem oder mehreren Pilotlinien in einem kleinen Bereich oder Standort gestartet werden, um das System zu testen. Ein solches Pilotprojekt deckt anfangs nur bestimmte Module oder Nutzergruppen ab – etwa eine einzelne Abteilung oder Niederlassung. Hat das funktioniert, erfolgt die weitere Ausrollung gestaffelt („gestufter Rollout“): nacheinander werden weitere Standorte, Fachbereiche oder Funktionalitäten migriert. Ein Vorteil der phasenweisen Einführung ist das niedrigere Risiko: Erkenntnisse aus den frühen Phasen (z. B. ungelöste Probleme oder Optimierungsbedarf) können in den späteren Phasen berücksichtigt werden. Nach und nach wird so das gesamte System in Betrieb genommen.

Vor dem finalen Go-Live müssen alle Anwender geschult und informiert sein. In Abschlussworkshops und Schulungen (Präsenz oder E‑Learning) werden die Key-User und Endanwender in den letzten Details des neuen Systems fit gemacht. Typischerweise werden in dieser Phase auch FAQs oder Quick-Guide-Pakete verteilt.

• Letzte Anwenderschulungen: Abschließende Workshops für alle Nutzergruppen, in denen die neuen Prozesse live durchgespielt werden. Dabei beantworten die Trainer offene Fragen und demonstrieren Workarounds. Die Schulung der Trainer (Train-the-Trainer) sollte beendet sein. Training wurde für alle obligatorischen Funktionen abgeschlossen.

• Informationsmaterial: FAQ‑Listen, Benutzerhandbuch, kurze Video-Tutorials oder Intranet‑Artikel werden bereitgestellt. Anwender erhalten ein Informationspaket mit einem Ablaufplan, Kontakten und häufigen Fragen. So sind vorgegebene Supportwege bekannt.

• Support und Hotline: Eine Supportstruktur ist etabliert: Key-User übernehmen erste Supporttickets, ein Helpdesk beantwortet allgemeine Fragen. Oft wird für den Go-Live ein Hotline‑Dienst oder Helpdesk mit erweiterten Zeiten geschaltet – Dreher Consulting empfiehlt z. B. in der ersten Go-Live-Woche sogar einen 24/7‑Service einzurichten. So kann auf dringende Probleme schnell reagiert werden.

• Kommunikation: Über E-Mail, Intranet oder Meetings werden alle Mitarbeiter rechtzeitig über den anstehenden Go-Live-Termin, die wichtigsten Neuerungen und Ansprechpartner informiert. Regelmäßige Status-Updates („Go-Live ist am…“, „Bitte keine neuen Daten ins Altsystem einpflegen“) halten das Team informiert.

Nach Go-Live werden die operativen Zuständigkeiten definiert und das System offiziell an die Betreiberseite übergeben.

• Key-User-Struktur: Eine stabile Key-User-Organisation wird aktiv: Für jedes Fachthema gibt es Schlüsselnutzer, die Ansprechpartner für ihre Abteilung sind und laufend Wissen aus dem Projekt an Kollegen weitergeben. Sie fungieren als Bindeglied zwischen Anwendern und Projektteam.

• Support-Übergabe: Das Projektteam übergibt Tickets, offene Issues und Handbücher an den operativen Support (First-/Second-Level-Support). Ansprechpartner der IT‑Betriebsteams sind definiert. Service-Level-Vereinbarungen (Reaktionszeiten, Wartung) treten in Kraft.

• Dokumentation: Sämtliche System- und Prozessdokumentationen, Betriebsanleitungen, Schnittstellenbeschreibungen sowie Test- und Migrationsprotokolle werden an die Betriebsorganisation übergeben. Auch Change-Logs (Änderungsdokumentation) und Anforderungslisten gehören zur Abschlussdokumentation. So stellt man die Nachvollziehbarkeit (auch revisionssicher) sicher.

• Knowledge Transfer: In Workshops oder Übergabesitzungen vermittelt das Projektteam das notwendige Spezialwissen. Hier werden beispielsweise komplexe Workflows, Eskalationspunkte oder Besonderheiten (z. B. kundenspezifische Anpassungen) mit dem Betriebsteam besprochen.

Hypercare, Stabilisierungsphase, Fehlerbearbeitung, Feedbackschleifen. Nach dem offiziellen Go-Live beginnt die Hypercare-Phase – eine intensiv betreute Stabilisierungszeit (häufig 2–6 Wochen). In dieser Phase steht das Projektteam in einem „War Room“ bereit und behandelt auftretende Probleme priorisiert nach Geschäftsauswirkung (Triage-Prozess). Tägliche Abstimmungstreffen (Daily Stand-ups) zwischen Projektleitung, Key-Usern und IT sorgen dafür, dass Muster in Fehlerberichten erkannt und schnell behoben werden. Es gibt klare Exit-Kriterien: Wenn z. B. mehrere Tage keine kritischen Störungen (Prio 1) auftreten und erste Berichtszyklen erfolgreich durchlaufen wurden, gilt Hypercare als abgeschlossen. Dreher Consulting fasst es so zusammen: Hypercare ist ein Sicherheitsnetz nach der Einführung, das den Projekterfolg garantiert, indem es intensive Anwenderbetreuung und Krisenmanagement ermöglicht.

Neben der akuten Fehlerbehebung werden in dieser Phase weitere Feinjustierungen vorgenommen: Systemeinstellungen werden optimiert, Kennzahlen überwacht und offene Change-Anfragen priorisiert. Vor allem muss die Nutzung des Systems weiter intensiv überwacht werden. Regelmäßiges Feedback der Anwender (z. B. über Umfragen, Tickets oder Workshops) wird genutzt, um Bugs zu identifizieren und Folgeanpassungen einzuplanen. Wie ein CAFM‑Fachblog betont: „Go‑Live is just the beginning!“ – das System wird kontinuierlich beobachtet und anhand von Nutzer-Feedback weiter verbessert. Nach Hypercare geht der Betrieb sukzessive in einen stabilen Regelbetrieb über.

Rollout‑Strategien: Big Bang vs. gestuft vs. parallel (Vor- und Nachteile)

• Big-Bang-Einführung: Alle Module/Standorte werden gleichzeitig umgestellt. Vorteil: kurze Gesamteinführungszeit und klare Systemlandschaft ab einem Stichtag. Nachteil: hoher Aufwand für den Cutover und großes Risiko (bei Fehlern sind alle Anwender betroffen). Diese Strategie benötigt einen extrem stabilen Master-Plan und ausreichende Ressourcen, um das «große Umschalten» in einem Rutsch zu schaffen.

• Gestuft/Phasenweiser Rollout: Die Einführung erfolgt in Wellen (z. B. erst Standort A, dann B, oder zuerst Modul 1, dann 2). Vorteil: Erfahrungen aus der Pilotphase können in späteren Wellen genutzt werden, das Risiko pro Welle ist geringer und es lässt sich gezielter kontrollieren. Nachteil: die Einführungsdauer verlängert sich, und es gibt für eine Übergangszeit eine heterogene Systemlandschaft. Die Koordination zwischen „Live-“ und noch-nicht-live-Teilen erfordert zusätzliche Planung. Wie ein Implementierungsratgeber empfiehlt, kann ein „Soft Launch“ mit einem Pilotbetrieb in kleinem Rahmen sinnvoll sein.

• Parallelbetrieb: Das alte und das neue System laufen für eine Zeit nebeneinander. Vorteil: bei Fehlern kann kurzfristig ins Alt-System zurückgegriffen werden. Nachteile: doppelter Pflegeaufwand und Gefahr von Dateninkonsistenzen, da beide Systeme geführt werden müssen. Diese Strategie wird seltener gewählt und oft durch skripbasierte Synchronisationen („Delta-Loads“) realisiert.

Die Wahl der Strategie hängt von Projektgröße, Zeitdruck und Risikoappetit ab. Oft kombiniert man Elemente: z. B. starten ausgewählte Module phasenweise (Rollout nach Funktionen), während kritische Geschäftsprozesse im Parallelbetrieb überbrückt werden.

• Go/No-Go-Entscheidung: Es wird definiert, welche Gremien (z. B. Lenkungsausschuss, IT-Steuerkreis) das Go-Live final absegnen. Üblicherweise findet kurz vor Go-Live ein formales Review statt – sind alle Abnahmen (Testsignoffs, Datenqualität, Ressourcen) erreicht, wird freigegeben; andernfalls wird der Cutover verschoben. In vielen Vorgehensmodellen wird der «Go/No-Go-Punkt» so festgelegt, dass danach ein Abbruch nur mit hohem Aufwand möglich wäre.

• Abnahmefreigaben: Vor Go-Live müssen alle Fachabteilungen und der Kunde formell abgenommen haben (z. B. Abzeichnen der User Acceptance Tests). Erst mit diesen Freigaben ist die Software für die Produktion freigegeben. Man dokumentiert dies häufig in Abschlussprotokollen oder -berichten.

• Change-Freeze: Spätestens ab Ende der Testphase tritt ein Entwicklungs-Stopp (Change-Freeze) in Kraft. Keine neuen Funktionen oder nicht dringenden Anpassungen mehr implementieren – nur noch notwendige Fehlerkorrekturen. Dies stabilisiert den Zustand und verhindert Überraschungen kurz vor Go-Live. Auch beim Cutover selbst sollten keine Änderungen mehr vorgenommen werden (zum Beispiel während des Datenabgleichs).

• Abstimmungs-Meetings: Ein regelmäßiges Governance-Board hält den Überblick über den Projektfortschritt. In ihm wird geprüft, ob Zeitplan, Budget und Qualitätskriterien eingehalten sind. Hier werden auch Risiken und Eskalationen (z. B. Verzögerungen) behandelt.

Aus der Praxis haben sich mehrere Erfolgsfaktoren herauskristallisiert: Ein durchdachter Datenplan und gründliches Daten‑Cleansing sind essenziell – im Schnitt sollte ein großer Teil der Projektzeit für Datenaufbereitung eingeplant werden. Ebenfalls entscheidend ist die Einbindung der Key-User und Fachbereiche: Sie schaffen Akzeptanz und können das Projekt rückkoppeln. Transparenz spielt eine große Rolle: Der Cutover-Plan sollte für alle Beteiligten jederzeit einsehbar sein und regelmäßig mit Management und Anwendungsverantwortlichen abgestimmt werden. Gerade in komplexen Rollouts erhöhen Generalproben (sogenannte Trockenläufe) die Erfolgschancen erheblich: Empfehlenswert sind mindestens zwei vollständige Tests des Cutover-Ablaufs vor dem echten Go-Live. Moderne Cutover-Tools können zudem helfen, die Planung dezentral zu erarbeiten und Änderungen nachzuverfolgen.

Typische Risiken bei CAFM-Implementierungen sind ungenügende Datenqualität, zu knappe Zeitplanung und unvollständige Tests. Verlassen Sie sich nicht darauf, Daten „beim Import zu bereinigen“ – im Gegenteil sollte die Migration als Chance zur radikalen Datenbereinigung genutzt werden. Auch Change-Requests unmittelbar vor Go-Live gefährden den Zeitplan; eine strikte Freeze-Regel kann hier vor Chaos schützen. Aus Lessons Learned folgt: Planen Sie ausreichend Puffer für unerwartete Probleme ein, testen Sie Schnittstellen frühzeitig und sorgen Sie für eine enge Kommunikation. Abschließend lässt sich sagen: Ein klar strukturierter Cutover-Prozess, fundiertes Test- und Trainingsmanagement sowie eine aktive Post-Go-Live-Betreuung (Hypercare) sind wesentliche Erfolgsfaktoren für einen reibungslosen Systemstart.