A STAKEHOLDER PERSPECTIVE OF ENTERPRISE SYSTEMS IMPLEMENTATION a CASE STUDY OF a UNIVERSITYS ENTERPRISE RESOURCE PLANNING PROJECT

List of Tables Table 1 Basic Characteristics of Enterprise Systems 9 Table 2 Five Features of Enterprise Systems 12 Table 3 The Main Stakeholders of ES Projects 21 Table 4 ES Life Cycle’

A STAKEHOLDER PERSPECTIVE OF ENTERPRISE

SYSTEMS IMPLEMENTATION:

A CASE STUDY OF A UNIVERSITY’S ENTERPRISE

RESOURCE PLANNING PROJECT

SATHISH S/O SRITHARAN

(B Comp., Information Systems, NUS)

A THESIS SUBMITTED

FOR THE DEGREE OF MASTER OF SCIENCE

DEPARTMENT OF INFORMATION SYSTEMS

NATIONAL UNIVERSITY OF SINGAPORE

2004

Acknowledgements

The completion of this MSc thesis is the culmination of a long and eventful journey

This was a journey that I strongly feel I would never have completed on my own With

that in mind, I would like to take this opportunity to express my heartfelt gratitude to a

few special people, without whom this thesis would not have been possible

First and foremost, I would like to thank my supervisors, Prof K S Raman and Dr Pan

Shan Ling Thank you for your help Thank you for your support Thank you for

believing in me when others, and sometimes even myself, didn’t You have taught me so

much in the time we’ve spent together, and because of you, I have not only become a

better person, but more importantly, I have finally found my way in life

Next, I would like to thank my fellow research colleagues People like Paul, Mamata,

Calvin, Chee Wee, and so many others Not only have you been a sounding board for me,

but more importantly, your dedication and passion for your work has truly inspired me to

aspire to reach greater heights in both academia and teaching

I would also like to thank my gatekeeper and the rest of the project team in my case study

site You have opened your doors to me, and done your utmost to facilitate my study, and

for that I am forever grateful

To my family, who has endured my erratic hours and behavior, I thank you for your love

and your support Without you, I would not be where I am today

Finally, to my fiancée You have stood beside me through thick and thin, and your love

has been my anchor during this time Thank you

Table of Contents

Title ……… i

Acknowledgements ……… ii

Table of Contents ……… iv

List of Tables ……… … ix

List of Figures ……… x

Executive Summary ……… xi

Chapter 1: Introduction ……… 1

1.1 Research Background ……… 1

1.2 Research Questions ……… 4

1.3 Expected Contributions ……… 4

1.4 Organization of Thesis ……… 5

Chapter 2: Literature Review ……… 6

2.1 Enterprise Systems ……… 6

2.1.1 Introduction to Enterprise Systems ……… 6

2.1.2 Features of Enterprise Systems ……… 10

2.1.2.1 Use of External Vendors ……… 12

2.1.2.2 Best Practices ……….………… 13

2.1.2.3 Potential for Integration ……… 15

2.1.2.4 Evolving Nature of Enterprise Systems ……… 16

2.1.2.5 Modular and Flexible ……… 18

2.1.2.6 Summary ……… 19

2.1.3 ES Implementation Involve a Large Number of Stakeholders ……… 19

2.1.4 Enterprise Systems Life Cycle ……… 25

2.2 Stakeholder Theory ……… 30

2.2.1 Definition of Stakeholders ……… 31

2.2.2 Several Key Stakeholder Theory Issues ……… 32

2.2.3 Sample Stakeholder Theories ……… 36

2.3 A Stakeholder Perspective of Enterprise Systems Implementations ………… 42

Chapter 3: Research Methodology ……… 46

3.1 Methodology Selection ……… 46

3.1.1 Qualitative versus Quantitative Research ……… 46

3.1.2 Case Study Approach ……… 49

3.2 Case Selection ……… 51

3.3 Data Collection ……… 52

3.4 Data Analysis ……… 58

3.5 Summary ……… 62

Chapter 4: Case Description ……… ……… 63

4.1 Introduction ……… … 63

4.2 SAP Implementation Background in the University ……… 64

4.3 The SAP Time Management (TM) Module ……… 67

4.3.1 Deciding on the TM Module ……… 67

4.3.2 Overview of the TM Project ……… 69

4.4 Stakeholders of the TM Project ……… 71

4.4.1 Project Management Team ……… 71

4.4.1.1.Steering Committee ……… 71

4.4.1.2.Project Managers ……… 72

4.4.1.3.User Lead ……… 74

4.4.1.4.HRD-Users ……… 74

4.4.1.5.HRD-IT ……… 75

4.4.1.6.SAP Lead Consultant (SAP-LC) ……… 75

4.4.1.7.Computer Department ……… 76

4.4.1.8.Development Team ……… 76

4.4.2 Other Stakeholders ……… 77

4.4.2.1.Policy Makers ……… 77

4.4.2.2.University Staff ……… 77

4.5 Project Life Cycle ……… 77

4.5.1 Project Preparation Phase ……… 80

4.5.1.1.Activities during this Phase ……… 80

4.5.1.2.Importance of Stakeholders during this Phase ……… 81

4.5.1.3.Inter-Stakeholder Relationships during this Phase ……… 84

4.5.2 Business Blueprint Phase ……… 87

4.5.2.1.Activities during this Phase ……… 87

4.5.2.2.Importance of Stakeholders during this Phase ……….… 88

4.5.2.3.Inter-Stakeholder Relationships during this Phase ……… 91

