The Enterprise System Experience - From Adoption to Success

7/17/2019 The Enterprise System Experience - From Adoption to Success

http://slidepdf.com/reader/full/the-enterprise-system-experience-from-adoption-to-success 1/36

Chapter 10

The Enterprise System Experience—From Adoption to Success

M . Lynne Mar kus and Cornelis Tan is

“[T ]he noti on that a compan y can and ought to have an exper t

(or a gr oup of exper ts) cr eate for i t a si ngle, compl etely

i nt egrated super system—an ‘M I S’—to hel p i t gover n ever y

aspect of it s acti vi ty i s absur d.” (D ea rd en, 1972, p. 101)

173

For some 20 year s a fter J ohn Dearden w rote these words, history proved him right.

Today, how ever, there is a b ooming m a rket for softwa re packa ges claiming t o provide

a tota l, integra ted solution to compan ies’ informa tion-processing n eeds. E ven compa-

nies that choose not to adopt such packages are pursuing aggressive strategies of

systems integra tion by redeveloping custom softwa re a nd a dopting technologies such

as data warehousing. Integrated enterprise systems deserve serious research atten-

tion because of their great potential for financial, technical, ma na gerial, huma n, an d

stra tegic benefits, costs, an d risks.

This chapter provides a theoretical framework for analyzing, both retrospec-

tively a nd prospectively, th e business va lue of ent erprise syst ems. We first describethe historical context in which enterprise systems emerged. Next we identify the

key chara cterist ics of enterprise systems, discuss the reasons compan ies do and do

not adopt them, and summarize arguments about why enterprise systems are an

important topic for research. We then analyze enterprise systems in terms of the

concept of success. We argue that the many facets of success create difficulties for

Acknowledgments: The authors gratefully acknowledge the support of other members of their research

team: Sh eryl Axline, Lars B o Eriksen, and Da ve Petrie. In addit ion, they wish t o thank th e following in-

dividuals for helpful input at various stages in this work: Carole Agres, Matt Alvarez, David Brown,

Dorothy Cooney, Sa bine Hirt , Debbie Mahan , Christ ina Soh, and Na ncy Wendt.



both academics and practit ioners and require a framework for understanding the

“enterprise system experience.” Essential elements of this framework include

pha ses, sta rtin g condit ions, goals , plans, a nd qu a lity of execution. We conclude wit hsuggestions for future research.

HISTORICAL CONTEXT OF ENTERPRISE SYSTEMS

Whether because the capacity of computers and programming languages was too

sma ll or organizat ions w ere content to man age th emselves along narrow functional

lines, the 1970s vision of a single integrated information system for the enterpriseremained a mira ge for t he ma jority of computer-using organiza tions. Instea d, organi-

za tions creat ed “isla nds of aut omat ion” (McKenney & McFa rla n, 1982). When compa -

nies identified a new applicat ion for IT, th ey progra mmed a discrete new informa tion

system. If the new system had something in common with existing systems, it was

loosely interfaced (sometimes ma nua lly) ra ther t ha n integra ted tight ly with these ex-

isting systems. As a result, combining informa tion about sales or manufa cturing with

accounting data was difficult and error prone. Analyses could be performed easily

only at a summary level; detailed transaction-level analysis required special ad hoc

programming or manual record sifting. Multiple systems contained the same dataelements; because duplicate da ta entry promoted errors and because systems va ried

in update schedules, the data in different systems often did not agree. Decision

making was stymied. Corporate restructurings necessitated major reprogramming

(or were a ban doned a s t echnologically infeasible1). The total organizational costs of

ma inta ining this loose patchw ork of redunda nt a nd overlapping systems grew, eclipsing

the funds ava ilable for building new ones (Lientz & Sw an son, 1980). In short, organiza -

tions fina lly began to experience the burden of not having pursued the dream of “one-

compa ny, one-syst em.”

B ut t he dream did not die am ong members of the informa tion systems commu-nity. Throughout the 1980s and 1990s, software entrepreneurs in Germany, the

Netherlands, the United States, and elsewhere were developing integrated software

packages in which multiple functional applications shared a common database.2

A

single transaction such as a sales order could “flow through” the entire applications

suite, automat ically updat ing fina ncial and inventory records wit hout additional da ta

entry and feeding various planning and decision support systems. As the vendors

enhanced the functiona lity of their integrat ed packages, they claimed with some (but

not total) truth that their products met all the information-processing needs of the

compan ies tha t ad opted t hem. These packages becam e known a s enterprise resourceplanning (ERP) systems, and they include some that have developed out of the

adm inistra tive (financial a nd huma n resources) side of the business (e.g., SAP an d

P eoplesoft), as well as some tha t grew from ma terials resource plan ning in ma nufac-

turing (e.g., Ba an ).

Software packages have always been more acceptable for smaller enterprises

than for large ones for a variety of historical, technical, and economic reasons. There-

fore, integrated packages made relatively little headway in the largest organizations

unt il th e mid-1990s, w hen vend ors bega n t o offer versions for t he client/server a rchi-

tecture. For some time, compan ies had been a wa re tha t the client/server ar chitectureafforded advantages relative to mainframe-based applications. The latter had much

higher operating costs, a nd t hey did not support gr aphical user int erfaces for business

174 M. Lynne Markus and Cornelis Tanis



applicat ions. Ma ny compan ies tried redeveloping t heir core tr an sa ction sy stems for

th e client/server a rchitectur e, only t o discover tha t t he process w a s extremely expen-

sive and highly failure prone; packages as an alternative to in-house (re)developmentsta rted t o become a n a ppea ling option, even in large companies. P a cka ges got a huge

boost a s companies bega n t o realize th e full impa ct of the Year 2000 (Y2K) problem—

an d came to see packages as a solution. (Other reasons for ERP a doption are dis-

cussed lat er.) Suddenly, nearly everyone got on the ERP band wa gon.

By 1998 approximately 40%of companies with annual revenues of more than

$1 billion had implemented ER P systems (Ca ldwell & St ein, 1998). ERP vendors

began aggressively targeting smaller firms because they represent a much larger

market. In aggregat e, the ERP marketplace is huge. SAP Inc., the largest ERP system

vendor, ha d 1997 revenues of $3.3 billion (Da venport, 1998). A resear ch firm recentlypredicted tha t t he ERP ma rket would reach $66.6 billion by 2003 (AMR Research,

1999).3

The ERP systems and services market ha s cooled somewha t a t present be-

cause man y compan ies have already implemented ER P in response to Y2K concerns.

Nevertheless, interest in related enterprise systems such as sales force automation,

supply chain integrat ion, a nd product configura tion remains s trong.

Enterprise systems are clearly a phenomenon in the IT marketplace. Their

potential significance for computer-using organizations cannot be overstated. They

represent a nearly complete rearchitecting of an organiza tion’s portfolio of tra nsa ctions-

processing applications systems to achieve integration of business processes, systems,a nd informat ion—along with corresponding cha nges in the supporting computing plat -

form (hardware, software, databases, telecommunications). On a societal scale, the en-

terprise syst em phenomenon seems t o be about a complete renewa l of enterprise IT in-

frastructure.4

The potential consequences—economic, technical, and social—of this

development a re indeed significan t. Two sma ll exa mples will illustra te th is point. One

ERP implementa tion enabled a 70%reduction in a ccounting personnel by eliminating

duplicate data entry and many consolidation tasks (Larsen & Myers, 1997). And ana-

lysts have speculat ed that w idespread adoption of the same ERP package by the firms

in a single industry (an observed phenomenon for semiconductor manufacturers)might lead to the elimination of process innovation–based competitive advantage

(Da venport, 1998).

Despite the potential benefits of widespread IT renewal, the process to date

ha s been fa r from smooth. Some organ izations ha ve utterly failed in their at t empts

to insta ll ERP systems (Bulkeley, 1996). Others h ave a chieved some benefits despite

decidedly rocky beginning s (Cole-G omolski, 1998; S tedm a n, 1998a , 1998b, a nd 1998c;

St edman , 1999b). Ma ny h ave failed to a chieve the h oped-for fina ncial returns on their

ER P investment (KP MG , 1998; St edman , 1999a ).

Of course, companies have had similar difficulties with each new wave of infor-ma tion technology since the first m ain fra me syst ems (McKenney, Copelan d, & Ma son,

1995). It ta kes years a t best to realize some envisioned IT-enabled cha nges in orga ni-

zat ional processes a nd performance, and there are ma ny w ays to fail along the wa y.5

So

one wa nts t o know how, if at all, the enterprise system experience is similar to, or dif-

ferent from, experiences with any other type of information technology, such as

decision support groupwa re, an d w orkflow. In the I S field, theory a nd empirical find-

ings related to this question are highly dispersed. Similar concepts are discussed

under different names, such as implementation and adoption. Conceptually related

ideas ha ve generat ed literatures w ith little overlap; for example, the research litera-ture on IT impacts rema ins quite dist inct from the literat ures on system development

methodologies and on the pa yoffs from IT investment s. B ecause the ent erprise system

Chapter 10 175



experience cuts across all of these “islands of ideation,” it is t ime to ta ke an integrat ed

view. This chapt er a tt empts a n int egrat ion of th e diverse bodies of knowledge bearing

on the enterprise system phenomenon.

ENTERPRISE SYSTEMS

In t his section, we identify th e key chara cteristics of enterprise systems, list reasons

companies do and do not a dopt t hem, and summ arize arguments a bout w hy enter-

prise systems are an important topic for research. Enterprise systems are commer-

cial softwa re packages tha t ena ble the integrat ion of tra nsactions-oriented data an dbusiness processes throughout an organization (and perhaps eventually throughout

the entire interorganizational supply chain). In our definition, enterprise systems

include ERP softwa re and such relat ed packages as adva nced plann ing and sched-

uling, sales force automation, customer relationship management, and product con-

figurat ion. Organiza tions t ha t a dopt enterprise systems ha ve a wide ra nge of options

for implementation and ongoing operations, from do it yourself, through selective

external assistance, to total outsourcing.

CHARACTERISTICS OF ENTERPRISE SYSTEMS

Ent erprise systems ha ve several chara cterist ics, each w ith important implications

for the organ izations tha t a dopt them.

• Integration. Enterprise systems promise “seamless integration of all the in-

forma tion flowing through a company—fina ncial and accounting informat ion, huma n

resource information, supply chain information, and customer information” (Daven-

port, 1998, p. 121). However, it is extremely important to note that achieving this

integra tion depends on “configuring” (setting up) the system in part icula r wa ys. Con-figuration in this context

6means choosing which package modules to install and

setting s oftw a re para meters t o represent, for exam ple, the compa ny’s products, cus-

tomers, accounts a nd the par ticular a rra ngement of business processes, such a s cen-

tra lized or decentralized wa rehousing a nd purchasing. An a ddit ional importa nt part

of the configuration task is capturing configuration decisions and their rationale.

The quality of such documentation is essential to the organization’s ability to make

future changes efficiently a nd effectively.

• It is possible, especially in lar ge, complex orga niza tions, to configure enter-prise systems so that the benefits of integration are not achieved. For ex-

ample, companies may purchase and install only the “financials” modules of

an enterprise system, thus depriving themselves of the potential advantages

of integrating accounting data with sales, manufacturing, and distribution

dat a. F urthermore, an organizat ion ma y a llow each of its business units to

adopt a different enterprise system or to configure the same enterprise

system however they see fit, with the result that it is not possible to obtain

integra tion benefits fr om common purcha sing or better decision ma king.7

• Packages. Enterprise systems are commercial packages; that is, they arepurchased or leased from software vendors rather than being developed in-house




from scrat ch. This ha s tw o importa nt implicat ions for the organ izat ions th at ad opt

them.

• First, the I S life cycle is different.8 Rat her tha n designing a system to meetthe organization’s idiosyncratic ways of working, the adopters of an enter-

prise system often ad just the organiza tion’s w ay s of working to fit the package

(because modifying packages has numerous negative consequences). Conse-

quently, package a dopters sometimes forgo or curtail t he a na lysis of current

information requirements and business processes that is a hallmark of the

tra ditional I S life cycle. Fur thermore, the process of configuring a n ent erprise

system for an organization differs substantially from software programming.

P rogramming involves creating new softw ar e functionality. Configurat ion in-

volves ada pting th e generic functionality of a package to the n eeds of a pa rtic-ular organization (usually by setting parameters in tables). Configuration is

often performed by team s of end-users w ith IS specialists working primar ily

on infrastructura l issues.9

In other words, enterprise package implementation

obsoletes some of the IT skills commonly found in IT adopting organizations

a nd requires the acquisit ion of new skills. In part icular, enterprise systems put

a premium on skills related to (1) ma pping orga niza tiona l requirements t o the

processes and terminology employed by the vendor and (2) making informed

choices about the parameter setting.10

• Second, organizations that purchase an enterprise system enter into long-

term relationships w ith softwa re vendors. It is true tha t some organiza tions

purchase a n enterprise system with t he idea tha t t hey will modify the pack-

a ges to suit idiosyncratic needs. But doing so reduces th eir ability t o benefit

from vendors’ continued development of the pa ckages, and it m ay creat e de-

pendency on outside contractors who specialize in enterprise software cus-

tomizations. (Vendors generally do not undertake to support or maintain

customers’ modificat ions of their softwa re.) Consequently, ma ny orga niza -

tions depend on the vendor for continued enhancement of the package

(for example, redeveloping t he softw ar e for futur e computing a rchitectures).

As a result, purchasers of an enterprise system ma y need to become active in

user orga nizat ions, a mecha nism by wh ich softw a re buyers collectively try to

influence the vendor’s plans for pa ckage maint enan ce an d enhan cement. B e-

cause of their dependence on vendors, organizations are vulnerable in the

event th at their chosen vendor goes out of business or lacks th e resources for

continued technical development. Furthermore, they are committing them-

selves to upgrading the softw a re periodically if th ey hope to a void ma jor con-

version headaches.11

• Best Pra cti ces. B ecause t hey are designed to fit t he needs of many orga niza-

tions, enterprise systems are built to support generic business processes that may

differ quite substantially from the way any particular organization does business.

B y ta lking to many businesses a nd looking to academic theory (or t o AP ICS )12

about

the best way to do accounting or manage a production floor, the vendors of enter-

prise systems have crafted what they claim to be “best practices.”13

B est practices

represent a powerful reason to adopt enterprise systems without modifying them

because few organizations claim to have redesigned all their business processes for

cross-functiona l efficiency and effectiveness—wh ich wa s th e sta ted purpose of busi-ness process reengineering (Hammer, 1990). But to realize the advantages of the

Chapter 10 177



best practices embedded in enterprise systems, most a dopting organ izations must

commit themselves to some degree of business process reengineering (Connolly,

1999).14

• There is great debate a bout t he relative a dvan ta ge of doing business process

reengineering15

before, during, or after enterprise system implementation.

But there is general consensus that business process change adds consider-

ably to the expense a nd risk of th e implementa tion of enterprise systems. The

principal reason is the difficulty of man aging la rge-scale huma n a nd organi-

zational change. For example, four business functions are involved in the

early phases of aircraft design and manufacture: contract management,

project a ccounting, project ma na gement, an d estima ting. In tra ditionally or-

gan ized aerospace firms, t hese four functions ma y be performed by differentorganizat iona l units wit h consequent recycling and la yers of approval. B aa n’s

software for aerospace and defense industries requires (by means of screen

design and software processing logic) that all four functions be performed by

an “integrat ed product tea m” comprising all four sets of skills. Ent erprise sys-

tems ha ve many such embedded business pra ctices, the details of which may

var y from vendor to vendor. Some orga nizat ions rebel aga inst t he inflexibility

of these imposed business practices; even when organizational leadership

accepts the need for change, the process of implementing enterprise systems

can involve considera ble cha nge in organ izat iona l stru cture, job design, w orksequencing, tra ining, an d so on.

• Some Assembly Requi r ed. At one level, the claim of enterprise syst ems to be

“integrated” is wildly overstated. What is integrated is the software, not the com-

puting platform on which it runs. Empirically, enterprise system–adopting compa-

nies have had grea t difficulty integrat ing their enterprise softwa re with a package

of hardware, opera t ing systems, da tabase management systems sof tware , and

telecommunications suited to their particular organizational size, structure, and

geographic distribution.16

And this is only one of the integration challenges associ-

at ed with enterprise systems. Mar keting claims a side, in today’s sta te of the art , no

single enterprise syst em meets a ll the informa tion-processing needs of th e majority

of organ izat ions.

• In m an y cases, enterprise system–adopting organ izat ions w ill need to inter-

face the package to the company’s own proprietary “legacy” systems, for

wh ich the enterprise system does not provide a n ad equa te replacement. The

organizations may also need to acquire and interface the package to any

number of “bolt-on” applications from third-party vendors for various tasks. 17

Sometimes the adopting organization may t urn to a t hird party tha t ha s inte-grated the enterprise package around the special needs of a particular in-

dustry segment.18 Finally, some organizations adopt a “best-of-breed” strategy

in wh ich th ey try to integrat e severa l enterprise packages from different ven-

dors, ea ch designed to be the best fit in its class w ith t he needs of the adopting

organizations. Examples of companies that have adopted the best-of-breed

approach are American St a nda rd Companies (B a shein et a l., 1997) a nd St ar -

bucks (Ara gon, 1997).

• Evolving. Fina lly, like a ll of IT, enterprise syst ems a re ra pidly chan ging.

First , they are changing architectural ly. In the 1980s enterprise systems weredesigned for the main fra me syst em ar chitecture. Today, they ar e designed for




client -server a rchitectures. S ome vendors ha ve just r elea sed Web-ena bled versions

of the software; most vendors have object-oriented versions under development.

B aa n is pursuing a stra tegy of “componentizat ion,” consist ing of an open backboneto w hich th e offerings of other vendors can be connected. The funct ional i ty of enter-

prise syst ems is a lso evolving. Today, ent erprise softw a re vendors a re releasing ex-

tensions to their core products19

designed to handle “front office” (i.e., sales man-

agement), “supply chain” (i.e., adva nced planning a nd scheduling), dat a wa rehousing,

specialized vertical industry solutions, and other functions. Enhancements such as

customer relationship management and electronic commerce are in the works. Ser-

vice ar r angement s are also changing. Some services firms offer packaged implemen-

ta tion services; others (often ca lled applicat ion service providers) a re offering ongoing

enterprise software functionality on an outsourced basis. Enterprise systems terminology will undoubtedly change, too; only time will tell whether the extensions con-

tinue to be identified a s something different from enterprise systems or are eventu-

ally folded into the enterprise system rubric.

• However things ar e called, ma ny people now regard enterprise systems (or

enterprise integrat ion a chieved in other wa ys) as the organizational infra-

structure that will support future value-generating applications, such as

linking the organization’s operations with those of suppliers and customers,

leading to substa ntia l reductions in duplicated a ctivit ies across f irms.

REASONS FOR ADOPTING ENTERPRISE SYSTEMS

Given the richness of enterprise systems in terms of functionality and potential

benefits to adopting organizat ions, it should not be surprising tha t companies a re

adopting these systems for many different reasons20

(Ross, 1999). S ome compan ies

have largely technical reasons for investing in enterprise systems. Examples are

the desire to reduce mainframe system operating costs, the need to solve the Y2K

an d similar problems, th e need for increased systems capacity to ha ndle growt h, orthe need to solve the maintena nce heada ches a ssociat ed with a ging legacy systems.

Other companies give largely business rea sons for ad opting ent erprise systems. For

exam ple, the company ma y need but not ha ve, due to limitat ions in its legacy sys-

tems, the a bility to present “one face to the customer” or to know wh ether it ha s fin-

ished goods inventory or planned production capacity “available to promise” to the

customer on a regional or global basis. Many companies have both technical and

business reasons for a dopting enterprise softwa re.

B oth small a nd lar ge compan ies can benefit both t echnically and st ra tegically

from investments in enterprise systems. Generally, the needs and opportunities ofsma ll companies a re a subset of those facing la rge companies. For example, in addi-

tion to problems stemming from unintegrated legacy applications, large companies

(particularly those that have grown through acquisit ion or have had a highly

decentra lized IT ma na gement regime) ma y a lso ha ve the heada ches of mainta ining

ma ny different systems of the sa me applicat ion t ype. In large companies, it is not

unheard of to find, say, 42 different general ledger packages or 22 separate pur-

chasing a pplicat ions in use a t t he t ime of adopting a n enterprise system. Boeing, for

example, had 14 bill-of-material systems and 30 shop-floor control systems before

th e company a dopted ERP (Schn eider, 1999). (See Ta ble 10.1 for a sum ma ry ofreasons th at companies give for adopting enterprise systems.)

Chapter 10 179



It is important to take into account these wide variat ions in motivation to

adopt enterprise systems when attempting to assess or explain their impacts anddownstream consequences. Some goals are much more ambitious than others; if

companies are like people, those with more ambitious goals are likely to achieve

more than companies w ith less a mbitious goals, but t hey a re less likely to realizetheir full aspirat ions, a nd t hey ma y encounter ma ny more difficult ies along the wa y.

Furth ermore, enterprise systems ma y be better suited to realizing some goals tha nothers. For example, the largest companies may face technical capacity constraint s

that prevent full data integration. Clearly, what companies think they are aboutwhen they adopt enterprise systems must figure somehow in the ways they ap-

proach the ent erprise system experience a nd in t he outcomes th ey achieve.

REASONS FOR NOT ADOPTING ENTERPRISE SYSTEMS

Of course, not all organizations adopt enterprise systems, even when they have

some or all of the listed motivations for adopting. Some who do adopt enterprise


TABLE 10.1 Reasons for Adopting Enterprise Systems

Sm all Comp anies/ Large Comp anies/

Simple Structures Complex Structures

Technical reasons • Solve Y2K and similar problems Most small/simple company• Integrate applications cross- reasons plus

functionally • Consolidate multiple different• Replace hard-to-maintain systems of the same type

interfaces (e.g., general ledger packages)• Reduce software maintenance

burden through outsourcing• Eliminate redundant data entry

and concomitant errors anddifficulty analyzing data• Improve IT architecture• Ease technology capacity

constraints• Decrease computer operating

costs

Business reasons • Accommodate business growth Most small/simple company• Acquire multilanguage and reasons plus

multicurrency IT support • Provide integrated IT support

• Improve informal and/or • Standardize differentinefficient business processes numbering, naming, and

• Clean up data and records coding schemesthrough standardization • Standardize procedures across

• Reduce business operating and different locationsadministrative expenses • Present a single face to the

• Reduce inventory carrying customercosts and stockouts • Acquire worldwide “available

• Eliminate delays and errors in to promise” capabilityfilling customers’ orders • Streamline financial

for merged businesses consolidations• Improve companywide

decision support



systems choose to use only certain modules, relying on legacy systems or new

custom development for th eir rema ining needs. And some wh o do ad opt discontinue

implementing or using th ese systems for a variety of reas ons.21

One reason for nonadoption, par tia l a doption, or discontinuan ce is l ack of “featur e-

function fi t” between the compan y’s needs and t he packages ava ilable in the mar ket-

place. “There ar e very few compa nies tha t don’t hav e specialized processes dicta ted by

their industry,” according to one consultant (Sla ter, 1999). Many E RP system ma nu-

facturing m odules were developed for discrete part ma nufacturing; t hese systems do

not s upport some processes in process ind ust ries (e.g., food, paper), project ind ust ries

(e.g., aerospace), or industries manufacturing goods with dimensionality, such as

clothing a nd footw ear. When organiza tional size an d scale of operations a re ta ken into

account, t here simply ma y be no commercially a vaila ble package suita ble for a pa rtic-ular organization.

More commonly, the organization may choose to adopt only certain parts of an

enterprise system or may modify the system to improve feature-function fit. Con-

sider examples of the implementa tion of SAP R/3 from Visio (a s oftwa re compa ny)

(Koch, 1997). The first example concerns “deferred channel revenue.” The article

implies that Visio met this need with legacy code.

Many software companies “dump” extra product with distributors at the close of a

quarter so that they can pump up weak sales revenue totals. The downside of the

strategy is that some of the extra software may flood back to the company in unsoldreturn s. . . . To break th e cycle, Visio tracks sa les through t o the reta il outlets an d com-

pares the retail sales with the number of units shipped to distributors each month. If

the r eta il stores sell less tha n Visio ant icipat ed, Visio defers some of the revenues from

the sales . . . ; if sales are up, it adds back some deferred revenues from previous

months. . . . Unfortunately for Myrick and the Visio team, it ’s a complex and fairly

unique w ay of handling r evenues—tw o att ributes tha t rea lly an noy R/3. (Koch, 1997)

The second sit ua tion in w hich S AP R/3 did not m eet Visio’s needs concerns

Visio’s m ethod of ha ndling invent ory.

Visio outs ources its ma nufa cturin g. . . . But R/3 doesn’t let compa nies tr a ck somet hing

they don’t own outrigh t, a nd it doesn’t recognize inventory tha t ha s no assigned value,

like trial softwa re, mar keting ha ndouts a nd other freebies. The consulta nts offer Visio

two massively unpopular choices: Visio could assume ownership of the inventory

thr oughout t he ma nufa cturin g cycle, or it could send t wo invoices . . . [to customers]. . . .

[The consultant ] agrees to a bsorb the cost of fixing the inventory own ership process,

ultima tely conceding tha t sending tw o invoices to customers each month w as una ccept-

able. (Koch, 1997)

The consulta nts a pparently found a w ay to cha nge the process w ith a bolt-on tha tdid not require expensive and risky modificat ion of the SAP code itself.

In addition to the lack of feature-function fit, a second major set of reasons for

nonadoption, partial adoption, or discontinuance of enterprise systems concerns com-

pany growth, stra tegic flexibility, a nd decentra lized decision-ma king st yle. Dell Com-

puter Corp., for inst an ce, planned full implementat ion of SAP R/3 but st opped a fter

the HR module. The CIO claimed that the software would not be able to keep pace

with Dell’s extraordinary growth rate (Slater, 1999). Visio cited strategic flexibility as

a reason for performing sales commission an alysis outside of its enterprise system:

“I wa nted to reta in the flexibility to cha nge the commission structure wh en I needed tobecause it ’s such a crit ica l process . I t wa s my und erstanding tha t i t might ta ke awh ile

to do tha t w ithin SAP and t hat once it was done, it w ouldn’t be so easy to change.”

Chapter 10 181



B ecause the commission str ucture is so closely linked to the orga nizat ional stru cture of

the sales gr oups, B uckley a nd My rick decided to keep commissions a na lysis out of R/3.

(Koch, 1997)

Companies that continually change their organizational structures and business

models and particularly those that are not run “in a very top-down manner” may

find enterprise systems unsuitable as a corporate solution (Bancroft , Seip, &

Spr engel, 1997).22

For exam ple, a t K ra ft F oods Inc., a highly decentra lized company

