learning from a failed erp- indian

7/30/2019 Learning From a Failed ERP- Indian

1/21

Learning from a failedERP implementation: a case

study researchC. Venugopal and K. Suryaprakasa Rao

Anna University, Chennai, India

Abstract

Purpose Enterprise resource planning (ERP) projects failing to meet user expectations is a causefor concern as it often leads to considerable time and money losses. The purpose of this paper is tounderstand the causal factors for such failures in the Indian context.

Design/methodology/approach A scientific case study research methodology was followed. Theunit of analysis: a failed ERP project followed by a successful one in the same organization. Data were

collected through interviews, observation and study of archival documents. Analysis was methodicaland validated through a triangulation approach.

Findings The results suggest that it is the manner in which key critical success factors (CSFs)such as top management support are operationalized; good project management; a smaller scope and ahybrid approach of integrating the legacy system with the ERP that facilitates adoption and leadsto a succesful implementation.

Research limitations/implications The study extends the work of earlier researchers in a newmarket India. It identifies important constructs, composites of existing CSFs, which future researchcould measure as ex ante predictors of ERP project success.

Practical implications The authors offer several guidelines related to the role of topmanagement, the importance of simplicity of scope, change management steps all of whichwould help implementation teams better manage projects.

Originality/value The two case methodology of a failed implementation followed by a successfulone in the same organization is unique, in the Indian context. This is the closest to a controlledexperiment one can have in case study research. The findings pave the way for the development ofpredictive instruments of ERP project outcomes.

Keywords India, Enterprise resource planning, Critical success factors, Project management

Paper type Research paper

IntroductionEffective implementation of IT projects, of which enterprise resource planning(ERP) systems is a subset has become important for modern businesses. Althoughproject management methods have evolved over time, the track record of IT projectimplementations remains poor and project success rates may have actually regressed

(Standish Group Chaos report, 2009). Although the reference is to all IT projects,the situation related to ERP implementations is no better.

In this paper we ask the question: Why do ERP projects fail? A body of literatureattempts to addresses this issue by identifying critical success factors (CSFs) which aredefined as those critical areas where things must go right for the project to succeed(Rockhart, 1979). These CSFs are a descriptive list of conditions that lead toimplementation success or failure (Bussen and Myers, 1997). But an examination ofsuch literature spanning the last three decades reveals that there are several hundred

The current issue and full text archive of this journal is available at

www.emeraldinsight.com/1753-8378.htm

IJMPB4,4

596

International Journal of ManagingProjects in BusinessVol. 4 No. 4, 2011pp. 596-615q Emerald Group Publishing Limited1753-8378DOI 10.1108/17538371111164038


2/21

CSFs identified; different researchers have defined the same CSF differently; there areinternal contradictions on what constitutes a particular CSF (Chua and Lim, 2009).So much so that the large list of CSF has become unwieldy and is even criticised asbeing just a laundry list (Richmond, 1993 quoted in Akkermans and Helden, 2002).

If CSFs have to be useful there is a need to understand them better especially the wayin which they operate and influence outcome.

We use a case study research approach to examine this problem. Case study researchhas been used in information systems research for the last three decades (Markus, 1983;Benbasat et al., 1987; Lee, 1989; Yin, 1993; Keil, 1995; Parr and Shanks, 2000; Chua andLim, 2009). ERP by its nature is dynamically reconfigurable and therefore emerges inan organisation through repeated use and interpretation by its users (Orlikowski, 2000).ERP is, therefore, best studied in the context of its implementation and use hence the casestudy approach.

In this paper, we report on two case studies relating to different ERP implementationsin 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 countryas well as overseas. The cases were selected because the first was, in terms of useracceptance and other measures, a failure and the second a success. The lessons learntfrom the first failed implementation led to a change in implementation strategy for thesecond which finally led to success. We believe there are lessons to be learnt both fromthe failure and from the later success both for research and practice. Being from the sameorganization with no major changes in either the ERP or the management and userteams, a comparative study gives an opportunity to zero in on those causal variables thatseem to make a difference.

In this paper, we first review extant literature on CSFs for ERP success and concludethat there is a need to understand the causal mechanisms through which they operate.We then look at theories from the social sciences that have in the past been used to

understand the adoption of new technologies to see if they would throw light ofthe mechanisms through which CSF operate. We then present the cases, listing thechronology of events highlighting the similarities and differences and analyse the effectof the differences on the outcome of the ERP implementation. We conclude the paperwith a detailed discussion on the findings, limitations of the study and suggestguidelines for practice and areas for continuing research.

CSFs for ERP project outcomesResearchers have looked at the possible causal factors that could influence ERP projectoutcomes. Davenport (1998) identifies six factors, mostly relating to the directional orstrategic aspects of an ERP project. This includes factors related to top management

support, use of a cross functional steering committee, communication, cross functionalimplementation teams, etc.

An often cited and comprehensive list of CSFs is that of Somers and Nelson (2001)who identifies a set of 22 CSFs. Their study examined existing literature and this wasfollowed by an empirical study covering 86 medium to large organizations who hadimplemented ERPs. They used the Cooper and Zmuds (1990) six-stage model of ITimplementation to track the importance of different factors across the six stages of:initiation, adoption, adaptation, acceptance, routinization and infusion.

Learning froma failed ER

implementatio

59


3/21

Hong and Kim (2002) stress on the organization preparedness aspects of theimplementation namely organizational fit, system adaptation levels, resistance tochange, 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 similaritieswith an ERP project it is complex, it has pan-organization linkages, and changemanagement issues are involved.

CSF literature is also not without its critics. Robey et al. (2002) criticize the CSFresearch as being based on variance models (rather than process models) without therigour of a supporting theoretical base that could throw light on reasons for theoutcomes.

