1.

What are the different phases of ERP

implementation?
Ans. The ERP implementation project also has to go through different phases
(see

Fig. 22.1). There are no clear demarcating lines between these phases, and
in many cases one phase

will start before the previous one is completed. However, logical order is
followed. The different phases of the ERP implementation are

given below:

• Pre-evaluation screening

• Package evaluation

• Project planning phase

• Gap analysis

• Reengineering

• Customization

• Implementation team training

• Testing

• Going live

• End-user training

• Post implementation

Figure 22.1 ERP implementation life cycle—different phases. (ERP

Demystified)

Although these phases may seem very linear and distinct from each other, in
reality, the phases are

in fact quite fluid throughout an actual implementation. In many cases,

companies go through many

implementations—in different business units, different modules, or

manufacturing locations. Thus
at any given time, more than one of the phases may be operational. Some
companies opt for the one

and only ‘big bang’, while other companies favor sequential rollouts—each
company has different

needs. However, whether it is the ‘big bang’ method or sequential rollout,

the life cycle phases are

the same.

Pre-evaluation Screening

Once the company has decided to go in for the ERP system, the search for
the perfect package starts.

However, there are hundreds of ERP vendors—of all sizes and shapes—all
claiming to have the

solution that is ideal for you. Analyzing all the packages before reaching a
decision is not a viable

solution. It is also a time-consuming process. Thus, it is better to limit the

number of packages that

are evaluated to less than five. It is always better to do a thorough and

detailed evaluation of a small

number of packages, than to do a superficial analysis of dozens of packages.

Therefore, the company

should do a pre-evaluation screening to limit the number of packages that

are to be evaluated by the

committee.

Not all packages are equal—each has its own strengths and weakness. The
pre-evaluation process

should eliminate those packages that are not suitable for the company’s
business processes. One can

zero in on the few best packages by looking at the product culture of the
vendors, getting help from

external consultants, and most importantly finding out what package is used
by similar companies.
It is always better to look around to find out how the different packages are
performing in environments

similar to yours.

If one studies the history of the ERP packages and finds out how each
package evolved, then it

soon becomes evident that every ERP package grew out of the experience or
opportunity of a group

of people working in a specific business who created systems that could deal
with certain business

segments. It is generally accepted that most ERP packages are stronger in

certain areas than in others

and each one is trying hard to add functionality in areas where they have
been lacking. For example,

PeopleSoft is strong in HR and less so in manufacturing; Baan, on the other

hand, is historically

stronger in manufacturing than in financial, and so on.

The ERP packages evolved over time as the companies grew. The experience
gained from implementation,

the feedback by users, the need to enter into new markets, and pressure
from competitors

forced most ERP vendors to re-define and expand the scope of the activities
and functionality of

their products. The concepts were expanded upon, new functions were
introduced, good ideas were

copied from others, and so on. However still, each package has a history (or
origin) that determines

the type of business it is best suited for.

Therefore while making the analysis it is a good idea to investigate the

origins of the different

packages. Now, almost all packages cater to all business and service sectors.
It would be wrong to
say that a system that was developed initially for manufacturing is not
capable of catering to the

needs of another business sector, e.g. software development. The system

must have been thoroughly

re-vamped and re-designed to meet the needs of the diverse business

sectors that it is catering to.

However, it should be remembered that many ERP packages are still very
good in some areas, even

though they are capable of catering to the needs of other sectors.

Once you select a few packages after the screening, you can start the
detailed evaluation process.

Package Evaluation

The evaluation/selection process is one of the most important phases of the

ERP implementation

because the package that you select will decide the success or failure of the
project. Since ERP systems

involve huge investment, once a package is purchased it is not an easy task

to switch to another.

Thus, it is a ‘do-it-right-the-first-time’ proposition and there is no room for

error.

The most important factor that should be kept in mind when analyzing the
different packages

is that none of them are perfect. The idea that there is no perfect package
needs to be understood

by everyone in the decision-making team. The objective of the selection

process is not to identify

a package that covers each and every requirement (a perfect fit). The
objective is to find a package

that is flexible enough to meet the needs of the company, or in other words,
software that could be

customized to obtain a ‘good fit’.

Thus, once the packages to be evaluated are identified, the company needs
to develop the selection

criteria that will permit evaluation of all the available packages on the same
scale. To choose the best

