abstract - dagda.shef.ac.ukdagda.shef.ac.uk/dispub/dissertations/2005-06/external/oladiran... ·...

Titilope Oladiran MSc. Information Systems

1

ABSTRACT

With the development of the IT architect such as enterprise systems, projects failure

has become a controversial issue in the IS research area. Many large organisations,

these days tend leverage cost by employing the implementation of IS systems such as

ERP. Incredible facts shows projects failure can lead to catastrophic results in either

economic or social divisions. For example, FoxMeyer a leading drug company went

bankrupt after an ERP implementation. There is a vital need to fill the research gap

by investigating “what are the critical factors which contributes a lot to ERP

projects failure”.

This dissertation surveys the analysis and findings multiple case studies of large

organisations where ERP has been implemented. The study investigates the failure

factors involved with ERP projects, and analyses each of this factor in details. To

undertake this study, a checklist was developed after reviewing a number of

literatures. Several relevant headlines, which is consistent with the dissertation’s

objectives, are generated to analysis the conceptions of “ERP failure”. On the basis

of this checklist the 7 case studies, identified as ERP case studies, were analysed.

The study reveals that no organisation embarks on an ERP project with the mind to

fail, however failure is imperative when some factors come into play. Further the

study also helped in identifying these key issues. The dissertation highlights the

barriers to successful ERP migrations including: project management issues; poor

contingency planning; and organisation issues.


2

It was observed that majority of the organisations used in the study failed to deliver a

successful project implementation. Further the study deduced the possible risks

involved with these project implementations. It was observed that some of these

factors were more detrimental than others; hence they were classified as Critical

Failure Factors of ERP implementations in large companies.


3

ACKNOWLEDGEMENT Specifying and enlisting all the individuals whose contribution went into the

development this work is a very difficult task. My gratitude goes to my very sincere

but supportive supervisor and personal tutor Dr. Miguel J.B. Nunes, for his

encouragement and to research student Alex Peng. They both made this a personally

rewarding experience. I thank them for their unrelenting support and constant

inspiration, without which understanding the intricacies of the study would have

been very difficult. They not only taught the fundamentals for undertaking the

research but also helped me develop as an individual.

My heartfelt gratitude also goes to the University of Sheffield, UK, for providing me

with the opportunity to avail the excellent facilities and infrastructures. The values

inculcated and the management skills imparted to me as an individual will be of

immense help at the very start of my career. After undergoing these three months of

rigorous study, I can confidently say that this experience has not only enriched me

with academic and industrial knowledge but has also imparted the maturity of

thought, vision, the attributes required to be a successful professional. Special thanks

to Mrs T.Onipede, who took special efforts in proof reading this work.

I would also like to express my thanks to my parents, Prof T. Oladiran and Mrs W.

Oladiran and other family members, friends and colleagues, who have been helping

hands throughout. Last but not least, I express my thanks to God for seeing me

through the challenges of this project-I am forever grateful to you.


4

TABLE OF CONTENTS

ABSTRACT ................................................................................................... 1

ACKNOWLEDGEMENT................................................................................ 3

CHAPTER ONE............................................................................................. 8

INTRODUCTION ........................................................................................... 8

1.0 Introduction.................................................................................................................................... 8

1.1 Background Information....................................................................................................... 8

1.2 Statement of the Problem ............................................................................................................ 10

1.3 The Research Question ................................................................................................................ 11

1.4 Objectives of the study................................................................................................................. 12

1.5 Relevance of Study ....................................................................................................................... 12

1.6 Research Gap................................................................................................................................ 13

1.7 Methodology ................................................................................................................................. 14

1.8 Limitation of the study................................................................................................................. 15

1.9 Outline of Dissertation ................................................................................................................. 15

CHAPTER TWO .......................................................................................... 16

ENTERPRISE RESOURCE PLANNING ..................................................... 16

2.0 Introduction.......................................................................................................................... 16

2.1 Overview of Enterprise Resource Planning ............................................................................... 16 2.1.1 What is Information Systems ................................................................................................. 17 2.1.2 What is ERP ........................................................................................................................... 18 2.1.3 Evolution of ERP.................................................................................................................... 20

2.2 ERP Functional areas .................................................................................................................. 21 2.2.1 Characteristics and Components ............................................................................................ 22 2.2.2 Applications............................................................................................................................ 24

2.3 ERP Vendors ................................................................................................................................ 27

2.4 Current Trends in ERP ............................................................................................................... 28

2.5 Summary....................................................................................................................................... 29

CHAPTER THREE ...................................................................................... 30


5

ENTERPRISE RESOURCE PLANNING IN LARGE ORGANISATIONS.... 30

3.0 Introduction.................................................................................................................................. 30

3.1 Overview of ERP in large organisations .................................................................................... 30 3.1.1 Benefits of ERP to large Organisation.................................................................................... 32 3.1.2 Disadvantages of ERP to organisation ................................................................................... 35

3.2 Overview of ERP Project............................................................................................................. 37 3.2.1 Risks involved in ERP projects .............................................................................................. 40

3.3 Critical Susses factors of ERP Project........................................................................................ 42

3.4 Failure factors of ERP Project .................................................................................................... 45 3.4.1 Critic of Failures Definitions.................................................................................................. 46 3.4.2 Causes of ERP failure............................................................................................................. 50

3.5 Summary....................................................................................................................................... 53

CHAPTER FOUR ........................................................................................ 55

RESEARCH METHODLOGY ...................................................................... 55

4.0 Introduction.................................................................................................................................. 55

4.1 Research Methodology................................................................................................................. 55

4.2 Research Approach...................................................................................................................... 56

4.3 Research Method.......................................................................................................................... 59 4.3.1 Data from Past Research ........................................................................................................ 60 4.3.2 Desktop Research ................................................................................................................... 61 4.3.3 Case Study Analysis ............................................................................................................... 61

4.4 Research Design ........................................................................................................................... 62

4.5 Data analysis - Checklist development ....................................................................................... 66

4.6 Summary....................................................................................................................................... 70

CHAPTER FIVE........................................................................................... 71

DATA FINDINGS AND ANALYSIS ............................................................. 71

5.0 Introduction.................................................................................................................................. 71

5.1 Case Study of Fox Meyer .................................................................................................... 71 5.1.1 Introduction of Fox Meyer ................................................................................................ 71 5.1.2 Analysis of FoxMeyer ............................................................................................................ 72 5.1.3 Discussion .............................................................................................................................. 80

5.2 Case Study of Manco ........................................................................................................... 80 5.2.1 Introduction of Manco............................................................................................................ 80 5.2.2 Analysis of Manco.................................................................................................................. 81 5.2.3 Discussion on Manco ............................................................................................................. 87


6

5.3 Case Study of Hershey Foods.............................................................................................. 88 5.3.1 Introduction of Hershey Foods ............................................................................................... 88 5.3.2 Analysis of Hershey Foods..................................................................................................... 89 5.3.3 Discussion on Hershey Foods................................................................................................. 94

5.4 Case Study of NIBCO.......................................................................................................... 95 5.4.1 Introduction of NIBCO ..................................................................................................... 95 5.4.2 Analysis of NIBCO ................................................................................................................ 95 5.4.3 Discussion of NIBCO........................................................................................................... 101

5.5 Case Study of Dell Computers .................................................................................................. 102 5.5.1 Introduction of Dell Computers............................................................................................ 102 5.5.2 Analysis of Dell Computers ................................................................................................. 103 5.5.3 Discussion on Dell Computers ............................................................................................. 107

5.6 Nestle ........................................................................................................................................... 108 5.6.1 Introduction of Nestle........................................................................................................... 108 5.6.2 Analysis of Nestle................................................................................................................. 109 5.6.3 Discussion on Nestle ............................................................................................................ 115

5.7 Case Study of Hewlett Packard................................................................................................. 116 5.7.1 Introduction of Hewlett Packard (HP).................................................................................. 116 5.7.2 Analysis of HP...................................................................................................................... 117 5.7.3 Discussion on HP ................................................................................................................. 121

5.8 Further Discussion ..................................................................................................................... 122 5.8.1 Strategic Goals ..................................................................................................................... 123 5.8.2 Top management’s Commitment to the system ................................................................... 125 5.8.3 Project Management............................................................................................................. 127 5.8.4 Commitment of the Organisation to Change ........................................................................ 128 5.8.5 Selection of Project Team .................................................................................................... 129 5.8.6 Education and Training of Users .......................................................................................... 131 5.8.7 Performance Measures ......................................................................................................... 132 5.8.8 Multi-site issues.................................................................................................................... 133 5.8.9 Technical difficulties ............................................................................................................ 134 5.9 Risks Associated with ERP implementation ........................................................................... 134

5.10 ERP Failure Factors................................................................................................................. 136

5.11 Summary................................................................................................................................... 138

CHAPTER SIX........................................................................................... 139

CONCLUSION........................................................................................... 139

6.0 Introduction................................................................................................................................ 139

6.1 Conclusion................................................................................................................................... 139

6.2 Future Research ......................................................................................................................... 141

REFERENCES .......................................................................................... 142


7


8

CHAPTER ONE

INTRODUCTION

1.0 Introduction

This chapter introduces the work undertaken in this dissertation. In section 1.1, the

background information lays a foundation for the research, and the subsequent

section 1.2 presents the statement problem. The next two segments 1.3 and 1.4,

discusses the research question and the objectives of the study. In order to affirm the

importance of the study, section 1.5 and 1.6 highlights the relevance of the study and

research gap respectively. A brief description of the methodology employed for this

study along with the limitations and constraints encountered are highlighted in

sections 1.7 and 1.8 correspondingly. Lastly in section 1.9, the author presents the

outline of the dissertation.

1.1 Background Information

Information technology and systems have tremendous impact on the productivity of

both manufacturing and service organizations. Martin (1998) noted that companies

have implemented systems such as enterprise resource planning (ERP) over time for

improving their productivity. ERP systems have received much attention lately

because of their ability to facilitate effective decision-making. Many companies are

implementing ERP packages as a means to reduce operating costs, increase

productivity and improve customer services (Martin, 1998). Black (1999) noted that


9

ERP has grown as an integration tool, the aim been to integrate all enterprise

applications to a central data repository with easy and discrete access to all relevant

parties.

Bhattacherjee (2000) noted that SAP R/3 has been installed in over 20,000 locations

in over 107 countries. However ironically, many have concluded that these ERP

systems can cripple a company, if they are not implemented properly. Laughlin,

(1999) and Bancroft et al. (1998) noted cases of horror stories of ERP

implementations.

Bancroft et al. (1998), notes that the sole purpose of an ERP system is to integrate all

facets of the business enterprise under one suite of software applications.

Researchers such as Motwani et al. (2004), states that as more organizations move

from functional to process-based IT infrastructure, ERP systems are becoming one of

today’s most widespread IT solutions, however, not all firms have been successful in

their ERP implementations. They went on to argue that by evaluating ERP

implementations: “Factors affecting the resulting success or failure of ERP projects

can be understood better”

The works of Mandal and Gunasekaran (2003) concluded that for an ERP system to

give a competitive advantage to an organisation the pre-implementation strategies,

implementation strategies and post implementation strategies are very important and

if care is not taken when formulating these strategies, this may lead to critical

failure of the system project.


10

Hong and Kim (2001) noted that an IT driven initiative such as ERP implementation

requires change of the organisation’s socio-economic system, which is intertwined

with technology, tasks, people, structure and culture. Thus organisational change is

critical in determining the implementation of ERP software.

1.2 Statement of the Problem

A project which is delivered on time and within budget with satisfied outcomes is

usually considered successful and on the contrary, project failure implies over

budget, out of schedule, undelivered or system dysfunction (Martin, 1998). Khafre

Systems International (KSI 2001) describes failure as “not meeting stated project

goals”.

According to Black (1999) failure is never so easy to be clarified. In reality, failure is

a very complex issue which contains a wide range of fixed and variable

determinations. Moreover, different types of failures can be acknowledged from

different views. The author found out from Davenpot (2000) that in order to qualify

and classify failure it might be important to understand and benchmark it against

success factors.

Nowadays, in the emerging ERP research area, the definition and measurement of

ERP implementation failure is a thorny issue (Black, 1999). Markus and Tanis

(2000) stated that failure and success means different thing depending on who

defines it. Thus, for instance, project managers and implementation consultants,

“often define success in terms of completing the project on time and within budget.


11

But people whose job it is to adopt ERP system and use them to achieve business

results tend to emphasise having smooth transition to stable operations with the new

system, achieving intended business improvements like inventory reductions, and

gaining improved decision support capabilities ” (Markus and Tanis 2000, p2).

Clemons (1998) noted that this relative point of view for success can also be applied

to failure, and people also qualify an implementation as a failure according to their

expectations of the project.

ERP Systems are complex, and implementing one can be a difficult, time-

consuming, and expensive project for a company (Ghosh, 2002). They also noted

that it can take years to complete and cost as much as $500 million for a large

company. Furthermore, there is no guarantee of the outcome. The parameter of this

research is surrounded by the evaluation of failure factors and determining what

causes project to fail when implementing an ERP system.

1.3 The Research Question

• What are the failure factors, involved with the implementation of

Enterprise Resource Planning Systems (ERP) Systems in large

Organisations?


12

1.4 Objectives of the study

The aim of the investigation is to:

1. To draw up a checklist of possible failure factors ERP based on success

factors

2. To find, qualify, and classify failure factors

3. To find out what causes failure in ERP implementation

4. To highlight some potential what risks that are involved these projects

5. To determine how failure factors can be avoided

1.5 Relevance of Study

The research was to examine the failure factors involved with the implementation in

ERP systems in large companies. Information systems are addressed in a number of

disciplinary fields, the most relevant being:

• Information Science (specifically relevant are the areas of information

organization and retrieval, and business information management),

• Computer Science (specifically software engineering, software design)

• Informatics (specifically systems analysis and design, and MIS or

management information systems).

Furthermore, the study examines the provision of management information in a

specific context relating to transfer and use of data across an organisation, therefore

this work is also relevant to logistics, marketing and other management disciplines.


13

1.6 Research Gap

Information systems (IS) research emerged in the 1990s in the international context

(Dean 2001), before then, information systems had usually been seen as a domestic

issue and there was only a little research on large corporations level (Ross, 2000).

Similarly, Hong and Kim (2001) who studied activities in large companies relating to

information systems argued that there were only a few empirical studies in a large

company’s context. To a lesser degree, research linked specifically to information

sciences has materialized within the large enterprise management research streams;

therefore, there is a clear gap in current gap in the current research on large

companies, which creates an interesting research opportunity.

As supported by Davenport et al. (2000), the relationship between ERP

implementation in large companies and failure factors of these implementation is an

emerging topic, firstly because of increasing investment in ERP systems, secondly

because of reported failures in ERP system implementation, and thirdly because

implementing organisation structure changes and ERP are seldom combined in

research.

In information studies research, there are surprisingly few studies of the long term-

changes that enterprise resource planning systems may create for firms. The existing

research focuses on the adopting organisations, e.g. end-users in the line

organisations. Baskerville, et al. (2000) put forward that, in early research on ERPs,

the long-term impacts of ERPs on IT support and maintenance, and on other

elements of any participant organisation were unknown. However, the existing


14

literature (for instance Davenport, 1998, 2000, Hall, 2002) acknowledges that

management, organisational structure, and corporate culture changes are connected

to ERPs.

Based on this discussion of the research gap, this research focuses on hindrances to

business domain been integrated to the IT domain during the ERP implementation

and thereafter. The research analyzes what are the possible problematic areas during

an implementation that could result in a failure of implementation.

1.7 Methodology

In order determine the failure factors involved with ERP implementations in large

organisations, firstly the author identified the factors to be considered for the study.

In order to do this, an exhaustive literature review formed the basis of selecting the

checklist features. Secondly, the author evaluated these factors. Case studies of large

organisations that have implemented an ERP system were selected. Thereafter, an

analysis on these sample case studies was conducted using the checklist developed.

The case studies for the analysis were selected based on the criteria of selection of

case studies as stated by Yin (1993) and Stake (1995). In order to obtain sufficient

results the accepted sample size of 7 case studies were used. The sample data was

obtained from textbooks, journal and from individual websites by doing a desktop

research. Lastly the results and findings of the research were drawn.


15

1.8 Limitation of the study

This study is constrained by some limitations, like any other research. In order to

demarcate this study and clarify the scope, the author highlighted the limitations to

this study. The major challenge was finding the appropriate cases, in order to

conduct a data analysis. The theory that is developed would have been more accurate

if tested, however this was not possible due to time constraints as this is a Masters

degree dissertation and it was done alone.

1.9 Outline of Dissertation

This dissertation is structured as follows:

Chapter 1- introduces the research work undertaken in this dissertation along

with the research question, objectives of the study, background information to

the topic and the importance of the research.

Chapter 2- evaluates literature in order to gain an understanding of ERP

systems.

Chapter 3- discusses enterprise resource planning systems in large

organisations.

Chapter 4- gives an overview of the methodology adopted for this study.

Chapter 5- presents the findings and analysis of data (individual case

studies) of the study. It also provides a further evaluation and discussion for

all the data(case studies) presented in the previous section of the chapter

Chapter 6- draws up conclusion around the topic area. It also proposes an

area for future research.


16

CHAPTER TWO

ENTERPRISE RESOURCE PLANNING

2.0 Introduction

This chapter presents the epistemology of the survey of literature conducted by the

researcher with regards to ERP. The sole aim and rational behind this part of the

write-up is to give the reader a better understanding of Enterprise Resource Planning

Systems. It encapsulates concepts and theories surrounding ERP and guides the

design of study reported with a strong grasp of the overall concept. Firstly an

overview of ERP is discussed here. Then the author proceeds to evaluate what

functional areas of ERP are. The different ERP vendors, along with the current trends

in ERP are also highlighted in this chapter.

2.1 Overview of Enterprise Resource Planning

In the 1990s according to Davenport (2000), innovations in information technology

led to the development of a range of software applications aimed at integrating the

flow of information throughout a company, and these commercial software packages

were known as Enterprise Systems.

Holland et al., (1999) also stated that during this period a particular enterprise system

called ERP caught the attention of some of the world’s largest companies.


17

As noted by Huang, and Palvia. (2001), until recently the major ERP vendors such as

SAP and Oracle were mainly targeting the high end of the market (companies with

more than 1000 employees); but this market has come close to saturation. Davenport

(1998) also estimated that businesses around the world have been spending almost

$10 billion per year on ERP systems.

2.1.1 What is Information Systems

Information Systems take inputs (business data) and transforms them into output

(business information) (Chaffey and Wood, 2005). Davenport (2000) defines

information system as a computerized or manual system to capture data and

transform them into information and/or knowledge.

The UK Academy for Information Systems (www.ukais.org) defines information

systems as follows: “Information systems are the means by which organisations and

people, using information technologies, gather, process, store, use and disseminate

information.” An information system (IS) is a formalized computer information

