ISO/IEC 25000:2014-03 System und Software-Engineering - Qualitätskriterien

Ein präzises Begriffsverständnis ist die Voraussetzung, um Qualitätsanforderungen an FM-Software systematisch zu formulieren, messbar zu machen und über den Lebenszyklus zu steuern. Dieses Kapitel definiert zentrale Termini, erläutert das Qualitätsmodell nach ISO/IEC 25010 und verortet die wichtigsten Normen der ISO/IEC‑25000‑Familie. Zudem werden die für das Facility Management relevanten Daten- und Austauschstandards (BIM/IFC/COBie, CAFM‑Connect) sowie Grundprinzipien der Datenintegration im FM dargestellt.

Facility Management ist die integrierte Steuerung und Leistungserbringung von Unterstützungsprozessen, die Gebäude, Anlagen, Flächen und Services über ihren Lebenszyklus hinweg effizient und wirkungsvoll bereitstellen.

• strategisch: Portfolio- und Lebenszyklusmanagement, Governance, Compliance, Nachhaltigkeit, Supply‑Chain‑Steuerung;

• taktisch/operativ: Instandhaltung und Asset Management, Flächen- und Umzugsmanagement, Energiemanagement, Sicherheit und Bewachung, Gesundheit/Arbeitsschutz (HSE), Reinigung, technische und infrastrukturelle Services, Helpdesk.

FM wirkt am Knotenpunkt von Bau/Planung (BIM), technischer Gebäudeausrüstung (BMS/BAS/IoT), kaufmännischen Systemen (ERP), Dokumenten- und Geoinformationssystemen (DMS/GIS) sowie Sicherheits- und Compliance‑Anforderungen (z. B. DSGVO, KRITIS).

• Produktqualität: Eigenschaften des Softwareprodukts selbst (acht Merkmalsgruppen).

• Quality in Use: Qualität der Nutzung in einem bestimmten Kontext (z. B. Wirksamkeit, Effizienz, Zufriedenheit, Freiheit von Risiken, Kontextabdeckung).

• Funktionale Eignung: Vollständigkeit, Korrektheit und Zweckmäßigkeit der Funktionen. Beispiel: korrekte Generierung von Wartungsplänen gemäß Herstellervorgaben und rechtlichen Intervallen.

• Leistungseffizienz: Zeitverhalten, Ressourcenverbrauch und Kapazität. Beispiel: Antwortzeiten von unter 2 Sekunden bei typischen Abfragen wie Raum- oder Assetsuche auch bei großen Portfolios.

• Kompatibilität: Koexistenz und Interoperabilität mit anderen Systemen. Beispiel: stabile Schnittstellen zu ERP-, BMS- und IoT-Plattformen sowie konfliktfreier Parallelbetrieb.

• Benutzbarkeit (Usability): Erkennbarkeit der Zweckmäßigkeit, Erlernbarkeit, Bedienbarkeit, Schutz vor Benutzungsfehlern, UI-Ästhetik und Barrierefreiheit. Beispiel: rollenbasierte, aufgabenorientierte Oberflächen für Techniker, Disponenten oder HSE-Verantwortliche.

• Zuverlässigkeit: Reife, Verfügbarkeit, Fehlertoleranz und Wiederherstellbarkeit. Beispiel: Systemverfügbarkeit von mindestens 99,9 Prozent, transaktionssichere Ticketverarbeitung und robuste Wiederanlaufprozeduren.

• Sicherheit: Vertraulichkeit, Integrität, Nichtabstreitbarkeit, Verantwortlichkeit und Authentizität. Beispiel: DSGVO-konformer Umgang mit personenbezogenen Daten wie Zutrittsprotokollen, starke Authentifizierung oder SSO sowie Audit-Trails.

• Wartbarkeit: Modularität, Wiederverwendbarkeit, Analysierbarkeit, Änderbarkeit und Testbarkeit. Beispiel: konfigurationsgetriebene Regelwerke für SLAs anstelle hart codierter Logik sowie automatisierte Tests für kundenspezifische Anpassungen.

• Übertragbarkeit (Portabilität): Anpassbarkeit, Installierbarkeit und Austauschbarkeit. Beispiel: Cloud- und On-Prem-Portabilität, Containerisierung und Infrastructure-as-Code.

• Effektivität und Effizienz: Aufgabenabschlussquote und Bearbeitungszeit wie etwa der Ticketdurchlauf; direkte Einflussgröße auf die Prozesskosten.

• Zufriedenheit: Nutzerakzeptanz und wahrgenommene Qualität; relevant für den Adoptionsgrad, zum Beispiel bei Mobile-Apps im Field Service.

• Freiheit von Risiken: Minimierung von Sicherheits-, Datenschutz- und Compliance-Risiken im Nutzungskontext.

• Kontextabdeckung: Robustheit der Lösung über unterschiedliche Standorte, Sprachen, Rechtsräume und Betriebsmodelle hinweg.

• CAFM hat seinen Ursprung in der immobilien- und gebäudebezogenen Verwaltung (Flächen, Assets, Wartung, Helpdesk, CAD‑Anbindung).

• IWMS steht für integrierte Plattformen, die zusätzlich übergreifende Domänen wie Miet-/Vertragsmanagement, Workplace/Hybrid Work, Projekte, Nachhaltigkeit/ESG, Kapitalplanung und oft Real‑Estate‑Funktionen abdecken.

Typische Funktionsbereiche sind u. a. Stammdaten- und Flächenmanagement (inkl. CAD/BIM‑Integration), CMMS/Instandhaltung, Ticketing/Service Management, Asset- und Ersatzteilverwaltung, Energiemonitoring, Belegungs- und Buchungssysteme, Mobile‑Apps, Reporting/BI. Moderne Architekturen bieten APIs, Event‑Streams und Konnektoren zu ERP (z. B. SAP), DMS, GIS, BMS/BAS (z. B. BACnet) und IoT‑Plattformen (z. B. MQTT).

Softwarequalität beschreibt den Grad, zu dem ein Softwareprodukt spezifizierte und implizite Bedürfnisse seiner Stakeholder erfüllt. Sie umfasst messbare Eigenschaften des Produkts (z. B. Zuverlässigkeit, Sicherheit, Wartbarkeit) sowie der Nutzung (z. B. Effektivität, Effizienz, Zufriedenheit). Im FM konstituiert sich Qualität nicht nur aus funktionaler Eignung (richtige Features), sondern ebenso aus Datenqualität, Interoperabilität, Performance im operativen Betrieb, Compliance, Auditierbarkeit und der Fähigkeit, Änderungen (z. B. neue Gesetze, Energieziele, IoT‑Rollouts) wirtschaftlich zu adaptieren.

Die ISO/IEC‑25000‑Familie operationalisiert Softwarequalität über Modelle (z. B. ISO/IEC 25010), Metriken (ISO/IEC 25023) und Prozesse zur Bewertung (ISO/IEC 25040). Für FM ist besonders die Verknüpfung mit Datenqualität (ISO/IEC 25012) und Sicherheitsstandards relevant.

Building Information Modeling (BIM) ist eine methodische Arbeitsweise zur modellbasierten, kollaborativen Planung, Ausführung und Bewirtschaftung von Bauwerken. Für das FM ist BIM vor allem als Datenquelle für den Betrieb relevant: Anlagendaten, Räume/Flächen, Systeme (z. B. HVAC), Produkt-/Typeigenschaften, Dokumente und Betreibervorgaben.

• IFC (Industry Foundation Classes): Offenes, von buildingSMART entwickeltes Datenmodell/Schemastandard zur strukturierten Beschreibung von Bauwerksinformationen. Für das FM sind insbesondere folgende Konzepte relevant: IfcSpace/IfcZone (Flächen), IfcAsset/IfcEquipment/IfcDistributionElement (Assets/Technik), IfcSystem/IfcRelAssignsToGroup (Systemzuordnung), IfcPropertySet (Eigenschaften), IfcDocumentReference (Dokumentenverweise). IFC ermöglicht herstellerneutrale Übergaben aus Planung/Bau in FM‑Systeme und bildet eine Grundlage für semantische Konsistenz.

• COBie (Construction‑Operations Building information exchange): ein standardisiertes Datenlieferformat, das die für Betrieb und Instandhaltung wesentlichen Informationen in tabellarischer Form (z. B. XLSX, XML) strukturiert. Typische Tabellen sind u. a. Facility, Floor, Space, Zone, Type, Component, System, Spare, Resource, Job, Document, Attribute. COBie ist „FM‑minimalistisch“: Es fokussiert auf das, was für Asset‑ und Wartungsmanagement zur Inbetriebnahme und im frühen Betrieb benötigt wird, und lässt komplexe Geometrie außen vor. In der Praxis werden IFC und COBie kombiniert: IFC liefert Geometrie und Beziehungen, COBie die betriebskritischen Stammdaten.

• Frühzeitige Definition von FM-Datenanforderungen (AIA/EIR) und Abnahmekriterien.

• Eindeutige Identifikatoren (GUIDs) zur Sicherung der Referenzierbarkeit.

• Mapping und Transformation von IFC- und COBie-Attributen auf CAFM- und IWMS-Datenmodelle.

• Qualitätssicherung nach ISO/IEC 25012, zum Beispiel Vollständigkeit der Pflichtfelder, Konsistenz von Typ und Komponente sowie Aktualität bei Änderungsständen.

• Dokumenten- und Nachweisverknüpfung, etwa Wartungsanleitungen und Prüfbücher.

CAFM‑Connect ist ein in der DACH‑Region verbreiteter Standard für den Datenaustausch zwischen CAD/BIM- und CAFM‑Systemen sowie zwischen unterschiedlichen CAFM‑Lösungen.

• Konsistente Stammdatenübernahmen aus Planung und Bestandserfassung.

• Standardisierte Schnittstellen für Flächen- und Assetdaten inklusive Geometriebezug.

• Wiederholbare Migrations- und Updateprozesse über den gesamten Lebenszyklus.

Für FM‑Organisationen bietet CAFM‑Connect eine pragmatische Brücke zwischen internationalen Standards (IFC/COBie) und konkreten, operativen Datenmodellen der CAFM/IWMS‑Praxis in DACH, einschließlich definierter Pflichtfelder und Kodierungen.

• Integrationsparadigmen: Batch-ETL/ELT mit zeitgesteuerter Extraktion aus ERP, DMS oder IoT-Historian, anschließender Transformation und Laden in CAFM/IWMS oder ein Data Warehouse.

• Echtzeit-APIs (REST/GraphQL) für transaktionale Prozesse wie Ticket-Synchronisation oder Buchungen.

• Event- und streambasierte Kopplung, z. B. über MQTT für IoT-Events oder Kafka zur Skalierung, um Zustandsänderungen wie Alarm, Störung oder Belegung direkt in FM-Workflows zu überführen.

• ERP/Finanzen: Buchungs- und Kostenstellenabgleich, Bestell- und Wareneingangsprozesse sowie Instandhaltungsrückmeldungen.

• BMS/BAS/IoT: BACnet, Modbus und OPC UA auf Anlagenebene sowie MQTT und AMQP auf Plattformebene; Aggregation und Normalisierung von Messwerten für Monitoring, Energiemanagement und Predictive Maintenance.

• SSO/IDM: OIDC, SAML, LDAP und SCIM zur Identitäts- und Rollenverwaltung sowie attributbasierte Zugriffskontrolle.

• GIS/DMS: Georeferenzierte Flächen und Liegenschaften sowie Dokumentenverknüpfung, z. B. von Prüfberichten und Zertifikaten.

• Eindeutige Schlüssel für Assets, Räume, Gebäude und Verträge sowie Versionierung und Historisierung.

• Festgelegte Verantwortlichkeiten wie Data Owner und Data Stewards sowie der Einsatz von Data Catalogs und Glossaren.

