ERP Systems & Critical Success Factors

Get Complete Project Material File(s) Now! »

Theoretical Framework of Reference

In this chapter, the authors will present the relevant theories to the purpose of the research. The first part fo-cus on the concepts change management. The second part focus on enterprise resource planning systems & associated critical success factors, and the third part will focus on benefits management & key performance indicators.

Change Management

The change problem inside organizations would become less worrisome if the business environment would soon stabilize or at least slow down. But most credible evidence suggests the opposite: that the rate of envi-ronmental movement will increase and that pressures on organizations to transform themselves will grow over the next few decades –John P. Kotter, 1996
The Change Management chapter will cover the concept of change management/leadership and project management/leadership and how they affect large scale change projects within organizations.

Change Leadership

The theory and practice of change management suggests that while incremental change re-quires significant management skill to monitor and evaluate the existing business perfor-mance, it is suggested by author John P Kotter (1996) that while management is essential, what is really needed in transformational change is leadership.
”Management is a set of processes that can keep a complicated system of people and technology running smoothly. The most important aspects of management include planning, budgeting, organizing, staffing, con-trolling and problem solving. Leadership is a set of processes that creates organizations in the first place or adapts them to significantly changing circumstances. Leadership defines what the future should look like, aligns people with that vision, and inspires them to make it happen despite the obstacles.”
– John P Kotter, 1996
According to Roger Gill (2003) the reasons change programs often fail is because of poor management; poor planning, monitoring and control, lack of resources and know-how, and incompatible corporate policies and practices. The reasons for these shortcomings may vary from organization to organization as the condition for change remains unique in each case as it involves human activity systems as well as hard technological systems. However, there are suggestions on what is necessary for a successful organization change, one being the need of a leader steering the change.
Kotter (1996) describes an eight step approach in his book, Leading Change:
1. Establish a sense of urgency: Kotter (1996) advocates that for change to happen it is important that you create a sense of urgency in order for everyone to feel that a change is needed. This might help to raise the motivation to change.
2. Creating the guiding coalition: It is important to have strong leadership that can convince people and guide the change. Kotter (1996) recommends that you identify key people in the organization that will act as leaders in the change project, continuing to build on the urgency for change.
3. Developing a vision and a strategy: Kotter (1996) argues that a clear and concise change vision that is easily understood by the employees needs to be developed. A strategy for how this vision will be attained must also be developed.
4. Communicating the change vision: The change vision and the strategy for achieving it needs to be communicated to the employees (Kotter, 1996). This will result in more people buying in to it and accepting the change. It should be kept fresh in everyone’s mind.
5. Empowering broad-based action: In the fifth step, employees should be empowered to act on the change vision and remove obstacles that are hindering the change project (Kotter, 1996). A structure for change should be developed.
6. Generating short-term wins: Success is a motivational factor. It is therefore im-portant that short-term wins are generated to show the employees results of the change project (Kotter, 1996). People opposing the change might damage the progress if no results are presented.
7. Consolidating gains and producing more change: Kotter (1996) state that in many cases, victory is declared too early and this is the reason for their failure. It is important to continue building on the change and not become complacent.
8. Anchoring new approaches in the culture: Kotter (1996) points out that it is im-portant to make the change stick making it a part of the organization’s core. Continu-ous efforts should be made to ensure that change is present in the organization.
The steps presented by Kotter have also been identified by other authors which suggests towards a consensus of what requirements are needed during a transformational change process. Similar to Kotter, Covey (1992) suggests that:
”Without strategies for change, vision is a dream. Strategies are ways of pursuing the vision and mission; they are informed by vision, mission and values. Strategic plans are ’road maps’ for changing terrain where a compass (vision) is needed.” – Covey, 1992
In his article from 2003, Roger Gill lists two more authors (Eden & George) discussing the need for creating a clear vision and getting commitment for the change that is identified. This also incorporates creating a strategy to successfully fulfill the change as well. Accord-ing to Gill (2003) author Colin Eden suggests in his work from 1993 (Strategy Development and Implementation: Cognitive mapping for group support) that:
”A key issue with the effectiveness of strategies is where their ownership lies and commitment to them: effec-tive strategy development taps the wisdom of people in the organization”
together with a quotation from William W. George (Gill, 2003) in his article from 2001;
”Employees can adapt to major strategic shifts as long as the company’s mission and values remain con-stant”
presents examples of how change leadership differs significantly from change management. Instead of focusing on performance measures solely for improvement, there is a need to take the initial change need discovery one step further. When a change need is discovered during the incremental improvement cycles, it may be qualified as game changing e.g. fine tuning the machinery no longer works, deeper change is required. When such a thing hap-pens, a different approach is needed. The authors listed above suggest that there is a strong need for developing a vision of what needs to be done. Furthermore this vision needs sup-port. Compared to incremental change, transformational change may be of a volatile nature and be very costly for an organization in terms of resources (human capital, time and/or money). The transformational change may also be unknown, meaning, the effect may not be as clear as with incremental change as there are more factors that has to be measured. Before a transformational change can occur, there is a strong need to evaluate the need for change and what nature it incorporates.

Diagnosing the Need for Change

The business analysis and diagnosing the organization has been touched upon in previous chapters regarding different approaches to quality management e.g. Six Sigma or TQM. Us-ing those methods, the result usually results in a reduction of waste. If, however, the analy-sis of the business suggests that there is neither a need for efficiency improvement nor in-novation, as discussed by Strebel in his cycle of competitive behavior (Hayes, 2007), there might be a different need for the organization to use a different approach towards im-provement. Firstly it is important to evaluate the nature of the change need. This can be done by applying different models and or methods to capture the existing domain, such as PESTLE (Political, Economical, Societal, Technological, Legal and Environmental) or SWOT (Strengths, Weaknesses, Opportunities and Threats) which analysis the business from an external vs. internal fit perspective. Another approach is suggested by Kotter and his Integrative model of organizational dynamics (Hayes, 2007). Kotter suggests that it is important to understand each main part of an organization and how they affect the key organizational processes, see Figure 6 – Integrative Model of Organizational Dynamics below:
According to Hayes (2007), a change project involving an ERP system would then be con-sidered more of a transformational change project by nature since the project affects the organization on a deep scale, both adapting to existing processes, but also bending process-es around it. Therefore we suggests that when evaluating a need for change in terms of ERP systems, there is a strong need to evaluate it from a perspective that suggests deep change within an organization. Burke and Litwin offer a complementary model further ex-plaining the organizational change domain Figure 7- The Transformational factors (Hayes, 2007):
A transformational change involves the mentioned parts above and will affect the deeper structure of the organization. Although that being said, the change may bring incremental changes as well since the target still is improvement, however processes already established requires to be evaluated to understand what system solution is necessary, if any, and what processes should remain and let the ERP solution be tailored around them, and vice versa.

Business Process Analysis & Enterprise Modeling

According to Ward & Peppard (2002): ”business process analysis is a technique for assessing the ef-fectiveness of core business processes in support of business objectives and drivers from one or a number of SBUs (Strategic Business Unit), or from specific business areas within an SBU”
The need for conducting a business process analysis predicates the understanding how the change need identified will affect the current situation on both macro and micro level. When the change need has been specified, an organization has to focus on understanding how the current situation actually is. The analysis will typically adopt a AS-IS approach which, suggested by authors such as John P. Kotter (Ward & Peppard, 2002), emphasizes on a modeling process that will try to capture different elements that has been deemed as important.
In Figure 6 – Integrative Model of Organizational Dynamics (Hayes, 2007), Kotter’s model sug-gests what components are important in understanding the business situation. Similar to Kotter (1996) and Bubenko Jr, Persson & Stirna (2001) suggests a modeling approach cap-turing; processes, actors & resources, technical components, business rules, important concepts & their rela-tions and goals & problems. The specific name of the modeling method was Enterprise Knowledge Modeling (EKD) (Bubenko Jr, 2001).
The purpose of using modeling as a tool for identifying the existing processes fuels the vi-sion in clarifying why a change might be needed in an organization. Suggested by Kotter (1996) in his steps 3-5, there is a need to create a strategy, communicate it together with the vision and empower different actors within the organization. Rather than using an abstract vision, the company could then involve influential/knowledgeable employees in capturing the organization through modeling workshops. This would as Kotter suggest (1996) em-power employees to participate in the change work and as suggested by Bubenko Jr, et al, (2001) support the creation of a shared understanding of the current business.
The end product would then display a current, AS-IS scenario, and a future, TO-BE sce-nario. The difference between these two scenarios is commonly called a GAP, and the pro-cesses of understanding how to bridge them, a GAP analysis. (2012) offers this simple definition of GAP analysis:
”A technique for determining the steps to be taken in moving from a current state to a desired future-state”–, (2012)
According to Ward & Peppard (2002), the assessment of business processes and organiza-tional conditions should then provide an understanding of how the current processes and components (actors and resources) are meeting the business objectives and drivers. The goal is to understand where the greatest opportunities of improvement exist in terms of meeting and improving the business objectives and drivers.

Change Agents & Roles

During the ERP project there is a demand for different roles to structure the different stages and make sure that someone owns specific tasks, making them responsible.
One change agent already identified is the leader of the change. Weick & Quinn (1999) suggests that the leader has the role of the prime mover, whom is the one responsible for creating change. In the eight step model by Kotter (1996) it is further elaborated that the change leader is involved with aspects such as creating a vision, gathering and involving a strong guiding coalition consisting of influential individuals such as the CEO or senior management, communicating the change vision and empowering other employees. This is further linked to Weick & Quinn (1999) as Kotter (1996) describes the need for a leader that not only leads the change, but also to live and breathe the change.
While the role of the leader is significant in rallying employees to the cause, there are sever-al other roles of equal important as well. In the article by Eisenbach et al (1999) the role of the manager is discussed in terms of how they can support the leader in structuring the change and how their involvement impact on the environment targeted for change. Eisen-bach et al (1999) quotes findings from Brown & Eisenhardts publication from 1997, where they suggest that three characteristics of the manager helped in successful change. The first attribute was the successful delegation of work, i.e. clarifying roles and responsibilities and then extensively communicating this through the organization. This led to a more open en-vironment with freedom for change rather than creating inertia. The second attribute was supporting the study of the future, testing new procedures or brainstorming for new ideas. Thirdly, and very importantly, these managers supported the linking of current project with the future.

Anchoring the Change

Towards the end of the project and when milestones have been reached, it is according to Kotter (1996) very important that the change that has been made up until that point is rein-forced into the organization. While Kotter (1996) discusses the need for celebrating wins as one of the important change steps, the organization may not receive any benefits intended until the changes are in place. Kotter (1996) therefore suggests that the combination of cel-ebrating short term victories is a stepping board in make what has been changed into a part of the organization. It is also through these shorter wins that the bigger change can be bro-ken into smaller pieces which are easier for the organization to adapt to and anchoring it in a smooth way rather than focusing on completing the whole task at once.

ERP Systems & Critical Success Factors

The Enterprise Resource Planning & Critical Success Factors chapter will cover the concept of en-terprise resource planning system implementation approaches, a set of development methods and Critical Success Factors in ERP projects.

Implementation Approach

Implementing an ERP system is very challenging even without taking the current business processes into consideration and the changes needed to those processes based on the func-tionality of the new system. Motiwalla and Thompson (2009) stress the fact that if the cur-rent business processes are not analyzed and compared with the functions of the new sys-tem, it is quite possible that several significant modifications to the ERP system will be re-quired after it has been implemented. It is therefore important that a decision is made re-garding the number of modifications that should be made to the ERP system. An ERP sys-tems implementation with a significant amount of modifications to it can increase the suc-cess with the users since it has been tailored according to the users’ requirements, but many modifications increase the investment in the ERP system and also results in a higher im-plementation risk (Motiwalla and Thompson, 2009). These modifications must also be ad-dressed for every system upgrade, which will result in a more expensive system in the end. According to Motiwalla and Thompson (2009) most purchased ERP systems today are minimally modified in order to protect the investment. This approach requires the compa-ny to realign their business processes according to the ERP system in order for it to work properly (Motiwalla and Thompson, 2009).
Anderson et al. (2011) discuss that there are two ways of approaching the implementation of an ERP system, either to do the implementation quickly or to implement the ERP sys-tem specially customized to the organization. The quicker approach is a technology-driven approach while the slower (traditional) implementation adopts a strategy to redesign pro-cesses, technology, and to change people. The slower traditional implementation puts the emphasis on mapping the current situation (AS-IS) and how it should be when the ERP has been implemented (TO-BE). A large amount of time is spent to make the organization and the ERP implementation unique from its competitors in order to obtain a competitive advantage (Anderson et al., 2011).


