Production Rescheduling Software: When and Why to Rerun the Plan

A reschedule in EDGEBIC by User Solutions is a surgical re-plan, not a reset. Completed work is treated as historical fact and never recomputed. Work in progress keeps the hours already logged against it. Only the unfinished balance and the not-yet-started operations are re-planned, and they are re-planned from the point the shop has genuinely reached rather than from where the old plan said it would be.

That distinction is why rescheduling can be routine. In systems where a reschedule wipes and reruns everything, planners avoid it, and avoidance is exactly how a plan drifts into fiction. This post covers the decision layer: when a reschedule earns its keep, how to choose scope, what policy you set once, and what the run can never do for you.

The Three Zones, Briefly

Every operation of every job sits in one of three zones when a run starts.

Illustrated on a three-step routing:

Routing:   [1 Cut - Saw-1] -> [2 Mill - CNC-Mill-1] -> [3 Assemble - Assembly-1]

Step 1   ##########   actual start + actual end        -> COMPLETED   (frozen)
Step 2   ###.......   actual start, 3 h of 11 h logged -> IN PROGRESS (3 h locked, 8 h re-planned)
Step 3   ..........   no actuals                       -> NOT STARTED (fully re-planned)

The mechanism behind the freeze is covered in how EDGEBIC preserves completed work. What matters here is the consequence: because a reschedule cannot damage history, running one is a low-risk act, and low-risk acts can be done on a schedule.

Five Rules That Always Hold

1. Completed work never moves. No mode, no setting, no policy will shift, shrink, or recompute an operation that has both actual dates.
2. Started operations keep their machine. Once an operation has begun on a work center, a reschedule will not relocate it.
3. Remaining work re-plans from reality. Not-started steps queue behind the real finish of the last completed or running step, not behind the old plan.
4. Each job keeps its own routing copy. The routing in force when a job was scheduled is stored with the job, so a later master-routing edit cannot silently reshape work already on the floor. See routing snapshots explained.
5. Every reschedule leaves a trace. Old dates, new dates, actor, and timestamp, inspectable through the job audit trail.

Rule 3 has a flip side worth stating plainly: if actuals are missing or wrong, the reality the engine resumes from is wrong too. Log before you reschedule, every time.

When a Reschedule Earns Its Keep

Five triggers cover almost every legitimate case.

Two situations that look like triggers and are not. A single operation finishing 20 minutes late on a non-constraint work center rarely changes anything downstream, because queue time and shift boundaries absorb it. And a job that is fully complete needs no run at all: the engine recognizes it as done and writes it back unchanged, which makes an accidental reschedule of a finished job harmless but pointless.

Choosing Scope

Three scopes, and picking the right one is most of the skill.

Full reschedule. The Drive Schedule tab's Schedule and Re-Schedule button. New unscheduled jobs get scheduled; already-scheduled jobs get re-planned under the five rules. Use it when something changed that affects everyone: a holiday, a shift pattern, a work center added or lost, a large batch of new orders.

Targeted reschedule. After dragging and saving bar changes on the Schedule View tab, the Re-Schedule button re-plans only the jobs you modified since the last run. Every other job keeps its plan and its reserved capacity. This is the day-to-day option, and it is the polite one on a busy plant because it cannot disturb work you never touched.

Single job. The Re-Schedule button under the Job View Gantt strip does the same for the selected job's context. Use it when one order has drifted and nothing else has.

The habit worth building: targeted for corrections, full for calendar and capacity changes. Planners who reach for the full run every time generate movement on jobs that had no reason to move, and that movement is what erodes floor confidence.

The One Policy to Decide Once

Sometimes an operator marks a step complete having logged fewer hours than planned. That is a short-confirm, and what the next reschedule does with the missing hours is a site decision, not a per-job one. It lives under Options as Partial-Confirm Behaviour.

Forward-shift is the default because it matches standard practice: the hours are either owed or the plan was fat, and forward-shifting surfaces the question instead of burying it. Trust-the-stamp fits shops where the floor's word is final and routings are known to run generous.

Pick one, as a site, and leave it alone. Switching this setting between runs is a reliable way to make consecutive schedules disagree for reasons nobody can reconstruct. The full worked case is in the partial completion reschedule walkthrough.

What Changes and What Survives

Nothing is deleted. A reschedule replaces the future plan and keeps all history.

Verifying the Run

Thirty seconds per critical job, after every run.

1. Open Job View and check the hours header. Actual hours must be unchanged by the reschedule. Only planned timing moves.
2. Compare the grid's actual start and actual end columns against what the floor reported. Completed rows must show exactly the logged values.
3. Click Job Audit, or right-click a bar and choose View Audit Trail. The newest event is the reschedule with old and new dates side by side, and earlier events show every drag and completion that led here.
4. Scan the Gantt for operations still flagged as downstream-changed. After a run those should be gone; any that remain still carry manual overrides the engine was told to respect.

The audit trail is the answer to "what moved and why," and having it before a customer asks is the difference between an explanation and an apology.

Signals You Have the Cadence Wrong

Two failure modes, and each announces itself.

Too often. Supervisors stop reading the printed sheet. Setups get staged against a plan that changed before the shift started. The same job appears at three different positions in one week without anything real having happened to it. The cure is a published rhythm plus targeted scope for exceptions, so movement traces to a cause somebody can name.

Too rarely. Every reschedule produces a large, unwelcome move because it is absorbing a week of drift at once. Promise dates lurch rather than adjust. Planners start negotiating with the output instead of trusting it. The cure is more frequent runs against fresher actuals, which produce smaller corrections that nobody argues with.

The healthy pattern is boring: a daily run that moves a handful of jobs by a few hours each, with an audit entry explaining every move. If your runs are either invisible or dramatic, the cadence is the thing to change before any setting is touched.

What Rescheduling Cannot Do

Three honest limits.

It does not create capacity. If the constraint work center is full, the new dates will be later and they will be correct. Identifying that constraint is a separate exercise: see production bottleneck identification.

It does not fix bad data. The engine resumes from the actuals it was given. Stale or auto-filled actuals produce a confident plan built on assumption, which is why actuals logging mistakes is worth reading alongside this.

It does not decide priorities for you. Re-sequencing follows the priorities and due dates you set. If two jobs both need the same slot tomorrow, the engine will place one of them second, and whether that was the right one is a business decision.

The Rhythm

The single habit that makes rescheduling work: log first, reschedule second, on a published cadence. Daily before shift start suits most shops. Per shift suits plants running near capacity with long routings.

Shops that reschedule on a rhythm keep promise dates honest and give supervisors a stable sheet to work from. Shops that reschedule reactively teach their floor to ignore the printout, and once that has happened no scheduling engine can help. The broader case for treating scheduling as a discipline rather than an event is in what production scheduling is.

Where to Go Next

How to reschedule safely is the step-by-step workflow with the pre-flight and post-run checks. How EDGEBIC preserves completed work explains the immutability guarantee in mechanical detail. Rescheduling mistakes covers the traps that make a correct run look wrong.

When a job moves further than expected, why did my job jump two days diagnoses the four causes. The platform overview is the complete guide to EDGEBIC, and a demo of EDGEBIC can run a reschedule on your own live jobs.