How Walmart's Supply Chain Innovation Led to Dominance

Wal-Mart Used Technology to Become Supply Chain Leader
by Todd Traub
Posted 7/2/2012 in Arkansas Business
_____________________________________________________
_________________________
It is hard to talk about supply chain management without
mentioning Wal-Mart.
In its relentless pursuit of low consumer prices, Wal-Mart
embraced technology to become an
innovator in the way stores track inventory and restock their
shelves, cutting costs and passing
the savings along to customers. In the process the company
became synonymous with the
concept of successful supply chain management.
“I don’t believe there is a university in the world that doesn’t
talk about Wal-Mart and the supply
chain,” said James Crowell, director of the Supply Chain
Management Research Center at the
Walton College of Business. “They are just so well respected
because they do it so well, and
certainly I know a lot of peer institutions around our country …
will bring a Wal-Mart guest to
speak.”
From ancient times through two world wars to today’s global
market, the logistics of supply
chain management have challenged any enterprise that tries to

move goods and materials a long
way in a timely manner. A break in the supply chain leading to
a dearth of food or ammunition
could spell disaster for an army on the move. For consumers and
businesses, a supply chain
breakdown means empty shelves and a loss of revenue.
Through a combination of distribution practices, truck fleet
management and technological
innovations, Wal-Mart not only became the model of supply
chain efficiency and used it to
become the largest retailer and private sector employer in the
world.
Even the U.S. military noticed. Army Col. Vernon L. Beatty,
who commanded the Defense
Distribution Depot in Kuwait, spent a year with Wal-Mart as
part of the military’s Training With
Industry program.
“Supply chain management is moving the right items to the
right customer at the right time by
the most efficient means,” Beatty said in article about his
experience. “No one does that better
than Wal-Mart.”
Fewer Links
Wal-Mart’s supply chain innovation began with the company
removing a few of the chain’s
links.
In the 1980s Wal-Mart began working directly with
manufacturers to cut costs and more
efficiently manage the supply chain. From 1993 to 2001, Wal-
Mart grew from doing $1 billion

mailto:[email protected]
in business a week to $1 billion every 36 hours, growth that was
attributed as much to supply
chain management as to customer service.
Last year, Wal-Mart sold $1.22 billion worth of merchandise
every day.
Under a Wal-Mart’s supply chain initiative called VMI —
vendor managed inventory —
manufacturers became responsible for managing their products
in Wal-Mart’s warehouses. As a
result, Wal-Mart could expect close to 100 percent order
fulfillment on merchandise.
Wal-Mart streamlined supply chain management by constructing
communication and
relationship networks with suppliers to improve material flow
with lower inventories. The
network of global suppliers, warehouses and retail stores has
been described as behaving almost
like a single firm.
“Wal-Mart’s whole thing was collaboration,” Crowell said.
“That’s a big part of what made them
so successful.”
Even in its early years, Wal-Mart’s supply chain management
contributed to its success. Founder
Sam Walton, who owned several Ben Franklin franchise stores
before opening the first Wal-Mart
in Rogers in 1962, selectively purchased bulk merchandise and
transported it directly to his

stores.
In 1989 Wal-Mart was named Retailer of the Decade, with
distribution costs estimated at a mere
1.7 percent of its cost of sales — far superior to competitors
like Kmart (3.5 percent) and Sears
(5 percent).
The company’s supply chain has only become more effective
since then.
Wal-Mart developed the concept of “cross docking,” or direct
transfers from inbound or
outbound truck trailers without extra storage. The company’s
truck fleet and corps of non-
unionized drivers continuously deliver goods to distribution
centers (located an average 130
miles from the store), where they are stored, repackaged and
distributed without sitting in
inventory.
Goods will cross from one loading dock to another, usually in
24 hours or less, and company
trucks that would otherwise return empty “back haul” unsold
merchandise.
Collaboration
Companies within the supply chain synchronize their demand
projections under a collaborative
planning, forecasting and replenishment scheme, and every link
in the chain is connected
through technology that includes a central database, store-level
point-of-sale systems and a
satellite network.

Wal-Mart implemented the first companywide use of Universal
Product Code bar codes, in
which store level information was immediately collected and
analyzed, and the company devised
Retail Link, a mammoth Bentonville database. Through a global
satellite system, Retail Link is
connected to analysts who forecast supplier demands to the
supplier network, which displays
real-time sales data from cash registers and to Wal-Mart’s
distribution centers.
“The big piece of supply chain management is Wal-Mart has the
retail link,” Crowell said, “the
information from point-of-sale data, the cash register, that they
put into their system and share
with all their partners.
“What makes that so innovative is at one time a lot of
companies weren’t sharing that. In fact,
they were using third parties where they had to pay for that
information.”
Wal-Mart’s approach meant frequent, informal cooperation
among stores, distribution centers
and suppliers and less centralized control. Furthermore, the
company’s supply chain, by tracking
customer purchases and demand, allows consumers to
effectively pull merchandise to stores
rather than having the company push goods onto shelves.
In recent years Wal-Mart has used radio frequency
identification tags (RFID), which use
numerical codes that can be scanned from a distance to track

pallets of merchandise moving
along the supply chain. Even more recently the company has
begun using smart tags, read by a
handheld scanner, that allow employees to quickly learn which
items need to be replaced so that
shelves are consistently stocked and inventory is closely
watched.
RFID and smart tags are just the next generation in supply chain
innovation that dates back to the
1960s, when Sam Walton personally attended an IBM school in
upstate New York with the
intention of landing experts to computerize operations.
Wal-Mart reaps the benefits of its supply chain management in
time saved, faster inventory
turnover, increased warehouse space and accurate forecasting of
inventory levels.
“They really understand that if I’m going to build some stores
and build some distribution
centers, how am I going to service them?” Crowell said. “If you
look at some of their
competitors, sometimes they would put a store in and then
think, ‘How am I going to service
it?’”
Reference
Traub, T. (2012). “Wal-Mart Used Technology to Become
Supply Chain Leader,” Arkansas
Business, Retrieved from
http://www.arkansasbusiness.com/article/85508/wal-mart-used-
technology-to-become-supply-chain-leader (current Sep 30,
2013).

technology-to-become-supply-chain-leader
technology-to-become-supply-chain-leaderWal-Mart Used
Technology to Become Supply Chain Leader
�� Journal of Cases on Information Technology, 11(2), ��-
�0, April-June 2009
Copyright © 2009, IGI Global. Copying or distributing in print
or electronic forms without written permission of IGI Global
is prohibited.
ExECutivE suMMary
This case illustrates the importance of vendor selection, top
management support, and team structuring in
implementing a complex ERP system. While most organizations
choose the de-facto brand as their prod-
uct, Cisco and its consulting partner, KPMG, went against this
perception and selected Oracle who was a
newcomer in ERP business. For Oracle this was a golden
opportunity to enter a market dominated by SAP
and get its ERP modules litmus tested by an industry leader.
Cisco on the other hand agreed to help Oracle
to market its latest releases to potential customers, in lieu of the
successful implementation. Oracle even
allowed changing some of its modules to fit Cisco’s purposes.
The implementation team comprised the best
people from Cisco, KMPG and Oracle. To have the customized
ERP up and running in nine months the
team blended the robustness of sequential life cycle model with
the flexibility of the iterative prototyping.
[Article copies are available for purchase from InfoSci-on-

Demand.com]
Keywords: Cisco; Contract Negotiation; ERP Implementation;
Information Systems Project Manage-
ment; Oracle; Systems Development Lifecycle; Top
Management Support
orGanization BaCkGround
Cisco Systems, Inc. was founded in 1984 by two computer
scientists from Stanford University.
Their primary product was the “router” that controlled the flow
of data between the complex
TCP/IP1 networks that made up the Internet and corporate
intranets. Demand for Cisco’s prod-
ucts increased dramatically with the rise in the use of Internet
after 1990. By 1993 Cisco was a
$500 million company and in 1997 Cisco it ranked among the
top five companies in return on
revenues and returns on assets. In the same year, Cisco entered
the Fortune 500 and reached a
market capitalization of over $100 billion.
Don Valentine, partner of Sequoia Capital and vice chairman of
the board of Cisco, was the
first to take initiative and pave the path for the young company.
He appointed John Morgridge as
CEO in 1988, whose first effort was to build a professional
management team. His management
Cisco systems:
implementing “Customized” Erp in nine
Months and within Budget
Avimanyu Datta, Washington State University, USA