system that can; collect; store; process; and report data from various sources to

provide the information necessary for managerial decision making (Bancroft et al.,

1998).

Researchers such as Sumner (1999) and Davenport (2000) have argued that ERP

systems are a type of information systems.


18

2.1.2 What is ERP

An ERP system is a set of integrated programs that is capable of managing a

company’s vital business operations, for the entire global enterprise. Although the

scope of ERP system may vary from company to company, most ERP systems

provide integrated software to support business functions of the organisation

(Davenport, 2000).

Kashef and Izadi (2001) put forward that ERP is a set of applications that help

manage and automate a business. A large database provides access to all application

programs and serves in all areas within a manufacturing enterprise. This is

accomplished by exchanging information with suppliers and customers directly or

through trading community portals and e-commerce links, and with outsourcing

partners (Wreden, 1999).

ERP incorporates all of the elements of a business from financial processes to

manufacturing and marketing activities, into a unified whole that operates more

effectively and efficiently in today’s competitive economy (Hill, 2000). Explanations

from the works of Kashef and Izadi (2001) highlights that these applications include

finance, human resources, management, manufacturing, logistics, and supply chain

management.

Enterprise resource planning (ERP) systems are commercial software packages that

enable the integration of transaction-oriented data and business processes throughout

an organization (Markus and Tanis, 2000).


19

The diagram below is captured from the works of Adam and Sammon, (2004). It

gives a brief description of what other researchers in the field have defined ERP to

be.

Figure1: ERP description From Adam and Sammon (2004)


20

2.1.3 Evolution of ERP

The first generation enterprise systems, MRP evolved in the 1970s and they gave

information about material basic number crunching, quantities and dates (Garther

Group 1999). As supported by Sandoe et al., (2001), the next decade ushered in the

emergence of the next generation enterprise systems, MRPII. These systems helped

to facilitate the improvement of master planning; it incorporated modules for

capacity management and shop floor control. These systems also integrated sales

orders, purchasing, work orders, and stock. Through these systems an organisation

was able to achieve full planning and control. In the 1990s, the enterprise resourced

planning system materialized. These systems included better financial integration

and distribution/warehousing Sandoe et al., (2001).

Its Evolution started in 1960.

1960-70’s MRP Manufacturing Resource Planning

1980’s MRPII Manufacturing Resource Planning II

1990’s ERP Enterprise Resource Planning

2000’s Extended ERP (Garther Group 1999)


21

MRP ERP eERP

Figure 2: The Gartner Group View From Garner Group (1999)

2.2 ERP Functional areas

Researchers such as Boykin (2001) ands Chen (2001) noted that the ERP

functionality usually includes a set of mature business applications and tools for

financial and cost accounting, sales and distribution, materials management,

production packages and computer integrated manufacturing, supply chain, and

customer information.

1980s 1990s 2000s

Competitive

Focus

Manufacturing Enterprise Supply Chain

Enterprise

Strategy

Inventory

Reduction

Business Process

Efficiency

Revenue

Enhancement

Technology

Focus

Automation Integration Interoperability

Process Focus Departmental

Alignment

Enterprise-wide

Closed Loop

Customer

Differentiating

Organizational

Focus

Department Business Process Product/Market

Channel


22

Gallagher (2005) explained that ERP functionality includes managing the key

elements of the supply chain operation-product planning, purchasing, production

control, inventory control, interaction with suppliers and customers, delivery of

customer service and keeping track of orders. He went further to state that it may

also include human resource models which maintain a central database of the

organisation’s people, which is critical to production and staff scheduling functions,

and staff payments.

ERP encompasses human resources, decision support applications, distribution,

maintenance support, quality and regulatory control and health and safety

compliance (Martin, 1998). An ERP system can be used as a tool to help improve the

performance level of a supply chain network by helping to reduce cycle times

(Gardiner et al 2002).

Davenport (2000) argued that with ERP, since the manufacturing modules and data

are integrated with other systems within a firm, all potential problems, such as data

reliability and consistency in both MRP and MRP II, likely no longer exists.

2.2.1 Characteristics and Components

1. Client/Server System: Enterprise Resource Planning systems depend on

client/server technology, which enable the users to access the information

from a central server. These enterprise applications typically reside on a

server and provide users access at the PC level. They invite greater access to

the non computer-literate end users. This concept has the ability to bring a

systematic computerized power to the desktop (Kashef and Izadi, 2001)


23

2. Enterprise-wide Databases: ERP has one database that serves all the

application systems. These applications enable a company to automate almost

every aspect of its operations by tying the ERP database to its intranet and

extranet and thus allowing full browser access to them (Kashef and Izadi,

2001).

3. Applications/Modules: Each ERP vendor provides a number of ERP

applications (or modules) for their systems. These are the functional software

packages for each individual business unit like finance, human resources,

order processing and so on (Stevens, 1997).

4. WWW/ERP: To accomplish communication among multiple computers a

common software standard and a communication standard is needed. This

issue has largely been solved by the existing protocols and standards of the

WWW like Java and HTML. The ERP system collectively organizes a

company’s processes, communication systems, and management organization

to make seamless software paradigm embedded in the WWW. Hence,

companies can give customers access to their own records, give employees

control over their own benefits, and let financial departments control

purchases of office supplies in innovative ways (Alsop, 1998).

The works of Chan (1999) reflected that an ERP system should embody the

requirements of the following IT architectural components:

• network infrastructure;

• server operating systems (OS) /platform;

• database;

• data ownership;


24

• client OS/ workstations;

• web enablement;

• prerequisite user skills;

• IT capacity.

Davenport (2000) noted that two tendencies evolving in the components of ERP are:

1. The state-of-art client/server architecture is being replaced by a more

versatile web-based.

2. As a tendency of failure, it has been seen to stick on “best practice” and rely

on a single software vendor that provides a standard process.

2.2.2 Applications

This section, discusses the application of ERP software. Most ERP systems start with

a set of core modules, and offer additional modules from which a company can select

as desired. All these applications are fully integrated to provide consistency and

visibility for all the activities across entire system operation (Baan, 1997). However,

ERP systems require users to comply with the processes and procedures as

implemented in the individual modules.

Finance functions:

According to Chan (1999), ERP can facilitate the following finance functions:

• General ledger: ERP can keep track of the centralized accounts and corporate

financial balances.


25

• Accounts receivable: ERP can keep track of payment dues from customers.

• Accounts payable: ERP can schedule bill payments to suppliers and

distributors.

• Fixed assets: ERP can manage depreciation and other costs associated with

tangible assets such as buildings, property and equipment.

• Treasury management: ERP can monitor and analyze cash holdings, financial

deals and investment risks.

• Cost control: ERP can analyze corporate costs that are related to overhead,

products, and manufacturing order.

Human Resources:

The human resources (HR) division can be enhanced through the following ERP

process:

• HR administration: ERP can automate personnel management processes

such as recruitment, business travel and vacation time.

• Payroll: ERP can handle accounting process and preparation for checks

related to employee salaries, wages and bonuses.

• Self-service HR: ERP can allow workers to change their personal

information and beneficial allocations online.

Manufacturing and Logistics:

The manufacturing and logistics unit can benefit from the use of ERP for:

• Production planning: ERP can perform capacity planning and create a daily

production schedule for manufacturing plants.


26

• Order entering: ERP can automate data entry, process customer ordering, and

keep track of order status.

• Warehouse management: ERP can keep track of goods and process

movements in corporate warehouses.

• Transportation management: ERP can schedule and monitor the delivery of

products to customers.

• Project management: ERP can monitor costs and work schedule on a project-

by-project basis.

• Plant maintenance: ERP can set the plan and oversee upkeep of internal

facilities.

• Customer service management: ERP can administer service agreements and

check contracts and warranties when customers needed.

Figure 3: ERP Application areas from Davenport (1998)

ERP Database & Systems

Sales & Marketing

Human Resource

Financial Applications

Data Analysis

Customer Service

Supply-chain management

In & out-bound logistics Manufacturing

planning


27

Although the author discussed only three application areas of the ERP system, the

diagram above captures other application areas of the systems.

2.3 ERP Vendors

In accordance with Garner Group Report (Enterprise Resource Planning, 2004-2009)

ERP market revenues increased 14% in 2004. The report indicates that

approximately one-third of the growth in the overall market was due to fluctuations

in currency exchange rates.

Reilly (2005) noted that while the ERP market has grown in revenue, consolidation

continues to change the industry. He went further to explain that in 1999, the top

five vendors (J.D. Edwards, Baan, Oracle, PeopleSoft, and SAP) in the ERP market

accounted for 59% of the industry’s revenue. AMR Research expects the top five

vendors in 2005 (SAP, Oracle, Sage Group, Microsoft, and SSA Global) to account

for 72% of ERP vendors’ total revenue.

The Reilly (2005) report delivers revenue and growth rates for the top ERP players

as well as growth forecasts through 2009. The top ten ERP vendors ranked by 2004

ERP license revenue can be seen in the chart below.


28

Figure 4 :ERP Top Vendors in 2005 from Reilly (2005)

2.4 Current Trends in ERP

Even through the work of complementing “standard ERP” is still under way in many

organizations, as argued by Hong and Kim (1999), some trends have already

established themselves in the development of ERP:

Recently, ERP systems have expanded their reach into the “front office”,

supporting among other things Supply Chain Management (SCM) and

Customer Relationship Management (CRM). It can be argued that this is

driven both by customer demand as well as the ERP vendors to desire, to

keep revenue growth at continued high levels while their core market has

been saturated (Reilly, 2005).


29

There are discussions concerning both the ROI (Return Over Investment) as

well as the business benefits to the organizations, but the issue of value is

complicated considering the huge impact of ERP on almost all parts of a

business (Reilly, 2005 ).

2.5 Summary

Innovations in information technology, has led to the maturity of a range of software

applications aimed at integrating the flow of information throughout an organisation.

These commercial software packages were known as Enterprise Systems.

The 1990s ushered in the emergence of ERP systems. ERP systems are known to be

are integrated software packages composed by a set of standard functional modules

(production, sales, human resources, finance, etc.) developed or integrated by the

vendor, that can be adapted to the specific needs of each customer.

ERP are a development of their predecessor software MRPII and MRP respectively.

The ERP application areas includes: manufacturing and logistic, finance; human

resources etc.


30

CHAPTER THREE

ENTERPRISE RESOURCE PLANNING IN LARGE

ORGANISATIONS

3.0 Introduction

This chapter will introduce ERP implementation practices in large organisations. The

major overview of ERP project implementation along with the different type’s

implementation strategies is also highlighted. Moreover this section will discuss the

benefit of an ERP implementation to an organisation.

The aim of this chapter is to introduce definitions and themes that are important for

the reader to know in order to understand the ERP concept in relation to large

companies as a whole and not partially. The review will focus on the exploration of

important terms such as risks factors and critical success factors (CSF) and of course

a formal definition of failure factors.

3.1 Overview of ERP in large organisations

Past research put forward that organisational context is a determinant of Information

System (IS) success. Schultz and Slevin (1975) and Ein-Dor and Segev (1978) were

among the first in pointing the importance of organisational factors in managing

Information Systems. In their early work, Ein-Dor and Segev (1978) proposed a

framework after studying Information System in which they identified organisation


31

size as one of the critical variables. Researchers such as Delone (1988b), Lai (1994),

Raymond (1985), and Raymond, (1990) have concluded that large organisations

have distinctive and unique needs compared to small organisations therefore the

research findings of small organisations cannot be generalized to large firms.

As explained by Davenport (1998) customarily large organisations tend to use ERP

software packages as they provide a generic, computer-based, enterprise-wide,

business-process support for many organizations. In the year 2000, it was reported

that over 70% of Fortune 1000 companies had or were in the process of

implementing an ERP system (Hillegerberg and Kumar, 2000). They went further to

note that flexibility and quick response are hallmarks of business competitiveness.

Hillegerberg and Kumar, (2000) noted that access to information at the earliest

possible time can help business serve customers better, raise quality standards, and

assess market conditions. He also described enterprise resource planning as a key

factor in instant access.

According to Davenport (1998) a large enterprise may have several units across

separate geographical locations with different degrees of freedom in activities,

therefore a large company is geographically, time-wise and environmentally (both

externally and internally) diverse.

Although researchers such as, Hong and Kim (2001) stated that ERP has packaged

processes for best business practises in the form of a business blue print. They went

further to explain that this blueprint guides firms from the beginning phase of

product engineering, including evaluation and analysis, to the final stages of product


32

implementation. Hong and Kim (2001) argued that business units, headquarters-

subsidiary relations or business processes and operations in the units are

heterogeneous as local requirements or market conditions create differences in

business activities. There are still questions on how ERP system developed in a

different locality matches up to the organisational environment it proposes to serve.

3.1.1 Benefits of ERP to large Organisation

As affirmed by Rao (2000) the difference between a successful and profitable

organization and an average one is the quality of service. The quality comes when

companies undergo a “metabolic change” in the way they manage customers and

potential prospects. “The smart organizations today could anticipate and exceed

customer expectations that are evaluated on the basis of quality, time, service,

availability and efficiency. The one tool that innovative and progressive

organizations have come to increasingly depend on in this endeavor is ERP

solutions,” (Sarker and Lee, 2003).

As supported by Cadle and Yeates (2001) ERP through its various functional spheres

in an organization, works as a link through the entire enterprise. It is aimed at

adapting best industry and management practices for providing the right product at

the right place at the right time at least cost.

The works of Davenport (1998) reflected that the complexities of internal and

external factors have a significant influence on the management of a large company.

Particularly challenging for multinational enterprise is the balance between demands


33

from business units world wide and the advantages of capturing cross-business

synergies. Information used in managing a large organisation originates in different

locations. Therefore, information is fragmented in a large organisation (Davenport,

1998). Davenport went further to noted that re-organization of an enterprise around

process, changes the way of doing business, eliminates the old nonfunctional

approach, and transforming into a strategic process-centric organization.

The table below shows how the ERP system affects business processes in an

organization.

Figure 5: New organization structure From Davenport (2000)

Hum

an Resourse

Marketing and Sales

Production

Finance and Accounting

ENTERPRISE

Functional Oriented

Production

M &

S

Finance and accounting

Order Processing

Hum

and Resourced

Production

Customer Service

F &C

Business Processes

Process Oriented


34

ERP benefits include:

1) Easier Access to Reliable Information: ERP systems function utilizing a

common database management system. Thus, decisions on cost accounting or

optimal sourcing can be made across an enterprise. This bypasses the need to look at

separate operational units and then trying to coordinate the information manually, or

reconciling data across multiple interfaces with some other application (Kashef, et

al., 2001 and Baan, 1997).

2) Elimination of Redundant Data and Operations: Driven by business process

re-engineering, the implementation of ERP systems reduces redundancy within an

organization. With functional business units utilizing integrated applications and

sharing a common database, there is no need for repetition of tasks such as re-

entering data from one application to another (Kashef, et al., 2001 and Blanchard,

1998)

3) Reduction of Cycle Times: ERP systems recognize that time is a critical

constraint variable, for both the overall business and the business use of information

technology Minimizing delays in retrieving or disseminating information achieves

time reductions and cost savings (Kashef, et al., 2001 and Sheridan, 1995)

4) Increased Efficiency and Reducing Costs: ERP allows business decisions to be

analyzed enterprise-wide, hence this results in time saving, and an improved control

and elimination of extra operational costs (Kashef, et al., 2001 and Baan, 1997)

5) Easily Adaptable in a Changing Business Environment: Recognizing

companies’ needs to reduce their time to market for goods and services, ERP systems

are designed to respond quickly to new business demands and can be easily changed

or expanded without disrupting the course of business. Hence, the time required in


35

deploying and continuously improving business processes will be greatly reduced

through the use of ERP (Kashef, et al., 2001 and Appleton 1997)

The table below is adapted form the works of Rashid, et al. (2002) and it captures the

benefits of ERP systems to an organisation.

Figure 6: ERP Advantages From Rashid, et al. (2002)

3.1.2 Disadvantages of ERP to organisation

Trimi et al., (2000) put forward that the greatest disadvantage of an ERP system,

even if installed to vendor preferences, is the staggering cost of implementation.

Implementation costs they went on to explain include software, hardware,

installation consultant fees, and in-house staff for installation. However, these are not

the only costs. There are also costs for staff to operate the system (to include help


36

assistance to users) and the very large cost component of user training. ERP systems

are by their nature expensive.

ERP disadvantages: are shown below:

1) Implementation: The implementation of an ERP system is a very time

consuming, expensive and arduous task. In an interview with Information

Technology executives from Fortune 1000 companies that had implemented ERP,

44% reported that they had spent at least four times as much on implementation than

they did on the software license itself (Kashef, et al., 2001 and Michel, 1997).

2.) Conformity to the software processes: ERP systems force their customers to re-

engineer current practices to fit within the processes described by their modules.

Selecting the wrong ERP software could result in an unwilling commitment to

information architecture and applications that do not fit with the organization’s

global strategic goals (Kashef, et al., 2001 and Hecht, 1997).

3) Commitment to a Single Vendor: Letting one vendor provide all enterprise

systems is an attractive but risky proposition (Kashef, et al., 2001 and Weston,

1997).

Table below summarizes the ERP disadvantages from the works of Rashid, et al.

(2002).


37

Figure 7: ERP Disadvantages From Rashid, et al., (2002)

3.2 Overview of ERP Project

Kashef, at al. (2001) noted in writing that, the large ERP providers have made many

promises, but many user companies are still asking, “what’s the payoff?’ the answer

is still unclear. Davenport (2000) reflected the fact that implementing wall-to-wall

software is not a matter of powering up the computer and installing a program from a

CD-ROM.

According to a survey carried out by Michel (1997) ERP is a huge investment in time

and money, and it can take years of work by numerous managers and cost millions,

or in some cases hundreds of millions of dollars.


38

McKinney (1998) noted that the cost of implementing an ERP application depends

on the scope of the effort, size of the enterprise, the ERP application selected, and the

Information Technology environment required. Cost for a large system can run to

several hundred million dollars. Many large corporations are currently spending

between $5 million and $200 million to implement an ERP system (McKinney,

1998).

Companies are anticipating immediate returns on efficiencies in production and

inventories, with additional returns in other areas being realized over the long term.

The greatest return will be one that cannot be easily quantified. This is an integrated

system that provides timely information, better customer support and a competitive

edge; it addresses strategic goals and objectives, and takes a company into the 21st

century (Standish Group 2000).

Davenport (1998) explained that for many businesses, installing ERP was traumatic.

Following long, painful, and expensive implementations, some companies had

difficulty identifying any measurable benefits.

ERP Implementation Strategies

Shanks (2000) stated that there are two key decisions to be taken in determining the

module implementation strategy. The first decision concerns the selection of modules

as ERP systems are modular systems. The second decision is concerned with the

process of connecting each module to existing systems. There are two standard

approaches: either implement module-by-module, and as each is implemented


39

