Routing drift is the gap between the routing a job was scheduled against and the routing that is current in the system today. It appears whenever someone edits a master routing after jobs using it have already been planned, which on an active shop is routinely. Drift is not an error and it does not corrupt anything, because each job keeps its own copy of the routing as it stood when it was scheduled. What it does mean is that the plan on the floor and the standard in the system can disagree, and EDGEBIC by User Solutions makes that disagreement visible rather than leaving it to be found.
How it works
Two copies of a routing exist once a job has been scheduled, and understanding which is which explains everything else.
The master routing is live and editable. It is the standard for the product, and engineering changes it as processes improve, fixtures change, or a mistake is corrected. It governs every job scheduled from now on.
The job's copy is frozen. When a job is scheduled, the routing it used is captured with it. That copy is what the plan was built from and what the job continues to be run against. Nothing an engineer does to the master afterwards reaches back into it.
Drift is simply the two copies no longer matching. Detecting it is a comparison of the fields that would actually change a plan: which work center the step runs on, how long setup takes, how long each unit takes, and how much waiting the link adds. A change to a description or a note is not drift in any sense that matters, because it would not have produced a different schedule.
Where the comparison finds a difference, it is surfaced at the point it becomes relevant. On the shop floor terminal that means a banner before setup starts, naming what differs. It does not block anything, because the job is legitimately running to the routing it was scheduled with. It exists so the person at the machine, who is better placed than anyone to judge, knows the standard has moved.
Adopting the newer routing on a specific job is possible and is an explicit action followed by a reschedule. That deliberateness is the point. Automatic adoption would mean a running job's plan changing for reasons nobody on the floor witnessed, which is precisely the behavior that teaches a plant to stop trusting its schedule.
A concrete example
A milling step has a cycle time of eight and a half minutes per unit and a setup of forty-five minutes. Twenty jobs are scheduled against it across the next three weeks.
On Tuesday, engineering commissions a new fixture that cuts the cycle time to seven minutes and the setup to thirty, and updates the master routing accordingly.
Nothing about the twenty scheduled jobs changes. Each one still holds the old figures, still shows the same dates, and still occupies the same capacity. This is correct: whether any given job benefits depends on whether the new fixture is actually on the machine when that job runs, and the system has no way to know.
On Wednesday an operator starts one of those jobs at the terminal. Before setup, a banner tells them the routing has changed since this job was scheduled, naming the cycle time and the setup time as the differences. They acknowledge it and run the job.
That acknowledgment is worth something. If the fixture is in place, the operator now knows the job should take less time than the plan says, and the planner has a case for adopting the new routing on the remaining nineteen jobs and rescheduling them, which would pull the whole three weeks forward. If the fixture is not scheduled to be fitted until next month, the operator knows to run to the old standard and nobody wastes time investigating why the job took longer than the newest numbers suggest.
Either way, the disagreement was noticed by a person on Wednesday rather than emerging as an unexplained variance in a report the following month.
How EDGEBIC uses it
The frozen copy is the mechanism that makes drift safe, and it is described in what is a routing snapshot and worked through in how a frozen routing snapshot protects a running job. Which copy a scheduling run reads is itself a setting, covered in what is a BOR source mode in scheduling.
The floor-facing half is described in the BOR drift banner at the kiosk, and the terminal it appears on is covered in what is a shop floor kiosk. The comparison is deliberately narrow, covering only the fields that change a plan: the work center, plus the timing fields described in what is setup time in manufacturing, what is run time per unit in manufacturing scheduling and what is queue time in manufacturing scheduling.
Where a planner does decide to adopt a newer routing, the follow-up is a scheduling run scoped to the jobs concerned, described in what is a targeted reschedule.
The takeaway
Routing drift is the normal consequence of a shop that keeps improving its processes while jobs are already in flight, and the design response to it is two-part: freeze what each job was planned with so nothing changes underneath the floor, then say out loud when the standard has moved. Neither half works without the other. Freezing alone would let a plant run for months on figures everyone knows are stale; warning alone would mean a running job's dates shifting for reasons nobody at the machine can see. The judgment left to a person is the right one: does the new routing describe what this job will actually do. For the wider vocabulary see the manufacturing glossary, and for the product itself see EDGEBIC.
Routing drift is the difference between the routing a job was scheduled against and the routing that is current today, arising whenever an engineer edits the master routing after jobs using it have already been planned. Each job keeps its own copy of the routing as it stood when it was scheduled, so drift does not silently change a running job. It does mean the plan on the floor and the standard in the system can disagree, which is why the disagreement is surfaced rather than left to be discovered.
No, and that is deliberate. A job holds the routing it was scheduled with, so an engineering change made this morning does not silently re-time work that started last week. The alternative would mean a job's plan changing underneath the people running it for reasons nobody on the floor witnessed. Adopting the new routing on a specific job is possible but is an explicit action, so somebody decides rather than the change simply arriving.
A non-blocking banner before setup begins, naming which aspects differ: the work center, the setup time, the cycle time, or the waiting time on the link. The operator acknowledges it and carries on, because the job is running to the routing it was scheduled with and that has not changed. The point is that somebody at the machine now knows the standard has moved, which is exactly the person best placed to say whether the new one is right.
No. Jobs already scheduled hold the routing they were planned against, so a cycle-time cut applies to jobs scheduled after the change rather than retroactively to ones already planned. If you want existing jobs to benefit, adopt the updated routing on those specific jobs and reschedule them; both are deliberate actions. The behavior protects you far more often than it frustrates you, since the same rule stops a mistaken edit from silently re-timing half the plant.
Not automatically. Ask whether the change describes what the job will actually do. A cycle-time improvement from a new fixture applies only if that fixture is on the machine for this job, and a work-center change may be entirely wrong for a job already part-way through on the original machine. Adopt when the new routing describes this job's reality, leave it when it does not, and treat the warning as the prompt to ask rather than as an instruction.
Expert Q&A: Deep Dive
Q: Engineering cut a cycle time last week and my schedule dates did not improve. Is something broken?
A: No. Jobs already scheduled hold the routing they were planned against, so a cycle-time cut applies to jobs scheduled after the change rather than retroactively to ones already planned. If you want existing jobs to benefit, adopt the updated routing on those specific jobs and reschedule them; both are deliberate actions. The behavior protects you far more often than it frustrates you, since the same rule stops a mistaken edit from silently re-timing half the plant.
Q: Should I always adopt the newer routing when I see a drift warning?
A: Not automatically. Ask whether the change describes what the job will actually do. A cycle-time improvement from a new fixture applies only if that fixture is on the machine for this job, and a work-center change may be entirely wrong for a job already part-way through on the original machine. Adopt when the new routing describes this job's reality, leave it when it does not, and treat the warning as the prompt to ask rather than as an instruction.
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
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.
Share this article
Related Articles
The EDGEBIC Scheduling Glossary Index
A themed index to the EDGEBIC glossary: scheduling engine, capacity and calendars, materials and planning, shop floor, reporting, quoting, and data import terms, defined in plain language.
What Is the Critical Chain in Manufacturing Scheduling?
The critical chain is the longest dependent path through a plan once shared machine contention is counted, not just step precedence. Here is how it differs from the critical path.
What Does Finite Capacity Mean in EDGEBIC?
Finite capacity means the scheduler refuses to book more hours on a machine than that machine actually has. See exactly how EDGEBIC enforces it, day by day and shift by shift.