Engineering Change Management Architecture: ECR to ECO in PLM (2026)

Every manufacturer I have worked with believes their change backlog is a people problem. The approvers are slow. The reviewers do not read. The board meets fortnightly. So they buy a reminder bot, add an escalation rule, and the backlog does not move. It does not move because engineering change management backlogs are almost never caused by lazy approvers. They are caused by modelling decisions made years earlier — a change object scoped so broadly that it cannot be approved without twelve signatures, an effectivity type that forces manufacturing to guess, or an approval workflow welded to the release workflow so that nothing can ship until everything is agreed.

Change is the one PLM process where your data model and workflow topology directly determine business cycle time. Get the objects wrong and no amount of process discipline recovers it.

What this covers: the ECR–ECN–ECO object model and why the objects are separate, revision versus version versus iteration semantics, effectivity model selection and its ERP consequences, BOM redlining and where-used impact analysis, parallelising the change advisory board, interchangeability and part numbering, propagation to ERP and MES, the failure modes, and how to measure change cycle time honestly.

Context and Background

Formal engineering change management is older than PLM software. Its vocabulary comes from aerospace and defence configuration management — the discipline of knowing exactly which design defines which physical article, and being able to prove it years later. ISO 10007:2017, Quality management — Guidelines for configuration management, still frames the process as five activities: configuration management planning, configuration identification, change control, configuration status accounting, and configuration audit. Every commercial PLM change module is an implementation of those five activities, whether or not the vendor says so.

The second lineage is CMII, developed in the 1980s by the Institute of Configuration Management in Phoenix, Arizona — now the Institute for Process Excellence, which markets the method as CM2. CMII’s contribution was the closed-loop change process: the originator of a change must learn the final outcome before it appears in the delivered product, and changes must move in a fixed sequence from inception through effects analysis, notification, implementation, and reporting by dated baseline. That closed loop is the reason your PLM system insists on separate request and implementation objects rather than one free-form ticket.

The third influence is far more recent and far less principled: the ERP side. SAP’s Engineering Change Management (LO-ECH) predates most modern PLM change modules and imposes its own semantics — a change master record carrying a valid-from date, with the standard system supporting DATE and SERNR effectivity types and user-defined parameter effectivity beyond that. Because the ERP is where the change actually costs money, its effectivity model tends to win any argument with the PLM model. Teams that design their PLM change process without reading the ERP’s change master schema discover this the hard way, usually about four weeks after go-live.

Choosing between the major platforms is a separate exercise — I have covered that in the Aras vs Teamcenter vs Windchill PLM comparison. This post is about the architecture underneath all of them, which is more similar than the marketing suggests.

The Engineering Change Management Reference Architecture

Engineering change management is the controlled process of proposing, evaluating, authorising, implementing and recording changes to a released product definition. In PLM it is implemented as a chain of distinct objects — problem report, change request, change notice, change task — each carrying its own lifecycle, approvers and affected-object list, so that investigation, authorisation and execution can be tracked and audited separately.

Figure 1: The canonical change object chain, from problem report through change tasks to effectivity and ERP propagation.

The diagram shows the spine that every major PLM platform implements with different names. A problem report captures an observed defect or an improvement request. A change request holds the analysis: root cause, proposed solutions, cost, and the business case for doing anything at all. A change notice carries the authorised implementation plan. Change tasks decompose that plan into assignable units of work — CAD and engineering BOM in one, manufacturing BOM and routings in another, technical publications and service documentation in a third. Affected objects and resulting objects record the as-is and to-be revisions. Effectivity binds the change to a point in the production stream, and only then does the ERP change master get created.

Why the objects are separate, not one ticket

The single most common architectural mistake is collapsing this chain into one object because “our process is simple.” It is not simple; it is small. Those are different things, and the chain exists to decouple four decisions that have genuinely different owners and genuinely different latencies.

Siemens Teamcenter Change Manager expresses this as a derivation hierarchy. A problem report describes the issue. An engineering change request derived from it proposes a solution with cost estimate and benefit. An engineering change notice derived from the ECR carries the detailed work plan, identifies affected items and documents, and authorises the actions. Teamcenter is explicit that the cardinality is many-to-many in both directions: one ECR can implement several problem reports, and two or more ECNs can implement a single ECR. Each object exposes its relationships through Implements and Implemented By folders.

