CAFM-System: Datenhaltung und Datenbankmanagementsystem

• Objektorientierte Dateninterpretation: Die Anwendung muss an der Benutzeroberfläche eine objektorientierte Darstellung der Daten bieten. Facility-Management-Entitäten wie Gebäude, Flächen, Anlagen, Räume, Verträge etc. werden dem Nutzer als eindeutige Objekte mit ihren jeweiligen Eigenschaften und Beziehungen präsentiert – nicht lediglich als isolierte Tabellen oder Datensätze. Dies ermöglicht eine intuitive Bedienung, da die Daten die reale Struktur (z. B. Gebäudehierarchie oder Anlagenstruktur) widerspiegeln.

• Metamodell-gestützte Objektstruktur: CAFM-Objekte sind über ein Metamodell hierarchisch und relational organisiert. Typische Strukturen (z. B. Gebäudegliederung von Liegenschaft > Gebäude > Etage > Raum, Anlagen- und Inventarhierarchien, Zuordnung von Nutzungsobjekten zu Flächen usw.) müssen im Datenmodell abgebildet werden und im System navigierbar sein. Der Zugriff auf Daten erfolgt über diese fachlichen Strukturen, was eine flexible Auswertung entlang der Objektbeziehungen erlaubt.

• Historisierbare und versionierbare Daten: Das System muss historisierbare bzw. versionierbare Datenstrukturen unterstützen. Änderungen an wichtigen CAFM-Daten (etwa an Flächengrößen, Vertragsinhalten, Wartungsständen oder Begehungsprotokollen) sollen mit Zeitstempel als neue Versionen gespeichert werden, statt alte Werte zu überschreiben. Dadurch bleibt die Historie nachvollziehbar und es kann zu beliebigen Stichtagen der vergangene Zustand eines Objekts oder Datensatzes abgerufen werden. Dies ist insbesondere für Auswertungen über Zeiträume und für Audit-Zwecke erforderlich.

• Logische Mandantentrennung: Das System muss mehrere Mandanten in einer gemeinsamen Systemumgebung verwalten können. Dies beinhaltet eine logische Trennung der Daten je Mandant, während zentrale Stammdaten (wie z. B. Kataloge, Objektklassifikationen oder Benutzerrollen) mandantenübergreifend nutzbar sind. Jeder Mandant (z. B. unterschiedliche Tochterunternehmen, Bereiche oder Kunden in einer SaaS-Umgebung) arbeitet in der Anwendung mit eigenen Daten, sieht jedoch nur die für ihn bestimmten Datensätze.

• Datenschutz je Mandant: Für jeden Mandanten muss sichergestellt sein, dass sensible Daten nur für berechtigte Nutzer dieses Mandanten sichtbar sind. Es darf keine unautorisierte Sichtbarkeit oder Zugriff auf mandantenfremde Daten geben. Zugriffsrechte und Sichtbarkeiten sind so zu gestalten, dass ein Benutzer ausschließlich auf die Daten seines eigenen Mandanten zugreifen kann. Damit wird Vertraulichkeit zwischen Mandanten gewährleistet, selbst wenn diese die gleiche physische Datenbank nutzen.

• Optional: Technische Trennung von Mandanten: Falls aus Sicherheits- oder Performance-Gründen erforderlich, sollte das System alternativ eine technische Mandantentrennung unterstützen. Dies kann z. B. durch den Betrieb jeder Mandantendatenbank in einer eigenen DB-Instanz oder auf einem separaten Server erfolgen. Diese Option ermöglicht es, Mandanten bei Bedarf vollständig physisch zu isolieren (z. B. um besonders hohe Anforderungen eines einzelnen Mandanten getrennt zu skalieren), bleibt jedoch optional und ist nur bei explizitem Bedarf zu berücksichtigen.

• Backup- und Restore-Fähigkeit: Das System muss über zuverlässige Backup- und Wiederherstellungsmechanismen verfügen, die mit minimalem Betriebsunterbruch einhergehen. Datensicherungen sollen regelmäßig und möglichst im laufenden Betrieb (bzw. mit sehr kurzen Wartungsfenstern) durchführbar sein. Im Fehler- oder Datenverlustfall muss eine rasche Wiederherstellung der CAFM-Daten aus den Backups möglich sein, um die Betriebsunterbrechung so gering wie möglich zu halten.

• Skalierbarkeit bei großem Datenvolumen: Die Datenhaltung muss skalierbar sein, sodass auch sehr große Datenmengen und lange Nutzungszeiträume performant bewältigt werden. Das System muss in der Lage sein, Millionen von Datensätzen – etwa aus vielen Jahren Betriebs- und Nutzungsdaten – zu verarbeiten, ohne dass die Antwortzeiten oder Stabilität inakzeptabel abnehmen. Die Architektur sollte horizontale und/oder vertikale Skalierung ermöglichen (z. B. durch leistungsfähigere Hardware oder verteilte Last auf mehrere Server), um wachsende Datenbestände zu handhaben.

