CAFM: Datenmodell und Objekt-/Flächen-/Asset-Struktur

Ein zentrales Element des CAFM-Datenmodells ist die objekt- und flächenbezogene Hierarchie. Sie bildet die räumliche Struktur der Immobilien und Anlagen ab, typischerweise vom Großen ins Kleine.

• Standort/Liegenschaft: Die oberste Ebene bezeichnet das Grundstück oder das Ensemble von Gebäuden. Eine Liegenschaft repräsentiert das bebaute/unbebaute Grundstück und die Eigentumsverhältnisse. Oft entspricht dies einem Campus, Werksgelände oder einer geografischen Liegenschaft.

• Gebäude: Darunter folgen die einzelnen Gebäude an einem Standort. Jedes Gebäude wird als eigenständiges Objekt mit eigenen Attributen erfasst (Adresse, Baujahr, Gebäudetyp etc.). Falls ein Standort nur ein Gebäude hat, decken sich Standort- und Gebäudeebene weitgehend.

• Gebäudeteil (optional): In vielen Fällen werden Gebäude weiter in Gebäudeteile oder Trakte untergliedert – etwa verschiedene Flügel, Bauteile oder Nutzungseinheiten eines großen Gebäudekomplexes. Diese Ebene ist besonders in komplexen Gebäuden sinnvoll, um Struktur zu schaffen (z. B. „Altbau“ vs. „Neubau“ oder verschiedene Mieterbereiche).

• Etage/Geschoss: Jedes Gebäude oder jeder Gebäudeteil gliedert sich in Geschosse (Stockwerke). Die Etagen werden meist von oben nach unten oder unten nach oben durchgezählt (inkl. Kellergeschosse, Dachgeschosse etc.). Diese Ebene ist wichtig für die Verortung von Räumen und Flächen sowie zur Bezugnahme auf Geschosspläne.

• Raum/Fläche: Die unterste räumliche Ebene bilden die Räume bzw. Flächen. Ein Raum ist ein in sich abgeschlossener Bereich (durch Wände/Decken begrenzt) mit einer eigenen Raumnummer. In CAFM werden hier alle räumlichen Einheiten erfasst – Büros, Hallen, Labore, Verkehrsflächen, Sanitärräume usw. Falls offene Bereiche erfasst werden müssen (z. B. Parkplatzflächen, Flure als Flächen ohne Wände), können diese ebenfalls als Flächenobjekte in dieser Ebene abgebildet werden. Ein Raumobjekt erhält Attribute wie Raumnummer, Raumname, Nutzungsart und Fläche in m². Diese Raum- bzw. Flächenebene ist die letzte Topologie-Stufe der räumlichen Struktur.

• Asset/Anlage: Jenseits der reinen Raumhierarchie werden im CAFM technische Anlagen und Assets verwaltet. Diese werden in der Regel einem Raum oder Standort zugeordnet, haben aber ihre eigene Objektstruktur. Ein Asset kann z. B. eine technische Anlage (Heizkessel, Lüftungsgerät), ein Ausstattungsgegenstand (Kopierer, Möbel) oder eine Infrastrukturkomponente (Aufzug, T GA-System) sein. Assets können hierarchisch weiter untergliedert sein – etwa eine Anlage, die aus mehreren Komponenten besteht.

• Komponente/Baugruppe: Viele Anlagen setzen sich aus Komponenten zusammen. Beispielsweise besteht eine „HKL-Anlage“ aus Komponenten wie Pumpe, Motor, Ventil usw. Im Datenmodell können daher Assets als übergeordnete Objekte mit untergeordneten Komponentenobjekten abgebildet werden. Dies ermöglicht eine genaue Abbildung von Stücklisten, Ersatzteilen und Wartungseinheiten.

Die obige Hierarchie ist flexibel anpassbar an den konkreten Anwendungsfall. In einem kleineren Gebäudebestand kann man ggf. auf die Ebene Gebäudeteil verzichten, während in einem großen Campus noch eine Ebene “Liegenschaftsgruppe” darüber eingeführt werden könnte. Wichtig ist, dass diese Top-down-Struktur einmalig festgelegt und dann stringent genutzt wird. Sie erlaubt es, jedes Objekt eindeutig im Kontext zu verorten (z. B. Standort A – Gebäude X – 1.OG – Raum 101 – Asset ABC).

Standards empfehlen diese klare Objekt- und Flächenhierarchie. So definieren viele CAFM-Richtlinien eine Struktur Liegenschaft > Gebäude > Ebene > Raum als Mindeststandard. Ein Beispiel ist das CAFM-Connect Datenaustauschformat, das in Version 1.0 Raumdaten exakt in dieser Hierarchie übergibt (Liegenschaft, Gebäude, Etage, Raum). In Version 2.0 von CAFM-Connect wurden ergänzend Anlagen- und Ausstattungsdaten hinzugefügt, sodass auch Assets übertragbar sind. Dies zeigt, dass die Kombination aus räumlicher Hierarchie und Anlagenstruktur als Best Practice gilt, um FM-Daten abzubilden.

Es schafft die hierarchische Struktur eine übersichtliche Baumstruktur aller verwalteten Objekte. Sie ermöglicht es, schnell vom Großen (Standort/Gebäude) ins Kleine (Raum/Asset) zu navigieren und Abhängigkeiten abzuleiten. Prozesse wie Flächenmanagement, Reinigung, Instandhaltung oder Umzüge lassen sich so gezielt auf den jeweiligen Ebenen verankern.

• DIN 277 (Grundflächen und Rauminhalte im Bauwesen): Diese Norm definiert Kategorien von Flächen und Räumen sowie deren Berechnung. Insbesondere werden Flächentypen wie Nettogrundfläche (NGF), Bruttogrundfläche (BGF), Nutzungsflächen (NUF) etc. beschrieben. Im CAFM-Kontext dient DIN 277 als Grundlage für das Flächenmanagement: Räume werden nach ihrer Nutzungsart klassifiziert (z. B. NUF 1 Bürofläche, NUF 6 Verkehrsfläche) und Flächenberechnungen einheitlich durchgeführt. Best Practice ist, die Raumarten und Nutzungsarten im CAFM an DIN 277 anzulehnen, damit z. B. Auswertungen von Büro- vs. Technikflächen konsistent sind. Viele CAFM-Systeme unterstützen die Hinterlegung von DIN-277-Kategorien pro Raum.

• DIN 276 (Kosten im Bauwesen): Diese Norm gliedert die Kosten von Bauwerken in Kostengruppen (KG 100–700 für Bauwerkskosten, 800 für Baunebenkosten). Im Betrieb wird DIN 276 genutzt, um Kostenstrukturen auch im FM zu klassifizieren. Beispielsweise werden technische Anlagen häufig mit ihrer entsprechenden Kostengruppe versehen (etwa gehört eine Heizungsanlage zur KG 420 – Wärmeversorgungsanlagen). Dadurch kann im CAFM eine Anlage kostenmäßig eingeordnet werden und z. B. bei der Budgetplanung oder beim Controlling der Bezug zu Baukosten oder Instandhaltungskosten pro Kostengruppe hergestellt werden. CAFM-Standards wie CAFM-Connect nutzen DIN-276-Kostengruppen als Attribut, um eine gemeinsame Basis für Kostendaten zu haben.

• GEFMA 924 (Datenmodell, Kataloge und Ordnungsrahmen für FM): Die Richtlinie GEFMA 924 liefert ein herstellerneutrales, datenbanktaugliches Strukturmodell für FM-Daten. Darin werden einheitliche Strukturen und Kataloge vorgeschlagen, u. a. für Gebäudearten, Facilities, Lebenszyklusphasen, Prozesse, Dokumentarten, Rollen und Qualifikationen. Besonders relevant für die Objekt-/Flächenstruktur sind der Katalog der Bauwerkstypen (Teil 1) und der Katalog der Facilities (Teil 2) in GEFMA 924. Diese enthalten standardisierte Begriffe und Nummern für Gebäude- und Anlagenklassen, an denen man sich orientieren kann. GEFMA 924 verfolgt den OpenBIM-Ansatz und definiert Daten und ihre Beziehungen, damit sie lebenszyklusübergreifend nutzbar sind. Obwohl GEFMA 924 (Stand 2017) noch als „Positionspapier“ gilt und nicht verbindlich ist, hat es sich in der Praxis bewährt und fließt z. B. ins CAFM-Connect-Datenformat ein. So werden Lebenszyklusphasen und Bauwerkstypen nach GEFMA 924 standardisiert, Räume nach DIN 277 klassifiziert und Dokumente nach GEFMA 198 geordnet, um einen absprechfreien Datenaustausch zu erreichen.

• ISO 19650 (Organisation von Daten zu Bauwerken – Informationsmanagement mit BIM): Diese internationale Normenreihe legt ein Rahmenwerk für das Informationsmanagement über den gesamten Lebenszyklus von Bauwerken fest. Für CAFM ist relevant, dass ISO 19650 auf strukturierte, gemeinsame Datenumgebungen (CDE) und klare Verantwortlichkeiten bei der Datenpflege pocht. Bei der CAFM-Einführung, insbesondere wenn BIM-Daten übernommen werden, sollte gemäß ISO 19650 definiert werden, wer welche Informationen wann liefert (Stichwort AIM – Asset Information Model). Die Norm fordert konsistente Ordnungsstrukturen, Versionskontrolle und den Einbezug aller Beteiligten, was im Kern das CAFM-Datenmodell und seine Pflege betrifft. Sie liefert allerdings keine konkreten Objektkataloge – dafür greift man auf nationale Standards (DIN/GEFMA) zurück.

• Weitere Richtlinien: Es existieren zudem branchenspezifische Empfehlungen, z. B. GEFMA 430 für Datenmanagement in CAFM (betont Datenstruktur und -qualität), GEFMA 444 (CAFM-Softwarezertifizierung, fordert bestimmte Datenstrukturen), DIN EN ISO 41011 (FM-Begriffe) und DIN EN 15221 (europäische FM-Normen). Auch VDI 2552 (BIM Richtlinienreihe) ist relevant, da dort Anforderungen an AIA (Auftraggeber-Informationsanforderungen) definiert sind, die letztlich bestimmen, welche Objektdaten ins CAFM fließen sollen. Für technische Anlagen gibt es mit VDMA 24186 Checklisten, welche Stammdaten pro Gewerk erfasst werden sollten (z. B. bei einer Lüftungsanlage: Luftleistung, Motorleistung etc.). Solche Dokumente können helfen, das CAFM-Datenmodell im Detail auszugestalten.

