BOM Where Used Analysis for Shared Hardware Changes: Find Every Affected SKU

A BOM where used analysis starts with a component and traces upward to the assemblies and finished items that reference it; it is the reverse question to asking which parts make one product. When a supplier proposes a change to a shared bracket, screw, insert, or other component, the buyer needs to know which direct parents and top-level saleable SKUs could be affected. That design relationship is not the same as knowing which purchase orders, warehouse lots, work in progress, or shipped units contain the component. Keep those two scopes separate and record the filters, date, revision, and source of the report.

The useful output is an evidence-backed impact list, not simply a screenshot or export. First identify the exact component and revision being reviewed. Next define which product structures, effective dates, alternates, and lifecycle statuses the query includes. Then trace the results through intermediate assemblies to the finished SKU level. Finally, hand the identified scope to the separate inventory and order cutover process. A where-used report can show a configured design relationship; by itself it does not prove that every listed assembly is currently produced or that every unlisted stock unit is unaffected.

Here, BOM where used analysis refers to the exact buyer decision and product scope described in this guide. The phrase BOM where used analysis remains tied to the named model, evidence, and limitations above.

What does a component where-used report answer?

A forward bill of materials (BOM) view answers: “Which components are listed in this assembly?” A where-used view reverses the direction: “Which parent structures reference this component?” Oracle’s manufacturing documentation describes where-used information as a way to view the parent assemblies that use an item, with structure and item attributes helping define the result. Oracle Cloud documentation also distinguishes structures and their relationships. These are product-specific software descriptions, not proof that every system uses identical terms, filters, or screens.

For a hardware buyer, the practical task is to trace from one exact component to each direct assembly and then, where needed, through higher levels until reaching the finished sellable SKU. A shared screw may sit directly in several products. A mounting plate may sit in a subassembly used by different finished goods. If the query stops at the first parent, the buyer can miss downstream products. If it expands without recording levels or filters, the list can become difficult to interpret and may include irrelevant or obsolete structures.

The report should therefore state what it means by “where used.” Does it show only direct parents, or every top-level ancestor? Does it include all revisions or only the selected effectivity date? Are alternates, substitutes, phantom or kit structures, inactive items, and pending engineering changes included? Is the view for a specific organization, site, plant, or product line? These details change the result. The word “complete” is meaningful only when the scope and system context are defined.

This table is a buyer control, not a prescribed ERP data model. Use the fields available in the supplier or buyer system and document any limitation. If the supplier cannot run a recursive query, it may still provide a controlled manual mapping or multiple reports, but the method and responsible reviewer should be recorded. Do not imply that a spreadsheet is equivalent to a verified PLM or ERP record without checking the underlying information.

Trace direct parents and finished SKUs separately

Begin by validating the component at the leaf level. Confirm item number, drawing, material or part description where known, revision, and the proposed change. If the supplied list uses an internal code that does not match the drawing or quote, resolve that identity before analyzing the parent structures. A correct query on the wrong component code is still the wrong answer.

The first result set is the direct-parent list: the assemblies in which the component is an immediate member. For each parent, capture its code, description, revision, and relationship to the component. The second pass follows each parent upward. That may reveal subassemblies, product variants, kits, or multiple finished SKUs. Keep the path visible; a table that lists only final products can conceal how the component reaches them and whether a common intermediate assembly is involved.

Consider a hypothetical shared mounting plate used by two intermediate shelf assemblies. One shelf assembly may be incorporated into a bathroom caddy and a laundry organizer; the other may be used only in a replacement kit. The component’s direct-parent list contains two assemblies, while the top-level list may contain three saleable items. That example explains why a single “number of parents” count is insufficient. It is illustrative only and does not describe Koitor’s actual BOM, product range, or customer data.

For each path, distinguish a structure relationship from a product listing. A BOM may contain an item in a configuration that is not released, not currently sold, or no longer used for new production. Conversely, a live product can have a supplier-side name that differs from the buyer’s catalogue code. The reviewer should reconcile the structure path with the buyer’s product master or current supplier list, and flag unmatched items instead of silently dropping them.

Choose filters before interpreting the output

