trainning erp

Training: Key to Effective Enterprise Resource Planning Implementation

Prepared for:

Mr. John Meinke

INSS - 690

University of Maryland – Europe

By John [email protected]

March 9, 2002

Training: Key to ERP 2


Abstract

The power and potential of Enterprise Resource Planning systems often gounrealized, due to implementations that do not prepare users for the processchanges that these systems entail. Sources indicate that improper training isoften to blame for these failed implementations. A comprehensive trainingstrategy, therefore, is key to the effectiveness of an ERP implementation. AnERP education / training plan is proposed, addressing training needs on thebasis of who needs training, when it is needed, and what topics should bepresented.


1 The term training, as used in this discussion, includes all forms of education,change management, knowledge management (including documentation,briefings, etc.), and training.


Introduction

The acceleration of information is a sword that cuts both ways. Customers, spoiled bythe speedy response they get on the Internet, now expect instant gratificationeverywhere. They demand higher standards of service, and lower prices. Forcompanies serving these customers, the competition has become more agile than ever. In today’s virtual marketplace, companies can shop the globe for cheaper, moreresponsive suppliers with the same ease that customers can shop around for best values. The same high-speed information that increases benefits to customers also increases thestress of competition among companies serving customers.

Today, the speed at which information is delivered is just as important as the quality ofthe information itself. Unless companies can strengthen their ability to processinformation more efficiently and more effectively, they risk being squeezed out bycompanies that can. To improve their efficiency and their effectiveness, manycompanies are turning to Enterprise Resource Planning (ERP).

With ERP, a company can improve both the quality and speed of the information used inmanaging its operations. An ERP system has such awesome power, in fact, that one CIOlikens it to a jet fighter (Schneider, March 1, 1999).

However powerful ERP might be, it is not a magic cure. An ERP system places heavydemands on a company that installs one. To benefit at all, the company must undergo athorough metamorphosis. A comprehensive training1 strategy, therefore, is key to theeffectiveness of an ERP implementation.

This paper will describe the nature of ERP systems, and problems encountered duringtheir implementation. It will then explore ways that companies can use trainingprograms to increase the likelihood of success.


Manufacturing Background

Using techniques such as standardized parts and specialized tasks, manufacturers as farback as the Industrial Revolution sought to produce goods as cheaply and efficiently aspossible. Driven by profits, the captains of industry divided work into separatefunctions, so that each worker could do what he did best. By decentralizing tasksbetween line and management, and realizing economies of scale, manufacturers gainedmany benefits, including better managerial control, better use of facilities and materials,faster production, better quality, and more creativity. Seeking ever greater competitiveadvantage, many manufacturers decentralized their operations further by movingfactories overseas, to countries with cheaper labor costs.

To increase competitive advantage, domestic American manufacturers introducedcomputer applications, such as Materials Requirements Planning (MRP), in the 1970s. With MRP, manufacturers could better manage the planning and scheduling of materialsupplies, as well as the control of inventories. During the 1970s and early 1980s, moresophisticated algorithms for controlling manufacturing functions continued to emerge. Materials Requirements Planning evolved into Materials Requirements Planning II(MRP II) and Business Requirements Planning (BRP). However, the manufacturingbenefits gained by specialization and decentralization eventually reached a limit, evenwith the help of software.

Business Automation

At the same time that specialized software was increasing the efficiency of factories,computer applications were appearing in all areas of business. Initially, computerapplications were mainframe-based and found in only larger organizations.

The advent of the personal computer (PC) brought computing power to the desktops ofworkers in virtually all organizations, large and small. Using a range of PC-basedoffice suites, workers could independently generate documents, spreadsheets and smalldatabases to communicate and process information related to their specific businessfunctions. Many stand-alone legacy programs, written as mainframe or PC applicationsduring the mid-1980s to the 1990s, are still in use.

During the 1990s, local area networks (LANs) became increasingly more common onthe business landscape. As companies attempted to use this technology to shareinformation among internal functions, they soon discovered that, instead of havingsystems that could communicate information between departments, they had “silos” or“stovepipes.” Stovepipe systems were capable of providing internal departmentalsolutions, and carrying information from a given source to a few narrowly-defined


destinations – but nowhere else. Because businesses (and individual departments withinthese businesses) were moving toward automation at different speeds and not always inthe same direction, achieving connectivity has been an undeniable challenge.

Another aspect of this challenge was the way data was treated. Typically, eachdepartment had unique information requirements, some overlapping those of otherdepartments. For example, only some details of a customer order would be of interest toboth the Sales department and the Accounting department. Many customer detailswould be of no interest to Accounting. Likewise, many billing and payment detailsmight not interest Sales.

Each department typically entered data independent of other departments, and kept onlyinformation pertinent to its function. Independent entry by individual departmentsresulted in data redundancies, inconsistent data format (e.g., Robert Smith vs. R. Smithvs. Smith, Robert), and data entry errors.

Information was stored in paper form, on databases, or both. Therefore, whentransferring data from one department to another, additional errors could easily beintroduced. By putting data in motion, the data itself became a moving target. It wasnot clear which location held the most recently updated version of a piece of data. Reports to management often reflected “different versions of the truth.”

As company departments became more interconnected, they learned about “islands ofinformation” and other problems inherent with “stovepipe” information systems. Efforts to interconnect stand-alone systems (with each department entering dataindependently and each department using its own proprietary data formats) consumedenormous amounts of company resources, in terms of time and effort. Clearly,decentralized information systems had reached a limit.

Enterprise Resource Planning Systems

Within the last 20 years, managing a diversified company has become a greaterchallenge, especially as companies have expanded across product lines and acrossglobal borders. A narrow focus did not always serve decision makers, who demandedan enterprise-wide view of their companies. Growing out of the development of MRP IIand integrated databases, manufacturers (and later all variety of organizations) soughtthe means to combine information used by an organization’s many departments anddiverse functions into an integrated computing system. ERP systems were developed tofulfill this need.


The goal of ERP is to manage information across all functions of an enterprise, suchas inventory, purchase orders, customer data, and employee records, using a commondatabase (instead of isolated departmental databases). Centralization, using a singlenetworked database, made data available to all departments. The unifying features ofERP provide an enterprise with many benefits. For example, the manufacturer of abuild-to-order product (such as personal computers), using an ERP to processtransactional data on a central database, can:

• receive a customer order;• process the credit card payment through the company bank;• notify the manufacturing department to build the computer;• track the delivery of the finished computer to the customer;• order computer components to replenish inventories;• receive and add supplies into inventory;• order payment of supplies when received;• track customer preferences for future marketing campaigns; and• manage employee hiring, payroll and benefits.

Because a common database holds and supplies data for all processes companywide, itis not necessary for each department to reenter data. Data consistency is realized bykeeping each data element in only one format. Because only one version of the data iskept, there is no concern over which version is the most recent. Transactionalprocessing and cross-functional data sharing happen faster, with fewer errors. Finally,because the company’s business processes are unified and automated, better-informedoperational decisions can be made, real-time, throughout the entire enterprise.

ERP systems offer companies many possibilities for increasing profits and improvingcompetitive advantage:

• Sales and manufacturing levels can be increased due to more efficientutilization of existing facilities and staff.

• Production can be coordinated among multiple plant locations.• Products get to customers faster, thanks to fewer mistakes and delays.

Information and products can be moved through the global supply chain inhours and days, instead of weeks and months.

• Deliveries can be made sooner, faster, and in the most cost-efficientmanner.

• Inventories of both supplies and finished products can be kept smaller andmore up-to-date. (One company improved its inventory accuracy from 50-60 percent to nearly 100 percent. (Blanchard, Spring, 1998).)

