“Every time I find the meaning of life, they change it”

Understanding the impact of a Change Management methodology to address and reduce resistance in an ERP adoption process

Business Administration, Bachelor Thesis Atlantis Program

Linköping University Spring Semester 2009

Authors

Hervé, Sandrine Wallisson, Calle

Tutor – Dr. Emeric Solymossy

2

Abstract

Bachelor Thesis in Business Administration, 15 ECTS

Linköping University, Department of Management and Engineering (IEI), Spring 2009

Management

Authors: Sandrine Hervé and Calle Wallisson

Tutor: Dr. Emeric Solymossy

Title “Every time I find the meaning of life, they change it” : Understanding the impact of a Change Management methodology to address and reduce resistance in an ERP adoption process

Keywords Change Management, ERP (Enterprise Resource Planning), resistance, stakeholders, communication, leadership

Background and problem discussion

ERP has become a system used by most companies to integrate their processes and increase efficiency, however, many ERP implementations fail and we wanted to understand what aspects of ERP made it so difficult to implement. Change Management, and especially theories to identify and reduce user resistance caught our attention.

Purpose Increase awareness of the benefits of developing a Change Management methodology in parallel with an Enterprise Resource Planning (ERP) system adoption in order to address and reduce resistance to change.

Theoretical framework

We used mostly Change Management theory and facts about ERP implementations coming from critically reviewed sources.

Methodology

This study is based on literature but also on a case study and additional interviews with experts to identify the extent of a Change Management methodology´s use in practice in organizations. We used a deductive approach and a qualitative method to collect our data.

Case study and additional interviews

The case study took place in a single organization where we interviewed five persons internally and an external consultant to obtain their views on their ERP implementation. This case study intends to help understand the impact of the system on individuals and observing if a specific methodology was used to implement it. We also interviewed 9 experts, both in Change Management and/or ERP who gave us their insight on ERP challenges.

Conclusion

- A main reason for resisting change has its roots in a lack of understanding of the impact the new system will have on the end users´ work

- Identifying all stakeholders and knowing what their interest are and what they can do to help to trigger their involvement

- Identifying and knowing the current business processes to effectively set the expectations with the ERP vendor

- The need for communication and leadership throughout the process to transmit the vision, empower, motivate and align people

3

Acknowledgments

First of all, we would like to thank our tutor, Dr. Emeric Solymossy, for his guidance and advice throughout this thesis. His comments, suggestions of literature, and critical review of our work helped us stay on the right track and learn.

Our thanks go to Richard McAndrew, our former professor of ISM (Information Systems Management) at ECE Lyon, for his guidance and expertise. His lectures triggered our interest for our topic of research and his early advice confirmed this interest.

We would also like to mention Daniela Rausch at HansaWorld who has been of great help throughout our work. She helped us obtain interviews for our case study and also accepted to answer our numerous questions. We are very grateful for her dedication.

Thank you for the time taken by Christina Axelsson, Christine Müller, Helene Hagberg, Ann Sofie Andersson and Agneta Larsson to answer our questions in a very interesting and enjoyable collective interview at Mercodia.

We would like to thank the experts we talked to for their valuable insight for this research.

Moreover, we would like to give our thanks to Dr. Peter Gustavsson for his help in the early stages of this thesis and for his time and precious advice.

Finally, thank you to our classmates who have given us extremely valuable feedback, their help was really appreciated.

We wish our readers a pleasant time reading this thesis.

Sandrine Hervé and Calle Wallisson, May 30th, Linköping

4

Table of Contents

I. Introduction ............................................................................................................................................. 6

A) Background ..................................................................................................................................... 6

1. Information system adoption: an organizational challenge ............................................................ 7

2. Enterprise Resource Planning: a one-of-a kind information system............................................... 8

3. Resistance: a natural response to change ........................................................................................ 9

4. Change Management as a way to deal with the “people´s side of change” .................................. 10

B) Purpose ......................................................................................................................................... 11

C) Problem statement ........................................................................................................................ 11

D) Scope ............................................................................................................................................ 11

E) Practical Value .................................................................................................................................. 12

II. Theoretical Framework ......................................................................................................................... 13

A) Introduction .................................................................................................................................. 13

B) Characteristics of ERP systems .................................................................................................... 13

1. Opportunities and risks for organizations ..................................................................................... 13

2. ERP and Business Process Reengineering.................................................................................... 16

3. A need for end-user involvement ................................................................................................. 18

C) Change Management: a way to reduce resistance ........................................................................ 20

1. Resistance: a common response to change ................................................................................... 21

2. Different types of resistance ......................................................................................................... 24

3. How can resistance be addressed? ................................................................................................ 26

D) Facilitating change: identifying stakeholders, communicating and leading the change ............... 30

1. The importance of stakeholder identification ............................................................................... 30

2. Communication: an important but difficult tool to master ........................................................... 32

3. The need for leadership in times of change .................................................................................. 35

E) What have we learned? ..................................................................................................................... 39

III. Research Methodology ..................................................................................................................... 41

A) Our philosophical perspective ...................................................................................................... 41

B) Our methodological approach....................................................................................................... 42

C) Techniques of collecting data ....................................................................................................... 43

1. Secondary sources ........................................................................................................................ 43

2. Primary sources ............................................................................................................................ 43

D) Ethical considerations ................................................................................................................... 46

IV. Empirical data ................................................................................................................................... 48

5

A) Introduction .................................................................................................................................. 48

B) A case study at Mercodia .............................................................................................................. 48

C) What counts in an ERP adoption process ..................................................................................... 54

1. Identifying and assessing the importance of the stakeholders in the ERP adoption process ........ 54

2. ERP as a challenging adoption process ........................................................................................ 56

3. Reasons for resisting, ways of resisting, and how can it be reduced? .......................................... 58

4. Aspects of organizational change that leaders tend to underestimate ........................................... 63

5. A particular issue: training ........................................................................................................... 64

6. Change Management and its use today: do companies effectively manage change? ................... 66

7. One single advice for CEOs implementing ERP .......................................................................... 66

V. Analysis and discussion ........................................................................................................................ 68

A) Introduction .................................................................................................................................. 68

B) Resistance as a lack of understanding .......................................................................................... 68

C) Stakeholders as a partnership in an ERP adoption process ........................................................... 70

The project team, but not alone ............................................................................................................. 70

The consultant on the vendor´s side ...................................................................................................... 71

Sponsors ................................................................................................................................................ 71

The end users ........................................................................................................................................ 72

The rest of the organization .................................................................................................................. 72

The system administrator ...................................................................................................................... 72

D) A change management methodology in an ERP adoption process ................................................... 76

Acknowledging every stakeholder´s needs and competencies.............................................................. 76

Having a clear vision and people who will support this vision ............................................................. 77

Understanding that identifying current business processes will facilitate the change process ............. 77

Setting the expectations: a two-way process ......................................................................................... 79

Training and testing .............................................................................................................................. 79

Going live is not the end of the journey ................................................................................................ 80

VI. Conclusions and recommendations................................................................................................... 82

A) Conclusions .................................................................................................................................. 82

B) Recommendations on continued work .......................................................................................... 83

VII. Bibliography ..................................................................................................................................... 84

Books ........................................................................................................................................................ 84

Printed articles ........................................................................................................................................... 85

Online articles ........................................................................................................................................... 85

Websites .................................................................................................................................................... 86

6

I. Introduction

In order to introduce our readers to our area of focus, we will first explain what motivated our choice of research in a personal way, before giving more details and a clear definition of the field of research. This explanation and definitions of important terms and issues is a first step that will lead to our purpose and research questions. We also clearly delimitate our area of interest and the practical value this research has, that is to say, to whom it can be of interest.

A) Background

We both had been working with Microsoft Office 2003 for a couple of years, and felt quite comfortable and confident in our skills with that software. However, one day, we heard about this new and fantastic updated version called Microsoft Office 2007 and we got so thrilled about it… until we actually started using it! Then, we realized that not only the design was new but the applications had changed also. All of the knowledge we struggled to obtain in computer labs and exploring the Office suite at home suddenly felt like a waste of time. For instance, when trying to create a table the same way as we did before, we ended up spending hours trying to find the right button. Of course, it was natural to try to do things the same way we did before because we felt comfortable with our routine, and now we were blaming everyone at Microsoft in front of our computer screen.

Luckily, we were both born in the 1980´s so computers have always been a part of our lives. We eventually learned, step by step, and found the right button to create a table. We eventually stopped blaming Microsoft people and started to see advantages with Office 2007, even though it took us a while. We finally accepted the change, and we now appreciate it. Nevertheless, talking from our own experience, this change is still an ongoing process for our parents who started using a computer halfway through their lives. Obviously, there are different degrees of acceptance when we are confronted with a change, and this depends on a variety of factors such as our personalities, our age, but also, and maybe mostly, the way we are accompanied and guided through this change.

From a broader perspective, changes are found everywhere, and they can drive us forward but we don´t often go through without pain and struggle. Moreover, a change we are not really prepared for is usually even harder to accept. We find changes in organizations especially interesting to study because organizations often decide on changes they want to implement, implementations such as creating a new department, acquiring a competitor, implementing a new information system, etc. They have the power and potential to manage this change and make it less painful, and even meaningful. This is why we decided to focus our interest on Change Management and how an organization can make this process easier for its employees. However, there are various types of organizational changes and their implications can be quite different. Therefore, we will examine Change Management in parallel with a specific type of Information System (IS) adoption: a new Enterprise Resource Planning (ERP) system.

7

First, we will explain what Information Systems are, and in which way they can be challenging to implement. Then, we will present an IS in particular that will be our focus throughout this research, ERP. After demonstrating how such a system has an impact on individuals in an organization, we will explain to the reader why resistance to change can be expected. Finally, we will introduce the notion of Change Management, and in which way it is of interest when experiencing an ERP adoption process.

1. Information system adoption: an organizational challenge

With this section, we want to introduce our readers with the concept of Information System, what it implies for organizations, and how the technical implementation of such systems must be accompanied by a management of change that is not technically oriented but business oriented. First, we find it important to define what an Information System (IS) is. According to Encyclopedia Britannica, an IS is “an integrated set of components for collecting, storing, processing, and communicating information”. ISs have become a critical asset for organizations to be able to compete in today´s business environment. These systems have become a necessity in a constantly evolving technological context. IS projects require to manage user involvement. There are usually multiple stakeholders in this type of projects, and stakeholders’ involvement must occur at early stages of the process and throughout the project (Fuller et al. 2007). It might be an “integrated set of components”, but it is also a set of components that requires a large set of people to be fully functional.

Lientz and Rea argue, “in the early days of computerization, systems did not operate within the business process. Instead, they worked beside the business process” (2004: 20). Today, the situation is different. When organizations implement ISs, they also face non-technical challenges because they now operate within the business processes. For instance, order entry systems are not computerized. New Information Systems like ERP and CRM (Customer Relationship Management) are often quite complex and costly, and their implementation can take a long time depending on their scope. Many organizations do not have the expertise in-house to implement the systems, so they need to rely heavily on consultants or employees of the software vendor, which can turn out to be very expensive (Fuller et al. 2007). Magnus Mähring states that when the information system is large, it will most of the time lead to an important organizational change, and argues that governing an IT project is not only about dealing with a complex development effort, it is also about governing an organizational change (2002). In addition, Sadler acknowledges that one of the conditions for organizational change is the search for a more effective organization, which is one of the underlying factors for implementing an information system (1997). However, it is important to remember that a complex IS implementation can also lead to an increased level of responsibility for everyone

8

in the company, and “if you simply install the software without changing the ways people do their job, you may not see any value at all” (Lientz and Rea 2004). We intended here to make the reader understand that these systems can have repercussions on the business in its entirety. Usually, these systems will mean adopting new ways of working for employees. However, any IS won´t necessarily have an impact on the entire business, some systems will only concern one department. Therefore, we will now focus our attention on a specific information system that has an impact on the entire organization, ERP.

2. Enterprise Resource Planning: a one-of-a kind information system

We will discuss here the particularities of ERP, and its many “hidden costs” that help understand its implications for any organization and what should be taken into consideration when deciding to implement such a system.

There are different types of IS, and each aims at providing a particular set of functions for a business, but ERP is a unique system since it intends to integrate all departments in a company within a single computer system. ERP was created to integrate every computer system in an organization into a single software program. In fact, ERP enables improved information sharing and communication throughout an organization since it implements a single database accessible to every member of the organization. Moreover, everyone should be able to update the information so ERP truly increases people´s responsibility in the organization. For instance, when someone updates information in one department, this update will be seen not only in the specific department but in all departments where ERP is installed. An ERP system intends to improve an organization´s business processes by integrating them together and standardizing them. The benefits of such systems are wide in terms of integration of information, standardization of processes, inventory reduction… Overall, ERP intends to increase effectiveness and efficiency since it can be seen as a tool that can help a company reach its goals and be more competitive.

Figure 1. The scope of an ERP system (Source: adapted from McAndrew, 2006)

9

Implementing an ERP system is not an easy task. It literally changes the way people do their work. This means that not only technical issues, but also, and maybe mostly, people issues have to be taken into consideration throughout the process (Wailgum 2007). Furthermore, ERP is a costly system and the total cost of ownership, all the costs associated with the system, are often underestimated. There are many “hidden costs” encompassed in ERP. The most underestimated cost related to this system may be training. Employees experience a critical change in the way they work, and this implies a need for intense training to be able to use the system to its full potential. However, training by itself is not sufficient to ensure good implementation, as we will explain later. Furthermore, consultancy costs are often underestimated or simply avoided, which can lead to many problems once the system is used. External consultants often play an important role because they have the expertise to ensure a good implementation and effective use of the system, that is to say making sure that everyone uses the system to its full potential and knows what its interest for the business is. In addition, the implementation team cannot be sent back to its usual task once the system is implemented because reaching the system´s full potential takes time, and this team needs to accompany the process. Return on investment is usually not immediately observed since adaptation to the system is a lengthy process (Wailgum 2007). Overall, it is important to be aware of the fact that ERP changes people´s jobs, therefore the cost of ERP is not limited to the software itself.

In this section, we intended to introduce our reader with ERP and what it specifically brings to an organization. We have seen first the benefits of the system, and how it can create value added to an organization, but we have also stressed the major issues often triggered by this system.

3. Resistance: a natural response to change

The previous parts underlined the inherent need for organizational change when implementing an Information System, and more specifically ERP. Still, for individuals, change is often perceived as a threat, as a discomfort, so a natural way to respond to it is resistance. We will introduce in this section our reader with this concept of resistance that will be central throughout this thesis. Resistance is “the active or passive opposition to change and the management of change” (Lientz and Rea 2004: 33).Usually, when people are confronted with change, opposition occurs and can appear in different forms and degrees of intensity. Lientz and Rea state that it is natural that an organization´s staff wants the new system to do the work in the same way the old system did the work. Sometimes, they try to twist the system back to the old process. Lientz and Rea (2004: 36-39) refer to various reasons why people resist change during an information system implementation. For instance, employees might fear that the system will mean losing their job, or that their importance in the organization will decrease due to the new

10

system´s implementation. In addition, they will need to learn new processes, a completely new way of working to use the system, and if they don´t understand the reason why it is implemented or don´t trust the implementers, then resistance could easily appear. Managers should be aware of these common concerns. Moreover, people can adopt either a passive or an active way of resisting. Active resistance means that people openly express their disagreement whereas passive resistance is much more difficult to detect and therefore manage because people do not openly express their animosity. Managing resistance is a hard task in that sense that resistance is often passive (Lientz and Rea 2004: 36). With this section, we aspired to introduce or remind our readers of the importance of understanding resistance in a change context. Resistance and ways to reduce it are of predominant importance throughout this research, so the issue will be further developed.

4. Change Management as a way to deal with the “people´s side of change”

Mentioning resistance to change implies that accepting change is not an easy process for many individuals. The Change Management theory intends to help organizations handle resistance and reduce it, and manage a multitude of aspects of change. We will propose in this section an introduction to this theory, but this will be further developed in our theoretical framework.

Hiatt et al. (2003) define Change Management as the “people’s side of change” and as an application that stems from many different ideas from the fields of engineering, business and psychology. The IT community early used the term “Change Management” to refer to the processes and systems of managing software and hardware revisions (Hiatt et al.). There are many definitions of Change Management, Lientz and Rea define Change Management as “the approach to plan, design, implement, manage, measure, and sustain changes in business processes and work”. In this thesis, we will refer to Change Management as a practice meant to drive an organization forward to a desired new way of working and as a way to address and reduce potential obstacles on the road of change. We consider that the change in people´s tasks induces a need for behavioral change, which is what often leads people to resist.

The ideas of Change Management are many and managers, consultants and academics have realized that transforming organizations is difficult. Recent studies show that two out of three transformation initiatives fail (Sirkin et al. 2005). Changes depending on their size and complexity can have an impact at different levels in the organization and therefore it demands people´s involvement. One can therefore argue that there is a need for a Change Management methodology translating recognition of the need for change into desire for change (Hayes 2007).

11

In this section, we intended to explain the essence of Change Management, managing with the “people´s side of change” (Hiatt and Creasey 2003).

B) Purpose

Our purpose is to increase awareness of the benefits of developing a Change Management methodology in parallel with an Enterprise Resource Planning (ERP) system adoption in order to address and reduce resistance to change.

C) Problem statement

- How does identifying business processes have an impact on an ERP implementation? - How does identifying the stakeholders have an impact on an ERP implementation? - What are the main reasons why people resist organizational change and what form

does it usually take when confronted with an ERP implementation? - How can communication and leadership be used efficiently to reduce resistance and

obtain user support?

D) Scope

First, our theoretical interest in this thesis lies within Change Management literature; however, after talking to experts we understood we needed to complete our frame of reference with some aspects we did not find sufficiently developed in the Change Management literature.

Theories we found relevant to our research to complete were stakeholder theory, leadership theory and communication theory. Concerning the stakeholder theory we found what we needed in Project Management literature. Project Management is a practice closely linked to Change Management. However, if we would have written our thesis through the glasses of Project Management we would have probably focused on the ERP system itself. We are not suggesting that one is more important than the other, but Change Management is the focus in this thesis since it allows us to understand the organizational change and the impact it has on individuals in an ERP adoption process. In Project Management authors often define project success with help of the “Iron Triangle” or in other words time, cost and quality. In this research about ERP adoption process and Change Management we see success as the adoption of the system by people, and reduced resistance. We will observe the change in tasks and change in behavior. We believe that the change in people´s tasks induces a need for behavioral change, which is what often leads people to resist.

12

We see Change Management as a way to handle obstacles that arise when people in an organization experience change. Moreover, Change Management involves many activities, but due to lack of time and resources, we will in this thesis focus on the most important aspects we could identify in an ERP adoption context. Our interest lies primarily in the aspects of resistance to change, business processes, communication and leadership. These aspects involve individuals and their patterns of behaviors in an organizational change context, so our research is qualitative. This will be further explained in the methodology section.

E) Practical Value

This thesis can be of interest for business students who will be working with ERP in the future and who therefore need to understand ERP´s implications on an organization´s business process. We believe this thesis is of special interest for CEOs and managers of organizations who plan to implement an ERP system since our thesis intends to build a better understanding of the issues that need to be considered throughout this critical change process. It can be of interest for CIOs also and the IT side of business in general. We also direct this thesis to other researchers in the field of Change Management and ERP implementation, especially to trigger further empirical research.

13

II. Theoretical Framework

A) Introduction

After introducing our reader with our area of research and presenting our purpose and research questions, this frame of reference examines more deeply our field of investigation. First, we will present important characteristics of ERP systems in order for our reader to understand better why we chose to focus our research on this specific type of system. We will raise the opportunities and risks implied for organizations. In addition, we will see how ERP changes existing business processes, and the need for end-user involvement throughout the adoption of the system. Subsequently, we will examine the Change Management theory, focusing on its contribution to resistance understanding and potential solutions to reduce it. Finally, we will examine the importance of communication and leadership in times of change.

B) Characteristics of ERP systems

