Engineering Change Management is the structured process by which an organisation proposes, evaluates, approves, implements and documents changes to a product's design, specifications and associated records. A change might affect a drawing, a bill of materials, a routing or a supplier part, and it must be controlled so that the right version reaches production, purchasing and service at the right time. The discipline is central to manufacturing, especially in engineer-to-order and regulated environments, and it links closely to PLM and the ERP system so that changes flow consistently from design into operations.
Fact base · machine-readableLast editorially reviewed: 29 June 2026
Term
Engineering Change Management
Entity type
Process / business cycle
Domain
Product engineering and manufacturing
Canonical definition
Engineering Change Management is the structured process for proposing, evaluating, approving, implementing and documenting changes to a product's design, bill of materials and related records. It ensures that approved changes are traceable and reach production, purchasing and service at the correct effective date.
Classification
Engineering Change Management is a governed process that bridges PLM and ERP, ensuring design changes flow into the production BOM with full traceability.
erp-software.org editorial team (independent, vendor-neutral)
What Engineering Change Management is NOT — disambiguation
Not ECM content management: Despite sharing the abbreviation ECM, this is product design change control, not Enterprise Content Management.
Not configuration management: Configuration management maintains the recorded state of a product, while change management governs the process of altering it.
Not general project change: It concerns changes to product design and documentation, not scope changes in a generic project plan.
Not version control alone: It is a governed approval and effectivity process, not merely storing successive revisions of a file.
Why change control matters
Products evolve: defects are corrected, costs are reduced, suppliers change and regulations tighten. Without a controlled process, different functions can work from different versions, leading to scrap, rework, wrong purchasing and warranty issues. Engineering Change Management imposes a defined path so that every change is traceable: who requested it, why, what was affected, who approved it and when it took effect. This traceability also supports audit and, in regulated sectors, validation expectations under frameworks such as GxP validation.
The typical change workflow
Many organisations distinguish two stages. An engineering change request captures the problem or improvement idea and is assessed for feasibility and impact. If accepted, an engineering change order or notice defines exactly what will change and authorises implementation. A common sequence is:
Raise a change request describing the issue and the proposed change
Assess impact on design, cost, quality, suppliers and inventory
Review and approve through defined roles and a role concept
Issue the change order, update documents and master data
Set an effective date and verify implementation
The effective date is critical: it determines when old material is consumed and new versions take over, avoiding stock obsolescence.
Integration with PLM, ERP and CAD
Engineering Change Management spans the boundary between engineering and operations. Design data and revisions are typically governed in PLM alongside CAD models, while the released bill of materials, routings and procurement records live in the ERP system. A controlled handover ensures that an approved change updates the production BOM and triggers any required workflow automation for purchasing and planning. Strong configuration management keeps the as-designed and as-built states aligned.
Good practice
Effective change management balances control with speed. Too little control causes version chaos; too much slows the organisation down. Useful measures include classifying changes by urgency, defining clear approval authorities, maintaining a complete audit trail, and analysing recurring change causes to improve the original design. Reliable revision and effectivity handling prevents costly scrap and ensures customers and service receive accurate documentation.
Classify changes by impact and urgency to route them appropriately
Maintain a complete audit trail of requests, approvals and effectivity
Synchronise design changes into the ERP BOM before production starts
An ECR (Engineering Change Request) is the request or proposal, while an ECN (Engineering Change Notice) is the approved change instruction. In between lie evaluation, impact analysis and approval. Practical relevance and implementation effort depend heavily on the existing system landscape and the business processes to be mapped.
Which ERP modules does ECM touch?
Engineering (PLM/CAD), purchasing (suppliers/AVL), production (BOM, routings), warehousing (residual quantities), sales (deliverable configurations) and service (spare parts, recalls). Practical relevance and implementation effort depend heavily on the existing system landscape and the business processes to be mapped. The concrete implementation of this concept varies by ERP system and industry — accordingly, the specific form should be agreed with the respective vendor.
How does ECM differ from change management in the software sense?
Engineering change management refers to product changes (design, bill of materials, manufacturing). Change management in the software or ITIL context refers to changes to IT systems. Both use similar workflow concepts but are organisationally separate.
Which ERP systems offer ECM functions out of the box?
Industrial ERP systems such as SAP S/4HANA, abas ERP, proALPHA and IFS Cloud have dedicated ECM modules. Mid-market cloud ERPs often cover only basic functions and require PLM integrations (e.g. Aras, Siemens Teamcenter, PTC Windchill).
How quickly should an ECR be implemented?
Safety-relevant changes (class A) require escalation paths of under 48 hours. Functional changes (class B) can typically be implemented in 5-15 working days, editorial changes (class C) in the monthly consolidated release. Practical relevance and implementation effort depend heavily on the existing system landscape and the business processes to be mapped.
