More Enterprise Systems. More PLM Integrations. That’s Not the Problem

PLM integrations are supposed to make life easier. Centralize product data, connect the systems that need it, eliminate duplicate work, and create a cleaner IT landscape. It’s a vision that every manufacturer hopes to achieve, and it looks convincing during the planning phase. In practice, growing businesses often experience something quite different.

When an organization rolls out PLM, they are usually promised a simpler IT landscape. Fast forward a few years after go-live and the integration map has grown, not shrunk. What started as PLM-to-ERP and PLM-to-CAD now includes manufacturing systems, quality tools, supplier portals, customer portals, reporting platforms, sustainability software and more. The first instinct is to ask what went wrong. Usually, nothing did. More integrations is what it looks like when a business becomes more digital and grows. It is not proof that the PLM strategy failed.

Every new tool need product data

Manufacturers are now buying softwares faster than ever. Every department wants a tool that make work faster, give better visibility or adhere to some compliance. The tools are all different, but they all need the same thing, reliable product information.

Engineering needs product structures and CAD data. Manufacturing needs released BOMs and work instructions. Quality wants change history and traceability. Purchasing wants approved supplier and manufacturer part data. Service teams need to know exactly which configuration sits at which customer. Sustainability projects need material data down to substance level.

Each tool adds value on its own, and each one becomes another system pulling data out of PLM. The more digital the business gets, the more systems come knocking.

Old systems don’t actually go away

In most scenarios, companies keep bringing in specialized tools without switching off the ones they already run. After a while they end up with an ecosystem where old and new systems must live side by side. It just start with for few more months and end with for a decade or more.

A typical story goes like this. The company adds an MES to see what is happening on the shop floor. Then a QMS to tighten up compliance. Then a supplier platform so people can stop emailing spreadsheets to vendors. Later someone starts a Digital Product Passport project, or wants an AI assistant that can answer engineering questions. None of this makes PLM less important. The opposite happens. Every one of these projects treats PLM as the trusted source of product data, and every one of them needs a new connection to it.

Product data left the engineering department long ago

There was a time when product information mostly flowed between engineering and ERP, and that was the end of it. Those days are gone.

Most integration problems start innocently. The first project connects PLM to ERP. It works, it delivers value, everyone is happy. The next project needs another interface. Then another. Each one is built by whoever runs that project, in whatever way seems reasonable at the time.

A few years later there are dozens of interfaces, owned by different teams, built with different tools, documented to very different degrees. Half the time, the person who built the oldest ones left the company years ago. Now a small change to a product attribute means touching five interfaces. Testing takes longer because nobody is quite sure which systems are affected. When something breaks there is no single place to look, so troubleshooting turns into detective work. At that point, keeping the existing connections alive starts eating more effort than building anything new.

“Fewer integrations” is the wrong goal

Plenty of transformation programs set a target of reducing the number of integrations. It sounds sensible. Fewer interfaces should mean less to maintain. But the goal falls apart the moment the business adopts its next tool.

If five new applications arrive over the next three years, they will all need product data, target or no target. The target just gets quietly forgotten. Refusing to build integrations only to keep the diagram tidy creates no business value. A better goal is to make every new integration predictable, reusable and easy to maintain. Measure success by how quickly you can connect the next system, not by how few lines sit on the picture.

One thing separates mature integration strategies from the rest is that, they assume change. New software will arrive. Regulations will tighten. Customers will expect more. So the architecture is built for growth instead of being tuned only for today’s requirements.

The companies that handle PLM Integrations well are not the ones with the fewest integrations. They are the ones that accepted early on that the number will keep growing, and then built an architecture that can absorb it.

They stopped asking how to eliminate interfaces and started asking how to make the next one as easy as the last. That shift in mindset, more than any tool choice, decides whether an integration setup stays manageable for the next ten years or turns into a permanent source of technical debt.

Success isn’t measured by how few integrations you have. It’s measured by how confidently you can build the next one.