CAFM: Applikationsbetrieb und Monitoring

• Regelmäßiges Patching: Einspielen von Security-Patches und Updates für Betriebssystem, Datenbank und die CAFM-Software selbst. Sicherheitslücken müssen zeitnah geschlossen werden, weshalb präventive Wartungen oft in geplanten Wartungsfenstern stattfinden. Dazu gehört auch die Installation von Hotfixes bei akuten Problemen und das Aktualisieren von Drittsoftware (z. B. Middleware).

• Release-Management: Planung und Durchführung von Software-Upgrades. Neue Versionen der CAFM-/IWMS-Software (Minor-Updates, Major-Releases) werden gebündelt und kontrolliert ausgerollt. Dies umfasst das Lesen von Release Notes, Testen der neuen Version in einer Testumgebung und die Koordination mit dem Hersteller oder Entwicklungsteam. Größere Release-Wechsel erfolgen idealerweise außerhalb der Hauptnutzungszeiten und werden den Nutzern frühzeitig angekündigt (ggf. mit Schulungsmaterial).

• Überwachung und technische Betreuung: Die Betriebscrew (Systemadministratoren) kümmert sich um das Monitoring der Systemlandschaft, reagiert auf Störungen (siehe Monitoring/Incident Management unten) und führt Fehlerbehebungen durch. Dazu zählt z. B. das Analysieren von Logfiles bei Fehlermeldungen und das Neustarten von Diensten oder Servern bei Bedarf.

• Backup und Recovery: Tägliche Aufgabe ist die Datensicherung nach dem definierten Backup-Konzept (Details siehe Abschnitt Backup). Administratoren prüfen Backup-Jobs und führen periodisch Recovery-Tests durch, um die Wiederherstellungsprozesse zu verifizieren. So wird sichergestellt, dass im Ernstfall eine schnelle Datenwiederherstellung möglich ist.

• Benutzer- und Berechtigungsverwaltung: In Abstimmung mit dem CAFM-Admin (Key User) werden neue Nutzer im System angelegt, Rollen und Rechte gepflegt und bei Austritten Accounts gelöscht. Dies ist wichtig für Datensicherheit (Prinzip der minimalen Rechte) und reibungslose Nutzung.

• Konfigurationspflege und technische Unterstützung: Das Betriebsteam nimmt kleinere Konfigurationsanpassungen vor (z. B. technische Parameter ändern, Integrationen konfigurieren) und unterstützt bei der Stammdatenpflege aus technischer Sicht. Ebenso steht es dem Fachbereich beratend zur Seite bei Fragen zur Systemnutzung oder beim Auftreten ungewöhnlicher Systemverhalten (Second-Level-Support).

Durch diese regelmäßigen Aufgaben – Patch- und Releasemanagement, proaktives Monitoring, Backup sowie User-Support – wird ein stabiler und aktueller Betrieb der CAFM-Lösung gewährleistet. Viele dieser Tätigkeiten sind durch Standards (z. B. ISO 27001 oder BSI IT-Grundschutz) vorgeschrieben beziehungsweise als Best Practices etabliert, um Betriebssicherheit und Compliance zu gewährleisten.

Kontinuierliches Monitoring ist essenziell, um den Zustand der CAFM-Applikation und der zugrundeliegenden IT-Infrastruktur im Blick zu behalten. Moderne Monitoring-Systeme sammeln zahlreiche Metriken in Echtzeit und bereiten sie in Dashboards übersichtlich auf. Wichtige Kennzahlen sind etwa: Verfügbarkeits-Checks (Erreichbarkeit der Weboberfläche oder API, sog. Heartbeat-Signale), Performance-Metriken wie Antwortzeiten von Webservices und Datenbank-Abfragen, Ressourcenauslastung (CPU-, Speicher- und Plattennutzung der Server) sowie anwendungsspezifische Werte (z. B. Anzahl offener Wartungsaufträge oder Ticket-Stau).