In der Praxis empfiehlt es sich, die eigene Objektstruktur so weit wie möglich an diesen Standards auszurichten. Beispielsweise könnte man für die Raumhierarchie DIN-konforme Bezeichnungen verwenden (z. B. Geschoss: „EG“, „OG1“ etc. gemäß interner Regel), für Flächentypen die DIN-277-Schlüssel (NUF1–NUF7) als Auswahlliste im CAFM hinterlegen, bei Anlagen die Kostengruppe (DIN 276) und ggf. eine Anlagengruppe gemäß einem standardisierten Katalog speichern. Dadurch wird die Datenbasis kompatibel mit Austauschformaten und anderen Systemen. Zudem schafft man eine gemeinsame Verständigungsgrundlage: alle Beteiligten (Architekten, FM, Dienstleister) meinen das Gleiche, wenn von „Nutzfläche“ oder „KG 410“ die Rede ist.

Neben der hierarchischen Gliederung benötigen CAFM-Daten inhaltliche Klassifikationen, um Objekte nach bestimmten Kriterien zu gruppieren und auszuwerten.

• Gebäudetypen: Kategorisierung der Gebäude nach Nutzung oder Bauart. Beispiele: Bürogebäude, Produktionshalle, Lager, Schule, Krankenhaus, Wohngebäude etc. Ein solcher Katalog ermöglicht es, FM-Kennzahlen (wie Reinigungsaufwand oder Energieverbrauch) nach Gebäudetyp zu vergleichen. GEFMA 924-1 stellt hierfür einen Katalog der Bauwerkstypen bereit. Ein Gebäude bekommt z. B. den Typ „Verwaltungsgebäude“ oder „Parkhaus“ zugewiesen. Oft ist diese Klassifikation 1:1 mit der Hauptnutzung des Gebäudes verknüpft.

• Raumarten / Flächennutzungen: Jeder Raum sollte eine definierte Nutzungsart haben. DIN 277 unterscheidet z. B. Hauptnutzflächen (HF) in Kategorien wie Büro, Produktion, Wohnen, Schule, etc., sowie Nebennutzflächen, Verkehrsflächen, Technikflächen. In vielen CAFM-Systemen gibt es Raumart-Schlüssel oder Nutzungsart-Felder, die aus einer festen Liste gewählt werden. Beispiele: Büroarbeitsplatz, Besprechungsraum, Labor, Flur, Sanitärraum, Technikraum, Archiv, Garage. Einheitliche Raumarten sind wichtig für Flächenberechnungen (z. B. Mietfläche vs. Allgemeinfläche) und für die Zuordnung von Verantwortlichkeiten (etwa Reinigung nach Raumart). GEFMA 100-2 (Leistungsspektrum FM) und GEFMA 130 liefern Hinweise zur Definition von Raumkategorien im Flächenmanagement. In CAFM-Connect wird z. B. die Raumart nach DIN 277 mitgegeben („Räume nach DIN 277“).

• Anlagenarten (Asset-Typen): Technische Anlagen und Inventar werden ebenfalls klassifiziert. Ein Anlagenarten-Katalog listet z. B. alle Geräteklassen: Heizung, Lüftung, Klima, Elektro, Fördertechnik, Maschinen, Fahrzeuge, Möbel, IT-Hardware usw. Hier kann ein mehrstufiger Katalog sinnvoll sein: z. B. Obergruppe „TGA-Anlage“, Untergruppe „Lüftungsanlage“, Spezifizierung „Lüftungsgerät mit Wärmerückgewinnung“. Branchenübliche Referenzen sind etwa die Kostengruppe nach DIN 276 (die oft schon grob die Art bestimmt, z. B. KG 420 = Wärmeversorgungsanlagen), oder VDMA/AMEV-Kataloge für gebäudetechnische Anlagen. Eine Katalog der Facilities (GEFMA 924-2) könnte entsprechende Anlagenklassen enthalten. Vorteil einer sauberen Anlagenklassifikation: Man kann Wartungspläne und Prüfpflichten pro Anlagenart standardisieren (z. B. alle „Aufzugsanlagen“ haben gleiche Prüfvorschriften).

• Gewerke (Trades): Jedes Asset bzw. jede Wartungsleistung lässt sich einem Gewerk zuordnen: z. B. Heizungsbau, Elektro, Sanitär, Tischler, Maler, Gartenpflege etc. Ein Gewerkekatalog hilft, Aufträge und Verantwortlichkeiten zu strukturieren (z. B. alle Störungen im Gewerk Elektro werden an die Elektro-Fachabteilung oder den Vertragspartner Elektrotechnik gemeldet). Gewerkeklassifikationen sind oft unternehmensspezifisch, orientieren sich aber an gängigen Handwerks-/FM-Gewerken. Auch hier kann DIN 276 indirekt helfen (Technische Kostengruppen ~ Gewerke).

• Kostengruppen: Wie oben erwähnt, werden Kostengruppen (nach DIN 276) häufig als Attribute von Anlagen, Bauteilen oder Maßnahmen hinterlegt. Dies dient dazu, Kosten im Betrieb der entsprechenden Investitionsgruppe zuzuordnen. Beispielsweise könnte man im Instandhaltungsmodul die Aufwände pro Kostengruppe auswerten (Wieviel kostet das Gewerk 410 Heizung Lüftung im Jahr?). GEFMA 200 (Kosten im FM) empfiehlt einheitliche Kostengliederungen in Anlehnung an DIN 276 und DIN 18960 (Nutzungskosten) für FM-Budgets.

• Raum- und Ausstattungskataloge: In manchen CAFM-Kontexten gibt es definierte Kataloge für Raumausstattungen (z. B. welche Möblierung ist Standard in einem Büroraum Typ X) oder für Gebäudebauteile (Fenster, Türen mit Typisierung). Diese sind jedoch sehr unternehmensspezifisch. Standards wie DIN 277 liefern hier eher Aggregate (z. B. dass ein Büro vorrangig NUF Bürofläche ist, aber nicht welche Möbel drinstehen).

• Lebenszyklusphasen: Nicht direkt eine Objektklassifikation, aber im Datenmodell oft vorgesehen: Die Phase des Objekts im Lebenszyklus (Planung, Bau, Betrieb, Sanierung, Stilllegung). GEFMA 924-3 enthält z. B. einen Katalog der Lebenszyklusphasen (LzPh.). Jedes Datenelement könnte mit einer Phasenkennung versehen werden, was besonders bei BIM-Übergaben wichtig ist (z. B. wird ein Objekt im CAFM als „Bestand“ markiert vs. „in Planung“).

• Dokumentenarten: Auch Dokumente, die Objekten zugeordnet werden (Pläne, Verträge, Handbücher, Prüfprotokolle), sollten nach einem Katalog klassifiziert sein. GEFMA 924-6 bietet etwa einen Katalog der Dokumentenarten. Dies stellt sicher, dass z. B. Wartungsdokumente, Verträge, Rechnungen etc. einheitlich benannt und abgelegt werden. GEFMA 198 gibt in Teil 2 ebenfalls Hinweise zur Dokumentation je Objektart.

Viele dieser Klassifikationen können hierarchisch aufgebaut sein (Baumstrukturen). Ein Beispiel aus der Praxis: Die Klassifizierung nach GEFMA 198 sieht etwa vor, Gebäude, Flächen und technische Objekte in einem Allgemeinen Kennzeichnungssystem (AKS) zu führen. Dabei werden Objekte über Schlüssel codiert, die indirekt auch Klassifikationen erkennen lassen (z. B. ein Raumcode beinhaltet Gebäude- und Geschosskennung; ein Anlagencode enthält Angaben zum Gewerk). Wichtig ist, dass zu Beginn der CAFM-Einführung solche Kataloge definiert oder aus Standards übernommen werden, damit alle Stammdaten konsistent erfasst werden können.

• Logisches Datenmodell (ERM): Dies ist meist eine Entitäts-Beziehungs-Modellierung (Entity-Relationship-Modell), die die Datenobjekte (Entitäten) und deren Beziehungen abstrakt darstellt. Beispielsweise werden Entitäten definiert wie Standort, Gebäude, Geschoss, Raum, Anlage, Komponente, Person, Vertrag, Meldung, Dokument etc., jeweils mit ihren Attributen. Beziehungen (Relationships) zeigen, wie die Entitäten verknüpft sind, z. B. Standort enthält Gebäude, Gebäude enthält Geschosse, Raum gehört zu Geschoss, Anlage ist installiert in Raum, Vertrag betrifft Gebäude, Meldung bezieht sich auf Anlage usw. Ein solches Modell kann man grafisch als ER-Diagramm oder UML-Diagramm darstellen. Es bildet logisch die FM-Welt ab, losgelöst von einer konkreten Software. Das FM-Datenmodell FM-3D, das GEFMA entwickelt hat, definiert z. B. solche Datenbausteine samt ihrer Beziehungen. In Abb. 1 und 2 von GEFMA 924 (laut Artikel) werden diese abstrakten Beziehungen illustriert – vergleichbar mit einem universellen Baukasten von Datenobjekten (LEGO-Prinzip). Dieses konzeptionelle Modell sollte alle benötigten Informationen und Verknüpfungen enthalten, aber noch keine technischen Details (wie Tabellen- oder Feldnamen).

