Clarity on PLM

What I learned this week … was that we could use a good, common PLM definition and scope, but we will not get one. The discussion (a lot of discussion in multiple forums, actually) came from my post SAP, Too Much or Too Little Credit for PLM Efforts and another called Who Will Disrupt Entrenched PLM Vendors? Chris Williams pointed out on a LinkedIn thread that he felt maybe the confusion was due to a lack of understanding of what PLM really is, and asked for a common definition. My response? Not so much.

A Not-so-Common Defintion

Chris asked the million dollar question. But PLM is not one thing. While ERP has matured to a more common footprint across the vendors, the scope of PLM from each of the vendors differs. I define PLM as “processes and software used to improve product innovation, product development, and engineering performance.” That is (by definition, not by fault) very broad. There is no one “PLM” definition. The vision of the vendors shows consoliation over time, but today they are very different. Siemens includes MRO (maintenance, repair and overhaul) for A&D. Dassault Systemes has spent much more effort in “lifelike simulation.” PTC includes development of product documentation. Then, there are the applications that don’t come as a part of the suite, which makes each implementation different. Aras includes APQP and quality. They are all different.

Implications for Manufacturers

The lack of a common definition is also why putting in PLM without a strategy is a quagmire waiting to happen. But a common defintion won’t help. While there are standard processes in PLM, they are not as common as in ERP. There are examples of common processes, such as Stage-Gate processes for new product development (NPD) or CMII for change management. But product innovation and product development are not as standardized processes as accounting, as an example. It is not the lack of common PLM system definition at the root of this, it is the lack of common PLM processes. And as much as companies like Invention Machine are putting process orientation into innovation, it will still not be as standardized as ERP functions like human resource management.

So, manufacturers really need to think about what problems they want to solve before implementing PLM. You can’t just install the software and expect any benefits (beyond maybe simple data management). This is what I call the PLM Program, a strategy and vision for PLM that you accomplish in small, incremental steps.

So those are my thoughts on a common PLM defintion, don’t hold your breath waiting for it. I hope you found it interesting. Do you have a better one? I didn’t, if you do let us know about it.

That, by the way, is one of the reasons it is very hard for ERP to simply build another module and call it PLM. That is why SAP has a long program to develop PLM (which will be yet another variation on the PLM theme, different from the others).

A quick peek into some feedback on my research on … the Evolving Roles of ERP and PLM in the manufacturing industry. First, thanks to Oleg for his feedback an continuing the ERP-PLM conversation on PLM Think Tank. Oleg made some very good points and provided some good research on the research. But in the spirit of a healthy debate I want to “myth bust” his response. I will address each of the sections in his response idividually, although I split the first one into three responses.

Responses and Reactions

Managing Innovation (Busted) - The title to Oleg’s report does not reflect the thrust of my paper, but he touches on a topic that is near and dear to my heart. He makes a strong point that innovation can’t be managed. I think the first two responses to his post say a lot, particularly the first one, show that this isn’t the case. No, we are not going to automate innovation with a product line of robots. But the energy and time of smart, innovative people can be harnessed and guided to produce more results by following an innovation process. I call this operationalizing innovation. It is about process. Really.

Distinct Roles of ERP and PLM (Busted) - The point that I was making in my paper is that ERP and PLM serve different purposes. PLM helps drive product innovation, ERP helps execute the business of manufacturing. PLM’s primary role is not managing innovation, it is helping companies innovate, develop new products, and engineer them more effectively. These are fundamentally different purposes. Yes, there is overlap. But there are more differences than overlaps. See the table below for more of my thoughts on this.