Für all diese Metriken werden Schwellenwerte definiert. Überschreitet eine Messgröße ihren Schwellwert – etwa wenn die CPU-Last über einen definierten Prozentsatz steigt oder ein Webservice länger als X Sekunden antwortet – schlägt das Monitoring Alarm. Üblicherweise können Administratoren in Dashboards Ampelanzeigen oder Grafiken sehen, die kritische Zustände (rot/gelb) anzeigen. Tritt eine Auffälligkeit oder ein Ausfall auf, erzeugt das System automatisch einen Alert und verschickt Benachrichtigungen, z. B. per E-Mail oder SMS an den Bereitschaftsdienst. Diese automatische Früherkennung erlaubt es, viele Probleme proaktiv anzugehen – idealerweise bevor Endanwender die Störung bemerken.

Neben dem technischen Monitoring spielen auch funktionale Dashboards in der CAFM-Software eine Rolle, um z. B. Auslastungen, Energieverbräuche oder Ticketlaufzeiten im operativen FM-Geschäft zu beobachten. Aus Betriebs-Sicht jedoch steht vor allem das Technik-Monitoring im Vordergrund, um die Verfügbarkeit und Performance der Applikation sicherzustellen. Regelmäßige Überprüfung der definierten Schwellenwerte und Anpassung dieser Werte (z. B. bei Erweiterung der Nutzerzahl) sind Teil des kontinuierlichen Verbesserungsprozesses im Monitoring.

• Infrastruktur- und Uptime-Monitoring: Überwachungswerkzeuge prüfen rund um die Uhr, ob alle Systemkomponenten erreichbar sind und protokollieren Antwortzeiten (Uptime-Checks). Klassische Monitoring-Tools oder Cloud-Dienste melden sofort, wenn ein Server oder Dienst nicht reagiert, und messen Performance-Indikatoren. So wird z. B. die Verfügbarkeit der Webanwendung kontinuierlich getestet, indem regelmäßig HTTP-Requests an den CAFM-Webserver oder API-Endpoints gesendet werden. Bleibt eine erwartete Antwort aus oder ist sie zu langsam, wird ein Alarm generiert. Solche End-to-End-Checks (synthetische Transaktionen) stellen sicher, dass nicht nur der Server läuft, sondern auch die Applikationsfunktion gegeben ist.

• Log-Analyse und SIEM: Die Protokollierung (Logging) aller wichtigen Ereignisse ist eine wertvolle Informationsquelle fürs Monitoring. Spezielle Log-Analyse-Tools oder SIEM-Systeme (Security Information and Event Management) sammeln die Logfiles zentral und durchsuchbar. Dort laufen z. B. Anwendungs-Logs (Benutzeraktionen, Fehlerstacktraces) und System-Logs (Server- und Netzwerkereignisse) zusammen. Durch automatisierte Auswertung können Anomalien erkannt werden, etwa wiederholte Fehlversuche beim Login oder Datenbank-Timeouts. Das SIEM kann Korrelationen herstellen – z. B. erkennen, wenn kurz vor einem Applikationsfehler bestimmte Systemereignisse auftraten – und entsprechende Warnungen erzeugen. Außerdem dienen Logs der forensischen Analyse und Nachvollziehbarkeit (Wer hat was wann getan?), weshalb Aufbewahrungsfristen und Zugriffsschutz auf Protokolle definiert sein müssen.

• Performance-Monitoring und Dashboards: Zur tiefgehenden Überwachung der Performance werden Application Performance Monitoring (APM) Tools eingesetzt, die z.B. die Ausführungszeiten einzelner Transaktionen oder Datenbankabfragen messen. Diese liefern detaillierte Einblicke und unterstützen das Troubleshooting, falls die CAFM-Software langsam reagiert. Ergebnisse fließen oft in Dashboards ein, die in Echtzeit Auslastungen und Antwortzeiten visualisieren. Administratoren können Trends ablesen (z. B. wachsende Speicherbelegung) und rechtzeitig Kapazitäten erhöhen (siehe Kapazitätsmanagement).

• API- und Schnittstellen-Monitoring: Da CAFM-Systeme meist mit anderen Systemen integriert sind (ERP, IoT-Sensorik, Gebäudeleittechnik, etc.), ist die Überwachung der Schnittstellen essentiell. Spezielle Tools prüfen regelmäßig, ob Schnittstellen-Jobs erfolgreich laufen und ob Dritt-Systeme erreichbar sind. Beispielsweise kann ein Monitoring-Skript die REST-API der CAFM-Plattform periodisch aufrufen und einen Datenaustausch simulieren. Bleiben erwartete Antworten oder Datenimporte aus, wird ein Fehleralarm ausgelöst. Im Betriebskonzept sollten solche Schnittstellen-Monitoringprozesse fest verankert sein, da ein Ausfall einer Schnittstelle unmittelbar Auswirkung auf angebundene Geschäftsprozesse (z. B. Ticketübernahme, Raumreservierungen) hat.

