Executive Summary

Enterprise Resource
Planning (ERP)
By:
David Giles
Matthew Haack
LeRue Holbrooke
The information on the first two pages of this document is intended to present an
executive summary regarding Enterprise Resource Planning. All additional information
can be found immediately after the executive summary.

What is ERP?
Enterprise Resource Planning (ERP) is a software package consisting of modules that
integrate core parts of a business.1 The integration of these modules allows a company
to work more efficiently by sharing data between each module. Some of the modules
that ERP software can include are product planning, purchasing, production control,
inventory control, interaction with suppliers and customer, delivery of customer service
and keeping track of orders. According to AMR, the ERP market will grow from its
current $19.8 billion to $31.4 billion in 2006. 2 Management when implementing an ERP
solution should consider the following benefits and risks.

Promised Benefits of ERP

Improved Productivity Due to increased efficiencies a report can be

produced without contacting multiple departments. In other words, productivity is
achieved via a reduction in manual processes.
Improved Customer Demand Management All information is integrated. An
order can be tracked faster allowing you to respond to your customer faster.
Cost Reductions Increase in productivity and better management of customer
demand allows reductions of cost.
Manufacturing Efficiencies Inventory can be managed more effectively.
Teamwork Members of a team are able to look at data immediately and come
up with new solutions as necessary.

Hidden Costs of ERP

Organization Cultural Change Need to prepare the organization for a

different way of operating. ERP can change the legacy business processes
causing employees to do things differently.
Testing Need to ensure that all requirements have been met before into
production.
Data Analysis Identify contents of old data.
Data Conversion Map old data into new format with 100% accuracy.
Transition From Outside Consultants Consulting firms can be used as
implementation partners to leverage their knowledge of the ERP system. They
can either be an asset to planning or the cause of the failure.
Training Costs are usually underestimated because the ERP project is a first
for the company and they are not aware of how their employees will adapt to the
new system.
Customization Customizing an ERP package requires many hours of
programming and testing cost. Also raises the cost of software upgrades by
forcing review of the new upgrade and determining if old customization must be
required.
Integration Careful choices must be made to ensure that all software
packages are compatible.
Implementation Should be in short lifecycles to avoid scope and or version
creep.

ERP Best Practices

Business process review/ reengineering Look at all processes in granular

detail to understand and improve current processes.
Establish knowledgeable project team Team should know about your
organization in order to be able to make decisions and assist the ERP team.
Ensure software compatibility with industry practice and requirements
Make sure the software that you choose is the right software (manufacturing
software for manufacturing, human resources for human resources, etc).
Prepare organization for change Make employees aware of the changes
that will take place and how they will be affected.
Establish sufficient training methods Make sure that employees will be
adequately trained to use ERP software to perform their daily task.
Perform gradual implementations Take baby steps so that you can fix
mistakes quicker and avoid falling on your face.
Keep short project lifecycles The longer the lifecycles the more opportunity
for scope and/or version creep.

All information on the following pages provides additional details and support for the
statements contained within the executive summary. There are also ERP
implementation case studies for FoxMeyer Drug (Failure) and the University of Missouri

Page 2of 32

(Challenged). The FoxMeyer case is based on second-hand information and the UM

case original research done through interviews.

Page 3of 32

Enterprise Resource Planning

No company can afford to start....stop....and re-start an ERP project. But many
companies have been forced to do just that. They purchase multi-million dollar software
packages just to find out during the implementation process that it does not work, or
does not work well, for a key business element. There are a number of stories about
firms, throughout the world, who began an ERP installation project only to abandon the
project because of functional or philosophical reasons.
Until the end of 1996, Dell Computers had planned to roll out SAPs full suite, but
stopped after only implementing the HR modules. The company recognized that a
single software package monolith would not be able to keep pace with Dells
extraordinary rate of growth. Dell, instead, designed a flexible, middle-ware architecture
to allow the company to add or subtract applications quickly and then selected software
from a variety of vendors to handle finance and manufacturing functions. 3

How does ERP work?

The following figure Error: Reference source not found shows how ERP shares
information with multiple modules at the same time by using a central database. This
may seem like a simple process by the illustration but the fact that information must be
assimilated into all parts of a business means that a lot of thought must go into an ERP
software package.
Reporting
Applications

Customers

Sales and
Delivery
Human
Applications
Resource
Management
Applications

Sales Force
And Customer
Service Reps

Financial
Applications

Employees
Suppliers

Central
Database

Service
Applications
Human
Resource
Management
Applications

Page 4of 32

Manufacturing
Applications

Inventory
And Supply
Applications

Back-office
Administrators
And Workers

The previous figure gives an idea of how ERP shares information and simplifies how the
software works, and it almost simplifies it so much that you forget how much power and
efficiency an ERP software package can give your employees. An ERP software
package provides the means to allow all parts of a business to gear up to make a
product. The following is an example of a few of the parts of the business that could be
affected by ordering a product.

Example of an order done on ERP Software

First, the data is entered as an order, and then this information notifies multiple
departments that a large order has been made and each part of the organization
determines their requirements. Production determines how long the job will take, and
the number of people required for product production. Inventory determines how much
space will be needed to store the products until the order is complete. Shipping and
Logistics will determine how long it will take to deliver the product. Finance will notify
the person making the order how much each item should cost.
The example above, if performed prior to installing an ERP solution, would involve a
great deal of time, effort, and money. ERP allows the processes described above to
function seamlessly within the background of the ERP software. Once the order is
entered, the costs, quantities, and locations would be identified by the ERP software. If
the item were in stock, shipping would get confirmation from the ERP system and
finalize the order. Once the item is actually shipped, the inventory will automatically be
decreased in the system, and accounting will see that a sales transaction has been
posted in the system. If done properly ERP can save money, but in the wrong hands, it
can cost a lot of money.

A different perspective on how ERP evolved.

