Learning from adopters' experiences with ERP: problems encountered and success achieved
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
T E
U L D
RO
GE
Journal of Information Technology (2000) 15, 245–265
·
·
up
Tay
ro
r &
Fr a nci s G
lo
Learning from adopters’ experiences with ERP:
problems encountered and success achieved
M . LY NNE MAR KUS, SH ERY L AXLINE*, DAVID PETR IE‡
AND CORNELIS TANIS§
City University of Hong Kong, Hong Kong, PR China,* School of Behavioral and Organizational Sciences and
‡School of Information Science, Claremont Graduate University, 1021 North Dartmouth Avenue, Claremont,
CA 91711, USA, §Coach and Commitments, Utrecht, The Netherlands
Enterprise resource planning (ERP) packages touch many aspects of a company’s internal and external
operations. Consequently, successful deployment and use of ERP systems are critical to organizational perfor-
mance and survival. This paper presents the results of a study of the problems and outcomes in ERP projects
which was conducted under the sponsorship of an ERP systems vendor. Two basic research questions were
addressed. First, how successful are companies at different points in time in their ERP experiences and how
are different measures of success related? (That is, can early success be followed by failure and vice versa?)
Second, what problems do ERP adopters encounter as they implement and deploy ERP and how are these
problems related to outcomes? The ndings showed that the success of ERP systems depends on when it
is measured and that success at one point in time may only be loosely related to success at another point
in time. Companies experience problems at all phases of the ERP system life cycle and many of the problems
experienced in later phases originated earlier but remained unnoticed or uncorrected. These ndings suggest
that researchers and companies will do well to adopt broad de nitions and multiple measures of success
and pay particular attention to the early identi cation and correction of problems.
Introduction internal and external operations, their successful
deployment and use are critical to organizational
One of the most enduring research topics in the performance and survival.
eld of information systems (IS) is that of system This paper describes the results of a study of prob-
success (Lyytinen and Hirschheim, 1987; deLone and lems and outcomes in ERP projects. The study was
McLean, 1992; Ballantine et al., 1996). Prior research conducted under the sponsorship of an ERP vendor
has addressed the measurement of success, the who was interested in helping its customers be more
antecedents of success and explanations of success or successful in ERP implementation. Two basic research
failure. Yet for each new type of information tech- questions are addressed: First, how successful are
nology (IT) or application the question of success companies at different points in time in their ERP
comes up again. In the case of enterprise resource experiences, and how are different measures of success
planning (ERP) systems success takes on a special related? (That is, can early success be followed by
urgency, since the costs and risks of these massive tech- failure and vice versa?) Second, what problems do ERP
nology investments rival their potential pay-offs. adopters encounter as they implement and deploy
Failures of ERP system implementation projects have ERP, and how are these problems related to outcomes?
been known to lead to organizational bankruptcy
(Bulkeley, 1996; Davenport, 1998; Markus and Tanis,
2000). Success with ERP and how it happens
Brie y, ERP systems are commercial software
packages that enable the integration of transactions- The de nition and measurement of success are thorny
oriented data and business processes throughout matters. First, success depends on the point of
an organization. From a base in manufacturing and view from which you measure it. It became clear early
nancial systems, ERP systems may eventually allow on in our research that people often mean different
for integration of interorganizational supply chains things when talking about ERP success. For example,
(Davenport, 1998; Markus and Tanis, 2000). Because people whose job it was to implement ERP systems (e.g.
these systems touch so many aspects of a company’s project managers and implementation consultants)
Journal of Information Technology
ISSN 0268–3962 print/ISSN 1466–4437 online © 2000 The Association for Information Technology Trust
http://www.tandf.co.uk/journals
DOI: 10.1080/02683960010008944246 Markus et al.
often de ned success in terms of completing the project business bene ts (if any) from the ERP system and
plan on time and within budget. However, people plans the next steps for technology implementation
whose job it was to adopt ERP systems and use them and business improvement. A number of success
in achieving business results tended to emphasize hav- metrics can be de ned for each of these phases.
ing a smooth transition to stable operations with the
new system, thereby achieving intended business
Success in the project phase
improvements such as inventory reductions and gain-
ing improved decision support capabilities.
(1) Project cost relative to budget.
In this paper we adopt an inclusive perspective that
(2) Project completion time relative to schedule.
focuses on the organizations that adopt ERP systems
(3) Completed and installed system functionality
and the individuals within these organizations (rather
relative to original project scope.
than on ERP vendors and external implementation
consultants). We recognize that our ‘etic’ perspective
(non-interpretive, outside looking in) may not have
Success in the shakedown phase
corresponded with that of any particular actor(s) in
the organizations we studied, but it allowed us to
(1) Short-term changes occurring after system ‘go-
include many different dimensions in our assessment
live’ in key business performance indicators such
of success, including the following.
as operating labour costs.
(1) Success viewed in technical terms. (2) Length of time before key performance indica-
(2) Success viewed in economic, nancial or tors achieve ‘normal’ or expected levels.
strategic business terms. (3) Short-term impacts on the organization’s
(3) Success viewed in terms of the smooth running adopters, suppliers and customers such as aver-
of business operations. age time on hold when placing a telephone
(4) Success as viewed by the ERP-adopting organ- order.
ization’s managers and employees.
(5) Success as viewed by the ERP-adopting organ-
ization’s customers, suppliers, and investors. Success in the onward and upward phase
A second important issue in the measurement of
(1) Achievement of business results expected for the
success concerns when one measures it. Some years
ERP project, such as reduced IT operating costs
ago, Peters and Waterman (1982) attracted much
and reduced inventory carrying costs.
attention with their study of ‘excellent companies’. A
(2) Ongoing improvements in business results after
few years later, a sizeable number of their excellent
the expected results have been achieved.
companies were no longer star performers. Project
(3) Ease in adopting new ERP releases, other new
managers and implementers can afford to declare
ITs, improved business practices, improved
success in the short run, but executives and investors
decision making, etc., after the ERP system has
are in it for the long haul. The organizations that adopt
achieved stable operations.
ERP systems need to be concerned with success, not
just at the point of adoption but also further down the These success metrics include indicators of human
road. The importance of considering ERP success at and organizational learning. It is important not just
multiple points in time was made clear in a case study how well the ERP system itself performs (e.g. accu-
by Larsen and Myers (1997) in which a successfully racy, reliability and response time), but how well
installed ERP system was later terminated when the people in the organization know how to use, maintain
company merged with another. and upgrade the ERP system and how well the busi-
In this study we were concerned with the assess- ness improves its performance with the ERP system.
ment of success at three different points in time during An unresolved question is the relationship between
the adopting organization’s experience with an ERP the measures of success at different points in time.
system. We can conceptually differentiate three distinct Larsen and Myers (1997) found that an ERP experi-
phases in the ‘ERP experience cycle’ (Markus and ence could be an early success and a later failure. But
Tanis, 2000): (1) the project phase during which ERP can an ERP experience be an early failure yet a later
software is con gured and rolled out to the organiza- success? How important is it for organizations to be
tion, (2) the shakedown phase during which the successful at all three phases of the ERP experience
company makes the transition from ‘go live’ to ‘normal cycle? And how often do organizations push through
operations’ and (3) the onward and upward phase initial failure to achieve an ultimate measure of success?
during which the company captures the majority of These are empirical questions.Learning from adopters’ experiences with ERP 247
A third important issue in the measurement of The phrase optimal success suggests that most
success is the yardstick or criterion against which to organizations experience outcomes that fall somewhat
compare an actual level of achievement. It is quite short of what a ‘best in class’ organization might
common in systems evaluation, technology assessment achieve. This observation directs attention at the prob-
and impact studies to use the adopters’ objectives, lems companies experience when they adopt, deploy
expectations and perceptions as the standard for and use ERP systems and how they respond when
de ning and measuring success. Naturally, these sub- problems arise. This is not a focus on ‘success factors’
jective judgements of success can be quite important per se, but on aspects of the ‘lived experience’ of organ-
in understanding how organizations behave. If a izations’ ERP journeys. One wants to know how (the
company stops using an ERP system because cor- process by which) some companies realize better or
porate objectives have not been met, it does not matter worse outcomes than other companies do and what
that an outside observer might have assessed the they do that makes the difference. Put differently, one
implementation project and system operation as wants to know whether all companies experience the
successful. same types of problems with ERP systems, whether
However, there are serious disadvantages to using they respond similarly to the problems and whether
perceptions, objectives and expectations as the sole the problems and responses are related to the outcomes
measures of success. In the rst place, it is hard to they experience.
normalize them across individuals and organizations, It should be clear that we believe that the outcomes
thus making comparisons dif cult. Second, their rela- companies achieve with ERP systems (varying degrees
tionship with so-called ‘objective’ measures of success of suboptimality, relative to what they could achieve,
(such as whether or not a project is terminated prior if all went perfectly well) are non-deterministic.
to completion), (cf. Sauer, 1993) is unclear. People’s Problems such as a lack of resources or turnover of
objectives for and expectations of ERP systems may personnel can arise in each phase of the ERP experi-
be overly ambitious so that they are unrealizable ence cycle. They may or may not be perceived as prob-
no matter what people do. Alternatively, or they may lems by the people in the organization and, even when
be insuf ciently ambitious so that people do not take people perceive the problems as problems, they may
full advantage of the capabilities ‘in’ the technology or may not take appropriate actions for resolving them.
which are available for them to use (Markus and Tanis, As a result, the outcomes in a particular phase may
2000). be optimal or less than optimal and the problems may
If one wants to compare the outcomes achieved or may not remain unresolved, thereby affecting
by the organizations that have adopted ERP systems, outcomes later. See Markus and Tanis (2000) for a
it is useful to have an external yardstick of success more detailed treatment of this ‘theory’ of ERP
in addition to internal perceptual measures and local success.
objectives and expectations. For this purpose, we In practice, it can be extremely dif cult to differen-
proposed using optimal success, as de ned by (Markus tiate between problems, symptoms of problems and
and Tanis, 2000), as our crieterion as follows: outcomes (that is, the consequences of problems).
Nevertheless, the importance and complexity of the
Optimal success refers to the best outcomes the
ERP experience suggests the need to try. Therefore,
organization could achieve with enterprise systems,
this study addresses two related questions about the
given its business situation, measured against a port-
ERP experience. First, how successful are companies
folio of project, early operational, and longer term
at different points in time in their ERP experiences
business results metrics. Optimal success can be
and how are different measures of success related?
far more or less than the organization’s goals for an
(That is, can early success be followed by failure and
enterprise system. Further, optimal success can be
vice versa?) Second, what problems do ERP adopters
dynamic; what is possible for an organization to
encounter as they implement and deploy ERP and how
achieve may change over time as business conditions
are these problems related to outcomes?
change (p. 186–7).
Table 1 helps to frame the ndings of this research
Naturally, the concept of optimal success de ned by providing a more complete description of the issues
thus is dif cult to operationalize. However, the advan- involved in assessing the success of ERP projects.
tage of attempting to assess outcomes by using such Table 1 outlines (1) the activities that characterize each
an external, non-interpretive yardstick is that it helps phase of the ERP life-cycle, (2) how and why the activ-
us compare the results achieved in different organiza- ities in each phase may affect the outcomes an adopter
tions and explore the interesting relationships between achieves, not just in the phase but also downstream,
‘objective’ outcomes and people’s perceptions of (3) some of the problems an ERP adopter may expe-
results. rience during the phase (which can also be understoodTable 1 Assessing achieved success in the ERP experience
248
Major activities of the phase Implications of phase activities for Common problems Phase success measures
success in phase and later
Project phase
Project team formation and training The majority of ERP expenditure plans Inability to acquire/retain employees and Project cost relative to
Develop enterprise model for con guration are made during this phase external advisers with requisite expertise in budget
and develop and validate kernel in Few bene ts are experienced during this ERP, project management and supporting Project completion time
multiple implementations phase unless the organization pursues a technologies relative to schedule
Con gure ERP software to re ect either ‘quick wins’ or ‘low hanging fruit’ strategy Turnover of project sponsor or project Completed system
current operations or planned new of identifying and implementing business manager functionality relative to
business processes process improvements while ERP planning Excessive turnover (and/or stress-related original project scope
Design and execute changes (if any are and con guration is under way health problems) on project team
planned) in the organization’s business The longer the project phase, the lower Unwillingness of business managers and
processes and related organizational the overall nancial bene ts from the key users to make time for project
elements (organization structure, jobs, system on a discounted cash ow basis activities
compensation, etc.) If the project goes very badly, decision Major changes in project scope after start
Implement add-ons, modi cations and makers may terminate it of project
interfaces with other enterprise systems When the schedule gets tight, team may Poor quality software, documentation and
and legacy systems decide to cut scope, so that strategically training materials
Acquire IT infrastructure resources and essential processes are not supported Modi cations that do not work and delays
integrate ERP system with infrastructure in development of modi cations and
and legacy systems (if any) interfaces
Document con guration decisions and Con icts with implementation consultants
rationale over project plans and management
Decide how to satisfy decision support/ Cutting testing and/or training when
reporting needs schedule gets tight
Communication and change management Pressure to terminate project if cost and
Clean up data and convert data to new schedule overruns occur
ERP system
Test the new system
Train users
Markus et al.Table 1 continued
Major activities of the phase Implications of phase activities for Common problems Phase success measures
success in phase and later
Shakedown phase
Make the transition to ‘normal operation’ The organization may not be able to Extremely poor system performance Short-term deterioration in
of the new system and the new business realize planned improvements in IT costs Excessive stress and/or turnover of key key (business) performance
processes and/or business process ef ciency until (1) users and/or key system support personnel indicators (KPIs) (e.g. process
‘Rework’ (mistake correcting) activities the new system stabilizes, (2) the old Excessive dependence on ‘key users’ cycle times, inventory levels
may include changing con guration systems are interfaced or turned off and (project team members) and/or IT and operating labour costs)
settings, upgrading IT infrastructure, older IT resources are removed from specialists Length of time before KPIs
revising business practices and procedures maintenance agreements and (3) users Maintenance of old procedures or manual and business impacts return
and retraining users achieve full pro ciency with the new workarounds in lieu of learning the to normal
system relevant system capabilities Short-term negative impacts
In addition, the organization may have to Data input errors on organization’s suppliers
make signi cant new expenditures for Inability to diagnose and remedy system and customers (e.g. average
temporary and overtime labour, consulting and/or business process performance time on hold, lost calls, lost
help and additional IT resources in order problems sales and customer
Learning from adopters’ experiences with ERP
to complete the transition from ‘go live’ Extremely negative reactions from satisfaction levels)
to ‘normal operations’ customers and suppliers (e.g. large losses
The longer the shake down phase, the of business)
lower the overall business bene ts on a Absence of sharp and fast improvements
discounted cash ow basis during shake down
If shake down goes very badly, the system Absence of satisfactory management
may be removed or the organization may information/analysis and reporting
become unwilling to undertake future Pressure to de-install system
system improvements (e.g., upgrades)
249Table 1 continued
250
Major activities of the phase Implications of phase activities for Common problems Phase success measures
success in phase and later
Onward and upward phase
Ongoing operation and use of system and The majority of business bene ts (if any) ‘Normal operation’ never materializes Achievement of planned
business process after the shakedown are achieved after shake down Non-improvement in users’ ERP skill business results (e.g. IT
phase Many desired business bene ts may not levels (e.g. many potential users remain operating costs, inventory
Planning for upgrades and migration to be possible with the current release, but untrained and users routinely rely on carrying costs, business
later releases/versions of hardware and may require the organization to undertake project team members and technical process cost and cycle time)
ERP software a series of upgrades (e.g. reductions in an support personnel to perform ‘normal’ job Use of data and decision
Adoption of additional modules/packages organization’s IT personnel expenditures activities) analyses produced by the
and integration with ERP may not be realizable during the initial Failure to retain people who understand system
Business decision making based on data ERP experience cycle and achieving the implementation and use of ERP Ongoing improvements in
provided by the ERP system business process ‘visibility’ across sites systems business results (after
Continuous improvement of users’ occurs after all sites have been No documentation of rationale for planned results have been
IT skills implemented) business rules and con guration decisions achieved)
Continuous business process improvement Many bene ts cannot occur until: (1) Dif culty in optimizing system Ease in developing/adopting/
in order to achieve better business results users have learned how to use the system performance and in recon guring the implementing additional
Recon guration of current release/version well, (2) managers have used the data system to support business innovations innovations in technology,
collected by the system in order to make Unwillingness of organization to adopt business practices and
business decisions and plan improvements additional changes in business processes, managerial decision making
in business processes and (3) additional system con gurations or IT infrastructure Original decision to
changes are made in business processes, Pressure to de-install system implement ERP still makes
practices, software con guration, etc. sense in light of subsequent
business decisions and
events (e.g. mergers and
acquisition)
(Over time) decreases in
length of project planning
and shake down phases for
subsequent ERP
implementations
Markus et al.Learning from adopters’ experiences with ERP 251
as indicators that the experience may be heading known outcomes. Studying completed projects allows
for suboptimal success) and (4) the success measures researchers to identify the key causal factors in success
relevant to the phase. or failure. Thus, we aimed for a mix of both completed
and in-process projects. Table 3 shows the stage of
completion reached by each company at the time we
Approach collected data. Because some of the cases we studied
were in process at the time of data collection, we do
This research study combined several methods: not have complete outcome data for all companies.
(1) reviews of published and in-process research Third, we went out of our way to select projects
studies and teaching cases of ERP implementations, that had experienced problems rather than projects that
(2) in-depth case studies of the ERP experience in were unquali ed successes. A major goal of the study
ve ERP-adopting organizations following the proce- was understanding the problems adopters experience
dures prescribed by Yin (1994), 3) interviews with 11 with ERP systems, why these problems occur and what
additional ERP-adopting organizations and (4) ap- could be done about them. Therefore, we skewed our
proximately 20 interviews with ERP implementation sample towards companies with problems and subop-
consultants and members of the ERP vendor company timal success. This means that the companies exam-
sponsoring this study. Table 2 describes each of the ined in this study may not be a representative sample
16 ERP-adopting organizations that directly partici- of all companies using ERP systems. It would not be
pated in this research. At the same time, the analysis valid to draw conclusions from this study about how
and interpretation of the results presented in this report frequently ERP adopters experience certain problems
re ect the experiences of a much larger number of or how frequently they achieve success (or lack of it)
companies (approximately 40 in total), including those on different measures.
described in teaching cases, other research reports and Two additional factors may limit the potential statis-
the trade press. tical generalizability (Yin, 1994) of the results. First,
The 11 ERP adopter interviews were conducted by all 16 of the adopter companies we studied were based
phone or in person: one or more members of the in North America or Europe. Second, all 16 compa-
research team discussed the ERP experience with one nies used the ERP products of a single software
or more members of the adopting organization. The vendor. However, we do not believe that these factors
interviews ranged from 1 to 3 h in length. The case materially affected our ndings about the kinds of
studies involved a much more signi cant level of effort. problems and outcomes companies experience with
Two to four members of the research team visited the ERP systems. Our ndings closely tracked reports by
case site for 2–4 days, interviewing 12–25 people. other academics and journalists. Further, these factors
Documents describing the company and its imple- were not likely to affect the analytical generalizability
mentation effort were collected and analysed. Notes (Yin, 1994) of our results. Although the current study
were transcribed and reviewed by project team design did not provide reliable data about frequencies,
members and summaries were written. The detail and it could provide reliable insights into how and why
thoroughness of the case study method meant that it problems and outcomes occur when they do occur.
was not necessary to examine a large number of cases
in order to gain the bene ts of this research strategy
in analysing ‘how and why’ research questions (Yin, Findings
1994). For such scienti c purposes, four to 12 case
studies are considered perfectly adequate. Table 4 presents a summary of the problems and
Several criteria were used in selecting the compa- outcomes reported by the companies participating in
nies for this study. First, we selected companies that this research. Immediately below, we present some
were interested in learning about how to improve their interesting generalizations about the nature of success
ERP experiences from the research. These companies across the ERP life-cycle. In a subsequent section, we
were recruited at public presentations where we discuss the problems companies experienced.
described our research project.
Second, we studied companies at different stages of
Findings about adopters’ achieved success with
the ERP experience. Studying projects in process
ERP systems
provides useful knowledge about how the ERP expe-
rience unfolds over time. This is particularly useful in First, none of the ERP adopters we studied was an
identifying why companies act the way they do. After unquali ed success at all of the stages of the experi-
the project is over, people forget many details and ence cycle completed at the time of our data collec-
reconstruct the past in order to be consistent with tion. This is to be expected given the nature of ourTable 2 Overview of companies in the study
252
Company Company description ERP implementation description – Data sources
identi er status at time of data collection
Company A $250 million US company Project was justi ed to and approved by company Four researchers performing
Company had grown through past mergers board approximately 12 h of interviews with
that were never fully integrated Single-site implementation with approximately one key informant plus 3 h interview
Single manufacturing location, functionally 400 users with chief information of cer (CIO)
organized All major business functions included in project, (one researcher)
Assemble to order manufacturing plus some including manufacturing, nance and distribution Data collected in US in March through
custom business processes (but excluding human resources). to September 1998
Industry details omitted at company request System went live June 1997
Total project cost approximately $17 million including
hardware and consulting services
Company B $1.2 billion global North American-based Company was having dif culty deciding which Three researchers performing
manufacturing company with 7000 software release to implement approximately 24 h of interviews with 16
employees and 170 sites all over the world Approximately 500 concurrent users world-wide members of implementation team,
Fifth or sixth in their industry. were expected including CIO and consultants
Make-to-stock, assemble-to-order and a small Project budget approximately $133.5 million and Reviewed internal documentation and
proportion of engineer-to-order processes planned schedule 30 months videotapes of ERP project introduction
Company formed through 1997 merger of The ERP project was cancelled in 1999 after an at leadership meeting January 1998
two companies roughly equal in size and expenditure of $70 million Data collected in US in June 1998
previously competed in distinct, industrial
equipment niches; little integration of the
companies has occurred
Company C European subsidiary of US multinational Multisite, pan-European roll-out in process Two interviews with ve key informants
apparel company (eight sites over 4 years) in summer 1998
Make to stock manufacturing Headquarters went live with nance modules Two researchers performing
Facing declining market demand for core December 1997 (on time) and raw materials approximately 27 h of on-site interviews
product management in June 1998 (6 months delay) with 19 informants in September 1998
First af liate and sales of ce live in July 1998 Reviewed key internal documentation
(6 months delay) Data collected in Belgium and The
Multisite con guration: eight (logistical and nancial) Netherlands
companies were set up
Distributed architecture – separate server at each site
$5.5 million worth of modi cations and interfaces
(includes consulting)
Company D $330 million arm of global energy and Three divisions each with separate single-site instance Two researchers performing
engineering rm located in Scandinavia of same ERP package approximately 30 h of on-site interviews
One thousand ve hundred employees First division went live in January 1996, on time and with 17 informants from operations,
Company is the result of a 1996 merger within budget nance and IS and one external IT
of three companies preserved in 1998 as Second division went live May 1998 6 months behind consultant in September 1998
three divisions schedule and 25% over budget due to buggy software Reviewed key internal documentation
Manufactures components and systems that and more customizations than planned Data collected data in Scandinavia
serve the entire supply chain of the electrical Third division was in the process of implementing
power industry
Markus et al.Table 2 continued
Company Company description ERP implementation description – Data sources
identi er status at time of data collection
Company E Multinational conglomerate based in the UK Implementation began autumn 1997 Three researchers performing
Thirty ERP projects planned over 5 year period approximately 20 h of on-site interviews
with 13 informants in October 1998
plus 3 h of interviews prior to site visit
Company N Small private US company manufacturing Single-site implementation One hour telephone interview with
health care equipment and supplies Initial implementation in 1993 and reimplementation company president in March 1998
in 1997
Company O $1 billion electronics company based in Multiple implementations in different international One hour telephone interview with
the US sites member of worldwide roll-out team in
Manufacturing locations in ve countries First implementation of early ERP package in March 1998
Six thousand employees Germany then company-wide roll-out
In the process of reimplementation and worldwide
roll-out, starting with manufacturing
Learning from adopters’ experiences with ERP
Company P Japanese-owned automotive supplier Planned live dates in May 1998 for Canadian One hour telephone interview with
operating in North America operations and August 1998 for main of ce manager of corporate services and
One thousand employees in North America All modules to go live at once corporate production planning in March
Regional of ces in ve sites 1998
Experiencing rapid growth
Company Q $40 million Canadian electronics Beta test site for early ERP package One hour telephone interview with
semiconductor manufacturer In the process of reimplementing ERP with CIO/IT project manager in April 1998
Growing at 20+% per year new software
High-tech company with strong IT
experience
Company culture tolerates change
reasonably well
Company R Small private company with plants in the US, Used ERP since 1993 One hour telephone interview with CIO
Canada and the UK Currently implementing ERP upgrade in April 1998
Combination of assemble to order and
repetitive manufacturing
Company S $1 billion and growing US-based industrial Enterprise rollout planned for 1999 One hour telephone interview with
equipment manufacturer with 5200 Description of ‘unit A’, the rst division to go live manufacturing systems manager of unit
employees worldwide with ERP: A in April 1998
Fifty years old; a wholly owned subsidiary of Single-site implementation with ten licences
a major industrial equipment company Went live in November 1997
Project budget of $1.2 million
First release implemented was ‘very buggy’ and now
reimplementing later release
Still have three major interfaces to homegrown systems
Plan to replace with ERP in the future
253Table 2 continued
254
Company Company description ERP implementation description – Data sources
identi er status at time of data collection
Company T Small North American-based producer of $1.5 million project Electronic interview in April 1998
security systems Server upgraded numerous times due to undersizing
Approximately 600 direct labour by ERP vendor
manufacturing employees Due to company’s performance problems, vendor
Fifteen to twenty per cent annual growth rate performed special modi cations in order to enable
over previous 5 years special software release
Company U Small European electronics assembler First ERP implementation in 1990; logistics One hour telephone interview in June
Twenty- ve to thirty per cent annual Reimplemented current release 1998
growth rate
Five hundred employees
Company V $175 million US-based manufacturer Went live on ERP early 1997 One and a half hour telephone interview
Products sold in 100+ countries through Elapsed time from initial project concept to go-live with IS director in March 1998
distributors and dealers approximately 2.5 years
Nine hundred employees, most of which are One hundred and fty or more users of the system
at headquarters/manufacturing facilities
Many of the products are engineered to order
Company X Large manufacturing rm Roll-out completed December 1997 One hour telephone interview in June
Details omitted at company request 1998
Company Y Large US manufacturing rm in the Two US locations and three phase roll-out One hour telephone interview in June
aerospace industry First phase went live May 1997 1998
Other two planned to be complete by Reviewed internal documentation
September 1998
Markus et al.Learning from adopters’ experiences with ERP 255
Table 3 Companies studied by stage of ERP experience company S did achieve its desired business results,
cycle despite a massive cut in scope. While company S
implemented only 15% of the ERP functionality it had
Stage of experience cycle reached Company
at time of data collection identi er
originally planned to implement, the company claimed
to have achieved substantial inventory reductions, as
Project phase Company B intended. This result shows that it is possible for
Company O ‘failed’ projects to achieve eventual business success.
Company P
We found that companies differed substantially in
Shakedown phase Company C how they de ned success in the project phase because
Company E they differed in their de nitions of the project itself.
Company X Some companies de ned the project as ‘implementing
Company Y ERP as quickly and cheaply as possible’. Others de ned
Onward and upward phase Company A the project as ‘adopting best practices enabled by
Company D ERP’ (which entails business process re-engineering).
Company N Still another de ned the project as ‘achieving com-
Company Q monality of systems and business practices in a de-
Company R centralized organization’ (which entails a process of
Company S organizational development and consensus building).
Company T
In general, the larger the organization’s de nition of the
Company U
project the more willing the organization was to expand
Company V
the project’s budget and schedule. These companies
were less likely to judge the overall ERP experience as
sampling (overselection of companies that had experi- unsuccessful when the project budget and schedule
enced or were experiencing dif culties) and it may not were not met.
be a representative nding. We do believe that some We found that larger organizations tended to de ne
companies are successful on all three categories of the ERP experience in much more expansive terms
success measures. than smaller ones. They often demanded business
However, Ross and Vitale (2000) found that a results from ‘IT’ projects. In many cases, these orga-
performance dip after initial implementation of an nizations were planning for multiple (perhaps dozens
ERP system is very common. Many of our companies of) ERP installations and realized the importance of
similarly experienced moderate to severe business dis- learning how to implement and upgrade ERP systems
ruption when their ERP systems ‘went live’. They had better each time. They were more likely than smaller
dif culty diagnosing problems (which had many possi- organizations to start planning for the onward and
ble causes) and they had dif culty recovering from upward phase during the project phase.
them. They sometimes achieved ‘normal’ operations Third, as Larsen and Myers (1997) observed, some
only by permanently increasing staf ng levels and re- companies that achieved ‘success’ in the project phase
ducing expectations about labour ef ciency. In general, could be classi ed as failures later on. Either they expe-
ERP adopters seemed both physically and psychologi- rienced substantial dif culties during the shakedown
cally unprepared for shakedown phase dif culties. phase (companies E and N) or they reported a lack
Further, extreme dif culties in the shakedown phase of business bene ts during the onward and upward
appeared to have strong negative in uences on compa- phase (company Q). Similarly, one of the companies
nies’ willingness to continue with the ERP experience. studied by Dolmetsch et al. (1998) successfully imple-
mented SAP R/3 (a particular ERP system) within 4
Several companies with shakedown phase problems
months but was later disappointed not to have achieved
reported strong pressure to de-install their ERP system.
business performance improvements because it had not
Even when the ERP system was retained, there was
re-engineered its processes.
great unwillingness to upgrade to ‘enhanced’ versions
We were surprised that several companies in the
of the software. In essence, these companies imple-
onward and upward phase could not say whether they
mented ‘legacy’ ERP systems.
had achieved business bene ts from using ERP with
Second, mixed ‘success’ results were observed even
any con dence. They gave a variety of related reasons
with a single phase. For example, a number of compa-
for their inability to assess their results.
nies achieved their budget and schedule targets, but
had to cut scope, often substantially (companies S, (1) The ERP system had been adopted for tech-
A and T). In the case of company T, these scope nical reasons (e.g. Year 2000, cost or lack of
reductions led to failure later on: the company did not capacity in their current system) and not for
achieve the business results it had hoped for. However, business reasons.Table 4 Problems and outcomes experienced by phase
256
Companies by Project phase problems and outcomes Shakedown phase problems and outcomes Onward and upward phase problems and
phase of outcomes
experience cycle
at time of study
Companies in project phase
Company B In-process ERP project halted and rechartered N/A N/A
when company merged
ERP system faced huge organizational integration
issues
The ERP project was cancelled in 1999 after an
expenditure of $70 million
Company O Had to modify ERP software for essential N/A N/A
functionality despite policy against it
First implementation partner replaced for lack
of relevant experience
ERP project combined with company-wide
standardization and re-engineering;
big change in management issues
Company P Had to modify ERP software for essential N/A N/A
functionality despite policy against it
Project team had dif culty getting involvement
from local sites
Companies in shakedown phase
Company C Project team communicated well with Experienced system performance problems N/A
management and sites KPIs deteriorated in short term
Management centralized formerly decentralized Customers and suppliers experienced negative
IS units for ERP implementation; local sites effects
resisted Managers not happy with reporting capabilities
Experienced cost and schedule overruns
Company E On time and within budget KPIs deteriorated in short term N/A
Expected scope achieved
Project team did excellent job of building
consensus around need for common systems in
this decentralized company
Company X Not discussed Experienced dif culties with data conversion N/A
Experienced system performance problems
KPIs deteriorated in short term
Company Y Budget and schedule overruns Experienced system performance problems N/A
Experienced software bugs KPIs deteriorated in short term
Customers and suppliers experienced negative
Markus et al.
effectsTable 4 continued
Companies by Project phase problems and outcomes Shakedown phase problems and outcomes Onward and upward phase problems and
phase of outcomes
experience cycle
at time of study
Companies in onward and upward phase
Company A On schedule and within budget KPIs deteriorated in short term Turnover of experienced users and support
Scope cuts personnel
User skill with system is low
Some improvements in key business
measures
Other planned improvements not achieved
(owing to scope cuts)
System may be partially de-installed
(owing to unanticipated merger)
Learning from adopters’ experiences with ERP
Company D One division on time and within budget Experienced heavy data entry errors by users User skill with system remains low and
A second division experienced schedule delays Had to increase staff to cope with errors errors remain high
due to software modi cations KPIs deteriorated in short term System not used in managerial decision
making
Insuf cient plans for ongoing system
support and business improvement
Company N Acceptable project outcomes despite heavy Disastrous performance problems Never achieved normal operations
customizations Severe business disruption Experienced permanent loss of business
Severe negative impact on customers and
suppliers
Company Q Acceptable despite entirely in-house Users challenged by conversion to client-server Business improvements were not sought as
implementation with no prior experience environment part of ERP implementation
Severe system performance problems
Company R Experienced poor consulting advice Experienced many software errors due to lack of Business improvements were not sought as
Made excessive software modi cations integrated system testing part of ERP implementation
Experienced dif culty recovering from errors
Company S Within budget Not discussed Planned business bene ts achieved
Greatly behind schedule
Greatly reduced scope
257Table 4 continued
258
Companies by Project phase problems and outcomes Shakedown phase problems and outcomes Onward and upward phase problems and
phase of outcomes
experience cycle
at time of study
Companies in onward and upward phase
Company T Within budget Not discussed Head count increased instead of decreased
Schedule overruns as planned
Scope cuts Improved reporting and data access
Some planned business improvements not
achieved
Company U Project team took excessively functional Extensive recon guration occurred as a result of Poor data quality continues to hamper
approach to implementation learning about integrated operations business
Management support gained quite late KPIs improved after recon guration Company has gained improved awareness
in process of bene ts of cross-functional integration
Management is extremely satis ed with
system
Upgrade to new release is planned
Company V Ignored advice of experienced implementation Extreme business disruption owing to Permanent loss of customers
consultants con guration errors, system integration problems Business processes streamlined
Did not follow conventional implementation and incomplete/inaccurate data Company is now ready to undertake
methodology KPIs deteriorated in short term process re-engineering
Excessive project manager turnover ( ve times) Customers and suppliers experienced negative
effects
Markus et al.Learning from adopters’ experiences with ERP 259
(2) No business goals had been set for the ERP experienced were ‘wicked’, that is hard to recognize
project. and diagnose due to multiple interacting causes and
(3) The company did not manage by metrics. varying symptoms and effects. In this section, we
(4) Existing systems did not allow the company to describe what we believe to be the most dif cult prob-
measure where it was on key business metrics lems adopters experienced and why the problems
prior to the implementation of the ERP system. occurred.
(5) The company did not perform a post-imple-
mentation audit of the ERP project in order to Project phase problems
assess whether projected bene ts were achieved. The most challenging project phase problems reported
by our respondents involved software modi cations,
In general, companies that do not deliberately set
system integration, product and implementation
out to achieve measurable business results do not
consultants and turnover of project personnel.
obtain them (or do not realize that they have obtained
them). Further, the inability to document measured Software modi cations Almost every analyst of the ERP
bene ts from an ERP implementation appears to experience strongly advises companies to avoid modify-
discourage organizations from undertaking future ing the software. Companies are advised to live with
upgrades and/or migrations. existing ERP functionality and to change their pro-
In conclusion, success in the ERP experience is multi- cedures to adapt to it. However, we found the following.
dimensional and often hard to measure. Early success
(or success on project measures) is not closely linked (1) Many adopters could not avoid some degree of
with later success (success on business measures) and ERP software modi cation. In some cases, ERP
early failure (failure on project measures) is not tightly packages are selected on a centralized basis in
linked with later failure (failure of business measures). order to t the majority of corporate needs.
Clearly then, success in an ERP experience is not pre- Often, there are a few sites that cannot operate
determined by a set of success factors in place at the effectively with the software’s functionality, even
start of the project and continuing unchanged through- if people there are in principle willing to modify
out. Either conditions change over the course of the their business processes. For example, one
experience or different types of actions are required at company reported having an order of magni-
different phases and the ways in which a company tude more entities (e.g. sales representatives)
responds to conditions at each phase in uence the than were allowed by the relevant eld size
subsequent progress and ultimate success of the ERP in the software package. Other companies
experience. This observation suggests one obvious explained that the software simply did not t
normative recommendation: companies should be con- business rules around commissions and royal-
cerned with success in all phases of the ERP experience ties and that these rules could not be changed
and should not concern themselves exclusively with without serious negative business implications.
what happens during the project phase. In addition, this (2) Many adopters had dif culty in getting modi -
observation suggests one obvious research issue: In cations to work well. They complained about
order to understand the success of an ERP experience, implementation consultants who did not deliver
one needs to look at what goes on (e.g. problems expe- well-tested and working modi cations in a
rienced and attempts at problem resolution) at each timely manner.
phase of the experience cycle. In the next section, we (3) Most distressingly, several adopters reported
focus more deeply on why the companies we studied that, after wrestling with modi cations (and
achieved suboptimal success. sometimes failing to make them work well), they
eventually learned that their modi cations were
Findings about adopters’ problems with ERP unnecessary after all. They had usually made
plans for software modi cations early in the
We asked adopters what problems they experienced
project phase when they did not understand the
with ERP systems, how they had dealt successfully
software thoroughly (in particular the integra-
with these problems (if they had) and what they had
tions across modules). Later on when they
learned as a result of their experience. We also formed
understood the software better, they discovered
our own impressions of their experiences based on
ways of implementing the needed capabilities
what we observed when we visited their companies.
without modi cations.
We came away with a deep respect for the challenges
they faced. If what they were trying to do was easy, For a more general treatment of the issues involved in
more of them would have been successful on all tailoring ERP software to a company’s speci c needs see
measures. However, many of the problems they L. Brehm, A. Heinzl and M. L. Markus (forthcoming).260 Markus et al.
Problems with system integration ERP systems are sold (1) Few IT products and services rms were willing
as ‘integrated packages’, implying that they contain to take end-to-end responsibility for coordi-
everything one needs and that ERP software con gura- nating all parties. In addition, adopters were
tion (plus tailoring) is the major activity of the project often rightly reluctant to cede authority for
phase. However, there are a number of respects in project management to an outside party, even
which this is not so. when they were willing to pay the steep fees for
outside assistance.
(1) First, an ERP system needs to be integrated with (2) IT products and services rms generally seem
the computing platform on which it will run. We to resent taking subordinate roles to other such
found that companies had great dif culty rms. They do not to cooperate well. There is
integrating their enterprise software with a pack- much nger pointing when problems occur.
age of hardware, operating systems, database (3) Despite representations during the sales cycle,
management systems software and telecom- there was widespread lack of knowledge about
munications systems suited to their particular the details of ERP products, particularly where
organization size, structure and geographic dis- integrations, tools and interfaces with ‘partner’
persion. They reported having dif culty nding products were concerned.
experts who could advise them on the precise (4) Because IT products and services rms are
operating requirements of their ERP con gura- growing rapidly, they nd it dif cult to provide
tion. They described having made unplanned continuity in personnel assigned to adopter
upgrades of processors and memory to support projects and adopters strongly value continuity
their systems. One company reported making in personnel.
several changes of database management system (5) Several adopters reported having had con icts
before nding one that ‘worked’. (sometimes severe) with IT products and
(2) Second, for all that ERP systems are said to be services vendors over contractual provisions
comprehensive packages that cover every orga- (e.g. pricing and billing arrangements) and
nizational function, most of the companies we project direction (e.g. project management).
studied (large and small) reported needing to
retain some legacy systems that performed Turnover of project personnel An all too common com-
specialized functions not available in ERP pack- plaint was the frequency with which adopters lose
ages. (Alternatively, they acquired specialized key personnel experienced with ERP or supporting
software from third parties.) These systems technologies. As already noted, external service
needed to be interfaced with ERP systems – providers themselves are unable to maintain continuity
a process, that is both challenging and expen- of customer support personnel. In addition, adopters
sive. frequently reported the following.
(3) A particular area in which many organizations
(1) Losing key IT specialists and user representa-
found ERP systems de cient was that of data tives working on the project while the project
reporting. ERP systems are essentially transac- was going on, often despite handsome retention
tion processing systems that do not (without bonuses.
expensive add ons) solve companies’ needs for (2) Losing experienced people after the project was
decision support. For descriptions of the complete. Many IT specialists thrive on project
measures companies must often take to solve work and view assignment to a ‘competence
their ERP-related data reporting problems, see centre’ (support unit) as unpleasant mainte-
the cases of Microsoft (Bashein et al., 1997) and nance work.
MSC Software (Bashein and Markus, 2000).
In short, the project phase of the ERP life-cycle posed
Problems with product and implementation consultants severe challenges for the adopters we studied and not
ERP implementations are socially complex activities. all companies resolved these problems well. In some
As many as a dozen or more external companies – cases, unresolved issues ‘left over’ from the project
including the ERP vendor, vendors of ERP product phase became the source of problematic outcomes later
extensions, vendors of supporting hardware, software in the shakedown phase.
and telecommunications capabilities, implementation Unfortunately, it was also the case that companies
consultants and so forth – may be involved in experienced problems that had originated in the project
different aspects of an organization’s ERP experience. phase, but which were not perceived as problems or
Coordinating the efforts of all these rms is, to put it recti ed at that time, during the shakedown phase.
mildly, a challenge. We found the following. Although these problems are more rightly classi ed byLearning from adopters’ experiences with ERP 261
their origins as project phase problems, we list them appropriate cross-functional representation. For an
below as shakedown phase problems because that is example, see Koh et al. (2000).
where their symptoms show up.
Inappropriately cutting project scope Knowledgeable
Shakedown phase problems project managers know that exceeding the project
As mentioned earlier during the discussion on schedule is the major threat to project success (more so
‘success’, many of our companies experienced nega- even than budget overruns). Therefore, cutting scope is
tive outcomes during the shakedown phase. Among a common tactic when the project shows signs of miss-
the outcomes experienced were the following. ing key milestones. Project managers are often tempted
to cut scope according to what looks hardest to do;
(1) Performance problems with the ERP system
those who stay focused on ‘what is the minimum func-
(and underlying IT infrastructure).
tionality we can implement in order to obtain the
(2) A slow down in business processes.
desired business bene ts?’ are more successful. As men-
(3) Errors made by users entering data into the
tioned earlier, several of the companies we studied cut
system.
scope when the schedule and budget ran short. These
(4) Increased staf ng required to cope with slow
deletions often made it necessary for users to adopt
downs and errors.
inef cient manual processes in the shakedown phase.
(5) A drop in the company’s key performance indi-
cators. Cutting end-user training Schedule pressures affect
(6) Negative impacts on customers and suppliers training as well as scope because end-user training is
from an inability to answer their queries and typically one of the last activities to occur in the pro-
from delayed shipments and payments. ject. Adopters frequently reported having underesti-
(7) A need for manual procedures for addressing mated the needs for end-user training. In particular,
lack of functionality in ERP software. they told us that users needed additional training and
(8) Data quality problems. education in non-ERP areas.
(9) Inadequate management reporting.
This list is an uncomfortable mélange of symptoms of (1) Making the transition from ‘green screen’
leftover problems (e.g. performance problems with the (mainframe software) to ‘client-server’ (PC-
based software). Surprisingly, this was a major
system and slow down in processes), attempts to
hurdle in several adopter organizations.
resolve problems (e.g. manual processes, workarounds
(2) Understanding ERP and MRP (material require-
and increased staf ng) that create new problems in
ments planning) concepts. Some adopters
their turn and true outcomes – consequences of prob-
believed it necessary to conduct extensive APICS
lems (e.g. negative impacts on customers). These
(a professional institution) education to accom-
elements are dif cult to disentangle analytically.
pany ERP training.
However, after detailed examination, we concluded
(3) Understanding cross-functional business pro-
that many shakedown phase dif culties were caused
cesses. In many organizations, people understand
by problems that occurred during the project phase
what they do, but not how their work affects
but were not recognized as problems or successfully
others. In the ERP setting, such a limited world
resolved at the time they occurred. The most impor-
view leads to errors and misunderstandings.
tant of these problems were approaching ERP imple-
(4) Recovering from data entry mistakes. Because
mentations from an excessively functional perspective,
ERP systems are integrated, data entry errors
inappropriately cutting project scope, cutting end-user
have many more rami cations than do errors in
training, inadequate testing, not rst improving
traditional systems and they are much harder
business processes and underestimating data quality
to correct. Adopters reported suffering from lack
problems and reporting needs.
of training activities that addressed recovery
Approaching ERP implementations from an excessively from data entry problems.
functional perspective Cross-functional integration is In some companies, training was not budgeted as
still a new concept to many organizations. It is far part of the ERP project itself, but was left to the
more natural for them to approach implementing ERP budgets and discretion of operating managers. This
on a module-by-module basis and to assume that management policy increased the likelihood of inade-
ERP modules correspond to traditional functional quate end-user training.
departments in the organization (e.g. accounting,
manufacturing and sales). Con guration errors often Inadequate testing, particularly of interfaces, modi cations,
follow when adopters set up project teams without integrations and exceptions Like scope and training,You can also read
