The Sink Hole of PLM Implementations?

unplanned-cost-roiThinking more about PLM implementation during last few days, I’d like to come and discuss few aspects of PLM implementation cost. Everything looks nice in the beginning of the PLM journey. Single point of truth, collaborative environment, business processes, support of the multiple integrated design environment. The sharp pencil of PLM strategy shows impressive ROI from PLM implementation. The question I want to come with is to analyze what is the potential source of unplanned PLM cost.

I see three core sources of unplanned PLM costs. Let’s talk about them in details.

1. Integration Cost in a diverse enterprise environment. It’s almost impossible to bring PLM solution in empty space. Normally, PLM comes to the organization already having some design and manufacturing environment.In some cases PLM strategy created for companies and organization having acquisition history and previous CAD/PDM/PLM/ERP implementations. PLM is naturally positioned as a mediator in business processes between existing design, manufacturing, supply chain, marketing and sales environments. Because of that integration of PLM into this environment is absolutely a requirement, but at the same time very underestimated by vendors and service providers. Addition unplanned cost came as a result of longer integration processes or unplanned works that need to be done to acquire data or integration functions.

2. Support of new PLM environments and versions. PLM implementation is spanning on a significant time frame. When working with multiple CAD/PDM/PLM software, coming from different vendors the new version can come with overlap to the PLM implementation or very soon after implementation release. To support new and updated software can be a second important source of waste and unplanned maintenance cost of PLM.

3. Implementation Change Cost. Business becomes very dynamic these days. “Build to change”- this is how modern business systems need to be created, in my view. Unfortunately, I don’t see many of today’s PLM software packages answer these needs. Adjustments and changes in PLM implementation are a third big danger for additional PLM implementation cost.So, far these are my top 3 sources of unplanned PLM cost? How do you see it? Have you had chance to experience something similar in your PLM projects?

Best, Oleg

Share

