Dispatching in Manufacturing: Rules, OEE & Reality

What dispatching actually is

Dispatching is the operative release, prioritisation and assignment of production orders to machines, lines and workstations on the shopfloor. The planning layer — APS, ERP, fine-scheduling — defines what should happen on each resource and when. Dispatching decides what does happen next, given current machine states, current material availability, current personnel, current OEE, and current disruptions. It is the layer where the plan meets the factory, and it is the layer where most of the difference between good and mediocre production performance is actually made.

The quiet reality that most buyer conversations avoid: dispatching is also the layer at which OEE gets quietly gamed. Long batch runs with few changeovers produce visibly better availability and performance numbers than short mixed-product runs with frequent setups — same machines, same people, same material, measurably different headline KPIs, and often materially worse delivery performance. The rule choice itself is where the metric-gaming happens. Not in the measurement; in the dispatching logic that produces the measured reality. This is the most important practical thing to understand about dispatching, and it is almost never in the glossaries.

Dispatching vs. scheduling vs. sequencing vs. APS — four words for four distinct things

The vocabulary in this space is used loosely in buyer conversations. Clarifying it matters because the four functions sit on different layers of the manufacturing stack, are owned by different roles, and fail in different ways.

The practical consequence of getting this distinction wrong: buyers arrive at evaluation assuming they need an APS when what they actually need is better dispatching logic on top of the plan they already have, or vice versa. The planner has already generated an optimised schedule; the shopfloor then dispatches work in a completely different order because the schedule did not account for the 07:15 material shortage, and the schedule quietly stops being used. That is not a planning failure; it is a dispatching gap.

The dispatching rules — and when each one breaks

The standard dispatching rules are all well-documented. What buyer-facing content rarely provides is an honest evaluation of when each rule works well and where each one produces worse outcomes than the alternatives. This is the question every MES evaluation should ask, and it is the question the vendor pitch rarely answers.

The operational consequence: no single rule is correct. Working dispatching in a real plant is almost always a weighted combination — for example, EDD as the primary rule, with changeover optimisation as a tiebreaker inside same-due-date windows, plus an explicit rush-order override lane. The vendor pitch that a single rule will solve dispatching is a pitch to be sceptical of.

Observation from global MES rollouts across seven countries: between 2006 and 2018 I rolled out dispatching logic at Johnson Controls and Visteon in plants in China, Mexico, the US, Tunisia, Macedonia, France and Russia. Different machines, different workforces, different languages, different customers. The same dispatching pathology re-emerged in all seven. When a plant comes under OEE pressure from corporate — and every plant does, sooner or later — the local response is almost identical everywhere: lengthen batch runs, reduce changeover frequency, push the same product through for longer stretches. The OEE numbers improve visibly within a month. Availability goes up because changeover time falls. Performance goes up because steady-state running is easier than ramp-up. Quality often goes up too because operators aren't re-learning the process every four hours. The reporting looks excellent. What also happens, quietly, and with a lag of one to three months: delivery performance drops. Short runs of smaller customer orders get pushed behind long runs of large customer orders. On-time-in-full deteriorates. Finished-goods inventory of the long-run products climbs. Customer complaints start. By the time the corporate finance team connects the OEE improvement to the delivery deterioration, a year has passed and the plant is in a measurable worse commercial position than when the OEE push started. I wrote a book about the broader version of this — OEE can be improved in ways that make the underlying operation worse, and the dispatching-rule choice is where the gaming quietly lives. The fix is almost never to abandon OEE or to abandon dispatching automation. The fix is to measure delivery performance and OEE together, enforce a dispatching rule set that weights both, and make the weighting visible at the plant-manager level. When both KPIs sit next to each other on the same daily dashboard, the gaming disappears within a quarter because it becomes immediately visible to the level above the plant.

How modern dispatching actually runs in an MES

Rule-based dispatching in a modern MES is a continuously recalculating queue per resource. The inputs are live: current machine state, current OEE trend, current WIP, material availability signalled from the ERP or WMS, personnel availability from shift data, rush-order flags. The outputs are a priority-ordered list of orders per resource, refreshed in seconds. When a machine drops offline, the queue of orders routed to that machine is automatically reconsidered — either redistributed to alternative resources, or held, depending on rule configuration. When a rush order arrives, the priority logic inserts it into the queue according to its configured override class.

