European Journal of Operational Research 146 (2003)241–257 www.elsevier.com/locate/dsw
Enterprise resource planning: Implementation procedures and critical success factors
Elisabeth J. Umble a, Ronald R. Haft b, M. Michael Umble a,* a Department of Management, Hankamer School of Business, Baylor University, P.O. Box 98006, Waco, TX 76798-8006, USA b Huck Fasteners, 8001 Imperial Drive, P.O. Box 8117, Waco, TX 76714-8117, USA
Abstract
Enterprise resource planning (ERP)systems are highly complex information systems. The implementation of these systems is a difficult and high cost proposition that places tremendous demands on corporate time and resources. Many ERP implementations have been classified as failures because they did not achieve predetermined corporate goals. This article identifies success factors, software selection steps, and implementation procedures critical to a successful im- plementation. A case study of a largely successful ERP implementation is presented and discussed in terms of these key factors. 2002 Elsevier Science B.V. All rights reserved.
Keywords: Enterprise resource planning; Business process reengineering; Project management; Critical success factors; Implementation procedures
1. Why ERP? As the business world moves ever closer to a completely collaborative model and competitors The business environment is dramatically upgrade their capabilities, to remain competitive, changing. Companies today face the challenge of organizations must improve their own business increasing competition, expanding markets, and practices and procedures. Companies must also rising customer expectations. This increases the increasingly share with their suppliers, distribu- pressure on companies to lower total costs in the tors, and customers the critical in-house informa- entire supply chain, shorten throughput times, tion they once aggressively protected [17]. And drastically reduce inventories, expand product functions within the company must upgrade their choice, provide more reliable delivery dates and capability to generate and communicate timely better customer service, improve quality, and effi- and accurate information. To accomplish these ciently coordinate global demand, supply, and objectives, companies are increasingly turning to production [25]. enterprise resource planning (ERP)systems. ERP provides two major benefits that do not exist in non-integrated departmental systems: (1)a * Corresponding author. unified enterprise view of the business that en- E-mail address: [email protected] (M.M. Umble). compasses all functions and departments; and (2)
0377-2217/03/$ - see front matter 2002 Elsevier Science B.V. All rights reserved. PII: S0377-2217(02)00547-7 242 E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257 an enterprise database where all business transac- lem. Capacity planning represents an equal chal- tions are entered, recorded, processed, monitored, lenge. In response, techniques for capacity planning and reported. This unified view increases the re- were added to the basic MRP system capabilities. quirement for, and the extent of, interdepartmental Tools were developed to support the planning of cooperation and coordination. But it enables com- aggregate sales and production levels (sales and panies to achieve their objectives of increased operations planning), the development of the communication and responsiveness to all stake- specific build schedule (master production sched- holders [9]. uling), forecasting, sales planning and customer- order promising (demand management), and high-level resource analysis (rough-cut capacity 2. The evolution towards ERP planning). Scheduling techniques for the factory floor and supplier scheduling were incorporated The focus of manufacturing systems in the into the MRP systems. When this occurred, users 1960Õs was on inventory control. Companies could began to consider their systems as company-wide afford to keep lots of ‘‘just-in-case’’ inventory on systems. These developments resulted in the next hand to satisfy customer demand and still stay evolutionary stage that became known as closed- competitive. Consequently, techniques of the day loop MRP [21]. focused on the most efficient way to manage large In the 1980Õs, companies began to take advan- volumes of inventory. Most software packages tage of the increased power and affordability of (usually customized)were designed to handle in- available technology and were able to couple the ventory based on traditional inventory concepts movement of inventory with the coincident finan- [23,25]. cial activity. Manufacturing resources planning In the 1970Õs, it became increasingly clear that (MRP II)systems evolved to incorporate the fi- companies could no longer afford the luxury nancial accounting system and the financial man- of maintaining large quantities of inventory. This agement system along with the manufacturing led to the introduction of material requirements and materials management systems. This allowed planning (MRP)systems. MRP represented a huge companies to have a more integrated business step forward in the materials planning process. system that derived the material and capacity re- For the first time, using a master production quirements associated with a desired operations schedule, supported by bill of material files that plan, allowed input of detailed activities, trans- identified the specific materials needed to produce lated all this to a financial statement, and sug- each finished item, a computer could be used to gested a course of action to address those items calculate gross material requirements. Using ac- that were not in balance with the desired plan curate inventory record files, the available quantity [23]. of on-hand or scheduled-to-arrive materials could By the early 1990Õs, continuing improvements in then be used to determine net material require- technology allowed MRP II to be expanded to ments. This then prompted an activity such as incorporate all resource planning for the entire placing an order, canceling an existing order, or enterprise. Areas such as product design, in- modifying the timing of existing orders. For the formation warehousing, materials planning, ca- first time in manufacturing, there was a formal pacity planning, communication systems, human mechanism for keeping priorities valid in a resources, finance, and project management could changing manufacturing environment. The ability now be included in the plan. Hence, the term, ERP of the planning system to systematically and effi- was coined. And ERP can be used not only in ciently schedule all parts was a tremendous step manufacturing companies, but in any company forward for productivity and quality [21,23,25]. that wants to enhance competitiveness by most Yet, in manufacturing, production priorities effectively using all its assets, including informa- and materials planning are only part of the prob- tion [23,25]. E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257 243
3. The promise and pitfalls of ERP––why the imple- chain information, and customer information. For mentation process matters managers who have struggled, at great expense and with great frustration, with incompatible infor- Enterprise systems appear to be a dream come mation systems and inconsistent operating prac- true. The commercially available software packages tices, the promise of a quasi ‘‘off-the-shelf’’ solution promise seamless integration of all information to the problem of business integration is entic- flows in the company––financial and accounting ing. Fig. 1 illustrates the scope of an enterprise information, human resource information, supply system.
Fig. 1. The scope of an enterprise system. 244 E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257
It is no surprise that business organizations have systems, and many implemented ERP systems to been beating paths to the doors of enterprise system solve their year 2000 problems. But the price of developers. A successful ERP project can cut the securing the benefits of ERP may be high. Not fat out of operating costs, generate more accurate only do ERP systems take a lot of time and money demand forecasts, speed production cycles, and to implement, they can disrupt a companyÕscul- greatly enhance customer service––all of which can ture, create extensive training requirements, and save a company millions of dollars over the long even lead to productivity dips and mishandled run. At Toro Co., ERP, coupled with new ware- customer orders that, at least in the short term, can housing and distribution methods, resulted in damage the bottom line [29]. Moreover, according annual savings of $10 million due to inventory re- to Standish Group research, 90% of ERP imple- duction. Owens Corning claims ERP software mentations end up late or over budget [33]. helped it save $50 million in logistics, materials Although it has been estimated that the pay- management, and sourcing. ERP also resulted in back period for an ERP system typically ranges a reduction in inventory because material-man- from one to three years [3], the evidence is mixed. agement planners had access to more accurate Meta Group recently surveyed 63 companies–– data––such as how much inventory was already in ranging in size from $12 million to $43 billion in the pipeline––and could do a better job forecasting corporate revenue––to quantify the payback firms future demand [29]. ERP systems reportedly also realized from their ERP investments. The data lead to improved cash management, reduction in indicated that the average implementation cost personnel requirements, and a reduction in overall $10.6 million and took 23 months to complete. In information technology costs by eliminating re- addition, an average of $2.1 million was spent on dundant information and computer systems [17,29]. maintenance over a two-year period. Ultimately, In 1997, $10 billion was spent to purchase ERP their research indicated that companies showed an systems [31]. That figure increases significantly average ROI loss of $1.5 million over a six-year when the associated consultant expenditures are period [29]. included. A 1999 APICS survey indicated that one- fourth of members considered or planned to pur- chase a new ERP system or upgrade their old ERP 4. Critical factors for successful ERP implementa- system in the year 2000. That number jumped to tion 34.5% among companies with annual revenues of $1 billion or more. Boston-based AMR Research Implementing an ERP system is not an inex- predicted that the ERP market would grow at an pensive or risk-free venture. In fact, 65% of exec- annual rate of 32% through 2003. AMR concluded utives believe that ERP systems have at least a that the impetus for this skyrocketing demand moderate chance of hurting their businesses be- would be manufacturersÕ desire to establish better cause of the potential for implementation prob- control over their supply chains [2,3]. Clearly, the lems [5]. It is therefore worthwhile to examine the economic slowdown experienced through 2001 factors that, to a great extent, determine whether dampened this projected demand. However, as the the implementation will be successful. Numerous economy recovers, the demand for ERP systems authors have identified a variety of factors that can should again dramatically increase. be considered to be critical to the success of an Surprisingly, given the level of investment and ERP implementation. The most prominent of length of time needed to implement ERP systems, these are described below. many companies have proceeded to implement ERP without making any return on investment 4.1. Clear understanding of strategic goals (ROI)calculations. But, most companies seem to have had good reasons for doing so––some wanted ERP implementations require that key people to integrate diverse business units, others wanted throughout the organization create a clear, com- to consolidate redundant proprietary information pelling vision of how the company should operate E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257 245 in order to satisfy customers, empower employees, 4.4. Organizational change management and facilitate suppliers for the next three to five years. There must also be clear definitions of goals, The existing organizational structure and pro- expectations, and deliverables. Finally, the orga- cesses found in most companies are not compatible nization must carefully define why the ERP system with the structure, tools, and types of information is being implemented and what critical business provided by ERP systems. Even the most flexible needs the system will address [12,15,24,30]. ERP system imposes its own logic on a companyÕs strategy, organization, and culture. Thus, imple- menting an ERP system may force the reengineer- 4.2. Commitment by top management ing of key business processes and/or developing new business processes to support the organiza- Successful implementations require strong tionÕs goals [20]. And redesigned processes require leadership, commitment, and participation by top corresponding realignment in organizational con- management [8,16,21,26]. Since executive level trol to sustain the effectiveness of the reengineering input is critical when analyzing and rethinking efforts. This realignment typically impacts most existing business processes, the implementation functional areas and many social systems within project should have an executive management the organization. The resulting changes may sig- planning committee that is committed to enter- nificantly affect organizational structures, policies, prise integration, understands ERP, fully supports processes, and employees. the costs, demands payback, and champions the Unfortunately, many chief executives view ERP project. Moreover, the project should be spear- as simply a software system and the implementa- headed by a highly-respected, executive-level pro- tion of ERP as primarily a technological challenge. ject champion [6,12,18]. They do not understand that ERP may funda- mentally change the way in which the organization 4.3. Excellent project management operates. This is one of the problematic issues facing current ERP systems. The ultimate goal Successful ERP implementation requires that should be to improve the business––not to imple- the organization engage in excellent project man- ment software. The implementation should be agement. This includes a clear definition of ob- business driven and directed by business require- jectives, development of both a work plan and a ments and not the IT department [4,6,20]. resource plan, and careful tracking of project Clearly, ERP implementations may trigger progress [8,16,26]. And the project plan should profound changes in corporate culture. If people establish aggressive, but achievable, schedules that are not properly prepared for the imminent chan- instill and maintain a sense of urgency [16]. ges, then denial, resistance, and chaos will be A clear definition of project objectives and a predictable consequences of the changes created by clear plan will help the organization avoid the the implementation. However, if proper change all-too-common ‘‘scope creep’’ which can strain management techniques are utilized, the company the ERP budget, jeopardize project progress, and should be prepared to embrace the opportunities complicate the implementation [8,16,20]. The provided by the new ERP system––and ERP will project scope must be clearly defined at the outset make available more information and make at- of the project and should identify the modules tainable more improvements than at first seemed selected for implementation as well as the affected possible. The organization must be flexible enough business processes. If management decides to to take full advantage of these opportunities [6,26]. implement a standardized ERP package without major modifications, this will minimize the need to 4.5. A great implementation team customize the basic ERP code. This, in turn, will reduce project complexity and help keep the im- ERP implementation teams should be com- plementation on schedule [26]. posed of top-notch people who are chosen for their 246 E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257 skills, past accomplishments, reputation, and flexi- make end user training successful, the training bility. These people should be entrusted with criti- should start early, preferably well before the im- cal decision making responsibility [6,8,16,20,26]. plementation begins. Executives often dramati- Management should constantly communicate with cally underestimate the level of education and the team, but should also enable empowered, rapid training necessary to implement an ERP system as decision making [26]. well as the associated costs. Top management The implementation team is important because must be fully committed to spend adequate money it is responsible for creating the initial, detailed on education and end user training and incorpo- project plan or overall schedule for the entire rate it as part of the ERP budget. It has been project, assigning responsibilities for various ac- suggested that reserving 10–15% of the total ERP tivities and determining due dates. The team also implementation budget for training will give an makes sure that all necessary resources will be organization an 80% chance of implementation available as needed. success [19,32]. All too often, employees are expected to be able 4.6. Data accuracy to effectively use the new system based only on education and training. Yet, much of the learning Data accuracy is absolutely required for an ERP process comes from hands-on use under normal system to function properly. Because of the inte- operating conditions. Thus, a designated individ- grated nature of ERP, if someone enters the wrong ual (preferably the project leader)should maintain data, the mistake can have a negative domino effect ongoing contact with all system users and monitor throughout the entire enterprise. Therefore, edu- the use of, and problems with, the new system. cating users on the importance of data accuracy There is also a need for post-implementation and correct data entry procedures should be a top training. Periodic meetings of system users can priority in an ERP implementation [28,29]. help identify problems with the system and en- ERP systems also require that everyone in the courage the exchange of information gained organization must work within the system, not through experience and increasing familiarity with around it. Employees must be convinced that the the system [12]. company is committed to using the new system, will totally changeover to the new system, and will 4.8. Focused performance measures not allow continued use of the old system. To re- inforce this commitment, all old and informal Performance measures that assess the impact of systems must be eliminated. If the organization the new system must be carefully constructed. Of continues to run parallel systems, some employees course, the measures should indicate how the sys- will continue using the old systems [10]. tem is performing. But the measures must also be designed so as to encourage the desired behaviors 4.7. Extensive education and training by all functions and individuals. Such measures might include on-time deliveries, gross profit mar- Education/training is probably the most widely gin, customer order-to-ship time, inventory turns, recognized critical success factor, because user vendor performance, etc. understanding and buy-in is essential. ERP im- Project evaluation measures must be included plementation requires a critical mass of knowledge from the beginning. If system implementation is to enable people to solve problems within the not tied to compensation, it will not be successful. framework of the system. If the employees do not For example, if all managers will get their raises understand how a system works, they will invent and bonuses next year even if the system is their own processes using those parts of the system not implemented, successful implementation is less they are able to manipulate [6,10,16,23,26]. likely. Management, vendors, the implementation The full benefits of ERP cannot be realized until team, and the users must share a clear under- end users are using the new system properly. To standing of the goal. If someone is unable to E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257 247 achieve agreed-upon objectives, they should either effective and efficient operation and may reduce receive the needed assistance or be replaced. When costs. teams reach their assigned goals, rewards should Perhaps the most difficult decision to be made be presented in a very visible way. The project in a multi-site implementation is the question of must be closely monitored until the implementa- cutover strategy. The organization must choose tion is completed. The system must be forever between an approach where the implementation monitored and measured [10]. takes place simultaneously in all facilities or a Management and other employees often assume phased approach by module, by product line, or that performance will begin to improve as soon as by plant with a pilot implementation at one fa- the ERP system becomes operational. Instead, cility. With a large outlay of cash up front for because the new system is complex and difficult to software, hardware, and the project team, the master, organizations must be prepared for the company may want a simultaneous implementa- possibility of an initial decline in productivity. As tion in order to recoup its investment as quickly as familiarity with the new system increases, im- possible. provements will occur. Thus, realistic expecta- In a multi-site implementation, a phased ap- tions about performance and time frames must be proach is generally considered to be preferable. clearly communicated [14,21]. This is partly because the success or failure expe- rienced in the first attempt at implementation of- 4.9. Multi-site issues ten decides the fate of the entire project. Thus, the management team can gain momentum by select- Multi-site implementations present special ing a pilot site that has a high likelihood of success. concerns. The manner in which these concerns are And if ERP is installed in a phased approach–– addressed may play a large role in the ultimate module by module, department by department, or success of the ERP implementation. The desired plant by plant––the lessons learned at early sites degree of individual site autonomy may be a crit- can make the implementations at later sites go ical issue which depends on two factors: (1)the smoother [1]. degree of process and product consistency across the remote sites, and (2)the need or desire for centralized control over information, system setup, 5. ERP system selection and usage. One of the objectives of an ERP implementation may be to increase the degree An estimated 50–75% of US firms experience of central control through the implementation of some degree of failure in implementing advanced standardized processes. Alternatively, the imple- manufacturing technology [7]. Since an ERP sys- mentation may be undertaken in order to provide tem, by its very nature, will impose its own logic the remote sites with capabilities that allow them on a companyÕs strategy, organization, and cul- to fine tune their processes to their unique situa- ture, it is imperative that the ERP selection deci- tions. sion be conducted with great care. The greatest Another complexity in dealing with multi-site enterprise system implementation failures seem to implementations is the degree to which the culture occur when the new technologyÕs capabilities and of the organization differs between sites. The needs are mismatched with the organizationÕs ex- fundamental issue here is one of corporate stan- isting business processes and procedures. dardization versus local optimization. Corporate Most enterprises can expect to change or signif- standardization brings with it simplified interfaces icantly upgrade their computer information sys- among diverse parts of the organization, ability to tems at least every five to seven years. With the rapid move people and products between sites with development of new technology, the expansion of minimal disruption, and relative ease in consoli- features and capabilities, and the proliferation of dating data across the entire organization. On the software vendors, there are numerous options for other hand, local optimization may result in more ERP systems. While most ERP packages have 248 E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257 similarities, they also have substantial differences. essary expertise can develop their own systems Most ERP software vendors make assumptions for integration. Developing in-house software can about management philosophy and business offer the freedom to find creative solutions to in- practices. Thus, buying an enterprise application/ tegration problems. For example, in 1996, Dell ERP suite means much more than purchasing Computer Corporation initially planned to roll software––it means buying into the software ven- out SAPÕs full R/3 suite, but it balked because dorÕs view of best practices for many of the com- Dell executives did not believe that the package panyÕs processes. A company that implements could keep up with DellÕs extraordinary corporate ERP must, for the most part, accept the vendorÕs growth. Instead the company designed a flexible assumptions about the company and change ex- architecture to allow the company to add or sub- isting processes and procedures to conform to tract applications quickly and select software from them. Therefore, each organization should try to a variety of vendors [27]. select and implement a system that underscores The importance of the actual software selection its unique competitive strengths, while helping to process must not be underestimated. The current overcome competitive weaknesses [13,14,23]. The literature includes some recommended steps and ultimate goal should be to improve the business, suggestions for the selection process [14,20,21]. not to implement software. Based on the available sources and our own ex- When ERP systems are carefully examined, 80– periences, the authors recommend the following 90% of a particular system will be the same across thirteen-step selection process. different implementations, but 10–20% will be dif- ferent and tailored to the specific needs of the en- 1. Create the vision. Define the corporate mission, terprise [22]. Therefore, the company must identify objectives, and strategy. Use cross-functional its critical business needs and the desired features teams and executive-level input to identify, ex- and characteristics of the selected system. Two amine, and rethink existing business processes. distinct methods can be used for system selection. This helps to ensure the necessary buy-in of One method is to implement some overall business both executive management and the process strategy by focusing on the information technology owners. Clearly define why the ERP system is infrastructure. Some companies, especially large to be implemented. If multiple plants are in- ones, may derive their greatest benefit through the volved, the process must include participants centralization of data and increased control. The from all plants. Once the vision is approved other method is to determine the particular features by top management, broadcast the vision to that are required to run a specific business. So some the entire company. companies, especially small and medium ones, may 2. Create a feature/function list. A team composed opt for software that closely matches the specific of respected individuals who are familiar with functions and processes of their business to more the various software packages, company pro- easily manage the business, increase efficiency of cesses, and the industry should be responsible operations, and reduce costs [12,23]. for identifying the features and functions re- ERP packages are primarily proprietary sys- quired for the software to effectively support tems as opposed to open system architectures. This each functional area as well as the overall com- can limit the flexibility of the enterprise that pany vision. Business unit managers must be adopts a particular ERP package. Approaches to able to document their current business pro- process design depend on the enterprise software cesses to the project team and to map those pro- selected. Standardized processes such as SAP R/3 cesses to the new best practices model from the and PeopleSoft require the adopting firm to adapt ERP application. its processes to the requirements of the software. 3. Create a software candidate list. The field may SQL and Oracle are more accommodating and be narrowed based on criteria such as the size allow firms to tailor the software to existing pro- of the enterprise or industry type. Select only cesses [11]. In addition, companies with the nec- ERP providers that are right for your business. E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257 249
Talk to existing users, particularly those in your 11. Negotiate the contract. The companyÕs negotiat- industry, about what they like and dislike about ing position may be influenced by the analysis their ERP systems. performed in step 10. 4. Narrow the field to four to six serious candidates. 12. Run a pre-implementation pilot. The purpose of This can be accomplished by a preliminary a pre-implementation pilot is to uncover major analysis of the strengths and weaknesses of each surprises, both good and bad, about the soft- supplier and the ‘‘goodness of fit’’ of the soft- ware as quickly as possible so as to facilitate ware. the overall implementation. 5. Create the request for proposal (RFP). The 13. Validate the justification. Using all information RFP typically contains the feature and function collected to this point, make a final go, no-go list, which describes how the company wants decision on the implementation. In extreme each department or function to operate and cases, if necessary, reverse the decision to imple- the ‘‘outer wrapper,’’ consisting of instructions ment ERP, change vendors, or renegotiate the to the supplier, the terms and conditions, sup- contract. plier response forms, and so forth. 6. Review the proposals. Consider strengths, weak- nesses, areas that require more clarification, and 6. Implementation steps areas of doubt for each supplier. Ask for addi- tional information where appropriate. ERP systems can be complex and difficult to 7. Select two or three finalists. implement, but a structured and disciplined ap- 8. Have the finalists demonstrate their packages.In proach can greatly facilitate the implementation. order to provide a thorough critique, all key The authors have compiled a list of 11 recom- members of the selection team should be pre- mended steps for a successful implementation. sent for all demonstrations. These steps have been integrated from several 9. Select the winner. When companies select their works [14,21–23]. system, price is frequently a major factor. But it is critical not to underemphasize other impor- 1. Review the pre-implementation process to date. tant criteria such as supplier support, ease of Make sure the system selection process has been implementation, closeness of fit to the com- satisfactorily completed and all factors critical panyÕs business, flexibility when the companyÕs to implementation success are in place. business changes, technological risk, and value 2. Install and test any new hardware. Before at- (total implemented cost versus total value to tempting to install any software, it is essential the company). to make sure that the hardware is reliable and 10. Justify the investment. Based on the specific is running as expected. ERP software that has been selected, the poten- 3. Install the software and perform the computer tial tangible and intangible benefits of the im- room pilot. A technical support person from plementation can be compared to the costs. the software supplier will often install the soft- Tangible benefits might include better visibility ware and run a few tests to make sure it is in- of future requirements, improved material con- stalled correctly. trol, reduced costs, increased productivity, in- 4. Attend system training. Software training will creased on-time deliveries, improved customer teach users the keystrokes and transactions re- service, and the elimination of redundant and quired to run the system. contradictory data bases. Intangible benefits 5. Train on the conference room pilot. The confer- might include improved communications, sub- ence room pilot exercises the systems and tests stantially reduced chaos and confusion, and the usersÕ understanding of the system. The pro- higher morale. Make a formal go or no-go deci- ject team creates a skeletal business case test en- sion on the software; keep the option of choos- vironment which takes the business processes ing ‘‘none of the above.’’ from the beginning, when a customer order is 250 E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257
received, to the end, when the customer order is Information Week, were poor planning or poor shipped. management (cited by 77%), change in business 6. Establish security and necessary permissions. goals during the project (75%), and lack of busi- Once the training phase is finished, during the ness management support (73%). As a result, most conference room pilot, begin setting the security IT-related projects fall far short of their potential and permissions necessary to ensure that every- payback, and 26% are canceled before completion. one has access to the information they need. Moreover, in many of the completed projects, the 7. Ensure that all data bridges are sufficiently ro- technology is deployed in a vacuum and users bust and the data are sufficiently accurate. The resist it [8]. data brought across from the old system must Langenwalter claims that the percentage of be sufficiently accurate for people to start trust- ERP implementations that can be classified as ing the new system. ‘‘failures’’ ranges from 40% to 60% or higher [14]. 8. Document policies and procedures. The policy Ptak defines failure as an implementation that statement is a statement of what is intended to does not achieve the ROI identified in the project be accomplished; the procedural steps to ac- approval phase and finds that failure rates are in complish that statement may be detailed in a the range of 60–90% [23]. flowchart format. Based on the concepts presented in this paper, 9. Bring the entire organization on-line, either in a the reasons for failure can be placed into 12 cate- total cutover or in a phased approach. In a ‘‘cold gories [7,8,14,19–21,23,31]. These categories ap- turkey’’ approach, the whole company is even- pear in Fig. 2. tually brought onto the new system. The entire company prepares for the cutover date, which would preferably be during a plant shutdown 8. Case study: ERP implementation at Huck of one to two weeks. In a phased approach, International, Inc. modules/products/plants are brought on-line se- quentially. After the first module/product/plant Huck International, Inc., successfully imple- is live, procedures may be refined and adjusted, mented an ERP system during 1998 and 1999. This then the remaining modules/products/plants are case study is a description of their implementation, sequentially implemented. The phased ap- including an indication of the degree to which they proach may allow for improvements to be made adhered to the critical success factors, system se- during the implementation. lection guidelines, and implementation procedures 10. Celebrate. This can be the most important step. described in the first part of this paper. The company has just completed a major pro- ject; the celebration recognizes this and clearly 8.1. Brief history demonstrates the importance of the project to the organization. Huck International, Inc., designs, manufac- 11. Improve continually. The organization can only tures, and distributes a wide range of proprietary absorb a limited amount of change during a fi- commercial, industrial, and aerospace fastening nite time period. Change is an on-going process; systems. At the beginning of the ERP implemen- successful companies understand this and en- tation, Huck was comprised of three aerospace courage their employees to use the system to fastener plants, two industrial fastener plants, one continue to improve. installation tool manufacturing plant, corporate headquarters, and five international sales and distribution sites. Of the international sites, one 7. Why implementations fail also manufactured aerospace fasteners and one manufactured industrial fasteners. Annual sales The top three reasons for the failure of IT-re- were about $250 million. During the implementa- lated projects, as cited by IT managers surveyed by tion, acquisitions and consolidations significantly E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257 251
Fig. 2. Why ERP implementations fail. changed the company structure. The original site had specific modules that were unique to its twelve sites were consolidated to ten, and an ad- business environment. ManMan users were very ditional ten were added through acquisition. Sales familiar with the system and its capabilities. The at the end of the process approached $450 million hardware was extremely stable and software at per year. some sites had not been upgraded for several The legacy system at all Huck North American years. Huck sites in Japan and Australia were on and European sites was CA/ManMan, a classic unique, local systems. mini-computer based MRP II system. ManMan Although the MRP II system was ancient by IT had been in place since 1983 when it replaced standards, Huck had implemented an extensive a homegrown, IBM-based, centralized data pro- local area network. Most users accessed the main cessing system. While some of the smaller sites computer through the network and were familiar operated remotely, most sites had their own with windows-based applications. Network-based HP3000 as the standard hardware platform. The information sharing was widely used by most key system(s)had been upgraded several times, and users. For example, all engineering and manufac- numerous modifications had been installed. While turing drawings, as well as statistical process con- the base software and company modifications were trol data, were accessed through the network. PC administered from company headquarters, each workstations were placed throughout the plant for 252 E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257 easy access to these documents by all shop floor solidation. This was a dual disaster waiting to users. happen. Only the extraordinary dedication, effort, and ability of the implementation team prevented 8.2. A clear understanding of strategic goals (Why a significant failure in both initiatives. ERP for Huck?) 8.4. Project management and multi-site issues Several factors combined to initiate the move to ERP. Y2K incompatibility was a key issue. Mul- The new system was expected to replace all tiple upgrades and recreation of site-specific current ManMan functions. These included all modifications would have been required to become operations, sales, distribution, and accounting. Y2K compliant. The cost in dollars and business Payroll and human resources were not included. disruption would have been significant. Since the Although the capability to consolidate financials base software had not been significantly improved was desired (and a factor in the final selection), in recent years, the expense and effort would each site was set up as an independent financial at best achieve no functional improvement. In entity. The implementation strategy was to de- addition, the business environment was rapidly velop model processes at the primary site (located changing to encourage more intimate business-to- in Texas), and rollout to subsequent sites a frame- business transactions with key customers, and the work on which to build local processes. This old system was not compatible with the newer would provide learning curve benefits as well as systems that were being installed in the customer efficient resource utilization as support personnel base. Future enhancements to the existing system could move from site to site as the timeline rolled were not expected, and Huck did not want to forward. maintain in-house information system resources to As part of the multi-site implementation pro- develop the new capabilities and interfaces that cess, a Project Management Office was established. would be required. This function was charged with communication and coordination of resources. One very effective 8.3. Commitment by top management tool was the establishment of an intranet web site for the consolidation of information. The web site HuckÕs CEO issued a directive that the com- contained such things as telephone directories, pany would move toward a single information travel policies, weekly project update reports from system for all current and future sites. This was all sites, and an issues resolution database. An- strongly supported by top management. However, swers to frequently asked questions and previously during the implementation, a realignment of the solved problems, as well as the current status of in- executive staff somewhat affected the continuity process resolutions, could be easily accessed. The of executive support. But more significantly, the forward transfer of lessons learned from early closing of two sites, the acquisition of ten new implementations to later ones was a major re- sites, and unprecedented record sales so distracted sponsibility of the Project Management Office. top management that appropriate executive level The project was divided into phases. Phase I support was somewhat sporadic and certainly less included implementation of the system at the pri- visible than might have been desired. For example, mary site, corporate HQ, and the international the initial implementation site was designated to locations. The final software selection was made in absorb one of the two consolidation closings. And, March 1998; the anticipated go-live at the primary during the critical implementation ‘‘go-live’’ site was January 1, 1999. All seven phase I sites weekend, some of the implementation team were expected to be live by end of the first quarter members were also required to participate in the of 1999. Due to delays in the justification and physical reorganization of the manufacturing approval process, the project was not started until plant to facilitate the relocation of an additional late June, 1998. Target go-live dates were not ad- 100 workers and machines displaced by the con- justed because of the strong desire to cut over at E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257 253 the end of a financial period. Because of the ac- day interruptions, a smaller team would likely quisitions and consolidations, the scope of phase have been more productive. I ultimately increased to nine implementations. A major responsibility of the project team Phase I was actually completed in July, 1999. was the conference room pilot. A cross-section of products, processes, customers, and various sce- 8.5. Managing change narios were created and tested. Several new pro- cesses were evaluated and accepted or rejected. Long before the ERP implementation was un- One particularly rigorous test was a series of dertaken, Huck had developed a company culture complete order-to-cash process flows, where the that was receptive to change. For several years, the transaction values were manually calculated in company had embraced a program of monthly advance and the system results validated for ac- ‘‘kaizen breakthrough events’’ in the pursuit of curacy and completeness. The conference room lean manufacturing. These events occupy teams–– pilot was one place where the pressures of team composed of six to ten shop floor employees, local membersÕ daily responsibilities adversely impacted and corporate executives, customers, and suppli- the quality of the project. In those functional areas ers––who are charged with the analysis, redesign, that were represented by project team members and implementation of improvements in specific that had sufficient time available to explore alter- business or manufacturing processes. Teams fre- nate process strategies during the conference room quently install, move, or modify equipment, rewrite pilot, significant improvements were generated. procedures, change work assignments, set local But in those functional areas represented by team operations policy, and otherwise make changes as members that had inadequate time to dedicate to required to achieve their designated goals. In ad- the pilot, the typical result was a substandard dition, Huck has numerous self-directed, perma- replication of the old legacy system processes. nent cross-functional teams that are charged with continuous improvement in a variety of areas. 8.7. Data accuracy Huck was well positioned to implement and accept the changes brought about by the ERP imple- Once the pilot was validated, the conversion mentation. process was tested. Moving data is easy. Validat- ing that the data are accurate and complete is ex- 8.6. The implementation team tremely difficult. (One consultant working with Huck confided that, in a previous position as a The implementation team was selected from all user, his companyÕs conversion strategy did not functional disciplines. At the primary site, twelve include a reconciliation of total customer order of the most capable and knowledgeable people line items. Orders were ‘‘lost’’ in conversion and were selected. The expectation was for an average only discovered through customer complaints for commitment of 50% of the teamÕs time for the six- non-delivery.)Huck Õs conversion strategy included month anticipated duration of the project. Al- numerous checks for line counts of sales orders, though the total time estimate was very accurate purchase orders, work orders, and other assorted (actual logged time for the team was 6000 man- categories of dynamic data. hours)the distribution of time required varied Inventory revaluation is a huge concern when greatly. For some team members, a full-time cost accounting systems are changed. In the case of commitment was added to their continuing daily an ERP implementation, this is unavoidable (un- duties and responsibilities. A better approach less the cost accounting process of the legacy sys- would have been to assign six multi-discipline in- tem is somehow duplicated). To avoid any dividuals committed full time to the project. Ad- significant revaluation issues, a process was de- ditional expertise could have been attained as veloped to export real-time data from the con- needed through interviews and temporary assign- verted database and compare the cost variances. ments to the project team. Totally free of day-to- The process was a relatively simple export from 254 E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257 the legacy system of both dynamic and static data 60–70 people were allowed to input data transac- such as on hand balances, standard or average cost tions. Other users were gradually brought on to (Huck used both depending on the item), annual the system. This reduced startup problems from usage, average inventory, and so forth. This data poor training (or poor learning)and made it easier was loaded into a spreadsheet with the projected to track down and correct process errors. For ex- cost as calculated by the new ERP system. From ample, work order operation completions are re- this spreadsheet database, numerous detailed and ported directly into the system by the production summary analyses were conducted. Item-to-item workers. This process takes at most a few minutes costs were sorted by variance, and all major dis- per day for each individual, but is performed by crepancies were resolved. The total inventory re- almost 200 individuals. Until the system was sta- valuation was less than 1%. The process was also bilized, the reporting was logged and batch in- very effective in screening and testing practice runs putted by one work group leader per shift per of the conversion procedures for accuracy and department. Initial classroom training of the key completeness. users (not including the project team)took about Stress tests were conducted on the system as 1200 hours. Most training was conducted during soon as a converted database was available. The the month before the go-live date. Several training project team simulated full business operations by rooms were created for this purpose, and concur- initiating multiple processes and performing sys- rent sessions were not unusual. tem-intense procedures while simultaneously run- An unexpected training issue surfaced that af- ning CPU-intense utilities. Although no system fected several different functions. The implemen- problems were discovered during these tests, a tation team focused on training users in areas major system response issue arose at cutover. The where the processes had changed. Those users quality management module, which had worked needed specific instruction detailing how to use the flawlessly in the pilot, displayed response times of new system to perform their daily tasks. However, several minutes. This subsystem dictated that no some business processes were not affected by the inventory moves or transactions could occur until new system. When resolving cutover issues, the quality assurance had ‘‘signed off’’ on the trans- team found some users who, since they had not action. The slow response time totally froze oper- been shown a new way to do something, just ations! Because of the extreme urgency of avoiding stopped doing it! This became known as the a complete business shutdown, there was no time ‘‘hanging your brain on a nail syndrome.’’ To to properly investigate and resolve the underlying avoid this problem, the implementation team problems. To avert disaster, the entire subsystem should have compiled and distributed a list of was uninstalled item by item and order by order. processes that were not changing and needed to be continued as usual. 8.8. Education and training 8.9. Focused performance measures Education and training were conducted by the implementation team. Step-by-step instructions Huck utilizes a number of highly focused per- were created during the pilot. The instructions formance and incentive-based measures, includ- included detailed screen shots with valid company ing a profit sharing program. The profit share of data in all fields. These were imported to Word middle managers is typically based on the achieve- documents, which included instructions and writ- ment of negotiated MBO type goals. When the ten procedures. Training materials were available ERP implementation project began, the involved in hard copy for classroom and individual training middle managersÕ objectives were changed to the and could also be accessed on the project website. single goal of successful system implementation. The training strategy was to concentrate first on Additional specific performance measures were de- key users, work group leaders, and supervisors. veloped to measure and motivate the entire work During the first few weeks of the new system, only force during the implementation, even as previous E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257 255 goals and objectives were maintained. The expec- straints, it was not even considered. Moreover, the tation was that the increased efficiency due to the diligent checking of references for first-hand feed- new system would more than offset implementa- back of system performance in real-life situations tion costs. was not adequately pursued. The resulting lack of information led to a major surprise. Huck fully 8.10. System selection process expected its new ERP system to have a fully inte- grated, finite production planning and scheduling The system selection process generally followed system. In fact, having a fully integrated system the 13 steps described earlier in this article. After had been a key decision factor in the selection analyzing the financial and strategic viability, as process. But, three months before the targeted well as the geographic support capability of all ‘‘go-live’’ date, the project team learned that Huck major software providers, a request for quote was would be a beta test site for the integration inter- prepared and sent to the 13 qualifying suppliers. face programming. The integration did not yet Nine responded with formal proposals. The pro- exist! Performing a pre-implementation pilot and posals included detailed documentation and man- diligently checking references would have uncov- uals describing the products, functionality, and ered this fact early on (although it probably would implementation cases. A select team of IS and op- not have changed the software decision). But a erations personnel from various Huck sites and a major surprise would have been avoided, and the representative from HuckÕs parent company met for promised and expected benefits would have more a week to review the proposals. Based on the pro- easily flowed from the implementation. posals and some additional solicited information, a short list of suppliers was selected for a com- 8.11. A post-implementation audit plete product demonstration. Two software vendors (SAP and Baan)were selected for the final review. A post-implementation audit was conducted The demonstration and final selection process during the spring of 2000, ten months after the was a marathon, six-day event. The selection team ‘‘go-live’’ date. The objective was to determine was composed of 31 people representing all disci- what areas needed additional assistance in order to plines and locations that would be implementing the more effectively utilize the Baan system. The audit software. Included on the team were internal audi- was based on intensive interviews with 51 man- tors from the parent company. Each supplier pro- agers, supervisors, and key employees across 11 vided a two-and-a-half day demonstration of the different functional areas. A specially designed software. On the sixth day, the selection team met to survey questionnaire was used in all interviews. compare notes, review strengths and weaknesses, The interviewees were asked to give both objective and finally achieve consensus on the best soft- and subjective responses to a series of questions ware package. The option to select neither supplier covering various aspects of the ERP system and was always kept open. Ultimately, consensus was the implementation process. The interviews were reached, and Baan software was selected. conducted by a very capable university intern who The justification criteria demanded by the CEO had no previous knowledge or biases about the was that only hard dollars in savings or profit from operation of the company. increased revenue could be used to support the The analysis of the survey responses revealed a decision. The final justification relied on profit from number of interesting results. increased sales through enhanced capabilities, re- duced cost of system maintenance, and labor effi- • The majority of employees felt that the imple- ciency (reduced head count for a given level of mentation process was not over. The general be- business activity). lief was that there was still much to learn about There was a major shortcoming in HuckÕs how to use the Baan system. software selection process. A pre-implementation • Effective communications was a major issue pilot was not performed. Because of time con- throughout the plant. Most employees felt that 256 E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257
the Baan system has great potential, but many benefit side, there is evidence that labor savings found it necessary, or convenient, to go around and increased profitability have been achieved the system. This caused a ‘‘domino effect’’ of subsequent to the implementation. For example, poor information flows throughout the entire the justification process, conducted in early 1998, company. A number of employees recommen- required a reduction in head count at the pri- ded stricter controls and discipline for employ- mary site of eight to ten people (for the same level ees that do not use the system correctly. of business activity). The reduction was to be • Additional training was commonly identified achieved six months to a year after implementa- as a significant need across the organization. tion. Meanwhile, a labor-intense business unit was While the pre-implementation and cutover train- consolidated into the facility during the imple- ing appears to have been adequate, significantly mentation. Consequently, transaction levels in the more post-implementation training should have core business used to justify the implementation been conducted. A common complaint was that increased by 48%. All things remaining equal, with the process of finding needed information was the old MRP II system, approximately 22 new too time consuming. As a result, many users people would have been added in the targeted had developed numerous effective, but often in- functions to address the new business volume. efficient, ‘‘workarounds’’ for problems they en- With the ERP system, staffing of these functions countered. Another common complaint was grew by only 14 individuals. The net difference of ‘‘the system will not do that’’ which usually negative eight satisfies the justification require- translates to ‘‘I do not know how to do that ment. One year after implementation, the primary within the system.’’ site has seen sales revenue increase by 22%. • Despite the fact that the majority of the employ- However, the anticipated increase in revenues that ees stated that they were comfortable with their should result from greater compatibility and knowledge of the new system, the most frequent communication with customers and more open suggestion for improvement within their func- systems has not yet been achieved. tional area was additional training. A significant and somewhat unexpected im- provement was in the area of inventory control. Spurred by the survey results, tighter system The finished goods warehouse was converted from controls have been established. More importantly, zone storage to assigned, random storage using widespread additional training was initiated. standard features of the new system. By utilizing system rules for lot/location control, the ware- 8.12. Implementation success? house space requirement was reduced by 40%. Inventory accuracy increased from 94.5% to An ERP implementation is considered to be a 98.8%. The improved accuracy would be aston- success if it achieves a substantial proportion of ishing even if the error tolerance remained un- its potential benefits [7,21]. These benefits might changed, but in fact, the current tolerance is much include personnel reductions, a decrease in the stricter than that used in the past. Previously, a cost of information technology, better inventory cycle count was considered ‘‘bad’’ if the error was control, and an improvement in order and cash greater than 0.5% of six months usage. The current management. An alternate definition of imple- standard is that the cycle count is ‘‘bad’’ if there is mentation success is that the system achieves the any variance, in any location, or any lot number. level of ROI identified in the project approval The accuracy level is 99.6% in locations that are phase [23]. Thus, an ERP implementation should wholly under control of the warehouse system. be evaluated based on cost of ownership versus The non-financial improvements are probably quantifiable benefits, taking into account the time the most significant. The company is now posi- required to implement the system. tioned to continue to grow and to pursue new At Huck, to date, ERP implementation costs partnership opportunities that would not have have exceeded $10 million system-wide. On the been possible using the old information system E.J. Umble et al. / European Journal of Operational Research 146 (2003) 241–257 257 technology. The company has survived imple- [17] C. Loizos, ERP: Is it the ultimate software solution, mentation, consolidation, and record growth. Industry Week 7 (1998)33. [18] K. Maxwell, Executive study assesses current state of Now it can develop new strategies and techniques ERP in paper industry, Pulp and Paper 73 (10)(1999) to manage the business with a powerful and, as 39–43. yet, relatively underutilized tool. [19] D. McCaskey, M. Okrent, Catching the ERP second wave, APICS––The Performance Advantage (December)(1999) 34–38. References [20] T. Minahan, Enterprise resource planning, Purchasing 16 (1998)112–117. [1] D. Allen, Multisite implementation: Special strategies, [21] H. Oden, G. Langenwalter, R. Lucier, Handbook of APICS 1997 International Conference Proceedings, Falls Material and Capacity Requirements Planning, McGraw- Church, VA, 1997, pp. 551–555. Hill, New York, 1993. [2] A. Angerosa, The future looks bright for ERP, APICS–– [22] C. Ptak, ERP implementation––surefire steps to success, The Performance Advantage (October)(1999)5–6. ERP World Proceedings, August 1999, Downloadable [3] G. Buchanan, P. Daunais, C. Micelli, Enterprise resource from website: