CAFM: Go Live/Cutover Durchführung (inkl. Datenfreeze)

Eine sorgfältige Zeitplanung ist das A und O für einen erfolgreichen Go-Live. Idealerweise wird früh im Projekt ein Go-Live-Termin (Stichtag) festgelegt und ein entsprechender Go-Live-Kalender rückwärts davon abgeleitet. In diesem Kalender werden alle Meilensteine und Vorbereitungsaktivitäten mit ausreichendem Vorlauf terminiert – von finalen Tests über Schulungen bis zum Datenfreeze (Einfrieren der Altdaten).

Wichtig ist, ein Cutover-Zeitfenster einzuplanen, in dem die Umschaltung tatsächlich durchgeführt wird. Dieses Cutover-Fenster liegt oft außerhalb der regulären Betriebszeiten, um die Auswirkungen auf das Tagesgeschäft zu minimieren – typischerweise z.B. über ein Wochenende. Viele Unternehmen wählen Freitagabend bis Montagmorgen als Cutover-Fenster: Das Altsystem wird am Freitag nach Geschäftsschluss eingefroren/abgeschaltet, am Wochenende laufen Migration und Umstellung, und am Montag startet man mit dem neuen System in den produktiven Betrieb (ggf. zunächst als „Soft-Start“ mit verstärktem Support). Planungstipps für das Cutover-Fenster: Vermeiden Sie ungünstige Termine wie z.B. direkt vor Feiertagen oder Quartalsabschlüssen, an denen personelle Ressourcen knapp sind oder andere Risiken bestehen. Planen Sie genügend Puffer ein, falls einzelne Schritte länger dauern – es ist wesentlich besser, etwas Leerlauf einzuplanen, als in Zeitnot zu geraten.

Unter technischen und organisatorischen Vorlaufzeiten versteht man alle Fristen, die vor dem Go-Live eingehalten werden müssen, damit am Stichtag alles bereit ist. Beispiele: Hardware-/Infrastruktur muss Wochen vorher bestellt und installiert sein; Schnittstellenpartner müssen ggf. einige Tage vor Go-Live informiert und umgestellt werden; Key-User müssen rechtzeitig geschult sein (typisch einige Wochen vorher); ein Code-Freeze wird oft 1-2 Wochen vor Go-Live verhängt, damit keine letzten Änderungen mehr die Stabilität gefährden. Auch ein Datenfreeze gehört dazu (siehe Abschnitt 4): Ab einem bestimmten Stichtag werden keine neuen Daten mehr im Altsystem erfasst, um eine konsistente Datenbasis für die finalen Migrationsschritte zu haben.

beginnend beim Go-Live-Termin wird ermittelt, welche Aktivitäten bis wann abgeschlossen sein müssen. So entsteht ein Fahrplan, z.B.: T minus 4 Wochen: Abschluss der User-Acceptance-Tests und Go-Live-Freigabe; T-2 Wochen: Abschluss Endanwenderschulungen, generalstabsmäßige Probe des Cutovers (Generalprobe); T-1 Woche: Datenmigrationstest erfolgreich, letztes Go-Live-Readiness-Meeting (Go/No-Go-Entscheidung); T-0: Cutover-Wochenende läuft nach Plan; T+1-2 Wochen: Hypercare-Beginn (Nachbetreuung). Natürlich variieren diese Zeiträume je nach Projektgröße – große, internationale Rollouts planen oft Monate im Voraus, während kleinere Betriebe auch in wenigen Wochen umstellen können. Entscheidend ist, dass alle Beteiligten frühzeitig Klarheit über den Terminplan haben und Deadlines strikt eingehalten werden.

• Datenfreeze im Altsystem: Ein klar definierter Stichtag für den letzten Stand der Altdaten ist unerlässlich, um Chaos zu vermeiden. Ab diesem Zeitpunkt (einige Stunden oder Tage vor der finalen Migration) dürfen im alten System keine neuen Daten mehr erfasst oder geändert werden. Das Altsystem wird faktisch auf „Read-Only“ gestellt. Dies stellt sicher, dass während der Cutover-Aktivitäten keine neuen Transaktionen im Altsystem passieren, die nachträglich in die neue Lösung übernommen werden müssten – die Datenbasis bleibt konsistent. Oft wird parallel ein letzter Voll-Export aller relevanten Daten aus dem Altsystem erstellt und archiviert, um eine prüfbare Ausgangsbasis zu haben.