Chua and Lim (2009) analyse CSF literature and point out to the contradictions andfragmented nature of the studies. The CSFs listed vary across studies, the operationaldefinitions are different, several important causal factors like change management aremissing from some lists, etc. The researchers believe because CSF research has:

[. . .] emphasized identifying CSFs linked to project success at the expense of a more thoroughexploration of the causal mechanisms connecting organizational actions and processes toproject success. In other words, CSF research has focused on what CSFs look like,but overlooked how and why they become critical (p. 2).

Parr and Shanks (2000), studying ERP implementation propose a project phase model(PPM) consisting of three distinct phases: planning, project and enhancement. The PPMmodel synthesises earlier ERP implementation models: Bancroft et al. (1998), Ross (1998)and finally the Markus and Tanis (2000) model which primarily focuses on pre andpost implementation steps bundling the implementation phase into one category. Whilerecognising the importance of the planning phase and post-project phases, PPMfocuses on the project phase which they subdivide into set up, reengineering, design,

configuration/testing and installation. They then identify the relative importance ofdifferent CSFs in the different phases and sub phases. They use a two case methodologyof a failed ERP implementation in one organization and a successful one in another toestablish their model. They also emphasise: further case studies of ERP systemsimplementation are required in order to validate and extend the particular CSFs that areimportant in each PPM phase (p. 302).

This then is the motivation for this research. We attempt to understand the CSFs ingreater detail beyond mere words and articulation to how they are interpreted by theusers whom they impact. We follow the Parr and Shanks (2000) two case methodologywith the difference that both the failed and successful implementations are in the sameorganization. We also focus on the first two phases of the PPM model, viz., planningand project.

Framing of the research questionIn this case study we address the following questions supplementary to the Metaquestion Why do ERP projects fail? What are the factors that lead to a troubled ERPproject resulting in poor acceptance by users? What changes in these factors wouldalter the course of the ERP project in gaining greater user acceptance?

An area of dissonance and dissatisfaction in ERP projects comes from a gap betweenexpected and actual benefits from the implementation. Expectations-Confirmation

IJMPB4,4

598


4/21

theory posits that expectations, coupled with perceived performance, lead to post-purchase satisfaction. If a product outperforms expectations (positive disconfirmation)post-purchase satisfaction will result. If a product falls short of expectations (negativedisconfirmation) the consumer is likely to be dissatisfied (Oliver, 1977). If during the goal

setting and scoping stage, high expectations are raised, the likelihood of the productfalling short of expectations is high: If the gap is large, theory tells us that this would leadto negative disconfirmation and therefore dissatisfaction. Our first hypothesis wewould test therefore is:

H1. High expectations negatively impact ERP success.

An ERP project is [. . .] perhaps the worlds largest experiment in business change(Davenport, 1998). Lewins model of change posits that change management inorganizations moves through three stages Unfreezing, Change and Refreezing.Internal resistance to the new way of working happens during critical phases ofUnfreezing and Change. During this phase top managements visible advocacy of theproject, a shared vision of change, role of internal change agents (champions) becomeimportant and determines the future acceptance or otherwise of the proposed change.

ERP being a change project if the support and direction from top managementis weak, then theory tells us that the Unfreezing and Change phases could faceproblems leading to the ERP not being accepted by users. Top management support isevidenced by:

. senior management leading by example;

. allocation of resources as needed on time;

. repeated communications on the importance of project;

. inter-departmental/process conflict resolution; and

. continual monitoring and redirecting through an effective steering committee

process.

The users see these as evidence that top management is strongly backing the ERPproject. In line with this our next hypothesis is:

H2. Top management support would be seen as real only if it is manifest inspecific actions and sustained throughout the project.

Structuration theory provides us with an overarching view of the interaction of thetechnology (ERP artefact) with the existing social structure of an organisation.Originally proposed by Giddens (1979) and developed as adaptive structuration theory(Poole and De Sanctis, 1990), these models explore how people (in organisations),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, p. 404).

This theory relates to the existing social structures in the company: Structure here isunderstood as the set of rules and resources instantiated in recurrent social practice(Orlikowski, 2000, p. 406). These would include the roles, reporting relationships, thepower and authority of the various role holders in an organization. These are embodiedin the legacy systems of the company which encapsulate the existing businessprocesses, organization structure, culture [. . .] (Holland, Light and Gibson, 1999, p. 31).


implementatio

599


5/21

An ERP with its revised work flows could alter the existing businessprocesses and therefore would encounter resistance as per Interaction theory: [. . .]resistance generating conditions (are defined) as mismatch between patterns ofinteraction prescribed by the system and the patterns that already exist (Markus,

1983, p. 438).So structuration theory seen along with interaction theory would suggest that the

existing structures embodied in the well entrenched legacy system will offer greaterresistance to the work flows dictated by the ERP system. We therefore frame thehypothesis:

H3. A strong and well entrenched legacy system negatively influences theadoption of an ERP system.

MethodologyThis paper follows the scientific methodology suggested for case study research(Pare, 2001; Yin, 1993). The four important issues in a case study research are:

(1) framing of the research question;

(2) a priori specification of constructs/theory/hypothesis;

(3) definition of unit of analysis; and

(4) selection of the cases for study (Pare, 2001).

We discuss each of these.

Defining the unit of analysisThe units of analysis chosen for this study are the ERP projects 1 and 2 of ABCCorporation. ERP1 refers to the first implementation project of Oracle Applications[1]10.4 in a division of ABC Corporation. ERP2 refers to a fresh implementation ofOracle Applications 11i in the same division. To understand the context of theimplementation, a prequel, representing the two years prior to the start of ERP1 is alsoincluded. Although this prequel period is outside the boundary of the unit of analysis,during this period a strong legacy system was built and internalised atABC Corporations division. We have included this as our hypothesis states thatthis legacy system has an influence in the success or otherwise of the ERP project tofollow.