• Qualitätsregeln nach ISO/IEC 25012, zum Beispiel Pflichtfelder, Wertebereiche, Dublettenfreiheit und Plausibilitätsprüfungen, mit automatisierten Kontrollen in Form von Data Quality Gates entlang der Integrationspipelines.

• Datenschutz (DSGVO): Datenminimierung, Zweckbindung, Lösch-/Sperrkonzepte, Pseudonymisierung wo möglich (z. B. bei Buchungs-/Zutrittsdaten);

• Informationssicherheit: Ende‑zu‑Ende‑Verschlüsselung, Transport- und Ruheschutz, Härtung von Schnittstellen, Protokollierung/Audit‑Trails, Least‑Privilege‑Zugriffe;

• Nachweisführung: revisionssichere Protokolle für Änderungen an Stammdaten, nachvollziehbare Datenherkunft (Provenienz).

• Versionierte Schnittstellenverträge (API‑Specs), Testdaten und Staging‑Umgebungen;

• Monitoring von Integrationsjobs und Events (z. B. Latenzen, Fehlerraten, Backlogs);

• Resilienz: Retry/Backoff‑Strategien, Dead‑Letter‑Queues, Idempotenz, Circuit‑Breaker.

Leistungseffizienz (z. B. durch Caching/Indexierung), Zuverlässigkeit (fehlertolerante Pipelines), Sicherheit (zugriffskontrollierte Datenwege), Wartbarkeit (entkoppelte, dokumentierte Schnittstellen) und Benutzbarkeit (aktuelle, korrekte Daten für Workflows).

• FM benötigt präzise definierte Software- und Datenqualitätsziele, da Prozesse, Compliance und Wirtschaftlichkeit maßgeblich davon abhängen.

• ISO/IEC 25010 strukturiert die Produkt- und Nutzungsqualität, ISO/IEC 25023 operationalisiert deren Messung, ISO/IEC 25012 adressiert die Datenqualität und ISO/IEC 25040 liefert den Bewertungsprozess.

• BIM, IFC, COBie und CAFM-Connect bilden die zentralen Brückenformate zwischen Bau, Planung und Betrieb, deren qualitätsgesicherte Integration erfolgskritisch ist.

• Ein robustes Integrations- und Datenqualitätsmanagement schafft die Grundlage für ein skalierbares, sicheres und wirtschaftliches digitales Facility Management.

Diese Grundlagen bilden den Bezugsrahmen für die nachfolgenden Kapitel, in denen rechtliche/normative Vorgaben, organisatorische Verankerung, technische Architektur sowie Qualitätssicherung und Risikomanagement konkretisiert und auf FM‑Szenarien angewendet werden.

Dieses Kapitel verortet die Softwarequalitätsanforderungen im Facility Management (FM) im Spannungsfeld internationaler Normen, branchenspezifischer Standards und des DACH/EU‑Rechts. Ziel ist es, die für die Beschaffung, Implementierung und den Betrieb von CAFM/IWMS‑Lösungen maßgeblichen Vorgaben zu bündeln, zu strukturieren und in konkrete Anforderungen an FM‑Software zu übersetzen.

• ISO/IEC 25010 (Quality Models) definiert die Qualitätsmerkmale der Produktqualität wie funktionale Eignung, Leistungseffizienz, Kompatibilität, Benutzbarkeit, Zuverlässigkeit, Sicherheit, Wartbarkeit und Portabilität sowie die Quality in Use. Für FM dient die Norm als Referenzrahmen, um Qualitätsanforderungen systematisch, vollständig und widerspruchsfrei zu formulieren.

• ISO/IEC 25023 (Measurement) liefert Metriken und Messverfahren zur Operationalisierung der in ISO/IEC 25010 beschriebenen Merkmale, etwa Antwortzeit-Perzentile, Fehlerraten, Verfügbarkeitsgrade, Schwachstellen-Dichte, Änderungs- und Release-Durchlaufzeiten oder Testabdeckungsgrade. Dadurch werden Abnahme und Betrieb messbar und auditierbar.

• ISO/IEC 25012 (Data Quality) ergänzt den Fokus auf Daten durch inhärente und systemabhängige Qualitätsmerkmale wie Genauigkeit, Vollständigkeit, Konsistenz, Aktualität, Zugänglichkeit, Vertraulichkeit und Nachvollziehbarkeit. Die Norm ist zentral für BIM-to-FM-Übergaben sowie für Integrationen mit ERP, DMS und BMS/IoT.

• ISO/IEC 25040 (Evaluation Process) beschreibt den Prozess zur Planung und Durchführung von Qualitätsbewertungen und schließt die Lücke zwischen Lastenheft, Messung nach ISO/IEC 25023 und dokumentierter Abnahme.

Anforderungen in Ausschreibungen sollten explizit auf 25010 referenzieren, messbare Ziel‑ und Grenzwerte nach 25023 enthalten, Datenqualitätsregeln nach 25012 festlegen und den Bewertungsprozess nach 25040 verankern (inkl. Rollen, Artefakte, Nachweise).

• ISO 41001 legt Anforderungen an Managementsysteme für Facility Management fest. Analog zu ISO 9001/14001 adressiert sie Politik, Ziele, Prozesse, Rollen, Leistungsbewertung und kontinuierliche Verbesserung. CAFM/IWMS‑Systeme dienen als Enabler, um Nachweise (KPIs, Dokumente, Maßnahmenverfolgung) zu führen und die Wirksamkeit des FM‑Managementsystems zu belegen.

• EN 15221 (als Vorläufer der ISO‑41000‑Familie) prägte Terminologie und Prozessmodelle des europäischen FM. Viele Organisationen referenzieren ihre Prozesse weiterhin daran; CAFM/IWMS sollten entsprechende Prozesslandkarten, Rollen und Kennzahlen abbilden können.

• Unterstützung von Ziel‑/Kennzahlensystemen, Audit‑/Maßnahmenmanagement, Dokumentenlenkung;

• klare Verantwortlichkeitsmodelle (Rollen/Rechte), Nachverfolgbarkeit von Änderungen.

• ISO 19650 regelt das Informationsmanagement mit BIM über den gesamten Bauwerkslebenszyklus. Für das Facility Management sind insbesondere die Anforderungen an Organisations- und Asset-Informationsanforderungen (OIR/AIR) sowie die Auftraggeber-Informationsanforderungen (EIR) relevant.

• Zentral ist außerdem das Common Data Environment (CDE) mit klaren Regeln zu Datenstruktur, Metadaten, Zugriffsrechten und Versionierung, um eine konsistente und nachvollziehbare Informationsbasis sicherzustellen.

• Ergänzend definiert ISO 19650-5 Sicherheitsanforderungen an ein informationssicheres BIM-Management und verfolgt dabei einen sicherheitsbewussten Ansatz (Security-minded approach), der insbesondere für sensible FM-Daten von Bedeutung ist.

IFC (Industry Foundation Classes) ist der offene Datenstandard für Bauwerksinformationen und bildet die semantische Brücke in den Betrieb (Räume, Anlagen, Systeme, Eigenschaften). COBie (Construction‑Operations Building information exchange) standardisiert die für Betrieb und Instandhaltung essenziellen Stammdaten in tabellarischer Form (z. B. Facility, Space, Type, Component, System, Job, Document).

• Import und Mapping von IFC- und COBie-Daten nach festgelegten Datenmodellen sowie Validierung gegen Pflichtattribute und Wertebereiche.

• Fähigkeit, EIR- und AIR-basierte Mindestinhalte zu prüfen, insbesondere hinsichtlich Vollständigkeit und Konsistenz, und QS-Berichte für die Abnahme zu erzeugen.

• Integration in ein Common Data Environment (CDE) einschließlich Metadaten, Versionierung und Zugriffsrechten sowie Nachweisführung, dass Betriebsdaten gemäß ISO 19650-Regeln gepflegt werden.

• Berücksichtigung der Anforderungen aus ISO 19650-5, insbesondere Zugriffskontrolle, Schutzbedarfsfeststellung, Umsetzung des Least-Privilege-Prinzips und eine sicherheitsbewusste Veröffentlichung von Bauwerksdaten.

• CAFM-Connect ist ein im DACH-Raum etablierter Standard für den Austausch FM-relevanter Daten wie Objektklassen, Attribute und Identifikatoren zwischen CAD/BIM, Bestands­erfassung und CAFM-Systemen. Er operationalisiert die Brücke von internationalen Standards wie IFC und COBie zu produktiven FM-Datenmodellen.

• GEFMA 444 ist der Zertifizierungskatalog für CAFM-Software mit definierten Modulen und Prüfkriterien, beispielsweise für Flächenmanagement, Instandhaltung, Energiemanagement und Vertragsverwaltung. Er schafft Transparenz über Funktionsabdeckung und Qualitätsanforderungen im deutschsprachigen Markt.

• GEFMA 445 ergänzt dies durch Best-Practice-Leitlinien für Daten, Prozesse sowie die BIM- und CAFM-Kopplung im Facility-Management-Kontext.

• Unterstützung der CAFM-Connect-Profile und Schnittstellen mit klar dokumentierten Mapping-Regeln zwischen Quell- und Zielsystemen.

• Nachweisbarkeit der Erfüllung relevanter GEFMA-444-Module, beispielsweise durch eine formale Zertifizierung oder durch funktionsäquivalente, prüfbare Evidenzen.

• Definierte Pflichtfelder und Kataloge, die konsistent und kompatibel zu CAFM-Connect und GEFMA-Vorgaben aufgebaut sind.

Die nachfolgenden Vorgaben sind für FM‑Organisationen und deren Softwareeinsatz maßgeblich. Die konkrete Anwendung kann je nach Branche (z. B. KRITIS), Betriebsmodell (Cloud/On‑Prem) und Datenumfang variieren.

Personenbezogene Daten fallen in zahlreichen Prozessen an, etwa Zutrittskontrolle, Besuchermanagement, Videoüberwachung, Arbeitsplatz‑/Buchungsdaten, Helpdesk‑Tickets, Dienstleistersteuerung.

• Rechtmäßigkeit, Transparenz, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität und Vertraulichkeit sowie Rechenschaftspflicht.

• Rollenklärung mit Betreiber oder Unternehmen als Verantwortlichem, CAFM/IWMS-Anbieter in der Regel als Auftragsverarbeiter und Integratoren als Unterauftragsverarbeiter; erforderlich sind Auftragsverarbeitungsverträge, Unterauftragsgenehmigungen sowie technische und organisatorische Maßnahmen nach Art. 28 und 32 DSGVO.

• Betroffenenrechte wie Auskunft, Berichtigung, Löschung, Einschränkung, Datenübertragbarkeit und Widerspruch; FM-Software muss Such-, Export- und Löschkonzepte, Sperr- und Anonymisierungsfunktionen sowie eine lückenlose Protokollierung bereitstellen.

• Datenschutz-Folgenabschätzung, die beispielsweise bei großflächiger Überwachung, systematischer Verarbeitung von Zutritts- oder Bewegungsdaten oder Videoüberwachung erforderlich sein kann; die Software sollte DPIA-relevante Informationen zu Verarbeitungstätigkeiten, Datenflüssen und Speicherorten auswertbar machen.

• Sicherheit der Verarbeitung nach Art. 32 DSGVO durch Verschlüsselung bei Transport und Speicherung, Pseudonymisierung, Resilienz und Wiederherstellbarkeit sowie regelmäßige Tests und Assessments.

• Internationale Datenübermittlungen unter Einsatz von Standardvertragsklauseln und Transfer-Impact-Assessments sowie gegebenenfalls Datenlokalisierung; Cloud-Anbieter müssen Transparenz zu Unterauftragsverarbeitern und Speicherorten bieten.

• Meldepflichten bei Verletzungen des Schutzes personenbezogener Daten innerhalb von 72 Stunden; FM-Software sollte Ereignisse und Zugriffe revisionssicher protokollieren und Anbindungen an SIEM-Systeme unterstützen.

