Dispatching Rules Library (Practical Dispatch Heuristics)

What this library is for

Dispatching rules are simple, local heuristics that tell a machine, operator, or cell which job to run next. They don't replace good planning, capacity fixes, or accurate master data, but when chosen and combined carefully they reduce firefighting, protect bottlenecks, and make schedule intent repeatable on the shopfloor.

This reference gives a concise explanation of common rules, practical pros and cons, example situations, tuning tips, and a short pilot test you can run on a line or cell to see whether a rule helps your outcomes.

How to use this library

1. Identify the primary delivery hunger (throughput, on‑time %, lead time reduction, fewer changeovers, or protecting a bottleneck).
2. Pick one or two candidate rules that align to that hunger.
3. Run a short pilot using the Pilot Test in each rule section and measure the same metrics before and during the pilot.
4. Combine rules if needed (see combination patterns below) and iterate.

Quick decision guide

• If delivery dates matter most: EDD or Slack (least slack).
• If throughput and average lead time matter: SPT or SRPT (shortest remaining processing time).
• If changeovers are the dominant cost: Sequence by family or use lot‑based batching, not pure SPT.
• If you must protect a known constraint: Give constraint operations special priority (Drum‑Buffer‑Rope, or constrained‑first + local rule elsewhere).
• If you want fairness / stability: FIFO is simple and transparent; it reduces perception of unfairness.

Rules (description, pros/cons, example, tuning & pilot)

FIFO — First In, First Out

Description: Process jobs in the order they arrive at the workstation (or by start time in the queue).

Helps when: the shop values fairness and simplicity, jobs have similar processing times, and changeovers are low-cost.

Harms when: job sizes vary widely or some orders are urgent — long jobs can block many small urgent jobs and raise average lead time.

Example: A cell processing identical small parts where every job is roughly the same length and due dates are not tight.

Tuning tips: Use FIFO within families to reduce changeovers. Apply exceptions for a small emergency job class or at the constraint.

Pilot test: Run FIFO on one line for 2 weeks. Measure average lead time, on‑time %, WIP and number of changeovers per shift. Compare to the same metrics during the prior 2 weeks.

EDD — Earliest Due Date

Description: Prioritize the job with the nearest due date.

Helps when: on‑time delivery is the main priority and due dates are realistic and accurate.

Harms when: long jobs with near due dates monopolize capacity, increasing average lead time and possibly lowering throughput.

Example: Make‑to‑order lines where customer due dates drive penalties and customer satisfaction.

Tuning tips: Combine EDD with a short job cut‑off (e.g., if job processing time > X hours consider splitting or using a different queue). Protect the constraint by applying EDD only at upstream workstations where it improves flow into the bottleneck.

Pilot test: Apply EDD for all jobs on a cell for one production rotation. Track on‑time %, mean tardiness, and average lead time against a comparable baseline shift.

SPT — Shortest Processing Time

Description: Always process the job that requires the least time on the current operation.

Helps when: minimizing average lead time and increasing throughput for a mixed batch of short and long jobs.

Harms when: it continually delays long jobs (starvation), which may be critical; increases changeovers if job families aren’t considered.

Example: A high‑mix grinding cell where many short rework jobs compete with longer new‑build runs.

Tuning tips: Protect long but urgent jobs with a maximum wait time rule (if postponed longer than T, bump priority). Combine SPT with family grouping to reduce changeovers.

Pilot test: Run SPT on a single non‑bottleneck machine for 1–2 weeks. Compare average lead time and changeover frequency to baseline.

LPT — Longest Processing Time

Description: Prioritize the longest jobs first.

Helps when: you want to reduce the number of in‑process long jobs consuming capacity later (can be useful upstream of a bottleneck to ensure long work is started early).

Harms when: short urgent jobs pile up and average lead time for small jobs increases.

Example: Upstream operations feeding a single critical bottleneck where long jobs must be in flight to keep the bottleneck busy.

Tuning tips: Use LPT selectively, typically upstream of constraints or when changeovers favor longer runs.

Pilot test: Apply upstream of the identified constraint for a defined window and measure constraint utilization and downstream queue size.

Slack / Least Laxity

Description: Prioritize by least slack (due date minus remaining processing time). Also called Least Laxity First.

Helps when: meeting due dates across mixed jobs is critical and remaining processing times are known.

Harms when: if remaining processing time estimates are poor, the rule misprioritizes; it can also spike setup frequency if combined with high family mix.

