The change calendar: approved is not the same as effective
The single most common misunderstanding in change management is treating the approval date as the date the change happens. They are rarely the same day, and the gap is where things go wrong.
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 is consumed.
In a simple change all three collapse into one day. In most real changes they do not: a change is approved on the 3rd, effective on the 24th to let existing material deplete, and the last old-configuration unit ships in March because a service order was already in the system.
The calendar shows all three. A view of the approval schedule alone answers a governance question and is useless operationally; a view of effectivity answers what production needs and hides the decisions that have not been made yet.
What the calendar is for
It exists so that the question *what changes in the next fortnight* has one answer that everybody reads, rather than four answers held by four functions.
- Production needs to know which build configurations change and when, to plan the last old-configuration build and the first new one.
- Purchasing needs it earlier, because material with a twelve-week lead time must 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.
The failure it prevents
A change is approved with an effectivity date four weeks out, chosen 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 continues ordering the old component on the standing schedule.
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 and did not reach the function whose lead times made it urgent. A calendar that is visible to everyone rather than notified to approvers is the cheapest possible fix for a failure that costs six figures.
How it meets the rest of the product
Effectivity ranges are the underlying mechanism; the calendar is the view onto them. A date on the calendar is a date some structure's resolution changes, and clicking it resolves the affected structures before and after so the difference is visible rather than described.
Impact analysis populates the calendar's detail. A change entry shows which products it touches, which open orders it affects and which suppliers hold controlled copies of the affected documents, all resolved rather than hand-listed.
Deviations and waivers appear on it too, with their expiry dates, because 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.
Baselines anchor to calendar dates, which is what makes a retrospective question answerable. Asking what the definition was on a date in the past is the same operation as asking what it will be on a date in the future, because both are resolutions under stated conditions.
Notifications are driven from the calendar rather than from the approval event, so a function with a twelve-week horizon hears about a change twelve weeks out rather than on the day somebody signed it. The horizon is configured per role, because purchasing and service do not share one.
How it meets your ERP
The effectivity date is the date the ERP needs, and it is the date most integrations get wrong by publishing on approval instead. A structure published to the ERP on the day it was approved changes production four weeks early.
Manufacturing PLM publishes with the effectivity date carried, so where your ERP supports date-effective bills of material the change lands correctly without intervention. Where it does not — and many ERPs do not — the publication is scheduled for the effectivity date and appears on the calendar as a pending publication.
The calendar therefore doubles as an integration schedule. What is queued to publish, when, and to which system is visible in the same place as what is changing, which removes the standing question of whether the ERP has caught up yet.
Where the boundary is
The calendar does not plan production. It shows when definitions change; deciding which units get built when is your ERP's or MES's job, and Manufacturing PLM has neither the capacity data nor the demand signal to do it responsibly.
It also does not move dates on its own. An effectivity date that has become impossible — because material did not deplete as expected — is a change to the change, going through the same approval as anything else. A date that drifted quietly is a date nobody can rely on.
Facts
| Three dates | Approval · effectivity · cutover — rarely the same day |
| The gap | Where the failures live |
| Purchasing | Needs it earliest — lead times run ahead of effectivity |
| Service | Needs it longest — every historical configuration stays in the field |
| Also shown | Deviation and waiver expiry dates |
| Mechanism | Effectivity ranges; the calendar is the view onto them |
| ERP | Published with effectivity carried, or scheduled for that date |
| Not offered | Production planning · dates that move on their own |
Frequently asked
Why separate approval from effectivity?
Because they are rarely the same day. A change approved on the 3rd may be effective on the 24th to let existing material deplete, and the last old-configuration unit may ship in March because a service order was already in the system.
Who actually needs this view?
Four functions with different horizons: production plans the last old build and the first new one, purchasing needs it earliest because of lead times, quality because inspection plans change on a date, and service needs it longest because field units never stop existing.
What goes wrong without it?
Purchasing continues ordering a component after the decision to obsolete it was approved, because they were not an approver and so were not notified. The information existed in the change record and never reached the function whose lead times made it urgent.
Why are deviations on a change calendar?
Because 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. An expired deviation covering ongoing production is a nonconformance that nobody has noticed yet.
What does clicking a date show?
The structures whose resolution changes on that date, resolved both before and after it, so the difference is visible rather than described in a sentence. The calendar is a view onto effectivity ranges, which is where the actual mechanism underneath it lives.
Our ERP has no date-effective BOMs. What then?
The publication is scheduled for the effectivity date rather than sent on approval, and it appears on the calendar as a pending publication. That keeps the ERP from changing production four weeks early, which is the usual failure with approval-triggered integrations.
Can an effectivity date be moved?
Yes, as a change to the change, going through the same approval as anything else. A date that has become impossible needs to move, but a date that drifted quietly is a date nobody downstream can plan against, so the movement is recorded.