system, the company should identify the one that meets the business needs,
matches the business

profile, and identifies with the business practices of the company. It is

impossible to get a system

that will perform exactly as the company does business, but the aim should
be to get the system that

has the least number of differences. Some important points to be kept in

mind while evaluating ERP

software include:

• Functional fit with the company’s business processes

• Degree of integration between the various components of the ERP system

• Flexibility and scalability

• Complexity

• User friendliness

• Quick implementation

• Ability to support multi-site planning and control

• Technology—client/server capabilities, database independence, security

• Availability of regular upgrades

• Amount of customization required

• Local support infrastructure

• Availability of reference sites

• Total costs including cost of license, training, implementation,

maintenance, customization,

and hardware requirements

It is always better to entrust on a selection or evaluation committee that will
do the evaluation

process. This committee should comprise of people from the various

departments (the functional

experts), top management (preferably the CIO or COO), and consultants

(package experts). The

selection committee should be entrusted with the task of choosing a package

for the company. Since

all business functions are represented and the management is involved, the
package that is selected

will have company-wide acceptance. The package experts or the consultants

can act as mediators or

play the role of explaining the pros and cons of each package.

Project Planning Phase

This is the phase that designs the implementation process. It is in this phase
that the details of how

to go about the implementation are decided. Time schedules, deadlines, etc.,

for the project are

arrived at. The project plan is developed. Roles are identified and
responsibilities are assigned. The

organizational resources that will be used for the implementation effort are
decided and the people

who are supposed to head the implementation are identified. The

implementation team members

are selected and task allocation is done. This phase will decide when to begin
the project, how to do

it, and when the project is supposed to be completed. This is the phase
which will plan what to do

in case of contingencies; how to monitor the progress of the implementation,

what control measures

should be installed and what corrective actions should be done when things
get out of control. A
committee constituted by the team leaders of each implementation group
usually does the project

planning. The committee will be headed by the ERP in-charge (usually the
CIO or COO). It will meet

periodically (during the entire implementation life cycle) to review the

progress and chart the future

course of actions.

Gap Analysis

This is arguably the most crucial phase in the success of the ERP
implementation. Put very simply,

this is the process through which companies create a complete model of

where they are now and

where they want to be headed. The trick is to design a model, which both
anticipates and covers any

functional gaps. It has been estimated that even the best ERP package,
customized to a company’s

needs meets only 80% of the company’s functional requirements.

The remaining 20% of these requirements present a problematic issue for

the company’s BPR.

One of the most affordable, albeit painful, solutions entails altering the
business to ‘fit’ the ERP

package. Of course, a company can simply agree to live without a particular

function (the cheap but

annoying solution). Other solutions include:

• Pinning your hopes on an upgrade (low cost but risky)

• Identifying a third-party product that might fill the gap (hopefully it also
partners with the ERP

packages, keeping interfacing to a minimum)

• Designing a custom program

• Altering the ERP source code (the most expensive alternative; usually
reserved for missioncritical
installations)

Reengineering

It is in this phase that human factors are taken into account. In ERP
implementation settings,

reengineering has two different connotations. The first connotation is the

controversial one, involving

the use of ERP to aid in downsizing efforts. There have been occasions where
high-level executives

have invoked the reengineering slogan and purchased an ERP package with
the aim of reducing significant

numbers of employees. While every implementation is going to involve some

change in job

responsibilities, as processes become more automated and efficient, it is

best to treat ERP as an investment

as well as a cost-cutting measure, rather than as a downsizing tool.

‘Downsizing’ is a business

practice that may have its place but it should not be cloaked within the
glossier slogan of reengineering

or justified by the purchase of an ERP package. ERP should engender

business change but should not

endanger the jobs of thousands of employees.

The second use of reengineering in the ERP field (or business process
reengineering (BPR) as it is

usually called), refers to an ERP implementation model initially designed and

used with much success

by the major ERP consulting firms. The BPR approach to an ERP

implementation implies that

there are really two separate but closely linked implementations involved on
an ERP site: a technical

implementation and a business process implementation. The BPR approach

emphasizes the human
element of necessary change within organizations. This approach is generally
more time-consuming

and has received its share of criticism for creating bloated budgets and
extended projects. However,

adherents of the BPR approach to ERP would argue that there is no way that
you can ignore the