In 1972, Intel began selling the 4004 a microprocessor able to compute at lighting
speeds. Well to be honest it was fast enough to put in a new device called the
calculator and given the cheap price of three hundred dollars. Now this calculator had
power. It was able to do all the mathematical operations a person needed add, multiply,
divide, and subtract.
So how does a calculator with simple functions turn the business world upside down?
What about the mainframes and Manufacturing Requirement Planning (MRP) of the
1970's? While the mainframes and MRPs of the 1970's are important to business
manufacturing it is the calculator that changes the mind set of the business manager.
He sees a small device that can get answers to the person using it immediately unlike
the ten thousand Fortran cards needed to get a program working on his mainframe.
This immediate response gets him thinking about how great it would be for other parts
of his business to have immediate feedback. Examples would include a scenario in
which an accountant would determine how much money can be spent on a widget and
tell the project manager, manufacturer, human resources, and sales person all at the
same time with a click of a button. The example above would probably give too much

Page 5of 32

information to some groups (i.e. HR), but the example provides the basic idea of
Enterprise Resource Planning.

History of ERP
When Enterprise Resource Planning was first introduced it needed lots of computing
power to run efficiently and since it was the early 1970's the only computer able to
produce this power was the mainframe. The mainframe is defined by the Gartner
group as a large-capacity computer system with processing power that is significantly
superior to PCs or midrange computers.4 These mainframes required skilled technicians
to maintain and program which made it difficult for users and even programs to operate
in an efficient manner thus, few organizations had ERP because the hardware was very
expensive and hard to maintain.
While this slowed many corporations in their efforts to implement, ERP the 1990's saw a
development in technology that made hardware cheaper and the client/server was
born. The difference between a mainframe ERP and a client/server ERP
implementation is how the user interfaces with the data. On the mainframe ERP, all
programs are stored on a central computer and in order to work with the data you must
be on a terminal that is dedicated to the mainframe. The client/server is different in that
the data is stored on the server and the processing software is stored on the client.
These computers then have data entered into them and sent directly to the server
where other people in the organization can look at and use the data. The main
difference is that the client computer does all the processing of the data. It also can
mean that there are many servers that communicate information between the modules
of the ERP software.
Today the trend is to use thin client technology to implement ERP. The difference
between thin client and client/server technology is that the thin client does not need the
software installed on the computer to be used. Thin client has all the data and software
installed on a server which the thin client connects to and can use the program without
having to install the entire program on the hard drive of the client. This can allow a
company to implement a stripped down PC that is cheaper to maintain and cost less
because updates occur on the server not the client. What is nice about thin client is that
not all of the computers have to be stripped down and you may have full blown PCs or
the stripped down PC that can be used by anyone.

Page 6of 32

The following figure is an example of how large the systems were compared to their
predecessors and how they have built on the strengths of the previous systems.

Where is ERP Headed?

The current trend of thin client solutions means that a server is connected to all
computers via hardwire or WiFi. You can think of thin client as being web client. The
software is held on a server that a user can connect to over the internet/intranet. This
allows a company to have less overhead for their servers. All data and software is
accessed from this server. The software for ERP is also taking advantage of the Web
Client in that it is being packaged smaller so that a PDA or telephone may be able to
dial in and work on the software from anywhere.

Who Provides ERP Software Solutions?

The following information contains a synopsis of the three major ERP vendors (Oracle,
SAP, and PeopleSoft/JDEdwards). A company history and financial background will be
provided along with a market segmentation analysis.
ORACLE
Oracle is the first software company to develop and deploy 100 percent internetenabled enterprise software across its entire product line: database, business
applications, and application development and decision support tools.

Page 7of 32

Oracle Customers using enterprise management software: Atos , Belgian National

Railways, BT Group plc., Cal ISO, Conference Planners, Deutsche Bank, Digex,
Hutchinson-Priceline, Swiss Federal Railways, Telstra, TUSC, Unilever, US Navy
During FY03 (ended May 31st, 2003) Oracle shares traded as low as $7.32 and as high
as $13.26. Oracle reported 2003 revenues as $9,745 billion and net income of $2,307
billion. Major sources of revenue for Oracle are new software licenses, software license
updates and product support, and services, which include consulting, advanced product
services and education revenues. The total revenue is consistent with revenues in
2002 and 2001 ($9,673 and $10,961 respectively). Year end cumulative cash flow is is
at $4,737. Surprisingly, Oracles R&D spending is only $1,180 compared with sales and
marketing of $2,072.5

SAP
Founded in 1972 and headquartered in Walldorf, Germany, SAP is the world's largest
inter-enterprise software company, and the world's third-largest independent software
supplier overall. SAP employs over 28,900 people in more than 50 countries. For fiscal
year 2002 (ended December 31st, 2002), SAP had revenues of $7,770 billion and net
income of $533 million. The primary cause of the decrease from revenue to net income
was operating expenses of greater than $3 billion (including R&D of nearly $1 billion).
They also had income tax expense of $628 million (54% of EBIT!). The balance sheet
Page 8of 32

reveals nearly $2.2 billion in receivables as of December 31, 2002. For the year, SAP
had a favorable increase to cash of $384 million. 7
PEOPLESOFT/JDEDWARDS
PeopleSoft is the second largest enterprise application software company in the world
and the single largest vendor of mid-market solutions. With the much publicized
acquisition of J.D. Edwards, PeopleSoft is concentrating on market and product
expansion. PeopleSoft was founded in 1987 with the primary function of providing client
server based human resources support functions. Today, PeopleSoft has $2.8 billion in
annual revenues, $1.6 billion in investments and cash, 12,000 employees, and more
than 11,000 customers in 150 countries. 8
The Rest of the Pack
Oracle, SAP, and Peoplesoft are the three largest providers of enterprise resource
planning packages, but there are a number of other competitors in the marketplace.
The largest of these competitors include Baan, Great Plains, and IFS. The solutions
offered by Baan, Great Plains, and IFS are generally geared towards small to mid-sized
organizations seeking to streamline operations and increase overall productivity.
Vendor Summary
Each of the three top ERP vendors appear to be growing based on analysis of each
companys financial information. PeopleSoft is smaller than Oracle and SAP, but the
addition of JDEdwards should help PeopleSoft compete more effectively
(notwithstanding current takeover bid from Oracle). The general trend among these
companies is a continued sustained growth in revenue, net income, and cash flow.
PeopleSoft was the only company that suffered a cash flow loss during the most recent
fiscal year. In general, the strong trend of positive growth in revenue and net income
bodes well for each of these organizations.

