Schedule Optimizer Mistakes Planners Make

Most disappointing optimizer sessions in EDGEBIC by User Solutions come from four habits: expecting improvement every time, fighting the safety features, optimizing against bad master data, and judging a proposal by the one row that got worse. None of them are software problems, and all of them are quick to fix once named.

For the workflow, see how to run and read an optimization. For the guarantees behind the behaviors described here, see locked jobs and the never-worse guarantee.

Mistake 1: Treating No Improvement as a Failure

Symptom: the verdict says your current plan is still the best, and somebody files a support ticket.

That is a real answer, and usually a good one. The optimizer built complete alternative schedules, measured every one under your goal, and none beat the plan you already have. Your plan survived a serious challenge, which is worth knowing on a Monday morning.

The verdict often adds the nearest challenger and how far short it fell, which is the useful part: a challenger that missed by 0.2 hours tells you the plan is on a plateau, while one that missed by six hours tells you your plan is comfortably ahead.

Fix: read it as a confirmation. If you want a harder search, extend the time budget or try a different goal. Why the optimizer returned the same schedule covers the three underlying causes in detail.

Mistake 2: Fighting Locked Jobs

Symptom: the mathematical solver reports that jobs were locked, or that there is nothing to optimize at all, and the reaction is to look for a setting that turns locking off.

There is no such setting, deliberately. A job whose routing uses a capability the solver does not model natively, such as multi-instance machines, parallel processing, lot streaming, transit days, alternate work centers, machine pools, or an operator skill requirement, is reproduced exactly as the standard scheduler planned it. Its rows still consume capacity, so the optimizable jobs schedule around it.

An optimizer that rearranged work subject to a constraint it cannot see would produce plans that score better and fail on the floor. Locking is the feature that prevents that.

Fix: open Explain for the per-job reasons, then decide. If most jobs are locked, switch to the multi-run search in Options: it reorders whole jobs through the real scheduling engine, so every routing feature is honored and nothing needs locking. Locks also shrink over time as solver coverage grows, without you changing any configuration.

Mistake 3: Optimizing Bad Master Data

Symptom: the proposal looks great, the floor disagrees.

An optimizer arranges the work you described. If a routing says four hours and the operation takes eleven, optimization produces a confidently wrong plan with a better score than the previous confidently wrong plan. The arithmetic is honest and the inputs are not.

Fix: fix the data first. Routings with wrong hours, missing setup times, work centers with no shifts, and steps sequenced incorrectly all show up in EDGEBIC's diagnostic surfaces before they show up as missed ship dates. The troubleshooting guide covers the common shapes, and work center overloaded causes and fixes covers the most frequent one.

Mistake 4: Judging the Proposal by One Row

Symptom: the KPI table shows makespan getting slightly worse, and the proposal is rejected on that basis.

Goals are ordered lists of measures, so a proposal can lose a lower-ranked measure to win the one you asked for. Under On-time first, a slightly longer overall plan is an entirely acceptable price for one more job finishing by its due date, because due dates outrank makespan in that preset.

Fix: read the top rows first, since those are the measures your goal actually optimized. If the trade genuinely offends you, that tells you something about your goal choice rather than about the proposal: discard, switch to Fastest overall finish, and run again. Optimizer goals and presets lists what each preset ranks.

Mistake 5: Using On-Time First Mid-Week

Symptom: supervisors complain that the day changed under them after an accepted optimization.

On-time first will happily reorganize a committed day to save a due date. That is correct on Monday morning when the plan is still yours to shape, and disruptive on Wednesday afternoon when the floor has already organized around it.

Fix: run Fewest changes mid-week. It ranks stability first and moves an operation only when the gain clearly justifies the disruption. Then use Explain, then Copy, to send supervisors the same plain-language story that lands in the audit record. Twenty seconds of communication turns a surprise into a briefing.

Mistake 6: Accepting Without Reading the Move List

Symptom: an accepted plan contains a change nobody expected, discovered on the floor.

The move list is deliberately changes only: one row per operation that actually moves, with the job, work center, current start, proposed start, and a short reason. Unmoved operations are never listed, which is precisely what makes it a thirty-second read.

Fix: read it before Accept, every time. Look especially for operations moving later: a job giving way so another can hit its date is the trade a one-job-at-a-time scheduler cannot see, and it is also the change most likely to need a conversation.

Mistake 7: Leaving a Proposal Open Too Long

Symptom: Accept refuses with a banner saying changes arrived while you reviewed.

A proposal is held on your screen, in your session, computed against the picture at solve time. If a colleague reschedules or kiosk actuals land while you read, accepting would overwrite work the optimizer never saw. Rather than do that, EDGEBIC refuses and offers a Re-run on the latest data.

Fix: accept or discard in the same sitting, and press Re-run when the banner appears. It is never a data-loss situation, because nothing was saved. The same applies to closing the application with a proposal open: it drops, safely.

Mistake 8: Expecting Other Users to See the Proposal

Symptom: a planner asks a colleague to "look at the optimization" and the colleague sees nothing.

Proposals never reach the database. Only accepted plans do, which is the whole point of the Accept step.

Fix: use Explain, then Copy, to share the reasoning, or Accept and let the colleague read the accepted plan and the audit record. If two planners are working the same schedule at once, coordinate before Accept rather than after, since the staleness guard will otherwise do it for you.

Mistake 9: Assuming Longer Is Always Better

Symptom: every run is set to 60 seconds out of caution.

A longer budget lets the search evaluate more alternatives, so it can find more. It guarantees nothing extra, and there is one case where it provably adds nothing: with a small number of jobs, the multi-run search evaluates every possible ordering, so once it has tried them all, extra seconds have nothing left to try.

Fix: default to 30 seconds. Reach for 60 on a considered weekly planning run or a large open order book, and drop to 10 for a quick mid-day check.

Mistake 10: Expecting the Optimizer to Move Started Work

Symptom: "why did it not move the operation that is running late?"

Completed and in-progress operations pass through optimization unchanged, exactly as they do through every reschedule. Recorded work is not a suggestion the optimizer may revise.

Fix: none needed, but know where the boundary is. If a running operation genuinely needs to move, that is an actuals correction on the shop-floor side, not an optimization. See actual dates look wrong for that path.

Mistake 11: Running It Once and Forgetting It

Symptom: the optimizer is treated as an implementation-time exercise rather than a weekly habit.

The standard scheduler commits each job completely before it looks at the next one, which leaves reorderings on the table on a regular basis. In the documented worked example, three jobs and one reordering turn one late job into none, with makespan dropping from 22 hours to 18.

Fix: run it after every meaningful scheduling run. It costs seconds, it is guaranteed non-destructive, and the worst outcome is confirmation that your plan already wins.

The Fast Diagnostic Table

For where optimization sits among everything else, start at the complete EDGEBIC guide or the optimizer guide, and see EDGEBIC for the platform itself. If you are still deciding whether optimization is worth the seconds, production schedule optimization is the foundation post.