• Technische Betriebsbereitschaft: Die neue Umgebung muss vorab vollständig eingerichtet und getestet sein. Dazu zählen die Installation/Deployment der CAFM-Software in der Produktionsumgebung, die Konfiguration aller Schnittstellen und Integrationen, Nutzer- und Rechteanlagen, sowie die Infrastruktur (Server, Netz, Clients) in produktionsgleicher Ausprägung. Performance-Tests und Lasttests sollten idealerweise durchgeführt worden sein, um sicherzustellen, dass das System unter Real-Last stabil läuft. Zudem müssen Monitoring-Tools vorbereitet sein, um ab Go-Live die Systemgesundheit zu überwachen. Teil der technischen Vorbereitung ist häufig auch ein Code-Freeze oder Change Freeze: In den letzten Tagen vor Go-Live werden keine neuen Features oder Änderungen mehr am System vorgenommen– es sei denn zur Behebung kritischer Fehler. So wird verhindert, dass kurz vor knapp neue Fehler eingebaut werden.

• Finale Tests und Abnahmen: Vor dem Cutover sind sämtliche Tests abzuschließen und alle Abnahmekriterien zu erfüllen. Dazu gehören: Funktionstests und Integrationstests (inkl. Schnittstellen zu z.B. ERP, HR-Systemen etc.) mit erfolgreich bestandenen Ergebnissen, Datenmigrationstests (Probeimporte der Altdaten ins Neusystem) mit Validierung der Daten, und insbesondere der User Acceptance Test (UAT) durch die Fachanwender. Alle kritischen Befunde (Severity 1 und 2 Fehler) müssen vor dem Livegang behoben oder mit Workarounds versehen sein. Go-Live-Abnahme: Die Fachbereiche sollten formal bestätigen, dass das System in ihrem Verantwortungsbereich einsatzbereit ist (Freigabe zum Go-Live). Oft wird hierfür ein Go-Live Readiness Meeting oder Go/No-Go-Meeting einberufen, bei dem anhand einer Checkliste geprüft wird, ob alle Voraussetzungen erfüllt sind (siehe Abschnitt 8). Wichtig ist auch, Testwiederholungen kurz vor dem Cutover einzuplanen: So sollten z.B. unmittelbar vor dem Stichtag nochmals finale End-to-End-Tests oder ein kurzer Pilotenlauf durchgeführt werden, um sicherzugehen, dass während der Freeze-Phase nichts übersehen wurde. Ein „Mock Cutover“ (eine simulierte Generalprobe der Umschalt-Prozedur in einer Testumgebung) kann helfen, die Schrittfolgen, Timings und Verantwortlichkeiten zu verifizieren und das Team einzuspielen.

• Schulungen & Support vorbereiten: Alle Endanwender und Support-Teams sollten bis zum Go-Live-Termin geschult sein. In der Cutover-Vorbereitung stellt man sicher, dass Key-User und Admins verfügbar sind und ggf. vor Ort oder telefonisch bereitstehen. Kommunikationskanäle für Unterstützung (Hotline, Chatgruppen etc.) werden definiert und getestet.

Vor Go-Live muss die neue Lösung betriebsbereit, getestet und freigegeben sein. Das beinhaltet, dass alle Beteiligten wissen, was ihre Aufgaben sind, und dass keine offenen Blocker existieren. Eine Cutover-Checkliste kann hier helfen, nichts zu übersehen – z.B.: „Letzter Datenexport erstellt? Finales Mapping versioniert? Alle Schnittstellen erfolgreich getestet? Key-User verfügbar und informiert? Support-Hotline besetzt?.

Am Tag des Go-Live (bzw. während des Cutover-Wochenendes) erfolgt eine Reihe geplanter Schritte nach Checkliste. Eine klare Ablaufplanung mit Verantwortlichkeiten stellt sicher, dass nichts vergessen wird und alle wissen, was wann zu tun ist.

• T – 0 (letzte Aktionen im Altsystem): Abschluss des Datenfreeze – es werden keine Transaktionen mehr im Altsystem zugelassen (Benutzer ausloggen oder auf Read-Only setzen). Start der finalen Datensicherung des Altsystems (Backup) und Erstellung des letzten Datenexports für die Migration. Ggf. Abschluss einer letzten Delta-Migration (Übernahme seit dem vorherigen Probelauf geänderter Daten). Go/No-Go Bestätigung einholen: Projektleitung und Fachseite geben grünes Licht, dass mit dem Umschalten begonnen wird.

