G O O D

I D E A S

The ERP Dilemma: Plain Vanilla

Versus Customer Satisfaction
Customization of an ERP implementation can interfere with schedules
and budgets, yet it makes users happier
By Jeffrey W. Noyes

major dilemma faces any project

manager responsible for implementing an enterprise resource
planning (ERP) system: How do you balance schedule and budget goals against
the benefits of customizing the ERP software? A recent EDUCAUSE Center for
Applied Research (ECAR) study on ERP
implementation projects1 found that
one of the most significant variables in
determining project success is the degree
of customization done to the system.
The less customization, the more likely
the project will be completed on time
and on budget. The study also found,
however, that with more customization,
the user community is happier with the
resulting capabilities of the system. Thus
the ERP project manager is on the horns
of a dilemmadoes she minimize customization to maximize her probability
of success? Or, does she allow more customization to maximize the long-term
satisfaction of her user community?2

Mitigating Factors
Two factors can minimize the ERP
dilemma for project managers and help
reduce the constant tussle over customization requests during implementation. One is the advent of next-generation ERP systems, and the other is
knowing the systems features well.

ERPThe Next Generation

The first factor in minimizing the ERP
dilemma is the newer generation of ERP
systems themselves. With them, you
can have sprinkles on your plain vanilla.

54

E D U C A U S E Q U A R T E R LY

Number 2 2003

These new systems have become increasingly rules-based, meaning the majority
of enterprise-specific values, limits, and
other parameters are entered into the
system and maintained through the use
of tables that can be accessed and maintained by the authorized, principal users
of the system.
In many versions of older-generation
ERP systems, most parameters of this
type are hard coded in the programs
making up the system and therefore
require IT staff to change and maintain
them each time a new release or upgrade
is installed. In addition, when values
were changed, the programs had to be
recompiled and the entire system
relinked. This usually required nontrivial amounts of system downtime. While
some earlier ERP systems did have tables,
they were not always easy to set up and
use. Changing the programs was sometimes easier than using the tables. As
ERP technology has matured, tables have
become a valuable asset to all involved.
With the increased use, and corresponding increased ease of use, of tables
in the newer generations of ERP systems, users can themselves design and
actually enter most of the parameters
that determine the business rules of the
system for use at their institutions. This
eliminates the need for IT assistance
and the time-consuming system regeneration process.
Finally, when new releases containing
fixes and upgrades need to be installed,
the tables are not disturbed (except in
the case of major system changes, which

occur fairly infrequently), and no special

work is required by the user or the IT
staff. Thus, the new table-based ERP systems allow greater flexibility (which
could reduce customization) while not
creating the ongoing burden of maintaining a locally modified system.

Know Your ERP System

The second factor is having a really
deep and thorough understanding of
both the functionality and capabilities
of the ERP system to be installed and of
the application(s) to be supported by
that system. Generally, campus users
and IT staff are not very familiar with the
functional and technical details of a
new system.
Frequently, during an ERP system
implementation users will request a particular function that they have not seen
(or do not remember seeing) demonstrated in the new system. The project
team may approve it if they determine
that the function has sufficient priority,
and a customization of the new system
results. Many times, however, a way (or
several ways) to accommodate the
requested function already exists in the
baseline system through the use of its
screens and tables, but lack of knowledge
and experience with the system prevents the users or the IT staff from being
aware of it. In these cases the approved
customizations are not necessary.

Getting the Right Talent

A good way to deal with the problem
of gaining in-depth knowledge of a to-

be-installed system is to engage a consultant. This person should have a strong

background with the particular ERP system and module(s) being installed and
the application at hand. It is also very
important to engage the consultant for
the duration of the implementation.
When a user requests a function, the
consultant can first engage in a
miniprocess review and
recommend an alternate best-practice
solution,
find a way (or ways) to accomplish
the requested function through the
use of the systems baseline screens
and tables, or
report to the project manager that a
customization would in fact be
required and recommend whether or
not it should be implemented.
The final decision is up to the institutions project team, of course. Practical experience shows that, with this
approach, most user requests can be
accommodated using the baseline functionality of the new system. Really

necessary customizations are nearly

eliminated.
In addition, a consultant who is on
site for the entire implementation of an
ERP project will learn the culture, people,
and particular policies and procedures
of the host institution. This knowledge
helps the consultant maximize the new
ERP systems flexibility and minimize the
customization. The consultant can even
anticipate requests for customization and
other issues and recommend solutions
and alternatives before issues escalate or
become critical.

Vanillaand Sprinkles, Too!

Flexibilities provided in the newer generation of ERP systems and the use of a
knowledgeable consultant over the life of
an implementation project can
minimize the customization required,
maximize the satisfaction of the user
base, and
reduce the stress of a project manager facing the question of whether to
customize.

These benefits minimize the ERP dilemma

for an implementation project manager
and increase the projects likelihood of
success. e

Endnotes
1. R. B. Kvavik, R. N. Katz, and Associates, The
Promise and Performance of Enterprise Systems, ECAR Research Study (Boulder, Colo.:
EDUCAUSE, Dec. 2002).
2. Another factor the project manager must
consider arises over the lifetime of the
implementation: The ECAR ERP study
also indicated that every dollar spent on
customization during implementation
results in a three-dollar cost each and
every time that customization must be
reinstalled in subsequent upgrades and
releases of the system, which normally
occur one or two times a year. While these
costs do affect the implementation budget, they can significantly affect the ongoing operating budget.

Jeffrey W. Noyes (jnoyes@utsa.edu) is CIO

and Associate Vice President for Information
Technology at The University of Texas at San
Antonio.

Number 2 2003

E D U C A U S E Q U A R T E R LY

55