You cannot automate a step that is done five different ways

The proposal is to automate the coding of supplier invoices. Ninety five thousand to build, a step that takes nine minutes, eleven hundred invoices a month. Somebody has done the arithmetic, the payback is inside sixteen months, and it looks like a straightforward yes.

There is one question worth asking before it is signed, and it is not about the technology. Where did the nine minutes come from.

Five people, one step

Somebody stood behind five people doing the same step and timed it.

The nine minutes in the business case is the average of those five. It is arithmetically correct and it describes nobody. Nobody in that team takes nine minutes, and the range from best to worst is more than a factor of two on a step everyone has been trained to do the same way.

So the next hour is spent finding out what E does that A does not.

---

	The step as A does it	6.5 min
	Looking the cost center up in a second system	3.0 min
	Checking a second approval list	2.0 min
	Re-keying the supplier name, which does not carry across	1.5 min
	Waiting for a shared workbook to open	1.0 min
	The step as E does it	14.0 min

Illustrative figures. The itemisation is the point rather than the total: every line in the middle is a thing E does and A does not, and none of them is E working slowly.

Not one of those seven and a half minutes is effort. E is not slower than A. E is doing four things A is not doing, and E believes every one of them is part of the job, because at some point somebody told E it was and nobody has been back since.

That is the ordinary condition of a step nobody has standardized. There is no single method. There are five methods, wearing one name, and the difference between them is invisible in any report because the report carries the average.

What one page buys

Standard work here is not a program. It is a decision about which of the five methods is the method, written down, and half a day spent making sure everyone has what they need to follow it.

A’s method wins on inspection: the cost center list kept locally rather than looked up, the supplier reference carried across rather than typed twice, the second approval list confirmed as no longer required by anyone. Written on one page.

---

	Average before, across five people	9.0 min
	Average after, the same five people	7.0 min
	Saved per invoice	2.0 min
	Invoices a month	1,100
	Hours a month recovered, for one page and half a day	36.7 h

The spread also narrows, from 6.5 to 14.0 minutes down to 6.5 to 8.0. The narrowing is worth more than the two minutes, for reasons that have nothing to do with cost.

Thirty six and a half hours a month, for the price of a printed page and an afternoon. No system, no capital, no project board.

What that does to the business case

Here is the part that decides whether the automation is a good investment, and it is a question about the baseline rather than about the automation.

A business case is written against what happens if you do nothing. But doing nothing is not the alternative on the table. The alternative is doing the free thing, and the free thing is worth two minutes an invoice.

---

	Claimed saving, 9.0 min against 1,100 invoices at $38 an hour	$6,270
	Real saving, 7.0 min on the same basis	$4,877
	The difference, available without spending anything	$1,393
	Cost to build	$95,000
	Months to pay back, was 16	20

The two minutes are not the automation's to claim, because they can be had for a printed page. A case that claims them is comparing the project against a version of today that nobody has to accept.

Sixteen months becomes twenty. That may still be a yes, and on these figures it probably is. What matters is that it is now the right yes, made against a real alternative, and it will not be followed a year later by a review that finds the delivered saving twenty two percent short of the case with nobody able to explain where it went.

That review is the common ending. The project delivers exactly what it promised, the department’s hours come down by less than the case said, and the automation gets the blame for a shortfall that was written into the business case before a line of it was built.

The worse failure, which costs more than money

Now the second question, and it is the one that outlives the payback calculation. When the automation is specified, whose method does it implement.

If the person interviewed was E, because E is the senior one and the process owner, then the specification carries the second system lookup, the second approval list and the re-keyed supplier name. All three become code. All three are now permanent, they are in a document somebody signed, and removing one is a change request rather than a conversation.

A workaround performed by a person is visible and cheap to remove. The same workaround performed by a system is invisible and expensive to remove, and in five years nobody will remember it was a workaround at all. That is the real cost of automating before standardizing, and it does not appear in any business case because it is not a cost, it is a foreclosed option.

The order matters for a third reason too. After the method is standard, the times run from 6.5 to 8.0 minutes rather than 6.5 to 14.0. Whatever variation is left is the invoices, not the people, and that residual is the honest thing to size an automation against. It also tells you something the average never could: how often a case does not fit the standard method, which is the exception rate, and the exception rate is what decides whether an automation covers ninety percent of the volume or sixty.

When to skip the standardizing

This is not an argument that standard work always comes first, and treating it as one wastes time on steps that do not need it.

The test is in the timings. If five people doing the same step take materially different times, there is no single method and there is nothing to automate yet. If they all take roughly the same time, the method is already standard, whether or not anyone wrote it down, and the automation can be specified straight from what they do.

The same applies to a step that is genuinely mechanical: copying a field from one system into another, in the same way, every time, with no judgment in it. There is nothing to standardize, the variation is zero already, and asking for a standard work exercise first is bureaucracy rather than method.

The distinction is worth being blunt about, because both mistakes are expensive. Automating an unstandardised step buys the wrong nine minutes and casts a workaround in concrete. Standardizing a step that is already identical everywhere spends a fortnight producing a document describing what people were doing anyway.

Half a day with a stopwatch tells you which of the two you are looking at, and it is the cheapest half day in the whole project.

There is one more thing worth checking before the case is signed, and it is whether the step is anywhere near the constraint. Nine minutes an invoice sounds like a lot, and if invoices are not what the department is short of, the entire saving is capacity nobody needed. What an hour is worth depends entirely on where it was taken from, and that is a calculation of its own.