Cases for study need to be:. revelatory (when an investigator has an opportunity to observe and analyse

a phenomena previously inaccessible to scientific investigation) (Pare, 2001,p. 13).

. unique; or

. critical to testing the theory.

Furthermore, case study choices should provide opportunities to replicate andgeneralise the study.

The cases chosen by us are revelatory as the researcher was personally involved inERP1 as a project manager and in ERP2 as an observer. [. . .] participant observationmakes the researcher into an active participant in the events being studied.

IJMPB4,4

600


6/21

This provides some unusual opportunities for collecting data but could also beproblematic [. . .] as the researcher could well alter the course of events [. . .] Pare (2001,p. 16). This drawback is addressed as the researcher is looking at the events that unfoldedyears 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 ERP1 before the

start of ERP2 by a separate team. This provides an excellent third-party perspective ofthe events prevailing, the problems encountered, and the results achieved with acausal analysis. This proved invaluable in revalidating the impressions recorded in thenotes of the researcher. The choice of case studies also satisfies the condition ofcriticality-meeting the necessary conditions for testing our hypothesis. The organisationremains the same, top management and management team is largely the same; theERP under implementation is an enhanced version of the same ERP; the changes arerelated to the differences in top management support, change management initiatives,expectations management all of which are the hypothesis under test. Hence the choiceof cases affords an opportunity to test replicability of findings.

Data collection and analysis methodsThe 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 managerduring the implementation of ERP1.

(2) Detailed discussions with the erstwhile project manager of the ERP2project-specifically focussing on the differences in ERP1 and ERP2 (theconcerned project manager was a team lead in the ERP1 project and thereforecould make the comparisons).

(3) Face-to-face semi-structured interviews with users representing different usergroups:. president and business head;. CFO, materials manager, marketing manager;. sales coordination executive;. production manager and production executive representing manufacturing;

and. IT implementation staff.

(4) 10 users representing three different user cohorts: strategic users (businesshead/senior management); operational users (materials, sales, finance staff); andtechnical (IT staff, database administrators) responded to a structuredquestionnaire which captured impressions of the respondents on the strength

and presence of various factors during the implementation on a seven-pointLikert scale with end values: 7 completely agree and 1 completely disagree.It also checked the overall satisfaction level with the ERP on a seven-pointLikert scale with similar end values.

(5) We studied a post-completion audit report of ERP1 that was prepared by across-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 issuesresulting in a failed implementation.


implementatio

60


7/21

The case studies: ERP implementation at ABC corporationThe case studies relate to ABC Corporation, a technology driven process industrybased in India with over 2,000 employees, over a 100 industrial customers, and asupplier base spread all over the country as well as overseas. Computerized accounting

systems were introduced at ABC Corporation in early part of the 1980s.In the early 1990s, a FOXPRO-based accounting system was developed by,

a company IT team. Data were captured in a batch mode, from the various departmentsof the company and updated daily into the standalone accounting system. Modules forstores/inventory, sales, purchase and payroll were added each stand-alone, feedinginto the accounting system through batch updating. To overcome the problem disparatedatabases, the FOXPRO system was replaced with an relational data base managementsystem (RDBMS) using INGRES[2]. The various modules were linked, creating the firstsemblance of a future enterprise wide system.

In the years 1993-1995, the legacy system grew in functionality and was used for alltransaction processing. The internal EDP department maintained the same, oftengoing out of the way to accommodate requests from the users for newer and newerreports and functionality. The demands from the users often exceeded the capacity ofthe internal EDP department to meet.

With the opening of the Indian economy in the early 1990s ABC Corporationhad the vision of becoming a world class player in its business domain. The companyappointed an international consultant to carry out a gap analysis to study if theexisting IT system was ready to meet the information needs of the future. They wantedthe consultant to answer the following questions:

. What were the weaknesses of the current IT system of the company?

. What changes should be made to align the information system to the businessvision of ABC to become a world-class company?

The consultant team after a detailed study recommended that the company go for anERP system. A detailed exercise was carried out to select the ERP. The choices werebetween SAP, JD Edwards, Oracle Applications and Ramco Marshal[3]. OracleApplications Version 10.4 was chosen as it had a local support office, met the requiredfunctionality, had another reference site and was competitively priced. Theimplementation was planned at the largest division of the company. It was felt thatthat after successfully implementating ERP at one location, roll out to the other locationswould be much easier. The chronology of the ERP projects at ABC Corporation isgiven in Table I.

Case 1: roll out of Oracle applications 10.4 at ABC Corporation-(ERP1)The same international consultant was engaged for the implementation. A project team

headed by the IT head was constituted for the ERP project. The in house team consistedof three full time IT resources, five user members (part time as the departments couldnot spare resources full time). The consultant team consisted of a project managerand five full time resources (two technical consultants and three functional consultants).A senior manager was appointed as the project champion.

The project was initiated with a formal kick off with the CEO and top managementteam emphasising the importance of the project. The project then followed the standardERP implementation methodology involving:

IJMPB4,4

602


8/21

1993-1995 (backgroundphase) 1996-1998 (ERP1)

Events FOXPRO-basedaccounting systemdeveloped by internalteam-replaced withINGRESS based integrated(sales/inventory, purchase,accounting) system

ERP1 projectcommenced ERP implementationcontinues legacy systemstill in use in pockets

Legacy system gets wellentrenched throughrepeated use allowsmaverick practices

Top management not fullyaware of the complexity ofERP project

No reduction in staff- infact increase in some areasdue to increased data entryload

No dedicated user teams Only very limited drilldown available due todifferent systems legacy

and ERPSteering committee formed but meets infrequentlyTop management visiblesupport wanesHigh expectations fromERP as projected byconsultant oversells ERPbenefits (Table II)

Consequences Information needs grows/delays in financial closureof books