Page 9of 32

Who Uses These Software Packages?

The following set of charts helps explain the relationship between each of the ERP
vendors and the types of organizations, which tend to use these packages.

Peerstone Research Group via http://www.peerstone.com/pdfs/Samples_of_Quantitative_Data_from

%20_ERP_Studies.pdf Accessed 3-15-04

Per the chart above, it is easy to see that larger corporations prefer to use the big three
vendors rather than smaller software providers. SAP is more preferred than Oracle, but
the combination of PeopleSoft and JDEdwards is not far behind. Smaller organizations
tend to prefer the combination of PeopleSoft and JDEdwards over other providers. The
smaller non big three vendors also have a greater installed base within these smaller
organizations. SAP has the smallest market share in the small business market, which
could become an opportunity as these smaller organizations make upgrade decisions in
the future.

Page 10of 32

Peerstone Research Group via http://www.peerstone.com/pdfs/Samples_of_Quantitative_Data_from

%20_ERP_Studies.pdf Accessed 3-15-04

The chart above provides nice industry segmentation within the ERP market. It is
obvious that SAP dominates the manufacturing and utilities industries whereas
PeopleSoft/JDEdwards dominates the government, education, and financial services
industries.

What Can ERP Do For My Organization?

According to Thomas Davenport, ERP systems may have been the most important
development in the corporate use of information technology in the 1990s. 9 Companies
seeking ERP solutions are usually looking for ways to improve operational performance
and thus reducing operating costs. A recent census survey of manufacturing firms
supported this concept as 205 of 245 plants with enterprise planning packages reported
profitability gains because of their ERP software. 10 Moving beyond the traditional
manufacturing scenario, companies are increasingly looking for ERP to improve their
total supply chain process. The ERP software can integrate a supply chain by
combining purchase order, invoice, inventory, customs, freight, and logistics data so a
company can better manage sourcing and procurement throughout the entire supply
chain process11. Other advantages that companies expect from ERP packages include
improved productivity, improved customer demand management, cost reductions in
general12.

Page 11of 32

Critical Success Factors of an ERP Implementation

Toni Somers and Klara Nelson13 wrote very useful ranked list of critical success factors
for ERP implementations. The information is based on study of over 110 ERP
implementation cases. The list was rated by 52 high-level IT managers, which
consisted of CIOs, MIS managers, directors etc. The companies that were chosen for
the study were US organizations that had fully completed an ERP implementation.
Most of the critical success factors would apply to IT projects in general, but some of the
critical success factors are more readily applicable to ERP projects.

Most of the critical success factors have been mentioned and reviewed during previous
research regarding IT projects in general. Item number 10 (Careful Package Selection)
on the list warrants further explanation, as it is uniquely important in the context of an
ERP implementation. A company choosing an ERP package must sift through various
claims by the vendors to determine which package would fit their business best 14. Once
a vendor is chosen, the company must decide which versions and modules of the
software to install.15 If poor choices are made in this stage of the process, the company
may be stuck with software that doesnt fit their business well enough, and be subject to
costly and time-consuming customizations16.
As mentioned above, several benefits can be achieved via the implementation of an
ERP software package, but the securing the benefits of ERP may be able to be quite
costly. The cost of a modest ERP implementation can range from $2 million to $4
million, and in a large organization, costs can easily exceed $100 million. A recent
survey of 63 companies with annual revenues ranging from $12 million to $63 billion

Page 12of 32

indicated that the average implementation cost $10.6 million and took 23 months to
complete17.

COST CONTROL STRATEGIES

There are six types of costs that are most frequently not fully budgeted for: culture
change, training, integration and testing, data conversion, data analysis, and transition
from consultants.
Change of Culture
The top critical success factor above, is securing top management support before,
during, and after an ERP implementation. This support will enable the ERP package to
be accepted by lower level employees. The ERP process is more than just a software
installation, as it will likely change many business processes. Employees need to be
encouraged by senior management to adapt to the new business model. Key business
processes will likely be reengineered and if people are not prepared for the changes,
the reaction will probably include some type of resistance to change, which may delay
and impair the entire implementation.
Training
Extensive education and training will be required in order to have a successful
implementation. The purpose of the training should be to enable the employees to
solve problems within the context of the newly adopted ERP system. All groups within
the company should be included in training. Obviously, senior management will have
less detailed training, but they still need to be involved in the overall process. The
timing of the training would optimally occur before, during, and after the implementation.
Top management often dramatically underestimates the training costs necessary for a
successful ERP implementation. These training costs should definitely be included in
the original ERP budget documentation, as the training is a prerequisite for the use of
the entire ERP package.18
Owens-Corning originally estimated training to be 6% of the total project budget, but the
final cost was closer to 13%.19 Employees at all levels have to accept different
responsibilities, leading to change management, which usually appears in the budget on
the training line. Unfortunately, oftentimes training is the first item cut when budgets
have to be squeezed.
One caveat to the training platform is that an extensive amount of hands-on practice
will be required before the system efficiencies can be fully utilized. Generic training
which covers such topics as If you click the green icon, this process will happen will
not be sufficient. Users of the application must see how the program will be utilized in
their specific job function. For example, an accountant can be taught to look up
accounts receivable balances in SAP, but if they are not trained on the new accounts
receivable policy put into place because of implementation, the benefits of the system
will not be fully realized for a period.
Page 13of 32

