INTRODUCTION



[pic]

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.[i] 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.[ii] 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 (Challenged). The FoxMeyer case is based on second-hand information and the UM case original research done through interviews.

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 SAP’s 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 Dell’s 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.[iii]

How does ERP work?

The following figure 9 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.

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 MRP’s 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 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.[iv] 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 PC’s or the stripped down PC that can be used by anyone.

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.

[pic]

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 internet-enabled enterprise software across its entire product line: database, business applications, and application development and decision support tools.

[pic]

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, Oracle’s R&D spending is only $1,180 compared with sales and marketing of $2,072.[v]

[pic]

[vi]

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 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.[vii]

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. [viii]

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 company’s 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.

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.

[pic]

Peerstone Research Group via 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.

[pic]

Peerstone Research Group via 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 1990’s.[ix] 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.[x] 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 process[xi]. Other advantages that companies expect from ERP packages include improved productivity, improved customer demand management, cost reductions in general[xii].

Critical Success Factors of an ERP Implementation

Toni Somers and Klara Nelson[xiii] 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 CIO’s, 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.

[pic]

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[xiv]. Once a vendor is chosen, the company must decide which versions and modules of the software to install.[xv] If poor choices are made in this stage of the process, the company may be stuck with software that doesn’t fit their business well enough, and be subject to costly and time-consuming customizations[xvi].

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 indicated that the average implementation cost $10.6 million and took 23 months to complete[xvii].

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.[xviii]

Owens-Corning originally estimated training to be 6% of the total project budget, but the final cost was closer to 13%.[xix] 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.

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.[xx] 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 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 company’s existing system will need to be converted into a format that fits the structure of the ERP module’s 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,[xxi] 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 project[xxii].

CASE STUDY: FoxMeyer Drug

[pic]

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[xxiii].

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 FoxMeyer’s 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 Pinnacle[xxiv]. 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 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].” [xxv]

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 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.” 24

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 product…That led to a huge shrinkage in inventory…As 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." 24

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 FoxMeyer’s ERP Failure |

|Organization |Perspective on FoxMeyer Case |

|Andersen Consulting - Spokesperson |“We delivered, the work we performed was successfully completed, and |

| |we were paid in full.”21 |

|Pinnacle Automation – Christopher Cole |“…the problem wasn’t 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 |“It’s one of those stories where the operation was a success, and the |

| |patient died.”21 |

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 FoxMeyer’s business and then change processes to fit the new software systems.24

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.[xxvi]

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 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.26

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 / Re-engineering |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 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.

CASE STUDY: University of Missouri

Generally, a firm decides to implement an ERP project because one of its core business functions is broken. The corporation’s 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 nation’s 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 University’s capital assets is $1,534,573,000.

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.

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.

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.

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.

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

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 they’d 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 $10,110,325

Hardware 2,400,000

People 22,665,545

On going 3,569,487

Training 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 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 Registrar’s 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.

PeopleSoft’s 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 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 doesn’t “work that way” in the new version.

This project was scheduled to be completed in late 2002, early 2003. It is now mid-2004 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.

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 / Re-engineering |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 FoxMeyer and the University of Missouri should provide motivation for other organizations to avoid similar failures and challenges.

-----------------------

[i]

[ii]

[iii]

[iv]

[v]

[vi]

[vii]

[viii]

[ix] Davenport T (1998) Putting the enterprise into the enterprise system.

Harvard Business Review July–August, 121–131.

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

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

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

[xiii] 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 3–6 Maui, Hawaii (CD-ROM).

[xiv] 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

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

of Accountancy 188, 41–48.

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

and implementation policies. INFOR 34, 133–151.

[xvii] Elisabeth J Umble, M Michael Umble. Avoiding ERP implementation failure

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

[xviii] 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.

[xix]

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

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

[xxii] 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

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

[xxiv] 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.

[xxv] Cafasso, R. "Success strains SAP support",

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

[xxvi] 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







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.

-----------------------

Human

Resource

Management

Applications

Service

Applications

Inventory

And Supply

Applications

Back-office

Administrators

And Workers

Customers

Sales and

Delivery

Applications

Financial

Applications

Reporting

Applications

Manufacturing

Applications

Human

Resource

Management

Applications

Sales Force

And Customer

Service Reps

Employees

Suppliers

Central

Database

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.”

“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

[pic]

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download