At the end of eight months:ERP project delays projectcost escalates

Additional work load asboth systems workconcurrently

ABC has the vision ofbecoming world class

not sure if the informationsystem is geared up forfuture needs

Many system difficultiesencountered

Reconciliation problemscontinue

Severe resistance to ERPbest practices reluctanceto change entrenchedpractices

Very low level of useracceptance

User dissatisfactionmanifest

Managementaction/decisions

International consultantasked to study ABCs ITstrategy

Decision to continue withimplementation efforts (Note: classic case ofproject escalation Keil(1995)). Decision to revertback to legacy system formanufacturing

Conclusion: ERP project isa failure : decision to takestock and re-look at totalproject. A third part projectaudit carried out usingTQM problem solvingmethods

Consultant recommendsmigration to an ERP

Findings: re-implementERP (newer version 11i)with a new methodology/new implementationpartner

(continued)

TableABC Corporation ER

Project chronolog


implementatio

60


9/21

.

definition (requirement analysis, scoping, creating work plan); operationalanalysis (Gap analysis, As is and To be process design);

. solutioning (detailed design, work-around plans);

. building (parameterizing, coding, data migration, testing);

. transitioning; and

. go live.

1993-1995 (backgroundphase) 1996-1998 (ERP1)

2000 2001 and beyondEvents ERP2 Migration to

Oracle 11iOracle 11i takes root ERP Oracle 11i extended

to other divisions of thecompany

ERP2 project charter:simple goal of re-implementing Oracle 11i

Very limited expectationsfrom ERP (due to earlierbad experience)

The team that implementedthe ERP system seen asexperts and extend servicesto other implementations inthe company

President takes ERP aspersonal KRA. Steeringcommittee meets at leastonce a month

Users start to see value inan integrated system

Multi functional team with-

dedicated team- project ledby CFO. core usersidentified; projectchampion designatedTraining just in time;very limited customisation

Owing to user teams

having being full time much greaterunderstanding of ERPscreen navigation/workaround, etc.

Consequences Visible signs of change inattitudes

Complete shift from legacysystem; much greateracceptance by users

Users acceptance of thenew ways of workingalmost complete

Greater acceptance levels MIS quality improves Visible benefits of ERP-reduction in staff (15-20percent of transactionprocessing staff reduced)

Oracle goes live in six

months

Greater usage of systems

for decision making

Quicker turn round of

inventory due to fasterorder to delivery cycles

Managementaction/decisions

Conclusion: ERP2 Project isa success: managementplans for the next level ofsystems extension to theextended supply chain.Also decides to roll out theERP to all divisions of thecompanyTable I.

IJMPB4,4

604


10/21

A steering committee consisting of the IT head as chair and departmental heads asmembers was constituted. This committee was mandated to meet once a month toreview the project. Being themselves new to ERP and perhaps as a means of securing thecontract the consultant had raised the expectations of management on what the ERP

would do for the business. The scope of the project, therefore, was ambitious (Table II).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 oneverybodys time. After the kick off meeting there was no formal review of theproject. The steering committee met for the first two months from the third meetingonwards the attendance for the meetings started dwindling and altogether stoppedafter the fourth meeting.User team members, not being full time, got busy with their day-to-day work and saw theERPprojectas an additional burden.In keyareas, the participation of user members waspoor-the most dispensable junior was often the choice for serving on the ERP team. Thisperson neither had the knowledge nor the authority to make process change decisions thatwere required in configuring the ERP. There was a lot of resistance from users whoconstantly 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 systemalready gives it at the click of a button- in the ERP we need to go through three screens to getthe report and that too without all the details [. . .]

Goal scope ERP1 ERP2

Cost US $ Xa US $ YTime Nine months from start Six monthsFunctionality Seamless integration of Marketing,

sales, manufacturing, procurement,

inventory and financial

To move from Oracle 10.4 to Oracle11i

Compliance with ABCs accountingpolicyCreation of transactions and reports inline with statutory requirements

Accuracy 100 percent accuracy and timeliness ofbusiness MIS

Nothing specified

Drill down capability Drill down capabilities up totransaction level what if analysiscapabilities

Nothing specified

Information quality Real-time information on inventories,product availability, pending orders,sales, costs, etc.

Meeting basic functionalrequirements

Ease of use Simple screen navigation; quickscreen refresh (, 3 secs.); user-

friendly reports. All approvals ofvouchers, purchase orders online-work flow to be created to match thedelegation of authority within thecompany

Simple screen navigation as close tothat of current legacy system as

possibleEnable workflow as per revisedbusiness processes

Manpower reduction As a result of ERP reduction in staffof at least 15 percent

No manpower reduction goal

Note: aAmount disguised to ensure confidentiality of commercially sensitive information

Table IDifferences in proje

goals ERP1 and ERP


implementatio

60


11/21

Problems also started with localization this refers to the ability of the ERP tohandle the country/region specific requirements of taxes/ levies, etc. The legacy systemhandled 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:. prevention of maverick behaviour; and. perceived loss of power.

These are explained below:. Maverick behaviour. In many operational areas, there were informal (not officially

authorised) practices. For example: in purchasing, very often suppliers wereasked to send material without formal purchase orders. These were thenregularised post-facto at the time of bill passing; similarly the sales departmenthad a practice of extending despatches beyond the close of a period (say quarteror month) with predated invoices to meet month end targets. These practices

were tacitly allowed by the departmental managers but were frowned upon bytop management. As the ERP would not allow such practices, users who hadbeen doing this for years resisted the change terming the ERP as not beinguser-friendly.

. Perceived loss of power. ERP best practices brought about some work flowchanges that resulted in power shift between departments. For example, in thelegacy system bill passing was done by the accounts department. As a bestpractice it was decided that the complete accounts payable process from Indentto Payment would have the procurement department as the process owner.As the ERP provided a robust three way match (between invoice, goods receiptand purchase order) and also provided good audit trails, it was felt that the

