Key to Effective ERP Implementation: Comprehensive Training

Training: Key to Effective
Enterprise Resource Planning Implementation

Prepared for:

Mr. John Meinke

INSS - 690

University of Maryland – Europe

By John Felter
johnfelter@yahoo.com
March 9, 2002

Training: Key to ERP 2


Abstract

The power and potential of Enterprise Resource Planning systems often go
unrealized, due to implementations that do not prepare users for the process
changes that these systems entail. Sources indicate that improper training is
often to blame for these failed implementations. A comprehensive training
strategy, therefore, is key to the effectiveness of an ERP implementation. An
ERP education / training plan is proposed, addressing training needs on the
basis of who needs training, when it is needed, and what topics should be
presented.



Introduction

The acceleration of information is a sword that cuts both ways. Customers, spoiled by
the speedy response they get on the Internet, now expect instant gratification
everywhere. They demand higher standards of service, and lower prices. For
companies serving these customers, the competition has become more agile than ever.
In today’s virtual marketplace, companies can shop the globe for cheaper, more
responsive 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 the
stress of competition among companies serving customers.

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

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

However powerful ERP might be, it is not a magic cure. An ERP system places heavy
demands on a company that installs one. To benefit at all, the company must undergo a
thorough metamorphosis. A comprehensive training 1 strategy, therefore, is key to the
effectiveness of an ERP implementation.

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

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


Manufacturing Background

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

To increase competitive advantage, domestic American manufacturers introduced
computer applications, such as Materials Requirements Planning (MRP), in the 1970s.
With MRP, manufacturers could better manage the planning and scheduling of material
supplies, as well as the control of inventories. During the 1970s and early 1980s, more
sophisticated 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 manufacturing
benefits gained by specialization and decentralization eventually reached a limit, even
with 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, computer
applications were mainframe-based and found in only larger organizations.

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

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


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

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

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

Information was stored in paper form, on databases, or both. Therefore, when
transferring data from one department to another, additional errors could easily be
introduced. By putting data in motion, the data itself became a moving target. It was
not 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 of
information” and other problems inherent with “stovepipe” information systems.
Efforts to interconnect stand-alone systems (with each department entering data
independently and each department using its own proprietary data formats) consumed
enormous 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 greater
challenge, especially as companies have expanded across product lines and across
global borders. A narrow focus did not always serve decision makers, who demanded
an enterprise-wide view of their companies. Growing out of the development of MRP II
and integrated databases, manufacturers (and later all variety of organizations) sought
the means to combine information used by an organization’s many departments and
diverse functions into an integrated computing system. ERP systems were developed to
fulfill this need.


The goal of ERP is to manage information across all functions of an enterprise, such
as inventory, purchase orders, customer data, and employee records, using a common
database (instead of isolated departmental databases). Centralization, using a single
networked database, made data available to all departments. The unifying features of
ERP provide an enterprise with many benefits. For example, the manufacturer of a
build-to-order product (such as personal computers), using an ERP to process
transactional 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, it
is not necessary for each department to reenter data. Data consistency is realized by
keeping each data element in only one format. Because only one version of the data is
kept, there is no concern over which version is the most recent. Transactional
processing and cross-functional data sharing happen faster, with fewer errors. Finally,
because the company’s business processes are unified and automated, better-informed
operational decisions can be made, real-time, throughout the entire enterprise.

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

• Sales and manufacturing levels can be increased due to more efficient
utilization 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 in
hours and days, instead of weeks and months.
• Deliveries can be made sooner, faster, and in the most cost-efficient
manner.
• Inventories of both supplies and finished products can be kept smaller and
more 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 with
the decision of whether it is better to build a custom system, tailored to meet the unique
requirements of the company, or to purchase an off-the-shelf product. The advantage of
going with one of the leading ERP providers is the ability to capitalize on the insight
and experience gained from a large number of implementations, in a variety of
industries. Most major ERP vendors have developed various sets of industry-specific
templates that permit pre-configuration, following the best practices of each industry.

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

Another customization alternative is to start with an off-the-shelf ERP product, and add
desired 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 wide
margin. Other disadvantages of this approach are that modified, off-the-shelf ERP
systems are slower, more bug-prone and costlier to implement (after the coding changes
are completed) than similar products whose code has not been tampered with.