• Stand der Technik bei organisatorischen und technischen Maßnahmen sowie regelmäßige Sicherheitsnachweise und Audits.

• Meldepflicht erheblicher IT-Störungen und Etablierung von Prozessen zur Angriffserkennung.

• Einbindung der Lieferkette durch Sicherstellung der Vertrauenswürdigkeit kritischer Komponenten und Festlegung von Sicherheitsanforderungen an Dienstleister.

• Implikationen für FM-Software sind die Integrationsfähigkeit mit Angriffserkennungs- und Monitoring-Systemen wie SIEM oder IDS sowie die Bereitstellung vollständiger und manipulationssicherer Logs.

• Erforderlich sind zudem Systemhärtung, Patch- und Schwachstellenmanagement sowie belastbare Notfall- und Wiederanlaufkonzepte.

• Weiterhin notwendig sind Netzwerksegmentierung und sichere Fernzugänge, insbesondere an der Schnittstelle zu BMS, BAS und IoT-Systemen.

In AT/CH bestehen analoge Regelungen (z. B. NIS‑Umsetzung in AT), die in multinationalen Portfolios konsistent zu berücksichtigen sind.

• Betriebssicherheitsverordnung (BetrSichV): regelt die sichere Bereitstellung und Benutzung von Arbeitsmitteln sowie den Betrieb überwachungsbedürftiger Anlagen. Für FM-Software folgt hieraus die Fähigkeit, Gefährdungsbeurteilungen, Prüfpflichten und Prüffristen (z. B. Aufzüge, Druckbehälter, elektrische Anlagen), Prüfnachweise und Maßnahmenverfolgung revisionssicher abzubilden. Schnittstellen zu TRBS-Vorgaben und Prüfgesellschaften (z. B. Import von Prüfberichten) sind sinnvoll.

• Arbeitsschutzgesetz (ArbSchG): verpflichtet Arbeitgeber zu Gefährdungsbeurteilungen, Unterweisungen und Wirksamkeitskontrollen. CAFM/IWMS sollten die Dokumentation, Terminsteuerung, Verantwortungszuweisung (RACI) und Nachweisführung unterstützen.

• Bewachungsverordnung (BewachV): relevant, wenn FM-Organisationen Bewachungsdienstleistungen erbringen oder steuern. Softwareseitig sind Nachweise zur Eignung und Unterweisung, Einsatzplanung, Dienstanweisungen und Ereignisdokumentation zu führen; personenbezogene Daten sind DSGVO-konform zu verarbeiten.

• ISO/IEC 27001 beschreibt Anforderungen an ein Informationssicherheits-Managementsystem (ISMS). ISO/IEC 27002 liefert den Maßnahmenkatalog (Controls) zur Umsetzung. Für FM-Softwareanbieter (SaaS) und Betreiber ist ein ISMS ein wesentlicher Vertrauensnachweis.

• Relevante Control-Themen für CAFM/IWMS sind Zugriffskontrolle und Identitätsmanagement (starke Authentifizierung, SSO via SAML/OIDC, Rollen- und Attribut-basierte Zugriffskonzepte, Least-Privilege).

• Kryptografie umfasst Schlüsselmanagement, Ende-zu-Ende-Verschlüsselung und HSM-Einsatz je nach Schutzbedarf.

• Betriebssicherheit beinhaltet Logging und Auditing, Malware-Schutz, Härtung, Konfigurations- und Änderungsmanagement, Backup/Restore sowie Kapazitätsmanagement.

• Lieferantenbeziehungen erfordern Sicherheitsanforderungen an Hosting, Cloud und Integratoren, Auditrechte und Schwachstellen-Disclosure.

• Sicheres Entwickeln umfasst SDLC, Code-Reviews, statische und dynamische Tests, Dependency-Management, SBOM und Secrets-Management.

• Incident-Management beinhaltet Erkennung, Behandlung, Lessons Learned sowie Business Continuity und Disaster Recovery.

• Bereitstellung revisionssicherer Protokolle, Integration in SIEM-Systeme, Export von Audit-Trails.

• Mandantenfähigkeit und Mandantentrennung bezüglich Daten und Konfiguration.

• Konfigurierbare Aufbewahrungs- und Löschregeln zur Einhaltung von DSGVO und weiteren Compliance-Anforderungen.

• Nachweise durch Zertifikate wie ISO/IEC 27001, Statements of Applicability, Penetrationstest-Reports sowie Prozesse zum Vulnerability-Management.

• ISO/IEC 62443 adressiert Security für industrielle und automationsnahe Systeme; Gebäudeautomation (BMS/BAS) und IoT-Plattformen im FM fallen in den Anwendungsbereich.

• 62443-2-1: Anforderungen an das Sicherheitsprogramm von Betreibern (Governance, Prozesse, Zonen/Conduits, Risikoanalyse).

• 62443-3-3: System-Sicherheitsanforderungen und -Level (SL1-SL4) inklusive Authentisierung, Autorisierung, Integrität, Verfügbarkeit, Ereigniserkennung.

• 62443-4-1: Sicherer Entwicklungsprozess für Komponenten (SDL).

• 62443-4-2: Technische Anforderungen an Komponenten (z. B. Controller, Gateways).

• Zonenkonzept und sichere Schnittstellen (Segmentierung, Firewalls, Protokoll-Gateways).

• Härtung von Protokollkonvertern (BACnet/OPC UA/MQTT), Schutz vor unsicheren Default-Konfigurationen.

• Starke Authentisierung für Fernzugriffe, Just-in-Time-Privilegien, Protokollierung.

• Patch/Update-Prozesse und Schwachstellen-Management, Kompatibilitätsprüfung zwischen OT-Komponenten und CAFM/IWMS.

• Qualitätsanforderungen nach ISO/IEC 25010 mit messbaren Zielwerten nach ISO/IEC 25023 (z. B. 95-Perzentil-Antwortzeiten, Verfügbarkeit, Fehlerraten, Usability-Kennzahlen).

• Datenqualitätsregeln und Prüfungen nach ISO/IEC 25012 entlang von Migration, Integration und Betrieb; Definition von Pflichtfeldern, Referenzkatalogen, Dubletten- und Konsistenzprüfungen; Nachweisberichte.

• BIM/FM-Schnittstellen: Unterstützung von IFC/COBie und CAFM-Connect; definierte Mapping-Tabellen und Validierungen; CDE-Integration gemäß ISO 19650; Sicherheitsanforderungen nach ISO 19650-5.

• Compliance-Artefakte: AV-Vertrag (DSGVO), TOM-Beschreibung, Verzeichnis von Verarbeitungstätigkeiten, Lösch-/Aufbewahrungskonzepte, DPIA-Unterstützung; Meldeprozesse für Datenschutz- und Sicherheitsvorfälle.

• Informationssicherheit: ISMS-Nachweise (z. B. ISO/IEC 27001-Zertifikat), SoA, jährliche Pen-Tests, Schwachstellen-Reports, Secure-Development-Policy (ggf. 62443-4-1), SBOM und Patch-SLAs; Protokoll-Export an SIEM; Mandantentrennung.

• KRITIS-Tauglichkeit: Integrationen zu Angriffserkennung, manipulationssichere Audit-Logs, Notfall-/Wiederanlaufkonzepte, Lieferkettensicherheit.

• ArbSchG/BetrSichV/BewachV-Unterstützung: Module für Gefährdungsbeurteilungen, Prüf- und Unterweisungsmanagement, Fristensteuerung, Nachweisdokumentation, Eskalationen und Berichte für Behörden/Audits.

• Vertragsgestaltung: KPIs/SLA-Zielwerte, Auditrechte, Berichtspflichten, Abnahme-/Exit-Kriterien inkl. Datenportabilität (offene Formate), Sicherheits-/Datenschutzanhänge, Rechte auf Schwachstellen-Scans und Code-Reviews (bei On-Prem/Customizing).

• ISO/IEC 25010/25023 geben die Qualitätsziele und Messbarkeit vor.

• ISO/IEC 25012 und BIM-Standards (ISO 19650, IFC, COBie, CAFM-Connect) sichern Datenqualität und Interoperabilität.

• ISO 41001/EN 15221 verankern Qualität und Compliance im FM-Managementsystem.

• DSGVO und sektorale Vorschriften (BetrSichV, ArbSchG, BewachV) definieren Mindeststandards für den Umgang mit personenbezogenen Daten, Arbeitssicherheit und Nachweisen.

• ISO/IEC 27001/27002 und ISO/IEC 62443 operationalisieren Informationssicherheit für IT- und OT-Domänen.

• Etablierung eines gemeinsamen Governance‑Boards aus FM, IT/Security, Datenschutz und Rechtsabteilung;

• Pflege eines integrierten Anforderungskatalogs mit eindeutigen Referenzen zu Normen/Gesetzen, KPIs, Mess‑ und Nachweisverfahren;

• RACI‑Zuweisung für Spezifikation, Messung, Prüfung und Berichterstattung; jährliche Reviews;

• kontinuierliche Verbesserung über Audits, Lessons Learned und Marktbeobachtung (z. B. Weiterentwicklungen der Normen).

Damit entsteht ein konsistenter, auditierbarer Rahmen, der Rechtssicherheit, Interoperabilität und messbare Softwarequalität im digitalen Facility Management verbindet und in Beschaffung wie Betrieb wirksam umgesetzt werden kann.

Die erfolgreiche Einführung und der nachhaltige Betrieb von CAFM/IWMS-Lösungen beruhen auf klar definierten Rollen, etablierten Prozessen und einer gelebten Governance. Dieses Kapitel konkretisiert die organisatorischen Grundlagen, die erforderlich sind, um Qualitätsziele nach ISO/IEC 25010, Messbarkeit nach ISO/IEC 25023 und Datenqualitätsanforderungen nach ISO/IEC 25012 dauerhaft zu verankern.

Ein wirksames Organisationsmodell verbindet FM-Fachkompetenz mit IT-/Security-Governance und Lieferantensteuerung.

• Verantwortung: Strategische Zielbilder, Priorisierung der FM-Digitalisierung, Budget- und Ressourcenhoheit, Abnahme fachlicher Ergebnisse.

• Entscheidungshoheit über Make-or-Buy, Sourcing-Strategie, Roadmap und Nutzenargumentation (TCO/ROI).

• Verantwortung: Architekturvorgaben, Betriebsmodell (Cloud/SaaS vs. On-Prem), Integrationsstrategie, SSO/IDM, Infrastruktur- und Plattformbetrieb.

• Sicherstellung von Skalierbarkeit, Performance, Backup/Restore, Monitoring.

• Verantwortung: ISMS (ISO/IEC 27001/27002), Security-by-Design, Risikoanalysen, Freigaben für Änderungen, Schwachstellen- und Incident-Management.

• DSGVO-Compliance inkl. DPIA, AV-Verträge, Lösch-/Sperrkonzepte.

• Verantwortung: Definition fachlicher Anforderungen, Pflege von Stammdaten, Prozessdesign, Abnahme von Modulen und KPIs.

• Rolle als Product Owner für funktionsspezifische Backlogs.

• Verantwortung: Stammdaten-Governance (ISO/IEC 25012), Datenmodelle, Qualitätsregeln, Data Quality Gates, Pflegeverantwortung und Eskalationen.

• Verantwortung: Release-/Konfigurationsmanagement, Testkoordination, Lizenz- und Nutzerverwaltung, Servicekatalog.

• Verantwortung: Ausschreibungen, Vertragsgestaltung (SLA, KPIs, Auditrechte, Datenschutz-/Sicherheitsanhänge), Lieferantenbewertungen.

• Verantwortung: Implementierung, Schnittstellen, Customizing, Testnachweise, Betriebsübergaben und 3rd-Level-Support.

• Verantwortung: Produkt-Roadmap, Security-Fixes, Dokumentation, Nachweisführung (z. B. 27001-Zertifikat, Penetrationstests).

• Verantwortung: Mitbestimmung bei Überwachung/Leistungsdaten, Einhaltung von ArbSchG, Unterweisungs- und Nachweispflichten.

• Lenkungskreis (FM-Leitung, IT, Security, Fachbereiche): strategische Entscheidungen, Budget, Priorisierung.

• Change Advisory Board (CAB): Freigaben für Änderungen/Releases, Risiko- und Rollback-Bewertungen.

• Architekturboard: Bewertung von Lösungsarchitekturen, Integrations- und Technologieentscheidungen.

• Data Governance Board: Datenmodelle, Qualitätsregeln, Stammdatenprozesse.

• Security & Privacy Board: Risikoanalysen, DPIA-Freigaben, Incident-Reviews.

• Quellen: Prozessanalysen, Use-Cases, gesetzliche/normative Vorgaben (DSGVO, BetrSichV), EIR/AIR aus BIM, Lessons Learned.

• Strukturierung: Funktionale Anforderungen (z. B. Wartungsplanung gemäß Hersteller/Norm).

• Nichtfunktionale Anforderungen gemäß ISO/IEC 25010 (z. B. Antwortzeit p95 ≤ 2 s, Verfügbarkeit ≥ 99,9 %, Auditierbarkeit).

• Datenqualitätsanforderungen nach ISO/IEC 25012 (Pflichtfelder, Genauigkeit, Aktualität).

• Priorisierung: MoSCoW oder WSJF; explizite Abhängigkeiten.

• Rückverfolgbarkeit: Requirements-IDs, Verlinkung zu Testfällen, Abnahmekriterien, SLAs, Betriebsdokumentation (Requirements Traceability Matrix).

• Prototyping/PoC: Validierung kritischer Anforderungen (Usability, Performance, Schnittstellen) vor Vergabe.

• Abnahme-Definition: Definition of Ready/Done, Akzeptanzkriterien je Anforderung.

• Lastenheft: Referenz auf ISO/IEC 25010/25023, ISO/IEC 25012, ISO 19650/IFC/COBie, CAFM-Connect; definierte Messpunkte und Zielwerte; Sicherheits- und Datenschutzanforderungen (ISO/IEC 27001/62443).

• Bewertungsmatrix: Gewichtung von Funktion, Qualität, Sicherheit, Betrieb, TCO/ROI, Referenzen, Zertifizierungen; Nachweisformate (Berichte, Zertifikate, Testprotokolle).

• Anbieterklärung: Architektur-Blueprint, Datenmodell, Schnittstellenliste, Roadmap, Support-/Release-Modell, Mandantenfähigkeit.

• Due Diligence: Security- und Datenschutz-Check (SoA, Pen-Test-Reports, Subprozessoren), Rechtsprüfung (AVV, Auditrechte), Betriebsprüfung (RPO/RTO).

• PoC/Sandbox: vertraglich fixierte Testfälle mit Akzeptanzkriterien; Messung nach 25023.

• Vertragsgestaltung: SLAs (Verfügbarkeit, Reaktions-/Behebungszeiten), KPIs, Reportingpflichten, Auditrechte, Exit-Strategie (Datenportabilität, offene Formate), Change-Kostenmodelle.

• Change-Typen: Standard-, Normal-, Emergency-Changes; klare Schwellenwerte und Genehmigungswege.

• CAB: Zusammensetzung, Entscheidungskriterien (Risiko, Compliance, Downtime), Rollback-Pläne.

• Release-Kalender und Wartungsfenster: Koordination mit Fachbereichen; Kommunikations- und Trainingspläne.

• Konfigurations- und Versionsmanagement: CMDB/CIs für Mandanten, Module, Schnittstellen; Semver; Infrastruktur-as-Code bei On-Prem/Private Cloud.

• Teststrategie: automatisierte Regressionstests für Kernprozesse, Performance-Tests, Security-Scans (SAST/DAST), UAT mit Fachbereichen.

• Dokumentationsupdate: Aktualisierung von Betriebshandbuch, Datenmodell, Schnittstellenverträgen und Schulungsunterlagen.

• Servicekatalog: Leistungen, SLAs/OLAs, Supportzeiten, Schweregrade, Eskalationspfade.

• Support-Organisation: L1 (Anwender-/Prozessfragen), L2 (Konfiguration/Integration), L3 (Hersteller/Entwicklung); klare Übergabekriterien.

• Prozesse: Incident-, Request- und Problem-Management; Major Incident Verfahren; Post-Incident Reviews.

• KPIs: MTTA/MTTR, FTR-Quote, SLA-Erfüllung, Backlog-Aging, Change-Failure-Rate, p95-Antwortzeiten, Datenqualitätsindex (ISO/IEC 25012).

• Wissensmanagement: KEDB, How-tos, Self-Service-Portal; Standardlösungen und Workarounds.

• Monitoring: End-to-End- und synthetische Monitore, Business-Transaktions-Metriken, Log-/Audit-Überwachung; SIEM-Anbindung.

• QA-Plan: Rollen, Testumgebungen, Daten, Tools, Zeitplan; Bezug zu ISO/IEC 25023-Metriken und Akzeptanzkriterien.

• Testebenen: Unit/Komponenten-, Integrations-, System-, UAT-, Smoke- und Regressionstests; Security- und Datenschutztests (Rollen-/Rechte, Löschkonzepte).

• Testdatenmanagement: DSGVO-konforme Anonymisierung/Pseudonymisierung; synthetische Daten für sensible Szenarien.

• Datenqualität: Data Quality Gates in ETL/Streaming-Pipelines (Vollständigkeit, Plausibilität, Dubletten, Aktualität); DQ-Dashboards und Eskalationspfade.

• Audits: interne/externe Audits (ISO 41001/27001, GEFMA 444); Lieferantenaudits; Abweichungsmanagement mit Maßnahmenverfolgung.

• Kontinuierliche Verbesserung: Retrospektiven, Root-Cause-Analysen, Lessons Learned in Backlogs und Standards einpflegen.

• Anforderungsdefinition: Responsible = Fachbereiche/Product Owner; Accountable = FM-Leitung; Consulted = IT/Security, Data Owner; Informed = Einkauf/Recht, Integrator.

• Auswahl/Ausschreibung: R = Einkauf/PMO; A = FM-Leitung; C = IT/Security, Recht, Fachbereiche; I = Hersteller/Integrator (für Q&A).

• Datenmigration: R = Integrator/Data Stewards; A = Data Owner; C = Fachbereiche, IT; I = FM-Leitung.

• Release-Freigabe: R = Application Manager; A = CAB-Vorsitz (IT-Leitung); C = Fachbereiche, Security/DSB; I = Nutzerkreis.

• Incident-Management: R = Service Desk; A = IT-Betrieb; C = Integrator/Hersteller, Fachbereiche; I = FM-Leitung.

• Audit/Compliance: R = ISB/DSB; A = FM-Leitung; C = IT, Fachbereiche, Integrator; I = Management/Lenkungskreis.

Die RACI-Matrix wird im QM-Handbuch gepflegt und jährlich überprüft.

• Inhalt: Geltungsbereich, Begrifflichkeiten, Normenbezug (ISO/IEC 25010/25023/25012/25040, ISO 41001, ISO 19650, ISO/IEC 27001/62443, DSGVO).

• Prozesslandschaft (Anforderungs-, Beschaffungs-, Change-, Service-, QA-, Datenmanagement-Prozesse).

• Rollen- und RACI-Beschreibungen, Gremienordnung (Lenkungskreis, CAB, Boards).

• Dokumentenlenkung (Vorlagen, Versionierung, Freigaben, Aufbewahrungsfristen).

• Mess- und Reportingkonzept (Kennzahlen, Schwellenwerte, Dashboards, Reviewzyklen).

• Risiko- und Maßnahmenmanagement (Register, Bewertung, Priorisierung, Wirksamkeitskontrolle).

• Lieferantenmanagement (Qualifizierung, Audits, KPI-/SLA-Review, Eskalationen).

• Schulungs- und Kompetenzmanagement.

• Anhang: Checklisten, Bewertungsmatrizen, Testkataloge, Datenmodelle/Mappings.

• Initiierung: Business Case, Nutzen-/Risikoanalyse, Projektauftrag, Stakeholder- und Kommunikationsplan.

• Anforderungen: Lastenheft, Qualitäts- und Sicherheitsanforderungen (ISO/IEC 25010/25023/27001), Datenqualitätsregeln (ISO/IEC 25012), EIR/AIR.

• Architektur/Design: Zielarchitektur, Integrationsspezifikationen (APIs, Formate, Sicherheitsprofile), Datenmodell, Mandanten-/Rollenmodell.

• Beschaffung/Vertrag: Bewertungsmatrix, Vergabeprotokoll, Verträge inkl. SLAs/KPIs, AVV, TOM, Auditrechte, Exit-Regelungen.

• Umsetzung: Pflichtenheft, Mappings (IFC/COBie/CAFM-Connect), Migrationskonzept, Testplan/-fälle, Testdatenkonzept, Sicherheitskonzept.

• Abnahme: Testprotokolle, Messberichte nach 25023, DQ-Reports, Abnahmeprotokoll, Go-Live-Checkliste, Betriebsfreigabe (Security/DSB).

• Betrieb: Betriebshandbuch, Servicekatalog, Monitoring-/Backup-Konzepte, Notfall-/Wiederanlaufpläne, Change-/Release-Protokolle.

• Compliance: Verzeichnis von Verarbeitungstätigkeiten, DPIA, Schulungsnachweise, Auditberichte, Maßnahmenverfolgung.

Dokumentenlenkung umfasst eindeutige IDs, Versionsstände, Freigaben, Änderungslogs und Aufbewahrungsfristen. Elektronische Signaturen und revisionssichere Ablage im DMS sind obligatorisch.

• Schulungsprogramm: rollenbasiert (Disponenten, Techniker, Data Stewards, Admins), Onboarding-Packages, E-Learnings, Zertifizierungen.

• Kommunikation: Release Notes, Wartungsankündigungen, Major-Incident-Updates, Roadmap-Veröffentlichungen.

• Adoption-Messung: Nutzungsgrade, Task Success Rate, Zufriedenheitsumfragen; gezielte Optimierungen (Usability, Workflows).

• Organisationsentwicklung: Anpassung von Stellenprofilen, Verantwortlichkeiten und Zielsystemen an digitale Prozesse.

• ISMS-Integration: Risiko- und Kontrollkataloge, Secure Development Life Cycle, Schwachstellen-Management, SoA; jährliche Re-Zertifizierungen.

• BIM-Governance: CDE-Regeln, Rollen/Rechte, Modellabnahmen; BIM-Fachkoordination mit Data Governance Board; Synchronisierung von EIR/AIR mit CAFM-Datenmodellen.

Klare Rollen, definierte Prozesse und ein integriertes QM-/Governance-System sind die Voraussetzung, um Qualitäts- und Sicherheitsziele im FM nachhaltig zu erreichen. Mit RACI-Transparenz, verbindlichen Artefakten und messbarer Steuerung entlang ISO/IEC 25010/25023/25012 wird Softwarequalität vom Lippenbekenntnis zur gelebten Praxis – in Beschaffung, Implementierung und Betrieb.

Dieses Kapitel beschreibt die technische Grundlage für Planung, Implementierung und Betrieb von CAFM/IWMS-Lösungen. Im Fokus stehen Architekturprinzipien (Modularität, Mandantenfähigkeit, Cloud/SaaS vs. On-Premise), Integrationen (ERP, SSO/IDM, BMS/BAS/IoT, GIS, DMS), Datenstandards (IFC/COBie, CAFM‑Connect), Datenmanagement nach ISO/IEC 25012 sowie betriebliche Mechanismen für Updates, Monitoring, Auditierbarkeit, Zugriffskontrolle und Resilienz.

• Modularität und Domänenschnitt

