1. New Implications for Customization of ERP Systems
Elin Uppström
Stockholm University
elinu@dsv.su.se
Carl-Mikael Lönn
Stockholm University
cml@dsv.su.se
Madeleine Hoffsten
Stockholm University
maho5877@su.se
Joakim Thorström
Stockholm University
joth4046@su.se
Abstract
Enterprise Resource Planning (ERP) Systems are
standardized software packages intended to support
the majority or all of an organization's processes.
Customization of an ERP system is usually required
to achieve fit between system and business processes
of an organization. Customization options ranges
from setting parameters in the system to developing
new functionality by modifying source code. Models
describing customization options are a decade old.
Since then, the trend is for ERP systems to become
more flexible. The feasibility of customization is
facilitated and new options for customization are
made available. Through in depth interviews, this
research identifies a need for revising existing
models. Presents necessary changes and proposes
new customization options that should be included in
a new model. There is also a need for customization
models for different types of ERP systems. This paper
therefore also contributes with describing how
customization of cloud ERP relates to existing
models.
1. Introduction
The Enterprise Resource Planning (ERP) market
is one of the fastest growing and most profitable
areas in the software industry [1]. ERP systems are
standardized software packages that support a variety
of business functions. They are built on an
assumption of how a business functions by
organizing activities and work through pre-defined
business processes. Unfortunately, there is often a
gap between business requirement and the business
logic of packaged software, which can lead to
negative business outcome [2,3]. Alignment between
an ERP system and a business is sought either by
customizing the system or by reengineering business
processes or through a mix of both [4].
ERP implementation projects are venturous and
complicated [5] and often exceed budget and
timeframes [6]. Customizing is considered one of the
most precarious matters when implementing an ERP
system [2,7-9]. The cost and complexity of an ERP
implementation project increases with the degree of
customization [10,11] and a heavily customized ERP
system limits maintainability [12] and increases the
cost for future system upgrades [2]. At least some
degree of customization is however required in
almost every ERP system implementation [13].
Despite its importance for implementation
outcomes, research on ERP customization is scarce
[2]. There is some research describing models for
customization options [8,14-16] that are meant to aid
practitioners in managing customization of their ERP
systems. These models display varying complexity
and cost for different customization options. The
models are however at least a decade old.
The ERP market has since then evolved and
matured and businesses requirements on ERP
systems to be flexible and adaptable are higher than
ever today [17]. Business requirements and an
increased competition on the ERP market drives ERP
suppliers to offer more flexible systems. To meet this
trend, suppliers are trying to facilitate the feasibility
of customization of their systems [18] and are also
offering new options for customization.
Another trend within the ERP market is the
deployment of ERP through the cloud (cloud ERP) as
opposed to on-premise ERP deployment. The main
argument for cloud ERP is the economies of scale
gained from sharing resources in a multi-tenant
environment [19,20]. Research show that
customization of cloud ERP potentially presents an
even greater challenge than customization of on-
premise ERP [21] and customization has been
identified as one of the main obstacles in cloud ERP
[22,23]. Still, models for customization of cloud ERP
systems are lacking [21].
This research investigates changes necessary to
existing customization models in order to capture
customization options for on-premise ERP systems
today. It also investigates if existing customization
options are viable for cloud ERP.
The following research question have therefore
been formulated and answered in this paper:
2015 48th Hawaii International Conference on System Sciences
1530-1605/15 $31.00 © 2015 IEEE
DOI 10.1109/HICSS.2015.505
4220