• Quality problems can be backtracked to time and place of manufacture.


• Customer purchase trends can be gathered and analyzed.• Operating costs can be reduced, thanks to more efficient inventory

management and greater worker productivity.• Cyclical manpower requirements can be better anticipated and managed.

Build, Buy or Remodel

When considering the choice of an appropriate ERP system, companies are faced withthe decision of whether it is better to build a custom system, tailored to meet the uniquerequirements of the company, or to purchase an off-the-shelf product. The advantage ofgoing with one of the leading ERP providers is the ability to capitalize on the insightand experience gained from a large number of implementations, in a variety ofindustries. Most major ERP vendors have developed various sets of industry-specifictemplates that permit pre-configuration, following the best practices of each industry.

Proponents of custom-tailored ERP solutions argue that generic templates are less ableto meet the unique requirements of an individual company. Certainly the uniqueness ofan established company is demonstrated by its intertwined business processes andsmokestack systems that have evolved over the years. It would be tempting to leave thecompany’s old structures intact, and use custom-written software to link the variousexisting systems together into a functioning whole. As will be discussed, this approachdoes not fully capitalize on the benefits possible from a carefully orchestrated ERPimplementation.

Another customization alternative is to start with an off-the-shelf ERP product, and adddesired special features by rewriting portions of the code. The extra effort to re-engineer a sophisticated ERP package is great indeed. In fact, the cost of re-programming can easily exceed that of the original ERP product, often by a widemargin. Other disadvantages of this approach are that modified, off-the-shelf ERPsystems are slower, more bug-prone and costlier to implement (after the coding changesare completed) than similar products whose code has not been tampered with.

However appealing the case for custom-written or modified ERP software may be, theERP trend is for unmodified off-the-shelf packages. Used without modifications to theunderlying code, these packages still offer companies great flexibility to match theirspecific requirements, through an extensive range of configuration variables.

The major providers of ERP systems include SAP (Germany), Oracle, PeopleSoft,J.D. Edwards, and Baan (founded as a Dutch company, now part of Invensys). Originally providing modules for only discrete manufacturing operations (involvingcountable items), ERP vendors now supply industry-specific applications, including


systems for process operations (for things that flow; e.g., oil and gas, chemicals andutilities), and for financial services, consumer goods, and health care.

Initially, ERP software was installed mostly on mainframe computers, as centralizedapplications or deployed on limited networks. The most famous example of early ERPsoftware is SAP’s R/2. This was followed by SAP R/3, an example of Windows-based,scalable, client-server architecture that greatly increased the popularity of ERP systems. IT decision makers appreciate these systems for their platform- and operating-system-independence, and their network- and multi-language capabilities. Although users maynot appreciate the technicalities of their Java™ and HTML-based graphical userinterfaces (GUIs), users do find them more user-friendly than their predecessors. Without compromising data integrity or without disrupting operations, client-serverERP systems are capable of transferring data via LANs, the Internet or across SupplyChain networks. The implementation of client-server ERP systems does, however,require a great deal of special attention.

Front Office / Back Office

Sold by approximately 1,000 global vendors, ERP software provides back officecapabilities to manage such enterprise functions as projects, manufacturing, accountingand finance, and human resources. Complementing ERP software are new entrants to the integration software marketplace. These customer-facing software products, using the Internet, serves such front officefunctions as:

• Customer Relationship Management (CRM) – Manages customer datagathered from variety of sources (personal contacts of the sales force,point-of-sale (POS) operations, call centers and e-mail) and generates acomprehensive view of customer data and behavior. CRM enablescompanies to provide truly personalized and consistent customer service(set to a configurable standard).

• Sales Force Automation (SFA) – Supports the sales function (in bothsales office and the field) through a range of services from appointmentscheduling to contact management and qualification.

• Supply Chain Management (SCM) – Automates the supply chain: frommaintaining supplies of raw materials, to coordination of manufacturingand inventory, and to shipment of products to customers.


These front office packages, first emerging as Best of Breed products (concentrating ononly one element of the value chain), were deployed either as stand-alone applicationsor were integrated with existing ERP systems. Best of Breed packages are initiallysmaller, less complex, and cheaper than ERP products, and tend to be updated morefrequently. Over time, these niche applications have begun to broaden the scope of theircapabilities, taking on some of the back office integration power of their far larger ERPcousins.

Facing stiff competition from Best of Breed front office products, ERP vendors havebeen answering with their own web-enabled ERP products, which possess customer-facing capabilities. (SAP’s mySAP.com is an example of the latest so-called ERP IIrange of products.) Customers in the market for an electronic commerce application canselect from either Best of Breed products or ERP vendor products. While the formermay have greater overall functionality for a specific application, the latter will providefewer problems during integration with a customer’s main ERP system.

In addition to front office integration software, other data-enhancing applications arealso available, either as individual modules (of larger integration software packages) oras Best of Breed add-ons. These applications, all with integration issues similar tothose mentioned above, include:

• Data Warehousing / Data Mining – Software with the ability to collect,dimension, correlate, analyze and extract data, which has been collectedfrom internal and external databases.

• Business Intelligence (BI) – Uses decision-support techniques to drawinsights from hierarchies of disparate data and information. The resultshelp enterprises capitalize on opportunities, or to deal with managementchallenges.

• Knowledge Management (KM) – Promotes management of enterpriseknowledge, by extracting insights and business intelligence from existinginformation sources.

• Work Flow – Work flow programs contribute to the efficient operation ofintegrated systems through the orchestration of dynamic batchprocessing. Work flow sensors can be embedded in processes todetermine the optimal time and location to perform specific tasks based ondata flow.

• Middleware – This software resides in the layers between ERP and add-onsoftware packages, and facilitates linking these applications together.

Cost of ERP


ERP implementations are notorious for their cost, but the cost of the software itself isonly the beginning. The cost of other items must be taken into consideration whenmaking the decision to implement an ERP system. These cost items include:

• Planning – Preparing for an ERP deployment is costly. Planners mustdevote sufficient time and effort to fully develop the scope, costs, andimplementation time line of an ERP project.

• Consulting Fees – Because of the vastness of these projects, it is likelythat the demands of an ERP implementation will exceed the capabilities ofthe personnel of the company introducing the system. Consultants, eitherfrom the ERP vendor itself or from a third party firm with expertise in theselected package, may be hired to assist with the implementation. Consulting fees, which will constitute a large percentage of the ERPimplementation budget, must be anticipated and planned for in advance.

• Training (and Change Management) – This is the most elusive item, andis nearly always underestimated. ERP-related training is so expensivebecause nearly every employee must learn not only a new softwareinterface, but also an entirely new set of business processes which affectthe operation of the entire enterprise. Furthermore, the corporate culturewill be impacted by changes in the company’s business processes. Specialattention must be given to both training and change management efforts.

• Testing – This is another expense item that is often underestimated. Because a company’s ERP system ranks at the top of mission criticalsystems, it should be fully tested before going live. Each ERP system isdifferent, and every company has its own set of aging – and incompatible– legacy programs (and desired add-on programs) that need testing as partof the final integrated system. If the ERP implementation requires muchcustom coding, testing costs will increase dramatically. Testing should beperformed (under expert supervision) by the people who will operate theprocesses on a day-to-day basis.

• Data conversion – Real world data is rarely without problems. Forexample, legacy system data may be difficult – if not impossible – toconvert to the format of the new ERP system. The complexity of cleaningand analyzing data from multiple (internal and external) systems increasescosts further still. Management must decide whether the value of the datajustifies the cost of cleaning or re-entry.

