AI for Engineering Knowledge Management
Where-used analysis in PLM finds every part, assembly, and document affected by an engineering change. Learn how to run reliable impact analysis.
·
⏱
7 min read
Michelle Ben-David
Michelle Ben-David is a mechanical engineer and Technion graduate. She served in an IDF elite technology and intelligence unit, where she developed multidisciplinary systems integrating mechanics, electronics, and advanced algorithms. Her engineering background spans robotics, medical devices, and automotive systems.
BOTTOM LINE
Where-used impact analysis is one of the highest-value activities in engineering change management, because a missed dependency is the difference between a controlled revision and a field failure. The mechanics are straightforward, walk the relationship graph upward and return everything that touches the part, but the value of the answer is capped by the completeness of the relationships and metadata behind it. No process discipline can fully compensate for data that was never captured.
The practical path forward is to keep improving PLM data hygiene while using AI to read both structure and geometry, so the impact list reflects what the product really contains rather than only what someone remembered to record. That combination gives engineers fast, trustworthy where-used results today, and it lets every Engineering Change Order rest on evidence instead of hope.
A single fastener can sit inside forty assemblies. A bracket revision can ripple into drawings, work instructions, supplier agreements, and a customer-facing spare parts catalog. Before any engineering change moves forward, someone has to answer a deceptively simple question: where is this part used, and what breaks if we touch it?
That question is the heart of where-used impact analysis. In a Product Lifecycle Management (PLM) system, a where-used query takes a part and returns every assembly that contains it, every document that references it, and every process that consumes it. Done well, it turns a guessing game into a verifiable list. Done poorly, or against incomplete data, it sends a change through approval with hidden landmines still buried in the product structure.
This article explains how where-used and change impact analysis actually work, why result quality depends so heavily on the completeness of relationships and metadata, and how engineering teams can get trustworthy answers even when their PLM data is messy.
What a Where-Used Query Really Does
A PLM system stores product data as objects connected by relationships. Parts link to the assemblies that contain them. Drawings link to the parts they describe. Process plans link to the parts they produce, and supplier records link to the parts they source. A where-used query walks those relationships in reverse. Instead of asking what a part is made of, it asks what depends on the part.
There are two common forms. A single-level where-used returns only the immediate parents, the assemblies that directly call out the part. A multi-level, or top-level, where-used keeps climbing until it reaches the finished products at the top of every structure that contains the part. The difference matters. A washer might appear in three sub-assemblies, but those sub-assemblies might roll up into twenty different end products. A single-level view would badly understate the reach of a change.
Where-used is the inverse of the bill of materials. A BOM explodes downward from a product into its components, while a where-used query implodes upward from a component into everything that uses it. Both rely on the same relationship graph, so the quality of one predicts the quality of the other. Teams that struggle to keep their BOMs clean tend to struggle with where-used results too, which is why disciplined BOM management and reliable impact analysis go hand in hand.
IN PRACTICE
The connection to our PDM and using that as a data source is legit the best thing ever. I found three viable bracket options fitting my exact envelope constraints, in minutes, not days.
Eytan S., R&D Engineer
From Where-Used to Change Impact Analysis
A where-used query is a tool. Change impact analysis is the discipline that uses it. Impact analysis is the structured evaluation of everything that would change if a proposed engineering change were approved. It is the step that turns an Engineering Change Request into an informed Engineering Change Order, rather than a leap of faith.
A thorough impact assessment goes beyond the parts list. It asks a connected set of questions:
Which assemblies and end products contain the affected part, directly and indirectly?
Which drawings, specifications, and work instructions reference it and must be reissued?
Which suppliers provide it, and what inventory or open purchase orders are exposed?
What are the cost, tooling, and schedule consequences across every affected product line?
Industry guidance is consistent on this point. An Engineering Change Order should show directly and indirectly affected items, assemblies, drawings, operations, documents, and supplier parts. In regulated industries such as aerospace and medical devices, that traceability is not optional, it is the record that proves a change was controlled. Strong impact analysis is what keeps a routine revision from quietly overstocking a phased-out component or starving a line of an updated one. It pairs naturally with the broader practice of catching errors before they reach manufacturing.
Why Result Quality Lives or Dies on Metadata
A where-used query can only return relationships that exist in the database. This is the uncomfortable truth behind impact analysis: the answer is exactly as complete as the data feeding it. If a part was added to an assembly with a manual note instead of a structured BOM link, the query will not see it. If a legacy drawing references the part only inside a PDF and never as a managed relationship, the query will miss it. The result looks authoritative, yet it is silently incomplete.
Several common data gaps quietly degrade where-used accuracy:
Duplicate parts, where the same physical component exists under several part numbers, so a query against one number misses the assemblies that used the others.
Broken or missing relationships, where files were copied or migrated without their structure, leaving orphaned components that no query can trace.
Inconsistent metadata, where attributes like material, revision, or status are blank or non-standard, so filtered impact queries return partial lists.
Completeness applies to both the data and the metadata that describes it, and metadata feeds the search, discovery, and audit functions that impact analysis depends on. This is the same root cause behind so much wasted engineering time. When PDM search is broken and engineers cannot find parts, the underlying problem is usually thin metadata and missing relationships, and that same weakness corrupts every where-used result. The hidden cost of duplicate parts shows up most sharply during a change, when an analysis declares a part safe to retire because half its usage is hiding under another number.
The Manual Workarounds and Their Limits
When engineers do not trust the where-used results, they compensate with manual effort. They open assemblies one by one to confirm a part is really there. They email the original designer to ask where a bracket was reused. They export BOMs into spreadsheets and run filters by hand. They search file names and folder structures hoping to find the copy that the relationship graph never captured.
These workarounds are slow, and they scale badly. A multi-level where-used across a mature product family can touch hundreds of assemblies, and a person checking them by hand will miss some. Worse, the knowledge that fills the gaps often lives in people rather than the system. The engineer who remembers that a fitting was borrowed from an older project carries critical context that no query can reproduce, and that context walks out the door when they change roles. This is exactly the problem that engineering knowledge management exists to solve.
The deeper issue is that manual verification does not fix the data. It produces a one-time answer for a single change, then the next analyst starts over from the same incomplete graph. The cost compounds, and the risk never goes away. What teams need is a way to get a complete, trustworthy impact picture without first spending months perfecting their PLM data.
Instant Where-Used Analysis, Even With Incomplete Data
This is where an AI intelligence layer changes the economics of impact analysis. Leo sits on top of your existing PDM or PLM system and reads both the structured relationships and the geometry of the parts themselves. Because Leo understands shape and not only metadata, it can surface where a part is used even when the formal relationship was never recorded, finding the duplicate under a different number or the component that was copied into an assembly without a clean BOM link.
That geometry-aware reach is the concrete value driver. A where-used result built from relationships alone is only as complete as the relationships, but Leo can cross-check that list against what the models actually contain, then return an impact picture in minutes that a manual review would take days to assemble. Engineers get to run change impact analysis instantly, against the data they have today, rather than waiting for a multi-year data cleanup that may never finish.
Leo does not replace your system of record. It is an intelligence layer on top of it, and integrations are available for SolidWorks PDM, Autodesk Vault, PTC Windchill, Siemens Teamcenter, and Arena PLM. For teams already standardizing on conversational tools, Leo also brings the same capability to part search inside PDM, so the where-used question and the part-reuse question are answered in the same place.
FAQ
See Every Part a Change Affects
Run instant where-used and impact analysis on your real PLM data.
Leo connects to your PDM and PLM as an intelligence layer and returns complete where-used impact results in minutes, even when metadata is incomplete.
Schedule a Demo →
#1 New AI Software Globally - G2 2026
Enterprise-grade security
Trusted by world-class engineering teams
