A Throughput Request Cannot Find a Yield Loss

The request gets narrowed twice, and only one narrowing gets noticed

A plant data request on one of our engagements was narrowed twice in the same short call.

The first narrowing was the window. The ask covered a full year of history. The plant said a year would be heavy and offered year to date instead, and the team took it. That is an ordinary trade, and the requester made the right call: a shorter window that actually arrives beats a longer one that stalls in the reporting queue.

The second narrowing was the question itself, and it went by in a few seconds. Someone on the plant side asked whether a bin weight would answer the question without also knowing the weight of the material that entered the cut. A colleague answered on the requester's behalf that yield was not what he was after. The requester confirmed it. They wanted pounds per hour by cut, because the same crew takes far longer to fill a bin on some cuts than others, and the labor and overtime case needed a rate standard.

Then the plant offered something nobody had asked for: an existing report that compares standards to actual inputs and outputs, cut by cut. Someone in the room named it for what it was, a yield report, and the conversation moved on.

Both narrowings were defensible. Only one of them will be remembered.

One weight event, two questions, one of them asked

The weight exists for a single reason. An operator pulls a bin onto a scale and prints a label. That event is the raw material for two different calculations.

Divide label weight by elapsed run time and you get rate. Compare the mass that entered the run against the mass that left it in labels and you get yield. Same scale, same keystroke, same timestamp.

Rate is easier to request because it needs only the output side: run boundaries, label count, weight per label. Yield needs both sides, and the input side is where plants are weakest. In this case the input side was not merely missing from a report. The facility converts material it does not own, purchasing functions as inventory management rather than sourcing, and inbound pallets arrive commingled, so isolating what entered a given run would mean de-stacking loads before every shift. Nobody presented that as a finding. It arrived as an aside while scoping a spreadsheet.

That is the difference between a loss that stops the line and a loss that ships. Downtime announces itself, because someone is standing still and you can see it from the aisle. Scrap announces itself, because it occupies a container and somebody has to move it. Product committed above requirement leaves the building as sellable product. It clears the checkweigher, satisfies the specification, invoices normally, and shows up in no variance report that was not deliberately requested. Its only visible trace is the weight distribution, and the weight distribution is the field most likely to be scoped out, because the urgent question is almost always rate.

My rule after enough of these calls: the person who narrows a data request owns the narrowing in writing. Not the plant, and not the analyst who inherits the file three months later.

Ask for both sides, then price what you chose to exclude

Four things change if you treat the request as a decision rather than a logistics step.

Ask for the weight events, not the aggregate. Start time, stop time, label count, net weight per label, and the cut or item. A daily finished goods total cannot be decomposed back into either answer, and it is usually the field the plant says is hardest to produce. If you accept the total to save the plant effort, you have bought a number that answers nothing.

When the plant volunteers a report you did not ask for, take it. An operations team that already maintains a trim loss or standards variance report has already formed a view about where material goes. The existence of that report is evidence before anyone reads a row of it.

When you descope a question, record it where the next decision will see it. One line on the request, naming what was excluded and why. Without it, the rate baseline becomes the plant's complete picture of itself, and the next capital case gets modeled on an assumption of fixed material loss that nobody consciously made.

When the input side is structurally unavailable, report it as a conclusion. A plant that cannot reconcile input mass to output mass for a run cannot verify a material saving, which means it also cannot be paid for one. That constrains what you should promise a client or a board before it constrains what you measure. Negotiated savings, an implemented change, and a verified result are three different states, and the third one requires a reconciliation this plant cannot currently perform.

What a well-run version reads

Every run has a start timestamp, a stop timestamp, a label count, and a net weight per label, retrievable without a custom query. Input mass per run is identifiable to a stated tolerance, and the tolerance is written down. Rate and yield are derived from the same source table rather than from two systems that disagree. When a data request excludes a question, the exclusion is on the request, with a date and a name. A requester can answer, in one sentence and without rerunning anything, which losses the current data set is incapable of showing.

The test

Pull your most recent operational data request. Count how many fields describe time and how many describe mass. If the only mass field is an output quantity, you are about to build a rate standard that treats everything leaving inside the product as a constant, and the number you produce will be used that way for a year.

ARTICLE TITLE: A Throughput Request Cannot Find a Yield Loss