Dispatch Rule Library & Priority Matrix

Welcome — pick the rule that matches your finish line

Dispatch rules are simple, repeatable heuristics that decide which job to run next when multiple jobs compete for a machine or resource. The right rule depends on what you actually care about: on‑time delivery, throughput, cost, fairness, or lowering WIP. This toolbox helps planners, supervisors, and integrators choose, combine, and safely automate dispatching logic so shopfloor decisions support your operational goals.

Quick decision matrix (business priorities → recommended rules)

• Protect due dates / minimize late deliveries → EDD (Earliest Due Date), Slack Time, CR (Critical Ratio) as a hybrid
• Maximize throughput / keep bottlenecks busy → SPT (Shortest Processing Time) near the constraint; combine with constraint protection rules
• Reduce average lead time / lower WIP → SPT for non-urgent jobs; consider limiting WIP and pull-based buffers
• Minimize labor or setup costs → Batch by family, LPT (Longest Processing Time) for large runs, or setup-aware sequencing
• Balance fairness across customers or orders → FIFO or age-based priorities
• Mixed objectives or complex environments → Weighted scoring or hybrid rules (e.g., score = w1*due_urgency + w2*(1/processing_time) + w3*priority)

Common dispatch rules (what they do and when to use them)

• FIFO (First In, First Out) — Simple and fair when jobs are similar and due dates are not critical. Use when you want predictable order and low cognitive overhead. Trade-off: can miss urgent jobs.
• EDD (Earliest Due Date) — Prioritizes jobs with the closest due date. Good when due‑date performance is the main goal. Trade-off: may increase average lead time and starve long jobs.
• SPT (Shortest Processing Time) — Minimizes average completion time and WIP but can starve long jobs and hurt on‑time for urgent long jobs.
• LPT (Longest Processing Time) — Useful when you want to clear big jobs early (e.g., to reduce changeovers or finish customer batches), but increases average flow time.
• CR (Critical Ratio) — remaining_time / remaining_processing_time; balances due date urgency and work remaining. Useful for mixed environments; requires reliable remaining times.
• Slack Time — due_date - remaining_processing_time; small/negative slack are most urgent. Works well for protecting due dates when processing times are accurate.
• Weighted Scoring / Composite Rules — combine factors (due date, processing time, setup cost, customer priority) into a score to sort the queue. Flexible but needs tuning and transparent weights.

Simple pseudocode patterns you can integrate on the shopfloor

These examples assume a job list with attributes: job.id, due_date, remaining_processing_time, arrival_time, customer_priority, setup_family.

EDD: sort jobs by due_date ascending; dispatch first job.

SPT: sort jobs by remaining_processing_time ascending; dispatch first job.

Critical Ratio (CR): sort jobs by (due_date - now) / remaining_processing_time ascending; dispatch smallest value.

Composite score (example): for each job compute score = w_due*(1 / days_until_due) + w_pt*(1 / remaining_processing_time) + w_cust*customer_priority; sort by score descending.

Automation patterns and guardrails

• Implement the rule in a single, testable service or agent (e.g., a "sequencing microservice") so behavior is centralized and auditable.
• Use tie-breakers: when scores equal, prefer FIFO or smallest setup impact.
• Protect constraints: apply special rules near bottlenecks (e.g., reserve buffer slots, prioritize jobs that feed the constraint).
• Apply soft overrides: allow operators to flag urgent jobs that bypass the rule with a recorded reason and automatic follow-up audit.
• Rate-limit automation changes: deploy new rules in one cell or shift first, run A/B comparisons, then roll out.

What data you need and common pitfalls

• Accurate processing times and remaining times are essential. If times are garbage, rules like SPT or CR will misfire.
• Master data (customer priorities, setup families, due dates) must be maintained and versioned.
• Watch for starvation: long jobs may be perpetually deferred. Add starvation protection (e.g., maximum wait time before priority boost).
• Be cautious with blind automation: dispatch rules simplify decisions but don't fix upstream planning problems. Use them to stabilize, not to paper over capacity shortfalls.

Measure, experiment, and iterate

Don't assume one rule will solve everything. Run short experiments and measure the impact on a few KPIs:

• On-time delivery % (OTD)
• Average lead time and percentile lead times (e.g., 95th)
• WIP level and WIP variance
• Throughput at constrained resources
• Number of changeovers and average batch sizes

Suggested experiment approach: pick two comparable cells or shifts, run the baseline rule for two weeks, switch the experimental rule for two weeks, compare KPIs, inspect root causes for unexpected results, and adjust weights or guardrails.

Practical rollout checklist

1. Choose the simplest rule that matches your primary hunger (start with FIFO or EDD).
2. Verify data quality (processing times, due dates, setup families).
3. Implement the rule as a configurable service with logging and tie-breakers.
4. Run a directed pilot in a single area, collect KPIs and operator feedback.
5. Tune weights, add starvation protection and constraint-aware rules as needed.
6. Document the rule, expected behavior, and operator override process.

When to call a deeper fix

If dispatching changes produce only small or transient gains, investigate upstream issues: capacity mismatch, inaccurate routings/times in ERP/MES, excessive setup times, or chronic scrap/rework. Dispatch rules help execution; they don't replace planning or investments in capacity and data quality.

Use this library as a starting point. Prefer simple, auditable rules and iterate with short experiments so your sequencing logic becomes a living tool that matches your shopfloor reality.