CAFM: Übergabe in Betrieb (Handover, SLAs, Verantwortlichkeiten)

Eine formale Betriebsübergabe sollte erst erfolgen, wenn alle Abnahmekriterien erfüllt und die Betriebsbereitschaft nachgewiesen sind.

• Erfolgreiche Abnahme-Tests: Alle vereinbarten Tests (Funktions-, Integrations-, Abnahmetests) sind durchgeführt und kritische Mängel behoben. Ein strukturiertes Go-Live Readiness-Review bestätigt, dass das System produktionsreif ist. Bevor der Betrieb startet, sollten idealerweise auch ein Probebetrieb bzw. Pilotlauf stattgefunden haben, um das Zusammenspiel aller Komponenten unter Realbedingungen zu erproben.

• Erfüllte Abnahmekriterien laut Vertrag/Pflichtenheft: Falls vertragliche Abnahmekriterien definiert wurden (z. B. Leistungsnachweise, Schnittstellen-Funktionen, Performance-Werte), müssen diese erreicht sein. Oft wird hierzu ein Abnahmeprotokoll erstellt, das von Auftraggeber und -nehmer unterschrieben wird. Darin werden ggf. noch offene Punkte (Restmängel) mit Fristen festgehalten.

• Betriebsfähigkeit („Production Readiness“): Alle technischen Grundvoraussetzungen für den Betrieb sind gegeben. Dazu gehört z. B., dass die Zielumgebung (Server, Netzwerk, Datenbank) korrekt aufgesetzt und gehärtet ist, Monitoring und Backup eingerichtet sind und Sicherheitsanforderungen umgesetzt wurden. Die technische Grundlage muss abgenommen sein – d. h. Gegenüberstellung der implementierten Komponenten mit den Anforderungen ergibt keine kritischen Lücken.

• Geschultes Personal: Die künftigen Anwender und Administratoren wurden ausreichend geschult, um das System im Alltag bedienen und verwalten zu können. Es sollte geprüft werden, ob Schulungsmaßnahmen (Key-User-Schulungen, Betriebs-Handbücher etc.) abgeschlossen sind und ob evtl. Wissenslücken bestehen, die vor Go-Live zu schließen sind.

• Supportstruktur steht bereit: Helpdesk und Support-Teams müssen auf das neue System vorbereitet sein (siehe unten zur ITSM-Integration). Insbesondere müssen Supportwerkzeuge, Prozesse und Ansprechpartner definiert und aktiv sein, sobald der Betrieb startet. Beispielsweise sollte das System im Service-Desk-System erfasst sein und die Support-Mitarbeiter müssen wissen, wie sie Anfragen dazu behandeln.

• Dokumentation vorhanden: Vollständige Betriebsdokumentationen (siehe nächster Abschnitt) liegen vor. Ohne aktuelle Dokumente zur Systemkonfiguration, Schnittstellen, Benutzerrechte etc. kann kein geordneter Betrieb stattfinden. Unklare oder fehlende Doku würde zu Verzögerungen und Risiken führen – daher ist dies zwingende Voraussetzung für die Abnahme.

• Betriebsgenehmigung durch Stakeholder: Ggf. muss von bestimmten Stellen (z. B. IT-Sicherheitsbeauftragter, Datenschutz, Betriebsrat bei Änderungen für Nutzer) eine Freigabe vorliegen, dass das System in Produktion gehen darf. Ebenso sollte die Fachabteilung, die das System nutzt, per Abnahmeprotokoll bestätigen, dass das System ihren Anforderungen entspricht (User Acceptance).

Wenn all diese Voraussetzungen erfüllt sind, steht einer formalen Übergabe nichts mehr im Wege. Dieser formale Akt kann z. B. in einem Übergabemeeting mit Unterschrift eines Übergabeprotokolls erfolgen, in dem beide Seiten (Projekt und Betrieb) bestätigen, dass das System ab Stichtag X vom Betriebsteam übernommen wird. Ab dann trägt das Betriebsteam die Verantwortung im Regelbetrieb, während das Projektteam nur noch ggf. im Rahmen von Gewährleistung oder Early-Life-Support (siehe unten) unterstützend tätig wird.

Ein zentrales Instrument der Übergabe ist das Handover-Dossier – eine Sammlung aller wichtigen Informationen und Dokumente, die für den Betrieb des Systems benötigt werden. Dieses Dossier dient als Nachschlagewerk und Beweis dafür, dass alle Vereinbarungen und Voraussetzungen erfüllt wurden.

• Übergabe-Checkliste: Eine Checkliste aller Punkte, die vor der Übergabe erledigt sein müssen – beispielsweise „Benutzerverwaltung eingerichtet“, „Monitoring-Alarme konfiguriert“, „Datensicherung getestet“, „Betriebsdoku übergeben“, „SLAs unterzeichnet“ etc. Diese Liste wird im Übergabetermin durchgegangen und abgehakt. Sie stellt sicher, dass nichts übersehen wurde.

