Antenor Blog 5 min read
The ROI Math of Predictive Maintenance with Machine Learning
A cost model for predictive maintenance: the four value drivers, the full cost side including false alarms, and a break-even test to run before building anything.
Predictive maintenance pays when the cost of unplanned failure is high, failures are frequent enough to learn from, and lead time before failure is long enough to act on. The value comes from four drivers: avoided downtime, cheaper planned interventions, longer component life, and reduced safety exposure. Against that stand sensor and data infrastructure costs, modeling effort, and the operational cost of false alarms, which is the item most business cases forget. Run the break-even arithmetic on one asset class before building anything.
“Predictive maintenance” is one of the most cited machine learning use cases in industry, and one of the most casually justified. The pitch usually stops at “downtime is expensive, therefore prediction is valuable.” That skips the arithmetic that determines whether a specific program on specific assets will ever pay for itself. Here is the model we walk through with clients before any data is collected.
The maintenance spectrum, priced
Every asset already has a maintenance strategy, even if it is implicit:
- Run to failure. Zero prevention cost, maximum failure cost. Rational for cheap, redundant, non-critical assets.
- Preventive (calendar or usage based). Intervene on a schedule. Pays a known cost to avoid an uncertain one, and wastes component life by replacing parts that were still healthy.
- Condition based. Intervene when a measured signal crosses a threshold. Requires instrumentation, catches degradation but with short warning.
- Predictive. Model remaining useful life or failure probability from sensor history, and intervene inside the window where action is cheap.
Predictive is not automatically the top of this ladder. It is the right rung only when the numbers below work.
The four value drivers
1. Avoided unplanned downtime. The core term: (downtime hours avoided) times (cost per hour). Cost per hour must include lost production, contractual penalties, and expediting, not just the maintenance crew. This number varies by orders of magnitude between a bottleneck machine and a peripheral one, which is why asset selection dominates program ROI.
2. Planned versus emergency intervention cost. The same repair is cheaper when scheduled: normal-hours labor instead of call-outs, parts shipped standard instead of overnight, production rescheduled instead of interrupted.
3. Extended component life. Against a preventive baseline, prediction lets you consume more of each component’s real life instead of replacing on a conservative calendar. This driver only exists if your current baseline is preventive; against run-to-failure it is zero.
4. Reduced secondary and safety damage. A bearing caught early is a bearing. A bearing caught late can be a shaft, a gearbox, and an incident report. Where failure modes have safety consequences, this driver can outweigh the other three, and it is also the hardest to quantify honestly.
The cost side, including the item everyone forgets
| Cost item | Nature | Notes |
|---|---|---|
| Sensors and connectivity | Capital, per asset | Often already present in modern equipment; retrofit costs dominate on legacy fleets |
| Data infrastructure | Capital plus running | Historian or pipeline, storage, monitoring |
| Modeling and validation | One-time plus refresh | Includes the failure-labeling effort, which is usually the true bottleneck |
| Integration with maintenance workflow | One-time | Predictions must create work orders, not dashboards |
| False alarms | Recurring, per alert | Each false positive costs an inspection and burns trust |
| Missed detections | Recurring, per event | Each false negative is a full unplanned failure, plus credibility damage |
False alarms deserve their own paragraph. A model that flags ten times for every real failure does not save maintenance effort, it multiplies it, and after a few wasted inspections technicians stop responding to alerts entirely. At that point the system’s value is zero regardless of its offline accuracy. The precision-recall operating point is a business decision, priced in inspection cost versus failure cost, and it should be set explicitly with the maintenance manager, not defaulted by the data scientist.
The break-even test
Before building, estimate for one candidate asset class:
- F: unplanned failures per year across the fleet.
- C_fail: average full cost of one unplanned failure (downtime, emergency premium, secondary damage).
- C_plan: average cost of the same intervention done planned.
- d: fraction of failures the system can realistically catch in time to act. Be pessimistic; this depends on whether the failure mode has a detectable precursor and enough lead time.
- A: expected false alarms per year times cost per inspection.
Annual value is approximately F times d times (C_fail minus C_plan), minus A. Compare that against the annualized cost of sensors, infrastructure, and modeling for that asset class. If the inequality is not comfortably positive under pessimistic assumptions, stop, or pick a different asset class. The best programs we have seen started on the one or two asset classes where the math was overwhelming, proved the loop from prediction to completed work order, and expanded from there.
Data reality check
Two conditions gate everything above. First, failures must exist in the historical record: a fleet with three failures in five years cannot train a supervised model, though anomaly detection against normal behavior may still add value. Second, failure events must be labeled or reconstructable from work orders, which usually means weeks of joining maintenance logs to sensor history. If your CMMS records “fixed” as the failure description, budget for that cleanup first. This is unglamorous work and it is where most predictive maintenance projects actually live or die.
Predictive maintenance modeling is part of our predictive models practice.
Frequently asked questions
How much history do we need to start?
Enough to cover multiple examples of the failure modes you care about, across seasons and operating regimes. For frequent failure modes that can be one or two years; for rare ones, supervised prediction may not be viable at all and the honest recommendation is condition monitoring with anomaly detection instead.
Do we need new sensors?
Often not for rotating equipment, where vibration, temperature, and current signatures already exist in modern drives and PLCs. The cheaper first question is whether the data your equipment already emits is being stored anywhere. Retrofitting sensors changes the cost model materially and should be justified by the break-even test above, per asset class.
What accuracy should we expect from the model?
The useful question is not accuracy but the operating point: how many of the real failures does it catch, at how many false alarms per month, with how much lead time. Those three numbers, priced with your intervention costs, determine ROI. A model with modest recall and very few false alarms frequently beats an impressive-sounding one that floods technicians with alerts.