CAFM: Konfigurations- und Dokumentationsmanagement

Änderungen an der CAFM-Konfiguration werden durch einen formalen Change- und Release-Management-Prozess gesteuert.

• Erfassung: Jede geplante Änderung wird in einem Change Request erfasst – z. B. „Austausch Kältekompressor Nr.2“, „Neue Benutzerrolle X anlegen“ oder „Formel in Kostenberechnung anpassen“.

• Bewertung und Freigabe: Fach- und IT-Verantwortliche prüfen den Antrag. Ein definiertes Gremium (z. B. Change Advisory Board) genehmigt die Änderung formal. Nach Freigabe wird der Change im Protokoll bzw. Ticketsystem dokumentiert.

• Umsetzung: Die Konfiguration wird implementiert (z. B. im Testsystem) und getestet. Alle Parameteränderungen und Skripte werden versioniert abgelegt (z. B. in einem Repository oder Änderungslog).

• Nachverfolgung: Jede Änderung wird mit Datum, Verantwortlichem, Freigabehinweisen und Versionsnummern aufgezeichnet. Ein Change-Logbuch oder Ticketsystem führt Historie und stellt Audit-Trails sicher.

• Release-Management: Mehrere Changes können in einem Release zusammengefasst werden. Rollback-Pläne und Freigabetests stellen sicher, dass Updates (Security-Patches, neue Module) reibungslos ausgerollt werden.

Dank dieses strengen Prozesses lässt sich jederzeit nachvollziehen, wer wann was im System geändert hat. Dies entspricht ITIL-Vorgaben: Eine CMDB führt alle „Configuration Items“ und Änderungsanträge, und jede Freigabe wird dokumentiert. So werden technische Integrität und Auditfähigkeit des Systems sichergestellt.

Für System- und Dokumentenversionen gelten klare Regeln: Vor jedem Update wird eine Baseline des Systems bzw. der Konfiguration angelegt. Alte Systemstände, vorherige Releases und Dokumentenversionen bleiben erhalten.

• Systemstände: Updates (Major/Minor-Releases) werden als eigene Version geführt. Das CAFM-Team dokumentiert Versionsnummer, Inhalt und Datum jedes Releases. Bei Problemen ist so ein Rücksetzen auf die Vorversion möglich (Rollback).

• Dokumentenversionen: Alle Handbücher, Prozessbeschreibungen und Spezifikationen sind versioniert. Ältere Versionen bleiben im Archiv abrufbar (inklusive Änderungsbegründung und Autorenangabe).

• Änderungsprotokolle: Sowohl bei Konfiguration als auch bei Stammdaten wird ein Protokoll geführt: z. B. wer Parameter geändert hat und warum. Jede Datenänderung oder Parametrisierung wird mit Zeitstempel im Systemjournal festgehalten.

• Historie im System: Viele CAFM-Systeme bieten Historisierungsfunktionen für Stammdatensätze (z. B. bei Flächen oder Assets). Damit ist ersichtlich, wann ein Datensatz (z. B. Flächennutzung oder Inventarnummer) geändert wurde.

Auf diese Weise bleiben frühere Zustände immer nachvollziehbar. Die Versionierung vermeidet Konflikte bei Mehrbenutzerbetrieb und unterstützt die Revisionssicherheit: Kein Eintrag verschwindet unwiederbringlich.

Man unterscheidet technische Konfiguration (Infrastruktur und Systemeinstellungen) von fachlicher Parametrisierung (Anwenderseitige Customizing-Einstellungen). Die technische Ebene umfasst z. B. System-Server, Datenbankversionen, Netzwerk- und Security-Settings. Die fachliche Ebene betrifft die im CAFM-Frontend sichtbaren Anpassungen: Validierungsregeln, Kalkulationsformeln oder Workflows für Facility-Prozesse. Beide Ebenen werden getrennt dokumentiert – etwa in IT-Betriebsunterlagen (Firewalls, OS) versus CAFM-Betriebshandbuch (Module, Feldlogik). Diese Trennung stellt klar, welche Änderungen nur vom IT-Betrieb (Ops-Team) und welche vom CAFM-Projektteam durchgeführt werden dürfen.

