CHAPTER 4 CASE STUDY –LEARNING FROM...

74

CHAPTER 4

CASE STUDY –LEARNING FROM FAILURE

4.1 INTRODUCTION

In this chapter we report on two case studies conducted as part of

this research. These cases relate to two different ERP implementations in

ABC Corporation, a midsized, multi location process industry in India with

over 2000 employees, over a 100 customers and a supply chain extending

across the country as well as overseas. The cases were selected because the

first was considered a failure and the second a success. The lessons learnt

from the first failed implementation led to a change in implementation

strategy for the second which finally led to success. We believe there are

lessons to be learnt both from the failure and from the later success both for

research and practice. Being from the same organization with no major

changes in either the ERP or the management and user teams, a comparative

study gives an opportunity to zero in on those causal variables that seem to

make a difference.

This company had a good legacy system but had decided to

implement ERP for meeting the long term information needs of the business.

The first project which we call ERP 1, had large cost and time overruns, did

not deliver promised results and met with severe user resistance. After

managing with an unsatisfactory implementation and attempting to a correct

the gaps over a two year period the company decided to do re-

75

implementation. This project we call ERP 2 was completed on time, largely

met targets and was considered successful.

We have used this context to scientifically study the processes that

caused failure in the first instance and success in the other. We look at the

interaction between the implementation process and organizational dynamics

to seek answers for the question of ERP failures. The case study addresses the

meta-question: “Why do ERP projects fail? We use insights gained to

identify key causal factors that lead to failure and steps that could be taken to

steer such projects to success.

In the following section we identify factors that have been found in

earlier research to have influenced IT project outcomes. Next the key

hypotheses that would be tested in the research through the case study are

enumerated. The section that follows explains the nature of qualitative

research and justifies its use in this research. The research methodology

followed is explained next. The cases are then described and the analysis of

the cases follows. The chapter ends with a detailed discussion on the case

similarities and differences with a final word on the key learning from the

case which are used in the empirical study that follows.

4.2 FACTORS INFLUENCING ERP OUTCOME

Chapter 2 presented a detailed literature study which included a

section on CSFs which could be causal factors in influencing ERP project

outcomes. We revisit these critical factors in this chapter as one of the

objectives of the case study is to understand the manner in which these causal

factors work in actual practice.

Most researchers starting from Davenport (1998) identify top

management support and such directional factors as crucial for ERP success.

76

These include factors like use of a cross functional steering committee,

communication, cross functional implementation teams etc.

Hong and Kim (2002) stress on the organization preparedness

aspects of the implementation namely organizational fit, system adaptation

levels, resistance to change etc.

Wixom and Watson (2001), study implementation issues related to

data warehousing project success. They categorize the CSFs as belonging to

into three groups, viz., Organizational, Project and Technical. A data

warehousing project has many similarities with an ERP project- it is complex,

it has pan-organization linkages, and change management issues are involved

Chua et al (2009) analyze CSF literature and point out to the

contradictions and fragmented nature of the studies. The CSFs listed vary

across studies, the operational definitions are different, several important

causal factors like change management are missing from some lists etc., The

researchers believe because CSF research has “emphasized identifying CSFs

linked to project success at the expense of a more thorough exploration of the

causal mechanisms connecting organizational actions and processes to project

success. In other words, CSF research has focused on what CSFs look like,

but overlooked how and why they become critical” (pp 2).

Parr and Shanks (2000), studying ERP implementation propose a

project phase model (PPM) consisting of three distinct phases: planning,

project and enhancement. The PPM model synthesizes earlier ERP

implementation models of Bancroft et al (1998), Ross (1998) and Markus

and Tannis (1999) which focus on the pre and post implementation steps and

bundle the implementation project into one category. While recognizing the

importance of the planning phase and post project phases, PPM focuses on the

project phase which they subdivide into set up, reengineering, design,

77

configuration/testing and installation. They then identify the relative

importance of different CSFs in the different phases and sub phases. They use

a two case methodology of a failed ERP implementation in one organization

and a successful one in another to establish their model. They emphasize the

need for “further studies of ERP systems to validate and extend the particular

CSFs that are important in each PPM phase” (pp302).

This then is the motivation for this case study. We attempt to

understand the CSFs in greater detail –beyond mere words and articulation to

how they are interpreted by the users whom they impact. We follow the Parr

and Shanks (2000) two case methodology with the difference that both the

failed and successful implementations are in the same organization. We also

focus on the first two phases of the PPM model, viz., planning and project.

4.3 HYPOTHESIS DEVELOPMENT

In this case study we address the following questions:

1. Why do ERP projects fail?

2. What are the factors that lead to a troubled ERP project

resulting in poor acceptance by users?

3. What changes in these factors would alter the course of the

ERP project in gaining greater user acceptance?

Dissatisfaction in ERP projects comes from a perceived gap

between expected and actual benefits. Expectations-Confirmation theory

posits that expectations, coupled with perceived performance, leads to post-

purchase satisfaction. If a product outperforms expectations (positive

disconfirmation) post-purchase satisfaction will result. If a product falls short

of expectations (negative disconfirmation) the consumer is likely to be

dissatisfied (Oliver 1977). If during the goal setting and scoping stage, high

78

expectations are raised, likelihood of the product falling short of expectations