Upon selection of the ERP vendor, the group responsible for performing the training
sessions should be included in all meetings to ensure that appropriate resources are
allocated towards the training function. At this point in time, the company receiving the
software should make a decision regarding whether the training should be outsourced
or insourced. Insourcing the training would be much cheaper, but possibly less effective
if a lack of internal skills exists. Another cost reduction technique would be the use of
web based training, but again, business relevant material will likely be insufficient in a
web based training forum. After the training strategy is determined, the budget for
training should be developed. Successful training can be expected to account for a
range of 10% to 20% of the total project budget.
Managers and so-called super-users should be heavily involved in the training
process, and in most cases it would be prudent to have these people train the trainers.
The business knowledge offered by these managers would prove invaluable to the
training process. They would be able to explain how to solve business problems with
the ERP software rather than learn how different icons function.
Integration and Testing
Enterprise systems are designed to consolidate information in large businesses.
Testing the compatibility between in-house software packages and ERP packages is
another cost usually overlooked because compatibility is only determined incrementally
as the integration progresses. 30% of the cost of a typical ERP implementation is
related to integration.20 These costs will substantially increase if the ERP package
needs to be customized (i.e. higher transaction costs). During the testing and
integration phase, a test environment or mock-office scenario should be used to see
how real data is manipulated by the software package.
Prior, to integration, senior management should have determined which business
processes need to be re-engineered in order to accommodate the new ERP software.
Some organizations incorrectly assume that the ERP system will integrate with all
existing processes. That assumption could prove to be most costly later on in the
implementation process. If the implementation is used to improve the company's
strategy and business processes, then the integration will be smoother and less costly
in the long run.
Fusing the ERP system to the business starts with deciding which modules should be
purchased. Configuration tables are then used to adjust the way processes function
within the system. Configuration tables enable the company to tailor a particular aspect
of the system to the way it chooses to do business. For example, an organization can
select an inventory accounting policy (LIFO, FIFO, etc.), and the priority rule for
scheduling work in the plant.
A tried and true theory for integration is to use a pilot approach to develop an overall
implementation strategy. The results of the pilot project will provide insight into best

Page 14of 32

practices and potential pitfalls. A more efficient procedure will then be available for use
at other facilities.
Data Conversion
It is highly likely, if not certain, that data from a companys existing system will need to
be converted into a format that fits the structure of the ERP modules tables. The
processes of reviewing the data, storing the data, and transferring the data will
undoubtedly add additional cost to the project.
According to Herr,21 the project team should consider the following: Should the data be
transferred in one fell swoop or should an incremental transfer approach be used. Also,
at what number of errors does the project need to be re-evaluated? Cost savings can
be achieved by advanced planning in the realm of data management.
Data Analysis
ERP software only arrives at a company with a set of pre-canned reports that may
meet some reporting requirements, but not all. Most companies neglect to budget for
the costs associated with building and testing customized reports. Without the reports,
the company may be severely impaired, but it will prove costly if the costs of these
reports are not originally budgeted for during the project development cycle.
Transitioning from Consultants
Consultants obviously add costs to the ERP project, but the decision to transition from
consultants to internal employees must be carefully measured. The main advantages of
bringing consultants to the organization are the pending knowledge transfer (buy-in
relationship) and quicker access to highly trained individuals (speeds up integration
process). As the project begins to wind down, it may become apparent that the
consultants have become a vital part of the organization, and it may be difficult to get rid
of them without hurting the business. The best strategy to mitigate this type of risk is to
ensure that internal employees retain and use skills taught by the consulting team. It is
also important to motivate internal employees to stay with the company in order to
establish some continuity in the new world of the business. Once again, it is essential
to plan for these types of issues in advance in order to minimize additional costs
towards the end of the project22.

Page 15of 32

CASE STUDY: FoxMeyer Drug

The following case provides useful insight into a failed ERP implementation at
FoxMeyer Drug Health Corporation. A set of ERP implementation best practices can be
found at the end of the case study.

What was FoxMeyer Drugs Background?

FoxMeyer Drug was once a company with over $5 billion in annual revenue, but poor
management of an ERP implementation caused material accounting and operational
deficiencies that ultimately led the company to bankruptcy in August 1995.
Academically, the FoxMeyer case is in the distant past, but the lessons learned by
FoxMeyer are of immeasurable importance to other companies seeking to avoid a
similar situation.
FoxMeyer sold pharmaceutical products to various hospitals, pharmacies, and other
medical care clients. They were the fourth largest distributor of pharmaceuticals in the
United States and employed over 2400 people in 21 states. Before the ERP project
was started, FoxMeyer had three linked data processing centers including electronic
order entry, invoice preparation and inventory tracking. A customer would fill out the
electronic order, and that order would be sent to one of the three data processing
centers. The orders were then manually filled at regional distribution centers 23.

Why did FoxMeyer want ERP?

The management team in place at the time of the ERP integration focused on meeting
the objective of achieving higher efficiency within the organization, and also to align
their IT systems with an overall business strategy of sales growth. The management
team was highly concerned that FoxMeyers aging IT systems could not handle the
projected growth of the company, so after performing researching the possibilities, SAP
was finally chosen as the ERP package to implement. The original system was a
Unisys mainframe struggling to cope with daily order totals exceeding 300,000 items.
The SAP modules included in the implementation were financials (FI) and logistics.
FoxMeyer hired then Andersen Consulting to assist with the integration project. In
conjunction with the SAP project, FoxMeyer purchased warehouse management
software from a company called Pinnacle24. FoxMeyer decided to use Pinnacle as SAP
was not the market leader in warehouse management at the time, and Pinnacle
supplied the actual automation equipment in addition to a software solution. FoxMeyer
Page 16of 32

required warehouse software capable of handling the high volume of transactions and
complex pricing models common in the healthcare industry.

The Implementation Plan

The SAP implementation project codenamed Delta III was originally based on the
notion that over $40 million in savings could be realized annually. The original project
timeline was highly accelerated towards completion within 18 months, but actually took
over two years to complete. The whole system (SAP, Pinnacle, and original Unisys
system overhaul) was originally expected to cost around $65 million with the actual ERP
implementation process costing an additional $18 million. Using the $40 million savings
estimate, the project would seem to pay for itself within two years of the go-live date.
The CEO and CIO at FoxMeyer were both strong supporters of the project and the CEO
was the project champion. The CIO was quoted to say, we are betting the company on
this [SAP project]. 25

How Did The ERP Implementation Turn Out?