that is gradually moving toward a “one-company” philosophy, enterprise systems

were viewed a s a cultura lly inappropriate stra tegy for systems integra tion (B ash ein

& Markus, 2000).

A third fa ctor in the nonadoption of enterprise systems is the ava ilability of

alternatives for increasing the level of systems integration. Data warehousing, abundle of technologies tha t integrat es da ta from m ultiple source systems for query

and analysis, provides what some describe as the “poor man’s ERP.” The usefulness

of data warehousing as an integration strategy is limited by the quality of the

source syst ems. Neverth eless, it ca n provide enormous relief for some organiza tions

suffering from some of the technical problems shown in Ta ble 10.1. Da ta w a rehousing

wa s the integra tion stra tegy favored by Kra ft Foods Inc. (B as hein & Mar kus, 2000).

Another alternative to enterprise systems involves rearchitecting in-house

systems a round a layer of middlewa re tha t isolates applicat ion systems from stores

of “mast er dat a.” When Dell aba ndoned SAP R/3 as its integrat ion stra tegy, thecompany “designed a flexible middleware a rchitecture to a llow the company to a dd

or subt ract applicat ions q uickly an d selected softwa re from a variety of vendors . . .

to handle finance and manufacturing functions” (Slater, 1999). Consultants say

that rearchitecting systems with middleware is a viable alternative to enterprise

systems when a company is basically satisfied with its software functionality and

wants only to improve software integration and upgrade the user interface. This

stra tegy is w idely a dopted in t he financial services indust ries, where enterprise sys-

tems ha ve made relatively few inroads (other tha n for administra tive systems).

Discussions of reas ons for not adopting enterprise systems usu a lly conflat e th eissues just mentioned above with three other issues—cost, competitive advantage,

a nd resist a nce to chan ge. For exam ple, Allied Wa ste recently a nnounced plans t o

“pull the plug” on a $130 million computer system (Bailey, 1999). The reason given

wa s tha t S AP wa s “too expensive and t oo complicat ed to operate.” Yet it a lso seems

clear that the software no longer fits the management style and structure of the

company, as it presumably did at the t ime the decision to adopt SAP wa s ma de. Ap-

par ently, Allied Wa ste grew ra pidly in the 1970s and 1980s w hen th e firm wa s a c-

quiring hundreds of tra sh ha ulers. When industry profits suffered, the compan y re-

sponded by cost cutt ing th rough centra lized opera tions, a st yle of ma na gement wellsupported by S AP. Today, the company is m oving towa rd much grea ter ma na gement

decentra lization. In th is case, cost reasons, it seems, are t ightly bound up wit h is-

sues of ma na gement culture.

Some ana lysts ha ve cited competit ive adva nta ge as a ma jor reason for not im-

plementing enterprise softwa re (Davenport, 1998). H ere, too, it is difficult to disen -

tangle competitive advantage from explanations based in fit. If a company claims it

will lose competitive ad va nta ge from ad opting a n enterprise system, it is also saying

tha t it does things differently th an the enterprise system does. The question here is

wh ether lack of fit reflects a n organ izat ion’s “value-a dding best pra ctice” (a lbeit dif-ferent from best pra ctices in the softwa re) or a costly inefficiency tha t th e orga niza tion




is cultura lly unw illing to give up. Not surprising, vendors a re more likely to cite “re-

sista nce to change” (or “lack of top man ag ement commit ment”) tha n th ey are to cite

“competitive advantage” or “lack of feature-function fit” as a major reason for non-ad option of enterprise systems. In practice, careful an alysis is necessar y t o determine

wh ether or not a n enterprise system is a good solution in a part icular sit uat ion—and

what the scope of the implementation project should be.

RECAP—IMPORTANCE OF ENTERPRISE SYSTEMS

Ent erprise systems a re an importa nt t opic for IS research for several reasons.

1. Fi nan cial Costs and Risks. Inst alling a n enterprise system is a n expensive

and risky venture. Large companies have been spending on the order of hundreds of

millions of dollars to make the technical and business changes associated with enter-

prise systems. There ha ve been several visible enterprise systems fa ilures, and nonaca-

demic studies have questioned the financial and business payoffs from enterprise

system projects. Therefore, enterprise systems raise questions that have long been

studied in t he IS field under t he following labels: the pa yoffs from investment in infor-

mation technology,23 IS project success and failure,24 and IS implementation process

and change mana gement

25

(training,

26

user involvement, communication, etc.).2. Techni cal I ssues. Enterprise systems are technically challenging. Among

the more importa nt t echnical a reas of research a round enterprise systems ar e the

“development” life cycle for enterprise system packages; software selection ap-

proaches; enterprise modeling and software configuration tools and techniques;

“reference models” for particular industry segments, systems integrat ion st rat egies,

and systems and software architectures; and data quality , reporting, and decision

support for enterprise systems.

3. Manageri al I ssues. Enterprise system projects are managerially challenging

since they may involve parties from many different organizations and cut across thepolitical structures of the organization. Furthermore, enterprise systems have im-

portant implications for how companies should organize and manage their informa-

tion systems functions. Finally, enterprise systems raise interesting challenges in

terms of personnel and skill acquisition a nd r etention. Therefore, the followin g a reas

of resea rch a re invoked by ent erprise systems: I T project ma na gement ;27

IT project

sponsorship and user involvement; IS-business relationships, vendor management,

structuring the IS function and IT management more generally, and IS personnel

management .28

4. I T A doption, Use, and I mpacts. Ent erprise systems h ave been widely adoptedacross orga nizat ions, a nd t he ad option of these technologies may spread furt her. How-

ever, it is not yet known how widely these technologies have been assimilated

(Fichman & Kemerer, 1997)29

in organiza tions, for example, how extensively th ey ar e

used within the organization, how faithfully they are used, and how effectively they

are used. Furthermore, these systems have large potential impacts30

at all levels of

an alysis: individua l a nd societa l (employment, occupat iona l stru cture, skills required,

and quality of work), work system (cooperation, business process efficiency), organi-

zational (competitive advantage, business results), and interorganizational (impact

on supply chain, industry structure). For example, at the individual level, enterprise sys-tems may entail a substantial increase in the visibility of an individual’s performance,

Chapter 10 183



leading to changes in the accountability and control regimes in the organization. In

add ition t o the general topics of IT ad option, use, and impacts, enterprise systems a re

linked to research on business process reengineering, interorganizational informationsystems, a nd t he stra tegic use of informat ion t echnology.

5. Integration. Finally, enterprise systems suggest some unique questions not

easily subsuma ble within existing bodies of informa tion systems research. First , to

wha t extent a re enterprise systems bound up in a complete restructuring of organ i-

zations and industries around the capabilities of information technologies? Second,

to wha t extent are w e observing a structura l change in the provision of IT services,

from predominantly in-house to predominantly outsourced? What is the emerging

role of the so-called system integrators (such as Andersen Consulting and IBM)?

How should organizations manage a long-term IT development trajectory involvingheav y dependence on externa l products a nd service companies? Third, w ha t a re the

pros a nd cons of the enterprise syst ems a pproach vis-à-vis other st ra tegies for a chieving

integrat ion a round informa tion technology, such a s rea rchitecting systems around

middleware a nd t he object d evelopment para digm or the looser integrat ion st rat egy

implied by dat a w ar ehousing?

In short , the enterprise system phenomenon ha s st rong conceptual links with

just a bout every ma jor a rea of informa tion systems research. In a ddit ion, the phe-

nomenon suggests the potential value of entirely new research directions.

The enterprise system phenomenon is so all-encompassing for organizationsand their key business partners that it virtually demands a framework by which to

understa nd it a s a wh ole. As suggested, many bodies of literat ure and, hence, many

theories are relevant to understanding important pieces of the enterprise system

phenomenon, but w ha t is lacking is an overa rching framework within w hich many

specific questions can be asked and their answers integrated. Our purpose in the

remainder of this chapter is to propose such a framework. The framework is de-

signed around the perspective of an enterprise system–adopting organization.31

That is, the framework is designed to shed light on the questions facing the execu-

tive leadership of a n organiza tion considering whether, why, and how t o participat e

in the enterprise system experience and w ha t to do at various points in the process.

FRAMING THE ANALYSIS OF ENTERPRISE SYSTEM SUCCESS

This section sets u p the description of our fram ework. We first a ddress t he quest ions

the fra mework is designed to answ er: Wha t is success w ith ent erprise syst ems? Why

does success not always occur? What can be done to improve the chances of success?In other w ords, success is the key outcome of interest in our fra mework. In aca demic

terms, it is our dependent variable.32

More specifically, we define the success out-

come as a multidimensional concept, a dynamic concept, and a relative one (to the

concept of “optimal success,” representing the best an organization can hope to

achieve with enterprise systems). Next, w e briefly review severa l broad ca tegories of

theoretical perspectives that purport to explain how and why enterprise systems

success occurs. Of thr ee ca tegories of theories, we choose th e “emergent pr ocess” t ype

and, in particular, a specific theory of the business value of information technology

as the basis for our framework. In the following section, we develop the frameworkmore fully.




THE IMPORTANT OUTCOME:SUCCESS WITH ENTERPRISE SYSTEMS

KP MG Ma na gement Consulting’s recent report Profi t-Focused Softw ar e Package Imp le-

mentation showed some worrying results. Eighty-nine per cent of respondent companies

claimed t hat their projects were successful, but only a qua rter ha d actua lly obta ined and

qua ntified all t he planned benefits. (KP MG, 1998)

To us, this quotation illustrat es a funda mental ga p in both pra ctical a nd a ca-

demic thinking about information systems—lack of consensus and clarity about the

mean ing of “success” w here informa tion systems a re concerned. People rar ely define

terms su ch as success and fa ilure; when th ey do, they invite endless complaint s. For

instance, one article in the trade press criticized a nonacademic study of enterprisesystem success for defining a project as a failure if project goals changed within a

year (Ferranti, 1998).33

Furthermore, people legitimately use a number of different

definitions of success. As the KPMG quotation suggests, one can define success

in terms of the implementat ion project (did th e compan y succeed in getting the syst em

up an d runn ing w ithin some reasonable budget a nd schedule?) or in terms of business

results (did t he compa ny s ucceed in r ealizing its business goals for t he project?). The

same ambiguity is clear in academic writing on the topics of information systems

success a nd/or effectiveness. For exa mple, one of th e few a cadem ic studies of a n en-

terprise system experience to da te shows tha t success can look very different w henexamined at different points in time, on different dimensions, or from different points

of view (Larsen & Myers, 1997).34

Our purpose is not to argue that one definition of success is inherently supe-

rior to an other. Instea d, we a re claiming, first , t ha t t he key questions a bout enter-

prise systems fr om th e per spectiv e of an adopti ng organ i zati on’s executi ve leader ship

are questions about success , for example: Will our investment pay off? Did our

investment pay off? How sh ould w e go about implementing enterprise systems to

a chieve our goa ls? Wha t can we do to increa se the chan ces for success an d a void the

risk of failure? Second, w e are claiming t ha t no one measur e of enterprise system

success is sufficient for all the concerns an organization’s executives might have

about the ent erprise system experience. Inst ead, enterprise systems–ad opting orga-

nizations require a “balanced scorecard” of success metrics addressing different di-

mensions (financial, technical, human) at different points in time. Based on our ob-

servations of enterprise systems projects, w e a rgue tha t a minimum set of success

metr ics includes th e following:

• Pr oject M etr ics. P erforma nce of th e enterprise system project team aga ins t

planned schedule, budget, and functional scope. These are the classic performance

measures applied t o project ma na gers.• Ear ly Operat ional M etr ics. How busin ess operat ions perform in the period

after the system becomes operational until “normal operation” is achieved. Specifi-

cally, these metrics include some normally used to track the business as well as

some unique to enterprise systems. Examples include labor costs, time required to

fill an order, customer calls unanswered, partial orders filled, orders shipped with

errors, inventory levels, and so on. Although the “shakedown phase” of an informa-

tion systems project is tra nsit ional by definit ion, it is crit ically importan t for t he im-

plementing organization for several reasons, some of which have been well docu-

ment ed by oth ers (Tyre & Orlikow ski, 1994). When t he bus iness perf orms ver ypoorly during the sha kedown phase, th e organizat ion m ay lose business, sometimes

Chapter 10 185



permanently, when the organization has yet to experience any major benefits to

offset the large up-front investment. Exceedingly poor performance can lead to in-

ternal or external pressures to disinstall the system and in extreme cases can t ipthe orga niza tion int o bankr uptcy, a s ha ppened t o Fox-Meyer Dr ug (Bulkeley, 1996).

Consequently, organizations should include early operational performance in their

definit ion of enterprise system success a nd s hould a ggressively ma na ge to minimize

early operat ional problems a nd t o resolve them qu ickly.

• L onger -Term B usin ess Resul ts. How the organization performs at various

times after normal business operation has been achieved. Examples of relevant

metrics include return on investment, a chievement of qualita t ive goals such as “one

face to the customer,” better ma na gement decision ma king at tr ibuta ble to higher-

qua lity da ta , continuous improvement of business metrics after opera tions returnto normal, maintenance of internal enterprise system competence (among both IT

specialists a nd end users), eas e of upgrading to lat er versions of the enterprise system

softw ar e, and so on.35

The foregoing discussion makes it clear that the success (or failure) of enter-

prise systems is not a monolithic concept. R at her, it is multidimensiona l a nd r ela-

tive. It is relat ive, first , to the t ime at which it is assessed. For example, in our

conversat ions w ith executives a nd int egrators, w e identified some companies w ith