• Systemdokumentation: Umfasst Architekturübersichten, Infrastruktur-Pläne (Server, Datenbanken, Netzwerk), Schnittstellenbeschreibungen, Datenmodell und Konfigurationseinstellungen. Wichtig ist ein konsistentes Asset-Register aller relevanten Komponenten mit IDs, Versionen, Standorten etc., damit der Betrieb weiß, was genau betreut wird.

• Benutzerdokumentation: Handbücher für Endanwender und Admins, ggf. Schulungsunterlagen, FAQ-Liste für typische Anwendungsfälle. Diese helfen dem Betriebsteam und den Key-Usern, die korrekte Anwendung des Systems sicherzustellen.

• Betriebshandbuch: Eine Anleitung für die Betreiber mit allen routinemäßigen Abläufen (z. B. Systemstart/Shutdown, Backup-Wiederherstellung, Benutzeranlage, Logs prüfen, Schnittstellen überwachen). Hier sollten auch Notfallprozeduren beschrieben sein (z. B. was tun bei Systemausfall, Wer kontaktiert wen?).

• Wartungs- und Supportplan: Beschreibung geplanter Wartungsfenster, Update-Zyklen und Release-Management-Prozesse. Dazu gehört eine Übersicht, wann welche Komponenten zu patchen sind, wie Updates eingespielt werden und wer dies freigibt. Auch Kontaktdaten von Herstellersupport oder Dienstleistern für Störungen gehören dazu.

• Verantwortlichkeitsmatrix (RACI): Eine übersichtliche Tabelle, wer für welche Aufgaben verantwortlich ist. Beispielsweise: CAFM-Admin (verantwortlich für Benutzerverwaltung und Stammdatenpflege), IT-Betrieb (verantwortlich für Serverbetrieb und Datensicherung), Hersteller (verantwortlich für Bugfixes in der Software) usw. Diese Matrix stellt sicher, dass im Betrieb alle wissen, wer wofür der Ansprechpartner ist.

• Vertrags- und SLA-Dokumente: Falls externe Dienstleister eingebunden sind (z. B. Cloud-Anbieter, Support-Dienstleister), sollten die relevanten Verträge und Service Level Agreements im Dossier abgelegt sein, damit das Betriebsteam jederzeit die Pflichten und Zusagen einsehen kann.

• Offene Punkte / Restarbeiten: Eine Liste etwaiger Restmängel oder Nacharbeiten, die im Rahmen des Projekts identifiziert wurden, aber erst nach Go-Live abgeschlossen werden. Wichtig ist hier eine klare Benennung der Verantwortlichen und Deadlines je Punkt, damit diese im Betrieb nachverfolgt werden können (oft im Abnahmeprotokoll enthalten).

• Change-Historie: Optionale Auflistung, welche größeren Changes oder Anpassungen während des Projekts vorgenommen wurden (z. B. Modul X doch nicht implementiert), um dem Betrieb Kontext zu geben. Ebenso könnte eine Lessons-Learned-Sektion für interne Zwecke enthalten sein, was im Projekt gut/schlecht lief – das hilft dem Betriebsteam, häufige Stolpersteine zu kennen.

Beginnen Sie mit der Dokumentation frühzeitig während des Projekts, damit am Ende nicht hektisch Informationen zusammengesucht werden müssen. Ein häufiger Fehler ist unzureichende Dokumentation, was später im Betrieb zu Wissenslücken führt. Das Projektteam sollte laufend alles Wesentliche dokumentieren, was für den operativen Alltag gebraucht wird – in angemessener Detailtiefe, ohne sich in Nebensächlichkeiten zu verlieren. Eine gut strukturierte Übergabedokumentation ist Gold wert, wenn nach Monaten noch nachvollziehbar sein muss, warum etwas so konfiguriert wurde.

Ein wesentlicher Teil der Übergabe ist das Definieren von Service Level Agreements (SLAs) sowie internen Betriebsvereinbarungen.

• Leistungsumfang und Verfügbarkeitsanforderungen: In einem SLA wird vereinbart, welche Dienste das CAFM-System bietet und mit welcher Verfügbarkeit (z. B. 99% Uptime in definierten Zeitfenstern) es laufen muss. Auch Wartungsfenster sollten festgelegt werden (z. B. reguläre Updates nur außerhalb der Kernarbeitszeit). Diese Anforderungen dienen als Qualitätsmaßstab, an dem der Betrieb später gemessen wird.

• Support-Level und Reaktionszeiten: SLAs definieren, innerhalb welcher Zeit auf Störungen reagiert und diese behoben werden. Beispielsweise kann festgelegt sein: Priorität 1 (kritischer Ausfall): Reaktion innerhalb 30 Minuten, Lösung innerhalb 4 Stunden. Diese Zeiten müssen realistisch und mit den Ressourcen des Betriebsteams (oder Dienstleisters) abgestimmt sein. Falls externe Support-Dienstleister involviert sind, sollte deren Reaktionszeit vertraglich zugesichert sein.

• Rollen und Eskalation im Support: Im SLA-Umfeld ist auch festgehalten, wer welche Rolle im Support übernimmt (First-Level durch internen Helpdesk, Second-Level durch CAFM-Admin oder externen Anbieter etc.). Die Eskalationswege (wann wird ein Ticket vom 1st an den 2nd Level oder an den Hersteller eskaliert) sollten transparent sein. Idealerweise wird dies im Support-Konzept (Teil des Handover-Dossiers) abgebildet.

• Servicezeiten und Erreichbarkeit: Es muss geklärt sein, wann Support geleistet wird. Beispiel: Support wird Mo–Fr von 8–18 Uhr gewährleistet, außerhalb dieser Zeiten Rufbereitschaft für kritische Incidents. Diese Supportzeiten müssen zum Bedarf der Nutzer passen und werden oft ebenfalls im SLA dokumentiert. Intern kann dies auch in einer Betriebsvereinbarung oder OLA (Operational Level Agreement zwischen internen Einheiten) festgelegt sein.

• Betriebsvereinbarungen intern: Neben externen SLAs mit Dienstleistern sollte es ggf. interne Vereinbarungen geben, z. B. zwischen IT-Abteilung und Fachabteilung, welche Leistungen im laufenden Betrieb erbracht werden. Eine Betriebsvereinbarung könnte regeln, welche Daten von der Fachabteilung wie geliefert oder gepflegt werden müssen, damit das CAFM-System aktuell bleibt (z. B. neue Räume, Anlagen oder Verträge) – also Pflichten der Anwenderorganisation. Ebenso könnten Verantwortlichkeiten für Stammdatenpflege oder Berichtserstellung intern vereinbart werden.

• Abschluss der Verträge vor Go-Live: Es ist ratsam, alle SLAs und Vereinbarungen vor dem Go-Live unter Dach und Fach zu haben. Während der Projektphase müssen diese Punkte ausgehandelt werden, idealerweise unter Einbeziehung des Betriebsteams. So kann geprüft werden, ob die angedachten Servicelevels realistisch im bestehenden Supportapparat erfüllbar sind, oder ob Anpassungen nötig sind (z. B. zusätzliche Ressourcen für 24/7-Betrieb). Beispiel: Wenn die Fachabteilung 24/7-Verfügbarkeit fordert, das interne IT-Team aber nur Werktags besetzt ist, muss eventuell ein externer 24/7-Dienst beauftragt werden – solche Entscheidungen fallen vor Übergabe.

• Messung und Monitoring der SLAs: Zur Betriebsübergabe sollte festgelegt werden, wie die Einhaltung der SLAs überwacht wird. Werden Verfügbarkeiten technisch gemessen (Monitoring-Tools)? Werden Support-Reaktionszeiten via Ticket-System erfasst? Ein Reporting-Konzept hierzu hilft, später transparent zu machen, ob alle SLA-Ziele (z. B. Verfügbarkeit, Performance) erreicht werden. Bei Nichteinhaltung sollten automatisch Eskalationen erfolgen (siehe Governance).

• Sanktionen und Anreizsystem: In externen SLAs üblich ist die Vereinbarung von Konsequenzen, sollte ein Dienstleister die SLAs nicht erfüllen (z. B. Gutschriften, Vertragsstrafen). Intern kann man stattdessen auf regelmäßige Service-Review-Meetings setzen, um Probleme anzusprechen, oder interne Zielvereinbarungen (KPIs für das Betriebsteam) definieren.

Am Ende der Übergabephase müssen die SLAs von allen Parteien abgenommen und unterschrieben sein. Damit gibt es eine klare vertragliche Grundlage für den laufenden Betrieb, an der sich alle Beteiligten orientieren. Diese Transparenz wirkt vorbeugend gegen spätere Konflikte und garantiert, dass die Erwartungen an den Betrieb explizit festgehalten sind.

Ein CAFM-System kann auf unterschiedliche Weisen betrieben werden. Bereits während des Projekts – spätestens vor Übergabe – sollte das Betriebsmodell feststehen, da es Einfluss auf Verantwortlichkeiten, Kosten und technische Umsetzung hat.

• Interner Betrieb (Inhouse): Das System wird von der eigenen IT-Abteilung auf eigener Infrastruktur betrieben (On-Premises) und auch administriert. Vorteile: maximale Kontrolle, Datenhoheit, keine Abhängigkeit von Dritten bezüglich Infrastruktur. Allerdings muss das Unternehmen ausreichend Know-how und Ressourcen bereitstellen (für Serverbetrieb, Updates, Security etc.). Ein internes Betriebsmodell passt oft zu größeren Organisationen mit vorhandener IT-Infrastruktur oder hohen Datenschutzanforderungen (z. B. öffentliche Hand, Krankenhäuser).

• Externer Betrieb (Outsourcing): Hier wird der Betrieb an einen externen Dienstleister vergeben. Das kann die Auslagerung der Infrastruktur (Hosting in einem Rechenzentrum) oder sogar des gesamten Applikationsbetriebs (inkl. Administration) sein. Man unterscheidet z. B. Hosting-Provider (betreibt Server und evtl. Datenbanken, während die Applikationsverwaltung intern bleibt) und Application Management Services (der Dienstleister betreibt und administriert die Anwendung komplett). Vorteile: interne Entlastung, Zugang zu spezialisiertem Know-how, oft hohe Verfügbarkeit durch professionelle Rechenzentren. Nachteile: Weniger Kontrolle, Abhängigkeit von SLA-Vertrag mit Dienstleister, evtl. höhere laufende Kosten. Verträge müssen Austrittsklauseln (Exit-Strategie) vorsehen, falls man den Anbieter wechseln will.

• Hybridmodelle: Kombinationen aus intern und extern. Beispielsweise kann die Infrastruktur extern gehostet sein (IaaS oder als Managed Server), aber die Applikationsbetreuung erfolgt durch interne CAFM-Administratoren. Oder umgekehrt: Die Infrastruktur steht intern, aber man holt sich externe Experten für den Applikationssupport. Ein Hybridmodell kann sinnvoll sein, um interne Stärken zu nutzen und gezielt Lücken durch Dienstleister zu füllen. Hier ist besonders wichtig, die Abgrenzung der Verantwortlichkeiten vertraglich festzulegen (wer patcht das System, wer reagiert im Alarmfall etc.).

• SaaS (Software as a Service): Das CAFM-System wird komplett als Cloud-Service bezogen. Der Anbieter stellt die Anwendung über das Internet bereit, kümmert sich um Hosting, Updates und oft auch Backup/Sicherheit. Für den Kunden entfällt damit viel technischer Aufwand – er nutzt die Software und konzentriert sich auf die fachliche Anwendung. SaaS ist besonders für kleinere und mittlere Unternehmen attraktiv, die keine eigene IT-Infrastruktur aufbauen wollen. Vorteile: schnelle Einsatzbereitschaft, Skalierbarkeit (Benutzer und Speicher lassen sich flexibel anpassen), keine lokalen Installationen. Updates kommen regelmäßig vom Hersteller (was Fluch und Segen sein kann – wenig Aufwand, aber auch weniger Kontrolle über Update-Zeitpunkte). Bei SaaS-Modellen muss das Betriebsteam vor allem die Nutzerverwaltung, Stammdatenpflege und Prozesse überwachen, während der technische Betrieb (Server, DB, Softwareupdates) beim Anbieter liegt.

• On-Premises: Klassischer Eigenbetrieb vor Ort (im eigenen Rechenzentrum). Hier hat man vollständige Kontrolle über Versionen, Update-Termine, Daten bleiben intern. Allerdings trägt man auch komplette Verantwortung für Hochverfügbarkeit, Redundanzen, Desaster-Vorsorge etc. On-Prem kann mit externem Support kombiniert sein (z. B. Hersteller liefert Updates, aber Installation macht man selbst). Organisationen mit strengen Compliance-Vorgaben ziehen oft On-Prem vor, um z. B. sicherzustellen, dass Daten nicht außer Haus gehen. Die Kostenstruktur ist anders als bei SaaS: meist höhere Initialkosten (Hardware, Lizenzen) und laufende Aufwände für Wartung, aber keine monatliche Miete pro User.

Die Auswahl des Betriebsmodells sollte zur Größe, Dynamik und IT-Strategie der Organisation passen. Häufig hilft eine Kosten-Nutzen-Betrachtung: Wann rechnet sich SaaS gegenüber eigenem Betrieb? Neben Kosten spielen Datensicherheit, Flexibilität und interne Kompetenz eine Rolle. Einige Unternehmen starten mit SaaS, um schnell live zu gehen, und wechseln später auf On-Prem (oder umgekehrt), wenn sich Anforderungen ändern – solche Wechsel sollten aber gut geplant sein (Datenmigration, Vertragslaufzeiten beachten). In jedem Fall muss das gewählte Modell klar in den Betriebsvereinbarungen verankert sein, damit alle Beteiligten wissen, wer welche Aufgaben übernimmt. Beispiel: Bei SaaS muss eindeutig sein, welche Leistungen der Anbieter erbringt (etwa regelmäßige Backups, Monitoring, Supporthotline) und was intern zu tun bleibt (Benutzer-Support, Datenpflege). Bei On-Prem wiederum muss intern geregelt sein, wer für Systemupdates zuständig ist und wie schnell Sicherheits-Patches einzuspielen sind.

Zusätzlich ist darauf zu achten, dass das Betriebsmodell mit dem Lizenzmodell der Software korrespondiert (Kauf vs. Miete, Named User vs. Concurrent User etc.), da dies Auswirkungen auf Kosten und Flexibilität hat. All diese Entscheidungen sollten idealerweise früh im Projekt getroffen und dokumentiert werden (z. B. in einem Betriebs- und Hostingkonzept), damit die Umsetzung (z. B. Beschaffung einer Cloud-Subscription oder Bereitstellung von On-Prem-Servern) rechtzeitig vor Go-Live abgeschlossen ist.

Für einen stabilen Regelbetrieb eines CAFM-Systems ist ein klar definiertes Rollen- und Verantwortlichkeitsmodell unverzichtbar. Jeder Beteiligte – ob Mensch oder externe Partei – muss wissen, welche Aufgaben in seinem Zuständigkeitsbereich liegen, um reibungslose Abläufe zu gewährleisten.

Diese Aufzählung kann je nach Organisation variieren; wichtig ist jedoch, dass alle nötigen Funktionen abgedeckt sind. Oft wird im Betreiberkonzept festgehalten, wer was entscheidet und wer was ausführt. So ist z. B. klar geregelt: Wenn ein Anwender ein Problem meldet, geht es an den Helpdesk (1st Level); kann dieser es nicht lösen, übernimmt der CAFM-Admin (2nd Level); liegt ein Software-Bug vor, eskaliert dieser zum Hersteller (3rd Level). Gleichzeitig weiß der CAFM-Admin, dass er für regelmäßige Datenpflege verantwortlich ist, während die IT für System-Backups sorgt – Verantwortungsüberschneidungen oder Lücken werden dadurch vermieden.

Bereits im Projekt sollte man ein Support-Konzept entwerfen, das diese Rollenverteilung skizziert, und es mit allen Beteiligten abstimmen. Wichtig ist dabei nicht nur die normale Aufgabenverteilung, sondern auch Sonderrollen: z. B. wer ist Betriebsführer im Notfall? Wer hält Rufbereitschaft für Wochenenden? Solche Fragen müssen vorab geklärt und schriftlich fixiert sein. Klare Verantwortlichkeiten sorgen dafür, dass im Tagesgeschäft keine Zuständigkeitsdebatten entstehen, sondern jeder weiß, wofür er Ansprechpartner oder Entscheider ist. Dies ist auch zentral für die Governance im Betrieb.

Neben der operativen Aufgabenverteilung benötigt der CAFM-Betrieb ein Governance-Rahmenwerk – sprich Richtlinien und Strukturen, wie Entscheidungen getroffen und Probleme eskaliert werden.

• Kommunikationswege & Meetingstrukturen: Es sollte festgelegt sein, wie regelmäßig sich Betriebsteam und Fachbereich abstimmen (z. B. monatliche Service-Review-Meetings, quartalsweise Strategiemeetings für Weiterentwicklungen). In diesen Runden wird die Performance des Systems besprochen, offene Punkte, Änderungswünsche usw. Außerdem müssen Informationsketten definiert sein: Wer wird informiert, wenn z. B. eine kritische Störung auftritt? (Bsp.: CAFM-Admin informiert Facility-Leiter und IT-Leiter innerhalb von 30 Minuten bei schweren Incidents). Eine klare Kommunikationsstruktur verhindert, dass Informationen verloren gehen oder wichtige Stakeholder im Dunkeln bleiben.

• Eskalationspfade: Trotz aller Vorsorge können Probleme auftreten – ob Systemausfall, massive Performanceprobleme oder ein SLA-Verstoß. Klare Eskalationsmechanismen sind essenziell, um IT-Probleme effizient zu lösen, Verantwortlichkeiten zu definieren und Compliance sicherzustellen. Daher sollte es für unterschiedliche Szenarien definierte Eskalationsstufen geben. Beispiel: Wenn ein Incident der Kategorie „kritisch“ nicht binnen 4 Stunden gelöst ist, Eskalation an den IT-Leiter; nach 8 Stunden an den CIO. Oder: Wenn der externe Dienstleister SLA X verletzt, Eskalation an Vertragsmanagement. Diese Pfade sollten nicht nur auf dem Papier stehen, sondern allen Beteiligten bekannt sein – idealerweise werden sie in Notfallübungen auch getestet. So vermeidet man Chaos im Ernstfall.

• Entscheidungsgremien und Change Governance: Für Änderungen am System (neue Module, größere Updates, Prozessänderungen) sollte ein Governance-Prozess definiert sein. Oft wird ein Change Advisory Board (CAB) eingerichtet, das Änderungen prüft und freigibt. Bei CAFM betrifft das z. B. Entscheidungen über Datenstruktur-Änderungen, Integration zusätzlicher Schnittstellen oder größere Anpassungen im Rollen-Rechte-Konzept. Das CAB stellt sicher, dass Änderungen kontrolliert erfolgen, Risiken betrachtet und Downtimes geplant werden. Kleinere Änderungen kann der Betriebsverantwortliche ggf. selbst freigeben, während große Änderungen ein Go von höherer Stelle brauchen. Wichtig ist, dass es Transparenz über geplante Änderungen gibt und diese kommuniziert werden (z. B. an Key User und ggf. alle Endanwender bei neuen Funktionen).

• Betreiberkonzept & Notfallpläne: Wie im vorherigen Abschnitt erwähnt, sollte ein Betreiberkonzept alle relevanten Governance-Aspekte bündeln. Dazu gehören auch Notfall- und Alarmierungskonzepte: Was passiert bei gravierenden Vorfällen? Etwa: Cyberangriff auf das CAFM-System – wer entscheidet über Stilllegung? Wer informiert die Nutzer über Alternativprozesse? Oder Ausfall der Klimaanlage im Rechenzentrum – wie wird die Weiterführung des Betriebs gewährleistet? Notfallpläne (inkl. Verantwortlichkeiten und Kommunikation) müssen verbindlich festgeschrieben und allen Beteiligten bekannt sein. Ebenso sollte klar sein, wie mit Alarmen aus Monitoring umgegangen wird (z. B. Server-CPU über 90%: wird ein Alert an den Administrator geschickt? Ab wann wird ein Incident eröffnet?).