connect it to the existing system, or alternatively implement all modules and then

connect them to the existing systems. The first option is less risky, but more resource

intensive. The second is precarious but a less time consuming. The table below

shows different types of implementation strategy, the time frame and the failure rate

for each strategy.

Strategy Months %

Big bang 15 41

Phased rollout by site 30 23

Phased rollout by module 22 17

Mini big bang 17 17

Phased rollout by module & site 25 2

Figure 8: Implementation Strategies From Source: Nah et al., (2001)

Above is implementation strategies put forward by Nah et al., (2001). The work

reflected that although the Big bang approach seems the cheapest they are:

• Dangerous

• Often makes sense in ERP if carefully planned

They went a step further to explain that the phased rollout strategy reduces risks,

especially for large organizations. Much has been said about “big bang” approaches

and gradual rollout of modules within a company. Davenport (2000) argued that


40

there is no evidence that any one way is better than another as a whole; however, one

approach will be better for companies on an individual basis. There have been many

widely publicized “big bang” successes, and many failures. The same is true for

gradual (phased) rollouts, although these generally are not headline-grabbers

(Davenport, 2000).

3.2.1 Risks involved in ERP projects

A simple definition of “risk” is: a problem that hasn't happened yet but could cause

some loss or threaten the success of your project if it did (Wiegers, 1998). In the

words of Chaffey and Wood (2005), risk is defined as “the potential harm that may

arise from some present process or from some future event. It is often mapped to the

probability of some event which is seen as undesirable. Usually the probability of

that event and some assessment of its expected harm must be combined into a

believable scenario (an outcome) which combines the set of risk, regret and reward

probabilities into an expected value for that outcome.”

A clue to why Project implementations are often fraught with difficulties is alluded

to by Rivard et al., (1999) when they state that information technologies are neutral,

their impact depending on the way they are implemented and used in a given

environment. Correctly implemented, information technologies can facilitate and

initiate important changes. Echoing The Standish Group Report, Rivard et al., (1999)

mention the following factors:

• A clear vision

• A proactive and sustained Management implication


41

• A good understanding of information technologies and their potential

impact.

The cost of downtime its one of the main risks that should be taken into

consideration and it has been ignore most of the cases. This cost should be address at

the begging of the project. On average ERP experience a 2.8 hours of unscheduled

downtime per week and according to a recent survey of 250 Fortune 1000

companies, the Standish Group reported that the average per minute cost of

downtime for an enterprise application sis $13000.

The table below is adapted from Sumner (1999). It summarizes the risk factors in

ERP system.


42

Figure 9: Risk factors in ERP systems From Sumner (1999)

3.3 Critical Susses factors of ERP Project

Vidyaranya et al., (2005) inferred that the measurement and definition of ERP

system success are thorny issues. They explained that success is a quite nebulous and

extremely subjective assumption. Firstly, success depends on the viewpoint from

which an individual measures it. Even within a single organization, people will have

several opinions. It can either be a complete success, i.e. one in which everything


43

goes according to planned with no glitches; or one with a few configuration

problems, resulting in temporary setback (Vidyaranya et al., 2005).

A critical success factor in terms of ERP is an important issue that organizations

must put into consideration to successfully implement an ERP solution. In terms of

information system projects, a critical success factor is what a system must do to

accomplish what it was designed to do (Yingjie, 2005). The idea of studying critical

success factors behind ERP implementations is very similar to the techniques used in

several studies in Information Technology (IT) implementation research, and some

of these proposed factors have been identified to be important in other IT

implementations (Yingjie, 2005).

There are several factors to be considered when making the decision of whether and

how to implement an ERP. The technical aspect is not the only factor that requires

consideration. The analysis should consider both benefit/cost analysis and also the

non-financial factors. These non-financial benefits include flexibility and information

visibility (Sandoe et al., 2001). The human resources/personnel cost is normally the

largest and most expensive, however, it is an area that has been given the least level

of consideration (Zhang et al., 2002). The software and hardware costs are often

easily quantifiable; however, the “human” cost is not (Davenport, 2000).

Huang and Palvia (2001) identified ten factors necessary for ERP implementation by

comparing advanced and developing countries. These were subbed into two

categories: the national/environmental and organizational level. They observed that

information technology maturity, business size, computer culture, business process


44

re-engineering experience, and management commitment were the organizational

level factors; while economy and economic growth, manufacturing strengths,

regional environment, infrastructure, and government regulations were the

national/environmental factors.

Similarly, in another study based on earlier papers, Nah et al., (2001), proposed 11

factors critical to ERP implementation success. These 11 factors include: top

management support; ERP teamwork and composition; change management program

and culture; business plan and vision; effective communication; project management;

software development, testing and trouble shooting; business process re-engineering

and minimum customization; monitoring and evaluation of performance; project

champion; and appropriate business and information technology legacy systems.

Further academic literature review of critical success factors from a national

perspective (in China and Finland), came up with about ten independent variables.

These factors responsible for ERP implementation success are indicated by Sandoe et

al., (2001), ABCD classification and user’s subjective satisfaction. They include: top

management support; suitability of software and hardware; re-engineering business

process; effective project management; education and training; data accuracy; vendor

support; company-wide commitment; user involvement; and organizational culture.

In accordance to the works of Umble et al., (2003), the author learnt that Critical

Success Factors for an ERP implementation fall under the following categories:

1. Clear understanding of strategic goals

2. Top management commitment


45

3. Project management implementation

4. Great implementation team

5. Ability to cope with technical issues

6. Organisational commitment to change

7. Extensive education and training

8. Focused performance measures

9. Resolution of multi-sites issues

3.4 Failure factors of ERP Project

According to Lucas’s book “Why information systems fail?” he describes that many

information systems had to be regard as failures because some systems were

definitely unworkable while others cannot provide the proposed outcome (Lucas,

1975). As a result, many IS professionals (Ackoff, 1967, Lyytinen & Hirschheim,

1987; Lucas, 1975, Sauer, 1993) were involved in the failure studies.

Before taking a further look on the exist literatures of ERP failure issues, as

supported by Liu (2002) it is better to bear in mind that although there are plenty of

literatures which present the difference formations of failure. There is no right or

wrong answers for this concept. The discussions and comparisons of these works are

just aiming to provide a wide view on the background knowledge of failure study.


46

3.4.1 Critic of Failures Definitions

From the works of Liu (2002) the author found out that the failure study began at

early 70’s when a range of traditional failure conceptions have come out constantly.

However, these conceptions have not been well-developed in a systemic way until

the end of 80’s. As one of the representatives in the failure study, Lyytinen and

Hirschheim (1987) summarized the former traditional works into three major

categories: correspondence failure, process failure and interaction failure.

1) Correspondence failure

“It main premise is that design objectives are stated in advance, and if these

are not met, the IS is a failure – hence the name ‘correspondence failure’. It is

generally believed hat the design objectives are objective and formal, and that their

achievement can be accurately measured” (Lyytinen and Hirschheim, 1987: 265).

The main disadvantage of this concept is ‘too idealistic’ to be valuable.

2) Process failure

“In many situations when the IS cannot be produced within given budget

constraints, it results in what is called a ‘process failure’” (Turner 1982, Brooks

1974, Gladden 1982, quoted in Lyytinen and Hirschheim, 1987). The concept of

process failure captures two related but distinct aspects of unsatisfactory

performance in producing the IS. One is non-workable system and the other is

largely over budget and time.

3) Interaction failure

A range of researchers have suggested that “a low level of IS use can be used as a

surrogate for IS failure” (Lucas 1975, King and Rodriguez 1978, Robey and Zeller


47

1987, quoted in Lyytinen and Hirschheim, 1987). In other words, a successful

information system is reply on the user’s interaction totally. However, Lyytinen and

Hirschheim (1987) also points that there is little empirical evidence which can

directly support this conception. Hence, the conception is too theoretical to use in the

reality.

In the words of Liu (2002) to recapitulate, the ‘correspondence failure’ is

corresponding with the design objectives failure. The process failure refers to

‘system input does not generate efficient system output’. The interaction failure

occurs when users is not so satisfied to the information system which lead to a low

level system performance.

Traditional issues, proposed by Lyytinen & Hirschheim create a new account of

definitions ‘expectation failures’ under the stakeholders’ model consideration. It is

supposed to combine all the traditional failure’s characteristics together. It defines

failure as “inability of an IS to meet a specific stakeholder group’s expectations”

(Lyytinen & Hirschheim, 1987). They went further to develop this concept by

identifying failure into two types: objective failure and consequence failure. The

‘objective failure’ is similar as the ‘expectation failure’ which agreed that failure is a

kind of disappointed result among the designers, users or supporters. While

consequence failure indicates that even though expectations are satisfied, system can

still be seen as unsuccessful because the effort or the output which system generated

is unacceptable.


48

Bignell & Fortune present failure in another view by arguing that “a system that has

failed to achieve its original goals may become successful when measured against

newly defined criteria” (Bignell & Fortune, 1984: 165). In order words, failure can

not be surely confirmed until a period time of using. It can occur in the past, present

and future.

Liu (2002) noted that it is obviously that ‘expectation failure’ concentrates on

fulfilled the stakeholders’ expectations. Although a project is most likely to be

failed when there is no users’ satisfaction in the project, considering too much to

the stakeholders’ expectation is a disadvantage for the entire failure study as

well.

The works of Sauer (1993:26) challenges Lyytinen & Hirscchheim’s ‘expectation

failure’ and argues that “…expectation failure does not respect the difference

between the situations where a system is terminated and serves nobody and the

situation where it serves some and not others”. Consequently, there is always a

question mark when the expectation failure is treated more than ‘a basis for

taxonomy’. To be more specified, he elucidates this argument by three criticisms:

1) The difference between the expectations

2) Expectation failure ignores intention

3) The difference between the stakeholders


49

He further noted that: “…failure is a failure of the information process. What

counts is that the project organizations obtain sufficient support to enable it to

continue to exist and to continue to service its information system. If it cannot

mange this, then it is a failure,” (Sauer, 1993: 18).

Failure is clarified as partial failure or total failure. In a partial failure, the project has

failed to meet some goals, but still provides enough value so that it makes sense to

continue with the project. In a total failure, the project has failed to meet certain

strategic goals and thus should be shut down completely (Khafre Systems

International, 2001).

A Standish Group Report entitled Chaos speaking about Information Technology

soft-ware projects in general, points to various failure factors resulting in cost or time

overruns, unfulfilled objectives, cancelled projects etc. The percentage of

“successful” projects in large companies was estimated at an unflattering 9 %

(STANDISH GROUP 1995). Davenport (1998) concluded that there are as many

success stories as there are failures related to the implementation of ERP systems. In

one failure case, Dell Computer cancelled their ERP contract in January 1997 after

spending $115 million dollars (The original cost of the project was estimated at about

$150 million). According to The Gartner Group, 70 percent of all ERP projects fail

to be fully implemented, even after three years (Khafre Systems International, 2001).


50

3.4.2 Causes of ERP failure

The reason of why project failure has been argued in a very early stage. A range of

themes (Lucas, 1975 and Liu, 2002) believe that people’s behaviours and

communications are the vital reasons for the project failure. The key persons who

involved in the projects include team top leaders (e.g. senior MIS Executive)

designers, end users and so on. Ackoff (1967) notes that, “No MIS should ever be

installed unless the managers for whom it is intended are trained to evaluate and

hence control it, rather than be controlled by it”. (Ackoff, 1967: 147-156)

Lucas stated that: “The success of information system is highly dependent upon the

relationship between users and the information services department and on the use

of the system. Concentrate on the technical aspects of systems and a tendency to

overlook organizational behaviour problems and users are the reasons most

information systems have failed.” (Lucas, 1975:2)

He went on to argue that the primary cause for the system failure is organization

behavioural problems (Lucas, 1975). He uses a descriptive tool, which focuses on

organization behaviour variables to illustrate his predication. A simplified descriptive

model was presented in the diagram below.


51

Figure 10: Causes of failure From Liu (2002)

This model above illustrates three essential classes of variables (Lucas, 1975:19-27):

1) User attitudes and perceptions (Proposition 1-6): The factors which will affect

user’s attitudes and perceptions are presented in the red area. It is general includes

system quality, user reactions, user contact, user involvement, technical quality, and

finally, management support.

2) The use of systems (Proposition 7-11): The blue area contains a wide range of

variables which influence the use of systems: favourable user attitudes, decision

style, different personal and situational factors, system quality and action


52

3) Performance (Proposition 12-16): The yellow area which determines the

performance contains: decision style, personal and situational variables, low

performance, problem-solving information and action and irrelevant information.

As supported by Liu (2002) from the above analysis, it is not difficult to conclude

that the failure comes out easily when a problem occurs in one of the variables. It can

further leading to a range of linked dissatisfactions which increases occurrence

proportion of failure.

Markus, and Tanis (2000), finally summarized it is "an interaction between the

characteristics related to the people and characteristics related to the system" cause

project failures.

The author found out that although there has been a lot of research into failure of

ERP projects, the area of failure factors is still a buzz area. Therefore for this

research, the author would develop a checklist based of CSF and risk factors defined

earlier, in order to deduce possible failure factors.


53

3.5 Summary

In summary the author found out that large organisation have distinctive needs with

regards to their information system. There is a significant investment and cost of

ERP systems on organisations. The benefits that a system like an ERP provides to an

organisation includes easier access to reliable information, elimination of redundant

data and operations, reduction of cycle time and easily adaptability to changing

business environment.

While these system seem to be very promising to organisation as noted by Davenport

(2000) they are not risk free. Some of the challenges these system offer as proposed

by Sumner (1999), include lack of a project champion, lack of integration, failure to

mix internal and external personnel etc. Researchers such as Rashid et al., (2002)

altogether stated that the disadvantages of ERP systems include time-consumption,

cost, conformity to modules, vendor dependence, features and complexity etc.

The critical success factors of ERP implementation was described by Umble et al.,

(2003). However although researchers such as Davenpor (1998) have reported of

failure of ERP project, as supported by Liu (2002), the area of distinct failure factors

are still a fuzz area. As portrayed by the diagram below, the CSF for successful

implementations are known, thus, is an interesting need to define failure factors.


54

Figure 11: Model for CSF From Vidyaranya, et al., (2005)

Resources

Implementation project team (s)

Critical success factors of ERP implementation

Successful ERP implementation

Non Successful ERP implementation

specialists

+

-

Return to original organisation


55

CHAPTER FOUR

RESEARCH METHODLOGY

4.0 Introduction

This chapter presents the research process used for this investigation. Survey of Case

study methodology was adopted. The research was divided into four phase ; finding

case studies; analyzing the case study findings; extend an overall discussion of the

discussion and develop the conclusion and further research area. This chapter

includes six section including Research Approach, Data Source, Case Study

Analysis, and the Research Design, In line with all that would be discussed in this

chapter a brief Summary is also included.

4.1 Research Methodology

Walliman describe research as “a term loosely used in every day speech to describe a

multitude of activities.” (Walliman, 2001: 6). The research methodology is one of the

most power tools to achieve a successful research. Furthermore methodology helps

to produce a reliable conclusion. The intention of this chapter is to provide a very

brief description of a range of research methodologies which has been used in

collecting, analyzing data and finally, generating innovative findings. It is pertaining

why these methodologies are particularly selected in fulfilled the research purpose.


56

Saunders et al., (2000) explained that research methodology can be classified into

four different categories, namely: quantitative; qualitative; inductive and deductive

approaches. The dissertation the author is embanking on, will adopt the inductive

research approach. The further discussion of inductive approach, and the justification

for choosing it, would be elaborated further.

4.2 Research Approach

In order to outline the research in an appropriate way, Inductive approach is

employed for the study. Inductive approach is where theory is developed as a result

of data analysis (Saunders et al., 2000). The writings of authors like Walliman

(2001) and Ford (2002) explain that through inductive argument we infer general

truths from the particular (Specific cases→ Theoretical conclusion)”.

Glesne and Peshkin (1992) noted that inductive approach starts with a question or

‘problem statement’, and then generates a conclusion from the existing data. In other

words, it is likely to obtain the academic concepts from the existing data or cases.

Therefore, under the intention of obtain the reasons why ERP projects fail, the

inductive approach is definitely more appropriate for the dissertation’s development.

Induction permits the data to determine the key concepts to be discussed, rather than

vice versa. Conclusions are drawn from the empirical data. (Bell 1987, quoted by

Ford 2002). Accordingly, it is better for this case-study related dissertation to use

inductive approach.


57

According to the arguments presented above, a methodology framework is likely to

be extremely helpful with the intention of getting a concise research strategy. The

figure 12 portrays the methodology framework, which suits this dissertation

appropriately. It is outlined from inductive standpoint to facilitate the results from the

background knowledge and specific cases. In order to obtain the final answer of the

dissertation question ‘why the failure factors of ERP implementation in large

companies?’ there are four main inductive steps applied in the framework:

1) A critical look at the existing research and theories. After doing this, a

background knowledge can be well-established.

2) Select three valid, representative and reliable cases in order to obtain empirical

knowledge of the research question.

3) Discuss the results of the case studies by using the former theoretical and

empirical knowledge.

4) Create the final theoretical conclusion.

The author would adopt the frame work of Galliers and Land (1988), which states

that: Research question → Survey research→ Theory building→ Case study

survey→ Theory testing→ Theory extension.


58

Figure 12: Dissertation Frame work

To be more precise, two main methods are involved in this research. One is data

collection methods, such as secondary data collection. The other is data analysis

methods, e.g. content analysis and case study. It is notable that case study is

particularly important for this dissertation’s development.

Background (1) Secondary data

collection and analysis

(2) Case studies Analysis and Comparing

Theoretical Conclusion

(3) Result discussion

Background Study

Background Knowledge

New Findings

Survey of Empirical study

Analysis using Empirical Knowledge

Dissertation Frame Work


59

4.3 Research Method

McNeill (1990) explained that there are two kinds of data which are involves in the

sociological research. They are primary data and secondary Data.

He characterizes that: “Primary data is collected by the researcher at first hand,

mainly through surveys, interviews, or participant observation. Secondary data is

available from some other source, and comes in various forms,” (McNeill, 1990:99).

He went further to denote secondary data as “being available from other source and

comes in various forms”

There is no directly interview or survey involves in this dissertation. Therefore, the

author will concentrate on the secondary data collection and analysis in this research.

A range of secondary data such as reports, surveys and several case studies (e.g. Dell

computers and FoxMeyer) are utilized for analysis in the chapter five.

McNeill’ went further to explain that, secondary data collection and analyzing can be

divided into four forms: Data from earlier sociological research, statistics, documents

as secondary data and content analysis (review of case studies) and desktop research.

After carefully consideration, some aspects of these forms were applied in this

dissertation.


60

4.3.1 Data from Past Research

Busha and Harter (1980) acknowledged that literature review is essential to carry out

a research, as it helps to establish the background knowledge by identifying the

concepts and themes and trends of the topic. As also supported by McNeill (1990), it