Example: Job shop with firm customer dates and reliable routing time estimates.

Tuning tips: Improve remaining processing time estimates (historical median by family). Consider a slack threshold to avoid frequent priority flips.

Pilot test: Use Slack for a subset of jobs flagged as due‑date sensitive and monitor on‑time % and priority flips (how often priorities change while waiting).

Critical Ratio (CR)

Description: Ratio of time until due date to remaining processing time (time remaining / work time remaining). Prioritize smallest CR.

Helps when: you need a simple normalized measure across large variation in job size.

Harms when: can favor very small jobs near due date or starve large jobs without special safeguards.

Tuning tips: Cap extreme CR values and combine with family grouping. Recompute frequently for dynamic environments.

Pilot test: Apply CR at a dispatching point where due dates are trusted and compare metrics to EDD and Slack for a week each.

SRPT — Shortest Remaining Processing Time

Description: Like SPT but considers remaining work (useful when jobs can be preempted or resumed later).

Helps when: you can preempt work, and you want to minimize average completion time.

Harms when: preemption overheads (setups, tooling) make switching expensive; it can cause starvation for long jobs.

Pilot test: Use SRPT where operations are easily pausable (e.g., inspection tasks, software steps) and measure average completion time and extra setup occurrences.

Family / Changeover‑aware sequencing

Description: Sequence batches by product family, tooling, or setup similarity to minimize changeover time.

Helps when: setups are costly or long and changeovers drive effective capacity loss.

Harms when: it may delay high‑priority single orders if overused without exceptions.

Tuning tips: Define families pragmatically (tools, fixtures, same fixtures) and allow urgent job exceptions with quantified cost tradeoffs.

Pilot test: Introduce family sequencing on one shift and track changeover minutes, throughput, and delivery impact.

Protect the Constraint (TOC / Drum‑Buffer‑Rope)

Description: Explicitly prioritize work that keeps the bottleneck fed and reduce variability feeding it. Use a rope to release upstream jobs to match constraint capacity.

Helps when: a clear, sustained bottleneck determines plant throughput.

Harms when: there is no dominant constraint or it shifts frequently; over‑controlling releases can starve downstream flexibility.

Pilot test: Implement a simple rope (limit WIP upstream of the constraint) and measure throughput, constraint uptime, and downstream queues.

Combining rules and simple automation patterns

• Hierarchical rule: Apply a protective rule at the constraint (e.g., constraint‑first or EDD at the constraint) and a different local rule elsewhere (SPT or FIFO).
• Priority matrix: Define job classes (urgent, normal, family‑run, do‑not‑preempt) and map rules per class—e.g., Urgent use Slack, Normal use SPT within family.
• Time windows: Use SPT most of the day but reserve a periodic EDD sweep to clear near‑due orders.
• Exception rules: Always allow a small emergency queue that can preempt the local rule with documented guardrails and cost tracking.

Pilot test template (practical, repeatable)

Run a controlled pilot so you measure effect before standardizing a rule.

1. Define scope: line/cell/machine, shifts, and product families.
2. Establish baseline: collect 1–2 weeks of metrics under current rule (or two equivalent shifts): throughput (units/hour), average lead time, on‑time %, WIP, number of changeovers, and average setup minutes.
3. Implement the candidate rule with clear operator instructions and a short training huddle.
4. Run pilot for the same duration and comparable demand mix.
5. Analyze results: compare the same metrics, look for unintended effects (priority flips, starvation, increased setups), and gather operator feedback.
6. Decide: adopt, adapt (tune thresholds), combine with another rule, or rollback.

Common mistakes to avoid

• Changing rules broadly without a defined pilot and measurement plan.
• Ignoring changeover impact when using SPT or SRPT in high‑mix environments.
• Applying date‑based rules (EDD/Slack) when due dates are unreliable.
• Not protecting the true constraint—local optimization can starve the plant bottleneck.
• Failing to capture operator feedback; some rules increase cognitive load and error risk.

Next steps and capability opportunities

Start with one targeted pilot and consistent measurement. If pilots show promise, consider packaging the rule plus a small interactive pilot form so operators and planners can record outcomes, exceptions, and comments.

Potential future enhancements: an interactive dispatching experiment form (collect pilot data and operator observations), integration with MES to automate chosen heuristics at the machine level, and simple simulation runs to compare rules under expected mixes.

Image

Suggested image search phrase: dispatching rules cheat sheet