disast rous project a nd sh akedown m etrics but high levels of subsequent business

benefits from enterprise systems. Conversely, we found companies with acceptableproject and shakedown metrics that could not identify business benefits from in-

stalling the system. Similarly, an enterprise system that gives competit ive advan-

tage today may not do so tomorrow when competitors catch up and having such a

syst em becomes a cost of doing business (McKenney et a l., 1995).

Second, success is often judged relative to the organization’s unique goals for

the syst em. Two organiza tions wit h identical improvements in inventory carrying

costs can be judged successful in different wa ys if t he one’s goals w ere to replace its

legacy systems (more successful than expected) and the other’s were to achieve an

increase in ma rket sha re (less successful tha n expected). At t he sa me time, th e com-pany’s goals, taken alone, make a poor standard against which to judge success.

First , t he company’s goals ma y be insufficiently a mbitious if they a re compared t o

the inherent capabilit ies of enterprise systems a nd how w ell the orga nizat ion needs

to perform given its competitive position. For example, a company that is losing

ma rket sha re because it cannot promise delivery on a global ba sis would be “leaving

money on the table” if it adopted an enterprise system solely to solve the Y2K

problem and implemented it so that available-to-promise capability was not pos-

sible.36

For a nother example, highly decentra lized businesses ma y a chieve less t ha n

is theoretically possible with enterprise systems if they configure the software sotha t ea ch product business unit presents its own separ at e face to the customer. Con-

versely, the success of a company that achieved more with an enterprise system

tha n it expected at the outset should be judged a gainst a higher sta nda rd of perfor-

mance than its unambitious goals. It might better be judged against the average

business benefits realized by similar firms in its indust ry.

To a ccommodat e th e multidimensiona lity a nd relat ivity of enterprise syst em

success from the adopting organ izat ion’s perspective, w e define a sta nda rd of optimal

success, which refers to the best outcomes the organization could achieve with en-

terprise systems, given it s business situa tion, measured a gainst a portfolio of proj-ect, early operational, and longer-term business results metrics. Optimal success




can be far more or less tha n th e organ ization’s goals for an enterprise system. Fur-

thermore, optimal success can be dynamic; wha t is possible for an organiza tion to

achieve may change over ti me as business conditions change. What we want theframework to help us predict or explain is an organization’s actua l achi evement of

a n enter pr i se system’s success (a scorecard of measures, assessed relative to optimal

success—the best possible outcome). Looking ahead to the framework itself, we

hope to show how and why an organization’s decisions or actions at one point in

time (e.g., during th e “project”) can r esult in optima l (or less tha n optima l) outcomes

subsequently (e.g., during “shakedown”).

We realize tha t orga niza tions do not usua lly set out to achieve optima l success

wit h informa tion technologies; good enough is us ua lly good enough. We also rea lize

tha t optimal success is a th eoretical abstr action tha t ma y be neither a chievable inpra ctice nor mea sura ble in empirical resea rch. Nevertheless, w e believe the concept

is theoretically useful because it “factors in” unintended positive and negative con-

sequences of enterprise system adoption and organizational realit ies that are not

fully reflected in the organization’s enterprise system goals.

THEORETICAL PERSPECTIVES ONENTERPRISE SYSTEM SUCCESS

Ha ving defined th e outcome of interest , we need a t heory to explain it. An a ccepted

classificat ion scheme (Markus & Robey, 1988, derived from Kling, 1980, a nd P feffer,

1982) par ses a cademic t heories of IT-relat ed outcomes int o rat ional a ctor, externa l

control, and emergent process theories. Rational actor theories emphasize the

great , but bounded, ability of organizations and decision makers to realize their

goals. An example of such a theory is the technology acceptance model (Davis,

Bagozzi, & Warshaw, 1989),37

which includes the factors that enter into an indi-

vidual’s choice of technology for part icular ta sks w hen fa ced w ith a lternat ives. On

the plus side, rat ional a ctor th eories highlight peoples’ motivations a nd th e actionsth ey ta ke to achieve th eir goa ls. Therefore, these th eories tend t o be very a ppealing

to practit ioners. A dra wba ck of ra t ional actor theories is tha t t hey downpla y influ-

entia l forces beyond t he decision ma ker’s contr ol; furt hermore, these t heories a ccept

ma nagers’ goals a s givens w ithout questioning their suitability relat ive to external

constraints.

The second type of theory—external control theory—emphasizes the inex-

orable environment a l forces, such a s th e tra jectory of technologica l development or

competitive ind ustr y forces. Academics employ externa l cont rol theories when th ey

claim that information technology alters industry structure or changes decision-ma king processes in a n organ ization. As trength of external control theories is t heir

explicit acknowledgment that organizations and people have less than perfect

ability t o make their goals a reality ; on the downside, they minimize the ability of

exceptional people and compa nies to cha nge our world.

The third type of theory—emergent process—emphasizes the often unpre-

dictable interactions between people in organizations and the environment. Emer-

gent process theories a ssume th at people try to a chieve goals but a cknowledge tha t

the outcomes are often different from those intended—sometimes better and some-

times w orse. E xternal forces sometimes ma ke a mockery of peoples’goals a nd a ctions,but sometimes the forces line up to favor th e most unlikely goals. A prominent

Chapter 10 187



example of an emergent process theory in the IS field is structuration theory (De-

Sa nctis & P oole, 1994; Orlikows ki & Robey, 1991). A str ength of emergent process t he-

ories is tha t t hey account for mutua l influences between the organiza tion and it s en-vironment. Weaknesses include th eir greater explana tory th an predictive power an d

the prominent role they assign to chance: Decision makers prefer prescriptive models

that favor skill more than luck and that promise successful outcomes to those who

follow th e rules.

For a theory to be useful to practit ioners, it must address their goals and

“motivated behavior” (actions they can a nd do take w ith th e intent to achieve their

goals).38

For a theory to fit th e facts (not a ll companies a re successful with enter-

prise systems, a nd not a ll the blame can be la id to their goals or a ctions), it must

a lso a ddress relevan t fa ctors tha t lie outside peoples’ direct control. (For exa mple,did the vendor actu a lly deliver on the promise to relea se required functionalit y on a

specified date? Is the software sufficiently bug free to support reliable operations?)

Because emergent process theories combine goals and actions with external forces

and chance, we chose this theoretical structure for modeling the enterprise system

experience.

More specifically, we build our framework on a particular emergent process

theory designed by Soh and Markus (1995) to explain how information technology

creates (or fa ils to crea te) business va lue.39

This t heory cont ributes thr ee key points

to an understanding of the success of enterprise systems. First , it argues that thenecessa ry conditions for a s uccessful outcome (in th eir model, high-qua lity informa -

tion technology “assets”) are not always sufficient for success. Occasionally, an IT

investment on track for success is derailed by an external event (e.g., competitors’

responses) or changing external conditions (e.g., recession). Chance and random-

ness can play an importa nt role in the outcomes a chieved.

Second, the Soh a nd Ma rkus (1995) fra mew ork describes the “IT investm ent t o

business value” process as a series of three linked models that correspond to the

phases of a typical IT investment, roughly speaking, system development, imple-

mentation, and ongoing operation. (See Figure 10.1.) The outcomes of one phasebecam e sta rt ing conditions for t he next. Thus, decisions a nd a ctions in a phase ma y

increase or decrease the potential for success (“optimal success”) subsequently.

Furthermore, because each phase generally involves different groups of people, the

framework directs a ttention to communication difficulties tha t a ccompany “the ha nd-

offs” from one phase t o the next.

Third, the Soh and Markus (1995) framework explains the outcomes of each

phase a s result ing from intera ctions betw een external conditions a nd t he a ctivit ies

tha t cha ra cterize the pha se. This mean s th at both un controllable events a nd choiceful

huma n a ctions can influence outcomes. At t he sam e time, events an d a ctions ma y beunsynchronized, and delayed effects may result in unresolved problems (or even op-

portunities) requiring action down the road. Thus, problems can accumulate, cas-

cading towa rd a wildly unsuccessful outcome.

Tw o importa nt cha nges a re needed to adopt the S oh and Ma rkus (1995) fra me-

work to the enterprise systems experience. First, the outcome variables need to be

changed from business value (and other intermediate outcomes) to success as de-

fined earlier. Second, th e framework requires the a ddit ion of an init ial pha se tha t

includes the important organizational decisions and actions before the project offi-

cially starts. In many organizations, executives, technical specialists, and consul-tants can spend considerable t ime (and money) making decisions about whether,




why, and how to undertake enterprise systems. For instance, any of the followingma y occur before a project ma na ger is nam ed and a budget is approved: documenting

current business processes, analyzing the potential for improvement, comparing

processes w ith the “r eference models” or “best practices” embedded in ent erprise sys-

tems softw ar e, selecting softw a re, deciding wh ich softw a re modules to implement in

what sequence, and deciding how to roll out the new functionality to various busi-

ness units. Therefore, we identify a new first phas e, which we call chartering. The re-

maining three phases in the enterprise system experience cycle (the pr oject phase,

the shakedown phase, and the onwar d and upwar d phase ) correspond loosely to th e

thr ee pha ses in th e Soh a nd Ma rkus model (see Figure 10.2).In the next section, we describe our framew ork in greater depth.

THE DYNAMICS OF ENTERPRISE SYSTEM SUCCESS

An organization’s experience with an enterprise system can be described as moving

through several pha ses, cha ra cterized by key play ers, typica l activities, cha ra cteristic

problems, appropriate performance metrics, and a range of possible outcomes. Eachenterprise system experience is unique, and experiences may differ considerably,

Chapter 10 189

FIGURE 10.1 Soh andMarkus (1995) Model “The IT

conversion process”

IT management/conversion activities

ITexpenditure

Organizationalperformance

ITassets

ITimpacts

“The IT use

process”

“The competitive

process”

Appropriate/inappropriate use

Competitive positioncompetitive dynamics

Ideas todollars

Decisionsdefining thebusiness caseand solutionconstraints

Dollarsto assets

Assets toimpacts

Impacts toperformance

Gettingsystem and

end users “upand running”

Stabilizing,eliminating “bugs,”getting to normal

operations

Maintainingsystem, supporting

users, gettingresults, upgrading

Phase I

Projectchartering

Phase II

The project(configure& rollout)

Phase III

Shakedown

Phase IV

Onwardand

upward

FIGURE 10.2Enterprise SystemExperience Cycle



depending, for exam ple, on wheth er the a doption of the enterprise system is initia ted

by IS specia lists or by businesspeople, involves externa l consulta nt s or is done lar gely

in-house, follows a process of strategic IT business planning or business processreengineering or does not follow such a process, a nd so forth.

Ta ble 10.2 summ a rizes th e four “idea l” pha ses of the enterprise syst em experi-

ence cycle,40

and the phases are briefly described in the following section. It is im-

porta nt t o note tha t organiza tions recycle through the phases wh en they undertake

ma jor upgra des a nd/or repla cement s of their enterprise syst ems.

THE PHASES DESCRIBED

The Chartering Phase

The chart ering pha se comprises decisions lea ding up to the fund ing of an ent erprise

system. K ey players in th is phase include vendors, consulta nts, company executives,

and IT specialists, although the precise constellation of players may vary. (Some-

times vendors sell directly to company executives, with minimal IT involvement;

other times the decisions are driven by IT specialists, with minimal executive in-

volvement.) Key activities include building a business case for enterprise systems,

selecting a softwa re package (though th is decision ma y be deferred until t he project

phase), identifying a project ma na ger, and a pproving a budget a nd schedule. A large

number of errors or problems can a rise during t his pha se. The business case for in-

vesting in an enterprise system can be incomplete or faulty; the organization may

seriously underestima te the need for business a nd organiza tional cha nge in conjunc-

tion with the software implementation; objectives and metrics for the initiative may

be left undefined (Ross, 1999). The outcome of this phase may be a decision not to

proceed with the enterprise system or a decision to proceed. If the latter, the char-

tering decisions pa ssed on to the next pha se ma y be sound or unsound. An exam ple

of an unsound charter is a build-to-order company purchasing a n E RP packagedesigned for a ma ke-to-stock busin ess (Sla ter, 1999). Anoth er exa mple is t he decision

not to allocate sufficient resources for change management and training (Ross,

1999). A third is the decision of a d ecentra lized company t o require more sta nda rd-

izat ion of business processes tha n is necessa ry t o achieve business benefits (Da ven-

port, 1998). Still another is the choice of a highly inexperienced project manager.

The Project Phase

The project pha se comprises a ctivities int ended to get the sys tem up a nd ru nning inone or more organizational units. Key players include the project manager, project

team members (often nontechnical members of various business units and func-

tional a reas), internal I T specialists, vendors, an d consulta nts. Again, the constella-

tion w ill var y, depending on the decision t o do th e project in-house, wit h outside a s-

sistance, or on an outsourced basis. Key activities include software configuration,

system integration, testing, data conversion, training, and rollout. Again, a large

number of errors and problems can occur. P roject t eams m ay be sta ffed w ith ina de-

quate representation; teams may lack requisite knowledge and skills; teams may

embark on extensive, unnecessary modifications; data cleanup, testing, or trainingma y be ina dequa te. In a ddition, of course, the business conditions chara cterizing the

chartering phase may have changed: The company may have fallen into financial




C h a r t e

r i n g ( “ i d e a s

t o d o l l a r s ” )

• D e c i s i o n s l e a d i n g u p

t o p r o j e c t a p p r o v a l a n d

f u n d

i n g

• E x e c

u t i v e s , s e l e c t e d

I T s p

