CAFM: Betriebsdokumentation und Runbooks

Ein Betriebshandbuch (auch Betreiber- oder Objekthandbuch) fasst alle für den Systembetrieb relevanten Informationen zusammen. Typische Inhalte sind: Systemübersicht (Topologie, Komponentenliste, Schnittstellen), Verantwortlichkeiten, Kontaktadressen, Zugriffsrechte und Betriebszeiten. Zudem gehören detaillierte Betriebs- und Wartungsanweisungen zum Beispiel für Anlagen, Software-Updates oder Sicherheitstechnik dazu. Nach GEFMA-Richtlinie 190 sollte das Handbuch u. a. Betriebs-, Inspektions- und Wartungsanweisungen sowie Flucht- und Rettungspläne enthalten; organisationsbezogene Unterlagen (z. B. Organigramm, Prozessabläufe) und lückenlose Aufzeichnungen über Prüfungen und Gefährdungsbeurteilungen. Im CAFM-Kontext ergänzt man dies um Verfahrensanweisungen für typische IT-Aufgaben (Backups, Rollouts, User-Administration) und betriebsspezifische Workflows.

Das Betriebshandbuch ist idealerweise in Kapitel gegliedert – etwa Systemumgebung, Prozeduren (Monitoring, Backup, Neustart etc.), Support und Eskalation, Dokumentation (Datenflüsse, Schnittstellen, Updates). Wichtig ist ein klarer Pflegeprozess: Änderungen an Systemen oder Prozessen führen zu sofortigen Aktualisierungen im Handbuch. Praxistipps sehen vor, bereits bei Inbetriebnahme alle relevanten Unterlagen zu erfassen (Pläne, Schaltbilder, Listen) und das Handbuch frühzeitig zu übergeben. Es sollte regelmäßig überprüft und bei Änderungen in Betriebsabläufen, neuen Gesetzen oder Technologien angepasst werden. In der Regel benennt man einen Dokumentenverantwortlichen, der Review- und Freigabezyklen steuert. So wird sichergestellt, dass das Handbuch stets vollständig und aktuell ist .

Ein Runbook ist eine ausführliche Schritt-für-Schritt-Anleitung für häufig wiederkehrende IT-Betriebsaufgaben. Es enthält standardisierte Abläufe, um z. B. Server-Patches durchzuführen, Backups anzulegen oder andere Routineprozesse zu erledigen. Runbooks bieten neuen wie erfahrenen Teammitgliedern „das Wissen und die Schritte, um schnell und präzise eine Aufgabe zu lösen“. Man kann sie sich wie ein Rezept vorstellen, das detailliert beschreibt, wie ein Ergebnis sicher erzielt wird. Dadurch teilen Experten ihr Wissen, und auch bei Ausfall von Schlüsselpersonen bleibt Wissen verfügbar. Der Nutzen von Runbooks liegt in höherer Effizienz und Zuverlässigkeit: Sie standardisieren Abläufe, verkürzen Einarbeitungszeiten und verringern Ausfallzeiten. Techtarget fasst zusammen, dass Runbooks die Konsistenz steigern und durch Standardisierung die Effizienz erhöhen, was „die Systemverfügbarkeit verbessert und Ausfälle reduziert“.

• Übersicht und Ziele: Kurze Beschreibung des Prozesses, betroffener Service und verantwortliche Rollen.

• Voraussetzungen: Technische Anforderungen (z. B. Zugriffsrechte, Software-Versionen).

• Schritt-für-Schritt-Anleitung: Detaillierte Abfolge der Befehle oder Aktionen, inklusive Screenshots oder Codebeispielen.

• Eskalationshinweise: Kriterien, wann eine Aufgabe an höhere Support-Ebenen übergeben wird, und Kontaktadressen für Hilfe.

• Rückfall- und Notfallplan: Vorgehen bei Fehlern oder Ausfällen (Rollback, Neustart, Logsammlung).

• Dokumentation: Verweise auf weiterführende Dokumente, Service Levels oder Change-Tickets.

