.svg)
What engineering change management has to keep aligned
Every engineering change produces one authoritative answer to a narrow question: which revision of this part is valid, from which date, at which sites. Three systems need that answer. PLM holds the engineering record. ERP holds the procurement and costing record. MES holds the work instructions the floor executes against.
When those three disagree, it is rarely visible. Each system reports its own revision as current, and each is internally consistent. Nothing throws an error. The mismatch surfaces at inspection, in a customer complaint, or during an audit, weeks or months after approval.
This is why engineering change management gets measured badly. Teams track engineering change order cycle times, which tells them how long approval took. It does not tell them whether the approved change is in force everywhere it should be. A change that clears approval in three days and reaches the MES in three weeks still shipped the wrong part.
The five stages of the engineering change management process
The discipline breaks into five stages, and the terminology matters because each produces a different artifact.
- Request: a quality engineer, supplier, or production lead raises an engineering change request (ECR) describing the problem and the proposed fix.
- Assessment: engineering, quality, and procurement establish what the change touches, which assemblies, which suppliers, which open work orders.
- Approval: the change board signs off, and the request becomes an engineering change order (ECO), the instrument that authorizes the change.
- Effectivity: the change is dated, so every system knows from which serial number, batch, or date the new revision applies.
- Propagation: the approved revision and its effectivity date reach every system and partner that acts on them.
Engineering change control is the governing framework around all five: who may approve what, and what evidence is retained. The first four stages happen inside one system, usually the PLM. The fifth crosses system boundaries, which is why it is the stage that fails.
Why approved changes still reach the floor late
Propagation fails in four recognizable ways, and none of them looks like a failure at the time.
Manual re-keying is the most common. An engineer emails the new revision to planning, someone types it into the ERP, and the transcription is correct until the day it is not.
Batch windows lose the effectivity date. A nightly sync carries the revision number but drops the date it becomes valid, so ERP treats the change as effective immediately while MES continues on the old instruction until its next refresh.
Structure conversion introduces silent drift. The engineering bill of materials in PLM is not shaped like the manufacturing bill of materials the ERP needs. When that conversion is scripted rather than governed, a substituted component can land on the wrong assembly. This is the same gap that breaks the digital thread more broadly.
Supplier notification stays informal. Revisions go out as email attachments, and the supplier has no reliable way to know whether the drawing they hold is current.
All four share one cause: once a change leaves the PLM, no system owns it.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
