CAFM-System: Installation, Roll-Out, Softwarewartung und Pflege

Vor dem flächendeckenden Roll-Out ist eine Pilotphase durchzuführen. In diesem Pilotbetrieb wird das System zunächst in einem begrenzten Umfang getestet – z. B. in einer ausgewählten Liegenschaft, Abteilung oder mit einer begrenzten Nutzergruppe. Ziel ist es, die Konfiguration unter realen Bedingungen zu verifizieren und etwaige Probleme frühzeitig zu erkennen, bevor die gesamte Organisation migriert wird. Die Erkenntnisse aus der Pilotierung fließen in die Optimierung der Systemeinstellungen und Schulungskonzepte ein. Anschließend erfolgt der Roll-Out stufenweise nach einem festzulegenden Roll-Out-Plan. Die Stufenplanung kann nach Organisationseinheiten, Standorten oder Funktionen erfolgen – bspw. Einführung erst in der Zentrale, dann schrittweise in Regionalstandorten, oder zuerst Modul A (z. B. Flächenmanagement) vor Modul B (Instandhaltung). Ein iterativer Roll-Out (schrittweise Einführung) minimiert Risiken, da Fehler oder Akzeptanzprobleme früh erkannt und behoben werden können, bevor alle Nutzer betroffen sind. Die jeweils gewonnenen Erfahrungen sollen für die nächsten Roll-Out-Wellen genutzt werden (kontinuierliche Optimierung). Alternativ ist auch ein „Big Bang“-Rollout (gleichzeitige Umstellung aller Bereiche zum Stichtag) zu betrachten, dieser birgt jedoch höhere Risiken (fehlende Rückfalloption, hohe Belastung aller Anwender zeitgleich). Die Entscheidung über die Roll-Out-Strategie wird in Abstimmung mit dem Auftraggeber getroffen und hängt von Rahmenbedingungen wie Projektgröße, Ressourcen und Risikobereitschaft ab. Unabhängig von der gewählten Strategie muss es für jede Phase einen detaillierten Roll-Out-Plan geben: dieser enthält Meilensteine, Verantwortlichkeiten, Zeitpläne und Erfolgskriterien für jede Einführungsstufe.

Die Einführung eines CAFM-Systems bedeutet eine Veränderung der Arbeitsprozesse und Gewohnheiten vieler Beteiligter. Daher ist ein proaktives Change Management unverzichtbar. Es muss ein Konzept vorliegen, wie die Betroffenen frühzeitig einbezogen und durch den Wandel geführt werden. Dazu zählen eine klare Kommunikationsstrategie (regelmäßige Informationen über Zielsetzung, Fortschritt und Nutzen der Einführung für verschiedene Zielgruppen) sowie Maßnahmen zur Einbindung der Nutzer. Bewährt hat sich z. B. die Einrichtung von Key-User-Gruppen oder Pilotgruppen, in denen Vertreter der Endanwender früh mit dem System arbeiten, Feedback geben und als Multiplikatoren fungieren. Praxisnahe Schulungen und offene Feedback-Runden schaffen Vertrauen in das neue System und fördern die Bereitschaft zur Veränderung. Nur wenn die Anwender verstehen, warum das neue System eingeführt wird und welchen konkreten Mehrwert es im Alltag bietet, steigt die Akzeptanz. Eventuelle Widerstände sind ernst zu nehmen; das Change Management sollte Anlaufstellen für Sorgen und Probleme bieten (z. B. ein zentraler Ansprechpartner oder „Kummerkasten“ für Rückmeldungen). Auch Führungskräfte sind aktiv in den Veränderungsprozess einzubinden, um Top-Down-Unterstützung zu signalisieren. Kommunikationsmaßnahmen können regelmäßige Newsletter, Intranet-Updates, FAQs, Demo-Veranstaltungen oder „Roadshows“ umfassen, in denen das System vorgestellt wird. Ein Änderungsmanagementplan soll all diese Aspekte bündeln und zu jeder Projektphase passende Aktionen vorsehen.

Ein wesentlicher Aspekt der Einführung ist die Überführung bestehender Daten in das neue System. Es ist zu ermitteln, welche Datenquellen migriert werden müssen – z. B. bisherige CAFM- oder Excel-basierte Daten, CAD-Zeichnungen, Anlagenlisten, Wartungstermine aus Altsoftware, Vertrags- oder Liegenschaftsdaten aus ERP-Systemen etc. Für jede Quelle sind Mappings zu definieren, d. h. wie Felder und Strukturen der Altdaten den Datenfeldern im neuen System zugeordnet werden. Der Anbieter muss dabei unterstützen und entsprechende Migrationswerkzeuge bereitstellen. Idealerweise gibt es Importfunktionen oder Skripte, die große Datenmengen automatisiert ins Zielsystem übertragen (z. B. CSV-/Excel-Import, ETL-Strecken oder APIs für Datenübernahme). Die Migration ist vor dem eigentlichen Go-Live testweise durchzuführen (Probeläufe), um Datenqualität und Vollständigkeit zu verifizieren. Dabei sollen Qualitätsprüfungen stattfinden: Sind alle erforderlichen Datensätze übernommen? Stimmen Werte mit der Altdatenbasis überein? Wurden Dubletten bereinigt und ungültige Altdaten herausgefiltert? Möglicherweise ist eine Datenbereinigung im Vorfeld nötig (Entfernen veralteter oder fehlerhafter Einträge), wofür ebenso Kriterien festzulegen sind. Der Anbieter soll einen Migrationsplan vorlegen, der Schritte, Verantwortliche und Zeitfenster (z. B. für Datenextraktion, Transformationslogik, Laden ins Zielsystem) beschreibt. Wichtig ist auch, festzulegen, Zeitpunkt und Dauer der finalen Datenmigration beim Go-Live (oft geschieht das unmittelbar vor dem produktiven Start, ggf. übers Wochenende). Falls ein Parallelbetrieb von Alt- und Neusystem übergangsweise nötig ist, sind Mechanismen zur Datenabgleichung zu definieren oder klare Stichtage, ab denen ausschließlich das neue System „führend“ ist. Für die Nachvollziehbarkeit sollte dokumentiert werden, welche Alt-Datenquelle welchem Datenobjekt im neuen System entspricht, um etwaige Migrationsfehler später zurückverfolgen zu können. Insgesamt muss die Datenmigration so geplant werden, dass Datenverluste vermieden werden und der Produktionsstart mit konsistenten, aktuellen Daten erfolgt.

Eine umfassende Schulung der Anwender und Administratoren ist Voraussetzung für den erfolgreichen Produktivstart. Der Anbieter soll ein Schulungskonzept vorlegen, das unterschiedliche Zielgruppen berücksichtigt: Endanwender (z. B. Hausmeister, Sachbearbeiter), Key User/Administratoren und evtl. technisches Betriebspersonal der IT. Die Schulungen sollten zeitlich so stattfinden, dass die Nutzer ihr Wissen zum Go-Live parat haben (nicht zu früh, um Wissensverlust zu vermeiden, aber rechtzeitig genug für eventuelle Nachschulungen). Falls sinnvoll, ist ein Train-the-Trainer-Ansatz zu nutzen, bei dem der Anbieter zunächst Schlüsselnutzer intensiv schult, welche dann ihr Wissen intern weitergeben können. Auch Schulungsunterlagen sind bereitzustellen (Benutzerhandbücher, Admin-Handbücher, ggf. Online-Hilfen, Tutorials). Diese Unterlagen sollten in deutscher Sprache und auf die spezifische konfigurierte Lösung zugeschnitten sein. Optionale eLearning-Angebote (Webinare, Lernvideos) können die Einführung unterstützen. Wenn die Ausschreibung dies vorsieht, kann dieser Abschnitt im Lastenheft auf ein separates Kapitel „Schulungsanforderungen“ verweisen, wo Details (Schulungsdauer, Teilnehmerzahlen, Anforderungen an Schulungsumgebungen etc.) geregelt werden. Wichtig für den Roll-Out ist, dass eine Test- bzw. Schulungsumgebung zur Verfügung steht, auf der Benutzer gefahrlos üben können, ohne Echtdaten zu beeinträchtigen. Diese Umgebung sollte möglichst realistische Daten enthalten (ggf. anonymisierte Echtdaten) und die finale Konfiguration widerspiegeln.

