Wir reden im Facility Management gern über Digitalisierung, CAFM, IWMS und den „digitalen Zwilling“. Wir reden weniger gern darüber, wie wir tatsächlich mit unseren Daten umgehen. Und genau da liegt das Problem.
Wir haben im CAFM-Umfeld kein Softwareproblem.
Wir haben ein Organisations- und Kulturproblem im Umgang mit Daten.
Die schöne Erzählung: Alles integriert, alles verfügbar
Wenn man sich Präsentationen von CAFM- und IWMS-Anbietern anschaut, klingt unsere Welt eigentlich einfach:
Durchgängige Daten vom BIM-Modell bis in den Betrieb,
ein „Single Source of Truth“ für alle Gebäudedaten,
vollintegrierte Prozesse, vom Ticket bis zum Lifecycle der Anlage und natürlich (Tusch!)
Predictive Maintenance, Smart Buildings, digitale Zwillinge.
Wenn das alles in der Breite Realität wäre, bräuchten wir viele Diskussionen nicht mehr. Was ich in der Praxis sehe, ist etwas anderes: Fragmentierte Systemlandschaften, Datenfriedhöfe und Organisationen, die ihre eigenen Daten nicht wirklich kennen – geschweige denn konsequent nutzen.
Datenfriedhöfe: Unser heimliches Kernsystem
Die meisten Unternehmen haben sie. Manche nennen sie „historisch gewachsene Ablagestruktur“, andere „Dokumentenmanagement“, wieder andere einfach „Laufwerk XY“. Gemeint ist immer dasselbe: der Datenfriedhof.
Er besteht aus:
Netzlaufwerken mit Ordnern, die nur noch Eingeweihte verstehen,
Excel-Dateien mit Versionen wie „final_v3_neu_final_endgültig_b“,
Übergabe-PDFs aus Bauprojekten, die seit Jahren niemand geöffnet hat und
Schattenlisten einzelner Fachbereiche, in denen die „wirklich aktuellen Daten“ gepflegt werden.
Das Beeindruckende: Diese Friedhöfe sind hochverfügbar. Sie funktionieren seit Jahren. Und sie wachsen zuverlässig weiter.
Das Tragische: Sie sind fachlich kaum nutzbar. Niemand hat den Überblick. Niemand hat die Verantwortung. Wir tun häufig so, als wäre unser CAFM das „führende System“. In Wirklichkeit ist das führende System oft das Laufwerk mit den Excel- und PDF-Sammlungen.
Isolierte Systeme: Integration auf dem Papier, Parallelwelten in der Praxis
Die IT-Landschaft im FM ist heute leistungsfähig: Wir haben Systeme für Flächen, Instandhaltung, Energie, Verträge, Dokumente, Tickets, IoT und mehr.
Die meisten dieser Systeme können für sich genommen viel. Aber sie sprechen oft nicht wirklich miteinander.
Typische Situationen:
Das CAFM kennt die Anlage – aber nicht ihren tatsächlichen Energieverbrauch,
das Energiemanagementsystem kennt den Verbrauch – aber nicht, in welchem Raum die Anlage steht oder welche Kritikalität sie hat und
das Ticketsystem kennt die Störung – aber nicht, ob diese Anlage seit Jahren Auffälligkeiten hat oder kurz vor Austausch steht.
Ja, es gibt Schnittstellen aber: Datenmodelle passen nicht sauber zusammen, IDs sind uneinheitlich oder werden inkonsistent gepflegt und Prozesse sind nicht an die Schnittstellen angepasst. Das Ergebnis ist keine echte Integration, sondern parallele Wahrheiten. Jedes System hat seine eigene Version der Realität.
Die Blackbox „Schnittstelle“
In Konzepten steht oft stolz: „Integration relevanter Drittsysteme über standardisierte Schnittstellen”. Oh ja, das klingt toll. In der Praxis sieht das häufig so aus:
CSV-Exporte, die nachts laufen und keiner genau versteht, APIs, die zwar existieren, aber spärlich dokumentiert und kaum überwacht werden,
Importprozesse, die nur dann funktionieren, wenn eine bestimmte Person im Haus sie „so wie immer“ bedient.
Ich habe Projekte erlebt, in denen die Organisation fest davon überzeugt war, dass bestimmte Daten „integriert“ seien – bis wir im Detail geschaut haben und feststellen mussten:
Ja, es werden Daten übertragen.
Nein, die fachlich relevanten Felder kommen nicht oder nicht konsistent mit.
Ja, die Oberfläche sieht integriert aus.
Nein, die Auswertungen basieren auf brüchiger Datenbasis.
Gefährlicher als fehlende Daten sind Daten, denen man vertraut, obwohl sie fachlich nicht belastbar sind.
Die unbequeme Wahrheit: Die Daten sind da – aber ungenutzt
Wir reden oft so, als hätten wir einen Datenmangel. Meiner Erfahrung nach stimmt das selten… denn was in den meisten Organisationen sehr wohl vorhanden ist, sind Flächendaten in Grundrissen, Excel und CAFM. Oder hübsch verexelte Anlagenlisten in Übergabeunterlagen, Wartungsdokumenten, Ticketsystemen oder Energieverbräuche in Zählern, Portalen, Energiemanagementsystemen. Die IT hat auch ein tolles Störmele-System via Helpdesk-Systeme und E-Mail und natürlich existtieren auch Vertragsdaten in ERP, DMS und Speziallösungen.
Die Daten sind da. Sie sind nur verteilt, unterschiedlich strukturiert, ohne klare Ownership und oft ohne konsequenten Kontext.
Ein Beispiel aus meiner Praxis: Ein Betreiber war überzeugt, keinerlei belastbare Ausfallhistorie zu kritischen Anlagen zu haben. „Das ist nie erfasst worden“, hieß es. Nach einigen Tagen Analyse zeigte sich dass Störmeldungen lagen im Ticketsystem vorlagen, Wartungsberichte als PDFs im DMS und in wild gepflegten, individuell geführten Excel-Sheets vorlagen und engagierte Techniker eigene Excel-Listen über besondere Vorkommnisse führten. Was jedem auch irgendwie sinnvoll erschien.
Die Daten waren vorhanden – nur nicht als „System“, sondern als Inseln. Wir haben sie zusammengeführt und konnten rückwirkend belastbare Kennzahlen erstellen. Das Problem war nie, dass die Daten fehlten. Das Problem war, dass niemand sie als zusammengehörigen Informationsraum verstanden und verantwortlich kuratiert hatte.
Der Lebenszyklus eines Gebäudes: Wie Daten unterwegs verloren gehen
Wenn man den Lebenszyklus betrachtet, wird deutlich, wo es knirscht:
Planung: Wir starten mit hohem Strukturgrad: BIM-Modelle, Leistungsverzeichnisse, definierte Attribute. Die Welt ist noch sauber – zumindest in der Theorie.
Bau und Übergabe: In der Bauphase wird angepasst, improvisiert, optimiert.
„As-built“ ist oft eine nette Idee, aber nicht konsequent umgesetzt. Bei der Übergabe landen Daten in Ordnern, auf Laufwerken, vielleicht im CAFM – oft ohne klare Übergabestrategie in den operativen Betrieb.
Betrieb: Hier entsteht die gesamte Dynamik: Umbauten, Anlagenwechsel, neue Flächennutzungen, geänderte Mieterstrukturen, Energieoptimierungen.
Aber: Datenpflege ist selten als klarer Prozess verankert. Es passiert viel in der Realität – wenig davon wird sauber im System abgebildet.
Optimierung, ESG, Reporting: Spätestens jetzt fliegt uns die Datenqualität um die Ohren. Wir wollen Kennzahlen, Benchmarks, ESG-Reporting, Lifecycle-Entscheidungen – und stellen fest: Die Datenbasis ist lückenhaft, inkonsistent oder schlicht unbekannt.
Der Bruch entsteht nicht an einer Stelle.
Viele kleine Brüche entstehen überall dort, wo niemand fachlich verantwortlich ist, die Daten über Zeit konsistent zu halten.
Anspruch vs. Wirklichkeit: Die Rolle der Anbieter – und der Kunden
Um Missverständnissen vorzubeugen: Viele CAFM-/IWMS-Systeme sind fachlich und technisch durchaus leistungsfähig.
Die Marketingwelt verspricht zuweilen: „Single Source of Truth“, „End-to-End-Prozesse“, „Plug-and-Play-Integration“, „Out-of-the-box Predictive Maintenance“ und 1000e andere Marketing-Buzzword-Aussagen. Oder tolle Features zum Abhaken. Und gern wird das als Beweis dafür angeführt, wie toll man selbst aufgestellt ist oder dass die Enstscheidung für das neue IWMS-/CAFM-System wohlbegründet und gut sei.
Das klingt verlockend, aber irgendwie zu glatt – aber auch nicht per se falsch. Falsch wird es, wenn man davon ausgeht, dass die Einführung eines neuen Systems automatisch Datenqualität sicherstellt, Prozesse diszipliniert (oder definiert!) und Verantwortlichkeiten klärt.
Das kann kein System leisten. Die Verantwortung liegt auf beiden Seiten: Anbieter sollten klarer kommunizieren, dass Technologie nur dann wirksam wird, wenn Datenstrategie, Governance und Prozesse im Betrieb ernst genommen werden. Und Kunden sollten aufhören zu glauben, man könne komplexe organisatorische Defizite mit einem Softwarekauf „erschlagen“. Aber dass will der Kunde von einem Software-Anbieter oft nicht hören. Oder der Vertrieb will es aus Angst um den Abschluss nicht kommunizieren.
Ohne klare Datenverantwortung wird jedes neue System nur ein weiterer, teurer Datenfriedhof mit schöner Oberfläche.
Typischer Projektverlauf: Warum es nach Go-Live oft bergab geht
Ich habe viele CAFM-Projekte gesehen, die einem Muster folgen:
Hohe Erwartungen: Viele Versprechen, viel Energie, klare Ziele, häufig guter Management-Support.
Datenrealität: Ernüchterung… Bestandsdaten sind uneinheitlich, veraltet, verteilt, nicht dokumentiert.
Strukturierungsphase: Workshops, Datenbereinigung, Modellierung. Es entsteht tatsächlich Ordnung – zumindest für den Moment.
Technisch erfolgreicher Go-Live: Das System läuft. Die Schnittstellen funktionieren. Trainings sind durchgeführt.
Alltag im Betrieb: Der Druck des Tagesgeschäfts kehrt zurück. Datenpflege ist „zusätzlich“. Verantwortlichkeiten sind nicht scharf genug definiert. Und nach 12–24 Monaten ist die Datenqualität spürbar schlechter als zum Go-Live.
Zentrale Fehleinschätzung: Datenqualität wird als Projektziel verstanden – nicht als Daueraufgabe.
Meine Kernthese: Wir haben kein Technologieproblem
Aus meiner Sicht sind die unbequeme Wahrheiten im CAFM-Umfeld:
Wir haben die Daten.
Wir haben die Systeme.
Wir haben das fachliche Know-how.
Was uns häufig fehlt, ist:
konsequente Data Ownership,
klare Prozesse für Datenpflege,
eine Kultur, in der Datenqualität als operative Aufgabe ernst genommen wird.
Und, das ist das Traurige, wenn wir das nicht als Ganzes adressieren, werden wir weiterhin neue Systeme einführen, weiterhin beeindruckende Präsentationen sehen und weiterhin nach einigen Jahren feststellen, dass wir auf einem neuen, schön verpackten Datenfriedhof sitzen. Da steht nur nicht mehr Excel/PDF/Word drauf, sondern CAFM oder meinetwegen auch IWMS.
Was aus meiner Sicht wirklich helfen würde (ohne Heilsversprechen)
Ich glaube nicht an die eine magische Lösung. Aber ich glaube an ein paar unbequeme, pragmatische Ansätze:
1. Echte Data Ownership statt Rollenfolklore
Für jede relevante Datenklasse (Flächen, Anlagen, Energie, Verträge, Störungen, Nutzer) braucht es einen klar benannten fachlichen Owner – mit Mandat und Zeitbudget, nicht nur im Organigramm.
2. Datenpflege als definierter Prozess, nicht als Nebentätigkeit
Jeder relevante Real-Life-Ereignis (Umbau, Anlagentausch, Mietvertragsänderung, ESG-Reporting-Anforderung) braucht einen klar beschriebenen Pfad ins System.
„Wir tragen das irgendwann nach“ ist keine Strategie.
3. Systemeinführung zwingend mit Prozess- und Verantwortungsanpassung koppeln
Kein neues CAFM/IWMS, ohne die Arbeitsorganisation zu ändern.
Wer macht was, wann, wie, in welchem System – und was passiert, wenn es nicht passiert?
4. Integration mit klarer fachlicher Zielsetzung
Nicht „alles an alles anbinden“, sondern präzise: Welche Daten sollen wohin, zu welchem Zweck, mit welcher Qualität und Verantwortung?
Integration ist ein Fachthema, kein reines Technikthema.
5. Transparenz über Datenqualität herstellen
Es ist besser zu wissen, was man nicht weiß, als sich auf eine scheinbare Vollständigkeit zu verlassen.
Datenlücken sollten benannt und sichtbar sein – nicht verschleiert.
Schlussfolgerung: Der größte Datenfriedhof ist die Organisation, nicht das System
Solange wir im Facility Management glauben, dass das nächste Systemupgrade unsere Datenprobleme löst, werden wir weiter neue Datenfriedhöfe eröffnen – nur mit modernerem Frontend.
Wir haben kein Technologieproblem.
Wir haben ein Organisations- und Kulturproblem im Umgang mit Daten.
Und das ist auch schon die gute Nachricht: Wir können es selbst ändern. Nicht mit der nächsten Lizenz, nicht mit dem nächsten Buzzword, sondern mit klarer Verantwortung, sauberen Prozessen und der ehrlichen Bereitschaft, Datenpflege als integralen Teil unserer Arbeit zu akzeptieren – nicht als lästige Zusatzaufgabe.