is high: If the gap is large, theory tells us that this would lead to “negative

disconfirmation” and therefore dissatisfaction. Our first hypothesis therefore

is:

H1 - High expectations negatively impact ERP success

An ERP project is “…perhaps the world’s largest experiment in

business change” (Davenport 1998). Lewin’s model of change posits that

change management in organizations moves through three stages

“Unfreezing”, “Change” and “Refreezing”. Internal resistance to the new way

of working happens during critical phases of Unfreezing and Change. During

this phase top management’s visible advocacy of the project , a shared vision

of change, role of internal change agents (champions) become important and

determines the future acceptance or otherwise of the proposed change.

ERP being a change project if the support and direction from top

management is weak, then theory tells us that the “Unfreezing” and “Change”

phases could face problems leading to the ERP not being accepted by users.

Top management support is evidenced by (a) senior management leading by

example (b) allocation of resources as needed on time (c) repeated

communications on the importance of project (d) inter-departmental/process

conflict resolution and (d) continual monitoring and redirecting through an

effective steering committee process. The users see these as evidence that top

management is strongly backing the ERP project. In line with this our next

hypothesis is:

H2: Top management support would be seen as real only if it is

manifest in specific actions and sustained throughout the project.

Structuration theory provides us with an overarching view of the

interaction of the technology (ERP artifact) with the existing social structure

79

of an organization. Originally proposed by Giddens (1979) and developed as

adaptive structuration theory (Poole and De Sanctis 1990), these models

explore “how people (in organizations), interact with a technology in their

ongoing practices, (and) enact structures (rules, practices etc.) which shape

their emergent and situated use of that technology...” (Orlikowski 2000,

pp 404).

This theory relates to the existing social structures in the company-

“Structure here is understood as the set of rules and resources instantiated in

recurrent social practice” (Orlikowski 2000, pp 406). These would include the

roles, reporting relationships, the power and authority of the various role

holders in an organization. These are embodied in the legacy systems of the

company which “encapsulate the existing business processes, organization

structure, culture...” (Holland, Light and Gibson, 1999 pp 31). An ERP with

its revised work flows could alter the existing business processes and

therefore would encounter resistance as per Interaction theory. “…resistance

–generating conditions (are defined) as mismatch between patterns of

interaction prescribed by the system and the patterns that already exist”

(Markus 1983, pp 438)

So structuration theory seen along with interaction theory would

suggest that the existing structures embodied in the well entrenched legacy

system will offer greater resistance to work flows dictated by the ERP . We

therefore frame the hypothesis:

H3: A strong and well entrenched legacy system negatively

influences the adoption of an ERP system.

4.4 CASE STUDY METHODOLOGY

In this section we explore qualitative research as used in IS studies.

Both quantitative and qualitative research are based on some underlying

80

assumptions regarding what is 'valid' research and which research methods

would be most appropriate. Let us look at these core assumptions.

Looking at the underlying epistemology which guides the research,

Guba and Lincoln (1994) suggest four underlying "paradigms" for qualitative

research: positivism, post-positivism, critical theory, and constructivism.

Orlikowski and Baroudi (1991), suggest three categories - positivist,

interpretive and critical. While these three categories are philosophically

distinct, often there is a need to accommodate various aspects of the three in

one study.

Qualitative research could be (a) positivist ( where there are formal

hypothesis, quantification of variables, testing, and the drawing of inferences

from the sample to a stated population) (b) Interpretive ( where inferences are

drawn based on an understanding of the social context of the phenomena

under study : how the IS artifact influences the organizational context and is

also influenced by the context ) and (c) Critical ( an approach that looks at the

interplay of forces of opposition, and conflicts with those that are

emancipatory – in the organizational context this would look at the

reinforcing cycles of change along with the balancing or countering forces

and seek meanings from them).

It follows from this that the choice of a specific qualitative research

method (such as the case study method) is independent of the underlying

philosophical position adopted. For example, case study research can be

positivist, interpretive, or critical, just as action research can be positivist,

interpretive or critical.

Case study research has been used in Information Systems research

for the last three decades (Benbasat et al 1987, Lee 1989, Yin 1993, Keil

1995, Markus 1983). It is an appropriate methodology because ERP is an

81

example is an artifact that cannot be studied outside the context in which it is

deployed. Being dynamically reconfigurable an ERP system “emerges” as it

were in an organization through repeated use and interpretation by users.

Structuration theory posits that “…structures of technology use are

constituted recursively as humans regularly interact with certain properties of

a technology and thus shape the set of rules and resources that serve to shape

their interaction…” (Orlikowski 2000 pp 407). The context therefore, defines

the ERP. Hence a case study approach is appropriate to study issues related to

ERP implementations in organizations.

This paper follows the scientific methodology suggested for case

study research (Pare 2001, Yin 1993). The four important issues in a case

study research are (a) framing of the research question (b) a priori

specification of constructs /theory/hypothesis (c) definition of unit of analysis

and (d) selection of cases for study (Pare 2001). We discuss each of these:

4.4.1 Defining the Unit of Analysis

The units of analysis chosen for this study are the ERP projects 1 &

2 of ABC Corporation. ERP 1 refers to the first implementation project of

Oracle Applications 10.4 in a division of ABC Corporation. ERP 2 refers to a

