Lot Splitting, Overlapping, and Transfer Batches

Most scheduling logic treats an operation as a single, indivisible block: this job takes six hours on this machine, and it runs start to finish as one contiguous span. That assumption holds most of the time and breaks in a specific, recognizable way — when an operation’s own length is long enough, relative to the time available before its due date, that running it as one block simply can’t finish in time, even though the total capacity to do the work exists somewhere in the plant. Lot splitting and overlapping are the two classic answers to that specific problem, and they answer it in different ways with different costs.

The problem: one big batch, one due date, not enough time

Picture a single operation — say, a bake cycle — that takes 12 hours to run 600 units on one oven, and a due date that only leaves an 8-hour window before the order needs to move to its next operation. Run as one uninterrupted block on one oven, this job simply cannot finish in time; the math doesn’t work no matter how the rest of the schedule is arranged around it. And yet the plant might have two identical ovens, each perfectly capable of finishing 300 units in 6 hours — well inside the 8-hour window — if only the batch could be divided between them.

That’s the structural situation lot splitting and overlapping both exist to solve: a due date the work could hit if it weren’t artificially treated as one inseparable unit.

Lot splitting: the same batch, run in parallel

Lot splitting divides one large operation into several smaller sub-lots that run independently — commonly across multiple machines at the same work center simultaneously, or, less commonly, across consecutive days when parallel machines aren’t available. In the oven example, splitting the 600-unit batch into two 300-unit sub-lots, one per oven, turns a 12-hour single-machine problem into two 6-hour parallel problems that both fit inside the 8-hour window.

Splitting isn’t free, and the costs are worth naming plainly rather than glossing over:

• Each sub-lot pays its own full setup. If the operation needs 20 minutes of setup before it can run, splitting into two sub-lots means paying that 20 minutes twice, not once. A batch split into five sub-lots pays setup five times. This is the single biggest reason splitting isn’t a default behavior applied to every operation — the setup overhead is real and compounds with every additional split.
• Tracking overhead multiplies. Each sub-lot needs its own identity as it moves through the rest of the routing — its own progress, its own location, its own eventual reconciliation back into the parent order’s total quantity. A shop with weak lot-tracking discipline will find splitting adds real administrative friction on top of the setup cost.
• Minimum lot sizes exist for a reason. Splitting a 600-unit batch two ways is a reasonable trade; splitting it twenty ways to shave a few more hours produces twenty sub-lots each carrying a full setup penalty, at some point costing more in duplicated setup than the compressed schedule saves. Most shops define a practical floor — a minimum sub-lot quantity below which a split isn’t worth making — precisely to keep the technique from being applied past the point of diminishing returns.

The trade being made is explicit and calculable: time saved by parallelizing the run, against setup time and tracking overhead paid for every additional sub-lot. Splitting wins when the due-date pressure is real and machines sit idle in parallel; it loses when a shop reaches for it reflexively on operations that were never actually at risk of missing their date.

How split work is usually tracked

A split operation creates a bookkeeping question a whole, unsplit operation never raises: what does the parent operation’s record show once the work has actually run as several independent pieces? The common convention — and the one most production-order systems follow, because it’s what the routing structure was built to hold — is that the parent operation’s own start and end dates represent its overall envelope: from the first sub-lot’s start to the last sub-lot’s finish, a true outer bound on when the work happened, even though the machine-by-machine detail underneath it is more granular than that one span shows. A planner reading only the parent record sees an honest window for the whole operation; the sub-lot-level detail — which unit ran where, in what order — lives one layer down, in whatever system or view is tracking the split itself.

This matters practically because it sets expectations correctly: a high-level report showing one operation’s overall time span isn’t wrong or imprecise when that operation was actually split — it’s answering a different, coarser-grained question than “which machine ran which sub-lot when,” and both answers can be simultaneously true and useful for different audiences.

Overlapping: starting downstream before upstream finishes

Overlapping — sometimes called send-ahead — solves a related but structurally different problem: it doesn’t divide the quantity, it divides the wait. Instead of holding the entire downstream operation until every last unit of the upstream operation is complete, overlapping releases completed units to the next operation as soon as a usable transfer quantity is ready, rather than waiting for the full batch.

Take a three-stage routing — mix, bake, decorate — where decorate cannot normally start until every unit has finished baking. If the first 100 of 600 units come out of the oven with 500 still baking, a strict no-overlap routing makes decorate wait for all 600. An overlapped routing lets decorate start on that first 100 immediately, working in parallel with the oven finishing the rest. The transfer batch — how many units have to be ready before the next operation is allowed to start pulling from them — is the key parameter: a smaller transfer batch starts downstream work sooner but adds more handling trips; a larger one reduces handling but delays the overlap’s benefit.

Overlapping doesn’t add setup cost the way splitting does — there’s still one bake, not two — but it does require the downstream operation to be genuinely able to work on a partial quantity without disrupting quality or process (some operations, like a single continuous chemical batch process, structurally can’t be interrupted or partially consumed), and it requires real material-handling discipline to move partial quantities forward accurately and safely.

Splitting and overlapping compared

The two techniques aren’t competitors — they solve different shapes of the same underlying problem and are sometimes combined. Splitting helps when a job is too long because it’s tied to a single resource and parallel resources exist to share the load. Overlapping helps when a job is too long because downstream work is waiting unnecessarily for a batch that could be consumed incrementally. A shop with idle parallel machines and a batch too big for one of them reaches for splitting; a shop with a strictly sequential routing and no spare machine capacity reaches for overlapping instead, since it costs no extra setup and needs no second machine.

When not to reach for either

Both techniques exist to solve a specific, occasional problem — an operation whose size, relative to its due date, doesn’t fit as one contiguous block. They are not general-purpose speed-up tools, and reaching for them by default has a predictable cost: unnecessary setup repetition from over-splitting, or handling complexity from over-fine transfer batches, applied to operations that were never actually going to miss their date. The right first question, before splitting or overlapping anything, is the one this whole problem starts from: does this operation, run as a single block, actually threaten the due date? If the answer is no, the added overhead of either technique is pure cost with no offsetting benefit.

Related reading

• Sequence-Dependent Setup: The Changeover Matrix Explained — why splitting’s repeated per-sub-lot setup cost is the same category of cost this article covers.
• Modeling Real Capacity: Shifts, Calendars, Efficiency, and Parallel Machines — the parallel-machine capacity that makes splitting possible in the first place.
• Measuring a Schedule: OTIF, Tardiness, and Utilization — the due-date pressure that makes splitting or overlapping worth their cost in the first place.
• In Microsoft Dynamics 365 Business Central: Setup, Run, Wait, Move, Queue: BC Routing Time Elements Explained — how BC represents a routing operation’s time span before any splitting or overlapping is applied to it.