• Documentation – An ERP project takes a long time to implement, but itsusable lifetime will be longer still. It is a safe bet that the ERP systemwill outlast the tenure of the IT employees and business-process managerswho design, implement, and maintain it. It is critical, therefore, todocument problems, questions and doubts that arise at every phase of theproject. This will aid those project team members joining the


implementation process midway through the process, as well as employeesjoining the company after the implementation has been completed. Although it adds to the cost of the project, quality documentation pays foritself when problems occur.

• Replacing staff joining the project team – According to commonwisdom, the better the caliber of staff (both IT and business) assigned aproject team, the greater the likelihood of the project’s success. Giventhe huge demands of an ERP implementation, it is likely that theseemployees will continue in ERP-related roles long after the ERP systemgoes live, instead of returning to their former jobs. This means thecompany must budget for the additional recruiting and salary costs toreplace the project staff in order to keep the company’s operationsworking during and after the implementation. (This raises a conundrumfor the company: If it moves its best staff to the project, the project willhave the best chance for success, but current operations will suffer. Onthe other hand, if the company unloads its “second string” workers to theproject, operations will continue to do well, but the success of the ERPproject will be imperilled.)

• Psychological costs – It is human nature that people resist change. Due tothe extra demands placed on the entire enterprise during the ERPimplementation, project team members are not likely to enjoy muchpopularity among other employees. In fact, team members may receive noappreciation at all for their valiant efforts and long hours, even frommanagement, until the project is a demonstrated success. While theirimplementation experience increases their market value to headhunters,lack of appreciation may cause members of the ERP implementation teamto “jump ship” once the system goes live. Unfortunately, many companiesplace a dollar value on these psychological costs only when it becomesnecessary to replace an essential employee.

• Performance drop – The operating performance of a company typicallydrops once an ERP system goes live. This is the stage of the project whenthe pressure to perform is greatest, the learning curve is the steepest, andthe company is most fully committed to the system working correctly. Itcan take months for the company to recover to pre-implementationperformance levels, and the cost of this lost performance should beconsidered.

All items listed above contribute to the total cost of an ERP implementation, and helpexplain why software costs represent only 10-33 percent of a typical ERP project(Slater, 1998).


Little public information is available about the true cost of ERP implementations orabout the benefits realized from these projects. To determine the Total Cost ofOwnership (TCO) of ERP packages, the Meta Group surveyed 63 companies (Koch,Slater and Baatz, 1999). Each company was asked how much it spent during the courseof installing its ERP system, and for a period of two years afterward. TCO included allhardware, software, professional services, and internal staff costs, as well as the cost ofoptimizing, maintaining, and upgrading the system. ERP investments ranged from a lowof $400,000 to a high of $300 million. The average TCO was $15 million, or $53,320on a per capita basis. The average implementation took 23 months, and required anadditional eight months before benefits of any kind were realized. Once ERP savingsbegan to flow, the median annual savings averaged $1.6 million per year.

To justify such large-scale investments on ERP tools, decision makers must be willingto look “way out into the future.” Says integration expert Slater (January 15, 2002),“The only thing more expensive is not using these tools ...” Of course, the return oninvestment (ROI) for an ERP project depends not only on the a company’s choice ofsoftware and the implementation, but also on the current economic conditions.

ERP Implementation Failures

In pre-ERP times, companies could insulate themselves from system failures in thewarehouse, for example, by having surplus inventories. With today’s tight inventoriesand just-in-time supply, such surpluses do not exist anymore. Companies want theiroperations to run like clockwork and invest heavily in ERP to make it happen. With somuch being spent on ERP initiatives, it is natural for expectations to run high.

During the course of implementing ERP projects, the usual difficulties are encountered. Like other IT projects, ERP implementations finish over budget or behind schedule. However, what has been most notable about implementations of ERP systems is theiralarmingly high rate of failure.

Hershey, the Pennsylvania-based chocolate maker, suffered severe losses in 1999 as theresult of a failed $115 million ERP implementation, which lasted three years andinvolved four separate consulting teams. Plagued with problems, the project fell behindschedule, and was rolled out during the lead up to Halloween and Christmas. According to Osterland (2000), Hershey simultaneously implemented all modules of anenormously complex ERP system from SAP, plus an add-on CRM package from Siebel,plus a logistics package from Manugistics. Hershey made the unfortunate choice ofpressing on with the roll-out at the busiest time of the year for a candy maker, the timewhen any hiccup in the system would have the greatest negative impact. When the


system went live, things went badly. Sales were lost, inventories piled up, and thecompany’s annual profits fell 19 percent.

Other major companies suffering similar – though less serious – ERP implementationdisappointments, included Whirlpool, Dow Chemical, Boeing, Dell Computer, AppleComputer, Allied Waste Management (Osterland, 2000), and Volkswagen (Stedman,2002). According to Madden (1998), FoxMeyer Drug Company claims that theaftershocks of its ERP system installation were so bad, that it was forced to file forChapter 7 bankruptcy.

Not all ERP implementations make the headlines as did those of the companies above. However, many companies do receive a nasty surprise upon going live. In a survey of886 IS managers, nearly 25 percent reported significant losses resulting from ERPsystem outages. These outages averaged 2.8 hours per week, and averaged $35,950 perhour in lost business and productivity (Dryden, 1998).

Causes of ERP Failures

One source of ERP system failures is poor or inappropriate project design. Accordingto Donovan (There is No Magic in ERP Software, n.d.), ERP software is often used tobandage over business process flaws, without addressing them. It is easier to purchasenew software than to do the necessary organizational self-examination to identify weak,ineffective business methods. If all a company does is to add new technology to an oldprocess, what it ends up with is an expensive old process (Scott, 2000). According toRockford Consulting Group (1999), this failure – to examine underlying businessprocess flaws and to develop a comprehensive, systematically defined set of functionalrequirements for the proposed system – accounts for nearly 60 percent of all ERPfailures.

Related to this, is the poor selection of off-the-shelf ERP packages. Trying to expeditethe decision process, top management sometimes will choose an ERP product withoutinvolving IT or business unit workers. A vendor is called in, and a decision may bereached before someone with the necessary technical or process knowledge is asked to“run the screens” to compare the chosen ERP product’s capabilities with what thecompany really needs. In some cases, executives had ERP experience with previousemployers, and assumed that what had worked in earlier situations would work again.

Rockford Consulting Group (1999) cites ill-advised cost cutting as another reason whyERP projects fail. In an effort to trim expenses on obviously very high-priced projects,some companies ask workers to work overtime, performing a double duty load. Doing


both their regular jobs and serving as project team members, these workers not only loseenthusiasm for the project, but just plain burn out mid-project.

Sheer size and complexity of the undertaking is another important reason why ERPimplementations can fail. ERP implementations can involve company-wide changes insoftware, hardware, and networking, as well as a re-engineering of business processesthat touch all functional areas. ERP systems are huge; and they operate at the very coreof and throughout the enterprise, controlling every mission-critical system. Theseprojects are often not accorded the respect they deserve, because management,especially at the C-level (CEO, CFO, CIO, etc.), does not appreciate the far-reachingpower that ERP systems can wield in an organization.

Another cause for ERP failure is the lack of a change management approach whendealing with core project issues. Preoccupied with implementing a project, topmanagement may fail to notice or appreciate the degree to which workers are resistantto the new system. If management neglects to demonstrate enthusiastic commitmentand visible support for the new ERP system, or to build a solid case for the comingchanges that will affect most (if not all) workers, the company runs the risk ofundermining the project’s success. The company can best manage the groundswell ofchange by involving the ultimate users, as well as all levels of management, in theplanning and implementation of the system.