2. How have on-premise ERP customization
changed and what ERP customization options are
viable for cloud ERP?
In order to answer the research question a survey
research strategy was applied. In-depth interviews
with ten companies in Sweden were used to collect
data. The paper contributes to research and practice
with new knowledge on ERP customization options
and gives directions for future research that could be
pursued within this area.
The paper proceeds as follows. The next chapter
presents an extended background related to
customization of ERP systems followed by recent
ERP trends and cloud ERP thereby motivating this
research. The research method is thereafter
described, followed by the results and discussion.
The paper ends with conclusions and directions for
future research.
2. Previous Research
This section presents a background to ERP
customization and recent ERP trends, as well as the
new phenomenon of cloud ERP.
2.1. On-Premise ERP Customization
EPR systems are complicated compound systems
with its built-in business logic. When an organization
is about to implement an ERP system they must
understand the impact that system will have on the
organization. The benefit of an ERP system can be
great [15] but the risks are also high [5,15]. Large
implementation projects can cost hundreds of
millions of dollars and span over numerous of years.
It is therefore important to choose and customize an
ERP system wisely, since an implemented ERP will
usually run for up a long period of time within an
organization [6].
An organization implementing an ERP system
have a number of customization options to choose
from, ranging from simple configuration of settings
to modification of the source code. All ERP systems
can to a certain extent be configured to cover a
variety of business processes [6]. Still, to create a fit
between business processes and system processes
configurations are not always enough, and the system
then needs to be further customized.
Building on [15] work, [14] suggest a model that
consists of three different options for customizing an
ERP system: module customization, table
customization and code customization. Module
customization refers to choosing what ERP modules
to implement; table customization involve changing
parameters in ERP tables and code customization
encompass changing the source code of the EPR
system or add custom made modules such as new
user interfaces. [16] suggests three customization
options, configuration, extension (user exit) and
modification. Configuration involves changing
settings in tables or files. Extension refers to interface
support. Modification is alterations of the system,
such as source code changes.
Reference [8] presents the most detailed model
for categorization of customization options. It
consists of nine different options of customization,
described in table one. Roughly, the complexity and
cost of customizations increases from top to bottom.
Table 1. Customization options [8, p.4]
Customization
option
Description
Configuration Changing parameters to modify the
behavior of the system.
Bolt-ons Extended and packaged functionality
developed to function with the ERP
system created by a third party supplier.
Screen masks Developing new user interfaces.
Extended
reporting
Creating new reports for presentation of
data.
Workflow
programming
Making changes in the system workflow.
User exits Adding open interface developed program
code.
ERP
Programming
Adding applications developed in the
ERP system programing language without
changing existing code of the EPR
system.
Interface
development
Creating interfaces to other systems.
Package code
modification
Making changes in the source code of the
system.
Only one recent study was found that mention
customization options [6]. The authors claim there
are three options typically used when implementing
on-premise ERP system. Codeless configuration,
which is done in an integrated, often graphical
environment built into modern ERP systems,
Application development to fill functional gaps with
specific applications that should be developed by
external partners and Key performance indicators and
reports where standard reports in the ERP system
must be merged with reports already in use. The
authors also stress that “ERP systems never stand
alone” [6,p.30] and integration with external systems
is therefore an important issue. [6]
2.2. Recent ERP Trends
Major modifications of an ERP system are
difficult to realize [12,15] and the traditional advice
4221

3. is to avoid customization as much as possible [6,15].
On the other hand an organization whose competitive
advantage are due to customized processes might lose
their benefits if they reengineer their processes after
the ERP system. The view of customization as
something that should be avoided has, however,
started to change. There is an on going trend for ERP
systems to become more flexible. Reference [24]
argues that, “Real IT innovation comes from tailoring
ERP systems to the unique needs of every company”
[24,p.5]. Reference [25] noted already in 2007 a
mounting interest among vendors to advance ERP
systems to better support the user organizations.
Businesses today want to be able to easily develop
unique features [26] and to meet this requirement
ERP vendors are trying to facilitate the easiness of
customization of their systems and are also offering
new options for customization.
Furthermore, there are several additional drivers
that impact the trend towards more flexibility in ERP
systems. The growth in the ERP market and that
small and midsized (SME) companies have adopted
ERP systems at a larger scale [1,18] are two drivers.
SMEs have different characteristics compared to
large companies and the same considerations in
regards to implementation of ERP systems in large
organizations do not necessarily apply to SME:s
[18,27,28]. One example is the importance for small
businesses to rapidly response to changes in the
market [18], thus requiring flexibility in ERP system.
Many small ERP service vendors have also taken
substantial market shares from the traditional ERP
vendors [29]. These niche vendors are able to
compete on price and time-to-deployment [30] and
they also offer new financing terms instead of the
traditional license fees to pay for the ERP systems.
This creates a need for ERP vendors to offer more
flexible systems to stay competitive.
ERP system integration is another factor driving
the flexibility trend. Reference [31] state that ERP
implementations focus has switched from an internal
to an external perspective; focus is now on external
stakeholders and the issue of connecting customers
and suppliers [31]. Other researchers are in
agreement with the need for integrating external
information systems with internal ERP systems to
make information accessible to partners e.g. [32-37].
This creates a need for ERP systems to be flexible
towards other systems.
The knowledge and requirements of ERP
customers are more mature due to them having
implemented several ERP systems [38]. This impacts
the flexibility trend since knowledgeable customers
have the capability to place unique and specific
requirements on ERP systems.
Advances in technology also impacts ERP
flexibility. Technology has matured and evolved [37]
and new architectures have been developed such as
service-oriented architecture (SOA), which is
expected to have a large impact on redefining the
ERP market [32]. ERP suppliers are also starting to
adapt to new platforms and offer functionality
through apps and tablets (e.g. Microsoft Dynamics &
SAP).
2.3 Cloud ERP
Cloud computing is commonly divided into
Software as a Service (SaaS), Platform as a Service
(PaaS) and Infrastructure as a Service (IaaS). With
cloud delivery models customers can, at least in
theory, construct their own IT environments by
orchestrating IT services from different vendors [39].
This allows greater flexibility in the packaging and
sale of large systems [40-42]. Instead of buying one
system for all needs specialized services can be
combined on a pay-per-view basis via the Internet.
The multitenant architecture, where all customers
share the same source code, can however impede
flexibility due to the impossibility to modify the
source code of specific service applications [43].
Cloud vendors have instead focused on providing
extensive configuration capabilities, which makes the
need for changes in the source code less needed [21].
In later years ERP as a service i.e. cloud ERP has
gained ground. The delivery model most used for
cloud ERP is SaaS [44] but PaaS solutions are also
becoming more common. The provisioning of ERP
through the cloud also differs a lot, from fully
multitenant as in for example 24SevenOffice, through
a combination of multi-tenancy and single tenancy as
in Oracle business suite to the single instance
solutions offered by Lawson in cooperation with
Amazon.
Compared to other cloud enabled systems, ERP
systems are integrated software packages and have
multiple services integrated in single software [44].
Configurations in regard to cloud ERP can therefore
be expected to have more apprehensions than for
other cloud-based systems [44]. Reference [24]
argues that cloud might weaken the ability of
enterprises to innovate due to customization issues.
Further, [45] show that customized software is more
strongly supporting innovation capability within a
company as opposed to standard software solutions.
Compared to on-premise ERP, customization of
cloud ERP has been identified as one of the main
obstacles [22-23] while advanced configuration
possibilities are considered a key factor for success
[44,46].
4222

