3 main factors of mainstream PLM adoption

plm-mainstreamI had chance to discuss PLM adoption rate already several time. I think, adoption rate, is one of the factors why Product Lifecycle Management is not coming to mainstream and remains something exclusive. If I look back in the computer and CAD industry history, the revolutions happened when sophisticated technologies were moved from exclusive and more expensive environment to mainstream. Microsoft did it for PC, John Walker and his partners moved from exclusive CAD workstations to mainstream PC in 1982, SolidWorks took all experience Pro-E developed until 1995 and revolutionized it on Windows platform.

So, what I had in my mind over this weekend is to think more about how to find roots for expensive and complicated PLM implementations. What those factors that make them so complicated and maybe to put few initial thoughts about how to move them to mainstream. I thought about every PLM implementation I had chance to touch and came to a conclusion that the following three major factors or steps are always causing complexity and cost: 1/Customization; 2/Legacy data; 3/Integration with ERP and other systems.

#1 – Customization.
This is a very significant piece of every PLM implementation. I hardly believe in “typical manufacturing environment”. Yes, definitely, there is some general similarity based on industry or organization type, but fundamentally people are running manufacturing differently, have their own environment, semantics of data, customized name schemas etc. So, cost to customize PLM system to get it to the right level is quite significant. To have right customization tools and integrated programming environment is key to success here. Everything is possible in software – we know that. However, what will be cost of these “possibilities”?

#2 – Legacy Data
In order to run your manufacturing environment, you need to have “your data” in the system. Without this, you are not actually running your manufacturing with PLM. To get legacy data in the system is a very painful task, in my view. I have almost never seen this happened easy. This is almost every time set of complicated steps of exporting and importing data. Since, there is no standard data, we back partially to factor #1 (customization) again.

#2 – Integration with ERP
This is last, but not least. The first chain in product development PLM needs to support is integration with ERP. If you don’t have integration with ERP implemented, you have closed environment that almost cannot optimize your manufacturing. Most of the product cost driving factors these days are on the intersection of product requirements, design and manufacturing and supply chain capabilities. To make integration with ERP is #1 task for PLM.

So, what is my short conclusion? These three factors can move every PLM implementation to nightmare. In today’s modern PLM systems, I had chance to follow few possible solutions to resolve these issues. Most PLM providers these days are focusing on industries, verticals and best practices. Not bad step in my view. As much closer you will come to final environment, less time you will spend to customize final environment. From integration and customization standpoint, moving to Microsoft development environment, Visual Basic and script based customization can be very efficient to decrease cost of implementation.
Even if I don’t think, these solutions are completely successful, but they definitely can bring some pain relief. However, I do believe, the right solutions are probably still in the future.

I’m looking forward to your comment and thoughts. I’d be glad to learn about your experience.
Best, Oleg.

Share

