GO NATIVE! Mind the Gap!
Mind the Gap! Part 3 of the 3 part series on Going Native.
This is the third of my three part blog series on leveraging native functionality in packaged business systems. The theme of this blog is how to leverage native functionality to the greatest extent possible, and then how to customize it to achieve competitive advantage. Furthermore when customizing a business system, you should strive to keep your customizations as succinct as possible so that they work reliably through future system upgrades.
For those who are not familiar with “the tube” (i.e. the subway) in London, you may be wondering about the title of this blog. “Mind the gap” is a warning repeated to passengers to take caution while crossing the gap between the station platform and train car. Under normal conditions, the gap should be small and easy to cross but you must be careful to avoid twisting your ankle as you step in or out. You can find more details at the following URL:
I chose this title because it is critically important to “mind the gap” when customizing business systems. No business system can or should attempt to address every single business nuance with native functionality. Well architected systems typically do a good job of providing a very robust functional framework that anticipates where customers will need the ability to provide custom logic in the form of enhancements.
Enhancements are used to close the small functional gaps that you encounter during your blueprinting or realization activities. They are not intended nor should they generally be used to fill gaping functional holes. If you find many of such holes during the fit/gap analysis in your software selection process, then you are likely evaluating a system or type of system that is a bad fit for your business needs. Mind the gap! But how?
Everything should be as simple as possible, but not simpler – Albert Einstein
There is a lot of wisdom in this quotation. My corollary is that you can find 100 or more ways to solve any given problem – but probably only a few of those ways are good ways – and the simplest way is usually the best way. Paradoxically simple solutions can often be the most difficult to find.
One of my favorite anecdotes is about a tractor trailer that was driving under a bridge and became stuck because of insufficient clearance. The trailer was so tightly jammed that it could not be moved. Engineers and experts were called to the site to figure out how to free the truck. They devised all sorts of elaborate plans to raise the bridge, cut the trailer top off, dig under the truck, etc. A child walked up to the scene and asked “why don’t you just let the air out of the truck’s tires?”
As in the example above, I instinctively know when I have found the simplest and most elegant solution to a problem. It just feels right and makes perfect sense. So how could something be simpler than possible? That just means that you didn’t entirely solve the problem but instead gave a simplistic solution that has limitations and didn’t fully meet the requirements. In most cases, this is a less than satisfactory outcome. You shouldn’t “dumb down” a problem just because it is difficult to solve, however it is always prudent to ask whether an elaborate solution is really required and whether it will actually be used as expected.
When you determine that you should or must enhance your business system, how do you know if you have done so appropriately? I have seen a lot of enhancements in my experience – some good, many bad. I use the following three simple rules of thumb to evaluate enhancements.
Be careful about designing and testing enhancements to work with only the subset of functionality that your company has implemented so far. While this may seem like a smart time saver at first, poorly implemented customizations can inadvertently limit your ability to use advanced native functionality or system upgrades in the future. Ideally your enhancements will work properly with the full range of native functionality, but if not then at least ensure that they gracefully trap situations beyond their original design and can be extended to support future needs.
How does one learn to implement good enhancements? In my experience, quality training for enhancing business systems is hard to find. The training that is available is all too often focused on the mechanics of the functionality, i.e. definitions and explanations of features and functions and how they work. Think of the analogy of learning about the various tools in a toolbox - does that training make you a skilled carpenter? Not by a long shot. I can personally attest to that fact. Both of my grandfathers were skilled carpenters. They showed me how to use every tool, but let’s just say that my carpentry would never be mistaken for expert craftsmanship.
While learning the mechanics of a business system is an obvious place to start, that shouldn’t be the end game. In practice, I have seen far too many customers send their team to one or more weeks of "mechanics" training and then have them return to design and implement enhancements for addressing complex business needs. You can probably guess how this typically works out. Perhaps I can illustrate by continuing my carpentry analogy with this quotation:
If all you have is a hammer, everything looks like a nail - Bernard Baruch
Perhaps the worst thing you can do is learn a few example enhancements and then start trying to apply those design patterns to every enhancement need that comes along. We call that the “blunt instrument surgery” or “bull in the china shop” approach. Implementing good enhancements requires a lot of knowledge and finesse. You should consider tapping your colleagues or user groups for ideas and experience in closing similar functional gaps. Chances are that your company is not the first or only to face a given customization challenge.
In my opinion, on the job training is usually the best and only way to really master the design of business system enhancements, but not all experience counts equally. Make sure that someone claiming "ten years of experience" truly has ten years of broad and progressively more challenging design work (as opposed to repeating a year's worth of the same type and complexity of design work ten times).
eLogic is highly experienced in implementing business system enhancements. We have built libraries of commonly needed and broadly applicable enhancements. Most of these enhancements are part of our “100x100 solution gallery” which represents over 100 best practices gleaned from over 100 business system implementations. These enhancements are categorized by industry need and functional area and have been very favorably received in the marketplace. These enhancements can provide you with significant business value right out of the gate. Let us know if you are interested in learning more about these enhancements or our solution gallery.
This concludes my three part blog series on leveraging native functionality in business systems. I hope that you found my advice to be useful. Thanks for reading!