fresh implementation of Oracle Applications 11i in the same division. To

understand the context of the implementation, a prequel, representing the two

years prior to the start of ERP 1 is also included. Although this prequel period

is outside the boundary of the unit of analysis, during this period a strong

legacy system was built and internalized at ABC Corporation’s division. We

have included this as our hypothesis states that this legacy system has an

influence in the success or otherwise of the ERP project to follow.

Cases for study need to be: (a) revelatory (“when an investigator

has an opportunity to observe and analyze phenomena previously inaccessible

82

to scientific investigation”) (Pare, 2001 pp13) (b) Unique or (c) Critical to

testing the theory. Furthermore case study choices should provide

opportunities to replicate and generalize the study.

The cases chosen by us are “revelatory” as the researcher was

personally involved in ERP 1 as a project manager and in ERP 2 as an

observer. “…participant –observation makes the researcher into an active

participant in the events being studied”. This provides “some unusual

opportunities for collecting data” but could also be problematic … “as the

researcher could well alter the course of events…” Pare (2001, pp16). This

drawback is addressed as the researcher is looking at the events that unfolded

years back in retrospect and has the advantage of seeing the events in

perspective. Detailed notes of the events made by the researcher also helped

in this process.

In addition, we had access to a detailed post completion audit done

of ERP 1 before the start of ERP 2 by a separate team. This provides an

excellent third party perspective of the events prevailing, the problems

encountered, and the results achieved with a causal analysis. This proved

invaluable in revalidating the impressions recorded in the notes of the

researcher.

The choice of case studies also satisfies the condition of criticality -

meeting the necessary conditions for testing our hypothesis. The organization

remains the same, top management and management team is largely the same;

the ERP under implementation is an enhanced version of the same ERP; the

changes are related to the differences in top management support, change

management initiatives, expectations management –all of which are the

hypothesis under test. Hence the choice of cases affords an opportunity to test

replicability of findings.

83

4.4.2 Data Collection and Analysis Methods

The data for the case was gathered over a six month period as

follows. :

1. Study of personal notes made by the researcher who was a

project manager during the implementation of ERP1.

2. Detailed discussions with the erstwhile project manager of the

ERP 2 project-specifically focusing on the differences in ERP1

and ERP2.( the concerned project manager was a team lead in

the ERP1 project and therefore could make the comparisons)

3. Face to face semi-structured interviews with users representing

different user groups: (1) President and Business Head (2)

CFO, Materials manager, Marketing Manager (3) Sales

Coordination executive (4) Production manager and production

executive representing manufacturing (5) IT implementation

staff.

4. 10 users representing three different user cohorts: Strategic

users (business head/senior management) Operational users

(materials, sales, finance staff) and Technical (IT staff,

database administrators) responded to a structured

questionnaire which captured impressions of the respondents

on the strength and presence of various factors during the

implementation on a 7 point Likert scale with end values:

7= Completely Agree and 1= Completely Disagree. It also

checked the overall satisfaction level with the ERP on a 7 point

Likert scale with similar end values.

84

5. We studied a post completion audit report of ERP1 that was

prepared by a cross functional team. This audit report was

prepared prior to the start of ERP2. This report was exhaustive

and made a very good causal analysis of the issues resulting in

a failed implementation.

4.5 THE CASE STUDIES: ERP IMPLEMENTATION AT ABC

CORPORATION

The case studies relate to ABC Corporation, a technology driven

process industry based in India with over 2000 employees, over a 100

industrial customers, and a supplier base spread all over the country as well

as overseas. Computerized accounting systems were introduced at ABC

Corporation in early part of the eighties.

In the early nineties, a FOXPRO based accounting system was

developed by, a company IT team. Data was captured in a batch mode, from

the various departments of the company and updated daily into the standalone

accounting system. Modules for stores/inventory, sales, purchase and payroll

were added -each stand-alone, feeding into the accounting system through

batch updating. To overcome the problem disparate databases, the FOXPRO

system was replaced with an (Relational Data Base Management System)

RDBMS system using INGRES1. The various modules were linked, creating

the first semblance of a future enterprise wide system.

In the years 1993 to 1995 the legacy system grew in functionality

and was used for all transaction processing. The internal EDP department

maintained the same, often going out of the way to accommodate requests

1 INGRES was one of the earliest RDBMS systems available in the early nineties fromIngres Corporation

85

from the users for newer and newer reports and functionality. The demands

from the users often exceeded the capacity of the internal EDP department to

meet.

With the opening of the Indian economy in the early nineties ABC

Corporation had the vision of becoming a world class player in its business

domain. The company appointed an international consultant to carry out a gap

analysis to study if the existing IT system was ready to meet information

needs of the future. They wanted the consultant to answer the following

questions:

1. What were the weaknesses of the current IT system of the

company?

2. What changes should be made to align the Information System

to the business vision of ABC to become a world class

company?

The consultant team after a detailed study recommended that the

company phase out legacy systems and go for an ERP. A detailed exercise

was carried out to select the ERP. The choices were between SAP, JD

Edwards, Oracle Applications and Ramco Marshal.2 Oracle Applications was

chosen as it had a local support office, met the required functionality, had

another reference site and was competitively priced. The implementation was

planned at the largest division of the company. It was decided that after

successful implementation at one location, the same could be rolled out to the

