Ask Whether the Software Can Model Your Plant

The demo leads with the algorithm

The typical scheduling software demo leads with the algorithm. A slide about how the search finds better schedules and the benchmarks keep improving. That is the easy pitch, and it is the same pitch for every plant in the room. The question nobody asks in the demo is the one that decides whether the tool works at all: can it hold this plant's physical facts? A batch stage feeding a continuous one, a changeover that takes three times longer one way than the other, twenty minutes to pump material between stages, a shift calendar that closes on Friday evening. If the model cannot hold those facts, the clever algorithm is optimizing a plant that does not exist.

Plans that look optimal and die on the floor

The scheduling literature has documented the gap between optimized schedules and executed ones for decades. Theory optimizes under static, deterministic assumptions; the floor runs a dynamic, stochastic reality. When a schedule does not survive contact with the shop floor, the standard response is to reschedule, which can delay or invalidate the work it was meant to protect. Schedule instability is a studied phenomenon. When the schedule keeps moving, the people running the line stop trusting it, and effort goes into chasing revisions. No statistic is needed; plant managers have lived this. The optimizer's sophistication is measured on a simplified model, while the floor runs the complicated reality. The gap between the two is a modeling gap.

The real test is the model, not the optimizer

The deciding factor in scheduling software selection is therefore model fidelity, not optimizer sophistication. Model fidelity is how faithfully the tool represents the process: batch versus flow stage behavior, changeover direction, transfer and handoff delays, shift calendars and downtime. Optimizer sophistication, the optimization language, is the algorithm's pitch: how smart the optimizer sounds when the vendor presents it. A scheduling tool is only as trustworthy as the process model underneath the optimizer. A powerful optimizer over a model that cannot represent the plant's physics produces schedules that cannot be executed, whatever the pitch claims.

Five physical facts a scheduler must hold

What does "represent the process" mean in practice? Five physical facts. Ask them of any tool.

Batch and flow stages in one route. A mixer works in batches on a cycle; a filler runs at a rate per hour, and one route contains both. Can the tool hold per-stage physics, or does it force one blended line speed?

Changeovers whose direction matters. Moving from one product to another takes different time than moving back. In the illustrative settings below, the wash-down into a light product takes far longer than the rinse in the other direction. Can the tool hold a changeover value that differs by direction?

Transfer and handoff delays. Material takes time to move between stages, by pump, conveyor or forklift. Can the tool chain a downstream start to upstream completion plus the transfer time, or does material arrive instantly?

Shift calendars, exceptions and downtime. Nights, weekends, holidays and booked downtime are capacity facts. Can the tool schedule work into working windows, or does it plan in elapsed time as if the plant never stops?

A visible wait when the line starves. When a downstream stage outruns the upstream supply, the schedule should show a wait, not assume material was already there. Can the tool show starvation?

A tool that cannot hold one of these produces schedules the floor cannot follow.

What the five facts are worth in settings

The five facts are not abstractions. Each one is a value a plant can state and a tool can either hold or lose. Write yours down before any demo, in whatever units your plant uses. The values below are illustrative and plant-specific; yours will differ.

Now ask what a tool does when it cannot hold one of them. A model that blends a batch stage and a flow stage into one line speed plans the fast stage against supply the slow one cannot deliver. A model that carries one changeover value for both directions treats the long transition and the short one the same, and a week that fits on paper does not fit on the floor. A model that moves material between stages instantly starts the downstream stage at the minute the upstream one finished. A model that plans in elapsed time treats nights and weekends as working hours, and a three-day schedule lands as a five-day one.

None of these is exotic, and each of them moves the schedule on its own. Together they produce a schedule the floor cannot run. No optimizer over such a model can recover, because the model never held the facts that would have exposed the error.

The optimizer is bounded by the model

The optimizer is bounded by the model, and that is exactly how Schantt works. The scheduling algorithm can only act on what the model represents. In Auto mode the tool may reorder the production sequence, clustering products so the long changeovers happen rarely; that works only because the model holds directional changeover values. In Semi-Auto mode the plant fixes the production sequence and the software optimizes the rest: which machine, which day, when each batch starts. In both modes the goal is total production time computed on the modeled physics, including batch cycles, changeovers, transfers, calendars and waits. The algorithm is only as good as the process model underneath it.

Fidelity and data upkeep are bought together

Modeling depth and data maintenance are bought together. The fidelity test therefore includes a question about data entry: can the plant's own values, changeover times, line speeds, batch sizes, transfer times and routing, even be entered and kept current? Schantt supports bulk configuration entry with validation, so a workbook of values loads in one pass. But the planner owns the numbers. The tool imports and validates; it does not measure or maintain them. A precise model fed with stale changeover times is a precise model of last year's plant. A schedule is only as good as the data underneath it.

When optimizer sophistication legitimately wins

Some plants are genuinely static. With a stable product mix, balanced stages and generous buffering between them, the static, deterministic scheduling model applies, and optimizer sophistication can be the differentiator. The claim of this post is that fidelity matters at least as much, not that it always wins. If your plant's physics are mild, compare algorithms freely. If they are real, compare models first.

Apply the model-fidelity test first

So apply the model-fidelity test before you compare algorithm pitches. Can the tool represent batch and flow stages in one route? Can it hold a changeover value that differs by direction? Can it chain a downstream start to an upstream completion plus a transfer time? Does it schedule into shift calendars and downtime, and show a wait when the line starves? If the model cannot hold the plant's physics, no optimizer over it can be trusted, whatever the benchmark slide claims. The algorithm's pitch is worth hearing. It is not worth hearing first. Model fidelity is the test that tells you whether the rest of the conversation is about your plant, or about a plant that does not exist.