Die Auswahl der konkreten Tools erfolgt produktneutral anhand der Anforderungen. Oft kommen Open-Source-Lösungen (z. B. für Log-Analyse oder Systemmonitoring) kombiniert mit bestehenden Unternehmens-Tools (etwa ein zentrales IT-Monitoring-System) zum Einsatz. Wichtig ist, dass alle Überwachungswerkzeuge nahtlos Alarmmeldungen erzeugen und an das zentrale Ticketsystem bzw. die zuständigen Admins weiterleiten, damit Monitoring und Incident Response eng verzahnt sind.

Trotz aller Vorsorge lassen sich Incidents – ungeplante Störungen oder Serviceunterbrechungen – nie ganz ausschließen. Entscheidend ist dann ein effizienter Incident-Management-Prozess, der durch Monitoring und klare Eskalationswege unterstützt wird. Sobald das Monitoring einen kritischen Zustand feststellt (oder ein Nutzer eine Störung meldet), wird automatisch ein Alert generiert. Dieser Alarm kann z. B. direkt ein Ticket im Helpdesk-System eröffnen oder eine Nachricht an den Bereitschaftsdienst senden. So wird umgehend das Betriebsteam informiert.

Die eingehende Störungsmeldung wird zunächst vom First-Level-Support (Service Desk) entgegengenommen. Der Service Desk fungiert als Single Point of Contact (SPOC) und erfasst alle relevanten Informationen im Ticketsystem. Anschließend nimmt er eine Priorisierung vor (z. B. P1 = kritischer Totalausfall, P3 = geringfügiges Problem) und versucht, einfache Probleme sofort zu lösen. Beispiel: Meldet ein Nutzer, dass er sich nicht einloggen kann, prüft der First-Level zunächst offensichtliche Ursachen (Passwort richtig, Account entsperrt etc.) und kann viele Vorfälle direkt beheben. Lässt sich die Störung dort nicht beheben, eskaliert der Service Desk an den Second-Level-Support.

Im Second-Level übernehmen erfahrene Administratoren oder Fachexperten den Fall. Sie analysieren tieferliegende Ursachen – etwa prüfen sie anhand von Logfiles, Datenbankstatus oder Konfigurationsparametern, warum die Anwendung fehlerhaft ist. Sie führen erforderliche Maßnahmen durch (Dienst neu starten, Konfiguration korrigieren, Workaround einspielen) und stellen so gut wie möglich den Normalbetrieb wieder her. Falls die Ursache außerhalb ihres Einflussbereichs liegt, wird ein Third-Level-Support hinzugezogen – das kann der Softwarehersteller sein (bei Programmfehlern) oder ein weiterer Dienstleister/Expert*in, z. B. vom Cloud-Provider bei Infrastrukturproblemen.

Für gravierende Störungen (sog. Major Incidents, etwa ein kompletter Systemausfall für alle Nutzer) gibt es gesonderte Prozeduren. In so einem Fall wird unverzüglich ein Incident Manager benannt und ein bereichsübergreifendes Krisen-Team einberufen, das sich ausschließlich der Störungsbehebung widmet. Parallel werden die Kunden aktiv über den Status informiert (per E-Mail-Broadcast, Telefon oder über eine Status-Webseite), um Transparenz zu gewährleisten. Das Ziel aller Incident-Reaktionen ist, die Unterbrechung so kurz wie möglich zu halten und schnell einen Workaround oder die endgültige Lösung bereitzustellen.