The actual implementation of the ERP package was a failure. Three key management
failures significantly contributed to the overall project failure. These failures included a
sales contract with the University Healthcare Consortium (UHC), poor warehouse
management transition, and a lack of internal IT involvement. Each of these situations
are discussed in further detail below.
In July 1994, FoxMeyer entered into a sales contract with UHC that promised more than
$1 billion in gross revenue on an annual basis. The arrangement may have sounded
like a great idea at the time, but in order to fulfill the requests of UHC the project
timeline of the ERP implementation had to be accelerated. The costs of updating SAP
to handle additional volume from the UHC contract really pushed the project beyond
original expectations.
Peter Dunning, SAP America's executive vice president for global had the following
comments regarding the UHC contract:
FoxMeyer had planned to have a small amount of capacity left on the
Unisys platform once the SAP implementation was complete. But with this
new contract their volumes would severely increase, and they ran out of
capacity on their mainframe. The throughput capacity of the SAP project
had to be increased.24
As it turns out, the UHC contract did not turn out to be as lucrative as originally
anticipated. This change in business in addition to the warehousing problems forced
FoxMeyer to file for bankruptcy in 1995.
The actual cost of the SAP implementation cost more than $100 million that far
exceeded original expectations. One of the primary reasons that costs escalated to this

Page 17of 32

level is the poor management of the warehouse transition process. Christopher Cole,
Chief Operating Officer at Pinnacle said:
The transition from closing old warehouses did not go smoothly
Equipment outages resulted in the shipping of numerous half-finished
orders. Then, when customers would complain about missing items,
FoxMeyer representatives, unaware of what was happening on the
warehouse floor, would authorize makeup shipments that turned out to be
duplicates but were never reported as such by recipients. Error:
Reference source not found
FoxMeyer also had setbacks in transferring inventory to the new warehouse facility.
Cole states:
Because of a debilitating morale problem among departing workers, a lot
of merchandise was dumped into trucks and arrived at Washington Court
House with packages damaged or broken open or otherwise unsalable as
new productThat led to a huge shrinkage in inventoryAs an outsider
looking at it, I would imagine that they lost a lot there, as well as with the
problems of their own internal computer system." Error: Reference source
not found
The following table of quotations further illustrates the FoxMeyer case by displaying the
viewpoints of each of the major players in the ERP project:

Outside Perspectives on FoxMeyers ERP Failure

Organization

Perspective on FoxMeyer Case

Andersen Consulting - Spokesperson

Pinnacle Automation Christopher Cole

We delivered, the work we performed was

successfully completed, and we were paid
in full.21
the problem wasnt the [automation
equipment]; it was the way that they
[FoxMeyer] were running orders through
the system.21
the old mainframe system choked and
died.21

SAP Peter Dunning

Its one of those stories where the

operation was a success, and the patient
died.21

Page 18of 32

Finally, FoxMeyer also suffered because of a lack of internal IT involvement due to lack
of skill and management commitment. This particular oversight allowed too great of a
reliance on Andersen and Pinnacle to completely understand FoxMeyers business and
then change processes to fit the new software systems.Error: Reference source not
found

How Can An Organization Avoid A Similar Failure?

FoxMeyer Drug did not implement the ERP package correctly. Both SAP and Pinnacle
are in agreement that the software implementation was a success, but the business was
not adequately prepared to deal with all challenges presented by the new system. The
main problem plaguing the FoxMeyer team was the inability to de-escalate the project.
Once the UHC contract was signed, the entire project should have been re-evaluated in
order to determine the revised requirements of the ERP package. The additional order
capacity could have been added to SAP in a more orderly and likely less expensive
manner.
The second major problem that occurred in the implementation was the situation with
the warehouse workers. The FoxMeyer management should have created contingency
plans for the departing warehouse workers. It may have been expensive to create such
plans, but in hindsight, those plans would not have been as expensive as the $34
million inventory adjustment. If the project had been de-escalated, it is likely that
FoxMeyer would have had more time to address this situation before going live with the
new systems.
The final issue that doomed the company was a willingness to rely on Andersen and
Pinnacle to handle the implementation. As mentioned above, FoxMeyer suffered from a
lack of competent IT staff within the company. If a well-equipped staff had been in place
during the integration, more issues may have been presented to the FoxMeyer
management team. A business-savvy IT department may have had the foresight to
realize the new UHC contract would exceed original system specifications and call on
management to delay the target date.
A software project risk identification framework developed by Keil, Cule, Lyytinen, and
Schmidt (1998) reveals that the FoxMeyer project had four substantial risks associated
with the SAP implementation project.
1. First, some users of the new system had little or no incentive to make the
necessary efforts to learn the new program. The users referenced were
warehouse workers whose jobs were threatened by the new software. These
workers could be classified as highly disgruntled and failed to properly interact
with the new system. The result of the lack of understanding or willingness to
participate in the new software system led to an unrecoverable inventory loss of
$34 million.26
2. Second, the management of FoxMeyer entered into a sales contract valued at $1
billion annually with the University Health System Consortium (UHC), but failed to
Page 19of 32

recognize that the volume requirements of this contract far exceeded the existing
capabilities of SAP. The business instinct is to take the contract with UHC for the
increase in sales, but failing to account for software constrictions when making
such arrangements can be devastating to an organization. Finally, the UHC
contract caused the project expense to increase to over $100 million as
additional work needed to be performed in order for the system to handle the
increased sales order volume.
3. Third, FoxMeyer had very little in-house skilled IT people and relied almost
entirely on the expertise of Andersen to conduct the implementation. The
separation between the management of FoxMeyer and Andersen could be one
reason that the company failed to recognize potential problems from the new
UHC contract.Error: Reference source not found
The following set of best practices can be extracted from the FoxMeyer Drug case
study:

ERP Implementation Best Practice Checklist

Best Practice

Did FoxMeyer Apply Best

Practice?

Business Process Review / Reengineering

NO

Establish Knowledgeable Project Team

YES

Perform Gradual Implementation

NO

Prepare Organization (Change

Management)

NO

Keep project lifecycles short

YES

Ensure software is compatible with

industry

NO

Establish training methodologies

NO

Final Thoughts
The lessons learned by FoxMeyer are essential in trying to avoid a similar failure. The
poor management more so than failed technology seems to have led the company
toward bankruptcy. FoxMeyer management did not handle the situation with warehouse
employees properly. They also failed to try an implementation phasing program to
Page 20of 32

