EDGEBIC How-To

How to Keep the Optimizer From Moving a Job in EDGEBIC

User Solutions TeamUser Solutions Team
|
7 min read

To keep the optimizer from moving a job in EDGEBIC by User Solutions, run the mathematical solver engine and give the job a constraint the model locks, then confirm it in the Explain dialog. The mechanism lives in how the solver treats jobs it cannot yet optimize natively: any job whose routing carries certain constraints is reproduced exactly as the greedy engine scheduled it, every step pinned, while it still consumes its capacity so other jobs schedule around it. There is no dedicated freeze-this-job button. The deliberate lever is to give the job a locking constraint, and the universal fallback is to Discard any proposal you do not like.

This recipe covers one specific task. For the whole optimizer workflow, read the EDGEBIC optimizer guide and the broader recipe how to run and read an optimization.

Before You Start

  • The mathematical solver engine selected. In Options, under Schedule, set the Optimizer Engine to the mathematical solver rather than the multi-run search. Only the solver applies job-level locks.
  • The job you want held in place, and access to its routing if you plan to add a locking constraint.
  • An understanding that nothing the optimizer proposes is written until you Accept, so Discard is always available as a fallback.

Step by Step

  1. In Options, under Schedule, set the Optimizer Engine to the mathematical solver.
  2. Decide how to lock the job. The cleanest deliberate constraint is to pin an operator on one of its steps, or to require a skill on a step. Either marks the job as locked.
  3. Save the routing change.
  4. Open the Schedule Jobs window, go to the Optimizer tab, pick a goal, and click Run.
  5. Open the Explain dialog on the result and check the locked-jobs section for your job and its lock reason.
  6. Click Accept to persist the proposal, or Discard to leave the schedule untouched.

What Changes When You Save

Setting the engine and adding a constraint changes nothing until you run and Accept. When the solver runs, it reads each job's routing and locks any job that uses a feature it does not optimize natively: a multi-instance or one-per-day work center, transit days, lot streaming, parallel processing, alternate work centers, an operator pin, or a required skill, among others. A locked job is copied verbatim from the greedy plan, so its steps keep the same machines, starts, and durations, and its rows still occupy capacity. The solver then rearranges only the unlocked jobs, fitting them around the locked one. Because the locked job cannot move, the optimizer can never emit a plan that disturbs it.

How to Check It Worked

Open the Explain dialog after the run. The locked-jobs section names every job the solver left alone and the reason for each. Your job should appear there with the reason that matches the constraint you added, such as an operator pin. In the KPI delta grid and the move list, the job should show no move. If the job is not in the locked list, the constraint did not trigger a lock; confirm you are running the solver engine and that the constraint is actually saved on the job's routing.

Common Mistakes

  • Running the multi-run engine and expecting a lock. The multi-run search reorders jobs globally and has no per-job lock, so a job can still shift when the order around it changes. Job-level locks belong to the mathematical solver.
  • Looking for a freeze-this-job button. There is no dedicated toggle. The lock is a property of constrained jobs. Add a locking constraint on purpose, or use Discard to reject a proposal that moves the job.
  • Forgetting that a lock also consumes capacity. A locked job is not removed from the plan; it holds its slots, so the optimizer schedules others around it. That is the intended behavior, not a bug.
  • Accepting a proposal without reading the Explain dialog. The dialog is where the locked jobs and reasons live. Read it before Accept so you know exactly what moved and what did not.

Where to Go Next

Locking a job and choosing a goal are the two controls that shape an optimization run. Read how to choose an optimizer goal next, and if a run surprises you, see why the optimizer returned the same schedule. The full platform is at EDGEBIC, with more recipes in the EDGEBIC How-To Library.

Expert Q&A: Deep Dive

Q: We want one job left exactly where it is but the rest optimized. What is the cleanest way?

A: Run the mathematical solver engine and pin an operator on one of that job's steps. The pin marks the job as locked, so the solver reproduces it exactly as greedy scheduled it while it rearranges the unlocked jobs around it. Open the Explain dialog after the run to confirm the job appears in the locked list. If you would rather not change the routing, the fallback is to review the proposal and Discard any run that moves the job.

Q: The multi-run engine still shifted our job in time. Does it have locks?

A: The multi-run engine changes only the global job order and reruns the greedy engine, so a job can shift when the order around it changes; it has no per-job lock. Job-level locks are a feature of the mathematical solver engine. If you need one job held in place while others optimize, switch to the solver in Options and add a locking constraint to that job. Either way, nothing is written until you Accept, so Discard always undoes a proposal you dislike.

Frequently Asked Questions

Ready to Transform Your Production Scheduling?

User Solutions has been helping manufacturers optimize their production schedules for over 35 years. One-time license, 5-day implementation.

User Solutions Team

User Solutions Team

Manufacturing Software Experts

User Solutions has been developing production planning and scheduling software for manufacturers since 1991. Our team combines 35+ years of manufacturing software expertise with deep industry knowledge to help factories optimize their operations.

Let's Solve Your Challenges Together