• Physisches Datenmodell (tabellarisch): Dies ist die Implementierung des logischen Modells in einer Datenbank oder Software. Im einfachsten Fall entspricht jede Entität einer Tabelle, jedes Attribut einer Tabellenspalte und jede Beziehung entweder einer Verknüpfung über Schlüssel oder einer Relationstabelle. In einem CAFM-System sind diese Tabellen und Felder meist vordefiniert vom Hersteller (bei Standardsoftware). Beispiel: Es gibt eine Tabelle Building mit Spalten für Gebäude-ID, Name, Adresse, Baujahr, usw.; eine Tabelle Room mit Raum-ID, Bezeichnung, Fläche, Gebäudereferenz, Geschossreferenz, Nutzungsart etc.; eine Tabelle Asset mit Anlagen-ID, Typ, Modell, Seriennummer, Standortreferenz (Raum oder Gebäude), Hersteller, Wartungsintervall, usw. Die Beziehungen sind durch Schlüssel abgebildet – z. B. jeder Raumdatensatz hat ein Feld Gebäude-ID, das auf das Gebäude verweist (foreign key). Ein physisches Datenmodell sollte auch die Integritätsbedingungen einschließen (z. B. „ein Raum muss immer einem Geschoss zugeordnet sein“, „eine Anlage muss eine gültige Kategorie haben“). Dieses Modell kann tabellarisch dokumentiert werden (Datenbankschema). Viele CAFM-Anbieter liefern ein Datenbank-Handbuch, das alle Tabellen und Felder beschreibt. Bei Eigenentwicklungen würde man an dieser Stelle ein SQL-Datenbankschema oder ähnlich entwerfen.

• Semantisches/objektorientiertes Modell: In neueren Kontexten (BIM, Semantic Web) spricht man auch von semantischen Datenmodellen – hier werden Daten als Objekte mit Klassen und Eigenschaften beschrieben, oft in Ontologie-Sprachen oder als objektorientiertes Modell. IFC ist ein Beispiel eines semantischen Gebäudemodells: Es definiert Klassen wie IfcBuilding, IfcSpace, IfcEquipment, mit Attributen und Beziehungen (z. B. IfcBuilding enthält IfcBuildingStoreys, diese enthalten IfcSpaces). Ein CAFM-Datenmodell lässt sich mit einem BIM/Ontologie-Ansatz ebenfalls beschreiben. So könnte man analog Klassen Gebäude, Raum, Anlage, Auftrag, Person definieren mit entsprechenden Properties. Der Vorteil semantischer Modelle ist die Flexibilität bei Erweiterungen und die Möglichkeit, regelbasiert Abfragen zu formulieren („zeige alle Räume, die Klimaanlagen enthalten und >20 m² groß sind“). Allerdings bleibt die CAFM-Praxis meist beim relationalen Schema, ggf. ergänzt um Objektlayer. Dennoch ist es hilfreich, die semantische Struktur zu verstehen – sprich: welche Bedeutung und Beziehungen die Datenobjekte haben – um sie korrekt abzubilden. GEFMA 924 liefert hier eine Art Ontologie für FM-Daten (z. B. welche Objekte es gibt und wie sie zusammenhängen).

• Tabellarische Kataloge: Ein Teil des Datenmodells sind auch die Wertelisten und Kataloge (siehe vorheriges Kapitel). Diese kann man ebenfalls als Tabellen auffassen: z. B. eine Tabelle Raumart_Katalog mit Codes und Bezeichnungen, die dann über einen Code mit der Raumtabelle verknüpft wird (statt Freitext). Solche Katalogtabellen stellen sicher, dass nur gültige, vordefinierte Werte verwendet werden. Im physischen Modell sollten diese als separate Entitäten implementiert werden, um Datenkonsistenz zu gewährleisten (Stichwort Normalisierung).

In der Praxis beginnt man bei der CAFM-Einführung typischerweise mit einem konzeptionellen Modell (Welche Objekte wollen wir verwalten? Welche Beziehungen brauchen wir? Welche Berichte sollen herauskommen?). Dieses Modell wird oft gemeinsam mit dem CAFM-Anbieter gemappt: Welche vorhandenen Module/Tabellen decken das ab, wo braucht es evtl. Erweiterungen? Anschließend folgt die Umsetzung im System, also die physische Datenmodellierung, entweder durch Konfiguration des Systems oder durch Customizing (z. B. zusätzliche Felder anlegen). Wichtig ist, das Modell dokumentiert zu halten – z. B. in Form eines Datenstruktur-Handbuchs für das Projekt.

Häufig erstellt man kleine Teil-Modelle je FM-Prozess (z. B. ein Datenmodell für das Instandhaltungsmanagement mit Anlagen, Wartungsplänen, Prüfterminen und Verantwortlichen). Diese lassen sich aus dem Gesamtmodell ableiten. GEFMA 924 nennt das „FM-3D Datenset“ – eine Zusammenstellung von Datenelementen für einen bestimmten Anwendungsfall. So ein Datenset für z. B. Betreiberpflichten könnte beinhalten: Regelwerk, konkrete Pflicht, Verantwortlicher, Anlage, Prüfdokument, Datum und die Beziehungen dazwischen. Solche Sichten helfen, das große Datenmodell in handhabbare Bereiche zu gliedern, ohne die grundsätzliche Einheitlichkeit aufzugeben.

Jedes Objekt im CAFM-Datenmodell – sei es ein Raum, eine Fläche, eine Anlage oder ein Vertrag – wird durch Attribute (Eigenschaften) beschrieben. Bei der Einführung eines CAFM-Systems muss genau festgelegt werden, welche Attribute erfasst werden, mit welchen Wertebereichen und welcher Verbindlichkeit.

• Pflicht- vs. Kannfelder: Man unterscheidet Muss-Felder, die zwingend für jedes Objekt gefüllt werden müssen, und optionale Felder. Beispiel: Für einen Raum könnten Raumnummer und Raumart Pflichtfelder sein, wohingegen Telefonanschluss oder Raumnutzer optionale Angaben sein können. Pflichtattribute gewährleisten die Mindestdatenqualität, z. B. dass kein Raum ohne Flächenangabe oder keine Anlage ohne Hersteller erfasst wird. In vielen CAFM-Systemen lassen sich Felder als „erforderlich“ markieren oder über Eingaberegeln prüfen. Bei der Attributdefinition sollte man sich fragen: Welche Information ist unverzichtbar, um das Objekt zu identifizieren und seine FM-Prozesse zu bedienen? – Diese Informationen gehören zu den Pflichtfeldern. Alles Weitere kann optional bleiben, um die Dateneingabe nicht zu überfrachten.

• Datenformate und Einheitlichkeit: Jedes Attribut hat ein vordefiniertes Format bzw. Datentyp. Typische Formate sind: Text (für Namen, Beschreibungen), Nummern (für Flächenangaben, Zählerstände), Datum/Uhrzeit (für Baujahr, Wartungsdatum, Vertragslaufzeit), Boolesch/Ja-Nein (für Indikatoren wie „denkmalgeschützt (ja/nein)“), Listenwerte (für Kategorien), ggf. Währungsfelder (Kosten) oder Verweise (für Verknüpfungen). Die Formate sollten konsequent gewählt werden, um spätere Auswertungen zu erleichtern. Beispielsweise ist es sinnvoll, Flächen immer numerisch in Quadratmetern zu speichern (mit Einheitsepfehlung nach DIN 277), Zahlen für Räume oder Kostenstellen ohne Formatierungszeichen (keine Tausenderpunkte etc.), Datumsangaben möglichst mit Uhrzeit oder als eindeutiges Datum im ISO-Format. Einheitliche Maßeinheiten sind wichtig: z. B. Raumhöhe in [m], Massen in [kg] etc., falls solche Attribute erfasst werden.

• Auswahllisten (Controlled Vocabulary): Wo immer möglich, sollten Attribute nicht als Freitext, sondern als vorgegebene Werte geführt werden. Dazu dienen Kataloge/Listen, wie im vorherigen Kapitel beschrieben. Beispiele: Raumart = {Büro, Besprechung, Lager, Flur, …}, Gebäudetyp = {Bürogebäude, Industriehalle, …}, Anlagenstatus = {aktiv, außer Betrieb, in Wartung, außer Dienst gestellt}. Durch Pull-Down-Listen im CAFM wird sichergestellt, dass nur gültige Werte eingetragen werden – das erhöht die Konsistenz (z. B. nicht einmal „Büro“ und ein andermal „Buero“ oder „Office“ geschrieben). GEFMA 924 stellt viele solcher Kataloge bereit, die man übernehmen kann. In CAFM-Connect werden Attribute wie Kostengruppe, Raumart etc. immer nach vordefinierten Listenwerten codiert.

• Statusfelder: Insbesondere für Anlagen und Räume ist es sinnvoll, Statusattribute zu führen. Ein Raum kann z. B. den Nutzungsstatus „belegt“, „frei“, „in Renovierung“ haben; eine Anlage Status „in Betrieb“, „außer Betrieb“, „Störung“, „außer Dienst“. Solche Felder erleichtern das Prozessmanagement enorm – etwa bei der Umzugsplanung (zeige alle freien Büros) oder bei der Instandhaltung (zeige alle außer Betrieb genommenen Geräte). Statusfelder sind typischerweise auswahllistenbasiert und oft mit Geschäftsregeln verknüpft (z. B. ein außer Dienst gestelltes Asset taucht nicht mehr in Wartungsplänen auf). Ein weiteres Statusfeld ist der Datenstatus an sich: Man kann z. B. Objekte als „vorläufig“ oder „verifiziert“ markieren, wenn bei der Datenerfassung noch Lücken bestehen. - Beispiel aus der Praxis: Bei Migration werden alle Räume zunächst mit Status "unbestätigt" importiert und sukzessive durch eine Begehung validiert, woraufhin der Status auf "geprüft" gesetzt wird. So sieht man jederzeit, wie weit die Verlässlichkeit der Daten reicht.

