The ERP Implementation Project: Risks and Key Success Factors

The ERP acquisition and implementation constitutes a risky project that may result in a high number of cases in unsatisfactory, if not failed, system implementations. Therefore, the understanding of ERP implementation key issues is crucial.

It has been reported that nearly three-fourths of ERP implementation projects are judged unsuccessful by the ERP implementing form (Griffith et al., 1999). Cases of failures in well-known organizations such as Boeing (Stein, 1997), FoxMeyer (Diederich, 1998), Panasonic (Zerega, 1998), or Siemens (Seidel & Stedman, 1998) have been described. More detailed reports (Booz & Allen 1999 report on ERP cited by Buckhout et al., 1999) confirm that nearly 35 percent of ERP implementation projects are cancelled, while in 55 percent of the projects, the budget has to be raised by nearly 200 percent from the expecting one, and so happens with respect to the estimated project due dates. Besides, in these cases, desired functionalities of the new system have to be cut by nearly 50 percent. The causes of failures can be classified into three big groups:

• inherent complexity of ERP implementation project

• implementation strategy

• organizational/cultural clash

These are investigated in detail in the next subsections.

Complexity of ERP Implementation Projects

One must take into account that ERP implementation projects are extremely complex projects affecting several key functional areas of the enterprise. Besides, each of these areas is affected by a process ranging from purely technological aspects such as the network and systems design to business process issues. Additionally, the team accomplishing the core of the project is external to the enterprise, although supported by the company staff. This makes handling this complexity even more difficult because both parts of the team may not share the same internal measures, company culture, or may even use different jargons.

A relatively common practice to deal with this complexity is for the ERP implementing enterprise and the consultancy company to maintain a framework of shared risks so that deviations due to budget and/or due date modifications are assumed by both parts (Bennett, 2000). Besides, the complexity may be better handled by increasing the composition of internal staff in the project. Ideally, it is estimated that the implementation team should be composed of nearly 50 percent of internal staff. Furthermore, these members should be chosen among the more experienced employees in order to give the most useful assessment to the external consultants.

Implementation Strategy

Another reason for failures in ERP implementation projects is originated by the implementation strategy adopted. In some companies, big-bang implementation strategies have been followed. In such big-bang strategies, the idea is to implement all required features and modules at once, thus reducing the overall implementation time and minimizing the transient period between the former and the new information systems (Gill, 1999). However, this approach delays the visibility of the results for a very long time (often more than one year). This can cause months of deep disruptions in several key areas of the enterprise. With the consequent lack of productivity, the expected outcome not only has not arrived, but forecasting usually indicates that implementation times and budgets were underestimated. In some cases, this leads to distrust in the overall ERP implementation project, and the result is often either trying to accelerate its end by reducing the number of features supported by the ERP system or by canceling the whole project (this happens in nearly 10 percent of the ERP implementation projects, as indicated, e.g., by Booz & Allen, 1999; Parr & Shanks, 2000).

In order to avoid or minimize the above situations, employing a phased implementation strategy is widely recommended. In this strategy, the project is divided into milestones with each one representing an ERP package module or set of related functionalities. Then, these modules or sets are implemented one by one, and the implementation of a module is not started until the previous one has been satisfactorily implemented and tested. Not all modules are of the same expected difficulty in their implementation. In contrast, some modules are expected to be more easily implemented than others, due either to the fitness of the business processes described in the module with the enterprise business processes or because there are legal rules restricting the customization process (e.g., financial accounting configuration may be, in general, of simple configuration as compared to, e.g., cost accounting). Therefore, the 'easy' modules can be scheduled first, so partial goals might be sooner achieved to inflate confidence in the overall project, and what is more important, the approach is also gradual in the complexity of the tasks. In contrast, the phased strategy results, in general, in longer visibility of the results, which in turn may cause a feeling of constant, never ending change, the loss of initial sponsorship, and usually requires the creation of temporary interfaces between new and old modules.

It is possible to increase the smoothing of the curves in the phased strategy by performing, at each module, a two-phase approach: first the module (or set of functionalities) is implemented with only the minimum customization required for the basic operation of the system with no added or updated functionalities. Once this first phase is considered finished, new functionalities are implemented or their updating is carried out.

Organizational/Cultural Clash

Throughout the literature, it is stated that the implementation of ERP systems requires disruptive organizational changes (Hammer & Stanton, 1999; Volkoff, 1999; Hong & Kim, 2002). Therefore, it is not surprising that it is claimed (Wheatley, 2000) that some 60 percent of the failed implementation experiences arise from cultural or organizational clashes. Although there are several causes for this clash, reports point at poor training as the main cause. On one hand, it may be that the hours of training have been underestimated. This can happen because it is rather usual that the training is offered by the same consultancy company performing the system configuration. Therefore, from the ERP implementing firm viewpoint, training and configuration are seen as a whole, being the most costly part of the ERP implementation project. When negotiating in order to reduce the overall bill from the consultancy company, the ERP implementing firm rarely admits a cut on the configuration project since this frequently results in the reduction of the features supported by the ERP system. Therefore, it often happens that this reduction is achieved by cutting training hours or diminishing the quality of the trainers by reducing the price per hour (so this has to be accomplished by junior consultants).

Figure 3: Big-Band vs. Phased Strategies.

On the other hand, although training may be sufficient in terms of hours or even price per hour, another source of problems for the ERP operation is focusing the training process in the technical aspects of the new information system (e.g., buttons and screens) rather than in clearly explaining the new business processes. The latter issue is very important, not only because it does not help understanding the logic of the new system but also because it does not point out to the new (and sometimes dangerous) consequences that may have some rather harmless decisions or mistakes done in the old information system (Sweat, 1998). Using an almost trivial example, consider the difference between an information system where the main decisions regarding manufacturing are manually triggered and another information system (e.g., an ERP) where such a decisions, once configured, are automatically triggered without human intervention. In the first case, mistakes produced when entering wrong data in the system (such as ordering to manufacture certain product a hundred times in excess) may be probably detected before the product is actually manufactured. However, the same mistake may be detected too late, or not detected at all, in an ERP system where such decisions are automatically triggered, and there are no employees to detect the mistake.

The solution of the poor training is obviously a higher awareness of the importance of the ERP training in the success of its implementation. It is considered that when training costs are below 10 percent of the total costs of the implementation project, then the system is at risk. Optimal figures for training costs are between 15 percent to 20 percent. Besides, training must be more focused on the system's business processes rather than on the system's screens, so the users can sufficiently understand the logic of the new system. Experiences to achieve the last issue point out that, if possible, it is useful that the staff of the ERP implementing enterprise carry out part of the training, instead of being accomplished exclusively by external consultants.

With respect to key success factors, they stem from the consideration of the ERP implementation project as a strategic project, in terms of time, costs and expected benefits. Therefore, as with any strategic project, a commitment of the enterprise with the project is required (Appleton, 1997). By doing this, many of the risks described above can be avoided or minimized. For additional information about critical success ERP factors, see, e.g., Clemons (1998), Brown and Vessey (1999), Holland and Light (1999), Sumner (1999), Markus and Tanis (2000), Parr and Shanks (2000), and Allen et al. (2002).