PLM vs ERP: who owns what

The question is ownership, not capability

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 is usually framed as “which one should we use”, and why that framing produces bad answers.

The useful question is narrower: for each object, which system is the master? Not which one displays it, not which one people look at, but which one wins when the two disagree — because they will disagree, on a Wednesday, six months in, when a planner edits a structure directly.

An organisation that has answered that question for six objects can run both systems indefinitely. One that has not will run both systems until somebody gives up and maintains one by hand.

What each system is actually for

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 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. The 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 six contested objects

In practice the argument is about six things. Here is where each one usually lands, and why.

• Item identity — PLM, for parts engineering creates. The ERP keeps its own identity for items that originate in purchasing or sales: packaging, freight, consumables, services. Forcing both into one namespace is a common early mistake.
• Engineering BOM — PLM, without exception. An EBOM editable outside the change process is not under change control in any meaningful sense, which defeats the reason for having a PLM at all.
• Manufacturing BOM — genuinely contested, and the one row that should be decided per organisation rather than assumed by a vendor. If manufacturing engineering owns routings in the ERP, the MBOM usually belongs there too.
• Cost — ERP, always. Standard cost, actual cost and valuation are accounting facts. A PLM should display cost and roll it up through a structure; it should never write one.
• Inventory and lead time — ERP. Nothing else is even arguable, and a PLM holding a stock figure is holding a stale copy of somebody else's truth.
• Supplier record — ERP for the commercial relationship: terms, pricing, the vendor part number a buyer transacts against. PLM for the approved manufacturer list: which manufacturer parts engineering has qualified for a given internal part. These are two different questions that one supplier field has never answered well.

Direction is not implied by ownership

This is the subtlety that causes most of the remaining trouble. Naming a master does not tell you which way data moves, and treating the two as the same thing produces integrations that are wrong in a way nobody notices for months.

An ERP-mastered field still flows into the PLM — engineers need to see cost on a bill of materials to make a design decision. It flows read-only. The correct behaviour is that the field renders greyed and labelled with its owning system, so nobody edits a number the next sync will replace.

Equally, a PLM-mastered object flows outward on a trigger rather than continuously. “Continuously” is not a trigger; it is a way of avoiding the question, and it is how integrations end up firing during a month-end close. The right trigger for a released structure is the release itself.

The effectivity trap

The single most common integration defect has nothing to do with ownership. It is that approval and effect get collapsed into one event.

A change is approved in August to take effect on 1 October, because production has six weeks of the old component on the shelf. If the integration fires on approval and stamps today's date, the ERP believes the new structure is current from August. Planning nets requirements against the new component six weeks early, releases purchase orders for it, and stops consuming the stock that determined the October date in the first place.

Nothing errors. Both systems did what they were told. The fix is that the effectivity date must travel with the publication and must land in the field the planning run actually reads — a dated BOM revision, a change master with a valid-from, an effective-start on a revision. An effectivity date written into a custom field or a description is invisible to planning, which makes it worse than useless: it looks like the problem was handled.

Writing it down before you integrate

The artefact worth producing is a table with one row per object and four columns: master, direction, trigger, and conflict rule. It takes an afternoon and it is the difference between an integration that survives and one that gets switched off.

The fourth column is the one people skip and the one that matters most. Somebody will edit the published BOM in the ERP — often for a good reason. The question is only whether the system raises a reconciliation task naming the field and both values, or silently overwrites their work at two in the morning and lets them find out from a shortage report.

A PLM that wins arguments with the ERP silently gets disabled within a quarter, and deservedly so. Whatever tools you are evaluating, ask each vendor for that table. The ones who cannot produce it are telling you something useful.