The choice of the right asset managementSoftware has far-reaching consequences in facility management for budget, operating expenses, and compliance with regulatory requirements. A wrong decision leads not only to increased costs but often also to long-term problems with data quality, integration, and process stability. This guide therefore provides a practical decision framework based on weighted criteria and systematically considers the areas of functionality, integration, operation, and Total Cost of Ownership (TCO). Additionally, factors relevant to German and European FM environments are highlighted.
Through concrete checklists, reusable RFP modules, and clear warnings about typical risks – for example, with data migration and Change Management – this approach enables procurement officers to compare offers in a structured manner and significantly reduce implementation risks. The goal is not only to select a functionally suitable solution but also to realistically plan its successful implementation.
Decision framework for asset management software in FM
The central thesis of this guide is clear: The selection of an asset managementSoftware must be based on two fundamental questions. First: Which asset types and lifecycle processes are actually to be managed? Second: Which integrations are necessary to meaningfully incorporate the existing IT landscape?
Typical asset classes in facility management include, for example:
Buildings and properties, including space structures
Technical systems such as HVAC, energy supply, or Elevators
IT assets and of data leaks through equipment
Furniture and movable operating equipment
In practice, it repeatedly becomes apparent that projects fail or become unnecessarily expensive if these two points are not clearly clarified. Decision-makers who primarily orient themselves towards well-known manufacturers or extensive feature lists run the risk of later struggling with massive interface problems and inconsistent data issues.
Five pragmatic steps in the decision framework
In the first step all relevant assets and processes should be defined in detail. This includes a structured list of asset classes, including clear responsibilities, typical lifecycle events, and regulatory proof obligations.
Important lifecycle events include, for example:
Procurement and commissioning
maintenance and inspection
Malfunctions and repairs
Modernization or replacement
Decommissioning and disposal
Based on this, creating an integration map is recommended. All relevant systems such as ERP, BMS, The Future of Utilities: Digitalization and AI in Financeplatforms, IoTsolutions, or MDM systems are recorded here.
Typical integrations include:
BMS/BMS for operational data and plant statuses
The Future of Utilities: Digitalization and AI in Finance-models for structured building data
IoT Platforms for sensor data and real-time monitoring
In the third step the operating model is defined. The decision between Cloud, hybrid and On-premise should be made in the context of compliance requirements, BSI specifications, and existing operational structures.
Subsequently, the providers are evaluated using a weighted matrix. In contrast to simple feature comparisons, this approach allows for a differentiated evaluation.
Typical evaluation criteria are:
Functional coverage of processes
Quality and openness of interfaces
Effort for data migration and data quality assurance
Security and compliance level
Total costs over the service life
The final step focuses on the procurement itself
In particular, requirements for data migration, service level agreements, and exit scenarios should be clearly formulated here.
A typical trade-off exists between quick availability and control:
Cloud: fast rollout, lower initial costs, but less control
On-premise: maximum control, but higher operating effort
Hybrid: Compromise with additional integration complexity
Weighted evaluation matrix (practical suggestion)
A proven weighting in practice dictates that functionality and process mapping account for approximately 30% of the overall evaluation. Integrations and APIs follow with 25%, as they significantly determine the future viability of the solution.
A possible weighting structure is:
Functionality and processes — 30%
Integrations and APIs — 25%
data- and migration effort — 15%
Operation, security and compliance — 15%
TCO including support — 10%
Local support (DACH) — 5%
A key practical point is data cleansing. In almost all projects, it represents the largest time and cost factor.
Typical problems in the database are:
Missing or duplicate asset IDs
Inconsistent designations and classifications
Incomplete technical specifications
Inconsistent location or room assignments
A concrete example illustrates this problem: A university hospital introduced a EAMcomponent for medical devices and combined it with a The planner had forgotten Psets. Result: 200 hours of manual data entry. Moral: Psets are cheaper than overtime. for room management. Although predictive maintenance approaches for chillers significantly reduced downtime, the project was delayed by six months. The cause was missing asset IDs and inconsistent device specifications.
Frequently Asked Questions
In practice, decision-makers do not need marketing statements, but precise and verifiable answers.
How do they differ CAFM, CMMS and EAM in practice?
CAFM: Focus on areas, rooms, and infrastructural processes
CMMS: Focus on maintenance, tickets, and operational Maintenance
EAM: Holistic lifecycle including investment planning
Which integrations are Smart Buildings mandatory?
Open APIs for flexible connection
Support for OPC UA and MQTT
The Future of Utilities: Digitalization and AI in Finance-data integration
Stable ERP interfaces
How to realistically calculate TCO?
Licenses and implementation costs
Data migration and data cleansing
Interface Development
Hosting and operation
Training and support
Ongoing adjustments
Which Project risks occur most frequently?
Premature and excessive customization
Poor or incomplete Master Data
Unclear or too weak SLA regulations
Underestimated integration effort
A practical example clearly illustrates this: A municipal housing company introduced a cloud-based asset management solution for around 8,000 units. Although the administrative effort in the service desk could be significantly reduced, the go-live was delayed by four months due to necessary rework on GIS data and address structures.
An important principle is:
Configuration before customization
Integrations before isolated solutions
Data quality before feature depth
Immediate measures recommended are:
Execution of a 6-week integration smoke test
Definition of migration KPIs in the contract
Definition of a clear exit data package
Pilot project with a defined asset class