IGI PUBLISHING
This paper appears in the publication, Journal of Cases on
Information Technology, Volume 11, Issue 2
edited by Mehdi Khosrow-Pour © 2009, IGI Global
701 E. Chocolate Avenue, Hershey PA 17033-1240, USA
Tel: 717/533-8845; Fax 717/533-8661; URL-http://www.igi-
global.com
ITJ 4874
Journal of Cases on Information Technology, 11(2), ��-�0,
April-June 2009 ��
is prohibited.
team clashed with the founders of Cisco systems, which resulted
in departure of the founders
after the company’s initial public offering in 1990. This
eventually enabled CEO Morgridge
to implement an extremely disciplined management structure
within Cisco. He maintained a
centralized functional organization that continued
approximately the next 10 years.
setting the stage
Cisco’s IT infrastructure was supported by a UNIX-based
software package to conduct its core
transaction processing tasks. The package supported the three
key functional areas of the company:

finance, manufacturing, and order entry. Pete Solvik, CIO of
Cisco, analyzed the UNIX-based
software package and found that it did not provide the degree of
redundancy, reliability, and
maintainability that Cisco needed to keep up with their current
business demands.
Unreliability and regular outages brought into question the
soundness of trying to modify
the current system to meet Cisco’s constantly growing needs.
An upgrade was made available,
which was a solution that offered more reliability and
redundancy2 without maintainability or
room for growth. An upgrade from their current software vendor
could not suffice for their
changing needs.
The management structure in 1993 was such that each
functional business unit made its own
decisions regarding the future of their IT systems. IT
representatives from each department were
asked to report the expenses to Slovik. Each department head
knew that further “band-aiding”
the current system was not going to be sufficient to keep up
with the company’s rapid growth.
However, no individual was willing to approach the board with
a costly and lengthy proposal
for replacement of the legacy systems.
Solvik’s initial intention was to avoid an ERP solution because
of implementations and cost
overruns. In addition, Cisco’s independent department structure
was contrary to organizational
structure supported by ERP system. Thus, Slovik planned to let
each functional area within
Cisco make its own decision regarding the software application

that they wanted to use. How-
ever, all functional areas were required to use a common
architecture and database to maintain
standardization within the company.
CasE dEsCription
failure of the Existing system
The year 1993 witnessed little change in the software support
system at Cisco. None of the de-
partments actually got itself a new and updated package.
Instead, they kept operating by fixing
the existing systems and somehow managed to carry on. In late
1993 Randy Pond, Senior VP
of Operations at Cisco, confirmed that fixing the existing
system was pointless as it would not
serve the growing needs of the firm. Finally, in January of
1994, Cisco’s legacy environment
entirely failed, resulting in companywide shut-down for almost
2 days. This was a shortcoming
that could no longer be ignored. A number of managers at Cisco
came to the conclusion that the
autonomous approach to systems replacement would not suffice
any longer.
Solvick, along with other managers, put together a plan to take
on replacement of all faulty
legacy applications in a single ERP project that would provide a
common data architecture
throughout each business unit. The analysis below will describe
in detail the points of their
implementation approach, why the project was successful,
whether the success was “smart” or

is prohibited.
“lucky” (or a combination of both), and the possibility of other
companies’ ability to replicate
Cisco’s ERP implementation technique.
the system replacement
Carl Redfield, the senior vice-president of manufacturing, took
the lead in getting a single inte-
grated replacement of all the applications at Cisco instead of
integrating separate projects in the
different functional areas. Thus, a team was formed to
investigate the best possible replacement
for the existing software support system. The factors that would
govern the implementation of
the new system were decided to be less time, low
customization3, and high priority. The company
had two options available to it:
1. Purchase a single ERP system, which would be expensive to
procure, time consuming to
implement, and would replace each department’s autonomous
structure.
2. Upgrade the existing legacy system, built to support a $300
million company, which Cisco
no longer was. With the need for a much larger system for its
growing needs, Cisco chose
to purchase a single ERP system.

ChallEnGEs
selection of partnering Consultant and a vendor
Cisco’s management team realized that implementing an
enterprise-wide system to meet the
business needs would require heavy involvement from the
business people and the people from
the IT department. Such an involvement would be required from
the beginning of the project.
The most competent people from every department were
handpicked to be a part of the ERP
implementation team. The next step that Cisco took was to
involve a consulting partner to aid
in the implementation process. Consultants are thought to be
able to use their previous ERP
implementation experiences and act as knowledge providers
who lower the knowledge deficiency
existing within organizations (Grabski & Leech, 2006). A close
working relationship between
consultants and the organization’s project team can lead to a
valuable skill transfer (Grabski &
Leech, 2006), and control over the project. Cisco was looking
for a partner who would, in addi-
tion to providing consulting services, also help Cisco to choose
the ERP vendor.
Only4 KPMG Consulting5 agreed to provide the support Cisco
was looking for. KPMG’s
portfolio in consulting combined technical and expert business
knowledge. They appeared to
be an ideal partner for Cisco because they were willing to give
them the expert resources that
Cisco required from selecting a vendor to completing the
project in as short a time as possible.

KPMG sent their best ERP Implementation program manager,
Mark Lee. Under Lee’s leader-
ship, a 20-member team from Cisco evaluated the available
software packages in the market.
Ten days were spent drafting the ERP Request for Proposal
(RFP). Using research resources
like Gartner and Forester, the team zeroed on two prime
packages. Oracle was chosen in the end
due to the following reasons:
1. Their better support for clients in manufacturing industry
2. The promises of long-term functionality development.
3. Geographical closeness of Oracle’s headquarters to Cisco.
April-June 2009 �9
is prohibited.
Oracle was particularly motivated to see the Cisco Project
succeed. This would be a first
major implementation of a new release of the Oracle ERP
product. Thus, Oracle saw an oppor-
tunity of promised success. A successful implementation at
Cisco would launch the new product
on a very favorable trajectory. With such an opportunity, Oracle
decided to put a large amount
of resources and some of their best people on the project to
guarantee its success. The contract
itself reflected Oracle’s commitment by promising capabilities,
not simply a software package. In
addition, Cisco agreed to help Oracle to market their latest

newest releases to potential customers,
in return of successful implementation within budget and time.
This gave Cisco huge bargaining
power, something it could not have had with established ERP
vendors like SAP or PeopleSoft.6
Thus, Cisco went against the conventional wisdom of selecting
the most popular brand of ERP.7
Table 1 shows a comparative analysis of SAP, PeopleSoft, and
Oracle.
setting up the Budget and schedule
The Cisco team took only 75 days from analyzing the problem
to the final selection the vendor
and finalizing the schedule and budget. At this stage, the board
of directors at Cisco was concerned
with how long the project would take and how much it would
cost. A gigantic project such as
this often consumes a huge amount of resources, spins out of
control, and delivers substandard
results in the end. The Cisco team committed to do the entire
process within 9 months and for $15
million. Cisco did not attempt to do a formal economic
justification for the costs to be incurred
in this project. They looked upon it to “institutionalize a
business model for the organization.”
It was the single largest capital project ever approved by the
company.
Managing the implementation team
Cisco expanded its team from its core 20 to 100 members for
the actual implementation process.
Once again, the team consisted of only the best people,
representing a cross-section of Cisco’s

Table 1. Comparative analysis of ERP vendors in 1994
People Soft SAP America Oracle
1995 total Revenues $210 million $ 1.1 billion $291 million
% from Software 57% 74% 54%
% from services 43% 26% 46%
1994-1995 total revenue growth 94% 88% 81%
Revenues outside United States 17% 67% 60%
Headquarters Pleasanton, California Walldorf, Germany
Redwood Shores,
California
Strengths 1. Customer service
2. Excellent functionality
3. Growing network of
partners
1. Broadest functionality
in integrated product
suite.
2. Size and market
presence
3. Broad support from
partners
1. Large installed base
of Oracle Customers
2. Global presence
3. Link to other Oracle
technologies

Weaknesses
1. 1. Aging Technology
2. Poor—cross product
integration
3. credibility in non-HR
products
1. Long complex
implementation.
2. backlash against high
cost
3. Inflexible
1. Limited to HR
functionality.
2. Weak Service
partner program
3. limited to Oracle
database
�0 Journal of Cases on Information Technology, 11(2), ��-
is prohibited.

