Large Monolithic PLM Implementations Are a Thing of the Past

Continue my last week post about how to make next PLM implementation simpler, I decided to put some ideas towards how the next PLM implementations will look like.

PLM vendors are making huge efforts to simplify PLM deployment and make implementation simpler. Despite that, in my view, typical PLM implementation is still combined from three typical steps: a significant planning effort, deployment of software and additional customization and adaptation services. These steps make implementation expensive. Talking with PLM specialists and consultants you will learn the most important PLM activities are related to good planning upfront, methodologies and clarification of what organization need and how to math organizational needs to capabilities of the system. Gaps are covered by services.  It looks like a deadly connected circle. How we can break it?

I think many of PLM vendors and implementers made a misinterpretation of out-of-the box terms. What is currently proposed in PLM “out-of-the-box” package is an effort to create “standard PLM”. What you can hear around is additional activities how possible to create typical industry implementations, OEM/supplier oriented typical implementation, etc.

In my view, this is a dead-end in PLM evolution. Such efforts will be endless similar to multiple standard activities in product development. The main reason for that is because manufacturing these days need to be more agile, lean and dynamic to sustain in their business and making profit. When such fundamental for their product development system like PLM becomes “typical”, you cannot expect them to be dynamic, lean and efficient at the same time.

What is a possible solution? I think software vendors need to learn again lessons from 15-20 years back. In beginning of 90th, few companies were doing PDM. Such projects were considered as luxury, needed by big organizations only. PDM budgets started at six digits numbers and requires major involvement of software vendor, custom software builds and long project implementation time line. However, in the middle and end of 90th we had chance to see a strong trend towards flexible data models, inexpensive Windows based systems and as a result lower entry barrier for PDM implementation.

My conclusion today. Vendors need to leave magic-out-of-the-box marketing efforts and depart to the new station where we’ll able to find new engineering solution for old problem. Future systems will be adaptive, will not require a significant effort to deploy and implement.

Just my thoughts. YMMV…
Best, Oleg

Share