First, ERP systems, as mentioned in our background, have very specific characteristics that imply significant changes in organizations. These changes involve both opportunities if they are managed well, but also risks if they are mismanaged. We will also display how ERP involves business process reengineering for organizations. Ultimately, we will point out how the organizational change implies a need for end-user involvement.

1. Opportunities and risks for organizations

ERP as an integration and improvement of the business processes… which leads to major organizational change

An ERP system “attempts to integrate all departments and functions across a company onto a single computer system that can serve all those different departments’ particular needs” (Wailgum 2007). Instead of having different software and databases in each department, ERP merges all the systems into one software program and a unique database is run by the system for the whole organization. This unique integration can enable greater communication and information sharing in an organization, which could ultimately increase the efficiency and effectiveness of the business processes (Wailgum 2007). This system is described by O´Leary (2000: 3) as “a corporate marvel, with a huge impact on both the business and information technology worlds”.

ERP is mainly about business, it cannot be considered purely as a technical implementation. Corcoran (in O´Leary 2000: 6) stresses the fact that “there is a huge demand for users or line-

14

of-business personnel who also have professional level IT skills. But traditional IT types who know only about technology and nothing about the business are not needed now as they once were”. ERP processes most of the transactions of an organization in real time, and it therefore changes the business process of the organization (O´Leary 2000: 27). Rowe depicts ERP systems as “having the potential to radically change existing businesses by bringing improvements in efficiency, effectiveness, and the implementation of optimal business processes” (in Sammon 2004: 6).

Most companies decide to adopt ERP to integrate their financial information, to integrate their customer order information, to standardize and accelerate their manufacturing process, to reduce their inventory, and/or to standardize their human resources information (Wailgum 2007). The objective is always to increase business performance. This is well defined by Watson and Schneider (in Sammon 2004: 10): “ERP systems can be considered catalysts for radical business changes that result in significant performance improvement”. Of course, organizations in different sectors might have different needs and they might want to increase the efficiency of a single department. This need had to be taken into account by ERP vendors who create different modules such as finance or manufacturing.

ERP answers a need for standardization in many organizations where different softwares are used by different departments without much coordination or communication across functions. Overall, the significant benefits that can be observed with ERP, such as business performance improvement, will only be seen if a real organizational change accompanies the implementation. As explained by Orlikowski (in Sammon 2004), “it is how users interact with a technology in their daily tasks, not the mere fact that the technology is here, that affects the business benefits gained from a technology”.

ERP as an integration and improvement of the business processes … which leads to major organizational change

The main challenge with ERP resides in this need for organizational change that goes hand in hand with the adoption process. Harwood (2003) describes ERP implementation as a “multidisciplinary team effort”; IT people should not be the only ones involved. ERP adoption should lead primarily to a global organizational effort, involving end-users throughout the process. Unfortunately, Rutherford observed in 2001 that only 10% to 15% of ERP implementations were delivering the anticipated benefits they were supposed to bring to an organization (in Sammon 2004: 10). In a case study of an ERP post-implementation period in an Australian firm, it was observed that the implementation failed because of a managerial misconception of what ERP is about. Managers thought they could perfectly adapt ERP to their current business process (Sammon 2004: 72-91).

In this case study, another characteristic of ERP is shown that can put the whole implementation in jeopardy if not managed effectively: “the people who have been around for a while understood, thought they understood how the whole thing worked and now all of a

15

sudden bang they are right back to kindergarten level with everyone else and they have got the baggage of having the old system still in their mind while trying to operate an entirely different new system”(Materials Manager in Sammon 2004: 82). The system can be traumatizing for people who worked in a specific way for years, and are asked to drastically change their routine all of a sudden. Everyone becomes more accountable in the organization since everyone can have access to the data and update it companywide. It appears like a potential benefit, but if people are not prepared to handle the increased level of responsibility, it can put the implementation at risk (Sammon 2004: 86).

Preparing people for the change can be a lengthy process, so senior management should be aware of the need for time and adequate resources to carry out this process. Here it is also necessary that business executives are aware of the total cost of ownership of ERP because it is not only about buying software, there are also other important costs such as training, consulting or testing (Wailgum 2007). All of these costs actually demonstrate well the extent to which an ERP system affects an organization, and if the system fails, the whole organization could be paralyzed. The main risk of failure comes from being unable to get people to use the software, and this is likely to happen if costs such as training have been underestimated from the beginning.

Another important thing to bear in mind is the relationship that is created between the ERP vendor and the organization. Much of the responsibility for the maintenance and updates of the system will be given to the vendor. The vendor shouldn´t disappear once the system is implemented because the organization will need its help and support, therefore the process of choosing a vendor is also important (O´Leary 2000: 19-20).

Implementing ERP should be a thoughtfully decided process

After looking at both opportunities and risks of ERP systems, it should be clear that deciding on implementing such a system should be a thoughtful process where the pros and cons are clearly identified by the organization. In the decision process it is also important the role of the system, if it is aligned with the strategy of the company, Wailgum (2007) also states that a common reason for deciding not to implement ERP is realizing that the system won´t support a strategic business process.

It is very important to understand the “triggers for change” (Lientz and Rea 2004: 5), that is to say the factors that led to deciding to implement the system. There can be both internal and external factors that lead the organization to decide to implement ERP. An internal factor could be a bad inventory turnover whereas external factors could be increasing competitive pressure. Most of the time, external factors will have importance for senior management when deciding to change, but employees are often not so aware of these factors. For employees, “failure of the current methods in the work must be one of the triggers for change” (Lientz and Rea 2004: 5).

16

2. ERP and Business Process Reengineering

As mentioned before, ERP changes the way people work, and these ways of working are often referred to as business processes. In this section, we will first explain what a business process is. Then, we will see in which way ERP can require a certain degree of business process reengineering. Finally, we will look at a model developed by Hayes that explains how to go through such a process in a systematic manner.

What is a business process?

In any organization, there are usually various business processes in place in order to carry out the work. Lientz and Rea (2004: 17) describe a business process as a “set of organized activities and work to carry out specific defined functions”. If we take the example of two processes such as order entry and manufacturing in an organization, we can demonstrate an important property of processes: they are intertwined and a process is often dependent upon others and vice-versa. For instance, the order entry process has an impact on the manufacturing process since the order entries will determine the production level. Therefore, it is very important to understand the links between the processes.

Every business process uses rules and guidelines because a process seeks to standardize a specific set of activities. Sadler (1997: 41) depicts systems, procedures and processes as “relatively formal, prescribed and standardized ways of doing things that have been developed or adopted by the organization”. Lientz and Rea (2004: 18) define the different types of rules and guidelines that frame the use of processes such as business rules, procedures, business policy and guidelines. Business rules and procedures are both internal, often built by the company in a formal way to give clear directions to the employees on how the work should be done. Business policies on the other hand can be both internal and external. For instance, a law can impose a certain way of handling transactions, but an agreement signed with a labor union can also have an impact on the processes. Finally, guidelines are less formal but they give a general direction about how to do the work. When changing a business process, all of these rules must be taken into consideration, otherwise, the change effort is likely to fail. The business processes are tightly linked with organizational change in the sense that “organizational change involves both the modification of existing systems and procedures and the introduction of new ones” (Sadler 1997: 42).

17

How does ERP trigger a need for Business Process Reengineering (BPR)?

“The work and transactions in the business process are carried out by people and through systems and technology” (Lientz and Rea 2004: 18). Information Systems play an important role in business since they enable to formalize the business processes. ERP in particular intends to integrate the different business processes.

Since ERP integrates the business processes, the existing processes before the implementation cannot be a perfect fit with the new system. In fact, integration requires better coordination between different units (Spector 2010: 89). Hayes (2007: 321) throws light upon the fact that “BPR involves switching attention away from fragmented functional-based thinking towards cross-functional processes that create value for the organization”. Processes need to be reengineered, in other words rethought so that they are adapted to ERP. Hammer and Champy (in Hayes 2007: 322) defend a “clean-sheet” approach to reengineering that should not build upon existing processes. However, this approach is not unanimously accepted. Davenport and Stoddard (in Hayes 2007: 322) attest that this “clean-sheet” approach can´t be achieved in practice because the implementation phase should be done step by step.

Besides, BPR goes hand in hand with organizational redesign. Spector (2010: 82) characterizes organizational redesign as “arrangements, both formal and informal, that an organization calls upon to shape employee behavior”. Whereas informal redesign can concern providing employees with new responsibilities, formal redesign would be creating a new reporting structure for instance. Spector advocates that informal redesign should be done first before considering formal redesign. When applying this to an ERP context, informal redesign is very important because employee responsibility will expand, and there is a need for new process rules and guidelines for instance.

“No design solution, no matter how useful it may be at one time, is impervious to the need for change” (Spector 2010). Likewise, ERP requirements demonstrate this need to change design solutions. In addition, an important piece of advice given by Spector is to “be systemic and strategic rather than piecemeal and haphazard” when changing design (2010: 84). However, this is rarely found in practice because many leaders prefer to avoid the confrontation they could encounter.

It can of course be difficult to redesign the whole organization at once, so a solution can be to use change pilots. Spector defines change pilots as “small units or specific processes which can be targeted at early stages of change implementation to experiment and learn” (2010: 85). Companies such as SAP have understood this concern and their ERP solution is therefore developed as a suite of different modules, as mentioned earlier. When going through a business process improvement, an important step is to understand how the new activities will add value for the customer. With ERP, the internal value added of integrating the different processes should lead to increased value added for the customers, maybe with better delivery time for instance.

18

Business Process Reengineering step by step

Hayes recommends seven steps that should be followed when reengineering business processes (2007: 324-327).

Figure 2. Business Process Reengineering Steps (source: Hayes 2007: 324-327)

First, one should map the processes to understand well what they are, what they do, and what their value added is. Then, one can identify which processes need to be reengineered, based upon their limitations. The reengineering team should also make sure that these processes selected are well understood. Once this is confirmed, it is time to define key performance objectives, that is to say writing down what needs to be accomplished with the new processes. Bearing in mind these objectives, the next procedure consists of designing new processes. Once the design phase or decision is done, it is time to test ideas to establish if they will work in practice. Finally, the last step is the actual implementation of the new processes.

With this section, we presented first what a business process is in order to understand how ERP triggers a need for business process reengineering. Finally, we used Hayes´ model to show that such a transformation of business processes must be planned, organized and understood.

3. A need for end-user involvement

We mentioned how ERP implies changing business processes, and therefore its impact on the day-to-day work of the organization´s personnel. Since employees will be the ones using the new system, their involvement throughout the ERP adoption should be important, and the importance of end-user involvement is well developed in the literature.

Map processes

Identify which processes need

to be reengineered

Define key performance objectives

Design new processes

Test ideas to establish if it

works in practice

Implementation of new

processes

19

Putting into context the need for end-user involvement

First, Wailgum (2007) presents a good example of how ERP involves most of organization´s personnel by describing a customer order fulfillment. The customer service representative who is in charge of entering the order has access to all the information he needs to complete the order. For example, he has access to the credit rating of the customer and the current inventory level of the company. Every department in the company has access to the information, and the order is routed through the system from department to department until the order fulfillment. Everyone has responsibility in the process since many employees update the information. Nevertheless, their involvement should begin early and it should be perceived as important throughout the ERP adoption process. As Corcoran remarks, “IT professionals … are blurring the lines between IT and users” (in O´Leary 2000: 6). Especially in an ERP adoption context, the importance of the business side of the adoption is vital.

A lack of involvement and its consequences

Before considering the interest of involving end-users, it is interesting to examine the consequences of not involving personnel in the process. Lientz and Rea scrutinize many “common myths of change” and “reasons why change fail” that involve this idea of user involvement (2004: 26-29). Too often, managers perceive the need for change, and they assume that this need is evident for everyone in the organization. However, if the managers´ don´t explain why the change is undertaken and decide alone, how could employees understand the reasons that triggered change? Furthermore, some executives suppose that it is sufficient to involve a small number of “key employees” to put into effect the change. Again, this is one of the “myths of change” that can´t function in practice. These two suppositions lead to a common reason for change failure: “people who do work in the process are not heavily involved in the effort”. They should be the pivot of the change, yet managers don´t take into account their ideas or they refuse to disrupt work. Spector mentions how change forced from above will lead to resistance because “people don´t resist change, they resist being changed” (2010: 12).

The benefits of user participation

Being critical for the implementation´s success, employees should therefore be enabled to participate in this effort. Spector describes the importance of employee participation in these words: “by diagnosing problems, understanding their importance, and being part of the process of formulating solutions, people develop a psychological sense of ´ownership´ over the outcome” (2010: 12). Participation is the process of enabling employees to articulate their opinion, and consider it. The objective with employee participation is to develop commitment

20

and a sense of responsibility so they support the change effort. However, Spector makes clear the distinction between motivating employees to change and tricking them into changing. Obviously, the second option involves great risks since it could lead to a complete lack of trust from personnel.

Likewise, Lientz and Rea enounce two critical success factors directly related to user involvement issues. First, they suggest to “involve many people at the lower levels of the organization” to obtain support and participation. Moreover, they warn against involving too many upper managers in the process. Whereas senior management should provide support initially and give a clear vision, their involvement in following steps should be restrained to strategic issues. This relates to leadership considerations that will be further discussed in section D. Finally, Lientz and Rea demonstrate the need for involvement throughout the process, that is to say that employees should be involved from goal setting to implementation of the change (2004: 29-30).

With this section, we wanted to remind our reader how ERP asks for user involvement using a concrete example of its impact on individuals in the organization. Then, we have seen how no end-user involvement can lead to problematic situations before appraising the importance of user participation in the ERP adoption process.

C) Change Management: a way to reduce resistance

“It ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, than to take the lead in the introduction of a new order of things. Because the innovator has for enemies all those who have done well under the old conditions, and indifferent defenders among those who may do well under the new” (Machiavelli cited in Paton and McCalman 2008: 47)

In the previous section, we have seen the importance of user involvement in an ERP adoption process and the problems that can arise when neglecting it. In this part, we intend to go more into depth with the concept of resistance. First, we will see why people resist change. In a second part, we will see how it materializes, and finally how it can be addressed.

Important to clarify early is that that managers should not see resistance as something “bad” , Spector (2010) means that leaders actually have the possibility to learn from employee resistance, however, he argues that resistance will eventually have to be dealt with and solved.

Additionally, it is important to understand evolving behavior throughout the change process. Cadle and Yeates (2004) suggest that there is a need to understand individuals´ pattern of behavior before addressing the actual resistance.

21

Figure 3. Evolving behavior throughout the change process (Source: Cadle and Yeates, 2004:6)

Cadle and Yeates define the first step when going through a change process as denial, when people feel challenged by a new system and at the same time believe that they can use their current skills to handle the new system. A natural second step, they argue, is resistance when people gain more information and feel a lack of self-esteem and signs of stress. In the exploration phase the employees share their feelings and difficulties with each other, and in a “trial and error manner”, they gradually regain confidence.

1. Resistance: a common response to change

In the Change Management literature, the concept of user resistance when an organization is undergoing change has been quite developed. First, it is of interest to define what resistance is. Lewin asserts that “resistance refers to action, overt or covert, exerted on behalf of maintaining the status quo” (in Spector 2007: 36). Resistance has also been defined as “active or passive opposition to change and the management of change” (Lientz and Rea 2004: 33). What is of interest is that authors agree on the fact that not all employees embrace change with equal ardency.

Resistance as a natural reaction to change?

Lientz and Rea argue that “you should assume that you will meet some resistance to change as this is only natural and a part of life, but be proactive about it” (2004: 39). In fact, they imply that resistance should be acknowledged, and therefore, measures should be taken so that resistance can at least be reduced. Many authors see resistance as natural human behavior. Paton and McCalman for instance state that “no matter how welcoming an organization is to change, it will still face a degree of employee, supplier, distributor, and stakeholder and consumer resistance to change” (2008: 47).

Denial

Resistance Exploration

Confidence

Launch Exploitation Education

22

Not everyone is satisfied with this assumption. Spector (2010) argues, “employees do not naturally resist change, but they often resist change because of the way it is being implemented” (2010: 9). Having this in mind it implies that resistance to change might be a natural reaction, but it can be managed to a certain extent. What authors do agree on is that executives sometimes underestimate resistance.

Interesting to notice is also that Cadle and Yeates (2004) assert that there is often resistance in Information System projects because the project manager has not anticipated the reactions from the end-users. In the following part we will present theories about why employees resist to change, this will be followed with theories about what types of resistance that can be detected in organizations implementing an information system and finally, a last section will be focusing on how to deal with this resistance.

A feeling of comfort with the status quo

A lot of attention on resistance has been focused on why people resist change or why employees fail to join the change effort. To better perceive the concept of resistance we believe it is important to sort out theories that will be of importance for our research. In this part, we will mention patterns and reasons why individuals resist change when faced with a system´s implementation.

Most theories suggest that one major reason to why people resist change is the convenience of the status quo, in order words the comfort of existing working conditions. Hiatt and Creasey (2003) claim that practitioners and business leaders often underestimate the level of comfort with the current state, “the present is so powerful that at times it seems to defy as logic” (LeMarsh in Hiatt and Creasey 2003: 20). Paton and McCalman (2008) acknowledge that people do what they do well so they prefer the status quo. For instance, when you have been working with the same software for a long time, you know well the specific steps you need to follow to do one transaction so you feel more comfortable with this process. The idea of changing this pattern often makes people uncomfortable, this is because that the change often creates new technical challenges and challenges old ideas and routines. Hullman (in Spector 2007) presents the underlying factors to individual resistance. He suggests that individuals are satisfied with the present state of affairs since their needs are already being met, so why would they go through the trouble implied with change? Dawson states that the main reason why resisting change is because “the proposed change may break the continuity of the work environment and create a climate of uncertainty and ambiguity” (Dawson 2003: 19). All of these authors insist on one notion: status quo. Whereas what has been done in the past feels like a secure path that the individuals master, the future is uncertain and involves change so it is natural to feel uneasy with this idea.

23

Personal interest and concerns related to change

Moreover, there is also a fear for the change related to each individual´s own interest. Hiatt and Creasey (2003) claim that primary concerns for employees when faced with a change are: “What will this change mean to me? Will I have a job? And do I have the needed skills and knowledge to succeed in the new environment?” Dawson expresses other factors such as fear of reduction in economic safety or job rearrangement, psychological threat or new work patterns (2003). Spector (2007) and Lientz and Rea suggest that employees can see the change as a threat because they fear that they will be negatively affected. People might fear that they will not be viewed as important for their organization because of the change. Kotter and Schlesinger (in Hayes 2007) point out “parochial self-interest”, which means that people resist because they think they will lose something of value. Zaltman and Duncan (in Hayes 2007) also mean that the most important source of resistance are the threats to power and influence, they also point out that even managers can resist change if they believe it will decrease their power and authority. Moreover, as Kanter (in Paton and McCalman 2008) suggests, it is easy to say yes at first to a new idea at the development stage since almost no impact can be observed yet, but detractors appear when change materializes.

Different assessments leading to resistance if not managed

As Hiatt and Creasey pinpoint, usually front-line employees have a different point of view on change than the rest of stakeholders since they do not have a detailed discernment into business strategy and financial performance of the organization (2003: 8). This connection between organizational performance and the need for change in their everyday work is usually not clear for many employees, that is also why it is difficult to convince them to change based only on the organization’s performance needs. Spector also notices that employees might appear positive to the change, but they believe in fact that the costs counterbalances the benefits or they believe that the organization is not approaching the process well enough.

Kotter and Schleisinger refer to common problem as “different assessments” where internal and external stakeholders and change initiators assess the situation differently (in Hayes 2007). One classical mistake appears when the change initiator chooses not to inform the employees about the change prior to the implementation (Dawson 2003). These authors demonstrate how the way the organization handles the change process can have an impact on the degree of resistance. Indeed, this lack of involvement ultimately triggers a lack of understanding, and therefore resistance.

24

Resistance: created by managers?

