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-
Although enterprise derstanding the impli-
cations of these prob-
resource planning lems and learning how
to mitigate the risks
may be the toughest they pose will be vital to
project youve ever the success of ERP pro-
jects on and off the
attempted, doing it Web.
right will be the key
ERP DEFINED
to implementing ERP productssuch
as those by SAP, Baan,
a successful JDE, SSA, JBA, Or-
e-business. 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, todays 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 companys 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, Oracles ERP product is among the
most flexible; SAPs is among the least flexible.
Over the past few years, ERP products special-
ized for particular industry segmentssuch as the
apparel industrys JBA System 21 Stylehave
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 youll
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 clients total IT envi-
ronment. Some ERP components are self-con-
tained software packageseither 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.
Inside
Strategic Options for
Enterprise Reengineering

22 IT Pro January February 2000 1520-9202/00/$10.00 2000 IEEE

DOCUMENTED ERP PROBLEMS
Since the early 1990s, many companies worldwide have
attempted to implement ERP systemsand 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-
temsthese 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 Keyboards
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 cant 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 failuresalthough 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.
In one survey, 62 percent of
respondents cited people issues
as a prime problem in taking
ERP projects live.
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 reports 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
January February 2000 IT Pro 23

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 companys opera-
tions. The following choices describe the spectrum
of strategic options available for reorganizing a
companys 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.
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 lotthe ones that survived most of the
process, management, and technology risks that kill so many
other projects before they can go live. So its 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 versionis 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 Intl 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 architecturesor 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 dont 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
because IT shops must upgrade the
customizations each time a vendor Figure 1. E-business system architecture.
upgrades the base ERP package.
Once an ERP system is fully loaded
with the necessary corporate data and
hundreds or thousands of people start
E-commerce
using it, performance can suffer if you
applications
havent designed for scalability. Users
who must wait more than a few sec- Customers
onds to see the on-screen results of
Products/
their input will not be happy. Nor will services
the regular appearance of the dreaded
blue screen of death please them.
ERPs silver lining
Although trade publications tend to
focus on ERPs failures, many ERP
projects have succeededthey just
dont 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, Ive 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 systemsa 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
ERP e-b2b
and supply
other chain
MIS/IT management
systems applications Suppliers
Parts/
services
Integrated, enterprisewide
information system
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 companys business processes are unlikely to
match the default embedded processes. Further, vendors
can implement the systems 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 dont
know who will invent this technology or even when we will
see it. Its not Java or ActiveX. Its not CORBA or DCOM,
because I also wonder where organizations will find expert
integrators who know how to architect the whole solu-
tionat present they are in extremely short supply.
Assessing project risks
Most of todays corporate CIOs and CTOs dont 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, integratabilitymodel 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-
January February 2000 IT Pro 25
 ENTERPRISE
RESOURCE PLANNING

AN E-BUSINESS
Figure 2. Typical project life-cycle model. SYSTEM PROJECT MODEL
A corporate e-business project typi-
E-business goal cally consists of five major phases, as
shown in Figure 2. These phases, per-
Strategy definition formed incrementally, usually overlap
heavily.

Existing-systems analysis and Strategy definition. Phase one ad-

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

26 IT Pro January l February 2000

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, Ive 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
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 LearningA Path to Practical Knowledge
Management (Joyce Statz and Don Oxley, Application
Development Strategies, June 1998, http://www.teraquest.
com/risk/).

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 its
back to the planning phase again.
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 Ive presented
here can provide tools for starting this process.

MANAGING ERP RISKS Herb Krasner is an independent software systems/man-

Based on my experiences with ERP projects in the agement excellence coach and troubleshooter at Krasner
1990s, Ive found that for your project to succeed, you must Consulting. Contact him at hkrasner@cs.utexas.edu.
prevent problems in the following high-priority areas:

e-business strategy,
project management approaches,

RENEW
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, your Computer Society
avoidable, and detectable early. One viable approach to membership for
reducing the likelihood of failure is to identify the crucial
risks at each point of the project life cycle, then build plans The best rates for
to address them before they become real problems. I have IT Pro
found this technique useful in evaluating ERP projects
and fully expect it to be useful for evaluating e-business 12 issues of Computer
system projects as well.
My colleagues at TeraQuest and I have built a risk fac- Member discounts
tors model-and-analysis toolset for these types of e-busi- on periodicals,
ness-system projects (see http://www.teraquest.com).The conferences, books,
model captures the experience gained from studying ERP proceedings
failures as well as from identifying areas of improvement
in the management capabilities of organizations that per- Free membership in
form large software projects using component packages. Technical Committees
For example, the toolset identifies 76 risk factors in eight
key categories for consideration when selecting an ERP or Digital library access
e-commerce package. It then rates these factors as low-, at the lowest prices
medium-, or high-risk indicators.Working with the factors
and toolset, a project team uses the high-rated factors to Free e-mail alias
plan for the mitigation of a risky selection decision. @computer.org
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 http://www.ieee.org/renewal
started. Data collected from all these sources provides a

January February 2000 IT Pro 27