4. The feasibility of adapting the system to the
requirements of a company need to be addressed by
user organizations before a decision for cloud ERP is
taken [47]. It is also important, both for customers
and vendors of cloud ERP to understand the aspects
of customization in cloud ERP to be able to manage
their systems efficiently and deliver full value to their
businesses [19,44]. Already in 2008 reference [19]
stated that ERP vendors, supplying cloud solutions,
needed to create a strategy for the enabling of
customization by their customers themselves. They
get support from [44] who claims that the way
forward for customizing ERP in the cloud is to
provide web-based tools for customers to perform
their customizations themselves.
Through utilizing PaaS technology ERP vendors
can provide customers with the possibility of
developing applications without downloading and
installing any software [48,49]. Customers are
thereby provided with the possibility to build
customizations themselves. Through Application
Programming Interfaces (APIs) and web services
cloud ERP vendors can also offer solutions that are
easily integrated [50,51].
Two examples of companies that have addressed
the customization issues in a successful way are
Salesforce with their PaaS solution Salesforce1 and
NetSuite incorporated, both large players that started
out as SaaS providers. As a way to solve the
customization issue for cloud ERP they have started
to offer PaaS and/ or IaaS solutions to their
customers.
Although several researchers have pointed out the
need to consider customization of cloud ERP, none of
the previously mentioned categorizations for
customization consider cloud ERP. The lack of
scientific coverage of the area of cloud ERP systems
is also conveyed by [52]. They get support from
among others [21] who state that research is needed
for building a “clear framework to determine the
level of configuration and customization ability of
cloud ERP systems” [21,p.13]. [44] also points out
the need for research on customization of cloud ERP.
3. Method
In this research qualitative survey research was
used as a research strategy. In-depth interviews have
been conducted to provide depth and completeness in
the information collected [53]. Through interviews a
better validity can also be ensured since data can be
verified during collection, because in interviews there
is a better possibility to clarify, ask additional
questions and deepen statements [54].
A total of ten experts from ten different
companies were interviewed. Mainly ERP vendors
and/or consultancy firms are represented among the
ten companies. One user organization is included.
Information about the respondents is visible in Table
two below.
Table 2. The experts included in the study
and their organizational belonging
Organization Description Expert Interviewed No
ERP vendor, one of the
largest on the Swedish
market
Manager product
localization.
1
Swedish ERP organization
that develops and delivers
an on- premise ERP
system.
Senior developer. 2
Organization providing a
cloud based ERP systems,
which has been in used for
more than ten years.
Managing Director for
Sweden. Previously
founder of one of the
largest ERP systems
developed in Sweden.
3
Partner organization to one
of the largest ERP vendors
in the world, the partner
organization delivers an
ERP system to their
customers.
Head of competence
department.
4
Organization delivering
bolt-on solutions to one of
the largest ERP systems on
the Swedish market.
Product manager. 5
One of the largest IT
companies in the world,
building several ERP
systems for a worldwide
market.
Technical advisor for
customers and partner
companies.
6
Swedish manufacturing
organization with presence
in several countries.
Process owner for the
ERP system used at the
financial department.
7
A large worldwide
organization offering a
diversity of different IT
services ERP consultancy
services are one.
Project leader and
implementation
consultant.
8
Swedish medium sized
consultancy firm, offering
a range of consultancy
services.
ERP integration
consultant.
9
Consultancy firm working
with a worldwide PaaS
solution.
Country manager for
Sweden.
10
The companies and the interviews were chosen
through purposive sampling. “Purposive sampling
operates on the principle that we can get the best
information through focusing on a relatively small
number of instances deliberately selected on the basis
of their known attributes” [53,p.34]. In a purposive
sampling people that are “most likely to have the
experience or expertise to provide quality
4223