Je nach Automationsebene können Runbooks manuell (bedienergeführt), teilautomatisiert oder vollautomatisiert sein. Empfehlenswert ist ein konsistentes Format (z. B. Wiki-Seite, PDF oder spezielles Runbook-Tool) mit klarer Struktur. Wichtig ist, dass Runbooks regelmäßig geprüft und aktualisiert werden – als „lebende Dokumente“, die Änderungen in Systemen und Prozessen berücksichtigen. So bleibt die Dokumentation immer aktuell und praxistauglich.

Moderne CAFM-/IWMS-/CMMS-Systeme integrieren sich meist in eine heterogene IT-Landschaft (ERP, Buchhaltung, IoT-Sensoren, GIS/CAD, Wartungsplaner etc.). Daher müssen alle Schnittstellen klar dokumentiert sein: Art (z. B. API, Webservice, CSV-Import), technische Spezifikation (Datenformat, Felddefinitionen), Übertragungswege und -frequenzen (z. B. Echtzeit vs. Batch) sowie Verantwortlichkeiten. Ebenso gilt dies für ETL-Prozesse (Extraktion, Transformation, Laden), etwa beim initialen Datenimport aus Excel-Listen oder beim fortlaufenden Abgleich von Inventardaten. Hier dokumentiert man Herkunftssystem(e), Transformationsregeln (Mapping, Berechnungen) und Zieltabellen. Datenflüsse lassen sich gut in Diagrammen (z. B. Datenflussdiagramme) visualisieren, um die Prozessschritte und Abhängigkeiten zu verdeutlichen.

Die CAFM-Connect-Schnittstelle harmonisiert Datenflüsse zwischen CAFM und Fremdsystemen. Sie kann Wartungs- und Kosteninformationen in Echtzeit ins ERP übertragen oder Sensordaten (z. B. Temperaturmessungen) an das CAFM-System liefern. Die Dokumentation dieser Datenflüsse ist essenziell, da sie automatische Prozesse ermöglicht und Fehler vermeidet. Automatisierte Datenübergaben steigern Effizienz und Transparenz, reduzieren manuelle Eingriffe und stellen die Compliance sicher, indem sie „Daten konsistent dokumentieren“.

Die betriebliche Dokumentation umfasst alle routinemäßigen Abläufe, die für den IT-Betrieb nötig sind.

• Backup und Recovery: Ausführliche Beschreibung des Backup-Konzepts – wer ist zuständig, welche Systeme wann gesichert werden, mit welchen Werkzeugen (z. B. Voll-/Inkremental-Backups) und wo die Sicherungen aufbewahrt werden. Praktisch listet man in einer Tabelle: Verantwortliche Personen, Backuptools, Sicherungsintervalle, Aufbewahrungsfristen und Prozeduren für Wiederherstellungstests. Beispielsweise empfiehlt eine Checkliste, mindestens folgende Punkte zu dokumentieren: Kontakte der Backup-Verantwortlichen, Backup-Verfahren, Zuordnung der Systeme zu Sicherungsmethoden, Backup-Intervall, Quelle der Backup-Software, Ablageort von Zugangsdaten und Vorgehen bei Test-Wiederherstellungen. So kann jeder IT-Mitarbeiter im Notfall die Wiederherstellung nachvollziehbar durchführen.

• Monitoring und Alarming: Auflistung der überwachten Komponenten (Server, Dienste, Netzwerk), der eingesetzten Monitoring-Tools und der definierten Schwellenwerte/Events. Dokumentiert wird, wer auf welche Alerts reagiert und mit welchen Prozeduren (z. B. Logs analysieren, Neustart durchführen). So ist sicher, dass „bei einem Alarm sofort klar ist, was zu tun ist“. In Runbooks selbst finden sich oft Anweisungen zum Überwachen des Systems – nach ITIL gehören Monitoring-Aufgaben zum operativen Betrieb.