In multi-plant architectures, the dispatching rule set is defined centrally and applied locally. That matters because it is the mechanism by which the seven-country pathology I described above is actually prevented: when every plant in a global network uses the same dispatching rule set, and that rule set weights delivery performance alongside OEE, the local incentive to game OEE by running long batches simply does not have an operational path forward. The rule enforces the policy. This is the single strongest argument for platform-level dispatching over plant-level local optimisation, and it is the reason enterprise MES rollouts often fail when dispatching is left as a plant-by-plant configuration.

When rule-based dispatching is the wrong answer

Honest cases where automated rule-based dispatching produces worse outcomes than supervisor judgement, at least in the exception handling:

• Rush orders with political weight. A rush order from the plant's largest customer, arriving at 07:45 on a Monday, does not get handled well by pure rule logic. Every rule will either override all other priorities (pathologically, starving everything else) or will apply a rush-order multiplier that may or may not be sufficient. The honest answer in most plants is a supervisor judgement call, with the MES recording the override.
• Multi-constraint exception situations. A machine goes down, two operators are off sick, a material delivery is three hours late, and a rush order is on the queue. No rule set handles this combination well. Human judgement is genuinely better.
• First week of a new product ramp-up. The processing-time estimates are wrong by definition, which breaks every rule that relies on them (Critical Ratio, Slack, SPT). Running rule-based dispatching on bad data produces worse outcomes than a supervisor sequencing by eye.
• Low-volume, high-mix, project-style operations. The overhead of configuring and maintaining the rule set can exceed the value it produces. Manual dispatching with an MES as audit trail, rather than as rule engine, is often the better compromise here.
• When dispatching rules conflict politically. Sales wants EDD; operations wants changeover optimisation; finance wants SPT to reduce WIP. If this conflict is not resolved at the policy level before the rule set is configured, rule-based dispatching becomes a daily argument in a new form. The rule engine surfaces the conflict; it does not resolve it.

How this fits into the SYMESTIC platform

SYMESTIC implements dispatching as part of the production control module. Rule configuration is policy-level — EDD, SPT, changeover-optimised, critical ratio, bottleneck-first, or weighted combinations of these — applied at the resource or plant level. The dispatching engine consumes live machine state from OPC UA and IoT-gateway feeds, live OEE from the production metrics module, order and material context from bidirectional ERP integration (SAP R/3 via ABAP IDoc, Microsoft Dynamics/Navision, Infor/InforCOM, proAlpha), and rush-order overrides from either MES user interaction or ERP signals. The rule set is defined centrally for multi-plant deployments and applied locally without site-level reinterpretation — which is the mechanism by which platform-level dispatching prevents the local-OEE-gaming pathology I described above.

Over 15,000 connected machines in 18 countries currently run on this dispatching foundation, including in customer environments where I have personally seen the gaming pattern that prompted my 2025 book "OEE: Eine Zahl, viele Lügen". The practical argument the book makes, translated into dispatching terms: a lower OEE number measured against a rule set that weights delivery performance honestly is worth more than a higher OEE number produced by a rule set that optimises for metric appearance. Most of the commercial value in production comes from getting the rule set right, not from getting the OEE number high.

FAQ

What is the difference between dispatching and scheduling?
Scheduling (typically handled by APS or ERP) creates the forward-looking plan: which orders run on which resources, in what order, over days to weeks. Dispatching implements this plan in the immediate moment and continuously adjusts it to live conditions — machine state, material availability, rush orders, disruptions. Scheduling is planning-oriented; dispatching is execution-oriented. In practice, dispatching is the layer that decides whether the schedule actually gets followed or quietly discarded.

Can dispatching be fully automated?
Partially, and the partial answer is the honest one. Rule-based dispatching according to defined priority logic (EDD, SPT, critical ratio, changeover-optimised, weighted combinations) can run automatically for the steady-state majority of orders. For the exception situations — rush orders with political weight, multi-constraint failures, new product ramp-ups, first-week-of-the-month quarter-end pushes — supervisor judgement remains genuinely better than any rule set. A working MES combines rule-based automation for the 80% with a clean override mechanism for the 20%, and records the override as data.

Which dispatching rule is best?
There is no universally best rule. EDD (Earliest Due Date) is a defensible default for most delivery-performance-critical environments. Changeover-optimised is better for setup-dominated operations like injection moulding or paint lines. Critical Ratio is better where processing-time estimates are reliable. Most real plants run a weighted combination — for example EDD as primary, changeover optimisation as a same-due-date tiebreaker, with an explicit rush-order override lane. The vendor pitch that a single rule solves dispatching should be treated with caution.