However appealing the case for custom-written or modified ERP software may be, the
ERP trend is for unmodified off-the-shelf packages. Used without modifications to the
underlying code, these packages still offer companies great flexibility to match their
specific 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 (involving
countable items), ERP vendors now supply industry-specific applications, including


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

Initially, ERP software was installed mostly on mainframe computers, as centralized
applications or deployed on limited networks. The most famous example of early ERP
software 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 may
not appreciate the technicalities of their Java™ and HTML-based graphical user
interfaces (GUIs), users do find them more user-friendly than their predecessors.
Without compromising data integrity or without disrupting operations, client-server
ERP systems are capable of transferring data via LANs, the Internet or across Supply
Chain 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 office
capabilities to manage such enterprise functions as projects, manufacturing, accounting
and 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 office
functions as:

• Customer Relationship Management (CRM) – Manages customer data
gathered from variety of sources (personal contacts of the sales force,
point-of-sale (POS) operations, call centers and e-mail) and generates a
comprehensive view of customer data and behavior. CRM enables
companies to provide truly personalized and consistent customer service
(set to a configurable standard).
• Sales Force Automation (SFA) – Supports the sales function (in both
sales office and the field) through a range of services from appointment
scheduling to contact management and qualification.
• Supply Chain Management (SCM) – Automates the supply chain: from
maintaining supplies of raw materials, to coordination of manufacturing
and inventory, and to shipment of products to customers.


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

Facing stiff competition from Best of Breed front office products, ERP vendors have
been 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 II
range of products.) Customers in the market for an electronic commerce application can
select from either Best of Breed products or ERP vendor products. While the former
may have greater overall functionality for a specific application, the latter will provide
fewer problems during integration with a customer’s main ERP system.

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

• Data Warehousing / Data Mining – Software with the ability to collect,
dimension, correlate, analyze and extract data, which has been collected
from internal and external databases.
• Business Intelligence (BI) – Uses decision-support techniques to draw
insights from hierarchies of disparate data and information. The results
help enterprises capitalize on opportunities, or to deal with management
challenges.
• Knowledge Management (KM) – Promotes management of enterprise
knowledge, by extracting insights and business intelligence from existing
information sources.
• Work Flow – Work flow programs contribute to the efficient operation of
integrated systems through the orchestration of dynamic batch
processing. Work flow sensors can be embedded in processes to
determine the optimal time and location to perform specific tasks based on
data flow.
• Middleware – This software resides in the layers between ERP and add-on
software packages, and facilitates linking these applications together.

Cost of ERP


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

• Planning – Preparing for an ERP deployment is costly. Planners must
devote sufficient time and effort to fully develop the scope, costs, and
implementation time line of an ERP project.
• Consulting Fees – Because of the vastness of these projects, it is likely
that the demands of an ERP implementation will exceed the capabilities of
the personnel of the company introducing the system. Consultants, either
from the ERP vendor itself or from a third party firm with expertise in the
selected package, may be hired to assist with the implementation.
Consulting fees, which will constitute a large percentage of the ERP
implementation budget, must be anticipated and planned for in advance.
• Training (and Change Management) – This is the most elusive item, and
is nearly always underestimated. ERP-related training is so expensive
because nearly every employee must learn not only a new software
interface, but also an entirely new set of business processes which affect
the operation of the entire enterprise. Furthermore, the corporate culture
will be impacted by changes in the company’s business processes. Special
attention 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 critical
systems, it should be fully tested before going live. Each ERP system is
different, and every company has its own set of aging – and incompatible
– legacy programs (and desired add-on programs) that need testing as part
of the final integrated system. If the ERP implementation requires much
custom coding, testing costs will increase dramatically. Testing should be
performed (under expert supervision) by the people who will operate the
processes on a day-to-day basis.
• Data conversion – Real world data is rarely without problems. For
example, legacy system data may be difficult – if not impossible – to
convert to the format of the new ERP system. The complexity of cleaning
and analyzing data from multiple (internal and external) systems increases
costs further still. Management must decide whether the value of the data
justifies the cost of cleaning or re-entry.
• Documentation – An ERP project takes a long time to implement, but its
usable lifetime will be longer still. It is a safe bet that the ERP system
will outlast the tenure of the IT employees and business-process managers
who design, implement, and maintain it. It is critical, therefore, to
document problems, questions and doubts that arise at every phase of the
project. This will aid those project team members joining the