Wurde die Störung behoben, dokumentiert der zuständige Support-Mitarbeiter die Ursache und Lösung im Ticket und schließt den Incident in Rücksprache mit dem Meldenden ab. Anschließend kann – insbesondere bei schweren oder wiederholten Incidents – eine Problem Management-Phase eingeleitet werden (siehe ITSM-Schnittstellen), um die Grundursache der Störung zu ermitteln und dauerhaft zu beseitigen. Durch dieses strukturierte Vorgehen (Automatisierte Alerts -> mehrstufige Eskalation -> schnelle Incident-Bearbeitung -> Nachanalyse) werden Ausfallzeiten minimiert und Erkenntnisse für die Zukunft gewonnen. Eine automatisierte Metrik wie die Mean Time to Repair (MTTR) oder Einhaltung von Reaktionszeiten gemäß SLA (z. B. Antwort innerhalb 30 Minuten bei P1-Incident) dient dazu, die Effizienz des Incident-Managements zu überwachen.

• Plattform-Betreiber / IT-Betrieb: Dies ist die Organisation, die die CAFM-Plattform technisch bereitstellt und betreibt. In einem SaaS-Szenario ist das der Anbieter oder ein beauftragter Dienstleister, in einem On-Premise-Szenario oft die interne IT-Abteilung des Kunden. Der Betreiber trägt die Gesamtverantwortung für den sicheren, performanten Betrieb der Infrastruktur und Applikation. Dazu stellt er Personal für Administration, Wartung, Überwachung und Second-Level-Support bereit. Der Betreiber definiert die Betriebsprozesse, Wartungsfenster, Backup-Strategien und sorgt für die Einhaltung von Sicherheitsrichtlinien. Häufig gibt es einen benannten Service Manager oder Betriebsleiter, der die Abläufe koordiniert und als Serviceverantwortlicher (Service Owner nach ITIL) fungiert.

• Systemadministrator(en) (Ops-Team): Die technischen Experten, die im Auftrag des Betreibers das System administrieren. Ihre Aufgaben umfassen das Deployment neuer Versionen, das Überwachen der Systeme, das Beheben von technischen Fehlern sowie das Durchführen von Backups und Wiederherstellungen. Sie verwalten die Cloud- oder Server-Infrastruktur, inklusive Netzwerk, Serverinstanzen, Datenbanken und Schnittstellen. Außerdem setzen sie Änderungen (Changes) im System gemäß Change-Management-Prozess um und stellen die Einhaltung von Konfigurationsvorgaben sicher. Die Systemadmins arbeiten eng mit dem Service Manager und ggf. den Entwicklern (bei Updates) zusammen, um technische Verbesserungen oder Fehlerbehebungen auszusteuern.

• CAFM-Administrator des Kunden (Mandanten-Admin / Key User): Auf Kundenseite wird in der Regel eine verantwortliche Person benannt, die die Nutzung der CAFM-Plattform intern betreut. Dieser Mandantenverantwortliche übernimmt das Benutzer- und Berechtigungsmanagement innerhalb seines Mandanten (Nutzeraccounts anlegen, Rollen zuweisen für z. B. Techniker, Manager, externe Dienstleister). Er ist Hauptansprechpartner für den Betreiber in allen Anwendungsfragen, meldet Probleme oder Änderungswünsche gebündelt an den Support und koordiniert die Datenpflege auf Kundenseite. Zudem stellt der Key User sicher, dass die Endanwender geschult sind und die Software gemäß den definierten Prozessen bedienen. Diese Rolle wird oft als CAFM-Admin oder Applikationsverantwortlicher bezeichnet.

• Endanwender (Nutzer): Die Endnutzer sind die operativen Anwender der Plattform, z. B. Facility Manager, Hausmeister, Techniker, Dienstleister oder Mieter, je nach Anwendungsfall. Sie nutzen die CAFM-Software für tägliche Aufgaben wie Flächenbuchungen, Störungsmeldungen, Wartungsaufträge oder Auswertungen. Endanwender haben in der Regel keine Admin-Rechte, sondern arbeiten innerhalb der vom CAFM-Admin vorgegebenen Strukturen. Ihre Verantwortung liegt darin, das System korrekt zu bedienen und alle notwendigen Informationen einzugeben (z. B. das Erfassen von Störungen, Rückmeldungen nach erledigten Aufgaben) Fehlerhafte oder fehlende Eingaben können die Datenqualität beeinträchtigen; daher ist die Sensibilisierung der Endnutzer für Prozesse und Systemnutzung wichtig (oft Aufgabe des CAFM-Admins).