How does dispatching quietly game OEE?
Long batch runs with few changeovers produce visibly better availability and performance numbers than short mixed-product runs with frequent setups — same machines, same people, same material, measurably different headline KPIs. A dispatching rule set that optimises purely for changeover reduction will improve the reported OEE within a month. What it quietly does, with a one-to-three-month lag, is degrade delivery performance, increase finished-goods inventory of long-run products, and shift customer orders out of the on-time-in-full window. The rule choice itself is where the gaming happens. The fix is to measure delivery performance and OEE on the same dashboard at plant-manager level, so that the trade-off becomes visible one level above the plant.

How is dispatching related to Lean production?
Dispatching is where Lean principles become enforceable at execution level. Small controlled WIP buffers, pull signals, clear priority at the bottleneck, stable cycle times despite disruptions — these Lean ambitions depend on a dispatching layer that actually releases work according to the Lean rule set rather than according to whatever the supervisor happens to see on the floor. Without MES-level dispatching, Lean tends to work on the line where the champion is personally present and degrade everywhere else. See MES: definition, functions & benefits for the broader context.

What is the relationship between dispatching and bottleneck management?
Bottleneck-first dispatching (drawn from Theory of Constraints) is one of the legitimate rule choices, particularly in environments where the bottleneck is stable and clearly identifiable. The subtlety is that in most real plants the bottleneck shifts — between lines, between shifts, between product mixes. A dispatching rule that treats yesterday's bottleneck as today's bottleneck will produce poor outcomes. Working TOC-based dispatching requires continuous bottleneck identification, which in turn requires live OEE data per resource. See OEE: definition, calculation & practice for the measurement question.

What is the single most common dispatching mistake in multi-plant rollouts?
Allowing each plant to define its own dispatching rule set. The local incentive, under OEE pressure from corporate, is almost always to drift the rule set toward changeover minimisation — because that is what most visibly improves the headline KPI. Within a year, each plant in a multi-site network is running a slightly different rule set, delivery performance diverges across the network, and cross-plant load balancing becomes impossible because the plants are no longer comparable. The fix is centralised rule policy with local execution, enforced at the platform level. This is one of the strongest operational arguments for a single-platform MES over a federation of plant-level tools.

How does SYMESTIC handle the rule-vs-override balance?
Rule-based dispatching runs continuously on the configured rule set. Supervisors have explicit override authority at the workstation level, and every override is recorded as structured data — who, when, which order, against which rule. That structured override log is itself valuable, because the pattern of overrides over time tells you where the rule set is systematically wrong and needs to be re-tuned. A plant where the overrides drop toward zero over a quarter is a plant where the rule set has converged on the operational reality. A plant where the override rate stays high is a plant where the rule set does not match how the plant actually needs to run — and that is useful information, not a failure.

Related: MES: Definition, functions & benefits · OEE: Definition, calculation & practice · MES software compared · OEE software · Cloud MES vs. on-premise · AI in manufacturing and MES · Production metrics module · Process data module · Alarms module · Production control module · Production planning module · Automotive · Metal processing · Food & beverage · Plastics processing · For COOs & plant managers · For operational excellence · For production managers.

About the author

Christian Fieg

Head of Sales at SYMESTIC. Over 25 years in manufacturing. Six Sigma Black Belt. Career path: Johnson Controls Automotive (1998–2013) as maintenance engineer, Six Sigma Black Belt in headliner production, PLC engineer in the JIT Center of Excellence, Expatriate in Changchun (China) 2006, then Team Leader Business Analyst for global MES and traceability with responsibility for 900+ connected machines, 750+ users and 30+ manufacturing processes across plants in China, Mexico, the US, Tunisia, Macedonia, France and Russia. Visteon Corporation (2013–2015) as Manager Center of Excellence with end-to-end responsibility for the global MES programme. iTAC Software AG (2015–2018) as Sales Manager MES for DACH. Dürr AG (2018–2021) as Senior Sales Manager. SYMESTIC since 2021. Author of the 2025 book "OEE: Eine Zahl, viele Lügen" on why an honest low OEE is worth more than a gamed high one. Expertise: Manufacturing Execution Systems (MES), OEE, shopfloor digitalisation, Six Sigma (Black Belt), traceability, smart factory, production data capture, PLC programming, JIT/JIS processes, automotive production, global MES rollouts, cloud MES. · LinkedIn