4.5.3 Realization Phase ……… 101

4.5.4 Final Preparation Phase ……… 101

4.5.5 Go-Live and Support Phase ……… 102

4.5.6 Post-Implementation Phase ……… 102

Chapter 5: Research Findings ……… ……… 103

5.1 Stakeholder Identification ……… 103

5.1.1 Key Activities Identification ……… 104

5.1.2 Relevant Stakeholder Involvement Identification ……… 105

5.1.3 Relevant Inter-Relationships Identification ……… 107

5.1.4 Stakeholder Identification Model ……… 109

5.2 Stakeholder Prioritization ……… 110

5.2.1 Stakeholders’ Legitimacy Characteristics ……… 112

5.2.2 Stakeholders’ Level A Sources of Power ……… 113

5.2.3 Stakeholders’ Level B Sources of Power ……… 114

5.2.4 Stakeholder Prioritization Model ……… 115

5.3 Stakeholder Management ………116

5.3.1 Project Stakeholder Mix ……… 117

5.3.2 Inter-Stakeholder Relationships Facilitation ………119

5.3.3 Inter-Stakeholder Knowledge Sharing Facilitation ……… 121

5.3.4 Stakeholder Management Model ……… 124

5.4 Summary ……… 126

Chapter 6: Conclusion ……… … 128

6.1 Summary ……… 128

6.2 Research Contributions ……… … 130

6.2.1 Contributions to Theory … ……… 131

6.2.2 Contributions to Practice … ……… 134

6.3 Future Research ……… 137

6.4 Limitations of Research ……… 140

Chapter 7: References ……… 142

Appendix A: Case Study Protocol …… 157

A.1 Introduction ……… 157

A.2 Briefing the Interviewee ……… 158

A.3 Interview Questions ……… 159

A.4 List of Stakeholders ……… 162

Appendix B: A Sample of the Three-Step Thematic Analysis …… 163

B.1 Sample Thematic Analysis: Step One……… 163

B.2 Sample Thematic Analysis: Step Two … ……… 165

B.3 Sample Thematic Analysis: Step Three ……… 167

Appendix C: A Sample Codebook ……… 169

C.1 Code Number One ……… 169

C.2 Code Number Two ……… 170

List of Tables

Table 1 Basic Characteristics of Enterprise Systems 9

Table 2 Five Features of Enterprise Systems 12

Table 3 The Main Stakeholders of ES Projects 21

Table 4 ES Life Cycle’s Key Players and Activities (Markus & Tanis, 2000) 27

Table 5 Six-Step ES Project Life Cycle Model 30

Table 6 Strengths and Weaknesses of Sample Stakeholder Theories 42

Table 7 Qualitative versus Quantitative Research 47

Table 8 Relevant Situations for Different Qualitative Research Strategies 49

Table 9 Details of Stakeholders Interviewed 57

Table 10 Results of Thematic Analysis of Case Study 60

Table 11 SAP Implementation Timeline in the University 66

Table 12 Activities and Stakeholders during the TM Project Life Cycle 80

List of Figures

Figure 2 Anatomy of an Enterprise System (Davenport, 1998) 20

Figure 3 Enterprise Systems Life Cycle (Markus & Tanis, 2000) 25

Figure 4 Accelerated SAP (ASAP) Roadmap 28

Figure 5 Typology of Influence Strategies (Frooman, 1999) 37

Figure 6 A Stakeholder Theory Model (Mitchell et al., 1997) 39

Figure 7 Extended Relational Foundations (ERF) Model 40

(Hirt & Swanson, 2001)

Figure 10 Inter-Stakeholder Relationships during the Project Preparation Phase 85

Figure 11 Inter-Stakeholder Relationships during the Business Blueprint Phase 92

Figure 12 Stakeholder Identification Model 109

Figure 13 Stakeholder Prioritization Model 116

Figure 14 Stakeholder Management Model 125

Figure 15 Stakeholder Analysis Model of Enterprise Systems Implementation 127

Executive Summary

Given the high rate of failure of Enterprise Systems (ES) projects (Sarker & Lee, 2003),

ES surprisingly remain an under-researched area in IS (Rosemann & Watson, 2002)

Studies that have explored ES per se have focused on common issues, such as measures

of success, and lack of fit between organizational needs and system capabilities In

contrast, the study of the stakeholders of ES projects has not been adequately explored in

IS practice (Papazafeiropoulou et al., 2002) The involvement of the large number of

stakeholders, from within and without the organization in ES projects, though, seems to

indicate the need for more in-depth studies on the perspectives of stakeholders and their

inter-relationships (Pouloudi, 1999)

This study thus proposes the use of Stakeholder Theory as a lens through which to

analyze the role and management of stakeholders of ES projects In particular, this study

begins with a review of literature on ES, to highlight the importance of stakeholders

during ES projects, and on Stakeholder Theory, to showcase how it can facilitate the

analysis of ES project stakeholders Next, a case study of the first two phases of a

university’s ERP implementation was conducted Based on this, several findings were

identified with regards to the three components of the stakeholder analysis process of ES

implementations; namely stakeholder identification, stakeholder prioritization, and

stakeholder management

For stakeholder identification, this study recognized the need for the identification of key

activities in each phase of the ES project life cycle, followed by the identification of the

stakeholders and their inter-relationships during each of these activities This results in a

comprehensive list of the relevant stakeholders during the ES project For stakeholder

prioritization, this study identified two legitimacy characteristics, two Level A sources of

power and two level B sources of power, that facilitate the differentiation between the

relevant stakeholders such that the more appropriate important stakeholders receive

greater priority during each phase of the project For stakeholder management, this study

identified the need to form a well-balanced mix of the stakeholders involved in the

project This study also identified the need to facilitate an environment in which these

stakeholders can enhance their inter-relationships and knowledge sharing

Finally, this study concludes with a comprehensive stakeholder analysis model for the

study of the stakeholders of ES implementations and some future areas for research

Consequently, this study hopes to contribute towards bridging the gap in the

understanding of the stakeholders of ES projects

Chapter 1

Introduction

1.1 Research Background

Enterprise Systems (ES), as a distinct phenomenon of interest, are an important yet under

researched area in IS curricula (Klaus et al., 2000; Rosemann & Watson, 2002) This is

surprising since the business world’s embrace of ES may be the most important

development in the corporate use of IS in the 1990s, despite the media attention given to

the rise of the Internet (Davenport, 1998) This is especially so today, as ES have become

the price of entry for running a business (Kumar & van Hillegersberg, 2000; Sarker &

Lee, 2003) and the question for managers is no longer whether to implement ES but

rather how to maximize such systems (Sousa, 2002)

The lack of studies on ES per se is all the more surprising when you realize that a

significant proportion of ES projects fail (Sarker & Lee, 2003) At best, these failures

result in huge losses for the organization, as in the case of Dell Computers, which spent

US$30 million before abandoning its SAP project (Staehr et al., 2002) At worst, they

could lead to cases such as FoxMeyer Drugs, which filed for bankruptcy when its SAP

R/3 project went badly wrong and FoxMeyer ended up suing its implementation partners,

SAP and Anderson Consulting (Volkoff & Sawyer, 2001)

ES are integrated enterprise-wide systems based on centralized databases They are large,

comprehensive and complex systems, involving large groups of people (Oliver & Romm,

2002; Rosemann & Watson, 2002) They are also expensive projects, not just in terms of

money, with costs ranging from $50 million to over $500 million (Davenport, 1998; Pan

et al., 2001), but also in terms of other investments, such as staff and time (Adam &

O’Doherty, 2000; Lee et al., 2003; Poston & Grabski, 2000) It is thus perhaps not

surprising for so many ES projects to turn out to be less successful than expected

(Akkermans & Helden, 2002; Sarker & Lee, 2003)

Thus far, ES studies have primarily focused on common issues, such as measures of

success, lack of fit between organizational needs and system capabilities, and systems

integration Studies on certain groups of stakeholders involved in ES implementations,

such as users and IT staff, have also been advocated in recent literature (Pouloudi, 1999),

but this has been on a small scale where each group is considered individually In reality,

ES projects involve many different groups of people, or stakeholders, from within and

without the organization (Schneider, 2002) These stakeholders generally have key roles

to play in ES projects and interact closely to fulfill those roles

For example, the use of external third-parties to implement ES (Light, 2001) results not

just in the involvement of new external stakeholders in the project, but also new

inter-stakeholder relationships among these external inter-stakeholders and traditional internal

stakeholders, such as IS staff and employees ES’ ability to facilitate enterprise-wide

integration also results in greater involvement in the project by the numerous

stakeholders from across the organization, thus resulting in a complex web of

inter-stakeholder relationships Such issues exemplify the diverse range of inter-stakeholders who

potentially are affected by or can impact on ES implementations Logically, it thus

appears that organizations should pay closer attention to these stakeholders and their

needs Instead, their importance, different viewpoints and ability to make things happen

has been undermined in much of IS practice (Papazafeiropoulou et al., 2002)

This study posits that an in-depth study of the relevant stakeholders of ES

implementations will provide greater insight into the impact they can have on the project

and each other, and hence, how they should best be managed to maximize their

contributions This study proposes Stakeholder Theory as a lens to look at the

stakeholders involved in ES implementations

Stakeholder Theory focuses on the people factor instead of the technical factors of ES

projects and looks at who (or what) are the stakeholders of an organization, and whom (or

what) should organizations pay attention to (Freeman, 1984) It also advocates the study

of the more important, and yet under-researched, issue of how the organization should

deal with stakeholders who vary in importance (Jawahar & McLaughlin, 2001)

Although such an in-depth exploration of the perspectives of stakeholders and their

inter-relations seems obvious (Pouloudi, 1999), there has been little systematic application of

stakeholder analysis concepts, particularly in the context of ES implementations This

study aims to help to bridge this gap in ES implementation literature through a

qualitative, interpretive case study of the first two phases of a university’s ERP project

from a stakeholder perspective Data from this case study was then analyzed to identify

key findings about the impact of stakeholders during ES projects

1.2 Research Questions

To facilitate this study, three research questions were raised They revolve around the

application of stakeholder theory to the study of ES implementation

1 How can the stakeholders of an ES implementation be identified?

2 How can the important stakeholders of an ES implementation be differentiated?

3 How can the different stakeholders be managed?

The first question focuses on the identification of the relevant stakeholders involved in

ES implementations, out of the entire gamut of stakeholders associated with the

organization The second question addresses the issue of who among these stakeholders

are more important and deserving of attention Finally, the last question considers how,

given the different levels of importance of its stakeholders, organizations should manage

them during the course of ES implementations

1.3 Expected Contributions

The contributions of this thesis are expected to be relevant to both researchers and

practitioners To researchers, the findings should help to bridge the gap in ES

implementation literature and give some insight into ES implementation from the project

stakeholders’ perspective, thus serving as a launch pad for further studies in this area