5. information and valuable insights on the research
topic” are intentionally chosen [53,p.35]. The criteria
for choosing companies were that the companies are
well known and established ERP suppliers, ERP
consultant companies or very experienced ERP users.
Criteria for choosing experts to interview were that
they work with customizing ERP systems and that
they volunteered to participate.
All interviews performed followed the same
structure. First, questions were asked to the
respondent to find out relevant information about the
expert. Then, questions were asked to the respondent
to find out relevant information about the
organizations ERP related systems and services. Then
questions about configuration and customization of
ERP systems were posed. The typology suggested by
[8] was used as a foundation for discussion about
ERP customization options. The typology was chosen
because it’s well cited and provides a detailed
categorization of ERP customization options. All of
the interviews were recorded and after each interview
the recordings were transcribed. The results were
analyzed by using content analysis to identify
patterns in the answers. The findings were also again
considered against the work by [6,8,14,16] in order to
determine the adequacy of these typologies.
4. Results
In this chapter the results from the interviews are
described. First the views of the respondents in
relation to the understanding of customization are
described. Then the point of view of the respondents
on the different customization options and thereby
the adequacy of the typology suggested by [8] is
described. A few statements and quotes from the
interviews have been selected to illustrate the
respondents view. The authors have translated all
quotes in the result section from Swedish to English.
4.1. The Understanding of Customization
Different levels of customizations are still a
common phenomenon in ERP implementation
projects. All respondents agree that some
customization is necessary in an ERP implementation
project today. There is also obvious that the extent of
customization differs a lot and that is to a large extent
dependent on the specific system implemented. The
understanding of customization differed among the
respondents. Respondent 1 states that “Customization
is setting pre-defined parameters in the system,
configuration is modifications in the source code”;
respondent 3 are in agreement with this view.
Respondent 4 and 5 as well as 8 and 9 instead agree
on another view: “Customization is when you have to
make changes in the code while configuration is
setting parameters in tables and switching functions
on and off” (respondent 4).
The differences in the understanding of
customization are especially visible between cloud
ERP and on-premise ERP. The respondent working
with on-premise ERP did to a large extent agree with
[8] definition of configuration (setting parameters)
although extended configuring options, such as visual
workflow configuration, was also visible. The cloud
ERP respondents had a different view of what
changes are possible to do through configuration but
there were also large differences in how different
cloud vendors regarded the possibilities of
configuration. From only cosmetic changes
(Respondent 3) to advanced changes in the database
or the creation of trigger events (Respondent 10).
According to respondent 10, working with a PaaS
system, configuration enables changes not only by
setting parameters but also enables changes in the
user interface and database, through drag and drop,
and, by creating business rules, triggers and actions
without coding. “We get very far by configuring the
system before we even need to code, and when code
is needed it is often very little actual coding
involved” (respondent 10). In the PaaS solution their
customers often buy only the development
environment, or the platform, and then build all
functionality by configuring the system, sometimes
without any coding at all.
That configuration enables a larger set of changes
in the PaaS solution, compared to on-premise ERP
creates difficulties. “It is very difficult for me
sometimes when communicating with customers who
are stuck in the old fashioned way of viewing
customization. Many customizations that require
coding in on-premise solutions are possible by
configuring the PaaS solution. Since what we offer is
so different it is hard to get a common
understanding”. (respondent 10)
4.2. Customization Options
The customization options within the [8] typology
were perceived different depending on who was
answering. Several respondents recognized or were
familiar with a number of the names in the typology,
such as user exits, but did not agree with the offered
definition of them. It was still possible to discuss
customization based on the typology made by [8]
since most companies had knowledge and recognized
most of the customization options.
Based on the customization options in the model
suggested by [8] the status for each option is
4224

