Creating a Change Request, routing it for review, approving it, and eventually creating an Engineering Change Order is relatively straightforward. Most PLM systems can represent a workflow.
The difficult part begins when the organization has to answer what the workflow alone cannot explain.
What is actually affected? Which revisions must be created? Is the same item already part of another active change? What happens to the MBOM? Where does the change need to be implemented? How do we know that every required implementation step is complete?
These questions are the difference between moving a change through a process and actually controlling change across the product lifecycle.
A useful change-management environment should help teams answer:
- What is affected by this proposed change?
- Which product structures, documents, requirements, suppliers, and manufacturing definitions are involved?
- Which new revisions or resulting items are required?
- What implementation work must happen, and who owns it?
- Are there conflicting or overlapping active changes?
- Is the change complete everywhere it needs to be?
- What evidence proves the change is ready to close?
What Is Engineering Change Impact Analysis?
Engineering change impact analysis is the structured evaluation of everything that may be affected when a product definition changes.
The analysis should go beyond the changed item itself. A component may be used in multiple assemblies, manufacturing structures, product variants, documents, supplier relationships, requirements, or released configurations. A change that looks local can therefore create consequences several levels away from the original object.
The purpose of impact analysis is to identify those consequences before implementation begins so the organization can make a controlled decision and plan the work required to execute it.
Impact area | Questions to evaluate |
Items and revisions | Which items change? Which resulting revisions or new items are required? |
BOM / product structure | Which parent assemblies and downstream products use the affected item? |
MBOM / manufacturing | Does the manufacturing structure require a different revision, replacement, or implementation action? |
CAD and documents | Which models, drawings, specifications, work instructions, or technical documents need updates? |
Does the change alter or conflict with any linked requirement? | |
Suppliers and sourcing | Are supplier approvals, alternates, lead times, or sourcing decisions affected? |
Quality and validation | Is new inspection, testing, or qualification required? |
Other active changes | Is the same item or product context already involved in another change? |
Why the Workflow Is Only the Beginning
A workflow can tell you that a change is 67% complete. That is useful, but it does not automatically tell you whether the correct affected items were identified, whether the manufacturing structure is ready, or whether an implementation task is still missing.
This is why engineering change management needs more than a sequence of states. Teams need a working context that brings together scope, impact, decisions, approvals, implementation, verification, and product relationships.
In practical terms, the change should become a place where the team can understand the whole story instead of reconstructing it across separate forms and screens.
A Better Model: Scope, Impact, Implement, Verify
- Define the scope: Clarify the problem, proposed change, reason, affected product area, and expected outcome.
- Connect the change to product context: Link the request to the relevant items, assemblies, BOMs, documents, requirements, suppliers, and manufacturing structures.
- Analyze impact: Identify affected end items, parent assemblies, resulting revisions, manufacturing consequences, dependencies, and overlapping changes.
- Make the decision: Route the right reviewers and approvers based on the actual impact, not only a generic workflow template.
- Plan implementation: Break the approved change into Engineering Change Tasks or implementation actions with clear owners and due dates.
- Implement across functions: Update engineering, manufacturing, documentation, sourcing, quality, and other required contexts.
- Verify readiness: Confirm that required resulting revisions, tasks, approvals, and implementation evidence are complete.
- Close with traceability: Preserve the history of what changed, why, who approved it, what was implemented, and how completion was verified.
The Change Cockpit: Managing a Change as a Working Context
Nora IPLM approaches engineering change management as a connected working context rather than a collection of isolated forms.
The Change Cockpit brings affected items, impact analysis, approvals, implementation work, readiness, status, and product context into the same environment. This reduces the need for users to jump between separate screens and mentally reconstruct how the change fits together.
The objective is not simply to make the workflow visually attractive. It is to make the change easier to understand and manage in context.
A cockpit-style change environment can bring together:
- change progress and KPIs
- affected items and resulting revisions
- relationship and navigation maps
- approvers and responsible owners
- implementation tasks
- validation readiness
- warnings and failed checks
- 3D product context
- Knowledge Thread relationships
- lifecycle state and release information
Example: A Change to an Industrial Forklift Assembly
Consider a change to an industrial forklift truck assembly. The engineering team wants to modify a component after an issue is identified.
The change cannot be treated only as a form moving from In Work to Approved. The team must determine which forklift assemblies use the component, whether the same item is already part of another active change, which new revision is required, and whether manufacturing needs a corresponding MBOM update.
The implementation plan may include an engineering revision, a manufacturing task, a supplier action, a quality validation, and a controlled release. If one of those actions is missing, the change may be approved but not actually implemented everywhere it should be.
Change question | Example forklift context |
What is affected? | Forklift item, parent assembly, BOM positions, related documents, and manufacturing structure. |
What revisions are needed? | New revision for the changed component and any parent structure that requires formal release. |
Is there overlapping work? | Check whether the same item is already involved in another change or task. |
What happens to manufacturing? | Review the MBOM and any plant-specific implementation requirements. |
Who owns implementation? | Engineering, Manufacturing, Quality, Procurement, or other assigned owners. |
How do we know it is complete? | Required tasks, resulting revisions, checks, approvals, and implementation evidence are all complete. |
Why Implementation Tracking Matters
One of the most common weaknesses in change processes is the gap between approval and implementation. A change can be fully approved while the actual work is still incomplete.
A released engineering revision does not prove that manufacturing instructions were updated. A completed ECO does not automatically prove that every plant implemented the change. A supplier notification does not prove that old inventory was handled correctly.
Implementation tracking closes that gap by connecting the decision to the work required to make the new product definition real.
Implementation evidence may include:
- resulting item or document revisions
- completed Engineering Change Tasks
- updated EBOM or MBOM structures
- manufacturing or work-instruction updates
- supplier or sourcing actions
- quality validation or test evidence
- effectivity or release conditions
- final verification checks
Change Verification: How Do You Know the Change Actually Happened?
Verification should answer a different question from approval. Approval asks whether the organization agrees that the change should proceed. Verification asks whether the approved change has been implemented correctly and completely.
A mature change process should therefore include explicit readiness checks before closure. Missing approvers, incomplete tasks, unresolved affected items, or missing resulting revisions should remain visible until the change is truly ready to close.
Verification check | What it confirms |
Affected items identified | The change scope includes the product records that need attention. |
Resulting revisions created | The approved product definition exists in the correct revision state. |
Tasks complete | Required implementation work has been carried out by the assigned owners. |
Approvals complete | The required decision makers have approved the change. |
Manufacturing updated | The relevant production or MBOM context reflects the approved change. |
Validation complete | Required quality, test, or readiness evidence is available. |
No unresolved conflicts | Overlapping changes, warnings, or failed checks have been addressed. |
Why Change Impact Needs the Digital Thread
Engineering changes rarely stay inside one object. Their impact travels through relationships.
An item belongs to an assembly. The assembly belongs to a product. That product may have manufacturing structures, requirements, documents, suppliers, quality records, projects, and downstream configurations. Understanding change impact therefore depends on being able to follow those relationships.
This is where the Digital Thread becomes operational. It is not only a data model showing that information is connected. It becomes a way to explore dependencies, identify affected context, and support better change decisions.
From Workflow Management to Change Intelligence
Once impact, relationships, implementation, and readiness are connected, change management can support more than routing and status tracking.
Teams can analyze dependencies before approval, identify conflicts with active changes, prioritize implementation work, and surface missing information before closure.
AI can also become more useful because it has access to a richer product context. Instead of reasoning from one form or document, an AI assistant can work across the affected items, relationships, requirements, tasks, and change history that surround the decision.
Examples of useful questions include:
- Which released products could be affected by this item change?
- Is this item already involved in another active change?
- Which MBOM structures need review?
- Which implementation tasks are still incomplete?
- Which approvals or validations are blocking readiness?
- What similar changes have we implemented before?
Cockpits as a Broader PLM Interaction Model
The Change Cockpit is also an example of a broader interaction model in Nora IPLM.
Complex product work often requires users to understand structures, relationships, tasks, status, exceptions, and decisions at the same time. A cockpit brings those elements together on one page so the user can work in context instead of navigating through disconnected object screens.
Change Management is the first area where Nora IPLM applies this approach, but the same concept can support other product-lifecycle processes where context matters as much as the individual record.
Best Practices for Engineering Change Impact Analysis
Start with product context, not only the form: Connect the change to the actual items, assemblies, documents, requirements, and manufacturing structures involved.
Identify affected end items early: Do not wait until implementation to discover which released products use the changed component.
Check overlapping changes: A technically valid change can conflict with another active change to the same item or assembly.
Separate approval from implementation: An approved decision is not the same as completed implementation.
Use explicit readiness checks: Make closure dependent on evidence such as completed tasks, resulting revisions, required approvals, and validation.
Keep manufacturing in the loop: Review MBOM, plant, process, and production impact when the engineering definition changes.
Preserve traceability: Keep the original reason, impact analysis, decisions, implementation work, and verification evidence connected to the change history.
Engineering Change Management Should Prove That the Change Happened
Engineering change management is often presented as a workflow problem. But routing a form is usually the easy part.
The harder problem is understanding what the change affects, deciding what must be updated, coordinating implementation across functions, and proving that the new product definition has been adopted everywhere it should be.
That is why a stronger change-management environment needs to bring impact, decisions, approvals, implementation, and verification together in one connected working context.
The goal is not simply to move a change from Open to Closed. The goal is to understand its impact and make sure the change actually happens.
Frequently Asked Questions
What is engineering change impact analysis?
Engineering change impact analysis is the evaluation of which items, assemblies, BOMs, documents, requirements, manufacturing structures, suppliers, and other product records may be affected by a proposed change.
Why is impact analysis important before an ECO is implemented?
It helps teams understand the real scope of the change, identify downstream consequences, assign the right reviewers, and plan implementation before product data is revised.
What is the difference between change approval and change implementation?
Approval authorizes the change. Implementation is the work required to update the affected product definition, manufacturing context, documents, suppliers, and other required areas.
How do you know an engineering change is complete?
A change is complete when the required resulting revisions, implementation tasks, approvals, validations, and downstream updates are finished and verified.
How does PLM help with engineering change impact analysis?
PLM keeps product structures and related records connected, making it easier to identify where-used relationships, affected objects, revisions, and downstream dependencies.
Can one item be involved in more than one engineering change?
Yes. That is why overlapping active changes should be identified before implementation to avoid conflicting revisions or duplicated work.
Why should MBOM impact be included in engineering change management?
A change to the engineering definition may require a corresponding manufacturing update. The MBOM, plant context, manufacturing-specific items, or implementation timing may need review even when the engineering change appears simple.
What is a Change Cockpit in Nora IPLM?
The Change Cockpit is a working environment that brings change progress, affected items, impact analysis, approvals, implementation work, readiness, and product context together so users can manage the change without reconstructing its story across separate screens.
See the consequence before you commit to the change
Discover how Nora IPLM Knowledge Thread turns connected product data into a traceable AI Change Impact Simulation, from qualified evidence and visual propagation to alternate-item, carbon, and AI-assisted analysis.