e c i a l i s t s , e n t e r p r i s e

s y s t e

m s v e n d o r , a n d / o r

c o n s

u l t a n t s ( m a y b e

I T d r

i v e n w i t h l o w

e x e c

u t i v e i n v o l v e m e n t

o r e x

e c u t i v e d r i v e n

w i t h

l o w i n - h o u s e

I T i n v o l v e m e n t )

•

I d e a o f a d o p t i n g

e n t e r p r i s e s y s t e m s

s u r f a c e d

•

B u s i n e s s c a s e f o r

i n v e s t m e n t d e v e l o p e d

( m a y b e h i g h l y

i n f o r m a l )

•

D e f i n i t i o n o f k e y

p e r f o r m a n c e i n d i c a t o r s

a n d p r o c e s s o f

m e a s u r e m e n t

•

C u r r e n t s t a t e a n a l y s i s

( m a y b e d e f e r r e d o r n o t

d o n e )

•

S e l e c t i o n o f s o f t w a r e ,

h a r d w a r e p l a t f o r m ,

n e t w o r k i n g , d a t a b a s e ,

i m p l e m e n t a t i o n

p a r t n e r , p r o j e c t

m a n a g e r ( m a y b e

p a r t i a l l y o r t o t a l l y

d e f e r r e d t o p r o j e c t

p h a s e )

•

I n i t i a l p l a n s f o r h o w

s y s t e m

w i l l b e r o l l e d

o u t , s u p p o r t e d , a n d

m a i n t a i n e d , u p g r a d e d ,

e t c . ( m a y b e d e f e r r e d )

•

C o m m u n i c a t i o n t o

o r g a n i z a t i o n

•

O r g a n i z a t i o n a l c h a n g e s

a n d / o r i n c e n t i v e s

r e l a t e d t o e n t e r p r i s e

s y s t e m

a n d / o r

o r g a n i z a t i o n a l

p e r f o r m a n c e

i m p r o v e m e n t , i f a n y

( m a y b e d e f e r r e d )

•

D e c i s i o n t o p r o c e e d ,

a p p r o v a l o f p r o j e c t p l a n

• O v e r s e l l i n g b y s o f t w

a r e

v e n d o r s a n d

i m p l e m e n t a t i o n

c o n s u l t a n t s

• F a i l u r e t o l i n k

t e c h n o l o g y p l a n t o

b u s i n e s s s t r a t e g i c p l a n

• U n r e a l i s t i c b u s i n e s s

c a s e a n d p r o j e c t

p a r a m e t e r s

• K e y p e r f o r m a n c e

i n d i c a t o r s n o t o r p o o r l y

d e f i n e d , i n c l u d i n g t h e

m e a s u r e m e n t p r o c e s s

a n d o w n e r s h i p o f t h

i s

• S e l e c t i o n o f

i n a p p r o p r i a t e s o f t w a r e ,

h a r d w a r e , i n t e g r a t o r ,

a n d / o r p r o j e c t

m a n a g e r ; i n a d e q u a t

e

c o n t r a c t i n g w i t h

e x t e r n a l p a r t i e s

• I n a d e q u a t e c o n t r a c t

i n g

w i t h v e n d o r s a n d


• L a c k o f l o n g - t e r m

s u p p o r t a n d m i g r a t i o n

s t r a t e g y

• F a i l u r e t o r e c o g n i z e

n e e d f o r b u s i n e s s

c h a n g e ;

u n d e r e s t i m a t i n g

c h a n g e m a n a g e m e n

t

d i f f i c u l t y

• M i s u n d e r s t a n d i n g


r e q u i r e m e n t s ,

p a r t i c u l a r l y a s r e l a t e

d

t o n e e d f o r d a t a a c c

e s s

a n d r e p o r t i n g

• N o t u s u a l l y f o r m a l l y

m e a s u r e d

• P o s s i b l e m e t r i c s

i n c l u d e q u a l i t y

o f

b u s i n e s s c a s e , f i t w i t h

b u s i n e s s s t r a t e g y ,

r e l e v a n c e o f k e y

p e r f o r m a n c e i n

d i c a t o r s ,

a d e q u a c y o f s c h e d u l e

a n d b u d g e t , s o

u n d n e s s

o f p r o j e c t p a r a m e t e r s ,

a n d c o n s t r a i n t s

• E n t e r p r i s e

s y s t e m s i d e a

a b a n d o n e d a s u n l i k e l y

t o p r o v i d e

b u s i n e s s

b e n e f i t s

• D e c i s i o n t o p r o c e e d

w i t h a p r o

j e c t w i t h

c e r t a i n p a r a m e t e r s

( s c h e d u l e ,

s c o p e , a n d

b u d g e t )

• B u s i n e s s

c a s e f o r

p r o j e c t i s u n s o u n d ,

c r e a t i n g

p o t e n t i a l

f o r p r o b

l e m s l a t e r

• B u s i n e s s

c a s e f o r

p r o j e c t i s s o u n d

T A B L E

1 0 . 2

T h e E n t e r p r i s e S

y s t e m E x p e r i e n c e C y c l e

b y P h a s e

P h a s e N a m e ,

T y p i c a l

D e s c r i p t i o n ,

C o m m o n E r r o r s

P e r f o r m a n

c e

P o s s i b l e

a n d K e y A c t o r s

T y p i c a l A c t i v i t i e s

o r P r o b l e m s

M e t r i c s

O u t c o m e s

( c o n

t i n u e

d

o n

t h e n e x

t p

a g e

)



P r o j e c

t — C o n f i g u r a t i o n ,

i n t e g r

a t i o n , a n d r o l l o u t

( “ d o l l a r s t o a s s e t s ” )

• A c t i v i t i e s d e s i g n e d t o

g e t t h e s y s t e m

u p a n d

r u n n

i n g i n o n e o r m o r e

o r g a

n i z a t i o n a l u n i t s

• P r o j e c t m a n a g e r ,

p r o j e c t t e a m

m e m b e r s ,

a n d

a v a r i e t y o f

e x t e

r n a l t e c h n i c a l a n d

g e n e r a l m a n a g e m e n t

c o n s u l t i n g r e s o u r c e s ,

e x e c

u t i v e s ( i n s t e e r i n g

c o m

m i t t e e c a p a c i t y ) ,

o t h e

r o r g a n i z a t i o n a l

m e m

b e r s ( i n

c o n s u l t a t i v e r o l e s )

•

D e v e l o p m e n t o f

d e t a i l e d p r o j e c t p l a n

•

O n g o i n g p r o j e c t

m a n a g e m e n t

•

S e l e c t i o n a n d

a s s i g n m e n t o f p r o j e c t

t e a m

m e m b e r s

•

T r a i n i n g o f p r o j e c t

t e a m

m e m b e r s a n d

a c q u i s i t i o n o f

s u p p o r t i v e s k i l l s

•

C u r r e n t a n d / o r f u t u r e

b u s i n e s s p r o c e s s

m o d e l i n g a n d

r e e n g i n e e r i n g , i f a n y

•

E x e c u t i o n o f c h a n g e

m a n a g e m e n t p l a n ,

i f a n y

•

S o f t w a r e c o n f i g u r a t i o n

•

S o f t w a r e c u s t o m i z a t i o n ,

i f a n y

•

S y s t e m

i n t e g r a t i o n

•

I n t e g r a t i o n o f s o f t w a r e

b o l t - o n s a n d / o r l e g a c y

s y s t e m s , i f a n y

•

D a t a c l e a n u p a n d

c o n v e r s i o n

•

D o c u m e n t a t i o n

•

T e s t i n g , b u g f i x i n g , a n d

r e w o r k

•

E x e c u t i v e a n d e n d - u s e r

t r a i n i n g

•

R o l l o u t a n d s t a r t u p

• S t a f f i n g p r o j e c t

s u b t e a m s w i t h o u t

a p p r o p r i a t e c r o s s -

f u n c t i o n a l

r e p r e s e n t a t i o n

• D i f f i c u l t y a c q u i r i n g

a d e q u a t e k n o w l e d g e

a n d s k i l l i n s o f t w a r e

c o n f i g u r a t i o n

( e s p e c i a l l y c r o s s -

m o d u l e i n t e g r a t i o n ) ,

i n t e g r a t i o n o f b o l t - o

n s

o r l e g a c y s y s t e m s , a

n d

a v a r i e t y o f p l a t f o r m

t e c h n o l o g i e s

• P o o r - q u a l i t y s o f t w a r e ,

d o c u m e n t a t i o n ,

t r a i n i n g m a t e r i a l s

• I n a d e q u a t e k n o w l e d

g e

o n p a r t o f c o n s u l t a n

t s

a n d v e n d o r p e r s o n n

e l

• C o n f i g u r i n g s o f t w a r

e

f o r m u l t i p l e u n i t s o n

t h e b a s i s o f a n a l y z i n

g

o n l y o n e u n i t

• A s s u m i n g t h a t e n d - u s e r

t r a i n i n g s h o u l d b e

f u n d e d f r o m

o p e r a t i o n s

b u d g e t s

• C o n f i g u r a t i o n e r r o r s

t h a t r e q u i r e r e w o r k

i f

c a u g h t

• C u s t o m i z a t i o n s t h a t d o

n o t w o r k

• F a i l u r e t o m a n a g e

p r o j e c t s c o p e ,

s c h e d u l e , b u d g e t

• I n a d e q u a t e a t t e n t i o n t o

d a t a c l e a n u p

• P r o j e c t p e r f o r m

a n c e t o

s c h e d u l e , s c o p e , a n d

b u d g e t

• P r o j e c t t e r m i n a t e d

o w i n g t o o v e r r u n s o r

i n t r a c t a b l e t e c h n i c a l

p r o b l e m s

• R o l l o u t o f

s o m e

o p e r a t i o n a l e n t e r p r i s e

s y s t e m f u n c t i o n a l i t y t o

o n e o r m o

r e

o r g a n i z a t i o n a l u n i t s

• F u n c t i o n a l i t y ,

o p e r a t i o

n a l

p e r f o r m

a n c e , a n d


p r e p a r a t i o n a r e

i n s u f f i c i e n t t o a d d r e s s

b u s i n e s s n e e d s

• F u n c t i o n a l i t y ,

o p e r a t i o

n a l

p e r f o r m

a n c e , a n d


p e r f o r m

a n c e a r e

s u f f i c i e n

t t o a d d r e s s

b u s i n e s s n e e d s

T A B L E

1 0 . 2

( c o n

t i n u e

d )

P h a s e N a m e ,

T y p i c a l



P e r f o r m a n

c e

P o s s i b l e



o r P r o b l e m s

M e t r i c s

O u t

c o m e s



S h a k e d o w n ( “ a s s e t s t o

i m p a c

t s ” )

• P e r i o d o f t i m e f r o m

“ g o i n g l i v e ” u n t i l

“ n o r m a l o p e r a t i o n ” o r

“ r o u

t i n e u s e ” h a s b e e n

a c h i e v e d

• O p e

r a t i o n s m a n a g e r s ,

e n d

u s e r s , r e m n a n t s o f

t h e p r o j e c t t e a m , I T

s u p p

o r t p e r s o n n e l ,

e x t e

r n a l t e c h n i c a l

s u p p

o r t p e r s o n n e l

•

B u g f i x i n g a n d r e w o r k

•

S y s t e m

p e r f o r m a n c e

t u n i n g

•

A d d i n g h a r d w a r e

c a p a c i t y

•

P r o b l e m

r e s o l u t i o n

•

P r o c e s s a n d p r o c e d u r e

c h a n g e s

•

R e t r a i n i n g , a d d i t i o n a l

t r a i n i n g

•

A d d i n g p e o p l e t o

a c c o m m o d a t e l e a r n i n g

a n d s h a k e d o w n n e e d s

• B u s i n e s s d i s r u p t i o n

• D i f f i c u l t y d i a g n o s i n g

a n d s o l v i n g

p e r f o r m a n c e p r o b l e

m s

• E x c e s s i v e d e p e n d e n

c e

o n “ k e y u s e r s ” ( p r o j e c t

t e a m

m e m b e r s ) a n d

/ o r

I T s p e c i a l i s t s

• M a i n t e n a n c e o f o l d

p r o c e d u r e s o r m a n u

a l

w o r k a r o u n d s i n l i e u

o f

l e a r n i n g t h e r e l e v a n

t

s y s t e m

c a p a b i l i t i e s

• D a t a i n p u t e r r o r s

• P o o r s o f t w a r e e a s e o f

u s e

• N o g r o w t h o f e n d - u

s e r

s k i l l s a f t e r i n i t i a l

t r a i n i n g

• U n d e r u s e / n o n u s e o f

s y s t e m

• F a i l u r e t o a c h i e v e

n o r m a l o p e r a t i o n s

( “ s y s t e m ” n e v e r

s t a b i l i z e s )

• R e l e v a n t s y s t e m

p e r f o r m a n c e m

e a s u r e s

s u c h a s d o w n t i m e ,

r e s p o n s e t i m e ,

e t c .

• S h o r t - t e r m

c h a

n g e s i n

k e y p e r f o r m a n c e

i n d i c a t o r s s u c h

a s

c u s t o m e r c a l l s

m i s s e d ,

l a b o r c o s t s , o r d e r

f u l f i l l m e n t c y c l e t i m e

a n d e r r o r r a t e s

, l e n g t h

o f t i m e r e q u i r e

d t o

c o m p l e t e f i n a n

c i a l c l o s e

• S h o r t - t e r m

i m p

a c t s o n

c u s t o m e r s a n d

s u p p l i e r s