In addition, theories also assert that managers often create resistance themselves through their approach. Spector (2010: 11) asserts that it is important to realize that the biggest factor that has an impact on the resistance comes from “how the process is managed and the degree to which employees are allowed to participate in the process”. Spector also acknowledges that managers, in some cases, see change resistance as a bad thing and something that needs to be handled with force. However, this manner of pursuing change can create resistance. In fact, managerial actions can lead to almost all of the reasons to why resistance occurs. For example, if managers choose not to include employees in the learning phase, employees are likely to be even more content with the status quo because they are not motivated to change.

In this part we have described what change resistance means, and why it often occurs. The major reasons to why employees resist change seem to be the comfort of the status quo, a certain fear because it changes the way of working, a lack of user participation and we have also seen how managers often can create resistance themselves in their pursuit of change. In the next part, we will see what types of resistances are to be found in change implementations and what characterizes these types of resistances.

2. Different types of resistance

There is not one way of resisting change, different theories show that resistance can take many forms. For instance, Lientz and Rea (2004) argue that both individuals and groups can express different degrees of resistance. Moreover, they add that resistance is dynamic and changes depending on specific situations.

Resistance: out in the open or latent?

Lientz and Rea argue that there is a need for categorizing the different types of resistance “to help to understand, discuss, and counter the resistance” (2004: 35). Spector, Cadle and Yeates, but also Lientz and Rea, categorize the different types of resistance into “active resistance” and “passive resistance”. Spector (2007) describes passive resistance as a “mild form of resistance” where employees aspire to argue with the change but they won´t express it clearly, whereas he describes active resistance as a way to hinder the change and behave in a certain way to oppose the vision. Lientz and Rea suggest that active resistance is easier to handle since employees openly discuss the changes and indicate their lack of support. Passive resistance might be more difficult to detect. For instance, Spector (2010) gives an example of passive resistance when employees can appear to behave positively to the change initially, but as it is getting closer, the resistance starts to come through. Lientz and Rea take it one-step further and considers open versus underground resistance (2004: 36).

25

Type of resistance Open Underground

Active XYZ ABC Passive DEF GHI

Figure 4. Types of resistance (Source: Lientz and Rea 2004: 36)

Individual ABC is someone who actively resists change that can come from an ERP implementation, but does not do so in the open, these individuals are “real threats” to a change implementation. Individuals GHI are usually many in number and they resist change because they naturally doubt that the change will work, they are a bit different from the more unusual DEF individuals who “now and then” openly admit their concerns. Lientz and Rea insist on the “underground” types of resistance because, as mentioned earlier, these are the most difficult to observe and therefore manage.

A spectrum of reactions to change

Spector suggests that change is not accepted in the same way among the employees, there are a wide variety of reactions. Spector presents a spectrum from Commitment, Involvement, Support, Apathy, Passive resistance, Active resistance and finally to Aggressive resistance (2010: 10). Instead of giving definitions of each term, we decided to use Spector´s continuum and associate each individual response to change with an example of individual behavior in ERP adoption that would correspond to each one.

Commitment Individual part of the Change Management team

Involvement Individual asking if he could be of any help in the change effort team

Support Individual mentioning the ERP system as a good thing for the organization

Apathy Individual aware of the ERP implementation but doesn´t either support or oppose the change

Passive resistance Individual who keeps to himself his reticence Active resistance Individual who openly expresses its reserve

concerning the system with colleagues during breaks

Aggressive resistance During training sessions, the individual purposely refuses to do the exercises and encourages his colleagues to do the same thing

Figure 5. Continuum of individual Response to Change (Source: Spector 2010: 10)

26

We have here seen that there is a need to understand the different types of resistances and categorize them in order to help, understand and counter it. Lientz and Rea suggest that passive underground resistance is the most common type of resistance and we have also seen that resistance often materializes as the change is getting closer. Therefore, after looking at why employees resist and what types of resistance there are, it is now time to look at how to address resistance to change.

3. How can resistance be addressed?

As a natural step, after looking at why resistance appears and what forms it might take, we are now ready to look at what theory tells us about how to tackle employee resistance to change.

As we have seen, a certain degree of resistance to change is almost unavoidable, so the question is how and what to focus on since “Change Management may manage to reduce the frequency and potency of resistance, but it will never eradicate the fear of the unknown” (in Paton and McCalman 2008: 47). However, as mentioned previously, it is important to remember that Change Management is a way to deal with resistance and obstacles before it is too late (Hiatt and Creasey 2003). Change Management is also a way to deal with what Lientz and Rea refer to as “king bees” or “queen bees”, or in other words people that have gained knowledge and power by doing the same work in the same business process for many years and who will be the most resistant to change (2004: 20).

The Change agent obviously plays a vital role during the change implementation. This role is not easy, Paton and McCalman mean that “the effective change agent must be able to orchestrate events, socialize within the network of stakeholders, and also manage the communication process” (Paton and McCalman 2008: 51).

Change as a team effort

As we have seen resistance often stems from lack of sponsorship, participation and involvement, therefore describing change as a team effort may be relevant in some cases. Lientz and Rea turn to the change initiator and state that in general, “the more time you spend with the people doing the work, the more you gain their confidence” (2004: 42). Sadler affirms that resistance to change can be minimized with planning and answering questions like: “who will be affected by the change? Directly and indirectly, what aspects of their working lives will be affected? Who should communicate information about change, when and how? And what management style is most appropriate to use?” (1996)

Hiatt and Creasey (2003) mean that as a change leader, you need to be aware of that effective sponsorship at the right level may induce success or failure of the change implementation.

27

However, it is still a problem if the employees have seen frequent examples of incompetence by the sponsor or if they know of a history of failed changes from the change agent’s side. Paton and McCalman point out that “managers must engage in a process of negotiation, striving towards agreement. This is essential where those opposing have the power, and influence, to resist and ultimately block the change” (2008: 50). Boddy and Buchanan argue that the most important task for a change manager is to reduce the uncertainty that is associated with the particular change situation and after that encourage positive action (in Paton and McCalman 2000). This leads to the importance of leadership, which will be further discussed.

We have also seen many Change Management authors stress the need of participation and involvement. Spector (2010) and Buchanan and Huczynsky (in Paton and McCalman 2008) affirm that participation in the change process is the best way to build support and reduce resistance to change. The aim is to stimulate interest and commitment and minimize fears (Buchanan and Huczynsky in Paton and McCalman 2008) however, as Spector (2010) points out, this is not a guarantee for success. Buchanan and Huczynsky (in Paton and McCalman 2000) also suggest that it might be necessary to provide support services to assist in promoting an individual’s awareness for the need for change.

Useful skills and knowledge for the change initiator

It is important to understand that the change initiator walks a thin line when addressing resistance, on the one hand he or she should not wait for major problems to appear, but taking immediate action when targeting resistance tends to drive the resistance underground instead of eliminating it (Spector 2010). Timing is here a dimension that has to be taken into account when addressing resistance. Lientz and Rea point out that you can detect early signs of resistance by observing employees’ tone of voice, body language and their discussions in the managers’ presence and on their breaks (2004: 40). The manager should take a soft approach, since you don’t want to force change upon employees.

More important, if you are aware of the symptoms and not of the causes, there should at least be a resistance strategy, where the focus would be on transactions that do not require involvement of “king or queen bees”, and isolate and deal with exceptions in a group. Lientz and Rea also points out the important to stress the downside of status quo, in other words try to raise awareness on what will happen if the change is not undertaken.

Another important helper when implementing a change seems to be what Kanter (in McCalman and Paton 2008) present as the “change master”, she means that these masters exist throughout the organization. These change masters have the ability to work independently without the power and sanctions of the management hierarchy, they compete in ways that enhance rather than destroy cooperation, they develop high trust relations with high ethical standards and respect the process of change as well as its substance. They can work

28

across business functions and units, and have a willingness to take rewards on results and gain satisfaction from success.

Paton and McCalman (2008) also argue that there is a need for competent internal change agents to ensure cooperation, effective implementation and successful handover after completion. However, the external change agent has a lot to offer, and it is the responsibility of the client to determine the need for an objective outsider after considering the internal competencies and the external opportunities.

When reflecting over what just have been mentioned, what seems to be fundamental to understand for the change leader when undergoing a change is Hiatt and Creasey’s (2003) three lessons learned on how to reduce employee resistance. First, it should not come as a surprise that the resistance is there; instead, the resistance needs to be expected and planned for, here it is also important to be patient with individuals through the change process. Secondly, it is important to understand the capacity for more change in the organization, and thirdly, the importance of understanding that persistent and prolonged resistance from anyone in the organization can compromise success. There is a need to understand why resistance exists and deal with its root causes.

Addressing resistance depending on type of resistance

A very clear idea on how to deal with resistance what Kotter provides with his “six methods”. It shows different measures for different types of resistance. These methods ranges from “Education and communication”, “Participation and involvement”, “Facilitation and support”, “Negotiation and agreement”, “Manipulation and cooption” to “Direction and a reliance on explicit coercion”(Kotter 1999: 44).

When it comes to “Education and communication”, Kotter means it is useful in situations where there is inaccurate information or a lack of information, in other words a lack of understanding. The advantage here, according to Kotter, is that once people are persuaded , they are onboard. However, especially when the change affects many people, it can be very time consuming.

There seems to be different methods to use in this education to the need for change. For instance, if you assume that those affected by the change are rational human beings that base their decision on facts and behave accordingly, then you should use an unbiased presentation built on facts and numbers so that the ones affected can make their own rational decision (Zaltman and Duncan in Hayes 2007). Hayes also recommends that when the dedication to the initiated change is low, a more persuasive and biased strategy that aims at motivating the employees could be a good strategy; this can include stressing the downside of being stuck in the status quo. Another strategy as Nadler (in Hayes 2007) argues is to explore the concept of “unfreezing”, via education or persuasion, to “create a feeling of dissatisfaction with the

29

current state” would be of vital interest to the change initiator. However, he acknowledges that this is risky since employees can take this as negative critique.

Furthermore, to solve the problem when for instance those in charge of implementing the ERP system are lacking information needed to design the change, and others have significant power to resist the ERP system, Kotter (1999) means that “participation and involvement” is the solution. The benefits of the participation is to get commitment, motivation and to get ideas from the users, however also this is risky and time consuming, especially due to the potential skills from the participators to design a change. Nadler implies that this can “excite, motivate and help create a shared perception of the need for change” (in Hayes 2007: 217). However, important to remember is that this builds on the assumption that the information people collect for themselves is more accurate than information presented by an outsider (Hayes 2007).

Moreover, providing “facilitation and support” can also be useful when fear and anxiety are the major reasons for resisting (Kotter 1999). Kotter means that “no other approach works as well with this adjustment problem” (1999: 44) This might involve training in new skills, giving time off after a demanding period, or simply listening and providing emotional support. This can be useful in ERP implementations when employees feel that the way they used to work which maybe was a part of their identity, and even more useful when their feelings and emotions hinder them to think clearly. The drawbacks here are that it is no guarantee for success rather a guarantee for high cost in terms of money and time (Kotter 1999). Hayes (2007) adds that there is also a risk that this might increase rather than reduce the resistance.

The fourth method “Negotiation and agreement” is described as sometimes “an easy way to avoid major resistance” (Kotter 1999: 44). Kotter means that this is suitable when individuals or groups clearly will lose something they value with the change, and they have a substantial power to resist the change. Kotter and Schlesinger (in Hayes 2007) also suggest that if it is easy to identify those who have the sufficient power to resist change, “Manipulation and cooption” might be a less expensive method than negotiating; this involves influencing others to change by deliberate biasing of messages. This is also very risky and quite unethical since employees might feel tricked into supporting the change.

The last method presented by Kotter is “Explicit and implicit coercion”, this is suitable when those in charge of the ERP implementation possess extensive authority and where rapidity is key. Obviously, this is risky since the reactions from the users might be unpleasant.

Finally, Boddy and Buchanan (in Paton and McCalman 2008) present a process solution to help reduce resistance, it ranges from “identifying the stakeholders” through “work on objective”, “set a full agenda”, “build appropriate control systems” to “planning the process of change”. They demonstrate the need for management support throughout the change process, which we have dealt with in this chapter, and more specifically they also stress the need for communication and feedback since communication is a two-way process when building appropriate control systems. The concept of stakeholder identification, communication and feedback will be analyzed in depth in the next chapter.

30

In this part, we have seen the difficult and important roles the change agent plays. Understanding what comes with this role, he or she must first determine if the required competences for change can be found in-house. We have seen a need for participation, involvement and active sponsorship. The change agent must engage in a process of negotiation towards agreement. To understand the concept of resistance is vital, not to mention that the resistance should not come as a surprise. Additionally, we have seen how different measures can be taken to address different types of resistance. In the resistance literature, it appears that there are aspects of a change process that are neglected when resistance is high. Therefore, the ways of reducing resistance will be further discussed by looking at stakeholder, communication and leadership theories.

D) Facilitating change: identifying stakeholders, communicating and leading the change

As we have realized, the tasks and responsibilities for managers or change initiators are many and complex. Not only is the end user interested in the outcome of a change process, in some cases there might be a need for the manager to prioritize his or her limited time and resources when it comes to stakeholder attention. In this part, we will first see what stakeholder theories that can be of interest when adopting an ERP system. Then, we will identify different communication techniques and strategies in times of change. Finally, we will observe leadership theory in Change Management and see what leaders can bring to the change process.

1. The importance of stakeholder identification

Lientz and Rea define stakeholders as “internal and external entities that are interested or involved in the activities of the organization” (2004: 49). Spector defines stakeholders as “individuals or groups who lay legitimate claim to the performance of the organization; they have a stake in how the organization is doing (Spector, 2010: 33).This definition implies that something is at risk, which explains also why people may be resisting as we have seen.

In order to understand better how an ERP implementation affects the organization and the people within it, it is important to identify who the stakeholders are when implementing an ERP system. Moreover, interesting to notice is what Campbell suggests, that most organizations can be divided into two groups when it comes to their organizational purpose as “serving the interests of the stakeholders”, and whether the organization is focusing more on financial terms and shareholders or if it focuses more on the employees, customers, suppliers, community and shareholders (in Sadler 1997: 47).

A stakeholder mapping seems to be of interest. Lientz and Rea believe that there is a need for clear statements concerning the vision and mission for the organization. They also stress the

31

importance of listing stakeholders when formulating vision and mission (2004: 51). Lientz and Rea give an example of a sample list of stakeholders where they include IT, technology and business processes as stakeholders. They argue that they are critical to Change Management and much of the change that is done involves systems, therefore, it is better to include them in the analysis as early as possible.

There seems to be different theories on how much attention the manager should give stakeholders. Spector points out that “a key source of outstanding performance lies in the willingness of organizational leaders to commit time, energy, and resources to tending to the interest of multiple stakeholders; most especially to shareholders, to customers, and to employees” (Spector 2010: 33).

Furthermore, there are many theories on how to map the stakeholders. Newcombe’s “predictability/power” and “interest/power” matrices are a good way to map them since it focuses on three interesting dimensions (2003). First, Newcombe defines power as a mechanism that stakeholders use to influence a project. He also states that power can be used in two opposite forms, either to “retain the status quo” or to “enforce fundamental change”. Stakeholder predictability can be defined as the relative possibility to foresee the way stakeholders will behave throughout the change process. Finally, stakeholder interest relates to their relative engagement, involvement in the process.

Figure 6. Predictability/Power and Interest/Power Matrices (Source: Newcombe 2003: 844)

One could also use a “stakeholder grid” where one axe attitudes can range from” positive” through “neutral” to “negative”, and the other axis from “blockers” to those who work proactively for success defined as “sponsors” (Hayes 2010: 157). Moreover, Philips states that the requirements and demands from the stakeholders often change throughout the change process.

32

Jones and Wicks´ theory also points out that the role and importance of specific stakeholders changes during the change process (in Hayes 2007). According to Jawahare and McLaughlin the stakeholders’ ability to meet specific organizational requirements changes over time, which makes them more or less important in specific phases (in Hayes 2007: 158). They also express that it is possible to identify which stakeholders are the most important at a specific time during a change process; therefore, it will be possible for the manager to prioritize his or her attention to a specific stakeholder at a specific stage of the change implementation. They also suggest two further stages that involve “formation of relationships” and “termination of relationships”. An example of the different levels of stakeholder attention can range from “Proaction” , which implies to anticipate stakeholder issues, through “Accomodation”, “Defense” and finally “Reaction” where one ignores or refuses to deal with stakeholders (Carroll and Clarkson in Hayes 2007: 156).

In this section, we have seen the importance of identifying, mapping the stakeholders, so managers know with whom they should communication. Having a clear map of every stakeholder, including users, is a powerful tool to communicate the change better.

2. Communication: an important but difficult tool to m aster

After having observed both ERP particularities and Change Management as a way to reduce resistance, it appears that communication is a key enabler for effective user involvement. This notion of communication is very present in the Change Management literature, and several models of communication in times of change can be useful to understand and reduce resistance. First, we will appraise some basic recommendations that should be kept in mind when delivering a change message. Then, we will review five basic communication strategies observed by Clampitt, DeKoch and Cashman (in Hayes, 2007: 180-182). Finally, we will consider the “Power Equalization Steps” developed by Spector (2010: 66) that aim at unimpeded communication.

Basic recommendations when delivering a change message

First of all, Paton and McCalman remind us of some elementary but yet key guidelines that should be bear in mind when communicating change (2000: 45-46). “Customizing the message” is a central recommendation. It implies that depending on whom you are communicating the message to; it will need to be coded differently so the person can actually understand it. For instance, when explaining to employees what the ERP system will do, the message won´t be transmitted in the same way to manufacturing employees or to IT department staff. Whereas IT people have a technical language they understand, other employees don´t, and it is important to make sure to employ a comprehensible vocabulary. Telling employees that “the first ERP systems were an extension of MRP (Material

33

Requirements Planning) and CIM (Computer Integrated Manufacturing)” would be meaningless to them, and that is the last thing you want when communicating.

In addition, it is important to remember that the content of the message is often as important as the tone employed to voice it. If you look uncomfortable, it tells people “he is uneasy with what he says so he probably doesn´t believe in this project”. Furthermore, there must be built in feedback in the message. Communicating doesn´t involve only the sender, the receiver must have the opportunity to react and express its response to the message.

Moreover, be consistent! Consistency is key because if the message keeps changing, credibility and trust will soon disappear. Finally, it is important to select the most adapted media to ensure diffusion of the message. There is no norm applicable to any communication since it is dependent upon the type of change, who it will affect, the organization… Overall, these guidelines are valuable because “effective communication will assist in overcoming both resistance to change and ignorance” (Paton and McCalman 2000: 47).

Different managers, different communication strategies

However, all managers when communicating change do not necessarily consider these advices. Clampitt et al. (in Hayes, 2007) have observed many managers and their communication strategy before identifying five basic communication patterns. This classification is based upon the authors´ observation that “managers can communicate about anything but they cannot communicate about everything” . Through their observations, they have noticed that many managers don´t pay enough attention to the role of communication, and therefore communicate inefficiently. If we take again the example of a manager presenting the ERP system to employees, talking about specific technical aspects such as how the database will work is inefficient. On the other hand, giving concrete examples to the personnel of how the system will help them complete transactions faster and allow them to give feedback will be a lot more efficient.

Now, let´s observe the characteristics of each communication strategy type observed by Clampitt et al. First, “spray and pray” consists of giving a lot of information to the employees and hoping that they will feel informed enough. Managers who communicate this way assume that abundant information equals better communication, but this solution presents problems. In fact, if the information is not sorted out, the employees will select it themselves and extract only what matters to them, or they will feel lost and confused.

A second strategy is “tell and sell”, when managers select a smaller amount of information that is meant to address central issues related to the change. Unfortunately, managers taking this approach often assume that they have given employees all the data they need and they are not willing to take into account their input. Communication here is limited since it only goes in one direction.

The third strategy is called “underscore and explore”main difference is that managers are willing to listen to concerns and consider it.