Share This Post

  • Lets go point by point
    1. First of as pointed out, in most of the organizations, PLM Implementation comes as a requirement for integration of all functions as its a must do thing because of OEMs or simillar. But I will say that everyone at everylevel should understand that it is a reality to adopt PLM to have better control over business management. So PLM Implemtation cost and strategies should be well planned and well in advance.
    2. Coming to Integrations. yes, it is necessary. But again for any organization integration are must and limited to number of functions in an organization. If an organization needs more integration, then it may be result of unplanned software investment in past. PLM is a tool like any other software tool as far as IT dept is considered. Educating an organization on its needs and then go for tools which should be easy for integration with other tools. This is should be one of the objectives of IT dept in an organization. In most of the organization. IT either plays a dept which has max budgets to make everything at a single click and promises single click automation or either just enablers. Both roles are harmful and lead to additional cost or waste of money.
    3. Point 2 in your post is a very valid and serious. Infact its a major concern. I think we should have some mechanism to control launch of innovations in PLM. Otherwise in every quarter an organization needs to scrap its earlier implementation.
    4. Implementation change cost point is valid. But is the business is really so dynamic. I will say, businessmen are dynamic and mover things. A well thought and flexible tool can adress this as well. Its a reality that PLM tool being complex at the moment is a concern but can answer in future.

    In my opinion, a controlled release of PLM versions and a PLM Software portfolio ranging from OEMs to Small scale should solve this issue.

    E.g. For a player like DS or Siemens, launching a product which has cost and feature controlled package for every size will solve most of the issues.

  • Jovan

    Hi Oleg, LTNS 🙂

    I have one point to add to your 3d bullet.

    Have business process clearly defined help you to reduce the cost of implementation. If not done, you losing time to make decision about the flow of data as nobody will ever agree with the others if he comes from a department. If the process are laid down before the PLM implementation, it’s easier to figure out how to implement it.

    One of the implementation I was working on, the customer did not expect the PLM to be responsible of a full change of product structure and a lot more time that previously planned has been spent to define the new structure. And as you know it’s not something easy!

  • Implementation and integration costs are almost always going to go over budget from what the service provider quoted. It’s not that the service provider didn’t understand the scope of the implementation/integration challenges. It’s because the pressure to close the deal forces the service provider to lower the numbers on the proposal knowing full well it’s going to cost more – much more, depending in large part on the PLM platform selected, the size of the company, the number of legacy applications and databases to be integrated and the level of experience/sophistication that the client company has on it’s own staff to support and guide the process. Rule of thumb to follow – whatever the service provide quotes on implementation and integration – double it for starters and double the implementation schedule as well. If you don’t have a sophisticated IT staff in your company – triple it.

  • Alec Gil

    Oleg, excellent points all. The integration projects must be anticipated and planned for. If they come up as a surprise, it is a sure prescription for substantial cost overruns at best, or complete implementation failures at worst.

    The second issue is critical. PLM in general has its roots in CAD where once a year, perhaps more, major software releases were expected. If PLM is expected to become a business system on par with others (ERP, for example), suppliers must be able to commit to multi-year support of software versions. Companies with large-scale PLM implementations simply cannot absorb or afford major upgrade projects more often than once in three-four years and even that may be perceived as too often by some. Add to this a mix of technologies with different release dates, various versions of OS and databases and pretty soon this soup becomes unmanageable. PLM industry as a whole must do a much better job in helping users navigate through these murky waters.

    Finally, your third point harkens to one of the fundamental canons of Continuous Improvement and that is to never implement anything inflexible in your processes. Again, I believe it is a responsibility of technology suppliers to provide systems with the greatest amount of flexibility as the business environments and the related processes these technologies support will continuously undergo transformation.

  • Ashish, How “controlled” version will solve problem of integration and change management? Regards, Oleg.

  • Jovan, You are right, clearly planning feature and implementation can make waste more predictable. But still, change is something that nobody can manage well in my view. Regards,Oleg.

  • Scott, You are right – Integration business is complex and because of competition, SIs are trying to take a risk and reduce estimations. The biggest problem that customers are affected and pay by implementation delayes and in-direct costs. Regards, Oleg

  • Alec, I liked your comment about continues improvement and flexibility. This is a big deal in my view. However, current trend toward ready to use packages is contradicting. Issue#2 related to change also have impact on ability to support continues improvement. Regards, Oleg.

  • Ashish Kulkarni

    Here I am thinking about controlled release of PLM Software and not change management.
    Most of the time, new versions are result of bug fixes. There should be an authority which should approve PLM Software release. This is highly conceptual but may be a good idea.

  • Ashish, When you release a new package, you need to make a change in existing implementation. How you can simplify this process with controlled release? Regards, Oleg

  • Ashish Kulkarni

    Hmmm. It is really complex. I do understand it. Let us have a case. I release a PLM Tool say PLMT1 and then release 1.1…..1.5 in a year. Is it not possible to release 1.1 or PLMT2 with all releases packaged together? I do understand that this is not so simple. But its like for every bug fix or minor/major feature improvement, end customer is getting affected. Is it not possible to make a rule that there should be only 1 major release during so and so period. Releasing many updates affect end customer directly and hence PLM Implementation becomes an unwanted project in any organization. This is not only applicable to PLM but to other fields as well.
    Consider sa,e car getting launched every quarter with minor updates and at minor cost. We are know that there are VAVE and Engineering changes going on for any vehicle. But its wise to give customer an option so that he does not get frustrated on his own decisions. I hope i tried to make my point clear.

  • Ashish, you car example is very good. Car manufacturer can release maintenance and replacement procedures. I had chance to see how software in my Honday Odyssey was upgraded during last maintenance. As soon as customer wasn’t affected it’s ok. The same could be potential way for PLM to move between releases…. Best, Oleg.

  • Pingback: The Sink Hole of PLM Implementations? ERP1()

  • Hardware costs required to support PLM systems is overlooked often. As PLM systems evolve, you need a number of servers (file server/SAN, database server, application server, proxy servers, multiple front end servers to support parallel processing, data replication servers for remote sites) and a number of supporting technologies like load balancing, WAN accelerators etc.

    the costs could quickly add up and could impact go-live/implementation of these systems where a compromise due to cost could impact performance 6-12 months after go-live.

    Resource costs are also another element. Typically CAD/PDM systems are maintained by a single person or a small group within engineering, as these companies embark on PLM implementation, they over look resource planning and quickly run into situations where they need either additional headcount or consulting/contract $$$$…in most cases PLM consultants are not cheap!

    License requirements are not very clear in most cases, when you start you typically start small and then quickly realize you may need more licenses to support a number of requests for work flow/automation to support increasing user base.

  • Swati, I think your explanations is excellent enhancement of what I called “cost of change”. You are right… hardware, licenses etc. – in many cases, companies have a tendency underestimate needs. But PLM vendors need to more clear in their explanations as well. This is not very specific to PLM, but in general for enterprise software (ERP, ECM etc.). Licensing and packaging are often very complex. Regards, Oleg

  • I thought you were referring to the cost of adapting the new system to match business processes used within most companies…in some cases, too much customization places additional burdens on upgrading PLM systems as the underlying schema (database, application) go through changes and deprecation.

    Excellent post overall 🙂

  • Swati, In my view “ability of system to change” is something can be applied to both – adapting for customer requirements and IT environment change. You are right, this not always the same. Each enterprise system, in my view, should be able to calculate “change index”- cost to make change in this system. This is will be very helpful when you make decision with regards to particular system. For example, OOTB system can have very fast ROI, but become very expensive for change in the future if has not enough API and other flexible mechanisms… Regards, Oleg.

  • Ed Doctor

    The “sink hole” is established when unrealistic expectations are set. Both PLM vendors and the companies they serve are guilty of setting this in motion in the name of trust and fiscal responsibility. In my opinion, this occurs within every multi-phase PLM implementation where granular expectations and deliverables are defined and agreed upon. As PLM is implemented knowledge of the system, and the capabilities it offers, expands throughout the company. This is an organic process which can be factored into the initial implementation plan but cannot be accurately determined until one phase is completed, assessed, and adjusted and the next phase begins. Staying the course from Phase 1 to Phase 2 and beyond generally results in lost opportunity to realize significant ROI. A company operates in a dynamic environment. Failure to do so will result in failure of the company in the open market. A PLM implementation must be as dynamic as the company it serves. This may result in greater expenditure of resources and capital but will be offset by significant competitive advantages resulting in greater profitability. The “sink hole” is never wavering from the initial PLM implementation plan and Standing up a PLM solution that has minimal value to the company as a whole.

    Regards,

    Ed

  • Ed, What I learned from your comment is that you probably would expect some additional flexibility for PLM implementation going between phases. I’d say, phased implementation is something that can bring PLM step-by-step to organization. However, as you mentioned, such implementation if this is not planned well can result in significant disconnection in processes inside of organization when going to the next step. I hope i get your comment in the right way… Best, Oleg

Subscription Options:

Subscribe via RSS

Popular Posts

Recent Posts

Archives

Blogroll