PLM as a Module of ERP (Busted) - Oleg disagreed with my statement that “PLM is not just another module of ERP” and points out SAP as an example. I disagree strongly with this. SAP tried to introduce PLM as just another module. If they were successful there would be no market for PTC Windchill, Siemens Teamcenter, or Dassault Systemes Enovia. What has SAP done over the last couple of years? SAP  developed a multi-year program to introduce PLM as a complete subystem to ERP instead of a module. See my post Does SAP “Do” PLM? for more on that. Can an ERP vendor provide PLM? Sure. Is it part of the ERP system itself? Not in the near future. Need more proof? Oracle bought Agile instead of developing further on their e-business suite. Busted.

Design and Product Data Management (Confirmed) - The core of PLM is data management. PDM should be rock solid, with very robust security. I do believe that extending to other areas (compliance, costing, etc.) that leverage that core data makes absolute sense. It is like building a house on an unstable foundation, it may look nice but in the end it will collapse.

Cross Funtional Processes (Plausible) – I absolutely agree that processes are organizational.  I believe that business processes absolutely come before software and functionality. I also agree that business processes cross enterprise boundaries (click to see the article with that same name). But my point was – and still is – that companies need to choose which processes will be supported by which solution. Yes, the answer can be that some processes are supported by a combination of the two. And I would love to see business process management (BPM) play a role, even to the point of developing composite applications that leverage the functions of each system. But the point is that there are some overlap areas where companies need to choose. There is more to agree with here than disagree, though.

PLM and ERP Integration (Plausible) – I didn’t go into technical integration in my report. Why? Because I believe that it is more important to get the ownership of data and the alignment of business processes right. This includes addressing semantic differences between the systems. The days where we couldn’t get one machine to talk to the other or data was stored in a proprietary format were the dark days of integration. Today, the technical side of integration is “easy.” By “easy” I mean it is a simple matter of time and money, but it is possible. It no longer requires magic. But it does require effort. And there are some good integration stories between ERP and PLM, but currently it is mostly customer or through integration partners. So we are mostly in agreement here (I think).

Where Does PLM Stop and ERP Begin? (Busted) - Oleg says “don’t even try to put this border.” Unfortunately, as a manufacturer you have to. You have to develop a strategy about which system will address which process (again, it can be a combination). From a vendor perspective there are no boundaries, and I am not suggesting some industry standard footprint of each solution. But for an individual implementation? In some processes you have two tools that can do the job, you have to pick.

Summary
So that was a “quick” reply to Oleg’s comments on my recent research. I hope you found it interesting. I hope you found it entertaining. Mostly I hope you (and Oleg) recognize the good spirit in which this is written. Respectful debate is good for all of us. I appreciate Oleg’s perspective even when I disagree. And more often than not, we agree.

Do you see it differently? Let us know what it looks like from your perspective.

Please feel free to review more free research and white papers about PLM and other enterprise software for manufacturers from Tech-Clarity.

What I learned this week … came from some reflection on a workshop I conducted on enterprise systems for a small division of a large A&D contractor. We discussed their needs for functionality across a number of different solutions including ERP, PLM, QLM, and EPM. Other than a craving for alphabet soup after all of the acronyms flying around the room, I took some time to think about the enterprise systems ecosystem and how disjointed it is. I couldn’t believe the number of different, disconnected solutions they needed. It begged the question, should we fight best-of-breed or embrace it?

My Observations

On the one hand, I realized that there was no one system that could handle all of their needs, and that they would have to address overlaps and conflicts between the systems they needed. Their business strategy requires capabilities including:

• ERP
• PLM (Product Lifecycle Management) – including a significant amount of document/content management
• EPM (Enterprise Program Managment) – including project accounting and billing for government contracts, which might not really fit cleanly under the EPM label
• QLM (Quality Lifecycle Management – including process management for things like ISO, CAPA, and others

As they begin to look at solutions, I am hopeful they find and ERP that meets their program/contract accounting needs. I am also hopeful that either their ERP or PLM will be able to give them a start on their quality and risk management requirements. I am also thankful that they don’t need customer relationship management (CRM), supply chain management (SCM), or service lifecycle management (SLM) right now – just thinking about integrating all of that makes my head spin.

Even without the other solutions, this was a big laundry list of solutions for a small manufacturer to tackle. I was concerned about the best-of-breed approach we were arriving at, although I am not aware of any single, integrated solution that would meet their needs. Then, I also realized that integrating the collection of solutions they need will be a lot easier than it would have been even five years ago. In many cases, integration today involves connecting web services. It still takes work to map out processes to the appropriate solutions and define cross-application workflow (reminds me of an older article I wrote on Business Processes Cross Application Boundaries, still interesting to read I think). But the technical job of integration has gotten much easier. While I don’t expect this company to develop a lot of sophisticated composite applications, simply tying capabilities together in a portal and creating hyperlinks between information may take them a long way.

Implications for Manufacturers

I believe that the trade-offs between a fully integrated solution and a best of breed approach have shifted. Integration is still not easy, but the need to trade off critical functionality for integration has diminished. For example, in the integration of ERP with PLM we have seen a lot of advancement, and I see a lot of standard integration offerings between vendors. And as one participant in a recent study on ERP and PLM integration indicates, even solutions from a single vendor typically require integration work because one size does not fit all. But if we stick with best-of-breed, don’t we perpetuate the lack of standard application boundaries and overlapping scope issues we find with the different applications? Clearly, there is still a trade-off to be made.

So those are some of my thoughts on best-of-breed strategies, I hope you found it interesting. I hadn’t really given enough thought about how much has changed until putting it into context for this manufacturer. What do you think? Is best-of-breed returning to favor as the preferred approach? How much functionality are you willing to trade for integration?

What I learned this week … came from a question in response to my post on The Evolving Roles of ERP and PLM in Manufacturing. The question came from a knowledgeable source, and I had to think hard before answering. I thought I would share my thoughts here instead of responding via e-mail for two reasons. The first is I think there are other questions that should be asked first, and other readers might get some value out of the answer. The second is that some of you might be able to answer the initial question better than I can. It also caused me to go back and review a report from five years ago to refresh my memory on my recommendations, and I think they hold up pretty well today (sigh of relief).

The Question

The question as asked was “For a mid-size company that has a complex Bill of Materials, are there specific ERP systems that integrate well with CATIA and SmarTeam?” It was a good question, and I started developing a mental list of solutions that I thought might fit will with SmarTeam. Then, a red flag popped up in my head. What level of priority are we giving integration to PLM in making an ERP decision? As much as I firmly believe in the need to integrate ERP and PLM, making the right choice of each system overrides any ease of integration between the two. As I wrote in my first paper on this topic titled The Complementary Roles of ERP and PLM “relative capabilities should be based on analysis of products and references, as not all systems are alike” and “clearly a manufacturer can’t choose between product innovation and corporate execution – both are critical elements of the manufacturing business model.”

Implications for Manufacturers

For manufacturers that are looking for an ERP system, please put PLM integration on your list of priorities. But also consider where in the priority list it should really be. Having the wrong ERP system well integrated to PLM is far worse than having the right ERP system without integration to PLM. ERP is essential to running the modern manufacturing enterprise. And as much as everyone likes to call ERP a commodity and say they are all the same, they are not. If I was advising a company to look for an ERP system, here are some things I would put on the priority list before integration with PLM. If I thought about it harder, I might add some more, but these are off the top of my head. Part of this was included in the original question, and I am sure they would have taken these into consideration as well, but I thought it was worth sharing:

Industry – Does the ERP system work in my industry? How many references do they have like my company?

Manufacturing Model – Am I a make-to-stock, make-to-order, assemble-to-order, engineer-to-order, or project-based job shop manufacturer? ERP requirements for each are very different.

Sales Model – Do I sell directly or through a distribution network? Do I rent or lease products in addition to selling them? Does the ERP system address those? What about service?

Company Size – Does the solution fit the complexity of my business? If I am a small to midsize business (as many SmarTeam customers are) then do I really want a highly complex ERP system designed to support multi-nationals?

Geography – Particularly if the ERP is supporting financials, does it meet the regulatory and accounting needs of my country. Taxation? Human resources? Are they up to date?

Technology – Can I support the technology? Does it fit with my strategic IT infrastructure?

Support – This isn’t about the product itself, but about the whole solution (including training, hotline support, new releases, etc.) Is their support sufficient for my needs? Can I find local resources to help? As I said in the original paper, “For best results, the analysis of ERP and PLM should extend beyond the product into the software vendor’s capabilities for training, provision of best practice templates, business knowledge and solution implementation.”

After that, I would look for the ability to easily integrate with other solutions. If there was pre-integration with my existing PLM system that would be great. But first, I would make sure that I bought the right ERP system. By the way, this goes the other way as well. I would not buy a PLM system just because it came pre-integrated with my ERP solution, or even because it came from the same vendor. First it has to work to support it’s intended function. Then, and only then, is it worth integrating to other enterprise systems.

So that is how I feel about integrating ERP and PLM, I hope you found it interesting. I realize I jumped up on my soapbox a bit here, but I thought it was important that people understood that I wasn’t promoting integration over functionality. And as for the original question, please feel free to contribute your thoughts on which ERP fits well with SmarTeam and I will pass them along (with my above caveats that it should be checked first for other factors).

A quick peek into some research on … how the roles of ERP and PLM have evolved from Tech-Clarity’s most recent report, Tech-Clarity Insight: The Evolving Roles of ERP and PLM – Integrating the Roles of Execution and Innovation. This research is a follow up to The Complementary Roles of ERP and PLM. The paper furthers my previous research and describes how the use of these enterprise systems has evolved, and the associated maturation of the integration between ERP and PLM systems. As my past research has concluded, these systems remain the cornerstone of product profitability and are better together.

The Research

The research included interviews with manufacturers Emerson and Cameron, along with an interview with a Systems Integrator that focuses on ERP-PLM integration. What I appreciated the most about the integrator’s perspective is that they partner with leading vendors of both PLM and ERP software, and understand both perspectives. Having worked closely with ERP systems prior to reconnecting with my engineering roots and focusing more on PLM, I recognize how rare it is to speak with people that really understand (and respect) both domains.

The Research Findings

At the highest level, the key takeaways from the research are:

• PLM and ERP still play distinct, complementary roles in helping manufacturers drive product profitability
• ERP supports the business of planning and managing the execution cycle
• PLM owns the innovation cycle – including product development and engineering
• Companies are making great progress in integrating ERP and PLM, as ERP-PLM integration has become the norm and many have moved to advanced levels of integration

What Else is New?

The advances in integration caused me to rework my “Innovation Cycle – Execution Cycle” framework that I use to explain the roles of ERP and PLM. I have changes the model to reflect a more bi-directional model, and to support exchanges of more advanced information including:

• Bill of Process (BOP) – including the ERP “routing” in addition to the manufacturing BOM
• Quality, Compliance, and Cost plans – from PLM to ERP for execution
• Actual results – from ERP to PLM, including costs, inventory levels, etc.

The other thing that is new is not well reflected in the graphic yet. That is that ERP is frequently managing the execution of the manufacturing business, but not necessarily executing it. There is frequently a layer of solutions including Manufacturing Execution Systems (MES), MRO, Supply Chain Management, and others that manage real-time execution and integrate to ERP as the backbone. But that is a study for a different time.

Implications for Manufacturers

So what can manufacturers learn from this research? The first thing is that they shouldn’t be spending their time choosing between ERP and PLM. They need both. The second is that integration has moved from a “nice to have” to a standard, and that more advanced companies are extending ERP-PLM integration beyond release to manufacturing and change management. Companies that haven’t integrated the ERP and PLM systems are now behind the competitive curve. Of course if your company doesn’t have both ERP and PLM, your business is either very unique or the chances are you are even farther behind the curve. The good news is that it appears easier to integrate ERP and PLM than ever before due to advances in technology, and that companies are improving efficiency and reducing cost by doing so. So the task at hand is easier to achieve, and provides solid payback. Sounds like ERP and PLM integration needs to be on everybody’s enterprise systems agenda.

So that was a quick peek into some recent research on the roles of ERP and PLM, I hope you found it interesting. Does the research reflect your experiences? Do you see it differently? Let us know what it looks like from your perspective.

Please feel free to review more free research and white papers about PLM and other enterprise software for manufacturers from Tech-Clarity.

What I learned this week … is a thought sparked by a post in the Daily PLM Think Tank on Engineering and Manufacturing Data Management back in 1992. The post isn’t from 1992, but Oleg was re-reading some books from that time and commented on some issues that the manufacturing industry is still struggling with after 17 years of progress. I know there are strong proponents of the single bill of material (BOM) concept, but I wonder if we will every really get there and whether we haven’t made some really good progress managing bills of material with different perspectives. And maybe, just maybe, there is an easier way.

The Single Bill

Oleg’s post doesn’t go into detail, but the first issue he shares is “Multiple Bills of Material” and follows with “Relations between Design, Engineering BOM and Routing.” The truth is that Engineering works from a different BOM than Manufacturing does. And, as the post also points out there are also separate “Maintenance and Repair Bill of Materials.” There are strong arguments for a single BOM that supports different views for different people (engineers vs. manufacturing vs. service, etc.). And there are very strong proponents (to the tune of religious zealot levels of belief). So for this discussion, let’s take as a given that it would be great to have a single BOM.

Single BOM – Feasible or Folly?

Now that we are all friends, it is time to ask a practical set of questions:

• Is a single BOM really feasible?
• How hard of a transition would it be to support processes for a single BOM?
• And (most importantly) how much is it worth?

Let’s face it. Engineers care about things that manufacturers don’t. And manufacturing engineers care about things that design engineers don’t. Manufacturing really requires a lot more information than engineering, they require an integrated view of both the materials and procedures required to product a product – a Bill of Process (BOP). See more thoughts on the BOP in Research Rap: Enhancing Productivity and Reducing Cost with MPM and the Digital Factory and the related research report. Can the BOP be a different view of the same BOM? Yes, potentially. But that asks a lot of the people, the process, and the data model.

One other consideration is the difference between what an ERP needs to execute the business of manufacturing as compared to what engineers need. ERP BOMs frequently include information used for costing and consumable items used in manufacturing. They also summarize a detailed set of components into a single part number for procured items or sub-assemblies based on how they are physically present in the manufacturing environment. Even ERP routings are much simpler than the detailed BOP, primarily focusing on the level of detail required to track cost and plan production. See Research Rap: Complementary Roles of ERP and PLM in Innovation and look for some new Tech-Clarity research coming soon on the integrated roles of ERP and PLM. Again, can these be different views of the same data? Of course. But as we have proven by history, people aren’t moving in that direction with any great haste because it is simply hard to pull off.

We haven’t even touched on service, spare parts, preventitive maintenance, or discussed tracking “as built” or “as serviced” BOMs. But let’s just agree for the sake of argument that they are not easy to integrate.

Cost-Benefit of the Single BOM

OK, you are probably thinking “why didn’t he answer the questions he asked in the beginning of this section? All we have discussed so far is that it is difficult. So let’s conclude that there is a cost associated with moving to a single BOM approach. And for now, let’s ignore what it would take to transition from the “as is” to the “to be” state.

Now that we have agreed there is challenge and cost associated with a single BOM approach, the most logical question is to ask how much value the single BOM provides. Clearly, a single BOM would contribute to fewer errors and disconnects between all of the different people in involved in a product over the product lifecycle. It would go a long way towards the “single version of the truth” in regards to products that we all profess. But here is where I want to throw out a different question. Instead of comparing the cost-benefit of the single BOM approach, let’s look back at history and see if an alternate approach has been evolving as PLM has matured.

Single BOM or Associated BOMs?

Manufacturers and PLM providers have not ignored this topic. I would argue that a lot of progress has been made. How? Companies have spent a lot of time and effort making logical connections between different BOMs, and developing tools to help develop and synchronize different BOMs. For example, PLM, MPM, and Digital Manufacturing software helps companies translate an engineering BOM into a manufacturing BOM and then further into a BOP. In fact, they have gone further upstream to match conceptual BOMs and requirement structures downstream to BOMs. Maybe you would call these “workarounds” to the real answer of a single BOM. But I would propose a different view based on history and my observations. Perhaps engineers have done what we do best – addressed the problem in the most practical way as opposed to the most elegant way to solve a problem.

So those are my thoughts, I hope you found them interesting. I will admit that I am not a zealot in one direction or the other, and recognize those that are passionate about a single BOM. I am happy to be educated on different views, but I think the question needs to be asked. Are we trying to achieve our goals by taking the long, hard road when an easier path might suffice? Or am I all wet?

A quick peek into some research on … the respective roles that ERP and PLM play in product innovation. This is not brand new research, but I believe it is just as relevant today as when I initially wrote this almost 5 years ago. Why? Not much has changed – with a couple of notable exceptions (SAP and Oracle). I find myself coming back to this topic on a regular basis, and I am starting to do some research in this area again so I thought I would bring this one back to the surface. It also offers some insight that might be helpful for a recent discussion on PLMTwine that touches on the importance of integrating PLM with ERP.

The Research
The research identified two clear and distinct sets of business processes that companies use to drive product
profitability. These two sets of processes include:

• The Innovation Cycle – characterized by rapid iteration
• The Execution Cycle – characterize by a more linear, repeatable process

These cycles are different, and require different solutions. PLM and ERP were developed – and have since evolved – to meet the needs of each of these cycles. Is there overlap? You bet. Processes like engineering change are consistent challenges to coordinate between these two meta-processes. But for most companies, there is
a clear hand-off point where a design is released to manufacturing (and external suppliers, for that matter)
where ERP takes over.

Below is a table extracted from the research that helps to show the differences between ERP and PLM. These differences are what make each the best solution for their respective set of processes – execution or innovation.

Updating the Viewpoint
So what would I change now that five years have passed? Not much. One other interesting fact from the research (and confirmed by a later benchmark I conducted at Aberdeen Group) is that most companies would really rather have one enterprise solution that covers all of their innovation and execution needs. Unfortunately, at the time none existed. I would love to say that five years later that had changed drastically, but it has not. What has changed? The desire for an integrated solution clearly has not changed, but:

• PLM vendors such as Dassault Systemes, PTC and in particular Siemens PLM have progressed their integration to ERP, focusing mainly on SAP due to it’s market prominence in ERP
• Oracle acquired Agile, giving them a PLM solution (two actually, including Prodika) that will be further integrated with Oracle ERP over time, but is also being sold into other ERP environments (again, including SAP)
• SAP has announced and is progressing on their own SAP PLM roadmap (Update: Look for a One to One on SAP PLM in the near future, we have just had a good conversation with the SAP PLM team about their progress)

Having said that, none of the above are clearly differentiated enough to serve as the “one integrated
answer” that many companies are looking for. So for now, the best solution is likely a hybrid of ERP, potentially some PLM from you ERP vendor, some best of breed PLM suite solutions, and some best of breed point PLM solutions. Sorry, I wish there were a cleaner answer than this.

So that was a quick peek into some recent research on the roles of ERP and PLM. I hope you found it interesting. Does the research reflect reality? Do you see it differently? Let us know what it looks like from your perspective.