• Dokumentenlenkung und Prozesshandbuch: Zur Governance gehört auch, dass zentrale Dokumente (Betriebshandbuch, Verantwortlichkeitsmatrix, Notfallhandbuch) gepflegt und versioniert werden. Eine Stelle (z. B. der CAFM-Admin oder Qualitätsmanager) sollte verantwortlich sein, diese Dokumentation aktuell zu halten, wenn sich im Betrieb etwas ändert. Auch sollten Änderungen in Prozessen immer allen Betroffenen mitgeteilt werden, um ein gemeinsames Verständnis zu sichern.

• Audit- und Compliance-Struktur: Gerade im CAFM (Facility Management) gibt es Betreiberpflichten und Compliance-Vorgaben (z. B. Prüffristen von Anlagen, Datenschutz bei Flächendaten etc.). Die Governance muss regeln, wie die Einhaltung solcher Pflichten überwacht wird. Das kann bedeuten: jährliche interne Audits des CAFM-Betriebs, regelmäßige Kontrollen der Datenqualität, oder Reporting an Compliance-Stellen. Ein Governance-Aspekt ist auch die Nachvollziehbarkeit von Entscheidungen – wer hat wann genehmigt, dass Datensatz X geändert wird? Hier spielen Berechtigungskonzepte und Logging eine Rolle. Revisionssichere Prozesse helfen, im Ernstfall (z. B. Unfall, Prüfung durch Aufsichtsbehörde) nachzuweisen, dass alle Verantwortlichkeiten wahrgenommen wurden.

Alles in allem sorgt eine solide Governance und definierte Eskalations- und Kommunikationsstruktur dafür, dass der Betrieb nicht im „Blindflug“ läuft. Jederzeit muss klar sein, wer informiert werden muss und wer Entscheidungen trifft, sei es im Normalbetrieb oder im Störungsfall. Dies schafft Vertrauen bei allen Beteiligten – von den Endanwendern bis zum Management –, dass das CAFM-System verlässlich gemanagt wird.

Ein CAFM-System sollte nicht isoliert betrieben werden, sondern in die vorhandenen IT-Service-Management (ITSM) Prozesse der Organisation eingebettet sein. Gerade wenn bereits nach ITIL oder ähnlichen Frameworks gearbeitet wird, ist es sinnvoll, das neue System in diese Abläufe zu integrieren, um Einheitlichkeit und Effizienz sicherzustellen.

• Incident Management: Störungen oder Benutzeranfragen zum CAFM müssen über den gleichen Service Desk laufen wie andere IT-Themen, damit Nutzer einen zentralen Anlaufpunkt haben. Praktisch bedeutet dies, dass im vorhandenen Ticketsystem ein Kategorieeintrag für das CAFM-System eingerichtet wird. Der Helpdesk sollte geschult sein, typische Erstmaßnahmen bei CAFM-Problemen zu ergreifen (wie z. B. Cache leeren, Benutzerrechte prüfen etc.). Meldungen werden im zentralen Tool erfasst, was Transparenz schafft und Auswertungen ermöglicht. Auch das Priorisieren nach Kritikalität folgt bestehenden Regeln, sodass schwere CAFM-Ausfälle genauso behandelt werden wie andere kritische Incidents. Durch die Aktivierung von Helpdesk und Ticketing spätestens zum Go-Live wird sichergestellt, dass ab Tag eins alle Supportfälle strukturiert erfasst und bearbeitet werden.

• Problem Management: Falls sich wiederkehrende Probleme mit dem CAFM zeigen (z. B. regelmäßige Schnittstellenfehler), sollte das Problem Management eingreifen – also Ursachenanalysen, Known Error Database etc. Genau wie für andere Services sollte das CAFM-System in die Problem-Management-Meetings einbezogen werden. Gegebenenfalls wird ein Major Incident Review nach größeren Ausfällen durchgeführt, um Verbesserungen abzuleiten.

• Change Management: Änderungen am CAFM (Updates, Konfigurationsänderungen, neue Module) sollten dem etablierten Change-Management-Prozess folgen. D.h. Changes werden dokumentiert, bewertet (Impact auf andere Systeme, Risiken) und von den zuständigen Gremien freigegeben. Der Change-Kalender berücksichtigt CAFM-Änderungen, so dass es nicht zu Konflikten (z. B. gleichzeitigem Update von CAFM und einer integrierten Software) kommt. Notwendige Downtime-Ankündigungen für das CAFM werden über die üblichen Kommunikationskanäle an die Nutzer verteilt.

