One uncontrolled design change can disrupt an entire production line.
Picture this scenario. An engineer notices a stress concentration in a bracket and updates the geometry in the CAD model. The change is real — the design is genuinely better. But instead of going through a formal process, the file gets shared directly: emailed to a few teammates, uploaded to a shared folder, mentioned in a Slack message.
Within a few weeks, production is building from an old revision. The supplier received yet another version. Quality is checking against the original. When parts don't assemble correctly and the root cause investigation begins, the first question is always the same: which version is the latest?
This is not a hypothetical. It's one of the most common failure patterns in manufacturing. And it's exactly what Engineering Change Management exists to prevent.
What Engineering Change Management Is
Engineering Change Management (ECM) is a structured process for managing modifications to products, designs, processes, or documentation. The key word is structured. ECM doesn't prevent changes — it controls how they happen, who approves them, how their impact is assessed, and how they are implemented and communicated across all affected functions.
In a manufacturing environment, a single design change rarely affects just one thing. Change a hole diameter and you've affected the drawing, the BOM, the assembly instruction, the tooling specification, the inspection criterion, and potentially the supplier's production setup. ECM ensures all of these downstream effects are identified, planned for, and handled — not discovered after the fact.
The Three-Stage ECM Process
Engineering Change Management follows a three-stage flow that separates the identification, authorization, and implementation of changes into distinct, controlled steps. This separation is intentional — it creates decision points where the right people assess the right information before action is taken.
Stage 1 — The Change Request (CR)
The Change Request is where a change is first formally proposed. It's the entry point into the ECM process, and it serves a specific purpose: capturing enough information about a proposed change that the right people can evaluate it properly.
A well-formed CR answers several questions: What is the problem or opportunity? Which parts, documents, or processes are affected? What is the reason — engineering defect, customer requirement, regulatory change, cost reduction? What is the urgency? Who is requesting it?
At this stage, the change is not yet approved. It is a proposal. The CR exists to initiate evaluation, not to authorize action. This distinction matters — in organizations without formal ECM, changes often start being implemented as soon as someone identifies them, before their full impact is understood.
Stage 2 — The Change Order (CO)
The Change Order is the authorization stage. This is where cross-functional stakeholders — engineering, manufacturing, quality, procurement, program management — review the Change Request, assess its impact across their respective domains, and decide whether and how to proceed.
A thorough CO review covers: What does this change cost to implement? What is the schedule impact? Are there tooling, supplier, or qualification implications? Does this affect configuration-controlled deliverables? Are there regulatory or certification considerations?
When the review is complete and the change is approved, the CO formally authorizes the change and defines the implementation scope — which specific actions need to happen, in what order, on what timeline. The CO is the bridge between the problem being identified and the solution being executed.
- Impact assessment — full scope of affected items documented before approval
- Cross-functional sign-off — all affected domains confirm awareness and readiness
- Implementation plan — specific actions, owners, and timelines defined
- Effectivity — when the change applies (serial number, date, or lot-based effectivity)
Stage 3 — The Change Action (CA)
The Change Action is where implementation happens. CAs are the individual work tasks that together execute the approved change: update the CAD model, revise the drawing, update the BOM, revise the work instruction, notify the supplier, update the inspection plan.
Each CA is tracked against the Change Order that authorized it. Progress is visible. Completion is verified. Once all CAs are closed, the change is formally complete and the updated product configuration becomes the new baseline — reflecting the change and maintaining full traceability back to the original CR.
ECM in PLM Systems
Manual ECM — paper forms, email chains, spreadsheet trackers — works at small scale. It breaks down as programs grow, teams distribute, and change volumes increase. The solution is implementing ECM within a PLM system, where the change process is embedded in the same environment as the product data it governs.
In ENOVIA on 3DEXPERIENCE, the ECM workflow is directly connected to the product data it affects. When a CR references a part, ENOVIA knows exactly which drawings, assemblies, and processes reference that part — the impact scope is computed automatically, not assembled manually. Approvals route to the right people based on the type and scope of change. CAs link directly to the objects being modified. And the complete change history is preserved in the product's lifecycle record.
Other PLM platforms — Teamcenter, Windchill, Aras — offer similar ECM capabilities. The principles are consistent; the implementation varies. What they all share is the fundamental advantage of connecting the change process to the data it governs, rather than managing changes in systems separated from the product definition.
Engineering Change Management is not bureaucracy. It's the infrastructure that allows engineering organizations to move fast without breaking things — to make changes confidently because every affected party is informed, every downstream effect is managed, and every decision is traceable. The organizations that treat ECM as an overhead to minimize are the ones that keep asking the same question in the same meetings: "Which version is the latest?"
Written from hands-on experience working with Dassault Systèmes tools across Transport & Mobility and Aerospace & Defence programs. Views are my own.