Then, “identify and reply” takes a difconcerns before developing the message. Unfortunately, the individuals are often not aware of the critical issues so they can´t ask the right questions.

Finally, managers who use “withhold and uphold”becomes really necessary. It is a policy of secrecy and control where information is seen as power and where managers consider that employees lack the ability to understand the “big picture”. Building trust and credibility with this method seems hard to achieve…

Figure 7. Five communication patterns (Source: Clampitt, DeKoch and Cashman in Hayes 2007)

With this graphical representation, we intend to show what the authors conceive as most or less effective practice. For Clampitt et alstrategy because it takes from central issues related to the change and from taking into account concerns and feedback from employees.

Adapting the environment to enable better communication

Finally, Spector developed what he called main impediment to open and efficient commorganizations (2010: 66). Spector´s model consists of seven steps to make communication more open and prevent organizational silence. charge of these steps becausecommunication. Before describing thesilence is. Spector defines it as a widespread assumption on the part of employees that candid feedback and open exchange of

Spray and pray

Tell and sell

Underscore and explore

Identify and reply

Withhold and uphold

34

“underscore and explore” and it resembles “tell and sell”main difference is that managers are willing to listen to concerns and consider it.

” takes a different approach since the manager first listens to concerns before developing the message. Unfortunately, the individuals are often not aware of the critical issues so they can´t ask the right questions.

“withhold and uphold” don´t communicate the information until it becomes really necessary. It is a policy of secrecy and control where information is seen as power and where managers consider that employees lack the ability to understand the “big

redibility with this method seems hard to achieve…

. Five communication patterns (Source: Clampitt, DeKoch and Cashman

With this graphical representation, we intend to show what the authors conceive as most or ctice. For Clampitt et al., “underscore and explore” is the most effective

strategy because it takes from “tell and sell” the idea of selecting information to address central issues related to the change and from “identify and reply” the idea of listeningtaking into account concerns and feedback from employees.

Adapting the environment to enable better communication

Finally, Spector developed what he called “Power Equalization Steps” because he believes a main impediment to open and efficient communication is a large power distance in organizations (2010: 66). Spector´s model consists of seven steps to make communication more open and prevent organizational silence. It appears that upper management should be incharge of these steps because often, a lack of power decentralization leads to limited

Before describing these steps, it is important to define what organizational silence is. Spector defines it as a “lack of truthful dialogue in organizations caused by the

mption on the part of employees that candid feedback and open exchange of

Spray and pray

Tell and sell

Underscore and explore

Identify and reply

Withhold and uphold

“tell and sell” but the main difference is that managers are willing to listen to concerns and consider it.

ferent approach since the manager first listens to concerns before developing the message. Unfortunately, the individuals are often not aware

on´t communicate the information until it becomes really necessary. It is a policy of secrecy and control where information is seen as power and where managers consider that employees lack the ability to understand the “big

redibility with this method seems hard to achieve…

. Five communication patterns (Source: Clampitt, DeKoch and Cashman

With this graphical representation, we intend to show what the authors conceive as most or is the most effective

the idea of selecting information to address the idea of listening and

because he believes a unication is a large power distance in

organizations (2010: 66). Spector´s model consists of seven steps to make communication It appears that upper management should be in

lack of power decentralization leads to limited steps, it is important to define what organizational

“lack of truthful dialogue in organizations caused by the mption on the part of employees that candid feedback and open exchange of

35

ideas will have either no positive impact or negative consequences to the individual” (2010: 63).

A first step to reduce power distance is “delayering” where the objective is to remove various hierarchical levels so that communication is made easier. Then, “decentralizing”, which can be either combined or separated from “delayering”, is about giving decision-making power to lower hierarchical levels. A step further is to create an “egalitarian culture” by for example calling everyone by its first name or not having special parking and catering for executives. Moreover, “third-party facilitation” can also help reduce the power distance by having assigned people in the organization who take part into communication involving various hierarchical levels and who can suggest or impose rules so that dialogue is more open and trust is promoted. Furthermore, using “representation” involves introducing multiple hierarchical levels in the dialogue so that everyone feels part of the change discussion and effort. Last, “teamwork” is another equalizer because it triggers shared purpose and shared responsibility to bring people together. These steps developed by Spector really demonstrate another aspect of communication by not focusing on the delivered message itself but on behaviors and actions that can be taken to harmonize the environment where communication will occur.

Overall, we have seen in this section basic guidelines when communication change, linked to the way of delivering the message. Then, we have explored Clampitt et al.´s model and seen different approaches taken by managers to communicate change, each more or less effective. Finally, Spector´s “Power Equalization Steps” demonstrate the importance of a developing a good communication environment to facilitate open and truthful dialogue.

3. The need for leadership in times of change

What is leadership and why is it important?

After having seen the importance of communication, it is also critical to have not only managers but leaders to guide and empower people through the process. What is really leadership? For Spector, “at whatever level, effective leadership can be understood as a set of activities or behaviors that mobilize adaptive behavior on the part of members of the organization” (2010). In a change process, according to Kotter (1990), the challenge is “to combine strong leadership and strong management and use each to balance the other”. Leadership is especially important in times of change, because leadership involves aligning people, motivating and inspiring them, “keeping people moving in the right direction”. Managing involves “organizing and staffing”, “controlling and problem solving”, tasks that need to be done not only in times of change but also daily in organizations.

36

What is the difference between leaders and managers?

“Since the function of leadership is to produce change, setting the direction of that change is fundamental to leadership” (Kotter 1990). According to Kotter, managers and leaders have to accomplish three different functions: deciding what needs to be done, developing the capacity to do it, and ensuring that it is done (in Hayes, 2007). When deciding what needs to be done, leaders need to build a vision, setting a direction to where the company is going, whereas management will be more concerned with building concrete plans to achieve it. Paton and McCalman (2008) mention that a commonly found problem in change processes is a lack of vision and understanding when a conceptual framework is built. In developing the capacity to change, leaders need to communicate the vision, empower people so this vision is transformed into reality. Finally, when it comes to ensuring that it is done, leaders have the task of motivating and inspiring others, whereas managers will use control tools and problem solving. Kotter stresses the difference between leadership and management, but he also acknowledges that managers are often the ones that should also lead change, therefore triggering a “dual responsibility for management” (in Hayes 2007).

This dual responsibility of management is shown through the key managerial competencies identified by Buchanan and Huczynski (in Paton and McCalman, 2008). They stress the importance of having good communication skills and providing and sustaining motivation and leadership for everyone concerned by the change. Moreover, managers need to “facilitate and orchestrate group and individual activities”. According to them, negotiation and influencing skills are also critical to obtain consensus. Furthermore, planning and control are important steps that shouldn´t be forgotten. Also, managing is not only a downward process, it should be done upward and in groups, so stakeholders can communicate their concerns or ideas to their superiors. Lastly, knowing and being able to influence the rationale for change is essential. For Paton and McCalman, “people manage change, and well managed people manage change more effectively”.

How can leaders really trigger change?

Nicholls considers leadership as a tri dimensional concept (1994). He refers to the supervision day-to-day operations in a company as supervisory leadership or the “hands-on” aspect. For example, making sure that an order entry is well filled in, that no specification is missing. This aspect is about adjusting the management style to the competence and commitment of the employees. Then, strategic leadership is about creating an effective organization. For instance, making sure that the current Information System used by the company is truly effective or if there are better systems. It is usually an upper management´s role. Strategic leaders are aiming at “finding a better way” and at creating a climate so that things get done. These two aspects are specific to organizations. The third aspect,

37

inspirational leadership, can occur anywhere, it is about creating a vision and empowering people so that they understand this vision. A commonality of the three aspects is that leadership is an “influence process”.

For Nicholls, a definition of leadership that includes all three aspects would be “that activity that stimulates purposeful activity in people, individually or collectively, by changing the way they look at the world around them and relate to one another” (1994: 12). Whereas other authors claim that leaders need to be differentiated from managers, Nicholls defines a “managerial leadership”. For him, this leadership is both supervisory and strategic, and can be understood through a diagram.

Change Uncertainty ENVIRONMENT Fixed complexity

Strategic Leadership HEAD Doing the right things

Administration FEET Getting things done

Supervisory Leadership HANDS Doing things right

Collectively PEOPLE Individually Impersonally Personally

Figure 8 . Managerial Leadership (Nicholls 1994: 13)

“Managerial leadership” combines efficiency and effectiveness, getting things done but also “getting right things done right”. It is not just about filling in well the order entry, but also having a system that is quick and clear. However, there is an element missing to be able to talk about transforming leadership, which is of interest in this research. To become transforming, leadership must incorporate inspirational leadership by considering people as individuals and helping them deal with change and uncertainty. Transforming leaders do not just create a vision, they also empower others to act, and they become “vision enablers”.

ENVIRONMENT

Strategic Leadership HEAD Doing the right things

Inspirational Leadership HEART Inspiring by doing

Administration FEET Getting things done

Supervisory Leadership HANDS Doing things right

PEOPLE

Figure 9 . Transforming Leadership (Nicholls 1994: 13)

38

What should change leaders do?

Kotter developed a Change Management process focused on leadership and what needs to be done by leaders at different stages (1990). First of all, leaders need to establish “a sense of urgency”, stressing why change needs to occur. Then, they must “form a powerful coalition”; uniting people who will be committed to the change process and direct it. Once this team has been created, it is time to “create a vision”, something that leaders can effectively communicate to the rest of the organization. This vision must then be communicated to every stakeholder, so that they understand and acknowledge the need for change. It is also important to “empower others to act on the vision”. If the vision is communicated well but people feel they are not granted the power to act to implement this vision, then it is likely that the change won´t be successfully implemented. After, leaders should plan and create “short-term wins” since change takes time, and people could easily lose the initial focus and sense of urgency if no milestones are in place to recognize achievements along the way. These short-term wins should lead to “consolidating improvements and producing still more change”. The early wins can serve here as a way to induce motivation for further steps on the road of change. Finally, a last important step is to “institutionalize change”, reinforcing the change by showing its benefits until it become truly a part of the organizational culture (Kotter in Hayes 2007). Indeed, the maintenance of change aspect is also stressed by Spector for whom “at every stage of organizational change, leaders intervene to oversee and orchestrate implementation” (2010).

Boddy and Buchanan also developed a model consisting of different steps representing the core tasks that the “change agent” (or leader) should do throughout the change (in Paton and McCalman 2008). First of all, they stress the importance of identifying and managing stakeholders in order to obtain commitment from them. Once this is done, the change should have clear objectives so that stakeholders understand it and can truly commit to it. Then, the change agent needs to “set a full agenda” that gives a clear direction and actions that need to be taken by everyone concerned by the change. Also, “appropriate control systems” are important so that stakeholders are given the opportunity to give their feedback. Finally, the process of change needs to be planned, and this phase consists of different sub-phases: establishing clear roles, building a team, building support to reduce resistance and neutrality about the change effort, communicating, using power bases and making sure that the change is maintained afterwards. This model is quite similar to Kotter´s.

Moreover, Spector defines five core tasks for effective change leadership, referring to the leader´s actions, not to his personnality (2010: 190). First, he mentions again the importance of developing a vision, what he refers to as “clear and consistent sense of purpose and direction”. Moreover, change leaders should establish “demanding performance expectations” so that people know what to do and where they are going. Moreover, he also enlightens the importance of upward communication, but also “forging an emotional bond

39

between employees and the organization”, so that they feel committed because they really care about the organization. Finally, “developing future change leaders” because they will be the ones leading future change and the organization will need such people in the future.

Furthermore, Mansour Javidan mentions six roles that leaders play (in Sadler 1997: 146). They need to be visionaries, they need to have a deep understanding the current situation to be able to develop what the future will be. In addition, they should act as symbolizers, they should “practice what they preach” and put the organization´s interest before theirs. Moreover, leaders should be innovators; they should create an environment open to new ideas and be themselves willing to do new things. Additionally, leaders should be auditors that compare the performance of the organization against high standards. Along with this, a leader must be an ambassador that represents the organization externally. Finally, a leader should also be a mobilizer, he or she should “empower people to turn the vision into reality”.

Not one by multiple leaders

For Kotter and also for Kanter (in Paton and McCalman, 2008), leaders can be found throughout the organization, there is not one leader but multiple leaders. Spector agrees and indicates that “changing an organization at multiple levels and across numerous units is a challenge that requires distributed rather than individual leadership” (2010: 197). However, Kanter acknowledges that leaders are especially “crucial at the top”.

In this section, we intended to pinpoint the importance of leadership in times of change, how the individuals affected by the change need leaders to guide them throughout the process, trigger their motivation and support by relating the change process to the organization´s vision, something that can truly more everyone forward.

E) What have we learned?

In our theoretical framework, we intended to make our reader more familiar with the specific characteristics of ERP systems in order to understand in which way they trigger a real organizational change. Then, we presented through theory that such an important change often leads to a certain degree of resistance if the adoption process of the system is not well managed. We therefore described reasons for resisting, but also the forms resistance can take and ways to address it. Finally, stakeholder theory, communication theory and leadership theory, all referred to in Change Management, are of special interest to help understand how resistance can be addressed.

On the following page, we present a theory mapping to get a visual understanding of how the theoretical framework is organized.

40

Figure 10. Theory mapping (source: authors)

ERP

Integration of departments

Change of business processes

Requires people to change

Change in tasks Change in behavior

RESISTANCE

Why? What types?

Adressing Resistance

Facilitators of change

Stakeholder identification

Communication

Leadership

41

III. Research Methodology

In this chapter, we intend to discuss and explain to our readers the path we decided to take to conduct our research. We will thereby present our research design and explain the interest of this design in relation with our purpose. We will also depict the techniques used to collect our data. Finally, we will discuss the practical value in addition to the limitations of our method. Designing our own research methodology, something that would correspond to what we wanted to achieve, was not an easy process. We asked ourselves many questions about our way to perceive reality and how the approach we would take would influence our research.

In order to build our research methodology, we went through several steps. Considering our purpose of increasing understanding and establishing the benefits of a Change Management methodology in practice, we decided to use a deductive approach, looking first at theory in order to collect and examine our data with a real understanding of the value of Change Management. We also took a qualitative approach in our research. With a single case study and supplementary interviews with experts, our aim is not to build or confirm a theory; instead, we intend to analyze what the reality looks like and examine analogies and differences with our theoretical findings. This process served also as a way to investigate if there is a need for further studies.

A) Our philosophical perspective

We intend with our thesis to increase awareness of the benefits of developing a Change Management methodology in parallel with ERP adoption in an organization. Therefore, we focus our interest on the “business side of ERP implementation”, and not so much on the technical implementation issues. We see Change Management as a way to reduce resistance to change, to trigger awareness of the need for communication and user involvement. Individuals in the organization have an immense power because ultimately, their relative acceptance of the change will be what determines if the implementation is successful or not. The theoretical background is quite extensive, concerning both Change Management and ERP, however we decided to focus our interest on the resistance to change, user involvement, and communication aspects of the theory. We intend to describe and explain how a Change Management methodology can help businesses deal better with the “people´s side of change” (Hiatt and Creasey 2003).

We are observing human behavior and the consequences of different types of behavior on change acceptance or resistance. It is important to interpret this behavior to be able to carry out a change process efficiently. For instance, if a manager gets irritated when realizing that his team is resisting change, he probably will worsen the team´s response to change by showing no will to understand why his team reacted the way they did. We want to understand behaviors related to change, and how they can be understood and managed.

42

For us, social entities such as organizations are built by social actors; they are not external to these actors but a human construction. For example, an organizational culture is something that doesn´t belong to the organization as an entity, it belongs to the people who constitute the organization because this culture has been built and evolves through an organization´s people. This view explains the decisions we took to proceed with our data collection process, as we will mention later on.

B) Our methodological approach

Since we intend to understand patterns of behavior, collecting and analyzing qualitative data is a richer source of information for our purpose.

Our aim is to increase awareness of the benefits of developing a Change Management methodology in order to reduce resistance in an ERP adoption process, so we decided to present and analyze our data after our theoretical framework. In addition, our interviews and questions are based on theoretical issues so it is important to give this framework first so that the questions are asked in a context understood by our readers.

Moreover, we observed the behavior and management of individuals in an organizational change environment, therefore we decided to focus our data collection on a single organizational entity where we could identify these different stakeholders and understand their behavior. The challenges of ERP we believe could be well observed through a single case study. Exploring a single organization is interesting because you can capture different point of views on a single even, and examine, compare and analyze these different behaviors. For example, when asking two different employees about how they experienced the change, maybe one will have a positive attitude towards it whereas the other person will have struggled a lot. Comparing the behaviors and trying to understand where the differences come from is something that a case study of a specific organization allows us to do. However, as we became more aware of the ERP challenges, we decided to proceed to a more in-depth investigation through additional interviews and questionnaires with experts.

Even though in-depth knowledge could be built through our case study, having additional interviews with experts, and observing similarities and differences in point of views could give us a wider understanding of these challenges. These interviews and questionnaires allowed us to be more critical concerning our findings and analyze our data more efficiently than we would have done with our case study by itself.

43

C) Techniques of collecting data .

1. Secondary sources

The discovery of our area of focus brought us to, first, look at secondary sources in order to gain knowledge before engaging into our data collection. We used books about Change Management, information systems and organizational change. We also read articles about these areas of concern, mostly internet-based articles.

When using secondary information, we have been very careful with the use of internet and we always verified that the information was reliable. For instance, most of our online articles about Change Management or ERP systems come from CIO, which is part of IDG (International Data Group), the largest technology media company worldwide. Both the magazine and its website have received many journalistic international awards (see http://www.cio.com/about-cio). Moreover, we mostly worked with books, and when using literature, we verified the curriculum of the authors. In fact, it was important for us to use books related to Change Management written by scholars who have also worked for companies so they have experienced change in practice. We have also used a few articles that were part of recommended literature in previous classes we have taken. Finally, we used some presentations made by Richard McAndrew, our former Information Systems Management teacher that has experience both as a scholar and as an executive who has been implementing ERP systems and dealt with user resistance for many years.

2. Primary sources

Our empirical data consists of primary sources of information in order to understand the impact of Change Management in companies, and to what extent a methodology could be found.

Interviews and Questionnaires

We decided to use a semi-structured interview design, interviewing five persons in the organization concerned with the ERP adoption, and the external consultant in charge of the implementation. We also decided to conduct supplementary interviews, apart from our case study work, with experts in ERP implementation and Change Management that could give us their insight about future trends and their understanding of the importance of Change Management. We decided to use semi-structured interviews because of the richness of the information we could gather through personal contact with our interviewees. A main advantage of interviewing people is that many issues or concerns you wouldn´t think of

44

beforehand can appear as you discuss, and you have the possibility to explore these areas of concern by asking additional questions. However, we also sent questionnaires with open-ended questions for experts who didn´t have time to answer our questions in an interview way. These answers proved also to be very useful and exploitable for our research.

Table 1. Interviewees for the Mercodia case study

Name Position Christine Müller

System administrator of HansaWorld

Christina Axelsson

Vice President, Managing Director of Marketing

Helene Hagberg

Project Manager for the MPS (Master Production Scheduling) module implementation in 2007-2008 and Production Manager

Ann Sofie Andersson

Product Manager in the Marketing Department

Agneta Larsson

Production Planner

Björn Schwab

Consultant

At Mercodia, we conducted a collective interview with everyone mentioned in the table above, except Björn Schwab who could not be interviewed with the rest of the interviewees, so he was contacted through Skype a few days after.

The questions asked at Mercodia were open-ended, and the interview was semi-structured. We prepared some questions, but many questions arose during the interview, and even between interviewees, which was very interesting.

Some examples of questions that were prepared beforehand are:

- Before implementing ERP, what did you think the benefits would be for your company?

- Did you experience any resistance from people before going live / after going live due to the system?

- What was the main challenge during this process? - If you could start the process all over again, would you do something differently?

45

Table 2. Experts contacted

Name Company/University Position Type of data collection

Richard McAndrew -FH Joanneum International School of Business -Graduate School of Business at California Lutheran University -ECE Lyon -Pacific Business Methods

-I.T. Emphasis Leader -Teacher -Teacher -Owner and founder

Interview through Skype

Bert Spector -Northwestern University (Boston) -MIT -Inseead

-Associate professor of organizational behavior -Visiting professor -Visiting professor

Interview through Skype

Daniela Rausch HansaWorld International Education Manager

Interview face-to-face

Stefan Possnert Oracle Consulting (Kista, Stockholm)

ERP Practice Manager Interview through Skype

Alex Abbate Abbate Consulting Independent IT advisor Questionnaire

Robert Paton University of Glasgow Business School

Professor of Management and consultant

Questionnaire

John Hayes -University of Leeds -Aarhus School of Business -Copenhagen Business School -COBRA (Center for Organizational Behavior Research and Analysis)

-Professor of management studies for MBA programs -Change Management teacher -Change Management teacher -Director

Questionnaire

Bennet Lientz UCLA Anderson School of Management

Professor and MBA student advisor

Questionnaire

James McCalman Chief Executive at Windsor Leadership Trust

Reader in organizational behavior

Interview through Skype

46

For the interviews with experts, we also used a semi-structured type of interview, but the same prepared questions were asked to all of them, so we could identify patterns, differences, and similarities. Indeed, some have exclusively an ERP related experience, some have knowledge both in ERP implementations and Change Management, and others have expertise in Change Management mostly. Therefore, we could assume that these different backgrounds, even if basic questions asked would be the same, could lead the discussion into different directions.

We believe it is important to present the questions we asked these experts, because they are built upon concerns that are linked to our theoretical framework, and because they were meant to obtain a deeper understanding of issues related to ERP adoption processes and therefore change:

- According to you, who are the most important stakeholders when implementing an Information System package such as Enterprise Resource Planning system in an organization?

- What do you perceive as the biggest challenges when implementing such a system? - When implementing an ERP system, to what extent can user resistance be expected?

In which forms? - What do you think are the main reasons why people resist organizational change when

experiencing an ERP implementation? - In general, how do you think this resistance should be addressed? By whom? - Are there aspects of organizational change that leaders tend to underestimate? - Have you seen many companies where communicating change was well done? How

was change communicated, what made the difference? - Do you think companies in general have become better at managing organizational

change than they were (10 or 15 years ago)? - How often have you seen companies that use a Change Management methodology? - If you could give only one advice to a CEO who decides to implement an ERP system

in his company, what would that be?

D) Ethical considerations

