Ensuring e-business success by learning from ERP failures

Abstract

Although enterprise resource planning may be the toughest project
you've ever attempted, doing it right will be the key to implementing a
successful e-business. Based on his own experiences with ERP projects in
the 1990s, the author found that for your project to succeed, you must
prevent problems in the following high-priority areas: e-business
strategy; project management approaches; complex technology and systems;
and end-user resistance. A small investment in understanding, analyzing,
tracking, and preventing these major problems should pay off well, given
that most such problems are common, expected, avoidable, and detectable
early. One viable approach to reducing the likelihood of failure is to
identify the crucial risks at each point of the project life cycle, then
build plans to address them before they become real problems. The author
found this technique useful in evaluating ERP projects and fully expect
it to be useful for evaluating e-business system projects as well

Full text

22 IT Pro January ❘ February 2000
1520-9202/00/$10.00 © 2000 IEEE
ERP IMPLEMENTATION
Ensuring
E-Business
Success by
Learning from
ERP Failures
Herb Krasner
I
n the 1990s, a plethora of companies at-
tempted to use enterprise resource planning
systems to support and improve their internal
business processes or to address Y2K com-
pliance issues.During my recent involvement in
troubleshooting several failed ERP projects,I dis-
covered a set of common problems that besets
these projects.As the shift toward e-business accel-
erates in this decade, more companies will face
similar problems. Un-
derstanding the impli-
cations of these prob-
lems and learning how
to mitigate the risks
they pose will be vital to
the success of ERP pro-
jects on and off the
Web.
ERP DEFINED
ERP products—such
as those by SAP,Baan,
JDE, SSA, JBA, Or-
acle,and PeopleSoft—
conceptually contain a
set of functional com-
ponents, integrated around an enterprise data
warehouse. These components provide auto-
mated support in traditional business process
areas such as inventory control,material require-
ments planning,and order processing.
With each product suite emerging from a dif-
ferent historical perspective, today’s ERP prod-
ucts offer a wide variety of capabilities. People-
Soft,for example,began by specializing in back-
office systems,then expanded into the front office.
Oracle specialized in relational database man-
agement systems, branched into data warehous-
ing,and then moved into ERP. SAP started by
specializing in manufacturing automation before
expanding into other areas.Thus, each product
derives its strengths and weaknesses from its his-
tory and its company’s current business strategies.
Some vendors design their products to be flex-
ible in capturing and using customer business
processes;others dictate the processes to be used.
For example,Oracle’s ERP product is among the
most flexible; SAP’s is among the least flexible.
Over the past few years, ERP products special-
ized for particular industry segments—such as the
apparel industry’s JBA System 21 Style—have
also emerged.
Highly complex, ERP systems contain many
hardware,software,and peopleware components
that can be interconnected in a variety of patterns.
Pop the hood on one of these systems and you’ll
find dozens of parts and millions of lines of code.
These systems are further complicated by the het-
erogeneity of the connected components, the
newness of the underlying technology, and the
need for integration into the client’s total IT envi-
ronment. Some ERP components are self-con-
tained software packages—either custom-built or
standard products. For example, SAP/R3, Baan,
and others now offer various client-server prod-
ucts that reside within an overall ERP system
architecture.
Although enterprise
resource planning
may be the toughest
project you’ve ever
attempted, doing it
right will be the key
to implementing
a successful
e-business.
Strategic Options for
Enterprise Reengineering
Inside

