Almost every manufacturer with a PLM system also has a person who copies bills of materials into the ERP by hand. Everyone agrees it should not be necessary. It has usually been on the improvement list for two or three years. And it is still happening, in companies that have already paid for both systems and for an interface between them.
The reflex explanation is that the integration was never built, or was built badly. Occasionally that is true. Far more often, the interface exists and works, and someone is still re-typing, because the thing they are doing is not data transfer.
What the person re-typing is actually doing
Watch the process closely and you will see that the transfer is rarely mechanical. The person does not copy the engineering BOM line for line. They reinterpret it.
They add consumables that engineering never listed. They flatten an assembly that exists in the design but never gets built as a separate unit. They substitute an approved alternative for a part that has been out of stock for a month. They split one engineering position into two operations because that is how the line is set up.
None of this is written down anywhere. It lives in the head of one experienced planner, and it is applied consistently enough that nobody has noticed the process depends on a single person.
The manual step is not the problem. It is the symptom.
Someone is compensating, by hand and in real time, for a structural gap between how the product is designed and how it is actually made.
Two BOMs that are not the same list
The gap has a name. Engineering and manufacturing hold two different views of the same product, and they are supposed to be different.
The engineering BOM, or eBOM, describes the product as designed. It is structured by function: what the product consists of and how the parts relate to each other. It is the output of the design process and it answers the question of what the product is.
The manufacturing BOM, or mBOM, describes the product as built. It is structured by assembly sequence: what gets consumed at which operation, in which order, on which line. It answers the question of how the product gets made.
| Engineering BOM | Manufacturing BOM | |
|---|---|---|
| Structured by | Function and design logic | Assembly sequence and operations |
| Owned by | Engineering | Manufacturing or process planning |
| Lives in | PLM | ERP, usually |
| Includes | Parts that make up the product | Everything consumed to build it |
| Excludes | Adhesives, welding wire, packaging | Design-only groupings that are never built |
| Varies by | Product revision | Plant, line, and available stock |
These two lists describe the same product and they will never be identical. That is not a defect. A design structured around how it happens to be assembled in one particular factory would be a bad design.
What the gap looks like in practice
Engineering releases a housing assembly: two shells, a seal, four screws. Four positions, clean and logical.
Production builds it differently. The seal is applied with an adhesive that engineering never listed, because adhesive is not part of the product, it is part of the process. The four screws come from a bulk bin and are not tracked per unit. The two shells arrive pre-joined from a supplier on some orders and separately on others, depending on lead time.
The manufacturing BOM for that same assembly has adhesive, a bulk consumable position, and a conditional structure depending on how the shells were sourced. Seven positions where engineering had four, and none of the differences are errors.
Now multiply that by every assembly in the product, and add the fact that the mBOM changes when the line changes, when a supplier changes, or when a second plant builds the same product a different way.
Why automating first makes it worse
The obvious response is to build an interface and push the eBOM into the ERP automatically. Companies do this, and a predictable thing happens.
The interface transfers the engineering structure faithfully. Production receives a BOM that is missing the adhesive, missing the packaging, and structured around an assembly they do not build as a unit. They cannot plan from it.
So the planner starts correcting the transferred BOM instead of typing it from scratch. The manual work has not been removed, it has been moved and made harder to see. Worse, the corrections now live in the ERP, disconnected from engineering, so when the next revision arrives it overwrites them or conflicts with them.
The company has automated the wrong half of the problem and now has two sources of truth where it previously had one person who knew what they were doing.
The order matters. Deciding how the eBOM becomes an mBOM is a process decision. Building the interface is a technical task.
Doing the technical task first does not remove the need for the decision. It just means the decision gets made implicitly, by whatever the interface happens to do.
What has to be decided before anything is built
Four questions, none of them technical. They are the reason this problem survives for years in companies that have capable IT departments.
1. Who owns the manufacturing BOM
Not who maintains it in practice, but who is formally responsible for it and who approves changes to it. In most companies this has never been assigned, which is why it ends up with whoever is willing to keep doing it.
2. What transformation rules apply
Which consumables get added at which operations. Which design assemblies get flattened. How alternates and substitutes are handled. How packaging enters the structure. These rules exist already, in someone’s head. Writing them down is most of the work.
3. What happens when engineering releases a change
Not every engineering change affects the manufacturing structure, and some affect it in ways engineering cannot predict. The question is which changes propagate automatically, which require review by manufacturing, and who decides which is which.
4. Where each BOM lives
The common answer is eBOM in PLM, mBOM in ERP. It is not the only valid one. Some companies hold both in PLM and transfer only the finished mBOM, which keeps the transformation visible and versioned. The choice depends on which system your process planners actually work in.
These four answers are what an interface implements. Without them, the interface implements whatever the developer assumed, and the assumptions surface eighteen months later as a data quality problem.
The uncomfortable part
There is a reason this decision keeps getting deferred, and it is not technical.
Formalizing the transformation rules means making explicit something that currently works informally, and that has a consequence: it makes visible how much of production planning depends on undocumented judgment by one or two people.
That is uncomfortable to surface. It can read as criticism of people who have, in fact, been holding the process together for years. In practice they are usually the ones most relieved when it finally gets written down, because they are also the ones who cannot take two consecutive weeks of leave.
Companies that skip this conversation and go straight to the interface end up having it anyway, later, under time pressure, in the middle of a project.
What it looks like when it is done properly
The engineering BOM is released in PLM with a revision and an approval. That release triggers a defined transformation into a manufacturing structure, applying the documented rules: consumables added, phantom assemblies resolved, plant-specific variants handled.
The resulting mBOM carries a link back to the engineering revision it came from. When engineering releases a change, the system flags which manufacturing structures are affected and what the difference is. A person reviews and approves. They do not re-type anything.
Failed transfers are detected and reported rather than discovered when production builds from an outdated structure. Both lists remain traceable to each other, so the question of which version production actually used has an answer.
Handling that transformation is a native capability in Windchill PLM and on the 3DEXPERIENCE platform. The systems are not the hard part. The rules they enforce are.
How to tell where you actually stand
Ask three questions inside your own company. Each takes a minute and none require a consultant.
- If the person who maintains the manufacturing BOMs left tomorrow, how long until it caused a problem? If the answer is measured in days, the rules are not written down.
- When engineering releases a revision, how does production find out which of their structures are affected? If the answer involves an email or a meeting, there is no link between the two.
- Can you tell which BOM version was used to build a batch you shipped last year? If not, traceability stops at the point where the manual step happens.
Three uncomfortable answers do not mean you need to buy anything. They mean the manual re-entry is doing more work than anyone has credited it with, and that removing it is a process project with a software component, not the other way around.
Can our ERP hold both BOMs?
Technically yes, and some companies run it that way. The difficulty is that the engineering BOM changes with design revisions, and ERP systems are generally not built to manage revision history, change approval, and CAD linkage. You end up rebuilding a subset of PLM inside the ERP, usually without the change control.
Is this only a problem for complex products?
The gap between design and manufacturing structure exists at any complexity. What changes is how expensive it is to bridge by hand. A company with twenty products and stable processes can absorb manual re-entry indefinitely. One with frequent engineering changes or several plants cannot, and usually discovers this during growth rather than before it.
How long does it take to remove the manual step?
The technical work is measured in weeks. Agreeing the transformation rules is measured in workshops, and that is where the schedule actually gets set. Companies that already have documented process planning move quickly. Companies where the knowledge is undocumented spend most of the effort there, and that effort is worth it independently of any interface.
Do we need to fix everything before automating anything?
No, and trying to is a common way to stall the project entirely. A workable approach is to formalize rules for one product family, build the transfer for that family, and confirm it holds in production before extending. The rules for the second family are usually much faster, because the pattern is established.
What if engineering and manufacturing disagree about the structure?
That disagreement is the actual project. It is not a sign that something has gone wrong, it is the thing that has been unresolved all along and quietly absorbed by whoever was re-typing. Surfacing it is progress, even though it does not feel like it during the workshop.
Still re-typing BOMs into the ERP?
Ask us the three questions above about your own process. If the answers are uncomfortable, the useful next step is an assessment rather than a proposal, and that conversation costs nothing.