gradually implement this somewhat untested technology. The untested technology

assertion stems from the fact that at the time, SAP was not capable of handling high
transaction volumes. FoxMeyer should have invested more time and money in in-house
IT resources in order to ensure that the basic needs of the business would be met
through the new system implementation. Better management practices would have
likely saved the project and ultimo ately the company.

Page 21of 32

CASE STUDY: University of Missouri

Generally, a firm decides to implement an ERP project because one of its core business
functions is broken. The corporations financials need integrating, the manufacturing
processes need to be standardized, or maybe the human resources group needs to be
more efficient. Depending on the focus of the changes, one enterprise software offering
may be better suited than another to meet those needs. PeopleSoft began life as an
HR software package and still excels in HR, while other enterprise packages began life
as discrete manufacturing software, etc. It's wise to take that into account, as well as
the specific business problems you're trying to address, when picking a package. If a
vendor is regarded as a specialist in one area, it is a good idea to scrutinize the other
modules more closely to insure their functionality is sufficient for the enterprise's needs.

An Overview of the University of Missouri

The University of Missouri has provided teaching, research, and service
to the State of Missouri since 1839. It was the first public institution of
higher education in the Louisiana Purchase territory. Today it is one of
the nations largest, public institutions of higher education with over
60,000 students on four (4) campuses and an extensive Outreach and
Extension program. The University system recently signed a Letter of
Intent with Northwest Missouri State University. When the merger is
complete a fifth campus will be created.
Columbia remained the only campus until the School of Mines and Metallurgy was
established in Rolla in 1870. In 1963, the University founded a new campus in St. Louis
and acquired the University of Kansas City, creating the present four-campus system.
A nine-member Board of Curators governs the University System. Each member is
appointed by the Governor and confirmed by the Missouri Senate. When necessary,
they also establish the search teams and choose the President of the University
System. A chancellor reporting to the president heads each campus. Like a Board of
Directors, the Curators are responsible for the high level funding issues. They make the
decisions on all capital projects throughout the University System.
As of Fall 2003, the four campuses had a total student enrollment of 60,903 (45,129
undergraduates and 15,774 graduates and first professionals). The University also
hires 10,610 teaching and research staff and an additional 15,636 administrative and
support staff. The net book value of the Universitys capital assets is $1,534,573,000.

Page 22of 32

The campuses breakdown as follows:

The Columbia Campus (UMC) is a predominantly residential
campus. The enrollment in Fall 2003 was 26,805 (20,441
undergraduate, 6,354 graduate and first professional students).
There are 5,107 (41.3% full-time, 58.7% part-time) teaching and
research staff with an additional 6,605 (75.2% full-time, 24.8%
part-time) administrative and support staff
UMC also operates the University of Missouri Health Care (UMHC) that includes
University Hospital, Children's Hospital, Ellis Fischel Cancer Center and Columbia
Regional Hospital, all in Columbia, and the Missouri Rehabilitation Center in Mount
Vernon.
In addition, the University Physicians practice operates numerous outpatient clinics in
Columbia and several mid-Missouri communities.
During fiscal 2002, UMHC hired 335 (99.7% full-time, 0.3% part-time) teaching and
research staff and 4,451 (68.5% full-time, 31.5% part-time) administrative, service and
support staff. UMHC has a total 694 beds and admitted 17,387 patients for a total
113,746 Inpatient days. UMHC operated outpatient clinics (587,777 visits), and
Emergency Center (34,127 visits) and performed same-day surgeries 4,603 times.
The Kansas City Campus (UMKC) enrollment in Fall 2003 was
14,244 (57% undergraduate, 43% graduate and first professional
students). Nearly two-thirds (64%) of the on-campus students are
registered as full-time students; 36% are part-time. There are
2,368 (47.3% full-time, 52.7% part-time) teaching and research
staff and 1,763 (75.8% full-time, 24.2% part-time) administrative
and support staff.
The Rolla Campus (UMR) is an institution of science and
engineering. The enrollment in Fall 2003 was 5,459 (4,089
undergraduate, 1,370 graduate students). There are 1,044 (33.8%
full-time, 66.2% part-time) teaching and research staff and 831
(81.6% full-time, 18.4% part-time) administrative and support staff.
The St. Louis Campus (UMSL) The enrollment in Fall 2003 was 15,605 (12,630
undergraduate, 2,975 graduate and first professional students). 60.1% of all
undergraduates were enrolled full-time and 39.9% part-time. Among graduate students,
22.4% enrolled full-time and 77.6% part-time. There are 1,412 (35.1% full-time, 64.9%
part-time) teaching and research staff and 1,135 (76.6% full-time, 23.4% part-time)
administrative and support staff.

Page 23of 32

Different Cultures Different Needs

As you can see, each campus attracts a different mix of students. Some campuses
attract full-time, residential students. Other campuses serve the working student
allowing them to attend classes part-time while pursuing other endeavours. Each
campus had their own way of doing things. The University had many disparate
business ventures.

Why ERP for the University of Missouri?

In the early 1990s, the Curators recognized that the current systems were not meeting
customer specification or performing adequately. Between 1991 and 1996, the Curators
made large investments in the technical infrastructure.
The Board of Curators recognized that past improvement efforts had automated
processes without making much change to the underlying policies and processes. In the
past, there had been a tendency to "computerize" rather than redesign processes, thus
leaving unnecessary processes intact. Applying automation, without redesigning
processes, limits the productivity and service benefits possible with new technology and
does not leverage investments in technology. Changes in policy and processes are
critical to continue the mobilization for change. Beginning in 1996, the Curators
established a five (5) year plan to review and improve the processes of the campuses to
make them more efficient and user-friendly.
They are too paper intensive, require numerous approvals, take an inordinate
amount of time to complete and are supported by computer hardware and
software that is as much as 20 years old.
James McGill, UM Executive Vice President
The recommended strategies are to redesign processes to meet customer
needs.
James McGill, UM Executive Vice President

Business Process Review