• Durchführung der finalen Datenmigration ins Neusystem (Import der Altdaten aus dem letzten Export in die neue Umgebung). Dabei Monitoring der Migrationsjobs; bei Fehlern sofort Analyse/Behebung nach vordefinierten Procedures. Parallel dazu werden bereits technische Umschaltaufgaben erledigt: z.B. Umstellen von Schnittstellen und Integrationen auf das neue System (Ändern von API-Endpunkten, Dateischnittstellen auf neues Ziel verweisen etc.), Umkonfigurieren von Batch-Jobs und geplanten Tasks auf das neue System, Umlenken von Reporting-Tools, Druckerqueues oder mobilen Apps auf die neue Plattform.

• Validierung und Smoke-Tests: Nach erfolgter Migration und Einrichtung wird das neue System in einem kurzen Smoke-Test auf Herz und Nieren geprüft – idealerweise gemeinsam von IT und Fach-Key-Usern. Wichtige Fragen: Sind alle Daten vollständig und korrekt angekommen (Summenabgleiche, Stichproben)? Funktionieren die Kernprozesse (z.B. lassen sich Anlagen, Flächen, Tickets anlegen; können Berichte gezogen werden; Schnittstellen tauschen Daten aus)? Sind Benutzerzugriffe und Berechtigungen korrekt (können sich alle anmelden, richtigen Zugriff)? Diese Checks sollten in der Cutover-Planung als Aufgaben mit Verantwortlichen dokumentiert sein. Falls gravierende Probleme entdeckt werden, muss ggf. der Fallback-Plan greifen (siehe Abschnitt 7). Sind alle Prüfungen erfolgreich, wird die Fachseite den produktiven Betrieb freigeben.

• Produktivnahme und Umschalten der Nutzer: Sobald die Freigabe erteilt ist, erfolgt die eigentliche Go-Live-Aktivierung: Alle Nutzer werden informiert, dass das neue System nun live ist. Geplante Produktions-Jobs oder -Services werden gestartet (z.B. Hintergrunddienste, die bis dahin pausiert waren). Das Altsystem bleibt abgeschaltet oder in read-only für Notfälle, damit keine Verwirrung entsteht. Es kann sinnvoll sein, den Produktivstart zunächst als „Soft Opening“ zu gestalten: nicht alle neuen Funktionen sofort an alle Anwender kommunizieren, sondern ggf. stufenweise über den Tag verteilen, um das Support-Aufkommen zu steuern – dies hängt aber von Projekt und Unternehmenspraxis ab.

• Engmaschige Betreuung während des Tages: Am Go-Live-Tag (und den unmittelbar folgenden Tagen) sollte ein dediziertes Go-Live-Team bereitstehen – bestehend aus Key-Usern, IT, ggf. Herstellersupport oder Beratern –, um Fragen zu beantworten und etwaige Probleme sofort zu lösen. Dieses Team verfolgt einen klaren Go-Live-Taskplan und Häkchenliste: z.B. „Systemstart erfolgt um 6:00, Benutzer informiert um 7:00, erste Statusprüfung um 10:00“ etc. Verantwortlichkeiten sind eindeutig zugeordnet (wer überwacht Systemlogs, wer koordiniert die Kommunikation, wer priorisiert Eingabefehler).

• Status-Updates und Abschluss: Im Laufe des Cutover-Tages sollten regelmäßige Statusmeldungen an die definierten Stakeholder rausgehen (Projektleiter informiert Management: „Cutover läuft planmäßig, 50% der Daten migriert“ usw.). Nach erfolgreichem Abschluss aller Schritte wird ein „Go-Live abgeschlossen“-Update versendet. Hierbei kann man auch erste Erfolge melden (z.B. Anzahl erfolgreich übernommener Datensätze, erster Ticket erstellt im neuen System etc.), um Vertrauen zu schaffen.

Eine schriftliche Go-Live-Checkliste ist ein unverzichtbares Hilfsmittel am Umstellungstag. Darin werden alle vorgenannten Schritte mit Reihenfolge, Zuständigem und Erfolgskriterium festgehalten. Beispielsweise: „Datenbank-Backup Altsystem abgeschlossen (Verantwortlicher: DB-Admin)“, „Schnittstelle X auf neues System umgeschaltet (Verantw.: Entwickler Y)“, „Summenvergleich Auftragsbestand alter vs. neuer DB OK (Verantw.: Fachkeyuser)“ usw. – jeweils mit Zeitstempel und Abhaken. So behält das Team den Überblick, und nichts gerät „zwischen Tür und Angel“ in Vergessenheit.