We used primarily qualitative interviewing as primary data. This implies that we needed to consider important ethical issues due to the implication of our interviewees in our final research. For instance, when we started to contact our interviewees, we always made sure to present ourselves, give the background of our research and our purpose, and explain why we selected them as potential interviewees. In addition, since we used semi-structured interviews, we sent our framework of questions beforehand so the interviewees had a clear idea of what we wanted to ask them, and to make sure they were willing to answer these questions. We tape-recorded all of our interviews, and this was of course agreed upon beforehand with the interviewees. Moreover, before handing in our final research paper, we

47

sent a copy of our thesis to each of our interviewees so they could verify quotes, ideas, and any thought that we had transcribed in our paper. In addition, we were always open to suggestions and comments.

Moreover, we are aware of the fact that the selection process of interviewees has its importance, especially in terms of validity of the data. For our case study, we made sure to interview different employees so we would get a broader picture of the ERP implementation. We got in contact with Mercodia through HansaWorld, their ERP vendor, and Mercodia is a pleased customer so we could assume that the implementation had been a successful process. However, examining the reasons why this implementation had been successful was of interest for us since identifying key success factors would also point out what should not be done in practice. Moreover, additional experts we interviewed were selected upon their knowledge and experience in our area of interest. It was essential for us to interview people who were both scholars and professionals. For instance, most of our interviewees are both professors and professional consultants. Through our data collection, we intended to build a link between our theoretical framework and working practices so the results of our research could be of interest for both practitioners and scholars.

48

IV. Empirical data

A) Introduction

This chapter will consist of two different parts. First, we will present our case study conducted at Mercodia, a pharmaceutical company located in Uppsala, Sweden. Afterwards, we will present the trends and observations made by experts in ERP and Change Management concerning ERP implementations in a more general way. We intend here to give to our reader a deeper understanding of the issues and trends linked to ERP and change. This chapter should allow the reader to consider theory with a different perspective, observing how implementations occur in “real life” and what is happening in organizations.

B) A case study at Mercodia

Mercodia is a Swedish-based company that develops, manufactures and distributes diagnostic immunoassay kits, kits able to detect a substance by using an antibody reactive with it. The company was founded in 1991 by the president Erling Holmlund and vice president Mona Österberg, and its growth has been exponential, especially since 2004. Mercodia´s headquarters are located in Uppsala, Sweden. Mercodia exports 90% of its production to more than a hundred countries around the world and they have an American subsidiary based in Winston Salem, North Carolina.

When the choice of economy system was to be made in 2004, Mercodia chose HansaWorld and their ERP system. One of the most important criteria then was the compatibility with Macintosh and that it would give full control over data flows, inventory and lead times. HansaWorld was chosen due to its economy and order-handling ERP modules. In 2006, Mercodia turned to HansaWorld again to buy an MPS (Master Production Scheduling) module and after a test period during the autumn of 2007, Mercodia went live with the system.

As the reader will be able to observe, this case is interesting to identify good Change Management practices. There were no major problems throughout the process, but it appears clearly that this was due to the way the change was managed. The interest of such a case is that instead of identifying bad management practices in a problematic implementation, it is possible to identify the reasons why people accepted the change.

Getting started with a new information system At Mercodia, people have always worked with Macintosh computers, and when they started thinking about changing their old system, it proved to be a problem. In fact, when starting to look for an ERP system, most of the vendors provided only PC-based systems and nothing for Macintosh. Christina Axelsson, Mercodia´s marketing and sales manager, got a call from HansaWorld one day, and this vendor caught her attention mostly because they mentioned

49

their system could also work with Macintosh, which would mean not having to change all of the hardware in the company. This would limit the total cost of ownership of ERP. Moreover, Mercodia was not only thinking about the present situation but also about the future. Indeed, the company would start using economy, invoice and ordering modules, but they knew that there would surely be a need in the future for an MPS (Master Production Scheduling) module. The vision they had was quite clear, and top management was not focused only on short-term but also made sure the ERP system could grow in concordance with the company´s growth. In fact, HansaWorld´s ERP is composed of different modules. Back in 2004, Mercodia was still a very small company, consisting of not more than 20 people, so implementing all modules at once would have been impossible, due to limited resources.

Mercodia heard about the vendor because HansaWorld was implemented in many companies worldwide, and it could be implemented in the US, which was important for Mercodia, having a subsidiary there. As mentioned by Christina Axelsson, “let´s say it was the best system we could find at that time”. The initial installation took only a month and a half, the old system started to be converted in July, and the process ended mid-August. Nevertheless, this initial implementation did not involve an important organization change since there were very few employees so not many people were using the system, it concerned only a couple of people back then. Therefore, the case will focus on a specific module implementation in 2007-2008, the MPS.

Mercodia started to think about this module early, even back in 2004, it was already in people´s minds that someday there would be a need for it, but things materialized really in 2007…

“The company is growing; we cannot work as we do today. At that point, in a few years, we can see that manual systems will not be enough for us. There won´t be a person who can have the overview of the products that are being produced or manufactured. So we decided to have a project, and we started with pre studies first of all” (Helene Hagberg, Production Manager and Project Manager for the MPS implementation)

Mercodia visited three other companies that were working with different systems, with different degrees of success, to have a clearer idea of what would be the best fit for Mercodia. It can be quite hard to picture the impact ERP will have on a company, and Mercodia felt the need to have external opinions of people who had implemented it before. Another company using HansaWorld caught their attention and appeared to be the best option for the company. Moreover, every company they visited gave the same advice:

“What they all said, if you sum it up, it was that: be sure what kind of processes you have before you install the system, know your own processes” (Helene Hagberg)

In fact, as mentioned by the project manager, one hard thing when looking for a vendor was the discourse of salespersons who tell you that you can get whatever you want. However,

50

finding out what is needed and “what you want” is not so easy. Therefore, the next step in these pre studies was to identify and understand well the production business processes. For this, Mercodia hired a consultant to help in this important task. This phase proved to be very helpful in order to build clear requirements.

“So we just mapped and we explained each process in steps, and from that drawing and those written processes, we made our specifications, to actually give to Björn [the consultant who worked with Mercodia throughout the implementation] and say: this is what we would like to have, this is important for us” (Helene Hagberg)

Once the processes we mapped and well understood, writing down the requirements for the project manager proved a lot easier. Having a clear picture of what the processes looked like made also clearer what the company needed the system to provide. For Björn Schwab, the drawings of the processes were very useful to get a clear overview of what Mercodia wanted. This also reduces the risk of having a system that will not meet the requirements, and therefore not adapted to company´s needs. However, this business processes identification seems not to be something done by every company adopting ERP.

“It is not what you get in all cases. Many companies they don´t go through all this, setting up their processes and any documentation, it´s non-existing. If you go higher in the sizes of company you´ll find this but for many of these companies this is a non-issue” (Björn Schwab, ERP consultant)

Moreover, it was important to keep everyone informed about the status of the project, not only the manufacturing department employees who were of course mostly concerned by this implementation, but also the rest of the employees. Involvement and information played a great role in the way this change was accepted. Even if only production people would use the MPS, it could affect the rest of the company, and the module would be linked to the rest of the system. Therefore, overall information was communicated at employee meetings once a month.

Also, there were meeting with the steering group who had decisional power, whose approval to go on with the project was important. The project manager mentioned the importance of having these people´s support to go on.

Finally, as this implementation was organized as a project, a project team was formed from the beginning that worked closely together throughout the project, and even after the project was completed. Team members were selected from different production areas in order to get a good overview, with production planners, technicians, operators, etc. This enabled to obtain regular feedback and ideas from most of the people directly involved in the adoption process.

“We didn’t chose people that are good in projects, that is something we learnt afterwards that they were… but I mean we had really people with good skills who knew what they were doing and also very dedicated in what they were doing” (Christina Axelsson)

51

Moreover, for the project manager, it was essential to have this team involved also afterwards in the administration work. The project is ongoing; it cannot end when going live because there is still a lot of work to do before reaching optimum performance and complete adoption.

In order to become familiar with the system, the training process was done step by step, as explained by the project manager. Mercodia had a lot of support from Björn Schwab, the consultant who worked for HansaWorld. The training really started four or five months before going live. Every unit in the production department tested independently their own “part” of the system, and once this was done, the testing was done in a more global way, integrating the parts, putting it all together.

“I believe that we could have tested, you can always test 110% … but that´s the way it is. Then we decided, ok we´re going live now, and we´re gonna take, maybe a year to see how it works. But I think that we tested the system as much as we could at that point” (Helene Hagberg)

The consultant´s work in this process appeared essential to everyone. Before this implementation, another consultant was working with Mercodia, and didn´t have the same skills, which made earlier progress with the system less easy and led to more problems.

“Competence, personality and everything, just fit” (Ann Sofie Andersson, Product Manager in Marketing Department)

For Björn Schwab, most of the consulting was done on site at Mercodia, and he spent approximately 300 hours in one year for this implementation.

“It was more or less an ongoing discussion with them about detailed level because the requirements were quite detailed, and let´s say in my world, you can get the same thing by doing something different, and you still meet the requirement of the customer. But you tweak the requirement just a little bit. But the main thing was that all these processes that had drawn up were very helpful because it gave me an immediate view of who did what, and in which order they did it. And then the 80 pages documentation was just, ok, more detailed level, the detailed requirements that was necessary to do the development” (Björn Schwab)

Was it necessary to work on site? Very much. In fact, most of Mercodia´s processes, working in the pharmaceutical industry, are very precise and timed. There were processes that would last four hours and do so every day at the exact same time, processes that would be performed by one person, others by a person and a machine, and processes that would be stopped on weekends… so there were many special requirements that had to be taken into consideration. Observing and designing the logic of the system was done in a partnership way mostly with Agneta Larsson, the production planner, because she knew all the rules involved with these processes. Another advantage of working on site is being able to spend time with end users, because some things, no matter how detailed the requirements are, are important to discuss

52

with end users to understand and adjust. This step shows the extent and importance of communication between end users and implementers.

In this case, training and testing were happening at the same time. People were going from a paper-based production to an automated system, so it was a big step. Therefore, while testing, the consultant could see what was maybe missed, misunderstood, or what could be fixed a bit better. The importance of having a consultant´s expertise in the change process can really be observed in this case.

As mentioned by the project manager, the team was very dedicated, so there were very few problems. If there were small problems, it was mostly linked to changes in the company´s size and therefore organization, for instance with production planners. Before, people would plan their work themselves, whereas with production planners, planning the work was delegated to someone else.

“It´s a different flexibility, but you have to be dedicated to the system. Then you have the flexibility, but in the system” (Helene Hagberg)

Solving these minor issues was mostly done through a lot of talking and patience. The time to go live seemed adequate, even if it involved a lot of pressure. Mercodia was also strengthening up its regulatory system and quality system as part of the MPS, so it was a complex process. Moreover, for Helene Hagberg, it was the first project of such a magnitude she was working with, so it was challenging.

After going live, it was time to collect feedback in order to improve gradually everyone´s use of the system to reach full potential.

“We took a lot of input at that time, and we used the administration group as where we addressed these questions to solve... I think that was very important, very very important to address the problems, what is working, what is not working and then immediately solve it” (Helene Hagberg)

In fact, an ERP adoption does not end when going live, it is very important to be aware that the change process continues after going live because there is still work to do to induce user acceptance.

Christine Müller, the system administrator for HansaWorld, is the person who knows the system best, and she has concentrated her attention on the CRM (Customer Relationship Management) mostly. CRM is usually a different system from ERP but since HansaWorld´s product combines ERP and CRM, we thought it was important to mention it. The company had implemented the CRM before the MPS, but it had never been really adopted because no one was taught how to use it.

53

“We had like 2, 3, 4 different ways of using the system and to get the same product in the end, so if you were looking for information, there were several ways to get this information. And Christine she collected everything and make a summary, and then decide the next step or advice us which would be the right way to go, the smartest way to go, to write all those instructions and everything” (Ann Sofie Andersson)

Due to the fact that the CRM was there, but that it had never been taught to employees, there were a few problems when the system administrator tried to trigger use of it.

“I think that it was a lot of “Hansa is bad”, “it doesn’t work” and it is many things that are wrong, and so they were not satisfied with the system. So that took quite a lot of work and energy to convince the people that the system is very good, you can take out a lot of information out of the system, but you have to understand first how it works” (Christine Müller)

This resistance was due to a lack of understanding of the module, so the system administrator´s objective was to make people understand in which way it would be useful for the workers, therefore triggering acceptance.

Reflecting on the MPS implementation

“I think with a system like this there are always things that you can learn and as the organization changes. Then you have to make sure that your system is still up to date. But I believe that people know what they are doing now. But I think it took us about a year with minor issues that we had to solve from the point that we went live with the system” (Helene Hagberg)

What has the system brought to the company and its employees in their work? Now, they can store all kinds of information, there is a history record of everything that happened, for instance what a customer ordered before, and this information can be found much faster . The difference between the old and new system could be observed right away.

An important aspect was also that there were no hidden costs linked to the system. The consultant knew exactly what Mercodia wanted, due to the clear specifications, and therefore the planning of consulting hours was almost perfect… since he ended up spending 2 or 3 hours less than planned.

“I wanted to have it clear. So, we actually ended up one hour less so I think that was fantastic, that was absolutely fantastic. Björn had a very clear vision of how many hours he would put” (Helene Hagberg)

For Mercodia, there were three aspects that really make this adoption successful: drawing and knowing the business processes, having a dedicated team, and having a dedicated and competent consultant. The system now makes the company less vulnerable, especially if

54

someone quits, since the system enables to trace back the information. In addition, Ann Sofie Andersson mentioned a new “tool” that has been very useful, using the system also outside of the company.

Björn Schwab comes once every two or three months, but his work now mainly consists of improving functionalities, some things with the MPS, but no major issues. Moreover, Mercodia has its own implementation group so the maintenance is mostly handled internally.

Today, the company experiences the benefits of the system and continues to improve its use of it. They are ready to focus on a difficult issue: making their American subsidiary work more with HansaWorld. It is challenging because they are far away, which makes it more complicated to train them, because they sell the products only in the US whereas HansaWorld in Sweden sells its products worldwide and finally because they use PCs and not Macintosh, so the information looks a bit different on the screen. Overall, there were other priorities until now, and with time and resources focused on this issue, it should not be a problem too difficult to handle.

“We didn´t have the time to sit down and go through the system and to try to get them on the same page as we all are right now. But I think that´s going to work as well in the future some time” (Christine Müller)

C) What counts in an ERP adoption process

The case study of Mercodia´s ERP implementation has stressed important aspects of adoption processes. However, it seemed important to get a more general and deeper understanding of these issues by talking to ERP and Change Management experts, and seeing if practices observed at Mercodia are things considered important for experts. In this part, we will present the discussions we had with experts and the issues that were relevant for our research.

1. Identifying and assessing the importance of the stakeholders in the ERP adoption process

Change Management theory refers to the role of stakeholders extensively. Therefore, a central question to ask our interviewees was whom they consider the most important stakeholders in an ERP implementation. Stakeholders often mentioned were the end users, business leaders, project manager and the ERP vendor, but it seemed also quite difficult to identify one single stakeholder as more important that the others.

For McAndrew, the most important stakeholders are the “functional owners”, which he meant include senior management such as the CFO, VP of Manufacturing, but maybe the most important stakeholder according to him is the CEO. These people often are the ones deciding on the implementation, and they base their decision to implement ERP on the

55

company´s strategy, on the company´s vision and mission. Often, they have a leadership role in such implementations. ERP is important for them because “it is affecting the organization that they are leading”. Spector and Possnert also mentioned the importance of senior executives in the adoption process. Possnert refers to the people with the funding. If it concerns a traditional ERP financial system, he mentions that the CFO or someone like him has the operational responsibility and functions as a “key stakeholder”. For him, the implementation needs to be firmly and heavily anchored. In Mercodia´s case for instance, it was very important for the project manager to have the “functional owners” support throughout the process and they had a say in the process through the meetings with the project team, making sure the process was going in the right direction.

Hayes acknowledges it is possible to identify stakeholders by taking different perspectives depending on their interest. First, he mentions those stakeholders who are motivated to drive the change because of the benefits they can anticipate. These stakeholders are the “functional owners” mentioned by McAndrew and most of the interviewees. Hayes explains this with an example:

“In Rumania the state has privatized state owned banks; many have been acquired by overseas institutions. The new (foreign) owners of one bank recognized that many of its systems were not fit for purpose and implemented an urgent change program. They had recently (and successfully) implemented a new ERP system in another Central and Eastern European bank it had acquired and decided to copy that system - with the absolute minimum of changes – and implement it in the Rumanian bank. Employees in that bank were not happy, While they recognized the need for an ERP system they wanted to be involved in its design, but the new owners had the power to impose the system they had implemented elsewhere (to save time) and push the change through. So in terms of making the change happen the most important stakeholders were the new owners” (Hayes)

This relates to the idea that leaders have power, but as Kotter suggests in his six methods for tackling change resistance (1999: 44), “explicit and implicit coercion” where the time issue is key and where the change initiator has extensive authority, the approach may work. However, it is a dangerous road to take since users will feel the change is forced upon them. For Hayes, a second perspective is to identify who has the knowledge to design, implement, and make the system work. For him, many stakeholders are important in that sense, especially ERP implementers and end users. This was clearly seen in the case study, with the intense communication between end users and the ERP consultant in order to make the system work in the end. Finally, a third perspective is to identify those who have the motive and power to resist the implementation. In the case of ERP, the end users certainly have power to resist since they can obstruct the system by not using it properly. In addition, they may have the motive to

56

