What the Optimizer Does Not Change

The optimizer changes one thing: the order jobs are taken, and therefore when their operations start. Routings, quantities, due dates, work center capacity, shift calendars, holidays, and every hour of recorded work are inputs it reads and never rewrites. That narrow scope is what makes it safe to run on a live plan and what makes its results trustworthy: every proposal is a complete schedule built by the same engine that produces your normal plans, under the same constraints.

EDGEBIC by User Solutions built the optimizer as a sidecar beside the scheduling engine rather than a replacement for it, and the list of things it will not touch is as much a feature as the list of things it will. This post covers the boundary, why it sits where it does, and what to do when the answer you need lies on the other side of it.

The one lever

The scheduling engine takes jobs in order and commits each job's routing completely before moving to the next. The optimizer's only intervention is to supply a different order and let the engine build the plan again. Nothing else about the engine changes.

That means each candidate the optimizer scores is a real schedule, not an estimate or a model approximation. Capacity handling, shift boundaries, queue times, calendars, and every routing rule apply exactly as they do on a normal run. Constraint compliance is total by construction, because the same code did the work. See why the optimizer is a sidecar not a replacement.

The list of things it will not touch

Two of these deserve more than a table row.

Recorded work is never moved

Completed and in-progress steps pass through an optimizer run unchanged, exactly as they do through any reschedule. This is not a special optimizer behavior, it is the same actuals preservation machinery the rest of the product uses, which is why the promise can be stated flatly rather than hedged.

You can see it on screen twice. The safety strip under every result states that completed work is untouched. And the move list, which shows only operations that actually changed, never contains a recorded step. If your in-progress morning work is absent from the changes list, it did not change, which it never would. See how the optimizer preserves completed and started work.

Due dates stay where you put them

A softer point that trips people up: the optimizer treats due dates as targets to hit, not as constraints it can relax or as values it can adjust. In the solver's model a due date is a dominant penalty rather than a hard wall, which sounds like flexibility but is the opposite of moving the date. It means the model will accept a late plan and score it badly rather than declaring the whole problem impossible. Your date is unchanged and the lateness is reported honestly. See why the optimizer treats due dates as soft targets.

Jobs the solver reproduces rather than rearranges

There is a further category of things that do not change, specific to the mathematical solver engine. A job whose routing uses a capability the solver does not yet rearrange natively is reproduced exactly as the scheduling engine planned it: same machines, same times, consuming the same capacity, with other jobs optimized around it.

The triggers are named per job in the Explain dialog, and include multi-instance work centers, one-per-day work centers, transit days, both forms of lot streaming, parallel processing, and alternate work centers. This is a safety property rather than a limitation to work around: the optimizer never guesses about a feature it does not fully model. If you want those jobs resequenced, the multi-run search reorders whole jobs regardless of the routing features they use. See how the optimizer locks features it does not model.

When the answer lies outside the boundary

The most useful thing about a narrow scope is what a negative result tells you. If the optimizer cannot get a job on time, and the Fastest overall finish goal cannot compress the plan either, sequencing is not your problem. One long chain is setting the plan length, or capacity in the relevant period is genuinely insufficient.

That sends you to a different set of tools in a sensible order: check routing hours and quantity, then work center capacity and instances, then the shift calendar for the period, then whether the constraining work center is the plant's real bottleneck. See production bottleneck identification and finite versus infinite capacity scheduling.

The same logic applies to testing a change. To find out what an extra shift is worth, change the shift configuration, run a normal schedule, then optimize the result. Measuring a capacity change against an unoptimized baseline overstates its value, because part of what the shift appears to buy is really just better sequencing.

Master data quality decides result quality

Because the optimizer takes everything except sequence as given, the quality of your results is capped by the quality of that input. Wrong setup times, an out of date shift calendar, or routing hours nobody has revisited in three years do not get corrected by optimization. They get amplified, because the optimizer will confidently arrange work around numbers that are not true.

That is the honest limit of any scheduling optimizer, and it is worth stating plainly. The check is boring and effective: before you chase a result that looks wrong, confirm the inputs.

The bottom line

The optimizer changes the order jobs are taken and nothing else. Routings, quantities, due dates, capacity, calendars, priorities, and all recorded work are inputs it respects, and every candidate it scores is a complete real schedule built by the same engine as your production plans. When resequencing cannot solve a problem, that is a signal pointing at capacity, routing, or master data rather than a failure of the run. To see the boundary in practice, open the Optimizer tab in Schedule Jobs and compare a proposal's move list against everything it left alone. For more, read the EDGEBIC optimizer guide and how a greedy schedule leaves capacity on the table, and explore the platform at EDGEBIC.