• Zeitbezug (historische und zeitabhängige Daten): Gebäude und Anlagen sind Veränderungen unterworfen. Das Datenmodell sollte zeitbezogene Attribute unterstützen, um Änderungen über den Lebenszyklus abbilden zu können. Dies kann auf zwei Arten erfolgen: - Historisierung von Attributen: Wenn sich ein Attribut ändert (z. B. Raumfläche nach Umbau, Anlagenstandort nach Umzug), möchte man evtl. den alten Wert mit Gültigkeitsdatum archivieren. Einige CAFM-Systeme bieten dafür integrierte Historisierung (Änderungsprotokoll, Gültig-von/bis Felder). Man kann auch selber Felder vorsehen wie Inbetriebnahmedatum, Außerbetriebnahmedatum für Anlagen. So ließe sich z. B. eine Anlage, die von 2010–2020 im Gebäude A stand, dann 2021 in Gebäude B umgezogen wurde, mit zwei Standort-Datensätzen führen, jeder mit Zeitstempel. - Zeitabhängige Objekte: Alternativ kann man bestimmte Objekte zeitlich modellieren, etwa Raumnutzung als eigene Entität mit Feldern Raum, Nutzungsart, von/bis Datum, sodass pro Raum verschiedene Nutzungen über die Zeit abgebildet werden (z. B. 2010–2018 Büro, ab 2019 Labor). Dieses Modell wird komplexer, ist aber bei stark veränderlichen Daten hilfreich. - Stichtagsbetrachtung: Für Auswertungen (z. B. Mietflächenreport zum 1.1. jeden Jahres) ist es wichtig, Datenstände zu bestimmten Zeitpunkten abrufen zu können. Daher der Hinweis: Wenn der Zeitbezug relevant ist, sollte im Datenmodell festgelegt sein, wie er gehandhabt wird. Instandhaltungspläne haben z. B. Next Due Dates (nächste Fälligkeit) – auch das ist eine Art Zeitbezug pro Datensatz.

• Beispiel Raum-Objekt (Auszug)

• Raum-ID / Nummer – Pflichtfeld: Eindeutiger Schlüssel für den Raum, meist kombiniert aus Gebäude- und Geschosskennung + laufender Nummer (z. B. B1-02-105 für Gebäude1, 2.OG, Raum 105). Format oft alphanumerisch, stabil vergeben (auch bei Mieterwechsel gleichbleibend).

• Raumbezeichnung – Pflicht: Klartextname des Raums, z. B. "Besprechung 1" oder "Büro Müller". Kann frei oder aus Liste (für Standardräume) kommen.

• Nutzungsart (Raumart) – Pflicht: Typisierung des Raums, Auswahl aus Katalog (z. B. Büro, Konferenz, Lager, WC, Flur, …). Idealerweise gemäß DIN 277-Kategorien.

• Fläche [m²] – Pflicht: Netto-Grundfläche des Raums in Quadratmetern, Numerikfeld mit 2 Dezimalstellen. Evtl. zusätzlich Bruttofläche oder Nutzfläche falls benötigt.

• Geschoss – Pflicht: Verweis aufs übergeordnete Geschossobjekt (idR via Dropdown oder automatische Hierarchieverknüpfung). Dadurch ist implizit auch das Gebäude klar.

• Kostenstelle – Optional: Falls Räume Kostenstellen oder Abteilungen zugeordnet sind (für interne Verrechnung oder FM-Kostenverteilung). Auswahl aus Liste der Kostenstellen.

• Raumstatus – Optional: z. B. belegt/frei/reserviert, um belegungsbezogene Infos zu pflegen.

• Nutzer – Optional: Hauptnutzer oder verantwortliche Person/Abteilung für den Raum.

• Raumhöhe [m] – Optional: Für Kubaturberechnungen oder Klimatisierung relevant, kann man Raumhöhe hinterlegen.

• Beispiel Anlagen-Objekt (Asset)

• Anlagen-ID / Inventarnummer – Pflicht: Eindeutige Kennung der Anlage im System, z. B. nach AKS-Schema oder Inventarnummer. Oft alphanumerisch (z. B. AN-000123).

• Anlagenbezeichnung – Pflicht: Klartextname, z. B. "Klimagerät Serverraum" oder "Aufzug Ost".

• Anlagentyp / Kategorie – Pflicht: Typisierung, Auswahl aus Katalog (z. B. Lufttechnische Anlage, Aufzugsanlage, Feuerlöscher, Schreibtisch je nach Breite des Systems). Ggf. mehrstufig (Hauptkategorie/Unterkategorie).

• Standort (Raum) – Pflicht: Verknüpfung zum Ort, wo die Anlage steht: meist ein Raum oder alternativ ein Gebäudebereich. So weiß man, wo die Anlage verbaut/aufgestellt ist.

• Hersteller – Optional: Freitext oder Auswahl, wer die Anlage hergestellt hat (z. B. Siemens, Jung Pumpen…). Hilft bei Gewährleistung oder Ersatzteilen.

• Modell/Typbezeichnung – Optional: Hersteller-Modellname oder -nummer, hilfreich für Spezifikationen.

• Seriennummer – Optional: Einzigartige Seriennummer des Geräts (wichtig bei Garantie und Rückrufaktionen).

• Baujahr/Installationsdatum – Optional: Jahr der Herstellung oder Datum der Inbetriebnahme. Dient als Anhaltspunkt für Alter, Lebensdauer, Garantiefristen.

• Wartungsintervall – Optional: Vorgabe, wie oft die Anlage gewartet werden muss (z. B. jährlich, vierteljährlich). Kann als feste Regel hinterlegt werden.

• Status – Optional: z. B. in Betrieb, außer Betrieb, in Reparatur, ersatzbeschafft. Dies steuert oft, ob die Anlage aktiv genutzt wird oder stillgelegt ist.

• Kostengruppe (DIN 276) – Optional: z. B. KG 430 (Elektrotechnik) für eine USV-Anlage, zur Zuordnung in Kostenberichten.

• Verknüpfte Dokumente – Optional: Möglichkeit, z. B. Bedienungsanleitung, Wartungsvertrag als Link/Anhang zu hinterlegen.

• Nächste Prüfung fällig am – Optional: Datum, wann die nächste wiederkehrende Prüfung (TÜV etc.) stattfinden muss, sofern es prüfpflichtige Anlage ist.

Dies sind natürlich nur Ausschnitte; je nach Objekt kann die Attributliste umfangreich sein (ein Raum hat evtl. 20 Attribute, eine Anlage 30 oder mehr, ein Vertrag andere wie Vertragsnummer, Laufzeit, Betrag etc.). Entscheidend ist, für jedes Attribut vorher festzulegen: Soll es immer gefüllt sein? Welche Werte sind erlaubt? Wer pflegt es? So entsteht ein Datenfeldkatalog, der Bestandteil des CAFM-Konzeptes ist. Im GEFMA-Whitepaper zu BIM im FM wird explizit gefordert, die Merkmale (Attribute) der Objekte eindeutig zu definieren – idealerweise schon in den Anforderungen an Planer, damit die beim BIM-Datentransfer mitgeliefert werden.

Eine zentrale Rolle bei der Datenstruktur spielt die eindeutige Identifizierung jedes Objekts. Jedes Gebäude, jeder Raum, jede Anlage braucht eine Primärschlüssel-ID, um es im System unverwechselbar anzusprechen – und um Verknüpfungen sauber abzubilden.

• Einheitliches Kennzeichnungssystem (AKS): GEFMA 198-1 (Dokumentation im FM) empfiehlt ein Allgemeines Kennzeichnungssystem für bauliche und technische Objekte. Das bedeutet, es soll eine strukturierte Kodierung geben, nach der Gebäude, Räume und Anlagen nummeriert werden. Beispielsweise: - Für Gebäude könnte ein zweistelliger Code verwendet werden (A1, A2… oder 01, 02… je Standort) oder eine Buchstabenkombination (z. B. HA für Hauptgebäude, NW für Neubau West). Wichtig ist, dass es keine Dopplung innerhalb des Portfolios gibt. - Geschosse: oft nummerisch mit Zusatz für Untergeschosse (z. B. UG, EG, 01, 02… oder -1, 00, 01...). Diese Geschosskennung fließt häufig in die Raumnummer mit ein. - Räume: ein üblicher Ansatz ist Gebäudekennung – Geschoss – Raumnummer. Beispiel: 01-2.OG-015 oder HA.02.015 für Gebäude 1, 2. Obergeschoss, Raum 15. Diese Kombination ergibt je Raum eine eindeutige Raumnummer, die zugleich dessen Lage codiert. DIN 277-2 Anhang liefert teils Hinweise, aber meist definieren Organisationen ihr eigenes Schema. Wichtig: konsequente Länge und Format (z. B. alle Raumkennzeichen 3-stellig pro Geschoss, mit führenden Nullen). - Anlagen (technische Objekte): Hier ist ein AKS besonders wertvoll, da Anlagen oft komplexer zu benennen sind. GEFMA 198 bzw. VDI 3814 und VDI 3810 (für TGA-Kennzeichnung) empfehlen mehrstufige Anlagenschlüssel. Beispielsweise: Gebäude – Gewerk – laufende Nummer. Ein Aufzug im Gebäude 1 könnte so 01-EL-001 (Gebäude 01, Elektrotechnik, Nr. 1) oder 01-AT-001 (Aufzug als eigenes Gewerke Kürzel) heißen. Für eine Pumpe in der Heizungsanlage könnte ein Schlüssel 01-HL-003 (Heizung/Lüftung, Gerät 3) gelten. Das AKS sollte so gestaltet sein, dass hierarchische Zugehörigkeiten erkennbar sind: Manchmal bilden Anlagenkennzeichen einen Baum (z. B. 410-01-02 könnte für KG410=Heizung, Anlage01=Heizkessel, Komponente02=Brenner stehen). Solche Nummern können lang werden, aber erleichtern später z. B. das Auffinden von Bauteilen auf Plänen oder in Listen. Einige Unternehmen lehnen ihr AKS an Normen wie DIN EN 81346 (Kennzeichnung von technischen Objekten) oder ISO/TS 16952 (KKS) an, insbesondere in kritischen Infrastrukturen. - Dokumente: Für Dokumente gibt es ebenfalls Kennzeichnungssysteme (Dokumentencodes nach GEFMA 198-2). Diese können angeben, zu welchem Objekt das Dokument gehört und welche Dokumentart es ist (z. B. PL-01-02-015-Grundriss.pdf für Grundriss von Raum 015 etc.).