implementation process midway through the process, as well as employees
joining the company after the implementation has been completed.
Although it adds to the cost of the project, quality documentation pays for
itself when problems occur.
• Replacing staff joining the project team – According to common
wisdom, the better the caliber of staff (both IT and business) assigned a
project team, the greater the likelihood of the project’s success. Given
the huge demands of an ERP implementation, it is likely that these
employees will continue in ERP-related roles long after the ERP system
goes live, instead of returning to their former jobs. This means the
company must budget for the additional recruiting and salary costs to
replace the project staff in order to keep the company’s operations
working during and after the implementation. (This raises a conundrum
for the company: If it moves its best staff to the project, the project will
have the best chance for success, but current operations will suffer. On
the other hand, if the company unloads its “second string” workers to the
project, operations will continue to do well, but the success of the ERP
project will be imperilled.)
• Psychological costs – It is human nature that people resist change. Due to
the extra demands placed on the entire enterprise during the ERP
implementation, project team members are not likely to enjoy much
popularity among other employees. In fact, team members may receive no
appreciation at all for their valiant efforts and long hours, even from
management, until the project is a demonstrated success. While their
implementation experience increases their market value to headhunters,
lack of appreciation may cause members of the ERP implementation team
to “jump ship” once the system goes live. Unfortunately, many companies
place a dollar value on these psychological costs only when it becomes
necessary to replace an essential employee.
• Performance drop – The operating performance of a company typically
drops once an ERP system goes live. This is the stage of the project when
the pressure to perform is greatest, the learning curve is the steepest, and
the company is most fully committed to the system working correctly. It
can take months for the company to recover to pre-implementation
performance levels, and the cost of this lost performance should be
considered.

