Clarity on PLM

What I learned this week … came from a great post on Hypertextual titled Positioning with other IT systems: the liquid nature of Enterprise 2.0. I really enjoyed reading the post, and some of the underlying information linked to it including How Enterprise 2.0 fosters Knowledge Capture. There are some very powerful thoughts here. I think the post does a fantastic job of discussing the value that social computing has to offer PLM (and other applications such as ERP, SCM, and CRM). I see things slightly differently regarding social computing and PLM, but I believe it is in a complementary not a conflicting way. I will respond to the post directly, but I felt I had more to say than I could fit into a comment so decided to share here.

Enterprise Applications Roles

To summarize a few key background points from the post (please read the post, it is worth your time and I will not do it full justice here):

• Referencing Michael Grieves’ book Product Lifecycle Management, Driving the Next Generation of Lean Thinking, the author (Cecil Dijoux) points out that the interconnecting nature of ERP, PLM, SCM, and CRM in relation to domain knowledge and business activities. The model here shows ERP overlapping in certain activities and domains. I couldn’t agree more.
• Later he states that ERP, PLM, SCM, and CRM systems “have very clear boundaries and a strict scope of responsibilities.” That is a good model to work from, although I believe that there are overlapping “grey areas” where roles need to be defined on a company basis. See The Evolving Roles of ERP and PLM in Manufacturing for more of my thoughts there, including how PLM develops plans for manufacturing and quality that are executed in ERP. Oleg has also been posting some very interesting points on ERP and PLM in PLM Twine.

Social Software and Enterprise Applications

More importantly, the Cecil goes further to point out two areas where traditional enterprise applications fall short, and social computing software (what he refers to as ”Emergent Social Software Platforms” or “ESSP”) “fill the gap”: 

• Tacit Knowledge – This is information that is corporate knowledge, and frequently poorly captured. I love the way Cecil describes the issue; “Some studies show that between 25 and 50% of the communication between knowledge workers remains tacit and uncaptured. The question is how can we be productive and comfortable with our daily work if about half of the raw material we’re working with is wandering around ?.“ Knowledge management is a tremendous issue in product innovation, product development, and engineering. In the underlying post on Enterprise 2.0, Cecil says “It is easier and less intimidating for knowledge workers to capture knowledge on collaborative platforms (wiki, blogs, forums etc …)  then on word documents and then knowledge management systems.“
• Communities – Product development is about people, or as I have been known to say “product innovation is a team sport.” Again, I love what Cecil has to say. “ESSP make it easy to build communities which, in the enterprise context, are built around common areas of knowledge, business expertise, and professional know-how. These communities juxtapose different types of experts (technical, marketing, sale, integration) on a specific domain. This allows to build multi-dimensional expertise in very confined and otherwise unreachable locations in the company activity and knowledge map.”

I can’t agree more with what Cecil says about how social computing helps capture tacit knowledge and develop communities. I went back to check, I said almost the exact same things in Going Social with Product Development, although in a different way. What I said is that there are three areas where social computing will help PLM specifically:

• Enhance product development team execution and collaboration
• More naturally capture and share product knowledge and expertise
• Enable the discovery of new IP and product value

I think the alignment with the second point and Cecil’s point on tacit knowledge is clear. My thoughts on communities are represented in both improving collaboration within existing teams, but also discovering new product value through “social discovery.” Please see more detail in the report Tech-Clarity Insight: Going Social with Product Development: Improving Product Development Performance with Social Computing.

My Complementary View

So where do I see things differently? Cecil talks about social computing filling gaps in the enterprise system landscape. In his words, “This provides a liquid nature to ESSPs that helps them to seep in and fill up any gaps left by other systems.” I see this very differently. Maybe it is my old scars from the days when enterprise workflow was going to do the same thing. Instead, I see social computing as a new part of the infrastructure that helps connect and extend applications like PLM into a community. The social software is important, but the product lifecycle management domain expertise is crucial.

What is the key difference in views? Integration. I believe that social software is a part of the answer. But social computing needs to be addressed in the context of PLM. See How Will PLM Get Social? for more of my insight. How will PLM capture knowledge and make it useful unless it is tied back to the underlying product record? It will help, but it will miss the mark. To me, the value in social computing is not as a gap filler. Yes, it fills the gaps of capturing tacit knowledge and developing communities. But instead I see it is a new way to connect and extend PLM to capture and discover knowledge in the context of the product. It is also a way to improve collaboration in the product development community. Perhaps Cecil will agree, we may just be looking at different aspects of the same topic.

Implications for Manufacturers

If you have read this far, you clearly have an interest in the intersection of social computing and PLM. I have only one piece of advise. Keep learning. This is going to have a big impact on how companies innovate and bring products to market, and the manufacturers that are experimenting with social computing techniques in PLM and developing corporate understanding will have a big advantage in the future. We don’t know what that future will look like, but I can tell you it will be different and you don’t want to be caught left behind. On this point, I believe Cecil would probably echo my thoughts. And if you haven’t read his posts yet, go back and learn from them. There is a lot you can take away from his posts.

So that is what I learned from Cecil on Hypertextual (Merci Cecil!) along with some of my perspective. I hope you found it interesting. Let us know what you think.