As for practitioners, the findings should highlight the practical importance of better

understanding of the role of stakeholders and management of the stakeholders involved in

ES projects Given the high failure rate of ES projects, practitioners need better solutions

on how to tackle these projects The work done in this study can thus potentially help

them to see the value of stakeholder management to the success of ES projects

1.4 Organization of Thesis

This thesis consists of six chapters, starting with this introduction chapter The next

chapter presents a literature review on two topics The first topic is Enterprise Systems;

their key features, the different stakeholders involved in ES projects, and their project life

cycle The second topic is Stakeholder Theory; how stakeholders are defined, several key

issues, and some sample theories

Chapter three presents the research methodology used in this thesis, how it was selected,

how the case was identified, and how the data from the study was collected and analyzed

Chapter four describes the details of the case, while chapter five presents the findings

from the case The study concludes in chapter six with a summary of the study, research

contributions, areas for future research, and limitations of this study

Chapter 2

Literature Review

2.1 Enterprise Systems

2.1.1 Introduction to Enterprise Systems

Enterprise Systems evolved from Enterprise Resource Planning (ERP) systems, which

were large, packaged application software that supported manufacturing organizations’

needs for better materials and logistics management since the 1970s (Hayman, 2000;

Klaus et al., 2000) As ERP systems grew in scope, Davenport (1998) noted that ERP

was too narrow a term to denote enterprise-wide integrated systems, and suggested that

the term Enterprise Systems (ES) be used instead (Rosemann & Watson, 2002)

Since then, Enterprise Systems has become an umbrella term not just for ERP systems

but other types of enterprise-wide integrated systems as well These include supply chain

management, inventory control, manufacturing scheduling, sales support, customer

relationship management, financial accounting, enterprise resource planning, human

resources, and product life cycle management systems (Markus & Tanis, 2000; Sedera et

al., 2003; Shang & Seddon, 2002) Generally, ES are defined as pre-packaged

enterprise-wide systems that integrate various day-to-day operations into a single system with a

shared database (Lee & Lee, 2000; Newell et al., 2003; Sedera et al., 2003)

The three popular types of ES are ERP, Customer Relationship Management (CRM), and

Supply Chain Management (SCM) systems (Brown & Vessey, 2003; Shaw, 2000) ERP

systems traditionally support recurring business processes like procurement and

manufacturing, enable enterprise-wide management of resources, and are not focused on

less structured and irregular processes like marketing and project management (Klaus et

al., 2000; Shang & Seddon, 2002)

Throughout the 1980s and 1990s, ERP systems expanded beyond their original scope, as

software entrepreneurs developed integrated software packages in which multiple

functional applications shared a common database to meet organizational

information-processing needs (Markus & Tanis, 2000) Simultaneously, traditional inventory control

(IC) packages evolved into Materials Requirements Planning (MRP) Systems, and

expanded to include other enterprise processes such as marketing, financial accounting,

and human resource management (e.g Baan) (Kumar & van Hillegersberg, 2000; Markus

& Tanis, 2000) ERP systems are an amalgam of these different points of origin

In the early 1980s, ERP systems were built on mainframe technology In the late 1980s,

they moved to minicomputers but their potential was still unrealized Acceptance of ERP

systems as a legitimate solution only emerged following the popularity of the

client/server platform and development of cross-functional integrated ERP systems based

on this architecture (Bennett & Timbrell, 2000; Markus & Tanis, 2000; Scott & Vessey,

2002) The growth of ERP systems is further expected to explode with the emergence of

new Web-based applications that provide levels of connectivity to rival the proprietary

networks of large organizations (Bennett & Timbrell, 2000; Davenport, 2000)

CRM and SCM systems evolved from ERP systems (Kumar & van Hillegersberg, 2000)

CRM systems help organizations optimize interactions with customers via one or more

touch points to acquire, retain or cross-sell to customers (Goodhue et al., 2002) by

incorporating traditional marketing-oriented functions, such as sales force automation and

customer service software (Davenport, 2000) SCM systems help organizations build

tighter collaborative networks of ERP systems with suppliers and buyers (Howard et al.,

2003; Lee et al., 2003; Markus & Tanis, 2000) to ensure that the right products are

delivered at the right time, at the right place, and at competitive prices (Shore, 2001)

Figure 1: Types of Enterprise Systems

Ideally, ERP, CRM and SCM systems are coordinated, with ERP systems integrating

back-office functions to serve as the backbone for the organization, CRM systems

integrating marketing, sales and customer service interactions with customers, and SCM

systems integrating processes among the organizations in the supply chain (see Figure 1)

Characteristic Reference

Large, comprehensive systems Oliver & Romm, 2002; Rosemann &

Watson, 2002 Highly complex to implement and manage Oliver & Romm, 2002; Rosemann &

Watson, 2002 Involve large groups of people and

resources

Akkermans & Helden, 2002

Expensive (monetary) Davenport, 1998; Livermore & Ragowsky,

2002; Pan et al., 2001; Robey et al., 2002;

Rodecker & Hess, 2001 Expensive (other investments, such as time,

capital and staff)

Adam & O’Doherty, 2000; Lee et al., 2003; Poston & Grabski, 2000

Many project exceed initial deadlines Kræmmergaard & Rose, 2002; Lorenzo,

2001; Murray & Coffin, 2001; Sprott, 2000 Many projects are less successful than

intended

Akkermans & Helden, 2002; Parr &

Shanks, 2000; Sarker & Lee, 2003

Table 1: Basic Characteristics of Enterprise Systems