All items listed above contribute to the total cost of an ERP implementation, and help
explain 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 or
about the benefits realized from these projects. To determine the Total Cost of
Ownership (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 course
of installing its ERP system, and for a period of two years afterward. TCO included all
hardware, software, professional services, and internal staff costs, as well as the cost of
optimizing, maintaining, and upgrading the system. ERP investments ranged from a low
of $400,000 to a high of $300 million. The average TCO was $15 million, or $53,320
on a per capita basis. The average implementation took 23 months, and required an
additional eight months before benefits of any kind were realized. Once ERP savings
began 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 willing
to 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 on
investment (ROI) for an ERP project depends not only on the a company’s choice of
software 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 the
warehouse, for example, by having surplus inventories. With today’s tight inventories
and just-in-time supply, such surpluses do not exist anymore. Companies want their
operations to run like clockwork and invest heavily in ERP to make it happen. With so
much 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 their
alarmingly high rate of failure.

Hershey, the Pennsylvania-based chocolate maker, suffered severe losses in 1999 as the
result of a failed $115 million ERP implementation, which lasted three years and
involved four separate consulting teams. Plagued with problems, the project fell behind
schedule, and was rolled out during the lead up to Halloween and Christmas.
According to Osterland (2000), Hershey simultaneously implemented all modules of an
enormously complex ERP system from SAP, plus an add-on CRM package from Siebel,
plus a logistics package from Manugistics. Hershey made the unfortunate choice of
pressing on with the roll-out at the busiest time of the year for a candy maker, the time
when 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 the
company’s annual profits fell 19 percent.

Other major companies suffering similar – though less serious – ERP implementation
disappointments, included Whirlpool, Dow Chemical, Boeing, Dell Computer, Apple
Computer, Allied Waste Management (Osterland, 2000), and Volkswagen (Stedman,
2002). According to Madden (1998), FoxMeyer Drug Company claims that the
aftershocks of its ERP system installation were so bad, that it was forced to file for
Chapter 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 of
886 IS managers, nearly 25 percent reported significant losses resulting from ERP
system outages. These outages averaged 2.8 hours per week, and averaged $35,950 per
hour in lost business and productivity (Dryden, 1998).

Causes of ERP Failures

One source of ERP system failures is poor or inappropriate project design. According
to Donovan (There is No Magic in ERP Software, n.d.), ERP software is often used to
bandage over business process flaws, without addressing them. It is easier to purchase
new 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 old
process, what it ends up with is an expensive old process (Scott, 2000). According to
Rockford Consulting Group (1999), this failure – to examine underlying business
process flaws and to develop a comprehensive, systematically defined set of functional
requirements for the proposed system – accounts for nearly 60 percent of all ERP
failures.

Related to this, is the poor selection of off-the-shelf ERP packages. Trying to expedite
the decision process, top management sometimes will choose an ERP product without
involving IT or business unit workers. A vendor is called in, and a decision may be
reached 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 the
company really needs. In some cases, executives had ERP experience with previous
employers, and assumed that what had worked in earlier situations would work again.

Rockford Consulting Group (1999) cites ill-advised cost cutting as another reason why
ERP 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 lose
enthusiasm for the project, but just plain burn out mid-project.

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

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

Poor communication among team members can cause problems in an ERP
implementation, for example, when doing business process re-engineering (BPR),
testing and other important implementation functions. As the result of an erroneous
assumption by a CIO or project leader that some departments may not be impacted by
a 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 the
project may suffer (Varon, 2000).

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


Example of Successful ERP Implementation

Complex ERP implementations are not impossible, states Osterland (2000). They just
require a tremendous amount of planning and coordination, and a stubborn adherence to
basics. For example, Amoco Corp. (now BP Amoco) successfully deployed ERP in all
17 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 is
that Amoco gave itself sufficient time to adequately plan and make the transition.
Furthermore, Amoco installed ERP modules from only one vendor (SAP) during the
implementation.

The Essence of ERP

The concept of ERP is built on standards and consistency. Processes must handle data
in 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 each
department to function individually, the standards represent a “best fit” for the
enterprise to function as a whole.

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

Over the course of thousands of implementations, vendors of ERP products have
accumulated a great deal of experience (read, problem-solving skills). For each vendor,
this accrued experience has inspired a growing array of “best practices” which are
routinely included in updated versions of their ERP product. On the one hand,
customers benefit from the accumulated knowledge – even wisdom – of all the
implementations that have gone before. On the other hand, customers may feel that, by
configuring their systems according to these now-widely-known best practices, their
systems will be the same as other companies in their industry; i.e. “just average.” This
is 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 a
company 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 of
change will not occur without pain. According to Davenport (2000), it is almost
tyrannical the way enterprise applications force companies to integrate their information
and processes. He adds, however, that it is worth the effort to have key information in
the same format throughout the business, and to have key processes performed in a
consistent fashion.

Growing Awareness of the Need for Training

Between the years 1998 and 2000, the total ERP budget spent on training grew from five
percent to 11 percent (Wheatley, 2000). By June of 2001, the Gartner Group was
recommending that companies devote a minimum of 17 percent of their ERP budget to
training. This Gartner recommendation also asserts that companies spending less than
13 percent of the implementation budget on training are three times more likely to bring
their projects in over time or over budget than those companies that exceed the 17
percent 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 have
become derailed, training is seen as a key ingredient in the salvage operation. Wilder
and Davis (1998) report that when ERP turn-around experts are called in to rescue failed
deployments, additional training and efforts are typically employed to secure user and
management buy-in.

Even companies with their expensive ERP systems up and running would do things
differently in a subsequent implementation. For example, Klein described a PeopleSoft
user seminar at which company representatives were asked if they would treat the
training component any differently if they were to implement another ERP project.
Seventy-five percent said that next time their companies would devote more time to
training, 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 in
order 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 the
company succeed in its ERP efforts. At each stage of the project, different kinds of
training need to be given to different levels of employees. This relationship is
illustrated in Three Dimensions of ERP Training (Figure 1).


Figure 1: Three Dimensions of ERP Training

Executives / ESC

Project Team
W HO

Process Owners

Power Users
AT

Ta
WH

sk
Kn
Users / Supply Chain

Tr
ow

a in
le d
Ch

in g
ge
an
WHEN

M
ge
Ed

an
M
uc

ag
an
at

em
ag
i on
Build (pre -Rollout)

post-Rollout
Pre - Sa les

Planning / Design

O ngoing

en
em

t
en
t

Along with the help of the vendor, third-party consultants, and the project team, the
Training Department (using this three-dimensional concept) should develop training
modules that address the specific needs of the ERP project. Some modules may be
appropriate for more than one target audience, and specific details may be repeated in
multiple 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 vendor
and which product(s) are selected. The following sections discuss training issues as
they 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. This
does not imply that workers need to be retrained at each stage. Rather, workers should
be assigned to training courses as they can be spared from their routine assignments. If
important new information is included (during later stages of the project) that calls for
retraining of certain groups, then ad-hoc training will be scheduled.

1. Pre-sales stage – The Executive Steering Committee (ESC) needs to appreciate
the difference between an ERP implementation and a typical Information Systems
project. Specifically, the ESC should be given information about ERP so that it
can make an informed decision on how to proceed in forming an ERP project
team and in selecting an ERP product. What should be given at this stage is not
training (how to perform a task), but rather education (why various tasks are
necessary, and why they should be done a certain way).

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


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

Source of Target of
When Purpose Example Modules
Training Training

Pre-Sales Education • Disinterested • Executive • Nature & Capabilities of
Third Party Steering ERP
Consultant Committee • 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 the
impact 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 of
commitment required by ERP, if the decision is made to go forward with the
project. One test of this commitment is if one ESC member steps forward to
become the ERP champion. Another test of commitment is if the ESC resists the
temptation to reduce the project’s training budget when negotiations get tough.

2. Planning and design stage – The project team, process owners (managers
responsible for specific functions), and the Training Department all need
guidance on how to plan a project as large as an ERP implementation, and how to
disseminate all the necessary knowledge, skills and attitudes to every level of the
organization.

Generating a new ERP mind set (from top to bottom), which will be a recurring
theme throughout the project, begins here. The project team and process owners
must prepare the entire enterprise for the organizational soul searching that forms
the foundation of a successful move to ERP. Questions that should be asked
include:


• 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 the
company’s process needs with the features of the proposed ERP software. Each
process should be examined and considered for re-engineering.

Instruction at this stage will address “Train the Planner” (to help those new to the
enormity 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 training
those workers who will replace the people chosen to become power users. This
pre-project training should be accomplished before power users get caught up in
their new responsibilities. This will reduce the need to pull power users away
from the project. It will also reduce conflicts and tensions between the project
team and the business units. It is of primary importance to maintain goodwill
between these two groups throughout the project.

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

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


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

Source of Target of
Training Training

Planning & Education • Vendor • Project Team • Train the Replacement
Design • Third Party • Training Dept • Train the Trainer
Consultant • IT Dept • Integrated Project Team
• Process Planning
Owners • Nature & Capabilities of
• Middle and ERP
Line Managers • Costs of ERP
• Power Users • Risks of ERP
• Benefits of ERP
• Commitments to ERP
• Legacy Systems & Data
Conversion
• ERP Budgets
• Testing ERP Processes

Change • Vendor • Project Team • Train the Trainer
Management • Third Party • Training Dept • Integrated Project Team
Consultant • Process Planning
Owners • Team Building
• Middle and • Job Re-classification
Line Managers Training
• Power Users

Knowledge • Vendor • Project Team • Insight Capture
Management • Third Party • Training Dept • Progress Logs
Consultant • Process • Version Control
Owners • Change Control
• Middle and Documentation
Line Managers • End-of-assignment Reports
• Power Users

Task • Vendor • Project Team • Train the Replacement
Training • Third Party • Training Dept • Train the Trainer
Consultant • IT Dept • Integrated Project Team
• Process Planning
Owners • Overall Process Training
• Middle and • Process-specific Training
Line Managers • Task-specific Training
• Power Users • Legacy Systems & Data
Conversion
• Testing ERP Processes

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


and their potential to facilitate the development and deployment of the new
system. Power users play several important roles throughout the project. One is
to provide insight to understanding the ERP processes that affect their functional
areas. Another primary role is to serve as Help Desk Supporter / Trainer for
other users and value chain partners. To this end, power users will be given
Train the Trainer instruction.

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

With the assistance of consultants, the Training Department and the project team
should develop and begin to implement a project training plan. Part of their work
at 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 the
implementation. Some jobs will be eliminated as a result of the new system, and
these employees will be let go. Other employees will be asked to move to new or
different positions with, perhaps, expanded responsibilities. These re-classified
employees will be given training to prepare them for their new jobs.

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

Along with Training Department staff, power users will present courses to
prepare the user and Value Chain community for the rollout. All training leading
up 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 Sample
ERP Implementation Training Plan – Build Stage (Table 3).


Table 3: Sample ERP Implementation Training Plan – Build Stage

Source of Target of
Training Training

Build Education • Third Party • Middle and • Nature & Capabilities of
(pre-Rollout) Line Managers ERP
Consultant
• Power Users • Costs & Risks of ERP
• Training • users • Benefits of ERP
Dept • Value Chain • Commitments to ERP
• IT Dept Partners • Legacy Systems & Data
• Process Conversion
Owners • Testing ERP Processes
• Power Users • Maintaining ERP Systems

Change • Third Party • Middle and • Team Building
Management Consultant Line Managers • Job Re-classification
• Training Dept • Power Users Training
• Process • Users
Owners
• Middle and
Line Managers
• Power Users

Knowledge • Third Party • Middle and • Insight Capture
Management Consultant Line Managers • Progress Logs
• Training Dept • Power Users • Version Control
• Process • Users • Change Control
Owners • Value Chain Documentation
• Power Users Partners • End-of-assignment Reports

Task • Training Dept • Middle and • Overall Process Training
Training • IT Dept Line Managers • Process-specific Training
• Process • Power Users • Task-specific Training
Owners • Users • Legacy Systems & Data
• Power Users • Value Chain Conversion
Partners • Testing ERP Processes
• Maintaining ERP Systems

System “Go-Live” Day

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


It is during the post-rollout stage that the learning curve is steepest, and lessons
to be learned will appear the fastest. Weaknesses in training given prior to this
stage 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 users
involved with a particular process) may need additional training, or may need
retraining, to optimize the way the system is used. The project team may want to
provide additional documentation instructions at this time. It is also possible that
the CM process may not have achieved desired results throughout the
organization, and some additional efforts may be required. Company customers
and value chain partners will need special (perhaps online) coaching or training
to 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 in
sufficient depth or with the latest system details, should be given now. ERP
topics 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

Source of Target of
Training Training

Post- Education • Training Dept • Middle and • Nature & Capabilities of
Rollout • IT Dept Line Managers ERP
• Process • Power Users • Costs & Risks of ERP
Owners • Users • Benefits of ERP
• Power Users • Value Chain • Commitments to ERP
Partners • Legacy Systems & Data
Conversion

Change • Third Party • Middle and • Team Building
Management Consultant Line Managers
• Training Dept • Power Users
• Process • Users
Owners
• Middle and
Line Managers
• Power Users


Source of Target of
Training Training

Post- Knowledge • Training Dept • Middle and • Insight Capture
Rollout Management • Process Line Managers • Progress Logs
Owners • Power Users • Version Control
• Power Users • Users • Change Control
• Value Chain Documentation
Partners • End-of-assignment Reports

• Process • Power Users • Task-specific Training
Owners • Users • Maintaining ERP Systems
• Power Users • Value Chain
Partners

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

• Users will discover ways to extend its usefulness, and will request
additional 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 and
conversion of the acquired company’s legacy data into the central
database.

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

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


Table 5: Sample ERP Implementation Training Plan – Ongoing Stage

Source of Target of
Training Training

Ongoing Education • Training Dept • Middle and • Nature & Capabilities of
• IT Dept Line Managers ERP
• Process • Power Users • Costs & Risks of ERP
Owners • Users • Benefits of ERP
• Middle and • Value Chain • Commitments to ERP
Line Managers Partners • Legacy Systems & Data
• Power Users Conversion

Knowledge • Training Dept • Middle and • Insight Capture
Management • Process Line Managers • Progress Logs
Owners • Power Users • Version Control
• Middle and • Users • Change Control
Line Managers • Value Chain Documentation
• Power Users Partners • End-of-assignment Reports

• Power Users • Power Users • Task-specific Training
• Users • Legacy Systems & Data
• Value Chain Conversion
Partners • Maintaining ERP Systems

Types of Training Programs

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

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


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

ERP Education

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

Niemann (personal communication, Germany, February 22, 2002) stresses that this
learning is essential to a successful implementation, and it is important to begin
training 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 the
high-level concepts which are important to making a wise product choice and clean
implementation. What is important at this stage is to learn to ask the right questions
about ERP systems in general, not to gather product details from vendors.

In addition to formal ERP education, executives can share concerns and learn about
potential problems by participating in pre-sales round-table discussions with supply
chain partners and other companies with ERP experience. Such pre-sales learning
efforts help decision makers develop that necessary level of comfort for them to commit
themselves to the project. This top-level commitment, says Niemann, is absolutely
essential for the project’s success.

Executives are not the only ones in need of ERP education, however. Users too must
develop an ERP mind-set, so that they can understand what consequences their actions
have throughout the system. Rather than being mere data entry people, ERP users now
set forces in motion that are felt throughout the enterprise. Users themselves handle
confidential information (customer credit ratings, etc.), view valuable company details
(inventory levels), and exercise business decisions (to sell or not). Never before has so
much 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 traditional
approach to the job to the integrated systems approach) can be likened to the mental
jump from doing arithmetic to solving algebraic problems, or from driving a taxi to
flying a jet fighter plane. ERP education must be designed to help users to increase
their understanding, from how to do a set of tasks under the traditional system to an
understanding of how processes work. They must learn to think in terms of the rules or
algorithms that control the processes of a system, especially those in their functional
area. ERP education will help users understand the why issues that surround the
technology and the processes of the new system.