PTC Windchill uses almost the same shape with different labels. A problem report documents an issue or enhancement request. A change request records the formal analysis — proposed solutions, cost analysis, justification — and is typically created once one or more related problem reports have been validated. A change notice represents the implementation plan and its execution, with one-to-many change tasks assigned beneath it covering CAD, eBOM, mBOM, documentation and process planning. Windchill adds a fifth object that the others generally lack as a first-class citizen: the variance, which records an accepted deviation from specification requested by a supplier or manufacturer. Windchill’s help documentation describes the network as built forward from problem report to change task, and resolved backward from change task completion to problem report closure.

Dassault Systèmes ENOVIA on the 3DEXPERIENCE platform names three: change request, change order, and change action. The change order orchestrates implementation strategy across functional organisations, and change actions are the formal documents authorising release of the changed objects, each with tasks, assignees and due dates. Change actions can be generated from change requests, change orders, or issues — or created standalone.

Aras Innovator takes the pragmatic route with Express ECO, a fast path for part and BOM relationship changes driven by an Impact Matrix that visualises how modifying one part propagates through the hierarchy. The Express ECO workflow moves through Planning, Draft Changes and Release activities, with a Team Manager owning impact analysis of affected parts and setting the effective date. Aras also supports the full multi-object chain when the change warrants it. This dual-track design — cheap path for cheap changes, full path for expensive ones — is the single most underrated feature in commercial change management, and the thing most implementations fail to configure.

Revision, version, iteration — and the trap underneath

The vocabulary here is genuinely confusing because vendors use the same words differently, and getting it wrong produces changes that appear to work and quietly do not.

Windchill is the cleanest reference. A version identifier such as A.1 decomposes into a revision (A) and an iteration (1). Iterations increment on every check-in. Revisions increment only when you deliberately invoke the Revise action, and revising uses the latest iteration as content for the new revision. Iterations are working history. Revisions are the controlled unit — the thing a change notice authorises, the thing a manufacturing plant can be told to build.

The trap is what I call revise the part or revise the BOM. Suppose a bracket in an assembly needs a thicker wall. You revise the bracket from A to B. Does the parent assembly automatically pick up bracket rev B?

The answer depends entirely on how the parent’s BOM stores its child references, and it is one of the most consequential modelling choices in the system. If the BOM line points at a specific revision, then no — the parent must itself be revised to repoint at bracket B, and so must its parent, and so on up the tree. That is precise and it is expensive: a change to a fastener at the bottom of a deep assembly can force revisions of a dozen upstream assemblies, generating exactly the kind of avalanche that clogs a change board. If the BOM line points at the part rather than a revision, and the effective revision is selected at configuration time by a revision rule, then the parent does not need revising — but you have accepted that the parent’s content depends on the query used to expand it, which is much harder to reason about and much harder to prove to an auditor years later.

Teamcenter sits at the configured end of this spectrum. Revision rules are parameters that determine which item revision appears in the structure for a given item, and changing the rule shows you a different configuration of the same assembly. Effectivity — date, unit number, or a combination — is specified in the revision rule to configure occurrences, and occurrence effectivity is stored as an effectivity object referenced by occurrences in the structure.

Neither model is wrong. What is wrong is choosing one by accident, or mixing them inconsistently across product lines, which is what most brownfield PLM estates actually do.

The affected-objects spine

The part of the model that carries the real operational weight is the affected-objects list. Windchill separates affected objects, review objects, affected end items and resulting objects for a reason: the set of things a change touches is not the set of things it changes, and neither is the set of things a reviewer must look at.

A good rule: affected objects are the released revisions being superseded; resulting objects are the new revisions the change produces; review objects are the things that must be assessed for impact without necessarily being modified. Teams that collapse these into a single list end up either over-revising (everything touched gets a new revision, inflating the change) or under-reviewing (nobody assesses the service manual, which then ships wrong).

Effectivity: the decision that quietly sets your ERP behaviour

Effectivity answers a deceptively simple question — from when does this change apply? — and the way you answer it determines how much inventory you scrap, how precisely you can trace a field failure, and how much manual reconciliation your planners do every week.

Figure 2: Choosing between unit, lot, run-out and date effectivity based on traceability need and inventory position.

The decision tree above encodes the sequence I use. It reads top-down: regulatory and safety drivers force the most precise model available; serialisation determines whether unit effectivity is even possible; lot control offers a middle path; and only when none of those apply does simple date effectivity become the right default rather than the lazy default.

The three models and what each actually costs

Date effectivity says the change applies from a calendar date. It is the cheapest to administer and the one every ERP supports natively — SAP’s change master record carries a valid-from date, and the change takes effect automatically at that time across sales orders, MRP and shop floor control. Its weakness is that it makes no promise about any particular physical unit. If the plant runs late, units built after the date still contain the old design, and your as-built record is now a fiction. Date effectivity is honest only when the cut-in is genuinely time-driven and you have a mechanism to reconcile actuals.

Unit or serial effectivity says the change applies from unit number n of a given end item. This is the aerospace default and it is what regulators expect when a change is safety-relevant. Teamcenter supports it directly, including multi-unit configurations saved as effectivity groups that configure occurrences against a combination of end items and unit-number ranges. SAP’s standard effectivity types are DATE and SERNR (serial number interval), which is what lets a PLM-side unit effectivity survive the trip into ERP. The cost is administrative: someone must maintain unit-number ranges, and if build sequence changes — as it always does — the ranges must be reissued.

Lot or batch effectivity applies the change from a named production lot. It fits process-adjacent discrete manufacturing, electronics with date-coded components, and anywhere the plant already runs lot control for other reasons. It is the pragmatic compromise: coarser than serial, far more truthful than a calendar date.

Beyond these, SAP supports user-defined effectivity parameters — CUSTOMER, MODEL, or combinations such as CUSTOMER and DATE — under parameter effectivity. This is powerful and it is a trap. Parameter effectivity lets you express “this change applies to units for customer X built after date Y,” which is often exactly the truth. It also means the configuration of a given unit is now the output of a rule evaluation rather than a stored fact, and rules drift.

Effectivity selection matrix

Driver	Date effectivity	Lot / batch	Unit / serial	Run-out then date
Safety or regulatory change	Inadequate	Marginal	Required	No
Field traceability to individual unit	No	Partial	Yes	No
Admin overhead	Lowest	Low	High	Low
Handles build-sequence slip	Poorly	Adequately	Well	Adequately
Old-stock write-off risk	High	Medium	Medium	Lowest
Native ERP support	Universal	Common	SAP SERNR and equivalents	Via planned date
Supplier notification complexity	Low	Medium	High	Medium
Best fit	Cosmetic or documentation change	Electronics, lot-controlled plants	Aerospace, medical, regulated	Cost-driven change with real inventory

The row that gets ignored is old-stock write-off risk. A change that is technically trivial and commercially painful — a cheaper connector, a substitute resin — should almost always be run out rather than cut in on a date. Setting effectivity to “next Monday” when there are eleven weeks of the old part in the warehouse is not a process failure; it is a modelling failure, because the person setting effectivity did not have the inventory position in front of them. Fixing that is an integration problem, not a training problem.

Impact analysis, BOM redlining, and the where-used hot spot

Before a change can be authorised, someone must know what it breaks. That is impact analysis, and it is where change management stops being a workflow problem and starts being a graph-traversal problem.

Where-used is the performance hot spot, and here is why

A BOM is a directed acyclic graph. Expanding a BOM — “what is inside this assembly?” — traverses downward from one root and is bounded by the size of that assembly. Where-used goes the other way: “which assemblies contain this part?” It traverses upward from a leaf with no natural bound, and in a shared-component estate, a single fastener may appear in thousands of assemblies across hundreds of products.

The asymmetry is structural. Downward expansion is a tree walk from a known root. Upward traversal is a reverse-index query whose fan-out is proportional to component reuse — precisely the thing good engineering organisations maximise. The better your parts standardisation programme, the worse your where-used performance. Add effectivity and revision-rule filtering, and each level of the upward walk must also evaluate which revisions were valid when, which turns a cheap join into an expensive one.

Three mitigations are worth knowing. First, bound the query deliberately: most impact analyses need where-used to end-item level, not exhaustive multi-level expansion, and offering “used in which top-level products” as a distinct, materialised query is dramatically cheaper than a full traversal. Second, cache the reverse index and refresh it asynchronously rather than computing it live — impact analysis tolerates a few minutes of staleness far better than it tolerates a thirty-second spinner. Third, run impact analysis at change-request time, not change-notice time, so the expensive query happens once during analysis rather than repeatedly during implementation.

Aras’s Impact Matrix is the clearest UI expression of this idea: it presents the propagation of a part modification through the hierarchy as a reviewable grid rather than a report you wait for. The interaction model matters, because impact analysis is iterative — you scope, look, rescope.