The most common analysis error is generating a report first and deciding afterward what it means. Agree the question and filters up front. If the change is proposed for a future effective date, the buyer may need both the currently effective structure and the planned structure. If a component is approved as an alternate only for selected models, the query should separate primary use from alternate eligibility. If the structure varies by plant or customer configuration, include that context.

An “all revisions” search can be useful for historical exposure, but it should not be confused with current design use. An “active only” filter may be useful for current production planning, but it may exclude superseded structures that still exist in stock or have units in the channel. A “current as-of date” result may miss a change scheduled to take effect later. None of these settings is automatically right or wrong; each answers a different question. Preserve the query settings with the export.

The review should also handle quantity and reference type carefully. Some BOMs define quantity per assembly; others may contain a scrap factor, unit-of-measure conversion, or other planning value. A where-used list that names parents does not by itself calculate how many physical pieces are required for a purchase order or how many finished goods are in inventory. A buyer should not multiply parent counts into a total exposure estimate without the correct BOM quantities, production mix, and time basis.

If the system allows the report to include substitutions or alternates, label those separately from the primary component. A permitted alternate indicates a documented design option under stated controls; it does not prove that the alternate was actually purchased, installed, or accepted in every listed unit. If pending engineering changes appear in the result, state whether they are approved, effective, or still under review. Do not treat a draft structure as released production evidence.

What a where-used report does not establish

A structure report describes configured relationships in a system at a particular scope and time. It is not automatically a purchasing history, shop-floor consumption record, inventory count, traceability record, or shipment manifest. It does not prove that every referenced item was built with the listed component. It also does not establish that unlisted items are free from exposure if the data is incomplete, the wrong code was queried, or manual changes were not entered.

This distinction matters when deciding customer notice, disposition, or transition actions. Once the engineering scope is identified, a separate operational investigation may need purchase orders, receipts, lot records, work orders, WIP, finished-goods inventory, shipment records, service parts, and supplier stock. Those records answer where actual material may be. A component where-used report answers which controlled product structures could reference it. The two analyses can be linked but should not be collapsed into one undocumented spreadsheet.

K1476 addresses the next decision: how to plan inventory cutover and old-stock disposition after the affected scope has been identified. K798 addresses a different foundation: design BOM, manufacturing BOM, and kit definitions. This guide focuses on the reverse trace from a changed component to parent structures and finished SKUs. Keeping those page boundaries clear helps buyers find the right step without repeating one broad “BOM basics” article.

No where-used result should be described as proof of product failure, regulatory noncompliance, or customer exposure. A change may be administrative, preventive, cost-related, or technical; the report identifies potential structure reach, not the reason or risk level. The responsible engineering and quality owners must evaluate the change itself and define any testing, reapproval, or communication required.

A practical component-change review workflow

Use a controlled sequence so that the query can be reproduced and its limits are clear:

1. Freeze the change identity. Record component number, description, revision, drawing or sample reference, proposed change, and source document.
2. Define the question. State whether the buyer needs current design parents, historical structures, future effectivity, or all of these as separate views.
3. Set the query scope. Name system, organization, BOM type, site, date, revision rules, lifecycle status, and treatment of alternates or substitutes.
4. Run the direct-parent search. Save the unedited result and capture the timestamp and report owner.
5. Trace parent paths upward. Continue to intermediate and top-level assemblies; preserve each parent-child path and any unresolved code mapping.
6. Reconcile finished items. Match top-level structures to buyer and supplier saleable SKU lists, noting inactive or unmatched codes.
7. Review change reach. Engineering assesses which structures require drawing, sample, process, inspection, or claim review; do not assume all parents need identical action.
8. Open separate exposure work. Purchasing, operations, quality, and logistics investigate actual orders, stock, WIP, and shipped product where necessary.
9. Approve the disposition. Assign owners, decisions, effective dates, evidence, and communication duties.
10. Retain the record. Store the query parameters, source export, mapping, review notes, and approved change under one traceable identifier.

Each step can be scaled to the organization. A small distributor with a supplier-provided report may need a joint review call and a signed mapping sheet rather than direct ERP access. A larger importer may connect PLM, purchasing, and warehouse records. The essential point is to distinguish what each record can prove and keep a chain from the component code to the buyer’s finished SKU.

How to handle missing or inconsistent parent data