Share This Post

  • Joy Garon

    Hi Oleg –

    Clearly the 3 items you listed are correct. But, let’s not forget people. Committed, dedicated resources that are empowered to drive improvements to process and evangelize within the company are critical to success. I have seen very small companies implement creative global PLM solutions with limited budgets and resources. (Although they didn’t label it PLM)

    Regards,
    Joy

  • Joy, You are absolutely right! People are very important… with regards to “labels” – this is more related to “evangelism” :).. and how you want to call it. So far, nobody invented something better in comparison to PLM. The best I heard and had chance to see is “PLM vs. non-PLM” on COFES (you can see it here – http://plmtwine.com/2009/04/17/cofes-2009-plm-vs-not-plm/). So far, TLAs is really less matter. Whatever you will do PLM or PDM in my view these three factors will follow you. Thanks for your comment! Best, Oleg.

  • Bruce Martin

    It has become increasingly obvious to me that one issue that drives slow adoption of PLM is largely due to an initial focus on the “technology” pieces (COTS). The major PLM vendors drive this, as they are in the business of generating revenue through software sales and support. From the customers point of view, the initial focus should be on optimizing your interal processes to eliminate non-value added activities. Understanding and documenting your process in fairly straight-forward. Once you have this information, you can better understand and prioritize the technical pieces that need to be implemented to support the desired process. Start small, with a simple and well understood process. Get some quick wins, gain support, and then begin to tackle the bigger issues or ERP integration and SCM.

  • Bruce, I agree with you. Current approach is driven by PLM vendors, and they are obviously coming from position of licenses/services. In one of my early posts on plmtwine, I brought an idea to think about a process capturing and may be optimization before you actually come to PLM implementation (http://plmtwine.com/2008/12/06/how-to-improve-plm-processes-before-plm-system-using-bpmn/). However, PLM vendor’s recommendation is to take phased approach. Problem with phased approach is that you need to have adequate support in products to be able easy to change environment, go in steps, easy customize, take legacy data inside etc. This is something that not working well, in my view. Thank you for your comments! Best, Oleg.

  • Oleg,

    I agree with your points, and the order of their priority. I think the customization/tailoring of PLM software to fit a business’ existing processes is the number one reason why deployments take a long time and are hard to maintain. The other two reasons certainly contribute, but wanting a “custom” system is #1 in my book.

    I am torn on that point, though. It would be nice if PLM were more commoditized, but I cannot argue with companies that claim that they need a highly customized PLM system. These companies believe that their competitive edge exists in their product development processes. Some companies are kidding themselves (and they could adopt PLM more standardly), but I have run into other customers that do have a unique product development process that is worth keeping (and automating). So although having a “custom” system is a significant barrier to PLM adoption, in some cases, it is the right solution.

    I believe that #3 (ERP Integration) is closely related to #1. People with custom PLM probably already have custom ERP, which means your integration must also be custom (and probably complex).

    I think we can make gains in #2, but this is certainly a challenge. This is a hidden issue today because no one wants to admit that sloppiness with data over the last 10-15 years has created the monster that it has. I meet very few engineering managers that believe the company’s CAD data is a mess (until shown direct proof of the problems). Associative (CAD) data is amazingly powerful, but deceptively painful unless managed properly (from the start).

  • Jonathan, Thank you for your very interesting analyzes. I definitely can understand your preference to have very customization-oriented approach. I think many today’s PLM customers (especially successful ones) will agree with this approach. However, in my view, customization will not lead us to mainstream. Customization is something very time and resource consuming. Remember, few years ago, we thought that the only way to attach a device to PC is to play with right IRQ. So, you had technicians that came to people to help with this work… What happens now? PnP devices and blog/social tools that can help people to do their tasks… Of course, this is extreme example and implement PLM is not like to connect a camera to laptop. But, think in perspective, maybe you will find it interesting… Regards, Oleg.

  • Oleg,

    I am actually neutral on the idea of customizing PLM. I understand when clients want to go down this path, and we (Razorleaf) have a business model that supports this. However, I believe too many clients go down the customization path unnecessarily.

    I agree that we need more mainstream PLM that people will use “out-of-the-box”. I think my company could have an equally viable model in such a future (where customization of PLM is minimal), because adopters still need to learn how to make the best use of PLM.

  • Jonathan, you don’t need to defense Razorleaf business models :). I think services, implementation and consulting are not going against PLM mainstream. I think, actually it’s not equal, as you mentioned. An adoption level will create a bigger market and opportunities for everybody, including Razorleaf, of course. Best, Oleg.

  • Oleg,

    Agreed. 🙂 I do feel a need to be somewhat defensive though. Not because of your comments, but because consultants have an unfortunate reputation in this regard.

    I would be happy to spend more time “training” and less time “tweaking” – I believe training is more valuable to people.

  • Oleg,
    When I read your post, it reminded me of a post I made a year ago that PLM is hard work (when will we learn?). But I think that the hard work is only partly technical, and that the real hard work is business process and people oriented. As I was off busy capturing my thoughts in my blog http://tech-clarity.com/clarityonplm/2009/implementing-plm-hard/, it looks like some of the other comments have come in along those same lines as well.

    While I agree with you that there are technical issues to overcome (we can debate relative priority of integration as we have done in the past), I think that both sides of the story have to be told. Implementing PLM is an enterprise transformation, and getting people to change the way they do work (across the enterprise, with customers, and into the supply chain) takes a tremendous amount of effort. All worth it, by they way, but a very large effort. If I were examing how to make PLM implementations easier, I would love to see the technical issues made easier. But I believe that the majority of the hard work remains in defining and implementing new processes.

    My 2 cents to complement your perspective,
    Jim

  • Jim,
    I agree with you as well as agreed with previous readers, people are part of any enterprise software implementation and PLM implementations are facing it significantly. But, at the same time, I’m asking may be very stupid question- why want to make enterprise transformation when coming to implement PLM? Is it so important? What about phased approach? Maybe just start from capturing what we have? Transformation is a change and change is a not easy task… What do you think about it?
    On the topic – implementing PLM Is hard. I’m looking on the slide in your bog post. The difference between PDM and PLM I see is processes system cover – engineering for PDM and more cross-discipline in PLM. So, maybe ability to cover wider scope of processes and data is key for PLM adoption?
    Regards, Oleg

  • Jonathan, I don’t believe you :)… implementors are always willing to tweak, not because it’s bad, but because it’s cool. PLM mainstream adoption, however, will bring broader customer landscape to do so. Regards, Oleg

  • Oleg,
    Why transform your business? Because there is only so much a tool can do on its own. I have seen too much technology implemented for its own sake, and implementations that get hijacked with trying to get the software implemented (and lose total sight of why they started the project in the first place, to improve the business). When I was doing implementations, I would have people ask “how should we use this module?” instead of “how can I improve the quality of our products?” or some other question with direct benefit. Software is the way to implement, support, and reinforce new processes.

    Having said that – I do think there is a big difference between implementing software tools than enterprise applications. Software tools can help an individual do their job better, and if they do that in a vacuum then there is still benefit. For example, you could implement 3D CAD to improve the efficiency of an engineer. Enterprise applications, though, rely on cross-functional groups playing their roles to make an overall process better.

    If by “just capturing what we have” you mean implement processes that already exist, I would agree if the processes are good ones. In rare situations I see people that have good processes supported by bad or disjointed technology. In those cases, maybe a technology swap is in order? The most successful projects I have seen are those where companies implement new processes and technology simultaneously in a synchronized way.

    But in most cases, if you aren’t going to change – you can save a lot of money by skipping the software implementation in the first place! 🙂

  • Jim, I agree, process improvement is important. However, the question is how to make it gradually and not revolutionary. I don’t know if this is possible. My view, is that by trying to combine all together we create big show-stopper on the way PLM is getting to organization. How we can make it easy and by phases? I doubt we are doing it successful today… what is your view on this? Should we continue to push best practices, process transformation or take different approach? Best, Oleg.

  • Oleg,
    I absolutely believe in incremental, and if change can be made gradually and still make a business impact that is great. But to be honest, I think that if all most manufacturers got after their PLM implementation was better support for their existing processes they would be missing a huge opportunity. Yes, PLM implemenations are disruptive. The technical disruption can (hopefully) be reduced. But a very large part of the value from an enterprise systems implemenation is the disruption. The key is to disrupt it in the right way, and put it back together so it is much better than it was before.

    Disruption = Discontinuity = Opportunity

  • Philip Page

    Implementing any enterprise application requires 1) cusomtizing the software to the companies needs and 2) changing the companies business to adopt to the software. The difficult part is for the project leader to judiciously determine which should change, then securing concurence among the stakeholders.

    Many people believe their process is a competitive advantage to the firm, and therefore do not budge on their requirements. Sometimes they are right, other times wrong.

  • Jim, I think, people have a problem to manage change. In the same way, companies might be having a problem to manage disruptive opportunity. Don’t you think so? How it co-exists with believe in incremental? What do you think about “continues improvement” in this context? Change is the most painful part of today’s enterprises. There are no way enterprises can manage change today. The last believe was SOA… what is coming now? Cloud? What else can help? Regards, Oleg.

  • Philip, Agree with you. The right balance of change/customizaiton is key when you approach enterprise implementation. So, I’d add Jim’s incremental approach to this balance to make it repeatedly in phases. Thank you for your comments! Best, Oleg

  • Oleg,
    I think PLM is too big to eat in one meal. If you look at it as enabling product innovation, product development, and engineering there is just way too much to do at once. So incremental is the only realistic choice. On the other hand, you have to start with a strategy or you will end up having to rip out the foundation you have just put in place partway through the process. Are there other opportunities that can provide value without as much disruption? I think there are a lot of standalone / single user solutions that can provide value without disruption. But PLM is more disruptive, higher value.
    Jim

  • Jim, it will be interesting to compare multiple PLM product implementations and see what type of incremental/disruptive combinations companies used to build solution in steps. Do you have an examples from your practice you can share? Best, Oleg.

  • What a lively exchange this is! Sometimes I wonder if the acronym PLM itself has become a deterrence in PLM adoption. Over the years, it has acquired certain connotations — big IT overhead, significant upfront investment, loss of productivity, not suitable for small businesses, and so on. Some are true; others are not. Consequently, people tend to have knee-jerk reaction when they hear that PLM is coming their way. Managing change order, for example, is part of PLM, but people seem much more open to adopting a solution for that than they are to PLM. The common belief is, a change-order management system gets rid of engineers headaches, whereas a PLM system gives engineers headaches.

  • Kenneth, you are right. People associate PLM with many negative things pursuant to different historical issues. In many cases, customers prefer to use more practical definitions, since they are aware about PLM negative notion. I have to say that nobody proposed something better yet, so unfortunately we stick with this TLA… And people try to explain it differently…. http://plmtwine.com/2009/07/28/plm-prompt-plm-non-plm-pdm-where-is-difference/
    Thanks for your comments! Best, Oleg.

  • Pingback: Why PLM Scares Me? « Daily PLM Think Tank Blog()

  • Pingback: PLM and Legacy Data()

  • Pingback: PLM and Legacy Data « Daily PLM Think Tank Blog()

  • Pingback: PLM and Social Connections()

  • Pingback: PLM and Social Connections « Daily PLM Think Tank Blog()

  • Pingback: Manufacturing Mold()

  • Pingback: “PLM journey” and thoughts about technology | Daily PLM Think Tank Blog()

  • Pingback: Mitigating the Legacy Data Risk to PLM Deployments - I-Cubed - I-Cubed()