6. described in short in the following two tables. The
status for on-premise ERP is presented in table three.
The viability for cloud ERP is presented in table four.
Table 3. Status of customization options
for on-premise ERP
Customization
option
Status
Configuration Common customization option.
Configuration encapsulates more possible
changes than before, e.g. role interfaces.
Lack of consensus in regards to definition of
configuration.
Bolt-ons Common customization option but
encapsulates more possible changes than
before. Development and dissemination
facilitated through marketplaces.
Screen masks Old fashioned, not commonly used and has
been replaced with other techniques such as
web and mobile interfaces. Configuration as
to a large extent replaced the need for screen
masks.
Extended
reporting
Outdated customization option. Replaced to
a large extent with Business Intelligence
tools and 3rd
party reporting tools.
Workflow
programming
Outdated customization option. Replaced
with configurations, workflow layers and
workflow engines.
User exits Valid and a (very) common customization
option.
“User exists are the most classical option of
customization, and you cannot do
implementation projects without using them.
They are always safe in regards to
upgrades”. (Respondent 8)
ERP
Programming
Status unclear. Differs between different
vendors and perceived as an unclear option
among the respondents.
Interface
development
Important and common customization option
but the naming is outdated. Interfaces are
often simpler to develop today due to more
tool support such as integration API:s.
“Using conventional integration tools such
as flat file transfers is today considered an
accident at work, instead integration is all
about using standard protocols for
transferring data and libraries with APIs and
web services” (Respondent 9).
Package code
modification
Regarded as a still valid option as well as
difficult to perform and should be avoided.
“In almost all implementation project some
kind of coding is necessary but we try to
keep it at a minimum to facilitate upgrades
and support of the system” (Respondent 8).
Table 4. Viability of customization options
for cloud ERP
Customization
option
Viable Comment
Configuration Yes Most customization is done
through configuration in cloud
ERP.
Bolt-ons Unclear “Everyone can build an app on
our platform; it does not even cost
anything. Then you can sell it on
the marketplace or sell it by
yourself” (respondent 10).
Screen masks No Cosmetic changes, such as screen
masks, are configuration options
and do not require customization
in cloud ERP systems.
Extended
reporting
No Covered by business intelligence
tools integrated with cloud
system.
Workflow
programming
No Made through configurable
workflows.
User exits Unclear Depends on the architecture of the
cloud system, viable in some.
ERP
Programming
Unclear Viable for PaaS but not for SaaS.
Interface
development
Yes “[The SaaS solution] uses a lot of
web services so that for example
CRM systems can send
information directly to the
system” (respondent 2). “Our
whole system is represented in
APIs, even the role configuration
and metadata. It is therefore very
simple to integrate towards our
platform, the potential problem is
always in the other systems”
(respondent 10).
Package code
modification
No Source code only available for the
vendor, impossible for customers
to make changes.
4.3. New Customization Options
Several of the respondents expressed a need for
having a package customization option that include
bundled customizations for specific business verticals
(respondent 1, 4, 5, 6 and 10). The reason is that a
common offer is to have several pre-developed
customizations together in a package deal to speed up
the implementation of the system. “What I consider
missing is packaging of customizations” (respondent
1). ”We work a lot with components, which is
smaller packages of functionality; maybe there
should be something about packages” (respondent 4).
“An app [application] can be a package of
customizations, they can be either large or small”
(respondent 10).
Mobile platform interfaces such as apps are also
considered common today. There is no common
agreement on how to regard mobile apps however.
Respondent 1 and 5 consider it to be a customization
option while respondent 4 and 2 consider it only as
an interface on a different platform and interview 3
states that “apps are only a new way to extend the
keyboard”.
Respondent 8 and 9 brings up the notion of
conversions as a customization on data level.
Conversion is used to adapt data to different systems
4225

7. to make migration of data from legacy systems and
integration between systems with different data
models possible (respondent 9). “We use a canonical
data model to make the integrations scalable and
remove system dependencies, all system specific data
are mapped towards the canonical system”
(respondent 9). “Our metadata model is available
through APIs which makes it easy to map data
towards our system or map our data towards others as
well” (respondent 10). The suggested new
customization options are suitable for both on-
premise and cloud ERP; summarized in table five.
Table 5. Suggestions of new
customization options for on-premise and
cloud ERP
Customization
options
Description
Package
customization
Bundled customizations for specific
business verticals.
Conversions Customization on data level.
Mobile platforms Unclear, needs further investigation.
5. Discussion
In this chapter the result is discussed.
5.1. The Notion of Customization
A factor for ERP implementation success is
communication [55] and it has even been identified
as the most important success factor by [17].
Different nomenclature and interpretations of
concepts are aspects that can influence
communication negatively.
The perception of what different customization
options stands for and how it is used differs among
practitioners. Vendors and consultancy firm seems to
use their own or system specific nomenclature. This
can have a negative impact on ERP implementation
projects, for instance, when a customer discusses a
possible customization with a supplier.
In respect to cloud ERP, further communication
hurdles exist. Extended flexibility and fit can be
offered through using only configuration options
present in the systems and several of the
customization options are shown to be viable at least
for certain cloud ERP systems. Communication
problems then arises when customers have a
traditional and thereby conflicting perception of
customization options. This can for instance lead to
misunderstanding of time estimations in the projects.
The authors therefore argue that there is a need
for system independent consensus regarding
constructs and nomenclature within the area of ERP
customization. A standard way of naming and
describing different customization options do not
exist in the Swedish ERP market. An updated model
with naming and definition of different customization
options can thereby help to improve communication
regarding ERP customization.
5.2. Adequacy of Existing Models
Models for customization such as [6,8,14,16]
were not well known by the ERP practitioners. The
respondents did however seem to regard the notion of
using models useful. The dissemination of such
models thereby needs to be improved.
Based on the results the authors of this paper
claim that the [8] model is not adequate, it does not
accurately reflect available customization options for
ERP today. The model would need to be revised in
order to meet new conditions on the ERP market.
The authors further claim that the model for
customization proposed by [14] for ERP
customizations presents to broad customization
categories to be relevant in this context. The two first
categories (module and table customization) can be
regarded as valid. The third category (code
customization) is valid per se, but it is not sufficiently
detailed to provide a comprehensive picture of
customization options and thereby less usable. The
same applies for [16]. The categorization offered by
[6] is also regarded as to broad and does, for example
not include integration, although it is pointed out as
an important issue by the authors themselves [6].
Compared to the older models there is a shift in the
complexity level of customizations. Changes that
required coding ten years ago is to a large extent
replaced with configuration options, and thereby less
complex to perform.
5.3. Suggested Changes Typologies
Table six below presents suggested changes that
need to be considered in a new model for on-premise
ERP.
Table 6. Suggested changes to on-
premise customization options
Customization
option
Suggested Change
Configuration The definition needs to be updated and more
configurable functionalities or levels of
configuration need to be included in the
definition.
Bolt-ons The definition needs to be expanded to
include several ways to develop and
4226