other locations easily. The chronology of the ERP projects at ABC

Corporation is given in Table 4.1.

2 An Indian ERP that was gaining in popularity

86

Table 4.1 ERP Project chronology

1993 -1995 (Background Phase) 1996 -1998 (ERP 1)

Even

ts

FOXPRO based accounting system developed by internalteam - replaced with INGRESS based integrated system.

Legacy system gets well entrenched through repeated use –

allows “maverick” practices.

ERP 1 -project commenced ; Top management not fully aware of thecomplexity of ERP project;No dedicated user teamsSteering committee formed – but meets infrequently; Top management

visible support wanesHigh expectations from ERP as projected by consultant oversells ERPbenefits

ERP Implementation continues- legacy system still in use inpocketsNo reduction in staff- in fact increase in some areas due toincreased data entry load

Only very limited drill down available due to different systems –legacy and ERP

Co

nse

q-

uen

ces

Information needs grow; delays in financial closure ofbooks;

ABC has the vision of becoming world class – - not sure ifthe information system is geared up for future needs.

At the end of 8 months :ERP project delays-project cost escalates

Many system difficulties encounteredSevere resistance to ERP best practices –reluctance to changeentrenched practices

Additional work load as ERP as well as legacy system workconcurrently.

Reconciliation problems continueVery low level of user acceptance

acti

on

/

decis

ion

s International consultant asked to study ABC’s IT strategy.Consultant recommends migration to an ERP system fromthe legacy system.

Decision to continue with implementation effortsDecision to revert back to the legacy system for Manufacturing

Conclusion: ERP Project is a failure: Decision: take stock andre-look at total project. A third party project audit was carried out.Findings: re-implement ERP ( newer version 11i) with a new

methodology/new implementation partner

2000 2001 and beyond

Even

ts

ERP 2 –Migration to Oracle 11i; The project charter simple

: goal of re-implementing Oracle 11iPresident takes ERP as personal KRA. Steering committeemeets at least once a month; Multi functional team with-

dedicated team- project led by CFO. Core users identified ;Project champion designated and empowered;Training – “ just in time” ;

Very limited customization – no new reports allowed unlesssanctioned by senior management. A system of notionaldebit of customization costs to the department budget

introduced as a disincentive.

Oracle 11i takes root

Very limited expectations from ERP ( due to earlier bad experience)

Users start to see value in an integrated system

Due to user teams having being full time –much greater understanding

of ERP screen navigation/work around etc.

ERP –Oracle 11i extended to other divisions of the company

The team that implemented the ERP system seen as experts and

extend services to other implementations in the company

Co

nse

qu

en

ces

Visible signs of change in attitudesGreater acceptance levels

Oracle goes live in 6 months

Complete shift from Legacy system; Much greater acceptance byusers;

MIS quality improves ;Greater usage of systems for decision making

Users acceptance of the new ways of working almost completeVisible benefits of ERP- reduction in staff (15 to 20% of

transaction processing staff reduced)Quicker turn round of inventory due to faster order to deliverycycles

Acti

on

/

Decis

ion

s Conclusion: ERP 2 Project is a Success: Decision : Management plans for the next level ofsystems extension to the extended supply chain. Also decides toroll out the ERP to all divisions of the company.

87

4.5.1 Case 1: ERP 1 – Roll out of Oracle Apps 10.4

The same international consultant was engaged for implementation.

A project team headed by the IT head was constituted for the ERP project.

The in house team consisted of 3 full time IT resources, 5 user members (part

time- as departments could not spare resources full time). The consultant team

consisted of a project manager and 5 full time resources (2 technical

consultants and 3 functional consultants). A senior manager was appointed as

project champion.

The project was initiated with a formal “kick off” with the CEO

and top management team emphasizing the importance of the project. The

project followed the standard ERP implementation methodology involving:

(1) Definition (requirement analysis, scoping, creating work plan)

(2) Operational Analysis (Gap analysis, ‘As is’ and “To be” process design)

(3) Solutioning (detailed design, work-around plans) (3) Building

(parameterizing, coding, data migration, testing) (4) Transitioning and (5) Go

live. A steering committee consisting of the IT head as chair and departmental

heads as members was constituted. This committee was mandated to meet

once a month to review the project. Being themselves new to ERP and

perhaps as a means of securing the contract the consultant had raised the

expectations on what the ERP would do for the business. The scope of the

project, therefore, was ambitious (Table 4.2).

From the start ERP1 had problems. Top management showed great

interest at the start of the project but soon this interest started to wane with

competing pressures on everybody’s time. After the “kick off” meeting there

was no formal review of the project. The steering committee met for the first

two months – from the third meeting onwards the attendance for the meetings

started dwindling and altogether stopped after the fourth meeting.

88

Table 4.2 Differences in project goals ERP1 and ERP 2

Goal/Scope ERP 1 ERP 2

Cost US $ X3 US $ Y

Time 9 months from start 6 months

Functionality Seamless integration of

Marketing, sales,

manufacturing, procurement,

inventory and financial

To move from Oracle

10.4 to Oracle 11i

Compliance with ABC ‘s

accounting policy

Use ERPs standard

reports as far as possible;

< 10 % custom reports.

Accuracy 100 % accuracy and timeliness

of business MIS

Nothing specified

