Both systems can hold a bill of materials. Both can hold an item. Both can version something and call it a revision.
That overlap is why the comparison usually gets framed as "which one should we use", and why that framing produces bad answers. The useful question is narrower and much duller: for each object, which system is the master? Not which one displays it, not which one people look at — which one wins when the two disagree.
Because they will disagree. On a Wednesday, six months in, when a planner edits a structure directly because a line was down and the alternative was doing nothing.
Why capability is the wrong axis
An ERP exists to plan and transact. It answers what to buy, what to build, what it cost, what is on hand and what is owed. Every object in it is shaped by that purpose, which is why an item generally must exist before it can be structured — an item that cannot be transacted has no business in a system of transactions.
A PLM exists to define and control change. It answers what the product is, who changed it, why, what else that broke, and what a specific unit shipped with. Its objects are shaped by that: revisions, effectivity, change orders, approvals, relationships.
The consequence people miss is temporal. An ERP has nothing to say about the eight months before an item exists — the concepts, the alternatives evaluated and rejected, the revisions that never released, the supplier that failed qualification, the requirement that drove a tolerance. That is most of what an engineering organisation argues about, and none of it is item-shaped.
The rows that matter
Six objects account for nearly every dispute. Four of them have a defensible default and two genuinely depend on your organisation.
- Part number. Usually the PLM, because a part needs an identity before it is transactable — during design, when it does not yet exist to the ERP. If your ERP issues numbers today and the process works, adopting them is fine. What is not fine is both systems issuing them.
- Engineering BOM. The PLM, without much argument. It is the definition, it changes through change control, and it has revisions.
- Manufacturing BOM. Genuinely contested, and the row that stalls implementations. If manufacturing engineering sits in the ERP and works there daily, leave it there and stop the PLM at the EBOM. If the MBOM is derived from the EBOM by engineering, it belongs in the PLM. Both work. Split ownership does not.
- Standard cost. The ERP, always. A cost figure engineering maintains is a cost figure that disagrees with the one finance reports on.
- Approved manufacturer list. The PLM, because it is an engineering approval about acceptable substitution, not a purchasing record about who you buy from. Those are different facts about the same company, and both should exist.
- Documents. The PLM, with the ERP holding references rather than attachments — because a reference supersedes itself and an attachment is a snapshot of the day somebody uploaded it.
The point of writing it down
An organisation that has answered these six questions can run both systems indefinitely. One that has not will run both systems until somebody gives up and starts maintaining one by hand.
That is not hyperbole, and the mechanism is worth understanding, because it is gradual rather than dramatic. Nobody decides to abandon the PLM. What happens is that a field disagrees, somebody fixes it on the side they were looking at, and the two records diverge slightly. It happens again. Within a year one system is trusted for one set of questions and the other for another, and there is a person in the middle who knows which is which — and that person becomes the actual system of record, which is a problem you cannot fix by buying software.
The matrix does not need to be sophisticated. It needs to exist, be short enough to read, and be decided before go-live rather than discovered afterwards.
What happens to the rows you skip
Every matrix has gaps, because matrices are written by people and products have a great many fields. The gaps are not a failure — pretending they are covered is.
An undefined row behaves in a specific way: both systems accept edits to it, neither reconciles it, and the divergence is invisible until somebody makes a decision on the wrong copy. The unit of measure field is the classic example. It looks like a settled fact, it is edited about once every three years, and when it is edited on the wrong side you get purchase orders out by a factor of a thousand because one system says metres and the other says millimetres.
So the useful discipline is not covering everything. It is making an uncovered row visible, so that a disagreement on it is reported as "nobody has decided who owns this" rather than silently split.
Reconciliation is a consequence, not a feature
Once the matrix exists, drift detection becomes mechanical and — this is the part people underestimate — actionable.
When two systems disagree about a field, the interesting question is not that they disagree. It is which one is supposed to be authoritative, because the answer determines the remedy. A cost disagreement where the ERP owns cost is drift in the PLM's cached copy, and it is fixed by re-reading. The same disagreement on a field the PLM owns is a publication that did not land, and it is fixed by re-publishing.
Same symptom. Opposite remedies. Different teams.
A system that reported both cases identically would send half its findings to the wrong people, and a team that receives wrong findings stops reading the queue within about a fortnight. Which means the matrix is not documentation about the integration. It is a runtime input to it.
Where to start
Write the six rows down. Argue about the manufacturing BOM properly, once, with the people who will live with the answer. Mark the rows you have not decided as undecided rather than leaving them blank.
Then do the boring thing that pays for itself: list the parts that exist in one system and not the other. Most teams have never seen that list. It is usually longer than expected, and it is usually the first honest measurement of how far apart the two systems have already drifted.