Introducing The PLM Paradox

(and Why Most Manufacturers Only Discover They Need PLM When It’s Already Too Late)

The paradoxical conversation I keep having

I spend a lot of time talking with manufacturers about PLM. Different sectors, different sizes, same pattern. The call often starts like this:

“We are halfway through our ERP programme and it has dawned on us that our product data will not cut it. We think we need PLM. Can you help us work out what to do?”

In recent years I can point to many examples where that same catalyst set the whole conversation in motion. ERP exposes the limits of the scattered information based in offline drawings, Excel files, SharePoint folders, and tribal knowledge. The moment teams try to push real products through the new system, the cracks show. Which eBOM is the master. How does it become a clean mBOM. Where do compliance, quality, and sustainability data live. Who controls the release.

My answer is consistent, even if it is uncomfortable. Yes, there is a need for PLM. Yes, ideally you should have started before ERP. And now, in the thick of ERP, the appetite for another system and another big transformation is low. People are tired. Budgets are spoken for. The business is bruised by change.

So we help clients through that journey, but it is the most painful way to begin. You are treating the symptom that ERP has surfaced rather than curing the underlying problem upstream. You are trying to retrofit product truth while the engine is already running hot. Part of that heat comes from years of ingenuity. Engineers solved problems with grit and spreadsheets. SharePoint became the filing cabinet of record. It worked, until it did not. We all know the joke. The world’s most popular ERP is Microsoft Excel, and the world’s most installed PLM is Excel too.

That is the PLM Paradox. The moment you finally see the need for a governed, connected source of product data is the very moment you feel least able to act on it.

How to spot the paradox early

You do not need a full audit to see it coming. These tests are simple and revealing.

• You answer product questions with links, not objects. If the source of truth is a folder path, a SharePoint URL, or a workbook, luck is doing too much work.
• Engineering changes feel like requests, not releases. ERP tickets get raised to tidy data because no complete change packet exists upstream. The history lives in tabs and emails.
• eBOM to mBOM is a negotiation, not a rule. Each build finds a new special case. The rule lives in someone’s head and an old spreadsheet.
• Compliance and sustainability sit off to the side. Declarations, recycled content, and footprints are tracked in tools that do not travel with the product record.
• Cutover plans include long change freezes. That signals a lifecycle that cannot run safely during transformation.
• Excel and SharePoint are doing heroic work. When you ask where the truth lives, people open a file. When you ask how it flows, they send a link.

If two or more of these are true, the paradox is forming. The earlier you accept it, the cheaper it is to fix.

First aid without a new programme

You do not need a grand plan to stop the bleeding. You need a repeatable sequence. Five moves, light enough to start this quarter, strong enough to carry you for years. Every move replaces fragile spreadsheet glue with governed flow, without disrespecting the ingenuity that got you this far.

1) Name the product truths you cannot trade away

Capture them on one page. Keep it to five to seven items. Typical examples include: a single master eBOM with states, a governed eBOM to mBOM translation, controlled drawings and specs linked to structures, a visible change history with clear roles, and required compliance attributes that travel with each release.

Write how each truth is handled today. If the answer is a workbook or a SharePoint rule, note the failure mode. Broken link. Hidden macro. Hard-coded units. That list is your risk register.

Decision rule: if a proposed change does not strengthen one of these truths, it is noise.

2) Make the “change packet” real and complete

A change is a bundle. Structure deltas, drawings, work instructions, affected items, effectivity, approvals, and any compliance or sustainability attributes that must move with it. Define the packet. Make it visible. Replace side files with governed artefacts and fields that carry their own state and history.

Decision rule: nothing goes to ERP unless it is in a complete packet.

3) Establish a minimal lifecycle with real states

Start small. Draft, In Review, Released, Obsolete typically works. Define who moves an artefact from state to state, and what evidence is required. If your current state is a coloured cell or a tab name, that is not a state. It is a wish.

Decision rule: add a state only when a legal duty or a real control demands it.

4) Fix the eBOM to mBOM handoff once, then publish the rule

Decide how options and variants appear. Decide make, buy, and service effects. Decide the handful of attributes operations must receive every time. Write the rule and publish it. Use spreadsheets to test the rule if you need to, but let the rule live in PLM, not in a macro.

Decision rule: every exception has a clock. If it repeats, it becomes a rule or it dies.

5) Choose the lightest system that can honour these rules

Begin with capability inside a platform you already own if it can respect lifecycles, hold the packet, and reference structures. If it cannot, add the lightest PLM you can that does. Measure success by the number of spreadsheets you retire without losing fidelity. Keep Excel for analysis and exploration. Move product truth into governed flow.

Decision rule: software follows the rules, not the other way round.

This is not a project plan. It is a working rhythm. It creates pull because the people who feel the pain notice the relief. When they see fewer late changes, fewer broken links, and faster answers, they ask for more of that behaviour.

From triage to trajectory, standing up PLM in parallel with ERP

Once those moves are in motion, it is time to shift from first aid to direction. You do not pause ERP. You stand up a thin PLM backbone beside it, then grow the backbone as value appears.

Set the intent in one page. ERP is not PLM. ERP runs transactions. PLM holds the digital thread, across design, make, service, suppliers, and customers. Write that sentence at the top of the page. Add three outcomes you will prove in six months, for example clean eBOM to mBOM flow for a priority family, released change packets consumed by ERP without rework, and traceable compliance attributes on every release.

Create a Product Truth Council. Three or four senior practitioners with decision rights from design, operations, quality, and data. Meet weekly. Resolve rules fast. Retire spreadsheets with respect.

Scope a thin digital thread MVP. Pick one product family that touches real volume. Model only what is needed for flow. States, packet, structures, and two or three critical attributes that operations and customers care about. Prove that the thread runs into ERP and out to the line.

Design coexistence, not big-bang replacement. Map where PLM is the master and where ERP is the master. Define the events that move data, for example release, effectivity start, supersession. Avoid nightly dumps that reintroduce spreadsheets by stealth.

Fund by value-back, not by headcount. Each quarter, the council submits the rework avoided, the time saved, and the quality impact from the thread. Use that to pull the next increment. Momentum comes from results, not banners.

Make change human. Protect a small core team from context thrash. Teach supervisors how to recognise a good packet. Run short, practical training that replaces five Excel steps with two governed actions.

This is how you grow PLM while ERP is flying. You avoid a second giant programme. You build a backbone that outlives this ERP phase and supports the next decade.

What this unlocks across the functions that run your business

The same thread runs through every benefit, you remove fragile Excel and SharePoint glue, and replace it with traceable product truth that ERP can trust.

Finance, where numbers must add up and stand up

What changes:

• Cost roll-ups become trustworthy because structures and routings match released configurations, not improvised lists.
• Inventory adjustments drop because effectivity is clear and superseded parts are controlled, not trapped in tabs.
• Month-end closes faster because there are fewer manual journals to reconcile product and execution truth.
• External reporting gains credibility because product-level compliance and footprint data can be traced back to a release.

What to watch:

• Variance from standard cost on top sellers.
• Obsolescence and write-offs tied to uncontrolled changes.
• Days to close and post-close corrections linked to product data.
• Percentage of releases with verified compliance or footprint attributes.

Operations, where flow meets reality every hour

What changes:

• Schedule adherence improves because changes arrive complete and on time, not as fragments in email threads.
• First pass yield rises because instructions and tooling match the released configuration.
• Deviation and rework loops shrink because quality events tie back to a specific change and state.
• Supplier performance is clearer because the mBOM and material attributes are stable and visible.

What to watch:

• OEE trends on lines tied to the most changed products.
• Rework hours per change and late change requests inside freeze windows.
• Supplier on-time and right-first-time for affected items.
• Mean time to implement a change packet end to end.

Design and Product Engineering, where change creates value

What changes:

• Handover to manufacturing becomes faster and calmer because eBOM, drawings, and specs travel together with context, not as a chain of links.
• Reuse increases because teams can find and trust the last good solution and its state.
• Compliance by design becomes standard because required attributes sit inside the product definition.
• Feedback loops from quality and the line strengthen because issues are tied to configurations and dates.

