Engineering changes rarely affect Engineering alone. For teams responsible for manufacturing, PLM, quality and operations, the real challenge is ensuring that an approved design change reaches production with the right product data, process information and implementation context intact. This article examines what happens after Engineering releases a change, where delays and information gaps typically emerge, and how connected product lifecycle management can support more controlled implementation across manufacturing processes, systems and sites.

An engineering change can look deceptively simple. A component is replaced, a material specification changes, or a tolerance is adjusted after testing. Engineering updates the model, revises the BOM, completes the approval workflow and releases a new version.

From an engineering perspective, the work may be finished. For manufacturing, this is often where another process begins.

The new definition may affect the manufacturing BOM, assembly sequence, tooling, work instructions, inspection requirements or production planning. If the same product is manufactured at several locations, individual plants may also have different equipment, suppliers, inventory positions or implementation schedules.

This is why engineering change management should not be judged only by how efficiently Engineering approves a revision. What matters just as much is whether the organisation can translate that revision into a correctly implemented manufacturing change without losing context or control along the way.

In practice, engineering change management involves more than approving a revision. It connects the engineering design process with configuration management, product data management, manufacturing planning, quality processes and downstream execution. The effectiveness of these change processes therefore depends not only on how quickly a decision is made, but also on how reliably its context follows the change through the organisation.

From engineering change request to factory-floor implementation

Consider a relatively ordinary component substitution. Engineering replaces a purchased part with an alternative that meets the same technical requirements. The EBOM is updated, documentation is revised and the change is released.

Before that release, however, the proposed modification usually needs to be documented, evaluated and approved. An Engineering Change Request (ECR) provides a formal way to capture the proposed change and its technical or business justification. Depending on the organisation and its PLM configuration, an Engineering Change Order (ECO)/Engineering Change Notice (ECN) or equivalent change object then controls or communicates the approved implementation. Terminology and sequencing differ between organisations, but establishing standard workflows for ECRs, ECOs/ECNs creates a clearer connection between the original request, the decision and the resulting product definition.

Manufacturing still needs to establish whether the new component enters the process at the same operation, whether existing tooling can be used, whether inspection characteristics remain valid and when the new part should become effective in production. Existing stock of the previous component may still need to be consumed. In a multi-site organisation, different plants may not even be able to introduce the change under the same conditions. 
 
In many organisations, the challenge is not only deciding what changes, but also when the change becomes effective. Manufacturing may introduce a revision based on a specific date, serial number range, production batch or inventory depletion strategy. Two plants can therefore implement the same engineering change at different moments while remaining fully compliant with the approved product definition.

A one-line modification in an engineering BOM can therefore create several downstream decisions.

This is where the relationship between EBOM and MBOM becomes particularly important. The engineering structure represents the product according to design logic, while the manufacturing structure represents how the product will actually be built. They need to stay related, but they are not supposed to be identical.

Between the engineering and manufacturing perspectives, process planning introduces an additional dimension. Manufacturing readiness is not determined solely by how product structures are organised, but also by the operations, sequences and resources required to build the product. A manufacturing change therefore needs to be evaluated in both the MBOM and the associated process plans.

The practical value of this relationship is that Manufacturing can assess the impact of an engineering change against its existing product structure instead of repeatedly reconstructing that connection from spreadsheets, exports or individual knowledge.

This relationship is also fundamental to configuration management. ISO 10007:2017 provides guidance on configuration management across the product lifecycle, covering configuration management planning, configuration identification, change control, configuration status accounting and configuration audit. In practical terms, proper management of configuration information helps an organisation understand not only which revision is current, but also how that state was reached and where it applies.

Change does not stop at the MBOM

EBOM-MBOM synchronisation receives a lot of attention in manufacturing process management, but an updated MBOM does not automatically mean that production is ready.

Manufacturing also depends on operations, sequences, allocated parts, tools, work centres, skills and operator instructions. A design modification can leave the MBOM structurally correct while making the process used to manufacture the product obsolete.

The downstream impact can be viewed across five layers:

Layer Example impact of an engineering change 
Product structure A part is replaced, added or removed 
Manufacturing structure The component needs to be reassigned or represented differently in the MBOM 
Process definition An operation, sequence, tool, resource or quality check needs to change 
Production information Work instructions and data transferred to ERP or MES need to reflect the new state 
Effectivity management Serial number, lot, date or plant-specific implementation rules need to be defined 

Imagine that a replacement component requires a different torque value. The EBOM may be correct and the MBOM may already be updated, but if the operator still sees the previous value in the work instruction, the change has not been successfully implemented.

This is why manufacturing readiness needs to cover more than product structures. The complete path includes the engineering definition, manufacturing structure, process planning and the information eventually consumed by production.

The same principle applies to quality processes. If a design change modifies an inspection characteristic, acceptance criterion or testing requirement, the related quality information also needs to reflect the new product definition. Otherwise, Engineering and Manufacturing may already be working with the revised configuration while Quality continues to verify the product against an earlier state.

The need for this level of control becomes even more visible in industries that manage complex products, long lifecycles and demanding quality or compliance requirements. Automotive, aerospace and defense organisations, for example, often need to understand precisely which configuration applies to a particular product, production stage or site. Medical device manufacturers face a similar challenge: changes to medical devices can affect product, manufacturing and quality information at the same time. Although the regulatory context differs between industries, the underlying operational problem is consistent — an approved change needs to remain connected to every downstream element it affects.

The hidden cost of change latency

Not every synchronisation problem creates a visible production incident. Very often, experienced people compensate for gaps in the process.

A manufacturing engineer compares two BOM versions. A planner notices that a routing has not been updated. Someone sends the latest drawing directly to the plant. An experienced employee confirms a change before production starts.

The line keeps running, so the process appears to work. The cost is hidden in the hours spent reconciling information, checking applicability and confirming that downstream data is current. 

For one change, this effort may be negligible. Across thousands of changes, several product lines and multiple factories, it becomes part of the operating model.

This is why change latency can be a useful measure. Instead of looking only at how long it takes to approve an engineering change, organisations can also consider the time between engineering release and verified manufacturing readiness.

Depending on the change, this may include:

  • reviewing affected manufacturing structures
  • updating process plans and operations
  • confirming plant-specific applicability
  • updating work instructions
  • transferring the approved manufacturing state to ERP, MES or other production systems

A company may reduce its engineering approval cycle from five days to three, but if Manufacturing still needs another two weeks to reconcile and implement the result, the improvement for the wider value stream is limited.

As product development accelerates, the ability of downstream processes to absorb change becomes increasingly important.

The business impact can also be significant. According to McKinsey & Company, efficiently executing engineering changes can reduce product development time by up to 33%. But shortening the engineering cycle creates limited value if delays simply move downstream into manufacturing implementation.

Change latency is also relevant to risk management. The longer an organisation relies on spreadsheets, manual comparison or individual knowledge to establish whether a revision has been implemented correctly, the harder it becomes to identify where an outdated configuration is still being used.

Multi-site manufacturing changes the equation

The challenge becomes more complex when the same product is manufactured in several plants. The engineering definition may be global. The manufacturing reality rarely is.

One facility may use automated assembly equipment while another relies on manual operations. Tooling can differ. Local suppliers may differ. One plant may be able to introduce a revision immediately, while another needs to consume existing inventory first. A global engineering change therefore does not always result in one identical manufacturing action.

The goal is not to eliminate all plant-specific variation. Many of these differences are operationally justified. The goal is to make them visible and controlled. For a significant change, the organisation should be able to establish:

  • which plants and manufacturing structures are affected
  • whether existing process plans remain valid
  • which local deviations need to be maintained
  • when the revised definition becomes effective at each site
  • who is responsible for confirming implementation

At this point, engineering change becomes more than a PLM workflow. It becomes a governance process involving Engineering, Manufacturing, Operations and often Supply Chain or Quality.

Better governance is not simply more workflow