Das Datenmodell des CAFM ist Kern der Software. Es definiert Objektklassen (z. B. Gebäude, Raum, Maschine) und ihre Attribute.

• Stammdatendefinitionen: Standardisierte Beschreibungen für alle Objekttypen und Attribute (Name, Typ, Pflichtfeld, Standardwerte). Z. B. umfasst dies Adressdaten, Gebäude- und Raumdaten, technische Ausstattung, Flächendaten, Produkt- und Vertragsstammdaten.

• Merkmalslogik: Festlegung, wie Attribute interagieren. (z. B. wenn „Gebäude aktiviert = Nein“, sind alle Räume inaktiv.) Beschrieben wird auch, welche Merkmale in welchen Prozessen verwendet werden.

• Datenhierarchien: Dokumentation der Hierarchien (Liegenschaft → Gebäude → Stockwerk → Raum) und Zuordnungen. Ergänzt werden Richtlinien zur Vergabe eindeutiger Kennzeichen (z. B. Raum-ID-Systematik).

• Data Governance: Prozesse zur Pflege der Stammdaten (Data Owner, Review-Intervalle, Datenqualitätsprüfungen).

Damit bleibt das Datenfundament konsistent. Die Richtlinie GEFMA 470 etwa fordert klare Datenstrukturen, um Datenaustausch zu standardisieren. Ein gepflegtes Datenmodell verhindert redundante oder widersprüchliche Informationen und erleichtert spätere Systemerweiterungen.

• Audit-Trail: Jede Änderung (Parameter, Stammdatum, Script) wird im Systemjournal protokolliert: Wer hat wann welchen Wert gesetzt. Dadurch kann niemand Konfigurationen „Schönfärben“, ohne Spuren zu hinterlassen. Auch Dokumente erhalten eine Revision, Änderungen werden mit Zeitstempel, Änderungsgrund und Autor erfasst.

• Rollenzugriff: Das Berechtigungsmodell wird selbst dokumentiert, so dass jederzeit nachvollziehbar ist, welche Rolle welche Rechte hatte (z. B. Änderungsrecht im Modul „Wartung“ nur für Projektleiter). Feingranulare Berechtigungsregeln verhindern unautorisierte Änderungen.

• Protokolle & Logs: Wichtig ist die Langzeitarchivierung von Protokollen (z. B. Änderungs-, System- und Benutzerlogs). ISO 27001 und gesetzliche Vorgaben (z. B. HGB-Aufbewahrungsfristen) schreiben vor, dass Protokolldaten über Jahre verfügbar sein müssen. Eine regelmäßige Sicherung aller Konfigurationsdaten gehört ebenfalls dazu.

• Review- und Freigabeworkflows: Neue oder geänderte Dokumente durchlaufen Freigabeschritte (z. B. Sachbearbeiter, Key-User, QM-Abnahme). So wird sichergestellt, dass jede Planungs- oder Verfahrensanpassung formell geprüft ist.

Durch diese Maßnahmen entstehen nachvollziehbare Audit-Trails. Das gesamte Konfigurationsmanagement ist dann revisionssicher – relevante Nachweise können bei internen oder externen Audits vorgelegt werden.

Die CAFM-Lösung wird in den größeren IT-Betriebsrahmen eingebunden. Das bedeutet: CAFM-CIs und -Änderungen werden in das unternehmensweite ITSM (z. B. ServiceNow, Jira Service Management) integriert.

• Handover an den Betrieb: Nach erfolgreicher Einführung wird die Systemdokumentation an das Betriebs- oder Support-Team übergeben. Ein Betriebsübergabe-Protokoll oder -Handbuch listet alle Konfigurationen und Schnittstellen auf.

• CMDB-Anbindung: Das CAFM-System und ggf. dessen Komponenten (Server, Datenbank, Lizenzserver) werden als Configuration Items (CIs) in die CMDB eingepflegt. So kann über das Change-Management jeder CAFM-Release oder Patch nachverfolgt werden.

