Dispatching & Sequencing Rules Library

Purpose

This library turns schedule intent into consistent shopfloor decisions that protect delivery and throughput. Use it to pick a simple, defensible dispatching rule for a line or cell, understand the trade-offs, and apply basic automation or visual patterns so decisions don't vary shift-to-shift.

Quick orientation

Dispatching rules decide which job to run next when multiple jobs wait at the same workstation. A good rule fits the operation's biggest risk: protecting a bottleneck, meeting due dates, reducing work-in-progress (WIP), minimizing lead time, or prioritizing high-value customers. Simple, consistent rules usually outperform ad-hoc choices.

Common rules — what they are, when they help, and trade-offs

Decision guidance — choosing a rule

Match the rule to your dominant hunger. If delivery precision matters most, prefer EDD or customer-priority. If average lead time and throughput matter, consider SPT or constraint protection. When in doubt, pick a simple rule and make experimentation easy so you can measure impact.

Suggested starting heuristics

• When a single machine or cell limits throughput: implement constraint-first protection plus a small buffer upstream.
• When due dates are rigid and many jobs are late: use EDD, but add limits so very long jobs cannot always jump the queue.
• When product mix is high and jobs are short: try SPT to lower average lead time, while reserving an expedite bucket for high-value jobs.
• When variability is low and fairness matters: FIFO is often the best practical rule.

Rule combinations and simple patterns

• Class-based dispatching: group jobs into classes (e.g., HOT, NORMAL, LOW) and apply a different rule inside each class (EDD inside HOT, FIFO for NORMAL).
• Protective buffers: define a buffer in front of the constraint and always prioritize jobs that will feed the buffer.
• Dynamic hybrid: use EDD for the next n hours' horizon, then SPT for lower-priority work.

Practical implementation checklist

• Pick one rule per line/cell and document it in the standard work.
• Define a clear policy for critical-job qualification and approval.
• Implement visible signals (tags, colored kanban cards, digital priority flags) so operators see priority without guessing.
• Keep job processing time estimates reasonably accurate; poor estimates make SPT and constraint rules fail.
• Run a short experiment (one shift or a few production runs) and track simple KPIs before changing rules broadly.

Metrics to monitor

• Throughput / completed units per period
• Average lead time and flow time
• WIP at critical points
• On-time delivery (OTIF) and number of late jobs
• Queue lengths at the bottleneck

Simple automation patterns

These patterns are implementable in an MES, digital board, or even by color-coded kanban cards:

• Priority flag: add a priority field on the dispatch list and sort by rule (e.g., EDD then SPT).
• Constraint buffer tracker: show buffer fill level and automatically raise priority for jobs feeding the buffer when low.
• Expedite gate: require manager approval to mark a job as HOT; limit active HOTs to a fixed count.
• Class-based queues: separate physical or digital queues for HOT and NORMAL work to avoid overtaking confusion.

Examples

Common mistakes to avoid

• Mixing many implicit rules across shifts — standardize and document a single approach per area.
• Overusing expedites — they should be rare and gated.
• Relying on inaccurate processing time estimates when using SPT or constraint protection.
• Changing rules without measuring impact — run small experiments and track KPIs.

Next practical steps

• Choose a candidate rule that matches your dominant pain (delivery, throughput, lead time, or customer priority).
• Document the rule, training notes, and expedite policy in standard work.
• Run a time-boxed experiment, capture the KPIs listed above, and adjust the rule, or introduce a simple hybrid if needed.

If you'd like, this reference can be paired with an interactive dispatcher-configurator that captures your line constraints, prioritization goals, and experiments so teams can trial rules and store results.