Drill down

capability

Drill down capabilities up to

transaction level- “what if”

analysis capabilities

Nothing specified

Information quality Real-time information on

inventories, product

availability, pending orders,

sales, costs etc.

Nothing specified

Ease of use Simple screen navigation;

quick screen refresh (< 3

seconds.);

user-friendly reports .All

approvals of vouchers,

purchase orders online- work

flow to be created to match the

delegation of authority within

the company

Simple screen navigation

– as close to that of

current legacy system as

possible

Enable workflow as per

revised business

processes

Manpower

reduction

As a result of ERP – reduction

in staff of at least 15%

No manpower reduction

goal

3 Amount disguised to ensure confidentiality of commercially sensitive information

89

User team members, not being full time, got busy with their day to

day work and saw the ERP project as an “additional burden”. In key areas, the

participation of user members was poor –the most dispensable junior was

often the choice for serving on the ERP team. This person neither had the

knowledge nor the authority to make process change decisions that were

required in configuring the ERP. There was a lot of resistance from users who

constantly compared the ERP with the existing system. A comment often

heard was:

“why are we spending so much for this (say an accounts

payable report) – our old system already gives it at the click of

a button- in the ERP we need to go through three screens to get

the report – and that too without all the details…”

Problems also started with “localization”- this refers to the ability

of the ERP to handle the country/region specific requirements of taxes/ levies

etc. The legacy system handled all of this perfectly but ERP always seemed a

step behind in addressing these. This necessitated work rounds which were

cumbersome. Another source of resistance to the ERP came from (a)

prevention of maverick behaviour and (b) perceived loss of power. We

explain these in the ensuing paragraphs.

(a) Maverick behaviour: in many operational areas, there were

informal (not officially authorized) practices. For example: purchasing often

asked suppliers to send material without formal purchase orders. These were

then “regularized” at the time of payment; similarly “sales” had a practice of

extending dispatches beyond the close of a period (say quarter or month) –

with predated invoices- to meet month end targets. These practices were

tacitly allowed by the departmental managers . As the ERP did not allow

90

these, users who had been doing this for years resisted the change terming the

ERP as not being “user friendly” .

(b) Perceived Loss of power: ERP work flow changes resulted in

power shift between departments. In the legacy system bill passing was done

by the accounts department. As a best practice it was decided that the

complete accounts payable process would have the procurement department

as the “process owner”. as the ERP provided a robust “three way match”

(between invoice, goods receipt and purchase order) and also provided good

audit trails. This change was resisted by the accounts department who felt that

they had lost the power they had earlier exercised over vendors and the

procurement team by controlling the payment process. The procurement

department happily accepted the changed workflow as they saw the power

shift to them. This caused conflict between departments that manifested in

other areas also.

At the end of 9 months the ERP project costs had exceeded original

estimates of $X Million as hardware had to be upgraded, additional licenses

procured to take care of the revised workflows; non-standard reports/

customizations (to match legacy system functionalities) required additional 12

man months of work. New estimates of cost were twice the original estimate.

The “go –live” happened after 14 months of start. During the first

two weeks there was total chaos. The legacy system had been switched off but

ERP processes still had glitches. Dispatches were delayed as inventory data

was inaccurate. Manufacturing systems were difficult to use. Improperly

trained users could not handle the screens on their own. IT staff and

consultants were running from one user to the other to trouble shoot/train/

help. Customers started complaining of wrong /delayed deliveries.

91

With no other alternative it was decided to switch back the legacy

at least for key “show stopper” processes .The consultant was asked to extend

their contract by another six months. After 24 months the conclusion was that

the ERP project was a failure. ERP was running but in many of the business

processes the legacy system was still continuing in parallel. There was

dissatisfaction at all levels in the company. Commenting on the state of

affairs, a senior manager from accounts put it best. To quote him:

“We had a good reasonably good legacy system... we were told

that the ERP would solve all problems and take us take to the

next level … now after more than a year and a half we find the

ERP is way below our legacy system, and we are putting

efforts to bring it up to our legacy level .. If only we had spent

half the amount of time and money and upgraded the legacy

system we would have been much better…....”

Table 4.3 gives the planned versus actual benefits derived from

ERP 1. The conclusion was that even at this late stage, ABC should consider

abandoning the ERP project and focus on improving the legacy system to

bridge the gaps. This feeling was shared by quite a few other managers. The

company continued with this hybrid solution for another year or so before

deciding to take a complete relook at the whole ERP implementation. By now

Oracle had come out with an upgraded version 11i and this was a good

opportunity to do a reimplementation.

92

Table 4.3 Planned versus Actual benefits of ERP1

Expectations of benefit Practical difficulty Actual benefit

Top Management will be

able to “drill down” to

transaction level

Facility would work only

if all modules

implemented and

perfectly integrated

Very limited drill down

possible. Reports had to

be generated out of the

ERP with Excel –Users

felt that there was no

additional benefit from

ERP

Manpower reduction

(hence cost) would be

reduced to 20% extent

Additional data entry

load and unfamiliar

screen navigation

required additional staff

(ERP forms had many

more fields to be

entered)

No reduction – in fact in

some cases additional

staff was needed to take

care of increased data

entry load.

Users will get reports as

needed

ERP reports looked

different from those they

were familiar with –

