The most common misunderstanding in change management is not technical. It is that people treat the day a change was approved as the day the change happens.
They are rarely the same day, and everything expensive lives in the gap.
Three dates, not one
A change has an approval date — when the decision was made and signed. It has an effectivity date — when the new definition governs what gets built. And it has a cutover point — when the last unit of the old configuration is actually produced, or the old stock finally runs out.
In a simple change all three collapse into one day, which is why the distinction is easy to lose. In most real changes they do not. A change is approved on the 3rd, made effective on the 24th to let existing material deplete, and the last old-configuration unit ships in May because a service order was already in the system when the decision was made.
Each date belongs to a different function, and each function needs a different one:
- Production needs the effectivity date, to plan the last old-configuration build and the first new one.
- Purchasing needs it earliest of anyone, because material with a twelve-week lead time has to stop being ordered long before the effectivity date arrives.
- Quality needs it because an inspection plan changing on the 24th means an inspection performed on the 23rd was correct and one performed on the 25th to the old plan was not.
- Service needs it last and longest, because units built to every historical configuration remain in the field and each one needs the definition it was actually built to.
What actually goes wrong
Here is the failure, and it is worth being specific because the abstract version sounds like it could not really happen.
A change is approved with an effectivity date four weeks out, chosen deliberately to consume existing stock. Purchasing is not on the change's notification list — they were not an approver, because the change was engineering-only and there was no reason for them to sign it. They continue ordering the old component on the standing schedule, because nothing told them not to.
On the effectivity date there are nine weeks of obsolete material in stock, ordered after the decision to obsolete it was made and approved.
Nobody was negligent. The information existed in the change record from the day it was approved, and it did not reach the function whose lead times made it urgent. That is a distribution problem wearing the costume of a process problem.
Why notification does not fix it
The instinctive fix is to add purchasing to the notification list. It helps and it does not solve the problem, for two reasons.
The first is that notification lists are per-change and maintained by whoever raises the change. Somebody will forget, and the failure will recur with a different function in the role.
The second is subtler: a notification tells you about one change. What purchasing actually needs is the aggregate — everything taking effect in the next twelve weeks, in one place, whether or not anybody thought to tell them about each item individually. That is a calendar, not a message.
A notification is a push to the people somebody remembered. A calendar is a pull for the people who know what they need.
The distinction matters because the failure mode of push is silence, and silence is indistinguishable from nothing having happened.
The deviations nobody diaries
There is a second class of date that belongs on the same calendar and almost never gets there: deviation and waiver expiry.
A deviation is an agreement, made in advance, that something out of specification may be built for a bounded period or a bounded quantity. It is a perfectly ordinary instrument and it is used constantly. It also expires.
A deviation expiring on the 11th is exactly as operationally significant as a change taking effect on the 11th, and it is the one people forget, because a deviation feels like a decision that has already been made rather than a date that is coming. An expired deviation still covering ongoing production is a nonconformance that nobody has noticed yet, and it will be found by an auditor rather than by you.
What this means for your ERP
The effectivity date is the date your ERP actually needs, and it is the one most integrations get wrong.
The wrong behaviour is easy to fall into: the PLM publishes a structure when it is approved, because approval is the event the PLM is emitting. The ERP receives it, and production changes four weeks early — before the material was supposed to deplete, which was the entire reason for the delay.
The right behaviour depends on your ERP. Where it supports date-effective bills of material, the publication should carry the effectivity date and let the ERP hold both versions. Where it does not — and plenty do not — the publication itself should be scheduled for the effectivity date, and should be visible in the meantime as something queued rather than something done.
Either way, the question "has the ERP caught up yet?" should have an answer on a screen instead of being asked in a meeting.
The short version
Record three dates instead of one. Show them somewhere everybody can pull from rather than pushing them to a list somebody maintains. Put deviation expiries on the same view. And publish to your ERP on the date the change takes effect, not the date somebody signed it.
None of that is sophisticated. It is just the difference between a change process that is documented and one that is operational.