Predictive Maintenance: What It Needs to Work

PwC Canada launched a physical AI service offering on September 8, aimed at asset-heavy industries wanting productivity gains from AI-powered robotics and autonomous systems. Predictive maintenance is usually the first thing on that list, because the pitch is irresistible: know the pump is failing before it fails. The reason most small and mid-sized projects stall is not sensors or software. It is that predicting a failure requires having recorded the last several.

Three maintenance strategies, and where this one sits

Approach	Trigger	Main cost
Reactive	It broke	Downtime, emergency rates, collateral damage
Preventive	The calendar says so	Servicing parts with life left in them
Predictive	The readings say so	Sensors, integration, and someone who responds

Most Canadian small businesses run a mix of the first two without ever calling it a strategy. The honest comparison for a predictive project is against your current preventive schedule, not against chaos, and preventive maintenance done consistently is already a decent baseline.

The data requirement nobody mentions in the demo

Prediction needs two separate things. Condition data, which is a live stream from a sensor measuring vibration, temperature, current draw, pressure or acoustics. And labelled failure history, meaning records of what actually broke, when, and what the readings looked like in the weeks before.

The first is easy to start. Retrofit sensors cost low hundreds of dollars per monitoring point and can be installed this month. The second cannot be bought or backfilled, because it had to be recorded while the failures were happening.

This is where projects die quietly. A business has ten years of maintenance records, opens them, and finds entries like "fixed compressor" with a date and a cost. No failure mode, no component, no readings, no note about whether it was caught early or ran to destruction. That is a bookkeeping record rather than a training set, and the general version of the problem is in data quality as the AI bottleneck.

Which assets justify it

Three filters, and an asset needs all three.

Failure is expensive. Not annoying, expensive. A production line stopping, a walk-in cooler full of stock, a service van off the road at the start of the busy season, an after-hours emergency callout at triple rate.

Failure is gradual. Bearings degrade, seals weep, belts fray, motors draw more current as they struggle. Something that snaps without warning gives a model nothing to detect, no matter how good the sensor.

You have several similar units. Patterns need repetition. One unique machine gives you one example of each failure mode, which is not enough to learn from, though it may still be worth monitoring against thresholds.

Rotating equipment passes all three, which is why every case study features motors, pumps, compressors, fans and gearboxes. HVAC contractors, food processors, machine shops, property managers and fleet operators are the Canadian businesses this actually fits.

Start with thresholds, not models

A large share of the benefit comes from something much simpler than machine learning. A sensor tells you the bearing housing is running 12 degrees hotter than it did last month. That does not need a model, a failure history, or a data scientist, and it catches a real proportion of what a learned system would catch.

Thresholds also do the thing that matters most, which is building the habit of acting on an alert. Every predictive maintenance project that fails to pay back fails at that step rather than at the algorithm. Alerts arrive, nobody owns them, they get muted after a fortnight, and eighteen months later the dashboard is a decoration.

Run thresholds for a year and two useful things happen. You find out whether your team responds. And you accumulate exactly the labelled history a model would need, because now every alert has a recorded outcome attached to it.

What to record from today

This part costs nothing and is worth more than any sensor purchase you could make this quarter. When something breaks, record five fields.

Asset identifier. Which specific unit, not "the compressor."

Failure mode. Bearing, seal, belt, control board, motor winding. A short list your technicians agree on beats free text.

Was it caught early or did it run to failure. One field, enormously useful later.

Runtime hours or cycles at failure. Where you can get it.

Total cost, including downtime. This is what tells you which assets clear the first filter, and it is the number that makes the business case later.

Two years of that turns an unusable pile of invoices into a training set. Businesses running SAP Plant Maintenance already have a structure for this, covered in predictive maintenance with SAP PM, and the scheduling side is in AI manufacturing scheduling.

A realistic first year

Pick the three assets whose failure costs you the most. Fit condition sensors and set conservative thresholds. Name one person who owns the alerts and give them authority to book the work. Record the five fields on every intervention, whether or not the sensor caught it.

At the end of the year you will know your response rate, your false alarm rate, and the real cost of the failures you avoided. That is the point at which a prediction model becomes a sensible purchase rather than a hopeful one, and the ROI calculator will finally have honest numbers to work with.

Frequently Asked Questions

What is predictive maintenance?

Servicing equipment based on evidence that it is heading toward failure, rather than on a fixed schedule or after it breaks. Sensors track something measurable such as vibration, temperature, current draw or pressure, and a model flags when the pattern is drifting toward a known failure mode. It sits between preventive maintenance, which services on a calendar whether or not anything is wrong, and reactive maintenance, which waits for the breakdown.

What data does predictive maintenance need?

Two things, and the second is the one that stops most projects. You need a stream of condition data from the asset, which sensors can start producing this month. You also need labelled failure history, meaning records of what broke, when, and what the readings looked like beforehand. A model cannot learn to recognise a bearing failure it has never seen. Businesses that logged repairs as free-text notes in a scheduling tool usually find that history unusable.

How much does predictive maintenance cost for a small business?

Retrofit vibration and temperature sensors typically run in the low hundreds of dollars per monitoring point, plus a gateway and a monitoring subscription. The sensors are rarely the expensive part. The cost sits in installation on equipment that was not designed for it, in integration with whatever you use for work orders, and in someone reliably acting on the alerts. Budget for the third item, because a system nobody responds to produces no savings at all.

Which equipment is worth monitoring?

Apply three filters. Failure has to be expensive, in downtime, spoilage, safety or emergency callout rates. Failure has to be gradual rather than instant, since something that fails without warning gives a model nothing to detect. And you need enough identical or similar units for patterns to mean anything. Rotating equipment such as motors, pumps, compressors, fans and gearboxes fits all three, which is why nearly every case study features them.

Do I need AI for predictive maintenance?

Not to start. Simple threshold alerting, where a sensor tells you a bearing is running 12 degrees hotter than last month, captures a large share of the benefit and needs no model or failure history. Move to a learned model once you have both the data and evidence that thresholds are producing too many false alarms or missing real problems. Starting with thresholds also builds the habit of acting on alerts, which is the part that actually determines whether any of it pays back.