• Domänenorientierung (Domain-Driven Design) trennt Funktionsbereiche wie Flächen, Instandhaltung (CMMS), Energiemanagement, Verträge, Helpdesk, Dokumente.

• Lose Kopplung über wohldefinierte Schnittstellen (API-first) und Ereignisse reduziert Abhängigkeiten und steigert Wartbarkeit (ISO/IEC 25010: Wartbarkeit, Kompatibilität).

• Technische Modularität: modulare Monolithen (ein Deployable, klare Modulgrenzen) vs. Microservices (eigene Deployables, unabhängige Skalierung).

• Tenancy-Modelle: Shared-DB, Shared-Schema (Mandantenkennung auf Datenebene; kosteneffizient, höhere Anforderungen an Isolation/Row-Level-Security).

• Shared-DB, Separate Schemas (bessere Isolation, individuelle Wartung/Upgrades möglich).

• Separate DB pro Mandant (stärkste Isolation, einfache Portabilität/Exit; höhere Betriebsaufwände).

• Isolationserfordernisse: Mandantenbezogene Verschlüsselungsschlüssel, strenge Zugriffskontrollen, mandantenbezogene Konfigurationen, Quotas und Rate Limits.

• Datenresidenz: Mandantenspezifische Region/Wohnsitzanforderungen (DSGVO, KRITIS).

• Cloud/SaaS: Pro: Elastizität, Automatisierung (CI/CD), kürzere Release-Zyklen, globale Verfügbarkeit, Managed Services (Datenbanken, Message-Broker).

• Contra: Abhängigkeit vom Anbieter, Datenübermittlung an Dritte, regulatorische Anforderungen an Subprozessoren.

• Typische Plattformen: Container-Orchestrierung, API-Gateways, Service Mesh, Managed Datastores (SQL/NoSQL/Time Series).

• Pro: Datenhoheit, Integrationsnähe zu OT-Netzen, individuelle Sicherheitszonen.

• Contra: Kapazitätsplanung, Patch-/Upgrade-Aufwand, längere Bereitstellungszeiten.

• Erfordernisse: Standardisierte Deployments (Container/VMs), Infrastructure-as-Code, Artefakt-Repository, Automatisiertes Patchen.

• Synchrone APIs (REST/GraphQL) für Transaktionen, Webhooks für Ereignisse.

• Asynchrone Events/Streams (z. B. MQTT, AMQP, Kafka) für IoT- und Prozessereignisse; entkoppelt und skalierbar (ISO/IEC 25010: Leistungseffizienz, Zuverlässigkeit).

• API-Verträge (OpenAPI/JSON Schema), versionierte Endpunkte, Idempotenz und Replay-Schutz.

• Internationalisierung: Sprachen, Zeitzonen, Einheiten/Kalender; deterministische Zeitbehandlung (UTC intern).

• Mobile/Offline: Native/Hybrid-Apps, Offline-Cache mit Ende-zu-Ende-Verschlüsselung, Konfliktlösung, MDM-Integration.

• Observability by Design: Metriken, Tracing, strukturierte Logs, Korrelation-IDs.

• Security by Design: Zero-Trust-Netzwerkzugriff, Least-Privilege, Secrets-Management, Härtung und sichere Defaults.

• ERP/SAP und kaufmännische Systeme

• Anwendungsfälle: Kostenstellen- und Kontenpläne, Beschaffung (Bestellungen, Wareneingang), Faktura, Anlagenbuchhaltung, Verträge, Zeiterfassung.

• Schnittstellen: SAP OData/REST, SOAP/BAPI, IDoc; für andere ERP vergleichbare REST/SOAP-APIs.

• Muster: Master-Data-Sync (ein-/zweiseitig), Bewegungsdatenkopplung, Belegfluss-Referenzen; Transaktionssicherheit (Two-Phase-Commit vermeiden, stattdessen Sagas/Outbox-Pattern).

• Datenabgleich: Referenzschlüssel und Mappingtabellen; Reconciliation-Jobs und Differenzberichte.

• Protokolle: OIDC/OAuth2, SAML 2.0, SCIM für Provisionierung, LDAP für Legacy.

• Autorisierung: RBAC/ABAC mit rollen-/attributsbasierten Policies; Mandanten-/Standortkontext; Segregation of Duties.

• Sicherheitsanforderungen: MFA, Conditional Access, JIT-Berechtigungen, zeitlich begrenzte Admin-Rollen, Audit der Berechtigungsänderungen.

• Protokolle/Ebenen: Anlagenebene: BACnet/IP, BACnet/SC, Modbus/TCP, OPC UA.

• Plattform-/IoT-Ebene: MQTT/AMQP/HTTP für Telemetrie und Events, TLS-gesichert, Client-Zertifikate.

• OT/IT-Entkopplung via gesicherte Gateways in DMZ, Zonenkonzept (nach 62443), Protokollkonverter, Normalisierung (Einheiten, Namensräume).

• Timeseries-Historian für Sensor-/Zählerdaten; Aggregation/Downsampling; Qualitätskennzeichen (Valid/Estimated/Missing).

• Ereignisverarbeitung: Alarm-/Störmeldungen in FM-Tickets; Deduplication, Eskalationslogik, Quiet Times.

• Sicherheit/Resilienz: Store-and-Forward bei Verbindungsabbrüchen, Rate-Limits, Quarantäne verdächtiger Geräte, Zertifikatsrotation, Patchbarkeit der Gateways.

• Standards: OGC WMS/WFS/WMTS, GeoJSON; Indoor-Mapping (z. B. IndoorGML/IFC Spaces).

• Anwendungsfälle: Liegenschafts-/Flächenkarten, Leitungs-/Versorgungsnetz, Geofencing für Einsatzsteuerung, Routenoptimierung.

• Technische Aspekte: Kachel- und Vektor-Services, Caching, Koordinatenreferenzsysteme, Layer-Rechtemanagement.

• Schnittstellen: CMIS, REST-APIs, WebDAV; Integration in CDE (ISO 19650).

• Funktionen: Versionierung, Metadaten, Aufbewahrungs-/Löschregeln, Rechtskonforme Archivierung (WORM).

• Verknüpfung: Dokumente an Räume/Assets/Jobs binden; OCR für gescannte Prüfnachweise; digitale Signaturen/Zeitsiegel.

• Kanäle: E-Mail, Push, SMS, Chat-Integrationen; Präferenz- und Ruhezeiten.

• Kollaboration: Aufgaben/Kommentare mit @Mentions, Dateilinks, Abnahme-Workflows.

• Relevanz: Semantisches Gebäudemodell (Räume, Anlagen, Systeme, Eigenschaften).

• Technische Punkte: IFC4 als Zielversion für Betrieb; GUID-Persistenz, PropertySets, Relationen (Aggregation, Zuweisung, Systeme).

• Umsetzung: Teilmodell-Extraktion (z. B. für TGA), Attribut-Mapping auf CAFM-Objekte, Geometrievereinfachung für Web/Mobil.

• Validierung: Schema-/MVD-Prüfungen, Naming/Classification (z. B. nach Uniclass/Omniclass/ETIM, falls eingesetzt).

• Tabellenstruktur: Facility, Floor, Space, Zone, Type, Component, System, Job, Spare, Resource, Document, Attribute.

• Nutzung: Betriebsrelevante Stammdatenübernahme, Wartungspläne (Job/Resource), Dokumentlinks.

• Qualitätssicherung: Pflichtfelder, referentielle Integrität (Space↔Component↔Type), Dublettenprüfung; Delta-Updates mit Change-Logs.

• Einsatz: Austausch standardisierter Objektklassen/Attribute im DACH-Kontext, Brücke zwischen CAD/BIM und CAFM.

• Nutzen: Eindeutige Identifikatoren, Pflichtfeldkataloge, wiederholbare Migrationen; Kompatibilität mit GEFMA 444/445.

• Governance: Versionierung des Profils, Mapping-Tabellen, Validierungsreports.

• API-Payloads in JSON/CSV/XML für Batch-Imports/Exports; JSON Schema zur Validierung.

• Zeitreihen: line-protocol/CSV/Parquet; Kompression und Retention-Policies.

• Dokumente: PDF/A für Langzeitarchivierung; TIFF/G4 für gescannte Altbestände.

• Rollen: Data Owner (Verantwortung), Data Stewards (operative Qualität), Custodians (technisch).

• Golden-Record-Strategie: Eindeutige Schlüssel (Assets, Räume, Standorte), Versions-/Statusmodelle (geplant/aktiv/außer Betrieb), Historisierung.

• Kataloge/Taxonomien: Anlagenklassen, Maßnahmen, Fehlercodes, SLA-Klassen; kontrollierte Vokabulare.

• Data Catalog/Glossar: Definitionen, Lineage, Verantwortlichkeiten; Self-Service-Findbarkeit.

• Vorgehen: Discovery/Profiling, Bereinigung (Dubletten, Normalisierung), Mapping (IFC/COBie/CAFM-Connect→CAFM), Testladungen, Parallelbetrieb, Cutover.

• DQ-Gates: Vollständigkeit (Pflichtfelder), Genauigkeit (z. B. Maße, Seriennummern), Konsistenz (Type↔Component), Aktualität (Stichtagslogik), Eindeutigkeit (Schlüssel).

• Abnahme: Stichproben- und Vollprüfungen, DQ-Scorecards, Fehlerklassen und Nachbearbeitungsprozesse.

• Inhärent: Genauigkeit, Glaubwürdigkeit, Vollständigkeit, Konsistenz, Aktualität.

• Systemabhängig: Zugänglichkeit, Compliance, Effizienz der Datenverarbeitung, Sicherheit (Vertraulichkeit/Integrität), Rückverfolgbarkeit.

• Operationalisierung: Regelkataloge pro Objektklasse, automatisierte Validatoren, Toleranzen und Grenzwerte, KPI-Dashboards (z. B. DQ-Index ≥ 95 %).

• Klassifizierung: Schutzbedarf (öffentlich/intern/vertraulich/streng vertraulich; personenbezogen/sensibel/KRITIS-bezogen).

• Verschlüsselung: TLS 1.2+/1.3 in Transit; AES-256 at Rest; getrennte Schlüssel pro Mandant; HSM/KMS, Rotation.

• Zugriff: RBAC/ABAC, Row-/Column-Level Security, Datenmaskierung, Pseudonymisierung/Anonymisierung, Data Minimization.

• Lebenszyklus: Aufbewahrung/Löschung (DSGVO-konform), rechtssichere Archivierung (WORM), eDiscovery/Legal Hold.

• Nachvollziehbarkeit: Data Lineage, Änderungsprotokolle (Wer/Was/Wann/Warum), Vier-Augen-Prinzip für kritische Änderungen.

• Backups: Kombination aus Snapshots (schnell) und logischen Dumps (konsistent), Verschlüsselung, Offsite/Geo-Redundanz.

• Tests: Regelmäßige Restore-Übungen, Validierung von RPO/RTO, Dokumentation und Runbooks.

• Portabilität/Exit: Export in offene Formate (IFC/COBie/CSV/JSON), vollständige Daten- und Dokumentenextrakte, Schlüsselentzug.

• Versionierung: SemVer, Long-Term-Support (LTS) für Kernmodule, Kompatibilitätsversprechen (API/Schema).

• Deployment-Patterns: Blue-Green, Canary, Rolling; Datenbank-Migrationen mit vorwärts-/rückwärtskompatiblen Scripts (Expand/Contract).

• Qualitätstore: Automatisierte Tests (Unit/Integration/E2E), Security-Scans (SAST/DAST/Dependency), Performance-Benchmarks; Staging-Umgebungen mit produktionsnahen Daten (DSGVO-konform anonymisiert).

• Änderungsfenster und Kommunikation: Wartungsfenster, Release Notes, Trainings für Änderungen mit hoher Nutzerwirkung.

• Architektur: Horizontale Skalierung, Read-Replicas, Partitionierung/Sharding, asynchrone Verarbeitung (Queues/Streams), Caching (API/DB/Edge).

• APM/Tracing: Messen von p95/p99-Latenzen, Durchsatz, Fehlerquoten, DB-Query-Zeiten; Tracing über Dienste hinweg (OpenTelemetry).

• Kapazität: Prognosen (Trend/IoT-Last), Autoscaling-Policies, Lasttests, Backpressure und Load Shedding bei Überlast.

• Optimierung: Indizes, Query-Tuning, Materialized Views; Batch-Fenster und Priorisierung kritischer Workloads.

• Strukturierte Logs (JSON) mit Korrelation-IDs; zentrale Log-Pipeline; unveränderbare Ablage (WORM) für Audit-Events.

• Audit-Logs: Authentifizierung/Autorisierung, Stammdatenänderungen, SLA-relevante Aktionen; Signierung/Zeitsynchronisation (NTP).

• Retention: Lösch- und Aufbewahrungsfristen abgestimmt auf DSGVO/Compliance; selektive Maskierung in Logs.

• SIEM-Integration: Forwarding sicherheitsrelevanter Ereignisse, Anomalieerkennung, Use-Cases (verdächtige Zugriffe, Datenexfiltration).

• IAM: Zentrale Richtlinien, SoD, regelmäßige Rezertifizierungen, Rezensionsprozesse für privilegierte Zugriffe.

• PAM: JIT-Admin, Break-Glass-Verfahren, Aufzeichnung privilegierter Sitzungen.

• Secrets: Zentraler Vault, Rotation von Schlüsseln/Passwörtern/Zertifikaten; keine Secrets im Code/Config; mTLS für Service-zu-Service.

• Hochverfügbarkeit: Redundante Instanzen, Zonen-/Regionenübergreifende Deployments, Stateful Sets mit synchroner/asychroner Replikation.

• DR-Strategie: Definierte RPO/RTO, regelmäßige Failover-Tests, Runbooks, Kommunikationspläne, Krisenstab.

• Fehlertoleranz: Circuit Breaker, Timeouts, Retries mit Exponential Backoff, Idempotenz, Dead-Letter-Queues.

• Chaos-Engineering: Gezielte Ausfalltests (Netzwerk, Knoten, Abhängigkeiten), Validierung von Alarmierung und Auto-Healing.

• Patch-/Vulnerability-Management: CVE-Scanning, SBOM, priorisierte Behebung, Wartungszyklen.

• SLI/SLO-Framework: SLOs für Verfügbarkeit, Latenz, Fehlerbudget; Koppelung an SLAs.

• Geschäftsmetriken: Ticketdurchlaufzeiten, First-Time-Fix, Datenqualitätsindex, IoT-Ingestion-Lag, Energiemonitoring-Genauigkeit.

• Dashboards: Technik (APM, Auslastung), Qualität (DQ, SLA), Sicherheit (Vuln-Status, Incident-Response).

• Post-Incident-Reviews: Ursachenanalyse, Maßnahmen, Verankerung in Backlog und Standardprozessen.

• API-Verträge als Produkt: Versioniert, dokumentiert, mit Mock-/Sandbox-Umgebungen; Consumer-Driven-Contracts.

• Testdatenstrategie: Synthetische Datensätze für Performance/Sicherheit; produktionsnahe, anonymisierte Dumps für UAT.

• Mapping-Kataloge: IFC/COBie/CAFM-Connect→CAFM-Objekte mit Attributpflichten, Code-Listen, Einheiten und Validierungsregeln.

• Edge-Strategie: OT-Gateways als Puffer und Policy-Enforcer; lokale Caches für Campus mit intermittenter Verbindung.

• Mobile-First für Field Service: Offline-Fähigkeit, Kamera/Barcode/NFC, digitale Formulare mit Prüf- und Signaturlogik.

• Exit-Readiness: Regelmäßig geübte Datenexporte, Dokumentation von Abhängigkeiten, neutralisierte Konfigurationen, Mandantenlöschung.

• Ziel: Vollständige, messbare und verifizierbare Anforderungen; Qualitäts- und Sicherheitsziele explizit.

• Fokussierte ISO-25010-Merkmale: Funktionale Eignung, Kompatibilität, Sicherheit, Benutzbarkeit, Wartbarkeit.

• Artefakte: Lastenheft, Datenqualitätsregeln (ISO/IEC 25012), Abnahmekriterien, RTM (Requirements Traceability Matrix).

• Ziel: Evidenzbasierte Bewertung, PoC-Verifikation kritischer Merkmale.

• Merkmale: Leistungseffizienz, Zuverlässigkeit, Sicherheit, Benutzbarkeit, Portabilität.

• Artefakte: Bewertungsmatrix, PoC-Berichte, Sicherheits-/Datenschutz-Nachweise, Referenzen.

• Ziel: Änderbarkeit und Testbarkeit sicherstellen; technische Schuld minimieren.

• Merkmale: Wartbarkeit (Analysierbarkeit, Änderbarkeit, Testbarkeit), Kompatibilität, Sicherheit.

• Artefakte: Pflichtenheft, Konfigurations-/Coding-Guides, Schnittstellenverträge, Mappings (IFC/COBie/CAFM-Connect).

• Ziel: Formale Verifikation gegen Anforderungen; Nachweis der Betriebsreife.

• Merkmale: Zuverlässigkeit, Leistungseffizienz, Sicherheit, Benutzbarkeit, Datenqualität.

• Artefakte: Testplan/-fälle, DQ-Reports, Pen-Test-Bericht, Abnahmeprotokoll.

• Ziel: Stabilität, Sicherheit und Performance im Tagesgeschäft; Auditierbarkeit.

• Merkmale: Verfügbarkeit, Fehlertoleranz, Wiederherstellbarkeit, Performance, Sicherheit.

• Artefakte: Betriebs- und Notfallhandbuch, SLO/SLA-Dashboards, Audit-Logs.

• Ziel: Gesteuerte Weiterentwicklung basierend auf Metriken, Vorfällen und Feedback.

• Merkmale: Wartbarkeit (Änderbarkeit, Testbarkeit), Benutzbarkeit (Zufriedenheit), Sicherheit (Schwachstellen-Management).

• Artefakte: Backlog, Lessons-Learned, Release-Roadmap.

• Vollständigkeit der Anforderungen: ≥ 95 % der identifizierten Prozessschritte durch Anforderungen abgedeckt (Messung via RTM).

• Messbarkeit: ≥ 90 % der Anforderungen mit quantifizierten Akzeptanzkriterien (z. B. Antwortzeit p95 ≤ 2 s).

• Sicherheitsanforderungs-Deckung: 100 % der identifizierten Schutzbedarfe mit Kontrollanforderungen (27001/62443-Bezug).

• Datenqualitätsregel-Abdeckung (ISO/IEC 25012): ≥ 95 % der relevanten Objektklassen mit definierten Regeln (Pflichtfelder, Wertebereiche).

• PoC-Performance: p95 Antwortzeit ≤ 2 s bei 500 gleichzeitigen Nutzern; Durchsatz ≥ 50 Tickets/min bei Peak; Zielverletzung < 1 %.

• Zuverlässigkeit im PoC: Fehlerrate < 0,1 % pro 1.000 Transaktionen; keine Datenverluste bei Failover-Tests.

• Usability: SUS-Score ≥ 75; Task Success Rate ≥ 90 % für Top-10-Use-Cases (Disponent, Techniker, Leiter).

• Sicherheit: 0 kritische/hohe Findings in initialem DAST/SAST; Hersteller weist Patch-SLA nach (kritische CVEs ≤ 14 Tage).

• Testabdeckung: Unit/Automationsgrad ≥ 70 % für Custom-Regeln/Skripte; kritische Pfade ≥ 90 %.

• Änderungsaufwand: Median Lead Time for Change ≤ 7 Tage; Change Failure Rate ≤ 15 %.

• Kopplung/Kohäsion: Maintainability-Index ≥ 70 für kundenspezifische Komponenten; zyklomatische Komplexität je Regel ≤ 10.

• Datenintegration: DQ-Index (Vollständigkeit, Konsistenz, Eindeutigkeit, Aktualität) je Ladezyklus ≥ 95 %; Reconciliation-Differences < 0,5 %.

• Zuverlässigkeit: MTBF in Lasttest ≥ 200 h (modellhaft durch fehlerfreie Zyklen); Defektdichte ≤ 0,5 Defekte pro 1.000 Testfälle.

• Leistungseffizienz: p95 Antwortzeit ≤ 2 s (Suche, Ticketanlage), p99 ≤ 5 s; IoT-Ingestion-Lag p95 ≤ 60 s.

• Verfügbarkeit (Go-Live-SLO): Monats-SLO ≥ 99,9 % (ohne geplante Wartung); RPO ≤ 15 min, RTO ≤ 2 h für Kernmodule.

• Sicherheit/Datenschutz: 0 kritische/hohe OWASP-Top-10-Findings; Rollenkonzept vollständig getestet (SoD-Checks); Lösch-/Sperrkonzept funktionsfähig.

• Benutzbarkeit/Barrierefreiheit: Task Success Rate ≥ 90 %; Fehlbedienungsrate ≤ 5 %; WCAG-Konformität (angemessene Stufe) nachgewiesen.

• Datenmigration: Pflichtfelder vollständig (≥ 99 %), referentielle Integrität 100 %, Dublettenrate ≤ 0,2 %, Abweichungsprotokolle abgearbeitet.

• Verfügbarkeit: Service-SLO ≥ 99,9 % (Standard) bzw. ≥ 99,95 % (kritische Prozesse).

• Incident-Kennzahlen: MTTA ≤ 15 min (P1), MTTR ≤ 2 h (P1), Wiedereröffnungsrate ≤ 5 %.

• Performance: p95 Antwortzeiten innerhalb der Abnahmeziele; Kapazitätsreserve ≥ 30 % CPU/IO; DB-Query-p95 ≤ 200 ms.

• Sicherheit: Patch-SLA kritische Schwachstellen ≤ 14 Tage, hohe ≤ 30 Tage; 2FA/MFA-Quote = 100 % für Admins; fehlgeschlagene Logins überwacht.

• Auditierbarkeit: 100 % der privilegierten Aktionen geloggt; Log-Integrität (Signaturen) geprüft; Export an SIEM in Echtzeit.

• Datenqualität im Betrieb: DQ-Index ≥ 95 %; Alter kritischer Stammdatenänderungen ≤ 24 h; IoT-Datenlücken < 0,1 %/Tag.

• SLO-Erfüllung: ≥ 99 % der SLO-Intervalle erreicht; Nutzung des Fehlerbudgets zur Priorisierung.

• Nutzerzufriedenheit: CSAT ≥ 4/5 oder NPS ≥ +20; Adoptionsquote mobiler Apps ≥ 80 % der Zielgruppe.

• Qualitätskultur: Automatisierungsgrad der Regressionstests ≥ 80 %; Rückgang wiederkehrender Incidents um ≥ 20 %/Jahr.

• Anforderung: Normenbezug aufgenommen? Messbare Kriterien je Anforderung? Datenschutzfolgenabschätzung erforderlich? Data-Owner benannt?

• Auswahl: PoC-Szenarien abgedeckt? GEFMA-444-Modulprüfung? 27001-Zertifikat/SoA vorgelegt? Exit-Szenario demonstriert?

• Konfiguration/Integration: Coding-Standards eingehalten? Trennung Konfiguration vs. Code? Schnittstellenvertragsversionen dokumentiert? Secrets-Handling geprüft?

• Test/Abnahme: Testabdeckung ausreichend? Security/Privacy-Tests bestanden? DQ-Reports ohne Blocker? UAT durch Fachbereiche signiert?

• Betrieb: Monitoring/SIEM angebunden? Backup/Restore getestet? Access-Rezertifizierung durchgeführt? Notfallübungen dokumentiert?

• DSGVO-konforme Anonymisierung/Pseudonymisierung produktionsnaher Datensätze.

• Synthetische Datengeneratoren für Grenzfälle (Massendaten, IoT-Bursts, seltene Fehlercodes).

• Goldene Referenzdatensätze für Migrationen (IFC/COBie/CAFM-Connect) mit bekannten Soll-DQ-Werten.

• Statisch: Anforderungs-Reviews, Architektur-/Code-Reviews, Sicherheits-Design-Reviews.

• Dynamisch: Unit, Integration, System, E2E, UAT; Performance-/Lasttests; Chaos-/Failover-Tests; Security (SAST/DAST/IAST), Privacy-Tests (RBAC/ABAC, Löschung).

• Data-Quality-Prüfstrecken: automatisierte Validatoren in ETL/Streams, Quarantäne bei Regelverletzung, manueller 4-Augen-Review für kritische Korrekturen.

• „Bei 1 Mio. Räumen und 5 Mio. Assets liefert die Suche nach Raum-ID im p95 ≤ 1,5 s; keine Timeouts.“

• „COBie-Import erfüllt Pflichtfelder zu 99,5 %; referenzielle Integrität ohne Fehler; Abweichungen < 0,5 % mit dokumentierten Korrekturen.“

• „Rollen ‚Techniker‘ kann keine personenbezogenen Reports exportieren; jeder Export wird protokolliert und erfordert Freigabe.“

• „Fehlgeschlagene BACnet-Konnektivität löst innerhalb von 60 s ein Ticket P2 mit Eskalationspfad aus.“

• Testplanung: R = QA-Lead/Application Manager; A = FM-Leitung; C = Fachbereiche, IT/Security; I = Einkauf/Recht.

• DQ-Gates: R = Data Stewards; A = Data Owner; C = Integrator, Fachbereiche; I = FM-Leitung.

• Security-Tests: R = ISB/Security Team; A = CISO; C = Hersteller/Integrator; I = Fachbereiche.

• UAT: R = Product Owner je Fachbereich; A = FM-Leitung; C = QA-Lead; I = IT-Betrieb.

• Abnahme: R = Projektleitung; A = Lenkungskreis; C = Recht/DSB/ISB; I = Stakeholder.

• Testprotokolle mit Traceability auf Anforderungen (RTM-Verlinkung).

• Messberichte nach 25023 (Methodik, Messumgebung, Ergebnisse, Abweichungen).

• DQ-Scorecards, Migrationsprotokolle, Reconciliation-Berichte.

• Security-Evidenzen: Pen-Test-Reports, Vulnerability-Listen mit SLA-Status, SoA/27001, Secure-SDLC-Nachweise.

• Betriebsnachweise: Monitoring-Screenshots, SLO-Reports, Backup-/Restore-Protokolle, Notfallübungsberichte.

• Systemausfall/Service-Degradation (z. B. Datenbank, Netzwerk, Cloud-Region).

• Integrationsfehler (ERP-Buchungsabbrüche, IoT-Ingestion-Backlog, BMS-Gateway-Ausfall).

• Datenqualitätsdrift (Fehlerhafte Migration, unkontrollierte Stammdatenpflege).

• Cyberangriffe (Phishing, Ransomware, API-Missbrauch, Supply-Chain).

• Datenschutzvorfälle (unberechtigte Zugriffe, fehlerhafte Exporte, fehlgeschlagene Anonymisierung).

• Release-/Change-Risiken (Fehlkonfiguration, Regressionen).

• Vendor-Lock-in/Abhängigkeiten (Proprietäre Formate, fehlende Exit-Strategien).

• OT-Sicherheitsrisiken (unsichere Protokolle, geteilte Anmeldeinformationen, Zonendurchbrüche – ISO/IEC 62443-Bezug).

• Bewertung nach Eintrittswahrscheinlichkeit und Auswirkung (Sicherheits-, Compliance-, Betriebs-, Finanz- und Reputationsschaden).

• Schutzbedarfsfeststellung (Vertraulichkeit/Integrität/Verfügbarkeit) pro Informationsverbund.

• Szenario-Analysen (z. B. Region-Failover, Massen-Ticketflut, kompromittiertes Service-Konto).

• Vermeiden (Scope-Anpassung), Reduzieren (Kontrollen), Übertragen (Versicherung/Vertrag), Akzeptieren (bewusst, dokumentiert).

• Kontrollen (Auswahl):Verfügbarkeit: HA/DR-Architektur, Rate-Limiting, Backpressure, Graceful Degradation.

• Verfügbarkeit: HA/DR-Architektur, Rate-Limiting, Backpressure, Graceful Degradation.

• Integrität: Transaktionslogs, Checksummen, Quarantänepfade, Vier-Augen-Prinzip.

• Sicherheit: Zero-Trust, Härtungsstandards, Secrets-Management, Netzsegmentierung, PAM/MFA.

• Datenschutz: Data Minimization, Pseudonymisierung, Export-Freigabeprozesse, Data Loss Prevention.

• Qualität: DQ-Gates, Pflichtfeldprüfung, Dublettencheck, Katalogpflege.

• Key Risk Indicators (KRIs): SLO-Verletzungen, Anstieg fehlgeschlagener Logins, Patch-Rückstände, DQ-Index < 95 %, IoT-Lag > 60 s, nicht geprüfte Backups.

• Regelmäßige Risiko-Reviews im Governance-Board; Aktualisierung des Risikoregisters; Lessons Learned aus Incidents.

• Kritische Geschäftsprozesse definieren (z. B. Störungsannahme/Tickets, Zutrittsverwaltung, gesetzliche Prüfpflichten).

• Zielgrößen: RTO/RPO je Prozessklasse (z. B. P1: RTO ≤ 2 h, RPO ≤ 15 min; P2: RTO ≤ 8 h, RPO ≤ 1 h).

• Redundanz: Multi-AZ/Region, aktive/aktive oder aktiv/passiv; DNS-Failover, Traffic-Shaping.

• Daten: Replikation synchron/asychron; regelmäßige Validierung der Replikationslatenz und Konsistenz.

• Komponenten: Second-Site für Datenbanken, Message-Broker, Filespeicher; Ersatz-BMS-Gateways mit vorinstallierten Zertifikaten.

• Runbooks: Schritt-für-Schritt-Anleitungen für Szenarien (DB-Ausfall, API-Gateway-Ausfall, CDE-Ausfall, BMS-Disconnect).

• Übungen: Mindestens halbjährliche DR-Tests (Tabletop und Volltest), dokumentierte Ergebnisse, Maßnahmenableitung.

• Messgrößen: Erfolgsquote DR-Tests ≥ 95 %; Abweichung tatsächliches RTO/RPO ≤ 20 % vom Ziel; Mean Time to Recovery in Übungen abnehmend.

• Krisenstab: Zusammensetzung, Rollen (Incident Commander, Kommunikation, Fachverantwortliche).

• Kommunikation: Vorlagen/Checklisten, Meldeketten, Behörden-/Kundennotifikation (DSGVO-72-h-Regel).

• Manuelle Fallbacks: Papier-Ticketannahme, lokale Zutrittsfreigaben, priorisierte Datenexports; spätere digitale Nachführung.

• Isolationsmaßnahmen (Accounts, Netze), forensische Sicherung, Beweissicherung.

• Koordination mit CERT/BSI bei KRITIS-Bezug; Lessons Learned in Secure-SDLC aufnehmen.

• Kontrolle und Compliance: Bedarf an Datenhoheit, Mandantentrennung, Auditierbarkeit (DSGVO/KRITIS), Anpassung an interne Policies/ISMS.

• Flexibilität und Differenzierung: Einzigartige Prozesse/Regelwerke (z. B. spezifische HSE-/KRITIS-Anforderungen), Release-Unabhängigkeit, Roadmap-Einfluss.

• Time-to-Value und Innovationsgeschwindigkeit: Verfügbarkeit von Features (Mobile, IoT, Analytics), Update-Kadenz, „Evergreening“.

• Ressourcen und Kompetenzen: Verfügbarkeit von Architektur-, DevSecOps-, Daten- und Domänenexpertise (BIM/IFC/COBie, BACnet/MQTT).

• Risiko und Resilienz: Abhängigkeit von Lieferanten (Lock-in), Sicherheit (27001/62443), Notfall-/Wiederanlauf.

• Wirtschaftlichkeit: TCO/ROI über 5–10 Jahre (Lizenz/SaaS, Implementierung, Betrieb, Schulung, Nacharbeit durch Qualitätsmängel).

• Eigenleistung, wenn hochspezifische Prozesse, strikte Datenlokalisierung oder tiefe OT-Integration unter 62443 dominieren und intern stabile DevSecOps-Fähigkeiten vorhanden sind.

• Standard/SaaS, wenn marktübliche Prozesse überwiegen, schnelle Wertrealisierung und kontinuierliche Innovation wichtig sind und Audits/Compliance durch Anbieter belegbar sind.

• Hybrid, wenn Standard als Kern dient, ergänzt um eigenentwickelte Services/Regeln (Low-Code/Pro-Code-Erweiterungen, Integrationsplattform) an klaren Schnittstellen.

• Maximale Kontrolle über Architektur, Daten, Release-Zyklen; maßgeschneiderte Abbildung von FM-Spezifika.

• Potenziell geringerer Lock-in, wenn offene Standards (IFC/COBie, CAFM-Connect) und offene Schnittstellen konsequent genutzt werden.

• Security-by-Design entlang des eigenen ISMS und 62443-Zonenkonzepts.

• Hohe Fixkosten (Team-Aufbau, Tooling, 24/7-Betrieb), Rekrutierung/Bindung knapper Skills.

• Innovationsdruck (Mobile, Analytics, KI, Regulatorik) dauerhaft selbst zu schultern.

• Qualitäts- und Sicherheitsnachweise (25010/25023/27001) sind eigenverantwortlich zu erbringen.

• Klare Produktverantwortung (Product Owner), Roadmap, Budget und SLAs.

• CI/CD, Testautomatisierung, Observability, Security-Gate (SAST/DAST/SBOM).

• Daten-/Metadaten-Governance (ISO/IEC 25012) mit Data Stewards.

• Schneller Einsatz, funktionsreife Module (GEFMA-444-Abdeckung), regelmäßige Releases.

• Skaleneffekte im Betrieb (Verfügbarkeit, Performance, Security), Zertifizierungen (ISO/IEC 27001, ggf. 27017/27018; SOC 2).

• Planbare Kostenmodelle, Support- und Ökosystemvorteile (Integratoren, Add-ons).

• Roadmap-Abhängigkeit, Anpassungsgrenzen; potenzieller Vendor-Lock-in.

• Erhöhter Aufwand für Datenschutz-/Sicherheitsprüfung (Subprozessoren, Datenstandorte).

• Multi-Tenant-Restriktionen für Schemata/Custom Code.

• Verankerung von Datenportabilität (Export in IFC/COBie/CSV/JSON), dokumentierten APIs, Mappings; Exit-Klauseln.

• PoC mit ISO-25023-Messung kritischer Qualitätsattribute (p95-Antwortzeiten, DQ-Index, Ausfalltests).

• Governance für Customizing (Konfiguration vor Code; Erweiterungen nur über stabile Public APIs).

• Einmalig: Analyse/Lastenheft, Implementierung/Customizing, Migration (IFC/COBie/CAFM-Connect), Schulungen, PoC/Tests.

• Laufend: Lizenzen/SaaS-Gebühren, Betrieb (Hosting, Monitoring, Backup), Support, Weiterentwicklung, Audits, Security-Pflege.

• Qualitätskosten: Prävention (Tests/Automation), Prüfung (Audits, DQ-Gates), Fehler (Nacharbeit, Ausfälle, Datenschutzfälle).

• Produktivitätsgewinne (Usability, Automatisierung), geringere Ausfallzeiten (Zuverlässigkeit), schnellere Änderungen (Wartbarkeit), reduzierte Integrationsaufwände (Kompatibilität).