8. disseminate customizations.
Screen masks Remove from model.
Extended
reporting
The option needs to be replaced with a
Business Intelligence concept.
Workflow
programming
The name and definition needs to be changed
to include additional ways to modify
workflows (i.e. configurations, workflow
layers and workflow engines).
User exits The definition should include differentiation
in level of difficulty.
ERP
Programming
Should possibly be removed.
Interface
development
Name should be changed to integration and
the definition should allow differentiation in
level of difficulty.
Package code
modification
Possibly a name change to source code
modification.
The model [8] also needs to be complemented
with additional options (see table 4) or the definitions
of the options needs to be expanded to include the
new options. It is also not possible today to sort
distinct customization options into a ranking based on
complexity and cost. This is because complexity
varies within specific options, for example user exits.
Customization options could include different
levels of difficulty.
The model [15] could be complemented with
additional categories and/or the code customization
category could be complemented with subcategories
describing different customization options on that
level. The model [6,16] needs to be further broken
down into specific options to be useful.
5.4. Applicability to Cloud ERP
Two out of the nine customization options in [8]
are viable for cloud ERP and four options are unclear
if they are viable. None of the existing models are
directly applicable to cloud ERP. We are in
agreement with reference [21] that a model for
customization of cloud ERP systems is needed. This
research contributes to building a model by mapping
on-premise ERP customization options to cloud ERP
(see table 3).
6. Conclusions and Future Research
Customization is important for ERP system
success and some degree of customization is required
in almost every ERP system implementation. Models
or frameworks that defines different customizations
options can help the communication regarding ERP
customization, but we observed that existing models
for on-premise ERP customization needs to be
revised. This paper therefore contributes with
presenting changes necessary to existing
customization models. It also contributes with
proposing new customization options (packaged
customization, conversions and mobile platforms)
that should be included in a new model. There is an
obvious trend visible in this research of replacing
code customization with configuration options, both
in on-premise and cloud ERP. The need for
consensus regarding constructs and nomenclature
within the area of ERP customization is also
highlighted.
There is also a need for customization models for
different types of ERP systems. In regards to cloud
ERP, models need to be designed to conform to their
technical platforms and delivery models. This paper
contributes with describing how existing
customization options relate to cloud ERP. The
authors of this paper therefore claim that there is a
need for new models for on-premise and cloud ERP
customization options. Future research should focus
on designing such models. The suggested changes
and new customizations options in this paper could
be used as a contribution to the first two steps in [56]
design science research methodology.
Although the authors claim that new models are
the most appropriate way forward, it should be noted
that for organizations using old ERP system the
existing typologies could still be adequate. Future
research should find ways to disseminate models in
order to help practitioners to get a deeper
understanding of the phenomenon and also in order
to move the standardization of ERP software
development forward.
7. References
[1] Da Xu, L. (2011). Enterprise systems: state-of-the-art
and future trends. Industrial Informatics, IEEE Transactions
on, 7(4), 630-640.
[2] Haines, M. N. (2009). Understanding enterprise system
customization: An exploration of implementation realities
and the key influence factors. Information Systems
Management, 26(2), 182-198.
[3] Gattiker, T. F., & Goodhue, D. L. (2002). Software
Driven Changes to Business Processes: An Empirical Study
of Impacts of Enterprise Resource Planning Systems at the
Local Level. International Journal of Production Research,
40 (18), 4799–4814.
[4] Sumner, M. (2004). Enterprise Resource Planning.
Prentice Hall, Upper Saddle River, New Jersey
[5] Aloini, D., Dulmin, R., & Mininno, V. (2012). Risk
assessment in ERP projects. Information Systems, 37(3),
183-199.
4227