resist if they were not informed enough and involved enough. For Possnert, an ERP consultant for Oracle in Sweden, those who have the power to resist the implementation, and specifically the end users of the system, are very important. In fact, “they have the ability to make this either a success or a failure, depending on their attitude to the system, their willingness to adopt it and so on”. For Paton, the difficult thing is to say who is not a stakeholder in these implementations, but he mentioned particularly the end users´ importance. Lientz and Spector agree with this mentioning the end users.

Rausch stresses the important project manager of the customer. She explains that this person on the customer´s side works together with HansaWorld’s project manager and there is a need for regular meetings throughout the process. The project manager of the customer is central because he is in charge of coordinating everything that needs to be done on the client´s side. She points out the benefit for the vendor of having one main contact that knows the processes, the status of the project, where they need to go and also someone who has the authority to do sign offs. At each step of the implementation process, they work closely with the client´s project manager and use sign offs to make sure agreement is reached. This ensures to stay on the right track. Another benefit with this is that “ideas are sometimes difficult to translate into words so we write down and say: is this really what you want?” This is about verifying there is common understanding, something that could be well observed in the case study, and proved to be very important.

However, Rausch also mentions, “in every stage there are different people involved” , with the project manager as a main link between these stakeholders. McCalman brings an interesting point of view by saying that there are indeed many stakeholders in an ERP adoption process, but assessing who is more important that the other is not possible and is not a goal.

“They all have to work together. No one stakeholder can take presidency over the others” (James McCalman)

2. ERP as a challenging adoption process

Most challenges mentioned by experts involve communication problems. For instance, difficulties to make people understand the need for change, but also aligning and getting user commitment. On the vendor side, a major challenge is to understand the client´s requirements and to translate them into a solution. Moreover, the ERP business has evolved, some companies are now replacing old ERP systems for new ones. This implies that business leaders need to understand that the new system won´t function in the exact same way as the old one, and this is also where Change Management is needed.

Paton mentions the importance of aligning people across the silos. ERP is about integrating systems that were separated before, but this cannot work if the systems are integrated without

57

people being aligned. Often, the importance of “meeting the needs of the organization as a whole rather than the functional silo in which any given component of the system resides” is underestimated. It is really about reaching goal congruence throughout the company.

For McAndrew, the most challenging characteristic of ERP implementation is about “understanding your processes and then designing the new ‘as is’ so to speak, the new processes, and then getting people to participate and implement and adopt, embrace and accept”. In the case study, understanding the processes was central; the whole adoption process really began with this step. Employees can see process change as very disruptive, not the ERP technology itself. Often, workers are concerned with the way their tasks will change due to the new system. But as McAndrew explains, if employees understand why it is implemented, how the company can benefit from it, then acceptance can be reached. As seen in the case study, reaching employees understanding and acceptance is not something that happens in one day, it is a long process.

Bert Spector agrees and the most challenging aspect when adopting an ERP system is the organizational change that comes with it. It is about having people understand that it is not just about technology, it is about the way people do their work. Problems often come from companies that do not realize this and “implement the same processes the same way they are now so they do not get the benefits”. Possnert also mentions this issue in some situations, people stay “stuck in the old thinking”. Again, it ties back to people not seeing the benefits of the system, often because they were not giving the means to understand.

For Hayes also, “gaining the commitment of all those who will have to use the new system once it has been designed and implemented” is the most challenging aspect. As stated before, it is a lengthy process, and it clearly needs to be managed. Building a project team that includes a variety of people involved in the change process with different backgrounds, as it was done at Mercodia, is one of the tools that exist to gain this commitment.

Possnert, an ERP consultant, argues that the biggest challenge is to “get your business to adopt the system to that extent that you still can call the system a standardized system”. The implementation is a two-way process that involves the client and the vendor. The system needs to be customized, but there must also be a willingness to adopt a standard way of working and the standard processes defined in the system”. Otherwise, the cost of ownership could turn out to be very expensive.

According to Rausch, understanding what the client wants, translating the requirements in terms of software functions, and figuring out how it will be implement and adapted is challenging. Many of these aspects are already dealt with in the sales process but after that, she means, HansaWorld needs to be very careful to find out exactly what the customer wants and needs. Sometimes the client needs something they had no idea that they needed. Communication mistakes can also happen, therefore, documentation is very important. It is really about handling the expectations. This is clearly a two-way process, the vendor having experience in implementations and being able to translate business requirements into software functions, the client knowing his processes and looking for ERP for reasons tying back to

58

company strategy. In the case study, the relation between the ERP consultant and Mercodia was optimal in that sense.

Another challenge concerns the going live phase, because it should not be considered as the end of the journey, it is followed by what Possnert calls a stabilization period. Sometimes he describes, the implementation comes out a bit different from what the customer expects, so after going live, small changes may have to be made.

Rausch mentions a new trend in ERP sales. Since the industry is now about 25 years old, there are also ERP replacement sales, companies changing their old ERP for a new one. In this case, it is important to realize that the new system won´t function in the exact same way as the old one. It will induce a change in employees tasks, maybe function, so change needs to be managed as well.

Overall, the experts mention some different challenges, but these challenges all relate to understanding, communication, and leadership issues. To align people across the silos being the different departments, people need to understand the value of the system for the company. In order for them to understand, it is important to know the business processes in place before designing new ones. Moreover, even if the system will be a bit customized, it needs to stay a standardized system, otherwise the value added of it is likely to decrease. Once going live with the new system, it is not the end; some problems that could not be identified beforehand will need to be addressed at this stage. That is what Björn Schwab was referring to in the case study, it is impossible to identify every minor issue before going live. Finally, one could think that it will be an easier task for company to switch from an old to a new ERP system, but the system will be different. It will change the way people do their job, so the issue will remain in this particular case.

3. Reasons for resisting, ways of resisting, and how can it be reduced?

According to Lientz, “many firms do not recognize the strength of the resistance to change”. This was an issue extensively discussed with experts to understand what they perceived as the reasons why people resist change, and in which forms it could be observed in practice. Finally, we also asked them how this resistance could be managed or reduced.

Why do people resist change?

McAndrew who has implemented many ERP systems has experienced resistance to change on many occasions: “I would say there is a high frequency of resistance, and that resistance could be at many levels across the organization”. According to McAndrew, even though resistance is more common among employees and middle managers, he has observed it also at

59

higher levels in the hierarchy. For him, there is resistance often because people do not understand what the rationale behind the change is, what the company is trying to achieve.

It hasn´t been sold to them. They haven´t accepted. So, I suppose they can understand it but they need to go beyond understanding, they need to be sold, you need buy in. And if they don´t see the rest of the organization being committed to it, if they don´t fully understand, if they feel that´s being forced on them, if they´ve not been able to accept the change, and everything that goes with it, which is fear and uncertainty and everything else, then you´re going to get many different forms of resistance during the ERP implementation (McAndrew).

Paton doesn´t like the term resistance because of its very negative connotation. It makes it sound like resistance should be fought, whereas it should be understood and there are many lessons to be learned from resistance. For Paton, the users concerns are often understandable since they are often related to unsuccessful past experiences. If they have seen in their company earlier changes that were not successful, obtaining buy in might be more difficult. Hayes shares this view. According to him, if the users see clearly the benefits of the new system, then, they will usually support the change. However, sometimes, even though end-users see the potential benefits of the implementation, they are pessimistic and don´t believe these benefits will be observed in practice. For Hayes, one reason for this type of behavior could be a lack of confidence in the change leaders.

As mentioned before, with ERP productivity tends to slow down right after the implementation, and “change is often seen as impeding present performance. There is pain before any gains and folks are measured on present performance – not future”. For Possnert, people are afraid of change, and it is a natural behavior, they are afraid of potential threats that could appear with the new system. Abbate shares this view, acknowledging that “people tend to rely on what they know, everyone is afraid of the unknown”. Hayes gives a concrete example of a company that implemented an ERP system where stakeholders were afraid of the potential threats induced by the system´s implementation.

While most stakeholder groups recognized and understood the reasons for the change, some saw the change as a threat to their existing position. For example, experienced programmers feared that they would lose status when new Oracle competent programmers were recruited. Also several groups of programmers and users were informed that they would have to retrain in order to retain their positions. Others anticipated an increased workload over the short term. There were also employees who anticipated job loses following efficiencies that would be delivered by the new system (Hayes).

Even though the need for change was recognized, for the individuals, it seemed hard to see the benefits at a personal level because the change was mostly seen as a threat for their jobs. For Daniela Rausch, it is not so often that end users resist change. Often, the challenge comes

60

from decision makers. “They want to have the processes exactly the same way as it was before, which is not possible, just because different systems work different ways”. If this type of behavior appears, the vendor needs set the expectations with the client, telling him what the system can do, what he should do, and how they can work with the new system. Experts mention various reasons why users resist change. These reasons seems to relate to a lack of information and education about the new system, therefore leading to limited acceptance. For McAndrew, the rationale for change has not been sold to the users, so they do not understand and therefore resist. Paton notices the negative connotation of the term resistance, whereas a lot can be learned from resistance. When users resist even if they understood the need for change, it may mean that they do not trust the change leaders. Moreover, employees may be afraid of potential threats such as job replacements. Finally, Rausch gives a different view by stating that the resistance may come from decision makers more often. Even if they understand the need for ERP, they do not understand that business processes will necessarily change.

Which forms can resistance take?

Concerning the forms of resistance, we should start with an example given by McAndrew in one implementation. As mentioned before, resistance comes usually from employees or middle managers, but in this particular case, the Vice President of Manufacturing was resisting change. The CEO of this company had decided to implement ERP, and the VP of Manufacturing was reluctant to changing the way the company was doing business. From the very beginning, he was involved in the selection process to find a vendor, but “he was involved just because he had to, because the CEO had mandated this”.

For McAndrew, it started in the planning phase when the VP of manufacturing would communicate this resistance through talks with his middle managers, and that cascaded down to his employees… so it was not just him anymore who resisted but also his staff. Paton refers to this form of resistance as misinformation. Then, when implementing the system and going live, they are always problems; it is a “bumpy road” as McAndrew refers to it. But this person used these problems to justify his resistance and why he thought they shouldn´t be putting an ERP package in the company. “It is: I told you it won´t work and now it doesn´t work, and I´m showing you it doesn´t work”. So at this stage, the resistance was shown through giving up. People “dragging one´s feet” is a form of resistance that Paton also referred to.

Another problem came from the training that was done by someone else than the vendor and people were not properly trained. They were trained too soon and finally, when they went live with the system, no one could remember what they learnt. Consequently, “the resistance of the people was giving up and not trying, blaming the system and continuing to do things that corrupted the system and blaming it on the system”. Possnert shares this view since he

61

states that resist can be seen through ignoring suggestions and keeping to do things as before, but with the new system.

In this same case, McAndrew mentions that CFO was the complete opposite of the VP of Manufacturing since, even though there were problems, he was supportive, involved, promoting the system and getting his people involved. This case can be considered as an extreme case, it is not an everyday situation, and therefore, the forms of resistance observed here are not found in any ERP implementation, but it clearly shows how things can go wrong, and how resistance can cascade down. If a manager resists, chances are his employees will resist also.

McAndrew also mentioned typical forms of resistance that he experienced in many cases. First, there can be a lack of commitment before going live, people not “buying in”. Then, once the system is operating, people “complaining it doesn´t work, not accepting there will be bumps”. For Spector, people just “won´t do it” if they do not understand the reason why ERP is implemented.

An important aspect mentioned is that resistance can cascade down. For instance, if a manager resists, his people are likely to resist also. Misinformation would in this case be a powerful tool. Dragging one´s feet is another display of resistance. Once going live, usual problems that appear can be used to show the system as not working. It may also happen that workers keep doing things the same way they did before, which ultimately corrupts the system.

Identifying ways to reduce resistance

The situation has to be managed along the complete implementation cycle. So you can´t say, when I get into this, what do I do? It has to be managed at the very beginning. So at the very beginning, in the selection process, you need to let people know: here is what we are doing, we are looking at changing the way we do our business, here is why, again, selling the rationale. So you manage it through communication (McAndrew).

For McAndrew, once resistance is here and you went live with the system, it is too late; Change Management must start at the planning phase and communication must happen from the beginning until the end of the ERP adoption process. In the case study, Mercodia even had a pre studies phase where they went to other companies to see systems in place and identify a vendor that could truly meet their requirements.

As a former ERP vendor, McAndrew mentions one thing that he could have done better. “We, the vendor, could have set the expectation with management, so that they could set the expectation with their people”. This step of setting the expectations was well managed at

62

Mercodia, with the drawn business processes and written documentation, a meaningful dialogue could be created between the vendor and the client so there was a common understanding.

Hayes recognizes that it is hard to prescribe a solution for all cases, but that often, resistance is greater because of a stakeholder involvement that comes to late in the process. Possnert sides with this idea since he stresses the importance of informing and educating stakeholders:

The most important thing is to give people information, well in advance, what will the effects be, so that people very early know what to expect from it. And also I think education, not only information but education very early of the new system, how will that affect their everyday work. I think the key issue is information of course, I think many people feel excluded from the process, which make them resistant (Stefan Possnert).

Selling the rationale of the project is a key component of this communication. McAndrew mentions that during this process, it is important to involve end users, tell them what they need to do so they feel like a part of the process.

“When it works well it is because senior management, or the change agent, have remembered that communication is about listening and it has to be a real time two way process. Also management has grasped the need to convey a compelling, achievable and measurable vision of the Promised Land” (Robert Paton).

This shows that communication is not just about transmitting the message but also allowing for feedback from the receiver. Moreover, it is about selling the rationale for the change.

Hayes mentions that there are change managers that are very good at communicating change, and “trust is key”. If trust is built, then there will really be a two-way communication, with receivers giving feedback. It will not be the case if the receiver does not trust the change leader. If there is trust, then involvement is also more likely to be strong. As Possnert indicates that, what can make the difference is to have the whole organization very involved in the process. For Abbate, end users involved from square one can lead more easily to change acceptance.

It is also important to acknowledge that once the system is installed, it won´t be perfect right away. “When you go to ride the bike, you are going to fall down… you need to set the expectation with people that we will have a bumpy road, that is the norm!” For Rausch, the customer needs to handle resistance, but in cooperation with the vendor. She stresses the importance of building a close relationship with the client, so that once you arrive in the going live, it does not come as a surprise for the users.

A critical aspect of Change Management for McAndrew is senior management commitment and the importance of leadership. “Most of all it needs to be led, not managed, be the CEO, to make sure that everybody is on board, and everybody is committed and that there is no way, we are only going to go forwards”. For Possnert also, change leaders should drive the users throughout the change.

63

For the experts, a unanimously accepted fact is that change needs to be managed from beginning to end, starting with planning and ending with institutionalization of the change. A first important step is to set the expectations with the vendor; it needs to be a two-way process. A common problem comes from not involving early enough the users in this process. Giving them early information and educating them to the new system enables them to know what to expect and to feel involved. It is also about selling the rationale, the benefits of the system. User training will also be key because it will be a time where they will evaluate what the system can bring them and have the possibility to give feedback. Acknowledging that going live will not be perfect then is important. It is there important to cooperate with the vendor so that the usual problems found at that stage do not come as a surprise. Finally, there is a need for leadership and senior management commitment so that end users are accompanied down the road of change.

4. Aspects of organizational change that leaders tend to underestimate

We also talked with our experts about aspects that business leaders tend to underestimate when a change such as ERP occurs in their company. For Spector, “it is a tough question, there are so many things”… We will present in this section the main aspects that leaders should consider more according to experts.

McAndrew mentions the most underestimated aspect as being the need to sell the rationale of the change to the organization through communication. Too often, leaders decide that the system will be implemented, but tend to forget that whereas they understand the rationale to it, employees may not because it has not been explained to them. The communication aspect as been stated by all experts as a key enabler of change, but it seems to be underestimated in some companies implementing ERP. Spector he stresses a common mistake of leaders: “they understand why they implement it and they think everyone understands”. If a leader believes his employees understood the rationale of the change whereas indeed they didn´t, it probably means that they were neither informed nor involved in the process. For McAndrew, this attitude from leaders may come from their inexperience as far as ERP is concerned. If someone has never been implementing ERP before, it may be hard to understand the magnitude of it.

Therefore, if leaders do not communicate why the change is implemented, then user involvement is likely to be minimal. For Possnert, information, education and training of end users is often underestimated. Spector also mentioned the lack of user involvement in the change process. According to Hayes, “too often, those with technical expertise exercise too much power and fail to design a system that fully meets the requirements of end users”. This is an important reason why user involvement is necessary. There will certainly be flaws in the system if users are not part of the process, and the system will therefore not be accepted.

Moreover, leaders may not see the value of following a clear methodology because they do not want to spent too much time planning with reactions such as “come on, let´s get going,

64

let´s put it in”. McAndrew recognizes that “when bad things happen downstream, it´s because the right things didn´t happen upstream”. In the case of Mercodia, it could be seen that some resistance was observed because there was no clear methodology when the CRM was first implemented. It is a couple of years later that people were thought how to use it, so of course it is harder to get people understand the value of it.

For Abbate, business process understanding tends to be cast aside. Hayes also mentioned this issue. For him, even if leaders believe they understand, business process issues are common, people not knowing well their current processes. This advice given to Mercodia by all three companies they went to, “make sure you know your own processes” shows that not knowing well their processes is something that happened to many companies. McAndrew also stresses the lack of consideration for the way processes will actually be changed and the impact of the process change on people.

Finally, according to Hayes, reward alignment is also underestimated. For example, a common mistake would be to have individual bonuses when you intend to promote teamwork. In a change process, rewards should go hand in hand with the changes that are expected.

From what was mentioned by experts, there seems to be important aspects required to effectively manage change that leaders tend to underestimate. A common mistake is to believe that because leaders do understand the rationale, everyone does. Also, this type of thinking often leads to a limited user involvement. However, if users are for instance not involved in the implementation, the system is likely to have flaws and not to be adopted. Another problem appears when leaders tend to rush the process, and especially the planning phase. Changing cannot happen overnight, and if planning is rushed, the rest of the process is likely to become a series of problems. In this planning phase, the importance of understanding business processes as been stressed, however this tends to be forgotten by executives. Moreover, the impact of the new processes on people can be neglected. Finally, reward alignment should be considered because if the rewards do not match the objectives of the change, it will also have a negative impact on the process.

5. A particular issue: training

When implementing an information system that is known to change the business processes, training end users so they can effectively utilize the system seems to be common sense. However, as mentioned by McAndrew, “training is the area that is given the least amount of respect”.

65

Why is training often tossed aside?

According to McAndrew, many leaders are shocked when they find out how expensive it is to train. As a vendor, training is considered as part of the services, and it is easier to reduce the cost of services than the cost of the software itself on which vendors make most of their margin. In fact, training can represent up to 20% of the total cost of ERP, so if the client thinks the bill is too expensive, the vendor will first try to reduce the training cost… and this can “absolutely compromise the project”.

Often, companies want to save money and reduce the overall cost of implementation, and training is a service that is reduced and suffers a lot from this strategy. This happens because budgets are tight and companies often don´t have the money to afford what the complete cost should be. For McAndrew, the solution to this problem is linked to a formula: “resources + scope = solution”. Instead of reducing resources that leads to obtaining an average or deficient solution, the scope of the project should be reduced. ERP is composed of different modules, so instead of installing both manufacturing and HR modules at the same time, it would be wiser to install only one module and have the adequate resources for it, and install the other one maybe a year later.

Who should train and when should training occur?

Possnert believes that training should start early in the ERP adoption process.

“As soon as you have decided on what kind of system you should implement, which part of the organization is affected by it, and which people you want to have involved in the process, then you should start the training. You cannot do it too early. It´s a process of getting used to a new system and to accept it, it is not something that happens from one day to the other, it´s a long process actually” (Possnert).

McAndrew mentions however that if the training starts early, then it should not stop weeks or months before actually going live, otherwise the risk is that people do not remember what they have learned, and the training becomes useless.

During Mercodia´s implementation, the training and the testing were combined. It started 4 or 5 months before going live, and it went on until actually going live, so there was no risk that people would not remember what they learned.