• Configuration Management (CMDB): Das CAFM-System und alle zugehörigen Komponenten (Server, Datenbanken, Applikationsmodule, Schnittstellen) sollten in der Configuration Management Database erfasst sein, falls im Unternehmen vorhanden. So ist nachvollziehbar, welche CIs zusammenhängen. Änderungen (wie ein Server-Upgrade oder ein neues Modul) werden in der CMDB gepflegt. Dies hilft insbesondere bei der Fehlersuche, da Abhängigkeiten sichtbar sind.

• Service Catalog: In vielen Unternehmen gibt es einen Servicekatalog der IT-Services. Das CAFM sollte darin als eigener Service mit Beschreibung, Leistungsumfang, Ansprechpartnern und SLAs aufgeführt werden. Endanwender wissen so, was sie vom Service erwarten können und wie Support erreichbar ist. Intern hilft es, den Überblick über alle Services zu behalten.

• ITIL-Schulung und Bewusstsein: Das Betriebsteam (insb. der CAFM-Admin und das Helpdesk) sollte im Sinne von ITIL wissen, wie sie in den Prozessketten mitwirken. Beispielsweise Tickets richtig kategorisieren (Incident vs. Service Request), Erfassung von Workarounds für die Knowledge Base, Einhaltung der Responsezeiten laut SLA etc. Falls nötig, ist eine kurze Prozesseinweisung fürs Team Teil der Übergabe. Oft unterscheiden sich die Abläufe eines CAFM gar nicht so sehr von anderen Anwendungen – wichtig ist nur, dass sie nicht als Sonderfall gehandhabt werden, sondern im Gesamtkontext stimmig sind.

• Integration mit bestehenden Tools: Möglicherweise lässt sich das CAFM auch funktional integrieren – z. B. mit dem zentralen Monitoring-System (um technische Alarme aus der CAFM-Datenbank oder Middleware an das NOC weiterzugeben) oder mit dem Logging/SIEM der IT-Security (damit sicherheitsrelevante Events aus dem CAFM erfasst werden). Auch die Einbindung ins unternehmensweite Identity Management (etwa AD-Anbindung für Single Sign-On) gehört dazu. Diese technischen Integrationen sollten während des Projekts umgesetzt werden, so dass zur Übergabe alles nahtlos funktioniert. Ein separates Inseldasein des CAFM würde sonst Mehraufwand bedeuten (z. B. doppelte Benutzerverwaltung).

• Support-Organisation verbinden: Sollte der CAFM-Support nicht direkt in der IT-Abteilung angesiedelt sein (manchmal ist er im Fachbereich FM verankert), muss trotzdem die Verzahnung mit der IT-Supportorganisation definiert werden. Beispielsweise können FM-Key-User First-Level-Anfragen entgegennehmen, aber sie nutzen dann das zentrale IT-Ticketsystem zur Eskalation an den IT-Support. Hier ist Prozessklarheit wichtig, damit Anfragen nicht hängen bleiben. Oft wird in solchen Fällen eine Schnittstellen-Prozessbeschreibung erstellt (FM-Support ↔ IT-Support).

Durch die Integration ins ITSM wird erreicht, dass das CAFM-System den gleichen Qualitätsstandards folgt wie alle IT-Services. Änderungen sind geplant, Ausfälle werden gemanagt, Wissen wird dokumentiert – kurz: der Betrieb läuft professionell. Zudem fühlen sich die Endnutzer gut aufgehoben, wenn sie bei Fragen zum CAFM einfach den gewohnten Servicedesk kontaktieren können, statt nach Zuständigkeiten zu suchen. Die Übergabe ist der richtige Zeitpunkt, um all diese Weichen zu stellen und das System fest im Service-Management zu verankern.

Nachdem das System live gegangen ist und die Betriebsverantwortung offiziell übergeben wurde, ist es Best Practice, eine Abschlussphase durchzuführen, in der Erfahrungen ausgewertet und letzte Anpassungen vorgenommen werden. Diese Phase wird oft Early Life Support oder Hypercare genannt und dauert typischerweise einige Wochen ab Go-Live (z. B. 4–8 Wochen). In dieser Zeit arbeitet das Projektteam noch eng mit dem Betriebsteam zusammen, um eventuelle Anfangsschwierigkeiten zu beseitigen.

• Intensives Monitoring & Support: Unmittelbar nach Go-Live wird das System verstärkt beobachtet (Performance, Fehlerlogs etc.), um Abweichungen früh zu erkennen. Das Supportteam steht in erhöhter Bereitschaft, und es gibt häufigere Abstimmungsrunden (z. B. tägliche oder zumindest wöchentliche Jour fixe), um Probleme schnell zu lösen. Ziel ist ein Stabilitätsnachweis unter realen Bedingungen – Störungen werden analysiert und nachhaltig behoben, um Kinderkrankheiten des Systems zu kurieren.

• Übergabe der Restarbeiten: In der Hypercare-Phase werden noch verbliebene Restmängel abgearbeitet. Das Projektteam stellt sicher, dass alle im Abnahmeprotokoll festgehaltenen Punkte gelöst oder an den Betrieb übergeben sind. Offene Change Requests, die nicht mehr vor Go-Live umgesetzt wurden, werden priorisiert für die nächste Releaseplanung vorbereitet. Somit ist am Ende der Phase das System in einem „baustellenfreien“ Zustand oder es ist zumindest klar vereinbart, wie mit verbleibenden Punkten umgegangen wird.