• Vermeidete Risiken/Strafzahlungen (DSGVO, KRITIS) durch nachweisbare Sicherheit/Auditierbarkeit.

• Fachliche Eignung: GEFMA-444-Zertifizierung oder funktionsäquivalente Nachweise; Referenzen in DACH, insbesondere in Ihrer Branche/Größe.

• Qualität/Sicherheit: Nachweise nach ISO/IEC 27001 (SoA), Penetrationstest-Berichte, Secure-SDLC-Prozess; für OT-nahe Gateways 62443-Bezug.

• Daten/Interoperabilität: Unterstützung IFC/COBie, CAFM-Connect; API-Dokumentation, Versionierungsstrategie; Export/Exit-Fähigkeit.

• Service/Betrieb: SLA-Ziele, Supportmodell (L1–L3), Release-Politik (LTS), RPO/RTO, Change-Transparenz.

• Wirtschaft/Bonität: Stabilität, Roadmap, Investitionsfähigkeit; Partnernetz (Integrator-Ökosystem).

• RFI/RFP mit gewichteter Bewertungsmatrix; Security-/Privacy-Fragebogen; Due-Diligence (Finanzen, Recht, Technik).

• Referenzinterviews, Site-Visits, PoC mit messbaren Kriterien nach ISO/IEC 25023.

• Risiko- und Lock-in-Bewertung inkl. Datenportabilitätstest.

• Klare SOWs (Scope, Artefakte, Akzeptanzkriterien, Meilensteine); Zeit- & Material vs. Festpreis je Risikoprofil.

• RACI und Sprint-/Meilenstein-Reviews; Definition of Ready/Done; Abnahme-Gates (Test-/DQ-Nachweise).

• KPI-basiertes Lieferantencontrolling (Termintreue, Defektdichte, Change-Failure-Rate, Dokumentationsqualität).

• ISO-25000-Kriterien: Referenz auf ISO/IEC 25010; Ziel-/Grenzwerte gem. ISO/IEC 25023, z. B.: Verfügbarkeit ≥ 99,9 % (kritische Services ≥ 99,95 %); definierte Wartungsfenster.

• Performance: p95 Antwortzeit Kerntransaktionen ≤ 2 s; p99 ≤ 5 s; IoT-Ingestion-Lag p95 ≤ 60 s.

• Zuverlässigkeit: Fehlerrate < 0,1 %/1.000 Transaktionen; MTTR P1 ≤ 2 h; Change-Failure-Rate ≤ 15 %.

• Benutzbarkeit: SUS ≥ 75; Task Success ≥ 90 % für definierte Use-Cases.

• Wartbarkeit: Patch-Zyklen definiert; Lead Time for Change Median ≤ 7 Tage für Konfigurationen.

• Sicherheit: 0 kritische/hohe Findings bei Go-Live; Patch-SLA für kritische CVEs ≤ 14 Tage; MFA für Admins 100 %.

• Datenqualität (ISO/IEC 25012): DQ-Index ≥ 95 %; Pflichtfelder ≥ 99 %; 100 % referentielle Integrität nach Migrationen.

• AV-Vertrag nach DSGVO, TOM-Anhänge (Art. 28/32), Subprozessor-Liste und Genehmigungspflicht, Datenstandorte/-residenz.

• Betroffenenrechte: Export-/Lösch-APIs, Fristen, Nachweise; DPIA-Unterstützung.

• Archivierung/Aufbewahrung: Rechtskonforme Retention, WORM, Legal Hold.

• ISMS-Nachweise (27001 Zertifikat/SoA), jährliche unabhängige Pen-Tests inkl. Executive Summary für Auftraggeber; SBOM-Bereitstellung.

• 62443-Zonen/Conduits für OT-Schnittstellen; Konfigurationshärtung und Fernzugriffsregeln.

• Recht auf Audits (fachlich/technisch/Security) 1× jährlich und anlassbezogen; Einsichtsrechte in Policies/Prozesse/Reports; angemessene Vorlaufzeiten.

• SIEM-/Log-Zugriff für Mandantenrelevantes; KPIs/SLA-Reports monatlich; Roadmap-Transparenz und End-of-Life-Mitteilungen.

• KPI-Set im Vertrag verankern (SLA-Erfüllung, MTTR, p95-Latenz, DQ-Index, Change-Erfolgsquote, Ticket-FTR).

• Service Credits bei SLA-Verletzungen; Bonus bei übertroffenen Zielen oder schneller Behebung kritischer Schwachstellen.

• Vollständiger Datenexport in offenen Formaten (IFC/COBie/CSV/JSON, Dokumente in Original/PDF-A), inkl. Metadaten/IDs.

• Übergabe von Konfigurationen/Skripten; Unterstützung beim Übergang (definierte Stunden/Kosten); Lösch-Bestätigungen.

• Trennung Standard vs. kundenspezifische Artefakte; Nutzungsrechte am Custom Code; bevorzugt Konfiguration vor Code.

• Code-Escrow nur bei On-Prem/Kernabhängigkeiten.

• Analyse und Anforderungsmanagement (inkl. ISO-25000-Qualitätskriterien)

• Implementierung/Customizing, Schnittstellen, Datenmigration (IFC/COBie, CAFM-Connect)

• Hardware/Plattform (bei On-Prem/Private Cloud)

• Schulungen, Change-Enablement, Test/Abnahme (PoC, UAT, Performance/Security-Tests)

• Lizenzen/SaaS-Gebühren, Wartung/Support

• Betrieb (Hosting, Monitoring, Backup/Restore, Security-Pflege)

• Weiterentwicklung (Releases, Konfigurationsänderungen, neue Integrationen)

• Datenpflege und Datenqualitätsmanagement (Data Stewards, DQ-Gates)

• Audits/Compliance (DSGVO, ISO/IEC 27001, ggf. 62443; Rezertifizierungen)

• Effizienzeinbußen durch Wartezeiten und Medienbrüche

• Reibung bei Dienstleistersteuerung (fehlende Transparenz, Nacharbeit)

• Prävention (gewollt): Investitionen in Qualitätssicherung (z. B. Testautomatisierung, Datenqualitätsregeln, Secure-SDLC). Diese Kosten senken erwartete Fehlerfolgekosten.

• Prüfung (gewollt): Abnahmen, Audits, DQ-Monitoring, Pen-Tests, PoCs.

• Interne Fehler (vermeidbar): Nacharbeit von Migrationen, Hotfixes, Rollbacks, Performance-Tuning, Re-Konfiguration, Doppelarbeiten wegen Dateninkonsistenzen.

• Externe Fehler (teuer/vermeidbar): Ausfallzeiten, SLA-Verletzungen (Service Credits), Gewährleistungsfälle, Vertragsstrafen, Compliance-/Datenschutzverstöße, Reputationsschäden.

• Ausfallzeiten kritischer Module (Ticketannahme, Zutrittsverwaltung) mit Folgekosten in Technikerdisposition, Sicherheits- und Produktionsprozessen.

• Niedrige Usability führt zu langen Bearbeitungszeiten, Fehlern und geringer Adaption (teure Schattenprozesse).

• Schlechte Datenqualität (ISO/IEC 25012) verursacht Fehlplanungen, Fehleinsätze und Auditabweichungen (BetrSichV, ArbSchG).

• Hohe technische Schuld erhöht Änderungs- und Testaufwände, verlängert Release-Zyklen und verlangsamt Innovation.

• Leistungseffizienz und Zuverlässigkeit

• Geringere Wartezeiten (Produktivität in Disposition, Helpdesk, Field-Service)

• Höhere Verfügbarkeit (weniger Stillstandskosten, geringere Service-Credits)

• Planbare Kapazität (weniger Überprovisionierung)

• Kürzere Einarbeitungszeiten, höhere First-Time-Right-Quoten

• Höhere Adaption mobiler Prozesse (mehr digitale Rückmeldungen, weniger Papier)

• Vermeidung von Datenschutzvorfällen und KRITIS-Risikoprämien

• Schnellere Auditdurchläufe, weniger Nacharbeiten

• Bessere Entscheidungsqualität (CAPEX/OPEX, Energiemanagement)

• Geringere Rückfragen/Nacharbeiten (Prüfpflichten, HSE-Nachweise)

• Organisation mit 30 Standorten, 1.200 Anwendern (davon 250 Techniker), 1 Mio. m² BGF, 600k Tickets/Jahr.

• Umstieg auf SaaS-IWMS mit Qualitätsfokus (ISO-25000), Standardintegration ERP/SSO, IoT-Anbindung für Alarme/Energie.

• Einmalig Jahr 0/1: Implementierung/Migration 1,2 Mio., Integrationen 0,4 Mio., Schulung/Change 0,2 Mio. → total 1,8 Mio.

• Laufend: SaaS 0,6 Mio./Jahr, Betrieb/Support/Weiterentwicklung 0,5 Mio./Jahr, DQ/QA/Audits 0,2 Mio./Jahr → 1,3 Mio./Jahr.

• Produktivität Helpdesk/Disposition: −20 s Bearbeitungszeit pro Ticket durch bessere Usability/Automatisierung. 600k Tickets × 20 s = 12.000 h/Jahr. Mit Vollkosten 55 €/h → 0,66 Mio./Jahr.

• Field-Service: +8 % First-Time-Fix (bessere Daten/Checklisten), −5 % Fahrtzeiten (optimierte Routen/Indoor-Karten). Zeitersparnis 10.000 h/Jahr × 60 €/h → 0,6 Mio./Jahr.

• Verfügbarkeit/Performance: −50 % ungeplante Ausfallzeiten (von 10 h auf 5 h/Jahr) bei 2.000 Nutzern à 45 €/h Opportunitätskosten → 0,45 Mio./Jahr.

• Datenqualität: −30 % Nacharbeiten bei Migration/Integration und −25 % Stammdatenfehler → 0,25 Mio./Jahr (operative Einsparungen, weniger Auditabweichungen).

• Compliance/Security: Vermeidete Service-Credits/Audit-Nacharbeiten und gesenkte Versicherungsprämien → 0,15 Mio./Jahr.

• Payback nach ca. 2,2 Jahren (1,8 Mio. / 0,81 Mio.).

• ROI Jahr 3–5 jeweils ~ 62 % (0,81 / 1,3).

• Kapitalwert (5 Jahre, 7 % Diskont, gleichbleibender Netto-Nutzen): NPV ≈ 0,81 × (4,100) − 1,8 ≈ 1,52 Mio. (vereinfachte Annahme).

• Worst-Case (nur 50 % der Zeiteffekte realisiert): Netto-Jahresnutzen ~ 0,405 Mio. → Payback ~ 4,4 Jahre.

• Best-Case (+30 % mehr Effekte durch hohe Adaption): Netto-Jahresnutzen ~ 1,05 Mio. → Payback ~ 1,7 Jahre.

• Rollenbasierte Oberflächen und geführte Prozesse reduzieren Klicks, Suchzeiten und Fehlbedienung.

• Mobile-First/Offline-Fähigkeit steigert die Rückmeldequote und Datenfrische im Field-Service.

• Pflichtfeld-, Plausibilitäts- und Dublettenprüfungen verhindern teure Nacharbeiten.

• Einheitliche Kataloge/Klassifikationen beschleunigen Analysen (Energie, CAPEX-Planung) und Ausschreibungen.

• Konfiguration statt Code, automatisierte Tests, entkoppelte Schnittstellen senken Änderungszeiten und Ausfallrisiken.

• Standardisierte Schnittstellen (IFC/COBie, CAFM-Connect, OpenAPI) reduzieren Integrationsaufwände und erleichtern Lieferantenwechsel (Portabilität).

• HA/DR-Design, Lastmanagement und Observability reduzieren MTTR und vermeiden Folgekosten bei Major Incidents.

• Durchgängige Auditierbarkeit und Automatisierung (z. B. Löschprozesse) senken Prüfkosten und vermeiden Strafzahlungen.