How to Move from Preventive to Predictive Maintenance

A production line stops at 3am. The technician who knows this machine is on annual leave. The asset has been serviced eleven times: four of those visits were written on paper, two were logged against a site rather than the machine, and the rest are spread across a scheduling system and a shared drive.

Nobody can say whether this failure was predictable, because nobody can assemble what the machine has actually been doing. That is the real barrier to predictive maintenance, and it is not an analytics problem.

This guide explains how to move from calendar-based servicing toward condition and predictive maintenance without a failed data project. We break down the four maintenance strategies and what each actually requires, how to test whether your data can support prediction, how to pick the first asset class, the resourcing cost nobody mentions, and a twelve-month plan that finishes.

Why Calendar-Based Preventive Maintenance Stops Scaling

Preventive maintenance schedules work on an interval (every 90 days, every 500 hours, every so many cycles), taken from the manufacturer, from regulation, or from experience. It is predictable, easy to resource and easy to evidence, which is why most field service operations run on it.

Its limits show up as an operation grows:

• You service things that did not need servicing. The interval is set for the worst case, so most visits are early. That waste is invisible because it never causes an incident.
• You still miss the ones that did. An asset running harder than the average fails between intervals, and the calendar has no way to know.
• Intervals drift shorter, never longer. Nobody is ever blamed for a service that was not needed. Everybody is blamed for a failure. Over years this asymmetry inflates the programme.
• It cannot tell you which assets to replace. A calendar produces visits, not evidence about whether a machine is worth keeping.

The answer is not to abandon preventive maintenance. It is to let condition data adjust intervals within it, which requires knowing what condition data you actually have.

How to Tell the Four Maintenance Strategies Apart

Most confusion here comes from collapsing four approaches into two words. They have different data requirements and different failure modes.

The gap between condition-based and predictive is far larger than the gap between preventive and condition-based. Condition-based is reachable for most operations within a year using technicians and a meter. Predictive is a genuine data project, and most operations describing themselves as predictive are doing condition-based work, which is a perfectly good place to be and considerably cheaper to hold.

How to Test Whether Your Data Can Support Prediction

There is a single test that settles this quickly. Pick one asset class and ask whether you could plot one measured value against time for the last two years. Not whether the information exists somewhere: whether you could produce that chart this afternoon.

If the answer is no, three things are usually responsible:

• Readings were recorded as prose. “Running hot” cannot be trended. Readings have to be numeric fields with fixed units, captured the same way by every technician.
• History belongs to the visit, not the asset. When the machine is moved, recontracted or reassigned, visit-anchored history is orphaned. Asset-anchored history survives.
• The reading was taken at different points. A temperature at start-up and a temperature after an hour running are different measurements. Averaged together they are noise.

Fix those three at the point of capture rather than cleaning data afterwards. Cleaning historical maintenance data is almost never worth what it costs.

Cleaning historical maintenance data is almost never worth what it costs.

This is fundamentally a record-keeping problem: asset management is what keeps readings and visit history attached to the machine rather than the job.

How to Choose the First Asset Class

Do not start with the most critical equipment. Start where you have the most repetition, because that is where a pattern becomes visible in a reasonable period.

• Enough units of the same type. A fleet of two hundred similar pumps beats four bespoke chillers. You need failures to learn from, and rare assets do not supply them.
• A leading indicator that moves before failure. Not at the moment of failure. If the only signal is the alarm, there is nothing to predict.
• Failure cost high enough to justify effort, low enough to risk. You will eventually extend an interval based on a forecast. Choose a class where being wrong is affordable.
• Serviced by your own technicians. At least initially, so you control how the reading is captured.

How to Handle the Resourcing Cost Nobody Mentions

Predictive maintenance moves work from a predictable calendar to an unpredictable signal. That is better for asset life and worse for resourcing, and it is the part vendors skip.

If your technicians are already fully committed, a model announcing that three machines need attention this week does not help unless something else can move. Operations that adopt this successfully keep a preventive baseline and let prediction adjust intervals within it, rather than replacing the schedule outright.

There is a commercial dimension too. If you service these assets under contract, changing the interval is a variation to that agreement however much better the outcome. The engineering case being sound does not make it a decision you can take alone, and the first extended interval reads to a customer as service being cut unless the conversation happened first.

Entitlements and agreed service intervals live in the contract, which is why this conversation starts there: see contract management for how coverage and renewal dates are held against the customer and the asset.

How to Run a Twelve-Month Plan That Finishes

Programmes in this area fail by being open-ended. A version with an end date, scoped to one asset class, is far more likely to produce something.

• Months 1–3: capture. Pick the asset class. Agree the two or three readings that matter and add them as required numeric fields on the service form. Change nothing about intervals yet.
• Months 4–6: audit. Check what is arriving and fix it at source. Expect gaps and inconsistency. This is the month most programmes quietly stop; push through it.
• Months 7–9: correlate. Compare the trend against failures you have had. You are not predicting yet: you are testing whether the reading you chose relates to the failure you care about.
• Months 10–12: act. If the relationship holds, set a threshold and run condition-based on a subset, keeping the preventive interval underneath as a backstop.

At the end you will either have a working condition-based programme on one asset class, or clear evidence that the reading you chose predicts nothing. Both are worth twelve months. What is not worth twelve months is a platform evaluation that produces neither.

Do You Need Sensors to Do This?

Most writing on predictive maintenance assumes instrumentation: vibration sensors, thermal monitoring, a telemetry feed. That is one route and it is the expensive one.

The cheaper route, available to any operation already attending these assets, is to treat the technician as the sensor. A reading taken consistently every visit, recorded as a number against the asset, produces a usable trend over a maintenance cycle or two at no capital cost. It is lower resolution than continuous monitoring and considerably better than nothing, which is what most operations have.

Instrument the assets where failure cost justifies it. For everything else, fix the record and let the people already standing there do the measuring.

How to Get Technicians to Capture Readings Consistently

Every plan in this guide depends on readings arriving in a usable form, and that depends entirely on the technician standing at the machine. This is where most maintenance data programmes actually fail.

• Make the reading a required field, not a note. A numeric field with fixed units that blocks job completion. A free-text box will be filled with prose within a fortnight.
• Ask for fewer readings than you want. Two or three values captured reliably beat a dozen captured sometimes. You can add more once the habit exists.
• Specify when in the visit the reading is taken. At start-up, after an hour running, at shutdown. Without this, values from the same technician are not comparable to each other, let alone across a team.
• Show the technician the trend. If they can see the last six readings for the machine in front of them, capture stops being data entry and becomes part of diagnosis. This single change does more for consistency than any policy.

The last point is the one that separates programmes that survive their first year from those that quietly lapse. A technician who can see that the value they are recording has been climbing for four visits has a reason to record it accurately.

Frequently Asked Questions