standard ERP reports had

a different “look and

feel”

Users found reports to be

cumbersome to use

3 sec screen refresh Due to wrong sizing and

network overload –

system slowed down

considerably.

Screen refresh took a long

time ( 5 -10 seconds)

Additional investments in

upgrading server/memory

were seen as additional

unbudgeted costs

Best practices would be

introduced

Best practices not

acceptable to users as

they were different from

prevailing practices

Users were not familiar

with online approval of

documents and needed

hard copies.

Users felt system was not

“user friendly”

Many easy work practices

in the legacy were

replaced with seemingly

complex steps in the ERP.

Go –live in 9 months Actual go-live after 14

months – stabilization

after 24 months

Huge time and cost

overrun

93

4.5.2 Case 2: ERP 2 - Re-implementation of Oracle Apps 11 i

ERP2, the reimplementation project, was handled very differently.

A post completion audit was conducted to analyze the causes of ERP1 failure.

A causal analysis identified the key causal factors that led to the problem:

Lack of visible management advocacy, inadequate process monitoring and

control and resistance to change from the current way of working came out as

the key reasons. In addition it was felt that the goals of the ERP were

unrealistic and that the implementation consultants had unnecessarily raised

expectations among the users.

Following this analysis the management took up ERP2 with the

following differences in approach:

1. The project goal was simple and realistic (Table 4.2). The key

goal was moving from Oracle 10.4 to Oracle 11i smoothly.

2. Top management decided to demonstrate commitment through

visible actions: (1) The President took the ERP implementation

as his personal Key Result Area (KRA). (2) The CFO was

made as the ERP project manager with the IT department

playing a supportive role. (3) The steering committee, with the

CFO as the chair met every month without fail. During the

initial and final phases the meeting frequency was increased to

once a fortnight.

3. A full time user team, relieved of all other duties, was created

(unlike in ERP1 where the user team worked on the project

part-time). A set of core users per module were identified and

given intensive training. Other users were trained “just in time”

- just before they were expected to use a module. (Note: In ERP

1, training was given well ahead of use. When the module was

94

ready (about 4 to 6 months down the line) to be used most

users had forgotten all that they had learnt).

4. A systematic BPR exercise, led by an expert consultant

involving all, preceded the new implementation. Special care

was taken to address the change management issues. In each

department opinion leaders were identified and tasked with

championing the revised work methods and flows. The issues

of power loss that were felt earlier in ERP 1 were much less as

new work flows had been in place for a year and users had got

used to the new power structures. Moreover through change

management interventions, these issues were tackled as and

when they arose.

5. Wherever possible, attempts were made to integrate legacy data

entry screens into the ERP using Application Program

Interfaces (APIs). This gave the users the comfort of familiar

legacy interfaces while at the same time not diluting the

integrity of the ERP.

Results: Within 6 months the ERP2 went on stream. The “go-live”

was relatively smooth and trouble free. As the users were trained just in time,

they were fresh and very little hand holding was needed. The “core users”

team became a very valuable resource and was able to solve most of the

operational issues. The quality of the MIS improved. With all systems under

ERP, drill down became possible to a large extent. As the expectations were

quite low to begin with, the results exceeded expectations.

The ERP stabilized soon and within the next 12 months the same

was well entrenched in the company. ERP2 was a success. Following this

success the company decided to roll out the ERP to other divisions of the

company.

95

4.6 DISCUSSION, ANALYSIS AND RESULTS

The cases were chosen primarily to illustrate how a change in

operationalizing certain critical success factors brought about a change in

outcome of the ERP project from failure to success. As the organization

remains the same, the ERP is the same and user groups largely remain the

same, it is the different operationalization of the CSFs that has made the

difference. We now discuss the similarities and differences in the two cases

and draw inferences for research and practice.

4.6.1 Case Study Findings – Similarities

Both projects followed the same standard methodology used by

implementation consultants

The ERP package- Oracle Applications, in both cases is the same –

the only difference being the versions -10.4 in the first case and 11i in the

second case. Both cases followed the standard ERP implementation

methodology which involves (1) Definition (scoping, creating work plan) (2)

Operational Analysis (Gap analysis, ‘As is’ and “To be” process design) (3)

Solutioning (detailed design, work-around plans) (3) Build (parameterizing,

coding, data migration, testing) (4) Transitioning and Go live. (see Appendix

5 for the standard AIM methodology used by Oracle)

There is no significant change in top management, users, technical

team between the two projects

Top management in the two cases remains largely the same. The

user community also is largely the same. The technical team for the

implementation from the company’s side was the same. The implementation

partner was different-but both being internationally known firms with

96

established systems, templates and practices we do not see this as a major

differentiating factor.

Top management support, project champion, a priori BPR

(considered as important CSFs) were present in both the projects (at least on

paper at the surface level)

Top management support was understood to be important in both

cases. Both projects started out with a letter from the CEO on the importance

of the project. Steering committees were constituted in both cases. A project

champion was appointed; user teams were constituted and trained. A BPR

exercise was carried out and revised work flows mapped. It must be noted that

at the surface level all the key CSFs appear to have been complied with. We

show in the next section that it is the differences in the manner in which these

are operationalized that seemed to have made the difference in the outcome.

4.6.2 Case Study Findings – Differences

