CAFM: Betriebs- und Supportmodell (ITSM/SLAs)

Ein erfolgreiches Betriebsmodell definiert klare Rollen mit Verantwortlichkeiten.

Damit die Zuständigkeiten transparent sind, empfiehlt sich ein Governance-Framework mit definierten Rollenprofilen, Verantwortungszuweisungen und Eskalationsmatrix (z. B. RACI-Diagramm). In RACI-Diagrammen wird festgelegt, wer für welchen Prozess verantwortlich, wer informierend oder entscheident ist. Entscheidend ist, dass Systemverantwortlicher, Administrator und Support-Leiter eng zusammenarbeiten und die Key-User in Schulungs- und Testphasen eingebunden werden.

Das CAFM-Betriebsmodell ist idealerweise in die bestehende IT-Service-Management-Struktur eingebettet. Der CAFM-Service-Desk fungiert als Single Point of Contact (SPOC) für alle CAFM-bezogenen Anfragen und Störungen und nutzt die etablierten ITIL-Prozesse (Incident-, Problem-, Change-, Release-, Configuration-Management). Ein zentrales Ticket-System erfasst Incidents und Service-Requests im CAFM, führt sie durch standardisierte Workflows und koppelt sie an relevante CIs (Configuration Items) in der CMDB. Über eine CMDB/CI wird beispielsweise jede CAFM-Hardware, Software-Komponente oder Schnittstelle als Konfigurationselement geführt. So lassen sich Ereignisse und Alarme automatisch korrelieren: Ein Alarm der Gebäudeautomation (GLT/BMS) kann per Event-Kopplung sofort ein CAFM-Ticket erzeugen. Dadurch wird eine durchgängige Prozesssteuerung erreicht – Fehlermeldungen aus allen Systemen fließen in dasselbe ITSM-Tool. Auch Change-Requests für CAFM-Anpassungen laufen über den ITIL-Change-Management-Prozess, häufig mit festgelegten Genehmigungen (Change Advisory Board) für Updates. Ein zentraler SPOC stellt sicher, dass es konsistente Servicefenster und Gremien wie ein CAB (Change Advisory Board) gibt.

• 1st-Level-Support: Kümmerer (z. B. Helpdesk oder Key-User) nehmen Meldungen entgegen (Telefon, E-Mail, Portal), klassifizieren und bestätigen sie. Sie liefern nach Möglichkeit Soforthilfe mittels Standard-Lösungen oder Workarounds (Runbooks) und terminieren nötigenfalls die weiteren Schritte. Der 1st-Level bewältigt oft die häufigsten Anfragen und führt Erstlösungen durch, bevor komplexere Analyse notwendig ist. Er arbeitet mit einer Wissensdatenbank (KEDB/FAQ) und dokumentiert jeden Vorfall im Ticketsystem.

• 2nd-Level-Support: Fachadministrator(en) oder technische Spezialisten übernehmen komplexe Fehlerfälle, die der 1st-Level nicht selbst lösen kann. Sie verfügen über tiefere Systemkenntnisse (z. B. für Datenbankprobleme, Schnittstellen, Module) und führen detaillierte Analysen durch. Häufig sind hier CAFM-Administratoren oder interne IT-Service-Techniker angesiedelt. Der 2nd-Level löst Probleme durch Konfigurationsänderungen, Datenkorrekturen oder Anpassung von Prozessen.

• 3rd-Level-Support: Wenn Probleme auch im 2nd-Level nicht gelöst werden können, wird auf den Hersteller oder Integrationspartner eskaliert. Der 3rd-Level hat tiefstes Systemwissen (z. B. Quellcode-Zugriff, detailliertes Customizing-Know-how) und ist für schwerwiegende Fehleranalyse, Patches oder Erweiterungsentwicklung zuständig. Er wird über Serviceverträge eingebunden und trägt die letzten Schritte bei dringenden Problemen.

Im CAFM-Kontext kann es zusätzlich Key-User-Support vor Ort geben (1st-Level untergeordnete Rolle) oder bei großen Umgebungen regionale Kundenschalter. Typischerweise existiert ein 24/7-Service-Desk (SPOC) für kritische Prioritäten (P1/P2), während weniger dringende Anfragen (P3/P4) innerhalb der Geschäftszeiten bearbeitet werden. Dabei gelten klare Eskalationsregeln: Kritische Ausfälle (P1) werden sofort an Fachstellen gemeldet und binnen definierter Fristen escalated. Beispiel: Eine P1-Störung ohne erste Reaktion kann z. B. zu einer Eskalation zum 2nd-Level führen, wenn nicht innerhalb von 30 Minuten reagiert wurde.