• Entscheidend: Eindeutigkeit über das gesamte System. Kein Schlüssel darf doppelt vergeben sein. Meist erfüllt man das, indem man beim Primärschlüssel einen eindeutigen Nummernkreis je Tabelle hat (z. B. eine interne GUID oder ID). Zusätzlich nutzt man aber die o. g. sprechenden Schlüssel als Attribut. Diese erleichtern dem Menschen die Orientierung (ein Techniker kann mit „Pumpe 01-HL-003“ mehr anfangen als mit ID 84930).

• Vergaberegeln und Governance: Es muss festgelegt werden, wer neue IDs vergibt und nach welchen Regeln. Beispielsweise: Raumkennzeichen werden im Rahmen der Bauplanung festgelegt (durch Architekt oder CAD-Verwalter nach vorgegebenem Schema), Anlagenkennzeichen werden durch die technische Gebäudeausrüstung Planung oder FM-Dokumentation vergeben (vielleicht gemäß einer Liste im Vertrag). Später, im laufenden Betrieb, muss klar sein: Wenn ein neuer Raum entsteht (Umbau) oder eine neue Anlage installiert wird, wer erzeugt den neuen Datensatz und vergibt die ID? Oft übernimmt dies der CAFM-Manager oder ein Datenverantwortlicher. Hilfreich sind ID-Vergabe-Tools oder Automatismen: Etwa generiert das System automatisch die nächste freie Nummer im passenden Kontext.

• Physische Kennzeichnung vor Ort: Die beste ID nützt wenig, wenn man sie im Gebäude nicht findet. Daher ist es gängige Praxis, Objekte physisch mit ihrer ID zu labeln: - Räume: Türschilder oder Aufkleber innen an der Tür mit der Raumnummer (so kann z. B. ein Handwerker die im Auftrag angegebene Raumnummer direkt im Gebäude finden). - Anlagen: Barcode- oder QR-Code-Aufkleber auf jeder Anlage, die die Inventarnummer/ID codieren. So kann mit einem Scanner oder Smartphone der Code erfasst und direkt der Datensatz im CAFM aufgerufen werden. Viele FM-Dienstleister statten ihre Prüftechniker mit Apps aus, die QR-Codes an den Geräten scannen – das springt dann zum richtigen Asset im System, vermeidet Verwechslungen. - Komponenten: Je nach Größe kann sogar Kleintechnik beschriftet werden, zumindest mit einer Teil-ID. In der Industrie sind RFID-Tags verbreitet, z. B. an Armaturen, die man nicht direkt sieht, aber per RFID auslesen kann.

• Verknüpfung von digitaler und physischer Welt: Moderne CAFM-Projekte streben eine durchgängige Digitalkette an. D. h. die im System vergebenen IDs sind wirklich vor Ort auffindbar. Dies ermöglicht z. B. Mobiles CAFM: Ein Techniker vor Ort scannt den QR-Code an der Anlage, die App zeigt ihm sofort die Wartungshistorie und Checkliste an. Oder jemand meldet einen Schaden, gibt die Raum-ID an, und der CAFM-Einsatzleiter kennt sofort den Ort ohne Missverständnisse. Die ID-Vergabe sollte daher immer mit dem Gedanken erfolgen: Kann ich diese ID eindeutig kommunizieren und referenzieren? – Deshalb sind zu kryptische oder zu lange Nummern manchmal hinderlich; ein Balanceakt zwischen Aussagekraft und Praktikabilität.

• Standards & Richtlinien nutzen: GEFMA 198-1 selbst liefert konzeptionell die Empfehlung eines AKS, aber es gibt auch konkrete Systematiken: Einige Nutzer verwenden z. B. das Schema nach VDI 3805/BS 1192 für Anlagenkennzeichnung oder orientieren sich an CAFM-Connect/GEFMA 444 Anforderungen (die fordern, dass jedes Objekt eine eindeutige Identifikation hat). Der CAFM-Ring (Verband) hat Kataloge, in denen z. B. Aufzugsanlagen als Typ 461 geführt werden – solche Nummernwerke können als Prefix in IDs einfließen.

• Abschließend sei betont: Konsequentes ID-Management erfordert Disziplin. Einmal eingeführte Nummern sollten nicht mehr geändert werden (auch wenn z. B. eine Abteilung umzieht, behält der Raum seine Nummer; auch wenn ein Gerät ersetzt wird, kann die neue Einheit die alte Inventarnummer übernehmen, mit Nachverfolgung). Änderungen von IDs führen meist zu Chaos in historischen Daten oder Verknüpfungen. Lieber ein zunächst etwas abstrakter Schlüssel, der dafür dauerhaft ist, als ein „sprechender Name“, der sich bei Änderungen als falsch erweist.

Konsequentes ID-Management erfordert Disziplin. Einmal eingeführte Nummern sollten nicht mehr geändert werden (auch wenn z. B. eine Abteilung umzieht, behält der Raum seine Nummer; auch wenn ein Gerät ersetzt wird, kann die neue Einheit die alte Inventarnummer übernehmen, mit Nachverfolgung). Änderungen von IDs führen meist zu Chaos in historischen Daten oder Verknüpfungen. Lieber ein zunächst etwas abstrakter Schlüssel, der dafür dauerhaft ist, als ein „sprechender Name“, der sich bei Änderungen als falsch erweist.

Ein CAFM-Datenmodell entfaltet seinen Nutzen vor allem dadurch, dass die Stammdaten (Gebäude, Räume, Assets usw.) mit den FM-Prozessen verknüpft werden.

• Flächen- und Mietmanagement: Hier greifen Prozesse wie Flächenbewirtschaftung, Belegungsplanung oder Vermietung direkt auf die Raum- und Flächenstammdaten zu. Beispielsweise werden Mietverträge Objekten (Gebäuden/Räumen) zugeordnet. Ein Mietvertrag im Vertragsmodul referenziert dann den konkreten Raum bzw. die Fläche, die vermietet ist. Nur so kann man z. B. automatisiert die vermietete Fläche pro Gebäude auswerten. Ebenso fließen Raumdaten ins Umzugsmanagement: Ein Umzugsauftrag enthält Ausgangs- und Zielraum (Verweise auf Raumobjekte) und möglicherweise die zu verschiebenden Assets (Verweise auf Anlagenobjekte). Das Flächenmodul nutzt Klassifikationen wie Raumarten, um z. B. Auslastungen zu berechnen (Bürofläche pro Mitarbeiter etc.).

• Instandhaltungs- und Asset-Management: Die Anlagenstammdaten bilden die Basis für Wartungsplanung, Störungsmanagement und Betreiberpflichten. Wartungspläne werden im CAFM auf Anlagenobjekte referenziert – z. B. hat jede Anlage einen hinterlegten Wartungszyklus und es generiert sich eine Wartungsaufgabe „Wartung für Anlage X fällig am <Datum>“. Diese Aufgabe ist im System direkt mit dem Asset verknüpft, sodass Historien pro Asset verfügbar sind (wann wurde was gemacht?). Störmeldungen (Tickets) werden im Helpdesk-Modul in der Regel entweder einem Raum oder direkt einem Asset zugeordnet. Ein Beispiel: Ein Nutzer meldet „Heizung kalt“ in Raum 101. Die Störmeldung wird erfasst mit Referenz Raum 101, ggf. genauer Heizkörper ID123 in Raum 101. Damit weiß der Techniker sofort, um welches Objekt es geht, kann eventuell Historie oder Dokumentation einsehen. Nach Behebung wird die Meldung geschlossen, was wiederum auf dem Asset vermerkt wird („Störung am 12.02. behoben, Thermostat getauscht“). Prüfpflichten (wie Brandschutztüren, Aufzüge) werden ebenso über Anlagen-/Objektdaten gesteuert: Jede prüfpflichtige Komponente ist als Asset im System hinterlegt und einem Prüfrhythmus zugeordnet – das System generiert Aufgaben, und bei Durchführung wird ein Prüfprotokoll an diesem Objekt abgelegt.

• Rechnungs- und Vertragsmanagement: Hier dient das Datenmodell dazu, Leistungen und Kosten Objekten zuzuordnen. Etwa wird ein Wartungsvertrag mit einem Dienstleister im System erfasst und den Anlagen, die er abdeckt, zugewiesen (Verknüpfung Vertrag – Asset-Liste). So kann man bei Auslauf des Vertrags sehen, welche Anlagen betroffen sind. Rechnungen (z. B. Energiekosten) können Gebäuden oder Kostenstellen (die an Räume gekoppelt sind) zugeordnet werden. Im Idealfall fließen Verbrauchsdaten (z. B. Zählerstände) vom Energiemanagement in Raumeinheiten zurück, um Nebenkostenabrechnung je Mietfläche zu erlauben.

• Infrastrukturelles FM: Prozesse wie Reinigungsmanagement oder Raumreservierung greifen ebenfalls auf Stammdaten zu. Ein Reinigungsplan enthält die Liste der Räume (IDs), die gereinigt werden müssen, und wie oft. Änderungen an der Raumfläche oder Nutzung können den Reinigungsintervall beeinflussen (z. B. ein Labor vs. ein Büro). Bei Reservierungen (Konferenzraummanagement) werden die Raumobjekte mit Belegungszeiten verknüpft, oft auch Ausstattung (Beamer, Bestuhlung) – letztere könnten als Assets oder als Raum-Attribute geführt sein.

• Sicherheit und Schlüsselmanagement: Ein weiteres Beispiel: Schlüssel sind Objekte, die bestimmten Türen/Räumen zugeordnet sind. Ein Schlüsseldatensatz verweist auf den Raum, den er öffnet, und auf den Personendatensatz, der den Schlüssel erhalten hat. So lässt sich ein verlorener Schlüssel dem Bereich zuordnen und Risiko abschätzen (welche Räume betroffen).

• Dokumentenmanagement: Dank der Objektstruktur können Dokumente zielgerichtet abgelegt werden. Eine Wartungsanleitung wird am jeweiligen Asset hinterlegt, ein Grundrissplan beim Geschoss oder Gebäude, ein Prüfbericht bei der Anlage, ein Mietvertrag beim Raum/Gebäude. So findet man sie kontextbezogen wieder. Das Datenmodell definiert hierfür Dokumententypen und die Beziehungen (z. B. Document verknüpft mit Asset).