business units. Cisco’s policy emphasized that this was a short
term project and would not impact
anyone’s career.
At the start of the implementation, the team members were split
up into five “tracks,” or
processes, each relating to a functional area Order Entry,
Manufacturing, Finance, Sales/Report-
ing, and Technology (Figure 1). Each track consisted of a Cisco
information systems leader, a
Cisco business leader, business and IT consultants from either
KPMG or Oracle, and personnel
from Cisco as team members. The five tracks were managed
from a Project Management Office
(PMO), which consisted of Cisco’s business project manager,
and KPMG’s project manager.
Monitoring the PMO was an Executive Steering Committee that
consisted of the senior-most
executives from Cisco, KPMG, and Oracle. The strategy behind
using the steering committee
was to relieve the development team of the need to intervene
directly in the management of the
project.
implementing oracle in iterative prototyping
Usually, an ERP is implemented in a sequential model as shown
in Figure 2. But Cisco employed
rapid iterative prototyping (Figure 3) as the development
technique for the implementation of
the ERP. This is because Cisco wanted to keep open the
provision to change Oracle codes to
suit its purpose. This customized coding was not offered by
other vendors. Oracle, being new
and promised with marketing assistance from Cisco, had no
option but to agree with Cisco’s

methodology.
Figure 1. Organizational structure of ERP implementation8
Executive Steering Committee
Comprised
Management from
Cisco, Oracle and KPMG
Monitored the Progress of project
Management office (PMO)
Project Management Office (PMO)
Responsible Implementation of the modules of Oracle
The team comprised of Mark Lee from KPMG, Slovick,
Pond and Redfield from CISCO, and the Project
Management team from ORACLE
Order Entry
• Cisco Business
Leader
• Cisco System
Leader
• 10-20 Personnel
from Cisco
• 1 IT consultant from
KMPG

Oracle
Finance
• Cisco Business
Leader
• Cisco System
Leader
• 10-20 Personnel
from Cisco
KMPG
Oracle
Sales/reporting
• Cisco Business
Leader
• Cisco System
Leader
• 10-20 Personnel
from Cisco
KMPG

Oracle
Technology
• Cisco Business
Leader
• Cisco System
Leader
• 10-20 Personnel
from Cisco
KMPG
Oracle
Manufacturing
• Cisco Business
Leader
• Cisco System
Leader
• 10-20 Personnel
from Cisco

KMPG
Oracle
5 Modules of oracle
Focus Group for
Customizing Oracle
Modules to fit Cisco’s
Business Processes
when Oracle realized
that the low
customization was not a
option.
is prohibited.
Figure 2. Sequential model of ERP implementation
Figure 3. RAD using iterative prototyping9
Strategy and
Planning:
Requirement
Analysis

Design and Blueprint:
Requires high interaction
with end-users. The internal
team and the consultant
must work together
Software
configuration
Application
customization: Similar to
Corrective, Adaptive, and
Perfective maintenance
Data migration: involves
populating the new ERP
master file with data from
existing system
Developers
Conception
Customer’s
Conception
Divergence
V
E
R
S
I
O
N

3
V
E
R
S
I
O
N
2
V
E
R
S
I
O
N
N-
1
Changes
Defects
Performance
Scope
Concept

Requirements
TOTAL
PACKAGE
JAD Session Focus Group Sessions
2-6 months
JAD refers to Joint Application Development, where the end
users and the developers meet
to note a rough list of specifications. Usually it compromises
80% of the requirements requir-
ing 20% of the effort. The remaining 20% customized solutions
are generated through focused
group sessions.
The implementation was broken into a series of phases called
“conference room pilots”
(CRPs). The purpose of a CRP was to build on previous work in
order to develop a deeper
understanding of the software and how it functioned within the
business environment and to
better configure the software to suit the company’s needs.
(Figure 4 shows how Cisco blended

is prohibited.
Table 2. Deliverables for each of the CRPs
Stage/ Prototype Deliverables and tasks
CRP 0
Training Cisco’s Employees on Oracle Package
Spelling out 80% of the requirements
Selection of Data settings of Oracle System for Cisco’s business
needs.
Delivery of the first Prototype
CRP1
(Built on CRP 0)
Customization of CRP 0, according to the requirements of the
departments, supported
by Oracle’s 5 modules (Order Entry, Manufacturing, Finance,
Sales/Reporting,
Technology )
Modify Oracle’s coding to match exact requirements of Cisco.
CRP 2
Enhancements,
Perfection, and
Testing
Enhancement of CRP 1 to add the following features:
1. Incorporation the new after-sales support package
2. Building a data warehouse to view historical data and project

future data
through data mining
Load testing the entire project
Figure 4. Blending of waterfall and iterative prototyping
the waterfall model with iterative prototyping from systems
analysis to final delivery. Table 2
shows the deliverables and tasks associated with each CRP).
CRP0 began with training the implementation team and setting
up the technical environ-
ment for the implementation. Here, two parallel efforts were
launched. The first effort involved
Analyze the
problem in existing
system
Evaluate Alternative
Solution
s and Zero
into one
Select Consulting
Make RFP

Select ERP Vendor
Make Contract
Create the team
Develop the system
in Prototypes
CRP0: First Iteration
CRP1: second Iteration
CRP2: Third Iteration

is prohibited.
training Cisco’s team members on the Oracle applications
through 2 days of intensive training.
While most ERP implementation requires 6 months to analyze
the system,10 CISCO with 40
people spent only 2 days for the same. In addition, the 5 day
training session that was required
to know the application suite was reduced to 2 16-hour days. At
this stage, 80% of the require-
ments were spelled out. The remaining 20% of customized
requirements were identified later.
Simultaneously, the second effort worked on setting up the
Oracle applications. The training
of the entire team was completed within a 2-week period.
Following this, the team members
spent 2 more days in intensive group meeting to decide on the
appropriate data settings11 for the
hundreds of parameters embedded within the Oracle software
that were to be set according to
their particular business needs. One week after this meeting,

CRP0 was successfully completed.
It implemented the capacity to take a Cisco order all the way
through the company’s business
process from its quotation to payment.
The implementation of CRP0 brought forward an important fact
that the initial target of
implementation with low customization of the Oracle software
would not be successful. This
made the process more time consuming. Thus, CRP1 was
started, building on the lessons learned
with CRP0. The goal of this phase was for each of the five
tracks/modules (Figure1), to make
the system work within their specific area. This was the focused
group geared toward custom-
izing the system. Oracle had to modify12 chunks of existing
codes to match Cisco’s customized
requirement. Cisco’s promise of future marketing partnership
left Oracle with no option. Team
members documented the purpose and procedures to complete
every process, and problem issues
were addressed in weekly 3-hour meetings with the PMO.
During CRP1, the team realized that there were many business
processes that the software

could not support. The implementation team developed a means
for categorizing and evaluating
each instance separately. All modifications were classified as
red (extremely critical), yellow
(critical), or green (moderate). In the end, 30 developers spent 3
months to modify Oracle to sup-
port the Cisco business process. In addition, the implementation
team understood that the Oracle
package would not adequately support the after sales support
needs of the company. So the team
launched a parallel effort to evaluate and select a separate
service support package. The service
package was selected and implemented within the same
schedule as the Oracle package.
The beginning of CRP2 saw the most difficult part of the
implementation. Cisco’s initial
target of low customization was given up, and a highly
customized system was built in the end.
It included major modifications in the Oracle software,
inclusion of a new after-sales support
package, and implementation of a new approach for data
communication via a data warehouse.
The feature included capability to report historical and future
data in the integrated data ware-

house.
The scope change involved further adjustments to Cisco’s
resource structure for the project.
The final goal of CRP2 was to begin testing the system, to see
how well it could stand up to the
processing load and transaction volumes required to support
Cisco’s growing business. CRP2’s
focus was on testing the system with full transaction load and
assessing the date when the system
could start operation. All these were accomplished within the
initial schedule.
The Initial Instability and Its Correction
On starting operation, the new system proved disturbingly
unstable. On an average, it went down
nearly once a day. The primary problem was with the hardware
architecture, and secondarily
with the software that could not handle the transaction volume
required in the Cisco environ-
ment. Cisco realized that their mistake was that they had not
tested the system with a big enough
database. They had run individual processes sequentially with
only a partially loaded database.

is prohibited.
After “cutover,” when all the processes were running together
over a fully converted database,
the system lacked the capacity to process the required load.
The Hardware Contract
Correcting the inefficiency meant purchase of additional
hardware, thus increasing the project
expenditure for Cisco. Cisco pulled out an unusually attractive
deal. The deal was to purchase
a promised capability, rather than a specific configuration. In
the end, all the pieces fell into
place with the new system fulfilling the promise of supporting
the rapid growth that Cisco was
expecting in the years to come. As a result, the responsibility

for fixing the hardware problems
fell completely on the hardware vendor.
Stabilization
The technical problems associated with Oracle proved short
lived. Strong vendor commitment
from Oracle and the hardware vendor and experienced support
from KPMG lead to an eventual
stabilization and substantial improvement in performance, after
3 months.
Results
Cisco was extremely successful in terms of the overall
performance of the system. With major
customizations, the system was working well. The only trouble
that had plagued the implementa-
tion was the issue of hardware capacity, which was later
rectified with a match winning contract
with the hardware vendor. The complete system performance
was worked out when the project
team did its CRP design and testing. By building on the
previous version of CRP, the team was
able to optimize its functionality. At the end of the

implementation, the cutover was successful
because of strong coordination between each company involved.
The overall cost expectancy
was met. The goal of the project was to have the budget at or
below $15 million. Cisco reached
this goal and also decided to provide its hard working
implementation team with a bonus pool
of over $200,000.
disCussion
From the initial conception of the project, its leaders, Solvick,
Pond, and Redfield, knew what
they wanted: a large system in a short amount of time that
contained the ability to adapt and
grow concurrently with their business, and a provider that was
going to be around to support
their product well into the future. The decisiveness of the
leaders on what they wanted pushed
the selection process forward in a short amount of time. Senior
management fully backed the
project and was kept informed on every step. From the very
beginning a strong schedule and the
backing of the top management helped to insure success of the
project. Because of top manage-

ment support, the project team was not required to go through
formal processes of management
approval, which further sped up the implementation
DiMaggio and Powell (1983) argued that structural change in
organization is driven less
by considerations of effectiveness, innovativeness, but rather by
structuration in organizational
fields. This they termed Isomorphism and classified into two
categories: competitive and insti-
tutional. Further they identified three types of institutional
isomorphism. While, Coercive Iso-
is prohibited.
morphism is based on political influence or the problem of
legitimacy, normative isomorphism
is based on professionalism and structuration of organizational

fields and mimetic isomorphism
that is based on standard responses to uncertainty. According to
DiMaggio and Powell (1983),
the majority of organizations are followers (reactive). Thus,
most organizations do not sense a
change in environment unless one of its competitors has adopted
a technology. Following the
conventional wisdom of reactive stance and address uncertainty,
Cisco would have opted for
SAP’s R3, which was the de facto industry standard. But they
selected Oracle instead. From
the very beginning till the end, Cisco did not lose sight of the
project and were in full control of
the ERP implementation. Since this was Oracle’s first major
ERP account, they got maximum
opportunity to test, retest, alter, customize, and standardize
their modules.
Karimi, Somers, and Bhattacherjee (2007) mentioned the
critical success factors to ERP
implementation success are: top management support, project
management resources, consul-
tant resources, and training resources. Woo’s (2006) list of
critical success factors included top
management support, project team, and project management.

Jones et al. (2004), in exploring
knowledge sharing across during ERP implementation, listed
eight factors, which were (a)
orientation to change, (b) control, coordination, and
responsibility, (c) orientation to collabora-
tion, (d) basis of truth and rationality, (e)motivation, (f)
orientation to work, (g) nature of time
horizon (short term versus long term), and (h) orientation and
focus. The long term vision of
having a system that can sustain Cisco’s growth, choosing a
consultant and a vendor who would
be partner in Cisco’s success, and combining expertise spread
across vendor, consultant, and
the client helped sharing of knowledge and controlling of the
project (Grabski & Leech, 2006;
Jones et al., 2004; Woo, 2006; Xu et al., 2006), which enabled
Cisco to have greater control and
visibility during the implementation.
Bradford and Florin (2003) mentioned that ERP implementation
success is driven by three
factors:
1. Innovative characteristics of technical compatibility,
perceived complexity, and business

process reengineering.
2. Organizational characteristics of top management support,
organizational objectives, and
consensus training.
3. Environmental characteristic of competitive pressure.
Cisco, being an innovative company with high technical
capability, propelled the success
factors. Being in the IT and telecom manufacturing industry, IT
investments were not seen as
a sunk cost as were seen by organizations of other industry
verticals. Further, the project not
only received top management support from Cisco, also got the
best personnel from Oracle
and KPMG. The importance of top management support was
also studied in detail by Ehie and
Madsen, (2005), Karimi et al. (2007), and Woo (2006). Last, the
exponential rate at which Cisco
was growing justified the need for the system.
Hong and Kim (2002), Iivari (1992), and Kanellis, Lycett, and
Paul (1999) researched and
stated that the fit between the organization and the ERP system

is integral to implementation
success. The fit was tested through the CRPs and with each
stage. Codes were modified and the
system was customized making the system fit for the business
processes. Combining the stability
of Iterative nature of ERP implementation and the dynamics of
Rapid Application Development
(Figure 4), Cisco was able to get its system operational by 9
months and within its budget. Such
blending was possible mainly for two reasons. First, Cisco
received top management support
(the key to successful ERP implementation, Figure 5; Bradford
& Florin, 2003) from the very
beginning of the project. The quick and concise execution of
selection and planning partnered
is prohibited.

with strong backing by senior management were the success
drivers of the entire project. Sec-
ond, the teams from Cisco, KPMG, and Oracle blended as one.
Such a blend of expertise spread
across helped sharing of knowledge and control the project
(Grabski & Leech, 2006; Jones et
al., 2004; Woo, 2006; Xu et al., 2006).
Cisco’s success can also be attributed in part to a combination
of luck factors and key tim-
ings that facilitated the fast implementation within budget. The
most important was the timing
of ERP implementation. Cisco’s need for a customized system,
paralleled with Oracle’s need
to establish its foothold in the ERP market. While Cisco wanted
a system that could support
its growth, Oracle needed a launching pad to test, correct, and
perfect its modules. This was
the perfect timing. Oracle had to prove its worth in a market
dominated by SAP. This timing
gave Cisco huge bargaining power over Oracle. Also, Cisco
promoted Oracle with marketing
assistance for Oracle’s upcoming products and its ERP. The
timing put Cisco and Oracle in a
positive sum situation. Another important aspect of this timing

was Cisco modifying Oracle’s
codes to match its customized requirements. Such timing is
impossible to replicate. It can also
be argued that Cisco, being in the telecom business, enabled its
partners, Oracle and KPMG,
to access the best technical resources for the project. This
reduced the cost of the project. The
lessons learned are:
1. Leadership—Formation of a cohesive team that was fast in its
acting led to the success of
the project. Besides, the team got indispensable support from
the Top Management.
2. Planning—The initial planning and analysis of project scope,
with the partner and vendor,
was integral to the success of the project. Cisco found the best
people for the job and what
they received in return was the unsurpassed service from each
of their partners.
3. Contract negotiation—Contract negotiation is always an
underlying factor in any project’s
success. In the Cisco case a great contract born of great
opportunity saved the company

thousands of dollars and perhaps months of system
configuration during the late stages of the
Figure 5. Model for successful ERP Implementation13
Top Management
Commitment and Support
Actual ERP Adoption
Favorable
awareness response
Favorable Feelings
Response
• Minimizing Adoption Cost
• Involving Individuals and
groups
• Enhancing ERP interface
quality
• Hands on training

• Securing Support of Opinion
Leaders
• Timing of ERP introduction
General
Favorable Adoption
Intention Response
• Communicating ERP Benefits
• Communicating ERP General
operations
is prohibited.
implementation. The timing of the contract negotiation gave
Cisco huge bargaining power

over Oracle. Also, Cisco promoted Oracle with marketing
assistance for Oracle’s upcoming
products and its ERP.
4. Persistence—During the choosing of parameters and system
configuration, the company
decided to go 80-20 on parameter settings and cram months of
research and choices into
2 days. Cisco was extremely persistent in meeting the deadlines.
And because they were
ahead of schedules, the massive customization did not eat away
project time, delaying the
delivery.
The methodology used by Cisco and Oracle confirmed the six-
stage model proposed by
Kwon and Zmud (1987). The six stages included:
1. Initiation: The first or initiation stage is characterized by the
various exo- and endogenous
factors that influenced the organizations to implement an
integrated system like an ERP
system. Here the outage of the existing system and the need for
having a system that could
support its growth would be the reasons.

2. Adoption: Investment decisions and cost–benefit analysis
related to implementation of ERP
systems and choice of brand or vendor were carried out during
the second or adoption stage
as suggested by Cooper and Zmud (1990) and Rajagopal (2002).
Identification of the vendor
by Cisco and KPMG and choosing Oracle because of unique
strengths is the adoption stage
of this case.
3. Adaptation: The implementation of the ERP system requires
changes in the way business is
conducted, and the companies that were interviewed carried out
BPR before implementing
an ERP system (Rajagopal, 2002). In Cisco’s case however,
business processes were not
altered. Since it was Oracle’s first major implementation,
chunks of codes were modified
to match Cisco’s business process. It was also an acid test for
Oracle’s system, as Cisco’s
business process was one of the bench marks for the industry
and Oracle got the opportunity
to change the codes to reach closer to best practices.

