How to Simplify My Next PLM Implementation?

Siemens’s blog post by Nik Pakvasa and following discussion drove me to put my thoughts in the this direction- how to make next move in my PLM implementation easier? The complexity of PLM implementation is one of the fundamental problems that prevents Product Lifecycle Management industry from mainstream expansion and deployment. When a customer likes all ideas related to how keep track of data and processes about products and around, the implementation becomes a nightmare. PLM vendors did a lot on the way to simplify products and their deployment by providing packaged out-of-the-box implementations, best (or useful) practices related to data models and process implementations. However, the better solution is definitely required.

Business is very dynamic these days. Customers challenged by competition, cost, need to adapt their business processes to the new conditions of business, etc. All these put a fundamental requirement for change in business systems, and PLM is standing first, in my view, in the line of these changes. Whatever happens – outsourcing, optimizing manufacturing or design process changes, the ability to adapt PLM system to the “next PLM implementation” becomes fundamental. However, most of them are not as simple as we want.

If you are looking on additional information about this topic, I can also advise you fresh CIMData paper analyzing customer migration challenges based on their experience with three Siemens PLM customers. Note, you need to make a registration on Siemens PLM web site to get access.

My analyzes shows three most important reasons why “my next PLM implementation” is always complex.

1. Insufficient flexibility of PLM systems. For the first time, you may think I’m kidding, right? In most of the cases, the perception of PLM system is that this is a very flexible outfit. However, if you will take a closer look, many of PLM systems have no consistent flexibility that customers can rely on for many years. Next big things, new releases, improved functionality,  new technologies – all these can create a very complex situation for customers.

2. High level of customization activities. This is a very typical for industry. Each PLM implementation contains a significant amount of services that include system configuration, adding of functionality, integration with customer’s systems like ERP and others. The amount of such implementations is so significant that becomes one of the key questions when the customer want to change/move existing implementation. Amount of testing and adaptation that need to be done make this project very complicated.

3. Lack of standardization activities in PLM-related industry space. Standardization is a very expensive activity. My best take on standards is as following: Standards like toothbrushes – everybody needs’em, but nobody wants to use somebody else…  If we can imaging that level of standardization in PLM space can be improved, reliance on these standards can be great help.

I want to say few words also about “out-of-the-box” (OOTB). It presented as the universal hammer to solve the problem of PLM implementation, OOTB is a Trojan Horse in PLM industry town. In my view, OOTB provides a simple answer on how to implement PLM system fast for the first time. At the same time, OOTB is not providing any advantages in simplification of my next PLM implementation step. OOTB should come in balance with flexibility and system openness – this is the only way to get PLM to the next level of maturity in implementation.

So, what are my recommendations today?

1. Invest in PLM system openness and flexibility
2. Simplify your customization functionally and technologically.
3. Plan small steps in your PLM implementation journey.
4. Sponsor standardization activity – this is future health of the industry.

Just my thought.
Best, Oleg


Share This Post

  • Dan P

    Migrating customizations is made substantially harder if you do not have a solid, high-quality base to build on. My experience is that the vendor outsourcing of development is not helping.

  • Dan, Thanks for your comment! Could you, please clarify what do you mean by “solid foundation” and “outsourcing” in this specific case? Thanks, Oleg

  • Prashant

    Dan, could you please enlighten us what is the relation between outsourcing and customization which is totally dependant on the technology that the vendor is using? Have the vendors outsourced their decision making process too? If you are using technology that is 25 years old no matter where the development team is from, they will never be able to achieve what today’s customers want. PLM vendors need to be more innovative and invest more in research, new technologies insted of keep packaging old wine in new bottles.

  • Dan P

    Thanks Oleg, Prashant,

    You’re right, I should have been clearer. I’m approaching this as a grunt software engineer. When I said “high quality base” I was referring to the code base and, to a lesser extent, the data model. What I want from a code base is modular and maintainable code (e.g. no cut-and-paste coding), consistently formatted with sensible comments. If this is lacking a merge of customized code with upgraded code can require more effort than re-implementing the cuztomization from scratch on the upgraded code! Oleg, I feel that this has parallels to your concept of ‘flexibility’?

    Prashant, my concern with outsourcing development to third parties is that it is easy to lose control of the quality of the code base. Once that occurs you can quickly find yourself in the situation I described above.


  • Nambi C


    Nice article and I agree with many of your recommendations. The problem also is PLM vendors havent been able to converge quickly on systems and show customers the roadmap. There is still a lot of “fog on windshield” when it comes to that. SOme progressive suctomers have taken it upin themsleve sto standardise on data model and build it as a shared service for their differnet groups, therbey driving down teh cost and challenge associated with upgrades or transition.

  • Dan, I didn’t want to take it so deep to the problems of code development. My take on flexibility was mostly about the fact that data models, business rules, user interface, customization and configuration capabilities need to be on the adequate level to make a customer to deploy a system in the way they are working in the organization first. After, you must have an ability to use the same tools – modeling, customization, configuration – to change system behavior in order to improve processes in your organization. Once done, system need to be consistent backward on capabilities introduced before. Best, Oleg

  • Nambi, I see a major difference between how I see it and the way you proposed. You cannot have “the standard” data model. The effort to have a standard model is a dead end. This way is extensive and cannot scale up. You probably can agree on something common in a team of 10 engineers, but when you have 100, it will be a voluntary decision. When it comes to a big organization, it becomes a nightmare and when you are talking about a multiple organization it looks how it looks now. 30% of OOTB product and 50-70% of services. After all, the cost to move to the next implementation is huge $$$. Of course, the reasonable effort in creating of industry standards can be very beneficial, however it will not resolve problem. The right solution is to develop flexible and self adaptable systems. Think about power supplier for your laptop, that (I’m sure, like mine) works for both 110V and 220V-240V when needed….Best, Oleg

  • Just picking up on the earlier point about so-called OOTB Best Practise Templates not being a cure-all.. Couldn’t agree more..
    No two companies have the exact same process needs (nor should they ever…otherwise where would competitive advantage be derived) so templates should only ever play a limited role.. However, promoted by PLM marketing departments as ends in themselves, OOTB Best Practise Templates are disingenuous and too often mask PLM systems (usually older systems that have been around a while) that are difficult to configure..Don’t get me wrong, templates can be fine as a place to start as long as they are built on modern, flexible PLM architectures and can be easily built upon and changed..companies should test the reason the OOTB templates exists and demand some pretty complex ‘on the fly’ configuration as part of the selection..

  • Graham, Thanks for your point and articulating of what you called “a company competitive advantage to deliver”. This is an important in the context of PLM. If companies will use “standard PLM”, they probably will deliver “standard competitive advantage”. I know, what will be said in the opposite is that PLM platform assumed to deliver flexible processes. However, before, there is an issue with configuration. In my view, PLM best practices is the best invention for marketing and demo environment to show to customers what system can do… After this step, the most important is system’s flexibility. Best, Oleg

  • Magnificent ! I would like to pose a video to illustate your fantabulous article, but I don’t see how to do ? Can someone help me ?

  • Brilliant ! I would like to insert a video to illustate your article, but I don’t see how to do ? Can someone help me ?