• Wissenstransfer & Shadowing: Die Betriebsmitarbeiter übernehmen Schritt für Schritt die Aufgaben, während das Projektteam noch begleitet. Beispielsweise schaut der CAFM-Admin dem Projektmitarbeiter beim ersten Update über die Schulter (Shadowing), um es künftig allein durchführen zu können. Alle Runbooks – also Arbeitsanweisungen für wiederkehrende Abläufe – werden finalisiert und praktisch erprobt. Damit wird sichergestellt, dass das Betriebsteam am Ende der Phase autark handlungsfähig ist.

• Abschluss-Review & Lessons Learned: Gegen Ende der Hypercare sollte ein Abschlussmeeting mit allen Beteiligten (Projekt- und Betriebsseite, plus ggf. Key User) stattfinden. In diesem Lessons Learned-Workshop werden die Projektergebnisse und der Übergangsprozess gemeinsam reflektiert. Typische Fragen: Was lief gut? Was hätte besser laufen können? Haben wir unsere ursprünglichen Ziele erreicht? Dabei werden sowohl fachlich-technische Aspekte (z. B. Datenqualität, Performanceziele) als auch organisatorische betrachtet (z. B. Adequacy der Schulungen, Kommunikation im Übergang). Die Erkenntnisse daraus sollte man dokumentieren – zum einen, um im laufenden Betrieb Verbesserungen abzuleiten, zum anderen als Lernmaterial für zukünftige Projekte. Gerade bei Folgeprojekten im Unternehmen (oder späteren Erweiterungsphasen im CAFM) ist es wertvoll zu wissen, welche Fallstricke man vermeiden kann.

• Formale Betriebsabnahme: Falls noch nicht geschehen, erfolgt am Ende der Übergangsphase die finale Betriebsabnahme. Hier bestätigt das Betriebsteam offiziell, dass es das System voll verantwortlich übernimmt und das Projektteam aus seiner Pflicht entlassen wird. Idealerweise kann man zu diesem Zeitpunkt festhalten, dass alle vereinbarten Ziele und SLAs erreicht wurden (z. B. Nachweis: die letzten Wochen liefen mit der geforderten Verfügbarkeit und Performance) Sollte es Abweichungen geben, werden diese dokumentiert und es wird vereinbart, wie damit umgegangen wird (z. B. verlängerte Supportunterstützung durch den Hersteller, bis Performance verbessert ist).

• Abschlussbericht: Aus dem Projekt wird ein Abschlussbericht erstellt, der die Gesamtleistung zusammenfasst, die Systemdokumentation final aktualisiert und Empfehlungen für die kontinuierliche Verbesserung enthält. Letzteres kann z. B. beinhalten: Vorschläge für weitere Automatisierung, Ausblick auf kommende Software-Releases und deren Nutzen, oder Hinweise, welche regelmäßigen Optimierungen (Cleanup von Altdaten, Überprüfung von SLA-Reports etc.) dem Betrieb nahegelegt werden.

Nach dieser Phase erfolgt die endgültige Übergabe der Verantwortung. Das Projektteam tritt ab, und das Betriebsteam übernimmt vollständig. Eine gute Vorgehensweise ist es, den Abschluss schriftlich festzuhalten – etwa in Form eines Betriebsübergabe-Dokuments, das vom Projektleiter und Betriebsverantwortlichen unterzeichnet wird. Darin wird bestätigt, dass alle notwendigen Deliverables übergeben wurden (Dokumentationen, Schulungen, Zugänge, Verträge usw.) und ab einem bestimmten Datum das Betriebsteam alleinig verantwortlich ist.

Ab diesem Punkt geht das CAFM-System in den normalen Regelbetrieb über – mit fest verankerter Organisation, klaren SLAs und allen notwendigen Informationen an Bord. Das Projekt wird formell geschlossen. Die in der Lessons Learned identifizierten Verbesserungsmaßnahmen können nun im Rahmen der kontinuierlichen Serviceverbesserung (nach ITIL gedacht: Continual Service Improvement) verfolgt werden.

Zusammenfassend lässt sich sagen, dass die Übergabe in den Betrieb weit mehr ist als ein einzelner Termin: Sie umfasst einen ganzen Prozess von Kriterienprüfung, Dokumentenübergabe, Vertragsschluss bis hin zu Nachbetreuung und Feedback-Schleifen. Wird all dies strukturiert und sorgfältig durchgeführt, sind die Weichen für einen erfolgreichen Langzeitbetrieb gestellt – das CAFM-System kann von Tag eins an Mehrwert liefern, und sowohl Projekt- als auch Betriebsteam haben Klarheit über ihre Verantwortungen und Erwartungen. Die Investition in einen guten Übergabeprozess zahlt sich damit in der Betriebsphase durch weniger Überraschungen, höhere Zufriedenheit der Nutzer und eine insgesamt effiziente Betriebsorganisation aus.