4. Acceptance: The systems become increasingly available for
use in the organization. The
systems are modified in order to solve the problems reported by
the end-users (Rajagopal,
2002). In this case, with every iteration CRP (0 through 2),
codes were modified as per the
needs of the users and the business.
5. Routinization: The process of using the system is routinized
through usage. Because the
system was developed with successive iteration, routinization
was achieved faster than
cutover approaches.
rEfErEnCEs
Aladwani, A.D. (2001). Change management for successful ERP
implementation. Business Process Manage-
ment Journal, 7(3), 266-275 . Retrieved November 3, 2008,
from http://web.njit.edu/~jerry/OM/OM-
ERP-Papers/ERP-10-Success.pdf
Amoako-Gyampah, K., & Salam, A.F.(2004). An extension of
the technology acceptance model in an ERP
implementation environment. Information & Management, 41,
731-745.

Bradford, M., & Florin, J. (2003). Examining the role of
innovation diffusion factors on the implementa-
tion success of enterprise resource planning systems.
International Journal of Accounting Information
Systems, 4, 205-225.
is prohibited.
Bredt, K. (2005, April). Cisco ERP. Retrieved November 3,
2008, from http://www.wi.rwth-aachen.
de/Lehre/Infosysteme/Files/Pr%E4sentation%20CISCO%20(ER
P).pdf
Burgelman, R.A., Christensen, C.M., & Wheelwright, S.C.
(2006). Strategic management of technology
and innovation. New York: McGraw Hill Irwin.

Cooper, R., & Zmud, R. (1990). Information technology
implementation research: A technological diffusion
approach. Management Science, 36(2), 123.
Cotteleer, M. (1998). Cisco systems, inc.: Implementing ERP.
In R.A. Burgelman, C.M. Christensen, &
S.C. Wheelwright (Eds.). (2006). Strategic management of
technology and innovation (p. 877). New York:
McGraw Hill Irwin.
DiMaggio, P.J., & Powell, W.W. (1983, April). The iron cage
revisited: Institutional isomorphism and col-
lective rationality in organizational fields. American
Sociological Review, 48(2), 147-160.
Duncan, W.M. (1997). Information systems management.
London: University of London Press.
Ehie, I.C., & Madsen, M. (2005). Identifying critical issues in
enterprise resource planning (ERP) imple-
mentation. Computers in Industry, 56, 545-557.
Field, T. (1997). When bad things happen to good projects. CIO
Magazine. Retrieved November 3, 2008,
from http:// www.coi.com/acrchive/101597/bad_content.html

Frame, J.D. (1995). Managing projects in organizations. San
Francisco: Jossey-Bass, A. Wiley Com-
pany.
Grabski, S.V., & Leech, S.A. (2006, December). Complimentary
controls and ERP implementation success.
International Journal of Accounting Information Systems, 8, 17-
39.
Harman, M. (1998). Software engineering and development
(Vol. 2). London: University of London
Press.
Hong, K.-K., & Kim, Y-G. (2002). The critical success factors
for ERP Implementation: An organizational
fit perspective. Information & Management, 40, 25-40.
Ifinedo, P, & Nahar, N. (2007, February). ERP systems success:
An empirical analysis of how two orga-
nizational stakeholder groups prioritize and evaluate relevant
measures. Enterprise Information Systems,
1(1), 25-48.
Iivari, J. (1992). The organizational fit of information systems.

Journal of Information Systems, 2, 2-29.
Information Technology Management. (1999). Modern RAD.
ITMWeb Media Corporation. Retrieved
November 3, 2008, from
http://www.dep.state.pa.us/dep/deputate/oit/SDM/inHTML/Html
Files/
SDM/StyleGuide/RapidApplicationDevelopment.htm
Jones, M.C., Cline, M., & Ryan, S. (2004). Exploring
knowledge sharing in ERP implementation: An
organizational culture framework. Decision Support Systems,
41, 411-434.
Kanellis, P. Lycett, M., & Paul, R.J. (1999). Evaluating
business information systems fit: From concept to
practical application. European Journal of Information Systems,
8, 65-76.
Karimi, J., Somers, T.N., & Bhattacherjee, A. (2007). The
Impact of ERP implementation on business
process outcomes: A factor-based study. Journal of Management
Information Systems, 24(1), 101-134.
Kwon, T., & Zmud, R. (1987). Unifying the fragmented models

of information systems implementation.
In Boland & Hirschheim (Eds.), Critical issues in information
systems research. New York: Wiley.
is prohibited.
Maner, W. (1997). Rapid application development. Bowling
Green State University. Retrieved November
3, 2008, from http://odl-skopje.etf.ukim.edu.mk/UML-
Help/html/01day3.html#67561
Rajagopal, P. (2002). An innovation—diffusion view of
implementation of enterprise resource planning
(ERP) systems and development of a research model.
Information & Management, 40, 87-114.
Robson, W. (1997). Strategic management and information
systems. London: Pitman Publishing.

Schach, S. (1999). Classical and object oriented software
engineering: With UML and Java. USA: Mc-
Graw Hill.
State Department of Pennsylvania. (2002, September 23). Rapid
spplication development (RAD) Approach.
Retrieved November 3, 2008, from
http://www.dep.state.pa.us/dep/deputate/oit/SDM/inHTML/Ht-
mlFiles/SDM/StyleGuide/RapidApplicationDevelopment.htm
Stratman, J., & Roth, A. (1999, November 20-23). Enterprise
resource planning competence: A model
propositions and pre-test, design-stage scale development. In
30th DSI Proceedings (pp. 1199-1201).
Woo, H.S. (2006, April). Critical success factors for
implementing ERP: The case of a Chinese electronics
manufacturer. Journal of Manufacturing Technology, 18(1),
431-442.
Wu, J., & Wang, Y. (2005). Measuring ERP success. The key
user’s viewpoint of ERP implementation to
produce viable IS in the organization. Computers in Human
Behavior, 23, 1582-1596.

Xu, L., Wang, C. , Luo, X., & Shi, Z. (2006). Integrating
knowledge management and ERP in enterprise
information Systems. Systems Research and Behavioral Science,
23, 147-156.
EndnotEs
1 The most commonly used Network Architecture. TCP stands
form Transmission Control Protocol. IP
Stands for Internet Protocol. The architecture was founded by
the Department of Defense, USA.
2 Data redundancy and redundant servers and clients are
required against outages.
3 We will see later in the case that the low customization would
not be an option.
4 Other consulting partners considered then were Cap Gemini,
Siemens, IBM, PriceWaterhouse Coo-
pers.
5 The KPMG Consulting division now is named as Bearing
Point.

6 On December 13, 2004, Oracle bought People Soft for $10.3
billion. Under the terms of the deal,
Oracle would acquire PeopleSoft for $26.50 per
7 Grounded to the theory of Mimetic Isomorphism (DiMaggio &
Powell, 1983 ), companies select the
most established de facto product of the time.
8 Source: Cotteleer (1998); Burgelman, Christensen, and
Wheelwright (2006).
9 Source: Maner (1997).
10 Systems Analysis is the first stage of the System
Development Life Cycle (SDLC). It is also the most
critical making the system correct for the business needs.
11 Data settings mainly refer to the domain of values a data is
supposed to accept. For instance the data
under item “Products” for Cisco would be routers, Switches,
and so forth. For Amazon it would be
books, CDs, DVDs, games, and so forth.

is prohibited.
12 Though code modification is uncharacteristic of ERP
implementation, here Oracle had to do it for
Cisco.
13 Source: Aladwani (2001).
Avimanyu Datta is a PhD student in the in Washington State
University (WSU). He holds a bachelor’s
degree in computing and information systems from the
University of London, U.K. and a master’s degree
in information systems from Hawaii Pacific University. His
research interest focus on understanding the
strategic use of IS and its transformational capabilities in
altering industrial structures and boundaries, as
well as IT mediated commercialization of innovations and firm
performance. In 2007, he represented the
business lead of the team that eventually won the best business

plan for Material Research Society. Before
joining WSU, he consulted with Frost & Sullivan and AMI
Partners.
Reproduced with permission of the copyright owner. Further
reproduction prohibited without permission.
Communications of the Association for Information Systems
| Number 1Volume 28 Article 18
4-1-2011
ERP Implementation Gone Terribly Wrong: The
Case of Natural Springs
Vlad Krotov
Abu Dhabi University, [email protected]
Serguei Boukhonine
University of Houston