The Administrative Systems Project Committee, comprised of 30 representatives from
all 4 campuses plus central administration, was appointed to develop a plan to make the
core business and service processes of the University more efficient and user-friendly.
With the help of Coopers and Lybrand Higher Education Consulting Group, the
committee began to look at the areas of finance and human resources and soon added
Student Administration.

Page 24of 32

Building on the work of the Student Systems Planning Group and several other quality
improvement studies, the Committee developed a plan to

Manage the change process

Evaluate staffing capacity and capability needed to implement the

changes

Evaluate and select enabling technology

All faculty, staff, and students were invited to participate. Over a 6 weeks period,
approximately 140 employees from the 4 campuses participated in interviews,
workshops, focus groups, and data analysis.

Vision Statement
The business processes and administrative
systems project must focus first on policy,
organization structure and process technology (i.e.
new software and hardware) should be viewed as
an enabler.

ERP Challenge Begins

In March 1998, the University purchased PeopleSoft. At the time, PeopleSoft was the
only ERP provider who had a product developed for educational and government
enterprises. The University purchased the following modules:

Student Administrations
o Admit
o Student Financials
o Financial Aid
o Student Records
Human Resources
o Human Resources
o Benefits
o Payroll
Finance
o General Ledger
o Accounts Payable
o Accounts Receivable
o Budgets
o Grants

Page 25of 32

The University also hired KPMG Peat Marwick (KPMG) as their implementation
partner. KPMG was an experienced and respected implementer of PeopleSoft in an
educational setting. The University trusted KPMG to guide them through the entire
painful process. That trust was misplaced. KPMG did not understand the diverse
cultures of each campus and advised installing a vanilla version of PeopleSoft. It
quickly became apparent that that was not the best approach.
During the first phase of the Administrative Systems Project (ASP), selected redesign
teams were formed in the finance, human resource, and student administrative areas.
The charge for these teams was to:
Review and define process, policy, people, and organizational issues. Design
future processes based on the PeopleSoft Applications and the ASP guiding
principles.
During the last quarter of 1998 and first quarter of 1999, the ASP Core Team in each of
the Human Resources, Financial Services, and Student Services areas conducted
Fit/Gap Workshops. These workshops presented a first look at PeopleSoft functions
and a good review of key business processes. From these workshops, both the Core
Team and the participating staff gained great insight into the University's needs as well
as the toolset theyd be using in the future to do business.
Working with the information gained from Fit/Gap Analysis workshops and other
experiences and inputs, the University formulated an initial plan for implementing the
Administrative Systems Project. This plan was presented to more than 170 Fit/Gap
Analysis Team participants and other University staff.
The Curators established an initial budget of over $40,000,000.
Software
Hardware
People
On going
Training

$10,110,325
2,400,000
22,665,545
3,569,487
1,300,000
$40,045,357

Project Plan is created

The project plan called for phasing in the various modules over a four to five year
period. As anyone knows who has planned a project over six (6) months, it is very
difficult to plan your behavior and that of others over a short period. Planning a project
over four or five years is impossible. A project that long would require constant
management and revision.
The various committees and teams went to work redesigning, prototyping, and
implementing the new system. Finance led the way expecting to implement the
General Ledger in July 2000. Recognizing and labeling the various data parts, mapping
them to the new database structure, creating data that may not have been collected, but

Page 26of 32

was deemed important by another campus, was a much larger job than the teams
anticipated. The General Ledger finally went into production in 2001.
Though KPMG was assisting, neither the technical teams nor the user teams, had the
expertise with PeopleSoft. Everyone involved was moving quickly to increase their
PeopleSoft skills while at the same time understand the legacy system they were
converting. Many choices were made that were in error.

Definition of Challenges
Karen Boyd, Office of Research Administration, spent 20% of her time, over 2.5 years in
order to design, prototype, and implement the system. Since the installation of the
grants package, she still attends regular meetings to discuss how well the new system
is meeting the needs of the customers. As is to be expected, some Administrators on
the various campuses like the new system, some absolutely hate it. As Karen said, the
new system is different. Though PeopleSoft had a grants module, no university who
had purchased the software had implemented it. The module was found to be very
difficult to use and not very efficient. The University of Missouri tackled the task of
forcing their data and processes into the PeopleSoft model. Karen did mention that
some of the data entry that was done on one screen in the legacy system now must be
entered on as many as five. She indicated that she believed some people were not
happy with the changes. The learning curve for PeopleSoft is steep and everyone does
not learn at the same pace. In the Grants area, she has established a quarterly training
session to be used for additional PeopleSoft and general Grants training.
In January 2004, UMR implemented the Student Records module. This module allows
students to access their own records at any time of day or night. Laura Stoll, Registrar
for UMR, described the implementation as bloody and painful. Though this module
has been implemented and is in use on the UMR campus, it is not finished. If a student
maintains dual majors, the Registrars staff must manually maintain the records. Laura
emphasized that her department always delivered, no matter what it takes. She did
emphasize that the Student Records module has not yet lived up to its promises, but
she thinks in another year or two all the bugs will be worked out.
PeopleSofts educational modules were designed as a vanilla educational package. In
the real world, a student may maintain dual majors, multiple G.P.A.s, major and minor
courses of study, or the need to track residential clients. PeopleSoft does not inherently
handle these data peculiarities and many more. PeopleSoft was not designed with
educational systems in mind.

Accepted Challenge of Implementation

The University of Missouri accepted the challenge of implementing a very large project
over the entire system. The plan extended over many years. With each passing year,
PeopleSoft upgraded their software offering bug fixes and new functions. With the
upgrade of the software module, the scope of the project changed. In some cases, the
project had to endure significant re-writes to capture the new functions. In Fall 2004,
the University will release a new version of PeopleSoft. Due to the customization, over

Page 27of 32

1,000 changes have been made to the existing PeopleSoft modules. Change
Management closed the previous version disabling the various teams from making any
more changes until after the new version is implemented. Change Management is
allowing approximately 8 months to compare the functions in the latest version with the
existing version. Some customization will be moved to the new version, some
customization has been included as new functionality, and some customization will need
to be changed because it doesnt work that way in the new version.
This project was scheduled to be completed in late 2002, early 2003. It is now mid2004 and the ERP system has still not been completed. Dr. Jerrold Siegel, Associate
Vice Chancellor for Information Technology, thinks that the University is still several
years away from completing the initial implementation. The initial budget totaled
$40,000,000. The current project expenses are well over $50,000,000 and still
climbing.

