Part 1 of the 3 part series on Going Native.
I have been implementing packaged business systems (ERP, CRM, PLM, etc.) for nearly twenty years. Over that time, I have seen some companies with very successful implementations while many others have struggled mightily. What causes this difference? When I think about the most critical success factor, it is clearly making optimal use of native system functionality to address the widest range of business needs and opportunities and then making limited enhancements to gain or secure competitive advantage. In a nutshell, GO NATIVE!
This is the first of a three part blog series on leveraging native functionality in packaged business systems. In this series, I will explore challenges and benefits of implementing these systems the way they were designed to be implemented. I will start each blog with one of my favorite quotations to illustrate the central theme of that blog...
If you always do what you always did, you will always get what you always got – Albert Einstein
At some point, every business system reaches the end of its useful life cycle. The end can be precipitated by internal influences like a company outgrowing its system’s capability or perhaps the merger of two companies needing to consolidate operations into one system. With time, the end will inevitably be precipitated by continual architectural advances in hardware and software or ever increasing expectations around user experience and system features or capabilities.
So eventually your company will decide to replace each business system with a new one. How should the new system be configured to meet your company’s current business requirements? “Just like our legacy system” you say? “After all, we know that it works. We have been through all the requirements that led to the processes that led to the system that we implemented and refined over the years. Our legacy system is the embodiment of how our business runs.”
I have been in a discussion like that many times. First of all, a legacy system is the embodiment of how a business *ran*. Over many years of usage, the business’ requirements, processes, and system can become incorrectly viewed as one and the same. In fact when the legacy system was implemented, your processes were shaped in part by that system’s capabilities and limitations. When replacing it, you must take a fresh look at your business requirements and determine what processes are now possible with the latest generation of business system functionality.
This is where you must be on the lookout for the “legacy intransigents”. Some people become quite emotionally attached to the way that their legacy system works. They find comfort in the familiar, the tried and true. They know where everything is and how it works. New systems are unfamiliar and rather intimidating to them. They view their legacy system through rose colored glasses. Long gone are their memories of when the legacy system *was* the new system, how its implementation was just as challenging, and when it wasn’t quite the panacea that it is today. For people like this, I have observed how the advent of a new system has accelerated more than a few retirements.
Your new system should enable you to take your business to the next level. Be careful that intransigents do not derail your new system implementation by trying to make it a “new and improved” version of the legacy system. This outcome is actually the worst of both worlds. You end up with a highly customized new system that isn't quite as quick or easy to use as legacy was, and it is more difficult and costly to maintain. Worse still, most of the new capabilities and features that prompted the purchase and implementation of the new system were likely not used because they did not exist in the legacy system.
In my experience, the most egregious examples of “falling into the legacy trap” occur in product configurator implementations. For example, I have been a solution architect or consultant in over 100 SAP ERP variant configuration projects. Granted most of these were small projects and my role was mainly design, but nevertheless I have seen too many instances of customers trying to force fit legacy configurator constructs and logic into SAP’s configurator. The resulting models typically have so many cryptic rules and design obscurities that it becomes quite difficult for anyone not deeply involved in the implementation to gain a comprehensive understanding of overall solution.
So if legacy isn’t the path to the future, then what should you do? First and foremost, learn the architecture, capabilities, and native functionality of your new system so that you can make informed implementation decisions. Identify your best technical and functional people and give them ample time to explore, experiment, and learn. Give them access to experienced consultants with deep domain and/or system experience. Keep your team small while ambiguity is high. Start with a proof of concept or pilot project where you can afford to go through the necessary cycles of learning. This isn’t “throw away” work; the time you will save and missteps you will avoid down the road are truly invaluable!
In my next blog, I will talk about the dangers of needlessly enhancing a new system instead of leveraging its advanced native functionality simply because the necessary learning described above did not happen. This “do-it-yourself” approach occurs all too often and leads to an array of problems. In fact, a significant portion of eLogic’s business has come from rescuing such failing or failed implementations. All other things being equal, I would gladly give up this “rescue” business in favor of helping companies do it right the first time around. Hopefully my advice in this or future blogs will help someone do just that.