Service Level Agreements (SLAs) definieren konkrete Kennzahlen für den Support. Üblich sind Klassifizierungen nach Priorität (P1 bis P4), die sich an Auswirkungen und Dringlichkeit orientieren. Zu jeder Prioritätsstufe gehören: maximale Reaktionszeit (erste Kontaktaufnahme), Wiederherstellungszeit (Lösungs- oder Wiederaufnahmezeit) und ggf. Zwischenziele (z. B. „First Call Resolution“).

Die konkreten Zeiten werden vertraglich vereinbart und orientieren sich an Geschäftsanforderungen (24×7 vs. Werktagsbetrieb). Entscheidend ist, dass Verfügbarkeitsfenster (Service Windows) klar geregelt sind (z. B. Wartungsfenster nachts/wochenends). In SLAs sind zudem Eskalationsstufen festgelegt: Bleibt eine P1-Anfrage unbeantwortet, wird sie auf die nächste Führungsebene eskaliert. Ein umfassender SLA-Katalog umfasst alle Stufen von der automatischen Bestätigung/Eingangsquittierung (z. B. E-Mail-Portal-Acknowledgement innerhalb von 30 Minuten) bis zur Wiederherstellungszeit und dokumentiert Erfüllungsgrade. (Kennzahlen werden laufend überwacht und in Dashboards visualisiert.)

• Ticketsystem (ITSM-Tool): Zentrales System zur Erfassung aller Incidents, Service-Requests und Changes. Es verwaltet Status, Historien und Eskalationen. Idealerweise ist das Ticketsystem mit dem CAFM/CMMS integriert, sodass z. B. Auftrags- und Bestandsdaten automatisch verknüpft werden. Eine verknüpfte Toolchain (Ticketing ↔ CAFM/CMMS ↔ Gebäudeautomations-Systeme) erhöht die Effizienz. So können Workflows End-to-End gesteuert und Audit-Trails nachgewiesen werden.

• Self-Service-Portal: Über ein Anwenderportal können Benutzer Störungen melden, Service-Anfragen stellen oder Self-Service-Funktionen nutzen (z. B. Rückmeldung bei Mängeln, Reservierungsänderungen). Ein Portal entlastet den Support und erhöht die Transparenz.

• Wissensdatenbank (Knowledge Base): Hier werden typische Fehlerbehebungen, FAQs und Lösungsdokumentationen gesammelt. Eine „Known Error Database“ (KEDB) enthält dokumentierte Probleme und Lösungen. Für den 1st-Level-Support ist sie unverzichtbar. Ein gepflegtes Wissensrepository und laufende Runbooks ermöglichen viele Erstlösungen ohne Experteneinsatz.

• Monitoring-Tools: Spezielle Software überwacht Systemzustände, Dienste und Schnittstellen. Sie registriert Ausfallzeiten, Performance-Kennwerte und generiert Alarme bei Abweichungen. Gängige Tools (z. B. Nagios, Grafana, Cloud-Services) werden häufig per API an das CAFM-Portal angebunden.

• Kommunikationskanäle: Telefon-Hotline, E-Mail, Chat oder Incident-Portal dienen als Kanäle für Störungsmeldungen. Idealerweise ist ein Omnichannel-Ansatz etabliert, bei dem alle Kanäle im gleichen Ticketsystem enden. Telefonsysteme können eine IVR (Menü) für Priorisierungen bieten (z. B. „Bei Notfalltaste“).

Ein modernes Supportmodell umfasst ein durchgängiges Monitoring der IT- und FM-Systeme. Dashboards zeigen in Echtzeit Schlüsselkennzahlen (Systemverfügbarkeit, Offene Tickets, MTTR etc.) an. Über Warnings und Alarme werden Betreiber rechtzeitig informiert, falls Grenzwerte verletzt sind. Ein Beispiel: Ein Dashboard visualisiert, wie viele Störungen derzeit offen sind und wie hoch die aktuelle Serverauslastung ist. So kann der Support sofort erkennen, wenn z. B. eine Datenbank-CPU ausbremst oder ein kritischer Job fehlgeschlagen ist. Automatisierte Alarmmeldungen (z. B. per Mail/SMS) leiten Abweichungen an die diensthabenden Techniker weiter. Ergänzend liefert ein Reporting- und Dashboard-System Kennzahlen wie SLA-Erfüllungsquoten oder Trendanalysen (u. a. First-Call-Resolution-Rate, Ausfallstatistiken). Diese Leistungsindikatoren (KPIs) werden kontinuierlich überprüft und in regelmäßigen Reports aufbereitet. Echtzeit-Sichtbarkeit über Dashboards ist ein zentraler Baustein für transparentes Betriebscontrolling.