Eine proaktive und transparente Kommunikation ist während der gesamten Go-Live-Phase essenziell – gegenüber allen Stakeholdern:

• Vor dem Cutover: Frühzeitig sollte intern und extern kommuniziert werden, wann der Go-Live stattfinden wird und welche Auswirkungen zu erwarten sind. Zum Beispiel: Ankündigung von geplanten Downtimes oder eingeschränkter Verfügbarkeit während des Cutover-Fensters, Hinweise für Endnutzer (bis wann müssen sie ihre offenen Vorgänge im Altsystem abschließen? Ab wann können sie das neue System nutzen? Wie melden sie Probleme?). Die interne Kommunikation bereitet die Teams auf die Umstellung vor – inkl. Support-Organisation: Alle sollen wissen, an wen sie sich wenden können, falls am Go-Live-Tag etwas nicht funktioniert. Auch die Geschäftsführung sollte eng eingebunden sein und den Rücken des Projekts stärken; idealerweise unterstützt ein internes Memo oder Intranet-Beitrag den positiven Wandel und weist auf die Bedeutung hin.

• Während des Cutovers: Halten Sie relevante Stakeholder durch Status-Updates auf dem Laufenden. Beispielsweise kann das Projektteam in regelmäßigen Abständen berichten („Datenübernahme läuft seit 2 Stunden, 70% abgeschlossen, keine Probleme bisher“). So bleiben alle ruhig und vorbereitet. Kritische Entscheider sollten jederzeit erreichbar sein (Bereitschaft), falls unerwartete Entscheidungen getroffen werden müssen (z.B. Go-Live abbrechen?). Es empfiehlt sich, einen Kommunikationskanal (z.B. einen Chat oder Call-Konferenzraum) einzurichten, in dem das Kernteam permanent verbunden ist. Gleichzeitig muss nach außen, etwa an einen definierten Benutzerverteiler, nur gefilterte Information kommuniziert werden, um Verwirrung zu vermeiden. Ein Beispiel: Ein kurzes Rundschreiben am Morgen nach der Umstellung, dass das System erfolgreich live ist und man nun im neuen System arbeitet, verbunden mit einem Dank an alle Beteiligten, schafft Klarheit.

• Nach dem Cutover: Auch in der Nachlaufphase (Hypercare) bleibt Kommunikation wichtig. Die externe Kommunikation könnte z.B. Pressemitteilungen oder Kundeninformationen umfassen, falls der Umstieg Außenwirkung hat (etwa „Wir haben ein neues Facility-Management-System eingeführt, um unseren Service zu verbessern“). Wichtiger ist jedoch die interne Nachkommunikation: Ein paar Tage nach Go-Live sollten alle Benutzer über den Stand informiert werden: Läuft alles wie geplant? Welche Probleme sind ggf. aufgetreten und wurden gelöst? Dieses offene Feedback stärkt das Vertrauen. Zudem sollten Feedback-Kanäle bereitgestellt werden, damit Anwender frühe Erfahrungen oder Schwierigkeiten melden können, ohne Hürden. Das Support-Team sollte diese Rückmeldungen systematisch erfassen und adressieren.

Im Projektteam selbst ist es üblich, unmittelbar nach Go-Live (oder nach der Hypercare-Phase) eine Retrospektive abzuhalten: Was lief gut, was muss beim nächsten Mal besser kommuniziert werden?. Insgesamt gilt: Keine Nachricht ist die schlimmste Nachricht. Daher lieber umfassend und ruhig kommunizieren, als die Gerüchteküche arbeiten zu lassen. Geplante Kommunikationsmaßnahmen rund um den Livegang – von Ankündigungen bis Dankes-E-Mails – sollten fester Bestandteil des Cutover-Plans sein.

Trotz bester Planung muss man auf den Ernstfall vorbereitet sein: Was, wenn etwas schiefgeht? Hier kommen Backup- und Fallback-Szenarien ins Spiel.