is generally accepted to use data from previous studies as the basis of new work. This

is a key method in this dissertation, as it facilitated in defining the problem situation

more clearly and effectively. It also enables researchers to formulate the research

question by identifying the knowledge gaps, significant issues and possible

questions.

Nevertheless, it has always been a parametric part of research report. For instance,

the literature review not only presented as two of the main chapters (2 & 3), but also

provided evidence for other sections including introduction as well as discussion

section of this study. On the basis of the literature review a set of questions were

developed. Using previous studies, however is not aimed at capturing a collection of

the old works, rather it is aimed at forming a platform in order to obtain a new result

to satisfy the research question, detail discussions will be given by using 7 typical

case studies of large companies. The literature was collected from various sources

however more emphasis was given to literature from scholarly journals, text books

and scholar websites.


61

4.3.2 Desktop Research

Saunder et al., (2000) stated that desktop research, involves the accessing of

information from published resources and non-published sources via the computer.

It relies on secondary sources of information, therefore can be classified as a form of

secondary research. It differs from a literature search in that authors review and

summarise the information, cite the actual documentation, and provide an overall

report on the search topic. They went further to explain that desktop research is

advantageous because, it is less expensive than original research; takes advantage of

research already undertaken saves time and money.

4.3.3 Case Study Analysis

Bryman (2000) articulated that some of the classic studies in organisational research

have been derived from the detailed investigation of organisations. One school of

thought such as the likes of Alavi and Carlson (1992) believe that case study research

is the most common qualitative method.

“A case study is an empirical inquiry that investigates a contemporary phenomenon

within its real-life context especially when the boundaries between phenomenon and

context are not clearly evident”, (Yin, 1994). It is vital to pint out that the author

would be surveying case studies that have been already documented.

Saunders et al., (2000) went a step further to define a case study as the “development

of detailed, intensive knowledge about a single case or a small number of related


62

cases”. As supported by Bhandari et al. (2005), this strategy is particularly useful for

this type of dissertation as it provides with an in depth understanding of the context.

This research the author carried out focused on finding different case studies of

different organisations (as data), which have participated in an ERP implementation

failure.

The next section focuses on how the case studies were identified in order to carry this

investigation.

4.4 Research Design

Every type of empirical research has an implicit, if not explicit, research design. The

works of Yin (1994) defines research design as, “an action plan for getting from here

to there, where “here” may be defined as the initial set of questions to be answered,

and “there” is some set of conclusions about the questions”. Between “here” and

“there” may be found a number of major steps including the collection and analysis

of relevant data. The works of Yin (1993) also stresses that a well articulated

research design might be one of the most important ingredients in doing a good case

study analysis. A case study is an empirical inquiry that; “investigates a

contemporary phenomenon within its real life context when the boundaries between

phenomenon and context are not clearly evident and in which multiple sources of

evidence are used” (Yin, 1993).


63

Below is a figure that illustrates the four types of case study designs proposed by,

Yin (1994). The one adapted for this study is the multiple-case (embedded) design,

that is, Type 4.

Single-case design multiple case design

Holistic (single unit analysis)

Embedded (single unit analysis

Figure 13: Basic Types of design for case studies adopted from Yin (1994)

The author would employ from the works of Yin (1994), the survey of multiple-case

(embedded design), for the purpose of this research. The reason for using multiple

cases is that a detailed understanding of issues relating to the topic area is required

for the investigation.

In order to determine the failure factors in ERP implementation in large

organizations, the author had to find out what factors should be investigated in the

study, the author then carried out an extensive literature review in order to identify

what these are. The researcher then had to select case studies of organizations that

have implemented ERP by evaluating, if these factors are in the cases studies.

Type 1 Type 3

Type 2 Type 4


64

Thereafter, analysis on these sample case studies were conducted using the checklist

developed.

The case studies for the investigation would be selected based on the criteria of

selection of case studies as noted by Stake (1995). In order to obtain sufficient results

the author wanted to use 10 case studies however getting studies organisation ERP

failure proved a very difficult therefore the accepted sample size of 7 case

studies was used. The data (case studies) for the sample would be obtained from

textbooks and from individual websites of the various ERP companies.

The criteria that were taken into consideration for selecting the cases were adapted

from the works of Yin (1993) and Stake (1995). They are:

Every case was demonstrated before coming to a final selection.

The type of organisations taken into consideration

The cases will cover different regions of country emphasising on different

economic conditions

Understanding the maximum learning’s one can get from the cases.

These case studies were mainly from “enormous” organisations, like Dell, Nestle,

Hewlett Packard, and more. The cases were also from the varied continents such as

“InformationWeek” and “CIO”. These were able to emphasise on different economic

as well as working conditions of organisations. Finally the cases were able to provide

answers to all the questions of the checklist developed from the literature review and

are further discussed in the chapter.


65

The approach taken for the dissertation in analysing the data is shown in the figure

below.

Figure 14: Multiple case study approach adopted From Yin (1994)


66

4.5 Data analysis - Checklist development

This section draws on how the checklist was developed for the study as a framework

for evaluation of failure factors in order to achieve the objectives defined in chapter

one. The approach to this development involves investigation of several case studies

as stated above in earlier section of this chapter and gain valuable insights for

scenarios of use from work conducted by leading practitioners in this field.

Below is the frame work that was developed, based on the understanding of the

literature review. As supported by Bryman, (2002) a checklist can contribute

substantially to the improvement of validity, reliability and credibility of an

evaluation and to obtain some useful knowledge about a domain.

In accordance to the works of Yin (1984) checklist would ensure uniformity in the

analysis of data by

been generic enough not to slant on one organisation;

been unbiased with the intention to highlight both the strengths and the

weaknesses of the organisation;

been simple and intuitive so as not to pose difficulties even for a person

unfamiliar with the domain; and

focus on features and functionalities, which have direct impact on knowledge

management.


67

Guided by the design considerations, the following checklist was developed:

Factor Evaluation Implemented CSF Comments

1.) Are strategic Goals clearly defined?

-Does the strategy align investment in IS

with business goals?

-Does the strategy exploit IT for

competitive advantage?

-Does the strategy execute direct efficient

and effective management of IS resources?

-Does the strategy facilitate the

development of technology polices and

architectures?

-Has the ERP version been strategically

selected for the company?

2.) Are Top management committed to

the system?

-Does management builds confidence and

buy-in from all stakeholders?

-Does the project have senior management

support?

-Is there effective communication?

-Does management realize the benefits

sought from the ERP implementation in the

timescale required and deliver the necessary

return on investment?

-Is there proper management and control

structure?


68

3.) How effective is the implementation

project Management?

-Is there a competent project champion?

-Is there an appropriate

implementation strategy chosen? -Is there a formalized project

plan/schedule?

-Is the project delivered within the specified

project plan?

-Is there adequate knowledge of legacy

systems?

-Is there necessary skills in-house

to facilitate the project

implementation

4.) How committed is the organisation to

change?

-Has business processes been effectively

redesign?

-Are users actively involved?

-How well is ERP adoption been promoted

in the organisation?

-Is there sensitivity to user resistance?

5.) Was a great selection team selected?

-Are the staff and consultants dedicated?

-Is there appropriate usage of consultants?

Are there sufficient technical expertise?

-Is there adequate application of

knowledge?

-Are there competent business analysts on

the team?

-Is there adequate project team

composition?


69

-Is there trust between Partners?

6.) Was there adequate education and

training of users?

-Was training of end-users sufficient?

-Was there effective communication with

users?

-Is there commitment of customers to the

project management and project activities?

7.) Are performance measures effectively

adapted

-Has performance measures that assess the

impact of the new system been carefully

constructed?

-Where effective change agents and change

managers incorporated/

-Did the organisation seek the expertise of

external consultants?

-Has an enterprise-wide design

which supports data integration

been followed for quality control?

-Did the organisation effectively

seek the expertise of external

consultants?

8.) Are multi-site issues properly

resolved?

-If there are any multi- site issues, have they

been well managed?

9.) Are there technical difficulties?

-Is there adequate software configuration?

-Is there an integrated technology strategy

for supporting client-server

implementation?

-Are there any software or hardware

difficulties?

Figure 14 Check list adapted for study


70

4.6 Summary

In summary this chapter, was totally cantered or the research methodology employed

for this dissertation. The approach was inductive. In addition case studies analysis

and literature review were the vehicle used to deliver the methodology stated. A

checklist was developed after critically reviewing the literature. This provided a

framework to analyse the case studies in order to gain an in depth understanding to

the subject.


71

CHAPTER FIVE

DATA FINDINGS AND ANALYSIS

5.0 Introduction

This chapter is pivoted on presenting and the findings of the study. The author would

first of all start by briefly introducing the company. Secondly present analysis of the

case. Thirdly draw up a brief discussion. This process would be repeated for each of

the case. Lastly the author presents further discussion on the topic. The full details of

the analysis captured by the checklist for each case study, is found on the appendix.

5.1 Case Study of Fox Meyer

5.1.1 Introduction of Fox Meyer

FoxMeyer Drugs was a $5 billion company and the nation's fourth largest distributor

of pharmaceuticals before the fiasco. With the goal of using technology to increase

efficiency, the Delta III project began in 1993. FoxMeyer conducted market research

and product evaluation and purchased SAP R/3 in December of that year.

FoxMeyer also purchased warehouse-automation from a vendor called Pinnacle, and

chose Andersen Consulting to integrate and implement the two systems.

Implementation of the Delta III project took place during 1994 and 1995. In 1996,

FoxMeyer Drug, the drug distributor, declared bankruptcy after failing to implement

an ERP system over a three-year period.


72

FoxMeyer sued SAP, the world’s leading supplier of ERP software, for $500 million,

stating that its system was a “significant factor” that brought about the company’s

financial ruin (this despite the fact that FoxMeyer only spent $30 million dollars on

the ERP project) (Davenport, 1998).

5.1.2 Analysis of FoxMeyer

Are strategic Goals clearly defined?

The case pointed out that FoxMeyer had poor strategic goals. The strategy did not

align investment with business strategy. The case noted that since company was

competing on price it needed a high volume of transactions to be profitable, however

with the new contract of UHC, the focus of the project dramatically changed, this

contributed to rising project costs, lowering FoxMeyer’s already narrow margins and

erasing its profitability.

The strategy did not execute direct and efficient and effective management of IS

resources. This is proven by the fact that the company chose to go with different

vendors for two of the company’s most important system. Keil (1995) describes this

as an error in strategic information processing.

The ERP version that was selected for the company was not done strategically. The

system was customized before it was implemented; this raises a question as to how


73

effective the business requirements were taken into considerations when choosing

this software.

The company did not formulate strategies that exploit IT, for competitive advantage.

From the work of Jesitus (1997), the author learnt that the chief operating officer at

Pinnacle (who on the project team), confessed that the FoxMeyer mess was “not a

failure of automation. It was not a failure of commercial software per se. It was a

failure to strategically incorporate IT in order to increase profit margins” (Jesitus,

1997).

Are Top management effectively committed to the system?

Top management are not effectively committed to the system. The case noted that

though both FoxMeyer’s CEO and CIO were strong advocates of the project, in

February 1996, Thomas Anderson, the health president and CEO (and champion of

the company’s integration/warehouse automation projects) were asked to resign due

to delays in the new warehouse. This reflects that top management did not build

buy-in and confidence from all stake holders. This also reflects lack of trust between

management.

Although the case indicated that the project had senior management kept on

supporting the project financially, management did not take control of project; rather

it relied so much on the external consultant to take control of its project. The

feedback and communication system was very ineffective; hence there is a question

as to how appropriate decisions take by management was. The work of Bancroft et


74

al., (1998), echoes this when it noted that: “feedback at FoxMeyer was not effective

because the communication and attention necessary for fast and effective feed back

were missing”.

Management did not realize the benefits sought from the ERP systems. The CIO at

FoxMeyer felt a high degree of personal responsibility to the project when he stated

that: “we are betting our company on this” (Cafasso, 1994). The building of the

system was all a bet to CIO. He did not realize the true cost and time needed to gain

the benefits sought by the company. A proper management and control structure was

not established at FoxMeyer.

How effective is the implementation project Management?

The project implementation was not very effective. It can be argued that the

company did not have a formalized project plan. This is supported by the warnings of

Woltz consulting during the early stages of the project that the schedule for the entire

implementation to be completed in 18 months was totally unrealistic. Hence it is no

wonder the project was not delivered on time.

Reports noted that although FoxMeyer used an implementation partner, the in-house

skill and knowledge was a problematic area. Therefore there was inadequate

knowledge of the legacy systems.

An appropriate implementation strategy was not chosen, as the one-step approach

(big bang) used did not leave the company with much room for organisational


75

learning, this also left little time for the company to transfer all its organisational

memory, from the old to the new system. This strategy was also inappropriate as it

left little time for the company to measure attitudes and reception of the new system.

Evidence also points to the fact that an appropriate team was not selected. The staff

and consultants were not dedicated. There was insufficient technical expertise in the

project. The consultants were not used properly, as the case noted that the company

did not have necessary skill in-house and was relying on Andersen Consulting to

implement R/3 and integrate the ERP with an automated warehouse system from

Pinnacle. The fact that the scope of the project was risk and the company was one of

the early adapters of SAP R/3, the company should have thought carefully about

signing the contract with University Health System Consortium (UCH) this event,

lead to an unprecedented volume of R/3 transactions. This reflects poor risk

mitigating plan on the part of the company.

How committed is the organisation to change?

The organisation was not committed to change. At FoxMeyer, although the senior

management were committed to change, high reports revealed that some users were

not as committed. The company did not have adequate change management and

procedures. The users were not actively involved in the change process.

An appropriate user buy-in plan was not properly implemented at the organisation.

The company was not open with users, effective communication channels were not

established with users, and there was poor sensitivity to user resistance. For example


76

its labour problems exploded when workers began leaving their jobs en masses from

three Ohio warehouses, which were scheduled to be replaced by the automated

Washington Court House centre. The debilitating morale problem among departing

workers caused them to dump a lot of merchandise into trucks with packages

damaged or broken. ERP adoption was not well promoted in the organisation.

Was an appropriate team selected?

Analysis of the case study shows that an appropriate team was not selected for the

project execution. The staffs were not dedicated to the project and the consultants

were just playing politic, because of the publicity of the project.

The company relied so much on the third party companies to help it take ownership

of its project. The company did not utilize the consultants effectively. Cafasso,

(1994) noted that “although at the height of the project there were over 50

consultants at FoxMeyer, many of them were inexperience and the staff turnover was

high.” The case went further to state that the execution of the project was an issue

that was not rightly justified due to shortage of skilled and knowledgeable personnel.

These points to the fact that the project team was not well equipped with sufficient

technical expertise and therefore there was inadequate application of knowledge.

The case highlighted that appropriate user requirements were not carried out; hence

this highlights the fact that the team did not have competent business analysts. The

team composition in general was inappropriate. According to FoxMeyer, Andersen

used trainees and used the Delta project as a “training ground” for consultants who


77

where very inexperienced (Bancroft et al., 1998). It also claimed that SAP treated it

like its own research and development guinea pig. This indicated that there was lack

of trust between partners.

Was there adequate education and training of users?

There was inadequate training of users at FoxMeyer. Case noted that FoxMeyer

overspent and bit off more than they could chew, since they lacked available users on

project team, with the sophistication to handle a fast-track installation. More time

should have been given to incorporate user training.

The company did not adopt an open culture with its employees; hence effective

communication could not be established. The case also noted that feedback at

FoxMeyer was not effective because the communication and attention necessary for

fast and effective feedback were missing.

Although managers claimed to be committed to the project the workers, however

were not committed to project management and project activities, as they felt that

their jobs were been threatened.

Are performance measures effectively adapted?

Performance measures were not effectively adapted at the company. This is evidence

from the fact that the automated warehouse did not perform as planned. It was

estimated that the company sustained an unrecoverable loss of $15 Million from


78

erroneous shipments .It should have been closely monitored in order to ensure that it

met up with performance standard.

There was no accurate measurement of quality assurance of the new system. The pre-

implementation testing was inadequate, partly because the UHC contract was added

afterwards. The system should have been tested more, in order to verify and validate

that the system would meet up to quality standards.

The warehouse automation multiplied the project risk and interactions between R/3

and Pinnacle's automation; this took FoxMeyer into uncharted waters. Using just one

vendor would have reduced the risks and complexity of the project, as it would have

facilitated the company in following an enterprise-wide design which supports data

integration.

The case points out that FoxMeyer should have avoided the morale problem in the

warehouses by training the employees, helping them develop new skills, putting

some of them on the implementation team and using appropriate change management

techniques. This shows that effective change agents and managers where not

introduced to the system project.

The case noted that FoxMeyer should have made an effort to become less dependent

on the consultants. For example, knowledge transfer should have been written into

the consulting contract. FoxMeyer needed to ensure that project knowledge was

transferred to the organisation from the consultants so that they could develop in-

house skills for maintenance of the system after the consultants left. Therefore it


79

could be deduced that the organisation did not seek the expertise of external

consultants effectively.

Are multi-site issues properly resolved?

Multi-sites issues were not properly managed, and this led to an increase in staff

turnover. The case noted that as a result of multi site issues that were not managed

properly, the company faced uncounted problems with its workers in three of its

Ohio warehouses. These issues should have been foreseen and appropriate

calculations to manage them should have been employed.

Are there technical difficulties?

The project team tried to customize the software in order to suit the company’s

business needs, however, there were technical problem such as bugs in the software.

Furthermore the case noted that the risks escalated when design and customization

coding enter the equation.

The case noted that the system could not process the required number of daily

transactions, as the client could not facilitate the increased number of transactions.

This raises a question as to whether the two systems from the different vendors

where actually integrated.


80

5.1.3 Discussion

The above case study indicates that FoxMeyer’s ERP (delta project III) project failed

for a number of reasons. This analysis points out that although a lack of management

commitment can result in project failure, management over-commitment can be even

more disastrous. It can cause errors in judgment and lead to project escalation.

Overall, the expected payoff from the Delta III project was probably overestimated,

given that benefits are often intangible.

FoxMeyer failed on all the checklist factors drawn up for this study. The failure

factors that were diagnosed includes: poorly defined strategic goals, poor change

management, poor strategy formulation, unresolved technical issues, poor

management of project, poor user training and user involvement.

Furthermore, why was the project allowed to escalate to the extent of contributing to

FoxMeyer's bankruptcy? It is obvious that regardless the expectations, for FoxMeyer

it was not worth taking the risks that it did. In conclusion, FoxMeyer's experiences

provide valuable lessons on what cause ERP failures.

5.2 Case Study of Manco

5.2.1 Introduction of Manco

The works of Sarker and Lee (2003), explain that Manco group is a well-established

company that, over its three decades of existence, had earned a worldwide reputation

in the air pollution and dust-collection markets. Unfortunately, Manco had become


81

increasingly dysfunctional in recent years, primarily due to the “territorial” culture