• Support-Team / Service Desk: Das Support-Team stellt den Benutzersupport sicher und ist meist mehrstufig organisiert. Der First-Level-Support (Service Desk) nimmt alle Anfragen und Störungsmeldungen entgegen, leistet grundlegende Hilfe (Passwort zurücksetzen, Anleitung geben) und löst einfachere Fälle sofort. Komplexere Probleme eskaliert er an den Second-Level-Support, der aus erfahrenen Administratoren oder Fachexperten besteht. Diese tieferen Support-Level analysieren technische Probleme und arbeiten ggf. mit Third-Level (Hersteller) zusammen, wie unter Incident-Management beschrieben. Der Service Desk informiert die Anwender über den Status ihrer Tickets und dient als Kommunikationsschnittstelle (SPOC) zwischen Nutzern und Betriebsteam.

• Sicherheits- und Datenschutzbeauftragte: Auf Betreiber-Seite (und bei größeren Organisationen auch auf Kundenseite) gibt es spezielle Rollen für IT-Sicherheit und Datenschutz. Ein Informationssicherheitsbeauftragter (CISO/ISO) achtet darauf, dass Vertraulichkeit, Integrität und Verfügbarkeit der Systeme und Daten gewahrt bleiben. Er überprüft regelmäßig die Wirksamkeit von Sicherheitsmaßnahmen (z. B. Berechtigungskonzepte, Patch-Management, Logging) und koordiniert Sicherheits-Audits. Der Datenschutzbeauftragte (DSB) stellt sicher, dass alle DSGVO-Vorgaben erfüllt werden, z. B. durch Abschluss von Auftragsverarbeitungsverträgen, Durchführung von Datenschutz-Folgeabschätzungen und das Prinzip der Datensparsamkeit bei der Systemkonfiguration. Beide Rollen beraten das Betriebsteam, um einen compliance-gerechten Betrieb zu gewährleisten.

Die klare Abgrenzung dieser Rollen – inklusive externer Dienstleister falls beteiligt – verhindert Überschneidungen und Lücken. Alle Beteiligten sollten wissen, wer für welche Aufgaben verantwortlich ist. Oft wird dies, wie erwähnt, in einer RACI-Tabelle oder Betriebsvereinbarung dokumentiert. Damit wird sichergestellt, dass im Alltag wie auch im Notfall jeder weiß, welche Zuständigkeiten er hat, was die Reaktionsfähigkeit und Zuverlässigkeit des Betriebs erhöht.

Ein professioneller Applikationsbetrieb ist eng mit dem übergreifenden IT Service Management (ITSM) des Unternehmens verzahnt. Das bedeutet, dass die Prozesse rund um Störungen, Änderungen und Serviceanfragen des CAFM-Systems nach ITIL-Best-Practices gestaltet sind und in bestehende ITSM-Tools integriert werden.