Die Inbetriebnahme des Systems erfolgt nach erfolgreichem Abschluss aller Vorbereitungen (Pilot, Schulung, Migration). Vor dem offiziellen Go-Live sind Go-Live-Kriterien gemeinsam festzulegen – d. h. Bedingungen, die erfüllt sein müssen, damit der produktive Start erfolgen darf. Typische Go-Live-Kriterien sind: Alle geplanten Daten erfolgreich migriert und stichprobenartig geprüft; Positive Rückmeldungen aus dem Pilotbetrieb; Alle Key User geschult; Keine offenen kritischen Fehler (Severity 1 Bugs) in der Software; Notfallpläne und Supportstrukturen sind etabliert. Insbesondere muss vor Go-Live eine Abnahme (User Acceptance Test) stattfinden: Dabei prüfen Vertreter des Auftraggebers, ob die im Lastenheft definierten Anforderungen erfüllt sind. Dazu wird ein Abnahmetestplan erstellt, der zentrale Funktionen und Szenarien umfasst (z. B. Flächenauswertung erstellen, Störung erfassen und verfolgen, Bericht generieren, Schnittstelle zu ERP testen etc.). Der Anbieter muss diesen Abnahmetest unterstützen, d. h. Testdaten zur Verfügung stellen, Fehlerprotokolle führen und etwaige Mängel umgehend beheben oder Workarounds anbieten. Nur wenn alle Prior-1 Anforderungen erfolgreich nachgewiesen sind (bzw. vereinbarte Abweichungen protokolliert und akzeptiert wurden), wird die Abnahme erteilt. Während der Inbetriebnahmephase (ggf. erste Tage/Wochen nach dem Go-Live) sollte erhöhter Support bereitstehen, um Anwenderprobleme sofort aufzufangen – z. B. Hotline-Verfügbarkeit am Go-Live-Tag. Go-Live wird dann in enger Zusammenarbeit zwischen Auftraggeber und Anbieter durchgeführt, oft an einem Wochenende oder definierten Stichtag. Ggf. ist ein Parallelbetrieb des alten Systems für eine Übergangszeit vorgesehen, um Daten oder Ergebnisse vergleichen zu können – in solchen Fällen sind klare Verfahrensanweisungen notwendig, um doppelte Arbeiten zu vermeiden. Nach dem erfolgreichen Go-Live wird eine Stabilisierungsphase definiert (oft 2–4 Wochen), in der das System intensiv beobachtet und letzte Nacharbeiten durchgeführt werden, bevor in den Regelbetrieb übergegangen wird. Kriterien für den Abschluss der Einführungsphase sind z. B. „X Tage stabiler Betrieb ohne schwerwiegende Vorfälle“ und eine formale Projektabschlussbesprechung.

Alle Tests, Migrationsergebnisse und ggf. Restabweichungen sind schriftlich zu dokumentieren. Der Anbieter liefert zum Projektende eine Systemdokumentation auf dem Stand der produktiven Installation, inkl. Konfigurationsdokumentation, Datenmodell (sofern angepasst), Schnittstellenbeschreibung, Benutzer- und Admin-Handbücher und Protokolle der Abnahme. Diese Dokumente dienen dem Auftraggeber als Referenz für den laufenden Betrieb und eventuelle Re-Ausschreibungen der Betriebsführung oder Weiterentwicklung. Zudem muss ein Abnahmeprotokoll erstellt werden, in dem Auftraggeber und Anbieter gemeinsam festhalten, welche Anforderungen erfüllt wurden und welche ggf. mit Auflagen in den Betrieb gehen. Dieses Protokoll ist von beiden Seiten zu unterzeichnen. Damit ist die Einführung formell abgeschlossen und der Betrieb/Wartungsmodus beginnt.

Nach dem Go-Live muss ein zuverlässiger Support gewährleistet sein, um Fehler zu beheben und Fragen der Nutzer zu beantworten. Der Anbieter soll einen Service Desk bereitstellen (Single Point of Contact), der Störungen und Anfragen entgegennimmt – typischerweise per Ticketsystem, telefonisch oder E-Mail. Eingehende Incidents (Störungsmeldungen) sind zu erfassen, in einem Ticketsystem zu dokumentieren und priorisieren. Dabei werden jedem Ticket zumindest ein Zeitstempel, eine Kurzbeschreibung, der betroffene Bereich/Modul und eine Dringlichkeitsstufe zugewiesen. Es sind klare Reaktions- und Lösungszeiten vertraglich festzulegen (Service Level Agreements, SLA): z. B. Priorität 1 (kritisch, Systemausfall) – Reaktion innerhalb 30 Minuten, Lösung innerhalb 4 Stunden; Priorität 2 (hoch, wichtige Funktion betroffen) – Reaktion innerhalb 2 Stunden, Lösung innerhalb 1 Werktag; Priorität 3 (mittel, minder kritischer Fehler) – Reaktion innerhalb 4 Stunden, Lösung innerhalb 5 Werktagen; etc. Die genauen Zeiten und Prioritätskategorien sind den Bedürfnissen des Auftraggebers anzupassen, aber prüf- und messbar zu definieren. Der Anbieter muss sicherstellen, dass qualifiziertes Personal verfügbar ist, um im SLA-Rahmen Probleme zu analysieren und zu beheben. Workarounds sollten angeboten werden, falls eine sofortige finale Lösung nicht möglich ist. Alle Aktivitäten zur Problemlösung sind im Ticket zu protokollieren (Analyseergebnisse, durchgeführte Änderungen, Kommunikation mit dem Melder). Wird ein Problem vom 1st-Level nicht gelöst, ist eine Eskalation an 2nd- und 3rd-Level Support sicherzustellen. Der 3rd-Level (z. B. Entwickler des Herstellers) sollte in Kontakt stehen, falls tiefgreifende Code-Anpassungen nötig sind. Für schwerwiegende Störungen (Major Incident, z. B. Komplettausfall für alle Nutzer) sind Sonderprozesse vorgesehen: unmittelbar ein Incident Manager benennen, Krisen-Team einberufen und fortlaufende Kundeninformationen zum Status bereitstellen. Nach Lösung eines Incidents wird dieser mit dem Melder abgestimmt geschlossen und einer Ursachenanalyse unterzogen (Problem Management), um künftige Wiederholungen zu vermeiden. Der Anbieter soll regelmäßige Reportings über die Service-Qualität liefern (Anzahl Incidents, durchschnittliche Lösungszeit, SLA-Einhaltung, häufige Problemursachen). Diese Kennzahlen dienen der Steuerung und kontinuierlichen Verbesserung der Softwarequalität. Insgesamt ist der Support an ITIL-Best Practices ausgerichtet (Incident Management, Problem Management) und garantiert dem Auftraggeber eine transparente, zuverlässige Wartung.

Neben Reaktions-/Lösungszeiten für Störfälle sollte das Lastenheft SLAs für weitere Betriebsaspekte fordern, z. B. Verfügbarkeit des Systems (siehe oben, z. B. 99,5 % im Jahresmittel). Falls der Anbieter die Infrastruktur betreibt (SaaS), sind in den SLAs auch Wiederanlaufzeiten nach Disaster, Datensicherungskonzepte usw. enthalten. Zudem kann ein Performance-SLA definiert werden, z. B. durchschnittliche Antwortzeiten unter X Sekunden. Bei Nichteinhaltung kritischer SLAs sollten Vertragsstrafen oder Verlängerungen von Wartungsleistungen vorgesehen werden, um einen Anreiz zur Einhaltung zu schaffen. Wichtig ist, dass SLAs messbar und berichtspflichtig sind: der Anbieter muss also die tatsächliche Verfügbarkeit und Reaktionszeiten messen und dem Kunden regelmäßig (z. B. quartalsweise) nachweisen. Bei SaaS-Betrieb liefert der Anbieter typischerweise eine Status-Seite oder monatliche Reports, die Uptime und Ausfälle dokumentieren. Vereinbarte Wartungsfenster (für Updates, siehe oben) sind ebenfalls Teil der SLAs; Ausfälle innerhalb vereinbarter Wartungsfenster werden nicht als SLA-Verletzung gewertet, sofern sie vorher angekündigt und im Rahmen bleiben.

