PLM and ERP: where the line runs

Three scenarios, one pattern

An ERP is not a bad PLM – it is built for a different job. This usually only becomes visible when something goes wrong.

A design engineer swaps a component in CAD. Three weeks later a complaint comes in – production was still building the old variant.

A raw material in a formulation is replaced for regulatory reasons. During an audit, no one can say with certainty which produced batch contained the new variant.

An experienced employee retires. Six months later an existing product is due for a revision – and no one can find the design decisions made back then.

Three different industries, three different symptoms, one common cause: a system being asked to take on a job it was never built for. This article describes the division of responsibilities between ERP and PLM (Product Lifecycle Management) for manufacturing SMEs. Not as a feature comparison, but along the questions: what can an ERP structurally not do? Where does that turn into real cost? And when is the point reached at which a dedicated system for product data becomes a business necessity?

What each system actually manages

ERP systems manage a company’s operational actual state: orders, inventory, postings, resources. They answer questions like Who ordered what? What do we have in stock? What does production cost? An ERP is a transaction-oriented system that runs day-to-day operations. PLM systems manage the product definition in its target state: requirements, design, versions, releases, changes, evidence – across the entire lifecycle. They answer questions like How did this product come about? Which version is valid? Who changed what, when and why? A PLM is an object-oriented system that maintains the product definition. ERP data describes what has happened. PLM data describes what a product is and how it came to be that way. The gaps between these two views are not configuration issues – they are architectural.

Four limits of classic ERP systems

1. Engineering data and design context

The released bill of materials exists in the ERP. What does not exist there: the CAD model, the calculations, the material specifications, the test reports, the dependent documents. The ERP knows that an assembly consists of three parts. The ERP does not know why it consists of three and not two. In practice: when a customer comes back three years after delivery with a problem, someone wants to know which variant was built back then, against which standard it was designed, and which tests were carried out. The delivery note can be found in the ERP. Everything else is somewhere.

2. Change management

Typically the old and the new bill of materials exist in the ERP. Who initiated the change, which alternatives were evaluated, which tests became invalid, what the impact on other products is – none of this is represented in classic ERP systems. PLM manages changes as objects in their own right: change request, impact analysis, affected objects, releases, dependent documents. A material substitution is then no longer a silent update of a bill of materials, but a traceable process with rationale, review and release.

3. Traceability at the definition level

Food, cosmetics, medical devices and increasingly electronics are subject to strict evidence obligations. ERP can trace at the transaction level: which batch of a raw material flowed into which batch of a product. That is enough for classic batch tracing. What it cannot do: connect substance classes, regulatory requirements, specification versions and product variants. Faced with a query such as “Which products contain substance X according to which specification in which valid version?”, ERP does not play along – not because it is misconfigured, but because its data structure does not know these relationships.

4. Knowledge that does not walk out with people

In SMEs, experience shows that a considerable share of product knowledge sits in people’s heads. Which design decision was made back then and why, which supplier alternatives were tried and rejected, which special tools a particular variant requires – all of this is implicit. PLM makes this knowledge explicit and version-proof. Not through additional mandatory fields in forms, but by structuring the natural artefacts of product development (CAD, documents, changes, decisions) and linking them to the product objects.

What connects the four gaps: the digital thread

The four gaps are not four problems, but four symptoms of the same problem: product information sits scattered, without a continuous identity. The design drawing does not know that it belongs to the bill of materials. The bill of materials does not know that there is a test report for it. The test report does not know which standard it tested against. The digital thread is the idea that every piece of information remains findable and contextualised along the product lifecycle: from the requirements specification through design and manufacturing to service and back into the next product generation. For an SME this does not mean “Industry 4.0 end-to-end”, but something more concrete: every product version is uniquely identifiable. Every change is traceable. Every document is bound to the correct variant. These properties sound trivial, but in most SMEs they are not a given today – and they cannot be created without PLM either, because they presuppose an object-oriented, version-capable data structure that ERP does not have.

