Short answer
Start with one class of critical rotating equipment, such as pumps or compressors, that already has instrumentation and a history of costly failures. Check that historian data and work order records are usable, build a baseline model that flags abnormal behavior, test it against past events, and agree who acts on each alert before going live.
Predictive maintenance is often presented as a large digital program. In practice, the projects that succeed start small, on equipment where the data already exists and the maintenance team has a reason to care. This guide sets out a first project that a reliability team can run and judge on its own terms.
Where predictive maintenance fits
Most sites use a mix of maintenance strategies:
- Corrective: repair after failure. Acceptable for low-consequence equipment.
- Preventive: fixed-interval tasks. Simple to plan, but parts are sometimes replaced while healthy and failures between intervals are still possible.
- Condition-based: act when a measured condition crosses a limit, such as a vibration alarm.
- Predictive: use patterns in the data to detect developing faults earlier than a single alarm would, and estimate how urgent they are.
The idea behind condition-based and predictive maintenance is the interval between the point where a fault becomes detectable and the point of functional failure, often drawn as the P-F curve. The earlier you detect, the more time you have to plan the repair instead of reacting to a trip.
Predictive maintenance does not replace safety-critical inspections or regulatory intervals. It adds information that helps plan everything else.
Step 1: choose the right assets
A good first candidate has four properties:
- It matters. Failures cause production loss, safety exposure or high repair cost.
- It is instrumented. Vibration, bearing temperature, pressure, flow and motor current are already recorded.
- There are several of them. A fleet of similar pumps gives the model more examples than a single unique machine.
- Someone owns it. A reliability engineer or maintenance planner will review alerts and act.
Centrifugal pumps, gas compressors and large motors are common choices.
Step 2: audit the data
Most of the effort in a first project goes into understanding the data. Check:
| Data | What to check |
|---|---|
| Historian tags | Which tags exist per asset, their sample rate, how far back they go, gaps, and how values are compressed or averaged |
| Vibration data | Whether you have online overall values, periodic route readings or full spectra, and from which bearings |
| Work orders | Whether failures are coded consistently, with dates, failure modes and the parts replaced |
| Operating context | Start and stop events, duty changes, product changes and planned shutdowns |
| Equipment data | Make, model, rated speed and power, and installation date |
If your organization follows ISO 14224 for reliability and maintenance data, this step is much easier, because failure modes and equipment boundaries are already defined. If not, a short cleanup of recent work orders is usually worth doing.
For vibration, ISO 20816 provides evaluation guidance and zones for many machine types. For the overall monitoring process, ISO 17359 gives general guidelines on condition monitoring programs. These standards help you agree with the team what "abnormal" means before any model is built.
Step 3: build a baseline model
With limited failure history, the most practical start is anomaly detection: a model learns how each machine normally behaves across its operating range and flags readings that do not fit. Because pump behavior depends on load, the model has to consider operating conditions such as flow and speed, not only fixed thresholds.
Keep the first model simple and explainable. When it raises an alert, the engineer should see which signals moved, by how much, and compared with what. An alert that says only "anomaly score high" will be ignored after the first false alarm.
Step 4: test against the past
Run the model over historical data and compare its alerts with the work order history. For each recorded failure, ask: would the model have flagged it, and how early? For each alert, ask: was there a real issue, or was it a startup, a process change or a sensor fault?
This back-test is the main evidence your team will use to decide whether to trust the system. Share it in full, including misses and false alerts.
Step 5: design the alert workflow
Most predictive maintenance projects that stall do so here, not in the modeling. Before go-live, agree:
- Where alerts appear: the CMMS, email, the control room screen or a dashboard.
- Who reviews them and how quickly.
- What the possible actions are: monitor, inspect, plan a repair or dismiss with a reason.
- How dismissed alerts feed back to improve the model.
An alert without an owner is noise. Name the role that acts on each alert type before the first one fires.
Step 6: measure and decide
After a defined period, review alerts raised, issues confirmed, issues missed, and maintenance actions taken because of the system. Combine these with the team's view of whether alerts were useful. That evidence, from your own site, is what justifies extending to more assets.
Common pitfalls
- Starting with too many assets. Breadth hides problems that a focused pilot would expose.
- Ignoring operating context. Without start, stop and duty data, models confuse process changes with faults.
- Treating sensor faults as machine faults. Data quality checks belong in the pipeline from day one.
- No feedback loop. If engineers cannot mark an alert as wrong, the model cannot improve and trust falls.