12.7 Process Batches, Transfer Batches, and Backflushing

Process Batch Versus Transfer Batch

A process batch is the quantity produced between setups. It is driven by setup economics: a large setup cost pushes the batch up, carrying cost pushes it down - the same trade-off behind economic order quantity in chapter 10.

A transfer batch is the quantity moved to the next operation. It is driven by flow: container size, handling equipment, distance, and how soon the downstream resource can start.

The central lean and theory-of-constraints insight is that these two quantities do not have to be equal, even though most enterprise resources planning defaults make them equal. Shrinking the transfer batch shortens lead time without touching setup cost at all, because you still run one setup per operation. You pay in moves, not in changeovers.

Worked comparison

A process batch of 500 units runs through two operations. Operation A: 2.0-hour setup, 0.04 hours per piece (20.0 hours run). Operation B: 1.0-hour setup, 0.03 hours per piece (15.0 hours run). Move time is 0.4 hours; queue excluded.

Transfer batch = process batch (500): 2.0 + 20.0 + 0.4 + 1.0 + 15.0 = 38.4 hours.

Transfer batch = 50: operation A completes its first 50 at 2.0 + 2.0 = 4.0 hours; they arrive at B at 4.4 and B's setup finishes at 5.4. B is the faster operation, so it starves between transfers and the finish is governed by the last transfer batch: A completes all 500 at 22.0 hours, move to 22.4, run the final 50 at 50 x 0.03 = 1.5 hours, complete at 23.9 hours.

That is 14.5 hours - a 38% reduction in throughput time - with the same two setups and the same 500-piece process batch. What changed is ten moves instead of one, ten move transactions, and work-in-process sitting in two places at once. This is the principle underneath the overlapped-scheduling technique in section 12.5: overlapping is the scheduling mechanic, and "transfer batch need not equal process batch" is the reason it works.

What Is Actually Runnable Today

A schedule says what should run. Four status feeds say what can run, and the gap between them is where dispatching earns its keep:

• Equipment status - up, down, degraded, or not qualified for this part; tooling, dies, fixtures, and programs present and within calibration.
• Labor status - who reported, who is certified on the operation, and whether overtime is authorised.
• Work-order status - planned, firm planned, released, in process, on hold (quality, engineering, or material short), complete, closed. Only a released order with material allocated and no hold is dispatchable. A planner who dispatches from the order pool rather than the released pool is scheduling work the floor cannot start.
• Preventive maintenance schedules - planned downtime must be netted out of available capacity before loading, not discovered afterwards. Deferring preventive maintenance to protect this week's schedule borrows hours at a punitive rate: the unplanned breakdown arrives without warning, usually in the week you can least afford it.

Backflushing

Backflushing (post-deduct inventory transaction processing) deducts component inventory automatically from the reported completion of the parent. Report 400 finished units and the system explodes the bill of material (BOM), relieving 400 times the per-unit quantity of every backflushed component from its point-of-use location. No picks, no issue transactions, no material-issue paperwork.

The appeal is transaction cost. On a repetitive line building thousands of units a day from dozens of components, discrete issues would flood the system with transactions that add no control value.

The prerequisites are cumulative - you need all of them, not most:

• Accurate bills of material at the current revision, with realistic scrap and yield factors
• Low, predictable scrap and substitution - the system deducts what the BOM says, never what was actually consumed
• Short cycle times and low work-in-process, so the timing error between real consumption and the reported deduction stays small
• Accurate completion reporting at the count point, with correct unit-of-measure conversions
• Disciplined point-of-use replenishment, so the location being deducted is the location being consumed

The failure mode is silence. A discrete issue that goes wrong leaves a wrong transaction somebody can find. A backflush that goes wrong leaves no transaction at all - an undocumented substitution, an unreported scrap event, a BOM one revision stale - and the balance simply drifts. Errors accumulate invisibly until inventory record accuracy collapses, and then the consequence chain the exam loves runs to its end:

stale BOM or unreported scrap, wrong quantity deducted, inventory record accuracy falls, MRP nets against a fictitious on-hand balance, wrong planned orders, shortages and excess appear at the same time, expediting.

Controls that keep backflushing honest: backflush only low-value, high-usage, stable components and issue high-value, serialized, or lot-traced items discretely; place count points at meaningful intermediate stages rather than only at final completion; treat any negative on-hand balance as a backflush error alarm; and cycle count backflushed items more frequently, because cycle counting is the only detector you have.

Closing Work Orders

Closing an order is a control transaction, not clerical tidying. At close you capture the final quantity completed, the scrap and reject quantity with its disposition, actual labor and machine hours, and any material issued but unused and returned. Those numbers produce the variances - material usage, labor efficiency, yield - and they feed the scrap factors and time standards used to plan the next order.

Leaving an order open does specific, traceable damage:

• Allocations stay live. Components remain reserved for an order that is already finished, so net available and available-to-promise are understated and MRP plans replenishment nobody needs.
• The open order still looks like a scheduled receipt. MRP believes supply is coming that will never arrive, under-plans against it, and the shortage surfaces later.
• Work-in-process value is overstated, and the residual eventually falls out as a write-off nobody can explain.
• Capacity reports carry phantom load - remaining operation hours on a completed order inflate work center load and distort every capacity decision built on it.

Close orders promptly, and close them with real numbers. An order closed at the planned quantity instead of the actual one is a backflush error with a signature on it.