• Reporting und Controlling: Alle oben genannten Prozesse generieren Daten (Meldungen, Aufträge, Kosten), die über die Objektstruktur aggregiert werden können. Z. B. kann man mit wenigen Klicks erfahren: „Wie viele Störungen gab es im letzten Quartal in Gebäude X?“ – weil jede Störung einen Raum/Gebäude-Ref hat, lässt sich das filtern. Oder: „Welche Wartungskosten hatten wir für alle Aufzugsanlagen (Anlagentyp) im Jahr?“ – jede Wartung ist einem Asset mit Typ Aufzug und damit einer Kostengruppe zugeordnet, was summiert werden kann.

All das funktioniert nur, wenn die Stammdaten sauber gepflegt und mit den Vorgängen verknüpft sind. Es erfordert initial etwas mehr Aufwand (z. B. beim Melden eines Schadens den Raum anzugeben, nicht nur Freitext), bringt aber immense Vorteile in Auswertung und Nachvollziehbarkeit.

Die CAFM-Software-Module sind üblicherweise so gestaltet, dass man beim Anlegen eines Vorgangs aus der Stammdatenhierarchie auswählen kann. Etwa: Störung erfassen -> Auswahl Standort/Gebäude/Raum aus Dropdown -> Auswahl betroffene Anlage aus Liste. Dadurch entsteht automatisch die Relation. Moderne Systeme erlauben sogar, aus dem Objekt heraus Aktionen zu starten (im Raum-Steckbrief einen Button „Störung melden“). Das zeigt nochmals, wie das Datenmodell die Basis aller Funktionen ist.

Die beste Datenstruktur nützt wenig, wenn die Datenqualität nicht stimmt. Bei der Einführung einer CAFM-Datenbasis sind daher Maßnahmen zur Qualitätssicherung unverzichtbar.

• Vollständigkeit: Alle definierten Pflichtattribute müssen gefüllt sein, und es sollte eine definierte Mindestdatentiefe je Objekt geben. Beispielsweise könnte als Projektziel formuliert werden: „Für jedes Gebäude: min. Standortdaten, Baujahr, Bruttofläche vorhanden; für jeden Raum: Fläche, Nutzung, Kostenzuordnung vorhanden; für jede Anlage: Typ, Standort, Wartungsplan vorhanden.“ Fehlende Daten gefährden Prozesse (z. B. ohne Wartungsplan wird eine Anlage nie gewartet). Daher müssen nach der Datenerfassung Berichte gefahren werden, die Datensätze ohne bestimmte Angaben listen (z. B. „Räume ohne Nutzungsart“). Schon beim Import oder der Eingabe sollten Pflichtfelder validiert werden – das System sollte nicht erlauben, einen Raum ohne Nummer oder 0 m² anzulegen.

• Korrektheit: Die inhaltliche Richtigkeit der Daten ist schwerer automatisch prüfbar, aber es gibt Plausibilitätskontrollen. Beispiele: Summe der Raumflächen eines Geschosses ≈ Geschoss-Gesamtfläche (Abweichungen melden), oder: Ein Baudatum darf nicht in der Zukunft liegen, ein Prüfdatum nicht in der Vergangenheit (bei Neuprüfung). Ortskoordinaten sollten im gültigen Bereich liegen, Telefonnummern das richtige Format haben etc. Solche Geschäftsregeln kann man teils im System hinterlegen oder per Datenbank-Trigger überwachen. Häufig bleibt es aber Aufgabe der Datenverantwortlichen, stichprobenartig die Korrektheit zu prüfen (etwa Abgleich mit Plänen).

• Konsistenz & Integrität: Das Datenmodell an sich definiert viele Konsistenzregeln: Referentielle Integrität (ein Raum verweist auf ein existierendes Geschoss; löscht man ein Gebäude, müssen auch alle Räume weg oder umgezogen sein), Eindeutigkeit (keine doppelten IDs oder Raumnummern innerhalb eines Geschosses), Wertemengen (nur erlaubte Klassifikationscodes). Diese lassen sich oft durch die Datenbank sicherstellen (Primary Key, Foreign Key, Unique Constraints). Zusätzlich sollen Mehrdeutigkeiten vermieden werden: z. B. jeder physische Raum sollte nur einmal in der Datenbank vorkommen. Klingt trivial, aber bei Datenmigration kommt es vor, dass Räume doppelt angelegt werden (einmal aus Planungsdaten, einmal aus einer Mieter-Liste). Solche Dubletten sind zu bereinigen. Im Rahmen von Qualitätssicherung ist es sinnvoll, Abgleiche zu fahren: Liste der Räume aus Bauzeichnungen vs. Räume in CAFM – stimmen Anzahl und Bezeichnungen überein? Ebenso bei Anlagen: Abgleich Inventarliste vs. ERP-Anlagenbuch.

• Aktualität: Datenqualität bedeutet auch, dass Daten up to date sind. Ein exzellentes Anfangsdatenmodell verliert Wert, wenn es nicht gepflegt wird. Daher definieren viele Organisationen Aktualitätsanforderungen: z. B. „Raumbelegungen werden monatlich aktualisiert“ oder „Nach jedem Umbau sind binnen 2 Wochen die Pläne und Flächenmaße im CAFM anzupassen“. Während der Einführung sollte man einen Datenpflege-Prozess etablieren (siehe Best Practices), damit Änderungen lückenlos nachgetragen werden.

• Prüfroutinen und Monitoring: Neben manuellen Checks können automatisierte Validierungsroutinen eingesetzt werden. Einige CAFM-Systeme haben Module für Datenqualität, die z. B. doppelte Räume oder offensichtliche Fehler (Raumfläche > Geschossfläche, Anlagen ohne Standort) aufzeigen. Auch Tools wie SQL-Skripte oder BI-Auswertungen helfen. Ein regelmäßiger „Daten-TÜV“ – etwa quartalsweise – ist empfehlenswert: Dabei werden definierte Qualitätskennzahlen erhoben (Anteil befüllter Felder, Anzahl Dubletten, Konsistenz an Schlüsselstellen). GEFMA 430 betont diese Pflege und Bewertung der Datenbasis als kontinuierliche Aufgabe für Verantwortliche.

• Benutzerrechte und Verantwortlichkeiten: Ein oft unterschätzter Faktor der Datenqualität ist, wer die Daten ändern darf. Zu viele Schreibrechte können Chaos verursachen (jeder trägt anders ein). Besser: klare Verantwortlichkeiten je Datenbereich. Beispielsweise: Stammdaten Räume dürfen nur vom CAFM-Team oder der Bauabteilung geändert werden, Anlagenstammdaten nur vom Instandhaltungskoordinator, Personendaten nur von HR-Schnittstelle etc. Dadurch hat man Experten, die wissen, was sie tun, und man kann sie gezielt schulen. Im System sollten Benutzerrechte so konfiguriert sein, dass z. B. ein Helpdesk-Mitarbeiter zwar Störungen erfassen kann, aber nicht die Raumfläche ändern.

• Dokumentation der Herkunft und Änderungshistorie: Um Vertrauen in die Daten zu haben, ist es gut nachvollziehbar zu machen, woher die Daten stammen (z. B. "Fläche gemäß Aufmaß Jan. 2024, Messmethode nach DIN277") und wer wann Änderungen vorgenommen hat. Änderungsverfolgung (Audit Trail) ist oft systemseitig vorhanden – mindestens sollte aber klar sein, wer als „Datenowner“ fungiert. Bei kritischen Daten kann ein 4-Augen-Prinzip eingeführt werden (Änderung nur durch 2 Personen freigeben).

• Schulung und Bewusstsein: Datenqualität entsteht nicht nur durch Regeln, sondern durch kulturelles Bewusstsein. Mitarbeiter müssen verstehen, warum es wichtig ist, dass z. B. jede Anlage den richtigen Raumbezug hat. Wenn das Nutzenargument klar ist (etwa „sonst findet der Wartungstechniker die Anlage nicht“), steigt die Sorgfalt. GEFMA 430 zielt auch darauf ab, Verantwortlichen diese Sensibilität zu vermitteln.

Letztlich sollte die CAFM-Einführung ein Datenqualitätskonzept beinhalten. Darin werden Soll-Qualität, Prüfmechanismen und Korrekturprozesse definiert. Nichts ist peinlicher, als nach Einführung eines schicken Systems festzustellen, dass die Auswertungen unbrauchbar sind, weil Eingabefehler und Lücken es verzerren. Daher lieber initial Aufwand in Qualität stecken – der Nutzen später (verlässliche Reports, weniger manuelle Nacharbeit) ist die Belohnung.

Viele aktuelle CAFM-Projekte stehen vor der Herausforderung, BIM-Daten aus Planung und Bau in das FM-System zu übernehmen. BIM-Modelle (etwa im Format IFC) enthalten bereits eine Fülle an Objektinformationen – jedoch mit anderem Fokus.

• BIM vs. CAFM – unterschiedlicher Fokus: BIM-Modelle (Building Information Modeling) entstehen vorrangig für Planung und Bau. Sie sind geometrisch orientiert (3D-Modelle) und sehr detailreich in bautechnischer Hinsicht. Sie kennen Objekte wie Wände, Türen, Fenster, Fassaden, Bodenplatten, etc., die im CAFM meist keine Entsprechung als eigenständige Stammdaten haben (man verwaltet z. B. nicht jede Wand als Objekt im CAFM, sondern nur Räume, die durch Wände definiert sind). CAFM dagegen fokussiert auf den Betrieb: Räume, Flächen, Anlagen, Verträge, Leistungen. Schnittmenge sind insbesondere Gebäude, Geschosse, Räume und technische Anlagen – diese kommen in beiden Welten vor.

