Skip to content
ZERO-RISK100% replacement guarantee on every hire.See how we work
Back to blog
PREDICTIVE MAINTENANCE / INDUSTRIAL IOT6 MIN READ

Predictive maintenance ROI: what the math actually looks like

Maintenance managers often struggle to get budget for predictive systems. The idea is persuasive, but finance wants numbers. "Fewer breakdowns" is not a business case. The good news is that the maths is simple, and you probably hold most of the inputs already.

SHAREinX
Predictive maintenance ROI: what the math actually looks like illustration

Maintenance managers often struggle to get budget for predictive systems. The idea is persuasive, but finance wants numbers. "Fewer breakdowns" is not a business case. The good news is that the maths is simple, and you probably hold most of the inputs already.

This article shows how to build the ROI calculation, which inputs matter most and how to start with a case small enough to prove. The key advice: start with your five most costly machines, not the whole plant.

The formula

The core calculation is:

avoided downtime hours ร— cost per hour + saved repair cost โˆ’ system cost

Each term needs a clear meaning.

  • Avoided downtime hours: the hours of unplanned stoppage that a warning would have turned into planned downtime.
  • Cost per hour: what an hour of stoppage costs you.
  • Saved repair cost: the difference between an emergency repair and a planned one, including parts, overtime, expedited shipping and secondary damage.
  • System cost: sensors, installation, software, connectivity, support and the time of the people who use it. Include running costs, not only the purchase.

The result is a net benefit for a chosen period, usually a year.

The inputs that matter

Three inputs drive the answer.

Your cost of an hour of downtime. Include lost output, idle labour, missed deliveries, scrap from interrupted runs and restart losses. Many plants underestimate this by counting only lost output. Ask finance and production to agree one number.

Failures per year on critical assets. Use maintenance records, not memory. Count unplanned stops per machine and the hours each took to resolve. Be honest about records that are incomplete.

The share a warning could prevent. This is the hardest input. Not every failure gives a warning. Review your failure types with the maintenance team and estimate, conservatively, which ones develop slowly enough to detect. Use a range rather than a single figure.

A worked example, with placeholder numbers

Use your own figures. As a pattern, imagine a machine that fails unplanned a few times a year. Each failure stops the line for a number of hours. Multiply the hourly cost by those hours. Then take the share of failures a warning could have turned into planned work. That gives avoided downtime cost. Add the difference between an emergency and a planned repair. Subtract the yearly cost of sensors, connectivity and support for that machine.

Run the sum three ways: a cautious case, an expected case and an optimistic case. If the cautious case is still positive, the case is strong. If only the optimistic case works, scale back or look for better targets.

Why starting with five machines works

Whole-plant projects are slow, costly and hard to judge. Five machines with the highest cost of failure give you three benefits:

  • A high return per sensor, because the machines matter.
  • A short project that finishes before attention fades.
  • Real results you can show when you argue for more.

Rank machines by the cost of downtime multiplied by failure frequency. The top of that list is your pilot.

Sanity-checking the inputs

Before you trust the result, test each input.

  • Downtime cost: does the number match what finance says an hour of stoppage costs? If production and finance disagree, resolve it first.
  • Failure counts: do the maintenance logs match what operators remember? Missing records mean you are probably undercounting.
  • Preventable share: has the maintenance team looked at the actual failure causes? A failure with no early signal should not be counted.
  • Warning lead time: is the warning early enough to order a part and plan a stop? A warning one hour ahead prevents little.
  • Response: will someone act on the warning? Include that effort.

What a warning must achieve

ROI comes from converting an unplanned stop into a planned one. That depends on lead time. A few days is often enough if parts are on the shelf and a maintenance window is near. If parts take weeks to arrive, you need a longer warning or a spare. Look at your critical machines and note how long it takes to prepare a repair. Compare that with how early the likely signals appear. This tells you which machines are good candidates and which are not.

Measuring after the pilot

Decide how you will judge success before you start. Record the baseline: unplanned stops, hours lost and repair cost for the last year. After the pilot, compare the same figures for the same machines over a similar period. Note any change in production volume or mix that could distort the comparison. Count also the warnings that led to action, and the false alarms. A system that produced useful warnings but was not acted on shows a process problem, not a technology problem.

Report results in plain terms to the people who approved the budget. A short, honest summary, including what did not work, builds trust for the next phase.

Costs people forget

  • Maintenance staff time to review and act on alerts.
  • Training.
  • Sensor replacement and calibration.
  • Connectivity and cloud costs.
  • Integration with the maintenance system.
  • The cost of false alarms.

Leaving these out makes the case look better than it is, and the audit later will find them.

Benefits people forget

  • Longer part life because you stop replacing on a calendar.
  • Safer working conditions, with fewer emergency repairs.
  • Better spare-parts planning and lower stock.
  • Fewer quality defects from degrading machines.
  • Data to support warranty and supplier conversations.

Count these only if you can support them. Keep the main case on downtime and repair cost.

Reading the result honestly

If the net benefit is small or negative for a machine, that is useful. It tells you where not to spend. Some machines are cheap to stop, easy to repair or fail without any warning. Time-based maintenance may be enough for them.

If the result is strongly positive, ask what could make it wrong. Is the downtime cost overstated? Is the system cost missing a recurring item? Could the preventable share be half what you assumed? Test the case with those changes. A case that survives pressure is one you can defend to a sceptical finance team.

Common mistakes

  • Using a single, optimistic number. Show a range.
  • Counting every failure as preventable. Many are not.
  • Ignoring the cost of acting on alerts. A warning without a response saves nothing.
  • Forgetting to measure afterwards. Track the baseline so you can prove the result.
  • Starting too wide. Pilot first.

Presenting the case

Keep the proposal to one page. State the machines, the failure history, the three scenarios, the system cost and the payback period in plain words. Add the main risks and how you will measure success. Offer a pilot with a clear review date, so approval is a small step and not a plant-wide commitment. Finance teams respond well to a modest first request with a way to check the result.

What to do next

Gather twelve months of maintenance records for your top machines. Agree an hourly downtime cost with finance. Estimate the preventable share with your maintenance team. Run the three cases. If the cautious case holds, start a pilot with a clear measure of success.

Brandsmashers can help with the calculation and with the pilot that tests it, using your records and your own numbers. If you would like a second view on your case, we are happy to go through it with you.

SHARE THIS ARTICLEinX

NEXT STEP

Need help with this?

KEEP READING

More insights.

ALL ARTICLES