• E m p l o y e e j o b

q u a l i t y / s t r e s s

• P r o j e c t t e r m i n a t e d

o w i n g t o s e v e r e

s h a k e d o w

n p r o j e c t s

( e . g . , d i s r u p t i o n o f

b u s i n e s s , p o o r t e c h n i c a l

p e r f o r m a n

c e , b u g s a n d

e r r o r s )

• N o r m a l o p e r a t i o n w i t h

r o u t i n e u s

e o f

e n t e r p r i s e

s y s t e m

i s

a c h i e v e d

• I m p a c t s

i n s u f f i c i e n t

t o a d d r e s s b u s i n e s s

n e e d s

• I m p a c t s

s u f f i c i e n t

t o a d d r e s s b u s i n e s s

n e e d s

T A B L E

1 0 . 2

( c o n

t i n u e

d )

P h a s e N a m e ,

T y p i c a l



P e r f o r m a n

c e

P o s s i b l e



o r P r o b l e m s

M e t r i c s

O u t

c o m e s

( c o n

t i n u e

d

o n

t h e n e x

t p

a g e

)

•

I n a d e q u a t e a t t e n t i o n t o

r e p o r t i n g

•

S h o r t - c u t t i n g t e s t i n g

a n d / o r t r a i n i n g w h e n

s c h e d u l e g e t s t i g h t

•

L a c k o f t e c h n o l o g y

t r a n s f e r f r o m

e x t e r n a l


•

V e n d o r d e l i v e r y a n d

s o f t w a r e p e r f o r m a n c e

p r o b l e m s

•

L a c k o f s o f t w a r e e a s e o f

u s e

•

T u r n o v e r o f p r o j e c t

p e r s o n n e l



O n w a r d a n d u p w a r d

( “ i m p a c t s t o o u t c o m e s ” )

• R o u t i n e o p e r a t i o n o f

t h e b u s i n e s s u n t i l s u c h

t i m e

a s a n e w v e r s i o n

o f e n t e r p r i s e s y s t e m

i s

r o l l e

d o u t

• P e r i o d d u r i n g w h i c h

b u s i

n e s s r e a l i z e s

b u s i

n e s s b e n e f i t s f r o m

s y s t e m , i f a n y

• O p e

r a t i o n s m a n a g e r s ,

e n d

u s e r s , I T s u p p o r t

p e r s

o n n e l , e x e c u t i v e s

•

P o s t i m p l e m e n t a t i o n

i n v e s t m e n t a u d i t ( m a y

n o t b e d o n e )

•

C o n t i n u o u s b u s i n e s s

i m p r o v e m e n t ( m a y n o t

b e d o n e )

•

T e c h n o l o g y

u p g r a d i n g / m i g r a t i o n

( m a y n o t b e d o n e )

•

A d d i t i o n a l e n d - u s e r s k i l l

b u i l d i n g ( m a y n o t b e

d o n e )

• N o t a s s e s s i n g s y s t e m

-

r e l a t e d o u t c o m e s o n a

r o u t i n e b a s i s

• E n t e r p r i s e s y s t e m o f

t o d a y b e c o m e s l e g a

c y

s y s t e m

o f t o m o r r o w

( o r g a n i z a t i o n a l

u n w i l l i n g n e s s o r

i n a b i l i t y t o m a k e

t e c h n o l o g y u p g r a d e s )

• N o a v a i l a b l e

d o c u m e n t a t i o n o n

c o n f i g u r a t i o n r a t i o n

a l e

• T u r n o v e r o f

k n o w l e d g e a b l e

p e r s o n n e l ( I T a n d

e n d u s e r )

• N o o r g a n i z a t i o n a l

l e a r n i n g a b o u t I T

p r o j e c t s , e n t e r p r i s e

s y s t e m s

• F a i l u r e t o m a n a g e t o

t h e i n t e n d e d r e s u l t s

o f

t h e e n t e r p r i s e s y s t e m

• N o t u s u a l l y f o r

m a l l y

m e a s u r e d

• P o s s i b l e i n d i c a t o r s

i n c l u d e c o n t i n u o u s

b u s i n e s s p e r f o r m a n c e

i m p r o v e m e n t / l e a r n i n g

m e t r i c s , e n d - u s e r s k i l l

a s s e s s m e n t , e a

s e o f

u p g r a d i n g / m i g

r a t i o n ,

s h o r t e n i n g o f p

r o j e c t

a n d s h a k e d o w n p h a s e s

o v e r t i m e , I T s p e c i a l i s t

c o m p e t e n c e m

e a s u r e s

• U n w i l l i n g n e s s o r

i n a b i l i t y t o i m p r o v e

b u s i n e s s p

e r f o r m a n c e

a n d / o r m i g r a t e

t e c h n i c a l l y ( e . g . ,

e x t r e m e d

i s s a t i s f a c t i o n

w i t h i m p l e m e n t a t i o n

p r o c e s s o r o u t c o m e s ,

l o s s o f t e c

h n i c a l o r

e n d - u s e r c o m p e t e n c e )

• F o r m a l o r

i n f o r m a l

a s s e s s m e n

t t h a t

i n v e s t m e n

t h a s b e e n

u n s u c c e s s

f u l ( e . g . ,

f a i l u r e t o a c h i e v e

h o p e d - f o r b u s i n e s s

r e s u l t s , u n

e x p e c t e d

c o s t s , o r c

o n s e q u e n c e s )

• F o r m a l o r

i n f o r m a l

a s s e s s m e n

t t h a t p r o j e c t

h a s a c h i e v e d g o a l s

a n d / o r u n

e x p e c t e d

b e n e f i t s

• O r g a n i z

a t i o n f a i l s t o

i m p r o v e i t s o v e r a l l

c o m p e t

i t i v e p o s i t i o n

• O r g a n i z

a t i o n

i m p r o v e s i t s o v e r a l l

c o m p e t

i t i v e p o s i t i o n

T A B L E 1 0 . 2

( c o n

t i n u e

d )

P h a s e N a m e ,

T y p i c a l



P e r f o r m a n

c e

P o

s s i b l e



o r P r o b l e m s

M e t r i c s

O u t

c o m e s



distress, it ma y ha ve merged wit h a nother compan y, or it ma y ha ve shifted business

models. Some projects are terminated owing to cost or schedule overruns or severe

technical problems. Oth ers result in th e rollout of the opera tiona l enterprise system

functionality to one or more organizational units. If the lat ter , the enterprise

system functionality, operational performa nce, a nd organiza tional preparat ion ma y

be sufficient to fit t he organ izat ion’s goals a nd/or needs, or they ma y be insufficient

for “success.”

The Shakedown Phase

The shakedown phase is the organization’s coming to grips with the enterprise

system. The phase can be said to end w hen “normal operat ions” ha ve been a chieved(or the organization gives up, disinstalling the system). The project (or consulting)

team may continue its involvement or may pass control to operational managers

an d end users and wha tever technica l support i t can muster . Act ivit ies include

bug f ixing and rework, system performa nce tuning, retra ining, and st a f f ing up to

ha ndle temporary inefficiencies. To a la rge extent, th is is the pha se in wh ich the

errors of prior phases are felt—in the form of reduced productivity or business

disruption—but new errors can arise in this phase too. For example, operational

personnel may adopt workarounds to cope with ear ly problems and then fa i l to

aba ndon them w hen the problems are resolved. Similar ly, the organiza t ion ma ycome to rely excessively on knowledgeable project team members rather than

building the enterprise system knowledge and skills in all relevant operational

personnel. As mentioned, some enterprise systems are terminated during the

sha kedow n pha se, a s in the case of F ox-Meyer D rug (B ulkeley, 1996). Alternt ively,

organizations may achieve (or declare) “normal operations.” If the lat ter , the im-

pacts a t t r ibuta ble to the organ iza t ion’s use of the system ma y f i t i t s goals or busi-

ness needs, or th ey ma y fa il to do so.

The Onward and Upward Phase

The onwar d a nd upwa rd pha se continues from norma l operation until t he system is

replaced with an upgrade or a different system. It is during this phase that the

organizat ion is fina lly able to ascerta in the benefits (if any) of its investment. K ey

players include operational managers, end users, and IT support personnel (in-

ternal or external). Vendor personnel and consultants may also be involved, partic-

ularly w hen deliberations a bout upgra des are concerned. Cha ra cterist ic activit ies of

th is phase include continuous business improvement, ad ditiona l user skill building,

an d postimplementat ion benefit a ssessment; however, th ese “typical” activit ies ar e

often not performed. A common problem of the onwa rd a nd upw ar d pha se is th e loss

of knowledgeable personnel who understand the rationales for prior configuration

choices and how to improve the business processes through the use of the system.

Several ultimate outcomes are possible: The organization may be unwilling to un-

dertake further improvements or upgrades. The organization may decide that its

investment has been unsuccessful in meeting goals or business needs. Or the orga-

nizat ion m ay decide its experience has been a success. If th e lat ter , the orga niza-

tion’s competitive position ma y or may n ot ha ve been improved as a result of its useof enterprise systems.

Chapter 10 195



TOWARD A PROCESS THEORY OFENTERPRISE SYSTEM SUCCESS

Each enterprise system experience runs a different course, but across the varia-tions, regularities can be found.

• Man y different things can go wrong in each phase of the enterprise system

experience cycle. Furthermore, not all problems or errors are immediately detectable

(an d, hence, they a re not a ll immediat ely correctable).

• There ar e several possible outcomes for each pha se. One is an “optim a l” out-

come, for example, in the chartering phase, the decision to proceed with an enter-

prise system project tha t h as a sound business case. A second outcome is a “termi-

nation” outcome, such as the decision not to proceed with the enterprise systembecause a na lysis revealed a n una ccepta ble business case. A third outcome might be

called “continuation with undetected and uncorrected problems” or “unresolved ex-

perience risk.”41

The subsequent phase inherits these unresolved risks.

• This third outcome is analogous to what sociotechnical systems theorists

call a “va ria nce” (Ta ylor, 1993). Va ria nces in production processes ar e devia tions

from sta nda rds in the inputs to a production activity (e.g., raw ma terial qua lity de-

fects). Variances are not necessarily detected right away; if they cause problems,

they may do so only much later in the production process after much money has

been expended in w orking t he ra w ma terial. S imilarly, requirements definit ion er-rors in softw ar e development ma y not sh ow up unt il the syst em is put int o produc-

tion. Unresolved variances in each phase of an enterprise system experience are

passed on to the next pha se, where they ma y or may not be detected and a ppropri-

ately resolved (depending on probabilistic processes). So, for example, some vari-

an ces in the chart ering pha se may remain uncorrected until they show up in the on-

wa rd a nd upwa rd phase a s a lack of business benefits. In genera l, the cost of fixing

problems increases wit h delay s in recognizing a nd correcting varia nces.

• G enera lly speaking, different a ctors a re involved in different phases of the

enterprise system experience cycle. While there may be some continuity across

pha ses (for exa mple, oversight by a n executive st eering commit tee during the proj-

ect pha se), ha ndoffs to a different gr oup of people (wit h different specialt ies, experi-

ences, and skills) increase the likelihood that variances passed on from earlier

phases will not be caught and resolved until they create significant problems.

For example, project teams rarely catch and correct significant errors (e.g., failure

to match the project to business strategy) in the business case that forms their

“charter.”

• Of course, not a ll varia nces end up causin g problems a nd requir ing fixing or

rework. Whether or not variances cause problems depends on probabilistic processes

such as bad luck, changing business conditions, intera ctions w ith other va riances, and

so on. For example, a badly configured enterprise system requiring expensive rework

may not be a problem if the organization’s financial position remains sound. Further-

more, it is possible for externa l conditions a nd t he organiza tion’s decisions a nd a ctions

to interact in such a way that the outcome is better than it was at a prior point, in-

creasing the standard of optimal success. For example, successful implementation of

ERP softwa re, while perha ps not providing immediate business value to the adopting

organ ization, might nevertheless position tha t organiza tion to take ad vant age of supply-chain integration, thus improving its competitive position relative to competitors.




Two brief examples illust ra te how our fra mew ork works. The first example con-

cerns Qua ntum Corp.’s implementat ion of the Ora cle suite of enterprise softw ar e ap-

plications (Radosevich, 1997). Consultants generally advise against “big-bang” imple-

ment a tions (implementin g all modules at once a nd/or implement ing in all loca tions a t

once) because of the high potential for business disruption. During its chartering

phase, Quantum’s leadership determined that acquiring the capability instantly to

commit inventory to customers on a worldwide ba sis (called a vaila ble to promise, or

ATP) was a strategic necessity.

B ecau se the ATP functionality t ouches on severa l ar eas, including sales processing, in-

ventory and logistics, Quantum had to have the entire suite operating before attaining

its key business goal. (Radosevich, 1997)

Quantum therefore decided to implement everywhere at once, but the leadership

clea rly und erstood the “bet-your-business” na tur e of this decision should the sha ke-

down phase not go as well as planned. Therefore, during the project phase, the

implementa t ion tea m ma de extra ordinary ef for ts in t est ing the system. Further-

more, when early testing revealed problems, the rollout date, scheduled for

summer 1995, was postponed. The rollout finally began as a planned shutdown

worldwide:

At t he str oke of midnigh t on April 26, 1999, every business sy stem a t Qua ntum Corp’s

offices across the globe went dow n. . . . The systems st ay ed down for a week. . . . On May5, Quantum switched on the new system, and it has been running successfully ever

since. (Ra dosevich, 1997)

In this example, the organization deliberately made a decision involving a high