bill-passing function could completely move to the procurement department bypassing the accounts department. This change was resisted by the accountsdepartment team. They felt that they had lost the power they had earlierexercised over vendors and the procurement team by controlling the paymentprocess. The procurement department happily accepted the changed workflowas they saw the power (to control payment to vendors) shift to them. This causedconflict between departments that manifested in other areas also.

At the end-nine months the ERP project was nowhere near completion. Costs hadalready exceeded the original budget of $X Million as hardware had to be upgraded,additional licences had to be procured to take care of the revised workflows, users hadasked for several additional non-standard reports/customisations (to match legacy

system functionalities) that required additional 12 man months of work. New estimatesof cost were twice the original estimate which top management had no choice but toapprove.

The go live happened after 14 months of start. During the first two weeks therewas total chaos. The legacy system had been switched off and the ERP processes stillhad glitches. Despatches were getting delayed as inventory data were inaccurate.Manufacturing systems were completely unusable. Improperly trained users could nothandle the screens on their own. IT persons and consultants staff was running from

IJMPB4,4

606


12/21

one user to the other to trouble shoot/train/help. Customers started complaining ofwrong /delayed deliveries.

With no other alternative it was decided to switch back the legacy at least for keyshow stopper processes and continue working on the ERP. The consultant was asked

to extend their contract by another six months. After 24 months the conclusion wasthat the ERP project was a failure. The consultant had left the project. ERP wasrunning but in many of the business processes the legacy system was still continuingin parallel. There was total dissatisfaction at all levels in the company. Commenting onthe 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 allproblems and take us take to the next level [. . .] now after more than a year and a half we findthe ERP is way below our legacy system, and we are putting efforts to bring it up to ourlegacy level If only we had spent half the amount of time and money and upgraded the legacysystem we would have been much better [. . .]

The conclusion: ABC should consider abandoning the ERP project and focus on

improving the legacy system to bridge gaps. This feeling was shared by quite a fewother managers. The company continued with this hybrid solution for another year orso before deciding to take a complete relook at the whole ERP implementation. By nowOracle had come out with an upgraded version 11i and this was a good opportunity todo a reimplementation.

Case 2: reimplementation of Oracle Applications 11i at ABC Corporation (ERP2)ABC Corporation approached ERP2 very differently from the way they carried outERP1. A post-completion audit was conducted to analyse the causes of ERP1 failure.A causal analysis identified the key causal factors that led to the problem: lack of visiblemanagement advocacy, inadequate process monitoring and control and resistance tochange from the current way of working came out as the key reasons. In addition it wasfelt that the goals of the ERP were unrealistic and that the implementation consultantshad unnecessarily raised expectations among the users.

Following this analysis the management took up ERP2 with the followingdifferences in approach:

(1) The project goal was simple and realistic (Table II). The key goal was movingfrom Oracle 10.4 to Oracle 11i smoothly.

(2) Top management decided to demonstrate commitment through visible actions:. The President took the ERP implementation as his personal key result area

(KRA).. The CFO was made as the ERP project manager with the IT department

playing a supportive role.. The steering committee, with the CFO as the chair met every month without

fail. During the initial and final phases the meeting frequency was increasedto once a fortnight.