created and encouraged by the Vice Presidents (VPs) of Engineering, Sales, and

Operations. There was little sharing of information among the functional areas

because of territorial attitudes and poor technological infrastructure. The resulting

coordination problems led to unreasonable lead-times and deteriorating quality of

products. Hence the company decided to embark on the journey of implementing an

ERP system. Data findings from the MANCO Group are available in the appendix.

5.2.2 Analysis of Manco


There was an attempt at Manco to clearly define its strategic goal. However, from the

model, it is portrayed that the strategy could have been enhanced in order to

incorporate the management of IS resources. Evidence of this is found in the case

when it noted that: the decision to pull out manpower and financial resource was a

miscalculation in the strategic management of IS resources.

The strategy should also have facilitate the development of polices and architectures.

This was not the case at Manco, as the case noted that the MORE management got

carried away by immediate organizational problems and the daily business demands,

as a result, concentrated on less important optimization and automation aims.

The case reflects that the strategy exploits IT for competitive advantage, when it

stated that the Manco Group IT strategies were formulated based on the status

assessment of the legacy systems, applications, and data structures, along with the

analysis of the business model developed by the re-engineering team in order to help


82

the company increase productivity. Furthermore it also indicates that the ERP

version had been strategically selected for the company.

Based on a comparison carried out by Bitco on the possible risks and benefits of the

two alternatives, the company chose to go to the global software market to select a

world-class package that best suited its current needs, and would serve future visions

and trends. This shows that the strategy align investment in IS with business

strategies.


There are questions as to how committed the top management was to the project. The

case noted that at the initial stage strong and committed leadership was in evidence

in the different functional areas. This may reflect that initially they sought buy-in

from all stake holders; however they did not incorporate a structure that would aid

them to gain full control of the project. This observation is made from the case when

it stated that: during Phase III, the leadership for the organization as well as for the

configurator implementation fell into complete disarray when the CEO left the

company.

One of the issues that could be deduced from the research is that management was

not full committed to the project due to the fact that they did not fully understand the

benefits sought from the ERP system.


83


The project had a formalized project plan. This can be observed from the fact that the

project was divided into three phases and each phase was expected to elapse for a

specified period of time. The project however was not delivered on the due date, as

the case noted that the configurator was not implemented three years after the

original deadline.

Adequate knowledge of the legacy system, and necessary in-house- was not ensured

throughout the project. One can observe from the case that two junior engineers (in

experience) were left on their own to complete the project, without regular

supervision of a project manager or a senior manager, or without regularly scheduled

interaction with representatives of other functional areas or the implementation team

members.

From the words of the IT manager it is obvious that appropriate quality assurance

measures and risk mitigating plans were not effectively employed. He noted that:

“The IT department began monitoring those services it provided to end-users and

those which could be related to legacy systems and which related to office

automation. A help desk was established for monitoring purposes, to provide some

statistics on performance. However, from the BPR point of view, there were no such

efforts, because the issue was not thought to be a corporate matter with a strategic

concern” (Sarker and Lee, 2003). These setbacks could be related to the fact that a

competent project champion, was not present through out however, there was an

appropriate implementation strategy.


84


Commitment to organisational change seems poor at Manco. The company did not

re-design its business process effectively in order to fully accommodate the ERP

system. This is reflected in the explanation given by the BPR manager when he

stated that: “Changes in the market situation were so drastic and so massive that

they even had to resort to other measures which did not, in fact, complement the

efforts and caused BPR failure by, for example, reducing manpower and reducing

salaries. Therefore, interest in the BPR project began to wane, it began to lose

resources and people became nervous because they thought their jobs were on the

line and they could be fired at any time”( Sarker and Lee, 2003).

The case noted that initially the user groups were actively involved; however as the

project progressed, the team did not carry them through. The team developed a full

listing of the business processes needed to carry out business transactions with out

consulting the users of the system. This reflects a poor user involvement on the part

of the project management. In addition, the case noted that the strong resistance

engendered by the manpower reductions resulted in BPR-related change principles

being compromised; this can be traced to poor sensitivity of user resistance.


Selection of project team was very poor at Manco. The staff and consultants were not

dedicated. While it is widely believed that help from an external consultant is

important to inject the concerned organisation with new skills and expertise, the


85

Manco Group experience contrasted belief and revealed several problems. This

points to the fact that the consultants where not appropriately used. The team did not

compose of sufficient technical expertise, project champion and business analyst

thence there was no adequate application of knowledge.


The Manco group did not offer its users sufficient training. The case noted that

scarcity of experienced staff, lack of training, education, and increasing overload all

contributed to failure of project efforts. The case went further to state that SAP R/3 is

a complex application, which places on IT staff the responsibility of supporting end-

users on a daily basis. This requirement was underestimated at the beginning, and

end-users resisted the new system. This resulted from ineffective communication;

they were not given enough skills to work with it. This illustrates the poor

communication of the project team with the users.

In addition the study shows that employees had a negative perception of re-

engineering, and increased sensitivity towards change efforts, hence it can be

acknowledged that there is poor commitment of customers to the project

management and project activities.


The performance measures were poorly adapted. This is reflected from the case

when it noted that The MORE project manager said that: “The progress of the


86

MORE project and its resulting benefits were not measured. Although some

parameters were developed, such as turnover, manpower, collection (cost reduction),

inventory, cycle time and benchmarking, they were not followed up” (Sarker and

Lee, 2003).

The absence of progress and performance measures, led the consultants to making

decisions that, transparently and negatively, influenced other major roles in the

company. This reflects a very poor measurement of quality within the system.

From the case the author learnt that although project manager instituted programs

(quality, profit-sharing, etc.) to help foster a cooperative culture in Manco, and

personally monitored the progress, towards the end of the project there was

indications that bills-of-materials produced were different from the once used by

manufacturing. This reflects that an enterprise design which supports data integration

had been followed. Performance was not accelerated due to lack of change agents.


The company tried to resolve all muti-site issues. The first phase of the initiative at

Manco, in preparation for the implementation of the ERP system, involved the

recognition of territorial walls in the organization and dismantling them through the

implementation of radical changes in the organizational structure, the reward

systems, and the organizational culture (Sarker and Lee, 2003)


87


The case noted that there were software difficulties. These difficulties were not

solved. The fact that the bills-of-material (BOM) created by the two engineers were

useful for engineers (designers), but were different from the ones used by

Manufacturing reflects a poor integrated technology strategy for supporting client-

server implementation. The technical problems that were faced were not properly

resolved, hence the implementation of the project failed.

5.2.3 Discussion on Manco

The study presents the analysis of the Manco case study. The MORE project

management had adopted a technical perspective, viewing IT as a force affecting,

and leading to, a certain organizational form. This state of affairs indicates a lack of

alignment between business strategy and IT strategy. This might be put down to lack

of developing adequate business requirements.

The major problem that the case points out includes: poor change management, poor

management of technological difficulties, poor project management, insufficient

training and education for users, lack of top managements commitment to project,

poor selection of project team and poor performance monitoring. Overall it can be

seen that the company embarked on destructive goals.


88

5.3 Case Study of Hershey Foods

5.3.1 Introduction of Hershey Foods

The Hershey Company is noted by the case to be a leading snack food company and

the largest North American manufacturer of quality chocolate and non-chocolate

confectionery products. Hershey incurred revenues of over $4 billion and more than

13,000 employees worldwide.

Reports from the works of Katz (2001) noted that Hershey went online in June 1999

with a new enterprise resource planning (ERP) system that cost $112 million.

Forecast indicated the project should have taken 48 months but was pushed through

in just 30. Consequently, there were major problems with order fulfilment and

shipping meaning that many customers didn't get their candy and warehouses

remained over-full. In total Hershey reported a 19% decrease in candy sales for the

1999 Halloween season and anticipated that it would also take a considerable loss

during the Christmas season as well. Making matters worse was the fact that three

separate software vendors were being employed to put into practice different parts of

the ERP system. The new system required "enormous" changes in the way Hershey

workers do their jobs. There was also evidence that insufficient user testing took

place before the new system was rolled out. (Katz, 2001)


89

5.3.2 Analysis of Hershey Foods


The analysis from the check list entails that at Hershey, the strategy aligned

investment in IS with business strategies. This can be observed from the case, when

it argued that the company knew that in order to achieve its business goals it needed

to improve its IS infrastructure.

However the strategy adopted by Hershey was quite poor, as it does not exploit IT

for competitive advantage. This can be portrayed from the fact that the company

wanted to get the system ready in time for the peak period, but the strategy did not

take into consideration the demands the project would have on business activities.

The strategy does not effectively manage IS resource and the strategy does not

facilitate the development of technological policies and architectures. The company

was information poor yet they did not a have strategy in place to help with in-house

maintenance of the new system. It is also self evident from the case that the ERP

version used was not strategically selected for the company. Indications from the

cases suggest that Hershey did not consider its user requirements and the business

processes that need changing before selecting the software.


90


The analysis from the model noted that the project had senior management support

throughout based on the fact that the project was actively sponsored by the

management; however analysis from the model also indicates poor management

commitment to the project. This is deduced from the fact that management did not

build buy-in from all stake-holders due to the fact that management did not play an

active role in the project life cycle.

The fact that management did not get involved with what was happening in the

project, could be put down to the fact that management did not establish effective

communication channels; inadequate management structure and control; and lastly

management did not realize the benefits of the ERP system.


Support from the case suggested that Hershey had a poor project management. The

author learnt from the case that people involved in the project felt that the lack of a

CIO wasn't necessarily the issue in 1999 so much as a lack of management

understanding of how much effort, both in systems development and organizational

change, would be required for success. This, points to the fact that there was no

competent project champion.

The implementation strategy employed was inappropriate, because the

implementation plan was to roll out the system all at once, leaving little room for


91

organisational learning. With three different vendors providing pieces to the puzzle,

the system should have been rolled out piecemeal and each piece should have been

tested extensively before moving on to the next, but with a shortened project

calendar there was not time. There was no formalized project plan for the team to

follow. The team did not have necessary in-house skills to facilitate the

implementation and there was no adequate knowledge of the legacy system on the

team.


The case noted that, Hershey’s CEO admitted that the project was a failed

implementation of new business processes. This portrays that the business processes

were not effectively redesigned at Hershey. The case went further to indicate that

much of the design did not efficiently incorporate a user group; therefore pointing to

a poor user involvement strategy.

In retrospect, of the data analysis, the researcher found out that Hershey was not

committed to change. ERP adoption was not promoted in the company as one of the

manager noted that Hershey had always over the years been very good at crisis

management, however they weren't used to dealing with computers. Users were not

actively involved in project activities, it can also be seen that users were not

committed to the project.


92


One consultant from vendor IBM Global Services pointed out that the business

process transformation underway at Hershey is an enormously complex undertaking.

However the consultants and employees are working hard to making sure that users

are using the business process/software correctly. This points out that staff and

consultants are dedicated.

Hershey executives wanted to supplement principal integrator IBM Global Services

with another consulting firm that had more experience with the SAP-Manugistics

interface. Hershey's management chose not to take that step. This shows an

appropriate usage of consultants. The choice of three vendors proved to have a

negative impact on the company. This was because the technical expertise, needed to

facilitate the project was not well organized.


The training and education were poorly delivered to users. The case noted that

without proper user communication, the complexity of the IT system hindered

coordination among processes within the organization. However the fact that users

work actively to get use to the system, shows a strong commitment of customer to

project management and project management activities.


93


Performance measures were not adequately incorporated. This is reflected when at

times Hershey saw itself unable to accommodate even the smallest portion of its

orders. The performance measures that assess the impact of the new system were not

carefully constructed. The implementation strategy chosen did not leave much room

for testing; this emphasizes a poor quality assurance of the new system.

The case noted that process should have been redesigned to facilitate an enterprise

wide integration, however they were not, resulting in a poor enterprise-wide design

which does not supports data integration


The case did not made mention of muti-site issues.


Hershey also experienced some technical difficulties. The case noted that the

problems caused by the abrupt transition (implementation strategy) weren't

immediately apparent, but essentially orders began falling through the cracks.

Despite having plenty of inventories on hand, Hershey couldn't get it to customers as

its data was not fully integrated. The software was not properly configured; there was

no integrated technology strategy for supporting client-server implementation. The


94

case also noted that there were a lot of software bugs that put a lot of demands on

software engineers.

5.3.3 Discussion on Hershey Foods

The above case, describes Hershey Foods Corp. a relatively low-end IT user with an

annual IT budget of only 1% of total revenue (Katz, 2001). In early 1996, Hershey

began an “Enterprise 21 Initiative,” a $112 million enterprise systems investment to

improve inventory management and ensure Y2K.

Prior to its Enterprise 21 Initiative, Hershey’s last major IT project was a barcode

scanning system in the 1980s. As a result, upon initiation of the new project, its

technological infrastructure was below industry standards. Its IT infrastructure

consisted of mainly mainframe-based hardware. The existing inventory management

system lacked the business functionality to support a seamless supply chain process.

In spite of its low IT capabilities, Hershey still made ambitious plans to implement

major IT systems concurrently: an enterprise system from SAP, a customer

relationship management system from Siebel Systems, and an inventory management

system from Manugistics (Songini, 2000).

Some of the problems that was indicated from the analysis includes poor change

management, poor strategy formulation, unresolved technical issues, poor

management of project, poor user training and user involvement.


95

5.4 Case Study of NIBCO

5.4.1 Introduction of NIBCO

The works of Brown and Vessey (2001) described NIBCO Inc. as a large

manufacturer of valves and pipe fitting with a workforce of about three thousand.

The company’s headquarter is in the US, and is reported in 2001 to have generated

an annual revenue of $460 million. The NIBCO management found it crucial to

break away from its existing legacy systems and replace them with a common,

integrated system for its finance, materials management, production, and

sales/distribution, operation which was offered in the Enterprise Resource Planning

(ERP) packages of major vendors by the second half of the 1990s. Contrary to the

advice of their consultants about taking a slower, phase-in approach, NIBCO’s

management developed plans for a Big Bang implementation of all modules (except

HR) with a $17 million budget and a project completion date 15 months r that

allowed for only a 30-day grace period.

5.4.2 Analysis of NIBCO


The strategic goal at NIBCO to a large extent was not clearly defined. The fact that

the case noted that “in order to quickly put in place the systems to execute the new

supply chain and customer-facing strategies, which had come out of the strategic

planning process, the company would had to commit a significant portion of its

resources” (Brown and Vessey, 2001), reflects that there was effective management


96

of IS resources. The strategy however did not align investment in IS with business

strategies. The case noted that the IS strategy that NIBCO was embarking on could

be described as being poor because it does not seem to link up with the business

objectives.

From the case study, it is stated that there was a poor knowledge transfer from the

consultants to the IT staff at NIBCO. This might be a paramount setback in the

development of technology policies as staffs are information poor, hence it can be

argued that the strategy does not promote the development of technology polices and

architectures.

Inadequate information strategy is reflected by the fact that the IT department was

under finance department. This raises question as to weather NIBCO viewed IT as an

essential strategic tool for gaining a completive advantage or as a liability on the

company

The case clearly states that NIBCO as a company would like to grow nevertheless

their choice of information systems package does not seem to reflect much of this

desire to grow, as they did not seem to take into consideration the business demands

in the future would have on their system. Many writers such as Davenport (2000)

highlighted that ERP can prove very difficult to manage when a company starts to

diversify, especially into areas of different region, country and culture. The vanilla

version chosen is known for being very inflexible.


97


By informing employees of the project initiative and the choice to go for an ERP

package reflects that management obtained buy-in from all stakeholders. The

analysis also portrays that project management had the senior management support,

through out the project life. This can be noticed from the way management

financially supported the project. However data from the case supported the fact that

the management team were not communicating with users regularly. This reflects

ineffective communication.

The case went further to state that The NIBCO management found it crucial to break

away from its existing legacy systems and replace them with a common, integrated

system for its finance, materials management, production, and sales/distribution,

operation in order to cut down on costs. This shows that management realized the

benefit sought from the ERP system

The project meant that there was an organisational restructuring. NIBCO took up the

form of a matrix structure. Johnson and Scholes (1988) explained that this structure

has some very good advantages that include: quality of decision-making where

interest conflict; direct contact replaces bureaucracy; increases managerial

motivation; development of managers through increased involvement in decisions.

This shows that a proper management and control structure was established.


98


The fact that Beutler, the project champion set up a cross-functional team to select an

ERP package early in 1996 argues that there was a competent project champion on

the NIBCO’s tiger team.

Though the choice to go with Big-Bang approach did not leave much room for

organisational learning, but at the end of the day it was appropriate for NIBCO,

pointing to the fact that the implementation strategy was effectively choosen.

NIBCO had a formalized project plan; however it did not follow it through as the

case reported that the organisation had restructured its supply chain process whereas

it was not initially planed for (diversion of plain in the middle of project). Hence it is

no wonder why the project was not delivered on schedule. NIBCO’s Go-live date

was postponed and the cost of the whole project implementation was more than what

was budgeted for.

There was inadequate skill in-house (NIBCO was information poor), the case noted

that the size of the IS department consisted of only 30 people out of 3000 associates.

There was adequate application of knowledge of legacy system, as the project team

constituted of divisional members who understood the system.


NIBCO had to restructure the company’s supply chain processes to better serve its

customers. Centralised all accounts payable where they were decentralised at first.


99

This shows that business processes had been effectively redesigned. From the case it

was explained that the choice to go for an ERP package did not evolve users,

pointing to a poor user involvement strategy.

Later on in the case it is noted that user’s attitudes did not change; till the end they

were reluctant to change and consolidation. This illustrates that ERP adoption had

not been effectively promoted through out the project life.


The project team was not appropriately selected. Staffs worked long hours, even

staying away from their families, showing that they were dedicated to the project.

NIBCO relied too much on its consultants. There was poor knowledge transfer from

consultants to staff. This indicates that consultants were not used appropriately.

However the presence of the consultants on the project team ensured that there was

sufficient technical expertise on the project team.

The case noted that there was no doubt that NIBCO needed to improve its

information wealth, however a poor knowledge application strategy is portrayed

when NIBCO decided to cut loose from its existing system.

Though there was mention of a business analyst, the case reflects that the only

feasibility study NIBCO went by was the one proposed by the consultants at the

Boston Group, bearing in mind that the feasibility study was for the phased in

approach rather than the Big Bang approach, that the company later embanked on.

This raises a question as to if there were competent analysts on the project team


100


The training and education offered to end users was inadequate. New organisational

structures, working spaces and environment for the change were created however

management did not concentrate on educating, training, and motivating the future

users of the system. Staffs were just told what to do. There was no proper

communication channel, where users can raise their concerns. Evidence from the

case noted that the staffs were committed to project activities.


Performance measures that assess the impact of the new system were not carefully

constructed, as it did not involve input from users. On the go life date the

consultants were gone and users were left to deal with the change. This highlights the