9. [6] Munkelt, T., & Völker, S. (2013). ERP systems: aspects
of selection, implementation and sustainable operations.
ERP adoption cost factors identification and classification:
a study in SMEs.
[7] Botta-Genoulaz, V. & P. A. Millet. (2006). An
investigation into the use of ERP systems in the service
sector. International journal of production economic, 99,
202-221.
[8] Brehm, L., Heinzl, A., & Markus, M. L. (2001).
Tailoring ERP systems: a spectrum of choices and their
implications. In Proceedings of the 34th Annual Hawaii
International Conference on Systems Sciences, Maui,
Hawaii.
[9] Buckhout, S., E. Frey & J. Nemec. (1999). Making ERP
succeed: Turning fear into promise. Journal of Strategy and
Business, 17, 60-72.
[10] Bingi, P., Sharma, M. K., & Godla, J. K. (1999).
Critical issues affecting an ERP implementation. IS
Management, 16(3), 7-14.
[11] Saini, S., Nigam, S., & Misra, S. C. (2013). Identifying
success factors for implementation of ERP at Indian SMEs
and large organizations and multinational organizations: A
comparative study. Journal of Modelling in
Management, 8(1), 103-122.
[12] Rothenberger, M. A., & Srite, M. (2009). An
investigation of customization in ERP system
implementations. Engineering Management, IEEE
Transactions on, 56, (4), 663-676.
[13] Huang, S. Y., Chen, H. J., Chiu, A. A., & Hsieh, S. L.
(2012). The factors of ERP customization from consulting
company’s perspective. MIS REVIEW: An International
Journal, 17, 1-30.
[14] Luo, W., & Strong, D. M. (2004). A framework for
evaluating ERP implementation choices. Engineering
Management, IEEE Transactions of Engineering
Management, 51(3), 322-333.
[15] Davenport, T. H. (1998). Putting the enterprise into the
enterprise system. Harvard business review, 76 (4).
[16] Haines, M. N. (2003). Customization, Configuration,
or Modification? A Taxonomy for Information System
Specializa- tion. Paper presented at the IRMA International
Conference, Philadelphia, PA, 18–21 May 2003. IRMA,
Hershey, PA.
[17] Hasibuan, Z. A., & Dantes, G. R. (2012). Priority of
Key Success Factors (KSFS) on Enterprise Resource
Planning (ERP) System Implementation Life Cycle,
Journal of Enterprise Resource Planning Studies, 1-15.
[18] Malhotra, R., & Temponi, C. (2010). Critical decisions
for ERP integration: Small business issues. International
Journal of Information Management, 30(1), 28-37.
[19] Sun, W., Zhang, X., Guo, C. J., Sun, P. & Su, H.
Software as a service: Configuration and customization
perspectives, in Proc. 2008 IEEE Congr. Serv. Part II
(services-2 2008), Sep. 2008, 18-25.
[20] Dillon, T., Wu, C., & Chang, E. (2010). Cloud
computing: issues and challenges. In Advanced
Information Networking and Applications (AINA). 24th
IEEE International Conference on, 27-33.
[21] Mijaþ, M., Picek, R., & Stapiü, Z. (2013). Cloud ERP
System Customization Challenges. In Central European
Conference on Information and Intelligent Systems.
[22] Purohit, G., Jaiswal, M. & Pandey, M. (2012).
Challenges involved in implementation of ERP on demand
solution: Cloud computing. International Journal of
Computer Science, 9(4), 481-490.
[23] Gd, M. & Bist, M. (2012). EAAS-ERP as A Service.
Journal of Information Operations Management. 3 (1),
141-145.
[24] Hofmann, P. (2010). Cloud Computing: The Limits of
Public Clouds for Business Applications. IEEE Internet
Computing, 14(6), 90–93.
[25] Johansson, B. (2007): Why Focus on Roles when
Developing Future ERP Systems. Springer, New York.
[26] Johansson, B., & Newman, M. (2010). Competitive
advantage in the ERP system's value-chain and its
influence on future development. Enterprise Information
Systems, 4(1), 79-93.
[27] Raymond, L., Rivard, S., & Danie, J. (2004). Small
enterprises’ predisposition to adopt an erp. In Proceedings
of the international conference on information systems
analysis and specification, 614–618.
[28] Tarn, J. M., Yen, D. C., & Beaumont, M. (2002).
Exploring the rationales for ERP and SCM integration.
Industrial Management + Data Systems, 102(1/2), 26–33.
[29] Jacobson, S., Shepherd, J., D’Aquilla M., & Carter, K.,
(2008). The ERP Market Sizing Report 2007-2012, AMR
Research. Management, 16(3), 7-14.
[30] Xin M., and Levina, N., (2008) Software-as-a-Service
Model: Elaborating Client-Side Adoption Factors, In: R.
Boland, M. Limayem and B. Pentland, Eds., Proceedings of
the 29th International Conference
[31] Kähkönen, T., Maglyas, A., & Smolander, K. (2014).
What Do We Know About ERP Integration?. In Enterprise
Information Systems (pp. 51-67). Springer International
Publishing.
4228

