Engineering change systems: getting a change through the plant without stranding stock

The request, the assessment and the decision in between

A raised request is a proposal, not a change. Between the two sits an assessment that should answer what problem it solves, what it costs to implement, what it saves or prevents, and how urgent it genuinely is. Separating request from order matters because it creates a place to say no, or to say later, without losing the idea. Plants without that separation either approve everything and drown the shop floor in churn, or route everything through a committee that meets too rarely, at which point engineers start making informal changes that never enter the record at all.

Affected-item analysis is where the system pays for itself

The list of things a change touches is longer than anyone's recall: parent assemblies through every level, routings and the operations within them, fixtures and gauges, inspection plans, work instructions, packaging specifications, spare part catalogues, service documentation, customer-facing data sheets and any supplier holding your drawing. A structured where-used query produces that list in minutes; a meeting produces the obvious half of it. The half that gets missed is consistently the same: tooling, inspection and packaging, because they are owned by people who are not in the room when the change is discussed.

Effectivity by date, by serial or by stock exhaustion

How a change takes effect is a business decision with different consequences. A date is simple and strands whatever stock remains. Running out existing material avoids write-off and makes the build configuration ambiguous for a period, which is unacceptable where safety or traceability depends on knowing which version shipped. Serial or lot effectivity is precise and demands that planning, production and service records all understand it. Choose per change rather than by standing rule, and record which basis was used, because a service engineer will one day need to know what is inside a specific unit.

Disposition of everything that already exists

Approval is the easy part. What follows is a set of decisions about finished stock, work in progress, material in the warehouse, material on order, stock the supplier holds against your schedule, and spares already in the field. Each needs an owner, an action and a cost home: use as is, rework, scrap, return, or run to depletion. Leaving disposition implicit is how a change that saved money on the unit cost ends up costing more than it saved, and how obsolete material is discovered during a stock count long after the responsible budget closed.

The change that never arrives at the point of use

The most common audit finding against change control is not that a change was wrong but that it stopped somewhere before the bench. A laminated instruction at a workstation still shows the old sequence, the inspection plan was never updated, the supplier was told verbally and their internal document unchanged. The fix is to treat document update and distribution as tasks inside the change order, not as follow-up, so the change cannot be closed while any of them is outstanding. That single rule catches most of what otherwise reaches the plant unannounced.

Frequently asked questions

Why do engineering changes keep reaching the plant as a surprise?

Usually because the affected-item list was built from the design structure alone, and the people who own tooling, inspection and packaging were not part of the assessment. The change is then correct on paper and incomplete in practice. Adding a mandatory impact review by each affected function, with a named individual rather than a department, converts a surprise into a scheduled task. It also slows the queue, which is a fair trade against unplanned line stoppages.

Should production be able to block an engineering change?

Block is the wrong framing; production should be able to set the timing and the conditions. A change that requires new tooling, a validation run or supplier requalification cannot take effect the day it is approved, and someone who understands the schedule has to say when it can. Where production has no voice at all, changes land mid-order and are absorbed by improvisation on the floor, which quietly destroys the configuration record.

How do we stop the change queue from stalling?

Separate urgent from routine and give them different paths. Safety, regulatory and customer-driven changes need a short route with a small standing approval group. Everything else can batch. The other common cause of a stalled queue is approval by committee where any absent member halts progress, so define delegation explicitly and set a rule that silence past a stated point counts as acceptance for lower-risk categories, with the risk categories agreed in advance.