What Each Scheduling Mode Rebuilds

EDGEBIC by User Solutions offers five scheduling modes, and the only thing they really differ on is scope: which orders the run touches and which of the existing plan's capacity it keeps reserved. A full reschedule clears everything and rebuilds; the incremental modes touch a subset and replay the rest so untouched slots stay booked; and across all of them, any operation that already has a shop-floor actual is preserved and never moved. Choosing the right mode is the difference between quietly slotting in three new jobs and accidentally reshuffling the whole shop.

Every scheduling run starts by deciding what to keep. That decision is the mode. Once it is made, the same placement engine runs; the mode only shapes the world the engine sees before it starts.

The one rule every mode obeys

Before the modes diverge, they agree on an invariant: actuals are immutable. Any schedule row carrying a logged actual start or end represents work the floor has already done or begun, and the engine never re-places it. Its capacity stays reserved, its dates stay fixed, and the engine reschedules only around it. This is why even a full reschedule cannot rewrite history: it clears the reservations for unstarted work, but a step someone actually ran keeps its place. Everything below is about the unstarted work.

The five modes

Each mode answers two questions: which orders are in scope, and what happens to the orders that are not.

New only is the safe daily run. You entered some orders this morning; this mode places them into the gaps in the current plan and touches nothing else.

Full reschedule is the reset. It releases every unstarted reservation and rebuilds the entire plan, so it is the mode to use after you change a routing, add a work center, or alter shifts, when the old plan was built against a reality that no longer holds.

All unstarted re-optimizes: it re-places every job that has not started, taking advantage of the latest priorities and capacity, while leaving jobs that are underway alone.

Smart incremental is all-unstarted with a guardrail. It additionally protects a near-term frozen window, so imminent work the floor is already set up for does not churn even though it has no actuals yet.

Single-job reschedule is the surgical mode: reschedule one job, from where its actuals leave off, and leave the rest of the shop exactly where it was.

Why "replay" matters

The subtle part is what happens to orders not in scope. They are not simply ignored. The engine replays their committed capacity into its internal picture of the shop before it places any new work. If it did not, a new job would be placed as if those machines were free, and two jobs would claim the same hours.

So in a new-only run, every existing order's whole schedule is replayed, and the three new jobs are threaded into whatever capacity is genuinely left. In an all-unstarted run, only the orders being kept, the ones with actuals, are replayed; the unstarted orders' old reservations are released so their work can be re-placed on better slots.

This replay is also the fix for a classic reschedule bug. If a job with a partial actual on step one kept step two's and step three's old reservations alive, the engine would see those machines as booked and push the new step two days into the future. The rule is precise: for a job being rescheduled, keep only the rows that have actuals, and release the rest. That is why a reschedule frees stale capacity reservations rather than tripping over them.

A worked example

Five orders. MO-10 through MO-13 are already scheduled; MO-14 was entered this morning. MO-11 has an actual start logged on its first operation.

New only. Only MO-14 is processed. MO-10 through MO-13 are replayed verbatim into the capacity picture, and MO-14 is placed into the gaps around them. Result: four untouched plans plus one new one. Nothing on the existing Gantt moves.

Full reschedule. All five are in scope. The engine clears every unstarted reservation and rebuilds. MO-11's actual-started operation is preserved, but its later unstarted steps, and all of MO-10, MO-12, MO-13, and MO-14, are re-placed from scratch against current priorities. This is the mode that "moved half my plan," and that is exactly what it is for.

All unstarted. MO-14 plus the unstarted parts of MO-10, MO-12, MO-13, and the unstarted tail of MO-11 are re-placed. MO-11's actual-started operation is preserved and replayed. You get a re-optimized plan that still respects what the floor has begun.

Smart incremental. The same as all-unstarted, except any operation inside the near-term frozen window, say the next shift the floor is already set up for, is left alone even though it has no actuals. You re-optimize next week while today stays put.

Single-job reschedule of MO-12. Only MO-12 is rebuilt, from where its actuals stand. The other four plans, including the just-entered MO-14 if it was already scheduled, are untouched.

Choosing a mode

The decision is really about how much disruption you are willing to accept in exchange for how much re-optimization. New-only accepts none and re-optimizes nothing existing. Full reschedule accepts total churn to get a plan fully consistent with changed data. The incremental modes sit between: re-place the unstarted work for a better plan, but keep the started work fixed, and with smart incremental, keep the imminent work fixed too.

The reason the modes exist at all is schedule stability: a plan the floor cannot trust because it reshuffles every run is worse than a slightly less optimal plan that holds steady. New-only and smart incremental exist to protect that trust; full reschedule exists for the moments when the underlying reality has changed enough that stability would just preserve a wrong plan.

For the full engine pipeline these modes feed, see the scheduling engine guide, and for the general reason a run respects existing bookings at all, finite versus infinite capacity scheduling covers why capacity has to be honored. To watch each mode's effect on your own plan, explore EDGEBIC or bring your data to a demo.