Batching
A batch size is a changeover time that nobody measured
Ten items, three steps, one minute each. Batched, the first one leaves in twenty one minutes. Unbatched it leaves in three, and the total work is identical.
Ask why the batch is twenty five and you will get one of three answers. That is what fits on the trolley. That is what the previous system defaulted to. Or, most often, nobody knows, it has been twenty five since before anyone currently on the line arrived, and the question has never been put.
None of those is a reason. There is exactly one legitimate reason to run work in batches, it is arithmetic rather than habit, and once it is written down it usually turns out to prescribe a much smaller batch than the one in use.
What a batch costs
Start with the cost, because it is invisible until it is drawn. Three steps, one minute of work each, ten items to get through. The work content is thirty item minutes and no arrangement changes that.
Run it as a batch. All ten are cut, then all ten are formed, then all ten are packed.
| Step one, ten items at one minute | 10 min | |
| Step two, the batch moves and ten items are formed | 10 min | |
| Step three, the first item is packed | 1 min | |
| When the first finished item exists | 21 min |
Illustrative figures, and deliberately the simplest case there is: no changeovers, no variation, no transport time. The last item of the batch is finished at thirty minutes.
Now run the same ten items one at a time, each moving to the next step as soon as it is done.
| Step one, the first item | 1 min | |
| Step two, the first item | 1 min | |
| Step three, the first item | 1 min | |
| When the first finished item exists, was 21 min | 3 min |
The last item is finished at twelve minutes rather than thirty. Same three steps, same one minute each, same thirty minutes of work performed by the same people.
Twenty one minutes against three for the first item. Thirty minutes against twelve for the lot. Nobody worked faster, no equipment changed, and the labor content is identical to the minute. The eighteen minutes the batch cost were spent by nine items waiting for a tenth they had nothing to do with.
That is the general shape of it. A batch makes every item in it wait for the slowest arrangement of all of them, at every step, and the penalty grows with the batch and with the number of steps.
What a batch buys
So why does anyone batch. Because switching between one kind of work and another is not free, and the time it takes is charged once per batch rather than once per item. Make the batch bigger and the switching cost per item falls. That is the entire argument for batching and it is a real one.
Which makes the batch size a straightforward budgeting question. One machine, one shift.
| Time available in the shift | 450 min | |
| Demand, 240 units at one minute of run time each | 240 min | |
| Time left for changeovers | 210 min | |
| Changeover time, measured | 12 min | |
| Changeovers the shift can afford | 17 |
Seventeen changeovers over 240 units is a batch of about fourteen. Sixteen batches of fifteen fits with eighteen minutes to spare, so fifteen is the smallest batch this shift can actually run.
Fifteen. Not because fifteen fits on the trolley, but because the changeover is twelve minutes and the shift is 450. If the batch in use is sixty, then four changeovers a day are being run where sixteen were affordable, and the difference is being paid for in waiting by everything in the queue.
The relationship is worth printing, because it is the answer to the question people actually want answered.
| Changeover | Changeovers affordable | Smallest batch |
|---|---|---|
| 20 min | 10 | 24 |
| 12 min | 17 | 15 |
| 6 min | 35 | 8 |
| 3 min | 70 | 4 |
Read down that column and the point of every changeover reduction program ever run becomes obvious. The batch size is not a policy. It is an output. Halve the changeover and the affordable batch roughly halves with it, without anybody needing to be persuaded of anything, because the constraint that forced the old batch has gone.
Which is why the sequence matters. Mandating a smaller batch before the changeover comes down produces a shift that runs out of time, misses its numbers, and concludes that small batches do not work here. Bringing the changeover down first makes the smaller batch the obvious thing to do next, and nobody has to be argued into it.
When the batch is not yours to choose
Some batches are physical or contractual and no amount of arithmetic dissolves them. An oven that holds forty trays. A courier that leaves at four. A payment file the bank accepts once a day. A report that runs when the overnight job runs.
In those cases the size is fixed and the frequency is the lever, and the arithmetic is even simpler: with work arriving steadily, the average wait for a departure is half the interval between departures.
| Working hours between collections | 8 h | |
| Average wait for the next collection, half the interval | 4 h | |
| Working hours between collections, twice a day | 4 h | |
| Average wait, twice a day rather than once | 2 h |
The batch is the same size and the same lorry does the same work. Only the interval changed, and the average wait fell with it. This holds whenever arrivals are roughly even between departures.
Two hours off the average journey of every item in the process, for a scheduling conversation. That is the standard shape of the fix in office work, where the batch is nearly always a schedule rather than a container: approvals gathered for a weekly meeting, records created on Tuesdays and Thursdays, invoices posted at month end. Nobody thinks of those as batches, and every one of them is.
Two things this does not say
It does not say the batch should be one. Moving items individually has costs of its own: handling, transport between steps that are not next to each other, tracking, and in transactional work the mental changeover of switching between case types, which is a real changeover even though nothing is unbolted. Where those costs are high the economical batch is genuinely larger than one, and the arithmetic above is how you find out where, rather than an argument that the answer is always the same.
It does not say batching is the reason the process is slow. It is one reason, and on a process nobody has measured it is rarely the largest. The way to find out is to sort every wait in the process by size and look at the biggest one, which may well turn out to be a batch and may equally turn out to be an approval sitting in somebody’s diary.
What the arithmetic does do is remove the batch size from the category of things that are simply how it is done here. It is a number, it follows from another number that can be measured with a stopwatch in an afternoon, and where the two disagree it is the batch that is wrong.
The other thing worth knowing is what a rule like this does to a process once it is embedded, which is that it stops looking like a rule at all and starts looking like a capacity problem. That confusion, and how to tell the two apart, is the subject of its own piece.