Oftmals ist es effizient, wenn der Anbieter im Fehlerfall oder für Konfigurationssupport per Remote-Zugriff auf das System zugreifen kann (bei On-Premise-Installation). Die Lastenheft-Anforderungen müssen regeln, unter welchen technischen und sicherheitstechnischen Bedingungen Fernwartung zulässig ist. Technische Voraussetzungen: Der Kunde stellt in Absprache einen gesicherten Zugang bereit, z. B. via VPN oder eine speziell gesicherte Fernwartungssoftware. Der Zugriff sollte zeitlich begrenzt und nur bei Bedarf aktiviert sein (keine ständige offene Verbindung). Sicherheit: Remote-Zugriffe von außen sind besonders kritisch und daher nur unter strikten Auflagen zu gestatten. Der Fernwartungszugang muss mindestens mit starker Authentifizierung geschützt sein (Multi-Faktor-Authentifizierung für den zugreifenden Techniker). Zugriffsrechte sind so zu gestalten, dass der Fernwartungsdienstleister nur auf die notwendigen Systeme und Applikationen Zugriff erhält, nicht auf das gesamte Kundennetz. Idealerweise werden gehärtete Jump-Hosts oder Gateways eingesetzt, die den Zugriff auf definierte Zielsysteme tunnelnd erlauben (z. B. in einer DMZ). Verschlüsselung aller Fernwartungsverbindungen ist Pflicht (VPN-Tunnel mit aktuellen Protokollen, z. B. IPSec oder SSH-basiert). Protokollierung: Alle Remote-Zugriffe müssen vollumfänglich protokolliert werden – wer hat wann was gemacht – und diese Protokolle sind dem Kunden auf Verlangen vorzulegen. Eine Integration ins zentrale SIEM des Kunden (Security Information and Event Management) sollte ermöglicht werden, sodass verdächtige Zugriffe automatisch erkannt werden. Zusätzlich soll ein zentrales Berechtigungsmanagement für Fernwartungszugänge existieren (d.h. der Kunde kontrolliert, wer wann Zugriff erhält). In der Praxis bedeutet dies oft: Der Fernwartende meldet sich beim Kunden an, bittet um Öffnung des Zugangs, führt die Arbeiten durch und meldet sich wieder ab; der gesamte Vorgang wird geloggt. Die Fernwartungssoftware oder VPN-Lösung sollte aktuelle Sicherheitsstandards erfüllen; veraltete oder unsichere Protokolle sind auszuschließen. Auch sollte technisch verhindert werden, dass der Anbieter eigenmächtig Daten abzieht oder verändert, außer im Rahmen der Ticketbearbeitung. Das Lastenheft kann fordern, dass der Anbieter ein Konzept zur Fernwartung vorlegt, in dem all diese Punkte – technische Einbindung, Ablauf, Sicherheit und Auditierung – beschrieben sind.

Ein oft unterschätzter Teil der Softwarepflege ist die laufende Dokumentation und Verwaltung von Konfiguration und Systemänderungen. Der Anbieter ist verpflichtet, änderungsbedingte Anpassungen in den Systemunterlagen nachzuführen. Beispielsweise müssen nach jedem größeren Update oder Konfigurationswechsel die entsprechenden Dokumentationen (Administrationshandbuch, Benutzerleitfäden, Betriebshandbuch) aktualisiert werden, sodass der dokumentierte Stand dem produktiven Stand entspricht. Dies erleichtert nicht nur den laufenden Betrieb, sondern ist auch für Audits und Wissenstransfer essenziell. Darüber hinaus sollte ein Konfigurationsmanagement-Prozess etabliert sein: Alle Konfigurationsparameter, Customizings, Schnittstelleneinstellungen etc. des Systems sind in einer Konfigurationsdatenbank (CMDB) oder ähnlichem festzuhalten. Änderungen an der Konfiguration (z. B. neue Werte, Aktivierung zusätzlicher Module, geänderte Workflow-Regeln) müssen versioniert und protokolliert werden. Dadurch kann jederzeit nachvollzogen werden, welcher Zustand wann galt und wer eine Änderung freigegeben hat. Bei größeren Anpassungen empfiehlt sich die Dokumentation mittels Change Requests, die vom Auftraggeber freigegeben werden. Dieses Vorgehen stellt sicher, dass im Fehlerfall oder bei einem notwendigen Rollback alle Änderungen rückgängig gemacht werden könnten, da der Vorher-Zustand bekannt ist. Bestandteil der kontinuierlichen Pflege ist auch die pflege der Stammdaten und Benutzerrechte: Das System sollte Funktionalitäten mitbringen, um z. B. veraltete Datensätze zu identifizieren oder ungenutzte Benutzerkonten zu deaktivieren (Daten- und Bereinigungspflege). Zudem müssen Konfigurationssicherungen existieren – z. B. Exportmöglichkeiten für Systemeinstellungen oder Konfigurationsfiles – um sie extern zu sichern und bei Bedarf wieder einspielen zu können. Schließlich gehört zur Pflege auch eine regelmäßige Überprüfung des Systems auf Optimierungspotential (Performance-Tuning, Archivierung alter Daten, Reorganisation der Datenbank). Solche Wartungsaufgaben (Re-Indexierung der DB, Bereinigen von Logdateien, Archivieren von historischen Datensätzen gemäß Aufbewahrungsfristen) sind vom Anbieter proaktiv einzuplanen und ggf. automatisiert durchzuführen.

In vielen Fällen nimmt der Kunde kundenspezifische Anpassungen am System vor – z. B. definierte Workflows, zusätzliche Datenfelder, Berichtsvorlagen oder Schnittstellen zu anderen Systemen. Das Lastenheft verlangt, dass die Software so ausgelegt ist, dass Updates und Upgrades trotz dieser Anpassungen möglich sind, ohne dass jedes Mal umfangreiche Reprogrammierungen nötig werden. D. h. Release-Fähigkeit auch bei Customizing: Anpassungen sollten idealerweise konfigurationsbasiert erfolgen (z. B. parametrierbare Workflows, Formulare, Reports), nicht durch Änderungen am Programmcode. Wenn doch Programmierungen für den Kunden erstellt werden (z. B. individuelle Module oder Erweiterungen), müssen diese klar abgegrenzt und dokumentiert sein, sodass sie bei Versionswechseln leicht angepasst werden können. Der Anbieter hat ein Verfahren darzustellen, wie er Kompatibilität sicherstellt – z. B. Prüfung kundenspezifischer Module auf neue Versionen schon im Beta-Stadium, Bereitstellung von Migrationsskripten für angepasste Datenmodelle etc.. Günstig ist, wenn die Software eine Plugin-Architektur besitzt, d. h. Erweiterungen werden als getrennte Module implementiert, die über definierte Schnittstellen andocken – so kann der Kern aktualisiert werden, ohne die Plugins zu brechen. Außerdem soll der Anbieter frühzeitig über geplante Änderungen informieren (Release Notes, Vorankündigungen), damit der Kunde seine spezifischen Workflows darauf prüfen kann. Ggf. können Updates zunächst in einer Testinstanz mit den kundenspezifischen Einstellungen geprüft werden, bevor man sie produktiv einspielt. Zusammengefasst: Maßgeschneiderte Anpassungen dürfen nicht dazu führen, dass man in zukünftigen Versionen auf einem „Abstellgleis“ landet; die Pflege der Software muss upgrade-kompatibel sein.