ERP 2 had a much smaller scope and realistic goal when compared

to ERP 1

A key difference is in the scope of the project. While ERP 1 had

very ambitious goals ERP 2 had a much smaller scope, the key goal being the

smooth transition from version 10.4 to 11i (see Table 4.2 for the differences

in scope between the two projects). This goal was understood by all and

accepted as the only benefit to be expected from the ERP.

Top Management support was visible, overt and continued

throughout the course of the project

Although in both cases top management support was available,

there was also a critical difference. In ERP 1 after the initial letter from CEO

97

and the kick-off meeting top management’s attention appeared to have waned.

In ERP 2 however, the president himself took ERP implementation as his

personal KRA. At every occasion the senior management would reemphasize

the importance of ERP. In business review meetings the status of ERP

implementation was the first agenda point. Resources in terms of personnel

(releasing best people from each functional area as full time team members),

additional computer hardware (new terminals, additional RAM memory etc.),

additional training, and visits to other successful sites were sanctioned by top

management.

Unlike in ERP 1 where the IT head was the ERP project manager,

in ERP 2 a senior line manager (the CFO) was made the ERP project head.

This person was very senior in the company, had the authority to sanction

business process changes and had a personal stake in a successful

implementation as his functional area would be the biggest user of the ERP

system.

Importance of the change management and BPR activities

In ERP 2 great care was taken to ensure that the reengineering

efforts had the “buy in” of large sections of the users. This was done through

several rounds of discussions involving all levels of employees, addressing

genuine concerns, allaying fears of loss of power, and above all constant

reinforcing communication. The opinion leaders played a crucial role

throughout the process. A process based structure (as against a function based

structure) with appropriate changes in goals (process goals against department

goals), appropriate changes in compensation structures (rewards on

achievement of group goals) etc. were incorporated.

The ERP with the revised work flows was rolled out only after a

reasonable comfort level on the new ways of working was achieved. In

98

several instances legacy screens were integrated into the ERP to give the users

the comfort of familiar screens.

Project monitoring and control

In ERP 2 the steering actively monitored the project without let up

till the completion of two months after go-live. As the CFO was the project

head (and also the steering committee chair) he was able to ensure full

participation of all the other steering committee members unlike in ERP 1

where the steering committee chair was the IT head who was not as senior in

the organization as the CFO.

A fully functioning steering committee was able to take crucial

decisions on funds allocation, changing work flows as needed and could limit

the extent of customizations in ERP 2 unlike in ERP 1 where there was very

little control on customizations. A disincentive for customization was

introduced by creating a notional debit (to a department’s budget) based on

customization man-days.

Creative use of legacy system

In ERP 1 on “go-live” the legacy system was switched off. This

created havoc and affected dispatches to customers forcing the company to

run the legacy in parallel. In ERP 2 a different strategy was adopted. A hybrid

strategy of introducing the ERP while retaining some crucial legacy screens

was adopted. The APIs available in the ERP were used to ensure that legacy

system data was sent to the appropriate ERP tables. As users got familiar with

the ERP slowly these legacy systems were phased out. The resistance from

users was thus creatively addressed.

99

4.7 HYPOTHESIS TESTING

We had hypothesized: H 1 - High expectations negatively impact

ERP success

Analysis of the cases shows that there were clearly different

expectations from ERP 1 and ERP 2 among the users. In the first

implementation, being new to ERP practice, the consultant inadvertently

raised expectations to a very high degree. For example, detailed “drill down”

capability, reduction in manpower of 20%, 3 second screen response, best

practices introduction were promised (Table 4.3). The actual results for ERP

fell far short.

Result: A large gap between expectations and actual delivery

leading to expectations-disconfirmation and thereby dissatisfaction.

In contrast in ERP 2 everybody including the consultant was wiser.

Coming after a disastrous implementation, the organization went into ERP2

project with little or no expectations. The ERP 2 scope was simple- the key

goal being migration to the latest version Oracle 11i. Furthermore, the users

had “zero” expectations from ERP due to their bad experiences in the past. As

one user succinctly put it

“… anyway the new ERP can’t be worse than the earlier one,

nothing can be worse … as long as it makes my work a little

easier I am satisfied”.

Result: ERP 2 was perceived as a successful implementation by

most users – compared to the failed implementation of ERP1.

We conducted a small empirical study, using a Likert scale with

anchor values of 7= completely agree and 1= completely disagree among a

sample of ten users drawn from diverse areas: Strategic users, operational

100

users and technical users. The results show a marked improvement

(Table 4.4) in satisfaction levels with ERP 2 compared to ERP 1 confirming

our hypothesis that high expectations negatively impact user satisfaction and

conversely low expectations positively impacts user satisfaction.

The next hypothesis H2: Top management support would be seen

as real only if it is manifest in specific actions and sustained throughout the

project.

We next analyze the differences in the nature of top management

support in the two projects. The key difference between the two

implementations with reference to top management support is in actual

actions of management. Although both the projects appear to have the

support of top management in ERP 1 the support was in form only while in

ERP such support was actually manifest in affirmative action (see discussions

on the differences between implementations). This fact is sensed by the users

and the nature of resistance to the ERP therefore varies in the two projects.

The empirical study also shows that the user’s perceptions of top management

involvement in ERP2 is substantially higher (Table 4.4).

