Academic Models

To understand the ERP implementation process models, one should first under-stand the participating stakeholders and the holistic view of the parts of the process and how these parts are connected. Wu and Wang (2007) present a simple model that presents the context of ERP implementation projects. Accord-ing to them, generally two different types of stakeholders take part in the pro-cess: an internal project team, and external contractors. Internal project team generally takes care of the requirements and needs, and the external contractors provide the system (Wu & Wang, 2007).

Figure 1 presents the stakeholders and their interactions in a simple man-ner. As it can be seen from this model, ERP external contractors usually consist of ERP vendors, third-party service providers, and consultants, which means that these three parties are often in close communication throughout the im-plementation project, and they treat the ERP system users as clients (Wu &

Wang, 2007). According to the model, ERP internal project team and ERP exter-nal contractors are communication together, and the interexter-nal project team then communicates with the user groups. Key users are the users that take part in the implementation phase as a part of project team. Key user group usually consists of employees that have a higher than average knowledge and/or expe-rience of the information systems and can give insights about the desired func-tionalities of the implemented ERP system. The internal project team consists of management (client side), MIS (Management Information Systems) staff, and key users. ERP external contractors implement the system, and users will test the functions, use the system, and give feedback and change requests. (Wu &

Wang, 2007.)

Figure 1: ERP implementation Context (Wu & Wang, 2007, 1585)

Looking at the academic models for ERP implementations, a corner stone for the studies has been a simplistic four-step model by Markus and Tanis (2000) (Vilpola, 2008). The model can be seen in Figure 2. This model consists of four phases: Project chartering, the project (configure & rollout), Shakedown, and Onward and upward. The model was created in order to give guidelines for the implementations while avoiding overemphasis on single elements such as methodologies. Goals are highlighted. The model is also created in order to be

able to trace problems to previous stages, as well as to be able to plan for the upcoming events and tasks. (Markus & Tanis, 2000.)

Chartering phase is about planning the project and choosing the ERP sys-tem, crafting a business case about it, choosing the project manager, and decid-ing the budget and schedule. This phase involves the largest amount of client-side decision making, thus making it crucial, as the client needs to have a clear business vision and they are under the risk of not understanding the needed changes in their business flows that come together with the ERP system or if there even is any need to implement an ERP system. The outcome of this phase can lead to either proceeding with the project or to disband it. (Markus & Tanis, 2000.)

The project phase focuses on physically implementing the system to unit(s) of the organization. The key tasks include everything from customizing the software according to the users’ needs to data migration (moving the legacy data to the new system) and testing the system. (Markus & Tanis, 2000.)

The shakedown phase refers to the time when the ERP system has been implemented and the client organization is trying to utilize it in its processes.

Activities during this phase include for example bug fixing, fine tuning the sys-tem, and retraining. This phase ends when the client organization reaches the stage in which it can continue its normal operations using the new system, or if the organization gives up on the system, thus failing the project. (Markus & Ta-nis, 2000.)

The last phase is called onward and upward phase. This phase spans the time when the implemented ERP system is used, until it is either upgraded or replaced with another system. The ERP external contractors may continue sup-porting the ERP service and the client organization may try to aim for continu-ous improvements in business and assess the benefits of the implementation.

The latter two tasks are usually completely external from the consultants and other knowledgeable people, meaning that these tasks are not often conducted properly. (Markus & Tanis, 2000.)

Figure 2: ERP system implementation phases (version 1) (Markus & Tanis, 2000, 189)

Two years later, a more extensive model was introduced by Rajagopal (2002). He used Kwon and Zmud’s (1987) earlier model as a basis that was orig-inally used as general means for IS implementation. This model consists of six steps instead of the original four. The steps are: Initiation, adoption, adaptation, acceptance, routinization, and infusion. The purpose of this model is to adapt the phases of general IS implementation to the ERP implementation, while pointing out the differences and idiosyncrasies of the ERP systems implementa-tion.

Looking at the model from the perspective of the initial model by Markus and Tanis (2000), initiation step can be seen as very similar to project chartering as these both are about distinguishing requirements and needs of the company and the ERP system. However, the adoption step is separate, and it includes parts from the original project chartering phase. According to Rajagopal (2002), adoption phase includes investment decisions and initial cost-benefit analysis.

The following step, adaptation, is where the implementation itself begins and it can be viewed as similar to the project in the earlier model. The difference is that Rajagopal (2002) emphasizes the need for business process re-engineering (modifying business flows in order to utilize the new ERP system in full potential) and change management which were not paid much attention to in the initial model. Also, training phase is initiated in the adaption phase which was originally separately in the shakedown phase. (Rajagopal, 2002.)