A quick peek into some research on … closing the loop on product innovation through an integrated ERP-PLM strategy. This paper furthers past research on The Complementary Roles of ERP and PLM and earlier research on how integration between these two enterprise systems is maturing in the Evolving Roles of ERP and PLM. The topic of how manufacturers can best leverage ERP and PLM systems is one that I continue to get questions on, and I hope that this paper, Issue in Focus: The Integrated ERP-PLM Strategy, helps further the conversation. I should also point to a good discussion on Oleg’s PLM Twine generated by my last research on ERP and PLM, there are some good comments made there.

The Research Findings

At the risk of being redundant, the paper reconfirms the primary roles of ERP and PLM:

• PLM – PLM focuses on product innovation, and is designed to help manufacturers design, develop, and launch profitable products.
• ERP - ERP’s role is executing the business of manufacturing, supporting the business of planning and managing the execution cycle.

To many these may seem to be an obvious statements, but I still hear confusion in the manufacturing community. This is particularly true as ERP companies introduce PLM solutions. That is why I clearly “Busted“ the myth that PLM is a module of ERP in my Mythbusting ERP-PLM Integration post.

So what is new in this report? A focus on closed loop integration. Here are the key points that I hope people will take away from the research:

• Innovation is not limited to Engineering – Manufacturing, Service, and other departments innovate too. They change processes and make minor product changes for service or manufacturability to keep things working smoothly. These smaller, day-to-day innovations are frequently not communicated back to Engineering, and are therefore implemented inconsistently and not designed into the next generation of products. I recognize that this is not as prevalent in all industries (due to regulation), but the result is a disconnect between what was designed and what is built and in the field.
• Companies are not Confident Enough to Introduce Changes Rapidly – Many companies do not have a change management process that allows them to rapidly improve their product. Engineering changes are held up into batches or delayed because manufacturers lack the ability to clearly communicate changes to Manufacturing and the supply chain without disruption. The result here is delayed time to market for cost reduction, quality improvements, and minor product enhancements. Or, companies push forward anyway and end up with scrap, rework, and unhappy customers.

A well integrated manufacturing systems environment can help companies overcome these two issues. Closing the loop (through integration) allows companies to rapidly introduce continuous improvements, and keep designs in sync across departments and the product lifecycle.  

Implications for Manufacturers
For manufacturers, integrating ERP and PLM is becoming more commonplace. This is good news. Of course, not everybody has PLM in place yet, although most have an ERP (or more than one in many cases, but that is a different story). Unfortunately, I continue to see companies make ERP and PLM choices tactically instead of strategically. I discussed one example of this in Choosing an ERP to fit PLM. This leads to two other points that I hope manufacturers will take away from this research:

• ERP and PLM strategies are too important to be technology-led decisions, and should be addressed in a process-centric approach.
• Recognizing that both ERP and PLM are critical to product profitability, manufacturers must be uncompromising on the needs of these two systems.

As I say in the final recommendations, “Choose the right ERP and PLM solutions, making sure they meet your company, industry, and manufacturing model requirements.” Get the right ERP and PLM systems first. Focus first on getting software that meets the innovation and execution needs of your business. It is better if those solutions are “integration-capable” through current technologies (SOA, XML, API, etc.). Ideally, the solutions come pre-integrated by the vendors. But integration has to be a secondary set of requirements behind functional capability.

So that was a quick peek into some recent research on integrating ERP and PLM to close the loop on product innovation, 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 … was a retrospective look at an article analyzing how industry-specific PLM application are. The review was in response to a comment on my post In Search of a Common PLM Definition. I had a little bit of fun with the review, and I thought I would share it here. In fairness to Oleg, I decided to use my “mythbusting” technique that I used on him earlier in the year in Mythbusing ERP-PLM Integration.

Responses and Reactions

Need to Document and Prioritize PLM Requirements (Confirmed) - I start by saying companies should document and prioritize requirements. I believe that holds as true today as ever. And I think that you might agree, so let’s confirm that as a statement that holds up today.

Inegrating PLM to Manufacturing (Plausible) - I use “technology transfer” as an example of a very industry-specific part of PLM. For those that aren’t as familiar with the term, it is effectively translating the product as defined in engineering / R&D (and PLM) into a product that can be produced, up to and including instructions for automated plant equipment. This is an area that really hasn’t come to be in most PLM solutions. The example holds trues as industry specific, but despite efforts in Digital Manufacturing (DM) and Manufacturing Process Management (MPM) - most manufacturers are still not yet integrating PLM to plant solutions like Manufacturing Execution Systems (MES) or Manufacturing Operations Management (MOM). The opportunity is still compelling, but I thought we would be further ahead. Hats off to my old friends at Sequencia for being ahead of the curve.

Product Portfolio Management in PLM (Confirmed) - I use Product Portfolio Management as an example for a general solution. I think this one still stands true, and is a hot topic in product innovation and product development today.

My Bio (BUSTED, big time) - Most importantly, what was I thinking with that bio picture? I think I thought it made me look like a serious analyst. Instead, I just look like I have a stomach ache (and seriously need a haircut). Yikes. Busted. Definately.

So that is a brief look at some old research with the benefits of hindsight, I hope you found it interesting. Who knew? I didn’t, if you did let us know about it. I look forward to additional commentary (although not on the picture, the glasses, or the haircut please).

NOTE: I use the “mythbusting” concept out of pure admiration and respect for such a brilliant concept, that helps kids (and adults) learn about how cool engineering can be while entertaining them.

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.