Every plant has a version of this argument. The MES dispatches Job B ahead of Job A, the scheduler on the floor is convinced that’s wrong, and IT gets a ticket that says “scheduling logic is broken.” Nine times out of ten, the logic isn’t broken. It did exactly what it was told to do. The problem is that nobody on the floor — sometimes nobody in the building — fully understands what it was told to do in the first place.
That gap is going to get worse before it gets better. As more MES platforms add “autonomous” or AI-assisted dispatch on top of traditional scheduling engines, the decisions get harder to trace, and vendors have not been especially good about exposing the reasoning in a way a controls engineer or production supervisor can actually audit. So it’s worth stepping back and understanding what’s really happening at ISA-95 Level 3, before you either blame the software or start clicking priority flags at random hoping something improves.
Where scheduling actually sits in ISA-95
ISA-95 splits manufacturing operations into levels. Level 4 is business planning — ERP territory, where someone decides what to make, how much, and by when, in units like weeks or days. Level 3 is manufacturing operations management — the MES layer — where that business-level plan gets translated into an actual sequence of work orders, operations, and dispatch decisions on specific lines, cells, and machines, in units of shifts, hours, and minutes. Level 2 and below is the control system itself: PLCs, SCADA, the equipment executing the step it’s been told to run.
The scheduling engine lives at Level 3 precisely because that’s the boundary where “make 5,000 units by Friday” has to become “run Job 4471 on Line 2 starting at 6:40 AM, changeover at 11:15, then Job 4483.” That translation is not arithmetic. It’s constraint-solving, and it’s where most of the disagreement lives.
Finite vs. infinite capacity: the first fork in the road
Before any priority rule matters, you need to know which capacity model your MES is running, because it changes everything downstream.
Infinite capacity scheduling assumes a resource can absorb as much work as you throw at it, and it schedules based purely on due dates and priorities, without checking whether the line can physically do it in the time available. This sounds naive, and for shop-floor dispatch it usually is, but it’s genuinely useful for rough-cut, longer-horizon planning where you’re trying to spot demand spikes before you commit real capacity to them.
Finite capacity scheduling respects actual constraints: machine availability, crew headcount, tooling, calendars, maintenance windows. It won’t let you schedule twelve hours of work into an eight-hour shift. This is what almost every real-time MES dispatch list is running, at least nominally, because the whole point of Level 3 is to produce a plan the floor can actually execute.
Here’s the practical gotcha: a lot of “the schedule is wrong” complaints trace back to a system that’s technically finite-capacity but has bad or stale capacity data feeding it — a machine calendar that still shows availability during a maintenance window, a crew size that hasn’t been updated since the last shift-pattern change, tooling constraints that were never modeled at all. The engine isn’t confused. It’s finite-capacity correct against inputs that are wrong.
Priority rules: the part everyone assumes they understand
Once capacity is modeled, the scheduler needs a tiebreaker logic for which job goes first when multiple jobs compete for the same resource. Common rule types, often layered rather than used alone:
- Due date / earliest due date (EDD) — whatever’s due soonest goes first. Simple, and it’s the default a lot of shops start with, but it can starve a job that’s due later but has a long remaining routing.
- Critical ratio — compares time remaining to work remaining, so a job that’s behind pace relative to its due date gets bumped up even if its absolute due date isn’t the nearest.
- Shortest processing time (SPT) — run quick jobs first to clear queue and improve throughput metrics, at the cost of potentially delaying a long job indefinitely.
- Customer or order priority flags — manually or ERP-assigned weighting, often the thing that quietly overrides everything else and the first place to look when a “should have run” job didn’t.
- Setup-based sequencing — group jobs to minimize changeovers (same tooling, same material, same color/allergen family), which can deliberately delay a higher-priority job because inserting it would trigger an expensive changeover.
Most real MES configurations run a weighted or hierarchical combination of these, not a single rule. And that’s exactly why troubleshooting “wrong job” complaints usually means finding the rule stack and checking which rule actually won the tiebreak — not assuming there’s one master priority number somewhere.
Sequencing constraints: the quiet dealbreakers
Even a perfectly prioritized job can be legitimately blocked. This is the layer people forget to check because it doesn’t look like “scheduling” — it looks like a rule buried in a routing or a BOM.
- Material availability — the job is ready by every priority measure, but the component lot hasn’t cleared quality hold or hasn’t arrived.
- Tooling and fixture constraints — the required die, mold, or fixture is in use on another line or is mid-changeover.
- Precedence/routing constraints — Operation 20 cannot start until Operation 10 is confirmed complete, which matters a lot when Level 3 is reconciling against real-time execution data instead of a static plan.
- Changeover and sequence-dependent setup rules — allergen changeovers in food, color sequencing in paint, cleanroom gowning in pharma — these often hard-block a sequence regardless of due date urgency.
- Operator/skill and certification constraints — a job requiring a certified operator won’t dispatch to a line without one on shift, even if that line is otherwise free.
Constraint conflicts are where “the AI made a weird call” complaints usually originate in newer MES deployments. The optimization layer found a technically valid sequence that satisfies every hard constraint and priority weight simultaneously — it’s just not the sequence a human scheduler would have picked by instinct, because the human wasn’t weighing tooling contention and changeover cost the same way the algorithm was.
Reading the engine instead of overriding it
When a dispatch decision looks wrong, the useful troubleshooting sequence is almost always the same:
- Check the capacity model first — is this genuinely finite, and is the underlying calendar/crew/tooling data current?
- Identify which priority rule(s) are active and how they’re weighted or ordered.
- Check for hard constraints — material, tooling, precedence, certification — that could override priority entirely.
- Check for manual overrides or priority flags set upstream, often at the ERP or order-entry stage, that nobody on the floor knows exist.
- Only after all that, consider whether the logic itself is misbehaving.
The honest reality is that step five is rare. Scheduling engines are mature, well-tested software; they don’t typically produce nondeterministic garbage. What they do produce is a defensible answer to a question you didn’t realize you’d asked, because a constraint or weighting was set months ago by someone who’s since moved to another role. As plants layer more autonomous, AI-assisted dispatch on top of these engines, that transparency gap is the thing to push vendors on — not “trust the algorithm,” but “show me the constraint and priority stack that produced this sequence, in terms I can audit.” A scheduling engine you can’t interrogate isn’t intelligent. It’s just opaque.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