Conclusion: Top Management Support is perceived to be real only

if accompanied by actions. Some typical actions that seem to make the

difference are: The president declaring the ERP project as his personal KRA,

visible use of systems by top management, ensuring that the steering

committee functions, allocation of full time resources, empowering the

project champion etc. The evidence of the cases supports the hypothesis.

The next hypothesis: H3: A strong and well entrenched legacy

system negatively influences the adoption of an ERP system

The company had a well entrenched legacy system. The legacy

system incorporated the current practices in the company – and conversely the

101

legacy system practices became the company preferred practices – the ERP

best practices therefore encountered resistance. The legacy system allowed

some amount of “bending” of system – for example the predating of invoices

– which the ERP did not allow. By the time ERP 2 was in place, the legacy

system influence was reduced as in many areas ERP 1 practices had taken

root (Table 4.4). Moreover the change management exercise addressed many

of the issues of power balancing and revised roles and responsibilities.

Conclusion: The facts of the case support the hypothesis that a well

entrenched legacy system negatively influences ERP adoption – only when

legacy system influences are reduced do the ERP best practices gain

acceptance.

Table 4.4 Results of empirical study

(10 respondents diverse stakeholder group)

User cohort (Nos.) ERP 1 ERP 2 Remarks

Q1 :Overall I am satisfied with the ERP that has been implemented

in our organization

Strategic Users (2) 4, 4(*) 6,5

Operational Users (4) 3,2,3,3 5,6,6,5

Technical Users (4) 2,1,2,2 6,7,6,6

Marked shift in

satisfaction levels –

especially among

operational users

Q2: The top management was actively involved and supported the

ERP project from start to finish

Strategic Users(2) 5,5 6,6



Major change in

perception about

Top management in

ERP 2

Q3: A steering committee was formed which met at least once a month,

monitored progress and initiated corrective actions in case of any




Steering committee

was seen to be

functioning very

well in ERP 2.

102

Table 4.4 (Continued)

User cohort (Nos.) ERP 1 ERP 2 Remarks

Q4: There was a project champion who led the project throughout by

providing guidance / building consensus /solving issues




Project champion

was appointed but

not empowered in

ERP 1

Q5: The ERP helps me do my job better when compared to the old (legacy)

system.



Technical Users (4) 3,232,2 6,5,4,6

Legacy system

influence reduced by

the time of ERP 2

(*) responses measured on a Likert Scale: completely agree=7 to completely disagree =1

4.8 IMPLICATIONS

4.8.1 Implications for Practice

In the practice area, management is advised to take care in the

scoping and goal setting process of an ERP implementation. Simple

achievable goals facilitates acceptance. The overall feel-good factor that

follows from achievement of expected goals will allow the management to

push its larger agenda for more fundamental process changes. It is better to

undersell ERP than oversell it. It gets accepted better.

Top Management has a pivotal role in ERP success. This role is

both symbolic as well as substantive. Symbolically top management should

be seen to own the project- as in the case of ERP 2 where the president of the

company takes ERP implementation as his personal Key Result Area (KRA).

Substantively top management has to ensure that best resources are made

available to the project - this means dedicated user teams for the duration of

103

the project, quality time for reviews, funds as needed for up gradation of

computer infrastructure etc.

The role of good project management cannot be reemphasized. A

senior line manager as ERP project head is most desirable. A functioning

steering committee that “steers” the project throughout its course is vital for

success. The steering committee has a key role in addressing issues that are

bound to come up quickly and decisively. An important decision involves

customization a major cause of cost and time delays. Users must be

encouraged to use ERP standard practices and reports. At ABC Corporation a

disincentive for customization was created. A notional cost debit (based on

estimated man days) was made to a department’s budget for every

customization request. This worked in curbing customizations.

4.8.2 Implications for Research

Our study extends the work of Parr and Shanks (2000). It follows a

similar two case methodology of an unsuccessful implementation followed by

a successful one in a new and important ERP market-India. It establishes the

value of scientific case studies in drawing important lessons for research and

practice. It differs from the work of Parr and Shanks in that the two

implementations are in the same organization separated in time. Thus it is

closer to a controlled experiment when compared to the earlier work. Further

it explores the effect of one of the key CSFs at the planning stage, the scoping

process. This was not covered in depth in the earlier research which primarily

focused on the implementation stage.

Our research has identified some key constructs that seem to impact

ERP implementation outcomes. For example, we have shown that top

management support is actually a composite of several other CSFs like full

time user teams allocation, personal example, empowering a champion etc.

104

All these together constitute a latent construct which could be called

Leadership the dimensions of which exceed what is generally understood as

top management support. Similarly all the other issues of managing the

implementation process like scope management, change management etc.,

would map to another latent construct –Process. These constructs represent

better ways of classifying the CSFs and future research could develop

measurement scales for these which could be used as predictive ex ante

indicators for ERP outcomes.

Our research had some limitations. The events of the case happened

at a time when ERP and computerization were in their infancy in India.

Perhaps with time and greater familiarity some of the issues that impacted the

project may not be as relevant today as it was then. But we believe the

learning is still relevant.

CHAPTER 4 CASE STUDY –LEARNING FROM...

Documents

Transcript of CHAPTER 4 CASE STUDY –LEARNING FROM...