66

6. Change Management and its use today: do companies effectively manage change?

According to McAndrew, ERP vendors today have understood the need for a methodology when implementing ERP, because there were so many problems in the past that they understood the need to design a methodology that would specifically fit their product. “Any vendor that wants to be considered seriously has to have their own methodology”. Moreover, clients are looking for these methodologies. Nevertheless, the situation is not idyllic yet.

According to Paton, when companies do change, “they tend to make all the same old mistakes”. Abbate had almost the exact same words to describe the situation by saying that “managers tend to repeat the same old mistakes”, even if ERP knowledge is now broader. In addition, for Lientz, companies implement the system faster, but not better. “They generally do not manage change well”.

For Spector and Hayes, it is hard to say, some have learned and some did not. For Possnert, the tools available to implement the systems are better today, and therefore the methods are better, there are more experienced people, yet there are some things they can improve. For Possnert also, it seems hard to generalize because from company to company it can be very different. There are methodologies in place, but the results he observes vary greatly from one company to the other.

Abbate mentions that many companies rely on standard project management methodologies, but that “blind application of standards would lead to disaster” .

The experts have different views on the use of Change Management in practice. It seems like companies are aware more aware today of the need for a methodology, but awareness does not mean that it is well used. Abbate, Paton and Lientz come from different backgrounds, yet they have this impression that change is not very well managed by many companies. For others, such as Spector, Hayes, and Possnert, it varies from company to company. Finally, Abbate stresses an important point by saying that applying standards without much thinking behind it cannot lead to change acceptance.

7. One single advice for CEOs implementing ERP

Rausch recognizes the need to look at the total cost of ERP. One should remember that ERP is not just about buying the software itself. There will be training costs, consulting costs, hardware costs… the list is long.

Abbate indicates the importance of analyzing well business processes, a view shared by Mercodia´s project manager and senior management. According to him, an external consultant should be contracted to do this.

For Hayes, you should insist on the role of end users who should be the ones leading the change whereas technical experts are here to support the processes. This advice relates to the

67

need for user involvement since they will be the ones ultimately working with the new system. Possnert also insists on the importance of understanding that ERP is not an IT project but a business project, therefore the insistence on the role of end users.

According to Paton, CEOs should remember that “inter silo knowledge transfer adds value”. In fact, this refers to the transition that ERP implies from different legacy systems in each department to a system that integrates the whole organization. The focus needs to be on the interest of the organization as whole in a goal congruent manner.

McAndrew stresses the importance of “being upfront as a leader” and creating consensus by using persuasion skills that most leaders should have to be in their position. In addition, he mentions keeping in mind to the vision and mission of the organization to build the strategy for change. Here again, the interest of the company as a whole is underlined.

The experts, depending on their background, give different advice, but they all seem key in an ERP implementation. They demonstrate the importance of user involvement, leadership, planning and analysis, and coordination and communication.

68

V. Analysis and discussion

A) Introduction

In this chapter, we intend to use both our theoretical and empirical findings in order to understand the benefits of a Change Management methodology, to make the ERP adoption process easier for individuals in the organization and build solid foundations for the change to be accepted. We could identify that resistance to change stems from a lack understanding of ERP and its benefits, therefore through a change management methodology, the objective would be to address and reduce this resistance. We will identify and explain why the stakeholders throughout the adoption process need to work in partnership. Finally, we will insist on the main aspects of the methodology, and what the benefits are in terms of ERP adoption.

B) Resistance as a lack of understanding

As we perceive it, Change Management is a way to handle obstacles during a change process and to reach adoption of the ERP system by the end users. In an ERP adoption process, we have learnt that one main obstacle to handle is resistance to change. In this part we intend to discuss the different factors and patterns that we have found during our collection of information concerning why people resist change in an ERP adoption process.

Important to acknowledge early is also that the experts we talked to all have different backgrounds, for instance scholars, ERP consultant, business process consultant, etc. These different backgrounds probably lead to different perceptions.

Moreover, we have devoted extensive interest in this research to resistance. Important to remember is that if resistance is considered as something negative, which we have seen it often is, managers and leaders forget that they can actually learn something from it. Paton for instance prefers to refer to it as employee concerns.

We have also seen that theory often refers to resistance as a natural human behavior, and some experts mentioned that it is quite natural to resist change. Possnert and Abbate refer for instance to the fear of change, the unknown and the threats that could appear with the ERP system as natural behavior. Also, after talking to our experts they all seem to agree with Spector when he argues that the degree of resistance will of course depend on the approach taken and also the fact that change should not be forced upon people. Some of the concerns that have been mentioned by our experts, such as when Hayes talks about lack of confidence in the change initiators, can explain the resistance in some cases.

It is interesting to notice that what seems to be the underlying explanation to many forms of resistance and more specifically in an ERP implementation is the lack of understanding of

69

what the system will bring to the organization and the need for a “buy in”. We believe this is a main reason for resisting, especially due to our findings in our case study and in our interviews with experts.

This can also be explained by the characteristics about an ERP system that the change initiator has to be aware of. We have seen in theory how the system integrates all departments and most likely changes tasks and therefore behavior. We have also listened to our experts who mean that productivity tends to slow down right after going live with an ERP system and that there is a stabilization period. Paton states that there is “a pain before any gains, and folks are measured on present performance – not future”. McAndrew also referred to his own experience that when a company goes live with a system people are sometimes complaining that it does not work and they are not accepting that there will be bumps, so here the resistance takes the form of simply giving up.

McAndrew also mentioned the high frequency of resistance in an ERP implementation, most commonly among middle managers and employees. What also came up in our interviews that support our assumption is that people are more likely to support if they understand and clearly see the benefits. People need to understand the rationale, and what the company wants to achieve with the system. Spector even went as far as stating that if they do not understand why the system is put in place “they just won’t do it!” Whether or not the company has implemented an ERP system before do not seem to make any big difference.

Furthermore as stated by many of the experts, if they do not understand, people will keep working as they did before. The danger with this is obvious due to the strong force of comfort with the status quo. As explained by LeMarsh: “the present is so powerful that at times it seems to defy as logic” (in Hiatt and Creasey 2000: 20). Theory even suggests that this force is so strong that sometimes people do not even want to understand, usually because they fear for their job and position. In addition, our experts Possnert, Abbate (who both works as consultants) and Rausch mean that in some organizations they just want to work with the new system in the same way as they worked with the old one.

The importance of understanding the rationale of the change could be observed in our case study. Even though most of Mercodia’s module implementations can be considered successful in terms of reduced resistance, in the CRM implementation, there was obviously a lack of understanding of the benefits with the system. Neither was this module implementation as well planned for compared to for example the well executed MPS implementation in 2007. End-users had problems to accept the CRM simply because they were never taught how to use it, and more important why they should use it, or in which way the module would bring value added to their work. This is a clear example where the employees did not understand the rationale for it. As mentioned by McAndrew, this type of change should always be linked to the strategy and goals of the organization, otherwise people simply can´t understand why the change would be worth undertaking.

Finally, what we can say is that by acknowledging that a lack of understanding is likely to reinforce resistance, the change agents should put more focus on explaining the need for change, stressing what the change will bring, showing what the success factors are, as

mentioned by McCalman. In order to do this, it is important to be aware of who has a stake in the adoption process.

C) Stakeholders as a partnership in an ERP adoption process

In this part, we intend to analyze tprocess and why they need to work in partnershipfigure showing the relationships between different stakeholders in this particular case and explain these relationships and their importance to manage change. We will analyze the different stakeholders roles and how these roles are subject to evolution throughout the change process.

Figure 11. Stakeholders in an ERP implementation (Source: authors)

The project team, but not alone

In our case study, a project team was put in place whose role was to manage the MPS implementation from the planning phase project leader in this case had a very important role,empowering others in the right direction.our theoretical framework and empirics, different authors and experts referred to the persons responsible for conducting the chanrefer to these people as change leaders, acknowledging that thones in different adoption processes.but he can´t work by himself. Focombination with each other. his relationship with the vendor is deficient, if the end users system is put in place, and if the rest of the organization doesn´t care about the project, then his management of change will be put in jeopardy into a torment.

ERP vendor

Consultant

Rest of the organization

Project leader and his/her team

70

In order to do this, it is important to be aware of who has a stake in

Stakeholders as a partnership in an ERP adoption process

In this part, we intend to analyze the interest of identifying stakeholders in an ERP adoption and why they need to work in partnership. Using our case study, we will present a

figure showing the relationships between different stakeholders in this particular case and relationships and their importance to manage change. We will analyze the

different stakeholders roles and how these roles are subject to evolution throughout the

. Stakeholders in an ERP implementation (Source: authors)

project team, but not alone

In our case study, a project team was put in place whose role was to manage the MPS implementation from the planning phase to the implementation, and even after that. The project leader in this case had a very important role, decisional, motivational, and empowering others in the right direction. She could really be considered as a change leader. In our theoretical framework and empirics, different authors and experts referred to the persons responsible for conducting the change process with different names. From now on, we will

as change leaders, acknowledging that these people will notin different adoption processes. The project leader may be a very important stakeholder,

work by himself. For McCalman, it is essential that stakeholders work in If the project leader has no support from the project sponsors, if

his relationship with the vendor is deficient, if the end users do not understand whyand if the rest of the organization doesn´t care about the project, then

hange will be put in jeopardy and the ERP adoption could easily turn

End users

Sponsors

Steering group

Project leader and his/her team

+

System administrator

In order to do this, it is important to be aware of who has a stake in

he interest of identifying stakeholders in an ERP adoption . Using our case study, we will present a

figure showing the relationships between different stakeholders in this particular case and relationships and their importance to manage change. We will analyze the

different stakeholders roles and how these roles are subject to evolution throughout the

. Stakeholders in an ERP implementation (Source: authors)

In our case study, a project team was put in place whose role was to manage the MPS the implementation, and even after that. The

decisional, motivational, and She could really be considered as a change leader. In

our theoretical framework and empirics, different authors and experts referred to the persons ge process with different names. From now on, we will

ople will not be the same project leader may be a very important stakeholder,

McCalman, it is essential that stakeholders work in leader has no support from the project sponsors, if

do not understand why a new and if the rest of the organization doesn´t care about the project, then

and the ERP adoption could easily turn

71

The consultant on the vendor´s side

The consultant on the vendor´s side is also a very important stakeholder in an ERP adoption process. A change of this magnitude often requires external help, and this needs to be acknowledged by companies. As described by Rausch, he is “executing everything that needs to be done with the implementation in the customer´s company”. His main contact person on the customer´s side will often be the project manager, since he is probably the most knowledgeable person about the project, its status, and he has the power to take decisions. In addition, the consultant will be very important in the planning phase, when the requirements are agreed upon. In fact, both Rausch and McAndrew agree on the fact that it is key to set the expectations in partnership with the client. On the one hand, the consultant has the expertise and the technical knowledge to translate business requirements into a technical reality through the software, on the other hand, the client knows his business processes and his company, and he should be able to explain what he expects from the software. The importance of setting the expectations will be further developed.

Then, if this relationship with the consultant is crucial in the planning phase, it is also very important when the time comes to test the system and train users. Consultants on the vendor´s side have done many implementations before; therefore, they have experience and know how to handle the “bumpy road” as McAndrew refers to it. In the case study, everyone on Mercodia´s side was pleased with the relationship developed with the consultant, referring to his dedication, his competence and personality, and having the impression that “[they] had priority number one”. This can truly have an important impact on the ERP adoption process, since for the first modules that were installed, the former consultant that worked with Mercodia didn´t show the same dedication, and the process went less smoothly. Moreover, for the project manager of the MPS implementation, it was essential that she would work with a dedicated consultant, certainly because his level of dedication in the process can have a tremendous impact on the final result. The consultant´s role is especially critical until going live.

Sponsors

The sponsors are also key stakeholders. For Hagberg, project manager at Mercodia, it was essential to have these people´s support, and to meet them regularly so they could give their approval to keep on going with the project and also stress things that could be improved. McAndrew refers to the importance of functional owners, defining the CEO as “maybe the biggest stakeholder of them all”. Often, the project sponsors are part of the steering group, and they are the ones who decided that there was a need for ERP in the company. Therefore, even if they are not part of the project team or involved as directly as the project group, the project leader still needs their approval and support. What if the project sponsors shows very

72

little interest for the project? It could appear to the project team as if ERP is not “top priority” and they might be less motivated to bring the best out of the project. Moreover, for Rausch, it would be very unusual for project sponsors to show no interest for the project since they allocate resources and personnel´s working time to it.

The end users

Besides, the end users are one stakeholder group that has been largely referred to by many experts as very important in the process. For Possnert, “they have the ability to make it either a success or a failure, depending on their attitude to the system, their willingness to adopt it”. But this willingness to adopt the system will mostly depend on the type of relationship that was built between them and the project team. It should remain clear to the project leader that end users will be the ones most affected by the change since they will have to work with a different software and therefore change their way of working. In our case study, employees in the manufacturing department went from a manual system to an automatic system with the MPS, this was an important change, and its impact on end users should be thought about and explained beforehand.

The rest of the organization

In addition, the rest of the organization should not be left apart from the process. In the case study, the MPS was a module that affected directly only the manufacturing department, but it doesn´t mean that other departments were not concerned. In fact, ERP modules are not meant to work separately but rather to be integrated and work together to increase efficiency. Therefore, the MPS would not only have an impact on the manufacturing department but also on the rest of the organization. Andersson, who works in the marketing department at Mercodia, really appreciated to be kept informed during employee meetings about the status of the project. She mentioned that there is not a need for detailed information, but rather having a general overview of what is going on. In theories, we have seen the benefits of participation and involvement. Even for stakeholders who are not directly affected by the change, it is important that everyone in the organization walk in the same direction.

The system administrator

Finally, the system administrator plays a very important role, but especially in later stages of the process, mostly after going live. The system administrator (or the administration group if it consists of more than one person) should be responsible for providing help for end users when they encounter problems with the system. For instance, at Mercodia, problems with the

system are solved in house with the help of the system administrator, and if it is not possible to do so, then the ERP consultant is contacted.

Of course, the different stakeholders throughout the adoption process wilheavily involved, and we thought it would be interesting to analyze these degrees of involvement to get a clearer picture of who gainstakeholders are always connected to each other and how they must

Figure 12. Key stakeholderauthors)

Not only knowing who are the stakeholders in an ERP adoption process but also assessing their importance and their role is necessary to make sure thetherefore accepted. By involving all the stakeholders mentioned above, and by being aware of their role, their interest, and what they can bring to the process, the relationships developed among them are likely to be tighter aEven if this was not so much observed in our case study, it is theory and experts mention

Pre studies

•Project team •Business process consultant

Planning

•Project team together with sponsors•End users input•Sponsors approval and support

Setting the expectations

•Project team requirements•ERP consultant´s understanding of requirements and clear explanation of what the vendor can deliver

Implementa-tion

•Project team guidance•ERP consultant expertise for training, testing and software improvement•End users involvement and feedback during training and testing to allow software improvements

•Sponsors approval and support

Maintenance

•System administrator expertise to solve problems and improve system •End users requests and feedback•ERP consultant expertise for complex problems and improvements

73

with the help of the system administrator, and if it is not possible to do so, then the ERP consultant is contacted.

Of course, the different stakeholders throughout the adoption process wilheavily involved, and we thought it would be interesting to analyze these degrees of involvement to get a clearer picture of who gains importance in each phase, and how the stakeholders are always connected to each other and how they must work in partnership.