ES have several basic characteristics (see Table 1) They are large, comprehensive

systems that are highly complex to implement and manage, involving large groups of

people and resources (Oliver & Romm, 2002; Rosemann & Watson, 2002) Many

projects last from fourteen months to four years (Murray & Coffin, 2001), with most

exceeding their initial deadlines (Kræmmergaard & Rose, 2002; Lorenzo, 2001; Sprott,

2000) They are also expensive (Livermore & Ragowsky, 2002; Robey et al., 2002;

Rodecker & Hess, 2001), with costs easily ranging from $50 million to more than $500

million (Davenport, 1998; Pan et al., 2001)

These high expenses are not limited to money, as significant investments also need to be

made in terms of capital, staff and time (Adam & O’Doherty, 2000; Lee et al., 2003;

Poston & Grabski, 2000) It is thus perhaps not surprising that many ES projects turn out

to be less successful than intended (Akkermans & Helden, 2002; Sarker & Lee, 2003)

due to these high risks of implementation (Parr & Shanks, 2000) Despite these risks,

there is a booming market today for such enterprise-wide integrated software packages

(Markus & Tanis, 2000) due to their potential to integrate organizational functions into a

single system with a shared database

2.1.2 Features of Enterprise Systems

As mentioned above, ES are large, complex and comprehensive enterprise-wide systems

whose implementation involves various different stakeholders Specifically, ES have five

special characteristics that highlight the potential impact of stakeholders on ES

implementations (see Table 2)

Firstly, ES projects’ development and maintenance are usually outsourced (Light, 2001)

Secondly, these outsourced systems often come with a pre-defined set of best practices

(Davenport, 1998) Thirdly, ES facilitate integration, which has long been the holy grail

for organizations implementing IS (Kumar & van Hillegersberg, 2000) Fourthly, ES

should be considered as ongoing concerns (Hirt & Swanson, 2001) due to their constantly

evolving nature Finally, ES are modular and flexible (Davenport, 2000) These

characteristics and the importance of stakeholders in each case are described next

Features Details

Use of external

vendors

- A preferred option due to the size and complexity of ES

- ES need different sets of tasks, skills and expertise

- Shortage of skilled IS staff in organizations

- Exploit experienced external expertise to plug gaps in organizational capabilities

- Long-term relationship between external vendors and organization

Best practices - ES come with their own in-built logic and best practices

- Organizations can change the system to suit their processes

- Organizations can change their process to suit the system

Potential for

integration

- A core objective of organizations

- A complex process

- ES is particularly useful for coping with legacy systems

- ES integration can affect the entire organization

Evolving

nature of ES

- Important to vendors

- Increase sales

- Easier to support several versions than various products

- Competitive market among vendors

- Important to customers

- Keep systems updated

- Get added functionality

- To counter external pressures from value-chain partners

- Increased organizational dependence on vendors

- Offers a higher level of portability

- Facilitates integration among supply chain partners

Table 2: Five Features of Enterprise Systems

2.1.2.1 Use of External Vendors

Organizations can develop ES in-house or purchase templates tailored for specific

industries (Klaus et al., 2000; Markus & Tanis, 2000; Sasovova et al., 2001) Due to their

size and complexity though, outsourcing development or purchasing pre-packaged

systems is the preferred option (Reimers, 2003; Scheer & Habermann, 2000; Willcocks &

Sykes, 2000)

Another reason for this trend is that ES implementations require a different set of tasks,

skills and expertise from traditional in-house developed systems (Hirt & Swanson, 2001)

Thus, using external vendors facilitates the acquisition of experienced external expertise

to plug this gap and expedite the organization’s exploitation of ES to its fullest (Adam &

O’Doherty, 2000; Nah et al., 2001; Sumner, 2000) This need for external expertise is

compounded by the shortage of skilled IS staff in organizations (Klaus et al., 2000)

Despite this, the focus in recent years has still primarily been on other stakeholders, such

as customers and end-users, as many have failed to foresee the rising importance of

vendors and third parties (Hirt & Swanson, 2001) This is especially surprising as ES

projects as not merely one-off things, but the start of long-term relationships between

organizations and external vendors (Markus & Tanis, 2000) Furthermore, as ES grow

more complex and comprehensive, organizational dependence on these external parties

increase (Davenport, 2000; Nah et al., 2001)

Consequently, organizations must learn how best to manage their long-term relationships

with external parties In addition, external parties change the organizational landscape

For example, internal IS staff may now handle systems integration and support, rather

than systems development Organizations thus need to identify and manage the new roles

and inter-relationships amongst their internal and external stakeholders

2.1.2.2 Best Practices

Another unique characteristic of ES is that they impose their own logic on the

organization’s strategy and culture (Davenport, 1998), based on the knowledge and

experience accumulated from previous implementations (Shang & Seddon, 2002) These

best practices could govern implementation methodologies (Knapp & Shin, 2001), data

flow (Rodecker & Hess, 2001), or business process models (Kumar & van Hillegersberg,

2000; Lee & Lee, 2000)

Despite the idealistic view that there is one universal set of best practices (Murray &

Coffin, 2001), these practices generally cater to specific classes of organizations (Nah et

al., 2001), rather than all organizations They are also vendor-defined and not

customer-defined (Davenport, 1998) Despite that, they do offer benefits garnered from lessons

learnt by past implementers, such as operational control, streamlined processes and

just-in-time manufacturing (Hayman, 2000; Scott & Vessey, 2002)