• Systemneustart (Restart): Schritt-für-Schritt-Anleitung zum kontrollierten Hochfahren, Herunterfahren und Neustarten der CAFM-Anwendung bzw. der zugrunde liegenden Server. Dies umfasst ggf. Reihenfolgen (z. B. erst Datenbank, dann Anwendung), Fehlermeldungen und Nachkontrollen. Ein Runbook für Systemneustarts enthält typischerweise alle notwendigen Anweisungen, da „ein Runbook Anweisungen zum Starten, Stoppen, Überwachen und Debuggen des Systems“ bereitstellt.

• Benutzer- und Rollenpflege: Verfahren zur Verwaltung von Benutzerkonten und Berechtigungen im CAFM-System. Das beinhaltet das Anlegen/Deaktivieren von Accounts, Zuweisung von Rollen nach dem Need-to-Know-Prinzip und regelmäßige Überprüfung von Berechtigungen. Die Dokumentation hält fest, welche Rollen es gibt, wer sie vergeben darf (z. B. Administratoren), und wann Zugriffsrechte angepasst werden müssen (z. B. bei Abteilungswechsel). So wird die Sicherheit und Nachvollziehbarkeit gewährleistet.

Es sollten alle Betriebsprozesse so beschrieben sein, dass ein fachfremder Dritter sie ausführen kann. Backup-Experten betonen, dass gerade die Bedienungsanleitung in Notfällen entscheidend sein muss – sie muss so klar formuliert sein, dass ein anderer Mitarbeiter sie sicher umsetzen kann. Analog zu den Backup-Anleitungen empfehlen sich für alle zentralen Prozesse Checklisten oder Flowcharts als Betriebsunterstützung.

Auch Supportprozesse gehören in die Betriebsdokumentation. Für Change Management dokumentiert man den Ablauf von Änderungsanträgen: Ein Antragsteller, Genehmigungsinstanzen (z. B. Change Advisory Board), Risikobewertung, Test- und Rollback-Konzepte sowie Freigabeprotokolle. So wird sichergestellt, dass Änderungen kontrolliert und nachvollziehbar durchgeführt werden. Beim Incident Management beschreibt man, wie Störungen erfasst, priorisiert und behoben werden. Das schließt Ticket-Vorlagen, Meldewege (z. B. internes Helpdesk-Ticket oder Systemalarm) und Kommunikationswege ein (Statusberichte, Eskalationsregeln).

Für das Problem Management hält man Verfahren zur Ursachenanalyse (Root Cause) und zum Umgang mit wiederkehrenden Fehlern fest. Hierzu gehört ein Known-Error-Register, in dem dokumentierte Fehler und Gegenmaßnahmen zentral erfasst werden. Allein durch klare Prozesse lassen sich Missverständnisse vermeiden – ITIL empfiehlt eine solche formale Ablaufbeschreibung für Störungs- und Problemprozesse. Wichtig sind Eskalationspfade: Definierte Schwellen, wann ein Incident an den nächsten Support-Level (z. B. von Level-1 auf Level-2) weitergeleitet wird oder wann die IT-Leitung informiert wird. Ein Eskalationsverfahren ist ein „vorbereitetes, strukturiertes Vorgehen, um ein ungelöstes Problem an eine höhere Support- oder Verantwortungsebene zu übergeben“. So wird sichergestellt, dass komplexe oder kritische Vorfälle schnell den richtigen Experten erreichen und die Betriebsbereitschaft rasch wiederhergestellt wird.

Ebenfalls dokumentiert werden alle Systemumgebungen und deren Versionen: Zum Beispiel Entwicklungs-, Test- und Produktionslandschaft (Servernamen, IP-Adressen, installierte Softwareversionen, Konfigurationen). Für jedes System beschreibt man Umgebung (z. B. On-Premises vs. Cloud), Datenbanken und Hardware-Ressourcen. Die aktuellen Release-Stände der CAFM-Software und ihrer Komponenten sind festzuhalten – inkl. Versionsnummer, Patchlevel, Datum der letzten Aktualisierung und ggf. Changelog. Diese Informationen erleichtern das Update- und Backup-Management sowie die Fehlersuche.