Change Management

According to Krasner (2000), Deloitte & Touche conducted a study of 164 users from 62
Fortune-500 companies using ERP systems. The Deloitte and Touch findings revealed
that, 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 that
people learn new skills, work in different functions, or face having their position
eliminated altogether.

For example, a typist who did simple data entry work before ERP will face a whole new
world after ERP. The contents of his / her computer screen, now holding customer data
relevant to many departments, can impact numerous issues companywide (such as
customer credit rating, payment history, shipping arrangements, etc.). Whether the
worker 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 new
behaviors, they can become quite unpredictable. It may be a matter of preferring “the
devil” that employees know to accepting a new, unknown system. Furthermore,
initiating an ERP effort can open a “Pandora’s box” full of personal / departmental
agendas and vested interests, which CM efforts will need to address.

Stovepipes all have their creators, who are committed to the status quo – both their own
and that of their pet projects. These employees may hoard information assets. They
may protect their fiefdoms against attack by the new system. It is difficult for these
stovepipe 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 many
years. If the worker was committed to the process, then changing or replacing the
process will be difficult and painful. If, on the other hand, the worker never got along
well 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 grief
process. At first workers are optimistic that the new system will solve problems
painlessly. Then, users go into a state of denial when discovering that absolute changes
in work practices will be required. Upon learning that they cannot go back to the old
system, workers go from denial to anger, to bargaining, and, finally, to despair. Only
after hitting bottom do users resign themselves that the system is there to stay, and then
accept the fact that the transition might work. It can take four to five months to develop
a strong group of believers, even longer to get the entire workforce on board (eAI
Journal, September, 2000).

