Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
Tailoring ERP Systems: A Spectrum of Choices and their Implications
Lars Brehm & Armin Heinzl
Department of Information Systems (BWL VII),
University of Bayreuth, Germany
{Lars.BrehmHeinzl}@uni-bayreuth.de
Abstract
The IS literature distinguishes between custom-built and
off-the-shelf software. Enterprise resource planning
(ERP) packages are often viewed as off-the-shelf
software, because adopters implement them by setting
parameters (called configuration), rather than by
traditional programming. Making changes to ERP
software code (called modification) is usually strongly
discouraged by vendors and implementation consultants.
Nevertheless, field research has shown that many
companies have had to modify ERP software in various
ways to meet essential business needs. This suggests that
ERP packages do not fit cleanly into the custom/off-theshelf distinction. In this paper, we describe a portfolio of
tailoring options between configuration and modification,
with important implications for implementation risk and
the difficulty of ERP system upgrades. We discuss the
implications of our framework for practitioners and for
further research on ERP systems.
1. Introduction
The widespread adoption of ERP systems in the 1990s
has rekindled interest in the implementation of software
packages, a topic about which there was some mention in
the 1980s in IS textbooks (e.g., early editions of Laudon
and Laudon’s popular textbook [16]) and journals [19,
20]. Conventional wisdom holds that “vanilla
implementations” of ERP packages such as SAP R/3,
Peoplesoft, Oracle Applications, and Baan are much more
likely to be successful than implementations that require
modifications of package code [2, 6], but Bashein et al.
[3], Markus and Tanis [21], and Soh et al. [27] have
reported that many companies have had to modify ERP
software to meet essential business needs.
Because package modification is posited as a factor
both in ERP project success and in companies’ business
success with ERP packages, it seems important to develop
a fine-grained understanding of ERP package tailoring.
The researcher wants to be able to measure the nature and
extent of package tailoring as an independent variable that
M. Lynne Markus
Department of Information Systems, Faculty
of Business, City University of Hong Kong
islynne@cityu.edu.hk
predicts or explains success. Practitioners want to know
how much and what kinds of tailoring pose a threat to
project success. At present, however, the literature makes
only the most basic distinction— between ERP packages
that have merely been “configured” and ERP packages
that have been “modified” [9, 22]. ([27] is an exception.)
Configuration (also called “customization” in SAP
parlance) refers to setting parameters in the package to
reflect organizational features; modification refers to
changing package code to perform unique business
processes, often resulting in loss of vendor support. We
use the word tailoring to encompass both configuration
and modification and a range of options in between. The
purpose of this paper is to show that the tailoring of ERP
packages is actually much more complicated than the
conventional distinction between configuration and
modification would allow. Based on an extensive review
of ERP literature (both practitioner and academic),
fieldwork from several investigations of ERP
implementations, and interviews with implementation
consultants and ERP vendor representatives, we present a
typology of ERP tailoring options. This typology can be
used in several ways. First, it can be used by academicians
to differentiate among ERP projects in studies of
implementation success and business value. Second, it can
be used by practitioners to assess the risks of
implementation projects and the likely future difficulties
when upgrading ERP systems.
2. Prior research
Although ERP packages have been one of the most
significant challenges for IS practitioners in the last
decade, relatively little has been written about ERP
systems to date, and most of the literature has focused on
project management and implementation [2, 4, 6, 7, 13,
18, 21]. Far less attention has been devoted to the postimplementation activities of maintenance and upgrades.
One of the most salient characteristics of ERP
packages is that they are in fact packages— that is,
software programs developed by independent software
Authorized licensed use limited to: Aarhus University. Downloaded on November 28,2023 at 07:34:20 UTC from IEEE Xplore. Restrictions apply.
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
1
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
vendors for sale to organizations that use them. Packages
are designed to meet the general needs of a class of
organizations, rather than the unique needs of a particular
organization, as is the case in custom software
development.
By
adopting
standard
packages,
organizations can substantially reduce the costs, risks and
delays associated with custom software development. And
they can benefit from the on-going support services
provided for packages by vendors and consultants. These
support services, which can be a major feature in package
adoption, are discussed below. The contention of this
article is that the costs, benefits, and risks of ERP
packages are related to the nature and extent of ERP
system tailoring.
2.1 Tailoring and the implementation of ERP
systems
ERP systems do not neatly fit the traditional distinction
between “custom-built” software and “off-the-shelf”
packages [17] in several important respects. First, the
scope of ERP packages is much broader than that of early
software packages (like mainframe-based financial
software or PC-based personal productivity tools). ERP
packages integrate many formerly discrete applications
around a common database. They enable adopters to
integrate data and processes throughout the organization,
and they support nearly all functions, e.g., accounting,
human resources, operations and logistics [9]. This means
that they are much more complex than traditional
packages, requiring more knowledge, effort and skill to
adapt them to the characteristics of a particular
organization.
Second, ERP packages allow for a great deal more
flexibility in the way a company operates than traditional
packages do. In traditional packages, business procedures
were “hard coded;” making them inflexible. Adapting
them to the unique business procedures of a particular
organization usually required modifications— changes in
package code.
It should be noted that modifying software packages
(whether traditional or ERP packages) is often strongly
discouraged. Software license agreements may deny
adopters access to source code and explicitly prohibit the
making of modifications. Vendors may refuse to make
changes themselves, claiming high development and
maintenance costs and low market demand. Even when
vendors allow access to the source code by the adopter or
a third party for the purpose of making modifications, they
may refuse to provide future support for the package. In
addition, adopters are warned that the risks involved in
making package modification are great [16].
In contrast to the inflexibility of traditional packages,
ERP packages are generally structured so that both data
and many procedures are represented as parameters in
tables— many thousands of tables in the most elaborate
packages. Implementation involves setting parameters to
represent both fixed organizational data (such as the
number and location of sales offices) and whether and
how particular processes should operate. As a result, many
more unique organizational circumstances can generally
be supported by ERP systems without program
modifications than is true for traditionally designed
packages. But, because the packages are integrated as well
as flexible, setting parameters in one module of the
package can have unintended consequences in other
modules, increasing the skill and effort required to
configure the package well. Further, the sheer size and
complexity of these packages means that implementers
may be unaware of exactly what an ERP package can and
cannot do, leading to configuration errors and unnecessary
modifications [21].
Because of the way ERP packages are designed, some
tailoring is always required to get them up and running.
But the extent of the tailoring can vary from one
organization to the next, based on a number of factors.
One factor is the degree of fit between the features and
functions of the package and the business processes of
particular organizations. The earliest releases of ERP
packages were developed for “generic” organizations
(usually manufacturing) and not particularized to different
industry sectors. This usually resulted in a relatively low
degree of fit between package and organizational features,
and a great deal of effort was required to make an
appropriate configuration.
Today, most ERP packages come in different industryspecific “flavors,” but in some cases the degree of fit may
still be low. For example, an organization with several
discrete-part manufacturing plants may buy a version of
the software tailored to fit those plants well, only to find
that it doesn’t fit the organization’s one continuous
process facility. And organizations whose products exhibit
dimensionality (e.g., clothing and footwear manufacturers)
may find that the inventory accounting of a generic ERP
package (designed for discrete-part manufacturing) does
not meet their needs. Thus, a fair number of organizations
may be motivated to consider package modification,
despite the problems modification is likely to entail.
One marketplace response to the lack the featurefunction fit in particular industry segments has been the
emergence of “bolt-on” packages . Bolt-ons are extensive
modifications of a basic ERP package developed by a
third-party independent software vendor (under license
agreements with the original vendor) to meet the needs of
a particular customer segment. For example, a third-party
vendor has implemented a flavor of theBaan package that
accommodates product dimensionality. By means of boltons ERP adopters can achieve greater feature-function fit
with lower configuration effort, without losing the
Authorized licensed use limited to: Aarhus University. Downloaded on November 28,2023 at 07:34:20 UTC from IEEE Xplore. Restrictions apply.
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
2
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
advantages of ongoing vendor support. Though the
ongoing development efforts of ERP vendors and thirdparties, many, but not all, business processes are now
supportable by ERP packages.
A second factor that influences the amount of tailoring
is the organization’s willingness to adapt its practices to
the package, when the two differ (and when the package’s
processes would actually work for the business, which as
mentioned above, is not always the case). The business
practices of many organizations have evolved over time,
acquiring idiosyncrasies that may not be strictly necessary
or efficient. Nevertheless, the organization may be
unwilling to abandon them. Thus, many ERP adopters
must face a painful choice when adopting a package that
works differently than they do. First, they can adopt the
business process built into the software, making the
necessary organizational changes such as departmental
reorganization and shifts in job duties. Second, they can
just live with the lack of fit between the package and their
procedures [22], which entails problems and inefficiencies
such as redundant manual processes and other
workarounds. Finally, they can try to adapt the ERP
package to the organization’s existing business process.
This is where tailoring comes in. Figure 1 shows these
three main alternatives in ERP implementation.
Capabilities of
ERP package
To-be business
processes
Process follows software
or
Software follows process
Tailoring ERP
package
and/
or
Organizational
adaptation
- Configuration
- Modification
Live with
problems
and/
or
ERP Implementation process
.
In this paper we are interested in the tailoring of ERP
packages— that is, in technical, rather than organizational,
adaptation. We argue that the effort required for system
implementation by the ERP adopter and the risks
associated with implementation depend on the types and
extent of ERP package tailoring, discussed in Section 3.
2.2 Tailoring and the maintenance of ERP
systems
Package vendors and consultants provide (for a fee) a
variety of support services that can reduce the burden on
system adopters. The availability of these services can be
a major factor in the decision to adopt packages. For
example, ERP adopters often view these packages as a
way to eliminate their considerable backlogs of legacy
system maintenance and enhancement projects [21].
The support services provided by package vendors
include help-desks and an ongoing stream of releases and
upgrades to fix bugs, add new functionality to the
package, include changes necessitated by external factors
(e.g., human resources changes related to new tax laws),
keep pace with competition in the software marketplace,
and accommodate technical developments (e.g., the
Internet) [5]. But vendor support does not entirely relieve
the ERP system adopter from maintenance and post
implementation activities. While the vendor is responsible
for correcting bugs in the source code, the adopter
sometimes has to implement changes in the program code
to fix urgent bugs. Further, the adopter is solely
responsible for correcting bugs in the configuration (e.g.
wrong parameter settings). Hirt and Swanson [11] show
that ERP maintenance activities are distributed across the
vendor, the adopter, and external consultants. Table 1
categorizes ERP maintenance activities according to
Swanson [30] with extensions by Pressman [24] and
Krogstie [15].)
Figure 1: Three broad choices in ERP
implementation (modified from [22])
Table 1: ERP system maintenance activities: participants and characteristics
External
Technically
Maintenance activities
Vendor
Adopter
Consultants
oriented
Corrective
ü
Adaptive
ü
Perfective
- non-functional
(e.g. EnjoySAP GUI)
- functional
Preventive
Business
oriented
r
þ
r
ü
þ
ü
ü
ü
ü
ü
r
r
(Legend: ü = main task for this participant; þ = secondary task for this participant; r = is related to)
Authorized licensed use limited to: Aarhus University. Downloaded on November 28,2023 at 07:34:20 UTC from IEEE Xplore. Restrictions apply.
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
3
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
As shown in Table 1, the adopter of an ERP package is
still responsible for significant aspects of perfective
maintenance, e.g. fixing configuration bugs, and
implementing upgrades, perhaps with the help of external
consultants. In this paper, we argue that the effort required
for system maintenance and post implementation by the
ERP adopter depends on the types and extent of ERP
package tailoring, discussed below.
3. A typology of tailoring choices
Through analysis of literature on ERP implementations
and our own interview data, we have identified 9 different
types of ERP package tailoring (see Table 2). Further
research may indicate the need for more or finer
distinctions. For the present, however, we believe this
framework is adequate for explaining or predicting project
success, assessing project risk, and predicting
maintenance and post implementation effort.
The tailoring types in Table 2 are choices made by a
company adopting an ERP package and applying it to its
own needs. In other words, we distinguish between the
ERP package delivered by the vendor and a specific
instance of an ERP system implemented by a company to
support its business processes, and our focus is on the
latter. A particular company may choose to tailor a
package by using almost any combination of the tailoring
types and by using them to a greater or lesser degree. A
company’s tailoring choices may not be best for its
situation: several researchers have noted the occurrence of
“unnecessary modifications” made out of ignorance of
package functionality [cf. 21].
The last column of Table 2 refers to a general 3-layer
model of application systems: communications layer
(contains communication with users, normally through
graphical user interfaces, and with other application
systems), application layer (definition of application
functions in program code, e.g. calculation of a MRP II
run) and database layer (management of the relevant data,
e.g. a relational database management system) [10].
Entries in the column show the layer or layers involved in
a particular ERP system tailoring type.
Table 2: Typology of ERP tailoring types
Tailoring Type
Description
Configuration
Setting of parameters (or tables), in order
(customization,
to choose between different executions of
in SAP parlance) processes and functions in the software
package
Bolt-ons
Implementation of third-party package
designed to work with ERP system and
provide industry-specific functionality
Screen masks
Extended
reporting
Examples
Define organizational units; create
standard reports; formulate availableto-promise logic; use of a standard
interface to an archive system
Provide ability to track inventory by
product dimensions (e.g., 2 500 m.
lengths of cable do not equal 1 1000
m. length)
Integrate three screens into one
Creating of new screen masks for input
and output (soft copy) of data
Programming of extended data output and Design new report with sales revenues
reporting options
for specific criteria
Workflow
programming
Creating of non-standard workflows
Set up automated engineering change
order approval process
User exits
Programming of additional software code Develop a statistical function for
in an open interface
calculating particular metrics
ERP
Programming
Interface
development
Programming of additional applications,
without changing the source code (using
the computer language of the vendor)
Programming of interfaces to legacy
systems or 3rd party products
Create a program that calculates the
phases of the moon for use in
production scheduling
Interface with custom-build shopfloor-system or with a CRM package
Package code
modification
Changing the source-codes ranging from
small change to change whole modules
Change error message in warning;
modify production planning
Layer
Involved
All layers
All layers
Communication
layer
Application
layer and/ or
database layer
Application
layer and/ or
database layer
Application
layer and/ or
database layer
All layers
Application
layer and/ or
database layer
Can involve all
layers
Authorized licensed use limited to: Aarhus University. Downloaded on November 28,2023 at 07:34:20 UTC from IEEE Xplore. Restrictions apply.
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
4
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
The order in which the types are shown in Table 2
represents a very rough indication of the “impact” of
tailoring, e.g., how severely the ERP system itself is
changed through tailoring and how much effect is
required of adopters to employ a tailoring type.
Generally speaking, the tailoring types at the top of the
chart are “lighter” in impact than those at the bottom.
The placement of bolt-ons in our typology deserves
some discussion. We have placed them at the low end,
because as a general rule, they reduce the effort required
to configure and otherwise tailor an ERP package for
industry-specific needs. Further, the third-party vendor
of the bolt-on is responsible for quality assurance and
maintenance, reducing the burden on the adopter. On the
other hand, bolt-ons introduce complexity. The quality
of the bolt-on may depend on the quality of the
communication between the ERP vendor and the bolt-on
developer. Further, there may be a “release lag”, where
the bolt-on vendor is supporting an older release of ERP
system that the one the ERP vendor is currently offering
to customers. This is likely to be an issue during ERP
system upgrading. Thus, the “weight” assigned to the
bolt-on type of tailoring is a matter of some debate.
Naturally, a host of issues other than tailoring type
will affect “impact.” One is how extensively a particular
type of tailoring is applied. Extensive use of user exists
may entail more impact than minor use of interface
development. Table 3 presents some specific examples,
drawn from literature and our research, of low and high
levels of usage of the 9 tailoring types.
Table 3: Specific examples of ERP tailoring types
Tailoring
Low Level of Usage
Type
Configuration SAP R/3 Ready-To-Run solutions are a
preconfigured R/3 system for SME [8]
High Level of Usage
Medium-sized manufacturer of electronic parts ($35 M
revenue, 380 employees) extreme reconfiguration after
splitting the company into three independent legal entities
(MIS Director interviewed by Brehm, 2-23-00)
Bolt-ons
Global manufacturing of power and telecommunications
cables adopted a bolt-on that accommodated the
dimensionality of its inventory. This effort substantially
increased the complexity of the project, since the
company wanted the functionality of the latest ERP
system release, but the bolt-on vendor was supporting an
earlier release. (Interviews by Markus, 9-98)
Screen masks
Global manufacturer of metal cutting tools ($1,9 B
revenue, 13’ employ ees): heavily changed screen masks in
sales & distribution area to satisfy users’ requirements
(MIS Director Europe interviewed by Brehm, 4-13-00)
Extended
Revel Asia: developed custom reports to
Microsoft Corp: developed custom reports and analysis
reporting
satisfy the needs of the Finance department capabilities using warehoused SAP data, delivered via the
[14]
intranet [3]
Workflow
Microsoft Corp: used workflow to
programming automatically route purchase orders for
approvals prior to execution by SAP [3]
User exits
Novem Car Interior Design: uses some
programs in user exits in order to enrich
data structures of their sales information
system [1]
ERP
Jo-Ann Stores Inc: had to add functionality Compaq: developed its own forecast and orderProgramming to the ERP system for tracking seasonal
management module in the computer language of the ERP
products and managing pricing and
package [9]
promotion [28]
Interface
Siemens Power Corp.: decision whether to Hershey Food Corp.: tried to tie their new ERP system
development program an interface or use an alternative
together with two packages for SCM and CRM [23]
way of connecting system was made on a
American Standard Companies: developed extensive
case-by-case basis [11]
interfaces between “best-of-breed” ERP systems and
custom developed applications [3]
Authorized licensed use limited to: Aarhus University. Downloaded on November 28,2023 at 07:34:20 UTC from IEEE Xplore. Restrictions apply.
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
5
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
Package code ComputerCo case site: did some package
Volkswagen AG: heavily modified its new ERP system
modification code modifications, but this did not
for its central parts warehouse in Germany (and had
invalidate vendor support [12]
trouble delivering spare parts) [29]
Global manufacturer of pumps and valves:
($1 B revenue, 14’ employ ees) modified
parts of the production module code of the
ERP system of one business line in order to
meet its production process requirements
(MIS Director of this business line
interviewed by Brehm, 4-10-00)
A second factor is the number of different tailoring
types used, which may be an indicator of tailoring
complexity and is plausibly related to tailoring impact or
risk. A third factor how well the tailoring is done: tailoring
can introduce bugs into otherwise working code. A fourth
is the degree to which tailoring changes the data stored in
the system or the data structures. A fifth factor is
interdependence among tailoring efforts. A sixth is the
degree to which tailoring can be “protected” when the
system is upgraded. A seventh factor is organizational
complexity and geographic dispersion, which influence
the scope of tailoring effort.
Clearly then, it can be a challenge to assess the impact
of ERP system tailoring. Detailed measurement studies in
in-depth case studies are clearly warranted. In the absence
of such research, we propose a surrogate measure based
on the typology in Table 2. We suggest that the impact or
risk of ERP system tailoring can be approximated by a
formula that factors in the number of different tailoring
types used, the level of usage of each type (from low to
high as shown in Table 3) and the “weightiness” of each
type (roughly indicated by the placement of the tailoring
types in the typology, with configuration at the top of the
chart representing light tailoring, and modification at the
bottom representing heavy tailoring). Therefore, impact or
risk of tailoring can be measured as the sum, over all
tailoring types, of the tailoring type’s weight factor
(ranging from light to heavy) times a level factor (extent
of use of the tailoring type, ranging from low to high). The
precise values of the weight factors are a promising topic
for future research.
The impact of ERP system tailoring as a function of the
number of tailoring types, the weight of the types used,
and the level of use of each type can be depicted by
diagrams such as Figure 2. Figure 2 presents the tailoring
profiles of two hypothetical projects. Company 1 has
configured its ERP system to fit its organizational
characteristics, but has made only low use of two other,
more weighty, forms of tailoring— extended reporting and
user exits. By contrast, Company 2 has made extensive
use of several forms of tailoring, including code
modification. We would predict that Company 2 is much
more likely to run into implementation and postimplementation (e.g., upgrade) difficulties than Company
1 and that Company 2 is at much greater risk of missing
schedule, cost, and performance targets.
not low
used level
high
level
Configuration
Company 1
Bolt-ons
Screen masks
Extended reporting
Company 2
Workflow
programming
User exits
ERP Programming
Interfaces
development
Package code
modification
Figure 2: Measuring the impact of
ERP system tailoring
4. Applying the typology
The representation found in Figure 2 may be useful for
helping practitioners assess risk and plan appropriate risk
mitigation efforts. The basis for the analysis can be the
whole project or a specific area of the project, e.g.
production planning and control in one line of business.
The tailoring typology presented here can also play an
important role in academic research on ERP system
“success” [21].
Authorized licensed use limited to: Aarhus University. Downloaded on November 28,2023 at 07:34:20 UTC from IEEE Xplore. Restrictions apply.
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
6
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
4.1 Using the typology to predict ERP project
success
The ERP package tailoring typology can be used to
predict success both during the initial implementation
phase and during the maintenance and post
implementation phase of the ERP system life cycle.
4.1.1. Implementation phase. As noted earlier in this
paper, conventional wisdom holds that ERP systems
should be implemented without modification, because
modification is a risk factor that contributes to project
failure. Our contention in this article is that there are many
options between configuration and modification and that
implementation risk is a function of an organization’s
type, nature and extent of tailoring. We therefore
hypothesize:
H1a: The greater the “impact” of tailoring on the ERP
system (as defined in section 3), the more likely it is
that the ERP system implementation project will
encounter difficulties and suffer on cost, schedule and
performance metrics.
On the other hand, tailoring increases the degree of
feature-function fit between the ERP system and the
organization, which is likely to result in an easier
“implementation” in human terms— lower resistance,
reduced training needs, less organizational adaptation— as
well as in greater business success Therefore, we
hypothesize that:
H1b: The greater the “impact” of tailoring on the ERP
system (as defined in section 3), the more likely it is
that organizational adaptation to the ERP system will
be easy and that the system will meet the needs of the
business.
The ERP adopter is likely to face trade-offs between
meeting business requirements and managing the project
risk associated with tailoring. Therefore, we hypothesize
that:
H1c: The more willing an ERP adopter is to change
organizational business processes, the more likely it is
that the ERP adopter will pursue business objectives
through light, rather than heavy, tailoring types.
Finally, as noted above, the heavier tailoring types are
often chosen out of lack of knowledge about ERP
packages capabilities. Therefore, we hypothesize that:
H1d: The greater the knowledge implementers have
about their ERP packages, the more likely they are to
address business objectives with light, rather than
heavy, tailoring types.
These hypotheses extend the scope of existing
frameworks for analyzing risk factors in ERP
implementation [25] and can be tested empirically.
Naturally, they assume adequate project management, e.g.
good planning and appropriate staffing.
4.1.2 Maintenance and post implementation phase.
Through new releases ERP system vendors fix bugs and
add new functionality, potentially involving changes in all
three layers of the ERP system: presentation or
communication, application, and database. Consequently,
because the tailoring done by an ERP adopter may have
changed these same layers in an earlier release, the
adopter may find it impossible to implement a newrelease
while preserving its investments in tailoring. Research has
shown that ERP system modification is related to upgrade
difficulties [21]. And, indeed, some organizations have
resolved to eliminate modifications after finding that
“upgrading” required a complete re-implementation of
ERP software.
The tailoring types are likely to affect upgrading in
different ways. For example, parameters set during
configuration should be unaffected by a newrelease. This
is a major task of the vendor and one of the benefits
adopters expect from packages. However, if some new
functions are provided in the upgrade, the adopter may be
required to set parameters to configure them. The other
tailoring types require greater effort since more system
layers are involved. For example, screen masks may have
to be reprogrammed if the underlying fields have been
changed in a new release or if new fields have been added,
but not if only the logic has been changed. A modification
of package code will have to be thoroughly tested and
may have to be reprogrammed every time a data field,
software function, or variable is changed in a newrelease.
The level of usage of tailoring types will also influence
the effort required for upgrading ERP systems. The more
complex a tailoring effort (i.e., large, interdependent with
other changes, or not protected against overwriting with
new software code), the more likely it is to require greater
effort in maintenance and post-implementation.
Some ERP vendors offer ERP “extensions”— separate
packages for capabilities such as data warehousing or
supply chain management. These extensions are tightly
integrated with the ERP system. Heavy tailoring can,
therefore, prevent an organization from benefiting from
these extensions or may require the time-consuming and
expensive programming of specific interfaces [26].
Table 4 presents an estimate, based on our research, of
how much effort ERP package tailoring creates for ERP
adopters during system maintenance and post
implementation.
Authorized licensed use limited to: Aarhus University. Downloaded on November 28,2023 at 07:34:20 UTC from IEEE Xplore. Restrictions apply.
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
7
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
Table 4: Consequences for system maintenance:
upgrades and conversions
Tailoring Type
Configuration
Bolt-ons
Screen masks
Extended
reporting
Workflow
programming
User exits
ERP
Programming
Interface
development
Package code
modification
Effort Required for System
Maintenance and Post
Implementation
None/ slight
Depends on coordination between
ERP vendor and bolt-on vendor
Slight/ moderate
Moderate/ heavy
Moderate/ heavy
Heavy
Heavy, if data from the ERP
application are used
Heavy/ very heavy
Very heavy
Based on this line of argument, we hypothesize that:
H2: The greater the “impact” of tailoring on the ERP
system (as defined in section 3), the more likely it is
that that a company will experience difficulties when
attempting to upgrade to a later package release or
convert to a later package version.
Again, this hypothesis is amenable to empirical test.
4.2 Tailoring and competitive advantage
An intriguing question raised by ERP systems is the
extent to which they contribute to, or detract from, a user
company’s competitive advantage as a differentiator. For
example, Davenport [9] has argued that nearly every
company in the personal computer, semiconductor and
petrochemical sectors uses the same ERP package (SAP
R/3), with consequent threat to these companies’
competitive advantage. Indeed, Davenport claimed that
one company (Compaq) programmed an extension to its
ERP system (a custom forecasting module) to gain
competitive advantage relative to companies’ using the
package as-is.
Our analysis of tailoring types, however, suggests that,
even without new module development, there can be wide
variations in what a single ERP package does for the
companies that adopt it. Through various forms of
tailoring, companies may be able to build unique
functionality into a standard ERP system. At the same
time, however, companies need to weigh the potential for
differentiation against the greater risks tailoring entails
during implementation and upgrading.
5. Conclusions and future research
In this article, we have attempted to show that
companies confront a broad spectrum of choices when
they implement ERP packages. The number, type and
extent of tailoring efforts have important implications for
the risks faced and outcomes realized by the companies
that implement ERP— ERP tailoring may even be a factor
in a company’s competitive advantage!
From the practitioner’s perspective, our typology poses
additional research questions:
• In what ways can each tailoring option be applied in
order to minimize the implementation and postimplementation risks involved?
• Are there “best practice” examples that indicate a
“good” trade-off between controllable implementation
risks and high competitive differentiation through
extensive tailoring?
IS academics might be interested in the following
research issues:
• How can we capture more precisely the technical
complexity induced by various tailoring types?
• Since software quality has never been a unidimensional construct, which dimensions are most
useful for capturing the technical complexity induced
by tailoring types?
• Can we elaborate generalizable relationships between
tailoring types and environmental factors like
organizational or technical characteristics?
• Does extensive tailoring really promote user
acceptance and business success?
Answering these questions will be a challenging but
rewarding research endeavor.
6. Acknowledgement
The authors would like to thank the participating
interviewees as well as the reviewers for their helpful
comments.
7. References
[1] M. Ackermann and L. Brehm, "Developing a sales
information system prototype with SAP R/3," Information
Management & Consulting, vol. 14, no. 4, 1999, pp. 49-56.
[2] N.H. Bancroft, H. Seip, and A. Sprengel, Implementing SAP
R/3, 2nd ed., Greenwich: Manning, 1998.
[3] B.J. Bashein, M.L. Markus, and J.B. Finley, Safety Nets:
Secrets of Effective Information Technology Controls,
Morristown, NJ: Financial Executives Research Foundation
Inc., 1997.
Authorized licensed use limited to: Aarhus University. Downloaded on November 28,2023 at 07:34:20 UTC from IEEE Xplore. Restrictions apply.
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
8
Proceedings of the 34th Hawaii International Conference on System Sciences - 2001
[4] P. Bingi, M.K. Sharma, and J. Godla, "Critical Issues
Affecting an ERP Implementation," Information Systems
Management, vol. 16, no. 3, 1999, pp. 7-14.
[5] L. Brehm and M.L. Markus, "The Divided Software Life
Cycle of ERP Packages," in Proceedings of 1st Global
Information Technology Management (GITM) World
Conference, Memphis (Tennessee, USA), 2000, pp. 43-46.
[6] C. Brown and I. Vessey, "ERP Implementation Approaches:
Toward a Contingency Framework," in Proceedings of
Twentieth International Conference on Information Systems,
Charlotte, North Carolina, 1999, pp. 411-416.
[7] S. Buckhout, E. Frey, and J.J. Nemec, "Making ERP
Succeed: Turning Fear Into Promise," Journal of Strategy and
Business, vol. 17, no. 2, 1999, pp. 60-72.
[18] S. Lozinsky, Enterprise-wide software solutions :
integration strategies and practices, Reading, Mass.: AddisonWesley, 1998.
[19] H.C. Lucas, Jr., E.J. Walton, and M.J. Ginzberg,
"Implementing Packaged Software," MIS Quarterly, vol. 12, no.
4, 1988, pp. 537-549.
[20] R.K. Lynch, "Nine Pitfalls in Implementing Packaged
Applications Software," Journal of Information Systems
Management, vol. 2, no. 2, 1985, pp. 88-92.
[21] M.L. Markus and C. Tanis, "The Enterprise Systems
Experience - From Adoption to Success," in R.W. Zmud, ed.,
Framing the Domains of IT Research: Glimpsing the Future
Through the Past, Cincinnati, OH: Pinnaflex Educational
Resources, Inc., 2000, pp. 173-207.
[8] D. Callaghan, R/3 Ready-to-Run on 400, Midrange Systems,
Vol. 11, No. 9, June 29 1998, p. 14.
[22] E.W. Martin, Managing information technology : what
managers need to know, 3rd ed., Englewood Cliffs, NJ: Prentice
Hall, 1999.
[9] T.H. Davenport, "Putting the enterprise into the enterprise
system," Harvard Business Review, vol. 76, no. 4, 1998, pp.
121-131.
[23] E. Nelson and E. Ramstad, "Hershey's Biggest Dud Is Its
New Computer System," The Wall Street Journal, New York,
October 29 1999, p. 1.
[10] O.K. Ferstl and E.J. Sinz, Grundlagen der
Wirtschaftsinformatik - Band 1, 3rd ed., München: Oldenbourg,
1998.
[24] R.S. Pressman, Software engineering : a practitioner's
approach, 4th ed., New York: McGraw-Hill, 1997.
[11] S.G. Hirt and E.B. Swanson, "Maintaining ERP:
Rethinking Relational Foundations,"MISQ, under review.
[12] C.P. Holland, B. Light, and P. Kawalek, "Beyond
Enterprise Resource Planning Projects: Innovative Strategies for
Competitive Advantage," in Proceedings of 7 th European
Conference on Information Systems, Copenhagen, Denmark,
1999, pp. 288-301.
[13] M. Kirchmer, Business process oriented implementation of
standard software : how to achieve competitive advantage
quickly and efficiently?, Berlin: Springer, 1998.
[14] C. Koh, C. Soh, and M.L. Markus, "A Process Theory
Approach to ERP Implementation and Impacts: The Case of
Revel Asia," Journal of Information Technology Cases and
Applications, vol. 2, no. 1, 2000, pp. 4-23.
[15] J. Krogstie, "On the Distinction between Functional
Development and Functional Maintenance," Software
Maintenance: Research and Practice, vol. 7, no. 6, 1995, pp.
383-403.
[25] J.E. Scott, "The FoxMeyer Drugs' Bankruptcy: Was it a
Failure of ERP?," in Proceedings of Fifth Americas Conference
on Information Systems, Milwaukee, Wisconsin, 1999, pp. 223225.
[26] B. Seidel, SAPs Data Warehouse wird erwachsen,
ComputerWoche, No. 16, Apr. 21 2000, pp. 17-18.
[27] C. Soh, S.D. Kien, and J. Tay-Yap, "Cultural Fits and
Misfits: Is ERP a Universal Solution?," Communications of the
ACM, vol. 43, no. 4, 2000, pp. 47-51.
[28] C. Stedman, Companies skittish about SAP AG's retail
application, Computerworld, Vol. 34, No. 17, Apr. 24 2000, pp.
24.
[29] C. Stedman, ERP Problems Put Brakes On Volkswagen
Parts Shipment, Computerworld, Vol. 34, No. 1, Jan. 3 2000,
pp. 8.
[30] E.B. Swanson and C.M. Beath, Maintaining information
systems in organizations, John Wiley information systems
series, New York: Wiley, 1989.
[16] K.C. Laudon and J.P. Laudon, Management information
systems : a contemporary perspective, Macmillan series in
information systems, New York, London: Macmillan, 1988.
[17] K.C. Laudon and J.P. Laudon, Management information
systems : organization and technology, 4th ed., Upper Saddle
River, N.J.: Prentice Hall, 1996.
Authorized licensed use limited to: Aarhus University. Downloaded on November 28,2023 at 07:34:20 UTC from IEEE Xplore. Restrictions apply.
0-7695-0981-9/01 $10.00 (c) 2001 IEEE
9