• IFC-Struktur als gemeinsame Sprache: Das offene BIM-Format IFC (Industry Foundation Classes) ist international standardisiert (ISO 16739) und bildet logische Gebäudestrukturen ab. Relevant für CAFM daraus sind u. a.: - IfcSite (Standort), IfcBuilding (Gebäude), IfcBuildingStorey (Geschoss), IfcSpace (Raum): Diese Hierarchie deckt sich mit der oben beschriebenen. Ein IfcSpace entspricht einem Raumobjekt mit Attributen wie Name, Nummer, Nutzungsart. IFC beinhaltet auch Raumgeometrien (Volumen) – im CAFM verwendet man eher die Fläche, aber Geometrie kann für Visualisierungen nützlich sein. - IfcEquipment / IfcAsset / IfcBuildingElement: Technische Ausstattung kann in IFC entweder als IfcBuildingElement (wenn fest verbaut, z. B. Kessel als Ausrüstungsteil) oder in neueren IFC-Versionen als IfcAsset modelliert werden (explizite FM-Objekt-Klasse). IFC4 bietet deutlich mehr FM-Attribute als ältere Versionen. So können in IFC neben Geometrien auch alphanumerische Eigenschaften definiert werden – z. B. Wartungsintervalle, Herstellernamen, Seriennummern (teils mittels sogenannter PropertySets, PSet_FacilityManagement). - IfcRelAssignsToGroup / IfcSystem: Anlagen können in IFC Gruppen/Systemen zugeordnet sein. Ein Lüftungssystem etwa kann als IfcSystem gruppiert werden mit Komponenten (Ventilator, Kanal etc.). CAFM würde das als Asset mit Komponenten oder als verknüpfte Anlagen darstellen. - Dokumente: IFC kann Dokumente verknüpfen (IfcDocumentReference). Alternativ gibt es das Format COBie (Construction-Operations Building Information Exchange), welches genau eine tabellarische Extraktion der FM-relevanten Daten aus IFC ist. COBie liefert in Excel-Form u. a. Tabellen für Facility, Floor, Space, Component, Type, System, Job, Resource, Document etc. Dabei sind z. B. in Space Tabelle Felder wie Raumnummer, Name, Etage, Fläche, Raumnutzung. CAFM-Systeme können COBie-Tabellen importieren, um Stammdaten zu füllen.

• Abgrenzung in Tiefe und Pflege: Während also die Struktur (Site-Building-Floor-Space-Asset) über BIM und CAFM ähnlich ist, unterscheiden sich der Detailgrad und die Aktualisierung: - BIM-Modelle enthalten z. B. jedes Rohr und Kabel (für FM oft zu granular). CAFM filtert meist die relevanten Objekte heraus (Räume und Anlagen ja, aber wir pflegen nicht jedes Rohr als separates Asset, außer in speziellen FM-Bereichen). - BIM entsteht in der Bauphase – danach wird es häufig statisch. Im Betrieb verändert sich aber vieles (Umbauten, Austausch von Geräten). Hier muss man entscheiden: Pflegt man das BIM-Modell fort (erfordert BIM-Kompetenz im FM-Team), oder übernimmt man einmalig Daten ins CAFM und pflegt diese getrennt? In der Praxis ist Letzteres häufiger: Das CAFM wird zum führenden System im Betrieb und BIM-Modelle werden bei größeren Änderungen aktualisiert (z. B. alle 5 Jahre ein Bestandsmodell). - Datenumfang: Ein CAFM benötigt bestimmte Attribute, die im BIM-Modell evtl. nicht angelegt wurden, weil sie für die Planung irrelevant waren (z. B. Instandhaltungsrelevante Daten wie Wartungsintervall, Prüffrist, verantwortlicher Techniker). Hier kommt es auf die AIA (Auftraggeber-Informationsanforderungen) an: FM sollte bereits in der Planungsphase definieren, welche Daten sie aus BIM erwarten (z. B. "Alle Wartungsgeräte mit ihren Prüfzyklen gemäß VDMA 24186 in Pset FMMaintenance"). GEFMA 926 adressiert das und listet z. B. FM-Anforderungen an BIM-Daten auf (AKS, Attribute, Übergabezeitpunkte, Formate). - IFC-Mapping ins CAFM: Viele CAFM-Systeme bieten Importe für IFC/COBie. Dabei muss man ein Mapping konfigurieren: Welche IFC-Klasse wird zu welcher CAFM-Entität, welche Property zu welchem Feld. Beispielsweise: IfcBuildingStorey.Name -> Geschoss.Name; IfcSpace.Number -> Raum.Nummer; IfcSpace.Area (via BaseQuantity) -> Raum.Fläche; IfcEquipment -> Anlage; IfcTypeObject (Bauprodukt-Typ) -> evtl. Anlagenkatalog/Gerätetyp. Eine Herausforderung sind manchmal ID-Abgleiche: Wenn BIM eine GUID hat und CAFM eigene IDs vergibt, muss man entscheiden, ob man die BIM-ID mit übernimmt (vielleicht in ein Feld "IFC_GUID") um später Updates matchen zu können. - Zusätzliche Strukturelemente: BIM kennt z. B. IfcZone – eine Zone kann Räume gruppieren (für Klimazonen, Mietbereiche etc.). Im CAFM könnte man Zonen als eigene Objekte einführen oder als Attribut "Bereich" bei Raum. Wenn solche Infos relevant sind (z. B. Brandabschnitte), sollte man es im Datenmodell vorsehen, ggf. analog als Hierarchieebene oder Zusatzrelation. - Geometrie vs. Sachdaten: IFC liefert Geometrie, CAFM ist primär sachdatenorientiert. Manche CAFM-Systeme speichern die Geometrie (Flächenumrisse) in einem CAD-Modul, andere verzichten darauf und speichern nur Flächenzahlen. Hier muss man definieren, ob z. B. Grundrisse als Grafik hinterlegt werden oder ob eine echte CAD-Integration erfolgt (mit Bi-direktionaler Verknüpfung: Klick auf Raum in Plan -> Datensatz, und umgekehrt). Das Datenmodell muss für CAD-Integration evtl. Koordinaten oder Flächenpolygone speichern können (z. B. in GIS-Koordinaten oder als Verweis auf eine CAD-Datei). IFC bietet diese Info (Raumpolygone), aber oft werden sie ins CAFM nicht voll übernommen, sondern nur als Verlinkung auf externe CAD. - BIM-Attribute aufteilen: Ein Beispiel: Im BIM-Modell hat ein Bauteil eine Bezeichnung, die im CAFM in zwei Felder aufgeteilt werden soll (z. B. "Lüftungsgerät V500, Fa. X" -> Anlage.Typ = Lüftungsgerät, Anlage.Beschreibung = V500, Anlage.Hersteller = X). Solche Transformationen müssen im Mapping beachtet werden. - Praxis – BIM2CAFM: In einem realen Projekt sollte ein Mapping-Tabelle erstellt werden, in der jeder gewünschte FM-Datenpunkt einem BIM-Datenpunkt gegenübergestellt ist. Z. B.: Raum-Nummer (CAFM) = Room.Number (Revit IFC Parameter), Prüfintervall (CAFM) = „Wartungsintervall“ (Attribut im BIM-Modell, falls vorhanden). Oft stellt man fest, dass manche FM-Daten gar nicht im BIM vorhanden sind -> die müssen später manuell angereichert werden. Umgekehrt haben BIM-Modelle Unmengen an Infos (Dämmstoffsorten, Betonfestigkeiten), die für FM irrelevant sind -> die werden beim Import verworfen.

• Abgrenzung in Verantwortlichkeiten: Ein weiterer Punkt: BIM-Daten werden vom Planer/Ersteller verantwortet, FM-Daten vom Betreiber. Nach Abnahme wechselt oft der „Datenhoheit“. Es ist sinnvoll, im CAFM zu markieren, welche Daten aus dem BIM-Modell stammen (und dort vielleicht noch aktualisiert werden müssten bei Planänderungen) und welche originär im CAFM gepflegt werden. Einige Organisationen führen ein Asset Information Model (AIM) getrennt vom Project Information Model (PIM), wie ISO 19650 es beschreibt. Das AIM entspricht dem CAFM-Datenbestand, der fortgeführt wird.

• Tools und Standards zur Integration: Neben IFC/COBie gibt es auch spezifischere Standards: z. B. CAFM-Connect (wie erwähnt) als Schnittstelle, die genau dieses Mapping standardisieren will – es basiert auf IFC, pickt aber die FM-relevanten Objekte heraus und versieht sie mit Klassifikationen nach GEFMA 924, DIN 276 etc., um Missverständnisse auszuschließen. In UK/USA-Umfeld gibt es OmniClass oder Uniformat-Klassifikationen, die auch im BIM mitgegeben werden und dann im FM genutzt werden (z. B. OmniClass 11 für Räume, 21 für Ausstattung).

• Konfliktpunkte vermeiden: Abgrenzung bedeutet auch, zu entscheiden, was nicht übernommen wird. Beispielsweise kann es sinnvoll sein, Kleinstobjekte nicht einzeln im CAFM zu führen (z. B. jedes Ventil im Sprinklersystem – hier reicht es evtl. das System als Ganzes als eine Anlage mit Attribut "Anzahl Ventile" zu verwalten, statt 200 Ventile einzeln). Solche Abstraktionen halten die Datenmenge beherrschbar. Auch Räume, die in BIM vielleicht anders zugeschnitten sind als für FM sinnvoll (z. B. ein Großraumbüro in BIM als ein Raum, im FM aber 10 Arbeitsplätze separat verwaltet) – hier muss man ein Konzept finden: ggf. im CAFM den Raum einmal führen plus 10 Arbeitsplatz-Sub-Objekte, oder den Raum in BIM schon entsprechend aufteilen.

Es ist eine enge Abstimmung zwischen BIM- und CAFM-Verantwortlichen nötig. Das CAFM-Datenmodell sollte kompatibel, aber nicht identisch mit dem BIM-Modell sein, abgestimmt auf die Belange des Betriebs. GEFMA 926 und andere Whitepapers empfehlen dazu, frühzeitig in BIM-Projekten die FM-Anforderungen einzubringen und standardisierte Austauschformate wie IFC4/COBie zu nutzen. So können Doppelerfassungen vermieden und ein nahtloser Übergang von Bau zu Betrieb erreicht werden – was letztlich Kosten spart und die Qualität der FM-Daten erhöht.

Die Einführung eines CAFM-Datenmodells ist kein einmaliges Technik-Projekt, sondern ein organisationsübergreifendes Vorhaben.

