PLM & ERP: The Same, Only Different

Recently, I took on a new and interesting assignment: develop and lead a program to overhaul our existing PLM (product lifecycle management) environment, much of which remains from the original implementation 20 years ago. At the outset, I told myself that the biggest mistake I could make was to think this assignment would be just like an ERP project. I also told the team supporting the existing environment that the biggest mistake they could make was to believe that it was not like ERP. In both cases, I was right, as I’ll explain below.

This project actually brings me back to my roots, as I spent the first 10 years of my career working in an engineering environment developing and managing systems in the space we call PLM today. For the last 15 years, I have been actively involved in large ERP programs. That’s why I find the overlap and evolution of PLM and ERP very interesting. To understand the differences and similarities of these two business execution technologies, we need to take a look at how they evolved and their underlying structures.

ERP software grew from packages supporting the general ledger and material requirements planning (MRP) process. These systems are highly transactional, processing small packages of information in a generally dynamic environment. As the cost of computing dropped and the global demands for business efficiency increased, the fundamentals of the business case for enterprise systems came into focus.

During the last 20 years, significant consolidation among ERP software providers has dramatically lowered corporate computing costs, reduced the complexity of integration and created a large market for consulting companies to supply trained development and support personnel (thereby making ERP talent a commodity).

PLM systems at the core grew up from computer-assisted design (CAD) packages. These systems are compute-intensive, with large files and relatively static information. To keep infrastructure and telecommunications costs low, companies tended to deploy PLM locally, and not across the enterprise. Corporate engineering organizations were happy to comply with this direction as it provided some autonomy in decision making. This in turn fragmented the marketplace for PLM development and support. Compared to the ERP market, large enterprise deals were non-existent and the supply base for implementation and support was much more diverse.

Over the last 15 years, companies have adapted their PLM environments to fit their unique product lines and business processes. These customizations are often viewed as intellectual property (IP) and defended as such by the engineers who did the development. As the cost of the software and computing bandwidth has dropped, the business case for enterprise-based PLM applications has clarified – and become much more compelling.

So for those with a foundation in ERP, here are five big ideas that show how PLM and ERP are the same, only different:

1. Upgrade Frequency: You will be doing a lot more upgrades with PLM then you are used to. With ERP you can go four to six years without a major upgrade, provided you play the cycle right. And not all upgrades are created equal in terms of benefits to the business. PLM upgrades are released about once every nine months, and they typically deliver significant performance improvements. So they should not be skipped.

To mitigate the risks associated with such frequent updates, I recommend focusing on the most established functional capabilities, such as product data management (PDM), and staying away from the newer capabilities until the dust has settled and they have proven their worth. There are plenty of immediate benefits to be gained from the solution sets that have been around awhile, and you won’t have to bear the cost of being a first mover or early adopter of the newer, less proven tools. This is no different from the recommended ERP strategies of 15-20 years ago. What was old is new again, just in a different space.

2. Fragmented and Limited Consulting Base: Because of the fragmentation in the PLM space, you will have a difficult time finding deep expertise in these tool sets at commodity prices. The core issue is the difficulty large systems integrators have in building a large talent base to support PLM. Each software package is different (as different as SAP and Oracle in some cases) and each has a relatively small customer base (especially when compared to big ERP players). That means big consulting shops struggle to keep their PLM people busy between projects. Still, they are trying to develop broad-based PLM practices covering all of the major packages, with a few specialists for each of the individual product suites.

With a small supply of PLM specialists, sudden increases in demand will inflate the consulting fees. For all of these reasons, I recommend a “grow your own” approach. In other words, companies are better off building their own internal skill sets using the talents and expertise of those folks currently working on the legacy PLM.

3. Core Infrastructure Management: PLM systems consume large amounts of bandwidth and tend to be heavily dependent on users’ processor speeds. Tools in the marketplace are not well developed to supplement PLM environments. You will need to dust off your infrastructure team’s skills to plan for the appropriate upgrades of users PCs and bandwidth well in advance of expected deployments.

4. Change Management: Most legacy PLM systems have been modified and designed to fit current engineering processes at the local level. In many cases, the users of these systems were the developers, too. This makes for some interesting dynamics when it comes time to replace these systems. The change management challenges cannot be underestimated. By engaging these user-developers early on in the process, it may be possible to transfer their pride of ownership from the old legacy system to the new process design, which will make life easier for everyone (especially project leads).

5. Integration of PLM and ERP: Yes, there is room for the big systems integrators here. The integration between PLM and ERP is amazingly complex for one simple reason: revision control. Most configurations of ERP deal with revision control at the level of bills of materials (BOM) or routing, not at the part dimensional level. For PLM however, changes at the dimensional level are just as important as BOM when it comes to form, fit or function of the part in the end application. Thus, these changes must be rigorously controlled within integration plans. Flowing and controlling these revisions is complicated and will require a significant amount of process design and master data management control. Working with a systems integrator that has “been there, done that and has the T-shirt to prove it” will be well worth the investment.