CAFM: Go Live Readiness Review

Das Readiness-Review deckt mehrere Prüfdimensionen ab – im Wesentlichen fachlich, technisch und organisatorisch. Fachlich wird beispielsweise überprüft, ob alle geplanten Geschäftsprozesse korrekt abgebildet und getestet sind (UAT-Abnahme, Datenintegrität, Prozess-Workflows). Technisch stehen die Systeminfrastruktur, Performanz und Sicherheit im Fokus: Systemperformance unter Last, Monitoring, Schnittstellenzuverlässigkeit, Datenbanken, Netzwerkkonfiguration, Sicherheitskonzepte sowie Backup-/Recovery-Tests. Organisatorisch werden Schulungsstand, Support- und Eskalationsprozesse sowie das Rollen- und Rechtemodell bewertet. Oft orientiert man sich dabei an ganzheitlichen Frameworks: So entspricht das ITIL-Konzept etwa den fünf Dimensionen People, Process, Technology, Documentation, Governance. Hierzu zählen u. a. geschulte Betriebsverantwortliche (People), definierte Support- und Incident-Prozesse (Process), verifizierte System- und Integrations-Funktionen (Technology), vollständige Dokumentation und SLAs (Documentation) sowie Risiken und Freigabeprotokolle (Governance). In der Praxis heißt das etwa, dass alle Anwender*innen ihre Aufgaben kennen, klare Verantwortlichkeiten bestehen und Supportabläufe etabliert sind, bevor das System live geht.

• Abgeschlossene User Acceptance Tests (UAT): Alle Abnahmekriterien sind erfüllt und von den Fachabteilungen bestätigt. Alle Testfälle, inklusive Extremszenarien, wurden erfolgreich ausgeführt. Offene Fehler oder Abweichungen sind entweder behoben oder im Rahmen von Restpunktelisten dokumentiert und absehbar (manageable).

• Datenmigration: Die Übernahme aller notwendigen Stammdaten und Bestände in die Zielumgebung ist vollständig und validiert. Migrationsprotokolle wurden geprüft und Datenkonsistenz festgestellt.

• Rollen- und Berechtigungskonzept: Das Rollenkonzept ist implementiert, alle Nutzerberechtigungen sind zugewiesen und in Tests verifiziert. Beispiel: Wird im Testlauf genau mit den Produktiv-Rollen gearbeitet.

• Schnittstellen: Sämtliche relevanten Schnittstellen sind aufgebaut, und Durchlauf- sowie Lasttests belegen die Funktionstüchtigkeit. Externe Systeme, z. B. ERP- oder Buchhaltungssysteme, synchronisieren fehlerfrei mit dem CAFM-System.

• System-Installation: Hardware und Software-Komponenten sind installiert und konfiguriert. Beispielsweise ist das CAFM-System lauffähig auf der Zielinfrastruktur. Alle erforderlichen Tools (z. B. für Reporting oder Mobile Apps) sind eingebunden.

• Schulung/Training: Alle Endanwender und Key-User wurden geschult; Schulungsunterlagen sind verteilt und verstanden. Die Mitabeiter können das System bedienen und kennen Supportwege. - Betrieb und Service: Das Betriebshandbuch (Runbook) liegt vor, die Supportorganisation steht bereit. Dokumentation wie Wartungspläne, SLAs und Notfallpläne ist finalisiert.

• Go/No-Go-Kriterien: Konkrete Stop-Kriterien werden definiert. Typisch ist etwa „100 % der kritischen UAT-Fälle bestanden“ oder „keine offenen kritischen Bugs“. Alle vorherigen Meilensteine (z. B. Master Data Freeze) wurden erreicht.

Diese Kriterien können tabellarisch oder als Checkliste abgearbeitet werden. In vielen Projekten hat es sich bewährt, diese Liste frühzeitig zu erstellen und während der Testphase sukzessive abzuhaken (statt nur punktuell kurz vor Go-Live). Ein Beispiel-Checkpunkt aus der Praxis: „Das CAFM-System ist erfolgreich installiert, alle Endanwenderschulungen sind durchgeführt und alle Servicefahrzeuge stehen bereit“.

