Enterprise Resource Planning (ERP) can be a blessing or a curse. Many companies find ERP systems help them make better-informed decisions. Others discover too late that their purchase has been based more on faith than good judgment, and run up tens or even hundreds of millions of dollars in extra costs and schedule delays.

How, then, can senior managers ensure that their companies build a sound business case for deploying ERP systems? And what can they do to guarantee that the promised benefits are not eclipsed by the costs of integration, process redesign, and training? One answer is to take a cost-based approach to the business case. Another is to be aware of common pitfalls.

Is ERP for us?

ERP systems (made by SAP, Baan, and PeopleSoft, among others) have received much attention for their potential to help companies make more effective decisions. The plaudits are often deserved. ERP can reduce the financial reporting, purchasing, and support expenses of management information systems (MIS), and lead to more timely analysis and reporting of sales, customer, and cost data. One large pharmaceutical company has used it to consolidate manufacturing support operations such as purchasing and vendor management; as a result, it employs fewer staff and has generated a return of more than 20 percent on its capital investments. One international biotechnology company expects its ERP system to help it save more than $10 million a year on financial reporting, purchasing, and MIS support.

But for all the talk of employee productivity gains and cross-business marketing opportunities waiting to be tapped, savings can prove elusive. Hard returns, such as reduced headcount resulting from streamlined operations, are simple to predict and control, but are only part of the picture. Soft returns, such as revenue or employee productivity gains, are neither easy to predict nor under a company’s direct control. The problem is a common one in evaluating IT investments.¹

In the case of ERP systems, the length of the payback period and the size of the investment needed—in terms of both cash and human resources—make it unwise to assess a project on anything but a hard-returns basis. This is not to suggest that an ERP system cannot help a company boost revenue, or that employees cannot learn to become more productive with the aid of superior MIS. But the difficulty and expense of deploying ERP mean that most companies should appraise such an investment purely in terms of its potential to cut costs. Five steps

Building a sound, cost-based business case for ERP entails extracting the savings that depend on ERP alone from the total savings to be had from ERP together with other sources (just as you can weigh a cat by holding the cat while weighing yourself, then deducting your own weight). The process consists of five steps:

1. Create a base case of year-by-year savings from cost cuts that could be made without the ERP system in place.
2. Create an ERP case of year-by-year savings that could be made with ERP. This should include savings that do not depend on ERP (the base case of step 1) as well as those that do.
3. Subtract the base-case savings (step 1) from the ERP-case savings (step 2) on a year-by-year basis, and calculate the net present value (NPV) of the residual cashflow. A positive NPV will indicate that you should probably proceed with the deployment of ERP.
4. If step 3 produces a positive NPV, conduct a sensitivity analysis to ensure that the business case is strong enough to withstand slippage and cost overruns.
5. Back-allocate all ERP system deployment costs to individual business units so that they can factor them into their planning. Ensure each unit is held responsible for producing the promised savings.

Developing the base case

By taking the savings made and subtracting all the one-off investment costs needed to achieve them, you arrive at the net business benefits. The base-case benefits and costs may be broken down as shown in Exhibit 1. Most of the branches on this benefits tree are self-explanatory, with the exception of "avoided costs." These are the costs a business would have to incur if it were to grow at the rate forecast without using ERP. They include increases in the cost of maintaining old systems that an ERP system would have replaced and the cost of hiring extra staff to handle increased business—staff who would not be needed if an ERP system were in use.

Developing the ERP case

The ERP case can be generated by including the cost of ERP in the one-off costs of the base case (Exhibit 2). Note that in this case, avoided costs are not incurred.

Calculating net present value

After year-by-year net benefits for the base case have been subtracted from the ERP case, the next step is to calculate the NPV of the resulting benefit streams. In doing this, several broad assumptions may be made without damaging the business case:

• All cash flows are pre-tax (that is, there is no depreciation tax shelter).
• There is no residual value in hardware or software.
• Business benefit streams need to be captured only for the two years beyond the estimated completion date of the rollout. (This is because benefits are difficult to predict with any certainty beyond two years, and because cashflows get discounted rapidly and leave the impact of later years arguably small.)
• A pre-tax weighted average cost of capital can be obtained from the industry’s or company’s average pre-tax borrowing rate.

If the NPV is positive, a sensitivity analysis will ascertain how robust the result is.

Performing the sensitivity analysis

The aim of the sensitivity analysis is to "tune" the cost and benefit streams to find the point at which the NPV turns negative. Companies thinking of buying an ERP system should test sensitivity along the following lines:

Unanticipated cost overruns. It is assumed that actual implementation costs exceed estimates at a uniform rate year by year. Tuning this factor therefore entails increasing ERP costs by a constant percentage year by year until the NPV turns negative. The constant multiple (in this case a number greater than one) at which this occurs drives the "boundary value" along this dimension. The boundary value is the cost at which the NPV turns negative, or crosses a boundary. Thus, as the multiple increases, the overall cost will increase until this "crossing" occurs.

Reduced business savings. In the same way, savings are tuned downward by reducing the year-by-year benefit streams by a certain percentage until the NPV turns negative. Again, the constant multiple (in this case a positive fraction less than one) drives the boundary value.

Schedule slippage. Computing the effects of slippage is more complicated, and calls for an iterative process:

• Select a "slip value," or the number of months by which the rollout is likely to slip. The first slip value may be a guess (albeit an educated one in the case of an experienced ERP implementer). This initial value is refined as the process is repeated.
• Compute how the costs might change year by year if the project were delayed by the slip value. This can be tricky, because overall costs change in a non-linear fashion. Some costs, such as the rent paid for the implementation team’s facilities, are fixed and will be incurred regardless of slip. Others, such as the avoided costs of supporting ageing systems, actually increase when there are delays. Still others, such as per diem expenses, do not change in aggregate, since they are not incurred when no one is working on the project.
• Finally, adjust all benefits by the slip value to generate the new net benefits stream.