• Backups: Vor dem Go-Live ist es Pflicht, vollständige Datensicherungen aller relevanten Systeme durchzuführen – insbesondere ein aktuelles Backup der Altdatenbank nach dem letzten Datenstand (Freeze) und idealerweise auch ein initiales Backup der neuen Umgebung vor dem Start (sofern schon Daten migriert wurden). Diese Backups sind die Versicherung, um im Zweifel einen Stand wiederherstellen zu können. Sie sollten geprüft sein (Restore-Test) und offline sicher aufbewahrt werden, damit sie im Fall von Datenkorruption durch die Migration verfügbar sind.

• Fallback-Strategie: Ein Rollback im Big-Bang-Ansatz ist schwierig, aber man muss zumindest definieren, bis zu welchem Punkt man im Notfall zurückgehen kann. Idealerweise erstellt man einen Fallback-Plan, der genau beschreibt, wie und wann zurückgeschaltet wird, falls der Cutover scheitert. Einige empfohlene Maßnahmen sind beispielsweise: Das Altsystem nach dem Freeze-Zeitpunkt zunächst nicht sofort physisch abzuschalten, sondern noch für eine gewisse Zeit im Hintergrund verfügbar zu halten (z.B. im Read-Only-Modus für 24 Stunden). So kann man, wenn das neue System innerhalb dieses Zeitfensters gravierend versagt, theoretisch die Benutzer wieder auf das Altsystem lassen, um dort weiterzuarbeiten (wobei dann die neuen Daten evtl. nacherfasst werden müssten). Ein anderer Ansatz ist, Snapshots der neuen Systemumgebung direkt vor dem Go-Live zu machen. Sollte das Update fehlschlagen, könnte man die neue Umgebung auf den Snapshot zurücksetzen und nochmal versuchen oder auf einen neuen Plan umschwenken. Wichtig ist auch, klare Abbruchkriterien im Voraus festzulegen: z.B. „Wenn Migration bis Sonntag 12:00 nicht vollständig, dann Rollback einleiten“ oder „Wenn nach Go-Live mehr als 20% der Kernfunktionalitäten ausfallen, binnen 2 Stunden Entscheidung zum Rückgang treffen“. Solche Go/No-Go-Checkpoints schützen davor, aus Euphorie in einen unsauberen Livebetrieb zu gehen.

Es sollte explizit dokumentiert sein, wer die Entscheidung trifft, den Fallback-Plan zu aktivieren (in der Regel der Lenkungsausschuss oder Projektleiter in Rücksprache mit Fachbereich und IT-Leitung). Der Fallback-Plan selbst muss die nötigen Schritte enthalten, um geordnet zurückzukehren: z.B. Neuen Datenbank-Import abbrechen, neue Systeme offline nehmen, Altsystem-Backup zurückspielen, Altsystem wieder online schalten, Kommunikationswege (Benutzer informieren über Verzögerung) usw. Realistisch betrachtet, strebt man bei Big Bang einen „Point of no Return“ an – wenn z.B. die Datenmigration final abgeschlossen wurde und das neue System bereits in Benutzung ist, ist ein komplettes Zurückrollen oft nicht mehr möglich oder nur mit immensem Aufwand (Dateninkonsistenzen!). Daher lautet die Devise: Fallback möglichst vermeiden durch intensive Vorabtests, aber für den Worst Case gerüstet sein, um wenigstens den Geschäftsbetrieb aufrechtzuerhalten (notfalls auch manuelle Fallbacks bereit halten: etwa Formulare in Excel als Zwischenlösung, falls das System nicht verfügbar ist, um wichtige Prozesse nicht zu blockieren).

Eine weitere Absicherung ist das Bereithalten von Business-Continuity-Maßnahmen während des Cutovers: Beispielsweise, sollte die Umstellung länger dauern als geplant, haben die Fachabteilungen idealerweise vorher definiert, wie sie kritische Aufgaben überbrücken (Papierformulare, Offline-Erfassung zur späteren Nachpflege etc.). Diese Pläne liegen idealerweise schriftlich vor. Insgesamt gibt ein durchdachter Fallback-Plan allen Beteiligten auch psychologische Sicherheit, „dass wir für alles gerüstet sind“ – oft muss er gar nicht zum Einsatz kommen, aber er erhöht die Vertrauensbereitschaft in den Go-Live erheblich.

Bevor der Schalter endgültig umgelegt wird, müssen klare Abnahmekriterien definiert und erfüllt sein. Diese Kriterien legen fest, unter welchen Bedingungen das neue System als „einsatzbereit“ gilt und der Go-Live erfolgen darf.

