Building the business case for production monitoring.

Most business cases for production monitoring fail for the same reason: they are built on somebody else’s improvement percentage. A vendor says 20% more capacity, the case is written backwards from it, and the first question in the room is where the 20% came from. Nobody can answer, and the case never recovers — not because the project was wrong, but because the evidence was borrowed.

The alternative is slower and much harder to argue with. Build the case from arithmetic your reader already accepts, keep every assumption visible and yours, and design a pilot whose job is to replace the assumptions with measurements.

Start with value drivers, not benefits

A benefit is “better visibility”. A value driver is a line somebody already has a number for, which you can move. Only the second kind survives a finance review. In most SME manufacturing businesses the list is short:

• Unplanned downtime. Hours you paid for that produced nothing, valued at whatever an hour of that machine is worth to you. This is usually the biggest line and the easiest to evidence, because a stop has a start time and an end time. The starting figure is usually already in a maintenance or downtime log and in the shift reports.
• The cost of quality. Scrap is the visible part. Rework, sorting, concessions, the expedited replacement and the customer audit that follows are the rest, and they are usually larger than the scrap figure people quote. Scrap notes, concession records and credit notes give you the starting figure.
• Energy consumed making nothing. The least arguable line on any of these cases, because a machine drawing power at the weekend is not a matter of opinion. Your electricity bills, or the half-hourly data your supplier holds, are where it starts.
• The hours spent collecting numbers. Someone walks the floor with a clipboard, someone types it up, someone reconciles the two before Monday’s meeting. Count the hours and value them at loaded cost: ask whoever produces the weekly report how long it takes. If the floor still runs on paper, count the re-keying too: travellers, job cards, inspection sheets and logbooks typed up after the shift, and the time spent chasing the ones that went missing. Going paperless removes that typing, but be honest about what it asks in return. Tablets on the floor need a network that reaches them, operators need a way to identify themselves, and a paper process nobody trusted does not become trustworthy just because it is on a screen.
• Quoting accuracy. Harder to quantify, worth naming anyway. If your standard costs were set years ago and adjusted by feel, some of your parts are being sold at a loss and nobody can currently say which. Standard costs set against actuals on a handful of recent jobs will show you whether it belongs in the case.
• Expediting and overtime. The cost of finding out late. Ask whoever authorises the overtime how much of it is caused by surprise rather than volume; the overtime authorisations are the record.

Pick two or three. A case built on two lines that everyone accepts is stronger than one built on six that invite argument, and the ones you leave out become your margin of safety when somebody challenges the total.

Put your own numbers through the arithmetic

The ROI calculator exists to do exactly this: you give it machine count, scheduled hours, the value of a machine hour, your downtime and scrap rates, and it tells you what those two lines cost you a year and what a single percentage point of improvement is worth. It deliberately does not tell you how many points you will get, because we do not know.

Choosing the improvement figure yourself is not a weakness in the case — it is the strongest thing in it. When the finance director asks where 3% came from, “I chose it, here is why, and here is what it looks like at 1%” is an answer. “The vendor’s website” is not. Show the case at a level you would be embarrassed not to achieve, and let the upside be upside.

Design a pilot that can fail

A pilot that cannot produce a negative result is a demonstration with a longer run time. Four things make the difference, and three of them happen before anything is installed.

1. Define the measures first

Write down, before you start, exactly which numbers will decide this: unplanned downtime hours per week on the pilot cell, scrap rate on a named part, hours spent producing the Monday report. Two or three, no more. Also write the decision rule — what result means roll out, what result means stop. Agreeing that in advance is what stops the pilot ending in an argument about interpretation. Written as a template, it can be as plain as this: “Roll out to the next cell if unplanned downtime on the pilot cell is at least [your figure] hours a week below the baseline by [date]. Stop if it is not.”

2. Measure a baseline before the system arrives

Spend a week measuring those same numbers the way you measure them today, with the clipboard and the spreadsheet. This is the step everybody skips and the one that decides whether the pilot proves anything. Without it you have an after with no before, and the first thing a monitoring system does is reveal downtime that was always happening and never recorded — which, with no baseline, looks exactly like the system making things worse.

Keep the baseline honest even when it flatters the old way. If your clipboard says 4% downtime and the system later says 11% (illustrative figures), the difference is not a failure of the pilot. It is the finding.

3. Let the system measure the after

Once it is in, stop hand-collecting. The whole point is that capture comes off the machine, and running both in parallel for months turns a pilot into a data-entry job that people quietly abandon. Where the two disagree, go and look at the machine — the disagreements are the most useful output of the whole exercise.

4. Keep it small and give it an end date

A cell, or a handful of the machines you argue about most, for a fixed period with a date in the diary for the decision. And give it an owner: a pilot that is nobody’s actual job produces a report nobody reads. If no one on the floor has time to own it, that is worth knowing in month one rather than month six.

“We tried a system like this before”

You will hear this, often from someone whose scepticism is entirely earned. Do not argue with it. Ask what happened, because the answer is almost always one of four things, and each has a specific counter.

• “The operators stopped entering data.” They always do, and they are right to. If uptime depends on someone typing, it will decay within a quarter. Ask what the new system captures without a human — states, cycles, energy — and treat anything that needs typing as a thing that must be worth the ten seconds it costs the person doing it.
• “Nobody believed the numbers.” Usually because the system filled gaps quietly: a zero where a sensor dropped out, an interpolated figure nobody was told about, an empty window reported as 0% OEE. Ask what the new system does when it does not know. If the answer is that it says so, on the tile, next to the number, that is the difference. If it cannot answer, you are buying the same problem. Quiet errors are easy to build: we nearly shipped a standard way of storing older machine data that would have overstated energy by about 2.8 times, and caught it at design review. The field note The sample rate that was lying to us has the working.
• “It became a reporting exercise.” Data was collected, a report was produced, nothing changed. That is a management-routine problem rather than a software problem, and no product fixes it. Decide now which meeting the numbers land in and who is expected to act on them.
• “It was a big project and it stalled.” Usually true, and usually because it was scoped as a factory-wide implementation with a go-live date. Scope this one cell by cell: a cell, then another, with a decision after each. Nothing forces a big-bang go-live, so nothing has to be finished before anything is useful.

What the case should end with

One page: the two or three value drivers with your own arithmetic behind them, the cost at full price, the pilot with its measures and decision rule, and the risks stated plainly rather than left for the room to find. State the supplier’s cost the way it is actually charged, and say whether you are asking for capital or for a run rate, because finance directors treat the two differently. In order, the page needs:

1. The problem, in pounds.
2. The two or three value drivers, with the arithmetic behind each.
3. The cost as it is charged, and whether it is capital or a run rate.
4. The pilot: scope, measures, baseline, decision rule, end date and owner.
5. The risks.
6. The decision you are asking for.

If match funding is available to you, put it in as acceleration rather than as the reason the case works; our guide to Made Smarter funding explains why that distinction matters. And if you want the underlying measure to be something everyone in the room defines the same way, start with OEE in plain English — a case built on a metric half the room defines differently will come apart at the first question.