Redlining is a proposal, not an edit

BOM redlining is the mechanism for proposing structural changes without committing them: mark a line for deletion, add a new component, change a quantity, and hold that delta against the change object until it is approved.

The architectural requirement is that the redline is a first-class delta object, not a checked-out working copy. If your implementation redlines by checking out the assembly and editing it, three things break. The released structure is now locked for the duration of the change, blocking every other change touching it. There is no reviewable diff, only a before and after that a reviewer must compare manually. And if the change is rejected, you must reliably undo the edit — an operation that is easy to get wrong when other changes have landed meanwhile.

Storing the delta separately gives you a change that can be reviewed as a delta, superseded, merged, or discarded without touching the released baseline. It also gives you the ability to detect conflicts: two in-flight changes redlining the same BOM line is a condition you want the system to raise at approval time rather than discover at release.

The change board: parallelising approval without losing control

Most change advisory boards are serial by accident. Design signs, then manufacturing signs, then quality, then supply chain — each step waiting for a queue it has no reason to wait for. If four functions each take three working days of wall-clock latency, serial approval costs twelve days and parallel approval costs three. Nothing about the review content changed. Only the topology did.

Figure 3: A parallelised change board — scope gate first, four concurrent reviews, one convergence point, timeboxed rework.

The scope gate comes before the reviewers

The gate at the front of Figure 3 is the highest-leverage element in the whole workflow, and it is the one almost nobody implements. Before routing to reviewers, ask one question: does this change have a single coherent root cause and a single effectivity intent?

If it does not — if it has become a basket of three unrelated fixes bundled to save process overhead — split it. Bundling feels efficient and is catastrophic for cycle time, because the approval latency of a bundled change is the maximum of its parts, not the mean, and its rejection probability is the union of its parts’ rejection probabilities. A change containing four items each with an independent 15% chance of objection has roughly a 48% chance of being sent back. Split into four, each clears on its own timeline and three of them ship while the fourth is reworked.

This is the mechanism behind most “our approvers are slow” complaints. The approvers are not slow. The changes are too big to approve.

Parallel review, single convergence, timeboxed rework

Once scoped, route all reviews concurrently. Each function reviews the same change against its own criteria — design reviews technical adequacy, manufacturing reviews producibility and tooling, supply chain reviews lead time and inventory exposure, service and compliance review field impact and regulatory notification.

The control you must not lose is convergence. Parallel approval fails when each reviewer can independently send the change back, because the change then bounces indefinitely with no single point where its state is knowable. Instead, collect all objections at one gate, and treat rework as a single timeboxed loop that addresses every objection at once before re-review. A change that has been round the loop twice should escalate automatically — a third loop almost always means the scope gate let something through it should not have.

Decouple approval from release

The last piece of workflow topology, and the most frequently violated: approving a change and releasing its resulting objects are different transitions, and coupling them destroys throughput.

When approval implies release, the change cannot be approved until every deliverable is complete — every drawing updated, every routing rewritten, every service bulletin drafted. The board therefore approves nothing for weeks while work it is not reviewing grinds on. Decoupled, the board authorises the change on the strength of the analysis, and change tasks complete and release their own deliverables on their own schedules under that authorisation.

This is exactly what the change-notice-plus-change-tasks decomposition is for. Windchill’s model of one change notice with many change tasks across CAD, eBOM, mBOM and documentation exists precisely so those workstreams do not block one another. Most implementations configure the objects and then wire a workflow that makes the notice wait for all tasks anyway, recreating the serial process inside a parallel data model.

Propagating the change: PLM to ERP to MES to supplier

Authorisation is the halfway point. The change becomes real when it reaches the systems that buy parts and build product.

Figure 4: Change propagation sequence — PLM change notice to ERP change master, MRP replan, supplier and MES release, and the as-built confirmation back to PLM.

The sequence shows the round trip that most integrations implement only in one direction. Engineering submits, the board approves and fixes effectivity, PLM publishes a BOM delta and change identifier to the ERP change master, MRP replans, the supplier gets a revised schedule and drawing package, MES gets the new routing at cut-in — and critically, MES confirms first article and WIP disposition back to PLM so the as-built record reflects what was actually built.

That last arrow is the one teams skip, and skipping it is why the as-built record diverges from the as-designed record within about two quarters of go-live.

The change master handshake

