The change board signed off on Tuesday. Revision C is released, the drawing is updated, and the engineer has moved on to the next fire. Meanwhile the ERP still holds open purchase orders for revision B, tomorrow morning’s MRP run will plan a few more, and the stockroom has bins of the old part that nobody has decided to use up, rework or scrap. The change is approved. It just hasn’t happened yet.
That gap isn’t a discipline problem. It’s an architecture problem. In most shops the engineering change lives in PLM, the item master and open orders live in ERP, and the work instructions live in MES. What connects them is an export, a nightly sync, or a person rekeying the new revision. Every handoff is a place where the change can stall, and no dashboard shows the stall, because each system reports its own half as done.
So here is the claim. An engineering change isn’t finished when it’s approved. It’s finished when every system that buys, builds or ships the part has acted on it. Effectivity, the disposition of stock on hand and on order, and the notice to the supplier are part of the change, not cleanup after it. If your process can’t show you, in one place, which open orders still reference the old revision, you don’t have change control. You have change approval.
N23D is built so that gap has nowhere to hide. Change control, the item master and purchasing read the same record, so releasing revision C puts every open order and every bin of revision B on the change itself, and the change can’t close until each one has a decision. One platform. Full digital thread. Thirteen vendors can each pass their own audit while the part you’re buying is still wrong.
Featured photo: Stockroom at the Long Beach, Calif., plant of Douglas Aircraft Company, attributed to Alfred T. Palmer, U.S. Office of War Information, public domain, via the National Archives and Wikimedia Commons.