Die CAFM-Software wird oft in ein Ökosystem von Anwendungen eingebunden (z. B. ERP, HR-System, Gebäudeautomation, IoT-Sensorik, Dokumentenmanagement). Daher ist ein Schwerpunkt der Wartung auch die Schnittstellenpflege. Das System soll offene, standardisierte Schnittstellen bereitstellen (z. B. REST/JSON-APIs, ggf. SOAP/XML Webservices), um den Datenaustausch mit anderen Systemen zu ermöglichen. Dabei sind etablierte Datenformate und Protokolle zu nutzen – z. B. IFC für BIM-Daten, CAFM-Connect oder andere branchenspezifische Standards – um die Interoperabilität zu maximieren. Schnittstellenmonitoring: Es muss Mechanismen geben, die laufenden Datenaustausch überwachen. Falls Datenimporte/-exporte zeitgesteuert laufen, soll das System kontrollieren, ob diese Jobs erfolgreich waren, und bei Fehlern Alarm schlagen. Beispielsweise könnte ein Monitoring feststellen, dass erwartete Daten (etwa ein nächtlicher Import von Personaldaten) ausbleiben oder ein Formatfehler auftritt – in dem Fall muss automatisch eine Meldung an den Betreiber/Support erfolgen. Der Anbieter übernimmt im Rahmen des Wartungsvertrags auch die Fehlerbehebung bei Schnittstellenproblemen: Tritt ein Problem im Datenaustausch auf, ist zeitnah nach der Ursache zu suchen (etwa Änderungen im Partner-System, Netzwerkprobleme, fehlerhafte Daten) und dieses zu beheben, da stockende Schnittstellen oft direkt Geschäftsprozesse beeinträchtigen (z. B. Wartungsaufträge aus ERP kommen nicht ins CAFM). Änderungen an Schnittstellen: Da angebundene Fremdsysteme Updates erhalten können, muss die CAFM-Software darauf vorbereitet sein. Der Anbieter verpflichtet sich, Kompatibilität mit neuen Versionen wichtiger Partner-Software sicherzustellen – z. B. wenn eine neue SAP-Version erscheint, muss der CAFM-Anbieter seine Schnittstelle prüfen und anpassen, sofern notwendig. Solche Abhängigkeiten sind in einer Schnittstellen-Dokumentation festzuhalten (inkl. Versionsständen, Verantwortlichen). Für jede Schnittstelle ist klar zu definieren, wer wartungsverantwortlich ist – etwa betreut der CAFM-Anbieter sein eigenes SAP-Connector-Modul, während für kundenspezifische Middleware-Lösungen evtl. der Kunde oder ein Drittintegrator zuständig ist. Diese Verantwortlichkeiten sollten vertraglich oder in einer Betriebsvereinbarung festgehalten werden (Schnittstellenvertrag). Um Ausfälle zu vermeiden, empfiehlt es sich, Änderungen an Schnittstellen (seitens beider Systeme) gegenseitig früh anzukündigen und in Testsystemen auszuprobieren. Auch hier gilt: Dokumentation aller Schnittstellen inklusive Datenfelder, Mappings, Frequenz und Monitoring-Methodik ist vom Anbieter zu liefern und bei Änderungen zu aktualisieren.

Neben der reaktiven Fehlerbehebung muss der Anbieter eine proaktive Wartung sicherstellen. Dazu gehört regelmäßiges Monitoring der Systemzustände (siehe nächster Abschnitt), aber auch das frühzeitige Identifizieren von Engpässen oder Anomalien. Beispielsweise sollte der Anbieter durch Auswertung der Nutzungsstatistiken erkennen, ob die Systemauslastung an Grenzen stößt und rechtzeitig Hardware-Upgrades oder Optimierungen vorschlagen. Auch die Datenqualität könnte im laufenden Betrieb überwacht werden (z. B. Anteil fehlender oder veralteter Einträge), um gezielte Pflegeaktionen zu initiieren. Wichtig ist zudem, dass der Anbieter über rechtliche Änderungen (z. B. neue Datenschutzvorgaben, Normen im Facility Management) informiert bleibt und die Software entsprechend anpasst oder Updates bereitstellt, damit der Kunde dauerhaft compliant bleibt (siehe regulatorische Anforderungen). Regelmäßige Status-Meetings zwischen Kunde und Anbieter (z. B. quartalsweise Service Review) sind zu etablieren, um die Zufriedenheit mit der Wartung zu besprechen, anstehende Änderungen zu planen und Verbesserungen einzuleiten.

Im Facility Management trägt der Betreiber von Gebäuden eine hohe rechtliche Verantwortung (Betreiberverantwortung) – z. B. für Sicherheit, Arbeitsschutz und Dokumentation von Prüfnachweisen. Ein CAFM-System muss den Auftraggeber dabei unterstützen, diese Pflichten zu erfüllen. Das bedeutet zum einen, dass die IT-Betriebsführung des Systems compliant sein muss (siehe Datenschutz unten), zum anderen, dass die Software Funktionen bieten sollte, um Betreiberpflichten zu dokumentieren (z. B. Wartungsprotokolle, Prüftermine und deren Nachverfolgung – dies jedoch eher im fachlichen Teil des Lastenheftes). Im Kontext Installation/Rollout relevant ist: Wer betreibt das System technisch und wer übernimmt welche Pflichten? Bei SaaS-Modell fungiert der Anbieter als technischer Betreiber des Systems – er muss garantieren, dass alle gesetzlichen IT-Betreiberpflichten (Datenschutz, IT-Sicherheit, Verfügbarkeit) eingehalten werden. Der Kunde bleibt währenddessen Verantwortlicher für die Inhalte und die korrekte Verwendung der Software. Diese Aufteilung ist vertraglich zu regeln, etwa im Rahmen eines AVV-Vertrags (Auftragsverarbeitung nach DSGVO) zwischen Kunde (Auftraggeber, Verantwortlicher) und Anbieter (Auftragsverarbeiter). Bei On-Premise-Betrieb liegt die IT-Betriebsverantwortung beim Kunden selbst; der Anbieter liefert Software und ggf. Support, aber der Kunde muss für Infrastruktur, Backups etc. selbst sorgen oder entsprechende Verträge abschließen. Das Lastenheft kann fordern, dass der Anbieter ein Betriebsmodell vorschlägt, das klare Rollen und Verantwortlichkeiten enthält, damit kein Aspekt unzuständig bleibt (z. B. wer überwacht die Schnittstellen, wer führt Softwareupdates durch, wer reagiert im Notfall).

Die Software und ihr Betrieb müssen datenschutzkonform ausgestaltet sein. Personenbezogene Daten, die im CAFM verarbeitet werden (z. B. Mitarbeiterdaten, Raumbuchungen mit Personenzuordnung, Vertragspartner), sind durch geeignete technische und organisatorische Maßnahmen (TOM) zu schützen. Dazu zählen insbesondere: Zugriffskontrolle (siehe Rechtekonzept oben), Datenverschlüsselung (bei Speicherung und Übertragung), Sicherung und rasche Wiederherstellbarkeit (Backups, Desaster-Vorsorge) sowie regelmäßige Überprüfung der Wirksamkeit dieser Maßnahmen. Die DSGVO fordert „Privacy by Design und by Default“ – also dass datenschutzfreundliche Voreinstellungen getroffen sind und die Software so entwickelt ist, dass nur nötige Daten erhoben und verarbeitet werden. Im Lastenheft kann festgeschrieben werden, dass z. B. Protokollierungen personengebundener Aktivitäten nach einer gewissen Zeit pseudonymisiert oder gelöscht werden müssen, um die Datenminimierung zu wahren. Weiterhin sollte das System Funktionen bieten, um Betroffenenrechte zu unterstützen (Datenexport, Löschung auf Anfrage etc.), wobei dies eher funktionale Anforderungen sind. Für den Betrieb relevant: Wenn der Anbieter als Auftragsverarbeiter fungiert, muss er garantieren, dass er die Daten nur zweckgebunden verarbeitet und z. B. kein unbefugter Zugriff durch Dritte erfolgt. Subunternehmer (z. B. Rechenzentrumsbetreiber) sind offen zu legen und vertraglich auf DSGVO-Konformität zu verpflichten. Zudem sollten Audit-Möglichkeiten bestehen: Der Kunde muss das Recht haben, die Einhaltung der Datenschutzvorgaben beim Anbieter zu prüfen (etwa durch Einsicht in Zertifikate, Prüfberichte oder im Rahmen eines Audits vor Ort). Insbesondere für öffentliche Auftraggeber ist die Einhaltung von Datenschutzgesetzen strikt einzuhalten – ein Datenschutz-Konzept seitens des Anbieters ist wünschenswert.

