An engineering change order (ECO) is a formal, controlled record used to propose, evaluate, approve, and document changes to a product’s design, components, specifications, or related documentation. It is a key element of change control in product development and manufacturing, especially in regulated or highly engineered environments.
What an ECO typically includes
An ECO commonly defines:
- The item or configuration affected (part numbers, assemblies, software versions, documents)
- The current state and the proposed change (before/after definition)
- The reason for the change (e.g., defect, cost, supply issue, compliance requirement, performance improvement)
- Impact assessment on form/fit/function, safety, quality, regulatory status, and validation
- Implementation details (effective date, effectivity by serial/lot/revision, disposition of existing stock or WIP)
- Approvals and responsibilities across functions such as engineering, manufacturing, quality, and supply chain
ECOs are often managed within a product lifecycle management (PLM) or product data management (PDM) system, but they can also appear in document control systems or QMS platforms, depending on how the organization structures change control.
Role in manufacturing and regulated environments
In industrial and regulated manufacturing, ECOs connect product design decisions to downstream operational changes. They help ensure that:
- Updated designs flow to manufacturing execution systems (MES), ERP, and work instructions in a controlled way
- Changes to BOMs, routings, and test methods are coordinated across engineering, production, and quality
- Traceability is maintained so that units can be associated with the design revision and ECO that governed their build
- Evidence of review and approval is available for audits and internal governance
Depending on the organization, ECOs may be closely linked with corrective and preventive action (CAPA) processes, supplier changes, or field issue investigations, but the ECO itself focuses on the technical and configuration aspects of the change.
Operational interoperability context
In practice, an ECO often spans multiple systems and teams. For example, a single ECO may:
- Originate in PLM when a design engineer proposes a change to a component or drawing
- Trigger updates to routings, recipes, or parameters in MES or other OT systems
- Require updates to controlled documents, work instructions, and inspection plans in a QMS or document control system
- Drive ERP changes to BOMs, item masters, and approved manufacturer lists
Aligning these handoffs and maintaining a shared, traceable ECO record is a central example of organizational interoperability: different departments using consistent change data, roles, and decisions across their respective tools.
What an ECO is not
An ECO is related to, but distinct from:
- Engineering change request (ECR): usually a preliminary proposal or idea for a change. An approved ECR may lead to an ECO that defines the final, implementable change.
- Deviation or waiver: a controlled, temporary permission to depart from the approved design or process without formally changing the baseline. An ECO establishes a new baseline rather than a one-time exception.
- CAPA record: focuses on identifying and addressing root causes of issues. An ECO may be one of the actions implemented under a CAPA.
Common confusion
The terminology around engineering changes varies by organization. Some use ECO as a combined request-and-order process, others separate ECR (request) and ECO (order). It is useful to confirm how a particular organization defines:
- When an ECO is created in the lifecycle of a change
- Which systems (PLM, MES, ERP, QMS) hold the authoritative ECO record
- Which changes require an ECO versus simpler document updates or local work instructions changes
Despite variations in local practice, in industrial and manufacturing contexts “engineering change order” commonly refers to the formal, approved instruction to change product configuration or related technical documentation, with controlled implementation and traceability.