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.

I had the chance to participate in a discussion by Bob Deragisch of Parker Hannifin at COFES last week. His topic, Living with Heterogeneous Systems, is a top of mind issue for many large manufacturers I speak with. So has Parker found the key to managing disparate engineering and enterprise systems? In a word, no. Sorry, there was no silver bullet answer uncovered by Parker or any of the other participants. But the steps Parker has taken and the ongoing challenge are worth discussing.

The Parker Scenario

Here are some of the key thinkgs that I took away from Bob’s discussion and description of the Parker Hannifin systems ecosystem:

• Parker Hannifin is now 135 divisions
• They have acquired 120 companies of all sizes
• Just in aersospace (Bob’s area), they have 8 divisions … and 6 ERP systems!
• They have even more engineering tools than ERP systems - 185 engineering tools

Does that sound scarey? It should. How can those systems possibly be integrated into a consistent, repeatable workflow? How can data be shared effectively across so many tools? How can engineering data be reused? How can employees be shared between divisions (or from program to program) to meet capacity needs? This is the challenge that Parker faced. This is not that different than a lot of big companies, particularly those that have grown through acquisition.

Parker’s Response

So given the challenges, what has Parker done? The first thing Bob made sure to say was that he wasn’t at COFES to present the answer, he was there looking for answers. He described what Parker has done to date. He explained that the first step was to try to homogenize. Parker developed corporate standards for their engineering tools. They have developed a systems design process that narrows tools down to 20 tools. For some, 20 might sound like a lot of engineering tools. For many, that number sounds like an unachievable dream. For Parker, it is a set of standards they are trying to move towards. They have one standard MCAD (mechanical CAD) tool and other singular standards for tools such as ECAD (electronics CAD), requirements management, and others.

So how has this worked? Trying to standardize on a single MCAD tool, for example, is “like herding cats.” There has been a lot of resistance by engineers that feel they are more productive in their tool of choice. Externally, Parker faces challenges in consolidating tools because they supply components and subsystems to other manufacturers. These customers ”expect designs to come in their format.” And Bob says they have given up on CAD interoperability.” Bob did add, however, that they expect interpoerability from PLM.

So is there help? PLM systems help manage the data and processes from all of these systems, and is a key part of the answer. New architectures make integration easier (see The Evolving Roles of ERP and PLM in Manufacturing). But this will be an issue for some time to come. If you have the answer, let us all know (and I will pass it on to Bob).

So that’s what I hear from Bob Deragisch at Parker, I hope you found it useful. I found his discussion relavent, open, and honest. Parker, as much progress as they have made, is still looking for answers. What do you think?

A quick peek into some research on … the technology behind PLM applications, and what today’s CIO needs to know to support it. The research from Tech-Clarity, Enabling Product Lifecycle Management: The CIO’s Guide to Supporting a PLM Initiative,  points out unique implementation and support challenges the CIO and their team must be aware of in order to get the most business value out of PLM.

The Research Findings

The CIO’s organization is getting more involved in PLM implementations. While many Engineering IT teams have managed CAD and other engineering software and supporting infrastructure, PLM is getting more attention from the enterprise IT team because it has become – (wait for it) – an enterprise application. I know, it only makes sense. Implementing enterprise class applications has different considerations than installing design tools, and enterprise IT typically has more experience with systems that span the organization and the supply chain.

Having said that, PLM is not ERP. Nor is it CRM, SCM, or any host of other business-oriented enterprise applications. PLM, by the nature of the processes and data it addresses, comes with some unique information technology challenges. Here are some of the considerations discussed in the report:

• Protecting IP – PLM data is concurrently highly confidential, and much more valuable when shared broadly. Intellectual property is more likely to be shared as collaboration expands, and a lot of that collaboration is outside of the control of the corporate firewall.
• Huge Files – Engineering and product development data is different than large volumes of transactional data. There are some potentially significant issues arising from managing and collaborating on large files in order to support PLM.
• Scalability – PLM is expanding to more people, a broader view of the product, to more of the product lifecycle, and supports more processes. Implementations needs to plan for expansion along multiple dimensions, which could potentially create an exponential demand on IT infrastructure.
• Architecture - PLM vendors are moving to enterprise architecture, providing support for the challenges above but also introducing new challenges. The good news, though, is that these challenges are ones that the many corporate IT groups have already addressed.

PLM also brings about integration challenges. Companies have to be ready to support frequent, bi-directional, real-time integration between PLM. If not in the first phase, potentially sooner than they think. See more on ERP-PLM integration in the Evolving Roles of ERP and PLM report and Mythbusting ERP-PLM Integration post. PLM integration with ERP and the rest of the manufacturing systems ecosystem is becoming more important and more prevalent.