Alle Beteiligten müssen in den Readiness-Prozess eingebunden werden. Wesentliche Rollen sind die Projektleitung (bspw. Projektmanager), IT-Architektur/Systemadministration (Infrastruktur, Netzwerke), Betrieb/Facility-Management (die künftigen Betreiber bzw. Betreiberverantwortlichen) sowie die betroffenen Fachbereiche. Oft gehören auch Key-User, Datenschutzbeauftragte oder interne Revision mit dazu. Idealerweise nehmen diese Gruppen gemeinsam am Go-Live-Workshop teil, um die Ergebnisse zu diskutieren. Ein Abstimmungsgremium (z. B. Steering Committee oder Change Advisory Board) entscheidet schließlich formal über die Freigabe. In der Praxis hat sich gezeigt, dass ein gemeinsamer Abschlussworkshop kurz vor Go-Live (etwa drei Tage vor dem Start) alle Stakeholder synchronisiert und offene Fragen klärt.

Die Resultate des Readiness-Reviews werden üblicherweise in einem Abnahmeprotokoll oder Report festgehalten. Darin werden alle geprüften Punkte dokumentiert und deren Status vermerkt. Abschließend erfolgt ein formaler Freigabeprozess: Ein Gremium (etwa Lenkungsausschuss) erteilt das Go/No-Go für den Live-Betrieb. Die endgültige Entscheidung basiert auf den geprüften Kriterien und Risiken. Eventuelle Restprobleme werden in einer Restpunkteliste (Punch List) geführt – diese enthält alle noch offenen Aufgaben mit Verantwortlichkeiten und Terminen. Unkritische Nacharbeiten können in der Hypercare-Phase (stabilisierter Betrieb nach Go-Live) abgeschlossen werden, während kritische Fehler ein Aufschieben des Go-Live erzwingen. Wichtig ist, dass sämtliche Beschlüsse und Aktionspunkte dokumentiert sind. Nach ITIL erfordert eine klare Governance-Phase beispielsweise, dass „Approvals klar erteilt“ sind und Risiken transparent geloggt wurden. Auch das Team berichtet im Anschluss aktiv an das Management, um Transparenz über mögliche Restschritte zu schaffen.

Das Go-Live-Readiness-Review ist kein technischer Umstellungsplan, sondern eine Vorbereitung und Freigabeprüfung. Während der Cutover- oder Go-Live-Plan die konkreten Schritte zur Umstellung (z. B. abschalten alter Systeme, Datenfinalisierung, Produktivsetzung und Backout-Verfahren) detailliert beschreibt, überprüft das Readiness-Review nur, ob die Voraussetzungen hierfür gegeben sind. In Microsoft-Implementierungen (Dynamics 365 F&O) wird etwa deutlich zwischen „Readiness Review“ und „Cutover Activities“ unterschieden: Das Review kommt vor der Produktionseinführung (Deploy), erst danach folgen Datenübernahme und eigentliche Cutover-Aktivitäten. Anders formuliert: Das Readiness-Review sagt “Wir sind bereit zum Schalten”, der Cutover-Plan sagt “So schalten wir jetzt um”. Beide Schritte hängen zwar eng zusammen, aber dienen unterschiedlichen Zwecken.

Aus Lessons-Learned-Analysen und Best-Practice-Erfahrungen lassen sich Empfehlungen ableiten: Zum Beispiel sollten Readiness-Checks möglichst strukturiert, schlank und faktenbasiert sein. Ein ITIL-inspiriertes „Lite“-Checklistenkonzept hat sich bewährt: konzentriert auf die wichtigsten Prüfungen, schnell durchführbar, leicht verständlich und evidenzbasiert. Es empfiehlt sich, den Review-Prozess früh in der Planung zu definieren, Checklisten schrittweise im Projekt zu aktualisieren und Ergebnisse schon in Zwischenschritten zu dokumentieren. Regelmäßige Status-Updates im Projektteam halten Risiken überschaubar. Zudem hilft eine offene Kommunikation: Gemeinsame Vorbereitungssitzungen mit allen Stakeholdern stellen sicher, dass jeder Kontext versteht und relevante Vorarbeiten termingerecht erledigt werden. Fachbereich und IT sollten bis zum letzten Moment – beispielsweise im letzten Test-Sprint – eng zusammenarbeiten, um späte Änderungen zu vermeiden. Auf Benutzerseite wirkt sich erhöhte Transparenz positiv aus: Klare Vorgaben (z. B. „Bis X dürfen keine neuen Features implementiert werden“) verhindern Last-Minute-Schocks. Schließlich sind nach erfolgtem Go-Live kurze Feedback-Runden und ein gezieltes Lessons Learned-Meeting empfehlenswert, um Checklisten für künftige Projekte weiter zu verbessern. Allgemein zeigen Erfahrungen: Je öfter der Readiness-Prozess wiederholt und überarbeitet wird, desto zuverlässiger deckt er spätere Risiken ab. Missverständnisse sollten unbedingt sofort adressiert, jedoch bürokratische Hürden vermieden werden.