Poor communication among team members can cause problems in an ERPimplementation, for example, when doing business process re-engineering (BPR),testing and other important implementation functions. As the result of an erroneousassumption by a CIO or project leader that some departments may not be impacted bya particular process, the ideas and concerns of entire departments could go unheard. Such oversights cause resentment and apathy toward the project, and the quality of theproject may suffer (Varon, 2000).

“Assumptions” can also lead to failed ERP projects. Perhaps the programmers andvendors of software programs should be forgiven for assuming that users will appreciatetheir works for their “obvious” inherent qualities, but unfortunately, the real world isdifferent. Users need to see the benefit of embracing a new practice or a new piece ofsoftware. According to Oracle’s Niemann (personal communication, Germany,February 22, 2002) training was usually an afterthought as many vendors implementedERP systems in the mid-1990s. Vendors relied nearly exclusively on partner consultingfirms to interface with customers, assuming that their expertise alone would carry theday. Not much thought was given to the vast adjustments that users would have to makein the way they did their jobs. Not much thought was given to building a “bridge ofunderstanding” from the old ways to the new.


Example of Successful ERP Implementation

Complex ERP implementations are not impossible, states Osterland (2000). They justrequire a tremendous amount of planning and coordination, and a stubborn adherence tobasics. For example, Amoco Corp. (now BP Amoco) successfully deployed ERP in all17 of its business groups, over the course of four years and five implementation sub-projects. What sets Amoco’s success apart from many of the failed implementations isthat Amoco gave itself sufficient time to adequately plan and make the transition. Furthermore, Amoco installed ERP modules from only one vendor (SAP) during theimplementation.

The Essence of ERP

The concept of ERP is built on standards and consistency. Processes must handle datain a consistent manner; data must be input, stored and output in a consistent manner. While the standards established may not represent the optimal method for eachdepartment to function individually, the standards represent a “best fit” for theenterprise to function as a whole.

A spirit of cooperation and compromise lies at the heart of reaching that agreement (onwhich standards best satisfy the needs of the enterprise). While a company may seem“confined” by its adopted ERP standards, its integration system must also includesufficient scalability to support the company as it grows and follows its strategic“vision.”

Over the course of thousands of implementations, vendors of ERP products haveaccumulated a great deal of experience (read, problem-solving skills). For each vendor,this accrued experience has inspired a growing array of “best practices” which areroutinely included in updated versions of their ERP product. On the one hand,customers benefit from the accumulated knowledge – even wisdom – of all theimplementations that have gone before. On the other hand, customers may feel that, byconfiguring their systems according to these now-widely-known best practices, theirsystems will be the same as other companies in their industry; i.e. “just average.” Thisis the paradoxical nature of ERP: a balance between standards and scalability.

Training for ERP

According to Koch, et al. (1999), a successful ERP implementation requires that acompany changes the way it does business, and that workers must change the ways they


do their jobs. Nothing short of a complete metamorphosis is required, and this kind ofchange will not occur without pain. According to Davenport (2000), it is almosttyrannical the way enterprise applications force companies to integrate their informationand processes. He adds, however, that it is worth the effort to have key information inthe same format throughout the business, and to have key processes performed in aconsistent fashion.

Growing Awareness of the Need for Training

Between the years 1998 and 2000, the total ERP budget spent on training grew from fivepercent to 11 percent (Wheatley, 2000). By June of 2001, the Gartner Group wasrecommending that companies devote a minimum of 17 percent of their ERP budget totraining. This Gartner recommendation also asserts that companies spending less than13 percent of the implementation budget on training are three times more likely to bringtheir projects in over time or over budget than those companies that exceed the 17percent figure (Heske, 2001).

In accordance with these recommendations, training (before and throughout the project)is a must for keeping ERP implementations on the right track. Even after projects havebecome derailed, training is seen as a key ingredient in the salvage operation. Wilderand Davis (1998) report that when ERP turn-around experts are called in to rescue faileddeployments, additional training and efforts are typically employed to secure user andmanagement buy-in.

Even companies with their expensive ERP systems up and running would do thingsdifferently in a subsequent implementation. For example, Klein described a PeopleSoftuser seminar at which company representatives were asked if they would treat thetraining component any differently if they were to implement another ERP project. Seventy-five percent said that next time their companies would devote more time totraining, and that it would focus more closely on the company’s business processes(Wheatley, 2000).

Three Dimensions of ERP Training

People must know the “who, what, when, where and why” of their new ERP system inorder for it to be effective (Donovan, There is No Magic in ERP Software, n.d.). Therefore, at each stage of the implementation, training plays a key role in helping thecompany succeed in its ERP efforts. At each stage of the project, different kinds oftraining need to be given to different levels of employees. This relationship isillustrated in Three Dimensions of ERP Training (Figure 1).


WHEN

WHO

WHAT

Executives / ESC

Project Team

Process Owners

Power Users

Users / Supply Chain

Pre

- Sal

es

Plan

ning

/ D

esig

n

Build

(pre

-Rol

lout

)

post

-Rol

lout

Ong

oing

Education

Change Management

Knowledge Management

Task Training

Figure 1: Three Dimensions of ERP Training

Along with the help of the vendor, third-party consultants, and the project team, theTraining Department (using this three-dimensional concept) should develop trainingmodules that address the specific needs of the ERP project. Some modules may beappropriate for more than one target audience, and specific details may be repeated inmultiple formats and at different times during the project.

When to Do What Training?

The exact nature of the ERP training program, however, will depend upon which vendorand which product(s) are selected. The following sections discuss training issues asthey pertain to the stages of the ERP implementation project. For each stage, a


suggested training plan is offered. Certain topics recur from one stage to another. Thisdoes not imply that workers need to be retrained at each stage. Rather, workers shouldbe assigned to training courses as they can be spared from their routine assignments. Ifimportant new information is included (during later stages of the project) that calls forretraining of certain groups, then ad-hoc training will be scheduled.

1. Pre-sales stage – The Executive Steering Committee (ESC) needs to appreciatethe difference between an ERP implementation and a typical Information Systemsproject. Specifically, the ESC should be given information about ERP so that itcan make an informed decision on how to proceed in forming an ERP projectteam and in selecting an ERP product. What should be given at this stage is nottraining (how to perform a task), but rather education (why various tasks arenecessary, and why they should be done a certain way).

It is important that members of the ESC receive a broad introduction to ERPbefore any vendors are brought in. Likewise, trainers at this stage should bedisinterested parties; i.e., consultants who do not specifically represent one of thelikely candidate ERP vendors. A summary of a suggested ERP pre-sales trainingplan is shown in Sample ERP Implementation Training Plan – Pre-sales Stage(Table 1).


Table 1: Sample ERP Implementation Training Plan – Pre-sales Stage

When Purpose Source ofTraining

Target ofTraining Example Modules

Pre-Sales Education • DisinterestedThird PartyConsultant

• ExecutiveSteeringCommittee

• Nature & Capabilities ofERP

• Costs of ERP • Risks of ERP • Benefits of ERP• Commitments to ERP• Legacy Systems & Data

Conversion• ERP Budgets• Change Management

Overview• Knowledge Management

Overview

Pre-sales training at this level should enable executives to broadly gauge theimpact of an ERP implementation for their departments in order to:

• estimate the range of the required resource budget• set priorities based on best-in-class metrics and return on investment• scope requirements for manpower, training, etc.

As a result of this training, the ESC should gain a sense of the depth ofcommitment required by ERP, if the decision is made to go forward with theproject. One test of this commitment is if one ESC member steps forward tobecome the ERP champion. Another test of commitment is if the ESC resists thetemptation to reduce the project’s training budget when negotiations get tough.