• Unterstützung von Cluster- und Container-Betrieb: Die Lösung sollte in modernen IT-Infrastrukturen betrieben werden können. Insbesondere wird die Fähigkeit zum Cluster-Betrieb (mehrere Server zur Lastverteilung und Hochverfügbarkeit) und der Einsatz in Container-Umgebungen (z. B. Bereitstellung der Anwendung und der Datenbank in Docker-Containern oder Orchestrierung via Kubernetes) erwartet. Dies erlaubt flexible Deployment-Optionen, erleichtert Wartung und Updates und erhöht die Ausfallsicherheit des Gesamtsystems.

• Offene Datenbank-Schnittstelle und Dokumentation: Das eingesetzte Datenbanksystem muss offen dokumentiert sein und den Zugriff per Standard-Abfragesprachen (insbesondere SQL) erlauben. Alle relevanten Daten sollen mittels Abfragen extrahiert und für Exporte, Berichte oder Business-Intelligence-Auswertungen genutzt werden können. Die Datenmodell-Dokumentation (Datenbankhandbuch oder ER-Modell) ist bereitzustellen, sodass Integrationen durch Dritt-Systeme und direkte Datenbankzugriffe ohne proprietäre Hindernisse möglich sind.

• Integration externer Reporting-Tools: Externe Reporting- und Analysewerkzeuge müssen direkt auf das Datenbanksystem des CAFM zugreifen können. Gängige Tools wie Microsoft Power BI, Qlik, Microsoft Excel (über ODBC/OLE DB) oder Crystal Reports müssen sich ohne zusätzliche Anpassungen an die CAFM-Datenbank anbinden lassen, um Auswertungen und Berichte zu erstellen. Damit wird sichergestellt, dass Auskünfte und Analysen auch außerhalb der CAFM-Software flexibel durchgeführt werden können und der Anbieter offene Standards unterstützt.

Zur Sicherstellung der Prüfbarkeit sind die oben formulierten Anforderungen nach Muss-, Soll- und Kann-Kriterien kategorisiert. Jede Anforderung wird mit einem konkreten Abnahmekriterium verknüpft, anhand dessen die Erfüllung überprüft werden kann.

• Unterstützung gängiger DBMS (MUSS): Das System unterstützt mindestens eine der üblichen relationalen DB-Plattformen (z. B. PostgreSQL, Oracle oder MS SQL Server) vollumfänglich. Abnahmeprüfung: Installation der CAFM-Software auf einem der geforderten Datenbankmanagementsysteme und Durchführung eines vollständigen Funktionstests. Die Anforderung gilt als erfüllt, wenn alle Kernfunktionen des Systems auf dieser DB-Plattform fehlerfrei laufen.

• Metamodell für Datenstruktur (MUSS): Die Datenstruktur ist durch ein Metamodell von der physischen Implementierung entkoppelt. Abnahmeprüfung: Einsicht in Systemdokumentation und Konfiguration. Die Anforderung ist erfüllt, wenn nachgewiesen wird, dass neue Objekttypen oder Datenfelder durch Konfiguration im Metamodell hinzugefügt werden können, ohne Änderungen am zugrundeliegenden physischen Datenbankschema vornehmen zu müssen.

• Objektorientierte Datenorganisation (MUSS): Die Anwendung stellt Daten als verknüpfte Objekte der realen FM-Welt dar (Gebäude, Räume, Anlagen etc.). Abnahmeprüfung: Vorführung im Testsystem, in der der Anbieter exemplarisch Gebäude, Räume und Anlagen anlegt. Es wird geprüft, ob diese Objekte in einer hierarchischen Struktur (z. B. Gebäude enthält Räume, Räume enthalten Anlagen) in der Benutzeroberfläche navigierbar sind. Die Anforderung ist erfüllt, wenn Benutzer eindeutig in Objekthierarchien navigieren können statt in isolierten Datenbanktabellen.

• Historisierung/Versionierung von Daten (MUSS): Wichtige Objekt- und Bewegungsdaten können mit Historie geführt werden. Abnahmeprüfung: Im Test wird ein Datensatz (z. B. ein Raumnutzungsobjekt oder Vertrag) geändert und anschließend der vorherige Stand abgerufen. Die Anforderung gilt als erfüllt, wenn das System ältere Stände des Datensatzes (vor der Änderung) auffinden und anzeigen kann (z. B. über eine Versionsverwaltung oder Historienfunktion).