Blake Ives
This material is brought to you by the Journals at AIS
Electronic Library (AISeL). It has been accepted for inclusion
in Communications of the
Association for Information Systems by an authorized
administrator of AIS Electronic Library (AISeL). For more
information, please contact
[email protected]
Recommended Citation
Krotov, Vlad; Boukhonine, Serguei; and Ives, Blake (2011)
"ERP Implementation Gone Terribly Wrong: The Case of
Natural
Springs," Communications of the Association for Information
Systems: Vol. 28, Article 18.
Available at: http://aisel.aisnet.org/cais/vol28/iss1/18
http://aisel.aisnet.org/cais
http://aisel.aisnet.org/cais/vol28/iss1
http://aisel.aisnet.org/cais/vol28
http://aisel.aisnet.org/cais/vol28/iss1/18
mailto:[email protected]>

Volume 28 Article 18
ERP Implementation Gone Terribly Wrong: The Case of Natural
Springs
Vlad Krotov
Abu Dhabi University
[email protected]
Serguei Boukhonine
Blake Ives
A Russian start-up company successfully introduced bottled still

water to the Russian market and, despite the rapid
growth of competition, three years later remained the market
leader. The firm’s CFO convinces the CEO of the need
for an Enterprise Resource Planning (ERP) system. He justifies
the ERP as the means to enhance financial and
administrative controls, to prepare for an IPO, and, among other
reasons, to create efficiencies by better linking the
St. Petersburg headquarters with their bottling facility located
100 miles to the north. The implementation fails,
primarily due to widespread resistance within the factory as
well as from the firm’s COO. The Case provides
students with a rich look at implementation and counter-
implementation of information systems as well as the high-
level politics that can often seemingly mysteriously impact
systems implementation. Further interest and
opportunities for discussion are added via the Russian context
and the transition to free markets, as well as the
technical and operational work-arounds often required to deal
with the inadequate public infrastructure often found in
less developed parts of the world or, as in this case, in sections
of a particular country.
Keywords: teaching case, ERP, implementation, failure, socio-
technical, resistance, politics

Editor’s Note: A teaching note for this case can be obtained
from [email protected] Only active MIS faculty
who are currently listed in the AIS Faculty Directory are
eligible to receive the teaching note.
Volume 28, Article 18, pp. 277-282, April 2011
Springs
Springs
278
I. NATURAL SPRINGS COMPANY
1

The Early Years
In 1992 a successful British entrepreneur (“the CEO”)
celebrated the sale of his company by treating himself and his
family to an extended tour of Europe. One stop was St.
Petersburg, Russia; there the CEO boarded ship for a
leisurely cruise along the Neva River. While the cruise was
enjoyable, the boat’s tap water was not—it had a most
unpleasant taste. To his dismay and surprise, the CEO
discovered that bottled still water was unheard of in Russia.
The CEO and his family, like most of the other tourists on
board, had to settle for the sparkling mineral water
available from the ship’s bar.
Later that day, the ship stopped in Kivgoda, a small town
approximately 100 miles North-East of St. Petersburg.
There, while touring an architecturally notable seventeenth
century building, the CEO mentioned his “drinking
problem” to the estate’s owner (“the Landlord”). The Landlord
told the CEO that he owned land nearby that was the
source of several natural springs that were highly prized sources
of drinking water. The CEO said he would like to try
this water and perhaps even bring some back to the boat for the

trip back to St. Petersburg. The Landlord was
happy to oblige. Moments after the first few sips, the idea of
bottling and selling the water jumped into the CEO’s
mind. He proposed a joint venture to the Landlord.
The company the CEO envisioned, and convincingly described
to the Landlord, would introduce to the emerging
Russian free market a new product: bottled still water. While
the Landlord was easily convinced, the plan to sell what
had always been free encountered considerable skepticism and
even derision. While hundreds of carbonated
mineral water brands existed in the former USSR, bottled still
water was unheard of. “Why,” people asked, “would
anyone pay for something without value adding ingredients such
as carbonation, minerals, syrups, etc.?”
Nevertheless, factory construction began the following year.
Most of 1993 and 1994 were spent putting up the
factory, installing equipment, designing bottles, designing a
distribution strategy and marketing campaign, and so on.
The CEO and his newly hired Chief Operations Officer (COO)
oversaw the work. The initial products were 1.5 liter
and 0.5 liter bottles. Sales in that first year, 1994, were less
than a million U.S. dollars and disappointing. A Chief
Marketing Officer (CMO) and a Chief Financial Officer (CFO)

were added to the executive team, helping to fuel sales
growth in 1995 to several million U.S. dollars. By 1996 sales
had exploded as the product category was now well
accepted, at least in the major metropolitan areas. Natural
Springs bottles were sitting on the conference tables in
the Kremlin, distributed on Aeroflot flights, and supplied to a
number of upscale hotels in Moscow and St.
Petersburg. 1997 promised to be another high growth year.
Natural Springs began to extend their product line and
leverage their brand and distribution channels. Among the first
additions were carbonated water and bottles of
additional sizes.
Leveraging that success, the company went through a successful
round of private equity financing, attracting the
attention of two international investment funds. Management
was now eying an initial public offering (IPO) in
London. No one was laughing at the business potential of
bottled water now. While dozens of competitors had now
sprung up, Natural Springs remained the undisputed market
leader. The future looked very bright.
Succession Plans
By 1996, the CEO of Natural Springs had grown bored with

hands-on management. He was more interested in
formulating new strategies, developing new products, and
working the financial markets. At the end of 1996, the
CEO announced his intention to soon resign as CEO and to
assume the new title of Chairman. In that role he
intended to play an advisor-like role.
The COO saw himself as the obvious heir to the throne. The
COO was born in Brazil to a Russian émigré family
fleeing the Russian Revolution of 1917. Eventually he made his
way to Canada, where he worked in a variety of
engineering and managerial capacities. Shortly after the
collapse of the Soviet Union, the COO, who spoke fluent
Russian, relocated to Russia where he eventually joined the
Natural Springs start-up and was charged with building
1
The name of the company, geographical names, as well as
certain facts have been altered in order to hide identity of
people involved in the
case.

279
and operating the factory. Because of his traditional upbringing,
the COO enjoyed undisputed power and respect
among the parochial factory workers in Krivogda. His
successful tenure with the company had also earned him the
unconditional trust of the CEO. Moreover, as a devout Orthodox
Christian (common among émigrés but rare among
Russians born under communism), he was on good terms with
the Landlord, another devout Orthodox Christian.
The CFO was the second legitimate contender. A Russian
national, he spoke fluent English and held an MBA from
an American university. His previous experience involved
several years in the CFO role of a regional office of a
prominent American consumer goods company. He was credited
with building Natural Spring’s financial and
administrative controls—controls that were essential for
attracting venture capital and building the foundation for an
IPO.

The CMO was the third contender for the CEO position. He was
young, British, and graduated with a degree in
Marketing and Russian from a top school in the UK. He was a
rising star; under his watch and via his marketing
programs Natural Springs had enjoyed spectacular sales growth.
Moreover, as a UK national, fluent in both English
and Russian, he enjoyed the confidence of British investors.
Teething Pains
Despite its early success, Natural Springs faced significant
challenges, though they were similar to those of other
firms operating in the emerging free markets of the former
Soviet Union. The Russian banking system was slow and
unreliable. Telecommunications, while tolerable in St.
Petersburg, were unavailable, unacceptably slow, or
unreliable in provincial cities, including Krivogda. The postal
system was generally agreed to be all but useless for
business purposes such as mailing invoices. Further problems
involved poor road infrastructure, crime (organized
and otherwise), a repressive and confiscatory tax regime, and
widespread corruption.
Furthermore, as a company experiencing rapid growth, Natural
Springs needed to hire more employees, but

qualified people were hard to find. The company wanted
employees unencumbered by the deeply ingrained Soviet
ways of management. Usually, this meant hiring young people
without much experience and training them “on the
job.”
Internal controls, something that the CEO viewed as being
essential for Natural Springs success in the chaos of the
emerging market, still lagged behind sales growth. With still
more growth predicted, and greater competition, rapidly
emerging controls had to be further strengthened if costs were
to be kept in line. In the beginning of 1995, the CEO
asked the CFO to move to Krivogda to strengthen the controls at
the factory. While the CFO actively resisted the
move away from St. Petersburg, the COO, who was located in
Krovogda, viewed the CFO’s move to the factory
town as a turf invasion.
II. THE ERP PROJECT
Near the end of 1995, and after a few months at the factory, the
CFO pitched to the CEO the idea of implementing
an Enterprise Resource Planning (ERP) system.
The Business Case