fact that accurate measurement of quality assurance of the new system was not taken

into consideration. One of the first tasks that the project team embanked on was to

design an enterprise-wide design. This was to incorporate a design which supports

data integration.

The study showed that NIBCO depended on outside capabilities for their change

management. Chaffey and Wood (2005) argued that any organisation wanting to

have a competitive advantage should take ownership of its change management as

change is the only true constant in any business environment.. From this, it can be

argued that effective change agents and managers were not introduced to the project.



101

The multi-site issues were properly resolved through the matrix structure adapted by

the company.


The case noted that although the project management team faced some difficulties,

these challenges were resolved properly; this indicates that software was also

configured properly. An integrated technology strategy for supporting client-server

implementation had been followed. This is proven by the fact that an integration

strategy was adopted for the company.

5.4.3 Discussion of NIBCO

In review of all that has being discussed so far, the author believes that the most

important thing that would help NIBCO to deal with all the future uncertainties and

changes its environment holds, would to develop strategies and cultures that would

elevate it to a learning organisation, where people at all levels, individuals and

collectively, are continually increasing their capacity to produce results. NIBCO

must be aware that learning is necessary before they can develop into a Learning

Once the company has excepted the need for change, it is then responsible for

creating the appropriate environment for this change to occur in.


102

One may wonder why is it that a company that had so many problems and set backs

during the implementation of its System project can be come a market leader within

its choice of information systems, against the all odds? What made NIBCO sail high?

After close evaluation of the case study analysis the author found out what made

NIBCO scale through all the mistakes and setbacks laid during the Information

Systems Project was that it had a Risk management program in place that worked

very well for it. Although they decided to cut loose from its legacy system, they had

a back-up in place. After the project, NIBCO (had had hands on experience) learnt

about how to manage risks and gained problem solving skills from the whole

experience.

5.5 Case Study of Dell Computers

5.5.1 Introduction of Dell Computers

Dell Inc., a leading computer manufacturer delivers innovative technology and

services they trust and value. Enabled by its direct business model, Dell sells more

systems globally than any computer company, placing it No. 25 on the Fortune 500.

Revenue for the last four quarters totalled $56.7 billion and the company employs

