EDGEBIC Scheduling Modes Explained: What Each Run Touches

A scheduling mode decides two things: which jobs a run replans, and what happens to the capacity held by every job it leaves alone. Get that right and a scheduling run is a routine three-minute operation. Get it wrong and you either move bars the shop floor is already working to, or you wonder why a change you made this morning had no effect at all. EDGEBIC by User Solutions works with five modes internally, and understanding them is the fastest way to predict what any run will do before you press the button.

This post is the map of those modes. The EDGEBIC complete guide covers the product end to end, and the scheduling engine guide opens up the mechanics of a single placement. Here the subject is scope: what enters a run, what stays untouched, and why.

The Five Modes in Planner Language

Two properties are shared by all five. First, recorded work is never moved: an operation with an actual start or end date is preserved verbatim and only the remaining work is replanned. Second, a job that fails to schedule (a product with no routing, an inactive work center) is reported with a reason and does not take down the rest of the run.

How the Button Maps to the Modes

There is no mode picker on the screen, and that is deliberate. The Schedule + Re-Schedule button on the Drive Schedule tab does both things its name says: jobs that have never been scheduled get their first plan, and already-scheduled jobs you ticked get replanned. Jobs you did not tick keep their existing schedules, and the capacity they hold is respected by everything planned around them.

Scope therefore comes from your row selection, not from a dropdown:

• Tick nothing and EDGEBIC asks whether to schedule all orders. Answering yes puts every job in scope, which is the full-rebuild case.
• Tick a handful of rows and only those jobs release their unstarted reservations and get replanned.
• Open Job View and press Re-Schedule and exactly one job is replanned. Completed and in-progress work on it stays put, and every other job's plan is untouched.

Before anything runs, a Confirm Scheduling dialog states the split in plain numbers: how many jobs are new (first-time scheduling) and how many are existing jobs that will be rescheduled. Read that line. It is the cheapest check available against the single most common scheduling mistake, which is scheduling everything when you meant to schedule three jobs.

Why Scope Matters: Reservations Are Real

The reason mode discipline matters at all is that capacity in a finite capacity system is a claim, not a suggestion. When the engine places an operation, it consumes hours from a specific work center on a specific date in a specific shift. Nothing else can use those hours. This is the difference between finite and infinite capacity scheduling, and it is why "which jobs are in scope" is such a load-bearing question.

Inside a run the rule is precise:

• A job not in scope keeps its entire plan, and every hour it holds is replayed into the capacity picture before new work is placed. New work fits around it.
• A job in scope keeps only the operations that carry recorded actuals. Its unstarted reservations are released so the engine can place them again, possibly earlier, possibly on a different machine.

That second rule fixes a problem that looks bizarre from the outside. If a job's own stale reservations were kept while it was being replanned, the engine would see its own future slots as booked by somebody else and push the new plan days out. Releasing only the unstarted rows of in-scope jobs is what keeps a reschedule from fighting itself. If you have watched a job jump after a replan, why a job moves after a reschedule walks through the other causes.

A Worked Comparison: Five Jobs, Four Modes

Take a plant with five orders. Jobs 10, 11, 12 and 13 are already scheduled. Job 14 was entered this morning and has no plan.

The practical difference shows up in the plan quality trade-off. The new-orders-only run gives job 14 whatever gaps remain, which may be a poor slot if jobs 10 to 13 were entered in a careless order. The full reschedule can produce a materially better plant-wide plan because it can re-sequence everything. It also moves bars that supervisors printed yesterday. That is the whole trade, and there is no universally right answer: schedule stability is itself a KPI on a busy shop floor.

What a Run Changes, Surface by Surface

Scope decides which jobs move. This table decides what "moving" means everywhere else:

Read the second and third rows together and the value of narrow scope becomes concrete. A run that touches four jobs changes four sets of bars. A run that touches forty changes forty, and every supervisor who printed this morning's plan now has a stale sheet.

Choosing a Mode: Five Practical Rules

1. Default to the incremental run. Enter orders, tick the new rows, run. Small runs are easy to review, and large runs hide surprises.
2. Rebuild after master data changes. Adding a holiday, changing a shift, editing a routing, or changing work center capacity does not ripple into existing plans by itself. The plan on screen reflects the old world until you run again for the affected jobs.
3. Set priorities before the run, not after. Jobs are planned one at a time in priority order, and each claims capacity as it goes. Re-running to fix priorities moves bars twice.
4. Use the single-job reschedule for single-job problems. A moved due date, a machine breakdown on one order, a routing edit on one job: replan that job and nothing else.
5. Protect the near term deliberately. If today's plan must not change, keep the frozen window in play rather than trusting yourself to tick the right rows every morning.

The Single-Job Case Deserves Its Own Habit

Most planners default to the plant-wide button because it is the one they learned first. The single-job reschedule on Job View is the better tool more often than it gets used, and the reason is scope again: it replans exactly one job and leaves every other reservation intact.

Reach for it when:

• A customer moves one delivery date.
• One job's routing was corrected.
• A machine problem affects one order's path and not the others.
• An operator logged actuals and you want that job's remaining work pulled back to reality now, without waiting for the morning pass.

Reach for the plant-wide run when the change is plant-wide: a new shift, a holiday, a capacity change, a batch of new orders, or a priority reshuffle that spans several jobs. The distinction is worth making explicit in your own operating procedure, because the two buttons feel similar and their blast radius is not.

What Never Changes, Whatever Mode You Run

Three guarantees hold across every mode, and they are worth stating plainly because they are what makes frequent rescheduling safe:

• Recorded work is immutable. Completed and in-progress operations are preserved exactly. Only remaining work is replanned, and it resumes from the latest actual rather than from the job's original start.
• Committed due dates are inputs, not outputs. The engine never moves a due date you set. It fills a blank due date once, from the job's first planned end, and never touches it again.
• The routing snapshot travels with the job. Each job freezes the routing it was first scheduled with, so a later edit to the master routing does not silently rewrite a job already running on the floor.

Those three rules together are why a plant can run the scheduler several times a day without the plan losing credibility with the people executing it.

Where to Go Next

Mode is scope. The next three questions are procedure, mechanism, and failure:

• To run a schedule properly, including how to read every column of the result, see how to run the scheduler in EDGEBIC.
• To follow what actually happens inside a run, phase by phase, see inside an EDGEBIC scheduling run.
• For the mistakes that produce a plan nobody trusts, see scheduling run mistakes.

If scheduling is new territory, the generic explainer on what production scheduling is sets the context before any of the above. User Solutions has been building finite capacity schedulers since 1991, for shops from single-cell job shops to the USS Nimitz overhaul with more than 26,000 tasks, and the mode discipline described here is the same discipline that made those schedules executable.

Bring your order list and your work center calendar to a demo and we will run all four scope patterns against your real data. Contact US for a walkthrough, or start with the EDGEBIC product overview.