3 bad PLM implementation habits to kill in 2017

3 bad PLM implementation habits to kill in 2017

plm-implementation-traffic

PLM implementations are slow. Cloud PLM reduced the level of complexity, but still there are things that cloud PLM cannot do for you. These things are directly related to the way PLM implementations are managed by IT and service companies. And these problems are not technology or product related. It is actually people related. I have my collection of “bad PLM implementation habits”.  Today, I want to come with my top 3 bad PLM implementation habits I recommend to change in 2017.

1- Insisting on 100% completeness of PLM use cases

Computers are good in main cases. People are good in exceptions. By trying to nail down PLM project to cover all use cases, we risk to over-complicate the solution. And it takes time and money and people resources. So, the new approach should be to program PLM implementation around main use cases. You can ask me what about the rest? My recommendation – kick out the rest as exceptions for manual processing. It might be incomplete, but it will make your PLM implementation simpler and healthier for the future. Some of these “what if” scenarios might not happen.

2- PLM “projects”

Traditionally organization make new technology come as a “project”. The more complicated problem, the bigger the project. But as project get bigger, the chances of failure increases. So, what to do? Switch from “project” to agile releases. And make them happen timely. Every 1-2 months. You might screw up some of these releases. Or you might come with incomplete results. But as you repeat more, implementations will improve. Each “release” brings enhancements in PLM implementation. As soon as you work out 1-2 months releases, move into continues integration. Ask your PLM vendor how to implement PLM technology using agile implementation methods. This is a good starting point how to escape risky PLM projects.

3- Focus on PLM TCO

PLM implementations are too obsessed with total cost of ownership (TCO). The obsession is so big that often it starts to impact the outcome. Actually cost generate benefits. And benefits are good. So, focus on how to generate benefits and not how to cut cost. TCO is discourage new functionality and as a result of that you can miss PLM value. So, shift from PLM TCO to PLM value. And combine it together with shift from PLM “project” to “releases”.

What is my conclusion? Old habits die hard. Remember the phrase “Nobody ever got fired for choosing IBM”? It came from the time when the focus was on how to take less risky decision. The result was impacting project duration and cost. Most of companies today don’t have a luxury to run 5 years PLM projects. There are things in PLM implementation practice that needs to be changed. Often, companies are doing things not because they are better, but because they did it before. Just my thoughts…

Best, Oleg

Want to learn more about PLM? Check out my new PLM Book website.

Disclaimer: I’m co-founder and CEO of openBoM developing cloud based bill of materials and inventory management tool for manufacturing companies, hardware startups and supply chain. My opinion can be unintentionally biased

Share

Share This Post

  • Pingback: GHZ Partners | IT Services, Software()

  • Devanga

    Absolutely. Right during requirements analysis phase pareto principle has to be kept in mind. Strict NO NO for 100% use case implementation. Also, implementation team should keep an eye on kind of problem, i.e related to people, process or technology. and act accordingly. Solving people issues with process or vice versa could be expensive and unnecessary. Also, IT or Business champions should be able to assess ROI on use case basis, which can automatically reduce the complexity of implementation. If there are no clues from upfront people/process, looking at help desk tickets for the past 6 months or past year can give an idea as to what are high priority problems.

    Agile implementation is good idea, however not sure if 1-2 months can work. Quarterly releases may be good idea keeping in mind time for testing and deployment to Dev, Test and Prod environments.

  • beyondplm

    Devanga, thanks for sharing your insight and support! The reduce complexity and built a tool sets for agile dev and continues integration is the key. To make it happen the implementation time must be reduced. Dev-Test-Prod should be automated. Can you explain why 3 months is important vs. 1-2 months?

  • Colin Bull

    Some companies will only accept Quarterly, it is arbitrary but looks good on a page. Most PLM are also integrated into ERP and some MES and they look at the same Quarterly schedule. I agree though Develop Test and Prod, automation is essential.

  • Devanga

    I am all for Agile development, but in my experience, implementation projects specifically one which involves some amount of customization with some developers doing parallel development its very difficult to sort out things with in month or 2. Planning and getting UAT done from business team was also challenge. Also keep in mind, back up procedures ( Database back up, configurations etc) , web application server updates etc need to be coordinated with different teams.

    I got opportunity to review deployment process for one of teams, where deployments were planned every two weeks. It was not an easy activity and deployment activities were taxing development and testing activities. Every one in team was stressed ( development team were worried to which branch source codes to be checked in to and project manager was concerned which changes can be successfully deployed for next drop) .

    If complete deployment process is automated, then may be we can think of it. In my experience building and deployment had reasonable level of automation, but automated testing was way off or not there at all.

    Hence in my opinion Dev and Test can updated with lesser frequency but not Prod.

  • Hi Oleg, we use our Benefits Appraisal methodology to look at ROI, payback as well as TCO. Since so many PLM-related tasks are repetitive, even small efficiencies can add up, so much so that we have “knobs” in our analysis tool to turn down the benefits so they are more believable.

    I agree that the main use cases are the most important. Industrial organizations have gotten addicted to customization/tailoring often abetted by their implementation partners. If you are going to teach a computer to do a process, shouldn’t you look at it to see if it can be improved? Processes often arise to deal with exceptions that may no longer apply.

  • beyondplm

    Devanga, thank you for sharing your experience! This is probably the best explanation why existing PLM platforms need to have retooling. Current technologies (database backups, configs, deployments, etc.) are not standing up to agile development.

  • beyondplm

    Colin, thank you for your comment! My hunch is that complexity is preventing from anything but Quarterly. Integration challenges is a good point and it usually slows down implementations significantly.

  • Devanga

    Thanks. I agree current tools/technologies have some limitations. But to be honest, IMHO lack of process discipline and ability to keep in pace with software releases from product vendors is more challenging and costs more than technology limitations.

    As you have pointed in other articles, upgrades owned by product vendor seems an excellent choice. All though I do not have experience, but definitely seems lot of progress in reducing the deployment activities.

    On a side note, I am always amazed at your vision and keeping tab on technological advances in PLM. . Still have difficulty in comprehending how you can come with nice topic each day..:-(.

    Its pleasure reading your blog.Thanks a ton.

  • beyondplm

    Devanga, you’re welcome!

  • beyondplm

    Stan,

    thanks for your comment! Teaching “process” can be an interesting use case. I truly believe an existing process (workflow) paradigm is going to change. It doesn’t mean we will eliminate process, but we will eliminate the way we implement it.

    Take a look here
    http://beyondplm.com/2015/10/07/plm-workflows-are-dead-interactive-user-experience-is-coming/

    I’d be very interested to know your opinion.

    Best, Oleg

Subscription Options:

Subscribe via RSS

Popular Posts

Recent Posts

Archives

Blogroll