Over the years, we CIOs have learned a lot about ERP initiatives. Many of these lessons have come the hard way -- after costly time- and company-consuming projects left us scrambling to find benefits to justify the costs. If you ask almost any ERP (or CRM or SFA or BPM or whatever) project manager what, in hindsight, they would do differently, the answer is usually the same:
"Do not customize the software!"
In spite of this advice, each time an organization starts an ERP (or CRM or SFA or BPM or whatever) selection and implementation project, the going-in assumption is that the software must handle the unique aspects of the business.
After having personally managed several large-scale system implementations (and consulted others on numerous projects), I developed a model to simplify business/IT initiatives. The goal of this model is to improve the likelihood that we will make more rational decisions about where to accept "vanilla," or standard, functionality and where it makes sense to customize. For an ERP implementation, I have found that using this approach reduces project timelines by as much as 50% and budgets by as much as 40%.
So, without further fanfare, let me introduce this model (which I, modestly, call The Nickolaisen Model). It is a quadrant, with a vertical axis that measures the level of market differentiation, and a horizontal access that measures the level of mission criticality of our business activities.
The Nickolaisen Model
Market
differentiation
of business
activity
|
|
High
|
Partner
|
Differentiating
|
|
Low
|
Who cares?
|
Parity
|
|
|
Low
|
High |
|
|
Level of mission criticality of business activity |
This yields four types of activities:
Highly mission critical and highly differentiating. I call these these activities differentiating, since we use them to gain market share, win customers and beat the competition. We need to excel at these activities. We should be innovative in how we perform them.
Highly mission critical but not differentiating. I call these activities parity. The majority of our activities fall into this category; they are the processes that allow us to do business, such as processing orders or invoicing suppliers. We need to perform these functions to achieve and maintain parity in the marketplace, but we should simplify and streamline the way we do them. Anything we do that makes (or attempts to make) these activities better than they have to be is an over-investment. This is typically where ERP projects run into trouble.
Highly differentiating but not mission critical. These are activities that, while not mission critical, can differentiate us in the marketplace. I call these partner activities because it makes the most sense to partner with someone who can deliver them.
Neither differentiating nor mission critical. I call these the who cares? activities, because I don't.
We spend most of our time on activities that are either differentiating or parity, with the vast majority being parity. In our drive to be unique, we tend to make our parity processes more complex than they need to be; instead, we should find standardized ways of performing them and focus our creativity on differentiating activities.
Let's look at an example.
A specialty retailer had decided to replace its legacy system. Though 25 years of customizations allowed the system to handle every possible exception, it did not capture transactional information that could answer product, customer and market questions. As a result, the retailer was losing market share (and money). The CEO decided that the legacy system could not support the turnaround of the retailer and ordered a project to replace the system.
The company started the project in the traditional way: gathering new system requirements to create a request for proposal. The project team compiled more than 300 pages of functional requirements (that were an exact description of the legacy system). That's when I came in.
I met with the management team and explained my model. It became 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. We scrapped the 300 pages and started over.
 |
|
|
|
|
Today, when someone enlists my help on a project, we first define the criteria we
will use to determine which business activities are differentiating.
|
|
|
|
|
|
|
|
|
|
First we assessed the difference between the current processes and the standard way of performing them. Because the ERP systems under consideration all supported the accepted way of performing the parity processes, we shifted the software selection criteria from functionality to factors such as total cost of ownership, ease of implementation, ease of integration, etc. During implementation, we configured the software to mimic industry best practices, changing business rules accordingly and training employees on how to do purchasing, inventory management, general ledger transactions, etc., in a new way.
Meanwhile, we unleashed the brainpower of the company to figure out new and better ways to perform the differentiating activities, such as merchandise selection. This resulted in really interesting (and highly successful) approaches to customer and market segmentation and product analysis.
In the end, the company experienced market growth, and we completed the project in 50% of the original time and at 50% of the original budget. Nice, clean and simple.
Today, when someone enlists my help on a project, we first define the criteria we will use to determine which business activities are differentiating. By default, most of the other activities are parity. Having these decision filters in place and communicating them throughout the company is extremely powerful. We then know how to approach business rule and system decisions. We ask, "Is this differentiating or parity?" If it's differentiating, we want to do it better than our competitors. If it's parity, we just need to mimic best practices.
Does using this model solve all of life's problems? Not by a long shot. However, it does help properly frame large- and small-scale project decisions while it aligns IT with the business. If you are interested, I have (since it is my model) more material on how to use this model, its affect on change management plans, and how it has been used for non-ERP projects. If you are interested, please let me know.
Niel Nickolaisen is CIO and vice president of strategic planning at Headwaters Inc. in South Jordan, Utah. Read Nickolaisen's past columns, including his first ITIL column, how he negotiated a telephone bill, tips on good management through performance reviews and more. Write to him at editor@searchcio-midmarket.com.
