Why AI won’t fix the HOW problem of PLM implementation without a missing truth layer.
Three recent conversations pushed me back to one of the oldest questions in our field: why is PLM implementation still so hard after thirty years of methodology?
The first was Jörg Fischer’s provocative post arguing that we have finally solved PLM, only for AI to take over the conversation (read it here). The second was Rob Ferrone’s comment on my last article, pointing out that the industry spends enormous energy debating what PLM should be and almost none on how those capabilities actually get established inside a company. The third was Nate B. Jones writing about AI-generated Office files and the discipline of building a“truth layer” before you trust anything an AI produces.
Jörg’s question is about methodology. Rob’s is about implementation. Nate’s is about trust. Put the three together and you get what I think is the real PLM question for the next few years.
We Learned to Describe PLM. We Never Learned How to Make It Work.
I agree with most of Jörg’s case. Over the last few decades the PLM community built a genuinely deep body of knowledge. We know how to talk about product structures, configurations, revisions, effectivity, Form-Fit-Function, change processes, lifecycle models, traceability, and governance. We know why item-centric and document-centric models solve different problems. We know that a revision and an effectivity date are not the same thing. We know that engineering, manufacturing, service, quality, procurement, and suppliers all need different views of the same product.
We also know the failure patterns by heart. Product data is fragmented. BOMs live in spreadsheets. CAD files sit in PDM or on shared drives. Suppliers trade PDFs and Excel files. Procurement works in ERP. The real engineering decisions are buried in emails, hallway conversations, and tribal knowledge, while the documented change process exists mostly on paper.
None of this is new, and that is exactly the point. The industry has produced thousands of slides explaining what good PLM looks like. So I would not say we solved PLM. I would say we learned how to describe it. Knowing how to describe a thing and being able to make it work inside a real organization are not the same skill, and the gap between them is where most PLM programs die.
Implementation Was Always a HOW Problem, Not a WHAT Problem
This is where Rob’s comment cuts to the bone. The industry loves to argue about the destination. Should PLM become a system of record, a digital thread, a product graph, a collaborative workspace, a knowledge network, a context layer, an agent platform? These are interesting questions. They are also the easy ones.
The hard question is how a company with twenty years of legacy data, five hundred engineers, fifteen ERP integrations, and a history of acquisitions actually gets there. PLM implementations rarely fail because the software cannot manage a BOM or run a workflow. Most mature systems can do that. They fail on the organizational mechanics: who owns the product data, what happens when engineering and manufacturing disagree, how you sustain sponsorship through a leadership change, how you keep momentum when priorities shift, how you move people off spreadsheets that are still faster for their daily job, and how you stop a software project from quietly becoming a five-year methodology debate.
The target architecture can be elegant and the workflow diagrams can be perfect. If the organization cannot adopt the model, the value stays trapped in PowerPoint.
Every Technology Wave Improved the Mechanics and Ignored the Adoption
Every major technology shift promised to make this easier. Relational databases structured the product data. PDM brought CAD files under control. The web improved access, the cloud removed infrastructure friction, SaaS simplified deployment, low-code promised faster customization, and APIs improved integration.
All of it mattered, and all of it changed how systems get built, deployed, and connected. None of it solved adoption. A database does not explain why a process matters. A cloud platform does not coach a reluctant engineer through a new change procedure. Low-code does not resolve a turf war between IT and operations, and an API does not tell anyone which BOM is the one the business actually trusts. Each wave improved the plumbing and left the human transformation exactly where it was.
That is the reason AI is worth a serious look, and it has nothing to do with AI being magic.
AI Is the First Layer That Can Participate in the Work, Not Just Run It
AI is still a technology layer. It depends on data, permissions, security, process design, and human judgment, like everything before it. What makes it different is that it is not passive.
A database waits to be queried. An AI assistant can explain the difference between an engineering change request and an engineering change order, flag a missing approver, compare a proposed workflow against how the team has actually behaved in the past, notice that procurement is ordering against a different part number than engineering released, and generate training material from the company’s own process rather than a generic manual. Earlier technologies required people to understand the system, configure it, document it, and drive adoption. AI can take part in those activities directly.
That is why I think AI can shorten the distance between PLM methodology and execution. The cloud reduced infrastructure friction and low-code reduced development friction. AI reduces translation friction. A process model can become a workflow, a business rule can become automation, a product structure concept can become a working application, and the distance between knowing and doing gets smaller. For an industry whose central failure has always been execution, that is the real story.
AI Can Also Automate Confusion Faster Than Anything Before It
Here is the catch, and it is a serious one. AI does not remove the human problems. It will not create sponsorship where there is none, resolve competing KPIs, end leadership turnover, or convert the PLM luddites. If the business why is weak, AI will not invent it.
Worse, AI is very good at making a bad implementation look finished. It will produce a polished workflow recommendation from incomplete process knowledge, summarize a stale document as if it were current, build a convincing dashboard from disconnected data, and write a tidy migration plan without any idea which source is trusted. The failure mode is not that AI fails loudly. It fails beautifully.
This is exactly the problem Nate describes for AI-generated Office files. A deck looks executive-ready before it is true. A workbook looks like a financial model while its formulas point at the wrong cells. His own example is hard to argue with: at the GPT-5 launch, OpenAI shipped benchmark charts where the bars did not match the numbers, and a human signed off. Polish is precisely the signal we are trained to read as trust, which is what makes the gap dangerous. So Nate’s discipline is to build the truth layer first, before the artifact: an inventory of sources, a map of which claim rests on which source, a log of every assumption, and a verification pass that tries to break the result before anyone else can. Source discipline comes before artifact generation.
If AI needs a truth layer to produce a board deck you can defend, it needs a far deeper one to guide a PLM implementation, because a PLM implementation is not a document. It is a living operating model for how products get designed, changed, sourced, manufactured, supported, and governed.
In PLM, the Truth Layer Is Product and Organizational Memory
So what would a truth layer even contain in our world? Before AI can guide an implementation, it has to know which CAD structure represents the real product, which revision is actually released, which supplier is approved, which change process is official and which one is written down but ignored, which spreadsheet runs the business and which one holds throwaway data, and which part number is obsolete but still being ordered by procurement. It has to know which approval exists because policy requires it and which one exists because the team always did it that way. Without that context AI cannot guide anything. It can only guess, and because it guesses fluently, the guesses look convincing.
That missing foundation is what I have been calling product and organizational memory. Product memory is the connected record of structures, CAD-to-BOM relationships, revisions, changes, effectivity, configurations, supplier and procurement context, cost, and lifecycle status. Organizational memory is the record of decisions, assumptions, ownership, exceptions, approval patterns, unresolved conflicts, and the history of why things were done a particular way. Both are required. A product structure without organizational context is incomplete, a process map without product data is abstract, and a change workflow with no record of the decisions behind it is fragile. AI needs to understand the product and the organization around the product before it can be useful as an implementation participant.
This Is Not Data Migration, and It Is Not Knowledge Management
Two easy misreadings are worth heading off. The first is to treat this as data migration. Moving records from one system to another does not create memory. Plenty of implementations migrated their data cleanly and still failed because the context did not come with it. Why was this part created, which part replaced it, who approved the change, which supplier constraint drove the decision, which customer requirement changed the configuration. That is the memory AI needs, and migration tools do not carry it.
The second misreading is to call this knowledge management. We have been there. Knowledge management too often became a graveyard of documents nobody trusted or maintained. Product and organizational memory has to be operational, connected to the work itself: to CAD, BOMs, changes, suppliers, procurement, quality, and the decisions that move them. The truth layer cannot sit outside the implementation as a separate repository. It has to be built as part of the implementation path.
That also changes the shape of the program. The traditional model was a big-bang transformation: define the methodology, design the future state, configure the system, migrate the data, train the users, go live, and discover years later that the organization moved while you were busy. A memory-grounded approach can start small instead. Capture product and organizational context around one concrete problem at a time, whether that is CAD to BOM, BOM release, change control, supplier collaboration, or the ERP handoff. Each step delivers value and also deposits memory, so the organization learns, the system learns, AI gets more context, and the next step gets easier. That is not AI replacing PLM, and it is not AI configuring everything on its own. It is AI-guided implementation built on a growing truth layer.
What is my conclusion? The New HOW Question
So, did we solve PLM? I still do not think so. We solved a great deal of the methodology, and that knowledge is valuable and should not be thrown out because AI is in fashion. But the unsolved problem is still HOW. How do companies move from fragmented reality to connected product operations, preserve what people know when they leave, and keep AI from generating confident answers out of disconnected data?
Without a truth layer, AI will not solve PLM implementation. It will only automate disconnected reality faster.
Which leaves the real question, and I would rather end on it than answer it. If AI can become an active member of the PLM implementation team, who in the organization is going to build the product and organizational memory it needs to be useful?
Just my thoughts…
Best, Oleg
Disclaimer: I’m the co-founder and CEO of OpenBOM, a collaborative product data management platform that helps engineering and manufacturing teams work with connected, structured product data, increasingly augmented by AI-powered automation and insights.
At Beyond PLM, I’m writing about PLM strategy, architecture, and the future of product data management since 2008.