The question then is whether the system fits organizational needs (Hong & Kim, 2002;

Soh et al., 2000; Van Everdingen et al., 2000) If yes, are changes to the organization or

system needed to support these best practices, and how should they be managed

(Kræmmergaard & Rose, 2002; Murray & Coffin, 2001)

On the one hand, organizations can configure a generic system to meet their needs

(Esteves & Pastor, 2001b; Rosemann & Watson, 2002) if they have unique core

requirements (Light, 2001) or to increase differentiation from competitors (Kremers &

van Dissel, 2000) However, it is difficult, costly and risky to modify the complex ES

(Jones & Price, 2001; Lee & Lee, 2000; Sumner, 2000), and it could cause complications

during future upgrades (Hong & Kim, 2002; Soh et al., 2000)

On the other hand, organizations can modify the organization via business process

reengineering (BPR) to support these best practices (Adam & O’Doherty, 2000; Kremers

& van Dissel, 2000; Rodecker & Hess, 2001) This too has consequences, as BPR can be

rather tedious (Robey et al., 2002), especially to organizations whose business schemes

cannot be reconciled to the standards required by the system (Lee et al., 2003)

In both cases, there is significant impact on organizational stakeholders For example, in

modifying the system, closer relationships may need to be fostered between the external

parties and internal IS staff to facilitate knowledge transfer so the IS staff can

subsequently handle system maintenance Alternatively following BPR, organizations

may need to redefine their internal inter-relationships with and between their staff whose

roles could change, and who need to be convinced and trained to utilize the new systems

2.1.2.3 Potential for Integration

Integration is a core objective for organizations implementing ES (Oliver & Romm,

2002; Singletary, 2002) The quest for integration has been the holy grail of IS since the

1950s but high levels of organizational and technical complexity have been major

stumbling blocks, until the emergence of ES, which facilitate the unification of an

organization’s IS (Adam & O’Doherty, 2000; Kumar & van Hillegersberg, 2000;

Singletary, 2002)

Even so, ES integration is still a complex process (Kræmmergaard & Rose, 2002; Sousa,

2002) It can involve the integration of modules, such as logistics and human resources

(Klaus et al., 2000; Sasovova et al., 2001), organizational functions (Knapp & Shin,

2001; Lee & Lee, 2000; Nah et al., 2001), or information across these functional units

(Jones & Price, 2001; Murray & Coffin, 2001; Reimers, 2003) ES integration is

particular useful for coping with legacy systems, which were custom-built and

proliferated over the years into complex, disjointed and obsolete “islands of automation”

(Brown & Vessey, 2003; McKenney & McFarlan, 1982; Tan & Pan, 2002)

In any case, ES integration can affect the entire organization (Reimers, 2003), especially

given the single, centralized, enterprise-wide database to which all the ES applications

are linked (Hirt & Swanson, 2001; Murphy & Simon, 2002; Stratman & Roth, 2002)

Some ES even go beyond traditional organizational boundaries to facilitate integration

along the inter-organizational supply chain (Davenport, 2000; Markus & Tanis, 2000)

ES projects have the potential to affect a number of organizational stakeholders within

and without the organization Thus, organizations need to cater to the needs of all these

diverse stakeholders, while trying to fulfill the primary objectives of their owners

Organizations also need to work out ways of building closer inter-relationships between

all the internal and external stakeholders to balance their contributions

2.1.2.4 Evolving Nature of Enterprise Systems

Another characteristic of ES is that they are not static systems They are always evolving

to better meet organizational requirements, with new versions and upgrades regularly

being made available (Brown & Vessey, 2003; Hirt & Swanson, 2001; Kumar & van

Hillegersberg, 2000) Organizations thus no longer ask “Should we upgrade?” but rather

“When do we upgrade?” with the main reasons holding them back being financial or bad

past experiences (Kremers & van Dissel, 2000)

These upgrades are important to vendors They increase sales from increased

functionality or bolt-on products (Kremers & van Dissel, 2000) Having a number of

smaller software versions is also easier to support as compared to a large variety of

products (Kremers & van Dissel, 2000) Regular upgrading is important to vendors too,

to keep pace with their competitors and prevent them from penetrating their market base

(Davenport, 2000)

Regular upgrades are important to organizations as they keep their systems updated

(Kremers & van Dissel, 2000; Shang & Seddon, 2002), and help them avoid major

conversion headaches as compared to if they skip a few versions (Markus & Tanis,

2000) The upgrades could also be implemented to acquire additional functionality or in

response to pressure from value chain partners (Kremers & van Dissel, 2000)

These regular updates though, may not only disrupt organizations’ previous

customizations (Kumar & van Hillegersberg, 2000; Murray & Coffin, 2001), they cause

organizations to become increasingly dependent on their vendors for future assistance,

updates and maintenance (Light, 2001; Oliver & Romm, 2002, Sumner, 2000)

Consequently closer ties are needed between organizations and external parties so

upgrades can be carried out in an efficient and timely manner

2.1.2.5 Modular and Flexible

The fifth characteristic of ES is its modularity The basic core ES is the rigid backbone

into which disparate best of breed applications are plugged and played (Davenport, 2000;

Sasovova et al., 2001) Vendors employ a component-based strategy based on

object-oriented systems modeling to develop modules that can be independently adopted on top

of the core ES (Murrary & Coffin, 2001), such that their internal complexity is hidden

from users who only have to understand the clearly defined interfaces (Kumar & van

Hillegersberg, 2000; Sprott, 2000)

This feature is especially important in today’s dynamic business environment, as

