Article: Business intelligence for maintenance: how to see what failure actually costs

Blog

Business intelligence for maintenance: how to see what failure actually costs

Most maintenance reporting measures activity, not consequence. Four questions that show whether you have a data problem or a decision problem.

Business intelligence for maintenance means connecting what fails, what it costs and what the business lost, so that maintenance performance can be discussed as a business outcome rather than as a compliance percentage. Most sites already hold the data required. What is usually missing is the connection between systems, an owner for the numbers, and a decision that changes as a result.

That is the short answer. The rest of this article is about how to tell which part you are missing.

The reporting is accurate, and it is answering the wrong question

Walk into most maintenance meetings and the reporting is good. Work orders raised and closed. Schedule compliance. PM completion. Backlog by trade and by age. It is accurate, it is produced on time, and the team put real effort into it.

Every one of those measures describes activity.

The trouble starts when someone outside maintenance asks a question. The general manager wants to know why the budget is up. The owner wants to know whether last year's spend worked. Finance wants the shutdown reconciled against what was approved.

Those are questions about consequence, and a compliance percentage cannot answer them. So the maintenance manager either spends a week assembling the answer by hand, or answers with the numbers they have, and the conversation drifts into budget rather than value.

What has gone wrong is not the reporting. It is that two different jobs are being asked of one set of measures.

The four questions

Before buying anything, work through these in order. Where you stop tells you what the problem actually is.

1. Do we know what is failing?

Not how many work orders were raised. Which assets fail, how often, for how long, and in what way.

This depends almost entirely on whether failures are coded or described. A free-text note saying "pump tripped again, reset and monitored" is useful to the next person on shift and useless to analysis. It cannot be counted this month and it cannot be compared next year.

If you stop here, you have a data capture problem. The fix is a small, enforced set of failure codes that the people doing the work will actually use — which usually means fewer codes than the system offers, not more.

2. Do we know what the failures cost?

This is the question most sites cannot answer.

The labour sits in the CMMS or the timesheet system. Parts sit in inventory. Contractors sit in accounts payable. Expedited freight sits with procurement. Lost production sits in the production system, if it is captured at all.

Each system is correct. None of them can answer the question on their own, and the join between them is usually a person with a spreadsheet and a spare week.

It is the most common reason a business cannot state what an asset cost it last month.

3. Does anyone own the number?

Every measure drifts unless someone is accountable for how it is produced.

The reactive work ratio is the clearest example. If nobody owns how work type is coded, coding will follow pressure. When compliance is under scrutiny, breakdowns quietly get raised against planned work orders. The ratio improves. Nothing on site has changed.

Ownership here does not mean owning the result. It means owning the definition: what counts, what does not, who codes it and when.

If you stop here, you have an ownership problem. No system solves it, because the system will faithfully report whatever it is given.

4. Does the number change a decision?

The last question is the hardest.

Take one report that goes out every month. Ask what decision was made differently because of it. If the honest answer is that it was produced, circulated and filed, then it is a record.

Records have their place. Some exist for compliance and should. But a record should not be funded, resourced and defended as though it were a control.

If you stop here, you have a decision problem, and this is the one where new software does the most damage. A better dashboard showing a number nobody acts on is a faster way to not act.

What good looks like

A business with working maintenance intelligence can do three things without a week of preparation.

Name its worst assets by cost, not by work order count. Repeat offenders surface automatically rather than being remembered by whoever has been there longest.

State what a failure cost, end to end. Labour, parts, contractors, freight and lost production against one asset, in one view.

Show what changed after a decision. When a maintenance strategy is altered, the same measure is checked afterwards, so the business can see whether it improved anything or simply reorganised it.

None of this requires a new CMMS. It requires the data already being captured to be coded consistently, joined across systems, owned by someone, and pointed at a decision. This is the core of our business intelligence and reporting work.

Where to start if you have no time

Start with one asset, and make it your worst one.

Pull twelve months of work orders for it. Group the repairs by what actually failed rather than by work order type. Add the labour hours, the parts, the contractor invoices and the freight. Then ask production what the downtime cost.

The number will take a day to assemble and it will be uncomfortable.

It does two things. It shows the business what one asset is costing, which usually ends the debate about whether maintenance visibility is worth investing in. And it shows you which of the four questions your operation fails on, because you will have discovered the answer the hard way while assembling it.

If you would rather not build the spreadsheet, the free Cost of Failure Calculator from our sister site, Maintenance Untangled does the arithmetic for up to five assets and separates what the maintenance budget shows from what the failures actually cost.

A practical next step

Run the four questions against your own maintenance reporting this week, before anyone books a system demo. Write down where you stop.

If you stop at question one or two, the work is technical and it is solvable. If you stop at three or four, the work is about ownership and decision rhythm, and buying software first will make it worse. Our continuous improvement work is where that decision rhythm gets rebuilt.

We work on exactly this problem at Johnstone BI — connecting people, process, systems and data so that operational performance can be seen clearly enough to act on. If it would help to talk it through, get in touch.