BOM genealogy under revision (and why the chain snaps at the ERP boundary)

The first time you read an ERP bill of materials report, it looks like a list. Parent item on top, child items beneath it, quantities in the right column. The screen does not lie. It shows you exactly what the database has. The problem is that the database is showing you a snapshot, and a bill of materials is not a snapshot. It is a versioned tree with a history of substitutions, revisions, and rolled-up decisions, every one of which can be the answer to a question that arrives months later from the shop floor or a customer.

The standard ERP item master stores the current BOM. The PLM system upstream stores the full genealogy. The handoff between them is where the chain breaks. PLM pushes the latest effectivity. The ERP receives it as a flat list of children under a parent. The fact that rev 12 existed last quarter, was consumed on three production runs, and matters for the field rework query that arrives in October is a fact that lives nowhere in the ERP record.

This piece is about why that boundary is structural, what it costs in the real plant, and the four specific moves we have watched fix it without ripping out either system.

People assume the BOM genealogy boundary is a tooling problem. Buy the right PLM connector, route the right fields, the chain stays intact. We have seen four tooling generations cross this boundary in production environments. The chain breaks every time. Not because the connector is buggy. Because the two systems were designed to answer different questions.

In the PLM, the identity of a part is the tuple (part_number, revision). Rev 12 and rev 13 of the same part number are different items. They have different drawings, different effectivity windows, different downstream children. A query against PLM that asks for the BOM walk of PMR-2810 requires an effectivity date to return a unique answer.

In the ERP, the identity of a part is the part number alone. The revision is a field on the item master record. When the revision changes, the field is overwritten. The history of revisions is recoverable only if the ERP was configured to keep a revision history table, and even then the table records what the current revision was on a given date, not which consuming work orders built against which past revision.

The mismatch is not at the wire. The mismatch is at the conceptual level. PLM thinks of an item as a sequence of revisions over time. ERP thinks of an item as a single identity whose attributes change over time. You can map them across a connector but the mapping is lossy in one direction.

The PLM knows that PMR-2810 rev 12 was the released revision from 2026-02-15 to 2026-05-31. It does not know which work orders consumed rev 12 during that window. That is not its job.

The ERP knows that WO-44291 consumed eight units of PMR-2810 on 2026-04-12. It does not know, three months later, what revision of PMR-2810 was released on that date. The field-on-the-item-master got overwritten when rev 13 went live.

The fact that you need to recover (which WOs built against which revisions) is the join of two facts neither system stores. Producing it requires reconstructing the released revision as a function of the WO release date, then joining to the WO consumption ledger. Most plants do this by hand, one engineering change at a time, when a field defect lands.

When we audit the BOM genealogy of a plant that is two to four years into a stable ERP deployment, the chain breaks in five recognisable places. They are not bugs. They are the consequence of the two structural mismatches above showing up at specific transition points.

PLM pushes the BOM for PMR-2810 rev 13 with an effectivity of 2026-06-01. The ERP connector reads the effectivity, applies the BOM change with an effective date, and overwrites the parent revision field. If the connector is configured to maintain a revision history table, the prior revision is captured. If it is configured for current state only (which is the default in three of the four tier-one ERPs we have wired), the prior revision is lost as a queryable record. The PDF release record exists in PLM. The link from a WO record to that PDF does not exist anywhere.

Mid-quarter, the buyer substitutes child component PMR-3104-CL-A with vendor V-218's equivalent PMR-3104-CL-B because the original part is on a four-week back-order. The substitution is approved. The PO is issued against the substitute. The WO consumes the substitute. The BOM in the ERP still lists the original. The genealogy record for that WO requires you to join the BOM (which lists A) to the actual PO consumption (which lists B) to know what actually went on the floor that day.^[1]

Engineering decides that on rev 13, the chamfer tolerance should be enforced at incoming inspection at +/- 0.02mm instead of the drawing-stated +/- 0.05mm. The decision is recorded as an inspection plan note in the quality module. The BOM is unchanged. Two quarters later, a field failure analysis goes looking for units built against the tighter tolerance and cannot tell from the BOM walk which units were inspected under the note and which were inspected under the drawing.

Discrete manufacturers commonly use phantom assemblies: an intermediate that exists on paper for BOM-walking purposes but never carries inventory. The ERP knows the phantom. The PLM thinks the phantom is a real assembly. The drawings for the phantom carry revisions. The ERP record of the phantom has no revision field because the phantom does not stock. When the WO releases against the phantom, the engineering revision of the phantom at WO release time is recorded nowhere.