Data structure as a prerequisite for automation and AI

The digital thread is not only a prerequisite for human findability – it is also the foundation for any form of automation, AI-based or not. The bottleneck rarely lies in the AI model alone. What is decisive is whether product data is available in a structured, versioned and traceable form. Whoever turns AI loose on unmaintained PDFs, Excel bills of materials and file servers does not automatically get knowledge – often just more quickly produced uncertainty.

An application that works on structured, versioned, relationship-oriented product data, by contrast, can give traceable answers – including source, version and maturity level. Concretely: queries such as “Which products are affected by the substitution of this material?”, “Draft an initial version of the service documentation for variant X-127” or “Which products need to be re-certified if standard XYZ is updated?” are technically not possible as long as the underlying data is not in the form the digital thread describes. The value of a PLM therefore does not lie in the AI capability itself, but in the data consistency and traceability that make every later stage of automation possible in the first place.

Industry-specific emphases

Machinery and plant engineering.

Variant management is the dominant driver: customer-specific configurations, several version strands running in parallel, long-lived products with service requirements spanning decades. The split between the engineering bill of materials (eBOM) and the manufacturing bill of materials (mBOM) is often the first pain point here at which ERP visibly hits its limits.

Food.

Recipe management with allergen and nutritional calculation, labelling obligations under EU 1169/2011, traceability under EU 178/2002, reformulations for cost or regulatory reasons. A formulation here is a standalone object with a version, release status and regulatory context – not a bill of materials in the classic sense.

Cosmetics.

INCI declarations, market-specific regulation (EU, UK, CH, US, GCC), CPNP notifications, substitution of banned or restricted substances. The complexity does not lie in the product structure, but in the regulatory relationships a formulation has to maintain.

High-tech and electronics.

Component obsolescence (parts drop out of the market mid-lifecycle), hardware-firmware binding, compliance against RoHS, REACH, IEC. The lifecycle of the end product here is often longer than the lifecycle of its components – a challenge classic ERP does not address. Common to all four industries: the product definition is more complex than the order-fulfilment process. Whoever runs only ERP has solved their simpler problem well – and left their actual problem untouched.

Regulatory requirements: DPP and industry-specific obligations

Digital Product Passport (DPP) under the ESPR.

The EU Ecodesign for Sustainable Products Regulation came into force in 2024. It creates the framework for product-related ecodesign requirements and digital product passports. Which product groups are concretely affected, and when, is being defined step by step through product-specific delegated acts. The EU working plan 2025–2030 prioritises, among others, textiles, furniture, mattresses, tyres as well as iron, steel and aluminium; horizontal requirements concern, among other things, repairability, recyclability and recycled content in electrical and electronic products. Food, feed and medicinal products are excluded from the scope of the ESPR.

The battery passport applies from 18 February 2027 for certain battery categories – in particular LMT batteries, industrial batteries above 2 kWh and electric vehicle batteries. It is therefore relevant for manufacturers who place affected battery categories on the market themselves or who have to supply corresponding evidence within complex supply chains.

A note for UK manufacturers. The DPP is an EU instrument, but it is hard to ignore from the UK: any company exporting affected products into the EU will have to meet DPP requirements at the EU border. In parallel, the UK is developing its own product and ecodesign agenda, and post-Brexit divergence (UKCA marking, UK REACH) means UK manufacturers increasingly have to satisfy two regimes at once – which raises, rather than lowers, the bar for well-structured product data.

Technically, the DPP is a data-architecture requirement. Verified, structured data on materials, origin, repairability, recyclability and much more has to be maintained consistently at the product-definition level and kept up to date across the lifecycle. Classic ERP systems address the transaction level; this data structure is something they cannot represent. Industry insiders estimate that building a DPP-ready data foundation requires 12 to 18 months of lead time – including supplier-data collection and schema definition.

Industry-specific obligations remain relevant.