level of r isk but took a ppropriat e steps to ensure that the risks did n ot ma terialize

into a disruption that might ha ve threatened the existence of the organizat ion.

Contrast this example with that of Fox-Meyer Drug (Bulkeley, 1996). When

this SAP implementa t ion wa s char tered, the CIO a t least w as a wa re tha t i t was a

“bet-your-business” proposition. Yet the $60 million project was approved at the

sam e time tha t t he company also embarked on a sta te-of-the a rt $18 million aut o-

mated warehouse. During the project phase, bad luck intervened: Fox-Meyer Drug

lost a lar ge customer, accounting for 15%of its bu siness. To increa se revenues, th e

company aggressively bid on new business: It f igured contract pricing on the as-

sumption tha t the projected a nnua l $40 million savings from t he SAP project would

be realized immediately on sta rtup, an d it decided to adva nce the SAP rollout by 90

day s. Tha t close to the end of the project , lit t le wa s left to do other th an tra ining an d

testing. S o project tea m m embers decided not t o test modules tha t ha d not been cus-

tomized (thus failing to detect configuration errors). Cutover to the new system

resulted in disaster. Mean wh ile, the a utomat ed wa rehouse also did not perform a s

planned. It w as estimat ed tha t t he company susta ined an unr ecovera ble loss of $15

million from erroneous shipments. The company was forced into bankrupcy, and

sha reholders have since sued both the enterprise system vendor a nd t he integrat ion

consult a nt for $500 million each.

In this example, the chartering decisions were moderately risky. When bad

luck occurred during the project phase, the company’s decisions had the effect of

increas ing ra ther t ha n decreasing risk. When ma jor problems finally ma terialized

during sha kedown, the organiza tion did not ha ve the t ime or the resources to over-come th em.

Chapter 10 197



FACTORS IN ENTERPRISE SYSTEM SUCCESS

One ca n a bstr a ct from such exam ples and t he deta ils of Ta ble 10.2 a m ore genera l

theory of success in the enterprise system experience. At any one moment in time(phase), an enterprise system–adopting orga nizat ion fa ces a situa tion tha t involves

conditions and events (some of them outside its direct control) with an ability to

make plans and take actions (that is, goal-directed or “motivated” behavior). These

element s of the situa tion a re the fa ctors in (influences on) the outcomes tha t become

inputs at the next moment in time (phase). In the next section we briefly describe

th ese success/fa ilure fa ctors.

Factors External to an Organization’s ControlThe organizat ion a dopting a n enterprise system fa ces several star ti ng conditi ons such

as competitive position, industry, financial position, prior relevant experience, size,

structure, and ma nagement systems t hat ma y predispose it to success or failure. While

there are undoubtedly threshhold levels for some of these conditions, they generally

can n ot be sa id to be necessary (or sufficient) for t he success of the ent erprise system,

since organiza tions ha ve been known to succeed or fail despite them. B ut t hese factors

come into play in t he enterprise system experience in tw o wa ys.

First, organizat ions’ goals a nd plans for enterprise systems may or ma y not be re-

alist ic when viewed objectively in light of t hese conditions. D ell, for exam ple, decided(after some experience) that an enterprise system was not sufficiently flexible for its

rapid growth. F or a nother exam ple, an organization on the brink of bankruptcy ma y

not have enough time and money to realize the benefits of an enterprise system.

Starting conditions define the needs and opportunities of organizations relative to

enterprise systems (whether or not organizations recognize them for what they are).

Second, start ing conditions may not remain the same over the course of the

enterprise sys tem experience. After a compa ny d ecides to customize th e enterprise

system software, the vendor delivers the needed functionality. After the company

has configured the enterprise system for a particular way of doing business, the

company merges or sells off a major line of business. Sometimes changes in condi-

tions favor the organization’s plans. But probably more often, changing business

conditions derail plans. Successful organizations modify goals, plans, and execution

to bring their behavior back into line with t he environment.

Organization’s Motivated Behavior

The organization’s goal-directed enterprise system behavior can be defined in four

categories: goals, plans, execution, and responses to unforeseen problems. First are

the goals themselves. Some goals are more conducive to success than others, some

are t oo unambitious to be motivat ing, and others are unrea list ic in light of the ob-

jective chara cterist ics of the enterprise system a nd t he organizat ion’s st art ing con-

ditions. G iven the grea t complexity a nd expense of enterprise syst ems, for exam ple,

some a na lysts a rgue tha t only compan ies seeking to strea mline business processes,

to standardize data, or to standardize processes can achieve a posit ive return on

their enterprise sy stem investm ent (Connolly, 1999).

Plans are another factor in the equation. Plans (and policies) such as not tocustomize, to reengineer first (las t, or not at a ll), an d to phase th e rollout a re essen-

tial to keeping the project phase on tr ack. En terprise system integrat ors often claim




to have “ the methodology” tha t w ill guara ntee success, but not a ll plan s a re creat ed

equal. The orga nizat ion’s plans for an enterprise system m ust be linked to its st ar ting

conditions an d goals. Tra ditional organiza tions ma y need much more cha nge ma n-

agement activity than those in the volatile high-tech sector. The need for a partic-

ular business capability m ay necessitat e a risky big-bang rollout (Ra dosevich, 1997).

For another example, the tier-one supplier to an automotive assembler should be

much more concerned th an a t ier-tw o supplier a bout the potential nega tive impacts

in lost business from plans t ha t shortchange testing.

The best laid plans are worthless if they are not followed. Good execution is

something t ha t a consulta nt ’s methodology cannot gua ran tee. If configurat ion ta sks

exceed the schedule, cutt ing the t ime a llotted t o testing and tra ining ma y not gua r-

antee failure, but, given these choices, success will require more than a little luck.

No matt er how well an organizat ion executes plans well designed to meet its

carefully thought-out goals, conditions may change and unforeseen problems may

arise. Successful organizations successfully resolve problems by changing their

goals, plan s, a nd a ctions t o get a favorable outcome.

Intermediate and Final Outcomes

Starting conditions, changes in conditions, goals, plans, and actions interact (Or-

likowski, 1996). Resulting from these interactions are unresolved risks and prob-

lems (as well as opportunit ies, although a voiding failure is usua lly the primar y con-

cern). U nresolved risks an d problems themselves int eract w ith cha nging business

conditions and the organization’s actions in response to them. If the experience is

not terminated, the interactions in one phase result in start ing conditions for the

next. In economic terms, the course of the enterprise system experience exhibits

“pat h dependence.” The fina l outcome ma y be very close to optima l success (itself a

moving ta rget) or suboptima l on one or more dimensions.

G ra phically, the a bstr a ct theory described here is depicted in Figure 10.3 for a

single phas e (nega tive situa tion only). Ta ble 10.3 summ a rizes the deta ils of th e

process th eory a s it a pplies t o the specific case of enterprise sys tems. Ta ble 10.3 is

organ ized according to th e importa nt dimensions of process models (Soh & Ma rkus,

1995) by phase: outcome, necessary conditions, probabilistic processes, and recipe

for success.

USES OF THE FRAMEWORK

This simple theory of the enterprise system experience has several benefits anduses. First , it is fra med in terms tha t a re meaningful to practit ioners, but it a voids

simplistic overemphasis on a single factor (such as methodology). Furthermore, it

explicitly recognizes the role of factors outside the organization’s direct control,

thereby focusing attention on both planning and the resolution of unforeseen prob-

lems. Perha ps most importa nt , it emphasizes the importance of goals—something

tha t t echnical specialists in pa rticular often ta ke as givens. In view of their greater

knowledge of system capabilit ies an d limita tions, technical specialists can increase

the probability of success by (tactfully) challenging the organization’s goals for the

enterprise system and these goals’ fit with business stra tegy a nd external conditions.As noted by Silver a nd collea gues (Silver et a l., 1995), th e theory outlined here

can be used both retrospectively an d prospectively. Ret rospectively, it is useful for

Chapter 10 199



tra cing ba ck problems an d suboptima l success at each phase to var iances arising in

earlier phases. For example, configuration errors (which disrupt business opera-

tions during shakedown) can result from chartering phase errors (selection of inap-

propria te goals, softw a re, or pa rt ners) as w ell as from project phas e problems (poor

composition of project team, inadequate change management execution). Prospec-tively, the theory can be used to identify a large number of potential problems that

should be addressed in basic and contingency plans. It can also help sensitize deci-

sion makers t o the need to chan ge plans a nd a ctions in light of common problems or

changing business conditions.

DIRECTIONS FOR FUTURE RESEARCH

The theoretical framework outlined in this theory is too broad in scope for direct

empirical testing. However, many lines of research follow directly from the frame-

work, and the phenomenon raises some research themes and issues beyond the

limits of the framew ork.

RESEARCH ON THE PROCESS THEORY

The basic structure of the framework is a sequence of phases, each with interme-

diate outcomes. The intermediate outcomes are argued to influence the final out-

come, but not to determine it ; in other words, events an d a ctions ta ken at an y point

in the experience cycle ma y dera il an experience tha t a ppea rs t o be destined for suc-

cess or ma y help a troubled experience get ba ck on t ra ck. This genera l proposition

lends itself to testing via multiple methods, including multiple case study and a

survey approach. One wa nts t o know the proportion of successes a t ea ch phase tha t a re

successful in the next a nd w ha t kinds of actions a nd events are most likely to change

the course of an experience. An important issue concerns the specific metrics of suc-

cess. Which metrics in each phase ha ve the great est predictive an d explan at ory pow er?The framework gives a special role to the decisions of the chartering phase.

Since errors in chart ering an enterprise system experience ma y not be caught an d


FIGURE 10.3 Factorsin Suboptimal Success

Poorinputs

&plans

Poor

execution

Unresolvedrisks and

problems

Negativeevents and changed

conditions



T A B L E

1 0 . 3

( c o n

t i n u e

d )

S u c c e s s f u l

N e c e s s a r y

P r o b a b i l i s

t i c

R e c

i p e f o r

P h a s e

O u t c o m e

C o n d i t i o n s

P r o c e s s e

s

S u

c c e s s

O n w a r d a n d u p w a r d

( “ i m p a c t s t o o u t c o m e s ” )

O

r g a n i z a t i o n i m p r o v e s i t s

c o m p e t i t i v e p o s i t i o n a s a

r e s u l t o f e n t e r p r i s e s y s t e m

p

r o j e c t a n d m a i n t a i n s i t s

t e c h n o l o g i c a l a n d b u s i n e s s

f l e x i b i l i t y f o r f u t u r e d e v e l -

o

p m e n t s

• M a n a g e r s c o m m i t t e d t o

a c h i e v i n g b u s i n e s s r e

s u l t s

( e . g . , t o u s e s y s t e m -

g e n e r a t e d i n f o r m a t i o

n t o

i m p r o v e o r g a n i z a t i o n a l

p e r f o r m a n c e )

• I m p a c t s a t t r i b u t a b l e

t o

u s e o f h i g h - q u a l i t y

e n t e r p r i s e s y s t e m a n d

i n f r a s t r u c t u r e

• S y s t e m , t e c h n i c a l

i n f r a s t r u c t u r e , b u s i n e

s s

p r o c e s s e s , a n d h u m a

n

r e s o u r c e s s u f f i c i e n t l y

f l e x i b l e t o a d a p t t o

c h a n g i n g b u s i n e s s

c o n d i t i o n s

• A d e q u a t e r e s o u r c e s

d e v o t e d t o m a i n t a i n i n g

a n d r e n e w i n g s y s t e m

,

t e c h n i c a l i n f r a s t r u c t u

r e ,

a n d h u m a n c o m p e t e

n c e

• Q u a l i t y o f a s s e t s r e s u l t i n g

f r o m e a r l i e r p h a s e s

• V o l a t i l i t y o f b u s i n e s s

c o n d i t i o n s

• S t a k e h o l d e r p o l i t i c s

• E x e c u t i o n o f r e s u l t s

m a n a g e m e n t a n d

m a i n t e n a n c e / e n h a n c e -

m e n t a c t i v i t i e s

• S u r v i v a l o f s o f t w

a r e

v e n d o r

S u c c e s s o c c u

r s w h e n

1 . B e n e f i t s f r o m u s e o f t h e

s y s t e m c o

m b i n e w i t h

f a v o r a b l e

c o m p e t i t i v e

c o n d i t i o n

s

A N D

2 . T h e f u t u r e e v o l u t i o n o f

t h e e n t e r p r i s e s y s t e m

a n d r e l a t e d

i n f r a s t r u c t u r e i s w e l l

m a n a g e d

Ch t 10 203



corrected during the project phase, they are likely to prove expensive to correct

lat er, if they a re not outright irreversible. Empirical resear ch is needed t o address

the chart ering phase errors th at ar e most likely, most consequential, a nd most diffi-

cult to detect. Why do these errors occur? Wha t ca n be done to prevent or correct t hem?

Adopting organizations with many subunits face chartering and project com-

plexities t ha t single-location businesses do not. Ma ny m an agement theories a ssume

tha t certa in “configura tions” of stra tegy or structura l varia bles ar e better suited tha n

others to the contingencies of part icular environments. The sa me ma y be t rue of the

strategies that companies develop to deal with enterprise systems, particularly in

complex organizations with many subunits. One wants to know first of all whether

there are relatively stable clusters of chartering decisions (e.g., big-bang rollout cou-

pled w ith n o local a utonomy on softw ar e configurat ion). If they do exist, how do orga-

nizat ions decide wh ich stra tegic configurat ions to a dopt? Are th ese stra tegic configu-

ra tions of decisions more successful in th e enterprise syst em experience if th ey fit w ell

