OOTB PLM is Hit or Miss
PLM Blog - Aras Corporate Blog

Syndication

PLM In A BoxOut-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?

Original image courtesy of CostumeFinder.co.uk


Posted Mon, Dec 6 2010 3:40 PM by MarcL

Comments

Chad Jackson wrote re: OOTB PLM is Hit or Miss
on Tue, Dec 7 2010 10:59 AM

Marc,

I agree with some of your points and disagree with others.

1.) You're right in that its very infrequent that an out-of-the-box PLM solution will fit a manufacturer's development processes.

2.) When there isn't a 100% match, then you have to modify or change the OOTB PLM solution.

3.) You can change the PLM solution with configuration (changes to preset options or values) or customizations (writing and compiling code to extend the solutions). There is a big distinction between the two.

4.) Just about every company I know at least configures their PLM solution. The customization is what just about every organization tries to avoid because they can often break during upgrades as the API changes.

5.) In your example on change management, adding steps to the process is often considered configuration. Designating new roles for specific actions in the process is also considered configuration.

6.) All in all, I would agree that flexibility is very important. How exactly is Aras Innovator more flexible than SPLM's Teamcenter, PTC's Windchill, DS's ENOVIA, Omnify's Empower PLM or any other number of PLM solutions?

Looking forward to the response.

Chad

MarcL wrote re: OOTB PLM is Hit or Miss
on Tue, Dec 7 2010 2:38 PM

Chad,

Thanks for your comment and the points outlined.  I hear what you’re sayin about configuration (changes to preset options or values) vs. customization (writing and compiling code).

While the idea of using “preset options and values” as the basis for PLM supporting complex company-specific processes sounds great, I just have not seen it serving the needs of most enterprise-wide global PLM deployments. Everyone tries to avoid customization, however, the fact is that the vast majority of PLM systems are heavily customized.

To answer your question about how the Aras flexibility is different/better than the other major PLM systems -- this is the Aras technology advantage: model-based SOA with dynamic data model instead of a hard-coded data schema like Windchill, Teamcenter, ENOVIA, Agile, etc. Can read more about this at http://www.aras.com/technology/">www.aras.com/technology

Can customize Aras in real-time without complex coding, compiling, etc. -- drag & drop changes to data schema, workflows, lifecycles, forms, business rules, etc... and no matter how much you customize, we’ll upgrade it for no cost when you’re on subscription http://www.aras.com/getting-started/faq.aspx#UpgradeServices">www.aras.com/.../faq.aspx That means this is not just marketing, we stand behind it.

Hope this helps.

MarcL

http://www.aras.com

NitinS wrote re: OOTB PLM is Hit or Miss
on Wed, Dec 8 2010 1:29 AM

Marc,

I understand what you have mentioned but I will still agree with Chad. I will not label any PLM to be customized if  there are some OOTB workflows manipulated to fit into customer's business process. As you said, no two organization can have same process and this is where PLM provides customer an ability to map their business process into it.

Customization mainly invloves coding like extension of OOTB class files or changing UI rendering behavior. While UI customization is mainly like improve display to help not so computer-savvy end users work with easily with PLM, extending classes is mainly done to change some OOTB functional behavior.

MarcL wrote re: OOTB PLM is Hit or Miss
on Wed, Dec 8 2010 11:05 AM

NitinS – Basically agree with the way you are defining configuration vs. customization. Doesn’t really change the fact that the vast majority of global PLM deployments undergo heavy customization. Those same organizations tried really hard to stay with configuration of OOTB, however, for one reason or another a lot of customization was necessary. suppose my point wasn’t strong enough… title should have been “OOTB is more Miss than Hit”. This leads to the case for real Flexibility (IOW, complex customization W/O the programming) don’t you think? MarcL

Jos Voskuil wrote re: OOTB PLM is Hit or Miss
on Thu, Dec 9 2010 7:08 PM

Mark hi, a post that is provocative and should raise more discussion. My response would be to long to write as a comment I discovered, therefore I added it as a blog post in my blog. See http://wp.me/pfRxK-i2 and looking forward to proceed with the discussion.

I agree - flexibility is key

Best regards

Jos

Paul wrote re: OOTB PLM is Hit or Miss
on Wed, Dec 15 2010 4:52 AM

I think the distinction between customisation and configuration is far from black and white.  When configuration can fundamentally change the behaviour of a system and upgrades restore default settings, there is as much effort in configuration control of configurations as there is in code - in some ways it's worse because they are harder to spot - a module that won't compile and install is easy to spot, a condition that has reverted from TRUE to FALSE is not so easy as nothing is 'broken'.  So whilst 'configuration' should survive an upgrade unscathed, regression testing is still a very significant piece of work and probably means that a sensible level of customisation actually adds little cost (we won't raise the onshore/offshore argument here :-)  )

I agree that OOTB is a joke for any company doing anything non-trivial, plus your point about process being the source of competitive advantage is spot on.  And it is frequently process that drives customisation (specific fields to support specific process steps, access controls within certain processes etc).  

The other thing is Integration - our recent project required significant PLM data model changes to support an ERP feed.

PLM Blog - Aras Corporate Blog wrote OOTB PLM. Seriously?
on Mon, Jun 17 2013 8:29 AM

I read the headline and couldn't believe my eyes: "PLM: Are You Ready for Out-of-the-Box?"