• Zentrales Element ist das Incident Management: Alle Störungen werden als Tickets in einem ITSM-System erfasst. In diesem Ticketsystem sind idealerweise die Configuration Items (CI) des CAFM-Systems hinterlegt – also Server, Datenbanken, Module etc. –, sodass bei einem Incident vermerkt wird, welche Komponente betroffen ist. Dies erleichtert Analysen, welche Bereiche besonders störanfällig sind, und ermöglicht Übersichtsberichte (z. B. “Wie viele Incidents entfielen im letzten Quartal auf das Modul XY?”). Zudem können SLA-Vorgaben dort hinterlegt und automatisch überwacht werden (z. B. ob Reaktions- und Lösungszeiten eingehalten wurden. Der Service Desk des CAFM folgt den gleichen Prozessen wie andere IT-Services – von der Ticket-Eröffnung über Priorisierung, Bearbeitung bis zur Ticket-Schließung in Abstimmung mit dem Meldenden.

• Wichtig ist auch das Problem Management als ITIL-Prozess: Wiederkehrende oder schwerwiegende Incidents werden nachträglich auf eine tiefere Ursache (Root Cause) untersucht. Das Betriebsteam analysiert, ob ein grundlegendes Problem im System vorliegt – etwa ein Bug in der Software oder ein Kapazitätsengpass – der die Vorfälle auslöst. In einem Problembericht wird diese Grundursache dokumentiert und Maßnahmen zu deren Beseitigung geplant (z. B. Bugfix durch den Hersteller, Upgrade der Hardware, Schulung der Nutzer). Ziel ist es, dass sich ähnliche Incidents künftig nicht mehr häufen. Im Rahmen der Root Cause Analysis werden oft auch Workarounds und Known Errors dokumentiert: Erkenntnisse aus gelösten Incidents fließen in eine Wissensdatenbank ein, sodass der First-Level bei erneut auftretenden Symptomen schneller reagieren kann.

Darüber hinaus bestehen Schnittstellen zum ITSM beim Change Management (siehe nächster Abschnitt). Änderungen an der CAFM-Anwendung sollten dem unternehmensweiten Change-Prozess folgen und vom Change Advisory Board (CAB) begutachtet und freigegeben werden, falls sie kritisch sind. Auch Service Requests (Anwenderwünsche, wie neue Reports oder Berechtigungsänderungen) können über das ITSM-Tool als Service Request erfasst und vom CAFM-Team abgearbeitet werden, um Transparenz über den Arbeitsaufwand zu haben.

Insgesamt fügt sich der CAFM-Applikationsbetrieb idealerweise nahtlos in die bestehende IT-Service-Landschaft ein. Dadurch gelten einheitliche Standards für Ticketdokumentation, Priorisierung und Bearbeitung. Zudem profitieren die CAFM-Verantwortlichen von etablierten Eskalationswegen und Reporting-Mechanismen des ITSM (etwa regelmäßige Service Review Meetings, Auswertungen von Incident-Kennzahlen etc.). Die Orientierung an ITIL und Co. stellt sicher, dass der Betrieb auditierbar und kontinuierlich verbesserbar ist und dass im Störungsfall rasch alle nötigen Stellen zusammenwirken.

Ein solides Backup- und Recovery-Konzept sorgt dafür, dass bei Datenverlust oder Systemausfall keine dauerhaften Schäden entstehen und der Betrieb schnell wieder aufgenommen werden kann. Zentrale Kenngrößen dabei sind Recovery Time Objective (RTO) – die maximal tolerierte Wiederherstellungsdauer – und Recovery Point Objective (RPO) – der maximal tolerierte Datenverlust (Zeitraum). In vielen CAFM-Szenarien werden z. B. ein RTO von 4 Stunden und ein RPO von 15 Minuten angestrebt. Das bedeutet, dass im Worst Case das System innerhalb von 4 Stunden wieder verfügbar sein muss und höchstens 15 Minuten an Daten verloren gehen dürfen. Solche Vorgaben fließen in die technische Umsetzung ein.

• Backup-Frequenz und Arten: Alle transaktionalen Daten (z. B. Datenbankinhalte) werden in kurzen Intervallen gesichert, etwa alle 15 Minuten inkrementell oder via kontinuierliche Replikation, um die RPO von 15 Min abzudecken Zusätzlich finden tägliche Vollsicherungen statt (häufig nachts), um einen konsistenten Tagesstand zu haben. Neben Datenbank-Backups werden auch Dateien, Dokumente und Konfigurationsdaten der CAFM-Anwendung in die Sicherung einbezogen, damit im Notfall das System komplett wiederhergestellt werden kann.

• Geografische Redundanz: Backups werden ausgelagert an einen zweiten Standort oder Cloud-Speicher, um selbst bei einem Desaster am Hauptstandort (Brand, Hardwareausfall) geschützt zu sein Oft werden Backup-Daten verschlüsselt in einem räumlich getrennten Rechenzentrum oder in der Cloud gespeichert. So ist die Datenbasis auch bei einem größeren Vorfall (z. B. Rechenzentrums-Ausfall) nicht verloren.

• Wiederanlaufplanung (Recovery Plans): Für verschiedene Ausfallszenarien gibt es dokumentierte Wiederherstellungsprozedere. Diese Pläne beschreiben Schritt für Schritt, wie im Ernstfall vorzugehen ist – von der Beschaffung neuer Hardware oder Aktivierung von Ersatzsystemen bis zum Einspielen der Backups und Prüfen der Systemintegrität. Wichtig ist, dass diese Prozeduren auch getestet werden. Geplante Notfalltests (z. B. einmal jährlich) validieren, dass die Daten aus den Backups tatsächlich innerhalb der vorgegebenen RTO (z. B. 4 Stunden) wiederhergestellt werden können. Etwaige Lücken oder Probleme im Ablauf können so im Vorfeld erkannt und behoben werden.

• Automatisierung und Monitoring der Backups: Die Backup-Prozesse selbst werden überwacht – ein Ausfall eines Backup-Jobs erzeugt einen Alarm, damit umgehend reagiert werden kann. Logs der Backup-Vorgänge werden geprüft, um die Erfolgsquote sicherzustellen. Zudem wird oft ein Checksum- oder Integritätscheck gemacht, um sicherzustellen, dass Backups nicht korrupt sind.

• Integration in Notfallmanagement: Das Backup-Konzept ist Teil eines umfassenden Notfallvorsorge-Konzepts (Disaster Recovery Plan). Darin werden Zuständigkeiten festgelegt (wer löst im Ernstfall den Wiederanlauf aus?), Kommunikationswege definiert und Prioritäten gesetzt (welche Services werden zuerst wiederhergestellt?). Auch werden Abhängigkeiten dokumentiert – z. B. dass die Datenbank vor den Applikationsservern zurückgesichert werden muss, oder dass zunächst Netzwerkverbindungen stehen müssen.

Etwa verlangt Art. 32 DSGVO ausdrücklich Maßnahmen, um die Verfügbarkeit und den Zugang zu personenbezogenen Daten nach einem physischen oder technischen Zwischenfall rasch wiederherzustellen. Ein getestetes Backup/Recovery-Konzept ist somit nicht nur technisch sinnvoll, sondern oft auch rechtlich erforderlich. Im Ergebnis gewährleistet ein gutes Backup- und Recovery-Konzept, dass selbst bei gravierenden Zwischenfällen die Geschäftskontinuität im Facility Management gewahrt bleibt – Ausfallzeiten werden minimiert und Datenverluste praktisch eliminiert.

Ein oft unterschätzter Erfolgsfaktor im Applikationsbetrieb ist die Dokumentation. Gemäß ISO 27001 müssen alle wesentlichen Betriebsprozesse und Konfigurationen nachvollziehbar dokumentiert und für das relevante Personal zugänglich sein. Dazu zählen z. B. Betriebsführungsdokumente, Netzwerk- und Architekturpläne, Installations- und Konfigurationshandbücher, sowie aktuelle Übersichten der Schnittstellen und Zugriffsberechtigungen. Eine solide Dokumentation ermöglicht es, dass Einarbeitung neuer Teammitglieder schneller gelingt und im Störungsfall sofort klare Anweisungen vorliegen (z. B. Ablaufpläne für Disaster Recovery). Auch Änderungen im Team oder bei Dienstleistern lassen sich so abfedern, da Wissen nicht nur in Köpfen einzelner steckt. Neben technischen Aspekten (Systemkonfiguration, Parameter) sollten auch organisatorische Prozesse (z. B. Eskalationswege, Wartungsfenster, Kontaktlisten für Notfälle) schriftlich fixiert sein. Diese Dokumente müssen versioniert und gepflegt werden – etwa im Rahmen des Konfigurationsmanagements.

Konfigurationsmanagement (Config Management) stellt sicher, dass der Soll-Zustand der Systemumgebung definiert und Abweichungen kontrolliert werden. Jede Änderung an der Infrastruktur oder Applikations-Einstellung sollte nachvollziehbar sein. Praktisch wird dies oft durch Infrastructure as Code (bei cloudbasierten Systemen) unterstützt oder zumindest durch klar geregelte Änderungsverfahren mit Freigabedokumenten. ISO 27001 verlangt, dass alle bedeutsamen Änderungen aufgezeichnet und formell genehmigt werden. Daher führt der Betreiber ein Änderungslogbuch bzw. nutzt ein Ticketsystem, in dem jede Änderung inkl. Genehmigung dokumentiert ist (Audit-Trail). Auch die aktuelle Konfigurationsdokumentation (z. B. welche Version ist installiert, welche Module sind aktiv, welche Parameter gesetzt) ist Teil des Config Management. Viele Unternehmen unterhalten eine CMDB (Configuration Management Database) als Teil des ITSM, worin die Komponenten und ihr Beziehungsgefüge erfasst sind – was wiederum bei Impact-Analysen für Changes hilft.

Eng verzahnt damit ist das Change-Management. In einer lebendigen CAFM-Umgebung sind kontinuierliche Änderungen unvermeidbar – von funktionalen Erweiterungen über sicherheitsbedingte Patches bis hin zu Konfigurationsanpassungen für neue Anforderungen. Um Wildwuchs oder unkontrollierte Eingriffe zu verhindern, wird ein strikter Change-Prozess etabliert. Dieser orientiert sich an anerkannten Modellen (z. B. ITIL Change Management) und stellt sicher, dass jede Änderung geplant, bewertet, freigegeben, dokumentiert und rückverfolgbar ist.

• Antragstellung: Ein Change Request wird erfasst mit Beschreibung der geplanten Änderung und Begründung (z. B. „Update auf Version X aufgrund neuer Funktionen/Bugfixes“).

• Bewertung: Fachexperten bewerten den Change hinsichtlich Auswirkungen (Impact-Analyse), Risiken und Aufwand. Gegebenenfalls wird eine Kostenschätzung vorgenommen, falls externe Aufwände entstehen.

• Freigabe: Ein zuständiges Gremium gibt die Änderung frei. Größere Änderungen gehen ins Change Advisory Board (CAB), dem Vertreter aus Betrieb, Entwicklung und Fachbereich (Kunde) angehören, um alle Perspektiven abzudecken. Geringfügige Changes können über vordefinierte Standard-Change-Prozesse schneller freigegeben werden.

• Planung der Umsetzung: Es wird ein genauer Umsetzungsplan erstellt: Zeitfenster (wann wird geändert, z. B. nächstes Wartungsfenster), verantwortliche Personen, betroffene Komponenten, und ein Backout-Plan (Rollback-Möglichkeit, falls etwas schiefgeht). Die Kommunikation an Benutzer/Mandanten wird vorbereitet, falls Downtime oder Änderungen im User-Erlebnis zu erwarten sind.

• Durchführung: Die Änderung wird im vereinbarten Zeitfenster von den zuständigen Technikern umgesetzt. In einer SaaS-Umgebung erfolgt das Ausrollen neuer Releases oft automatisiert über eine Pipeline (Continuous Delivery), nachdem die Version in Test/Staging-Umgebungen ausreichend erprobt wurde. Während des Deployments werden laufend Checks durchgeführt. Treten akute Probleme auf, kann ggf. der Notfall-Change-Prozess (Emergency Change) greifen, bei dem schnelle Gegenmaßnahmen oder Rollback initiiert werden.

• Nachbereitung: Nach erfolgreicher Umsetzung wird der Change dokumentiert (Change-Report mit Beschreibung, Zeitpunkt, Verantwortlichen, Ergebnis) und die Dokumentation wird aktualisiert (z. B. neue Versionsnummer in Systemdoku, Anpassung von Benutzerhandbüchern bei UI-Änderungen). Außerdem holt man Feedback ein – etwa von Key-Usern –, um sicherzustellen, dass alles erwartungsgemäß läuft.

Durch dieses disziplinierte Change- und Release-Management können Verbesserungen und Updates kontinuierlich eingespielt werden, ohne die Stabilität des laufenden Betriebs zu gefährden. Risiken werden vorab betrachtet und Rollback-Pläne stehen bereit, falls etwas schiefgeht. Das Change-Management trägt so wesentlich dazu bei, Ausfallrisiken zu minimieren und die Compliance zu wahren, da jederzeit nachvollziehbar ist, wer welche Änderung genehmigt und durchgeführt hat Nicht zuletzt erhöht es das Vertrauen der Anwender, da Änderungen transparent kommuniziert und kontrolliert umgesetzt werden.

Applikationsbetrieb und Monitoring im CAFM-Kontext erfordern ein ganzheitliches Vorgehen – von klaren Betriebskonzepten über technische Überwachung bis hin zu robusten Betriebsprozessen für Incident- und Change-Management. Nur so kann eine CAFM-/IWMS-Lösung langfristig stabil, sicher und effizient betrieben werden, was die Grundlage für jedes erfolgreiche digitales Facility Management bildet.