What Is Multi-Run Optimization in Scheduling?

Multi-run optimization re-runs the real scheduling engine many times with different orderings of the job queue, measures each complete resulting schedule against the goal you selected, and returns the best one it found. In EDGEBIC by User Solutions this is the default optimizer engine, and its defining property is that every candidate it considers is a genuine schedule built by the same engine that builds your normal plan, so no candidate can ever break a constraint the scheduler itself would have respected.

This entry is part of the EDGEBIC glossary series; for the broader vocabulary of production planning, see the manufacturing glossary.

How Multi-Run Optimization Works

To see why searching over job order is worth doing at all, you need the shape of the underlying scheduler. It is greedy: it works through jobs one at a time, most important first, and each job claims capacity as it is planned. That is fast, and it always respects every constraint, but it commits each job completely before looking at the next. The consequence is that the queue order silently decides who gets the good hours.

Multi-run turns that weakness into a search space. The procedure is:

1. Take the current plan as the baseline and measure it under the chosen goal.
2. Generate a different ordering of the job queue.
3. Run the real scheduler on that ordering, producing a complete schedule.
4. Measure the result under the same goal.
5. Repeat until the time budget runs out.
6. Return the best candidate found, provided it beats the baseline.

Two things about this deserve emphasis. Because step three is the genuine engine, a candidate cannot violate capacity, a calendar, a routing dependency, a setup rule, or the immutability of recorded work. There is no separate model to keep in step with the scheduler, and therefore no possibility of the two disagreeing. And because step six compares against the baseline, a search that finds nothing better returns your existing plan rather than a mediocre alternative.

What it does not do is claim proof. Multi-run tried a finite number of orderings inside a finite budget. A better ordering may exist that it never generated. The badge says exactly that and nothing more.

A Worked Example

From the documentation's sample plant, Monday July 20, with Day Shift running 08:00 to 16:00 and one machine each on Saw-1 and CNC-Mill-1. Three jobs each run saw then mill:

Scheduled in priority order, the six-hour saw job goes first and occupies the saw until 14:00. The two jobs actually due on Wednesday queue behind it, their mill work slides, and one of them finishes late.

The optimizer runs on the on-time-first goal. It tries orderings, including due-date order, which puts the two Wednesday jobs on the saw first and the Friday job last. Measured against the goal, that candidate shows late jobs going from one to zero and a shorter makespan. The badge reads that this was the best of the complete schedules tried within the budget, and the Explain dialog names the winning ordering, in this case earliest due date first.

Nothing about how any individual job is placed changed. The saw still runs at eight hours a day, the mill still splits work across Monday and Tuesday, and every dependency still holds. Only the order in which the three jobs went shopping for capacity changed, and that was enough.

How EDGEBIC Uses Multi-Run Optimization

A few product specifics:

• It is the default engine. The alternative, a mathematical solver, is selected in the scheduling options and changes the badge language rather than the screen. Both produce a proposal you accept or discard.
• Its badge is honest by design. Best of a number tried is a search claim, not a proof claim. The solver's badge, proven within a percentage of optimal, is the stronger statement, and the product never presents multi-run results as optimal.
• The never-worse guarantee applies to it. A candidate is only offered if it measurably beats your current plan under the goal you asked for; otherwise your plan stands and the optimizer says so.
• A longer budget means more candidates. Budgets of ten, thirty, or sixty seconds are offered, with thirty as the default, and a longer budget simply lets more orderings be tried.
• It inherits every scheduler capability. Because candidates come from the real engine, no routing feature is off limits and no job needs to be held aside.
• Nothing is saved until Accept. The result is an optimizer proposal held on screen, and canceling a run changes nothing at all.

The useful mental model is that multi-run does not schedule better than your scheduler; it schedules the same way many times and picks the winner. That framing keeps expectations right and explains both its strength, total constraint fidelity, and its limit, no proof of optimality. See greedy scheduling in manufacturing for the underlying method, a warm start in production scheduling for how the baseline enters the search, and how the multi-run optimizer searches schedules for a closer look at the orderings it tries.