The hour you lost at the bottleneck did not cost forty five dollars

Everybody on the floor knows which station is the problem. The business case to fix it is what does not get written, and when it does get written it is usually refused, because the person writing it costed an hour of the constraint at what the constraint costs to run.

That is the wrong number by roughly two orders of magnitude, and the right one is not difficult. It just requires accepting something that sounds like an exaggeration until the arithmetic is on the page: an hour lost at the constraint is an hour lost by the whole business, and it should be valued at what the whole business would have earned in it.

Two ways to value the same hour

A line makes one product. Test is the slowest station and everything else has spare capacity, so the line produces what test produces.

The finance system knows what test costs to operate: an operator, a share of the machine’s depreciation, power and consumables. That comes to forty five dollars an hour, and it is a real figure, correctly derived, and completely irrelevant to the question being asked.

The question being asked is what the business loses when test stops. So value the hour by what the business gets out of it.

---

	Selling price, one unit	$180
	Truly variable cost, one unit	$103
	Contribution, one unit	$77
	Units the constraint produces in an hour	38
	Contribution the business earns per constraint hour	$2,926

Illustrative figures. Truly variable cost means the cost that changes when one more unit is made: materials, bought in parts, anything consumed per unit. It is not a share of the rent, the supervisor or the depreciation, because none of those changes when the line makes one more.

Two thousand nine hundred and twenty six dollars, against forty five. The same hour, valued two ways, sixty five times apart.

Drawn honestly, on one scale, with no broken axis. The operating cost is the sliver. That is what sixty five times apart looks like, and it is why a business case built on the lower figure gets refused.

The reason the second figure is the right one is that the constraint sets the output of the line. Every other station has spare capacity, so an hour lost anywhere else is recovered later in the day and costs nothing. An hour lost at test is not recovered anywhere, because there is nowhere with the capacity to recover it. The units that hour would have produced are simply not produced, and the contribution they would have carried is simply not earned.

The same project, twice

Now put a real proposal through both. A fixture that halves the changeover at test, recovering forty minutes of run time a shift. It costs eighteen thousand dollars to make and three days of engineering time at six hundred a day.

---

	Time recovered at the constraint, a shift	40 min
	Value of a constraint hour	$2,926
	Value recovered, a shift	$1,951
	Fixture, plus three days of engineering	$19,800
	Shifts to pay for itself	11

Eleven shifts is a little over two working weeks. Across 230 shifts a year the same forty minutes is worth about 449,000 dollars, which is a figure large enough that people check the arithmetic, and they should.

Now the same project, with the hour valued at what the station costs to run.

---

	Time recovered at the constraint, a shift	40 min
	Operating cost of the station, an hour	$45
	Value recovered, a shift	$30
	Fixture, plus three days of engineering	$19,800
	Shifts to pay for itself, was 11	660

Six hundred and sixty shifts is nearly three years. Nothing about the project changed. One number in the middle of the calculation did.

Two working weeks or three years, from the same fixture, on the same line, recovering the same forty minutes. The only difference is which figure sat in the second row, and only one of the two describes anything that happens to the business.

This is not a subtle accounting dispute. It is the most common reason good constraint projects are refused, and it is nearly always made in good faith by somebody using the figure their system gave them.

The four conditions

The arithmetic above is only true under conditions that have to be checked rather than assumed, and a business case that does not state them is not finished. Three of the four are commonly missed.

The station has to actually be the constraint. Recover an hour at a station that already had spare capacity and you have produced nothing except more work in progress waiting in front of the real constraint. The value is zero, and it can be negative once the extra stock is paid for. Identifying the constraint correctly is the whole of this argument, and it is worth a morning with a stopwatch before it is worth a fixture.

You have to be able to sell the extra units. The whole calculation assumes the contribution is realized, and it only is if there is a customer for what the recovered hour makes. If the order book is the binding constraint, the factory constraint is not binding, an hour at test is worth nothing, and the honest answer to the proposal is that the money should be spent on demand instead. This is the condition that gets skipped most often, because it is the one that is not the writer’s department.

The recovered hour has to get used. Forty minutes freed at test and then spent waiting for material from the station upstream is forty minutes of nothing. The recovery is only banked if everything around the constraint is arranged to keep it fed, which is a scheduling change rather than a capital one and usually has to happen first.

The variable cost has to be genuinely variable. Anything that does not change when one more unit is made does not belong in that row. Including an allocated share of overhead is the standard mistake, it always makes the contribution look smaller, and it therefore always makes constraint projects look worse than they are. If the figure came out of a standard cost, take it apart before using it.

Fail the first two and the arithmetic on this page does not apply at all. Fail the third and it applies later. Fail the fourth and it understates.

Where the arithmetic stops

Two questions decide whether any of this holds, and neither is answered by measuring the line as it runs today.

The first is whether the constraint stays where it is once you fix it. Recover forty minutes at test and test may no longer be the slowest station, at which point the next fixture is worth nothing and the money would have been better spent elsewhere. The second is what the recovered hour actually does to the rest of the line: whether the station upstream can feed it, whether the queue in front of it drains or simply relocates.

Both of those are questions about the process as it would be rather than as it is, which is a different exercise from measuring the line in front of you. It is also the point at which the question stops being an arithmetic one and starts being a tooling one.

We do not review software here. Process Improvement Reviews does, against a published rubric and entirely from published sources, and its reviews of the tools that answer this particular question are the place to start.

What to do with it

Work out your own constraint hour and write it on the wall. Contribution per unit times units per hour at the slowest station. Most operations have never computed it, and everyone who sees it for the first time recalculates it, which is the correct response and is how it becomes trusted.

Then price the losses you already know about. The changeover nobody has attacked, the breaks the station is unmanned through, the rework it does twice. Each of those has a number now, and the numbers are large enough that the conversation changes.

And treat the figure as perishable. It moves when the constraint moves, when the price changes and when the mix changes, and a constraint hour computed last year for a product that is now a quarter of the volume is worse than no figure at all.

What the arithmetic will not do is tell you which of the losses to attack first, or which of them can be recovered without spending anything. That is a separate discipline, it has five steps, and the second one is the one that everybody skips: most constraints get elevated before they are ever exploited.