In the acceptance step, customization is made to the ERP system according to the users’ needs. According to Rajagopal (2002), benefits can already be measured here even though changes are still being made to the system. This is in conflict with the original model, as Markus and Tanis (2000) state that the measurements can only be made in the support phase (onward and upward phase). The acceptance step’s main focus is to optimize the system to the users, but it also includes additional training (Rajagopal, 2002).

In the routinization step the system usage becomes a routine. What is left for the vendors and consultants to do is to correct bugs and give continuous support that are similar to the onward and upward phase of the original model.

The benefit observations also continue. (Rajagopal, 2002.)

The final step is infusion. In this step the organization will already look forward to the next investment and continuously analyze if the current system is still feasible to the operational use. Infusion step can thus be connected again to the first step, initiation, making the implementation process a full cycle. The ERP implementation process model by Rajagopal (2002) can be seen in Figure 3.

Figure 3: ERP system implementation phases (version 2) (Rajagopal, 2002, 92)

After these two models, the literature started focusing more concretely to the steps specific to the ERP implementation context. Looking at these two models, the steps appear as very abstract and that there was still yet to be standardized phases during the ERP projects at the time of these studies, even though these two reported similar tasks throughout the stages of the models.

Ehie and Madsen (2005) made a solid presentation of an ERP system im-plementation model that captures the stages and tasks that are mentioned in the literature and captured with extensive interviews of professionals. They divide ERP implementation into five stages, each stage containing sub-stages and tasks specific to the ERP implementation context. The five stages are: project prepara-tion, business blueprint, realizaprepara-tion, final preparaprepara-tion, and go live & support.

The stages and sub-stages are presented in Figure 4. The model was created in order to handle CSFs, and to pinpoint them to specific areas of ERP implemen-tation and to visualize the flows of these projects.

Figure 4: ERP system implementation phases (version 3) (Ehie & Madsen, 2005, 549)

Ehie and Madsen (2005, 548) stress that: “It is crucial that management conduct a review at the end of each stage to make sure everyone agrees on its outcome before moving on to the next stage”, which highlights the complex and sensitive nature of ERP implementation projects. As it can be seen from figure 4, each stage of implementation contains multiple sub-stages. Sub-stage pairs 5a &

5b, 6a & 6b, and 7a & 7b happen simultaneously, each sub-stage benefitting its pair (Ehie & Madsen, 2005). Regarding the stages and sub-stages, this model does present a clear roadmap when planning specifically ERP implementations.

However, it is arguable if the creation of a detailed project plan is a feasible task before deciding on the ERP system that will be implemented, or should it be moved to the business blueprint phase, as the projects may have differences

depending on the system. Also, the partners may vary and require different type of planning.

Project preparation is dedicated to extensive planning and budget targets are created along with the project plan. The blueprint phase focuses on analyz-ing the business flows and processes to prepare for the implementation. Project management is highlighted to be an especially important factor during this phase. Technical foundation is developed during the realization phase. Testing is also conducted simultaneously. In final preparation, the new system is tested under normal and extreme working conditions, meaning that full data load and multiple risk scenarios are tested. Training is conducted during this phase. In go live & support phase the system is enabled for operational use and addition-al fixes and improvements are made to the system. (Ehie & Madsen, 2005.)

As it can be seen from the model, change management and business de-velopment can be viewed to encompass the entirety of the project from start to finish, which means that business development and change management should not be simply tied to specific stages like education, but to continuously drive them throughout the project.

As a general note to the implementation process models, even though it is not visible in the figures, there are two types of go-live: phased, and big bang.

Phased implementation means that go-live either happens with a limited num-ber of modules and/or in a limited amount of offices of the company. Big bang refers to a method in which all the modules are carried out in a limited number of offices/all offices at the same time. In the recent years, phased implementa-tions have been the strong majority, as the large scale of projects has made big bang generally unfeasible (Nagpal, Khatri & Kumar, 2015.)

After this final presented model, there have not been any substantial changes in the academic literature regarding ERP implementation models, meaning that some level of maturity has been reached within the topic (Nagpal, Khatri & Kumar, 2015). Scholars keep researching issues in the ERP implemen-tation projects but even though some of the stages receive revamping and new points of view are presented, the stages and sub-stages remain mostly the same.

A question remains if the recent arrivals of cloud-based ERP systems will offset a change in the ERP implementation literature. Also, agile way of thinking has made its way to the modern ERP system literature and is one of the more recent topics in the area (Nagpal, Khatri & Kumar, 2015)