Engineering change, end to end

What it is, and what it is not

Change management is the record of why the product is what it is. It holds the problem somebody found, the alternatives considered, the decision taken, who agreed to it, what it affected, and the date it took effect.

It is not a workflow with a status field on it. A status field records that a change was approved; it does not record what the approver was looking at when they approved. When a customer asks a question two years later, the second thing is the one that matters.

Nor is it a separate module bolted beside the BOM. Change is the mechanism by which released structures move at all — a released revision cannot be edited, only superseded through a change — so it is not an optional layer that disciplined organisations add.

Seven kinds, one object type

Problem Report, ECR, ECO, ECN, Deviation, Waiver and Stop Ship share every field, every relationship and every lifecycle state. They are one ObjectType discriminated by kind rather than seven types.

The reason is maintenance arithmetic. Seven types means seven copies of the same attribute list, and copies drift: someone adds a reviewer field to the ECO and not the ECR, and eighteen months later two change kinds disagree about what a reviewer is. One type with a discriminator cannot drift.

The three on the lower row of the figure are worth separating out because they are the ones people conflate. A deviation permits shipping off-specification within stated bounds. A waiver accepts a specific non-conformance once, after the fact. A stop ship halts. None of the three changes the design, which is exactly why they must not be modelled as an ECO with a flag on it.

The failure it prevents

The failure is not an unapproved change. It is an approved change whose scope nobody could see at the time of approval.

A connector is superseded. Four assemblies use it: two shipping, one in a customer qualification, one a service kit nobody has opened in two years. The engineer knows about two. The programme manager remembers the qualification but is not on the review. Nobody remembers the service kit.

The change is approved in a week and the service kit is discovered nine months later, by a customer. The approvers were not careless — they were shown a form with a description on it and asked to agree. Computing the impact set by traversal and storing it with the change means the approver is shown the four assemblies, and the record afterwards shows they were shown.

How it meets the rest of the product

The impact set comes from traversing the relationship graph over resolved structures, deterministically, with no model in the path. The same question asked twice returns the same bytes, which is what makes the stored set evidence rather than a snapshot somebody might have edited.

Effectivity binds at the change, not at the line. Approving a change and implementing it are separate events, and the change carries the date, unit range or plant scope on which its result takes hold. That is what allows a phased cutover to be a decision rather than a manual reconciliation.

Release is a single atomic transaction. Every affected object's new revision, every lifecycle transition and every relationship update either commits together or not at all — there is no intermediate state in which half a change is real. Mass BOM change consumes the same reviewed impact set, so a bulk operation runs against exactly the set that was approved.

How it meets your ERP

Release is the trigger for publication. When the transaction commits, Manufacturing PLM resolves each affected structure at the change's effectivity and publishes it in the shape the target expects — a dated BOM Revision in NetSuite, a Change Master with a valid-from in SAP S/4HANA, a versioned Production BOM in Dynamics 365, a Part Revision in Epicor, a dated revision in Acumatica.

The date travels with it. This is the part most integrations lose. If a change approved in August takes effect in October and the ERP receives it in August with today's date, planning nets requirements against the new component six weeks early and stops consuming the stock that set the October date in the first place.

Impact analysis reads the other direction. Objects already published to the ERP are flagged, with on-hand quantity and open order state alongside, so a reviewer sees that a cheap-looking change strands sixteen weeks of inventory. If a published structure is edited in the ERP afterwards, the next sync raises a reconciliation task naming the field and both values rather than overwriting.

Where the boundary is

Manufacturing PLM does not compute disposition. Use-as-is, rework, scrap and return-to-vendor are decisions people make with inventory data in front of them; the impact set tells them what to decide about and records what they decided.

It also does not schedule the implementation. A change carries the date it becomes effective; the work orders, purchase order changes and stock moves that make that date real belong to the ERP, and Manufacturing PLM neither creates nor sequences them.