Deciding What Runs First

Sequencing in EDGEBIC by User Solutions happens in three layers, and they are frequently confused: the dispatch order that decides which job enters the plan first, the slot strategy that decides which window an individual operation takes, and the optimizer that proposes an entirely different dispatch order. Knowing which layer you are looking at is most of the skill.

Generic dispatching theory is covered in priority dispatching rules for job shops. This post is about how the three layers behave in practice, in what order, and where each one can and cannot help.

Layer One: The Dispatch Order

Every run sorts the job list before placing anything, using three keys:

1. Priority, ascending. Lower numbers go first.
2. Earliest start date, ascending.
3. Due date, ascending.

That is the whole rule and it is deterministic. The same data produces the same sequence every time, which matters more than it sounds: a plan you cannot reproduce is a plan you cannot debug.

There is one conditional fourth key. When forward netting is active, a leading key places build-to-stock producers ahead of consumers, so a job that builds a stock buffer is placed before a job that might consume that buffer in the same run. Without it, the consumer would net against stock that had not been planned yet.

What priority actually buys you is first pick of capacity. The first job placed sees every machine empty and takes the slots it wants. The second job sees what the first left. There is no reservation, no bidding, no revisiting: the engine places one job completely, then the next.

That has an important consequence. Priority does not promise a finish date. A priority-1 job with a long routing through loaded machines can still finish after a priority-9 job with two short operations on idle equipment. Priority governs the order of claiming, not the outcome.

Editing Priority Without Surprises

Priority is edited inline in the orders grid. The edit is held until you click save, and it triggers no rescheduling by itself. It takes effect on the next run.

Two habits avoid most friction here.

Number in tens. Using 10, 20, 30 rather than 1, 2, 3 means a rush job slots in at 15 without renumbering anything. Renumbering a whole queue to insert one job is how priority schemes decay into everything being priority 1.

Save before you navigate. There is no auto-save on the grid, and leaving the view discards pending edits. The save button highlights when edits are pending, which is the cue.

A related check: the scheduling mode has to actually touch the jobs whose priority you changed. The incremental modes deliberately leave already-scheduled jobs alone. If you reprioritized work that is already on the plan and ran an incremental mode, nothing moved because nothing was supposed to. Scheduling modes explained covers which mode reaches which jobs.

Layer Two: The Slot Strategy

Once a job's turn arrives, each of its operations has to pick a window on its machine. The run's slot strategy decides how.

Two of those interact with features covered elsewhere. Minimize setup only has anything to work with once a sequence-dependent changeover matrix is populated: without it, every changeover looks identical and the strategy has nothing to prefer. Maximize utilization is also what the anchored path switches to automatically while it places a pinned constraint operation, so that operation's window is secured before subordinated work can compete for it.

The distinction from layer one is worth restating. The dispatch order decides which job gets to choose. The slot strategy decides which window it chooses. Changing the strategy without changing the dispatch order produces different placements for the same job order, which is often exactly what a shop needs.

Layer Three: Letting the Optimizer Propose an Order

The dispatch sort is a heuristic. It is a good one and it is predictable, but it commits each job's whole routing before looking at the next job, which is where measurable time gets lost: a long first operation can block a machine while a short job that would have fed the next work center waits.

The multi-run optimizer attacks exactly that. It re-runs the same engine with different global job orderings, scores each resulting complete schedule against the goal you picked, and returns the best. The orderings it tries are the classical dispatching rules plus seeded shuffles:

• Earliest due date, and priority-then-due-date
• Shortest processing time first, and longest first
• Critical ratio, which is remaining time divided by remaining work
• Seeded random permutations up to the candidate cap

For four jobs or fewer it simply tries every permutation. Earliest due date and shortest processing time are long-standing dispatching rules in production planning practice, documented by bodies such as ASCM; the value here is that each candidate ordering is turned into a complete real schedule by the same engine that runs production, so constraint compliance is total by construction.

Two guarantees make this safe to run casually. The result is clamped never worse than the ordinary run under the chosen goal, so a run can only help or return the baseline unchanged. And nothing is written until a planner clicks accept, so the comparison is free. The optimizer guide covers the flow, and optimizer goals and presets covers what each goal optimizes for.