If the report returns no parent, do not conclude automatically that the component has no use. Verify the exact code, organization, BOM type, date, status filters, and whether the structure is stored in another system. Ask the supplier to confirm that the query includes intermediate assemblies and approved alternates if those are relevant. Record the search attempt and what remains outside the data source.

If two reports disagree, compare their scope before comparing their rows. One may be current-only while the other includes obsolete revisions. One may include an alternate structure or a different production site. One may trace only direct parents while another reports top-level items. A row count cannot be reconciled meaningfully until those settings align. Preserve both reports and ask the data owner to explain the difference rather than editing away rows to make the totals match.

If the buyer and supplier use different item identifiers, establish a controlled cross-reference. The mapping should include both parties’ codes, descriptions, revisions, and who approved the match. Avoid relying on a shortened description or image alone. If the supplier will not reveal a confidential internal code, agree a reference that still lets both parties identify the same component and preserve an auditable link to the drawing or sample.

When a manual workbook is used, protect formula cells, label the source and date, and record who made the mapping. Keep the original export unaltered and perform changes in a separate review copy. A manual transformation may be necessary, but it should not obscure which rows came directly from the system and which were added through buyer interpretation. Mark assumptions, pending confirmations, and excluded structures clearly.

Keep design scope separate from operational risk ranking

Finding ten parent SKUs does not mean all ten have the same risk or need the same response. One item may be a low-volume accessory that has not been ordered for years; another may be a high-volume current product. One parent may use a cosmetic plate while another relies on the component for an interface that affects assembly. The where-used trace establishes potential design reach. The responsible engineering and business owners then decide how to prioritize review using product function, change rationale, timing, customer commitments, and verified production exposure.

This second-stage assessment needs its own assumptions. A product list can be combined with current sales or forecast data for planning, but the source period and item mapping should be stated. Do not assume the ERP’s parent quantity equals actual consumption if there are scrap factors, rework, engineering substitutions, or alternate routings. Do not estimate units affected by multiplying a theoretical BOM quantity by a sales number unless the buyer confirms that the BOM and sales time period align and that no alternate component was used.

It can help to organize the work into two connected tables. The first is the design reach table: component, parent path, top-level SKU, revision, status, and effectivity. The second is the operational exposure table: purchase order, production order, inventory location, lot or date code if available, WIP, finished goods, and shipment status. The second table may not be available to an external buyer; if so, identify the supplier owner who can verify it and record the answer as supplier-confirmed rather than independently observed. Do not fill unknown exposure rows with zeros.

An exception queue is preferable to silently omitting messy data. Create an item for every code that cannot be mapped, every report row with an unclear status, every alternate with unknown approval, and every structure that appears in one source but not another. Assign an owner and due date. The change cannot be closed just because the clean rows were easy to reconcile; the remaining exceptions define the limits of the current conclusion.

The engineering change itself may also have different effectivity across products. A shared component might be revised for one product family first while another family continues with an earlier approved revision. The buyer should preserve the product-specific transition date and not infer that a global component revision was applied everywhere at once. If a supplier confirms a staged rollout, record the affected product codes, purchase order window, and evidence needed to identify each production state. The change-control record should show who authorized the sequence and which document version governed each stage.

Supplier data request and confidentiality boundaries

An importer may not have direct access to the supplier’s complete product structures. The request can still be specific without asking for unrelated customer information. Ask the supplier to provide the parent and top-level product codes relevant to the buyer’s own items, the scope and date of the query, and a confirmation of whether the list includes all relevant revisions, sites, and alternatives. If another customer’s confidential product appears in an export, the supplier should protect or redact that data while still explaining whether it affects the buyer’s component or product.

The buyer should not demand a full proprietary ERP export where a targeted, signed summary can answer the question. Conversely, a one-line email saying “no other products use it” may not be enough when the change is material and the buyer needs an auditable basis. Agree the level of evidence with the supplier based on risk and contractual responsibility. A controlled extract, reviewer signoff, or trace table may be sufficient if its assumptions are clear and the owner can reproduce it.

Keep personally identifiable information, customer names, unrelated product codes, commercial pricing, and confidential drawings out of broadly shared reports. Provide an access-controlled package to the people who need to decide engineering, quality, purchase, and stock actions. If the buyer uses an external consultant, define what may be shared and how long it will be retained. The purpose is to establish a reliable impact path without exposing another party’s confidential program.