2. Planning and design stage – The project team, process owners (managersresponsible for specific functions), and the Training Department all needguidance on how to plan a project as large as an ERP implementation, and how todisseminate all the necessary knowledge, skills and attitudes to every level of theorganization.

Generating a new ERP mind set (from top to bottom), which will be a recurringtheme throughout the project, begins here. The project team and process ownersmust prepare the entire enterprise for the organizational soul searching that formsthe foundation of a successful move to ERP. Questions that should be askedinclude:


2 ERP training will be presented to all levels of the enterprise: the ExecutiveSteering Committee, Process Owners, the project team, Power Users,users, and value chain partners. While many of the same topics will beaddressed to all levels, each target group will be given specific details onlyas appropriate, on a “need-to-know” basis.

• Where is the business going, and how should it be run to get there?• What business problems exist throughout the organization?• What priorities should the business have?

With answers to these and many other questions, consultants, the project team,process owners, and power users should determine how to best match thecompany’s process needs with the features of the proposed ERP software. Eachprocess should be examined and considered for re-engineering.

Instruction at this stage will address “Train the Planner” (to help those new to theenormity of an ERP project perform the planning tasks) and “Train the Trainer”issues, as well as the topics which were presented to the ESC.2

Perhaps one of the most commonly overlooked training requirements is trainingthose workers who will replace the people chosen to become power users. Thispre-project training should be accomplished before power users get caught up intheir new responsibilities. This will reduce the need to pull power users awayfrom the project. It will also reduce conflicts and tensions between the projectteam and the business units. It is of primary importance to maintain goodwillbetween these two groups throughout the project.

A summary of a suggested ERP planning and design stage training plan is shownin Sample ERP Implementation Training Plan – Planning & Design Stage (Table2).


Table 2: Sample ERP Implementation Training Plan – Planning & Design Stage



Planning &Design

Education • Vendor• Third Party

Consultant

• Project Team• Training Dept• IT Dept• Process

Owners• Middle and

Line Managers• Power Users

• Train the Replacement• Train the Trainer• Integrated Project Team

Planning• Nature & Capabilities of

ERP• Costs of ERP • Risks of ERP • Benefits of ERP• Commitments to ERP• Legacy Systems & Data

Conversion• ERP Budgets• Testing ERP Processes

ChangeManagement

• Vendor• Third Party

Consultant

• Project Team• Training Dept• Process



• Train the Trainer• Integrated Project Team

Planning• Team Building• Job Re-classification

Training

KnowledgeManagement


Consultant

• Project Team• Training Dept• Process



• Insight Capture• Progress Logs• Version Control• Change Control

Documentation• End-of-assignment Reports

TaskTraining


Consultant

• Project Team• Training Dept• IT Dept• Process



• Train the Replacement• Train the Trainer• Integrated Project Team

Planning• Overall Process Training• Process-specific Training• Task-specific Training• Legacy Systems & Data

Conversion• Testing ERP Processes

The project manager and process owners will select power users from functionalareas on the basis of their functional expertise, work ethic, team-working ability,


and their potential to facilitate the development and deployment of the newsystem. Power users play several important roles throughout the project. One isto provide insight to understanding the ERP processes that affect their functionalareas. Another primary role is to serve as Help Desk Supporter / Trainer forother users and value chain partners. To this end, power users will be givenTrain the Trainer instruction.

It is important that Middle and Line Managers be included in all phases of theproject, so that they will be fully capable of dealing with post-rollout surprisesand emergencies as they occur. If not included in training, Middle and LineManagers can deliver counter-productive orders to users in case of an emergency. For this reason, Middle and Line Managers should be given process-specifictraining similar to power users.

With the assistance of consultants, the Training Department and the project teamshould develop and begin to implement a project training plan. Part of their workat this time is to assess the mood of employees regarding the new ERP system,and begin to design a Change Management (CM) strategy to facilitate theimplementation. Some jobs will be eliminated as a result of the new system, andthese employees will be let go. Other employees will be asked to move to new ordifferent positions with, perhaps, expanded responsibilities. These re-classifiedemployees will be given training to prepare them for their new jobs.

3. Build stage – As the re-engineering work proceeds, the project team will givecourse designers specific details and general information that should bepresented to each target audience. Power users will divide their time betweenassisting in BPR and course presentation.

Along with Training Department staff, power users will present courses toprepare the user and Value Chain community for the rollout. All training leadingup to the project going live must be completed during the Build stage.

A summary of a suggested ERP Build stage training plan is shown in SampleERP Implementation Training Plan – Build Stage (Table 3).


Table 3: Sample ERP Implementation Training Plan – Build Stage



Build(pre-Rollout)

Education • Third PartyConsultant

• TrainingDept

• IT Dept• Process

Owners• Power Users

• Middle andLine Managers

• Power Users• users• Value Chain

Partners


• Costs & Risks of ERP • Benefits of ERP• Commitments to ERP• Legacy Systems & Data

Conversion• Testing ERP Processes• Maintaining ERP Systems

ChangeManagement

• Third PartyConsultant

• Training Dept• Process




• Power Users• Users

• Team Building• Job Re-classification

Training

KnowledgeManagement





• Power Users• Users• Value Chain

Partners



TaskTraining

• Training Dept• IT Dept• Process




Partners

• Overall Process Training• Process-specific Training• Task-specific Training• Legacy Systems & Data

Conversion• Testing ERP Processes• Maintaining ERP Systems

System “Go-Live” Day

4. Post-Rollout stage – The moment ERP goes live is when the processes thesystem manages are most vulnerable. This is when all the lead-up work inplanning, designing, building and training is put to the test. The time and effortinvested in training will pay off most clearly during the post-rollout stage. Userswho are knowledgeable on how the system should work will be the ones whonotice problems, and will know what to do about them.


It is during the post-rollout stage that the learning curve is steepest, and lessonsto be learned will appear the fastest. Weaknesses in training given prior to thisstage will become evident, and should be corrected.

Much of the training that will be given during the post-Rollout stage will be ad-hoc in nature. Some groups (e.g., users in a particular department or usersinvolved with a particular process) may need additional training, or may needretraining, to optimize the way the system is used. The project team may want toprovide additional documentation instructions at this time. It is also possible thatthe CM process may not have achieved desired results throughout theorganization, and some additional efforts may be required. Company customersand value chain partners will need special (perhaps online) coaching or trainingto use the new system.

Once the system is live, the process of maintaining the ERP system begins. Training on maintaining the system that was not previously given, or not given insufficient depth or with the latest system details, should be given now. ERPtopics to be included in both scheduled and ad-hoc training, during the post-Rollout stage, are shown in Sample ERP Implementation Training Plan – post-Rollout Stage (Table 4).

Table 4: Sample ERP Implementation Training Plan – post-Rollout Stage



Post-Rollout

Education • Training Dept• IT Dept• Process




Partners


• Costs & Risks of ERP• Benefits of ERP• Commitments to ERP• Legacy Systems & Data

Conversion• Maintaining ERP Systems

ChangeManagement






• Power Users• Users

• Team Building




Post-Rollout

KnowledgeManagement





Partners



TaskTraining

• Training Dept• IT Dept• Process




Partners

• Overall Process Training• Process-specific Training• Task-specific Training• Maintaining ERP Systems

5. Ongoing – After post-Rollout issues have been resolved, the ERP system shouldbe operating normally. However, training will be necessary to support theongoing needs of the ERP system:

• Users will discover ways to extend its usefulness, and will requestadditional reports and system tweaking (configuration).