When the optimizer returns the baseline, that is a real answer rather than a failure: it means no candidate ordering it tried beat your existing sequence on the goal you asked for. Why the optimizer returned the same schedule covers the reasons in detail.

How Sequencing Interacts With Direction

Scheduling direction does not change a job's position in the dispatch queue. A backward job and a forward job with the same priority and dates are placed in the same relative order.

What direction changes is how each job claims slots once its turn comes. A backward job searches right-aligned from a deadline instead of left-aligned from an earliest start. An anchored job places its pinned constraint operation first at maximum priority with the capacity-packing strategy, then plans upstream and downstream around it.

The practical read for a mixed plan: an anchored job whose constraint operation is a machine your other jobs also use will claim its constraint window aggressively when its turn comes. If that machine is genuinely the plant constraint, that is correct. Bottleneck scheduling and due-date scheduling in the same plan covers the interaction properly.

Sequencing and Changeover Are Two Decisions

A frequent expectation is that populating a changeover matrix will make the scheduler group like products together. It does not, by default.

The matrix makes the cost of a sequence visible and correct: a plan that runs white, black, white now carries the real four-hour flush rather than a flat thirty minutes on each. That alone changes plans, because an honest plan slips where a dishonest one fitted.

Actively choosing a cheaper sequence is a separate decision, and there are two ways to ask for it: set the run's slot strategy to minimize setup, or run the optimizer with the least-setup goal. The second is a whole-plan search and is usually the more effective of the two, but it only appears in the goal list once changeover data exists, because a goal with no data to optimize would be a lie.

The size of the prize is easy to underestimate. On a three-job paint example from the product documentation, an honest plan under due-date order needs 330 minutes of changeover and overflows an eight-hour shift; the same three jobs sequenced light-before-dark need 90 minutes and finish with three hours to spare. Same work, same machine, same day: one decision.

Where Sequencing Cannot Help

Two situations look like sequencing problems and are not, and recognizing them saves a lot of fruitless reordering.

Uncontested capacity. Reordering only changes outcomes where two jobs want the same window. On a machine with plenty of headroom, every dispatch order produces the same placements, and a priority change that appears to do nothing genuinely did nothing. Before reordering, check whether the machine in question is actually loaded.

A routing that is simply too long. If a job's own operations sum to more elapsed time than the gap between its start and its due date, no queue position rescues it. Sequencing decides who waits behind whom; it cannot compress a routing. The levers there are different ones: overlap between operations, a machine pool so the work can shop for capacity, additional instances, or a higher utilization percentage on a machine that has been deliberately derated.

The practical test is quick. Add up the job's operation durations plus its queue and transit times, compare against the available window, and if the routing does not fit even on an empty plant, stop reordering and start looking at the routing.

An Anti-Pattern and a Better Scheme

The failure mode is everything at priority 1. It removes the top-level lever entirely and pushes every decision onto the tie-breakers, which are earliest start and then due date. Due-date ordering is a defensible default, so nothing catches fire, but you have lost the ability to say that one job matters more than another with identical dates.

A workable scheme looks like this:

The bands matter less than having them at all. Two properties are what you are buying: room to insert without renumbering, and a shared vocabulary so "that is a 15" means something to the next planner.

Reading the Result

After a run, three questions answer most sequencing puzzles.

Did the job get placed in the order I expected? The dispatch keys are priority, earliest start, due date. Check all three, not just priority: two jobs at the same priority order by their earliest start dates, and a start date somebody set months ago will beat a due date you care about today.

Was capacity actually contested? Reordering only changes outcomes where two jobs want the same window. On an unloaded machine, every order produces the same answer, and a priority change that appears to do nothing may simply have had nothing to do.

Did the mode reach the job? Incremental modes leave scheduled work alone by design. If you need a reprioritized queue to actually re-place, a full reschedule is the mode that does it. How to run the scheduler covers the choices, and scheduling run mistakes covers the ones that quietly produce nothing.

For the wider engine behavior, see the scheduling engine guide and the complete guide to EDGEBIC.