Nach dem Go-Live erfolgt üblicherweise eine Early-Life-Support-Phase, in der noch Projekt- und Betriebsteam eng zusammenarbeiten. Bei Projektabschluss erfolgt die formale Übergabe an den Routinedienst. Dabei wird eine umfangreiche Übergabedokumentation übergeben, einschließlich Betriebshandbuch, Administrationsleitfäden, Schnittstellenübersichten und Konfigurationsnachweisen. Auch alle Passwörter, Zertifikate und Servicevereinbarungen werden dokumentiert. Unterlagen zu Wartungsplänen, Backup- und Restore-Verfahren, Notfallmaßnahmen und Kontaktdaten der Dienstleister gehören ebenfalls dazu. Ideal ist eine abschließende Übergabesitzung oder -workshop („Go-Live Review“), in dem offene Punkte geklärt, Verantwortlichkeiten bestätigt und Laufbücher gemeinsam durchgegangen werden. Diese formale Dokumentation und das Workshop-Protokoll sind wichtig, damit das Betriebsteam selbstständig arbeiten kann und Wissen nicht verloren geht.

Für den stabilen Betrieb sind reguläre Abstimmungstermine und Governance-Meetings üblich. Beispielsweise finden monatliche Betriebsreviews statt, in denen SLA-Kennzahlen, offene Änderungen und aktuelle Risiken besprochen werden. Dabei nehmen Vertreter des Betreibers, des CAFM-Providers und wichtiger Fachabteilungen teil. Typischerweise gibt es festgelegte Reportings (z. B. monatliches SLA-Report, Incident-Statistik, Change-Log). Die Verantwortlichkeiten und Kommunikationswege sind in einem Governance-Rahmen dokumentiert: RACI-Matrizen zeigen, wer für welches Thema verantwortlich, wer konsultiert oder informiert wird. Ein Change Advisory Board (CAB) prüft größere Systemänderungen. Kritische Erfolgsfaktoren sind klare Eskalationsregeln und Kommunikations-Templates (z. B. automatische Benachrichtigungen an alle Stakeholder bei Major Incidents). Laut Best Practice ist eine streng dokumentierte Governance (Rollenprofile, CAB, Audit-Trails) mit regelmäßigen Audits und Review-Zyklen unverzichtbar. In dieser Struktur werden SLA-Verletzungen nachverfolgt und Korrekturmaßnahmen (Continuous Service Improvement, CSI) initiiert. Ein Beispiel: Ein monatliches SLA-Review-Meeting prüft, ob alle vereinbarten Reaktions- und Wiederherstellungszeiten eingehalten wurden; bei Abweichungen wird nach Ursachen geforscht und das Betriebskonzept angepasst.

Zur Sicherstellung der Servicekontinuität gehören technische und organisatorische Notfallvorkehrungen. Technisch werden redundante Systeme eingesetzt: Das Ticketsystem und die CAFM-Datenbank sollten hochverfügbar betrieben werden (z. B. Active-Passive-Cluster, Clustering oder Cloud-Failover). Offline-Runbooks stellen sicher, dass das Supportpersonal auch bei IT-Ausfällen (z. B. Netzwerkausfall) arbeiten kann – zum Beispiel in Papierform oder auf externen Medien.. Regelmäßige Datenreplikation und Backups (z. B. tägliche Sicherung auf externen Medien oder in ein Disaster-Recovery-Center) sind Pflicht. Ein Notfall- und Wiederanlaufplan definiert Vorgehen bei kompletten Systemausfällen: welcher Dienst wird bei einem Ausfall wie schnell wiederhergestellt, wer alar­miert welche Eskalationsstufen, und wie kommuniziert man intern/extern. Diese Pläne sind im Business-Continuity-Management der Organisation verankert. Beispielsweise wird beim Ausfall des zentralen CAFM-Servers gegebenenfalls auf einen Hot-Standby umgeschaltet; Schlüsselpersonen haben jederzeit Zugriff auf aktuelle Backups. Auch personelle Ausfallpläne sind Teil der Kontinuität (Cross-Training, Stellvertretungsregeln). All diese Maßnahmen – redundante Architektur, Backup-Partner, Eskalationswege – minimieren das Risiko von Ausfallzeiten.