• Vendors will release updates of ERP software every one to three years,and these need to be installed and configured.

• A company merger or acquisition may necessitate the inclusion andconversion of the acquired company’s legacy data into the centraldatabase.

In addition to these ongoing training requirements, employees will leave thecompany and new employees will join. These new hires will not have had theexperience of the transition to ERP, and will require much of the same trainingthat their counterparts received during the ERP implementation.

A summary of ERP training topics is listed in Sample ERP ImplementationTraining Plan – Ongoing Stage (Table 5).


Table 5: Sample ERP Implementation Training Plan – Ongoing Stage



Ongoing Education • Training Dept• IT Dept• Process





Partners


• Costs & Risks of ERP • Benefits of ERP• Commitments to ERP• Legacy Systems & Data


KnowledgeManagement






Partners



TaskTraining

• Training Dept• IT Dept• Power Users



Partners

• Overall Process Training• Process-specific Training• Task-specific Training• Legacy Systems & Data


Types of Training Programs

For increased ERP implementation success, companies should consider taking a holisticapproach to training to ensure that their people have a 360o readiness for the changesERP will bring. Training should focus on the processes that are being re-engineered orbeing put in place for the first time. The more processes involved in an ERP project, themore training will be required.

Companies have many choices when considering the format to be used in presentingtraining for ERP. Training involving hard-to-understand concepts or difficult issues(e.g., dealing with employee resistance) is best presented in a classroom setting. Inaddition to the traditional classroom setting, training material can be provided in theform of computer-based training (CBT), video courses, self-study books, pop-upscreens, and online virtual classrooms (24 x 7) in HTML or PDF format. As well aswhich format to use for training, companies must also consider which language. When acompany goes global with an ERP implementation, training courses should be availablein languages spoken by its employees.


As mentioned earlier, because the move to ERP involves the very way a company doesbusiness, training must address a full range of issues: rule-based processing, adjustingthe company culture to the new system, managing the body of knowledge as it growsthroughout the project, as well as “how-to” task training for performing transactions inthe various functional areas. For this reason, training must include education, changemanagement, knowledge management, and task training.

ERP Education

For ERP applications, the term training must include more than the “this button doesthat” notion of training. According to Wheatley (2000), the concept of training shouldbe extended to include education and CM. Whereas training concentrates on howsystems work and how to work the system, education deals with the why, who and wherequestions that arise. ERP education helps employees at every level understand howinformation flows through the business itself.

Niemann (personal communication, Germany, February 22, 2002) stresses that thislearning is essential to a successful implementation, and it is important to begintraining for this early in the process. For example, the C-level customer (CIO, CFO,CEO or board member) needs ERP education at the pre-sales stage, in order to learn thehigh-level concepts which are important to making a wise product choice and cleanimplementation. What is important at this stage is to learn to ask the right questionsabout ERP systems in general, not to gather product details from vendors.

In addition to formal ERP education, executives can share concerns and learn aboutpotential problems by participating in pre-sales round-table discussions with supplychain partners and other companies with ERP experience. Such pre-sales learningefforts help decision makers develop that necessary level of comfort for them to committhemselves to the project. This top-level commitment, says Niemann, is absolutelyessential for the project’s success.

Executives are not the only ones in need of ERP education, however. Users too mustdevelop an ERP mind-set, so that they can understand what consequences their actionshave throughout the system. Rather than being mere data entry people, ERP users nowset forces in motion that are felt throughout the enterprise. Users themselves handleconfidential information (customer credit ratings, etc.), view valuable company details(inventory levels), and exercise business decisions (to sell or not). Never before has somuch of an enterprise workforce been entrusted with so much accountability,responsibility and communication power as with today’s ERPs (Koch, 1999).


To a user who is unprepared for the move to ERP, the shift (from the traditionalapproach to the job to the integrated systems approach) can be likened to the mentaljump from doing arithmetic to solving algebraic problems, or from driving a taxi toflying a jet fighter plane. ERP education must be designed to help users to increasetheir understanding, from how to do a set of tasks under the traditional system to anunderstanding of how processes work. They must learn to think in terms of the rules oralgorithms that control the processes of a system, especially those in their functionalarea. ERP education will help users understand the why issues that surround thetechnology and the processes of the new system.

Change Management

According to Krasner (2000), Deloitte & Touche conducted a study of 164 users from 62Fortune-500 companies using ERP systems. The Deloitte and Touch findings revealedthat, of all areas of ERP problems, people issues were predominate (62 percent),followed by business process issues (16 percent) and IT issues (12 percent). Clearly,companies adopting ERP are doing something wrong.

A new ERP system incorporates changes to technology, processes and people. Of these,the factor with the greatest variability is people. The new system may require thatpeople learn new skills, work in different functions, or face having their positioneliminated altogether.

For example, a typist who did simple data entry work before ERP will face a whole newworld after ERP. The contents of his / her computer screen, now holding customer datarelevant to many departments, can impact numerous issues companywide (such ascustomer credit rating, payment history, shipping arrangements, etc.). Whether theworker wants it or not, he / she is a suddenly business person – and must have the mind-set to match. Desired or not, the job now demands an elevated level of responsibility,accountability and intercommunication.

Humans are fickle creatures. They do not like to change and, when forced to adopt newbehaviors, they can become quite unpredictable. It may be a matter of preferring “thedevil” that employees know to accepting a new, unknown system. Furthermore,initiating an ERP effort can open a “Pandora’s box” full of personal / departmentalagendas and vested interests, which CM efforts will need to address.

Stovepipes all have their creators, who are committed to the status quo – both their ownand that of their pet projects. These employees may hoard information assets. Theymay protect their fiefdoms against attack by the new system. It is difficult for thesestovepipe creators to step back and objectively study the role that their processes play in


the enterprise. Changing processes is similar to divorcing a marriage partner of manyyears. If the worker was committed to the process, then changing or replacing theprocess will be difficult and painful. If, on the other hand, the worker never got alongwell with the process, a new (and hopefully better) process will be welcome.

Consultant John Finout of BancTec, Inc. describes the resistance many users go through(when their company is rolling out a new system) in terms similar to the four-stage griefprocess. At first workers are optimistic that the new system will solve problemspainlessly. Then, users go into a state of denial when discovering that absolute changesin work practices will be required. Upon learning that they cannot go back to the oldsystem, workers go from denial to anger, to bargaining, and, finally, to despair. Onlyafter hitting bottom do users resign themselves that the system is there to stay, and thenaccept the fact that the transition might work. It can take four to five months to developa strong group of believers, even longer to get the entire workforce on board (eAIJournal, September, 2000).

Employees are more willing and able to participate in the transition and operation of anew system when they fully understand the nature of the transformation, as well as thebehavioral changes that will be asked of them. Employee buy-in depends on clearcommunication from the beginning, regarding the potential outcomes for eachindividual, each department, and the company as a whole. Employees cannot beexpected to give their best while fearing the unknown (King and Tang, 2002).

Cultivating a positive change environment is easier with newer, younger employees,without years of “that’s the way we’ve always done it” baggage to unload. Just as theflight crew of a Boeing 737 would have trouble adapting to a Boeing 747 (especially inan emergency), experienced employees have old habits (or “expert errors”) that must beunlearned before they can learn to become competent with a new system (Baxter, 1998).

A pro-integration climate should be created, in which early adaptors and contributingusers are rewarded for their participation. All employees should be motivated tobecome more systems-aware, more data-aware. They should be trained to makeinformed decisions based on direct access to data and interpretation tools.