The PLM-to-ERP interface is narrower than people expect, and that narrowness is a feature. What crosses is: the change identifier, the affected material numbers, the BOM delta as add/change/delete lines with quantities, the effectivity expression, and the released document references. What should not cross is PLM workflow state, reviewer comments or lifecycle names — the ERP has no use for them and every field you map is a field you maintain.

SAP’s engineering change management applies changes to BOMs, task lists, materials and documents with history under date effectivity, or conditionally under parameter effectivity. The mapping question that decides whether your integration is sane is: does one PLM change notice map to one ERP change number? One-to-one is far easier to reconcile, and it is another argument for the scope gate — a change notice too broad to map to a single change master is a change notice that should have been split.

The in-flight inventory problem

This is where change management becomes genuinely hard, and where most implementations have no answer at all.

At the moment a change takes effect, the material in your system exists in at least five states: finished goods already shipped to customers, finished goods in the distribution network, work in process on the shop floor at various stages, raw and purchased stock in the warehouse, and open purchase orders with suppliers. A change decision that addresses only the fifth — “update the drawing, tell the supplier” — leaves the other four undefined, and each one becomes a manual reconciliation somebody does under time pressure later.

A complete change decision states the disposition of every state. Use as-is, rework to the new configuration, scrap, or return to supplier — per state, with an owner. This disposition matrix belongs on the change object itself, not in a spreadsheet attached to it, because it is the input to the ERP’s inventory transactions and to the service organisation’s field policy.

Stranded WIP is the specific failure. A change goes effective on a date, the shop floor has 400 units mid-build against the old routing, nobody decided what happens to them, and they sit in a holding area for six weeks while engineering, quality and finance argue about who absorbs the cost. The units are not the problem. The undefined decision is.

Supplier notification lag

The external leg is the slowest and the least instrumented. A supplier needs the revised drawing, the revised specification, a purchase order or schedule change, and confirmation that they have tooling and material to comply by the effectivity point. Supplier tooling lead time is frequently the binding constraint on effectivity, and it is frequently discovered after effectivity has been set, forcing a change to the change.

The architectural fix is to make supplier confirmation an explicit change task with its own completion state, and to make effectivity provisional until that task closes. A change whose effectivity was set before the supplier confirmed capability is a change that will be revised.

Interchangeability: revise, or issue a new part number?

Underneath all of this sits a rule that predates PLM entirely and still decides more change outcomes than any workflow: form, fit and function.

Form is the physical characteristics — geometry, dimensions, mass. Fit is how the part interfaces with its neighbours — mounting points, connectors, envelopes. Function is what it does — its operational and performance characteristics.

The rule is straightforward to state. If the new design is interchangeable with the old across form, fit and function, a revision of the existing part number is sufficient. If it is not interchangeable, the new design requires a new part number, and every assembly that must use the new design has to be revised to reference it.

The consequences are asymmetric, which is why the rule is so often violated in both directions. Revise when you should have renumbered, and you have created a situation where one part number denotes two physically different, non-substitutable things — the warehouse cannot tell them apart, service ships the wrong one, and no as-built record can be trusted. This is the more dangerous error and the harder to unwind. Renumber when a revision would have done, and you inflate the item master, force revisions of every parent, and generate a change avalanche for no engineering benefit.

The judgement problem is that interchangeability is directional and context-dependent. A new part may be usable in place of the old but not vice versa — a strengthened bracket, for instance, or a higher-rated capacitor. One-way interchangeability is common and most PLM item models have nowhere to record it, so it lives in a note somebody reads or does not. If your product mix makes this frequent, model it explicitly as a substitution relationship with a direction, rather than pretending the binary rule covers it.

The practical test I would give a reviewer: could a stores operator, holding both parts, pick either one for any open order without checking anything? If not, it is a new part number.

Service, as-maintained BOM, and the change nobody scoped

Engineering change management processes are usually designed by people who think about the factory, and the factory is roughly half the problem.

Once product is in the field, three more structures exist. The as-maintained BOM records the current configuration of a specific unit including every part replaced during its life. The service BOM defines what is serviceable, in what kits, with what procedures. And the installed base records which configuration each customer actually has.

A change that alters a serviceable part propagates into all three, and the propagation is not automatic. Questions that must be answered explicitly: does the new part fit units built before cut-in? Is the old part still procurable for spares, and for how long? Does the service procedure change? Do field units get retrofitted, and is that mandatory, on-failure, or on-request? Does the change trigger a regulatory notification?