human element to an implementation that involves significant changes in

responsibilities. As the

ERP market shifts to a mid-market focus and as all implementations are

becoming more cost-sensitive,

the BPR approach has come under some real scrutiny.

Customization

This is the main functional area of the ERP implementation. There is a bit of
mystique around the

customization process and for good reason; the Holy Grail of ERP
implementation is synchronizing

existing company practices with the ERP package. In order to do so, business
processes have to be

understood and mapped in such a way that the solutions arrived at match up
with the overall goals

of the company. However, companies cannot just shut down their operations
while the mapping

processes take place. Hence the prototype—a simulation of the actual

business processes of the company—

will be used. The prototype allows for thorough testing of the ‘to be’ model in
a controlled

environment. As the ERP consultants configure and test the prototype, they
attempt to solve any

logistical problems inherent in the BPR before the actual go-live

implementation.

Configuring a company’s system reveals not only the strengths of a

company’s business process
but also—and perhaps more importantly—its weaknesses. It is vital to the
health of the company

and to the success of the ERP implementation that those configuring the
system are able to

explain what will not fit into the package, where the gaps in functionality
occur. For example, a

company might have an accounting practice that cannot be configured into

the system or some

shipping process that will not conform to the package. The company
obviously needs to know

which processes have to change in the process of implementation. Finding

out what will work and

what won’t requires a knowledge of the business process itself and an ability
to work with people

throughout the company. Thus, people with such skills should be assigned to
these tasks. As a

rule, in most large implementations, the functional customizations are split

between the different

areas within the company, thus some will attend to HR, some will be involved
in financials, and so

forth.

ERP vendors are constantly striving to lower customization costs. Strategies

currently being

pursued include automation and pre-customization. SAP, for instance, has

pre-configured industry-

specific templates that can be tweaked for each individual company

(Accelerated SAP or ASAP

Solutions). Sage MAS 500 ERP system provides a set of customization tools
which includes a software

development kit and a customizer. Similarly, almost all the ERP vendors offer
some tools that
automate at least some part of the customization process. Many third-party
companies offer customization

tools to make the task of customization as easy as possible.

The current ERP industry push toward developing the mid-range market in
turn creates an added

incentive to reduce costs, encouraging the sought after mid-range

companies to feel they can afford

to implement a top-of-the-line ERP package. By creating a custom pre-

configured ERP module for

a particular industry—say a shoe manufacturing software prototype created

for a shoe manufacturer—

the need for hands-on custom customization is reduced, thereby keeping the
costs down. The

hope is that a kind of ‘question and answer’ format can be used to find out
the kinds of business process

information hitherto addressed through the hands-on customization process.

In theory, these

pre-configured tools should save time and money but every business is
unique and at least some

customization is unique to each project.

Implementation Team training

Around the same time that the customization is taking place, the
implementation team is being

trained, not so much on how to use the system, but how to implement it.
This is the phase where

the company trains its employees to implement and later run the system.
The ERP vendors and the

hired consultants will leave after the implementation is over. However, for
the company to be selfsufficient

in running the ERP system, it should have a good in-house team that can
handle the various
situations. Therefore it is very vital that the company recognizes the
importance of this phase

and selects employees with the right attitude—people who are willing to
change, learn new things,

and are not afraid of technology—and good functional knowledge.

Testing

This is the phase where you try to break the system. You have reached a
point where you are testing

real case scenarios. The system is configured and now you must come up
with extreme case

scenarios—system overloads, multiple users logging on at the same time

with the same query, users

entering invalid data, hackers trying to access restricted areas, and so on.
The test cases must be

designed specifically to find the weak links in the system and these bugs
should be fixed before going

live. Some of the different types of testing employed are:

• Unit testing: Testing the new and additional features in isolation to make
sure that the

subsystem or unit works as expected.

• Integration testing: Testing end-to-end business processes including

customizations,

enhancements, and interfaces to external systems.

• Acceptance testing: Testing done by the users working with real data to
find out whether the

system is functioning as expected and to find out any problems that the
users of the system

have about the systems functionality or usability.

• Security testing: Testing the user roles, access privileges, authorizations,

and other security
measures that are set up to ensure the security of the system. The objective
of this testing is to

find the loopholes or weaknesses in the system’s security and fix if there are
any.

• Performance and stress testing: Testing done to find out whether the
system is able to