Engineering decides that PMR-2810-A and PMR-2810-B can be consolidated into a single parent PMR-2810 because the only difference was a marketing label that no longer applies. The PLM rolls the two into one going forward. The ERP item master gets a new parent and the old SKUs are flagged inactive. WO history referring to the old SKUs still resolves correctly in isolation. The query "all units shipped of the consolidated family in the trailing 12 months" now requires the analyst to know about the consolidation and union three tables. Most analysts do not know.

When a plant hits this boundary the first time, the recommendations are predictable. Buy a more expensive PLM connector. Configure the ERP to keep a revision history. Train engineering to bump revisions for every change. Standardise the substitution approval flow so the BOM gets updated when a buyer substitutes. Each of these mitigations is correct and each of them is insufficient.

The PLM connector fix addresses the effectivity push but not the silent substitution. The ERP history-table fix addresses the revision overwrite but not the phantom assembly. The training fix addresses the engineering note but assumes engineering will reliably remember to bump a revision for changes they currently do not consider revision-worthy. The substitution fix addresses the buyer substitution but requires the buyer to interrupt the PO flow to update the BOM, which they will skip when they are under pressure.

The structural reason these mitigations are insufficient is that they each address one snap point with a workflow change. The boundary itself is unchanged. A new snap point will appear the next time engineering invents a new change shape that does not fit the existing process.

The operations layer approach is to stop forcing one of the two systems to also be the other. Leave the PLM as the source of revisions and intent. Leave the ERP as the source of state and consumption. Add a thin layer between them that records the join continuously, against the same events the two systems are already emitting.

The mechanics are not complicated. The layer subscribes to three event streams. PLM publishes revision releases and effectivity. ERP publishes WO releases and consumption. The PO flow publishes substitutions when a buyer accepts an equivalent. The layer writes one row per join: which WO consumed which parent revision, which children were substituted, what inspection notes were active at the time. The row is keyed by the WO and the released parent revision. The row never gets overwritten when the parent revision rolls forward.

When the rework query arrives ninety days later, the answer is a single SQL query against the join table, not an engineering reconstruction. The engineer pulling rework targets gets a clean unit-by-unit list with the revision, the substitution flag, and the inspection note state, all recorded at WO release time, not reconstructed after the fact.

When a plant's BOM genealogy moves to an operations layer, four concrete things change. None of them require ripping out the PLM, the ERP, or the connector between them.

The shape of the first deployment is narrow. Pick one product family that has had a rework campaign in the last year. Wire the PLM revision events read-only into the layer. Wire the ERP WO release events read-only. Wire the PO substitution events read-only. Run the snapshot writer for two weeks against live WOs. Compare the snapshot rows against the genealogy the engineers reconstructed by hand during the recent rework campaign. The first comparison will surface roughly three substitutions per hundred WOs that the engineers missed and that the snapshot captured. That is the calibration moment.

By the end of the second week, the layer is running on the full plant. Engineers stop reconstructing genealogy by hand for new queries. The reconstructions for historical WOs (pre-snapshot) are still manual, and you walk those one quarter at a time.

Three objections come up when we walk a plant through this boundary for the first time. None of them are wrong. All of them have specific answers.

The first objection is duplication of data. "You are writing the BOM into a third place. Now there are three sources of truth." The genealogy join is not a third source of truth for the current state of the BOM. The PLM remains the source of truth for revisions. The ERP remains the source of truth for consumption. The join records what was true at WO release time and is immutable thereafter. The question "what is the current BOM?" still has one answer (the PLM). The question "what BOM did this WO build against?" now has one answer (the join). Each question goes to the system designed for it.

The second objection is the cost of write-time computation. "Walking the BOM at every WO release is expensive." The walk is the same walk the ERP performs at WO release for its own MRP purposes. The layer subscribes to the same event and records the result, instead of recomputing it. There is no additional walk.

The third objection is the operational cost of yet another system. "We already have to maintain PLM and ERP." The layer is read-only against both. It does not change the item master, the BOM, or the WO. It records a join table that the existing systems do not record. The maintenance burden is the layer's own snapshot writer, which is a single service watching three event streams. The systems it reads from are unaware of its existence.