Retrofit policy is where this bites hardest. A mandatory retrofit is a field campaign with its own cost, logistics and traceability requirements, and it must be recorded per unit in the as-maintained structure so that the next technician knows which configuration is in front of them. Very few change processes carry a field-disposition decision as a required field on the change object. Almost all of them should, because the alternative is a service organisation reverse-engineering engineering’s intent from a BOM delta.

There is a legitimate architectural argument that service impact assessment should be a review object on the change request — assessed during analysis — rather than a change task on the notice, because it can change whether the change is worth doing at all. Discovering after authorisation that a change requires a 20,000-unit field campaign is discovering it too late.

Trade-offs, gotchas, and what goes wrong

The change avalanche. One low-level part changes, every parent must be revised, each parent revision is itself a change, and the board’s queue explodes. This is the direct consequence of revision-pinned BOM references combined with deep assemblies. It is not always avoidable — regulated industries often require the precision — but it is manageable by batching parent revisions under a single change notice rather than generating one per level.

Effectivity drift. Effectivity is set at approval, implementation slips, and the effectivity date passes before the deliverables are ready. The change is now “effective” against a configuration that does not exist. Guard against it by making effectivity a value confirmed at release rather than fixed at approval, or by adding a hard validation that refuses release when the effectivity point is already in the past.

Stranded WIP. Covered above, and worth repeating because it is the most expensive routine failure in change management. The root cause is always the same: no disposition decision for material in process.

Supplier notification lag. Effectivity set without supplier tooling confirmation. The change then gets revised, and revised changes are the single clearest signal of a broken scope gate.

Approval coupled to release. Boards that cannot authorise until deliverables are complete. Symptom: long-lived changes in a state called something like “in work” that nobody can report on.

Over-broad scope. The parent of most of the above. Bundled changes have union rejection probability and maximum latency.

Where-used timeouts. Impact analysis that takes minutes drives engineers to skip it, which is worse than slow analysis. If the query is slow, bound it or cache it — do not leave it slow and hope.

Variance abuse. Every engineering change management deployment eventually discovers this one. Windchill’s variance object exists to record a bounded, time-limited or quantity-limited deviation. Used properly it is valuable. Used as a permanent workaround, it becomes a shadow configuration that no BOM reflects, and the as-built record silently becomes wrong.

Silent dual paths. Express or fast-track changes are a genuine good, but only with an explicit, enforced eligibility rule. Without one, the fast path becomes the default and the controlled process becomes theatre.

Measuring what matters: change cycle time

Most change dashboards count open changes. Open-change count is a level, not a rate, and it tells you almost nothing actionable. The measure that matters is cycle time, decomposed.

Instrument four intervals separately, all in calendar days, all reported as median and 90th percentile rather than mean — change duration distributions are heavily right-skewed and the mean is dominated by a handful of monsters.

Intake to analysis complete — problem report raised to change request approved. Long here means investigation capacity or unclear ownership.

Analysis to authorisation — change request approved to change notice approved. This is board latency, the interval everyone assumes is the whole problem. Measure it before you attack it.

Authorisation to implementation complete — notice approved to last change task closed. Long here means resourcing or deliverable dependency, not approval.

Implementation to effectivity realised — the gap between “engineering says done” and “the factory is actually building it.” This is the interval nobody measures and the one where ERP propagation, supplier lead time and WIP disposition hide.

Alongside these, three secondary metrics earn their place. Rework rate — the percentage of changes sent back at least once — is a direct readout on scope-gate quality; above roughly 20% and your changes are too big. Change velocity — closed per week versus opened per week — tells you whether the backlog is growing regardless of its absolute size. And revised-change rate — changes whose effectivity or scope changed after authorisation — is the sharpest single indicator that authorisation is happening on incomplete information.

One caveat on benchmarking. Published industry figures for average ECO cycle time vary by an order of magnitude depending on industry, change class and where the clock is deemed to start, so treat any external number as a conversation starter rather than a target. Your own trend over quarters is worth far more than another company’s median. The one comparison worth making externally is between your emergency and routine change paths: if emergency changes clear in three days and routine ones take sixty, the routine process is not slow because of the work involved, and the emergency path is quietly showing you what is possible.

Change data is also one of the more tractable targets for the language-model tooling now appearing in PLM — classification, duplicate detection and impact summarisation are pattern-matching problems over structured history, which is a topic I have taken up separately in AI-native PLM and LLMs over engineering data.

