Nine Production Rescheduling Mistakes That Make a Correct Run Look Broken

Most production rescheduling mistakes do not produce an error message. They produce a plausible schedule that describes a different factory than the one you are standing in. Below are nine that come up repeatedly in real EDGEBIC by User Solutions deployments, each with the symptom it produces and the correction. All nine are documented behaviors rather than speculation.

If you have not seen the mechanism these mistakes distort, how EDGEBIC preserves completed work explains what a run actually does.

1. Rescheduling Before Logging

Symptom. The run produces dates the floor disputes immediately. Downstream operations queue behind positions that stopped being true on Tuesday. Within two weeks supervisors are working from printouts instead of the screen.

Cause. A reschedule computes a resume point from the last logged position and plans everything remaining from there. Stale actuals produce a confident plan built on old reality, and nothing on the screen indicates that.

Fix. Log actuals first, every time, even roughly. One honest hours figure per operation per day supplies the resume point, which is the number that drives the run. The procedure is in logging actual hours and pieces.

This is the mistake that makes the other seven matter less. Fix it before anything else on the list.

2. Full Scope for Every Correction

Symptom. Fixing one order moves 40 jobs. Supervisors report that the plan looks different every morning. Setups that were staged yesterday are wrong today.

Cause. A full run re-plans every unfinished operation across the plant. That is correct after a calendar or capacity change and excessive after a single-order correction.

Fix. Use the narrowest scope that covers what changed. Targeted reschedule for day-to-day work, from the Schedule View tab after saving your bar changes: only the jobs you modified are re-planned, and every other job keeps its plan and its reserved capacity. Reserve the full run for changes that genuinely affect everyone.

Unnecessary movement has a cost even when every individual date is defensible, which is the whole subject of schedule nervousness.

3. Running With Unsaved Drags on Screen

Symptom. You spend twenty minutes arranging bars, run the reschedule, and the arrangement is gone.

Cause. Pending drags exist only on your screen. The run reads the database, and your screen is not the database.

Fix. Save what you meant and discard the rest before running. Saved changes are respected: a planned-start pin holds its operation on that date and work center, and a saved work center replacement is honored for started and pinned operations. Correct order is drag, save, then reschedule. See drag and drop rescheduling for what each drag mode commits you to.

4. Treating Short-Confirm Policy as a Preference

Symptom. Two runs from the same week produce different remainders from identical data. Hours reappear on operations somebody thought were finished, or vanish from ones that were not.

Cause. When an operator marks a step complete with fewer hours logged than planned, the policy under Options decides what happens to the gap: write it off, forward-shift it onto the next free slot, or forward-shift only flagged steps. Changing the setting between runs changes the answer.

Fix. Decide once, as a site, and document it. Forward-shift is the default and the standard choice when routings are trusted. Trust-the-stamp fits shops where the floor's word is final. Either is defensible; alternating between them is not.

5. Faking an Actual Start to Hold a Position

Symptom. An operation is locked to a work center nobody chose. The job's percent complete is wrong. A downstream operation queues behind a resume point that no work produced.

Cause. Entering an actual start on an operation that has not begun tells the engine that work started. That is not a display convention, it is a fact claim, and the engine acts on it: the operation keeps that machine permanently, and its projected end feeds the resume point for everything behind it.

Fix. Use a planned-start pin. It holds the operation on the date and work center you chose, survives the run exactly as an actual would, and dissolves automatically once a real start is logged. You get the control without corrupting the data.

6. Expecting a Routing Edit to Reach a Running Job

Symptom. Engineering updated a routing, you rescheduled, and the job re-planned on the old work center and old hours.

Cause. This is protection, not a defect. Every scheduled job carries its own frozen copy of the routing taken when it was first scheduled, so a master edit cannot silently reshape work already on the floor. The operator with a fixture set up for the original machine is the reason.

Fix. Adopt the change deliberately, per job, on the Scheduled Job BOR tab. Update this Job BOR edits the job's own copy. Reset BOR from Global replaces the copy with a fresh snapshot. Use Global BOR on Reschedule makes the job follow the master on the next run. The trade-offs are in working with frozen routings.

7. Blaming the Engine for Capacity

Symptom. A step lands days after its predecessor finished, and the gap has no obvious explanation on the job.

Cause. The work center's next free slot really is days away. Other jobs hold the capacity, or a holiday or downtime blocks the window. The engine placed the operation in the first genuinely available opening, which is the entire premise of finite capacity.

Fix. Look at the work center's load before assuming a bug. If the constraint is real, your options are an alternate work center, a priority change, or added capacity, not a scheduling setting. Finite versus infinite capacity scheduling covers why the gap is a feature, and production bottleneck identification covers finding the station causing it.

A related case: the gap between two steps is genuinely configured. Queue time, transit days, and overlap settings on the routing step all create deliberate separation. Check the step before checking the engine.

8. Not Opening the Audit Trail

Symptom. An argument about whether a completed date changed. A job that "moved for no reason". A meeting spent reconstructing what happened.

Cause. Every run writes an audit event holding the old and new start and end, the actor, and the timestamp, and almost nobody looks at it.

Fix. Thirty seconds per critical job after each run. Click Job Audit on the Job View tab, or right-click a bar and choose View Audit Trail. The newest event is the reschedule with old and new dates side by side; below it sit the completions and drags that led here.

This settles the completed-dates question instantly. Completed operations cannot move, so when someone reports that they did, what changed is the display window, the planned dates on the same operation, or a different row belonging to the same routing step on a parallel work center. The trail shows which.

9. Using a Targeted Run After a Calendar Change

Symptom. You added a plant holiday, or changed a shift pattern, or took a work center offline for maintenance. You ran a targeted reschedule on the jobs you thought were affected. A week later, jobs you did not touch are still planned across the holiday.

Cause. A targeted run deliberately leaves untouched jobs alone, including their reserved capacity. That is exactly what you want for a single-order correction and exactly wrong for a change that alters the calendar every job is planned against.

Fix. Match the scope to the change. Anything affecting capacity, calendars, shifts, or work center availability needs the full run, because the set of affected jobs is "all of them" and you cannot enumerate it by hand. Anything affecting one order or a handful of orders takes the targeted run.

The rule of thumb: if you changed a job, target it. If you changed the plant, run everything.

A Tenth, Quietly

Leaving overrides in place after they have served their purpose. A planned-start pin from three weeks ago, a work center replacement for a machine that is back in service, a short-confirm flag on a step that no longer needs one. Each one silently constrains every future run.

The tell is the downstream-changed state lingering on the Gantt after a run. The engine resolves sequencing, so those flags should clear; any that remain are operations still carrying instructions you gave the engine and forgot about. Sweep them monthly.

The Pattern

Most of this list is the same mistake wearing different clothes: acting on the schedule without telling the schedule what happened, or telling it something that did not happen. The engine is honest about its inputs, which means it is only as good as them.

The rest are process rather than data: scope chosen by habit instead of by what changed, and audit trails nobody opens. Both are cheap to fix and both change how much the floor trusts what you print.

Where to Go Next

Production rescheduling software covers when a run is warranted at all. How to reschedule safely is the checklist that prevents most of this list. How EDGEBIC preserves completed work explains the mechanism underneath.

For a specific move you cannot explain, why did my job jump two days is the diagnostic, and the EDGEBIC troubleshooting guide is the wider index. The platform overview is the complete guide to EDGEBIC. Bring a schedule you do not trust to a demo of EDGEBIC and we will find out which of the eight it is.