Batch and Flow Stages Keep Different Time

Two physics in one route

Picture a route you actually run: a mixer, cooker, reactor, or oven that charges a whole load, processes it for a fixed cycle, and releases it as one lump; and, a step or two downstream, a filler, packer, or drying line that takes material in at a steady rate. The two stages ask the schedule two different questions. The batch stage asks: how long does a load take on its cycle, and how many whole loads does this quantity make? The flow stage asks: at this rate, how long does the material take to pass through? One route, two physics. A schedule that answers both questions with a single duration model will be wrong in a specific, visible way: wrong about when the batch stage finishes, and wrong about when the flow stage actually has material to run.

The status-quo trap: one duration model for everything

The trap is the single duration model. A tool that times every stage the same way (a per-unit time, usually with setup and cleanup added, or a single per-batch time) cannot represent both kinds of physics in one route. One mainstream system, Odoo, models work-center duration as per-unit time with setup and cleanup, plus a count of units run at once, with no whole-load cycle concept. That is a single example, offered as context, not a market claim. The argument here is narrower and stronger: any tool that forces one duration model onto both stage types mis-times a mixed route and hides wait-material starvation. The failure takes two shapes. A per-unit model cannot represent partial-load rounding on a batch stage: it treats a third of a load as a third of a cycle, which a fixed-cycle batch stage never takes. A per-batch model cannot represent a flow stage's linearity in quantity: it cannot show that twice the material takes twice the time at the same rate. Both errors land the same way: the schedule's timing is wrong, and the wrongness stays invisible until material fails to arrive at the moment the schedule assumes it.

Duration is stage-type-specific

A batch stage's duration is whole-load physics. The number of loads is the quantity divided by the batch size, rounded up (a third of a load still takes a full cycle), and the stage's duration is that number of loads times the batch cycle time. A flow stage's duration is rate physics: the quantity divided by the throughput, equivalently the quantity times the minutes per unit. These are two different models, not two settings of one model. One quantizes; the other is linear. The rounding is the crux: a per-unit view of a batch stage sees 2,500 kg as two and a half units of work, but the equipment sees three loads. This is exactly how Schantt models it. Each stage is typed batch or flow; batch stages take a batch size and batch cycle time; flow stages take a line speed or throughput; and a product class routes through both stage kinds in one ordered path. Mixed batch-and-flow pipelines are first-class, not a special case bolted on.

A worked example: a batch mixer feeding a continuous filler

Here is what the two models do to the same quantity. The arithmetic below is derived from the two formulas above; it is a worked example of the models, not a statistic from any plant. Setup: a batch mixer with batch size 1,000 kg and batch cycle time 2 h, feeding a continuous filler with throughput 1,000 kg/h, with partial transfer enabled on the handoff at 1,000 kg (without it the filler cannot start until the mixer's whole run is done). The quantity is 2,500 kg.

Batch stage, its own model. 2,500 kg ÷ 1,000 kg is 2.5 loads, rounded up to 3; 3 loads × 2 h = 6 h. The third load is partial (500 kg) and still takes a full cycle.

Batch stage, flattened to per-unit time. 2 h ÷ 1,000 kg = 0.002 h per kg; 2,500 kg × 0.002 h/kg = 5 h. The flattened model understates the stage by 1 h because it cannot see the partial-load rounding.

Flow stage, its own model. At the filler's 1,000 kg/h rate, 2,500 kg takes 150 minutes, or 2.5 h.

Now put the two stages together and watch the releases. The mixer completes a load every 2 h: 1,000 kg at t = 2 h, 1,000 kg at t = 4 h, and the final 500 kg at t = 6 h. The filler starts at the first release, exhausts it by t = 3 h, and waits 1 h for the second load at t = 4 h.

The flattening error is not mainly in total time. It is in the release profile: a per-unit schedule makes the filler's supply look continuous, so the 1 h wait between t = 3 h and t = 4 h never appears in the schedule.

What the schedule shows: the wait-material pause

When a downstream stage runs out of material before the next supply lands, the schedule shows it: a wait-material pause on that stage's row until the next arrival. This is schedule timing, not inventory. Nothing here is about stock levels or buffer sizing; it is about what the schedule says the stage can do at each moment. Because a batch stage makes material available in lumps (a whole load at a time, at cycle intervals, once partial transfer is enabled at the handoff), a flow stage fed directly from it is governed by that rhythm. With no buffer between the stages, the downstream stage can only draw at the moments a load completes; it cannot run ahead of the releases, however steady its own rate. Leave partial transfer off and the handoff is stricter still: the downstream stage waits for the upstream stage's whole run before it starts at all. A schedule built from per-unit durations hides exactly this. Its arithmetic never produces the starvation window, so the window cannot appear; the schedule shows the filler running on material that, in the modeled world, has not arrived yet. Partial transfer is set per handoff rather than globally, so one route can mix full-completion handoffs with overlapping starts, and it changes the handoff timing, not the physics. The wait-material pause remains the visible consequence this post is built on.

What this argument is not

This is a claim about two duration models, not a claim that real stages behave perfectly. Batch stages vary (variable batch sizes, parallel vessels, partial transfers), and flow lines ramp up and stop for cleaning. The models use planner-set baseline values: a fixed batch size, batch cycle time, and throughput. Real plants vary; the argument is a model choice, not universal physics. The flattening error also has a scope. It bites where quantities are not whole numbers of loads and where batch cycles are long relative to downstream consumption. A fast batch step feeding a slow line is genuinely well-approximated by a rate, and there the single model loses little. Buffer or surge capacity between stages is real plant practice, and it sits outside the schedule model: naming it here is context, not a modeled feature. And starvation, as described throughout, is schedule timing. Nothing in this post is inventory management or stock-control advice.

The takeaway: a three-question test, and what Schantt does

Try a three-question test on the tool you use. One: does it round a partial load up to a full cycle on a batch stage? Two: does the schedule feed each downstream stage from upstream completions, or does it assume material is always available? Three: when a stage runs out of material, does the schedule show it (a visible wait-material pause) or does the timing error stay invisible? A tool that fails the first question cannot time a batch stage; failing the second and third, it cannot show you when a mixed route will actually starve. Schantt's answer is the direct one: model batch stages by loads and batch cycle time; model flow stages by rate; treat mixed batch-and-flow pipelines as first-class; show the wait-material pause on the schedule when supply timing lags demand; and offer partial transfer per handoff. None of this is configuration trivia. These choices exist because the schedule's job is to minimize total production time across all jobs, and a timing that starts from the wrong duration model cannot be trusted on a mixed route, no matter how well the rest of the schedule is built.