Master data drift — the quiet killer of every scheduling rollout

A scheduling system does not fail loudly. It fails the way a clock loses time — a few seconds a day, then a minute, then enough that the noon train is now the 11:53.

The scheduling rollouts that disappoint, in our experience, almost never disappoint at go-live. They disappoint at month four. The planner stops trusting the schedule. The plant goes back to running a parallel spreadsheet. The vendor gets blamed for "the model not matching reality" — which is true, but the vendor isn't what changed.

What changed is the master data underneath the model. And almost nobody owns it.

For a scheduler, "master data" isn't the polite definition you get in an SAP brochure. It is the specific set of facts the scheduling engine reads every run to decide what is feasible:

• Routings. Which operations happen on which resources, in which order, with what alternates.
• Cycle times and changeovers. Per product · per resource · per from-to combination.
• Resource capacity calendars. Shift patterns, planned maintenance windows, holidays, plant-specific exceptions.
• BOMs and yields. Especially yield variance, because a 96% yield assumption is a different schedule than a 92% yield assumption.
• Capability matrices. Which operator group, qualification, or cleaning state is required where.
• Constraint parameters. Min/max batch sizes, campaign rules, sequence-dependent setup hierarchies.

The scheduling engine treats every one of these as fact. It has no way to tell that the cycle time it's using was measured on a piece of equipment that was replaced eight months ago.

Drift never announces itself. A representative six months looks like this:

None of these are bugs. They are normal plant life. They are also four cumulative reasons the schedule the planner sees on screen is not the schedule the plant can run.

The structural problem is ownership. Master data for scheduling sits across at least four organisations:

The scheduling team owns the output. They rarely own any of the inputs. Each input has its own update cadence, its own change-control process, and — critically — no one whose job description includes "make sure the scheduling engine knows this changed."

So the scheduling system continues to consume the model it was given at go-live, plus whatever has been manually corrected by a planner who happened to notice. That's the drift.

Before the planner explicitly says "this isn't working," there is a stretch of six to twelve weeks of subtle symptoms:

• The schedule keeps proposing sequences that the floor manually re-orders.
• "Re-plan" runs more often. Manual interventions per shift creep upward.
• The variance between planned end-of-day and actual end-of-day grows by 10–20 minutes a week, then plateaus at "an hour or two".
• The planner stops looking at the optimisation score because the score doesn't correspond to anything they recognise.
• Spreadsheets reappear. Always.

By the time the conversation reaches "the scheduling tool isn't matching reality," trust is already gone, and rebuilding it is harder than getting to go-live was.

There is no clever architecture that eliminates this. There are operating practices that contain it. The plants that keep their schedules trustworthy do four things:

Not after. Before. A specific person — usually senior planner or planning manager — whose accountability includes the integrity of the scheduling master data. Not the integrity of the schedule. The integrity of the inputs to the schedule.

If no one's name is in the box, the answer to "who keeps this current?" is "nobody," and you can predict the rest.

Every time engineering issues a change order, every time a recipe is approved, every time an operator qualification record changes, the scheduling system should hear about it. Not on a quarterly export. On the event. In a regulated environment that's a controlled interface; in less regulated ones it's a webhook. Either way, drift compounds at the speed of unnotified changes.

Cycle times measured at go-live are not cycle times today. A simple quarterly job — pull actuals from the historian, compare to the master-data values, surface the deltas — keeps the model honest. Once a year, run a fuller audit that includes routings, alternates, and the capability matrix.

The planner should receive the same change notifications that production, quality, and engineering receive. They should have to confirm "scheduling master data updated to reflect change X" as part of the change closure. If the change closes without that confirmation, the change isn't closed.

The instinctive question when buying a scheduling tool is "what does the optimiser do?" The better question, by month six, is "what does this tool do to keep its master data honest?"

Listen for:

• Native consumption of MES / ERP master data, not a one-time import.
• Versioning of the scheduling model — when did this routing change, who changed it, what was it before.
• The ability to flag deltas between planned and actual times automatically, not on demand.
• A clean way to retire a piece of equipment from the model without leaving zombie routings behind.

A scheduler that ships without these is a scheduler whose accuracy will live entirely on the discipline of one person.

Master data drift is the largest single reason scheduling rollouts fail to deliver year-two results. It is preventable but not by accident. Name the steward, wire the change events, recalibrate on a fixed cadence, and put the scheduling team inside the change-control loop. Otherwise, six months from go-live, you will be looking at a clean schedule on a screen and a noisier plant on the floor, and you will not be sure why.