3 main factors of mainstream PLM adoption

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

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.

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).

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.

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.

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

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! 🙂

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

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.

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

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.