January ❘ February 2000 IT Pro 23
DOCUMENTED ERP PROBLEMS
Since the early 1990s,many companies worldwide have
attempted to implement ERP systems—and failed.Maga-
zines like Fortune,Datamation,and Information Week have
published articles on these failures.This publicity has cre-
ated the perception that large ERP implementation proj-
ects are dangerously failure-prone.To support my consulting
work,I have gathered a large compendium of such failures.
Consider the following excerpt from the Harvard Business
Review (Thomas H.Davenport,“Putting the Enterprise into
the Enterprise System,”July/Aug.1998,p.2).
ERP systems are expensive and difficult to implement.The
growing number of horror stories about failed or out of
control projects should certainly give managers pause. ...
Some of the blame for such debacles lies with the enor-
mous technical challenges of rolling out enterprise sys-
tems—these systems are profoundly complex ..., and
installing them requires large investments of money,time
and expertise ....The biggest problems are business prob-
lems.Companies fail to reconcile the technological imper-
atives of the enterprise system with the business needs of
the enterprise itself.
ERP systems resemble many other large, complex,
sophisticated IT systems. Extremely risky and failure-
prone to begin with, an ERP system by its very nature
courts greater risk than other system types,as the follow-
ing comment shows (Susan Conner,“And the Keyboard’s
Connected to the Backbone,”Chemistry and Industry,18
May 1998,pp.1-2):“The most obvious problem with ERP
implementations is that these projects are so large and so
complex that you can’t tell the implementation of the soft-
ware apart from re-engineering the business.”
These complexities can cause problems with manage-
ment,users,and technical issues.
Management problems
Most ERP disasters reported in the trade press and open
literature stem from management failures—although few
companies will admit to it.Many more such disasters have
gone unreported, an assessment supported by studies of
IT project failures in general (CHAOS, The Standish
Group,http://standishgroup.com/visitor/chaos.htm).
Previous articles have focused on the management dif-
ficulties involved in running a complex ERP project.For
example, Marie Benesh (“Managing Your ERP Project,”
Software Testing and Quality Engineering,July/Aug.1999,
pp. 38-43) describes five areas of common management
pitfalls that involve shortcomings in or a lack of
• integrated project team planning,
• managed communications across many people,
• a formal decision-making process,
• an integrated test plan and managed test process,and
• applying lessons learned from earlier implementations
to later implementations.
Another report (Stanley Wee,“Juggling Toward ERP
Success,” ERP News,Apr. 1999, pp.7-8) also focused on
management process issues as one lesson learned from
interviewing ERP customers.The key to success in over-
coming management problems,according to this report,is
to establish and maintain momentum by paying attention
to the following factors: focus, teamwork, defined scope,
business case analysis,planned training and support,smart
reengineering,overall architecture,rigorous project man-
agement, effective communication of expectations, and
top-management involvement.The report did not address
technology issues.
User problems
Financial services firm Deloitte & Touche conducted in-
depth interviews with 164 individuals at 62 Fortune-500
companies (The Review, Maximizing the Value of ERP-
Enabled Processes, Deloitte & Touche, 18 Jan. 1999).All
companies included in the report manufacture consumer
products,and all use ERP systems by vendors such as SAP,
Baan,Oracle,and PeopleSoft.The study focused on going
live:that point when the ERP system is made available for
general use within the company.
The study concluded that when issues and obstacles
occur before going live,they do so for the following reasons
and in the proportions reported (the report’s listed values
do not total 100 percent):
• people obstacles,62 percent;
• business process issues,16 percent;and
• information technology (technical) issues,12 percent.
After going live, people issues still dominate, but the
emphasis of concern shifts to such areas as ongoing sup-
port, business performance, reporting, system transition,
and training.Within IT issues, only about 5 percent of
respondents considered software functionality an obsta-
cle both before and after going live.
Unfortunately, the point at which a project should go
live is not universally defined and may not always be a firm
milestone on the basis of rigorously preestablished crite-
ria.Despite the relative proportions cited for the problems
identified,the impact of those problems does not occur in
In one survey, 62 percent of
respondents cited people issues
as a prime problem in taking
ERP projects live.

ENTERPRISE
RESOURCE PLANNING
the same proportions.Thus,how you deal with these obstacles
may be quite different.
Significantly,systems that suffered problems when going live
were the best of the lot—the ones that survived most of the
process, management, and technology risks that kill so many
other projects before they can go live.So it’s really no surprise
that the remaining issues that confronted these projects
involved people problems.
Technical problems
When you autopsy a failed ERP project,identifying the prob-
lems that occurred along the way can provide indicators of the
failure to come. Many ERP projects are plagued by complex
technical problems,which fall into the following general cate-
gories:
• nonrobust and incomplete ERP packages,
• complex and undefined ERP-to-legacy-system interfaces,
• middleware technology bugs,
• poor custom code,and
• poor system performance.
The ERP package vendor promises that its product—
usually the next version—is robust and has all the func-
tions and features to support your business processes.
If you naively believe it, go to the end of the line.
Independent certification of such a package can be
worth its weight in gold,and firms are setting up shop
to do this (for an example, see Hugh Klipp,“Quality
Assurance Services for ERP,”Proc.Ninth Int’l Conf.
Software Quality,American Society for Quality,Milwaukee,
Wis.,1999,pp.131-144).
To function,an ERP package must be placed in an IT envi-
ronment that already contains other systems.The interfaces
between these systems are complex and significantly affected
by the overall IT integration approach.You will need rigorous
legacy-systems analysis to precisely understand the ERP-inter-
facing requirements.You should also document each major
interface definition.
Middleware technology has emerged as the glue to interface
these various systems and applications over a distributed ERP
system.You can choose from several standard approaches—
based on CORBA (Common Object Request Broker Archi-
tecture),DCOM (Distributed Component Object Model),and
other distributed architectures—or roll your own.Be aware
that buggy client-server messaging or object-sharing tech-
nologies will bring the entire system to a halt.
Most ERP packages don’t cover all the specific business
requirements,and therefore you may need a certain amount of
customization to complete the fit.In some troubled projects,cus-
tom-code development started without sufficient thought and
planning.The subsequent undisciplined development produced
poor-quality code with unexpected,unlocalized side effects that
arose from poor structuring.Custom code also significantly raises
the total cost of ERP system ownership over the long haul
Strategic Options
for Enterprise
Reengineering
A first step in enterprise resource planning is to
reengineer,downsize,rightsize,or otherwise stream-
line business processes in pursuit of a competitive
edge or greater efficiency.This process,sometimes
called enterprise reengineering, promises big re-
wards but also carries big risks.
ER initiatives start with a planned strategy for
streamlining and integrating the company’s opera-
tions.The following choices describe the spectrum
of strategic options available for reorganizing a
company’s business processes.
➤ Functional centralization. This option man-
dates that a single organizational unit performs
all common business functions, such as human
resources or accounting.
➤ Functional standardization. Taking a cloning
approach, this option has one business process
fit all business units and mirrors that
uniformity in the IT systems’ im-
plementation. Functional stan-
dardization implies that a com-
pany must standardize on hard-
ware platforms, choose a standard
suite of ERP packages, then con-
vert each and every business unit
to those standards.
➤ Distributed functional specialization. This
option designates a selected business unit as a
center of excellence for a specific business func-
tion; the selected unit then performs that func-
tion for the whole corporation. Partial functional
specialization allows each business unit to con-
trol its own core MIS functions, such as sales
processing and inventory control, but also cen-
tralizes a limited set of business functions,such
as accounting,across the company.
➤ Functional business unit autonomy. This de-
centralizing option exemplifies the noninte-
grated enterprise approach, allowing each unit
to go its own way.
➤ Radical redesign of business processes. An
organization could choose this option in
response to a paradigm shift in which a new
approach replaces the normal business flow.
Hybrid strategies combine features of these basic
options. For example, you can loosely coordinate
standardization,allowing each business unit to pur-
sue an independent IT strategy,but insisting that it
still cooperate with business units on bulk hardware
and software purchases.

January ❘ February 2000 IT Pro 25
but that rarely happens.Even progressive companies have
done so well on the front end that they are now unable to
meet customer demands with sufficient product offerings
or services.
Lack of strategic thinking seems to get many companies
in trouble.For example,no matter how much a given com-
pany may want its e-business to run off a turnkey system,
the components that make up these systems will not come
from a single source any time soon.Even if such a system
existed, a company’s business processes are unlikely to
match the default embedded processes.Further, vendors
can implement the system’s component pieces with dif-
ferent underlying technologies and designs, forcing the
organization to overcome much greater integration chal-
lenges than if the underlying infrastructure was consistent.
Consequently,I believe that new middleware technology
must emerge that lets us glue these systems together.I don’t
know who will invent this technology or even when we will
see it.It’s not Java or ActiveX.It’s not CORBA or DCOM,
because I also wonder where organizations will find expert
integrators who know how to architect the whole solu-
tion—at present they are in extremely short supply.
Assessing project risks
Most of today’s corporate CIOs and CTOs don’t under-
stand the complexities of establishing an e-business.Aside
from the enormous management and people challenges,
many technical challenges confront such projects.
Examining e-business through the lens of the FURPSI—
functionality,usability,reliability,performance,supporta-
bility, integratability—model of system quality (Herb
Krasner,“Using FURPSI for Software Product Quality
Evaluations,”to appear in Software Quality Professional,
June 2000), I see increased technical risks in several areas.
• Functionality.Systems will need to support a more inte-
grated style of business processes, including womb-to-
because IT shops must upgrade the
customizations each time a vendor
upgrades the base ERP package.
Once an ERP system is fully loaded
with the necessary corporate data and
hundreds or thousands of people start
using it,performance can suffer if you
haven’t designed for scalability.Users
who must wait more than a few sec-
onds to see the on-screen results of
their input will not be happy.Nor will
the regular appearance of the dreaded
“blue screen of death”please them.
ERP’s silver lining
Although trade publications tend to
focus on ERP’s failures, many ERP
projects have succeeded—they just
don’t seem to get much press.One well-documented excep-
tion is Cisco Systems, which reportedly installed a com-
pany-wide ERP system for about $30 million in only nine
months (Cisco Systems,Inc.:Implementing ERP,Harvard
Business School Publishing,Report 9-699-022,20 Oct.1998,
http://www.hbsp.harvard.edu).When you look closely at
what Cisco did,you realize it has taken IT to a new level,
integrating with its suppliers and customers to an amazing
degree,and realizing tremendous efficiencies and capabil-
ities as a result.It showed that a strong focus on business
goals in defining a system could lead to business success.
E-BUSINESS SYSTEM CHALLENGES
E-business systems are the latest fad in advanced IT and
business process improvement.Figure 1 shows the emerg-
ing architecture for such a system in a large company.
While watching some of my clients join the e-commerce
game,I’ve often observed that the following “ease into it”
scenario works well.These clients start easy,establishing
a Web site presence.Then they incrementally redesign
their Web page to add better organization, additional
information,enhanced searching,linking,and interactive
capabilities.Next,they attempt the challenging task of tak-
ing customer orders or handling customer transactions via
their Web page. If they clear this hurdle, they attempt to
integrate their Web-based front-end system with existing
legacy IT systems—a task so difficult that many organi-
zations fail to implement it.If they successfully integrate
their legacy systems, they then try adding other e-com-
merce capabilities,like supply chain management.Finally,
with all these capabilities in place, they begin to see new
ways of running their business and start improving their
systems and processes accordingly.
Strategic vision is key
If the organization has analyzed, planned, and archi-
tected well,the system functions as a fit and useful whole—
Integrated, enterprisewide
information system
E-commerce
applications
ERP
and
other
MIS/IT
systems
e-b2b
supply
chain
management
applications
Customers
Suppliers
Products/
services
Parts/
services
Figure 1. E-business system architecture.

26 IT Pro January l February 2000
tomb management of customer, company, contractor,
and supplier relationships.
• Usability.Systems must support the emerging point-and-
click generation.
• Reliability.Systems must achieve the uptime goal of 24
hours a day, seven days a week, with 99.9999 percent
availability as the backup goal.Systems also need to be
safe and resistant to illegal penetrations.
• Agility. Demand for shorter Web response times will
grow as people tire of the World Wide Wait.
• Supportability.Systems must improve their capabilities
in a smooth evolution rather than through a constant
barrage of herky-jerky upgrades and bug fixes.
• Integratability. Complexity will drive the movement
toward component-based integration and glueware—
the Lego block approach.More organizations will move
toward a distributed system built around a tiered archi-
tecture.
When you add up the management,people-resistance,and
technical-complexity risks,it’s a wonder any substantive e-
business system project successfully achieves its lofty goals.
In this decade,existing ERP systems will expand to meet
e-commerce and supply chain management systems.Major
new versions of ERP software will be rearchitected to use
new technologies like Java and XML.The common archi-
tectural stratification standards may also give way to new
distributed-systems approaches.For example,it’s not clear
how existing client-server systems will meld with Web-
based technologies.
ENTERPRISE
RESOURCE PLANNING
AN E-BUSINESS
SYSTEM PROJECT MODEL
A corporate e-business project typi-
cally consists of five major phases, as
shown in Figure 2. These phases, per-
formed incrementally, usually overlap
heavily.
• Strategy definition. Phase one ad-
dresses the creation of a corporate e-
business strategy that contains a vision,
objectives, and an approach to
automating,improving, and integrat-
ing the company’s business processes
across the entire enterprise.The strat-
egy also defines the general scope of
an e-business system in terms of how
it will support the organization’s busi-
ness processes.
• Existing-systems analysis and new sys-
tem capability planning. Phase two
begins with an analysis of existing
legacy systems, followed by the plan-
ning and architectural definition of the
new system’s capabilities.
• System definition and development. Phase three involves
the precise definition and development of the integrated
e-business computer system that will provide support
for each of the company’s designated business units.
• Deployment. Phase four focuses on deploying the
e-business system within one business unit or across sev-
eral to support the organization’s business processes.
• Use and evolution. Phase five occurs when the organi-
zation effectively uses the deployed system—for
example,to improve the organization’s efficiency,effec-
tiveness, or competitiveness.Lessons learned from this
use feed back into earlier phases as the system evolves.
To reap the e-business system’s promised benefits, all
phases must succeed.Mistakes made in the first phase will
poison efforts in the second,and so on.
In some cases, an organization will outsource portions
of the project.For example,instead of the company’s own
MIS or IT department,you could contract with an IT sys-
tems integration company to develop the e-business sys-
tem. This solution presents a double-edged sword,
however:While outsourcing can supplement your com-
pany’s systems knowledge,it also exposes your company
to some risks in terms of performance and a knowledge
gap within your organization.
In the past decade,most ERP projects occurred over a
multiyear cycle. In this decade, however, increased com-
petitive pressures will demand that e-business systems be
delivered even more rapidly.The challenge of accelerat-
Strategy definition
Existing-systems analysis and
new system capability planning
System definition and development
Deployment
Use and evolution
E-business goal
Time
Figure 2. Typical project life-cycle model.

January ❘ February 2000 IT Pro 27
ing these phases will lead to rapid,incremental,and iter-
ative approaches to the essential activities of planning,
systems analysis,system definition,hardware acquisition,
software acquisition,custom software development,sys-
tems integration,testing,documentation,pilot use,instal-
lation, and evolution.
In ERP projects,I’ve seen many cases in which signifi-
cant iteration occurred both within the early phases and
across those phases.For example, it is not uncommon to
see the first and second phases iterate several times before
the planning is sound.Often,people think they know what
processes they want to automate right to the point when
the requested software packages actually come in-house.
Then gap analysis tells them it would be a lot cheaper to
adapt their processes than to rebuild the software,so it’s
back to the planning phase again.
MANAGING ERP RISKS
Based on my experiences with ERP projects in the
1990s,I’ve found that for your project to succeed,you must
prevent problems in the following high-priority areas:
• e-business strategy,
• project management approaches,
• complex technology and systems,and
• end-user resistance.
A small investment in understanding,analyzing,track-
ing,and preventing these major problems should pay off
well given that most such problems are common,expected,
avoidable, and detectable early. One viable approach to
reducing the likelihood of failure is to identify the crucial
risks at each point of the project life cycle,then build plans
to address them before they become real problems.I have
found this technique useful in evaluating ERP projects
and fully expect it to be useful for evaluating e-business
system projects as well.
My colleagues at TeraQuest and I have built a risk fac-
tors model-and-analysis toolset for these types of e-busi-
ness-system projects (see http://www.teraquest.com).The
model captures the experience gained from studying ERP
failures as well as from identifying areas of improvement
in the management capabilities of organizations that per-
form large software projects using component packages.
For example,the toolset identifies 76 risk factors in eight
key categories for consideration when selecting an ERP or
e-commerce package. It then rates these factors as low-,
medium-,or high-risk indicators.Working with the factors
and toolset,a project team uses the high-rated factors to
plan for the mitigation of a risky selection decision.
IT personnel currently use the toolset to analyze lessons
learned on completed projects,review the status of proj-
ects under way, and assess risk planning as projects get
started.Data collected from all these sources provides a
growing knowledge base of common risks encountered,
thus enabling less problematic acquisitions of such pack-
aged systems.For more information about how this tech-
nique has been used in past situations for organizational
risk management, see the article “From Project Risks to
Organizational Learning—A Path to Practical Knowledge
Management” (Joyce Statz and Don Oxley, Application
Development Strategies,June 1998,http://www.teraquest.
com/risk/).
I
f you consider your e-business system project to be cru-
cial to the future of your organization,you should want
to treat the knowable risks to success formally and
proactively so that you can focus resources and mitigate
potential project failures.The techniques I’ve presented
here can provide tools for starting this process. ■
Herb Krasner is an independent software systems/man-
agement excellence coach and troubleshooter at Krasner
Consulting.Contact him at hkrasner@cs.utexas.edu.
✔ The best rates for
IT Pro
✔ 12 issues of Computer
✔ Member discounts
on periodicals,
conferences, books,
proceedings
✔ Free membership in
Technical Committees
✔ Digital library access
at the lowest prices
✔ Free e-mail alias
@computer.org
RENEW
RENEW
your Computer Society
membership for
your Computer Society
membership for
http://www.ieee.org/renewal