The vendor pitch for predictive maintenance is everywhere, but most facility teams are not blocked by AI capability. They are blocked by the data underneath it. If equipment names are inconsistent, work orders close with one-line notes, and meter readings live in a technician's notebook, no model will produce a useful prediction. The honest path is a staircase: reactive control, then preventive discipline, then condition monitoring, and only then predictive insight.
- Predictive maintenance is a data outcome, not a software purchase.
- A clean asset register and standardised work orders deliver 80% of the value before any AI is introduced.
- Failure codes and meter data are what convert maintenance history into a predictive signal.
- The end goal is fewer surprise failures and calmer operations, not more dashboards.
Stage 1: Build a Reliable Asset Register
Every predictive programme starts with a single, trustworthy answer to: what equipment exists, where it sits, and who is accountable for it. Most sites underestimate this stage because the register already "exists" in a spreadsheet, but the moment two technicians name the same chiller differently, every downstream report fractures. Treat the asset register as the master record that every work order, meter, and failure code will be tagged against.
What to capture per asset
- Unique asset ID, parent system, and physical location down to floor or zone
- Equipment type, manufacturer, model, serial number, and commissioning date
- Maintenance priority or criticality tier (A / B / C)
- Service vendor, warranty expiry, and contract reference
- Linked documents: manuals, schematics, last service report
Common mistakes
Duplicate records for the same physical asset, free-text location fields ("near pantry"), and missing criticality tiers are the three issues that surface repeatedly during data audits. Fix these before adding sensors or scheduling rules on top.
Stage 2: Standardise Work Orders
Work orders are the historical record a predictive engine will eventually learn from. If they are inconsistent, the model inherits the inconsistency. Every job, whether routine PM or emergency callout, should be closed against the same minimum data set so that patterns can be compared across months and across assets.
Minimum fields on every closed work order
- Request source (PM schedule, user request, BMS alarm, inspection finding)
- Linked asset ID and the specific component or sub-system affected
- Fault category, action taken, and parts consumed
- Labour hours, downtime window, and technician on record
- Completion evidence (photo, reading, signature) and supervisor verification
"Fixed aircond" tells the system almost nothing. "AHU-03 belt worn, vibration abnormal, belt replaced, bearing noise monitored" becomes useful maintenance intelligence.
Stage 3: Capture Failure Codes and Root Causes
Free-text fault descriptions are the single biggest reason maintenance analytics projects stall. A predictive model cannot count "leaking", "drip", "water coming out", and "seal gone" as the same event. A short, controlled failure taxonomy, applied consistently, is what turns work order history into trend data.
A workable starter taxonomy
- Electrical (short, overload, contactor, control board)
- Mechanical (bearing, belt, coupling, wear)
- Control or sensor (faulty reading, calibration drift, comms loss)
- Fluid (leakage, blockage, pressure loss, contamination)
- Thermal or vibration anomaly, user damage, no-fault-found
Bad: "Pump not working, repaired." Good: Asset CHWP-02, failure class Mechanical > Bearing, root cause Lubrication Loss, action Bearing Replaced, downtime 90 minutes. The second record is what allows a future model to flag CHWP-02 before the next bearing fails.
Stage 4: Add Meter and Condition Data
This is the stage most vendors want to start at; it is the wrong place to start. Meters, sensors, and BMS feeds only become useful once the CMMS already knows the asset, the maintenance history, and the failure language for that asset. Otherwise condition data becomes a wall of unlabelled numbers.
Useful condition signals to capture
- Runtime hours and start/stop cycle counts
- Vibration amplitude and temperature on rotating equipment
- Energy consumption (kWh) and power factor trends
- Pressure, flow, and differential pressure across filters or coils
- BMS alarm events tagged to the same asset ID used in the CMMS
Every meter, sensor, or BMS point pushed into the CMMS must reference the same asset ID used on work orders. No shared ID, no predictive baseline.
Stage 5: Move From Alerts to Maintenance Decisions
A predictive alert that goes straight to a screen is wasted. The output must enter the same operational rhythm the team already runs on: inspection rounds, planned work orders, spare part reservations, and supervisor sign-off. Otherwise the system generates noise, technicians lose trust in it, and the investment quietly dies.
The alert-to-decision pattern
- Signal triggers an early-warning ticket against the affected asset
- Supervisor reviews against recent work history and condition trend
- Recommended inspection or PM is scheduled inside the existing planner
- Required spares are reserved or raised against the vendor
- Outcome and root cause are written back to close the learning loop
Example: vibration on AHU-03 trends 18% above baseline for seven days. CMMS opens an early-warning ticket, supervisor reviews the last bearing replacement date, an inspection is scheduled at the next low-load window, and the spare bearing is reserved. The fault is fixed before it becomes a breakdown.