Practical recommendations

Treat engineering change management as a data-modelling exercise first and a process exercise second. Start with the object model, not the workflow. If your problem reports, change requests and change notices are not separate objects with separate lifecycles, no workflow tuning will fix your cycle time — you are trying to schedule four decisions that share one state machine.

Put a scope gate in front of the board and enforce it. One root cause, one effectivity intent, one ERP change master. Splitting is cheap; bundled rejection is not.

Decide the effectivity model per change class rather than per change, and document the rule. Ad-hoc effectivity selection by whoever is filling in the form is how effectivity drift starts.

Get the inventory position onto the change screen. Nobody sets a cut-in date badly on purpose; they set it badly because the warehouse balance and supplier lead time were in a different system.

A working checklist before you authorise any change:

Single root cause confirmed, and the change maps to exactly one ERP change master
Where-used impact analysis complete to end-item level, with review objects distinguished from affected objects
Interchangeability assessed against form, fit and function, with the revise-versus-renumber decision recorded and justified
Effectivity type selected from the decision matrix, with supplier capability confirmed before the effectivity point is fixed
Disposition recorded for all five material states: shipped, distribution, WIP, stock, open POs
Service and as-maintained impact assessed, including retrofit policy and spares availability
Change tasks decomposed so that CAD, mBOM and documentation workstreams can complete independently
Approval and release explicitly decoupled, with the release gate owned by the task rather than the board

Frequently Asked Questions

What is the difference between an ECR and an ECO?

An engineering change request proposes and justifies a change — it captures root cause, options, cost and business case, and answers “should we do this?” An engineering change order (called an engineering change notice in Teamcenter and Windchill) is the authorisation and implementation plan — it identifies affected items, assigns work, and answers “how and when do we do it?” One ECR may spawn several ECOs, and one ECO may resolve several ECRs. They are separate objects so that the decision to change and the execution of the change can proceed on different timelines with different approvers.

Why does engineering change management need a separate problem report object?

Because most reported problems do not become changes. A problem report records an observation — a field failure, a warranty pattern, a supplier quality issue — before anyone knows whether a design change is the answer. Keeping it separate lets you triage, cluster related reports, and close ones resolved another way, without polluting your change metrics with investigations. It also gives quality and service a place to raise issues without needing to propose an engineering solution first.

When should a change get a new part number instead of a revision?

Apply the form, fit and function rule: if the new design is fully interchangeable with the old in physical form, interface fit and functional performance, revise the existing part number. If it is not interchangeable in any of the three, issue a new part number and revise the parents that must use it. The practical test is whether a stores operator could pick either part for any open order without checking. Revising a non-interchangeable change is the more damaging error, because one part number then denotes two different physical things.

Unit or serial effectivity, wherever the end item is serialised. Safety and regulatory changes require you to state exactly which physical units carry the new configuration and which do not, and date effectivity cannot make that promise if build sequence slips. Teamcenter supports unit-number effectivity in revision rules and effectivity groups, and SAP’s SERNR effectivity type carries serial-interval effectivity into ERP. Where units are not serialised, lot effectivity is the next-best option; plain date effectivity is generally insufficient for regulatory defence.

Why are where-used queries slow in PLM systems?

Because they traverse the BOM graph upward with unbounded fan-out. Downward expansion starts from one root and is bounded by that assembly’s size; where-used starts from a leaf and must find every parent, then every parent of those, across the whole product portfolio. Component reuse — the thing good engineering maximises — makes it worse. Adding revision-rule and effectivity filtering means each level also evaluates which revisions were valid when. Bound the query to end-item level, cache the reverse index, and run it during analysis rather than repeatedly during implementation.

How do I stop the change board from becoming a bottleneck?

Usually the board is not the bottleneck — change scope is. First, add a scope gate that splits bundled changes before routing, since a bundled change inherits the maximum latency and union rejection probability of its parts. Second, route functional reviews in parallel with a single convergence point rather than serially. Third, decouple approval from release so the board can authorise on the analysis without waiting for every deliverable. Measure board latency separately from implementation latency before assuming which one is actually long.

Engineering Change Management Architecture: ECR to ECO in PLM (2026)

Engineering Change Management Architecture: ECR to ECO in PLM (2026)

Context and Background

The Engineering Change Management Reference Architecture

Why the objects are separate, not one ticket