Taking the Functionality Out of ERP Selection and Implementation Decisions
- 17 November, 2009 12:15
Over the years we have learned a lot about ERP initiatives. Many of these lessons have come the hard way – costly, time-consuming, company-consuming projects that left us scrambling to find benefits to justify the costs. If you ask almost any ERP project manager what, in hindsight, they would do differently, the answer is the same: Do not customize the software! In spite of this advice, each time an organization starts an ERP selection or implementation project, the going-in assumption is that the software must handle the unique aspects of the business.
After having personally managed several ERP implementations (and consulted with others on numerous projects), I developed the following model to simplify ERP and many other business / IT initiatives. My goal in developing this model was to improve the likelihood that we would make more rational decisions about where to accept “vanilla” or standard functionality and where it makes sense to invest in changes to the standard functionality. I have used this model very successfully on both large and small IT initiatives. For an ERP implementation, using this approach has reduced the project timeline by as much as 50% and the budget by as much as 40%.
I have also used this model when integrating business processes and systems. For example, I recently used this approach to get rapid agreement (about 30 minutes) on a payroll consolidation decision. The goal was to consolidate the three separate payroll systems used by three separate divisions into one system. The meeting participants came to the meeting prepared the make the case for why we should consolidate the other two divisions onto their payroll system. We spent about 20 minutes going through the following model and then 10 minutes agreeing that, since our payroll activities were “parity”, any of the three systems would keep us at payroll process parity. We then chose the payroll system that had the best support model (and thus, took functionality out of the payroll decision). Nice, easy, and simple.
So, without further fanfare, the model is:
Using this model, we evaluate our business activities in two dimensions. The extent to which they differentiate us in the marketplace and the extent to which they are mission critical to us.
Page Break
This yields four types of processes.1. I genericize those that are both differentiating and mission critical as “Differentiating” since we use these activities to gain market share, win customers, beat the competition, et cetera. We want to excel at these activities. We should be innovative in how we perform these activities.
2. I genericize those that are mission critical but not differentiating as “Parity” (the majority of our activities fall into this category). The purpose of these activities is to achieve and maintain parity in the marketplace. These are the activities that we should simplify and streamline. Anything we do that makes (or attempts to make) these activities better than they have to be is an over-investment since these activities do not differentiate us in the marketplace. However, since these activities are mission critical, we need to make sure that we are at parity in how we perform these activities. If we are under parity with these parity activities, we can lose market share.
3. There might be some activities that, while not mission critical, can differentiate us in the marketplace. Since these are not mission critical for us, we find someone with whom we can partner in order to deliver what is differentiating.
4. Finally, some activities are neither differentiating nor mission critical. I call these the “who cares?” activities since we should not care.
Our approach varies according to the purpose of the activities as shown in the following:
We spend most of our time on activities that are either Differentiating or Parity (with the vast majority being Parity). It seems to be human nature to be creative in what we do. Since we spend most of our time immersed in Parity processes, we have a tendency to make our Parity processes more complex than they need to be. For the Parity processes, we should use our creativity to figure out better ways to implement the streamlined, simplified, standardized way of performing these activities. We should focus the creativity that helps us win in the marketplace for our Differentiating activities. That being said, let’s look at some case studies.
A specialty retailer had made the decision to replace their legacy system. After having used the legacy system for 25 years, its functionality was entirely meshed with the retailer’s business processes. The system handled every possible exception. As the retailer changed business rules, the development staff made new customizations to deal with the revised business rules. However, while the legacy system mimicked the retailer’s business rules and processes, it did not provide any meaningful analysis and decision support tools. The legacy system simply did not capture transactional information that could answer product, customer, and market questions. Lacking these answers, the retailer was losing market share. The CEO decided that the legacy system would not and could not support the turnaround of the retailer and so ordered the initiative to replace the system.
The company started the project in the traditional way by gathering the new system requirements in order to create a request for proposal (RFP) that would help select the new system. The company compiled about 300 pages of functional requirements that were an exact description of the legacy system and that required support for 25 years of custom development and exception handling. At this point in the project, I met with the CEO and explained my model. To the CEO, it was clear that much of the functionality of the new system fell into the Parity category and, as such, did not need to be better than or different from the accepted standard way of performing the Parity activities.
With this conversation, the new system project took a dramatic turn. Rather than gathering new system requirements (in order to make a software selection) we assessed the difference between the current processes and the standard way of performing these processes. The software selection criteria shifted from functionality (after all, the ERP systems they were considering all supported the accepted way of performing the Parity processes) to factors such as total cost of ownership, ease of implementation, ease of integration, et cetera. We took functionality out of the selection and implementation decisions. After selecting the new software, the implementation plan was based on how much time it would take to train the employees on how to use the standardized processes supported by the ERP and how long it would take to convert the legacy data into the new system. In parallel with a “vanilla” ERP implementation, we unleashed the brain power of the company to figure out new and better ways to perform the Differentiating activities of the company (product selection). This resulted in really interesting (and highly successful) approaches to customer and market segmentation and product analysis. In addition to the market benefits the company realized, the new system project was completed at about half the cost and in half the time of the original, traditional plan. Nice, clean, simple.
Others have used this model to integrate disparate systems. We often associate our systems with our lives and when someone proposes or mandates integration of systems, we build our defenses and build the case for why “our way” of doing things should become the standard for the integrated systems. By starting with this model, we take some of the emotion out of the system integration decisions. Does it really matter which system (and process) we use for purchasing? If it is a Parity activity, what matters is that the integrated system support a streamlined, simplified, standardized purchasing process. Same for all of the Parity activities.
Page Break
Does using this model solve all of life’s problems? Not by a long shot. However, it does help properly frame the criteria we can use to make decisions that optimize business value.One final non-ERP example. A software company had planned its next major upgrade. Its product managers and software development managers had mapped out the functional specifications for the new version. The specs included more than 3000 function points and a timeline of over a year. The CEO of the software company was concerned about the risks associated with a project this large and so asked me to conduct a risk assessment. All I needed to hear was “3000 function points and more than a year” to know that the project was high risk. I introduced the model and we agreed on the decision filters that would help us identify the Differentiating functionality. We then mapped the function points onto the model. There were about 350 Differentiating function points with most of rest being Parity function points (although, to be honest, we found a few Who Cares function points). Knowing which functionality would truly differentiate the company in the marketplace and which functionality needed to be “good enough” we re-planned the project. We anticipated creative designs to the Differentiating functionality. We agreed to not over-design the Parity functionality and explore re-use of existing code, where possible. The result of using the model to define functional design was a better product (the Differentiating functionality was truly superior) at a much lower cost and shorter timeline. Simplifying the design and development of almost 90% of the code was a significant cost and time benefit.
Finally, a few caveats. Using this model shifts the work of a project from systems to people. This model assumes that humans can adapt to streamlined, simplified, standardized business rules and processes. To be honest, some humans have an easier time of this than others. Also, it is critically important to stress the mission critical nature of the Parity activities (and those that perform the Parity activities). These activities and people are essential to our success. However, their importance does not come from their uniqueness. Rather, from their operational excellence.