perform as expected under normal business loads and also at huge increase
in the transaction

volumes—something that can happen in real life. The system should not fail
when there is

a spike in the transaction volume, and if that happens it must be fixed.

Inability to handle

occasional spike in transaction volumes (e.g. sudden increase in transactions

due to holiday

sales) can create a lot of problems including lost sales and customers. These
situations, if occurs,

should be fixed.

Going Live

This is the phase where ERP is made available to the entire organization. On
the technical side, the

work is almost complete: data conversion is done, databases are up and

running; and on the functional

side, the prototype is fully configured and tested and ready to go

operational. The system is

officially proclaimed operational even though the implementation team must

have been testing it

and running it successfully for some time. But once the system is ‘live’ the
old system is removed and

the new system is used for doing business.

End-user training
This is the phase where the actual users of the system will be given training
on how to use the system.

This phase starts much before the system goes live. The employees who are
going to use the

new system are identified. Their current skills are noted and they are divided
into groups based on

their current skill levels and based on this, training is imparted on the new
system. This training is

very important as the success of the ERP system is in the hands of the end-
users. Therefore, these

training sessions should give the participants an overall view of the system
and how each person’s

actions affect the entire system. In addition to these general topics, each
employee is trained on the

job or task that he/she is supposed to perform once the system goes live. It
is human nature to resist

change. Also many people are afraid of computers and other new
technologies. Hence, there will be

resistance to change. Another factor is that not all people will be successful
in making the changeover.

The company management should address these concerns and should take
necessary actions to

avoid failure. End-user training is much more important and much more
difficult (since most endusers

are not thrilled at having to change) than the implementation team training.
Companies are

beginning to take this phase seriously as there is now statistical evidence,

which shows that most

implementations fail because of a lack of end-user training.

Post implementation (Operation and Maintenance)

Once the implementation is over, the organizations enter the operation and
maintenance phase
(O&M). O&M phase begins with a period of initial struggle until people
become comfortable in their

roles and tasks. The duration of this stage depends on how effective the
training was. If the training

given to the employees was efficient and effective, the initial teething
problem will be overcome soon

and the system becomes stable. According to many ERP experts and
consultants, the period required

for the stabilization varies between 3 and 9 months, and during this period
one can expect a dip in

performance due to the continued training needs and fine tuning of the
processes.

One important factor that should be kept in mind is that the post-
implementation phase is very

critical. Once the implementation is over the vendors and the hired
consultants will leave. To reap

the full benefits of the ERP system, the system should get enterprise-wide
acceptance. There should

be enough employees who are trained to handle the problems that might
crop up. There should be

people within the company who have the technical prowess to make the
necessary enhancements to

the system as and when required.

The system must be upgraded as and when new versions or new

technologies are introduced.

Here, the organization should think in terms of the incremental benefits of

the new enhancements

because with any upgrade or enhancements, there will be a lot of other

aspects like user training

that have to be considered. Therefore, instead of going in for upgrade as and

when a new version is
announced by the vendor, the organization should first analyze the costs and
benefits.

Maintenance activities also will start shortly after implementation and

operation. The annual

maintenance costs should be budgeted during the planning phase itself. The
annual maintenance

costs will come to about 20% of the ERP implementation costs. A system
upgrade can cost as much

as 25–33% of the implementation cost. The maintenance activities include

preventive maintenance

(regular maintenance to keep the system functioning properly), emergency

or unscheduled maintenance

(maintenance done to prevent some damage from occurring to the system or

data), breakdown

maintenance (maintenance performed to correct some problem that have

caused the system

to stop functioning), and system updates (applying the patches, bug fixes,
etc., provided by the ERP

vendor).

The post-ERP organization will need a different set of roles and skills than
those with less integrated

kinds of systems. At a minimum, everyone who uses these systems needs to

be trained on

how they work, how they relate to the business process, and how a
transaction ripples through the

entire company whenever they press a key. The training will never end; it is
an ongoing process; new

people will always be coming in and new functionality will always be entering
the organization.

Just as courtships and honeymoons are different from marriages, living with
ERP systems will
be different from installing them. Projects for implementing the systems get
a lot of resources and

attention, but it is how the organization lives with ERP systems that have
more to do with the value

that one receives from them rather than the quick decisions made during
installation.

++++++++++++++++++++++++