Predictive maintenance pays for itself through downtime it prevents, not through maintenance labour it eliminates. This is the single most common modelling error in industrial AI business cases, and it is the reason so many of them are rejected by a finance team that is, on the numbers presented, entirely right to reject them.
The mistake in most business cases
A typical proposal reads: we currently run time-based preventive maintenance on 40 assets, at 6 interventions per asset per year, at ₹X per intervention. Predictive maintenance will cut interventions by 40%. Therefore we save 0.4 × 40 × 6 × ₹X.
Every number in that sentence can be true and the business case can still be worthless.
Maintenance labour is largely fixed. Your technicians do not go home when an intervention is cancelled; they are reassigned. Unless the deployment lets you genuinely reduce headcount, defer a hire, or release contractor spend, the "saving" is a reallocation, not a cash return. Finance knows this, which is why the proposal dies.
Where the money actually is
The return sits almost entirely in avoided unplanned downtime, and the reason is a ratio that is stable across most discrete manufacturing:
An unplanned failure costs somewhere between 8× and 20× the direct cost of the same repair performed on a planned basis.
That multiple comes from things that never appear on the maintenance work order:
- Lost production during the stoppage, priced at contribution margin, not revenue
- Scrap and rework generated in the minutes before the line was stopped
- Expedited freight for the replacement part, and premium labour to fit it
- Downstream starvation of processes that depended on the failed asset
- Overtime to recover the schedule, sometimes across several shifts
- In regulated environments, an investigation and a deviation report
A ₹80,000 bearing replacement, performed unplanned on a bottleneck asset, routinely lands between ₹6 lakh and ₹16 lakh once those are included. That gap is the product.
The arithmetic
The honest form of the calculation is:
Annual return = (failures prevented per year) × (average cost of one unplanned failure) − (annual cost of the system)
Which means you only need three inputs, and only one of them is difficult:
-
Average cost of one unplanned failure on the target asset. Get this from finance, not from maintenance. It must be priced at contribution margin during the stoppage. Most plants have never calculated it and are startled by the answer.
-
Annual cost of the system. Sensors, edge compute, integration, licence, and the engineering time to keep the model honest. This is knowable up front.
-
Failures prevented per year. This is the hard one, and it is where credibility is won or lost.
Why "failures prevented" is the hard number
You cannot measure a failure that did not happen. What you can do is bound it.
Start from the asset's actual failure history. If a critical pump failed unplanned four times in the last 24 months, the base rate is two per year. A model with a 95% detection rate and sufficient lead time to act converts most of those into planned interventions. Not all: some failures are genuinely sudden, with no degradation signature to detect. Electrical faults and foreign-object damage are the usual examples.
A defensible claim is therefore closer to "we expect to convert 60–80% of the historical unplanned failure rate into planned work" than to "we will eliminate unplanned downtime." The second claim is what gets a pilot approved and a rollout cancelled.
For most discrete manufacturing lines, break-even lands between two and five prevented failures. If the target asset does not fail at least twice a year, or its failures are cheap, it is the wrong asset. Choose a different one. This is a better outcome than discovering it eighteen months in.
The data prerequisite nobody mentions
A predictive model learns the difference between healthy and degrading. To do that, it must have seen degradation.
This means you need either:
- At least 12 months of historical sensor data spanning several real failures, with maintenance records accurate enough to timestamp when each failure began rather than when someone noticed it, or
- A seeded failure campaign, where known faults are deliberately introduced on a test rig or a redundant asset and the signatures recorded.
Plants that have neither can still deploy anomaly detection, which flags "this does not look like it usually does." That is genuinely useful and it is not the same thing. Anomaly detection tells you something changed. Predictive maintenance tells you what is going to break, and roughly when. Only the second one lets you order the part.
Be precise about which one you are buying. The lead time you can act on is what determines whether an alert becomes a planned intervention or simply an earlier warning of the same unplanned stop.
What we do about it
At Gothi Tech, a predictive maintenance engagement begins with a paid pilot on a single line, and the first deliverable is not a model. It is the failure-cost baseline, built with your finance team, for the specific assets in scope. If that number does not support the arithmetic above, we say so before anyone instruments anything.
The models come second, they run at the edge beside the PLC, and they write into the CMMS you already use — because an alert that does not become a work order belongs to nobody.
If you want to run this arithmetic against your own assets, talk to us — the failure-cost baseline is the first thing we build, and we will tell you if the numbers do not work.