• Vollständige Umsetzung der Anforderungen: Alle Muss-Anforderungen des Pflichtenhefts sind im System umgesetzt und verifiziert. Offene Change Requests, die nicht zwingend sind, wurden entweder verschoben oder als nicht-blockierend eingestuft.

• Erfolgreiche Tests: Alle Testphasen (Unit, Integration, UAT) sind abgeschlossen und bestanden. Insbesondere der User Acceptance Test ist formal abgenommen durch die Fachverantwortlichen. Keine kritischen Fehler (Kategorie 1) sind mehr offen; schwerwiegende Fehler (Kategorie 2) nur, wenn akzeptable Workarounds vorhanden sind.

• Datenmigration valide: Die migrierten Daten wurden überprüft (Abgleiche von Mengen und Summen, Stichproben auf inhaltliche Korrektheit) und von den Datenverantwortlichen freigegeben. Geplante Migrationsläufe (inkl. Test-Migrationen) waren erfolgreich. GoBD/Governance-Anforderungen (Nachvollziehbarkeit der Datenübernahme, Archivierung historischer Daten) sind erfüllt.

• Benutzer und Rechte eingerichtet: Alle benötigten Benutzeraccounts, Rollen und Berechtigungen im neuen System sind eingerichtet und von den Fachbereichen geprüft (z.B. können alle wichtigen Benutzer sich anmelden und sehen das korrekte Berechtigungsspektrum).

• Schulung und Dokumentation: Endanwender und Supportpersonal wurden geschult. Es existieren aktuelle Benutzerdokumentationen oder Online-Hilfen. Die Anwender wissen, wo sie Hilfe bekommen (Helpdesk ist informiert).

• Betriebs- und Supportkonzept steht: Monitoring, Backup, Disaster Recovery, und Supportprozesse für das neue System sind definiert und getestet. Verträge mit ggf. externen Betriebspartnern oder SaaS-Anbietern sind aktiv ab Go-Live.

• Go-Live-Team bereit: Alle personellen Ressourcen für den Go-Live sowie Nachbetreuung sind eingeplant und verfügbar (Bereitschaftspläne). Zuständigkeiten für jedes Go-Live-Task sind benannt.

Diese Kriterien münden in eine Go/No-Go-Entscheidung kurz vor dem Cutover: In einem Meeting (oft am Tag vor dem Cutover-Fenster) beurteilen Projektleitung, Fachbereichsleiter und IT-Verantwortliche gemeinsam anhand einer Checkliste, ob alle Abnahmekriterien erfüllt sind. Ist dies der Fall, wird offiziell "Go" gegeben – andernfalls "No-Go", d.h. der Go-Live müsste verschoben werden. Hierbei gilt es, ehrlich und streng zu sein: „Entweder die Kriterien sind erfüllt, oder nicht – Wunschdenken zählt nicht.“ Es sollte klar dokumentiert sein, wer die finale Abnahme erteilt (z.B. der Projekt-Sponsor oder Lenkungsausschussvorsitzende).

Mit dem Go-Live selbst erfolgt die Aktivierung der produktiven Prozesse: Das bedeutet, dass ab diesem Moment alle Geschäftsprozesse, die von der Software unterstützt werden, offiziell auf das neue System übergehen. Praktisch gesehen heißt das: Umschalten der Organisation auf das neue System. Beispiele: - Mitarbeiter im Facility Management erfassen neue Wartungsaufträge nun im neuen CAFM-System (und nicht mehr im alten oder auf Papier). - Automatische Prozesse wie Ticket-Erstellung, Eskalationen, Berichte laufen jetzt produktiv im neuen System. - Schnittstellen zu Buchhaltung oder Personalwesen schicken ihre Daten ab jetzt an das neue System.

Oft wird unmittelbar nach dem Go-Live eine Produktivitätsprüfung gemacht: Läuft z.B. die erste automatisch generierte Wartungsplanung korrekt durch? Funktionieren Buchungsläufe oder Berichtsgenerierungen planmäßig? Dies sind die Punkte, an denen man merkt, dass die „produktiven Muskeln“ nun spielen. Die Projektverantwortung geht jetzt Stück für Stück an den operativen Betrieb über. Formal kann es einen Abnahmebericht geben, der festhält, dass das System ab einem bestimmten Zeitpunkt X in Kundenverantwortung (Regelbetrieb) übergeht, nachdem die festgelegten Abnahmekriterien erfüllt wurden.