All three steps should be repeated until the NPV turns negative.

When the boundary conditions have been established, a "sensitivity pyramid" can be visualized within the limits of which the NPV remains positive (Exhibit 3). The value of this kind of sensitivity analysis lies in knowing that even if the deployment schedule were to slip by as much as two years, costs were to overrun by $35 million, and savings were to be only 70 percent of those forecast, the project would still be worth while. In other words, the sensitivity analysis indicates how far a company can mess up deployment and still achieve positive results.

Allocating costs and reinforcing savings targets

The final move is to back-allocate ERP costs to all business units and shared services. Unless units recognize at the outset how much they will have to pay to use the new system, they will be unlikely to appreciate how great a drain (albeit a legitimate one) on cash and human resources it will inevitably be. Fully aware, they will be able to factor the roll-out into their budget planning.

Our method requires costs to be back-allocated according to the savings each unit or shared service expects ERP to generate. If one unit believes it can streamline operations and save more through ERP than another can, then it pays more for its use. Allocating costs in proportion to forecast benefits also discourages business units from overstating potential savings. There remains the "free rider" problem of business units that understate their expected savings, although in our experience, they tend to do the opposite.

Two common pitfalls

Once a company has made a strong business case for an ERP system and subjected it to rigorous sensitivity analysis, how should the system be implemented? Companies’ ability to manage complex ERP installations varies widely, and cost overruns and slippage are common. There are two main weak spots:

• Lack of clear responsibility on the part of business units for realizing the benefits and helping manage the cost of implementation
• Lack of clear accountability to the business units on the part of managers responsible for ensuring a project’s successful completion.

Lack of clear business unit responsibility

Senior managers often do not recognize how much core business processes have to change before an ERP system can be deployed successfully. They view the rollout as an MIS activity, and as a result, the chief information officer becomes responsible for its success. This is a mistake, because the CIO is unlikely to have the clout to push through important process changes in the business units. The implementation should instead be headed by a business unit leader.

When business units lack clear responsibility for ensuring a successful ERP deployment, there is danger in store for corporations:

Business units must feel they are paying for something or they may not be motivated to track savings

They risk making poor decisions about project priorities. Since most ERP projects are capitalized, business units do not fully understand the costs they will incur once the capitalized costs begin to be depreciated. As a result, they forget to factor in resources essential to successful implementation. It is important that managers consider ERP’s resource implications as part of project planning. If they neglect to do so, they may take on too many projects that are not given enough attention.

They may not reach the savings targets they have set in the business case. Business units must feel they are paying for something, or they may not be motivated to track the savings, especially headcount reductions, that are crucial to ERP’s success.

Their business units may not feel motivated to redesign processes in the way required to extract ERP’s full value. Unit managers must see that inefficient business processes are altered, entrusting their top change leaders with ensuring that process redesign takes place.

They risk slippage if they do not have explicit contingency plans. Although business units will probably have top-level supervision of the ERP implementation, they generally exercise little day-to-day control over it. Instead, a vast amount of information about the project resides in the heads of a few individuals. Unless there is a contingency plan for coping without those individuals, business units will have little protection against serious slippage and cost overruns should they leave.

Lack of clear accountability to business units

Lack of accountability by project managers to business units manifests itself in two ways:

Frequent changes to the implementation specification. This means companies risk needlessly extending the planning cycle and delaying execution. Freezing the implementation specification early and managing to a tight schedule require strong project leadership and the backing of business unit managers. The project manager must be more than an order-taker for the business units. He or she has to take control of the scope and schedule of the deployment.

Spiraling costs. In our experience, ERP installations can exceed their budgets by 20 percent or more when checks on costs are lacking. Most deployments require the support of external systems integrators, but these consultants must be carefully managed to keep their costs under control and ensure timely deployment.

Facing up to the risks

Five steps can help mitigate the risks of ERP deployment, ensure that business units take ownership of the project, and guarantee that project managers are accountable to business units:

Ensure backing by appointing a business unit leader (and not an IT department head) to take charge of the rollout. This individual should be offered incentives tied to the project’s success (defined as the implementation of each phase on time and within budget). He or she should have the backing of other business unit heads as well as being directly accountable to them. All technical implementation staff, including external system integrators, should report to this individual.

Phase in the funding by having predetermined checkpoints for managing savings targets during the rollout. Defining these checkpoints at the outset helps maintain tight control over costs on projects of this magnitude.

Build tracking metrics into the rollout plan to enable business unit heads to monitor progress toward savings and staff-reduction targets. These targets should be incorporated into unit budgets, as should any metrics used by senior managers to monitor progress.

Develop a contingency plan to protect against dependence on a single individual, and make sure everyone knows about it. If the company has a strategy for retaining key staff, the ERP project leaders should be included in it.

Ensure that the rollout is integrated into business units’ project planning, even if it does not affect their budgets immediately. After all, costs will be allocated to the business units eventually, and managers will have to make efforts to change processes.

Implementing ERP systems successfully is fraught with risk. It calls for strong leadership, a clear implementation plan, a constant watch on the budget, and an explicit stake in the project for business units. The ability to manage operations of this complexity can be lacking, and cost overruns and slippage are all too common. Ensuring from the outset that a company has a strong business case and recognizes the most common pitfalls will go a long way toward reducing the risks.