Engineering change control is where PLM earns most of its value and where manufacturing organizations experience most of their process pain. Wrong revision built. Inventory obsoleted without a plan. Shop floor working to a superseded drawing. Most of those failures trace back to a change process that wasn’t well defined at the handoff point between PLM and the production environment.
This post walks through the mechanics of change control in PLM: the types of changes, the approval workflow, the dispositions that travel with a change, and the implementation tasks that bridge the gap between PLM approval and production execution.
Step 1: Categorize the change
The first thing a well-structured change control process does is distinguish between types of changes, because not all changes have the same downstream impact.
Non-material changes
These don’t alter the product definition in ways that affect what’s being built. Examples include a corrected typo in a document, a formatting update to a drawing note, or an administrative metadata change. These require revision control and documentation in PLM (you still need to know what changed and when) but they don’t require ERP to take any action. The product being produced today is unchanged.
Material changes
These alter the product definition in ways that affect production: a component swap, a dimensional change, a new assembly process requirement. These require a formal change control process with a defined approval workflow, structured review, and controlled release. Once approved and effective, a material change triggers an update in ERP and the new revision becomes the next producible version of the product.
Mixing these up in either direction creates problems. Over-routing minor changes through full formal review creates approval bottlenecks and reviewer fatigue. Under-routing material changes means production decisions get made on incomplete or unapproved data.
Step 2: Route for review and approval
In PLM, a material change follows a routing: a configured sequence of reviewers and approvers whose sign-off is required before the change can be released.
- Reviewers assess the change for completeness and correctness within their domain (engineering, manufacturing, quality, procurement)
- Approvers authorize the release
- In regulated industries, this workflow is also the audit record — the documented evidence that the right people reviewed the right information before any production action was taken
The output of a completed approval workflow is an effective change: a new revision of the product record that is now the authoritative definition of the product. That effective date is permanent and traceable.
Step 3: Assign dispositions
A material change doesn’t just introduce a new product definition — it creates a transition problem. What happens to everything in the production environment that was built around the old definition?
This is handled through dispositions, associated with each affected item on the change order. Dispositions communicate to ERP and production planning how to handle the transition:
| Affected area |
Disposition options |
| Inventory on hand (superseded components) | Use as-is, scrap, or rework |
| Open purchase orders | Receive and use, cancel, or redirect |
| In-process work orders and shop floor builds | Complete to old revision, hold, or retrofit |
PLM defines what the dispositions are. ERP executes against them. An integration that carries only the new BOM, without disposition instructions, leaves production planning without the information needed to manage the cutover cleanly.
Step 4: Understand the effective date vs. cut-in date gap
One of the most common sources of confusion in change management is the difference between when a change is approved in PLM and when it’s implemented in production.
Effective date (PLM): The change completed its approval workflow and is now the authorized product definition. From PLM’s perspective, this change is done.
Cut-in date (ERP): Production starts building to the new revision. This is almost always later than the effective date — sometimes days, often weeks — because of real-world constraints:
- Existing inventory of superseded components needs to be consumed or dispositioned
- In-process work orders may need to complete before the changeover
- Make-to-order components may have lead times that extend the transition
- The shop floor needs time to receive and confirm updated instructions and drawings
The effective date and cut-in date serve different purposes and are owned by different systems. PLM owns the effective date. ERP owns the cut-in date. The change process and the PLM-ERP integration both need to explicitly account for this gap.
Related reading: PLM vs. ERP: Understanding the Architecture Difference
Step 5: Track implementation tasks to completion
The gap between PLM’s effective date and ERP’s cut-in date is managed through implementation tasks — tracked work items assigned to specific people as part of the change workflow.
Typical implementation tasks include:
- Calculate cut-in date based on current inventory levels and lead times (production planning)
- Update item master and BOM in ERP (ERP administrator or planner)
- Communicate updated work instructions to the shop floor (manufacturing engineering)
- Disposition open purchase orders (procurement/buyer)
Each task has an owner and a completion status. PLM tracks these tasks, and the change doesn’t reach its final “complete” status until all implementation tasks are closed.
| Status | Meaning |
| Effective | Change approved and authorized; new product definition is active |
| Complete | All implementation tasks finished; production fully transitioned |
A change can be effective but not complete. Someone needs to be actively working those open implementation tasks. PLM makes that visible rather than leaving it to follow-up emails and tribal knowledge.
What this looks like end-to-end
A well-structured change control process gives engineering and production teams a clear, traceable path:
- Engineering develops and documents the change in PLM
- Change routes for structured review and approval
- On approval, the change becomes effective with a recorded date
- Dispositions travel with the change to ERP
- Implementation tasks are assigned and tracked to owners
- Cut-in date is calculated and applied in ERP
- Change reaches complete status when all downstream actions are closed
Every step is traceable. Every decision is documented. The product record in PLM is the authoritative source of what was approved and when. ERP has what it needs to execute. The shop floor gets updated information at the right time — not before it’s approved, and not after it’s been lost in an email thread.
That’s what change control is supposed to do.
Running Arena PLM? CADTALK automates the data handoff from Arena to ERP — carrying dispositions, BOM updates, and revision changes without manual re-entry. See how it works at cadtalk.com.