The CFO felt an ERP system would help the company in several
areas and laid out the justifications for the CEO as
summarized in Table 1.
The CEO of Natural Springs was convinced and approved the
project in early 1996. The CFO was charged with
responsibility for selecting and implementing the system.
System Selection
The company selected a British ERP system—Sun Systems
(marketed by the Systems Union). The system was
popular in Britain and the Commonwealth Nations and was
gaining popularity in Russia.
Before joining Natural Springs, the CFO had worked for a
Russian subsidiary of a prominent American consumer
goods company. The subsidiary reported to the European
headquarters in London. When the CFO joined the
subsidiary, he was directed to implement Sun Systems, which
the company had already implemented in other
Eastern European subsidiaries. The system worked fine for such
applications as inventory and sales management,
International Accounting Standards based financial accounting,

Western standard human resources management,
etc. But, he had initially found the system to be poorly suited
for Russian Accounting Standards, Russian human
resource management requirements, etc. His previous employer
brushed the CFO’s concerns aside. In time, the
http://www.sunsystems.com/Home/
http://en.wikipedia.org/wiki/Commonwealth_of_Nations
http://www.iasb.org/Home.htm
http://en.wikipedia.org/wiki/International_Financial_Reporting_
Standards
280
Table 1: Justifications for ERP
1. Both the head office in St. Petersburg and the factory in
Krivogda keep manual records of
business transactions. This leads to errors and delays. The

company desperately needs an
electronic system for recording and processing business
transactions.
2. An ERP system will streamline communication between the
head office in St. Petersburg and the
factory in Krivogda, improving the customer order fulfillment
process. As a reminder, here is how the
process currently works:
salespeople by phone
shipping information to the St.
Petersburg office
email nor faxes from St.
Petersburg can reliably reach the factory, St. Petersburg
dispatches a courier with printed

invoices who meet the trucks at a prearranged location. The
courier then rides with the
truckers and delivers invoices directly to customers. It is too
risky to hand invoices to
truckers since the documents can be intercepted by either
organized crime groups or local
tax authorities who would use them to extort money from the
company. The postal system is
too unreliable to mail them. Faxing or emailing invoices to
customers is insufficient since
they must have original hardcopies for statutory reasons
As we know, this process is riddled with inefficiencies and
fraught with the potential for, and the
reality of, errors. Frequent reconciliations of shipments and
invoices are the norm. An ERP system
can help us automate and streamline exchange of information
related to customer order fulfillment
process.

3. An ERP system will help Natural Springs strengthen its
internal controls. The St. Petersburg office
finds it difficult to exercise financial and inventory controls.
Although major purchasing and accounts
payable activities are done out of St. Petersburg, the factory
needs cash for local purchases, payroll,
etc. In the factory, unbudgeted funds are often disbursed
without consulting with the CFO. The St.
Petersburg office needs real time access to factory accounting
data if we are to tighten controls over
budgets. Further, real time access to factory data can provide St.
Petersburg with up-to-date
inventory information, which is very useful for sales and labor
forecasting, purchasing, and cash flow
planning.
4. Our plans for an IPO require the ability to produce financial
reports fast as well as demonstrating
the adequacy of our internal controls. The ERP is an essential
element of the IPO strategy.
5. A successful implementation of the ERP at the factory can
open the way for an eventual transfer
of most of our back office functions to Krivogda, thus, lowering
our administrative overhead.

CFO developed significant expertise and increased his
confidence in the system. His conversion from resistor to
champion had been facilitated when the local partner of the
Systems Union developed makeshift ways of producing
Russian accounting statements using the Sun Systems output.
Thus, when he arrived at Natural Springs and needed an ERP,
Sun Systems seemed the easy choice. No other
ERP system was seriously considered.
Implementation at the St. Petersburg Office
The initial implementation in 1996 was limited to the St.
Petersburg office and included only the sales and financial
accounting modules. Before the implementation, the CFO
recruited an experienced accounts receivable clerk from
his former employer as well as a bright young systems
consultant who previously had worked for the Russian
partner of the Systems Union. The duo proved invaluable in
solving the technical problems related to the system
implementation. All users of the new system in St. Petersburg
reported to the CFO who had personally hired and
trained them. They were predominantly young with little

previous experience. The St. Petersburg implementation
went relatively smoothly and encountered little resistance.
281
Factory ERP Implementation
While everybody agreed that a factory system was necessary,
there were two areas of concern: the network
connection between the two offices and system selection for the
factory.
System Connection
The ideal solution to the connection problem was to install a
high speed Internet connection at the factory and link it
to a wide area network (WAN) within the factory. Another
possibility was to acquire a private line between St.
Petersburg and the factory and implement an intranet over it.
Many other possibilities were discussed, but the

telecommunications infrastructure in and to the factory town
was so poor that a real-time WAN proved infeasible.
Thus, the initial plan of having a centralized ERP system
accessed in real-time from both the headquarters in St.
Petersburg and the factory town in Krivogda was abandoned.
The company had to settle for two systems—one run
on a server in St. Petersburg, another on a server at the factory.
These systems would be synchronized daily using
elaborate algorithms and batch transmissions at the close of
business each day.
System Selection
The other problem area was the choice of the system for the
factory. The CFO naturally wanted to implement the
Sun Systems ERP. He demonstrated the system to the factory
bookkeeping staff. Having spent literally decades
working with Soviet and then similar Russian accounting
standards and often lacking basic IT literacy, the factory
bookkeeping staff did not want to learn the system. Instead,
they wanted to purchase a Russian ERP package called
“1C” with locally available support. This package was tailored
to produce statutory accounts. It also had human
resources, inventory, manufacturing, and other modules
conforming to the all too numerous Russian regulations.

This package was poorly suited for producing IAS or GAAP
accounts, but this was of no concern to the factory
staff—IAS and GAAP accounts were produced in St. Petersburg
by the CFO. The COO supported his staff and
opposed the package favored by the CFO.
The CEO, loath to arbitrate between the COO and CFO,
compromised. The factory had to implement the Sun
Systems. However, the CEO allowed the COO to purchase the
Russian ERP system to meet Russian statutory
needs. The factory would run parallel systems.
Preparing for the Implementation
Since the existing factory staff claimed to be too busy to run
both systems, an additional clerk was hired to run the
Sun Systems at the factory. The factory IT manager was trained
to support the Sun Systems and shown how to
carry out the synchronization data transmission and procedures.
To begin to quickly capture some of the promised benefits of
the ERP, the executive team decided to speed up the
transfer of the back office functions to the factory. The
invoicing responsibility would be transferred immediately.
Henceforth, invoices would be issued at the factory and

distributed to the truckers in sealed envelopes. The St.
Petersburg office still retained the accounts receivable
responsibility. From then on, it would get invoice information
from the factory via the daily batched synchronization
transmissions.
The Factory Implementation Begins and Bogs Down
At the start of the factory implementation, CFO spent almost all
of his time at the factory. Everything went smoothly.
The local IT manager fulfilled his responsibilities quite well.
The factory Sun Systems clerk was a bright and hard
working individual who quickly demonstrated a good grasp of
the system. Two weeks after the factory
implementation started, the CFO went on a previously
scheduled two-week family vacation to California. With high
international telephone charges and no Internet connection, he
was essentially unreachable.
The CFO returned to find the St. Petersburg office in disarray.
The accounts receivable system was a disaster. The
factory had failed to follow the data transfer protocol. A variety
of technical reasons were given, but the bottom line
was that St. Petersburg did not have invoice information and,
therefore, could not verify the accounts receivable.

Moreover, with no invoice information, sales reps could not
provide order status updates to inquiring clients: they did
not know when the order was shipped (if at all) and could not
estimate delivery time. The CMO and sales reps were
now under pressure from customers and had to scramble to
prevent several of the company’s major clients from
deserting Natural Springs. The CFO tried a number of ways to
resolve the situation, including a visit to the factory.
The factory visit produced little results. The factory staff
(including the factory IT manager and Sun Systems clerk)
did little to help resolve the problem. They cited such reasons
as technical and functional inadequacy of the system,
lack of technical knowledge, and time constraints due to them
being occupied with their immediate job
responsibilities. Having received no cooperation from the
factory staff, the CFO eventually decided to pull the plug;
the company returned to the previous manual system for
handling invoices. The factory meanwhile continued to run
282

