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.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.