When changes are being lost between Engineering and Manufacturing, adding another review or approval step may seem like an obvious solution. Sometimes it is necessary. But additional workflow does not solve disconnected information.

Before deciding who should approve a manufacturing change, the organisation needs to know which manufacturing structures are related to the engineering definition, which process plans use the affected elements, where the change applies and which downstream systems depend on the new information. These relationships form the foundation of change governance.

For changes that require formal cross-functional review, an organisation may use a Change Control Board (CCB), also referred to in some environments as a change review board. It brings together stakeholders from relevant functions to assess the technical, manufacturing, quality and business implications of a proposed change. Depending on the organisation’s governance model, the board can approve, reject, return or defer a change request before implementation proceeds. PTC, for example, describes the ECR process as including evaluation of technical and business justification as part of formal change review and approval.

The participants depend on the change. Engineering, Manufacturing, Quality and Supply Chain may all need to contribute, while a project manager may coordinate activities when implementation spans several functions, sites or project milestones. The purpose of cross-functional review is not simply to collect more approvals, but to expose downstream consequences before the change reaches production.

Traceability is equally important. A controlled change record should make it possible to establish what changed, why the change was necessary, who reviewed or approved it, when it became effective and which product or process information was affected. This gives teams a documented connection between the decision and the resulting configuration instead of forcing them to reconstruct that history later.

It is also important not to confuse governance with full automation. Manufacturing decisions cannot always be derived automatically from an engineering change. Manufacturing Engineering still needs to decide how a product should be produced, which operations are affected and whether plant-specific processes remain valid.

The PLM environment should support those decisions with connected product and process context rather than forcing teams to reconstruct it each time.

The change does not stop at PLM

There is another boundary where continuity can be lost: the transfer of manufacturing information into ERP, MES and other execution systems.

The information chain is broader than EBOM-MBOM:

Engineering definition -> Manufacturing definition -> Process planning -> Execution systems -> Shop floor

A change may be complete in PLM while the corresponding information in ERP is still waiting to be updated. A revised process plan may exist, while MES continues to serve an older work instruction. A plant may receive an updated BOM without the related process information.

This is why integration architecture becomes part of engineering change management. From an operational perspective, what matters is not only whether individual systems work correctly, but whether product change can move through them without repeatedly losing or recreating context.

Windchill MPMLink does not remove the need for manufacturing judgement, and that is not its purpose.

Its value lies in maintaining relationships between engineering structures, manufacturing structures, process plans and manufacturing resources within the PLM environment. That gives Manufacturing a better basis for assessing downstream impact when Engineering releases a change.

Instead of asking:

„Did Manufacturing receive the latest revision?”

the organisation can ask:

„Which manufacturing structures and processes are affected, and what needs to be reviewed before this revision reaches production?”

The first question is about communication. The second is about impact management.

Engineering change is not the problem

Product organisations will continue to generate engineering changes. Components become unavailable, customers introduce new requirements, quality improvements are made and Manufacturing itself provides feedback that leads to product updates.

Not every manufacturing change originates in Engineering. Quality incidents, supplier issues, production deviations or service feedback can also initiate change. Mature organisations increasingly manage change as a closed-loop process where information flows not only from Engineering to Manufacturing, but also back from Manufacturing, Quality and Service into product development.

A mature organisation should therefore not measure success by its ability to avoid change. A more useful measure is how predictably it can absorb it.

That requires continuity between the engineering definition, manufacturing structures, process plans and downstream production systems. MPMLink can support that continuity by keeping engineering and manufacturing information related while still allowing Manufacturing Engineering to make its own decisions about how a product should be produced.

In practice, this is where manufacturing process management creates the most value – not simply by creating an MBOM, but by reducing the amount of manual interpretation required between an engineering change and its implementation on the factory floor.

The result is not simply better administration of engineering changes. More consistent implementation can reduce rework, protect quality processes and give manufacturing teams greater confidence that they are working with the intended product and process definition. Over time, that supports more predictable delivery and customer satisfaction without trying to eliminate the engineering changes that are a normal part of product development.