Share This Post

  • Anonymous

    I have a bit of experience trying to simplify PLM implementations myself… I think there is one factor that you’re missing here that in my opinion is the reasons that this is a VERY hard problem to solve. Well… really it’s two things. (1) companies data is SH*T. Its always a mess, often coming from multiple history companies and (2) companies never really want to change their processes. It’s too hard to wrangle all the key consumers of engineering data into a single mindset that is so critical in the adoption of OOTB software solutions.

    On the first topic… Well that’s easy. Is the return on investment of cleaning up the 200,000 duplicate part numbers worth it (hint: yes! it is!). The challenge is getting people to bite off that two year project to clean them up.

    The second makes me ask: Why are engineering departments and their surrounding organizations so damn stubborn when it comes to their data? for example – why don’t they want to change their part numbering systems? Why don’t they want to change the way their title blocks are attributed? Why don’t they want to change the way the shop floor gets a drawing?

    These are just a couple of examples. Companies are like organisms and the catalyst to get an organism like these to change is not PLM and it certainly doesn’t come from some top down decision. We like to think it does but in reality the people that have to execute on these decisions often fight the “man” and bypass the system (break out that old XLS file they’ve been using…)

    It’s frustrating…

    It’s almost impossible…

    So… my solution – at least today. Don’t do PLM. PLM in so many cases gets no further than a Vaulting implementation and MAYBE a little BOM. ERP integrations? Bi-directional data exchange? sure – if you have $100k min to implement it… (again back to that initial “really?!?” look you see in their face).

    Keep things simple. Departmental and point solutions that realize quick, incremental value are easier for humans to digest. Leave the PLM to ERP. One huge investment is big enough.

    I don’t want to poo-poo the possibilities of the future. But then again I fear that there is no technology in the world that can make people change their opinions… that has to come from somewhere else.

    I hope I’m proven wrong.

  • Hello, Anonymous, On the contrary I can say that even organisms have their self-cleaning processes. So, even what you said happens in the organizations today, some of them will die and some of them will have been clean themselves in order to become lean and agile. I think, ERP will come on target soon too, since CIO will be looking for next budget saving or not clear ROI. Looking on what is going with Enterprise 2.0, my prediction that more efficient systems will come soon to clean up field you described. I believe lots of organizations understand it and they are looking for more agile solutions these days… Don’t you think so? Best, Oleg

  • Bhushan

    Hi Oleg,
    Thanks for the wonderful post…
    My Views>>
    1. For few more years; we have to live with the same pain of the implementation.
    As per Organizational Behavior “Resistance to change is always there” & you are no apart from it..
    2. PLM Vendors coming with an industry specific standards & no customization mode >> easy to Deploy…I don’t believe in such things…. why? You can standardize schema/product structure but you can’t standardize processes of companies even in same domain..as Every organizational process is evolved ..through years together & it has been working for them.
    You can not ask a organization to change their process to suite PLM… The best interest is to map Industry process in PLM & again that needs Customization.
    Regards,
    Bhushan

  • Bhushan, Thanks for your comment! What, from your standpoint, can decrease amount of customization in PLM? Best, Oleg

  • Julien Boulay

    Intended of the PLM will consist probably of a thin division of the architecture.
    The problem reside at present in the monolithic approach developed by the PLM providers.

    Why not to supply a system divided into customizable and technical bricks. These components might answer to very simple business needs (by schema and product structure standardization for example)?
    Historically, systems as CoCreate and Windchill represented formidable tools boxes.

    The trend today is not really in this “component” approach. The PLM providers simply make efforts on the “parameterization” aspect of their solution.

    Maybe, more standardization (on a customization point of view) would make the PLM implementation task easier. Java JSR and the OMG Standardization group could show the way on a “Component” approach.

    Furthermore, as you have already underlined it in various comments, there are numerous additional systems in the PLM scope today (such as BPM, ETL, and social applications)
    The integration of such software bricks can certainly complete the tool box of PLM. BPM might then allow to implement processes of the organization, base on the PLM services (basics of SOA). ETL might allow to clean data and integrates with others systems…

    MDx (Model Driven Architecture/Engineering/Development/…) could also decrease the amount of customization !
    Regards,

    Julien

  • Hi

    May be it is a marketing issue.

    You are right, 20 years ago, very few companies where using PDM. It was A&D companies, Automotive manufacturers. Then PDM vendors searched for other potential customers, and try to sell the same software to other companies. And we are still there. Medium size companies are asked to implement the same software as large ones, which is simply a dream without customizing a lot the solution.

    But marketers told the customers: You can use it OOTB! They should have said: we have decreased the implementation time, you still need to match your process to the existing ones.

    So the question is: what is the right platform for middle size companies/business units? Is it existing today? I don’t think so, except in some domains like apparel, where new solutions appear these days. But never worked with…

  • Julien, Thanks for your comment! In my view, there are two separate approaches – (1) Toolboxes and (2) Flexible Systems. The difference is not always clear and therefore, I will try to explain my point. When you have a toolbox, you basically provide some additional tool beyond general technological stack (Like you mentioned JAVA or similar). Such “technological stack” dictates what you will use to develop, but in order to have a system up-and-running you need programmers to do their job. In the opposite, flexible system is a system that implements co-existence of two arts – ability to setup system without involvement of the programmers and ability to change a lot of pieces (like data model, system look and feel, business logic, etc.) without losing basic functionality. The last point is important, since many systems actually failed on that – you can change them, but many of the standard pieces become not useful anymore. Hope it is clearer now… Does it make sense? Best, Oleg

  • Francois, I think you asked a great question! What is the right platform? I think the answer is coming from emerging process related to changes of everything in enterprise. Take a look on Enterprise 2.0. Take another look on growing capabilities of platforms like SharePoint. Many of the things that presented there before belonged to “special data management” features. Open source is another interesting option…. On the marketing side – I think organizations will be ready to fight traditional marketing tough on their regular job. The smart marketing guys are moving to social options- they felt the future is coming from there… Best, Oleg

  • Oleg

    I think the platform has to be build. Existing PLM technologies have to fit, as you said, emerging processes into companies, for product development phases (product series is a different story)? Meaning very fuzy, lightweight and always changing processes.

    I think an application implementing a mixed of wiki, PLM gadgets like tree management, instant collaboration, simple data release, and a much higher level of ergonomy like ajax may be something that companies may adopt more easily, having not to analyse and adapt their processes to fit the application framework. Simply because companies do not have time and money for that anymore. That’s the reason why they try to adopt the OOTB strategy today, while they fail reaching their public at the end.

  • Francois, I think the believe to implement OOTB is very high and marketing is doing a really good job. Nevertheless, I see it as the dead end. This is a try to create “standard PLM”. How do you see it successful? Best, Oleg.

  • AndyF

    I came to the conclusion a while back that monolithic PLM solutions are useless for most applications. The PLM sales people are still trying to sell them but if you get out and talk to customers you’ll find a lot of disappointed people. PLM customers have spent millions and really don’t have much to show for it.

    We moved to building our own PLM solutions using the Aras Innovator framework and have no intention of every paying for PLM software again. I talk to PLM customers on a regular basis and they can’t believe how quickly we solve issues using Innovator. They usually can’t get their PLM vendor to even fix bugs much less actually solve a problem for them. And they are paying millions per year for this pleasure!

  • Andy, Open Source model is promising, but at the same time requires some skills in the organization to work on that. What do you see as a key of your success with Innovator? Thanks! Oleg

  • AndyF

    Oleg,

    The key for us is to have a few key people who know how to translate business requirements into an Innovator model.

    It doesn’t require a huge staff, we do all of this with just a couple of people but you do need the right people with the right skills.

  • Andy, Thank you for your comment! Let me ask you provocative question. I had chance to see the similar situation (translate a business requirements in flexible PDM/PLM model) with other tools (not Aras). And it works… It is always based on skills and good project organization. Is there something specific in Aras Innovator that helps or this is just a notion of “free tool”? Best, Oleg

  • AndyF

    While there are lots of application building software that can be used to solve various PLM problems, Innovator is the best one we’ve ever seen. The trick with Innovator is that it has so much pre-built functionality. The pre-built functions can be quickly assembled to solve most any data management problem. The fact that the software is free is a very nice bonus but the functionality is what is important.

    Of course, a person needs to be careful with so much flexibility. If you aren’t careful you can build something that works just as bad as a monolithic PLM system from a major vendor. Of course since the Innovator package is free you’ll only have wasted your time and not several million dollars.

  • Andy, Thanks! I agree with you about flexibility. Over-flexibility as well as complete out-of-the-box vertical solution is both dangerous for the company as a source of wasted time and resources. In my view, open source (or free) solution like Innovator can solve the problem of high risk. You emphasized it by saying “you don’t waste several million dollars”. By saying – no license fees, organization is getting lower entry barrier. It will be very interesting to see the evolution of this business model and impact of software development in the enterprises… Best, Oleg

  • Cam Bickel

    I would take a bit of exception to some of the statements above. We implemented Agile in one week – initially using only as a PDM system. This was 10 years ago and before much of the function was added through version upgrades. Yet we still started with using a fraction of the capabilities available at the time. It was certainly easier to evolve with the package than to be exposed to an overwhelming set of decisions – but I think with the right guidance you could start off small and use the pre-configured settings to begin. With a few exceptions we have not had problems changing our mind on the configuration over time – the flexibility of the package has allowed us to expand it’s use and change our processes without a lot of pain. Eventually we got into some customization to optimize some processes but there is a lot you can do with just configuration before you get to this point.

    I agree about data being a disaster in companies with a lot of history, especially acquired IP. I think the best approach is to avoid massive clean up before you implement. Decide which data attributes are fundamental and focus only on these. You can then get value from PLM earlier and use the categorization capabilities of PLM to manage further clean up activities. You may find a lot of the dirty data is no longer active and can be left alone.

    Conclusion is to find a configurable package and start using it to get your BOMs and Drawings and change process under control and then expand from there.

    Also, we did not have any problem with moving from our paper change form to the out of the box electronic version – we just did it.

  • Cam, thank you for your comment and sharing of experience with Agile. If I understand correctly, you increased functionality of implementation within the time. I’ve seen it in many successful implementations with different products. Normally, it shows rational approach and good balancing between goals and system capabilities. The key for me in such implementation always was “cost of change”. If you can keep the cost of change “low”, you will be successful with software/system you are going to implement. Best, Oleg

  • Pingback: Mid-market PLM: Smashed Or Transformed? « Daily PLM Think Tank Blog()

  • Raj

    So, Oleg, why does this not apply to ERP systems? ERP implementations are monlithic…

  • Raj, Thanks for your comment! I think, ERP apps won’t be monolithic too. However, the basis of ERP is much stronger (from $$$). So, for big company the lifespan of ERP apps can be 10-15 years. Therefore, wait 4-5 more years and you’ll hear lots of companies splitting there ERP implementations on services. Smaller customers will be the first segment to experience this change. Just my thoughts…Oleg

  • Pingback: Social Intranet and PLM Apps()

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

Subscription Options:

Subscribe via RSS

Popular Posts

Recent Posts

Archives

Blogroll