(3) A full-time user team, relieved of all other duties, was created (unlike in ERP1where the user team worked on the project part-time). A set of core users permodule wereidentified and givenintensive training. Otherusers weretrainedjustin time just before they were expected to use a module. (Note: In ERP1, training


implementatio

60


13/21

wasgivenwellaheadofuse.Whenthemodulewasready(aboutfourtosixmonthsdown 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, precededthe new implementation. Special care was taken to address the changemanagement issues. In each department opinion leaders were identified andtasked with championing the revised work methods and flows. The issues ofpower loss that were felt earlier in ERP1 were much less as new work flows hadbeen in place for a year and users had got used to the new power structures.Moreover, through change management interventions, these issues weretackled as and when they arose.

(5) Wherever possible, attempts were made to integrate legacy data entry screensinto the ERP using application program interfaces (APIs). This gave the usersthe comfort of familiar legacy interfaces while at the same time not diluting theintegrity of the ERP.

Results. Within six months the ERP2 went on stream. The go live was relativelysmooth and trouble free. As the users were trained just in time, they were fresh andvery little hand holding was needed. The core users team became very valuableresources and were able to solve most of the operational issues. The quality of the MISimproved Drill down up to transaction levels was possible in most functional areasfacilitating greater management control. As the expectations were quite low to beginwith, the results exceeded expectations.

The ERP stabilised soon and within the next 12 months the same was wellentrenched in the company. ERP2 was a success. Following this success the companydecided to roll out the ERP to other divisions of the company.

Discussion, analysis and resultsThe cases were chosen primarily to illustrate how a change in operationalizing certainCSFs brought about a change in the outcome of the ERP project from failure to success.As the organization remains the same, the ERP is the same and the user group largelyremains the same, it is the different operationalization of the CSFs that has made thedifference. We now discuss the similarities and differences in the two cases and drawinferences for research and practice.

Case study findings similaritiesBoth projects followed the same standard methodology used by implementationconsultants.

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 casesfollowed the standard ERP implementation methodology which involves:

. definition (scoping, creating work plan);

. operational analysis (gap analysis, As is and To be process design);

. solutioning (detailed design, work-around plans);

. build (parameterizing, coding, data migration, testing);

. transitioning and go live.

IJMPB4,4

608


14/21

There is no significant change in top management, users, technical team between the twoprojects. Top management in the two cases remains largely the same. The usercommunity also is largely the same. The technical team for the implementation fromthe companys side was the same. The implementation partner was different but both

being internationally known firms with established systems, templates and practiceswe do not see this as a major differentiating factor.

Top management support, project champion, a priori BPR (considered as importantCSFs) were present in both the projects (at least on paper at the surface level) . Topmanagement support was understood to be important in both cases. Both projectsstarted out with a letter from the CEO on the importance of the project. Steeringcommittees were constituted in both cases. A project champion was appointed; userteams were constituted and trained. A BPR exercise was carried out and revised workflows mapped. It must be noted that at the surface level all the key CSFs appear to havebeen complied with. We show in the next section that it is the differences in the manner inwhich these are operationalized that seemed to have made the difference in the outcome.

Case study findings differencesERP2 had a much smaller scope and realistic goal when compared to ERP1. A keydifference is in the scope of the project. While ERP1 had very ambitious goals ERP2had a much smaller scope, the key goal being the smooth transition from version10.4-11i (Table II for the differences in scope between the two projects). This goal wasunderstood 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 ofthe project. Although in both cases topmanagementsupport was available, there wasalsoa critical difference. In ERP1 after the initial letter from CEO and the kickoff meeting topmanagements attention appeared to have waned. In ERP2however, the president himself

took ERP implementationas his personal KRA.At every occasion, the senior managementwould reemphasise theimportance of ERP. In businessreview meetings, the statusof ERPimplementation was the firstagenda point. Resources in terms of personnel (releasingbestpeople from each functional area as full-time team members), additional computerhardware (new terminals, additional RAM memory, etc.), additional training, and visits toother successful sites were sanctioned by top management.

Unlike in ERP1 where the IT head was the ERP project manager, in ERP2 a seniorline manager (the CFO) was made the ERP project head. This person was very seniorin the company, had the authority to sanction business process changes and hada personal stake in a successful implementation as his functional area would be thebiggest user of the ERP system.

Importance of the change management and BPR activities. In ERP2 great care was

taken to ensure that the reengineering efforts had the buy in of large sections of theusers. This was done through several rounds of discussions involving all levels ofemployees, addressing genuine concerns, allaying fears of loss of power, and aboveall constant reinforcing communication. The opinion leaders played a crucial rolethroughout the process. A process-based structure (as against a function basedstructure) with appropriate changes in goals (process goals against department goals),appropriate changes in compensation structures (rewards on achievement of groupgoals), etc. were incorporated.


implementatio

609


15/21

The ERP with the revised work flows was rolled out only after a reasonable comfortlevel on the new ways of working was achieved. In several instances, legacy screenswere integrated into the ERP to give the users the comfort of familiar screens.

Project monitoring and control. In ERP2 the steering actively monitored the project

without let up till the completion of two months after go live. As the CFO was theproject head (and also the steering committee chair) he was able to ensure fullparticipation of all the other steering committee members unlike in ERP1 where thesteering committee chair was the IT head who was not as senior in the organization asthe CFO.

A fully functioning steering committee was able to take crucial decisions on fundsallocation, changing work flows as needed and could limit the extent of customisationsin ERP2 unlike in ERP1 where there was very little control on customizations.A disincentive for customization was introduced by creating a notional debit (to adepartments budget) based on customization man days.

Creative use of legacy system. In ERP1 on go live the legacy system was switchedoff. This created havoc and affected despatches to customers forcing the company to

run the legacy in parallel. In ERP2 a different strategy was adopted. A hybrid strategyof introducing the ERP while retaining some crucial legacy screens was adopted. TheAPIs available in the ERP were used to ensure that legacy system data were sent to theappropriate ERP tables. As users got familiar with the ERP slowly these legacysystems were phased out. The resistance from users was thus creatively addressed.

Testing the hypothesis against the facts of the caseWe had hypothesised:

H1. High expectations negatively impact ERP success.

Analysis of the cases shows that there were clearly different expectations from ERP1

and ERP2 among the users. In the first implementation, being new to ERP practice, theconsultant inadvertently raised expectations to a very high degree. For example,detailed drill down capability, reduction in manpower of 20 percent, 3 second screenresponse, best practices introduction were promised (Table II). The actual results forERP fell far short.

Result. A large gap between expectations and actual delivery leading toexpectations-disconfirmation and thereby dissatisfaction.

In contrast in ERP2 everybody including the consultant was wiser. Coming after adisastrous implementation, the organisation went into ERP2 project with littleor no expectations. The ERP2 scope was simple- the key goal being migration to thelatest version Oracle 11i. Furthermore, the users had zero expectations from ERP dueto their bad experiences in the past. As one user succinctly put it:

[. . .] anyway the new ERP cant be worse than the earlier one, nothing can be worse [ . . .] aslong as it makes my work a little easier I am satisfied.

It is to be clarified that zero expectations did not mean that users had no functional ornon-functional requirements. What is being said is that unlike in ERP1,this time round,users were under no illusion that the ERP would be a panacea for all ills. There was agreat deal of realism of what to expect and what not to expect. In fact, users approachedthe ERP project with a mindset that nothing really would be different after ERP.

IJMPB4,4

610


16/21

When finally the ERP was delivered, users were pleasantly surprised to see that the ERPhad indeed made work easier.

Result. ERP2 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 of7 completely agree and 1 completely disagree among a sample of ten users drawnfrom diverse areas: strategic users, operational users and technical users. The resultsshow a marked improvement (Table III) in satisfaction levels with ERP2 compared toERP1 confirming our hypothesis that high expectations negatively impact usersatisfaction 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 inspecific actions and sustained throughout the project.

We next analyse the differences in the nature of top management support in the two

projects. The key difference between the two implementations with reference to topmanagement support is in actual actions of management. Although both the projectsappear to have the support of top management in ERP1 the support was in form onlywhile in ERP such support was actually manifest in affirmative actions (see discussionson the differences between implementations). This fact is sensed by the users and thenature of resistance to the ERP therefore varies in the two projects. The empirical study

User cohort (Nos.) ERP1 ERP2 Remarks

Overall i am satisfied with the ERP that has been implemented in our organisationStrategic users (2) 4, 4a 6, 5 Marked shift in satisfaction levels especially

among operational usersOperational users (4) 3, 2, 3, 3 5, 6, 6, 5Technical users (4) 2, 1, 2, 2 6, 7, 6, 6The top management was actively involved and supported the ERP project from start to finishStrategic users (2) 5, 5 6, 6 Major change in perception about top management

in ERP2Operational users (4) 2, 1, 1, 1 7, 6, 6, 7Technical users (4) 2, 2, 2, 2 6, 7, 7, 7

A steering committee was formed which met at least once a month, monitored progress and initiatedcorrective in the case of anyStrategic users (2) 3, 2 6, 6 Steering committee was seen to be functioning very

well in ERP2Operational users (4) 1, 1, 1, 1 7, 7, 7, 7Technical users (4) 2, 2, 2, 2 6, 7, 6, 7There was a project champion who led the project throughout by providing guidance building concessus

solving issues

Strategic users (2) 5, 5 6, 6 Project champion was appointed but not empoweredin ERP1Operational users (4) 2, 1, 1, 1 7, 6, 6, 7

Technical users (4) 2, 2, 2, 2 6, 7, 7, 7The ERP helps me do my job better when compared to the old (legacy) systemStrategic users (2) 2, 3 6, 6 Legacy system influence reduced by the time of

ERP2Operational users (4) 1, 1, 1, 1 6, 6, 6, 7Technical users (4) 3, 232, 2 6, 5, 4, 6

Note: aresponses measured on a Likert Scale: completely agree 7 to completely disagree 1

Table IIResults of empiric

study terespondents (diver

stakeholder grou


implementatio

61


17/21

also shows that the users perceptions of top management involvement in ERP2 issubstantially higher (Table III).

Conclusion. Top management support is perceived to be real only if accompanied by

actions. Some typical actions that seem to make the differenceare: the president declaringthe 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 theproject champion,etc. Theevidenceof the cases supports the hypothesis.

The next hypothesis:

H3. A strong and well-entrenched legacy system negatively influences theadoption of an ERP system.

The company had a well-entrenched legacy system. The legacy system incorporated thecurrent practices in the company and conversely the legacy system practices becamethe company preferred practices the ERP best practices therefore encounteredresistance. 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 ERP2 wasin place, the legacy system influence was reduced as in many areas ERP1 practices hadtaken root (Table III). Moreover, the change management exercise addressed many ofthe issues of power balancing and revised roles and responsibilities.

Conclusion. The facts of the case support the hypothesis that a well-entrenched legacysystem negatively influences ERP adoption only when legacy system influences arereduced do the ERP best practices gain acceptance.

Implications for practiceIn the practice area, management is advised to take a lot of care in the scoping and goal

setting process of an ERP implementation. Simple achievable goals facilitate theprocess of acceptance. The overall feel-good factor that follows from the achievementof expected goals will allow the management to push its larger agenda for morefundamental process changes. It is better to undersell ERP than oversell it. It getsaccepted better.

Top management has the pivotal role in ERP success. This role is both symbolicas well as substantive. Symbolically top management should be seen to own the project-as in the case of ERP2 where the president of the company takes ERP implementationas his personal KRA. Substantively, top management has to ensure that the bestresources are made available to the project this means dedicated user teams for theduration of the project, quality time for reviews, funds as needed for the up gradation ofcomputer infrastructure, etc.

The role of good project management cannot be reemphasised. A senior linemanager as the ERP project head is most desirable. A functioning steering committeethat steers the project throughout its course is vital for success. The steeringcommittee has the key role in addressing issues that are bound to come up quicklyand decisively. An important decision is how much customization to allow. At ABCCorporation, a disincentive for customization was a notional cost debit(based on estimated man days) to a department for every customization request.This worked in curbing customizations.

IJMPB4,4

612


18/21

Implications for researchOur study extends the work of Parr and Shanks (2000). It follows a similar two casemethodology of an unsuccessful implementation followed by a successful one in a newand 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 Parrand Shanks in that the two implementations are in the same organization separated intime. 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 scopingprocess. This was not covered in depth in the earlier research which primarily focussedon the implementation stage.

Our research has identified some key constructs that seem to impact ERPimplementation outcomes. For example, we have shown that top management supportis actually a composite of several other CSFs like full-time user teams allocation,personal example, empowering a champion, etc. All these together constitute a latentconstruct which could be called Leadership the dimensions of which exceed what isgenerally understood as top management support. Similarly all the other issues ofmanaging the implementation process like scope management, change management,etc. would map to another latent construct process. These constructsrepresent better ways of classifying the CSFs and future research could developmeasurement scales for these which could be used as predictive ex ante indicators forERP outcomes.

Our research had some limitations. The events of the case happened at a time whenERP and computerisation were in its infancy in India. Perhaps with time and greaterfamiliarity some of the issues that impacted the project may not be as relevant todayas it was then. But, even today ERP projects suffer and the lessons learnt from ananalysis of the past failures may, we believe have important lessons for our presenttimes.

Notes

1. Oracle Applications was called Oracle Financials during early 1990s.

2. INGRES was one of the earliest RDBMS systems available in the early nineties from IngresCorporation.

3. An Indian ERP that was gaining in popularity.

References

Akkermans, H. and Helden, K. (2002), Vicious and virtuous cycles in ERP implementation:

a case study of interrelations between critical success factors, European Journal ofInformation Systems, Vol. 11 No. 1, pp. 35-46.

Bancroft, N., Seip, H. and Sprengel, A. (1998), Implementing SAP R/3, 2nd ed., ManningPublications, Greenwich.

Benbasat, I., Goldstein, D.K. and Mead, M. (1987), The case research strategy in studies ofinformation systems, MIS Quarterly, Vol. 11 No. 3, pp. 369-85.

Bussen, W. and Myers, M.D. (1997), Executive information system failure: a New Zealand casestudy, Journal of Information Technology, Vol. 12 No. 2, pp. 145-53.


implementatio

61


19/21

Chua, C. and Lim, W. (2009), The roles of is project critical success factors: a revelatory case,ICIS 2009 Proceedings, Vol. 196, Paper 196, available at: http://aisel.aisnet.org/icis2009/196

Cooper, R.B. and Zmud, R.W. (1990), Implementation technology implementation research:

a technological diffusion approach, Management Science, Vol. 36 No. 2, pp. 123-39.Davenport, T.H. (1998), Putting the enterprise into the enterprise system, Harvard Business

Review, Vol. 76 No. 4, pp. 121-31.

Giddens, A. (1979), Central problems in social theory: action, structure, and contradiction insocial analysis, University of California Press, Berkeley, CA.

Holland, P., Light, B. and Gibson, N. (1999), Critical success factors model for enterprise resourceplanning implementation, Proceedings of the 7th European Conference on InformationSystems, Vol. 1, pp. 273-97.

Hong, K.K. and Kim, Y.G. (2002), The critical success factors for ERP implementations:an organizational fit perspective, Information & Management, Vol. 40 No. 1, pp. 25-40.

Keil, M. (1995), Pulling the plug: software project management and the problem of project

escalation, MIS Quarterly, Vol. 19, pp. 421-47.Lee, A.S. (1989), A scientific methodology for MIS case studies, MIS Quarterly, Vol. 13 No. 1,

pp. 33-52.

Markus, M.L. (1983), Power, politics, and MIS implementation, Communications of the ACM,Vol. 26 No. 6, pp. 430-44.

Markus, M.L. and Tanis, C. (2000), The Enterprise System Experience from Adoption to Success.Framing the Domains of IT Management: Projecting the Future through the Past,Chapter 10, Pinnaflex Educational Resources Inc., Cincinnati, OH, pp. 173-207.

Oliver, R.L. (1977), Effect of expectation and disconfirmation on post exposure productevaluations-an alternative interpretation, Journal of Applied Psychology, Vol. 62 No. 4,pp. 480-6.

Orlikowski, W.J. (2000), Using technology and constituting structures: a practice lens forstudying technology in organisations, Organization Science, Vol. 11 No. 4, pp. 404-28.

Pare, G. (2001), Using a Positivist Case Study Methodology to Build and Test Theories inInformation Systems: Illustrations from Four Exemplary Studies, School of BusinessStudies, Montreal.

Parr, A. and Shanks, G.A. (2000), Model of ERP project implementation, Journal of InformationTechnology, Vol. 15 No. 4, pp. 289-303.

Poole, M.S. and De Sanctis, G. (1990), Understanding the use of group decision support systems:the theory of adaptive structuration, in Fulk, J. and Steinfield, C.W. (Eds), Organizationsand Communication Technology, Sage, Newbury Park, CA, pp. 173-93.

Robey, D., Ross, J. and Boudreau, M. (2002), Learning to implement enterprise systems:an exploratory study of the dialectics of change, Journal of Management Information

Systems, Vol. 19 No. 1, pp. 17-46.Rockhart, J.F. (1979), Critical success factors, Harvard Business Review, March/April, pp. 81-91.

Ross, J.W. (1998), The ERP Revolution: Surviving Versus Thriving, Centre for InformationSystems Research, Sloan School of Management, Cambridge, CA.

Somers, T.M. and Nelson, K. (2001), The impact of critical success factors across the stages ofenterprise resource planning implementations, Proceedings of the 34th Annual Hawaii

International Conference on System Sciences, Washington, DC, USA.

Standish Group Chaos report (2009), available at: www.standishgroup.com

IJMPB4,4

614


20/21

Wixom, B.H. and Watson, H.J. (2001), An empirical investigation of the factors affecting datawarehousing success, MIS Quarterly, Vol. 25 No. 1, pp. 16-41.

Yin, R.K. (1993), Applications of Case Study Research, Sage, Beverly Hills, CA.

About the authorsC. Venugopal is currently pursuing a doctoral program in the Faculty of Management Studies,Anna University, Chennai. He is a B.Tech (Hons.) graduate in Engineering from IIT, Kharagpurwith a post graduate degree in Management from JBIMS, Bombay University. He has over 30years of industry experience spread over a wide variety of business functions including as ageneral manager systems, in which capacity he led one of the earliest ERP implementations inIndia. Since then he has been a regular speaker and trainer in the areas of enterprise systemsimplementation and is currently a business consultant advising organizations on strategicaspects relating to among others, information technology and change management. C. Venugopalis the corresponding author and can be contacted at: [email protected]

K. Suryaprakasa Rao has a PhD in Industrial Engineering from The Indian Institute ofSciences, Bangalore and is a Senior Professor in the Department of Industrial Engineering,Anna University, Chennai. He had done post doctoral work at GSM-UCI, USA and is a facultyfellow at SUNY Binghamton, USA. He has over 17 years of teaching and academic experienceafter having served for over 16 years in industry. His areas of specialization include operationsresearch, discrete event simulation, systems engineering and supply chain networks. He has awide list of publications in leading international journals. He is also the recipient of The Presidentof India Award during the Indian Engineering Congress 1999.


implementatio

61

To purchase reprints of this article please e-mail: [email protected] visit our web site for further details: www.emeraldinsight.com/reprints


21/21

Reproducedwithpermissionof thecopyrightowner. Further reproductionprohibitedwithoutpermission.

learning from a failed erp- indian

Documents