Training will help overcome much of the fear, uncertainty and doubt (“FUD”) thataccompany the change to a new system. Special companywide team building effortsshould be initiated to encourage the sharing of processes and responsibility thataccompanies an ERP effort.

User buy-in is a main predictor of success for an ERP project. Through training, thecompany can go far in managing user expectations and reducing the natural resistance to


change. A good change management program will promote user ownership, which isessential to the success of an ERP effort.

Even with the best CM program, not every employee will be willing or able to adapt tothe new ERP environment of transparency and accountability. Not everyone will acceptthe new “group think” that some may perceive to be pervading the company. Someemployees may choose to leave the company, others may be forced out due todownsizing. In any case, the company must adjust its recruiting practices to includenew selection criteria and to attract employees that will fit the new corporate culture.

Knowledge Management

Many companies do not appreciate the need for a Knowledge Management programuntil they have undertaken a project as large as ERP. During the course of an ERPproject the company can witness a procession of vendor consultants, third partyconsultants, and replacement employees (taking the place of burnt-out project teammembers and project team members seduced by headhunters with more attractiveoffers).

As each consultant goes away, it is possible that valuable project knowledge orunderstanding vanishes as well. (Hopefully, team members get to work alongside expertconsultants, and can tap their knowledge before they finish their part of the project.) Pertinent questions are: “Has this person’s knowledge been recorded? Or do we loseknowledge at the boundary zones (the points in time and place where the project passesfrom one stage to the next)? Do we need to relearn some lesson, because we did notcapture what this person learned?” (Clark, 2000)

Effective project managers appreciate the need for capturing every insight gained byeach person participating in the ERP effort. Documentation helps keep the project ontrack, especially when project sponsors or key players leave the company or the project. Examples of this documentation include:

• Progress logs, that reflect who is doing what, and when;• Change control documentation, covering what changes were made during

each project phase: when, why and by whom; and• Routine documentation and reports due before a team member rotates out

of the project.

This reporting helps to maintain schedules and accountability. It can also captureinsights for better management of later stages of the project.


This set of logs, reports and documentation constitutes the project’s KnowledgeManagement (KM) efforts. KM contributes to project “ownership” by providingdocumentation (from preceding phases of the project) to new members and managers asthey take their place on the project team.

KM training provides a formal and efficient way for the project manager to stipulate the frequency and kinds of reports required of project team members. Procedures forcollecting and processing KM information can also be spelled out at this time.

Unless automated tools are used to support the project’s KM efforts, the projectmanager is wholly dependent on competent and conscientious assistants to collect andsynthesize reports and documentation in a timely manner. Some vendors include a KM(or CASE tool) repository as part of their ERP software, or offer it as an option. Suchtools can be configured to identify and capture specified knowledge elements at pre-determined milestones during the project.

By the end of the implementation, the KM system will provide a knowledge model ofthe project, depicting the relationships and dependencies of people, business processesand events. This model will help the project manager anticipate and plan for theknowledge requirements for later stages of the project (Clark, 2000). An effective KMsystem can reduce the learning curve for later implementations when various projectmodules are going to be implemented successively.

Not all ERP vendors offer KM modules to support their products, so a stand-alone KMtool would be a valuable aid to an ERP implementation. One such product is theVentrix SmartBridge, which can display context-relevant information based on:

• the user’s role in the organization• the computer screen being shown• the position of the cursor on the screen.

Users can subscribe to varying degrees of information / knowledge updates based onprocess ownership or management hierarchy. In addition, users can submit questions todesignated experts electronically (1999 EPSS Design Contest).


Finance & Accounting

Human Resources

Manufacturing

Task Training

Task training deals directly with the individual ERP processes involved in theimplementation, with the related screens, and with the keystrokes required to performspecific transactions. Therefore, training modules developed by the vendor or bypartner third party consultants can serve as a starting point for user training, but onlyafter adapting them to the specific situation of the company. The project team mustwork with the trainers to ensure that training on necessary process modules is included,along with examples specifically relating to the company.

Figure 2: Process Interrelationships

As seen in Process Interrelationships (Figure 2), although a particular ERP process fallsprimarily into one functional area (e.g. Finance and Accounting), it will overlap withother functional areas (because of the integration of processes). For this reason, it isrecommended that users and middle managers from all affected functional areas attendthe same training sessions. Simulated demonstration lessons will show cross-section ofusers first hand the necessity of an enterprise-wide mind-set, one that includes theuser’s own process, affected processes and the overall system.

This training (presented ideally in a classroom or networked computer lab, onsite oroffsite, after the education and CM modules – including team building exercises) willdemonstrate how all users must work together as a team when the system goes live.


Conclusion

ERP systems hold great promise, serving as the backbone of systems that integrate boththe back office and front office functions of an enterprise. Due to the great expense ofERP installations, and due to the propensity for failure when these systems are notproperly implemented, it is important that training be included as a cornerstone of theimplementation plan. An ERP training plan must focus on the processing requirementsof a company, following a three-dimensional plan (who, when and what training needsshould be addressed). ERP training also must address the issues of education, changemanagement, knowledge management and task training. In this way, a company cancapitalize on the potential of ERP.

By maximizing the gains possible through ERP, “the 21st century will be known as the‘100-percent-on-time, now, period’ era of manufacturing performance requirements”(Robert Burrows, CEO and president of Intrinsics International, quoted by Blanchard,Summer 1998, p.2).


References

1999 EPSS Design Contest. (n.d.). EPSS InfoSite. [Online], 3 pages. Available:http://www.pcd-innovations.com/infosite/contest99/ventrix.htm. [2/13/2002].

Anderson, Danielle. (November 1, 1997). Super Users to the Rescue, CIO Magazine,CXO Media, Inc. [Online], 6 pages. Available: http://www.cio.com/archive/. [1/4/2002].

Baxter, Paul. (1998). CRM Training Fails Because of What Trainees Already Know;Not Because of What They Don't Know, Neil Krey's CRM Developers. [Online],9 pages. Available: http://users2.ev1.net/~neilkrey/crmdevel/resources/paper/baxter/baxter.htm.[1/6/2002].

Best of Breed vs. ERP, HRM Software. HRM Software. [Online], 2 pages. Available: http://www.hrmsoftware.com/news_bobvserp.asp . [ 1/30/2002].

Blanchard, David. (Spring 1998). ERP - The Great Equalizer, Evolving Enterprise. [Online], 7 pages. Available: http://www.lionhrtpub.com/ee/ee-spring98/erpmain.html. [1/4/2002].

Blanchard, David. (Summer 1998). Manufacturing in the 21st Century, EvolvingEnterprise. [Online], 7 pages. Available: http://lionheartpub.com/ee/ee-summer98/manufacturing.hml. [1/4/2002].

Boyd, Jade, Ted Kemp and Margie Semilof. (November 9, 2001). IT Says No to CRMIntegration, Internet Week / Tech Web. [Online], 3 pages. Available: http://www.internetweek.com/newslead01/lead110901.htm. [1/6/2002].

Change Management and EAI. (September, 2000). eAI Journal. [Online], 3 pages. Available:http://www.eaijournal.com/PDF/Change%Management%20_%Korzeniowski_1.pdf. [2/12/2002].

Clark, Linda Eiland. (October 20, 2000). A Stitch in Time, Intelligent Enterprise. [Online], 7 pages. Available: http://www.intelligententerprise.com/001020/feat3.shtml. [1/6/2002].

Connolly, James. (March 9, 1999). ERP's Real Benefits, Computerworld / CNN.com. [Online], 7 pages. Available: http://www.cnn.com/TECH/computing/9903/09/erp.ent.idg/index.html. [1/19/2002].