Development Approach

Development during an ERP project can be approached from different perspectives. If the system is to be developed from scratch, one of the most common and traditional ap-proaches are the Information Systems Development Life Cycle (SDLC), sometimes also re-ferred to as the Waterfall approach (Avison & Fitzgerald, 2006). Even though there are many versions of the SDLC the most basic structure consist of the following six stages; Feasibility study, Systems investigation, Systems analysis, Systems design, Implementation, and Review and Maintenance. An alternative to the more traditional SDLC is agile software development methods, which were development and became popular as a result of the requests for speeding up the software development process (Avison & Fitzgerald, 2006). Cohen et al. (2003) have also identified that many customers are unable to specify their exact needs at the start of a project while they at the same time have higher expectations on the software. It is not uncommon those new user requirements arise during the project and that existing requirements are changed, which results in a halt in the project in order to accommodate the new changes (Cohen et al., 2003). This is where an agile method will be an efficient choice for developing the software since the core foundation of agile methods is, according to Highsmith et al. (2000), to:
“Deliver quickly. Change quickly. Change often”
There are several different agile methods, e.g. Extreme Programming and Scrum, and though they differ in practices and emphasis, they share characteristics such as; iterative de-velopment and a focus on interaction, communication, and reducing resource intensive ar-tifacts (Cohen et al., 2003). The iterative development allows for the development team to respond and adapt to changing requirements faster.

Critical Success Factors in ERP implementations

