Part 2 of the 3 part series on Going Native.
This is the second in my three part blog series on leveraging native functionality in packaged business systems. As before, I will start this blog with perhaps my favorite quotation - one that best describes the theme of this blog:
“Just because you can do something doesn’t mean you should” - many
Most everyone is familiar with the "80/20 rule". In the context of business system implementation, it suggests that at least 80% of your business needs should be addressed by the native functionality of your business system while the other 20% or so must be addressed through customizations and/or manual processing. Hopefully your business system has obvious native solutions for most of your needs, but what should you do when a business need arises without an obvious native solution?
Whatever you do, you must resist the temptation to develop a custom solution before fully investigating native alternatives. All too often I have seen customers develop custom reports, transactions, etc. when native functionality would have provided a better and more extensible solution. I have seen two general reasons why customers have developed a custom solution instead of leveraging a native one.
1) Lack of detailed knowledge about the native functionality (or how to use it)
2) Perception that a given custom solution is easier to implement or use than the native one
The first reason is typically the more difficult to overcome. It can be avoided with leadership from solution architects who have a deep understanding of the business system architecture and its design philosophies PLUS the skill to match business needs with native system capabilities (i.e. a fit/gap analysis). These individuals possess several key characteristics and abilities like the following:
Natural curiosity (e.g. what does a given feature do and in what situations would one want to use it?)
Translation (i.e. connecting business needs to functionality even though terminology may be different)
Pattern recognition (e.g. this need is similar to one that was solved using a certain native functionality)
Resourcefulness (e.g. finding ways to use leverage native functionality in creative ways or combinations)
Gap identification (i.e. determining when a need cannot or should not be met with native functionality)
The second reason is usually more of a corporate culture or training challenge. Many people have an inclination to "reinvent the wheel" or else that phrase would not be so commonly used. This mentality is rather self-defeating when implementing a business system. It can result in a lot of unnecessary effort and expense. I have seen people offer an array of excuses for justifying such customizations - see some examples below along with my typical rebuttal.
“The system doesn’t do it”. Where is your analysis and proof? Or is it more accurate to say “I don’t know how to do it in the system”?
“I have to see it like this”. Have you tried to view it the native way? Can you quantify the additional effort or risk for using the native transactions instead? By the way, you will need that to justify a customization.
“We must have this report”. Legacy systems often need custom reports because they lack native reports and transactions to see data that most modern systems natively provide. Another key metric is how often a given custom report is actually used. You might be surprised to learn how infrequently some “must have” reports are generated.
“We have always done it this way”. This is perhaps the quintessential excuse. Unless your business did not exist before the computer age, it is probably more accurate to say “I have always done it this way”. Or are you saying “we should always do it this way”? I find neither to be a very compelling argument.
Despite the question of why you would want to (re)build functionality that you have already licensed AND pay a vendor to maintain, there is another point you should consider. Customizations are often designed and tested to work with only the SUBSET of functionality that your company has implemented. All native functionality is designed to be fully integrated and supported across the entire system with few limitations. Improperly implemented customizations can inadvertently limit your ability to use advanced native functionality or upgrades in the future.
A significant portion of eLogic’s business comes from “retrofit projects” in which we implement or properly re-implement native functionality in situations where the expected ROI for a business system was not initially achieved. In such projects, existing customizations are the first thing that we evaluate to determine the following.
Which customizations can be reduced or eliminated using native functionality? The more the better.
Will newly implemented native functionality work properly with existing customizations? We routinely find poorly implemented customizations that prevent native functionality from working properly. They must be corrected or rewritten.
Will existing customizations continue to work with newly implemented native functionality? This is usually the largest and most difficult effort to quantify because many existing customizations can be complex, improperly scoped, and/or understood by only their original authors.
I hope that this blog has convinced you to resist the temptation to needlessly customize your business system. If so, then how do you learn to take full advantage of your system’s native functionality and keep customizations to the essential minimum? I will discuss my experience and suggestions in my next and final blog in this series.