with the various aspects of their environment such as industry type, organizational

structure a nd business model, orga nizat iona l culture, a nd th e like?

An especially interesting pa rt of the m odel is w ha t h appens aft er “normal op-

eration” is achieved. When, how, and why does the organization decide to keep

things as they are, making the enterprise system of today into the legacy system

of tomorrow? When, how, a nd w hy do organiza tions upgrade? Is it better to upgrade

frequent ly so as not t o risk big conversions? Do orga niza tions rea lly perceive th em-

selves to be locked in to a particular vendor? How does this influence their subse-

quent beha vior?

Finally, an underlying theme in the framework is the role played by human

knowledge a nd skill—and gaps in knowledge and skills—in enterprise system suc-

cess. What are the relevant bodies of knowledge? How are they distributed exter-

nally (across vendors and consultants) and internally (across IT specialists, execu-

tives, and users)? Under w ha t conditions a re they tr an sferred effectively? Wha t a re

the barriers to effective knowledge transfer? How can organizations acquire and

maintain the relevant expertise? These are just a few of the knowledge manage-ment questions posed by enterprise systems. One potentially significant knowledge

issue concerns the loss of knowledge about enterprise system configuration (e.g.,

through poor documentation and personnel turnover). One system integrator told

us he believed that it might be more costly to update a poorly documented enter-

prise system tha n a compara ble legacy system because w ith t he enterprise system,

the requisite knowledge most likely lies outside the organization. This is an inter-

esting testable hypothesis tha t gets at the heart of the adva nta ges claimed for pack-

a ges over in -house development .

BEYOND THE FRAMEWORK

In a ddit ion to the ma ny q uestions ra ised by the fram ework itself , the phenomenon

of enterprise systems ra ises interesting questions tha t go well beyond t he fram ework.

• Dependence on Vend ors. Because they are so all-encompassing, enterprise

systems create a level of dependence on a s ingle softwa re vendor t ha t fa r surpa sses

the dependence associated with prior technological regimes. Does this dependence

have negative effects on organizations? How do the effects manifest themselves?

Chapter 10 203

204 M Lynne Markus and Cornelis Tanis



How do organizations cope? What are the costs of picking the “wrong” vendor (one

tha t goes out of business or lacks t he resources for continued product enha ncement

in the company’s industry segment)?

• Uniqueness. To wha t extent do the ent erprise syst em experience cycle andrelated process theory apply more generally to other types of information systems?

What is truly unique and different about enterprise systems, as opposed, say, to

softw ar e environments such as Lotus Notes or to homegrown a pplicat ions?

• Other Ki nds of I ntegration. Some organizat ions have eschewed enterprise sys-

tems for any number of reasons. Nevertheless, many of the motivations for enterprise

systems rema in, part icularly in lar ge, complex organizat ions. To wha t extent ar e these

organ izations pursuing alterna tives to enterprise systems as a form of internal integra -

tion? (Alternatives might include summary-level integration via data warehousing,

rearchitecting legacy sy stems w ith middleware, or redevelopment using th e object para -

digm.) What are the a dvant ages a nd disadva nta ges of different integra tion approaches?

What are the consequences of these alternative choices for organizational performance

and future flexibility? In particular, are there observable negative consequences from the

“tight coupling” enta iled w ith enterprise systems?42

• Th e “Ext end ed E nt er pr ise.” The enterprise syst em experience framew ork as -

sumes that the organization is the most appropriate level of analysis. Increasingly,

however, organizations are looking to extensions of enterprise systems to connect

themselves more tightly w ith customers and suppliers in wha t is often called “supply-

chain integrat ion.” Suppliers ma na ge customers’ inventory, and redundan cies are

eliminated across organizational lines instead of just within them. Software enables

each part y to a ccess the other’s da ta —perha ps it is more appropriate t o speak of in-

terorganiza tionally sha red softw ar e and da ta resources. To wha t extent does the en-

terprise system experience framework apply to the interorganizational integration

experience? Can the fra mework be extended, or is a n entirely new fram ework needed?

Finally, of course, what are the societal consequences of this trend, if it continues?

• Other Ki nds of Coord inati on. Organ izat ions for which supply-chain int egrat ion

is not a valid option may still need interorganizational coordination that cannot be

supplied by market mechanisms (King, 1999). What kinds of information technology–

mediated mechanisms will industries such as health care use for coordina tion? How

will the costs and benefits of “nonintegrated coordination” (King, 1999) differ from

those of supply-chain integration and electronic markets?

• I nf lu ences on Vend ors. How do enterprise system–adopting organizations

influence the strategic development plans of enterprise system vendors? Which

adopters ar e influentia l a nd how do they exert their influence? Wha t a re the other

influences on vendors’ beha vior (e.g., shar eholders, media , technology ma rketing re-

search firms)?

CONCLUSION

Ent erprise systems represent an importa nt contemporary phenomenon in the orga-

nizational use of information technology. The most distinct differences between an

enterprise system and other transaction-oriented systems are that the enterprise

system is a package versus a system custom developed in-house (implying long-term

dependence on a vendor) a nd th at embedded in the enterprise system a re normat ive


Chapter 10 205



business practices (requiring many adopting organizations to undertake some form of

process reengin eering). To da te, collective experience w ith ent erprise sys tem s rema ins

quit e poorly codified; man y organiza tions a pproa ch the phenomenon wit h little directly

a pplicable knowledge a nd skill.Whether or not ent erprise systems w ill rema in a n enduring par t of the organi-

zational IT landscape clearly remains to be seen, but, because they have become

such a large par t of organizat iona l IT infrast ructure, they will continue to be a con-

sequential phenomenon for some years to come. En terprise systems a ffect nearly all

aspects of organ izat iona l life, not only at the point of sta rtup but also throughout

their opera tional lives. Indeed, an organizat ion’s enterprise system a ffects its need

and ability to upgrade or convert to more modern technologies. Consequently, we

need a framework for understanding and analyzing these systems throughout an

experience cycle that includes initial decision making, “development” and imple-

menta tion, early use, a nd extended use. The fram ework outlined in th is chapter is a

first at tempt at an integrated framework for understanding the systems intended

to integrate organizat ions.

The key features of this framework include the following. First, it addresses

both the motivated behavior of organizational actors, that is, the goals they are

trying to achieve, and the factors outside their control, such as the performance of

vendors and the reactions of customers and competitors. Second, the framework

allows for both emergence—outcomes that are not deterministic but are influenced

by both cha nce events a nd h uma n a ctions—an d dyn am ics—responses to problems

and opportunities created by earlier decisions and actions. Third, the framework

emphasizes the long-term nature of the enterprise system experience, including

maintenance and future upgrades and conversions as major contributors to total

costs a nd benefits. Fourth, the fram ework understa nds success as a m ultidimensiona l

and relative concept and introduces the concept of optimal success to accommodate

unintended consequences a nd externa l realities tha t a re not fully represented in or-

gan izat iona l goals. F ifth, a s a process th eory, the fra mework helps explain w hy orga-

nizations do not always achieve optimal success. Finally, the framework uses the

concept of unresolved risk or variance to explain how errors can have consequences

that show up long after the errors originally occurred. This explains why organiza-

tions often find it so har d to correct problems a nd t o learn fr om their experiences with

enterprise systems.

ENDNOTES

1. By the mid-1990s, it was common wisdom that business process reengineering

in many companies had failed because of the difficulty and huge expense of

reprogram ming t heir core tra nsa ction processing systems to support the n ew

processes.

2. See the chapter by George, this volume.

3. In th e first dra ft of this chapter, we wr ote: “The ERP total softwa re licensing

busi ness is expected t o grow t o $20 billion by 2002 (S tein , 1998). And consu ltin g

firms have estima ted tha t E RP consulting services will grow t o $8 billion by the

year 2002 (Stein, 1998).” David Brown, of Key Performance International, pro-

vided these interesting observations: “I noticed AMR Research released a new

Chapter 10 205




report la st w eek (5/18/99) projectin g tota l ER P softw a re revenu es of $66.6 bil-

lion by 2003 (Enterprise Resource Planning Software Report, 1998–2003). I

thought you might be interested in the large discrepancy between Stein’s pro-

jections a nd AMR’s. . . . B ased on earlier studies by AMR, E RP consulting ser-vices range between 2 and 5 t imes E RP license revenues. AMR reported a v-

erage ERP license revenues of $4,000 per seat (Ba an or SAP) and ER P

consult ing fees of $8,000 (B a a n) to $20,000 (SAP ) per E RP seat . If AMR’s report

of ERP consulting fees is accurat e, Stein’s estimat e of $8 billion in ER P con-

sultin g revenues support ing $20 billion in E RP license revenues is too low by a

fa ctor of 5 to 10” (B row n, 1999).

4. See the cha pter by Weill a nd B roadbent, th is volume.

5. See the chapter by Fichma n, this volume.

6. The configuration of enterprise systems is not to be confused with (business)product configurat ion, a functionality s upported by some ERP softwa re extensions.

7. Da venport (1998) quite rightly points out t ha t such lack of integration ma y be

perfectly appropriat e for some organ izat iona l str uctures an d business m odels.

8. See the cha pter by G eorge, this volume.

9. In t he langua ge of SAP, insta llat ion w ork is divided into “applica tions” work (the

province of end users) and “basis” work (the province of technical specialists).

10. For an example of some of the trade-offs involved and how they are resolved,

see the case st udy of Microsoft’s implementa tion of SAP R/3 financials (B as hein,

Ma rku s, & Finley, 1997).

11. Conversion may be unavoidable when the vendor redevelops the software for

an entirely new computing ar chitecture (e.g., ma infra me t o client/server, client/

server to object oriented).

12. An indust ry associat ion dedicated t o issues relat ed to production an d inventory

control.

13. When pushed, most analysts admit that there is no way to verify that their

practices are really “best .” Presumably, some organizations find ways to per-

form t he process even better.

14. Conversely, the unwillingness to change how they do business requires ma ny

organizat ions t o modify enterprise softw are.

15. See the chapter by G rover a nd Kett inger, this volume.

16. The difficulty stems in part from the lack of the relevant knowledge and skills,

which are scarce and distributed across a variety of occupational specialt ies.

Therefore, system integration often involves managing a sizable collection of

technical experts from different fields and often from different organizations.

New enterprise system developments such as Web-enabled software and out-

sourced implementa tion a nd operat ions a re possible solutions t o these problems.

17. To fa cilita te this int egra tion, enterprise system vendors ar e now publishing th e

structure of their software, for example, SAP’s business application program-

ming interface (BAPI).

18. Most enterprise systems tra ce their roots t o MRP II—a disciplined approach to

managing discrete parts production. Many businesses differ substantially in

form, st ructure, and business processes from discrete pa rts ma nufacturers, for

example, process industries, service business such as repair operations, and

manufacturers of products with “dimensionality” (e.g., clothing, footwear,

telecommu nicat ions cables). (An inv entory consisting of tw o 500 meter ca bles is

not equivalent to one 1,000 meter cable.) Therefore, companies in particular

y

Chapter 10 207



industry segments must buy a specialized version of the enterprise software

creat ed by either the vendor or by a third party. Otherwise, they fa ce the need

to modify the softwa re at grea t cost a nd risk.

19. In some cases, these extensions are developed by the vendors. In other cases,the vendors have acquired third-party software firms to gain access to their

products.



22. Even w hen enterprise systems a re not adopted at a corpora te level, they ma y

be adopted by a corporation’s individual business units.

23. See the cha pter by Ba rua a nd Mukhopadh ya y, this volume.

24. See the chapter by Kirsch, this volume.

25. See the chapter by G rover a nd Kett inger, this volume.26. See the chapter by Olfman, t his volume.

27. See the chapter by Kirsch, this volume.

28. See the chapter by Ang and Sla ughter, this volume.


30. See the chapter by Robey a nd B oudreau, t his volume.

31. In other w ords, our level of an a lysis is different fr om Alter ’s (1999).

32. See the cha pter by Ba rua a nd Mukhopadh ya y, this volume.

33. An argument in favor of the contested definition is that many enterprise sys-

tems projects a re scaled ba ck during insta llat ion, w hich usua lly means a failureto achieve the a mbitious origina l goals. On t he other ha nd, this definition would

a lso count a s failures projects t ha t yielded unan ticipa ted benefits.

34. This system and concomitant organizational changes succeeded in reducing ac-

count ing personnel by 70%, but mora le plummeted, skilled people left t he com-

pany, an d the system wa s disinstalled when the compan y wa s acquired.

35. These metrics include business, human, and adaptability outcomes (Silver,

Ma rkus, & B eat h, 1995).

36. Hirt (Hirt & Swanson, 1999) studied an organization in a declining industry

wit h severe profit pressure tha t implemented SAP to reduce mainfra me com-

puter costs and solve the Y2K problem. Because the company had done some

process redesign before implementin g S AP, it did not do more reengineering w hen

a dopting SAP. La ter, though, the compa ny w ondered whether more reengineering

would have produced better gains.

37. See the chapter by Agarwa l, this volume.

38. See the chapter by Robey a nd B oudreau, t his volume.

39. See the chapters by Ba rua and Mukhopadhyay and by Robey and B oudreau,

this volume.

40. This ph a se model differs from t ha t proposed by R oss (1999).

41. We borrowed this term from Nidumolu (1995).

42. Perrow (1972) would argue that tight coupling increases the likelihood of var-

ious kinds of fa ilures.

p

The Enterprise System Experience - From Adoption to Success

Documents

Transcript of The Enterprise System Experience - From Adoption to Success