Alle administrativen und sicherheitsrelevanten Vorgänge im System müssen nachvollziehbar sein. Dazu gehört eine bereits erwähnte umfangreiche Protokollierung (Audit-Trails), die z. B. erfasst: Änderungen an Daten (wer hat was wann geändert), Nutzeranmeldungen und -aktionen, Vergabe von Berechtigungen, Systemereignisse (Server-Start/Stop, Fehler). Diese Protokolle sollen in einer Weise geführt werden, dass sie bei internen oder externen Audits ausgewertet werden können. Idealerweise verfügt die Software über Audit-Reports oder Exportfunktionen, um Prüfern bestimmte Verlaufsdaten bereitzustellen. Revisionssicherheit ist hier das Stichwort: Wichtige Daten (z. B. historische Zustände von Prüfungen oder Wartungsnachweisen) sollen nicht unbemerkt gelöscht oder manipuliert werden können. Ggf. sind protokollierende Datenbanken oder Write-Once-Read-Many-Speicher (WORM) für bestimmte Logs zu verwenden, wenn dies gefordert ist. Das Lastenheft sollte definieren, wie lange welche Protokolle aufbewahrt werden müssen (z. B. Benutzerlogin-Historie 1 Jahr, Änderung an Stammdaten 10 Jahre oder gemäß GoBD bei relevanten Daten). Die Software muss mindestens ermöglichen, diese Daten entsprechend zu archivieren und wieder lesbar zu machen. Zudem sollen Prozesse für reguläre Audits definiert sein: z. B. jährliche Berechtigungsreviews (Überprüfung, ob alle Benutzer noch die passenden Rechte haben) – hier sollte die Software entsprechende Übersichten generieren können, wer welche Rolle besitzt. Ebenfalls muss der Betrieb auditfähig sein, d. h. der Anbieter führt selbst regelmäßige Sicherheitsaudits durch (oder externe Prüfungen wie ISO-Zertifizierungen) und teilt auf Anfrage die Ergebnisse bzw. Zertifikate mit. Insbesondere ISO 27001 fordert dokumentierte Prozesse und Nachweise, die einem Auditor vorgelegt werden können, um Einheitlichkeit und Wirksamkeit der Betriebsprozesse zu belegen. Solche Standards sollte der Anbieter erfüllen oder zumindest zum Ziel haben, um Vertrauen in die Betriebsführung zu geben.

Wie bereits unter „Security“ gefordert, ist ein feingranulares Rechtemanagement unabdingbar. Hier im regulatorischen Kontext sei betont: Das System muss es ermöglichen, personenbezogene Daten nur berechtigten Rollen zugänglich zu machen. Beispielsweise sollten nur bestimmte Rollen (z. B. Administratoren oder Vorgesetzte) Personaldaten sehen können, während ein normaler Benutzer vielleicht nur technische Objektdaten sieht. Rollen und Rechte müssen konfigurierbar sein, um auf die Organisationsstruktur angepasst zu werden. Es sollte vordefinierte Standardrollen geben, die die typischen FM-Prozesse abbilden (z. B. Meldungs-Ersteller, Disponent, Techniker, Berichtsleser), und die Möglichkeit, diese anzupassen oder neue Rollen zu kreieren. Jede Aktion im System sollte grundsätzlich einem Berechtigungsprüfungsmechanismus unterliegen. Darüber hinaus ist die Integration in bestehende Identity-Management-Lösungen des Auftraggebers gefordert. Das heißt, wenn der Kunde ein zentrales Nutzerverzeichnis hat (Active Directory, Azure AD etc.), soll die CAFM-Software dieses verwenden können, um Benutzer zu authentifizieren (z. B. via LDAP-Bind oder SAML-basiertes Single Sign-On). Dies erleichtert die Benutzerverwaltung enorm – neue Mitarbeiter werden automatisch ins System übernommen, ausgeschiedene Mitarbeiter verlieren sofort den Zugriff, wenn ihr zentraler Account deaktiviert wird. Ferner reduziert es Sicherheitsrisiken (weniger separate Passwörter) und erhöht den Komfort. Das Lastenheft sollte zudem angeben, ob eine Automatisierung bei der Berechtigungsverwaltung gewünscht ist – z. B. Zuordnung von Rollen basierend auf Abteilung/Funktion des Nutzers. Wichtig: Das System muss konsistente Administrationswerkzeuge für die Rechteverwaltung bereitstellen, idealerweise inkl. Audit-Funktionen (wer hat wann wem eine Rolle zugewiesen). Bei Mandantenbetrieb muss auch sichergestellt sein, dass Rechte nur innerhalb des Mandanten wirken und kein unbefugter Zugriff mandantenübergreifend möglich ist. Falls gewünscht, kann eine Integration in Identity- und Access-Management-(IAM)-Systeme verlangt werden, sodass z. B. Rezertifizierungen oder Provisionierungsprozesse über das zentrale IAM durchgeführt werden können.

Für einen professionellen Betrieb sind Monitoring und Logging essenziell. Der Systemzustand (Serverressourcen, Diensteverfügbarkeit, Antwortzeiten der Anwendung) soll kontinuierlich überwacht werden. Dazu sollte die Software bzw. der Betreiber Monitoring-Schnittstellen bereitstellen – etwa Metriken via SNMP, Web-APIs für Health-Checks oder integrierte Dashboard-Anzeigen. Ein Monitoring-System (z. B. Nagios, Zabbix, CloudWatch) kann so angebunden werden, um rund um die Uhr kritische Parameter zu prüfen. Beispiele: Prüfung, ob der Webservice erreichbar ist (Heartbeat), ob die durchschnittliche Antwortzeit einen Schwellenwert überschreitet, ob CPU-/Speicherauslastung kritisch wird. Bei Auffälligkeiten oder Ausfällen müssen automatisch Alerts generiert werden (z. B. E-Mail/SMS an den Administrator), damit zeitnah eingegriffen werden kann. Zusätzlich zum technischen Monitoring soll auch ein Geschäftsprozess-Monitoring greifen – beispielsweise Überwachung der Schnittstellenjobs (wie oben erwähnt) oder Zählen offener Vorgänge, um Stau festzustellen. Alle Logfiles der Anwendung und Infrastruktur sind zentral zu sammeln und auszuwerten (z. B. mittels eines SIEM oder Logging-Servers), um Trends zu erkennen und im Fehlerfall schnell Diagnose betreiben zu können. Das Logging muss dabei datenschutzkonform gestaltet sein – persönliche Daten in Logs sind möglichst zu vermeiden oder zu pseudonymisieren, und es sind Aufbewahrungsfristen für Logdaten festzulegen. Beispielsweise könnte das Konzept vorsehen: detaillierte Logs 6 Monate online verfügbar, danach ins Archiv; Protokolle mit personenbezogenen Bezügen werden nach X Monaten anonymisiert oder gelöscht. Wichtig ist die Protokollarchivierung insbesondere für sicherheitsrelevante Logs: Zugriffsprotokolle oder Änderungen an Objekten könnten für Compliance-Zwecke über mehrere Jahre vorgehalten werden müssen. Das System bzw. der Betreiber muss Mittel bieten, diese langfristige Archivierung sicherzustellen (z. B. Log-Export in revisionssicheres Format, um es in ein Archivsystem zu überführen). Des Weiteren soll das Monitoring auch die SLA-Einhaltung überprüfen (siehe SLA-Monitoring oben) – etwa automatisiertes Messen der Verfügbarkeit und Taktung von Reports darüber. Berichte und Protokolle: Der Anbieter sollte dem Kunden regelmäßig Betriebsberichte liefern, die u. a. enthalten: Systemverfügbarkeit, Performance-Metriken, Anzahl der Incidents, SLA-Verletzungen und ergriffene Maßnahmen. Diese unterstützen den Kunden dabei, die Einhaltung der vertraglichen Anforderungen nachzuvollziehen. Zusätzlich muss der Betrieb auf Notfälle vorbereitet sein – ein Monitoring-Alarm sollte im Zweifel ein Incident auslösen (Verzahnung Event Management mit Incident Management). Zusammengefasst sorgen Monitoring und Logging dafür, dass Probleme frühzeitig erkannt, effizient behoben und dokumentiert werden. Dies trägt wesentlich zur Betriebssicherheit und Transparenz bei.

