Get reliability work funded, in the language finance uses

Reliability work is often denied because it is presented as a method, a culture change, or a headcount request. Finance is asked to approve a program. What they can actually approve is a reduction in expected loss, compared with a stated cost, under assumptions they can see. That is the whole idea on this page: get reliability work funded in the language finance already uses.

The approach is borrowed from how insurers and risk engineers think about loss — frequency times severity, then a comparison with the cost of control. It is not an insurance product, and no insurer endorses it. It is a transparent way to put a number, a range, and a set of assumptions on the conversation you are already having.

Why budgets get denied

A maintenance budget request often arrives as a list of tasks, a training class, or a software subscription, backed by anecdotes about a bad breakdown last year. The people asking are usually right that the plant is taking too much risk. The file still gets rejected, or deferred, because it does not answer the questions a controller is paid to ask: what does the current risk cost in a typical year, what changes if we spend this money, how sensitive is that answer, and when does the spend pay back?

Those questions are fair. They are also answerable. You do not need a reliability department to start. You need a clean failure history, a defensible downtime cost, and the discipline to separate data from assumptions.

The insurer’s view: expected loss is frequency times severity

For a single failure mode, the expected loss in a year is the rate at which the event occurs, multiplied by what it costs when it does. If a pump has failed four times in two years, a simple estimate of the rate is two events per year. If each event costs $12,000, the expected annual loss is $24,000. Reduce the rate, or the cost of an event, and the expected loss falls. The difference is the benefit you are asking finance to buy.

Expected annual loss (ALE) = λ × E[S], where λ is the annual rate of occurrence and E[S] is the expected cost of one occurrence.

That is the same structure as annualized loss expectancy in information-risk work, and the same frequency–severity idea used in casualty risk engineering. The formulas, including a confidence interval on the rate and a way to apply reduction factors, are written out on the risk-quantification method page. You can run them, on your own numbers, in the RCM ROI and risk calculator.

Building the baseline from the CMMS

The honest baseline is usually in the computerized maintenance management system, the downtime log, or the operator notes — not in a vendor brochure. Count the events, write down the observation period, and be explicit about what was and was not recorded. ISO 14224 is a useful reference for how reliability and maintenance data can be classified; it is a taxonomy and a data-collection standard, not a claim that your CMMS is “ISO 14224 compliant.”

Severity should be built from the plant’s economics, not from a generic “cost of downtime” headline. Count contribution margin on output you cannot recover, idle and overtime labor, scrap, and the fixed costs of an event. The steps are in how to calculate downtime cost per hour.

Avoided loss versus program cost

Once you have a baseline ALE, you still need a view of residual risk after the program. That residual is not a promise. It is an assumption: a reduction in frequency, a reduction in severity, or both, stated as a low, base, and high case. Avoided loss is baseline minus residual. Subtract the ongoing cost of the program, divide the one-time cost by the steady-state net benefit to get a payback, and discount the cash flows if your finance team uses NPV. The method page shows a 25 / 75 / 100 percent ramp in the first three years, which you can change if your plant ramps differently.

If the CMMS cannot support a clean count, say what you used instead: a downtime log, operator notebooks, or a bounded sample of work orders. It is better to document a narrower, cleaner set than to force a plant-wide total from incomplete codes. ISO 14224’s taxonomy can help you decide what an “event” is so two people would count the same history the same way. You still have to do the counting; the standard will not do it for you.

Presenting to finance

A memo that holds up in a budget meeting is usually short. It states the scope, the baseline, the assumptions, the range, the payback and NPV, and the limitations. It does not claim that a method is guaranteed, or that “plants typically save” some percentage. If you want a blank memo, use the business-case template. If you want the memo built with you, that is the reliability business case engagement.

Objections you should expect

• The history is messy. Say so. Use a confidence interval on the rate, and say which events you included or excluded.
• The reduction is made up. Treat it as an assumption, show a range, and offer a tornado or a low case. Do not hide a single optimistic percentage in the executive summary.
• This is not how we do ROI. Ask for the plant’s hurdle rate and capital template, and put the same cash flows into their form.
• What if the program does not work? A success probability, or the low scenario, is a straightforward way to risk-adjust the NPV without inventing a new methodology.

ISO 31000 describes a general risk-management process, and ISO 55000 describes asset management. SAE JA1011 asks you to evaluate consequences before you select a task. None of those standards is a promise that a budget will be approved. They are the context in which this kind of case should be written.