Out-Of-The-Box (OOTB) PLM solutions are great in concept. The reality, however, is not so rosy or promising. A while back, Chad Jackson did a post on his blog, Engineering Matters, called My Points in the ‘Why Hasn’t PLM Taken Over the World’ Live Blog Debate. That post is where I got the title for this Blog.
Chad was outlining a series of points about the state of PLM and the industry as a whole, and one of his bullets in particular caught my attention:
Support of initiatives by OOTB PLM is hit or miss. Sometimes an initiative can be enabled with out-of-the-box PLM functionality. For example, many PLM providers have included an OOTB change management process in their solution. If that’s the initiative a manufacturer needs to address, then the OOTB functionality will most likely address their needs. But if the initiative is to provide DOD security access to over 100 suppliers, the OOTB functionality probably will not do what they need it to do.
While I agree with the point Chad’s trying to make, I do not think he goes far enough. Examples typically illustrate these kinds of issues the best so let’s take the Engineering Change Management example.
Today, whether your company has an existing PLM system or uses email & spreadsheets for Engineering Change Management you’ve got a specific set of required / optional information that is necessary for a proposed change, associated files, review & approval process, etc. The odds are slim that your change process is a 1-to-1 identical match with Ford’s process, even if your company is in the Automotive industry.
Now stop and think... the fundamental premise of OOTB enterprise software is that there’s an exact match between your corporate processes and the software. If it’s not an exact match, then get ready to customize (and it won’t be OOTB anymore).
This is why the concept of OOTB enterprise PLM is absurd. It doesn’t matter if we’re talking about Industry Accelerators or so called ‘best practice’ templates. The odds of a 100% perfect match are infinitesimally small. You might get really lucky on one process, but the odds are against OOTB working across your entire PLM scope. This is why as Chad puts it, OOTB PLM is “Hit or Miss”.
So, you have two options…
1. Change your company’s processes & practices to fit the OOTB software, effectively erasing any process-based competitive advantage your company has.
2. Customize the software to support your proprietary processes and retain your competitive advantage.
The inevitable conclusion: You’re going to have to customize your PLM.
This is a good conclusion. A logical conclusion. It also makes sense when you think about the future. Business conditions are changing rapidly; new market opportunities, new competitors, new innovations and requirements, new strategies, continuous improvement, etc. Your company should not get stuck with a static PLM process and a system that locks you into a one-size-fits-all OOTB PLM forever.
To compete you have to be able to quickly change your PLM processes on an ongoing basis to capitalize on opportunities and address competitive threats. If you are eternally stuck in a hard-coded OOTB PLM, you have jeopardized your company’s future. Just something to think about... seriously, think about it.
So, if customization is inevitable and OOTB is fantasy, then what’s the most important consideration. Flexibility. The ease with which you can adapt and modify an enterprise PLM solution trumps all other considerations at the end of the day.
Flexibility will drive everything else:
- Ability to support unique competitive practices
- Usability / ease of use (because all the features in the world are useless if no one uses them)
- Implementation costs
- Speed of deployment
- Ability to adapt overtime
- Cost and effort to upgrade
...and the list goes on and on... I’ve written about this in the past; can check out my posts Is PLM software OOTB Functionality a Red Herring?and PLM Industry Accelerators, Panacea or Problem?
The OOTB requirement is a long running issue. Over the past 20 years big companies have all had multi-million dollar, multi-year legacy PLM and ERP projects that became exceedingly complex, unmanageable and impossible to maintain and upgrade. The response (even if it’s illogical) has been, OOTB only and don’t customize.
It usually surfaces when a company says, “I only want OOTB functionality, but it’s got to match our processes.” It’s the kind of statement people make all the time without even thinking about it. Odds are against ever finding the ‘perfect fit’... Instead, my recommendation is to focus on Flexibility. That way you can escape the OOTB crap shoot which by definition results in a lock-in trap.
What’s your take? Will OOTB PLM be forever “Hit or Miss”? Or will we finally realize that we’ve been chasing the fallacy of OOTB for too long and begin focusing on Flexibility?