the Russian ERP system. The data provided by it were manually
translated by the CFO to prepare GAAP and IAS
accounts.
III. AFTERMATH
The implementation failure left the CFO deeply disillusioned
and upset at the obstinacy and incompetence of the
factory staff. His stature within the company was badly shaken.
The failure also badly reflected on the COO who was
now perceived to be parochial and uncooperative. A few months
after the implementation failure the COO left the
company, citing reasons unrelated to the ERP project. The
CMO, who was largely untouched by this imbroglio, was
promoted as the new CEO of Natural Springs. While continuing
to work for the company, the CFO saw his authority
gradually chipped away by the new CEO. The CFO was quietly
ousted in the beginning of 1999.
Natural Springs was sold to a leading multinational food and
beverages company in 2002 for an undisclosed
amount.
IV. EPILOGUE

Several months after the failed implementation, the factory
clerk who had been in charge of the Sun Systems, came
to St. Petersburg for technical training. The CFO invited the
clerk for a dinner in one of St. Petersburg’s restaurants.
After several glasses of wine, the CFO started asking for
opinions of the ERP failure. He learned that the clerk and
the factory IT manager had been ordered by the COO not to
synchronize data with the St. Petersburg office. They
had also been ordered not to talk about it.
LIST OF ACRONYMS
1C A leading Russian ERP package COO Chief Operating
Officer
CEO Chief Executive Officer ERP Enterprise Resource Planning
CFO Chief Financial Officer GAAP Generally Accepted
Accounting Principles
CMO Chief Marketing Officer IAS International Accounting
Standards
ABOUT THE AUTHORS
Vlad Krotov is an Assistant Professor of MIS at Abu Dhabi
University, UAE. His research, teaching, and consulting
work is devoted to helping organizations to use Information and

Communication Technologies for creating value for
their organizations. His research on strategic information
systems, e-commerce, RFID, biometrics, and
wireless/mobile technologies has appeared in the following
academic and practitioner-oriented journals: CIO
Magazine, Journal of Theoretical and Applied E-Commerce, and
Communications of the Association for Information
Systems.
Blake Ives is Past President and Fellow of the Association for
Information Systems, a past Editor-in-Chief of the
Management Information Systems Quarterly and has twice
served as Conference Chair for the International
Conference on Information Systems. Dr. Ives is also a founder
of ISWorld. A frequent contributor to Communications
of the Association for Information Systems, he has also
published in MIS Quarterly, Information Systems Research,
Sloan Management Review, Journal of Management Information
Systems, Decision Sciences, Management
Science, Communications of the ACM, IBM Systems Journal,
and variety of other journals. He has been a visiting
Fellow at both Oxford and Harvard. He holds the Charles T.
Bauer Chair of Business Leadership at the C.T. Bauer
College of Business at the University of Houston.

Serguei Boukhonine is a doctoral student at the Department of
Decision and Information Sciences, Bauer College
of Business, University of Houston. His research interests
include strategic information systems, biometrics, human
decision making, and computer education.
Copyright © 2011 by the Association for Information Systems.
Permission to make digital or hard copies of all or part
of this work for personal or classroom use is granted without
fee provided that copies are not made or distributed for
profit or commercial advantage and that copies bear this notice
and full citation on the first page. Copyright for
components of this work owned by others than the Association
for Information Systems must be honored.
Abstracting with credit is permitted. To copy otherwise, to
republish, to post on servers, or to redistribute to lists
requires prior specific permission and/or fee. Request
permission to publish from: AIS Administrative Office, P.O.
Box 2712 Atlanta, GA, 30301-2712, Attn: Reprints; or via e-
mail from [email protected]

.
ISSN: 1529-3181
EDITOR-IN-CHIEF
Ilze Zigurs
University of Nebraska at Omaha
AIS SENIOR EDITORIAL BOARD
Guy Fitzgerald
Vice President Publications
Brunel University
Ilze Zigurs
Editor, CAIS
Kalle Lyytinen

Editor, JAIS
Case Western Reserve University
Edward A. Stohr
Editor-at-Large
Stevens Institute of Technology
Blake Ives
Editor, Electronic Publications
Paul Gray
Founding Editor, CAIS
Claremont Graduate University
CAIS ADVISORY BOARD
Gordon Davis
University of Minnesota
Ken Kraemer
University of California at Irvine
M. Lynne Markus
Bentley University

Richard Mason
Southern Methodist University
Jay Nunamaker
University of Arizona
Henk Sol
University of Groningen
Ralph Sprague
University of Hawaii
Hugh J. Watson
University of Georgia
CAIS SENIOR EDITORS
Steve Alter
University of San Francisco
Jane Fedorowicz
Bentley University
Jerry Luftman
Stevens Institute of Technology

CAIS EDITORIAL BOARD
Monica Adya
Marquette University
Michel Avital
University of Amsterdam
Dinesh Batra
Florida International
University
Indranil Bose
University of Hong Kong
Thomas Case
Georgia Southern
University
Evan Duggan
University of the West
Indies
Mary Granger
George Washington

University
Åke Gronlund
University of Umea
Douglas Havelka
Miami University
K.D. Joshi
Washington State
University
Michel Kalika
University of Paris
Dauphine
Karlheinz Kautz
Copenhagen Business
School
Julie Kendall
Rutgers University
Nancy Lankton

Marshall University
Claudia Loebbecke
University of Cologne
Paul Benjamin Lowry
Brigham Young University
Sal March
Vanderbilt University
Don McCubbrey
University of Denver
Fred Niederman
St. Louis University
Shan Ling Pan
National University of
Singapore
Katia Passerini
New Jersey Institute of
Technology

Jan Recker
Queensland University of
Technology
Jackie Rees
Purdue University
Raj Sharman
State University of New
York at Buffalo
Mikko Siponen
University of Oulu
Thompson Teo
National University of
Singapore
Chelley Vician
University of St. Thomas
Padmal Vitharana
Syracuse University

Rolf Wigand
University of Arkansas,
Little Rock
Fons Wijnhoven
University of Twente
Vance Wilson
Worcester Polytechnic
Institute
Yajiong Xue
East Carolina University
DEPARTMENTS
Information Systems and Healthcare
Editor: Vance Wilson
Information Technology and Systems
Editors: Sal March and Dinesh Batra
Papers in French
Editor: Michel Kalika

ADMINISTRATIVE PERSONNEL
James P. Tinsley
AIS Executive Director
Vipin Arora
CAIS Managing Editor
Sheri Hronek
CAIS Publications Editor
Hronek Associates, Inc.
Copyediting by
S4Carlisle Publishing
Services
Recommended CitationCommunications of the Association for
Information Systems4-1-2011ERP Implementation Gone
Terribly Wrong: The Case of Natural SpringsVlad
KrotovSerguei BoukhonineBlake Ives
Processes and Information Systems Assignment (Due October
10th by 8:30 PM)

Directions: The assignment must be submitted to Moodle as a
single Word document. Save it as yourlastname_IT for
processes.docx
Please read the following three articles uploaded to Moodle:
1. Krotov, Vlad; Boukhonine, Serguei; and Ives, Blake (2011)
"ERP Implementation Gone Terribly Wrong: The Case of
Natural Springs," Communications of the Association for
Information Systems: Vol. 28, Article 18, pp. 272-282.
2. Datta, A. (2005). Cisco Systems: Implementing 'Customized'
ERP in Nine Months and Within Budget. Journal of Cases in
Information Technology, 11(2), pp. 56-70.
3. Traub, T. (2012). “Wal-Mart Used Technology to Become
Supply Chain Leader,” Arkansas Business, Retrieved from
technology-to-become-supply-chain-leader (current Sep 30,
2013).
Write a three-page paper answering the following two
questions. The first two pages should contain answer to
question 1 and the third page should contain the answer to
question 2. Your answers are graded based on the quality of
your arguments.
1. Read papers #1 and #2 above and answer the question:
“Analyze why ERP implementation could go wrong with some
companies and go right with others.” (65 points)

2. Read paper #3 to answer the question: How does Wal-Mart
use technology to manage their supply chains effectively? (35
points)
Please use Times new roman font, 12 size, single space, and 1
inch margins page margins. Do not exceed the page limit..
Include in-text citations in APA or MLA format
Answer to question 1:

How Walmart's Supply Chain Innovation Led to Dominance

Recommended

Recommended

More Related Content

Similar to How Walmart's Supply Chain Innovation Led to Dominance

Similar to How Walmart's Supply Chain Innovation Led to Dominance (20)

More from melbruce90096

More from melbruce90096 (20)

Recently uploaded

Recently uploaded (20)

How Walmart's Supply Chain Innovation Led to Dominance