When the supplier says its system cannot produce a recursive where-used report, ask what alternative verification is possible. A manual engineering review of each approved structure, a product-family matrix, or a controlled supplier declaration may help. The method should indicate who performed the check, which records were searched, what dates or sites were included, and which uncertainty remains. Never relabel a limited manual review as a comprehensive automated report.

Close the review with decisions, not just an export

The report is an input to a decision. A complete review records whether the proposed change is accepted, conditionally accepted, or held; which product structures are in scope; what additional samples or documents are needed; and whether operational exposure work remains open. The decision owner should be clear. A purchasing team can coordinate the request, but engineering should evaluate the technical change, quality should scope evidence and acceptance, and operations should investigate actual material and order status as appropriate.

If the review finds no active parent in the selected scope, preserve that result as “none found under the recorded filters” rather than an unrestricted statement that the part has never been used. If the result finds affected structures but the supplier cannot map them to buyer SKUs, record the unresolved mapping and do not issue a blanket approval. If actual stock exposure is still being checked, keep that workstream open even when the design analysis is complete.

The final package can be concise: a cover summary, the query settings, the untouched report export, a reviewed parent path table, an exception log, decisions, and a list of follow-up actions. Keep the title and date aligned with the change request. Link the record to the component drawing and affected product revisions. That makes later reorder, supplier audit, complaint review, or a second design revision easier to reconstruct without relying on someone’s memory of a meeting.

Buyer checklist for a where-used handoff

Before treating the analysis as complete, confirm that the record includes:

• The exact changed component, revision, and controlled source reference.
• The intended current, historical, future, or combined time scope.
• System, organization, site, BOM type, status, and effectivity filters.
• Direct parent assemblies and the upward path to top-level products.
• Separate identification of primary, alternate, substitute, pending, and obsolete relationships.
• Reconciliation between top-level structure codes and sellable buyer SKUs.
• Report timestamp, source owner, and known data limitations.
• A clear statement that design membership is not proof of actual inventory or shipped-unit exposure.
• An owner for separate PO, receipt, work-in-process, stock, and shipment tracing.
• Engineering decisions, follow-up actions, deadlines, and retained approval records.

The checklist can be attached to an engineering change request or supplier notification. It should not be treated as a universal mandated form. Adapt it to the systems and contract responsibilities in the buyer’s actual relationship, and retain any confidentiality controls required by the supplier.

Perguntas frequentes

Is a BOM where-used report the same as an inventory trace?

No. A where-used report identifies configured parent structures in a defined system scope. Actual inventory or shipped-unit exposure requires additional purchasing, production, warehouse, lot, and logistics records. The investigations should be connected but reported separately.

Should the report show direct parents or all finished SKUs?

Often the reviewer needs both. Direct parents explain the first relationship; recursive paths identify higher-level assemblies and potentially saleable products. State the depth and filters so readers know what the export includes.

Does an approved alternate mean the product was built with that part?

No. An approved alternate is a design or sourcing permission under its documented conditions. It does not establish the actual component used in a particular lot or unit. Check production and traceability records for actual use.

Should obsolete revisions be excluded?

That depends on the question. A current design review may focus on the effective revision, while historical stock or service exposure can require older structures. Produce separate views when those questions differ and label their dates and status filters.

Can a component change affect a product not shown in the first report?

It can be missed if the query stops at direct parents, omits another organization, excludes a relevant status, uses the wrong item code, or relies on incomplete data. Verify scope and trace upward before declaring the parent list complete.

Does this guide describe Koitor’s internal ERP or BOM system?

No. The examples are generic buyer workflow guidance and cite public software documentation for terminology. They do not claim Koitor uses a particular ERP, PLM, report, or customer product structure.

Fontes

• Oracle manufacturing where-used information — product-specific description of parent-assembly where-used views.
• Oracle Cloud structure views — product-specific documentation for structure relationships and views.
• Koitor BOM types and kit differences — existing owner for BOM-type definitions and kit scope.
• Koitor engineering-change inventory cutover — separate follow-on guide for stock and WIP disposition after the affected scope is known.

Trabalhe com a Koitor Hardware