Your Recovery Runs Are Writing the Capital Request

The scheduler who could name the trade

A scheduler walked my team through how her production week actually gets built. Most of the hour was the map you would expect: demand and firm orders, jobs issued well ahead, materials staged before anything goes on the board. Then she described a save, and the save is the part worth keeping.

A new item arrived with its packaging material already in house and no runway on the hold step that sits between making the product and packing it. Her route has three steps, and the third cannot start until the second has had its wait. She did not have the wait. She also had no trial on the item, so she could not predict how it would behave through the hold. So she ran it on the shared freeze asset with a consumable that buys the wait back, and the order went out on its date.

Then she said the part that almost never gets written down. Doing that takes capacity on that asset away from another item.

The hold did not go away, it changed accounts

A mandatory hold is not a queue. It is a physical state change with a duration, and the duration belongs to the product, not to the schedule. You can move the product, you can resequence around it, and you can buy it back with energy or a consumable. What you cannot do is delete it.

Buying it back is the move almost every plant with a hold step already knows. Blast instead of waiting. Add the gas. Take the faster pass. It is legitimate, it is sometimes the right call, and it is the only tool available once an order has been accepted without runway.

The problem is where the cost lands. The consumable shows up as a material variance, which is small and visible and gets argued about. The real charge is a block of time on a shared asset, and that block is almost always under-loaded. These assets are sized for an efficient batch per shift. A recovery run is one item, usually a short one, often a new one with no history. It takes the hour and returns a fraction of what that hour is worth.

That is one of two charges. The second is the item that was already planned into the block. It does not vanish. It moves, and if the week is tight it moves out of the week entirely, because backfilling the live week is how a single miss becomes a standing one. So a single order accepted without hold runway spends a block of asset capacity at poor yield and displaces a second item into a future week.

Neither charge has a line of accounting. The order shows its date met. The asset shows a low-yield hour. The displaced item shows a changed plan date. Three records, no link between them.

How this becomes a capital request

Watch what happens to the asset's load report over a quarter. It fills with hours. A meaningful share of those hours are recovery runs at a fraction of the efficient load. Average load per run falls, hours booked climb, and the asset starts to look like the thing that is short.

At that point someone prices the expansion, and the case is arithmetically sound and directionally wrong. The hours are real. The attribution is not. A share of that load is not demand, it is the plant converting accepted promises into asset time because the hold runway was spent before the order was taken.

Expanding the asset works, briefly. It also funds the upstream behavior. More recovery capacity means less friction on accepting an order with no runway, which means more recovery runs, which rebuilds the same load profile against a larger asset. The optimize case and the expand case look identical in the load data and are opposites in the operating model.

My rule here is narrow and it has held: before any capital goes to an asset that substitutes for time, the load on that asset has to be split into planned and recovery, with every recovery run traced to the order that caused it. If that split cannot be produced, the answer is not a smaller number. The answer is that the asset is not the subject yet.

Three things to pull before you price anything

Split the load. Take the last month of runs on that asset and tag each one planned or recovery. Planned means it was on the board when the week was built. Recovery means it was added to buy back a hold. If nobody can tell which is which from the records, that is the finding, and it is a bigger one than the capacity number.

Sort the recovery runs by load and name the order. For every run below the asset's minimum efficient load, find the order that triggered it and the date that order was accepted. You are looking for a pattern in acceptance, not in the asset. New items, items with no trial, and items where material arrived before the runway existed will cluster.

Follow the displaced item. For each recovery run, find what was planned in that block and what happened to it. If it moved to a future week, that week absorbed a cost created by a different order, and the only person who can see the connection is the scheduler who made both moves.

Keep the consumable cost out of this. It is the smallest number on the page and it pulls attention toward the variance and away from the capacity.

What a plant with a real hold runway reads like

Order acceptance names the hold runway in days next to the promised date, and the person who commits the date can see both before committing. Every substitution run on the shared asset carries two references, the order that triggered it and the item whose block it took. The asset's load report shows planned hours and recovery hours separately and states the recovery share for the period. Recovery share has a threshold that triggers a review of acceptance, not a review of the asset. Capital on that asset is priced on planned load only, and the recovery share has to be falling before the case is heard.

Ask for the split before the number

The next time an asset that substitutes for a hold step shows up in a capacity conversation, do not ask how many hours it ran. Ask what share of those hours were recovery, and ask who can name the orders behind them. If the split exists, you have a real capacity question. If it does not, you have an acceptance question that has been wearing a capital request, and the person who can tell you so in one sentence is the scheduler.