organizations need to be flexible and agile to cope with rapid internal and external

changes (Sprott, 2000; Stratman & Roth, 2002; Van Everdingen et al., 2000) ES thus

enables organizations to more flexibly mix and match their ES modules to better suit their

needs ES also offer high levels of portability, which further enhances the organization’s

ability to flexibly adapt to changing requirements (Adam & O’Doherty, 2000) This also

results in highly modularized organizations, each specialized in its core competency but

always prepared to link up with its business partners’ ES (Shaw, 2000)

Hence, ES projects again involve many stakeholders within and without the organization

This is because each new module has to be integrated with existing modules and should

complement the modules of partner departments and organizations Thus, the conditions

that necessitate flexible systems also necessitate flexible stakeholder relationships

2.1.2.6 Summary

In analyzing these five areas, it is clear that organizations who implement ES have to deal

with various different stakeholders from within and without the company Even their

usual stakeholders, such as end-users and internal IS staff, are changing, as their roles,

responsibilities and activities during ES implementations are different as compared to

other IS projects As such, organizations need to be able to identify and differentiate

between the new roles of these stakeholders during ES projects and their subsequent

levels of importance From there, organizations need to identify ways of managing them

to maximize their contributions during ES implementations

2.1.3 ES Implementation Involve a Large Number of Stakeholders

As seen from the characteristics mentioned above, ES implementations have a wide range

of impacts on the stakeholders involved As part of the development and use of ES, the

roles, responsibilities and inter-relationships of stakeholders are often redefined

Organizations thus need to keep abreast of their stakeholders and their interactions, so

that they can better manage them accordingly Furthermore, considering the wide scope

and impact of ES throughout the organization, they typically require input from a host of

different stakeholders from within and without the organization Hence, organizations

need to know how to identify the relevant stakeholders of such ES projects and find ways

to meet their various interests

Managers and stakeholders Reporting applications

Back-office administrators and workers

Suppliers

Manufacturing applications

Financial applications Sales and

delivery applications

Service applications

Sales force and

customer service reps

Customers Central

database

HR Employees

Human resource management applications

Inventory and supply applications

Figure 2: Anatomy of an Enterprise System (Davenport, 1998)

In a way, ES projects can be seen as socio-technical challenges where group dynamics

and technological advancement continuously and mutually shape each other (Newell et

al., 2002) There is thus a need to identify and understand these groups and their

dynamics Davenport (1998) initially attempted to identify the groups involved in ES (see

Figure 2) and his list included top management, shareholders (which he termed as

stakeholders), employees, customers and suppliers Other researchers further explored the

role of these stakeholders, and others, such as internal IS staff, third party vendors and

end-users as a whole In general though, the four main stakeholder categories of ES are

management, end-users, IT staff and external parties (see Table 3)

Stakeholder References

Management Akkermans & Helden, 2002; Brown & Vessey,

2003; Davenport, 1998; Esteves & Pastor, 2001a;

Kræmmergaard & Rose, 2002; Livermore &

Ragowsky, 2002; Murray & Coffin, 2001;

Reimers, 2003; Sarker & Lee, 2003; Stratman &

Roth, 2002; Sumner, 2000 End-Users Baskerville et al., 2000; Esteves & Pastor, 2001a;

Esteves & Pastor, 2001b; Hirt & Swanson, 2001;

Hong & Kim, 2002; Howard et al., 2003;

Howcroft & Light, 2002; Klaus et al., 2000;

Kræmmergaard & Rose, 2002; Lorenzo, 2001;

Pan et al., 2001 Internal IS Staff Baskerville et al., 2000; Hirt & Swanson, 2001

External Parties Akkermans & Helden, 2002; Brown & Vessey,

2003; Markus et at., 2000a; Nah et al., 2001;

Stratman & Roth, 2002; Volkoff & Sawyer, 2001

Table 3: The Main Stakeholders of ES Projects

The first key stakeholder category of ES projects is management This includes the

steering committee and project managers of the ES project The active (Brown & Vessey,

2003; Davenport, 1998; Murray & Coffin, 2001), strong and committed (Livermore &

Ragowsky, 2002; Sarker & Lee, 2003) support of management is important to the project

Such support signals the importance of the system and shows management’s backing of

the project (Akkermans & Helden, 2002; Reimers, 2003), which is crucial given its

complexity and comprehensive, enterprise-wide nature

Their support helps to build acceptance and confidence in the system among the rest of

the organizational stakeholders, to get them to contribute more effectively to the project

Such support needs to be evident throughout the project, from the start to roll it out, in the

middle to keep it on track, and at the end to encourage its utilization (Esteves & Pastor,

2001a) In particular, the project should be supported by a project champion who

overseas the project’s progress and allocates the resources required for successful

implementation (Esteves & Psator, 2001a; Stratman & Roth, 2002; Sumner, 2000) This

person needs sufficient strength and authority over the stakeholders (Sarker & Lee, 2003)

to energize them to work (Kræmmergaard & Rose, 2002)

The second major stakeholder category of ES projects is the end-users This includes

internal staff and external customers End-users are important as they possess the

necessary know-how of the relevant business processes, which needs to be accurately

mapped to the system’s configurations (Esteves & Pastor, 2001a; Hirt & Swanson, 2001;

Howcroft & Light, 2002) ES projects are more likely to succeed if end-user involvement

and understanding is high, and they have realistic project expectations (Esteves & Pastor,

2001b; Kræmmergaard & Rose, 2002; Pan et al., 2001)

Increasing the involvement of end-users also minimizes their resistance to changes in job