Aufbauend auf den technischen Grundlagen sollen konkrete Betriebsvorgaben formuliert werden. Für die Verfügbarkeit wird – wie oben – ein Zielwert vorgegeben (z. B. 99,5 % per annum). Wichtig ist, diesen Wert zu definieren und ausgenommenen Zeiten (Wartungsfenster) festzulegen, damit Klarheit besteht. Eventuell möchte der Auftraggeber auch Höchstgrenzen für geplante Wartungszeiten angeben (z. B. max. 2 Stunden Wartung pro Monat, nur außerhalb 18-6 Uhr). Performance-Vorgaben: Das System sollte unter Last X folgende Reaktionszeiten einhalten: z. B. Anzeige eines Objektdetails max. 2 Sek., Abschluss einer Wartungsplanung max. 5 Sek., paralleler Zugriff von 100 Nutzern ohne spürbare Verlangsamung. Solche Werte sind exemplarisch zu definieren, idealerweise basierend auf den späteren SLAs oder Erfahrungswerten. Lasttests in der Abnahme (siehe oben) werden diese Parameter prüfen. Sollte es spezifische Peak-Zeiten geben (z. B. Jahresabschluss, Inventurzeiten), muss das System dafür ausgelegt sein oder der Anbieter temporär zusätzliche Ressourcen bereitstellen. Wartungsfenster im Betrieb sind vorab gemeinsam festzulegen – z. B. regelmäßige Wartung jeden ersten Samstag im Monat 20-24 Uhr – und planbare Arbeiten sollen dort gebündelt werden. Außerhalb dieser Fenster sollte das System im Normalfall unterbrechungsfrei verfügbar sein; eine unbeabsichtigte Downtime wird als Incident gehandhabt. Falls gewisse Batch-Prozesse (z. B. tägliche Datensicherung oder nächtliche Reports) Laufzeit beanspruchen, dürfen diese die Interaktion der Nutzer nicht wesentlich beeinträchtigen (z. B. nur geringe Priorität im DB-System oder Ausführung in Off-Peak Hours). Skalierungsreserven: Der Anbieter soll im Betrieb stets eine gewisse Reserve an Leistung vorhalten, damit auch unvorhergesehene Lastspitzen oder zukünftige Erweiterungen aufgefangen werden können. Überstiege die Auslastung definierte Schwellwerte, muss proaktiv reagiert werden (siehe Kapazitätsmanagement oben). Fehlertoleranz: Die betrieblichen Anforderungen umfassen auch, dass kleine Störungen (wie Ausfall eines einzelnen Servers im Cluster) vom System selbstkorrigierend aufgefangen werden, sodass die Nutzer möglichst nichts bemerken. Zusammengefasst wird erwartet, dass der Anbieter einen Betrieb sicherstellt, der den Anforderungen an Kontinuität, Leistung und Transparenz genügt, wie es bei geschäftskritischen Anwendungen nötig ist.

Im Folgenden werden die Anforderungen aus den Abschnitten 1–4 in Muss-, Soll- und Kann-Kriterien unterteilt und jeweils prüfbar formuliert. Zu jeder Anforderung ist mindestens eine Abnahmeprüfung angegeben, anhand derer festgestellt werden kann, ob die Bedingung erfüllt ist.

• Plattform-Bereitstellung und Installation: Die CAFM-Software muss sowohl On-Premise installierbar sein (auf Standard-Hardware/VM unter Windows oder Linux) als auch als SaaS-Angebot verfügbar sein. Abnahmeprüfung: Prüfung der Angebotsdokumentation und eines Testaufbaus – der Anbieter weist nach, dass ein Installationspaket für On-Premise existiert (z. B. durch Installation auf einer bereitgestellten VM) und alternativ ein Cloud-Dienst zur Verfügung steht (Vorzeigen eines Web-Zugangs zur SaaS-Instanz). Außerdem wird überprüft, ob eine Datenhaltung in der EU im Fall SaaS vertraglich zugesichert ist.

• Datenbankunterstützung: Die Software muss mit mindestens einem gängigen relationalen Datenbankmanagementsystem (z. B. MS SQL, Oracle oder PostgreSQL) kompatibel sein. Abnahmeprüfung: Überprüfung der Herstellerdokumentation und Konfigurationsoberfläche – es wird kontrolliert, ob in den Systemvoraussetzungen mindestens eine genannte Standard-Datenbank aufgeführt ist und ob in einer Testinstallation die Anbindung an dieses DBMS funktioniert (z. B. Test der Verbindung und Anlage von Beispieldaten).

• Rechte- und Rollenkonzept: Das System muss ein rollenbasiertes Berechtigungskonzept implementieren, das differenzierte Zugriffsrechte ermöglicht. Abnahmeprüfung: In der Testumgebung werden mehrere Benutzer mit unterschiedlichen Rollen angelegt (z. B. Administrator, normaler Nutzer). Anschließend wird versucht, auf Funktionen/Daten zuzugreifen, die laut Rechtekonzept jeweils nicht freigegeben sein dürften (z. B. Normalnutzer versucht Admin-Funktion). Es muss bestätigt werden, dass der Zugriff verweigert wird. Zudem wird geprüft, dass neue Rollen angelegt und Berechtigungen konfiguriert werden können (z. B. über eine Admin-Oberfläche).

• Verschlüsselung: Sämtliche Kommunikation zwischen Client und Server muss per TLS verschlüsselt erfolgen; gespeicherte personenbezogene oder sicherheitsrelevante Daten müssen verschlüsselt oder durch Zugriffsmechanismen geschützt sein. Abnahmeprüfung: Durch einen Netzwerkmitschnitt (z. B. mittels Wireshark) beim Anmeldevorgang wird verifiziert, dass keine Passwörter oder Klartextdaten unverschlüsselt übertragen werden. Außerdem wird ein Blick in die Datenbank bzw. Konfigurationsdateien genommen, um sicherzustellen, dass z. B. Passwörter nur gehasht gespeichert sind und ggf. Datenbankverschlüsselung aktiv ist (Nachweis über DB-Parameter oder Dokumentation).

• Logging und Audit-Trail: Die Software muss wichtige Benutzeraktionen und Änderungen protokollieren (mindestens: Login, Logout, Datenerstellung/-änderung/-löschung mit Benutzer und Zeitstempel). Abnahmeprüfung: Es wird im System ein Datensatz erstellt und geändert, anschließend wird das Audit-Log oder Änderungsprotokoll exportiert. Die Einträge müssen die durchgeführten Aktionen mit korrektem Zeitstempel und Benutzer erkennen lassen. Zudem wird geprüft, dass Logs nicht vom Endanwender manipulierbar sind (z. B. sind sie nur mit Admin-Rechten einsehbar, schreibgeschützt).

• Backup und Restore: Es muss ein regelmäßiges Backup-Verfahren implementiert sein, und eine Wiederherstellung muss innerhalb eines vordefinierten Zeitfensters (RTO) möglich sein. Abnahmeprüfung: Einsicht in das Backup-Konzept – es wird nachgewiesen, dass Backup-Jobs eingerichtet sind (z. B. tägliche Sicherung um 2 Uhr nachts, inkl. Protokoll der letzten Sicherung). Anschließend wird zusammen mit dem Anbieter ein Restore-Test durchgeführt: eine gesicherte Datenbank wird in einer Testumgebung zurückgespielt. Die Wiederherstellung darf die geforderte RTO (z. B. 4 Stunden) nicht überschreiten und die Daten müssen konsistent vorliegen (Integritätsprüfung, Stichproben auf wiederhergestellte Datensätze).

• Hochverfügbarkeit: Die Systemarchitektur muss hochverfügbar ausgelegt sein, sodass ein einzelner Komponentenausfall nicht zum Gesamtausfall führt. Abnahmeprüfung: Architekturprüfung und Stresstest – der Anbieter legt Systemdiagramme vor, die Redundanzen zeigen (z. B. Cluster, Failover-Mechanismen). In einem Probelauf wird z. B. ein Applikationsserver-Dienst manuell gestoppt, und es wird beobachtet, ob Nutzer automatisch auf einen zweiten Knoten umgeleitet werden bzw. das System weiterläuft. Ebenso kann ein Datenbank-Failover simuliert werden, sofern Cluster vorhanden. Die Anwendung muss für die Endanwender ohne Unterbrechung oder mit sehr kurzer Unterbrechung weiter nutzbar sein (im Rahmen der vereinbarten 99,5/99,9 %-Verfügbarkeit).

• SLA-Reaktionszeiten: Der Anbieter muss vertraglich garantieren, dass im Fehlerfall festgelegte Reaktionszeiten eingehalten werden (z. B. P1 innerhalb 1 Stunde). Abnahmeprüfung: Sichtung des Vertragsentwurfs/Wartungsvertrags – es ist explizit geregelt, welche Reaktions- und Behebungszeiten für definierte Prioritäten gelten. Zusätzlich wird ein Test-incident im Ticketsystem eingestellt (Kategorie „hoch“); es wird protokolliert, wann eine Reaktion des Supports erfolgt. Diese Zeit muss der SLA-Vorgabe entsprechen (im Test toleriert man leichte Abweichungen, aber der Prozess der Überwachung wird so nachvollzogen). Außerdem wird geprüft, dass das Ticketsystem solche Zeiten erfasst, um später die Einhaltung nachzuweisen.