• Change-Management: Geplante CAFM-Änderungen laufen über das zentrale Change-Prozess-Tool (inkl. Genehmigungen). Dabei wird aus dem CAFM heraus ein Link zum entsprechenden Change-Ticket bereitgestellt und umgekehrt im Ticket Hinweise zur CAFM-Konfiguration.

• Betriebsdokumente: Übergabe-Dokumente enthalten z. B. Checklisten für den 1st/2nd-Level-Support, Eskalationsprozeduren und Kontaktlisten. Häufig wird eine RACI-Matrix definiert (wer ist verantwortlich/für was informiert) – z. B. „Backup durchführen (IT-Abteilung=Responsible, FM-Team=Informed)“.

Diese enge Verzahnung stellt sicher, dass CAFM-Änderungen wie jedes andere IT-Service-Change formal gesteuert, getestet und freigegeben werden. Schnittstellen zu anderen Systemen (ERP, IoT-Plattform, GLT) werden dabei als Teil der Service-Architektur verwaltet.

• Dokumentenmanagement-System (DMS): Ein zentrales CAFM-DMS speichert alle Protokolle, Handbücher, Schnittstellendefinitionen und Konfigurationsdokumente. Es bietet Versionierung, Check-In/Out, Metadaten und Workflows für Freigaben. (Beispiel: Ein neuer Parameter wird im DMS erfasst und nach Review freigegeben.)

• Konfigurations-Repository: Entwicklungs- und DB-Teams nutzen oft Versionskontrolle (z. B. Git), um Skripte oder „Infrastructure as Code“-Assets zu verwalten. So sind alle Infrastruktur- und Systemskripte verfolgbar.

• Vorlagen und Checklisten: Standardvorlagen (z. B. Change-Request-Formular, “Release-Notes”-Template, Rollen- oder Datenmodellmatrix) sorgen für einheitliche Dokumentation. Checklisten helfen, dass alle Aspekte (Module, Schnittstellen, Schulungen) abgearbeitet werden.

• Wiki oder internes Handbuch: Ergänzend kann ein Wiki (z. B. Confluence) verwendet werden, um Wissen kollaborativ zu pflegen (FAQ, Anleitungstexte). Dieses kann direkt aus dem CAFM oder Service-Portal verlinkt werden.

• Regelmäßige Reviews: Ein definierter Prozess sieht vor, Dokumentation und Konfiguration in bestimmten Abständen zu prüfen (z. B. jährliche Review-Meetings). Abweichungen oder neue Anforderungen (gesetzliche Vorgaben) führen dann zu Updates.

Moderne CAFM-Anbieter liefern oft Tools für eine revisionssichere Dokumentation mit. Letztlich ist wichtig, die Dokumente an einem zentralen Ort zugänglich zu halten – und Verantwortlichkeiten für ihre Pflege festzulegen. So geht kein Wissen verloren.

Die CAFM-Systemlandschaft umfasst oft viele externe Schnittstellen (ERP, CAD, IoT-Sensoren, SP, GLT, Zeiterfassung u.v.m.).

• Datenflüsse: Flussdiagramme zeigen, welche Daten (Stammdaten, Bewegungsdaten) zwischen CAFM und Fremdsystemen übertragen werden.

• Schnittstellenbeschreibung: Für jede Schnittstelle wird festgehalten, welches Protokoll/Format verwendet wird (z. B. REST API, CSV, BCF) und wie Daten gemappt sind (Mapping-Tabellen).

• Jobsteuerung: Bei geplanten Datentransfers (z. B. nächtliche Bestandsabgleiche) dokumentiert man Zeitpläne (Cron-Jobs), Trigger-Kriterien und Zuständigkeiten.

• Test- und Überwachungsprotokolle: Schnittstellen-Logs werden ebenfalls protokolliert (z. B. Datum/Uhrzeit, übertragene Datensätze, Fehlermeldungen). So kann man bei Störungen schnell eingreifen.

Beispiele für Dokumentation sind Datenflussdiagramme oder Tabellen, die Felder aus System A den Feldern in CAFM zuordnen (siehe Muster unten). In der Praxis wird oft das Betriebshandbuch um einen Abschnitt „Systemintegration“ ergänzt. Wie bei den Konfigurationen gilt: Alle Schnittstellendetails (inkl. Kontakt für Fremdsystem-Betreiber) werden revisionssicher abgelegt.