Implementing an ERP system is an expensive task that is far from free of risk. According to Umble et al. (2003) 65% of executives believe that an ERP system has a chance of dam-aging their business because of the potential problems associated with the implementation. Therefore, it is of interest to identify the factors that will make the implementation a suc-cess. Umble et al. (2003) have identified the most apparent of these.
Clear Understanding of Strategic Goals: It is vital that everyone involved in the project has a clear understanding regarding the strategic goals. This means that there must be clear definitions of the goals, expectations, and what is to be delivered. Umble et al. (2003) states that: “ERP implementations require that key people throughout the organization create a clear, compelling vision of how the company should operate in order to satisfy customers, empower employees, and facilitate suppliers for the next three to five years.” It is also important that an explanation of why the ERP system is being implemented and which critical business needs it will fulfill (Umble et al., 2003).
Top Management commitment: For any project to be successful it requires strong lead-ership, commitment, and participation from top management. Umble et al. (2003) are of the opinion that:
“Since executive level input is critical when analyzing and rethinking existing business processes, the imple-mentation project should have an executive management planning committee that is committed to enterprise integration, understands ERP, fully supports the costs, demands payback, and champions the project.”
Excellent Project Management: An ERP implementation is a vast and complicated pro-ject. It is therefore important that the organization engage in excellent project management (Umble et al., 2003). This involves several parts such as a clear definition of the objectives, development of both a resource plan and work plan. It also includes careful tracking of the project’s progress. Umble et al. (2003) point out that these tasks along with the project plan should be made achievable but at the same time scheduled in a way to maintain a sense of urgency. Umble et al. (2003) also point out the importance defining the project objectives in a clear way in order to help eliminating scope creep, which is the term for uncontrolled changes or continues growth to a project’s scope.
Organizational Change Management: According to Umble et al. (2003) the existing or-ganizational structure and processes are not compatible with the structure, tools, and types of information provided by the new ERP system. Even the most flexible ERP systems have its own logic that affects the implementing company’s strategy, organization, and cul-ture. It is therefore crucial that during an implementation the company adopts change management practices in order to reengineer the key business processes to support the new ERP system and the organizational goals. Umble et al. (2003) have also identified that many executives view ERP as only a software system and that the implementation of it is primarily a technological challenge, which, according to Cohen (2003), is wrong. Motiwalla and Thompson (2009) also identify Change Management as a critical success fac-tor and discuss that it is natural for people to resist change.
Great Implementation Team: Umble et al. (2003) discuss the importance of the imple-mentation team and stress that the team should consist of top-notch people who are cho-sen for their skills, reputation, past accomplishments, and flexibility. Motiwalla and Thompson (2009) agree with this and have also identified the implementation team as a critical success factor. The implementation team has an important role to play since it is responsible for creating the detailed project plan or overall schedule for the entire project, assigning responsibilities for various activities and determining due dates, and also make sure that the needed resources are available (Umble et al., 2003).
Data Accuracy: Umble et al. (2003) stress the importance of accurate data for the ERP system to work properly:
“Because of the integrated nature of ERP, if someone enters the wrong data, the mistake can have a nega-tive domino effect throughout the entire enterprise. Therefore, educating users on the importance of data accu-racy and correct data entry procedures should be a top priority in an ERP implementation.”
It is also crucial to make sure that everyone in the organization works with the system and not around it. Umble et al. (2003) states that the employees must be convinced that the or-ganization is committed to using the new system and are planning to eliminate the old. Running the two systems in parallel for too long will result in employees continuing to use the old system instead of the new one.
Education and Training: This is one of the most important factors deciding whether a project will be successful or not since user understanding and acceptance is essential. Um-ble et al. (2003) mention the importance of teaching user to solve problems within the framework of the system. The end user training should also start as soon as possible in or-der for the result to be as good as possible. According to Umble et al. (2003) many execu-tives underestimate the level of education and training that is needed and also state that:
“Top management must be fully committed to spend adequate money on education and end user training and incorporate it as part of the ERP budget.”
Umble et al. (2003) also state that training should still be carried out after the implementa-tion has been finished.
Focused Performance Measures: According to Umble et al. (2003) performance measures that assess the impact of the new system must be carefully constructed to make sure that they really indicate how the system is performing. Project evaluation measures should also be included from the beginning and if the system implementation is not tied to compensation and bonuses, it will not end in success. Umble et al. (2003) state that if man-agers still receive their bonuses even if the system is not implemented it is less likely that the implementation will be successful. According to Umble et al. (2003):
“Management and other employees often assume that performance will begin to improve as soon as the ERP system becomes operational. Instead, because the new system is complex and difficult to master, organiza-tions must be prepared for the possibility of an initial decline in productivity.”

Benefit Management

The Benefit Management chapter will cover theories and methods such as: Benefit Management & Best Practice Guidelines.

Benefit Management & Best Practice Guidelines

