Engineering Change Management That Stops Scrap

An engineering change that is incomplete, out of sequence or unauthorised does not fail visibly. It reaches the line and becomes scrap, rework, a slipped launch, or a warranty exposure discovered much later.

• The failure is silent at release. Nothing rejects an incomplete change; the line simply builds to it.
• Sequence matters as much as content. A correct change released against the wrong effectivity is still wrong.
• No single system sees the whole change. A revision touches the PLM, the ERP and the MES, plus supplier orders and the station. Each is authoritative for its own slice and blind to the rest, so every individual sign-off can be correct while the change as a whole is not.
• The cost lands far from the cause. Scrap and warranty surface weeks or months after the release that caused them.

A change reaches the line once. The gate checks that it is complete, in sequence, and released by someone entitled to release it.

• A final check before release. Completeness, effectivity, sequence and authorisation are verified before the change reaches production.
• Cross-system consistency. Drawing, routing, bill of materials and work instruction are compared rather than trusted.
• Unauthorised changes stopped. Release authority is enforced at the gate, not assumed from the workflow.
• A full audit trail per change. What was checked, what failed, who released it.

A change is signed off one slice at a time. Engineering approves its slice, purchasing approves its slice, and the line finds out when the wrong parts arrive or a work instruction points at a revision that no longer exists.

• Every dependent line, not only the changed one. A revision to a part is checked for the bill-of-materials lines, routings, work instructions and supplier orders that depend on it. An incomplete change is the most common failure and it never announces itself.
• Effectivity against open and in-transit orders. A correct change released against the wrong effectivity date is still wrong. The date is checked against what is already ordered, already in transit, and already staged at the line.
• Superseded revisions still in circulation. Any downstream document still pointing at the revision being replaced is surfaced before release, because the line builds to whatever is at the station rather than to what the PLM believes is current.
• Release authority, enforced rather than assumed. Entitlement to release this class of change is checked at the gate. That a change passed through a workflow is not evidence that the person who released it was allowed to.
• What the gate does not do. It does not author changes, edit a drawing or choose an effectivity date, and it has no write path into PLM, ERP or MES beyond recording its own verdict. That is what keeps it an outside check rather than another system with an opinion.

Each system is authoritative for its own slice and blind to the others, so nobody owns the only question that matters: is this change complete and in sequence everywhere at once.

• The cost lands far from the cause. Scrap, rework and warranty surface weeks or months after release. By then the change is one of hundreds and the link back is an investigation rather than a lookup.
• Speed is not the problem. Tools that draft change records, propagate updates and generate work instructions make the change faster. Faster is useful and it is not a check.
• The gate must not become the delay. Change cycle time is measured through the pilot for exactly this reason. A gate that slows compliant changes gets worked around, and a gate that is worked around protects nothing.
• Watch-only comes first. For the first weeks the gate observes every proposed change and touches no system of record, so the plant sees what it would have caught before anything is enforced.

Every individual sign-off can be correct while the change is wrong.

That is the shape of the failure, and it is why the check has to sit outside all of the systems it reads.

This is a 60 to 90 day pilot on a single line, cell, category or product family. The figures below are what the pilot measures against a baseline captured in its first two weeks. They are targets and instrumentation, not results already delivered.

• Scrap and rework tied to change error. Measured against the baseline for one product family, captured before the gate goes live.
• Change cycle time. Tracked to show the gate is not adding delay to compliant changes.
• A complete release trail. Designed to make root cause on a change-related defect a lookup rather than an investigation.