• Schrittweise und planvolle Einführung: Versuchen Sie nicht, auf einmal das komplette Datenuniversum zu befüllen. Priorisieren Sie nach Nutzen. Zum Beispiel: Start mit grundlegenden Gebäudedaten und Flächen (für Raumverwaltung und erste Berichte), danach Anlagen für die wichtigsten technischen Gewerke, dann schrittweise Ausbau (Inventar, Verträge etc.). Ein Phasenplan hilft, Komplexität zu managen. Wichtig: Die Hierarchie (Standort/Gebäude/Raum) sollte früh stehen, weil vieles darauf aufsetzt. Weitere Module können nach und nach integriert werden.

• Datenverantwortliche (Data Owner) benennen: Für jede Haupt-Datenkategorie (Gebäude/Stammdaten, Flächen, Anlagen, Verträge, Personen…) sollte es einen Verantwortlichen geben. Diese Person oder Rolle hat den Hut auf für die Datenqualität in dem Bereich. Z. B. könnte die Bauverwaltung für Gebäude- und Raumdaten zuständig sein, die Technikabteilung für Anlagendaten, die Vertragsabteilung für Vertragsdaten. Diese Data Owner definieren, wer Daten pflegt, prüfen regelmäßig deren Zustand und sind Ansprechpartner bei Unklarheiten. Sie sollten früh ins Projekt eingebunden sein und die Anforderungen an „ihre“ Daten mitdefinieren.

• Schulung und Dokumentation: Stellen Sie eine Datenstruktur-Dokumentation bereit – etwa ein Handbuch oder Wiki, in dem die Hierarchie, alle Objektarten und Attribute erklärt sind (inkl. Beispiele und Eingaberegeln). Schulen Sie alle Nutzer, die Daten eingeben oder nutzen, in diesen Standards. Nur wenn jeder versteht, was z. B. unter „Raumart“ genau zu wählen ist, bleibt es konsistent. Schulungen sollten praxisnah sein (ggf. mit Übungen am System). Für neue Mitarbeiter sollte die Datenrichtlinie verpflichtend sein.

• Prozesse für Datenpflege etablieren: Daten leben nur, wenn sie aktualisiert werden. Definieren Sie Prozesse, wann und wie Daten geändert oder ergänzt werden: - Bei Bauprojekten: Gibt es eine Übergabeprozedur? (z. B. der Bauprojektleiter muss alle neuen Räume/Flächen dem CAFM melden, idealerweise via BIM-Export). - Bei Anschaffung oder Austausch von Anlagen: Muss die Instandhaltung neue Geräte im CAFM anlegen? (Möglichst ja – evtl. über Integration mit Einkauf/ERP). - Bei Umzügen: Wer ändert Raumzuordnungen, Namensschilder, Belegungsstatus im System? (Vielleicht der Umzugsmanager führt eine Liste, die er an CAFM-Team gibt). - Bei regelmäßigen Prüfungen: Soll der Prüfdienstleister nach getaner Prüfung fehlende Geräte im System rückmelden? - Legen Sie Pflegeintervalle fest: z. B. Flächendaten jährlich auf den neuesten Stand bringen (mit Stichtag Abgleich mit CAD-Plänen), Inventur der Assets alle 2 Jahre. So verhindert man schleichende Veraltung.

• Datenmigration mit Qualitätskontrolle: Wenn Bestandsdaten aus Excel, Alt-Systemen oder BIM importiert werden, planen Sie ausreichend Zeit für Bereinigung und Mapping ein. Häufig passen die alten Daten nicht 1:1 ins neue Modell (andere Feldstruktur, nicht gepflegte Klassifikationen, Duplikate). Führen Sie einen oder mehrere Test-Importe, werten Sie Protokolle aus (was fiel durch Validierung?) und bessern nach. Es kann hilfreich sein, zunächst einen Daten-Musterbestand manuell einzugeben, um das Modell zu testen – bevor man tausende Datensätze importiert. Für Migration empfiehlt sich auch: bestimmte Felder vorbefüllen (Defaults), wenn Alt-Daten es nicht hergeben. Bsp.: Wenn kein Raumtyp vorhanden war, alle migrierten Räume erstmal als „unbestimmt“ kennzeichnen und später ergänzen.

• Nutzung von Referenzprojekten und Templates: Viele Berater und Hersteller bieten Datenmodell-Templates an, branchenspezifisch (z. B. für Büroimmobilien, für Krankenhäuser, für Hochschulen). Diese beinhalten vordefinierte Objektarten und Attribute. Nutzen Sie solche Vorlagen als Ausgangsbasis, um nichts Wichtiges zu vergessen. Das Rad muss nicht neu erfunden werden. Allerdings immer prüfen, ob alle Felder benötigt werden oder ob etwas Spezifisches fehlt, und das Template anpassen.

• Kontinuierliche Qualitätssicherung: Nach Go-Live sollte die Datenqualität ständig überwacht werden (siehe voriges Kapitel). Regelmäßige Audits und KPIs zur Datenqualität sind sinnvoll. Manche Organisationen machen jährliche Datenreviews: Dabei gehen Verantwortliche stichprobenartig durchs Gebäude mit Ausdruck der Stammdaten und prüfen vor Ort „stimmt das was im System steht?“. Abweichungen werden korrigiert. So bleibt die Datenbasis verlässlich. Auch Feedback der Endnutzer (z. B. „Raum xy wurde falsch benannt im System“) sollte ernst genommen und systematisch verarbeitet werden.

• Änderungen mit Wirkung auf Datenmodell steuern: Im Betrieb kommt es vor, dass neue Anforderungen zusätzliche Felder nötig machen oder Kategorien geändert werden müssen. Dafür sollte es ein Change-Management geben: z. B. Anträge für neue Attribute prüfen (wirklich nötig? wie wirkt es sich auf Schnittstellen aus?), dann hinzufügen und dokumentieren. Wildes Hinzufügen ohne Konzept führt zu Aufblähung und Unordnung. Wenn die Organisation wächst (mehr Gebäude, neue Nutzungsarten), kann der Katalog erweitert werden – möglichst kompatibel zu bisherigen (neue Raumarten hinzufügen statt alte umbenennen, sofern möglich, damit Historie stimmt).

• Integration mit anderen Systemen: Betrachten Sie das CAFM-Datenmodell im Kontext der gesamten IT-Landschaft. Gibt es ein ERP oder Finanzsystem, wo Gebäude als Kostenstellen geführt werden? – Dann sollten IDs abgeglichen sein oder eine Schnittstelle die Konsistenz sicherstellen. Mitarbeiterdaten kommen evtl. aus HR-System – dann soll das CAFM nicht getrennt Personenstammdaten pflegen, sondern via Import/Austausch aktuell halten. Jede Doppelpflegequelle birgt Risiko von Divergenzen. Also: klare System-of-Truth für jede Datenart definieren. Oft ist CAFM für Räume/Anlagen federführend, während Personen vom HR kommen und Finanzzahlen vom ERP.

• Visualisierung und Usability: Eine oft unterschätzte Komponente: Das Datenmodell mag intellektuell klar sein, aber Nutzer müssen damit arbeiten. Stellen Sie daher benutzerfreundliche Sichten bereit: z. B. ein grafischer Gebäudeplan zur Navigation (statt Listen von Raumnummern), oder ein Dashboard, das Kennzahlen pro Gebäude zeigt. Wenn das Modell gut strukturiert ist, können solche Frontends leicht darauf aufsatteln. Diagramme, Baumstrukturen und Kartenansichten helfen, die Daten greifbar zu machen und Fehler eher zu erkennen (z. B. wenn im Plan ein Raum fehlt, merkt es ein Nutzer schneller als in einer Tabelle).

Angenommen, ein Unternehmen führt CAFM neu ein. Man definiert zunächst alle Standorte und Gebäude im System (vielleicht aus einer Immobilienliste). Dann werden vorhandene CAD-Pläne genutzt, um Räume samt Flächen zu importieren (ggf. über Schnittstelle oder manuell Raum für Raum anlegen). Gleichzeitig erstellt das Team Kataloge für Raumarten und Anlagenarten, abgestimmt z. B. mit dem Arbeitsschutz (wegen Prüffristen) und Controlling (wegen Kostengruppen). Als Nächstes geht die Technik durchs Haus und erfasst Anlagen: Heizung, Klima, Aufzüge etc. – entweder via Excel-Template, das dann importiert wird, oder direkt mobil mit QR-Code kleben und per App ins System buchen. Jede Anlage wird gleich dem richtigen Raum zugeordnet und erhält einen Barcode. Nach ein paar Monaten hat man eine Grunddatenbank. Nun werden Wartungsverträge mit den Anlagen verknüpft und Wartungspläne eingepflegt. Störmeldungsprozess wird aufgesetzt: Nutzer melden per Portal Störungen, wählen den Raum (dank strukturierter Liste). Die FM-Leitung sieht erstmals Reports: Wo entstehen die meisten Probleme, welche Fläche steht leer, etc. Kleinere Lücken in den Daten werden erkannt und nachgetragen. Über das Jahr kommen Nachträge (Umbauten, neue Geräte) – dafür wurde festgelegt: ohne CAFM-Update gibt’s keine offizielle Inbetriebnahme. So bleibt man am Ball. Nach einem Jahr zieht man Bilanz: FM-Dashboard zeigt belastbare KPIs, das System ist angenommen. Nun kann man über weitergehende Schritte nachdenken (z. B. IoT-Sensoren verknüpfen, Energieverbrauchsdaten einspielen – alles leichter möglich, weil das Fundament steht).

Datenmodell und Datenstruktur sind lebendig. Sie müssen mit der Organisation mitwachsen. Aber eine solide initiale Struktur, basierend auf Standards und Best Practices, macht das Wachstum geordnet und handhabbar. Investition in Planung, Katalogisierung und Schulung am Anfang zahlt sich durch Effizienz und Vermeidung von Fehlern vielfach aus. Eine konsistente CAFM-Datenstruktur bildet somit das Rückgrat des digitalen Gebäudebetriebs – und ermöglicht es, die komplexen Aufgaben des Facility Managements im Griff zu behalten.