REACH and RoHS in high-tech, EU 1169/2011 and 178/2002 in food, CPNP in cosmetics. Regardless of simplifications in sustainability reporting, many product-related evidence obligations remain in place – on ingredients, specifications, traceability, labelling and technical documentation.

Customer-driven requirements.

Even SMEs that are not themselves subject to reporting obligations are increasingly asked by large customers for product-related sustainability data. The voluntary VSME standard is becoming the de facto minimum requirement here. The data that answers such requests is exactly the data a PLM holds in a natively structured form.

Where ERP and PLM work together

PLM does not replace ERP. The two systems serve different phases with different requirements, and used sensibly they work together. The typical handover point is product release. PLM defines what the product is, in which version, with which documents, checked against which requirements. On release, the operationally relevant parts – item masters, bills of materials, routings – move into the ERP, which then drives procurement, manufacturing and delivery. Changes to the released product run back through the PLM and are synchronised again on re-release.

This division of labour is not duplicate data keeping, but a separation of responsibilities. The ERP is not meant to do what the PLM does – and vice versa. Whoever tries to cover one with the other ends up with either a sluggish ERP full of special fields or a PLM that chokes on the accounting voucher.

The hidden cost of having no PLM

The cost of a missing PLM is spread across other accounts, and there it mostly stays invisible:

• Rework and scrap due to outdated specifications, wrong bill-of-materials versions or incompletely communicated changes.
• Delayed time-to-market due to unclear responsibilities in release processes and manual data maintenance across several systems.
• Audit and compliance effort, when every request from a regulatory body or a major customer costs weeks of research because the data has to be pieced together.
• Recall costs in the worst case – not because the product was defective, but because traceability was not good enough to tell a limited recall apart from a blanket one.
• Loss of knowledge when staff change, which cannot be quantified until the first existing product is due for revision and no one knows why it was designed the way it was.
• Shadow IT in the form of Excel bills of materials, SharePoint structures and file-server folder landscapes that every mid-sized engineering office knows.

None of these cost types is catastrophic on its own. Taken together they often tie up noticeable engineering, quality and IT capacity – without these costs becoming cleanly visible as a product-data problem.

Signs of maturity: when does an SME need PLM?

A short checklist for self-assessment. If three or more points apply, the conversation about PLM is overdue:

• Bills of materials are maintained in Excel or directly in the CAD system – without a separate system for versioning and release.
• Several product variants exist that have to be maintained in parallel.
• Changes are communicated by email or chat.
• Design and purchasing work from different “correct” bills of materials.
• An audit regularly costs several person-weeks.
• At least one employee has at some point been “the only one who can find the data”.
• Customer queries about compliance, ingredients or specifications are answered ad hoc.
• The same information is maintained in more than one place – with the risk of inconsistency.

How to introduce it – not everything at once

PLM implementations rarely fail because of the software. They fail because of big-bang approaches: an 18-month project that tries to cover everything at once and in the end meets neither the originally defined requirements nor the ones that have arisen in the meantime.

A realistic path looks different. First the foundation: master data, bills of materials, documents, CAD integration. This phase delivers measurable value – a clean data foundation, less searching, a defined release process – and is productive within a few months. Only after that come the next stages: structured change management, variant and configuration management, quality and compliance processes, integration with ERP and downstream systems.

This step-by-step approach has two advantages over the big bang. First, the benefit is tangible for the organisation after each stage – which keeps acceptance high. Second, after the first stage it is much easier to estimate what the next one will actually cost, because by then the company knows how it works with the system.

In closing

The question is not “ERP or PLM”. ERP controls orders, inventory, procurement, manufacturing and cost. PLM holds the product definition together: versions, documents, releases, changes and evidence. For simple products and stable processes, ERP can suffice for a long time. It becomes critical when variants, regulatory requirements, frequent changes or long-lived products enter the picture. Then cost arises not because ERP is bad – but because it is being asked to take on a job it was never built for. The sensible starting point is therefore not a big-bang project. It begins with a clear question: which product data has to be unambiguous, versioned and traceable in the future?