10. [32] Addo-Tenkorang. R. & Helo, P. (2011). Enterprise
Resource Planning (ERP): A review literature report. In
Proceedings World Congress on Engineering and Computer
Science, II.
[33] Beheshti, H.M. (2006). What managers should know
about ERP/ERP II. Management
Research News, 29(4), 184-93.
[34] Koh, S.C.L., Gunasekaran, A. & Rajkumar, D. (2008).
ERP II: The involvement, benefits and impediments of
collaborative Information sharing. International Journal of
Production Economics, 113, 245–268.
[35] Moller, C. (2005) ERP II: a conceptual framework for
next-generation enterprise systems?. Journal of Enterprise
Information Management, 18(4), 483–497.
[36] De Burca, S., Fynes, B. & Marshall, D. (2005).
Strategic technology adoption: extending ERP across the
supply chain. Journal of Enterprise Information
Management, 18(4), 427–440.
[37] Piazolo, F. & Felderer, M. (2013). ERP Future 2013,
In F. Piazolo and M. Felderer (eds.), Novel Methods and
Technologies for Enterprise Information Systems, Lecture
Notes in Information Systems and Organisation 8, DOI:
10.1007/978-3-319-07055-1_1,_ Springer International
Publishing Switzerland 2014
[38] Ram, J., Corkindale, D., & Wu, M. L. (2013).
Implementation critical success factors (CSFs) for ERP: Do
they contribute to implementation success and post-
implementation performance?. International Journal of
Production Economics, 144(1), 157-174.
[39] Abels, S., Brehm, N., Hahn A. and Gomez, J. M.,
(2006). Change Management Issues in Federated ERP
Systems: An Approach for Identifying Requirements and
Possible Solutions. International Journal of Information
Systems and Change Management, 1(3), 318-335.
[40] Cusumano, M. A., (2008). The Changing Software
Business: Moving from Products to Services. Computer,
41(1), 20-27.
[41] Fan, M., Kumar S. & Whinston, A. B. (2009). Short-
Term and Long-Term Competition between Providers of
Shrink-Wrap Software and Software as a Service, European
Journal of Operational Research, 196(2), 661-671.
[42] Saeed M. & Jaffar-Ur-Rehman, M., (2005).
Enhancement of Software Engineering by Shifting from
Software Product to Software Service, In: W. Khan and R.
Ahmed, Eds., First International Conference on
Information and Communication Technologies ICICT,
Karachi, 302-308.
[43] Lenart, A. (2011). ERP in the Cloud–Benefits and
Challenges. In Research in Systems Analysis and Design:
Models and Methods (pp. 39-50). Springer: Berlin,
Heidelberg.
[44] Al-Shardan, M. M., & Ziani, D. (2015). Configuration
as a Service in Multi-Tenant Enterprise Resource Planning
System. Lecture Notes on Software Engineering, 3(2).
[45] Engelstätter, B., & Sarbu, M. (2013). Does enterprise
software matter for service innovation? Standardization
versus customization. Economics of Innovation and New
Technology, 22(4), 412-429.
[46] Nitu. (2009). Configurability in SaaS (software as a
service) applications. In Proceedings of the 2nd India
Software Engineering Conference (ISEC „09), 19-26.
[4747] Schubert, P., & Adisa, F. (2011). Cloud computing
for standard erp systems: reference framework and research
agenda. Fachbereich Informatik, 16.
[48] Cusumano, M. (2010). Cloud computing and SaaS as
new computing platforms. Communications of the
ACM, 53(4), 27-29.
[49] Makkar, G. D., & Bist, M. (2012). EAAS-ERP AS A
SERVICE. Journal of Information & Operations
Management, 3(1).
[50] Benlian, A., Hess T., and Buxmann, P., (2009) Drivers
of SaaS-Adoption—An Empirical Study of Different
Application Types, Business & Information Systems
Engineering, 1(5), 357-369.
[51] Sääksjärvi, M., Lassila A. & Nordström, H., (2005)
Evaluating the Software as a Service Business Model:
From CPU Time-Sharing to Online Innovation Sharing, In:
P. Isaias, P. Kommers and M. McPherson, Eds. IADIS
International Conference e-Society 2005, 27-30, Quarwa,
177-186.
[52] Elragal, A. & Haddara, M. (2012). The Future of ERP
Systems: look backward before moving forward, presented
at the CENTERIS 2012, Algarve, Portugal.
[53] Denscombe, M. (2010). The Good Research Guide:
for small-scale social research projects. 4th edition, Open
University Press.
[54] Bhattacherjee, A. (2012). Social sciences research:
principles, methods, and practices. Second Edition.
[55] Willcocks, L. P., & Sykes, R. (2000). Enterprise
resource planning: the role of the CIO and it function in
ERP. Communications of the ACM, 43(4), 32-38.
[56] Peffers, K., Tuunanen, T., Rothenberger, M. A., &
Chatterjee, S. (2007). A design science research
methodology for information systems research. Journal of
management information systems, 24(3), 45-77.
4229