Out-Of-The-Box PLM and Open Source Option

I had chance to read the story “Is PLM software OOTB Functionality a Red Herring?” by Marc Lind on Aras’ community website. I definitely can see a growing amount of debates around PLM Out-the-box story or how software vendors call it very often – Best Practices.

Do you remember the name “turnkey solution”? This is one of the previous names for out-of-the-box. Welcome! You can buy a system, turn a key on, and you are done :)… The definition of “turnkey” solution was different and changed within a time. In the beginning, it was about how to not to “rebuild” the system for every customer. Then it moved to installation option that not required 10 people work for few months to install and configured system. Finally, it comes to the point when “a turnkey” started to focus on engineering and business problems.

Engineering Foundation of Out-of-the-Box (OOTB)
The invention of OOTB system as a system that can solve engineering and business problems had very good roots. A majority of engineering and manufactures software companies were started by engineers. Engineers tried to solve problems for engineers and definitely could find a solution. After the problem was solved for more than one customer, the obvious question was how to scale up?  There are few possible ways to move forward – to create a configurable and modular system or to open system to be modified and adjusted by customers themselves and partners. Vendors tried to solve both. The first seems to be complicated. The second was expensive and long in time.

Marketing Damage
At the time engineering tried to solve a problem of how to configure systems to fit needs of different customers, marketing came with a nice proposal to re-sell existing customer implementation packed as best practice solutions . Basically, it was a good idea – why not to re-use existing experience with customers? The implementations done by many of them represented state of the art and considered as best in their class. However, here the problem- engineers are not running their shops in the say ways. They strongly believe in their uniqueness and specific manufacturing practices. The marketing story becomes a story of long implementation cycles after deals were closed and money paid.

Open Source Option?
There are two important aspects of open source that can give a potential chance to PLM open source to grow in a current situation. The first is emotional – you are not paying upfront, and you pay for maintenance and support. Even if everybody understood that the same or comparable amount of money can be paid in different ways, it creates a social empathy to the solution. Second one is real – you can have a wider distribution of software. By doing so, open source creates the situation where the effect of scale can be significant and crowd sourcing will become a real option.  So, I see community building as a top factor that can make PLM open source real. In the case engineers will start to collaborate, it can create a potential network effect.

What is my conclusion? Selling Enterprise Software is a hard job these days. People stopped buying marketing stories. They need software to solve problems today and not tomorrow. Out-of-the-box started as an initiative to compensate long, complicated and expensive implementation cycle. The fundamental idea was simple- you pay more, but you can take a system and work now. One of the reasons it wasn’t successful is in the nature of manufacturing organization. If you talk to PLM vendors, they will give you PDM CAD document management as an example of the successful out-of-the-box functionality. However, when it is probably easy to agree on check-in/check-out/release commands, it won’t be so easy to produce “the universal change management module”. In my view, PLM needs to run a recovery mode now to get back from spectacular marketing presentation to nuts and bolts of engineering and manufacturing implementations.

Just my thoughts…
Best, Oleg



Share This Post

  • I agree Oleg, special care should also be taken when looking at so-called OOTB ‘industry’ or ‘best-practise’ templates. Are they there to provide a valuable head start on the journey towards an environment that really meets the organisation’s process needs (which is OK)? Or are they a marketing device to mask an outdated PLM architecture that is difficult to adapt and configure (definately not OK). Too often the latter is true and they become a straightjacket preventing operations differentiating themselves by innovating around process. What a terrible idea!

    The ideal is of course good OOTB functionality but also a flexible architecture that allow people to adapt the solution without fuss (and upgrade issues) to their processes. And don’t forget openness. They need that too. Who wants to be locked in that straightjacket forever? I’ve worked with a variety of big old PLM systems and they all pretty much sucked when it came to flexibility AND openness. The ones that were flexible weren’t open and the ones that were open weren’t flexible. Only Aras would get my vote on both counts.

  • Actually I’m interested in documenting some of these the key risks (from a program manager’s view) when it comes to implementing PLM. I’m interested in why some PLM initiatives add value to organisations while others fail to deliver the expected benefits and may actually destroy value.

    So far I’ve come with 8 risks based on my experience (see below). It would be great to get other people’s perspectives and experiences on why some initiatives fly and others bomb..

    Here’s the risks I have so far..

    Disconnect between the PLM initiative & the organisation’s strategy and business challenges.
    Poorly defined PLM implementation roadmap.
    Poor understanding of the total software procurement budget required to deliver the full PLM technology roadmap.
    Difficulty aligning the PLM technology with the process.
    Poor understanding of implementation services costs required to deliver the full PLM technology roadmap.
    Underestimating cultural change factors.
    Underestimating the data migration challenge.
    Inadequate User Methods Development & User Education

    The full paper is posted here


  • Sometimes I wonder how much of “can’t live with OOTB” is really just “Not Invented Here”. There have been several times in my experience that I’ve been told that standard or OOTB process just simply cannot work here. Then after a herculean effort designing a new process, because in most cases there isn’t one process to use but several along with religious wars over personal process preference, the result is at best marginally different from the standard OOTB. Some state names get changed and maybe a signature added but…

    The other side of that was a client who recognized chaos when it was staring him in the face and decided to use the OOTB, train everyone, see where it hurts and make adjustments. Worst case he had 1 and only one process launched in record time that might be limiting but is understood and then worked from there.

  • Graham, Thanks! I think, we are agreeing by considering OOTB as mostly marketing. The combination of flexible and OOTB is probably the most powerful. Openness can be different. You can talk about Open as NO LICENSE or you can talk from the standpoint of making content available. Best, Oleg

  • Graham, Thank you for sharing these materials. I found the list as a very interesting and co-sound with my view. Here are some of my thoughts about PLM implementation ownership. I think, it should be complimentary to your thoughts about PLM implementation and risks. http://plmtwine.com/2009/08/27/who-owns-plm-implementation-project/ Best, Oleg

  • Don, thanks for your comment! I got your point… It is very not natural for engineers to re-use, so they prefer to re-create. I don’t think somebody can prove what is most efficient – that to create a new or to modify existing OOTB template. Nevertheless, to understand WHAT to implement is the key. Best, Oleg

  • Oleg and Graham, as I think about my previous comments I realized that the path I advocated was based upon certain assumptions about the toolset. Very similar to some of Grahams needs. The OOTB application must be somewhat generic and that the supporting technology would allow rapid modification and adjustment as the organization learns from experience what’s working and what isn’t. Size of the organization will likely have a huge impact on the approach also since the politics and communication difficulties increase exponentially with size.

  • Don, Thank you for this clarification. I certainly can imagine all possible and impossible combinations between OOTB, implementation changes and corporate politics. I can see OOTB as a starting point – place to start. However, each organization will come to their own solution. I cannot see how OOTB can make TCO lower… Best, oleg

  • Pingback: The PLM State: Honesty is the best policy- Debunking PLM Myths - Zero Wait State()