Etwa welche Daten in welchem Mandanten liegen, wie Mandantensperren und Rechte übergreifend gehandhabt werden und ob es abweichende Konfigurationen gibt. So ist jederzeit ersichtlich, welcher Mandant welche Version nutzt und wie Daten getrennt sind. Damit werden Komplexität und Verantwortlichkeiten transparent, z. B. wenn verschiedene Geschäftsbereiche separate Mandanten verwenden.

Alle Betriebsdokumente sollten unter Versionskontrolle stehen und einem klaren Genehmigungsprozess folgen. So lässt sich jederzeit nachvollziehen, wer wann welche Änderung gemacht hat. Eine formale Dokumentationsrichtlinie oder ein kleines Governance-Konzept hilft dabei. Wichtige Elemente sind eine einheitliche Versionierungslogik (z. B. Datum im Dateinamen oder automatisiertes Versionsmanagement) und Freigabeprozesse: Jeder neue oder geänderte Dokumententwurf wird durch feste Verantwortliche geprüft und freigegeben. Dabei kann ein Workflow-Tool unterstützen. Die Docusnap-Leitlinie empfiehlt klare Regeln für Struktur, Layout und Versionierung sowie definierte Review- und Freigaberoutinen. So bleiben Dokumente aktuell und revisionssicher: „Dokumentationsmanagement berücksichtigt Versionierung, interne Verantwortlichkeiten und Compliance-Vorgaben“, um Informationen nachvollziehbar und rechtssicher zu halten. Zudem gehören Änderungsprotokolle (Changelogs) zur besseren Nachvollziehbarkeit, und alte Versionen werden archiviert. In der Praxis bewährt sich auch ein regelmäßiger Redaktionszyklus: So wie Code-Reviews üblich sind, sollte die Dokumentation in festgelegten Intervallen auf Aktualität geprüft werden.

Damit die Dokumentation im Alltag lebt, sollte sie in passende Wissens- und Betriebssysteme eingebettet werden. Beliebt sind Wiki- oder Knowledge-Base-Tools (z. B. Confluence, SharePoint, Jira Service Management), in die Betriebsanleitungen, FAQs und Runbooks zentral eingepflegt werden. Eine solche Wissensdatenbank fungiert als Zentraler Wissensspeicher, auf den alle Teams zugreifen können. Sie erlaubt Volltextsuche, Versionshistorie und Feedbackprozesse. Atlassian betont, dass eine Wissensdatenbank FAQs, Handbücher und Runbooks enthalten kann, auf die Teams selbstständig zugreifen. Das fördert Self-Service und gleichbleibende Informationsverteilung: Alle Mitarbeiter greifen so „auf dasselbe Playbook“ zurück, wodurch ein konsistenter Service und höhere Erstlösungsraten erreicht werden.

Weiterhin empfiehlt es sich, Dokumente in das Betriebskonzept einzubinden: Beispielsweise könnten Schichtübergaben Checklisten in der Wissensdatenbank enthalten, oder Änderungsprotokolle aus dem IT-Service-Management-Tool automatisch verknüpft werden. Betriebs- und Notfallkonzepte (z. B. Störfallhandbuch) sollten ebenfalls Teil des Knowledge Managements sein. Idealerweise verknüpfen moderne CAFM-Systeme selbst Dokumente (z. B. Anleitungen) mit relevanten Modulen – etwa ein Ticketsystem zeigt direkt das passende Runbook zum Störungsfall an. Wichtig ist vor allem ein Governance-Prozess, der Mitarbeiter motiviert, Wissen beizusteuern und zu aktualisieren (z. B. Rollenzuweisung für Dokumentenpflege). Insgesamt sorgt eine enge Verzahnung von Dokumentation mit operativen Konzepten dafür, dass Informationen nicht isoliert in Ordnern liegen, sondern aktiv für den Betriebsalltag genutzt werden – sei es durch ein Wiki, ein DMS oder integrierte Betriebssysteme.