In facility management, we like to talk about digitalization, CAFM, IWMS, and the "digital twin." We are less keen to discuss how we actually handle our data. And that's precisely where the problem lies.
We don't have a software problem in the CAFM environment.
We have an organizational and cultural problem in dealing with data.
The beautiful narrative: Everything integrated, everything available
When you look at presentations from CAFM and IWMS providers, our world actually sounds simple:
-
Consistent data from the BIM model through to operations,
-
a "single source of truth" for all building data,
-
fully integrated processes, from the ticket to the asset's lifecycle, and of course (drumroll!)
-
Predictive Maintenance, Smart Buildings, digital twins.
If all of this were a widespread reality, we wouldn't need many of these discussions. What I see in practice is something different: fragmented system landscapes, data graveyards, and organizations that don't truly know their own data – let alone use it consistently.
Data graveyards: Our secret core system
Most companies have them. Some call them "historically grown filing structures," others "document management," and still others simply "drive XY." They all mean the same thing: the data graveyard.
It consists of:
-
Network drives with folders that only insiders understand,
-
Excel files with versions like "final_v3_new_final_definitive_b",
-
Handover PDFs from construction projects that no one has opened for years, and
-
shadow lists from individual departments where the "really current data" is maintained.
The impressive thing: These graveyards are highly available. They have been working for years. And they reliably continue to grow.
The tragic thing: They are hardly usable from a technical perspective. No one has an overview. No one has responsibility. We often pretend that our CAFM is the "leading system." In reality, the leading system is often the drive with the Excel and PDF collections.
Isolated systems: Integration on paper, parallel worlds in practice
The IT landscape in FM is powerful today: We have systems for space, maintenance, energy, contracts, documents, tickets, IoT, and more.
Most of these systems can do a lot on their own. But they often don't really talk to each other.
Typical situations:
-
The CAFM knows the asset – but not its actual energy consumption,
-
the energy management system knows the consumption – but not which room the asset is in or its criticality, and
-
the ticketing system knows the fault – but not whether this asset has had issues for years or is about to be replaced.
Yes, there are interfaces, but: data models don't fit together cleanly, IDs are inconsistent or maintained inconsistently, and processes are not adapted to the interfaces. The result is not real integration, but parallel truths. Each system has its own version of reality.
The black box "interface"
Concepts often proudly state: "Integration of relevant third-party systems via standardized interfaces." Oh yes, that sounds great. In practice, it often looks like this:
-
CSV exports that run at night and nobody fully understands, APIs that exist but are sparsely documented and hardly monitored,
-
Import processes that only work when a specific person in the company operates them "as always".
I have experienced projects where the organization was firmly convinced that certain data was "integrated" – until we looked into the details and had to realize:
-
Yes, data is being transferred.
-
No, the professionally relevant fields are not included or not consistently included.
-
Yes, the user interface looks integrated.
-
No, the analyses are based on a fragmented data foundation.
More dangerous than missing data are data that you trust, even though they are not professionally reliable.
The uncomfortable truth: The data is there – but unused
We often talk as if we have a data shortage. In my experience, that's rarely the case... because what is very much present in most organizations are spatial data in floor plans, Excel, and CAFM. Or nicely jumbled equipment lists in handover documents, maintenance documents, ticket systems, or energy consumption in meters, portals, energy management systems. IT also has a great alert system via helpdesk systems and email, and of course, contract data exists in ERP, DMS, and specialized solutions.
The data is there. It's just distributed, structured differently, without clear ownership, and often without consistent context.
An example from my practice: An operator was convinced that they had no reliable failure history for critical equipment. "It was never recorded," they said. After a few days of analysis, it turned out that fault messages were available in the ticket system, maintenance reports were in PDFs in the DMS and in wildly maintained, individually managed Excel sheets, and dedicated technicians kept their own Excel lists of special incidents. Which everyone found somewhat sensible.
The data was available – just not as a "system," but as islands. We brought them together and were able to create reliable key figures retrospectively. The problem was never that the data was missing. The problem was that no one had curated it as a cohesive information space understood and responsible curated.
The life cycle of a building: How data gets lost along the way
Looking at the lifecycle, it becomes clear where the friction points are:
Planning: We start with a high degree of structure: BIM models, specifications, defined attributes. The world is still clean – at least in theory.
Construction and Handover: During the construction phase, adjustments are made, improvisation occurs, and optimization takes place.
"As-built" is often a nice idea, but not consistently implemented. During handover, data ends up in folders, on drives, perhaps in the CAFM system – often without a clear handover strategy for operational use.
Operation: This is where all the dynamics arise: renovations, equipment changes, new space utilizations, altered tenant structures, energy optimizations.
But: Data maintenance is rarely anchored as a clear process. A lot happens in reality – little of it is cleanly mapped in the system.
Optimization, ESG, Reporting: At the latest now, data quality comes back to bite us. We want key figures, benchmarks, ESG reporting, lifecycle decisions – and we realize: the data basis is incomplete, inconsistent, or simply unknown.
The break doesn't happen in one place.
Many small breaks occur wherever no one is professionally responsible for keeping the data consistent over time.
Claim vs. Reality: The role of providers – and customers
To prevent misunderstandings: Many CAFM/IWMS systems are technically and functionally quite capable.
The marketing world sometimes promises: "Single Source of Truth," "End-to-End Processes," "Plug-and-Play Integration," "Out-of-the-box Predictive Maintenance," and thousands of other marketing buzzword statements. Or great features to tick off. And this is often used as proof of how well one is positioned or that the decision for the new IWMS/CAFM system was well-founded and good.
This sounds tempting, and somehow too smooth – but not necessarily wrong in itself. It becomes wrong when one assumes that implementing a new system automatically ensures data quality, disciplines (or defines!) processes, and clarifies responsibilities.
No system can achieve this. The responsibility lies on both sides: providers should communicate more clearly that technology is only effective when data strategy, governance, and operational processes are taken seriously. And customers should stop believing that complex organizational deficits can be "overcome" with a software purchase. But customers often don't want to hear this from a software provider. Or sales, for fear of losing the deal, doesn't want to communicate it.
Without clear data responsibility, every new system will just be another expensive data graveyard with a nice interface.
Typical project progress: Why things often go downhill after go-live
I've seen many CAFM projects that follow a pattern:
-
High expectations: Many promises, lots of energy, clear goals, often good management support.
-
Data reality: Disillusionment... Inventory data is inconsistent, outdated, distributed, undocumented.
-
Structuring phase: Workshops, data cleansing, modeling. Order is actually created – at least for the moment.
-
Technically successful go-live: The system is running. The interfaces work. Training has been completed.
-
Everyday operations: The pressure of daily business returns. Data maintenance is seen as 'additional'. Responsibilities are not defined sharply enough. And after 12-24 months, the data quality is noticeably worse than at go-live.
Central misjudgment: Data quality is understood as a project goal – not as an ongoing task.
My core thesis: We don't have a technology problem
From my perspective, the uncomfortable truths in the CAFM environment are:
-
We have the data.
-
We have the systems.
-
We have the technical expertise.
What we often lack is:
-
consistent data ownership,
-
clear processes for data maintenance,
-
a culture in which data quality is taken seriously as an operational task.
And, sadly, if we don't address this as a whole, we will continue to introduce new systems, continue to see impressive presentations, and continue to find after a few years that we are sitting on a new, beautifully packaged data graveyard. It just won't say Excel/PDF/Word on it anymore, but CAFM or, if you like, IWMS.
What would really help from my perspective (without false promises)
I don't believe in the one magical solution. But I believe in a few uncomfortable, pragmatic approaches:
1. Real data ownership instead of role folklore
For every relevant data class (areas, assets, energy, contracts, disruptions, users), there needs to be a clearly named functional owner – with a mandate and time budget, not just on the organizational chart.
2. Data maintenance as a defined process, not a side activity
Every relevant real-life event (renovation, asset replacement, lease agreement change, ESG reporting requirement) needs a clearly described path into the system.
"We'll enter it later" is not a strategy.
3. System implementation must be coupled with process and responsibility adjustments
No new CAFM/IWMS without changing work organization.
Who does what, when, how, in which system – and what happens if it doesn't happen?
4. Integration with clear professional objectives
Don't 'connect everything to everything', but precisely: Which data should go where, for what purpose, with what quality and responsibility?
Integration is a subject matter expertise, not purely a technical issue.
5. Establish transparency about data quality
It is better to know what you don't know than to rely on a apparent completeness.
Data gaps should be named and visible – not concealed.
Conclusion: The biggest data graveyard is the organization, not the system
As long as we in facility management believe that the next system upgrade will solve our data problems, we will continue to open new data graveyards – just with a more modern frontend.
We don't have a technology problem.
We have an organizational and cultural problem in dealing with data.
And that's also the good news: We can change it ourselves. Not with the next license, not with the next buzzword, but with clear responsibility, clean processes, and the honest willingness to Data maintenance as an integral part of our work to accept – not as an annoying additional task.