• Ticketsystem und Incident-Dokumentation: Es muss ein Ticketing-System vorhanden sein, in dem alle Störungen erfasst und deren Status verfolgt werden können. Abnahmeprüfung: Es wird ein Test-Zugang zum Ticketsystem des Anbieters angefordert. Ein Probe-Ticket wird erstellt und an den Support übermittelt. Es wird verifiziert, dass das Ticket eine eindeutige ID erhält, der Status änderbar ist (offen/in Bearbeitung/geschlossen) und Kommentare/Aktualisierungen durch Support sichtbar sind. Ferner wird geprüft, ob das System Zeitstempel und Bearbeiter protokolliert. Optional kann der Anbieter einen Bericht exportieren, um zu demonstrieren, dass Statistiken über Tickets geführt werden (Anzahl pro Monat, durchschnittliche Lösungszeit etc.).

• Fernwartungssicherheit: Remote-Zugriffe des Anbieters müssen nur über gesicherte Wege (VPN/verschlüsselte Verbindung) und mit Zustimmung des Kunden erfolgen, alle Aktivitäten müssen lückenlos protokolliert werden. Abnahmeprüfung: Sichtung des Fernwartungskonzepts – es wird geprüft, dass MFA, VPN und Rollenbegrenzung vorgesehen sind. Dann wird ein Live-Test durchgeführt: der Anbieter verbindet sich via der vereinbarten Fernwartungslösung auf das System. Ein Sicherheitsverantwortlicher des Kunden überwacht z. B. via Log-Viewer die entstehenden Protokolleinträge. Am Ende der Sitzung wird kontrolliert, ob ein Protokoll (Logfile) existiert, in dem Start/Ende der Sitzung und ausgeführte administrative Aktionen verzeichnet sind. Außerdem wird getestet, dass der Zugang tatsächlich nur bei Aktivierung möglich ist (z. B. VPN wird nach Sitzungsende wieder geschlossen).

• Datenschutz und DSGVO-Konformität: Die Lösung muss alle Anforderungen der DSGVO an technische und organisatorische Maßnahmen erfüllen (z. B. Datensparsamkeit, sichere Verarbeitung, Löschkonzepte). Abnahmeprüfung: Einsicht in Datenschutz-Konzept und Audit: der Anbieter legt ein Dokument vor, wie er DSGVO umsetzt (z. B. TOM-Liste, ggf. ISO 27001 Zertifikat als Nachweis). Es wird stichprobenartig geprüft, ob Funktionen zum Löschen/Anonymisieren personenbezogener Daten vorhanden sind (z. B. Löschen eines Nutzers -> personenbezogene Daten nicht mehr einsehbar). Ebenso wird kontrolliert, ob Auftragsverarbeitung vertraglich geregelt ist. Falls möglich, wird ein Probelauf zur Datenexportierung gemäß Art. 15 DSGVO gemacht (z. B. Personendaten aus dem System extrahieren), um sicherzustellen, dass solche Anforderungen erfüllbar sind.

• Monitoring und Alarmierung: Es muss ein Monitoring der Systemverfügbarkeit und -leistung eingerichtet sein, inklusive automatischer Alarmierung bei Ausfall oder Überschreiten kritischer Schwellen. Abnahmeprüfung: Der Anbieter demonstriert in der Betriebsumgebung ein aktives Monitoring-Dashboard oder Test-Alarm. Beispielsweise wird der CAFM-Service kurz angehalten; binnen der definierten Reaktionszeit sollte ein Alarm (E-Mail/SMS) an den Support/Admin gesendet werden. Zudem wird Einsicht in Monitoring-Regeln genommen: es sollen Metriken wie CPU, RAM, Antwortzeit überwacht werden. Die Prüfer validieren, dass Grenzwerte definiert sind und bei deren Verletzung Einträge im Monitoring erscheinen.

• Verfügbarkeit und Performance im Betrieb: Die Software muss die geforderte Verfügbarkeit (z. B. >=99,5 %) und definierte Performancewerte erreichen. Abnahmeprüfung: Überwachung der Produktion (bzw. in einem Stresstest in der Abnahmeumgebung): Mit geeigneten Test-Tools wird eine simulierte Last erzeugt (z. B. 100 gleichzeitige Nutzer führen typische Aktionen durch). Dabei werden die Antwortzeiten gemessen – sie dürfen die im Lastenheft vorgegebenen Grenzwerte nicht überschreiten. Außerdem wird (später im Produktivbetrieb oder im Stabilisierungsmonat) ein Verfügbarkeitsreport eingefordert. Dieser Report muss mindestens 30 Tage Laufzeit abdecken und zeigen, dass die Uptime im Soll-Korridor liegt. Bei Abweichungen wird nach Ursachenanalyse gefragt. Ebenso wird geprüft, dass geplante Wartungsfenster eingehalten und vorher angekündigt wurden (Nachweis z. B. durch Ankündigungs-E-Mails an Nutzer oder Protokoll im Change-Kalender).

• Zero-Downtime Updates: Das System sollte Updates und Patches ohne Downtime einspielen können (Rolling Update, Blue-Green-Deployment). Abnahmeprüfung: Sichtung der Update-Dokumentation – es wird dargelegt, welche Mechanismen genutzt werden (z. B. schrittweises Hochfahren neuer Version parallel zur alten). In einem Test wird ein Minor-Update in der Cluster-Testumgebung durchgeführt, während simulierte Benutzer weiterarbeiten. Es wird beobachtet, ob Benutzer die Aktualisierung ohne Unterbrechung überstehen (z. B. Session bleibt gültig, keine Fehlermeldungen). Bei Erfolg wird das als erfüllt gewertet; bei leichter Beeinträchtigung (kurzer Reload) wird teilweise Erfüllung angenommen.

• Containerisierung und Cloud-Portabilität: Die Anwendung sollte containerisierbar sein (Docker-Image oder Kubernetes-Helm Charts verfügbar) für eine moderne Deployment-Option. Abnahmeprüfung: Der Anbieter liefert ein Container-Image oder Dockerfile. In einem Test orchestriert der Auftraggeber dieses Image auf einer Container-Plattform (z. B. lokal mit Docker). Startet der Container fehlerfrei und ist der Dienst erreichbar, gilt das Kriterium als erfüllt. Bonus: Ist sogar eine Kubernetes-Bereitstellung dokumentiert (Skalierung, Self-Healing), wird dies besonders positiv bewertet.

• Mehrsprachigkeit und Internationalisierung: Die Software sollte mehrsprachig nutzbar sein (insb. Deutsch und Englisch). Abnahmeprüfung: In der Testumgebung wird die Sprache umgestellt (sofern Option vorhanden) oder ein Benutzer mit anderem Sprachprofil angelegt. Die Oberfläche sollte konsistent in der gewählten Sprache erscheinen. Mindestens die Nutzeroberfläche muss Deutsch beherrschen; die Verfügbarkeit weiterer Sprachen (Englisch, ggf. Französisch) wird geprüft durch Ansicht zentraler Module in jener Sprache.

• Konfigurierbarkeit statt Programmierung: Kundenanforderungen sollten vorzugsweise durch Konfiguration statt durch Individualprogrammierung umgesetzt werden können (Workflows, Formulare, Felder anpassbar ohne Code). Abnahmeprüfung: Admin-Schulung/Workshop – es wird gezeigt, wie ein beispielhafter neuer Datenattribut oder ein einfacher Workflow (z. B. Genehmigungsprozess für eine Raumbuchung) im System eingerichtet werden kann, ohne Quellcode anzupassen. Gelingt dies mit Bordmitteln (Konfigurationsmenüs, Customizing-Tools), wird die Anforderung erfüllt. Müssen hingegen Entwickler eingreifen, ist dies Punktabzug.

• Reporting und Auswertungen: Das System sollte ein integriertes Berichtswerkzeug mitliefern, mit dem der Kunde eigenständig Berichte/Layouts erstellen kann. Abnahmeprüfung: Demonstration im Testsystem – ein einfacher Bericht (z. B. Flächenliste je Gebäude) wird ad-hoc erstellt bzw. ein bestehender Bericht angepasst (Logo ändern, Spalte hinzufügen). Der Kunde bewertet, ob dies ohne tiefere technische Kenntnisse möglich war.

• Self-Service & Knowledge Base: Der Anbieter sollte dem Kunden ein Self-Service-Portal oder Wissensdatenbank zur Verfügung stellen, in dem häufige Fragen, Dokumentationen und evtl. Community-Austausch möglich sind. Abnahmeprüfung: Zugang testen – der Anbieter zeigt sein Kundenportal, die Prüfer suchen nach einem konkreten Artikel (z. B. „Wie erstelle ich einen neuen Benutzer?“). Finden sie aktuelle, hilfreiche Informationen, gilt das als Pluspunkt.