Implications for Manufacturers

The good news? The PLM industry has learned from large scale PLM deployments, and has developed technology and best practices to address these issues. IT professionals today are not blazing the trail when they implement PLM. PLM is becoming much more mainstream. But it is also evolving to more of an enterprise application than just product data management (PDM), and moving into the enterprise realm. There is help available, from peer manufacturers that have undergone the transiiton and experienced consultants alike.

So that was a quick peek into some recent research on getting PLM technology right, 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.

I had the chance to talk with … the PLM team at SAP recently to get an update on their plans and their progress to date. I have stayed in touch with them over the years, and have always been impressed by the opportunity they have to connect the business of manufacturing with the business of product development. As I reflected on the conversation, I struggled to understand why after all of the years of SAP getting too much credit for PLM, why they don’t seem to be getting as much credit for their recent efforts as I would expect. Today I hope to present both sides of the argument in the hopes to bring some clarity to the subject, and to start a conversation so we can all learn from each other.

Too Much Credit?

I have focused a lot of discussion on the complementary roles of ERP and PLM, and for many companies that translates to the roles of SAP and PLM. I have cautioned manufacturers in the past:

• Not to assume that an ERP provider that “checks the box” for PLM actually has a suitable PLM suite
• Don’t assume that any company offering both ERP and PLM have actually integrated them in a way that works for their particular business
• PLM suites vary significantly between vendors, even among the “best-of-breed” vendors
• PLM is not just another module of ERP, but a suite of solutions itself with some unique requirements

Those comments were typically in reaction to the “suite provider effect” where executives take a cursory look at a software requirement (such as PLM) and say “Doesn’t our ERP company have that? Let’s just use theirs.” While the ERP vendor’s solution deserves a review, if it doesn’t meet the business needs than the potential benefits of a single vendor and an integrated solution don’t add up to much. This conversation started way back in 2003 with my article Can ERP Speak PLM? in Technology Evaluation Centers (TEC) when I served as the analyst for the PLM Evaluation Center.

With all of those cautions in mind, my hope was that manufacturers that have an ERP (such as SAP) would do a thorough evaluation of their needs, and then select the solution (or solutions) that would work best for their business. In other words, they shouldn’t just take PLM from their ERP provider blindly.

Not Enough Credit?

With all of those cautions aside, the ERP provider should get a fair evaluation. There are benefits to integration and a single vendor solution. And SAP has clearly invested in PLM. I wrote about SAP’s PLM strategy and roadmap in the past on my Manufacturing Business Technology blog.* SAP has taken on a multi-year program to enhance their PLM offering, and they have made significant progress. Last year they introduced a new, web-focused interface that pulls together a product-centric dashboard for an item. The “PLM Object Navigator” as it was called offers information about a part from both ERP and PLM perspectives, including configurable sidebars. They have now extended that interface to the process PLM community, where SAP has a significant installed base.

But user interface isn’t all that SAP has focused on. They have integrated CAD management and visual communication capabilities to develop visual representations of the CAD models that all users can access. They have added functionality including labeling functionality for consumer packaged goods (CPG). They have also enhanced product compliance, collaboration, and requirements management.

SAP has remained consistent in their focus to support four PLM “value scenarios,” enabling business processes to help manufacturers in specific initiatives to establish “Product and Service Leadership“:

• Consumer-Driven, Sustainable Innovation
• Integrated Product Development
• Continuous Product and Service Integration
• Embedded Product Compliance

The names have changed slightly over time, but the needs SAP is trying to meet are well-planned, important, and have remained consistent. Clearly, SAP has a plan and has been hard at work to achieve it. 

The Confusion, and the Questions

When I talk to the SAP PLM team, I can feel the excitement and their sense of accomplishment. I hear about the progress on their plans and how they are fulfilling the needs of their customers. Yet from the manufacturers I speak with, I don’t feel the same enthusiasm. So here are my questions:

• Am I talking to the wrong companies, or the wrong people?
• Is it still too early?
• Did the down economy last year stall SAP’s ability to get the word out?
• Does SAP not have the ear of the product innovation, product development, and engineering staff?
• Are manufacturers tired of hearing what is coming?
• Is there just still more that needs to be done?
• Are the best-of-breed vendors too far ahead? Or too entrenched?
• Is there a slow revolution happening that I am just not in touch with?

So that’s what I hear from SAP, and my resulting confusion. I hope you found it interesting. What do you think? Can you help shed some light on my questions?

*Note: Sorry, no link to past posts on SAP PLM right now. Unfortunately the blog was taken offline by Reed Business when they closed the magazine. I hope to get that content back at some point to share with you.

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.