“Once of the factors that differentiates successful from less successful companies in their deployment of IS/IT, according to a number of surveys, is the management resolve to evaluate IS/IT investments before and after they occurred” – Ward & Peppard, 2002
Presenting findings that suggests that only 26% out of 60 investigated organizations review projects after their completion, and 45% admitting that benefits had been exaggerated to gain project approval, Ward & Peppard (2002) discuss the area of benefit management in IS/IT investments. According to Ward & Peppard (2002) a problem with benefit manage-ment lies in how it is applied. 76% of the investigated 60 organizations perceived an oppor-tunity to become better in managing benefits in projects, but only 10% presented defined processes it (Ward & Peppard, 2002).
It is further suggested by Ward & Peppard (2002) that the benefit management process is a big part in an investment project, not just in the initial investment appraisal, and should more or less be combined with the change management part of the project, turning the project into an organizational change project rather than a IS/IT project. Ward & Peppard (2002) suggests that by integrating the benefit management process into the whole project, making it more complex, the value of the project can increase. Important questions to start with are (Ward & Peppard, 2002):
“Why is the investment being made – what is causing the organization to change and how critical to its fu-ture is the successful management of the changes? (Benefit drivers)” – (Ward & Peppard, 2002)
“What types of benefits is the organization expecting from the investment overall – to reduce costs, improve operational performance, gain new customers, create a new capability, etc? These need to be understood in general terms before detailed analysis of potential benefits in relation to the extent of change requires is un-dertaken.” – (Ward & Peppard, 2002)
“How will other activities, strategic initiatives, business developments, or organizational issues affect the particular investment either to facilitate or inhibit its progress and outcome? (The organizational context)” – (Ward & Peppard, 2002)
Ward & Peppard (2002) also offers a model which tries to capture the domain of benefit management, which can be seen in Appendix 4; Figure 10 – Benefits Management Context.
To work with the why, what and how questions in the identified benefit management domain and to integrate the benefit management process into the whole project process, Ward & Peppard (2002) offers a set of best practice guidelines and an overall model of the benefit man-agement model can be seen in Appendix 4; Figure 11 – A Process Model of Benefit Management (Ward & Peppard, 2002) Stage 1 Identification and Structuring of Benefits: In stage one the investment process is taken one step further and the process of identifying and structuring benefits is under-taken. Based on the initial strategic evaluation of why, what and how a rationale can be made regarding the intended investment, is it strategic, high potential, support or key operational (see Appendix 4; Figure 9 – Generic Source of Benefit for Different Applications, Ward & Peppard, 2002). If the projects benefits are deemed to be high potential and a bit unclear, there may be a need for processing it through further R&D to make them better known. By structuring the benefits, an understanding of how the benefits affect the organization is obtained and even more benefits can be discovered. It is however, important to link all the benefits back to the initial benefit drivers discovered in the initial strategic why process. With benefits identi-fied, it is then important to make them as measureable and tangible as possible, even though some are harder than others to measure. Preferably they should also be quantifia-ble. In the end of this stage, benefits owners are assigned to each benefit to make sure that at least one individual is responsible for realizing each benefit (Ward & Peppard, 2002).
Stage 2 Planning Benefits Realization:
With the benefits identified and structured, as well as individuals assigned to them, the next stage is planning the realization stage. In this stage the output, or goal, is a benefit de-pendency network, stakeholder analysis and an investment proposal. According to Ward & Peppard (2002), the dependency network will generate a cause-effect schema with identified changes required for intended benefits. An example of a benefit dependency network can be found in Appendix 4; Figure 12 – Example of (part of) benefits dependency network – sales and marketing system (Ward & Peppard, 2002).
It is further suggested that this is done in workshops in iterative steps so that the feasibility can be evaluated and questioned. The changes necessary can, according to Ward & Pep-pard (2002), be one of two types;
Business changes: are changes that affect processes and practices within the organization. They can usually not be done before enabling changes has been carried out or before the new systems is available (Ward & Peppard, 2002).
Enabling changes: are changes that involve defining and agreeing upon new work practices, redesigning processes, changes to job roles and responsibilities etc. (Ward & Peppard, 2002). Enabling changes are often seen as essential for bringing in the new system into ef-fective operation and can often be made in conjunction with the project and before the new system (Ward & Peppard, 2002).

Table of Contents
1 Introduction to Value Realization in ERP projects
1.1 Background
1.2 Problem
1.3 Purpose
1.4 Important Concepts
1.5 Research Questions
1.5.1 Delimitations
2 Method
2.1 Research Approach
2.2 Method for Analysis & Handling of Data
2.3 Research Ethics
2.4 Application of Behavioral Science & Design Science
2.5 Credibility
3 Theoretical Framework of Reference
3.1 Change Management
3.2 ERP Systems & Critical Success Factors
3.3 Benefit Management
4 Empirical Study
4.1 Company A
4.2 Company B
4.3 Company C
4.4 Company D
5 Empirical Findings
5.1 Interview Question 1
5.2 Interview Question 2
5.3 Interview Question 3
5.4 Interview Question 4
5.5 Interview Question 5
5.6 Interview Question 6
5.7 Extra Question
6 Analysis
6.1 Analysis of Research Question 1
6.2 Analysis of Research Question 2
6.3 Summary of Analysis: RQ1 & RQ2
7 Toolbox Artifact
7.1 Toolbox Artifact
7.2 Critical Assessment of the Toolbox Model
8 Conclusion
8.1 Theoretical Contributions
8.2 Managerial Contributions
9 Final Reflection and Future Research
9.1 Reflections on the Research Project & Results
9.2 Future Research
List of references

Related Posts