Langfristig erfolgreich ist ein Betriebsmodell nur mit gut geschultem Personal. Deshalb sind strukturierte Schulungen für alle Betreiberrollen unerlässlich: CAFM-Admin, Support-Team und Key-User bekommen gezielte Trainings (systemtechnische Einweisung, Bedienung, Prozessabläufe). Zudem sollten Wissens-Workshops nach Go-Live stattfinden, in denen Erfahrungen aus der Einführungsphase vermittelt werden. In regelmäßigen Abständen (z. B. vierteljährlich) finden Fortbildungen oder Refresh-Schulungen statt. Parallel wird eine Wissensdatenbank etabliert und laufend gepflegt. Dazu gehören SOPs (Standard Operating Procedures) und Runbooks, in denen typische Abläufe und Lösungen dokumentiert sind, sowie eine Dokumentation bekannter Fehler im System (KEDB). Ein Continuous-Training-Konzept (z. B. E-Learnings, Praxisübungen) hält das Know-how im Team aktuell. Die W-Fragen (Wer macht was, wann, wie?) sind schriftlich beantwortet. Dadurch bleibt das Betriebswissen im Team zirkulierend und nicht „im Kopf“ einzelner Personen. Best Practice ist: Wissen sichern durch Dokumentation und regelmäßige Review-Zyklen.

Erfahrungen aus vielen Einführungen zeigen typische Stolpersteine: Oft sind zu Projektende personelle Ressourcen knapp, Prozesse noch nicht gefestigt oder Daten unvollständig. Technische Herausforderungen können fehlende Schnittstellenstandards oder unklare CMDB-Daten sein. Um dem vorzubeugen, helfen strikte Daten-Governance und ein sauberes Konfigurationsmanagement (z. B. nach ITIL/GEFMA-Standards). Bei mangelhafter Datenqualität im CAFM steigen Fehlerraten im Betrieb – deshalb sind verpflichtende Stammdatenprüfungen und Daten-Qualitätsaudits (DQ) nötig. Integrationsprobleme (z. B. wegen alter Drittanbietersoftware) werden durch modulare Schnittstellenspezifikationen und API-Gateways gemildert. Auch Change-Risiken lassen sich minimieren: Strenge CAB-Prozesse, Notfall-„Hotfix“-Strategien und rücksetzbare Software-Deployments sind üblich. Organisatorische Hürden (wie Akzeptanzprobleme im Fachbereich oder Wissensinseln) adressiert man durch frühe Einbindung aller Stakeholder, laufende Kommunikation und Key-User-Programme. Weitere bewährte Maßnahmen sind regelmäßige Tests von Notfallplänen (z. B. Zutrittssystem ohne CAFM-Anbindung simulieren), Backup-Partner mit klarer OLA (Operational Level Agreement) für Ausfallszenarien und eingerichtete „War Rooms“ für größere Störungen. Zusammengefasst gibt es kein Allheilmittel, doch ein schrittweiser Ansatz mit Feedback-Schleifen (Continuous Improvement) und dedizierten Ressourcen hat sich als erfolgreich erwiesen.

Ein umfassendes Betriebs- und Supportmodell für CAFM/IWMS/CMMS umfasst klare Zielvorgaben (Verfügbarkeit, Performance, SLAs), eine definierte Betriebsträgerschaft (intern, extern, hybrid) und präzise Rollen mit Verantwortlichkeiten. Es integriert die CAFM-Abläufe in die ITSM-Prozesse (Incident, Change, CMDB), baut einen gestuften 1st/2nd/3rd-Level-Support auf, definiert ein detailiertes SLA- und Eskalationskonzept, nutzt angemessene Werkzeuge (Ticketsystem, Portal, Wissensdatenbank), überwacht den Betrieb kontinuierlich über Dashboards, regelt die Betriebsübergabe mit umfassender Dokumentation, etabliert feste Kommunikations- und Governance-Strukturen und sichert Betriebskontinuität durch Notfallkonzepte. Schulungen und Knowledge-Management sichern das Know-how im Team. Durch diese ganzheitliche Betrachtung werden Risiken minimiert, und die CAFM-Systemlandschaft kann zuverlässig, effizient und skalierbar betrieben werden.