• Mandantentrennung und -schutz (MUSS): Mehrere Mandanten können in einer Installation betrieben werden, wobei ihre jeweiligen Daten strikt voneinander isoliert sind. Abnahmeprüfung: Einrichtung von zwei Test-Mandanten A und B im System. Anschließend wird mit Benutzerrechten von Mandant A versucht, Daten von Mandant B einzusehen (und umgekehrt). Die Anforderung ist erfüllt, wenn in beiden Fällen kein Zugriff auf fremde Mandantendaten erfolgt und gemeinsame Stammdaten (z. B. Katalogeinträge) dennoch von beiden genutzt werden können.

• Backup und Restore mit minimaler Ausfallzeit (MUSS): Das System ermöglicht Datensicherungen und -wiederherstellungen bei minimaler Unterbrechung. Abnahmeprüfung: Vorlage und Prüfung des Backup-Konzepts des Anbieters. Gegebenenfalls wird ein Test-Backup während des laufenden Betriebs erstellt und zurückgespielt. Die Anforderung gilt als erfüllt, wenn die Datenwiederherstellung funktioniert und der produktive Betrieb dabei nur in dem im Konzept definierten, kurzen Rahmen unterbrochen wird.

• Skalierbarkeit bei großem Datenvolumen (MUSS): Die Lösung bewältigt auch langfristig anwachsende, große Datenbestände performant. Abnahmeprüfung: Nachweis der Skalierbarkeit durch einen performanten Testlauf mit umfangreichen Testdaten. Beispielsweise importiert der Anbieter eine große Menge an Datensätzen (im Millionenbereich) in die Testinstanz und demonstriert typische Abfragen oder Operationen. Alternativ können belastbare Referenzberichte oder Benchmark-Tests vorgelegt werden. Erfüllt ist die Anforderung, wenn das System auch bei großer Datenmenge flüssige Reaktionszeiten aufweist und keine Stabilitätsprobleme auftreten.

• Offene Datenbankschnittstelle (MUSS): Direkte SQL-Abfragen und Datenexporte sind möglich, das Datenbankmodell ist dokumentiert. Abnahmeprüfung: Prüfung der technischen Dokumentation des Datenmodells sowie Durchführung einer direkten SQL-Abfrage auf die Datenbank. Z. B. wird außerhalb der Anwendung mit einem SQL-Client eine Liste von Objekten oder Buchungen abgefragt. Die Anforderung gilt als erfüllt, wenn die Dokumentation vollständig ist und die direkte Abfrage konsistente, korrekte Ergebnisse liefert.

• Zugriff externer Reporting-Tools (MUSS): Gängige Analysewerkzeuge können an die Datenbank angebunden werden. Abnahmeprüfung: In der Testumgebung wird ein externes Tool (z. B. Microsoft Excel über ODBC oder Power BI) mit der CAFM-Datenbank verbunden. Anschließend wird ein beispielhafter Report (etwa eine Flächenliste oder Anlagenübersicht) live aus der Datenbank erzeugt. Die Anforderung ist erfüllt, wenn die Verbindung erfolgreich hergestellt werden kann und die abgerufenen Daten mit den in der CAFM-Anwendung sichtbaren Daten übereinstimmen.

• Cluster- und Container-Betrieb (SOLL): Das System unterstützt den Betrieb in Cluster-Umgebungen und als containerisierte Anwendung. Abnahmeprüfung: Sichtung der Systemarchitektur-Dokumentation oder Durchführung eines Deployment-Tests. Die Anforderung gilt als erfüllt, wenn der Anbieter nachweist, dass die Software z. B. in einem Docker-Container lauffähig ist oder in einer Kubernetes-Clusterumgebung betrieben werden kann, und dass bei Bedarf mehrere Instanzen für Lastverteilung/Redundanz eingesetzt werden können.

• Unterstützung alternativer DB-Technologien (KANN): Integration von objektorientierten oder NoSQL-Datenbanken für Spezialfälle ist möglich. Abnahmeprüfung: Falls vom Auftraggeber benötigt, muss der Anbieter einen Nachweis erbringen, dass eine Kopplung oder Erweiterung an ein solches DB-System machbar ist (z. B. Demonstration einer angebundenen MongoDB für IoT-Sensordaten). Ist diese Erweiterung nicht gefordert, bleibt das Kriterium ohne Bewertung.

• Separate Datenbankinstanzen pro Mandant (KANN): Technische Trennung der Mandanten über separate Datenbanken wird unterstützt. Abnahmeprüfung: Prüfung der technischen Architektur oder Absprache mit dem Anbieter. Die Anforderung gilt als erfüllt, wenn der Anbieter bestätigen kann (etwa anhand eines Systemhandbuchs oder Konfigurationsnachweises), dass anstelle der logischen Trennung auch eine vollständige physische Trennung pro Mandant umgesetzt werden kann (z. B. jede Mandantendatenbank auf separatem DB-Server). Dieses Kriterium wird nur relevant, sofern der Auftraggeber eine solche getrennte Betriebsweise wünscht.