Abnahmekriterien sorgen dafür, dass zum Go-Live keine bösen Überraschungen auftauchen, und die Aktivierung produktiver Prozesse bedeutet den Start des echten Geschäfts auf der neuen Plattform – ab da muss das System seine Versprechen im Arbeitsalltag einlösen.

Nach dem Go-Live beginnt keineswegs sofort „business as usual“. Vielmehr schließt sich die Hypercare-Phase an – eine intensivere Nachbetreuungsphase direkt im Anschluss an die Produktionssetzung. In dieser Zeit wird das neue System besonders eng überwacht und unterstützt, um sicherzustellen, dass es stabil läuft und eventuelle Anfangsschwierigkeiten schnell behoben werden.

Hypercare (oft 2-6 Wochen, je nach Projektgröße) bedeutet: erhöhtes Support- und Monitoring-Level. Das Projektteam (oder ein dediziertes Hypercare-Team) steht in erhöhter Alarmbereitschaft bereit, um unverzüglich auf Probleme zu reagieren. Es werden tägliche Statusrunden durchgeführt, in denen offene Post-Go-Live-Probleme priorisiert und Lösungsaktionen koordiniert werden. Ziele der Hypercare-Phase sind vor allem Stabilisierung des Systems, schnelle Fehlerbehebung und Unterstützung der Anwendereicht vor Ort Präsenz oder spezielle Hotline-Zeiten an, um Fragen zum neuen System zu beantworten und Anwenderakzeptanz zu fördern. Gleichzeitig wird geschaut, ob die realen Geschäftsprozesse reibungslos funktionieren: Passen die Workflows, kommen die Nutzer zurecht oder braucht es Nachschulungen? Gerade Change Management spielt in der Hypercare-Zeit eine große Rolle, um etwaigen Widerständen oder Unsicherheiten aktiv zu begegnen.

Ein wesentliches Element der Nachlaufphase ist auch das Monitoring als Frühwarnsystem. Direkt nach Go-Live fährt man idealerweise verstärktes Monitoring auf allen Ebenen: Systemmetriken (Server-CPU, Speicher, Antwortzeiten der Anwendung), Schnittstellenverkehr, Fehlermeldungen/Logs und auch Business-KPIs (z.B. Anzahl erfasster Vorgänge vs. erwartet) werden laufend beobachtet. Bei Big-Bang-Umstellungen sollte die Überwachung in kurzen Intervallen erfolgen, mit vorbereiteten Dashboards für die neue Architektur. Wichtig sind auch automatisierte Alarmierungen: Schon kleine Anomalien – z.B. ansteigende Fehlerquoten oder Performance-Einbrüche – sollen sofort gemeldet werden, bevor sie sich zu großen Problemen ausweiten Branchen setzt man hier auch auf sogenannte Early-Warning-Systeme, die definierte Schwellenwerte überwachen und ggf. automatische Gegenmaßnahmen einleiten (im einfachsten Fall: bei Responsezeit > X wird Alarm ausgelöst und evtl. ein Rollback-Trigger vorbereitet). Gerade nach einem Big Bang ist kein Vergleich mit einer alten Version parallel möglich, daher ist ein Baseline-Vergleich wichtig: Man nutzt die vor Go-Live erhobenen Performancewerte (Baseline) und definierten Service Level Objectives als Bezugspunkt, um zu prüfen, ob das neue System diese einhält oder auffällige Abweichungen zeigt.

Frühwarnsysteme können neben technischen Monitoring-Tools auch organisatorisch sein: z.B. tägliche Feedback-E-Mails von Key-Usern in den ersten zwei Wochen („Was lief heute nicht rund?“) oder ein Online-Portal, wo Nutzer Probleme eintragen. All das hilft, rasch ein vollständiges Bild zu bekommen und schnell einzugreifen.

Parallel dazu läuft meist ein definiertes Problem- und Incident-Management: Alle auftretenden Fehler nach Go-Live werden erfasst, priorisiert und möglichst umgehend gelöst. Kleinere Nacharbeiten oder Konfigurationskorrekturen sind normal – sie sollten in der Hypercare-Phase konzentriert abgearbeitet werden, solange das Projektteam noch involviert ist.