approximately 69,700 team members around the world (http://www.dell.com). Dell

Computers, after months of delay and cost overruns, abandoned their ERP project,

because they found that the new system was not appropriate for its decentralized

management model (Stefanou, 2000).

http://www.dell.com/


103

5.5.2 Analysis of Dell Computers


The analysis from the model pointed out that the strategic goals at Dell were not

clearly defined. Dell did not declare any operational goals other than a general desire

to support its growth. The strategy does not align investment in IS with business

strategies. Lack of continuous monitoring of the system, meant that Dell upgraded its

servers twice, this portrays a poor and efficient management of IS resource. The

business objectives where not clearly reflected in the choice of IT strategy. Hence it

can be argued that it does not exploit information technology for competitive

advantage.


Though the top management builds confidence and buy-in from all stake holders, as

in a letter to employees, senior vice-president and chief operating office explained

why the ERP project was a cornerstone two corporate priorities-infrastructure and

systems, and globalization, however analysis from the model reflects poor

commitment of top managers.

The project did not have senior management support through out. This is evidence

from that fact that the board began to get jumpy and eventually cut back on the

project, when they noticed the system was not working as it should. A proper

management and control structure was not established. The case went on to indicate


104

that management did not actually realize the benefits sought from the ERP system

and the time frame required in order to, achieve this benefits.


The management of the project implementation was also poor at Dell. There was no

competent project manager; an appropriate implementation strategy was not chosen;

though there was a formalize project plan, this plan was not followed through. The

project implementation also suffered as there was no adequate knowledge of the

legacy system and necessary skill in house to facilitate the project. Appropriate

quality assurance and risk management plan were not followed through.


Analysis from the checklist reflected that Dell had a poor commitment to change.

The business process had not been effectively redesigned to accommodate the ERP

system. In order to create a single view, Dell needed to standardize its business

processes around the world and capture them in R/3. This phase was not thoroughly

executed. Users were not actively involved in the change process and there was poor

sensitivity to user resistance. When employees at the company began to tinker with

prototypes of the new system, they did not like what they saw, however nothing was

done about this.


105

The ERP adoption was generally not well promoted at the company. This is deduced

from the fact that the new project champion did not reconcile the vision Dell with the

continuing SAP project of several years


The team worked very hard to get the system working; however case study indicated

that the staff and consultants were not dedicated. There is strong evidence pointing to

poor selection project team.

This is deduced from the fact that consultants were not appropriately used as the case

noted that as a result on undefined goals, the SAP team had difficulty focusing on

clear achievable benefits.

There was in sufficient technical expertise and business analyst, there was inadequate

project team composition. The case noted that the management realized that, the

technical staff did not know what they were doing.

The case noted that management pulled out the plugs on the project, as they did not

believe that the team was capable of safe delivery, this shows that there was lack of

trust between partners.


106


As noted by one of the employees, they felt that Dell was embarking on this project

just because it was what competitors were doing. Staff at Dell questioned the need of

such a project. This reflects that staff did not really believe in the project or project

activities. Though analysis also pointed out that the staff and consultants worked

very hard and were dedicated to project activity, one can argue how committed could

they have been to a project they had little or no faith in.

Though there was communication with users it was not effective enough, hence it

could be highlighted that the communication plan with users was inadequate. The

case noted that users still struggled to come to terms with what was going on around

them, this reflects that the training provided for the users, was not adequate enough.


As communication was vague, and there was no competent project leader, adequate

performance measures where not put in place. As a result of insufficient testing, the

system did not function as it was meant to. This reflects that there was inaccurate

measurement of quality assurance of the system

Effective integration of process in order to support the new system has not been

followed. The performance measure strategy adapted at Dell was generally a poor

one.


107


The case noted that the company had multi-site issues; however they were not

appropriately managed. The company needed to solve its organisation structure

before implementing the ERP


The case noted that the system began to route information all around the company,

causing havoc and wreck to the network of the company. This could be put down to

inadequate configuration of software.

The data from the various entry points were not full integrated; hence it caused a lot

of strain on the users, reflecting a poor integrated technology strategy for supporting

client-server implementation.

5.5.3 Discussion on Dell Computers

The above is the analysis of the case study on ERP implementation at Dell

Computers. The case presents a series of factors that caused the implementation to

fail. The training of end-users at Dell was poor. The performance measures were

poorly adapted at Dell; an enterprise wide approach which supports data integration

had not been followed. There was also poor measurement of quality of the system.

Change agents were not used to boost up performance at Dell and the organisation

did not effectively seek the expertise of external consultants. The multi-site issues at


108

Dell were not well managed. Dell experienced some technical problems during the

project management, however these problems were not well resolved; the

configuration of the software was inadequate; and an integrated technology strategy

for supporting client-server implementation had not been followed.

5.6 Nestle

5.6.1 Introduction of Nestle

Nestlé with headquarters in Vevey, Switzerland was founded in 1866 by Henri

Nestlé and is today the world's biggest food and beverage company. Sales at the end

of 2005 were CHF 91 billion dollars, with a net profit of CHF 8 billion dollars.

Nestlé currently employs around 250,000 people and have factories or operations in

almost every country.

Reports from the Dieringer, (2004) noted that in June 2000, Nestle signed a much

publicized $200 million contract with SAP-and threw in an additional $80 million for

consulting and maintenance--to install an ERP system for its global enterprise. The

consumer goods giant intended to use the SAP system to help centralize a

conglomerate that owns 200 operating companies and subsidiaries in 80 countries.


109

5.6.2 Analysis of Nestle


As reflected from the results of the analysis at Nestlé, the strategic goal were clearly

defined. The strategy aligned investment in IS with business strategies. Executives at

Nestle realized that the company needed to standardize its business processes if it

wanted to be competitive, this replicates that the strategy exploits IT for competitive

advantage.

There were plans made by the project champion, as to how the IS resource would be

effectively managed, this mirrors that efficient management of IS resources was at

the heart of the project activities. The strategy laid considered that there would be a

need future policies and architecture. Management consider a number of ERP

vendors before choosing the one that best fit their business strategies, this shows that

the ERP version was strategically chosen.


The stakeholders team presented a blueprint for major changes they thought could

be made in three to five years. Management made it very clear that the project

would be a business process reorganization and that the company could not do it

without changing the way it did business. This shows that the top managers built

the stake-holders confidence and buy-in.


110

Evidence from the case indicated that management believed in the project and

supported it financially. However although the company tried initially to build

communication, communication was not effectively established with users, and

divisional executives though out.

Management realized the benefits sought from the ERP as the case stated that Nestle

was at a severe competitive disadvantage and realized that it needed one system used

by all in order to be more efficient and survive in the global economy. However the

fact that by June 2000, Nestle was forced to halt the rollout and the project manager

was removed from the project and reassigned to Switzerland, shows that the top

management structure and control during the project was not stable.


The project was lead by a competent project champion; however analysis of the case

shows that an appropriate implementation strategy was not chosen. The case noted

that Nestle needed to realize that the implementation of software will not solve every

organizational problem and not every process in the company can be re-engineered

to fit the software.

The rollout was scheduled to take three years for Nestle largest sites with the others

to follow, hence there was a formalize plan for the project implementation. The

system was not delivered within time as so many things happen during


111

implementation that it was impossible to stay on target during a particular year, let

alone the life of the project.

There was adequate knowledge of the legacy and there were necessary in-house

skills to facilitate the project. Nevertheless the rush in the installation meant that the

some modules were not talking to each other, therefore this points to the fact that

there appropriate quality assurance measure were not put in place.

The case also noted that accurate update of budget projection at regular intervals,

was not incorporated. It was not a common practise at Nestle to frequently revisit

numbers in order to help minimize troublesome surprises, this could be put down to

lack of an appropriate risk mitigating plan.


Project champion noted that if she was to do it over again, she would first of all focus

on changing business processes; this reflects that the business processes at Nestlé

were not redesigned properly. The fact that the case noted that none of the groups

that were going to be directly affected by the new processes and systems were

represented on the key stakeholders’ team, reflect a poor user involvement strategy.

It was stated that much of the employee resistance could be traced to a mistake that

dated back to the project's inception, however nothing much was done about this.

This reflects that there was poor sensitivity to user resistance.


112

In general ERP adoption had not been well promoted in the organisation, as the case

noted that even before the SAP modules were rolled out, there was rebellion in the

ranks.


The case noted that fifty top business executives and ten senior IT professionals had

been assembled to implement the SAP project. The team's goal was to come up with

a set of best practices that would become common work procedures for every Nestlé

division, this illustration shows that the dedication on the part of the project team to

the project activities. The team was well equipped with sufficient amount of

technical staff, the IT Staff (including outside consultants), amounted to two hundred

and fifty.

The fact that business re-engineering was not placed in priority, cast doubt as to

whether there was appropriate application of knowledge. Nestlé did not realize on

time that it would need to redefine the business requirements of the project until after

conducting a meeting with nineteen key stakeholders, this instance from the case

study reflects that business analysts were not competent.

Lack of trust between partners is displayed when the director of information systems,

noted that the retreat organized by project champion with nineteen Nestlé key

stakeholders and business executives started off as a gripe session.


113

The overall team composition could have been improved. The team should have

ensured that the software met users’ requirement. The case stated that by the time the

implementation began in 1999 Nestle already had problems with its employees’

acceptance of the system.


Worthen, (2002), explained that not only did workers not understand how to use

the new system; they didn't even understand the new processes .This could be

put down to the fact that they were not adequately trained and educated on the

new system.

Divisional executives were just as confused as their employees as they had been

left out of the planning and development of the new system (Worthen, 2002).

This occurrence shows that the communication with users of the system was poor

at Nestle.

The case went further to note that divisional executives were less willing to assist

in straightening out the mess that had developed (Worthen, 2002). This shows

that the users were not fully committed to the project management or project

activities.


114


The works of Worthen (2002) put forward that the performance of the new system

was not adequately monitored, hence performance measures that assess the impact of

the new system not been carefully constructed.

The testing of the system was not followed through; hence there was no accurate

measurement of quality assurance of the new system. The case went further to noted

that business processes where not full integrated, this raises a question as to if an

enterprise-wide design which supports data integration was followed. The change

management plan was inadequate, as key change agents were not introduced to the

system.


The project champion later noted that “what I should have been done was to first of

all achieving universal buy-in from all its multi-sites and then and only then on

installing the software” Worthen (2002). This statement demonstrates that the multi-

sites issues that existed in Nestle were not well resolved through the project life.


In accordance to the case, in the rush to beat the Y2K deadline, the Best project team

at Nestle had overlooked the integration points between the modules. This reflects

poor configuration of software.


115

The case went further to state that though all the purchasing departments now used

common names and systems, and followed a common process, their system was not

integrated with the financial, planning or sales groups. It can be seen from this

illustration that an integrated technology strategy for supporting client-server

implementation was inadequate. The technical problems emerged during the

implementation, though the case noted that although the installation was successful

the implementation was a failure.

5.6.3 Discussion on Nestle

The analysis of the Nestle case study was an interesting one. It points out issues that

the company did well and points out to some failure of the processes undertaken

during the project implementation. The project champion Dunn noted that if she

were to do it over again, she'd focus first on changing business processes and

achieving universal buy-in, and then and only then on installing the software. "If you

try to do it with a system first, you will have an installation, not an implementation,"

she says. "And there is a big difference between installing software and

implementing a solution” (Worthen, 2002).

The words of this project manager, sheds a clear light to the fact that if a system

works on the go life date does not mean the project implementation was successful.

A successful implementation as supported by writers such as Chaffey (2005) is one

that proves useful to the users and the system owners. Though the system worked at

Nestle, the users did not find it useful. Project manager noted that she should have


116

focused more on the change management of the project in order to ensure a

successful implementation.

5.7 Case Study of Hewlett Packard

5.7.1 Introduction of Hewlett Packard (HP)

Hewlett-Packard (HP) is a large, successful company with over $31 billion in 1995

revenues. Its fast annual revenue growth of approximately 30% from such a large

base has astounded observers. HP delivers vital technology for both business and

life. The company competes in many markets, including computers and peripheral

equipment, test and measurement devices, electronic components, and medical

devices. HP’s $4 billion annual R&D investments fuel the invention of products,

solutions and new technologies, so that they can better serve customers and enter

new markets. HP invents engineers and delivers technology solutions that drive

business value, create social value and improve the lives of its customers. HP has a

dynamic, powerful team of 142,000 employees with capabilities in 170 countries

doing business in more than 40 currencies and more than 10 languages. HP was

described as the second largest computer manufacture in the world by 2001

(Chaturvedit and Gupta, 2001). It emerged to become the market leader desktop

computers, servers, peripherals and services such as system integration. Besides

computer related products and services, which accounted for more than 80% of sales

the company also made electronic products and systems for measurement, computing

and communication.


117

As a result of merger with Compaq Computer Corporation, in December 2003, the

top management at HP decided to re-organize their organisational model, hence they

embarked on a SAP implementation project.

5.7.2 Analysis of HP


The case noted that business objectives were not taken into considerations when

embarking on the project, therefore this reflects that the strategy align investment in

IS with business strategies. The main rational for the project was that management

saw is as an opportunity to cut costs, increase transparency, and equip HP to

embrace new business models rapidly. Based on this notion it could be accepted that

the strategy exploit IT for competitive advantage.

The implementation of the SAP solution was meant to reduced the huge costs

incurred in IT support and deployment, therefore the strategy execute direct efficient

and effective management of IS resources.

The strategy does not facilitate the development of technology polices and

architectures as insiders from the company explained that a real-time ordering

mechanism was being forced onto a system that was not capable of handling it. The

system would not be able to cope with future architectures. Though a number of

vendors were considered, HP chose the SAP integrated R/3 suite of client/server

applications software as it provided a high level of functionality for global use. This


118

points towards the fact that the ERP version had been strategically selected for the

company. It can be seen that the strategic goals at HP were not clearly defined.


Users were not involved or informed appropriately of project initiation. This reflects

that management did not build confidence and buy-in from all stakeholders. The

project have senior management support through out, as the case noted that

management were not fully interested in the project. The case noted that ERP

benefits were not fully understood by management. The case noted that a proper

matrix structure should have been established in order to cope with the organisation

complexity at HP. This indicates that management did not a proper management and

control structure. In review all that has been discussed the project did not have the

full commitment of management.


A competed project champion was not on the team, as the case explained that

management complained that champion was not performing well. Though there was

a formalized project plain, the project was not delivered on the due date. Evidence

from the study indicated that the implementation ran server months behind schedule.

The project did not have adequate knowledge of the legacy systems. The case noted

that problems arose between the legacy system and the new system because users

were not actively involved. The necessary skills in-house, to facilitate the project

implementation was poor. The staffs were not technically skilled enough to facilitate

the project. The case noted that the testing of the system was inefficient. Several


119

bugs arose from the system as a result of this. This shows that appropriate quality

assurance measure was not put in place. Overall the project management at HP was

poor.


From the case, the researcher found out that problems surfaced as result of business

processes that had not been integrated to the new system. This indicates that business

processes had not been effectively redesigned. The users were poorly adapted to the

project team. The case noted that the user group were not present on the project team.

The organisation was generally not ready for the ERP system. There no sensitivity to

user resistance. The case noted that nothing much was done to ease the fears

employees expressed with regards to loosing their jobs. Overall the efforts of the

project management were poor.


The fact that the case stated that many VPs left the company during the project

implementation, shows that the staffs and consultant might not have been fully

dedicated. The consultants were not appropriately used. The case noted that there

was a high level of dependency team members on the consultants. There was trust

between partners as SAP and HP had history of effective working relationship. The

division could not predict the actual demand for customized server product; this

shows poor application of knowledge. As the system requirements were not


120

adequately constructed, it could be inferred that competent business analysts were

not employed.

In review of all these, the team composition was poor.


The IT personnel did not have adequate time for training and to develop their skills

for the new system. There were problems of communication between the varied

groups. Users had fears of being laid off, so they were not committed to project

activities


When the system went live, some sales orders that went through were not accounted

for. The contingency plan was inadequate to handle the new system as it was an old

plan which had been used for earlier migrations and did not involve in-depth

assessment of the IS division. The case noted that there was data redundancy. The

different applications were not talking to each other


The study points out that the territorial walls that existed in the company were not

broken, therefore the company did not resolve it multi-sites issues.


121


Marketing team at HP failed to envision all the configurations, customers could

order. This shows that the software configuration was inadequate, it was some how

lacking processes that needed to be incorporated.

Problems surfaced between integration of the new SAP system that was

implemented. This reflects that an integrated technology strategy for supporting

client-server implementation was not employed. The team was tested for

standardised orders but not for customized orders; hence they faced technical

difficulties that were too late to be resolved.

5.7.3 Discussion on HP

ERP implementation failure at HP was a demonstration of how much failure could

impact overall business performance. HP spent huge amounts of money in speeding

up delay orders. Experts were of the opinion that every implementation of an ERP

package warrants a fresh approach and if it is not mapped to detail, it might miss its

objectives. The major issues that were brought to light was the inadequacy fo

existing business processes. From the investigation, some of the major challenges

that caused the implementation to fail were: poor project team constitution, data

integration problems, strategic forecasting problems, poor planning, improper testing

and inadequate implementation support and training. This case provides a valuable

lesson on failure factors of ERP implementation.


122

5.8 Further Discussion

The diagram below represents the overview of findings of the case study survey

conducted by the researcher. This section is aimed at discussing the global resulting

findings of this survey.

Figure 16: Global results

Note that factor 1-9 correspond with question 1-9 of the checklist respectively.

Colour Code

Good:

Average:

Failed:

Fox Meyer

Manco

Hershey Foods

NIBCO

Dell Computers

Nestlé

HP

Factors 1

Factors 2

Factor 3

Factors 4

Factors 5

Factor 6

Factors 7

Factors 8

Factors 9

Outcome of Implementation

F

F

F

P

F

F

F


123

5.8.1 Strategic Goals

Fox Meyer

Manco

Hershey Foods

NIBCO

Dell Computers

Nestlé

HP

Strategy align investment in IS with business strategies

X

√

√

X X √

X

Strategy exploit IT for competitive advantage

X √

X X X √

√

Strategy execute direct efficient and effective management of IS resources

X X X √

X √

√

Strategy facilitate the development of technological policies

X X X X X √

X

ERP version chosen strategically.

X

√

X X X √

√

Figure 17: Strategic Goals

Manco, Hershey Foods, and Nestle all aligned their investment in information

systems (IS) with business strategies; however they still experienced a failed ERP

implementation. On the other hand FoxMeyer, NIBCO, Dell computers and HP all

failed to align investment in IS with business strategies. Nevertheless NIBCO still

managed to achieve a successful implementation. This proves that while it is

important to align investment in IS with business strategies, failure to do so might

not be critical to a project implementation.

Fox Meyer, Hershey Foods, NIBCO and Dell computers all embarked on strategy

that did not effectively exploit IT for competitive advantage. With exception of

NIBCO all of these companies experienced a failed implementation. Though Manco


124

and Nestle incorporated a strategy that took full advantage of IT for competitive

advantage, this did not guarantee them in delivering a successful implementation.

This pinpoints that while it is good to develop strategy that uses IT for a competitive

advantage, it is not a sure banker for preventing ERP implementation failure.

NIBCO Nestle and HP employed strategy that effectively and efficiently managed

their IS resources. Though HP did not deliver a working system NIBCO and Nestle

were the only companies that did, though the implementation at Nestle was

considered a failure. The others did not develop plans that would effectively

managed there is resources; hence this could be considered as a critical failure factor.

All the companies with exception of Nestle, did not utilize strategy that would

facilitate the development of technological polices. While many researchers such

as Davenport (2000) suggested that this is a good practise, it is not a guarantee to

successful ERP implementation as evidence in the case of Nestle.

Nestle, HP and Manco were the only companies that strategically selected their ERP

version. This is very important as cautioned by Sumner (1999), however as reflected

from the study putting this in place alone is not an assurance to avoid a project

failure.

From the study it is evidence that only Nestle had a good information strategy

formation; however it failed in delivering successful ERP implementation. Though

the ERP implementation at Manco failed, the strategy formation was average. The

research also points that the ERP implementation at NIBCO was successful;

nevertheless, the formation of a poor strategy is clearly stated. As also supported by


125

writers such as Chaffey and Wood (2005) a lack of clearly defined strategy could

lead to failure of an ERP implementation, however from the research pointed out that

there are other failure factors in ERP implementation.

5.8.2 Top management’s Commitment to the system

Fox Meyer

Manco

Hershey Foods

NIBCO

Dell Computers

Nestlé

HP

Management builds confidence in buy-in from all stakeholders

X X

X √

√

√

X

Project have senior management’s support through out

√

X √

√

X √

X

Effective communication

X X X X X X X

Management realize the benefits sought from the ERP implementation in the timescale required

X X X √

X X

X

Proper management and control structure

X

X X √

X X X

Figure 18: Top management’s Commitment to the system

NIBCO, Dell and Nestle were the only companies where management builds

confidence and buy in from all users. Though NIBCO was the only one that


126

delivered a successful implementation, Nestle delivered a working system. This

suggests one of the factors that affect system failure is buy-in of all stakeholders.

FoxMeyer, Hershey, NIBCO and Nestle were the only companies that ensured

project had senior management’s support through out the system development.

NIBCO and Nestle were the only ones that had a working system at the end of

project life. This could indicate that for a failure to be avoided project management

support is vital.

None of the companies incorporated effective communication and only NIBCO

realized the benefits of ERP system and established a proper management and

control structure. Hence it is no wonder why it sailed safe through the delivery of its

project implementation.

From the research, the author found out that only two of the organisations used for

the study, actually sustained senior management’s commitment (NIBCO and Nestle).

Both companies were both graded average for top management commitment, which

means that this could have been further enhanced. On the Go-live date, both systems

worked (though the implementation at Nestle was regarded as a failure), and for the

other companies that failed in this particular factor (top managers commitment) their

implementation was a complete failure. This indicates that this factor could be a

critical failure, and for large organisation organisations in future embarking on ERP

projects, sustaining top management commitment is vital.


127

5.8.3 Project Management

Fox

Meyer

Manco

Hershey Foods

NIBCO

Dell Computers

Nestlé SA

HP

Competent project champion

X X X √

X √

X

Appropriate implementation strategy

X √

X √

√

X -

Formalized project plan/schedule

√

√

X √

√

√

√

Project delivered within the specified project plan

X X X X X X X

Adequate knowledge of legacy systems

X X X √

X √

X

Necessary skills in-house to facilitate the project implementation

X X X X X √

X

Appropriate quality assurance measure in place

X X X √

X X

X

Appropriate risk plan

X X X √

X X X

Figure 19: Project Management

NIBCO, and Nestle were the only company that had a competent project champion

and adequate knowledge of the system on the project team. This indicates that these

two factors could be inter-related.

Manco, NIBCO and Dell were the only companies that employed an appropriate

implementation strategy. All the companies except for Hershey had a formalized

project plan however all could not deliver the system on the expected go-life date.

This shows that failure to deliver on project date might not be a critical failure factor.


128

Appropriate quality assurance measure and risk mitigating plan was effectively

adapted by only NIBCO the other companies did not adapt it. Nestle was the only

company that had necessary in-house skill to facilitate implementation.

The research point out that NIBCO was the only organisation that employed

effective project management. This gives a clearer indication as to why it delivered a

successful implementation. The only other company, Nestle that tried to implement

effective project management (although it was graded average), obtained a working

system at the end of the project (though the implementation was classified as a

failure). This indicates that lack of effective project management is detrimental to

project implementation of an ERP system.

5.8.4 Commitment of the Organisation to Change

Fox Meyer

Manco

Hershey Foods

NIBCO

Dell Computers

Nestlé

HP

Business processes effectively redesign

X X X √

X X X

Users actively involved

X X X X X X X

ERP adoption promoted in organisation

X X X X X X X

Sensitivity to user resistance

X X X X X X X

Figure 20: Commitment of the Organisation to Change


129

NIBCO was the only company that effectively redesigned its business processes.

As stressed by Falkowski et al., (1998) an enterprise wide culture and structure

change should be put in place which facilitates people, organization and culture

change. This could be a principal reason why NIBCO did not fail in the project

implementation. Though Rosario (2000) explained that users must be actively

involved and concerns must be addressed through regular communication, working

with change agents, leveraging corporate culture and identifying job aids for

different users, none of the companies, including NIBCO was sensitive to user

resistance; neither did they get users involved. Lastly none of them promoted ERP

adoption within the organisations.

From the study all the companies that were used for the research did not employ

effective change management (including NIBCO, which ended up with a successful

ERP implementation). While writers such as Sumner (1999) and Davenport (1998)

have explained that change management is a vital in an ERP implementation, the

author learnt that there might be other factors that could lead to an ERP failure.

5.8.5 Selection of Project Team

Fox Meyer

Manco

Hershey Foods

NIBCO

Dell Computers

Nestlé

HP

Staff and consultants dedicated

X X √

√

X √

X

Appropriate usage of consultants

X X √

X X -

X

Sufficient technical expertise

X X X √

X √

X


130

Adequate application of knowledge

X X X X X X X

Competent business analysts

X X X X X X X

Adequate project team composition

X X X X X X X

Trust between partners

X

X X - X X √

Figure 21: Selection of Project Team

All the companies failed to adequately apply knowledge, employ competent

business analysts and ultimately achieve an adequate project team composition.

None of the companies except HP established trust between partners. HP and SAP

got on well, because they had a long history of good working relationships, more

than half of SAP’s customers run on HP servers These three factors could be closely

linked and interdependent of each other, however because NIBCO was able to

deliver a successful implementation this suggest that though this might be a failure

factor, it may not be considered critical.

Only NIBCO and Nestle had sufficient technical expertise on the project, no wonder

they both delivered a working system. The staffs at Hershey, NIBCO and Nestle

were dedicated to the project; however analysis shows that only Hershey made

appropriate usage of consultants.

From the study all the companies that were used for the research did not select

appropriate project team (including NIBCO, which ended up with a successful ERP

implementation). Though researchers such as Sumner (1999) and Davenport (1998)


131

have explained that team composition is a vital in an ERP implementation, the author

learnt that there might be other factors that could be more critical failure in an ERP

implementation.

5.8.6 Education and Training of Users

Fox Meyer

Manco

Hershey Foods

NIBCO

Dell Computers

Nestlé

HP

Sufficient training of end-users

X X X X X X X

Effective communication with users

X X X X X X X

Commitment of users to project activities

X X √

√

X X X

Figure 22: Education and Training of Users

Though the works of Roberts and Barrar (1992) pointed out that education should be

a priority from the beginning of the project, and the financial resources and time

should be spent on various forms of education and training. It can be seen from

analysis that none of the companies provided sufficient training for end-users, neither

did they established effective communication with users. Only Hershey and NIBCO

had users’ commitment to project activities. Though Hershey failed, so did all the

others that did not employ this strategy. This goes to say that while there are other

factors causing failure, user commitment to project activities is important in order to

avoid failure.


132

From the study all the companies that were used for the research did not employ

adequate education and training of users (including NIBCO, which ended up with a

successful ERP implementation). Though researchers such as Wee (2000) and

Davenport (2000) have explained that user training is a vital in an ERP

implementation, the author learnt that there might be other factors that could be more

critical failure in an ERP implementation.

5.8.7 Performance Measures

Fox

Meyer

Manco

Hershey Foods

NIBCO

Dell Computers

Nestlé

HP

Performance measures that assesses the impacts of the new system

X X X X X X X

Accurate measurement of quality assurance of the new system

X

X X X X X X

Followed an enterprise-wide design which supports data integration

X X X √

X X X

Effective change agents and managers

X X X X X X X

Effectively seek the expertise of external consultants

X X X X X - X

Figure 23: Performance Measures

None of the companies adapted performance measures that assess the impact of the

new system. In the case of all the companies, accurate measurement of quality

assurance of the new system was not adhered to; effective change agents were not


133

introduced to the project; and companies did not effectively seek the expertise of

external consultants. Only NIBCO followed an enterprise-wide design which

supports data integration.

The study shows that, none of the companies used for the research employed

effective performance measures (including NIBCO, which ended up with a

successful ERP implementation). The works of researchers Falkowski et al., (1998)

concluded that performance measures is a vital in an ERP implementation, however

the author learnt that there might be other factors that could be more critical failure in

an ERP implementation.

5.8.8 Multi-site issues

Fox Meyer

Manco

Hershey Foods

NIBCO

Dell Computers

Nestlé

HP

Multi-sites issues well resolved

X √

- √

X X X

Figure 24: Multi-site issues

NIBCO and Manco were the only companies that resolved their multi-sites issues

effectively. In accordance to Davenport (2000), multi-site implementations present

special concerns and the manner in which these issues are addressed may play a large

role in the ultimate success of the ERP implementation.


134

5.8.9 Technical difficulties

Fox Meyer

Manco

Hershey Foods

NIBCO

Dell Computers

Nestlé

HP

Adequate software configuration

X X X √

X X X

Integrated technological strategy

X X X √

X X X

Resolved software difficulties

X X X √

√

X X

Figure 25: Technical difficulties

NIBCO was the only organisation that employed adequate software configuration

and an integrated technological strategy. The analysis went further to point to the fact

that Nestle and NIBCO were the only companies that did resolved technological

difficulties. This shows that it is imperative to face technical difficulties during a

project implementation, however if this issues are not well managed it could be

critical to the failure of the project.

5.9 Risks Associated with ERP implementation

Below are the risks that were deduced from the study.

1. The company may not benefit from the opportunities provided by the new

ERP system (e.g. Nestle)

2. Poorly implemented business re-engineering processes (e.g. HP)


135

3. The financial aid to implement the system may not be allocated to the project

(e.g. Dell)

4. ERP implementation is a long process, generally running into several months,

therefore keeping an activity alive for such long duration would be nearly

impossible without top management commitment (e.g. Manco).

5. Employees may not understand how the system will change business

processes (HP).

6. Lack of support for staff as well as managers during implementation

7. Users’ needs will no be met after installation.

8. Impact of the new system on the organisation may not be appropriately

monitored for decision making processes.

9. Necessary feedback to facilitate change may not be received

10. Quality assurance measures may not be ensured

11. Inability to deliver orders or lost sales because of incorrect stock records.

12. Developing system that does not meet up with user requirements

13. A delay or scrapping of a new system implementation (e.g. FoxMeyer and

Dell).

14. Extra cost to prepare reconciliation.

15. Failed implementation

The list stated above is similar to the risks factors that was discussed in the works of

Sumner (1999) in section 3.2.1, Table 8.


136

5.10 ERP Failure Factors

As evident from the study, there are some failure factors that are more detrimental to

the project, they are known as critical failure factor (CFF). The author found out that

most of these factors lie around the area of top management’s commitment to the

project; project management’s effectiveness, management of multi-site and technical

issues. They include:

Inadequate software configuration

Ineffective Business processes redesign

Ineffective management of Multi-sites issues

Lack of buy-in from all stakeholders

Lack of integrated technological strategy

Lack of adequate knowledge of legacy systems

Lack of an enterprise-wide design which supports data integration

Lack of appropriate quality assurance measure in place

Lack of appropriate risk mitigating plan

Lack of commitment of users to project activities

Lack of competent project champion

Lack of dedicated staffs and consultants

Lack of proper management and control structure.

Lack of strategy that executes direct efficient and effective management of IS

resources

Lack of sufficient technical expertise

Management not realizing the benefits sought from the ERP implementation

and the timescale required in achieving these benefits.


137

Unresolved software difficulties

Other factor areas in ERP system that needs to be managed effectively in order to

avoid failure: training of users; performance measures, strategic goals, selection of

project team, and the organisation’s commitment to change.

How to Avoid ERP failure

From the study the researcher learnt that in order to avoid ERP failure:

1. Laying down clearly defined strategic goals.

2. Top managements commitment must be sustained for the project

3. Project management must be effectively coordinated by a competent project

champion.

4. Organisation as a whole must be fully committed to change

5. Effective project team must be selected

6. Users must be effectively trained and educated

7. Performance measures must be adequately adapted

8. Multi-sites issues must be resolved

9. Technical difficulties must be effectively managed

This was the same findings that were noted in the work of Umble et al., (2003), when

they put forward ERP critical success factors.


138

5.11 Summary The seven cases are especially characteristic for the current ERP project failure

study. They all failed in different ways, some are failed because of undelivered, and

some are delivered but still failed after a period of implementation. No matter why

these projects are failed, there are key issues to take into consideration: project

management, top management support, technical difficulties and multi-site issues.

These key factors were found to be critical. So far, the final result for the research

question of “ERP failure factors” can be answered in a consistent way. The factors

are deduced from the study along with support from previous chapters’ studies. To

sum up, to manage such an enormous ERP project in the large organisations is a

incredibly complicated task. It requires entire responsibilities and reliabilities of not

only the project leader, staffs, users and but also that of management. It is essential

for a successful project that all the involvers can collaborate and communicate in a

proper way.


139

CHAPTER SIX

CONCLUSION

6.0 Introduction

In this chapter, the research conclusion will be presented in the context of research

objectives which was given in chapter 1, section 1.4. The chapter concludes with the

discussion on recommendations for further research.

6.1 Conclusion

In this dissertation, a number literatures and reports are fully reviewed and compared

in Chapters two and three. The main aim of these chapters was to describe ERP

system and to discuss these systems in light of large organisations respectively. The

author learnt that ERP system may promise a lot of benefits to the implementing

organisations, there have been high reports of ERP project failures. There had been a

lot of study on the critical success factors (CSF) in ERP system. The author discusses

the issues that were pointed out. The author also tried to discuss failure and potential

failure of ERP system, as noted by other researchers.

For this purpose this study has developed a checklist for carrying out subsequent

evaluation of the sample case studies to identify and gain an insight into the

endeavours of the organisations in facilitating failure factors in project

implementation. The findings and analysis of this evaluation revealed that there are


140

four areas where most critical failure factors lie. The factors in this area would

lead to failure of projects if they are not effectively managed. They are: top

management’s commitment to the project; project management’s effectiveness,

management of multi-site and technical issues. There are other factor areas in ERP

system that needs to be managed effectively in order to avoid failure. These areas

includes: training of users; performance measures, strategic goals, selection of

project team, and the organisation’s commitment to change.

As a result of this study, the author recommends to implementing organisations that

information-based enterprises must be planned in an integrated way whereby all

stages of the project implementation are engaged to bring about agility, quality, and

productivity. In review of all that has being discussed so far, the author believes that

the most important thing that would help organisations to deal with all the future

uncertainties and changes its environment holds (with regards to project

implementation), would to develop strategies and cultures that would elevate it to a

learning organisation, where people at all levels, individuals and collectively, are

continually increasing their capacity to produce results. As rightly explained by

Peltum (1989) steering a successful course into such an unknown territory depends in

having a clear sense of direction and ability to respond effectively to unforeseen

pitfalls and opportunities therefore it is vital for a corporate strategy of information

management to have top management involvement and backing for information

management policies crucial.


141

6.2 Future Research

After three months investigation on project failure of ERP systems study, the main

issue that comes to the mind of the researcher is that not many literatures addresses

how to solve all the problems because “after decades of experience and countless

publications, most enterprise projects still fail to reach a satisfactory conclusion

(Davenport, 1998). Therefore there is a need to address this issue.

The author encourages that the further research should be conducted with regards to

ERP failure assessments. In accordance to Ward and Chapman (2002) systems are

failure in different ways. “Some systems never work… some work, but come in either

cripplingly over budget, very lat or both. Others are pared down in terms of

facilities… some perform to specification but turn out to be so inflexible that

maintenance and enhancement assume nightmarish proportions… others are thought

to work, but turn out not to do.” This was also revealed by the study, although Nestle

implemented a working system on the go-live date, it was still considered a failed

implementation. Therefore, the research on ERP system evaluation can reveal the

question what projects failures factors are even further.

Lastly the author proposes that, further research should evaluate and test if the only

critical failure factors to ERP system implementation are the ones mentioned in the

findings. The checklist could also be modified to incorporate other failure factors.


142

REFERENCES

Ackoff, R. L. (1967) "Management Misinformation Systems", Management Science,

14(4) Dec, 147-156

Adam, F. & Sammon, D. (2004) Setting the Scene — Defining and Understanding

ERP Systems, Idea Group Inc

Alavi, M., and Leidner, D.E. (2001) Review: Knowledge Management and

Knowledge Management Systems: Conceptual Foundations and Research Issues,

MIS Quarterly, Vol. 25. No.1 pp.107-136.

Alsop, S. (August, 1998) Is there life after ERP? For the valley, maybe not. Fortune,

231

Anita, L. (1996) "Getting in the pink", Management Review, Vol. 85 No.5, pp.18-23.

Appleton, L. (1997). How to survive ERP. Datamation, 50-53.

Baan (1997) Welcome to Baan,. http://www.baan.com/. [Access 12/08/2006]

Bancroft, N., Seip, H. & Sprengel, A. (1998) Implementing SAP R/3: How to

Introduce a Large System into a Large Organisation, Manning Publications,

Greenwich, CT.

Baskerville, R., Pawlowski, D. & McLean, E. R. (2000) Enterprise Resource

Planning and Organizational Knowledge: Patterns of Convergence and Divergence.

Proceedings of the International Conference on Information Systems. CONF21: 396-

406.

Bell, J. (1987) “Doing Your Research Project: A Guide for First-Time Researchers in

Education and Social Science”, Milton Keynes: Open University Press.

Bhattacherjee, A. (2000) Beginning SAP R/3 implementation at Geneva

Pharmaceuticals. Communications of the Association for Information Systems 4.

http://www.baan.com/


143

Available from <http://cais.isworld.org/articles/4-2/article.htm> (Article 2).

[Assessed 20/07/06]

Bignell, V., & Fortune, J. (1984). Understanding Systems Failures. Manchester:

Manchester University Press.

Bingi, P., Sharma, M.K., and Godla, J. (1999), ``Critical issues affecting an ERP

implementation’’, Information Systems Management, pp. 7-14

Black, J.D. (1999) Enterprise resource planning––spatial information meets business

process software in cyberspace. GeoWorld 12 (4), 38–40.

Blanchard, D. (1998) ERP the great equalizer, Available: Http://

lionhrtpub.com/ee/ee-spring98/ erp.html [Assed 20/07/06]

Boykin, R. F. (2001) "Enterprise resource planning software: a solution to the return

material authorization problem." Computers in Industry 45(1): 99-109.

Brooks, F. P. (1974) The Mythical Man-Month - Essays on Software Engineering,

Reading: Addison-Wesley.

Brown, C.V. and Vessey, I. (2001) NIBCO’S “BIG BANG” Communications of

AIS, Volume 5, Article 1

Brown, C.V., Tatikonda, M.V., and Vessey, I. (2003) NIBCO: mySAP Supply Chain

Management, Kelley School of Business, Indiana University

Bryman, A. (2002) Research Methods and Organisation Studies, London: Routledge

Busha, C. H., and Harter, S.P. (1980) Research Methods in Librarianship:

Techniques and Interpretation. New York: Academic Press.

Cadle, J. & Yeates, D. (2001). “Project Management for Information Systems”.

London: Pearson Education.

Cafasso, R. (1994) "Success strains SAP support", Computerworld, 28(36),

September.


144

Chaffey, D. and Wood, S. (2005) Business Information Management Improving

Performance Using Information Systems, Financial Times Pretence Hall.

Chan, S. (1999). "Positioning for the Future: CRM and ERP Integration: Competitive

Analysis", Gartner Report.

Chang, S. I., Gable, G. G., Smythe, E., and Timbrell, G. T. (2000) A Delphi

examination of public sector ERP implementation issues, Proceedings of

International Conference of Information Systems, Brisbane, Australia, 10-13

December

Chaturvedit, R. N. and Gupta, V. (2005), ERP Implementation Failure at HP, ICFA

Centre for Management Research.

Chen, I. J. (2001). "Planning for ERP systems: Analysis and future trend." Business

Process Management Journal 7(5): 374.

Chen, I. J. (2001). Planning for ERP systems: Analysis and future trend. Business

Process Management Journal, 7(5), 374-386.

Clemons C. (1998) "Successful Implementation of an Enterprise System: a Case

Study", Americas conference on Information systems (AMCIS), Baltimore, USA.

Davenport T. H. (2000) “Mission Critical: Realizing the Promise of Enterprise

Systems, Harvard Business School Press.

Davenport, T. H. (1998) "Putting the Enterprise into the Enterprise System,"

Harvard Business Review, July-August, 1998, pp. 121-131.

Dean, J. (2001) “Managing Technology." Government Executive 33(9): 76-80.

Delone, W. H. (1988b), "Determinants of success for usage in small firms", MIS

Quarterly, 12-1, pp 51-61


145

Dieringer, D. S. (2004) ERP Implementation at Nestle, Enterprise Resource Planning

Systems. Available online:

http://www.uwosh.edu/faculty_staff/wresch/ERPNestle.Htlm [Assed 20/06/06]

Ein-Dor, P., & Segev, E. (1978) Organisational Context and the Success of

Management Information Systems, Management Science, Vol. 24, No. 1, pp. 611-

622.

Falkowski, G., Pedigo, P., Smith, B., and Swanson, D. (1998) ``A recipe for ERP

success’’, Beyond Computing, pp. 44-5.

Ford, N. (2000) Designing Your Methods of Investigation. University Of Sheffield:

UK

Gallagher, M. (2005) ERP systems and business continuity management. Available

online at: http://www.continuitycentral.com/feature026.htm [assed 23/07/06]

Galliers, R.D. & Land, F.F., (1988) "Choosing appropriate information systems

research methodologies," Communications of ACM vol. 30, No 11, pp. 900 902,

1988.

Gardiner, S. C., Hanna, J. B., and LaTour, M. S. (2002)."ERP and the reengineering

of industrial marketing processes A prescriptive overview for the new-age marketing

manager." Industrial Marketing Management 31(4): 357.

Garner Group, (1999) “The ERP Vendors Market” Brisbane, October 1999.

Ghosh, S. (2002) Challenges on a global implementation of ERP software.

Engineering Management Conference, December.

Gladden, G. R. (1982). “Stop the life-cycle, I want to get off”. Software Engineering

Notes 7 (2), 35-39

http://www.uwosh.edu/faculty_staff/wresch/ERPNestle.Htlm

http://www.continuitycentral.com/feature026.htm


146

Glesne, C., & Peshkin, A. (1992) Becoming Qualitative Researchers. London:

Longman.

Gunson, J. and de Blasis, J. P. (2002) Implementing ERP in Multinational

Companies: Their Effects on the Organisation and individuals at Work, Journal of

Management Information Systems, 9 (3), 22-43.

Hall, R. (2002) "Enterprise Resource Planning Systems and Organizational Change:

Transforming Work Organization?" Strategic Change 11(5): 263-270.

Hayes, M. IT Moves to the Front Burner, InformationWeek, Sept 17, 2001.

Hecht, B. (1997) Choose the right ERP software. Datamation, 56-58.

Hill, L. (2000). SAP comes to Deere, JD Journal, 29(2), 12-13.

Hillegersberg, J. V., and Kumar, K. (2000) “ERP experience and evolution”

Communications of the ACM, 43-4, pp 23-26.

Holland, P., Light, B., and Gibson, N. (1999) A critical success factors model for

enterprise resource planning implementation, Proceedings of the 7th European

Conference on Information Systems, Vol 1, pp. 273-97.

Hong, K. K., Kim, Y. G. (2001) "The critical success factors for ERP

implementation: an organisational fit perspective", Information and Management, 1-

16, pp 1-16

http://www.cio.com/archive/051502/nestle.html [Accessed 20/06/06]

http://www.cio.com/archive/111502/tl_hershey.html [Accessed 19/06/06]

http://www.dell.com [Accessed 20/06/06]

http://www.nestle.com/All_About/Glance/Introduction/Glance+Introduction.htm)

[Accessed 20/06/06]

http://www.thehersheycompany.com/ [Accessed 14/06/06]

http://www.ukais.org/ [Accessed 29/06/06]

http://www.cio.com/archive/051502/nestle.html

http://www.cio.com/archive/111502/tl_hershey.html

http://www.dell.com/

http://www.nestle.com/All_About/Glance/Introduction/Glance+Introduction.htm

http://www.thehersheycompany.com/

http://www.ukais.org/


147

Huang, Z., and Palvia, P. (2001) “ERP implementation issues in advanced and

developing countries”, Business Process Management Journal, Vol. 7 No. 3, pp. 276-

84.

Jesitus, J. Broken Promises?; FoxMeyer 's Projectwas a Disaster. Was the Company

Too Aggressive or was it Misled?, Industry Week, November 3, 1997, 31-37.

Johnson, G., Scholes, K. (1988) Exploring Corporate Strategy. Hertfordshire:

Prentice-Hall International Ltd.

Kashef, A.E., Izadi, M., and Al-Sehali, S. H. (2001) ERP: The Primary Solution

Provider For Industrial Companies, Journal of Industrial Technology Volume 17,

Number 3

Katz, D. M. (2001) Case Study: What If Your ERP Can't Deliver?, Hershey still

haunts them, CFO, Available at: http://www.cfo.com/article.cfm/2993965?f=related

[assed 24/07/06].

Keil, M. (1995) "Pulling the plug: Software project management and the problem of

project escalation", MIS Quarterly, 19(4), December, 421-447

Khafre Systems International (2001), Why Projects Fail: An Architectural

Viewpoint. Http://Www.Ksiinc.Com/Why.Htm [Accessed 21 July].

King, W. and Rodriguez, J. (1978) “Evaluating management information systems”,

MIS Quarterly, 2(3).

Lai, V. S. (1994) "A survey of rural small business computer use: success factors and

decision support", Information and Management, 26, pp 297-304

Laughlin, S. P. (1999) An ERP game plan. Journal of Business Strategy 20 (1), 32–

37.


148

Liu, F. (2002) Critical Analysis the factors which Contribute to IS Projects Failure

In project Management Perspective: Three Characteristic Case Studies in the UK

Public sector, University of Sheffield Dissertation

Lucas, H. C. (1975). Why Information Systems Fail. London: Columbia University

Press

Lyytinen, K., & Hirschheim, R. (1987) “Information Systems Failures: A Survey and

Classification of The Empirical Literature. Oxford Surveys in Information

Technology”, Vol 4, 257-309.

Mandal, P., and Gunasekaran, A. (2003). "Issues in implementing ERP: A case

study." European Journal of Operational Research 146(2): 274-283.

Markus, M., and Tanis, C. (2000) “The Enterprise System Experience-From

Adaptation to Success” Pinnaflex Educational Resources, OH.

Martin, M. (1998) Enterprise resource planning. Fortune 137 (2), 149–151.

McKinney, R. (1998) Wall to wall change. Across the board. 32-38.

McNeill, P. (1990) Research Methods. London: Poutledge

META Group (1997) Adaptive Systems: The role of enterprise wide technical

architecture, Available online at :

www.metagroup.com/newwhos.nsf/InterNotes/Link+Pages/eas+-+delta2, [Accessed

22/08/06]

Michel, R. (1997) Reinvention reigns: ERP vendors redefine value, planning and

elevate customer service. Manufacturing Systems, (p. 28-92).

Motwani J., Mirchandani D., Madan M., Gunasekaran A., "Successful

implementation of ERP projects: Evidence from two case studies." International

Journal of Production Economics 75(1/2): 83.

http://www.metagroup.com/newwhos.nsf/InterNotes/Link+Pages/eas+-+delta2


149

Nah, F. F., Lau, J. L. and Kuang, J. (2001) “Critical factors for successful

implementation of enterprise systems”, Business Process Management Journal, Vol.

7 No. 3, (pg. 285-96).

Peltu, M. (1989) Introducing Information System Management, Blackwell, (p.g. 59)

Rao, S. S. (2000) Enterprise resource planning: business needs and technologies,

Central Leather Research Institute, India

Rashid, M. A., & Hossain, L., & Patrick, J. D. (2002) The evolution of ERP Systems:

A historical perspective. In L. Hossain, J. D. Patrick, & M. A. Rashid (Eds.),

Enterprise Resource Planning: Global opportunities & challenges (pp. 1-16).

Hershey, PA: Idea Group Publishing

Raymond, L. (1985) "Organisational characteristic and MIS success in the context

of small businesses", MIS Quarterly, 9-1, pp 37-52

Raymond, L. (1990) "Organisational context and MIS success", Journal of

Management Information Systems, 6-4, pp 5-20

Reilly, K. (2005) AMR Research Releases ERP Market Report Showing Overall

Market Growth of 14% in 2004, AMR Press (available online at:

http://www.amrresearch.com/Content/View.asp?pmillid=18358 )

Rivard, S., Pinsoneault, A., and Bernier, C. (1999) Impact des technologies de

l’information sur les cadres et les travailleurs, Gestion, 24 (3) automne 1999, (p.g.

51-65).

Roberts, H. J. and Barrar, P. R. (1992) ``MRPII implementation: key factors for

success’’, Computer Integrated Manufacturing Systems, Vol. 5 No. 1, (p.g. 31-8).

Robey, D. and Zeller, R. (1987) “Factors affecting the success and failure of an

information system for product quality.” Interfaces, 8(2).

http://www.amrresearch.com/Content/View.asp?pmillid=18358


150

Romei, L. (1996) "New technology strengthens new commitment", Managing Office

Technology, Vol. 41 No.7, pp.18-20.

Rosario, J. G. (2000) On the leading edge: critical success factors in ERP

implementation projects, Business World, Philippines.

Ross, J. W. (2000) "The ERP Revolution: Surviving vs. Thriving." Information

Systems Frontiers.

Sandoe, K., Corbitt, G., and Boykin, R. (2001) “Enterprise Integration”, Wiley, New

York.

Sarker, S., and Lee, A. S. (2003) "Using a case study to test the role of three key

social enablers in ERP implementation." Information & Management 40(8): 813-829

Sauer, C. (1993) Why Information System Failure: A Case Study Approach. Henley-

On-Thames: Alfred Waller Limited.

Saunders, A., Lewis, P. and Thornhill, A. (2000) Research method for business

students, Prentice Hall: England

Saunders, A., Lewis, P., and Thornhill, A. (2000) Research method for business

students, Prentice Hall: England

Schultz, R. L., & Slevin, D. P. (1975) A program for research in implementation, in

Schultz, R. L. and Slevin, D. P. (eds.), Implementing Operations

Research/Management Science, New York: Ameri can Elsevier

Scott, J. E. (1999) The FoxMeyer Drugs‘Bankruptcy: Was it a Failure of ERP?

Proceedings of the 5th Americas Conference on Information Systems (AMCIS),

Milwaukee, Wisconsin.

Shanks, G. (2000) A Taxonomy of ERP Implementation Approaches, Proceedings of

the 33rd Hawaii International Conference on System Sciences, 2000.

Sheridan, J. H. (1995) Which path to follow? Industry Week, 244(13). 41.


151

Songini, M. (2000) Users vent frustration over Oracle CRM/ERP upgrades,

Computerworld,

Songini, M. L. "Halloween Less Haunting for Hershey This Year," Computerworld,

Nov. 6, 2000.

Stake, R. E. (1995) The Art of case study research, Sage Publication: London

STANDISH GROUP (1995), Chaos, The Standish Group Report.

Stefanou, C. (2000) The Selection Process of Enterprise Resource Planning, ERP

Systems, In Proceedings of the 6th Americas Conference on Information Systems,

August 10th-13th, Long Beach California,( p.g.988-991).

Stevens, T. (1998) "Proof positive", Industry Week, Vol. 247 No.15.

Sumner, M. (1999) Risk factors in enterprise-wide/ERP projects, Journal of

Information Technology,1999) 15, 317–327

Trimi, S. and Sang, M. L., and Olson, D. L., (2000) Alternative means to

implement ERP Internal and ASP. Available online at:

www.emeraldinsight.com/0263-5577.htm [Accessed 23/07/06]

Turner, J. A. (1982) “Observations on the use of behavioural models in information

systems research and practice”, Information & Management 5(3), 207-213

Umble, E. J., Haft, R. R., and Umble, M. M. (2003) Enterprise resource planning:

Implementation procedures and critical success factors. European Journal of

Operational Research. Vol. 146(2).

Vidyaranya, B., Gargeya, K., and Cydnee B. (2005) “Success and failure factors of

adopting SAP in ERP system implementation”, Business Process Management

Journal, Vol. 11 No. 5, pp. 501-516, Emerald Group Publishing Limited

Walliman, N. (2001) Your Research Project: A step by step guide for the first time

researcher. London: Sage Publications.

http://www.emeraldinsight.com/0263-5577.htm


152

Ward, S., & Chapman, C. (2002) Transforming Project Risk Management Into

Project Uncertainty Management, International Journal Of Project Management, In

Press, 15 July.

Wee, S. (2000) Juggling toward ERP success: keep key success factors high, ERP

News, February, Available on at:

http://www.erpnews.com/erpnews/erp904/02get.html. [Accessed 22/06/06]

Weston, R. (1997) Huge enterprise apps pose management risk. ComputerWorld, 10.

Weston, R. (1998) ERP users find competitive advantages. Computerworld, (January

19).

Wiegers, K. (1998) "Know your enemy: software risk management," Software

Development, October.

Worthen, B. (2002) "Nestlé’s ERP Odyssey" in CIO magazine, May, ( pg. 62-70).

Wreden, N. (1999) ERP systems: promise vs. performance? Beyond Computing,

8(7). 16-22.

Yin, R. (1993) Applications of Case Study Research. London: Sage Publications.

Yin, R. (1994) Case Study Research: Design and Methods. London: Sage

Publications.

Yingjie, J. (2005) “Critical Success Factors in ERP Implementation in Finland”,

M.Sc. Thesis In Accounting, The Swedish School of Economics and Business

Administration

Zhang L., Matthew, K. O., Zhang1, Z., and Banerjee, P. (2002) “Critical Success

Factors of Enterprise Resource Planning Systems Implementation Success in China”,

Proceedings of the 36th Hawaii International Conference on System Sciences

(HICSS’03).

http://www.erpnews.com/erpnews/erp904/02get.html


153

abstract - dagda.shef.ac.ukdagda.shef.ac.uk/dispub/dissertations/2005-06/external/oladiran... ·...

Documents