What to watch:

• Engineering hours lost to rework and data hunting.
• Time from design freeze to first article approval.
• Percentage of change packets complete at first submission.
• Number of design decisions supported by verified supplier and material data.

Objections I hear, and how to move through them

“The executives do not see the value.” That is fair. PLM does not look like ERP or finance. There is no single ledger, no obvious daily dashboard. Its value is the seam that lets design, operations, supply, and service move as one. If you judge PLM as a tool, it reads like an overhead. If you judge it as the backbone for product DNA and flow, it reads like margin protection and speed to revenue.

“We cannot afford PLM right now.” On paper it looks like a new cost. In reality you are already paying for the absence of PLM every week, in rework, expedite freight, yield loss, late changes, and long month-ends spent reconciling mismatched truths. A thin backbone reduces those silent taxes by making releases complete and consumable, so ERP, the shop floor, and suppliers stop guessing. Start small, retire the three most expensive spreadsheets, and fund the next step from the waste you remove. Price the problem you have today, not just the software you might buy.

“There is change fatigue. We should not add more.” Agreed. Another programme makes it worse. The fix is not more change, it is better change, smaller, cleaner, and predictable. A thin PLM backbone reduces noise by turning scattered files into governed packets and simple states, so people stop firefighting and start flowing. That lowers the temperature of ERP and makes the next change easier to absorb. Less churn, fewer surprises, same people.

“We have no capacity.” Capacity is being consumed by hunting, fixing, and doing the same work twice in Excel and ERP. Create capacity by removing that friction. Protect a small core team, give them permission to define the five non-negotiable product truths, and measure hours released as you retire legacy workarounds. When changes arrive complete and effectivity is clear, planners, engineers, and supervisors get time back to spend on throughput and quality. You make space by stopping waste, not by adding headcount.

“What we have works. Why change it.” It works because good people are papering over gaps, not because the system is sound. The risk shows up at scale, under audit, or when key staff leave. PLM does not erase that ingenuity, it codifies it into rules, packets, and states that anyone can run. The benefit is fewer late-stage surprises, steadier margins, and product evidence you can defend with customers and regulators. Keep Excel for analysis, retire it as master of record.

“We are too busy.” Busy is the signal, not the excuse. The busyness comes from unclear ownership, partial packets, and one-off fixes that creep back into the work. Start with one product family and a 30-day focus on complete change packets and clean eBOM to mBOM flow. When the Friday firefights ease and right-first-time rises, you earn the right to extend it. Being busy is why you need PLM, not why you delay it.

“We will do PLM after ERP.” You can, but you will pay twice, once in ERP disruption, then in a retrofit that fixes the mess ERP revealed. You do not need a parallel mega-programme, you need a thin backbone in parallel that ERP can trust. Define states, packets, and the eBOM to mBOM rule for a priority family, then feed ERP cleanly. The benefit lands inside this ERP phase, and the backbone you build becomes the digital thread for everything that follows. Finish ERP stronger than you started, not with more process debt.

Closing thought

If you are mid-ERP and your team has just realised that product truth is not ready, you are not alone. The instinct is to delay PLM or to launch a second giant programme. There is a better path. Stabilise the present with five practical moves. In parallel, stand up a thin PLM backbone that proves the digital thread. Keep Excel for analysis, retire it as master. Let software follow your rules, not the other way round. Then grow by value, one clean release at a time.

Where are you seeing this in your own factory, and which move would change your next quarter the most?

Transform Your Operations with Nick Leeder & Co

Are you ready to elevate your engineering, manufacturing or sustainability initiatives? Partner with Nick Leeder & Co, an award-winning digital transformation coach, to boost your operational performance and reduce your environmental footprint. With over 25 years of experience, we specialise in guiding leaders like you through the complexities of Industry 4.0, ensuring sustainable growth and impactful results.

Join the ranks of industry innovators and leverage our expertise to unlock your factory’s hidden potential. Don’t miss the opportunity to work with seasoned professionals dedicated to your success.

Contact us today and ignite your digital transformation journey.

Learn more about our services.