Employees are more willing and able to participate in the transition and operation of a
new system when they fully understand the nature of the transformation, as well as the
behavioral changes that will be asked of them. Employee buy-in depends on clear
communication from the beginning, regarding the potential outcomes for each
individual, each department, and the company as a whole. Employees cannot be
expected 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 the
flight crew of a Boeing 737 would have trouble adapting to a Boeing 747 (especially in
an emergency), experienced employees have old habits (or “expert errors”) that must be
unlearned 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 contributing
users are rewarded for their participation. All employees should be motivated to
become more systems-aware, more data-aware. They should be trained to make
informed decisions based on direct access to data and interpretation tools.

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

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


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

Even with the best CM program, not every employee will be willing or able to adapt to
the new ERP environment of transparency and accountability. Not everyone will accept
the new “group think” that some may perceive to be pervading the company. Some
employees may choose to leave the company, others may be forced out due to
downsizing. In any case, the company must adjust its recruiting practices to include
new 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 program
until they have undertaken a project as large as ERP. During the course of an ERP
project the company can witness a procession of vendor consultants, third party
consultants, and replacement employees (taking the place of burnt-out project team
members and project team members seduced by headhunters with more attractive
offers).

As each consultant goes away, it is possible that valuable project knowledge or
understanding vanishes as well. (Hopefully, team members get to work alongside expert
consultants, 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 lose
knowledge at the boundary zones (the points in time and place where the project passes
from one stage to the next)? Do we need to relearn some lesson, because we did not
capture what this person learned?” (Clark, 2000)

Effective project managers appreciate the need for capturing every insight gained by
each person participating in the ERP effort. Documentation helps keep the project on
track, 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 capture
insights for better management of later stages of the project.


This set of logs, reports and documentation constitutes the project’s Knowledge
Management (KM) efforts. KM contributes to project “ownership” by providing
documentation (from preceding phases of the project) to new members and managers as
they 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 for
collecting 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 project
manager is wholly dependent on competent and conscientious assistants to collect and
synthesize 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. Such
tools 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 of
the project, depicting the relationships and dependencies of people, business processes
and events. This model will help the project manager anticipate and plan for the
knowledge requirements for later stages of the project (Clark, 2000). An effective KM
system can reduce the learning curve for later implementations when various project
modules are going to be implemented successively.

Not all ERP vendors offer KM modules to support their products, so a stand-alone KM
tool would be a valuable aid to an ERP implementation. One such product is the
Ventrix 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 on
process ownership or management hierarchy. In addition, users can submit questions to
designated experts electronically (1999 EPSS Design Contest).


Task Training

Task training deals directly with the individual ERP processes involved in the
implementation, with the related screens, and with the keystrokes required to perform
specific transactions. Therefore, training modules developed by the vendor or by
partner third party consultants can serve as a starting point for user training, but only
after adapting them to the specific situation of the company. The project team must
work 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

Manufacturing Finance & Accounting

Human Resources

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

This training (presented ideally in a classroom or networked computer lab, onsite or
offsite, after the education and CM modules – including team building exercises) will
demonstrate 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 both
the back office and front office functions of an enterprise. Due to the great expense of
ERP installations, and due to the propensity for failure when these systems are not
properly implemented, it is important that training be included as a cornerstone of the
implementation plan. An ERP training plan must focus on the processing requirements
of a company, following a three-dimensional plan (who, when and what training needs
should be addressed). ERP training also must address the issues of education, change
management, knowledge management and task training. In this way, a company can
capitalize on the potential of ERP.

By maximizing the gains possible through ERP, “the 21 st 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 21 st Century, Evolving
Enterprise. [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 CRM
Integration, 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.p
df. [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.
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], 6
pages. 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], 5
pages. 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 Preparation
of 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 the
Heart 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, CIO
Magazine, 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 of
ERP, 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 ERP
Failures, 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], 4
pages. 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], 3
pages. 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.
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.
http://www.cio.com/archive/051501/faster_content.html. [1/4/2002].
Schneider, Polly. (March 1, 1999). Wanted: ERPeople Skills, CIO Magazine, CXO
Media, 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, CXO
Media, 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.
http://cadvision.com/isaca/Sep_Implementation_Risk_Mgmt_ISACA.ppt.
[2/27/2002].
Slater, Derek. (January 15, 1998). The Hidden Costs of Enterprise Software, CIO
Enterprise 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…and
You…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 / CXO
Media, 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 Parts
Shipments, Computerworld. [Online], 1 page. Available:
http://www.computerworld.com/cwi/Printer_Friendly_Version/0,1212,NAV47_S
TO40471-,00.html. [2/4/2002].
Varon, Elana. (May 15, 2000). Human Error, CIO Magazine, CXO Media, Inc.
http://www.cio.com/archive/051500/people_content.html. [1/8/2002].

Wheatley, Malcolm. (June 1, 2000). ERP Training Stinks, CIO.Com Magazine.
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]

Key to Effective ERP Implementation: Comprehensive Training

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (19)

Similar to Key to Effective ERP Implementation: Comprehensive Training

Similar to Key to Effective ERP Implementation: Comprehensive Training (20)

Recently uploaded

Recently uploaded (20)

Key to Effective ERP Implementation: Comprehensive Training