Die Hypercare-Phase endet, wenn das System nachhaltig stabil läuft und die Anzahl/Schwere der Incidents zurückgeht. Typischerweise findet dann ein formelles Meeting statt, um den Übergang in den Regelbetrieb zu erklären. Dennoch wird empfohlen, erhöhtes Monitoring noch mindestens 3-6 Monate beizubehalten, um auch verzögerte Effekte oder saisonale Spitzen abzufangen. Erst wenn das System über einen längeren Zeitraum die Erwartungen erfüllt, kann man zum normalen Betrieb übergehen.

Die Nachlaufphase dient dazu, den Erfolg des Projekts abzusichern. Hypercare stellt intensiven Support sicher, Monitoring dient als Frühwarnsystem, um technische oder organisatorische Probleme früh zu erkennen. So wird garantiert, dass das neue CAFM/IWMS-System seine Vorteile voll ausspielen kann, ohne dass Anfangsprobleme das Vertrauen verspielen.

Nach erfolgtem Go-Live – sobald sich der Staub etwas gelegt hat – sollte das Projektteam unbedingt eine Lessons Learned-Sitzung durchführen. In dieser wird systematisch aufgearbeitet: Was lief gut? Was lief schlecht? Was können wir beim nächsten Mal besser machen? Die dabei gewonnenen Erkenntnisse sind Gold wert für zukünftige Projekte oder weitere Rollout-Phasen. Viele Organisationen verzichten aus Zeitmangel darauf, dokumentierte Lessons Learned zu erstellen – und wiederholen dadurch in späteren Projekten die gleichen Fehler. Das gilt es zu vermeiden.

• Waren die Zeitplanung und Ressourcenplanung realistisch? Wo gab es Engpässe oder unnötige Puffer?

• Haben die Testphase und Datenmigration gut genug vorbereitet? Gab es unerwartete Datenprobleme oder Schnittstellenthemen, die man früher hätte erkennen können?

• War die Kommunikation ausreichend? Fühlten sich die Endanwender genügend abgeholt und informiert?

• Wie hat das Team funktioniert unter Go-Live-Druck? Stimmen die Verantwortlichkeiten, oder gab es Chaos/Unsicherheit an irgendeiner Stelle?

• Hätten wir einen Parallelbetrieb gebraucht, oder war Big Bang die richtige Entscheidung? (Diese Frage ist je nach Ausgang interessant, um die Strategie zu reflektieren.)

• Wurden Fallback-Pläne benötigt und haben sie funktioniert? - Gab es Überraschungen trotz aller Planung? Wie können wir solche Unknowns künftig früher entdecken (z.B. durch bessere Discovery oder Probeläufe)?

Die Ergebnisse dieser Analyse sollten in einem Lessons Learned-Dokument festgehalten und allen relevanten Stakeholdern zugänglich gemacht werden. Insbesondere für Unternehmen, die regelmäßig IT-Projekte durchführen, ist es sinnvoll, eine Wissensbasis aufzubauen: z.B. eine Checkliste, die bei jedem neuen Go-Live erweitert wird, oder ein internes Wiki mit Best Practices.

Wichtig ist auch der Transfer der Lessons Learned in zukünftige Go-Lives: Die Erkenntnisse sollten in die Methodik einfließen. Wenn z.B. festgestellt wurde, dass die Key-User-Einbindung zu spät kam, sollte dies bei der nächsten Einführung von Beginn an anders geplant werden. Oder wenn ein bestimmtes technisches Monitoring-Tool sich als hilfreich erwiesen hat, sollte es zum Standard für alle weiteren Projekte werden.

Nicht zuletzt dienen Lessons Learned auch der Team- und Kulturentwicklung: Erfolgreiche Aspekte dürfen gewürdigt und gefeiert werden, um das Team zu motivieren. Fehler dürfen offen benannt werden, ohne Schuldzuweisung, um daraus zu lernen. Eine solche offene Lernkultur verbessert langfristig die Projektfähigkeit der Organisation.

Ein sauber geplanter Go-Live ist kein Zufall, sondern das Ergebnis strukturierter Vorbereitung – und künftige Go-Lives werden umso reibungsloser, je mehr man aus früheren Erfahrungen gelernt hat. Lessons Learned zu sichern und im Unternehmen zu verankern, ist daher ein letzter, aber entscheidender Schritt, um den Erfolg des aktuellen Projekts in zukünftige Vorhaben zu übertragen.