Joe Barkai on PLM

So PLM is going in many directions at the same time. It's really unclear at this time where PLM is heading, and it seems like both companies and vendors try to pull and push PLM in different directions to meet their needs. So some of the trends, some of the drivers, some of those issues that motivate the and drive the direction of PLM include incorporation of service into products. So services, product and service platforms. So how do we incorporate serviceability and service capabilities into a product? Should we take it as part of the design? So that would be one area that drives PLM forward. Another driver for PLM evolution is the need to improve the efficiency and rate of innovation. So how do we move innovation to the forefront in a more effective way? Innovation today is still not very efficient, very effective. Still the vast majority of products either fail totally or fail to meet expectations. And we need to move innovation into more structured fashion under PLM. So again, SLM innovation would be part of what drives PLM. Another area that really should be part and parcel of PLM already is software development. Over the last several years, there's been tremendous push to improve the efficiency of software development. But the current state is very much in flux and very much fractured and fragmented. We still have a hodgepodge of tools, disconnected tools that address only individual parts of the process. So you have requirements management, you have software development, you have configuration management, and they don't come together in a cohesive way. I did research not that long ago to see what tools companies use, and it's no surprise that The vast majority still use Excel spreadsheets as the primary tool to manage product innovation, in this case software. And obviously this is not scalable, this does not get you to the quality level that you need. So these are some of the drivers of PLM evolution going forward. Yes, you might say that PLM is innovation enabler, but I want to make sure that people don't think that PLM is the way to drive innovation. It's the other way around. Innovation is a culture, it's a process, it's behavior organization. PLM tools are in support of that, and people often make the mistake of saying, "We'll implement PLM," or maybe, "We need to upgrade PLM in order to improve our innovation culture and process efficiency." I don't think this is the case. So PLM, just like many other tools, should be there to support processes. It's process first, tool second. And often we make the mistake of or companies make the mistake of saying tools first and then we'll figure out how to best utilize the tools. And this is one of the reasons why often companies don't see the expected results from their PLM investment. There are many more disappointments than successes in PLM. The biggest misconception is probably that PLM is replacement of poor processes. Or a way to improve poor processes. Neither one is the case. If you have flawed processes, PLM is very good in implementing those flawed processes. PLM is very good in structuring processes, but if they are flawed, again, you're not going to get the results. So the misconception is the fact that— or the conception— misconception is that the PLM will fix flawed processes. The correct way to addressing product innovation, product engineering, and product development is create the right processes, especially around the interfaces. We find that human processes, certainly technology processes, fail in interfaces at the handoff where data needs to be transmitted, when decisions have to be transformed and moved forward and moved further downstream. These have to be taken care of first, care of first, and then the PLM tools to implement those. So let me start with what they should not really focus on, not ignore but not focus on. They should really not focus on features and functions. Again, not ignoring the fact that functionality is important, but this should not be the criteria, the primary criteria for making PLM decision. The reason for that is most tools, if not all of them, are highly capable. In fact, they're probably more capable than the organization needs or knows how to utilize. So it's really not about that. I researched this topic for quite some time now, and it becomes very, very clear that mature organizations do not buy PLM based on features and functions, but rather based on the vendor, i.e., what is the roadmap, the long-term roadmap of the vendor. Because as the buyer, I need to know not that the As a buyer, rather, as the buyer of PLM, I know that the functionality is there, and if the vendor does not have it, they can easily find a way to implement it. It's really about the knowledge that the vendor's roadmap is aligned with mine. As I evolve my business, as I explore new technologies, new markets, new product types, I want to know that the vendor will be there with me to support me in my needs. The question that I I see asked more frequently by, again, more mature buyers is about long-term product roadmap. Do I have an open-door policy, as it were, to not only R&D but also to the executive team? So again, it's vendor relationships and vendor alignment much more so than features and functions. Yes, even though we're a little bit early in the process, absolutely. And it's a trend that has been going on for a little while now. PLM extending its reach into process industries, also into retail and fashion and so on. And if you decompose the process in the process industry a little bit, you realize that it's not dissimilar than the engineering process. Obviously dealing with different product structures, bill of materials, BOMs, are not the same, but a lot of the principles around managing product information, managing product data, using data to make better decisions apply to all organizations. Granted, sometimes the user interface, the user experience, the workflow is not quite there, the language is not quite there, but the principles are there. The principles being I need a way to manage information to support decision-making. So if you think about data to support decision-making, it really doesn't matter which part you're at. To add to this, Even in process industries, there's tremendous amount of discrete-like products. All the manufacturing facilities that are used to create the process, to facilitate the process, to create those batches of products, still are relevant. So companies use PLM more on the service side to maintain their assets, to maintain the line production up, etc. So it's really just a matter of time until the user experience and the user interfaces will evolve, but the principles of PLM apply just as well. And I expect to see more of those participation, this kind of participation in future events. Okay, so I'm a little bit of a contrarian in this space. I don't think the IoT, the Internet of Things, has matured enough to the point that we can define the role of PLM. Other than to say that whatever your vision for IoT is, new products will have to consider IoT somewhere in the roadmap in the future. Whether it's embedded software, which is probably closer to where we are, all the way from embedded software to new business models. Where PLM applies to IoT today, I would say, is much more in the ALM, application lifecycle management, realm, which is developing capabilities built into the product to support IoT connectivity. Beyond that, I think that the market is still— the IoT as a notion is way too nascent to really understand how PLM should take a role. So the first step is really to define the role of PLM. Not define PLM, but rather define the role of PLM. And the way I view PLM is the role of PLM is to support better decision-making in the organization. So the first order of things is to really understand what are the types of decisions we make throughout the product lifecycle, whether it's innovation, design and engineering, how we prepare for volume ramp-up, how we manufacture product, how to take it then into the market, sell it, and service it. So to me, PLM is everything end-to-end. So it's really the L in lifecycle of a product. So companies have to still to first think about this process overall and then understand what is the role of information or data in making decisions to other processes. And PLM is designed to do that. So the first way of thinking about PLM is really what is the role of PLM in making decisions. So they need to start there and from that decompose requirements for the tools, such as what are the functionalities that I need, do I need to be compliant with certain industries In this case, it does have some bearings. Is cloud delivery critical for me, etc.? As I said earlier, it's the process first, the tool second. It's much less about the functionality and much more about the process itself. I don't really think that there are major disruptors. We like the word disruption, and I think that we sometimes misuse it. I don't think the market is facing a lot of disruption. In fact, I would ask this question maybe a little bit different, which is, given the heightened attention to PLM and ALM to some extent, who might be threatened as a result of that? I think that in this context, ERP products may be threatened to some extent because ERP systems are now primarily transaction transaction systems. They are not decision-making systems, they are transaction systems. They tend to record what had happened. They prescribe what should happen and then they record it. PLM is really much more proactive, especially these days, in managing innovation, in trying to facilitate new business models such as maybe SLM, which to some extent is new and exciting, not disruptive perhaps, but those activities in PLM and SLM and maybe try to bring more into PLM like you suggested. How about IoT? Is it really part of the new brave world of PLM? All these things really, I think, threaten the ERP systems, and I think we'll see more and more ERP companies responding to this one way or another. I have a surprising answer, and the answer is it's the same old project management mistakes. They all make the same mistakes. None of them is PLM-specific. Then you often see kind of best practices in PLM implementation, and if you look at them carefully, they are basic IT implementation, know the requirements, make sure that the tool meets them, have executive support, and so on. There is no surprise there. The disappointment is primarily because people underestimate the effort. They underestimate the effort to implement, they underestimate the effort of the organization the organization needs to undertake to adopt the tools, to change systems, to change the processes. Therefore, if I can offer advice, would be not to try to— don't think about PLM implementation as a customization exercise. As I said earlier, it's the process first, the tool next, whereas many companies go the other way around. Let's take a PLM tool and try to customize it to mimic the current processes. Especially when the current processes may be flawed anyway. But the tendency is to put the onus on the vendor and say, "Make magic happen for me," whereas what you should really do is start modifying, improving the process in-house. And while you're doing it, try to see if you really have to customize the tool. I think that we have less tendency today than 5 or 10 years ago to customize software, but I think that To the extent that you can, and I think that the vast majority of cases you can, use the tool as is, minimize customization, and see what will fail, what will break, as it were, if you adopt your processes to the tools. So maybe the approach should be much more kind of harmonization between what the tool out of the box with minimum customization can do and what your organization can do. But I'm going to repeat the same thing again. It's your process first and the tool second. If you start the other way around, you'll be disappointed. So the initiative should not be, let's implement PLM, because PLM in itself has no value, not intrinsic value. The value of PLM is improving the process. So the way I would sometimes approach it is actually, so we all taught and we train to do top-down analysis. Sometimes it makes sense to do, to augment this with bottom-up. So let's look at current processes and see weaknesses in the process and failure points where PLM can help improve. A very easy example, a very prominent example, example that I use very often is engineering change orders. All organizations have to go through the process and all of them use some sort of tools. Some of them can be very formal, many of them can be just spreadsheets, and it doesn't really matter as long as the process works. But my analysis of ECOs shows that the vast majority of ECOs in large organizations are preventable. Preventable in the sense that the root causes were already known. Preventable in the sense that had we had the time, had we had access to information, had we had the knowledge, we would have not made the mistake. That led to the ECO. So that's a very easy return on investment type analysis that shows if we could prevent so many ECOs, that in itself should pay the PLM system very, very quickly. So start with identifiable weaknesses in the process, those that can be translated immediately into some sort of business benefit. Could be financial benefits, could be market presence, could be brand, If you think about ACOs, it's financial benefit, but also if you think about failures and warranty, that also impacts the brand. Work from the bottom up to create some use cases to demonstrate where PLM could improve. Then augment this with the bigger picture. The other part, which is much more top-down, is think about the future as opposed to the present. If you intend to remain a small organization forever, then maybe you don't need PLM. Maybe a simple PDM and some other best-of-breed tools would do the job. But if you need to scale up in terms of larger portfolio, broader markets, in terms of trying to reach— if you are a supplier perhaps and you need to work with larger vendors that they may require PLM, then you need to be PLM ready, as it were. And I'm seeing more and more organizations requiring their suppliers to be PLM compliant. To deliver information according to standards in formalized CAD formats, manage ECOs throughout the lifecycle. So at some point, if you're a very small company, you will not be able to play with the big guys unless you have a PLM system in place. So the biggest challenge of organizations is to make complex, what I call complex multidisciplinary decisions. I think it's worth an explanation. Any decision maker in the organization, whether you're a C-level executive or you're a machine operator at the manufacturing floor, you often have to deal with multiple types of information to make the right decision. And often the decisions need to not only meet your needs, or what I call your goals and constraints, but also they have influence on what's going to happen downstream. Since we talk about SLM, let's talk about service for a second. Service is a good example to demonstrate complex multidisciplinary decisions. If I'm a designer, I optimize my design to my functional goals and constraints. I need to meet fit, form, and function, maybe cost sometimes, but I seldom think about downstream such as supply chain, such as service. I may create a perfect product, but then I'll find out, or someone else will find out, that is very difficult to service because parts are not easily removable, because the test point or measurement point is hidden behind a bracket I cannot reach, and so on. But as a design engineer, I was not aware of those needs downstream. At the same time, if I'm told someone, "Okay, you need to incorporate more serviceability features into your product," as a design engineer, I might say, "Well, it'll be over budget." or I will exceed my— I'll be out of schedule or I'll be late to market and so on. So now we have a complex optimization problem. Which one is more worthwhile? Increase cost and be late to market but improve service, or forget about service, I need to be in the market and someone else downstream will deal with the problem. There's no right answer here. The question depends on the circumstances. If this is a new product that is critical to be at the market this time to displace the competition or to capture a new market, then maybe I should say, "Yes, I need to be in market even with slightly lower quality and I will reap the rewards later." A very well-known example that I use is the Xbox 360 that absolutely went to market not ready. The designers knew there was a design flaw. Yet it was so critical to capture the Christmas market of that year, they say, I'm going to take the risk, capture the market, and pay for it later. It was worthwhile, and indeed this gamble was the right thing to do. Conversely, I might be in a situation where I make the decision not to invest in service. I'm early to market, but my product is so sub-quality, then I will end up paying more in warranty claims, bad reputation and so on. So what does it have to do with PLM? PLM allows you to have this type of visibility. PLM allows you to do this what-if scenario up front, all in virtual world through simulation and mockups and so on. So you can say, let me see what happens if I change the modularity of the software, if I improve quality, if I change supplier in order to improve some capabilities downstream. So that to me is the fundamental role of PLM, bringing me rich multidisciplinary context to make decisions before design commitments are finalized. And that's the power of PLM. And mature organizations do it extremely well, and they make odd decisions such as the Xbox 360, and they demonstrate the value of doing that. Companies that do not do that, i.e., they make highly localized decisions and ignore downstream end up paying dearly in warranty claims and tarnished brand image and so forth. It is related to the top of the process. Again, tools have to meet the needs and the culture and behavior of people, not the other way around. So it does tie to all the topics that we discussed, you're right, as far as Is the tool supportive of the culture and the behavior? Is the tool disruptive? Is it worthwhile disruption? But in a way, you could also point at this as being somewhat critical of PLM because it's the wrong question to ask, you know, do we need to instill a new culture of PLM in the organization? If an organization really is thinking about my new PLM culture, something is fundamentally not wrong, but needs some thinking. That to me says we are not really promoting a culture of collaboration, of decision-making, in understanding the goals or constraints of downstream. When I make decisions, I understand the impact of my decision on downstream folks. I design a product, do I understand the needs of the manufacturing engineering groups? Do I understand the needs in the goals of the supplier? Do I need to understand service? Do I understand even end of life of products, which is not very common in North America but it's much stronger in Europe, end of life of products, reclaiming personal material, recycling, and so on. If I'm thinking, going back to the question about how to select and how to buy PLM and how to sell it to the organization, I think that if we pay too much attention to the question of what is my new PLM culture. I think we need to stay back and say what is my product engineering, product development culture, what is my collaboration culture, and maybe I need to start there and then worry about my PLM tool.