Predictive Maintenance, Practically: What It Takes to Get Real Value
TL;DR
- Predictive maintenance only pays off when you have decent sensor data, a real history of failures, and a workflow that turns an alert into an action. Skip any one of those and the project stalls.
- Most teams should start with condition monitoring and simple anomaly detection, not machine learning. The boring version catches a surprising share of the failures and proves the action path works.
- Measure ROI in avoided downtime and avoided secondary damage, not model accuracy. If nobody acts on an alert, the model was a waste of money no matter how clever it was.
What are the three maintenance modes, and what does each actually cost?
Every plant runs on some mix of three maintenance modes, whether anyone has named them or not. Reactive means you fix things when they break. Scheduled, sometimes called preventive, means you service on a fixed calendar or run-hours interval no matter what condition the asset is in. Predictive means you watch the asset's actual behaviour and intervene just before it fails. Most operations we walk into are running a messy blend of the first two and calling it a strategy.
The costs are not where people expect. Reactive feels cheap because you only spend money when something stops, but the real bill shows up as unplanned downtime, rushed parts at premium prices, overtime, and the secondary damage a failed component does to everything around it. A bearing that seizes can take a shaft and a coupling with it. Scheduled maintenance trades that chaos for predictability, but you pay for it in wasted life: you're throwing out parts that had months left and burning labour hours on machines that were perfectly healthy.
Predictive sits between the two and tries to capture the best of both. Done well, you service close to the actual end of useful life and you do it on a planned shift instead of at 2am. But it isn't free either, and the cost is mostly upfront and mostly invisible: data, instrumentation, and the discipline to act on what the data says.
- Reactive: lowest planning effort, highest true cost per failure once downtime and collateral damage are counted.
- Scheduled: predictable spend and easy to plan, but routinely wastes remaining component life and labour.
- Predictive: lowest waste and least unplanned downtime, but needs data and a working action path to deliver.
- Most plants are accidentally reactive on their critical assets and over-serviced on their cheap ones - exactly backwards.
- The expensive failures are almost always the ones with secondary damage, which is precisely what prediction is good at catching early.
What does predictive maintenance actually require?
Here's the part the glossy case studies skip. Predictive maintenance is not a model you buy. It's three things that have to exist together, and the model is the smallest of them.
First, you need sensor data that reflects how the asset is actually behaving - vibration, temperature, current draw, pressure, acoustic, whatever signals degradation for that machine. Second, you need a history of failures, ideally with the events labelled: this asset failed on this date, this was the failure mode, here's what the data looked like in the weeks before. Third, you need a path from a signal to a decision to a work order, with a human who owns each step. Miss the third and you've built an expensive dashboard.
The uncomfortable truth is that the labelled failure history is the rarest of the three, and it's the one you can't shortcut. A model learns what 'about to fail' looks like by being shown examples of it. If you've been doing scheduled maintenance for a decade, you may have replaced parts hundreds of times and recorded almost none of it in a way a model can use. That gap is where most projects quietly die.
- Sensor data: the right signals for the failure modes you care about, sampled often enough to see degradation coming.
- Failure history: dated, labelled events tied back to the sensor data from the period before each failure.
- Action path: a defined route from alert to triage to scheduled work, with named owners at each handoff.
- Asset criticality ranking: you can't instrument everything, so you need to know which 20 percent of assets cause 80 percent of the pain.
- A baseline of normal: even simple methods need to know what healthy looks like for each machine and each operating mode.
Why do most predictive maintenance projects stall?
We've seen this pattern enough times to call it. The pilot looks great on a slide, money gets approved, and then twelve months later the system is either switched off or being ignored. The reasons are boringly consistent, and none of them are about the algorithm.
The first killer is no failure data. The team wants to predict failures but has never systematically recorded them, so there's nothing to train or validate against. The second is dirty sensor data - sensors that drift, that get unplugged during a maintenance job and never reconnected, that report in three different units across two sites, or that flatline for weeks before anyone notices. A model trained on garbage will confidently predict garbage. The third, and the most painful because it's the most fixable, is no path to action. The system raises an alert, the alert lands in an inbox nobody owns, and nothing happens. After the third alert goes nowhere, people stop trusting the system entirely.
Notice that two of the three are data problems and one is an organisational problem. None is a modelling problem. That's the consistent lesson: the hard part of predictive maintenance is almost never the prediction. First-hand, the single most common root cause we find is that the maintenance team was never brought into the project until after the dashboard was built - so the people who'd actually act on the alerts had no reason to trust them and no workflow to fit them into.
- No labelled failures means nothing to learn from and no honest way to measure whether the model works.
- Drifting, miscalibrated, or disconnected sensors poison the data faster than any model can compensate for.
- Inconsistent units, tags, and sample rates across sites turn integration into the bulk of the project budget.
- Alerts with no owner and no workflow get ignored, and trust evaporates after a few dead-end notifications.
- Maintenance teams brought in late treat the system as something done to them, not something they rely on.
Should you start with anomaly detection instead of machine learning?
Yes, almost always. The instinct is to jump to a model that predicts remaining useful life down to the day. Resist it. That kind of model needs rich failure history you probably don't have yet, and it's the hardest thing to validate. Start with condition monitoring and simple anomaly detection, which need far less and prove the most.
Condition monitoring is just watching the key signals against sensible thresholds and trends. Vibration creeping up week over week. Bearing temperature running ten degrees hotter than it did last month under the same load. Motor current drifting. You don't need machine learning to flag that a signal has left its normal band - you need a baseline and a rule. Anomaly detection takes one step further and learns the normal envelope automatically across operating modes, so it catches the weird stuff a fixed threshold misses. Both are explainable, both are cheap, and both give your team something concrete to react to right now.
The bonus is that running condition monitoring is how you generate the labelled failure data you'll need later. Every time an alert leads to an inspection, you record what you found and what the data looked like beforehand. Eighteen months of that and you suddenly have the training set that makes the fancier model viable. The simple system isn't a detour around the advanced one - it's the road to it.
- Threshold and trend monitoring catches a large share of mechanical failures with no model at all.
- Anomaly detection learns the normal envelope per machine and operating mode, catching what static limits miss.
- Simple methods are explainable, so technicians trust and act on them instead of arguing with a black box.
- Each acted-on alert becomes a labelled data point, building the failure history the advanced model will need.
- You get value in weeks, not quarters, which keeps the project funded long enough to mature.
Why is an alert nobody acts on worthless?
This is the part teams underinvest in, and it's the part that decides whether the whole thing works. An alert is not an outcome. A repaired machine is an outcome. Everything between the signal and the repair is workflow, and if that workflow is broken, the cleverest model on earth produces zero value.
Think through the human chain. A signal crosses a threshold. Something decides it's worth a human's attention rather than noise. A specific person gets notified in a place they actually look. That person can triage it - confirm it's real, judge the urgency, and see enough context to act. They raise a work order that lands in the planning system. The work gets scheduled into a real shift with the right parts on hand. Someone does the job and records what they found. Break any single link and the chain fails silently. The most common break we see is alert fatigue: the system cries wolf, technicians learn to ignore it, and a real failure sails straight through.
So treat the workflow as a first-class part of the project, not an afterthought. Tune sensitivity so alerts are rare and meaningful. Route them to a named owner. Give that owner the context to act in under a minute. Close the loop by recording the outcome of every alert, which both builds trust and feeds your data. The model is maybe a fifth of the work here. The workflow is most of it.
- Define the full chain: signal, triage, work order, scheduling, repair, recorded outcome - with an owner per step.
- Tune for precision early; a few trusted alerts beat a flood of noisy ones that train people to ignore the system.
- Give the triager enough context - asset, history, the signal trend - to decide in seconds, not by hunting.
- Record what every alert turned out to be, true or false, to build trust and grow the failure dataset.
- Watch for alert fatigue as the leading indicator that the system is about to be quietly abandoned.
How do you measure ROI on predictive maintenance?
Measure it in avoided downtime and avoided damage, not in model accuracy. A model with 95 percent accuracy that nobody acts on returns nothing. A crude alert that prevents one catastrophic failure on a critical line can pay for the entire program. The metric that matters is operational, not statistical.
Build the business case from what failures actually cost you. For each critical asset, work out the cost of an unplanned failure - lost production per hour times typical downtime, plus emergency parts and labour, plus any secondary damage and any safety or quality fallout. Then estimate how many of those failures the system can realistically catch with enough lead time to act. That's your avoided-cost number. Against it, set the real cost of the program: instrumentation, integration, the platform, and the maintenance team's time. The honest version of this calculation usually shows that the value lives in a handful of high-consequence assets, which is exactly where you should focus.
Track a small set of operational metrics over time so you can prove the value as it lands. Unplanned downtime hours. Number of failures caught before they happened versus failures that slipped through. Mean time between failures on the assets you're watching. Emergency work orders as a share of total. Don't drown the report in model statistics that mean nothing to the people approving next year's budget.
- Quantify the cost of an unplanned failure per critical asset: lost output, emergency parts and labour, collateral damage.
- Estimate the catchable fraction - failures with a signal and enough lead time to act - not every failure.
- Net avoided cost against real program cost: sensors, integration, platform, and the team's time.
- Report operational metrics: unplanned downtime, catches versus misses, mean time between failures, emergency work orders.
- Expect most of the return to come from a few high-consequence assets, and prioritise instrumentation accordingly.
What does a crawl-walk-run path look like?
Don't try to instrument the whole plant and deploy remaining-useful-life models in year one. That's how budgets get spent and trust gets burned. Stage it so each phase pays for the next and proves the action path before you add complexity.
Crawl: pick a handful of your most critical, most failure-prone assets. Get clean, reliable sensor data flowing from them and stand up basic condition monitoring with thresholds and trends. Wire up the full alert-to-work-order workflow on just these assets and make it work end to end. The goal here isn't sophistication, it's a closed loop that the maintenance team trusts. Walk: layer anomaly detection over the monitoring so you catch the patterns fixed thresholds miss, expand to the next tier of assets, and start systematically recording every alert outcome to build your labelled history. Run: once you've got real failure data and a workflow people rely on, bring in predictive models for the assets where lead-time precision genuinely changes the economics.
The discipline that makes this work is honesty at each gate. Before you move from crawl to walk, can you point to alerts that led to acted-on repairs? Before walk to run, do you have enough labelled failures to train and validate a model? If the answer is no, you're not ready, and forcing it just rebuilds the failure pattern from earlier. Patience here is cheaper than a stalled six-figure project.
- Crawl: clean data and basic condition monitoring on a few critical assets, with the full workflow working end to end.
- Walk: add anomaly detection, expand asset coverage, and record every alert outcome to build failure history.
- Run: deploy predictive models only where lead-time precision changes the economics and where you have the data.
- Gate each phase on evidence - acted-on alerts before walk, labelled failures before run - not on a calendar date.
- Let each stage fund the next so the program proves value continuously instead of betting everything upfront.
Start here
If you take one thing from this, make it this: predictive maintenance is a data-and-workflow project that happens to involve some modelling, not a modelling project. Get honest about your data and your action path before you get excited about algorithms. The teams that win are the ones that started small, proved the loop, and earned the right to get sophisticated.
So start here. Rank your assets by what a failure actually costs you, and pick the two or three at the top. Check what sensor data you already have on them and whether it's trustworthy. Find out whether you've recorded past failures in any usable form. Then map the path an alert would take from signal to repair, and find the broken link - there's almost always one. That assessment is a few weeks of work and it tells you whether you're ready to monitor today or whether you've got data groundwork to lay first.
Either answer is useful. Knowing you need six months of clean data collection before a model makes sense is far cheaper to learn now than after you've bought a platform. Be honest about the prerequisites, fix the workflow before you fix the math, and the value follows.
- Rank assets by failure cost and pick the top two or three to start with.
- Audit the sensor data you already have on those assets and confirm it's trustworthy.
- Check whether past failures were recorded in any form a model could eventually use.
- Map the alert-to-repair workflow and find the broken link before spending on tooling.
- Decide honestly: monitor now, or lay data groundwork first - both are legitimate next steps.
Want this built for your business?
We map the highest-leverage place to start and ship a first live system within two weeks.
Book a strategy callCommon questions
Is predictive maintenance worth it for a small operation?
It can be, but the right starting point is condition monitoring on your few most critical assets, not a full predictive program. If a single failure on one line costs you a day of production and a chunk of collateral damage, even simple threshold monitoring on that line can pay for itself. Match the investment to the cost of the failures you're trying to avoid, and resist instrumenting everything at once.
How much historical failure data do I actually need?
For threshold-based condition monitoring and basic anomaly detection, you need almost none - just a baseline of what healthy looks like. For machine learning models that predict remaining useful life, you need multiple labelled examples of each failure mode you want to catch, tied to the sensor data from before each failure. That's why we recommend starting with monitoring: it generates the labelled history the advanced models need.
What's the difference between preventive and predictive maintenance?
Preventive, or scheduled, maintenance services assets on a fixed calendar or run-hours interval regardless of their actual condition, which is predictable but wastes remaining component life. Predictive maintenance watches the asset's real behaviour and intervenes only when the data shows degradation, so you service close to the true end of useful life on a planned shift. Predictive needs more data and a working action path to deliver.
Why do predictive maintenance projects fail so often?
Almost never because of the algorithm. The three consistent killers are no labelled failure data to learn from, dirty sensor data that poisons the model, and no path from alert to action so notifications get ignored. Two of those are data problems and one is organisational. Fix the data quality and the workflow first, and the modelling becomes the easy part.
Do I need machine learning to do predictive maintenance?
Not to get started, and often not at all for a meaningful share of the value. Condition monitoring with thresholds and trends catches many mechanical failures, and anomaly detection learns a normal envelope without needing failure history. Bring in machine learning only for assets where predicting remaining useful life precisely changes the economics, and only once you have the data and a workflow people trust.
It can be, but the right starting point is condition monitoring on your few most critical assets, not a full predictive program. If a single failure on one line costs you a day of production and a chunk of collateral damage, even simple threshold monitoring on that line can pay for itself. Match the investment to the cost of the failures you're trying to avoid, and resist instrumenting everything at once.
Ask AI about X18 Global
“What does X18 Global (x18global.com) do for enterprise AI and automation - and can you summarise their guide "Predictive Maintenance, Practically: What It Takes to Get Real Value"?”