Page 28of 32

Final Thoughts and Conclusions

When analyzing both the FoxMeyer and UM cases, it is clear that both of these
organizations did not follow the best practices for ERP implementation. The FoxMeyer
case is an example of an extreme implementation failure and the UM case represents a
challenged implementation. The chart below provides a cross comparison of each case
study and the best practices utilized by each organization. It should be noted that
unless all of the practices listed below are followed, the project will have difficulty
advancing beyond the challenged status. Both FoxMeyer and the University of
Missouri followed a few of the best practices, but neither organization followed all of the
best practices. By not following all of the best practices, the FoxMeyer case ended in
failure and the University of Missouri case is still in a challenged state.

ERP Implementation Best Practice Checklist

Best Practices

FoxMeyer

UMSL

Business Process Review / Reengineering

No

Yes

Establish Knowledgeable Project Team

Yes

Yes

Perform Gradual Implementation

No

Yes

Prepare Organization (Change

Management)

No

Partial

Keep project lifecycles short

Yes

No

Ensure software is compatible with

industry

No

Yes

Establish training methodologies

No

Yes

With all of the information above in mind, it is clear that performing an ERP
implementation is a multi-facet endeavor. All parts of the organization must make a
commitment to allowing the implementation to succeed. Every major project will have
certain problems that cause additional cost and effort, but by following all of the best
practices mentioned above a company will have a much greater probability of
successful implementation. The two case studies within this article present examples of
projects that did not follow all of the best practices. The misfortunes suffered by

Page 29of 32

FoxMeyer and the University of Missouri should provide motivation for other
organizations to avoid similar failures and challenges.

Page 30of 32

http://www3.gartner.com/6_help/glossary/GlossaryE.jsp
2

http://www2.cio.com/metrics/2002/metric381.html

http://www.cio.com/archive/021599/erp.html

http://www3.gartner.com/6_help/glossary/GlossaryW.jsp

http://www.oracle.com/corporate/investor_relations/10_k2003.pdf

http://www.oracle.com/corporate/index.html?story.html

http://www.sap.com/company/

http://www.peoplesoft.com/corp/en/about/overview/corp_back.jsp

Davenport T (1998) Putting the enterprise into the enterprise system.

Harvard Business Review JulyAugust, 121131.
10

Doug Bartholomew. Industry Week. Cleveland: Mar 2004. Vol. 253, Iss. 3; pg. 31

11

Beth Bacheldor. InformationWeek. Manhasset: Mar 8, 2004. , Iss. 979; pg. 32, 6 pgs

12

Seewald, N., Enterprise resource planning tops manufacturers' IT budgets, Chemical Week, New York, Sep
11, 2002, Vol. 164, Issue 35, p.34.
13

Somers TM and Nelson K (2001) The impact of critical success factors across the stages of enterprise
resource planning implementations. Proceedings of the 34th Hawaii International Conference on Systems
Sciences (HICSS-3), January 36 Maui, Hawaii (CD-ROM).
14

H Akkermans, K van Helden. Vicious and virtuous cycles in ERP implementation: A case study of interrelations
between critical success factors. European Journal of Information Systems. Basingstoke: Mar 2002. Vol. 11, Iss.
1; pg. 35
15

Piturro M (1999) How midsize companies are buying ERP. Journal

of Accountancy 188, 4148.
16

Janson MA and Subramanian A (1996) Packaged software: selection

and implementation policies. INFOR 34, 133151.
17

Elisabeth J Umble, M Michael Umble. Avoiding ERP implementation failure

Industrial Management. Norcross: Jan/Feb 2002. Vol. 44, Iss. 1; pg. 25, 10 pgs
18

White, J.B., D. Clark, and S. Ascarelli. "The German Software Is Complex, Expensive, and Wildly Popular."
Wall Street journal, March 14,1997, Al, A12.
19
20

Vowler, J. "You Cannot Afford to Ignore Integration." Computer Weekly, June 3, 1999, 44.

21

Herr, W. "The Benefits of Data Integration: HFMA Study Findings." Healthcare Financial Management 50
(Sept. 1996): 52-56.
22

T Hillman Willis, Ann Hillary Willis-Brown, Amy McMillan Cost containment strategies for ERP system
implementations. Production and Inventory Management Journal. Alexandria: Second Quarter 2001. Vol. 42,

Iss. 2; pg. 36, 7 pgs

23

Olson, David Louis. Introduction to Information Systems Project Management. Publisher: McGraw-Hill/Irwin;
Book and CD-ROM edition (August 14, 2000) ISBN: 0072424206
24

Jesitus, J. "Broken Promises?; FoxMeyer 's Project

was a Disaster. Was the Company Too Aggressive or was
it Misled?", Industry Week, November 3, 1997, 31-37.
25

Cafasso, R. "Success strains SAP support",

Computerworld, 28(36), September 5, 1994.
26

Scott, Judy E. "The FoxMeyer Drugs' Bankruptcy: Was it a Failure of ERP?" in Proceedings of The
Association for Information Systems Fifth Americas Conference on Information Systems, Milwaukee, WI, August
1999.

Bibliography
http://riker.ps.missouri.edu/DeptPubs/UniRel/spectrum/Dec96/Spectrum6.html
http://www.umsystem.edu/ums/curators/news/index.shtml#review
http://asp.umsystem.edu/
Jerrold Siegel, Ph.D. Associate Vice Chancellor for Information Technology, University of
Missouri St Louis, interviewed in person by LeRue Holbrooke, March 15, 2004.
Karen Boyd, Office of Research Administration, University of Missouri St Louis, interviewed
in person by LeRue Holbrooke, April 5, 2004.
Laura Stoll, Registrar, University of Missouri Rolla, interviewed by phone by LeRue
Holbrooke, April 16, 2004.