• ISO 9001 (Qualitätsmanagement): Forderung nach dokumentierten Prozessen und Dokumentenlenkung. Ein gepflegtes Konfigurationshandbuch und Prüfberichte unterstützen die Qualitätsnachweise. Ähnlich verlangt ISO 10007 nach einem klaren Change-Control-Prozess.

• ISO 27001 (Informationssicherheit): Er legt fest, dass Änderungen an wichtigen Systemen kontrolliert, dokumentiert und auditiert werden. Benutzer- und Aktivitätsprotokolle (Audit-Logs) müssen vertraulich und manipulationssicher archiviert werden.

• GEFMA 444 (CAFM-Qualitätsstandard): Zertifizierte CAFM-Anbieter müssen eine transparente Betriebs- und Dokumentationsorganisation nachweisen. Hier fließen Punkte wie Release-Planung, Systemdokumentation und Audittauglichkeit ein.

• Branchen- und Datenschutzvorgaben: Je nach Umfeld (z. B. Gesundheitswesen, öffentliche Verwaltung) kommen zusätzliche Pflichten hinzu (z. B. Nachweis aller Systemänderungen, lückenlose Log-Aufbewahrung). Auch DSGVO-Anforderungen an Datenzugriff werden adressiert, indem Rollenrechte genau dokumentiert und Logins erfasst werden.

Durch ein strukturiertes Dokumentations- und CM-Konzept lassen sich alle Compliance-Anforderungen erfüllen und Nachweise im Auditmodus abrufen. Fehlt ein solches Konzept, drohen bei Prüfungen Regress und Imageverlust.

Ohne klares CM-Konzept entstehen häufig Inkonsistenzen und Risiken. So kann z. B. ein unbeaufsichtigter Einzeländerung zu fehlerhaften Berechnungen oder Sicherheitslücken führen.

• Ein Change-Logbuch, in dem jede Konfigurationsänderung in einem Takt (Datum, Verantwortlicher, Beschreibung, Freigabe) geführt wird. So erkennt man z. B. im Fehlerfall sofort, wann eine Änderung vorgenommen wurde.

• Rollback-Pläne für Releases: Vor jedem Update wird geprüft, wie man im Fehlerfall auf die alte Version zurückkommt (Backup-Procedure).

• Verantwortlichkeiten nach RACI: Klar definierte Zuständigkeiten (z. B. Mandanten-Administrator, CAFM-Key-User, IT-Administrator) verhindern Überschneidungen.

Typische Risiken ohne Dokumentationskonzept sind Datenverluste, lange Ausfallzeiten und unklare Verantwortlichkeiten. Ohne Audit-Trail gerät das Unternehmen in Haftungsgefahr (z. B. bei Zertifizierungs- oder Compliance-Audits). Im schlimmsten Fall führt unkoordiniertes „Konfigurieren nach Gutdünken“ zu einem instabilen System („Wildwuchs“).

Als Best Practices gelten: Eine klare Checkliste für alle Konfigurationsarten (siehe Tabelle unten), regelmäßige Schulungen der Key-User (die Dokumentationspflege ist Teil ihrer Rolle) und die konsequente Anwendung von Versionskontrolle. Zudem empfiehlt es sich, bekannte Leitfäden (z. B. GEFMA 420) zu nutzen, die ein strukturiertes Vorgehen über Konzeption und Implementierung sicherstellen.

Es stellt ein konsequentes CAFM-Konfigurations- und Dokumentationsmanagement sicher, dass das System über den gesamten Lebenszyklus hinweg effizient betrieben werden kann, ohne wesentliche Wissenslücken oder Risiken.

Beispielhafte Dokumente: Muster für Change-Request-Formular, Konfigurationschecklisten (Module/Parameter) und Rollenmatrizen sowie Interfaces-Übersichten können im Anhang bereitgestellt werden (siehe Empfehlung von GEFMA 922 bzw. internen QM-Leitfäden). Solche Vorlagen unterstützen den Arbeitsalltag und erhöhen die Konsistenz der Dokumentation.