Batch-Size Optimisation: Size the Gain Before You Commit to the Change

Batch-Size Optimisation sits in the Improve phase of RDMAICS. Its job is narrow and useful. It determines the optimal batch size balancing setup cost, WIP, and lead time for the future state.

You reach for it after Analyse has already done its work. By the time you open this tool, you should know that batch size is part of the cause. Maybe queues build between steps. Maybe lead time swings wildly with no change in demand. Maybe people run large batches because changeovers hurt, and the cost of that choice has never been counted.

The Improve phase is where a diagnosed cause becomes a candidate change. The risk at this point is obvious. People commit to a change because it feels right, then discover the gain was smaller than the disruption. Batch-Size Optimisation reduces that risk by making you compare options on one shared measure before you pilot anything.

The example below is fictional. It is the sample data that ships with the tool, and it exists so you can learn the mechanics without supplying your own numbers first.

Picture a process step with a changeover. Running a batch of 5 means paying a setup cost of $3.00 per batch, because the setup is spread across very few units. Running a batch of 20 drops that setup cost to $0.75 per batch, but holding cost climbs to $0.80 per unit and lead time stretches to 40 minutes.

That is the whole tension in one sentence. Larger batches dilute setup cost. Larger batches also inflate holding cost and lead time. The question is not which direction to move. The question is where the two forces cross.

The worksheet is a table with one row per candidate batch size. For each candidate you record four things: the batch size, the setup cost per batch, the holding cost per unit, and the lead time in minutes. The tool returns total cost for each row.

The sample data carries four candidates. Batch size 5 has a setup cost of $3.00, a holding cost of $0.20, a lead time of 10 minutes, and a total cost of $12.00. Batch size 10 has a setup cost of $1.50, a holding cost of $0.40, a lead time of 20 minutes, and a total cost of $9.50. Batch size 15 has a setup cost of $1.00, a holding cost of $0.60, a lead time of 30 minutes, and a total cost of $10.00. Batch size 20 has a setup cost of $0.75, a holding cost of $0.80, a lead time of 40 minutes, and a total cost of $11.50.

Note what the structure forces you to do. You cannot enter a single preferred batch size and ask the tool to bless it. You have to describe several options, which means you have to think about the range before you think about the answer. That alone catches a lot of weak reasoning.

The tool compares the candidates on total cost and reports the lowest total cost first. Lower values are better on this measure. From the sample data it returns an optimal batch size of 10, with a setup cost of $1.50, a holding cost of $0.40, a lead time of 20 minutes, and a total cost of $9.50.

The chart makes the shape of the answer visible. Total cost is $12.00 at a batch of 5, falls to $9.50 at a batch of 10, rises to $10.00 at 15, and reaches $11.50 at 20. That is a curve with a floor, not a straight line. The floor is the answer.

The $10.00 figure at batch size 15 is worth a second look. It is only 50 cents above the optimum. That tells you the curve is shallow on the right side of the floor, so a small drift upwards in batch size is not catastrophic. On the left side the penalty is steeper. Moving from 10 down to 5 costs $2.50 more per unit of measure, because setup cost triples from $1.50 to $3.00.

The result panel also offers an AI review that explains the comparison in plain language. Treat it as a second reading of the same numbers, not as a separate source of truth.

The first decision is whether to pilot at all. A $9.50 total cost against a $12.00 baseline is a real gap. A gap of 50 cents, as between 10 and 15, would be harder to justify disrupting a team for. The tool gives you the size of the prize before you spend anyone's time.

The second decision is which direction to move. If the floor at a batch of 10 is only reachable because setup cost sits at $1.50, then setup reduction work becomes the enabler, not the main event. The lead time column supports a third decision. Lead time falls from 40 minutes at a batch of 20 to 20 minutes at a batch of 10. If your customer problem is responsiveness, that halving may matter more to the pilot narrative than the cost column does.

The third decision is what to control once the change is in. The optimal row becomes the standard you watch in the Control phase. Batch size 10, lead time 20 minutes. Those are observable on the floor without a spreadsheet.

The most common error is entering too narrow a range. If the sample data had stopped at a batch of 10, the tool would have reported 10 as optimal and you would never have learned that 15 and 20 are worse. Bracket the answer. Include at least one candidate you expect to be too large and one you expect to be too small.

The second error is loading costs inconsistently. Setup cost here is per batch. Holding cost here is per unit. If you mix the bases, the total cost column still produces a number, and the number is still wrong. Check the units on every row before you read the result.

The third error is treating the optimum as a precise target. The sample curve shows a floor at 10 with 15 only 50 cents away. That shallowness is information. It means you have room to round the batch size to something the process can actually run, such as a pallet quantity or a tray count, without throwing away the gain.

A result is not a change. Batch size 10 at a total cost of $9.50 is a hypothesis with a number attached. The pilot tests whether the process behaves the way the worksheet assumed.

Write the pilot so it measures the same things the worksheet used. Track actual lead time against the 20 minutes the sample data predicted. Track how often the smaller batch triggers an extra changeover. If setup cost per batch drifts above $1.50 in practice, the floor moves, and you will want to rerun the comparison with the observed figures.

Keep the original worksheet. When someone asks in six months why the batch size is 10, the four-row comparison answers the question faster than any memory of a meeting.

It will not find your candidates for you. The four batch sizes in the sample data were chosen by a person. If the true optimum sits at 12, this tool will never say so, because 12 was never on the list. The output is only as good as the range you offered.

It will not validate your costs. A setup cost of $1.50 and a holding cost of $0.40 are accepted as given. The tool has no way to know whether those came from a time study or from a guess. Garbage in produces a confident-looking curve.

It will not account for anything outside its four columns. Quality effects, operator fatigue, batching rules imposed by a supplier, equipment constraints, shift patterns, scheduling knock-on effects. None of that is in the model. A batch size that minimises total cost can still be impossible to run.

It will not tell you whether batch size was the right cause to attack. That judgement belongs to Analyse. If the real constraint is downstream, a perfect batch size changes very little. Use this tool to size a gain you have already diagnosed, then test it in a pilot, then hold it in Control.