Sooner or later someone runs a comparison between the BOM in engineering and the BOM in ERP, finds several hundred differences and escalates it. What follows is usually a reconciliation project: a spreadsheet, a working group and three months of deciding line by line which system is right.
That project fixes today's differences and none of tomorrow's, because it treats drift as an accident rather than a symptom. The differences are not the problem. The mechanism producing them is.
Sort the differences before you fix any of them
Do not start line by line. Start by classifying, because the categories have completely different causes and only one of them is a data problem.
Structural differences by design. The engineering BOM describes the product as designed. The manufacturing BOM describes it as built — phantom assemblies collapsed, packaging added, consumables like adhesive and solder included, a sub-assembly restructured around how the line actually works. These are not errors. They are the two views doing their jobs, and reconciling them would break manufacturing.
If a large share of your differences are this kind, you do not have a data problem. You have a missing EBOM-to-MBOM transformation, and the fix is to model that transformation explicitly rather than hoping the two BOMs match by accident.
Timing differences. The change was approved in engineering last Tuesday and reaches ERP when someone rekeys it. Every difference in this category is a change in flight. The number of them is a direct measurement of your exposure window — the period during which the shop floor can build to superseded information. Count them; that number belongs in your business case.
Genuine errors. Somebody typed a quantity wrong, missed a line or applied a change to one system and not the other. This is the category everyone assumes they are dealing with. It is usually the smallest.
Three categories, three different fixes. A reconciliation project applies one fix to all three and therefore gets two of them wrong.
The question that identifies the real fault
For any given field, exactly one system should be authoritative. Not "both, kept in sync" — authoritative, with the other consuming it.
Draw the actual answer for the fields that matter most:
| Field | Who should own it |
|---|---|
| Part identity and description | Engineering |
| Engineering structure and quantities | Engineering |
| Manufacturing structure and routing | Manufacturing |
| Supplier, cost and lead time | ERP |
| Effectivity of a change | Engineering approves it; ERP schedules it |
The interesting exercise is not agreeing this table. Everyone agrees it in the meeting. The exercise is checking whether your systems enforce it. If a planner can edit a quantity that engineering owns, the table is a wish, and drift is guaranteed no matter how many reconciliations you run.
Most drift traces to exactly one thing: a field that two systems can both edit. Find those fields and you have found your root cause.
Why rekeying is the usual culprit
If a human retypes approved changes from PLM into ERP, drift is not a risk. It is a certainty with a known rate.
It also fails silently and asymmetrically. The person rekeying is reliable on the parts they touch often and unreliable on the ones they touch rarely — which means your error rate is highest on low-volume, long-tail parts, which are exactly the parts nobody checks and exactly the ones that generate expensive surprises years later.
An integration does not have to be sophisticated to beat this. It has to be the only path. A partial integration that people can bypass under time pressure will be bypassed under time pressure, and you will have paid for an integration and kept the drift.
What to do this week
- Extract both BOMs for twenty representative assemblies. Not all of them — twenty is enough to establish the pattern and small enough to finish.
- Classify every difference into the three categories above. The proportions tell you which problem you actually have.
- For the genuine errors, ask how each one got in. You will find two or three mechanisms accounting for nearly all of them.
- Fix the mechanisms, not the rows. Then re-run the comparison in a month. If the same categories come back, you fixed the wrong thing.
The rows will be back next quarter if you only fix rows. The value of the exercise is entirely in step 3, and it is the step most reconciliation projects skip because it is the least satisfying — nobody gets to report a number of lines corrected.
One last diagnostic, and it is the most reliable one in this whole paper: find out who keeps a private spreadsheet. Someone in planning or purchasing is maintaining their own list because they do not trust either system. Ask what is in it. That spreadsheet is a precise, free specification of what your integration is failing to deliver.
Working paper. If your BOMs have drifted and you want help finding the mechanism rather than reconciling the rows, get in touch.