content and uncertainty in the new system (Hong & Kim, 2002) The end-users of ES

also require extensive training (Lorenzo, 2001) to learn a wider range of skills to

effectively handle the system, and interact with internal IS staff and external vendors

(Baskerville et al., 2000; Howcroft & Light, 2002) One particularly important group of

end-users is the organization’s customers, as they are no longer passive recipients of

products and services Instead, they have become increasingly discerning, demanding

(Klaus et al., 2000), price conscious and impatient with regards to what they want

(Howard et al., 2003)

The third important stakeholder category of ES projects is the internal IS staff This

includes both permanent and contract IS staff in the organization handling the system’s

technical implementation As ES are generally developed by external parties, their role is

significantly different during ES projects (Hirt & Swanson, 2001) They no longer design

and build the actual system Instead, they require skills that are oriented towards

combining “package” knowledge and business knowledge (Baskerville et al., 2000)

They also help the external parties to gather end-user feedback to facilitate the system’s

configuration and its integration with existing organizational systems

The final important stakeholder category is the external parties This includes third-party

vendors, who develop the ES, and external consultants Where previously, organizations

would not contemplate delegating a project as important as an ES implementation to an

outside party, today, they have to do so as they lack the necessary skills to handle it

themselves (Akkermans & Helden, 2002) Third-party vendors thus help to develop the

systems software but are otherwise normally not involved in the ensuing implementation

(Volkoff & Sawyer, 2001)

External consultants then help to fill any gaps in expertise, product knowledge, process

guidance and IT skills (Brown & Vessey, 2003; Stratman & Roth, 2002; Volkoff &

Sawyer, 2001) during the implementation process As many as a dozen or more external

agencies – such as vendors of ES, ES extensions and supporting hardware, and

consultants – may be involved in different aspects of the ES experience and coordinating

their efforts is, to put it mildly, a challenge (Markus et al., 2000)

For an ES project to be successful, representatives of each of these categories should be

involved, and the strengths of each group maximized However, as it is unlikely that a

homogeneous category has all the relevant knowledge and expertise to implement ES

(Newell et al., 2002), the mix of representatives should be well-balanced to ensure a good

combination of knowledge, skills and experience (Sarker & Lee, 2003; Staehr et al.,

2002; Willcocks & Sykes, 2000) Both internal and external personnel should be included

to enable internal staff to “grow” the necessary skills for ES projects (Sumner, 2000)

This leads to three questions Firstly, given the project’s needs and the numerous

stakeholders in organizations, who should be included in these projects? Secondly, as the

project involves various stakeholders with their own needs and responsibilities, which of

them are more important and deserving of attention? Finally, given their different levels

of importance and the need to cater to as many of their interests as possible, how can

these different stakeholders be simultaneously managed?

2.1.4 Enterprise Systems Life Cycle

The identification and management of the relevant stakeholders of ES projects, though

seemingly straightforward on the surface, is actually rather complex as ES

implementations are not static processes They iteratively traverse several phases, each of

which is characterized by its own key players, activities, problems, metrics and outcomes

(Chang et al., 2000; Markus & Tanis, 2000; Newell et al., 2002) In particular,

stakeholders, and their roles and interactions, vary according to the phase in which they

are in (Pouloudi, 1999) (see Table 4)

Ideas to dollars

Phase I

Project chartering

Decisions defining the

business case and

Impacts to performance

Phase IV

Onward & upward

Maintaining system, porting users, getti sults, upgrading

re

Figure 3: Enterprise Systems Life Cycle (Markus & Tanis, 2000)

A widely referenced theoretical ES life cycle model was developed by Markus & Tanis

(2000) (see Figure 3) and consists of four phases, each with its’ own players and

activities (see Table 4) First is the Project Chartering, or planning, phase (Staehr et al.,

2002) Next is the Project phase, which involves the software configuration and roll-out

(Markus et al., 2000; Staehr et al., 2002) Third is the Shakedown phase from when the

system goes live to when normal operations are achieved (Staehr et al., 2002), after

which the project team either continues to handle the project or passes control to the

operational managers or end users Finally, the Onward and Upward phase lasts until the

system is upgraded or replaced, which can take up to four years (Staehr et al., 2002)

Phases Key Players/Stakeholders Key Activities

• Identifying a project manager

• Approving a budget and schedule

The project • Project manager

• Project team members (often non-technical members of various business units and functional areas)

Shakedown • Project manager

• Project team members (often non-technical members of various business units and functional areas)

• Operational managers

• End users

• IT support personnel (internal

or external)

• Bug fixing and rework

• System performance tuning

• Continuous business improvement

• Additional user skill building

• Post-implementation benefit assessment

Table 4: ES Life Cycle’s Key Players and Activities (Markus & Tanis, 2000)

A more practical ES model employed by organizations implementing SAP software is

SAP’s Accelerated SAP (ASAP) methodology (ASAP Roadmap; SAPFile) (see Figure

4) ASAP combines methodologies, tools, templates and best practices to streamline

implementations, covering a broad spectrum of functionality, and allowing for

modifications to the software to meet specific organizational requirements

Figure 4: Accelerated SAP (ASAP) Roadmap

This methodology consists of five phases During the Project Preparation phase, the

project team is finalized, the need for additional hardware is reviewed, and the high-level

project plan is completed During the Business Blueprint phase, a blueprint is developed

to understand the organization’s business goals and determine the business processes to

support these goals, and the key users attend the customized SAP training In the

Realization phase, the team and SAP consultants co-configure the business processes