stakeholders throughout the ERP adoption process (Source:

Not only knowing who are the stakeholders in an ERP adoption process but also assessing importance and their role is necessary to make sure the change is well

By involving all the stakeholders mentioned above, and by being aware of their role, their interest, and what they can bring to the process, the relationships developed among them are likely to be tighter and the change process should be handled more smoothly.

not so much observed in our case study, it is important to remember that some problems will materialize when you go live. A

Business process consultant

Project team together with sponsors

Sponsors approval and support

Project team requirementss understanding of requirements and clear explanation of what the vendor can

Project team guidanceERP consultant expertise for training, testing and software improvementEnd users involvement and feedback during training and testing to allow software

Sponsors approval and support

System administrator expertise to solve problems and improve system End users requests and feedbackERP consultant expertise for complex problems and improvements

with the help of the system administrator, and if it is not possible

Of course, the different stakeholders throughout the adoption process will be more or less heavily involved, and we thought it would be interesting to analyze these degrees of

importance in each phase, and how the work in partnership.

throughout the ERP adoption process (Source:

Not only knowing who are the stakeholders in an ERP adoption process but also assessing change is well grounded and

By involving all the stakeholders mentioned above, and by being aware of their role, their interest, and what they can bring to the process, the relationships developed

nd the change process should be handled more smoothly. important to remember that both

ll materialize when you go live. As

s understanding of requirements and clear explanation of what the vendor can

ERP consultant expertise for training, testing and software improvementEnd users involvement and feedback during training and testing to allow software

74

Jawahare and McLaughlin express (in Hayes 2007), the ability of the stakeholders to meet specific requirements from the organization often changes over time, that is why it is of interest to on a regular basis to review and map the stakeholders, to also be aware of the evolution of their roles throughout the change process.

Stakeholder theory can be used to analyze in more detail the power, predictability and level of interest of each stakeholder throughout an ERP adoption process. We will use Newcombes’s “predictability/power” and “interest/power” matrices to show the importance of each stakeholder in our case study at Mercodia (2003: 844).

Figure 13. Predictability/Power Matrix (Source: Newcombe 2003)

This matrix is interesting for the project leader in order to adapt its communication with different stakeholders depending on their predictability, what their reactions could be, and their relative power, how much influence do they have on the success of the implementation? The business process consultant is important in the pre study phase, but then he won´t be involved in the rest of the ERP adoption process. The rest of the organization in Mercodia´s case had a low power since they were not directly involved in the process, but their reaction could not be predicted. Other stakeholders had more power, since they were involved in a more direct way in the adoption process, but they were also more predictable. That was the case of the project team, the project sponsors and the system administrator since they all wanted the project to be successful and their role was to either support (sponsors), manage (system administrator), or lead (project team) this change.

We also identified two stakeholders as being both powerful and less predictable, the ERP vendor and the employees in the manufacturing department. Concerning the consultant, it is difficult to know beforehand how committed the consultant will be. In earlier module

75

implementations at Mercodia, the consultant did not have the same commitment and expertise as the one who worked with them for the MPS module, and this can make quite a difference in terms of change acceptance. Finally, the manufacturing department employees are key since they will be the ones using the software, but their reaction to change can´t be anticipated, and it can vary from individual to individual.

Moreover, stakeholders don´t have solely different degrees of predictability in the change process, their interest is also a variable. As we have seen, some stakeholders are more directly affected by the change, such as end users; therefore it is important to assess this degree of interest to manage the change.

Figure 14. Interest/Power Matrix (adapted from Newcombe, 2003)

In Mercodia´s case, the rest of the organization showed interest for the MPS module and they were kept informed about the status of the project. All other stakeholders could be considered as “key players” since their interest was high, all for different reasons. The project team´s interest was of course to make this project a success. For the ERP consultant, delivering a product meeting the client´s requirements would mean having a satisfied customer, and the objective of ERP vendors is not only to make sales but also to build long-term relationships with their customers so that they buy additional modules from the same vendor, and also do system upgrades with them. For the manufacturing department employees, their interest was to work with a more efficient system that really brought them something more than the old one. Moreover, the sponsor´s interest is obvious. ERP is expected to increase business process efficiency, and therefore bring return on investment. For the system administrator, the interest is to enable real institutionalization of the system by helping users when they encounter problems and help them improve their use of the system so they really see the benefits of it.

76

Overall, when asked to mention key stakeholders in an ERP adoption process, most experts mentioned more than one, or as Paton suggested, “it is almost worth asking who is not”! It appears clearly when mapping these stakeholders. We can observe that most of them have a high interest in the process and have a strong influence over the potential success of the adoption process. Therefore, they need work in partnership and be identified beforehand by the project leader(s) so that that this process occurs more smoothly.

D) A change management methodology in an ERP adoption process

Acknowledging every stakeholder´s needs and competencies

As we have just seen, there is a need for a real stakeholder partnership throughout the change process, the stakeholders “all have to work together” as McCalman explained. In the particular case of ERP, it is important to identify to whom the project team should communicate information, what type of information, and what they can do so that there is feedback and people truly feel involved in the process. This is not an easy task. We have acknowledged that each stakeholder is important in the change process, but they each have different roles and therefore different needs in terms of information and in terms of things they can do. The project team needs to be aware of these different needs.

Communication target What do they need to know? What can they do? Project Sponsors - Status of the project

- Difficulties / Success - Give their input - Show support

ERP consultant / Vendor

- What are the companies´ business processes

- What are the requirements and expectations

- Problems during the testing / go live

- Explain what the vendor can deliver

- Help the company better define its requirements

- Improve the system through iteration

End users - Status of the project - What will be the

different steps and milestones for them

- What they can do to help

- Express concerns - Give ideas - Use their knowledge of the

processes to help the consultant throughout the system´s improvement

Rest of the company - Status of the project - Show their support - Express their concerns

77

In order to understand better how change needs to be managed all the way, from building a vision to reaching acceptance and institutionalization of the change, there are different aspects that need to be considered down the road.

Having a clear vision and people who will support this vision

When business leaders decide to implement an ERP system, it is often because the system is seen as having the potential to increase effectiveness and efficiency. Many leaders use what Nicholls describes as Managerial Leadership (1994). They have identified that the current system does not enable to “do things right”, and ERP is a way to improve the business processes and therefore increase effectiveness. However, this type of leadership can trigger a vision, but it does not focus on the impact the change has on individuals. Companies need what Nicholls call “transforming leaders”; people who are able communicate the vision and trigger understanding of this vision. This is what McAndrew referred to as “selling the benefits”. It is not sufficient for leaders to understand what the change will bring, they need to convey the value added of the new system to the employees. This can be done through acknowledging also the limits of the old system, and insisting on what could not be done before in comparison with what the new system will enable people to do.

Moreover, as mentioned by Kotter, it is important to unite people who will be committed to the change process and direct it (in Hayes, 2007). But how can these people be selected? In the case study, Axelsson made an interesting comment: “we didn´t chose people who were good at projects (…) we had really people with good skills, who knew what they were doing and (…) very dedicated”. In this team, there were workers from different parts of the production department, so they could really represent the interests of end users and communicate not only in a formal but also in an informal way with them since they were colleagues. Teamwork is one Spector´s “Power Equalization Steps” that should enable dialogue to be more truthful and open (2010).

Understanding that identifying current business processes will facilitate the change process

We observed at Mercodia that before contacting any vendor, they went to other companies who had implemented ERP before. It was a way to picture the system and have a better understanding of what it would concretely mean to change, by seeing how it affected the working processes in other companies. This enabled also the company to become more aware of something very important before actually implementing ERP: knowing one´s own business processes. Therefore, the manufacturing department worked with a business process consultant that helped them draw their processes and explain them. One could say that people who work in the department already know these processes, but it is also important to be able to explain them, because the ERP vendor is not part of the client´s organization and can´t guess how they work. We will analyze how the business processes were reengineered at

Mercodia by comparing their method with Hayes ´streengineering because many similarities can be found

Hayes´ BPR steps

Figure 15. Business Process Reengineering Stepsand what was done at Mercodia

For Hayes, mapping the processes is about understanding what they are, what they do, and what their value added is. consultant in groups to identify these processes and put down on pathey bring to the organization.

Then, identifying which processes need to be reengineered was done in partnership with the ERP consultant when setting the expectations, knowing what Mercodia needed and what HansaWorld could deliver to them.

Subsequently, it was important to define what needed to be accomplished with the new processes. For instance, as explained by Schwab, the ERP consultant, Mercodia had processes that required strict timing due to the requirements of their seThere, these specific requirements need to be acknowledged.knows about what the company needs, the better the solution he will propose.

Map processes

Identify which processes need to be reengineered

Define key performance objectives

Design new processes

Test ideas to establish if it works in practice

Implementation of new processes

78

Mercodia by comparing their method with Hayes ´step-by-step business process reengineering because many similarities can be found.

Hayes´ BPR steps Mercodia´s “steps”

ness Process Reengineering Steps: a comparison between theory and what was done at Mercodia (Source: Hayes, 2007: 324-327)

For Hayes, mapping the processes is about understanding what they are, what they do, and This step was followed by Mercodia when working with a

consultant in groups to identify these processes and put down on paper what they do and what they bring to the organization.

Then, identifying which processes need to be reengineered was done in partnership with the ERP consultant when setting the expectations, knowing what Mercodia needed and what

ver to them.

Subsequently, it was important to define what needed to be accomplished with the new processes. For instance, as explained by Schwab, the ERP consultant, Mercodia had processes that required strict timing due to the requirements of their sector, pharmaceuticals. There, these specific requirements need to be acknowledged. In fact, the more the vendor knows about what the company needs, the better the solution he will propose.

Identify which processes need to be reengineered

Define key performance

Design new processes

Test ideas to establish if

Implementation of new

Drawing and explaining processes with the help of a business process consultant

Setting the expectations (project leader and ERP

consultant)

Mercodias requirements (process drawing + written

document)

Björn Schwabs work using Mercodias requirements

Combination of training and testing at Mercodia

Going live

step business process

Mercodia´s “steps”

: a comparison between theory

For Hayes, mapping the processes is about understanding what they are, what they do, and This step was followed by Mercodia when working with a

per what they do and what

Then, identifying which processes need to be reengineered was done in partnership with the ERP consultant when setting the expectations, knowing what Mercodia needed and what

Subsequently, it was important to define what needed to be accomplished with the new processes. For instance, as explained by Schwab, the ERP consultant, Mercodia had

ctor, pharmaceuticals. In fact, the more the vendor

knows about what the company needs, the better the solution he will propose.

Drawing and explaining processes with the help of a business process consultant

Setting the expectations (project leader and ERP

s requirements (process drawing + written

s work using s requirements

Combination of training and

79

With clear requirements, the ERP consultant can start to build upon the standard ERP package, and identify the specific requirements and adapt the software to these. This period of design was done in collaboration with Larsson, the production planner at Mercodia who knows well the process rules.

Next, it is important to test before going live. By testing, the consultant is able to make adjustments and identify problems that did not appear in written requirements.

Finally, it is time to implement the new processes, or more precisely the new form they take with ERP. Indeed, at Mercodia, the MPS module made the manufacturing department go from manual processes to automated ones, which means an important change. The “going live” is never perfect, it will for sure be a rough period, but going through a real business processes analysis beforehand will enable to encounter fewer problems when implementing the ERP module, and there will be less unexpected “surprises” on the road.

The comparison between Hayes´ model and what happened at Mercodia is by no means an attempt to make theory “fit” with our case study. When observing the process followed at Mercodia to implement the MPS, the similarities with Hayes ´model appeared clearly to us. There was clearly a methodology in place to conduct the change.

Setting the expectations: a two-way process

If the client company has a clear understanding of what its business processes are, then it will help them explain better their system requirements, and therefore the communication with the consultant on the vendor side will be more effective. As Schwab stated, business process drawings enabled him to have a good overview of what the company was expecting from the system. This was important for the consultant because he could then also explain what the system could actually deliver. As Rausch explained, it is a problem often experienced, people expecting that the business processes will look exactly as they did before. Therefore, if the requirements are very clear, a common understanding can be reached and the expectations can be acknowledged by the vendor but also be compared with the system can actually do.

A basic communication problem that could happen at this stage would be linked to unclear requirements on the part of the client, or the vendor being unclear on the capabilities of the system, or both. Setting the expectations should not be rushed, since any misunderstanding could lead to exponential problems in upcoming stages.

Training and testing As we have seen before, most of the stakeholders in the ERP adoption process can be considered key stakeholders, therefore they need to feel involved and informed. The training and testing of the new system are very important because end users especially are finally able to picture what the change will represent in their daily routine, how their work will differ.

80

However, training was an area discussed with experts, and McAndrew mentioned that it is the one part of an ERP implementation process that is “given the least amount of respect”, its importance tends to be underestimated.

For most experts, the training cannot start too early. However, it should not stop weeks or months before actually going live with the system, otherwise, people would not remember what they have learned.

Clampitt et al.´s “underscore and explore” communication pattern seems especially important to consider. In fact, during the training, employees should be educated and informed on central issues, things that they will really use in the system and that create a greater awareness of its value added in their daily work. This is a very important step where end-users´ education can truly take place. We have previously mentioned that the main reason for change resistance in an ERP adoption process is a lack of understanding. Kotter (1999) means that the best way to deal with a lack of understanding is by using education and communication. Possnert also mentions that one of the most important things in such an adoption process is to not only give people information well in advance but also to educate them, so they feel included in the process.

In addition, it is important to listen to end users concerns and address these concerns. It is crucial to allow for “representation”, introducing different hierarchical levels in the dialogue to increase involvement in the change process (Spector, 2010). To feel involved in the change process, workers need to know that their suggestions and comments during the training and testing of the system are taken into account. Moreover, their input is valuable in the sense that they are the ones who know the work best; they are “the feet in the street” as McAndrew refers to them. At Mercodia, the testing and training involved regular communication and feedback between the ERP consultant and Mercodia´s project planner who had the experience and expertise of the current rules and functionalities of the business processes. It is very important to draw the line between the business side and the technical side at this stage. In the words of Harwood, ERP should be a “multidisciplinary team effort” (2003).

Going live is not the end of the journey

When the system is finally implemented “for real” , business leaders should not expect everything to be perfect right away. As Possnert explained, there is a stabilization period that follows since no matter how hard people have worked on establishing the requirements, testing and training users well in advance and continuously, there will still be small issues that will need to be solved at that stage. As McAndrew states, “that´s the norm”.

Vendors do know that it is not an easy step, but they should create awareness of this on the client´s side also. Technical problems that can arise when going live should not come as a surprise since end users could reconsider the benefits of the system and feel the system is not meeting the expectations. Hayes defines trust as a key element of communication, therefore, the vendor should not draw an ideal picture of the implementation as a flawless process.

81

(2007). People need to be aware of the difficulties of this stage so that leaders can “keep people moving in the right direction”.

Once the stabilization period ends, if the change has been managed all the way through taking into account the “people side”, resistance has been addressed and reduced, and the adoption process can be considered fulfilled.

82

VI. Conclusions and recommendations

A) Conclusions

When we started to collect information about our area of research, the aim was to understand the interest of the Change Management theory for companies implementing an ERP system because of our awareness of the extent to which ERP changes people´s tasks, and therefore requires a behavioral change. We observed mostly the non-technical aspect of this type of implementation, since, as acknowledged by experts, ERP is first and foremost a business change as it changes the way people work and it integrates business processes. We more precisely focused our attention on user resistance and understanding how having a methodology to manage change could enable to address and reduce resistance.

What have we learned from this research? First of all, there are many reasons why people resist organizational change, but after having conducted a case study and talked to experts we realized that in an ERP adoption process, a main reason for resisting change has its roots in a lack of understanding the impact the new system will have on people. If the scope of an ERP implementation is not fully understood by the change leaders, then it will be even more difficult for them to sell the rationale of the change and obtain support. Also, leaders should not see resistance as an enemy. A lot can be learned from resistance since understanding the reasons why people resist enables to address and reduce it.

We also acknowledged that there are many key stakeholders in such an implementation. By recognizing who they are, and realizing that their needs and roles are different but complementary, change leaders need to make sure that these stakeholders work in partnership. In fact, combining their different knowledge, experience and expertise will ease the change process.

Concerning the identification of current business processes, it may seem unnecessary to business leaders because they assume that internally, the business processes are well known. However, it is key in an ERP adoption process due to the way the system will integrate different processes and therefore departments. Identifying processes is important both for the company and for the vendor, this for different reasons. On the company side, it can be seen as a tool to recognize the flaws in the current processes and therefore see more clearly the benefits of the change. For the vendor and the consultant, having drawn processes helps to translate business requirements into software functions.

Throughout the research, we could observe the importance of communication and leadership in an ERP adoption process. A change of this scope requires leaders, people that have a clear vision of what they want to achieve and who are able to transmit this vision and empower, motivate, and align people. Leaders are important at every step of the change. Some authors draw a line between management and leadership; however, we perceive a need to combine

83

these roles. For instance, in our case study, the project manager appeared to be both managing and leading the change. Moreover, we have observed how frequent communication between the key stakeholders described really facilitates the change process. This communication needs to be open, allowing feedback, and there should be trust. The best way to trigger this trust is to inform, educate and be honest with the users of the system.

Additionally, we have learned that since the ERP industry is now about 25 years old, many companies are switching from an old ERP system to a new one. Does that mean it is easier to change ERP than to implement a first ERP? We believe not. First, because it is not the type of information system that is changed every year, it is a big step to take, and there must be an underlying reason for it such as the old system becoming too small for the needs of the business. Also, systems might look alike, but they still function differently from one vendor to the other, and they evolve quite frequently with updates, additional modules… Then, leaders who implemented the first ERP may often not be part of the organization anymore; therefore, for people leading change, it will often be their first ERP implementation. Overall, we consider that assuming that it will be easier because it is not the first implementation may lead to underestimating the need for a change methodology, which could in the end compromise the success of the implementation.

Finally, a change management methodology in an ERP adoption process is about recognizing the importance of creating an understanding of the need for change across the organization. Change leaders must identify every stakeholder in the process and making sure that they work together. Both the company and the vendor must understand the current business processes and in which way they will be changed by ERP to be able to inform and educate end users. Leading the change and communicating extensively throughout the process, being aware of the impact of ERP on people, will help address and reduce resistance.

B) Recommendations on continued work

This research being a bachelor thesis, our amount of time and resources to conduct our research was limited. We conducted a single case study, so there might be patterns related to change in an ERP adoption process that could not be observed with this case alone. However, talking to experts was a way to create deeper understanding of the issues related to our area of research.

We believe that there is a need for further fieldwork and empirical studies, maybe especially observing SMEs and their present and future needs for a Change Management methodology and the role of ERP consultants in this process.

84

VII. Bibliography

Books

Bryman, Alan, and Emma Bell. Business Research Methods. New York: Oxford UP, USA, 2007.

Cadle, James, and Donald Yeates. Project Management for Information Systems. 4th edition ed. Pearson Education, 2004.

Dawson, Patrick M B. Understanding Organizational Change The Contemporary Experience of People at Work. Minneapolis: Sage Publications Ltd, 2003.

Fuller, Mark, Joseph S. Valacich, Joe Valacich, and Joey George. Information Systems Project Management. Prentice Hall, 2007.

Harwood, Stephen. ERP The Implementation Cycle (COMPUTER WEEKLY PROFESSIONAL). Chicago: Butterworth-Heinemann, 2003.

Hayes, John. The Theory and Practice of Change Management. Second Edition ed. Palgrave MacMillan, 2007.

Hiatt, Jeff, and Timothy J. Creasey. Change Management: the people side of change. Prosci, 2003.

Kotter, John P. John P. Kotter on what leaders really do. Boston: Harvard Business School P, 1999.

Lientz, Bennet P., and Kathryn P. Rea. Breakthrough IT Change Management. Elsevier, 2004.

Lindkvist, Lars, and Jonas Söderlund. "What goes on in projects? On goal-directed learning processes." Beyond Project Management New Perspectives on the temporary-permanent dilemma. Copenhagen Business School P, 2002. 278-91.

Mähring, Magnus. IT Project Governance. Stockholm: EFI, The Economic Research Institute, 2002.

Moreton, Robert, and Myrvin Chester. Transforming the Business: the IT contribution. Information Systems. Cambridge: McGraw-Hill, 1997.

O'Leary, Daniel E. Enterprise Resource Planning Systems, Life Cycle, Electronic Commerce, and Risk. New York: Cambridge UP, 2000.

Paton, Robert A., and James McCalman. Change Management: A Guide to Effective Implementation. 3rd Edition ed. SAGE Publications, 2008.

Sadler, Philip. Managing Change. London: Kogan Page, 1997.

Sammon, David. The Enterprise Resource Planning Decade: Lessons Learned and Issues for the Future. IGI Global, 2004.

Spector, Bert. Implementing Organizational Change Theory and Practice. Pearson Education, 2007.

Spector, Bert. Implementing Organizational Change Theory and practice. Second Edition ed. Pearson Education, 2010.

85

Wheelwright, Steven C., and Kim B. Clark. "Chapter 8." Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality. New York: Free P, 1992.

Yin, Robert K. Case Study Research Design and methods. 3rd edition ed. Vol. 5. Approach Social Research Methods. Sage Publications, 2003.

Printed articles

Bresnen, Mike. "Conflicting and conflated discourses? Project Management, organisational change and learning." Making Projects Critical. Palgrave MacMillan, 2006. 68-89.

DeMeyer, Arnoud, Christoph H. Loch, and Michael T. Pich. "Managing Project Uncertainty: From Variation to Chaos." MIT Sloan Management Review Winter 2002: 60-67.

Jugdev, Kam, and Ralf Müller. "A Retrospective Look at our Evolving Understanding of Project Success." Project Management Journal (2005): 19-31.

Kotter, John P. "What leaders really do." Harvard Business Review (1990): 103-11.

Lindkvist, Lars, Jonas Söderlund, and Fredrik Tell. Managing Product Development Projects: On the Significance of Fountains and Deadlines. EGOS, 1998.

Newcombe, Robert. "From client to project stakeholders: a stakeholder mapping approach." Construction Management and Economics. Vol. 21. 2003. 841-48.

Nicholls, John. "The "Heart, Head and Hands" of Transforming Leadership." Leadership and Organization Development Journal 15 (1994): 8-15.

Sirkin, Harold L., Perry Keenan, and Alan Jackson. "The Hard Side of Change Management." Harvard Business Review Oct. 2005: 109-18.

Online articles

Cellars, Tara. "Change Management Models: A Look at McKinsey's 7-S Model, Lewin's Change Management Model and Kotter's Eight Step Change Model." Associated Content. 10 May 2007. 1 Apr. 2009 <http://www.associatedcontent.com/article/237685/change_management_models_a_look_at.html?cat=3>.

Gordon, Mark. "Change Management at FedEx." CIO. 2008. 2 Apr. 2009 <http://www.cio.com/article/30233/Change_Management_at_FedEx>.

Koch, Christopher. "Change Management - Understanding the Science of Change." CIO. 2008. 01 Apr. 2009 <http://www.cio.com/article/24975/Change_Management_Understanding_the_Science_of_Change?page=7>.

86

Koch, Geoff. "ABC: An Introduction to Change Management." CIO. 2008. 1 Apr. 2009 <http://www.cio.com/article/102902/ABC_An_Introduction_to_Change_Management>.

Levinson, Meridith. "Common Project Management Metrics Doom IT Departments to Failure." CIO. 2008. 2 Apr. 2009 <http://www.cio.com/article/440721/Common_Project_Management_Metrics_Doom_IT_Departments_to_Failure>.

Nickols, Fred. "Change Management 101: A Primer." Distance Consulting. 2008. 30 Mar. 2009 <http://home.att.net/~nickols/change.htm>.

Philips, Joseph. "ABC: An Introduction to IT Project Management." CIO. 2008. 3 Apr. 2009 <http://www.cio.com/article/40342/ABC_An_Introduction_to_IT_Project_Management>.

Townsend, Maya. "Becoming a Change Leader." CIO. 2007. 1 Apr. 2009 <http://www.cio.com/article/108351/Becoming_a_Change_Leader>.

Wailgum, Thomas. "ERP definition and solutions." CIO. 2007. 31 Apr. 2009 <http://www.cio.com/article/40323/ERP_definition_and_solutions>.

Websites

"Information System." Encyclopedia - Britannica Online Encyclopedia. 19 Apr. 2009 <http://www.britannica.com/>.