• Mobile Unterstützung: Die Lösung sollte mobil (Smartphone/Tablet) nutzbar sein, entweder via responsivem Webdesign oder nativer App, damit Techniker im Feld arbeiten können. Abnahmeprüfung: Test auf mobilen Endgeräten – mit einem Tablet/Handy wird versucht, auf die Anwendung zuzugreifen (bzw. eine bereitgestellte App zu installieren). Ist die Bedienung möglich und die wichtigsten Funktionen klappen (z. B. Störmeldung aufnehmen mit Foto), wird die Soll-Anforderung als erfüllt gewertet.

• Performance-Reserve & Skalierung: Die Software sollte so skalierbar sein, dass auch bei Verdopplung der Nutzerzahl keine Neukonzeption nötig ist – Reserven für 100 % Lastanstieg. Abnahmeprüfung: Kapazitätsbewertung – anhand der gelieferten Performance-Tests und Systemmetriken wird hochgerechnet, ob noch Puffer bestehen. Z. B. wenn CPU-Auslastung im Test bei 50 % lag für 100 User, kann man auf 200 User extrapolieren. Falls schon im Test >80 % Auslastung erreicht wurde, ist das Kriterium nicht erfüllt. Idealerweise legt der Anbieter einen Skalierungsplan vor (wie würde man mehr Nutzer oder Daten handhaben, z. B. zusätzliche Server).

• Schnittstellen-Standards: Externe Schnittstellen sollten auf offenen Standards basieren (z. B. REST API mit JSON, IFC für Gebäudedaten). Abnahmeprüfung: Durchsicht der Schnittstellendokumentation – es wird erwartet, dass die API-Dokumentation z. B. REST-Endpunkte aufführt oder Datenformate wie IFC/XML beschrieben sind. Wenn proprietäre Formate entdeckt werden, wird dies als Schwäche gesehen. Günstig ist auch ein Live-Test: Aufruf einer beispielhaften REST-API (z. B. GET /api/v1/raeume) mit einem API-Client und Prüfen der Response auf Plausibilität.

• Mandanten-Trennung: Bei mandantenfähiger Nutzung sollte es möglich sein, Mandanten-spezifische Einstellungen (Logos, Texte, Nummernkreise) vorzunehmen, ohne Quellcode-Anpassung. Abnahmeprüfung: In einer Multi-Tenant-Testinstanz (oder simuliert durch Mandantenparameter) werden z. B. unterschiedliche Briefköpfe für zwei Mandanten konfiguriert. Dann wird in beiden Mandanten ein Report erzeugt, der jeweils das korrekte Logo/Bezeichnung enthält. Gelingt dies per Konfiguration, ist das Soll erfüllt.

• Erweiterte Hochverfügbarkeit: Die Architektur kann eine geografisch verteilte Redundanz unterstützen (z. B. aktives Zweitrechenzentrum), um auch Standortausfälle zu überstehen. Abnahmeprüfung: Anbieter-Beschreibung – der Anbieter erläutert, ob und wie ein Geo-Redundanz-Szenario umgesetzt werden könnte (etwa via Cloud Availability Zones). Falls nachweisbar (z. B. existierende Referenzinstallation), wird dies als Bonus berücksichtigt.

• Blue-Green-Deployment für Updates: Neben der Muss-Forderung eines nahezu unterbrechungsfreien Updates, kann das System vollständig Blue-Green-Deployment unterstützen, bei dem eine parallele Umgebung aktualisiert und dann umgeschaltet wird. Abnahmeprüfung: Der Anbieter zeigt konzeptionell, dass seine Update-Architektur dies hergibt (z. B. separate Staging-Umgebung, Umschaltung des DNS oder Load-Balancers). Ein Live-Test ist hier evtl. nicht praktikabel, aber vorhandene Automatismen (Container-Orchestrierung, Scripts) werden positiv bewertet.

• Automatisierte Skalierung (Auto-Scaling): In einer Cloud-Umgebung kann die Software automatisiert Instanzen hinzufügen oder entfernen, um dynamisch auf Last zu reagieren. Abnahmeprüfung: Demonstration in Testumgebung – Simulation hoher Last und Beobachtung, ob z. B. Kubernetes oder Autoscaling-Groups in der Cloud eine weitere Instanz starten. Wenn ja, wird überprüft, ob die Last dann verteilt wird und nach Abflauen wieder reduziert. Nicht vorhandenes Auto-Scaling führt nicht zum Ausschluss, wäre aber ein Mehrwert.

• SIEM-Integration: Das System kann eine direkte Anbindung an ein zentrales Security Information and Event Management (SIEM) des Kunden ermöglichen, um sicherheitsrelevante Ereignisse zu korrelieren. Abnahmeprüfung: Rücksprache mit der IT-Sicherheitsabteilung – es wird evaluiert, ob Logs im syslog-Format oder via Connector an das bestehende SIEM geschickt werden können. Ein Test könnte sein, einen sicherheitsrelevanten Event (z. B. falsches Login mehrfach) zu erzeugen und zu prüfen, ob dieser im SIEM auftaucht.

• Benutzer-Selbstverwaltung: Es kann Funktionen geben, mit denen Endbenutzer einfache Aufgaben selbst erledigen (Self-Service), z. B. Passwort zurücksetzen, FAQ im Tool, Status von gemeldeten Tickets einsehen. Abnahmeprüfung: Im Test wird versucht, das Benutzerpasswort ohne Admin-Eingriff zurückzusetzen (z. B. „Passwort vergessen“-Funktion) und es wird geprüft, ob Endnutzer ihren gemeldeten Instandhaltungsaufträgen folgen können (Ticketstatus einsehen). Vorhandene Self-Service-Portale fließen positiv in die Bewertung ein.

• Offline-Fähigkeit: Die mobile App kann offlinefähig sein, sodass Arbeiten auch ohne Netz und späterer Sync möglich sind. Abnahmeprüfung: Im Feldtest wird die Verbindung gekappt und der Techniker führt eine Wartung via Tablet durch. Die Daten werden lokal erfasst. Sobald wieder Netzwerk verfügbar ist, wird synchronisiert. Wenn der Datensatz danach im System erscheint, ist diese Kann-Forderung erfüllt.

• Big Data / IoT-Integration: Die Plattform kann große IoT-Datenmengen in Big-Data-Strukturen auslagern und in Echtzeit verarbeiten (für z. B. Sensorströme). Abnahmeprüfung: Dies wird anhand der Architektur bewertet – ist z. B. eine Kafka/Pulsar-Integration oder Time-Series-Datenbank vorgesehen? Konkrete Tests sind komplex, aber Referenzaussagen (z. B. „kann 10k Sensordaten pro Minute speichern“) werden als Indikator genommen.

• Zertifizierungen und Standards: Als Kann-Kriterium wird bewertet, ob der Anbieter und das Produkt zertifiziert sind (z. B. ISO 27001, ISO 9001, GEFMA 444 Zertifikat für CAFM-Software). Abnahmeprüfung: Vorlage gültiger Zertifikate. Diese geben zusätzliche Sicherheit, sind aber nicht zwingend vorgeschrieben im Lastenheft. Ein GEFMA-444-Zertifikat würde z. B. bestätigen, dass die Software branchenspezifische Anforderungen erfüllt.

• Nachhaltigkeitsaspekte: Optional kann der Anbieter darstellen, wie der Betrieb ökologisch nachhaltig gestaltet wird (Stromverbrauch, Green IT) – kein Muss, aber Bonus. Abnahmeprüfung: Einsicht in Rechenzentrumszertifikate (z. B. klimaneutrales RZ) oder Energiekonzepte. Wird informatorisch gewertet.

Die Muss-Kriterien sind bindend und führen bei Nichterfüllung zum Ausschluss, während Soll-Kriterien die Leistungsqualität bewerten und Kann-Kriterien zusätzliche Funktionen honorieren. Alle Anforderungen wurden so formuliert, dass sie prüfbar sind; die beschriebenen Abnahmeprüfungen dienen dem Auftraggeber als Leitfaden, wie die Erfüllung im Zuge der Systemabnahme oder Angebotsbewertung verifiziert werden kann. Dadurch wird sichergestellt, dass das fertig eingeführte CAFM-System den hier definierten Anforderungen an Installation, Roll-Out, Wartung und Pflege vollumfänglich entspricht und im laufenden Betrieb sowohl technisch stabil als auch compliant und zukunftsfähig ist.