Maintenance based on the principle of hope doesn't work ("No! Yes! Ohhh!").
Availability, safety, and operator responsibility depend significantly on how ruthlessly you structure your maintenance. But let's be honest: most maintenance plans end up as confusing data graveyards because they were never built for the reality of a CAFM system. This article shows how to create a maintenance plan that doesn't starve on paper – with tough risk prioritization, real mandatory fields, and integration into systems like Wave, Speedikon, or RIB FM.
1. Inventory: A CAFM without clean asset IDs is just an expensive address book
The illusion of many CAFM projects begins with the inventory structure. You buy expensive software and dump uncleaned legacy data into it. A practical inventory takes a razor-sharp assessment: Which technical building equipment (TGA) systems are subject to the maintenance plan and which are not? Use a relational structure, not flat lists.
- Asset ID: The unique identifier. Without it, all database logic collapses.
- Location: Building, floor, room – precisely located.
- Lifecycle & Status: In operation, in need of repair, being replaced.
- Responsible person: A name, not an anonymous department group.
A typical beginner's mistake is over-engineering: you want to immediately capture 50 attributes per asset and fail at data maintenance. Rigorously separate mandatory fields from "nice-to-have" attributes. A medium-sized production facility that limits itself to HVAC modules with clean IDs and locations imported its maintenance plan into CAFM flawlessly in three days – while the perfectionists were still fiddling with the Excel column for housing color ;-)
2. Risk-based prioritization: No more shotgun maintenance
Anyone who considers everything equally important ends up not properly maintaining anything. The scattergun approach wastes budgets and ignores real operator responsibility. Without a defined criticality (watch out, a buzzword for you: "Criticality Definition"), your resources are distributed arbitrarily.
Build a risk matrix: probability of failure multiplied by the severity of the consequence (for operations, safety, environment). The result dictates the maintenance type:
- Time-Based Maintenance (TBM): Preventive calendar maintenance. Good for systems with stable wear and tear.
- Condition-Based Maintenance (CBM): Condition-based via IoT sensors. Expensive to set up, unbeatable in operation – but only if you have defined real limit values.
- Run-to-Failure: Yes, this is also a valid strategy for non-critical components whose replacement is cheaper than monitoring (aka "Maintenance by breakdown").
The practice: The central hydraulic pump (criticality 5) gets IoT sensors for CBM. The fan in the adjacent warehouse (criticality 2) is visually inspected annually via TBM. This simple distinction saves massive operational costs. And some cheap component (which you have in stock anyway) is replaced when it breaks.
3. The template: Mandatory fields instead of data messiness
A maintenance plan must guarantee audit compliance. It's not prose, but a contract with operations. Separate basic fields that CAFM absolutely needs for ticket creation from optional fields.
The absolute minimum: Asset ID, location, maintenance type, interval, responsible person, checklist (What exactly needs to be done?), last/next maintenance. Only when these fields have 100% data quality do you enable things like "Associated stock level" or "Special tools".
4. Interval definition: Blind trust in manufacturer specifications costs money
If you only maintain according to manufacturer specifications, you primarily enrich the manufacturer's spare parts sales. Manufacturers often define maximum safety (and maximum revenue). Combine these basic specifications with real operating data (operating hours according to ISO 50001) and Your Risk assessment.
A calendar-based interval (every 12 months) gives the controller a good feeling, but is often inefficient with fluctuating load profiles. If the system runs for 4,000 hours one year and only 1,000 the next, your budget goes to waste. Link intervals to actual operating hours or sensor data wherever the M&E allows.
5. Resources and SLAs: Somebody is nobody
A plan without assigned resources is pure fiction. Define responsibilities using a clear RACI matrix. "The building services" is not a responsible party. Mr. Müller or subcontractor XY are responsible parties.
This leads directly to the make-or-buy decision: In-house teams offer flexibility, external service providers scale better. If you outsource, the life and death of the maintenance plan depend on watertight SLAs and the service provider's obligation to report its results directly into Your CAFM.
Anyone who accepts PDF reports from subcontractors has not understood digitalization.
6. CAFM integration: The moment of truth
This is where 80 percent of Excel plans fail. Integration into Planon, Archibus, or SINGU determines whether your plan lives. A clean maintenance plan must automatically generate a work order in CAFM, block the spare part in the ERP, and notify the technician via app.
This requires functioning mapping: field types (date, interval, status) must be identical in both systems. Use ETL scripts (Extract, Transform, Load) as a firewall between your initial data entry and the CAFM. Without clean master data, automation will only produce hundreds of data garbage tickets at lightning speed. And a deep red dashboard.
7. Conclusion: Pilot instead of philosophize
Stop designing the perfect, company-wide maintenance plan at a round table. Take a sample line, fill it with real data (e.g., P-HVAC-01, main pump north, 12 months, visual inspection) and run this single data set through your system.
| Field | Harsh FM Reality (Example) |
|---|---|
| Asset ID (Unique) | P-HVAC-01 |
| Location (Mappable) | MEP Central North / Rm. 0.12 |
| Maintenance Type & Interval | TBM / 4,000 operating hours |
| Responsible / SLA | External / Service Provider Meier GmbH |
| CAFM Status | Auto Ticket Generated |
The next step: Start a three-week pilot run in a manageable M&E sector. Measure the planned vs. actual deviation, capture mapping errors, and only scale up when the system is running smoothly. Otherwise, you'll end up like Louis de Funès ;-)