Davenport, Tom. (December 1, 1998). Living with ERP, CIO Magazine. [Online], 6pages. Available: http://www.cio.com/archive/120198/think_content.html. [1/4/2002].

Davenport, Thomas H. (March 1, 2000). Long Live ERP, CIO Magazine. [Online], 5pages. Available:http://www.cio.com/archive/030100_davenport_content.html?printversion=yes.[1/4/2002]


Donovan, R. Michael. (n.d.). Successful ERP Implementation the First Time, R.Michael Donovan & Co., Inc. [Online], 3 pages. Available:http://wwwrmdonovan.com/pdf/perfor_98_9.pdf . [2/7/2002].

Donovan, R. Michael. (n.d.). There Is No Magic in ERP Software: It’s in Preparationof the Process and People, R. Michael Donovan & Co., Inc. [Online], 3 pages. Available: http://wwwrmdonovan.com/pdf/perfor_98_9.pdf . [2/7/2002].

Dryden, Patrick. (July 27, 1998). ERP Failures Exact High Price, Computerworld. [Online], 3 pages. Available: http://etudiants.fsa.ulaval.ca/project/gie-64375/sap/ERPfailure.html. [1/6/2002].

Enterprise Resource Planning (ERP). (1999). Rockford Consulting Group, Ltd. [Online], 4 pages. Available: http://www.rockfordconsulting.com/erp.htm. [1/6/2002].

ERP Training Labyrinth. (December 11, 1998). PC Week. [Online], 2 pages. Available: http://www.adnet.com/filters/printerfriendly/0,6061,2173573-92,00.html. [1/18/2002].

Friscia, Tony. (Spring, 1998). The Enterprise Application Backbone: Getting to theHeart of a Company's IT Strategy, Evolving Enterprise. [Online], 5 pages. Available: http://www.lionhrtpub.com/ee/ee-spring98/fricia.html. [1/4/2002].

Heske, Patrick. (June 25, 2001). ERP: Vendors and Customers Face New Challenges,Computing SA / Computerworld. [Online], 4 pages. Available: http://www.computingsa.co.za/2001/06/25/Feature/fea01.htm. [2/21/2002].

King, Ro and Tammy Tang. (January 21, 2002). E-CRM in the Post Dot-Com Age: Nine Critical Factors for Success, IT Toolbox. [Online], 7 pages. Available: http://crm.ittoolbox.com/documents/document.asp?I=1864. [1/24/2002].

Koch, Christopher. (October 15, 1999). The Most Important Team in History, CIOMagazine, CXO Media, Inc. [Online], 13 pages. Available: http//www.cio.com/archive/101599/erp1_content.html. [1/4/2002].

Koch, Christopher. (June 15, 1996). Flipping the Switch – The Franchising Strategy,Special Focus SAP, CIO Magazine, CXO Media, Inc. [Online], 2 pages. Available: http://www.cio.com/archive/061596_flip_2_content.html?printversion=yes.[2/14/202].

Koch, Christopher, Derek Slater, and E. Baatz. (December 22, 1999). The ABCs ofERP, CIO Magazine, CXO Media, Inc. [Online], 9 pages. Available: http://www.cio.com/research/erp/edit/122299_erp.html. [1/4/2002].

Krasner, Herb. (Jan/Feb 2000). Ensuring E-Business Success by Learning From ERPFailures, IT Pro / The IEEE Computer Society. [Online], 5 pages. Available: http://www.computer.org/itpro/cover_stories/jan_feb/erp_2.htm. [1/6/2002].

Kuiper, Dick. (Spring 1998). The Key to a Custom Fit, Evolving Enterprise. [Online],5 pages. Available: http://www.lionhrtpub.com/ee/ee-spring98/kuiper.html. [1/4/2002].

Madden, John. (August 27, 1998). SAP Dismisses Lawsuit Alleging Faulty Software as‘Unfounded,’ PC Week Online. [Online], 2 pages. Available:http://www.zdnet.com/eweek/news/0824/27msap.html. [2/21/2002].


Mello, Adrian. (February 7, 2002). 4 Trends Shaping ERP, Enterprise. [Online], 4pages. Available: http://www.zdnet.com/filters/printerfriendly/0,2844338-92,00.html. [2/14/2002].

Mello, Adrian. (February 7, 2002). ERP Fundamentals, Enterprise. [Online], 3 pages. Available: http://www.zdnet.com/filters/printerfriendly/0,6061,2844319-92,00.html. [2/14/2002].

Osterland, Andrew. (January 01, 2000). Blaming ERP, CFO Magazine. [Online], 3pages. Available: http://www.cfo.com/printarticle/1,4580,0|83|AD|1684,00.html. [1/6/2002].

Pearson, D. (December 1, 1998). To Hell and Back, CIO Magazine, CXO Media, Inc. [Online], 14 pages. Available: http://www.cio.com/archive/120198_turk_content.html?. [1/6/2002].

Pender, Lee. (May 15, 2001). Faster, Cheaper ERP, CIO Magazine, CXO Media, Inc. [Online], 9 pages. Available: http://www.cio.com/archive/051501/faster_content.html. [1/4/2002].

Schneider, Polly. (March 1, 1999). Wanted: ERPeople Skills, CIO Magazine, CXOMedia, Inc. [Online], 12 pages. Available: http://www.cio.com/archive/030199/erp)content.html. [1/4/2002].

Schneider, Polly. (March 2, 1999) Human Touch Sorely Needed, CIO Magazine, CXOMedia, Inc. / CNN.com. [Online], 9 pages. Available: http://www.cnn.com/TECH/computing/9903/02/erpeople.ent.idg/index.html. [1/19/2002].

Scott, Barry. (September 12, 2000). ERP Risk Assessment, PricewaterhouseCoopers.[Online], 29 pages. Available:http://cadvision.com/isaca/Sep_Implementation_Risk_Mgmt_ISACA.ppt.[2/27/2002].

Slater, Derek. (January 15, 1998). The Hidden Costs of Enterprise Software, CIOEnterprise Magazine. [Online], 11 pages. Available: http://www.cio.com/archive/enterprise/011598_erp_content.html. [1/4/2002].

Slater, Derek. (February 15, 1999). An ERP Package for You…and You…andYou…and Even You, CIO Magazine / CXO Media, Inc. [Online], 11 pages. Available: http://www.cio.com/archive/021599/erp_content.html. [1/4/2002].

Slater, Darek, (January 15, 2002). Costly, Painful and Worth It, CIO Magazine / CXOMedia, Inc. [Online], 9 pages. Available:http://www.cio.com/archive/011502/costly_content.html?printversion=yes.[2/7/2002].

Stedman, Craig. (January 3, 2000). ERP Problems Put Brakes on Volkswagen PartsShipments, Computerworld. [Online], 1 page. Available: http://www.computerworld.com/cwi/Printer_Friendly_Version/0,1212,NAV47_STO40471-,00.html. [2/4/2002].

Varon, Elana. (May 15, 2000). Human Error, CIO Magazine, CXO Media, Inc. [Online], 8 pages. Available: http://www.cio.com/archive/051500/people_content.html. [1/8/2002].


Wheatley, Malcolm. (June 1, 2000). ERP Training Stinks, CIO.Com Magazine.[Online], 11 pages. Available:http://www.cio.com/archive/060100_erp_content.html?printversion=yes.[1/4/2002].

Wilder, Clinton and Beth Davis. November 30, 1998. False Starts, Strong Finishes,Information Week Online. [Online], 4 pages. Available:http://www.informationweek.com/711/11iufal.htm. [2/21/2002]

Technology

trainning erp