Management of Enterprise Resource Planning (ERP ... · in Enterprise Resource Planning (ERP)...
Transcript of Management of Enterprise Resource Planning (ERP ... · in Enterprise Resource Planning (ERP)...
Management of Enterprise Resource Planning (ERP) Maintenance and Upgrade: A Revelatory
Case Study
Celeste See Pui Ng
Bachelor of Science Master of Information Technology
Centre for Information Technology Innovation (CITI) Queensland University of Technology
Australia
Submitted for the Degree of Doctor of Philosophy (Ph.D.)
2003
Certificate Recommending Acceptance Dr. Taizan Chan Supervisor Senior Lecturer Faculty of Information Technology, QUT Professor Guy G. Gable Supervisor Professor Faculty of Information Technology, QUT Professor Robert L. Glass External Examiner Professor Emeritus Computing Trends Professor Ned Chapin External Examiner Professor Emeritus InfoSci Inc.
Keywords: Enterprise resource planning, ERP, maintenance, upgrade, packaged software, case
study, qualitative, revelatory case, exploratory, taxonomy, effort model, decision
support, user opportunity, data-model, methodology, maintenance model,
measurement, client, vendor, consultant, SAP, quantitative, mathematical model,
benefit-realization
Statement of Original Authorship
The work contained in this thesis has not been previously submitted for a degree at
any other higher education institution. To my best knowledge, the thesis contains no
material previously published or written by another person except where due
reference is made.
Signed:
Date: 21 July, 2003
Acknowledgement
I would like to express my gratitude to Dr. Taizan Chan for being my supervisor. He
has spent a lot of time and effort, and given countless guidance to me during the early
stages of my PhD journey. He has motivated me to become a more critical-thinker,
diligent, and independent researcher. His critical comments and insightful suggestions
have enabled this thesis to emerge from its initial inception to its finished end.
I am in debt to Professor Guy Gable, my supervisor. He has provided a lot of supports
to me ranging from academic aspect to financial aids. With his extensive knowledge
and abundant experiences, he has given me unlimited ideas and constructive
suggestions for improvement in my various publications and this thesis. He has
helped me to become who I want to be and an ambitious person.
To the participating case firm, Corporate Services Agency (CSA), Craig Vayo, Bill
Willmott, Philip Hood and other staff, many thanks for giving me the opportunity to
conduct my research in their organization. I appreciate their time and effort spent with
us for interviews and email discussions, and their interests in this project.
To the internal examiners, Associate Professor Alan Underwood and Dr. Robert W.
Smyth, I appreciate their time and effort in giving me helpful comments for my thesis.
To the external examiners, Professor Robert L. Glass and Professor Ned Chapin, it is
my privilege and pleasure to have them as my examiners. Thanks for their patience in
reading my thesis and positive feedbacks.
I owe a thank-you to my previous university, Tunku Abdul Rahman College (TARC)
for giving me this special opportunity in my life to do a PhD.
Thanks to my best and intimate friend, Kevin Tsai, I am grateful to him for always
being there for me throughout the ups and downs in my PhD journey. Also, thanks for
his encouragements, understandings, love and commitments. Finally, thanks to my
parents, brother, sister, second uncle and wife, third auntie and husband, fourth auntie,
cousins, friends and others for their morale supports throughout my studies.
Exe-1
Executive Summary
This research project contributes to a project “Cooperative ERP Lifecycle Knowledge
Management” that aims to identify relevant knowledge and related implications across the
industry partners (i.e. ERP-using organizations, ERP vendor (SAP1) and consultants) involved
in Enterprise Resource Planning (ERP) implementation and lifecycle support. This research is
an exploratory, descriptive, revelatory and collaborative case study. It seeks to generate both
research outcomes and applied outcomes for the industry partners. The main focus of this
study is ERP maintenance and upgrade activities of ERP-using organizations. While the ERP
vendor is a stakeholder, vendor maintenance of ERP is not the focus of this study.
With the installed base of ERP having grown dramatically over the past decade, the topic of
ERP maintenance and upgrade is receiving increased attention. Costs associated with ongoing
maintenance and upgrade activities are not trivial in most ERP-using organization Information
System (IS) budgets. However, research into fundamental issues of ERP maintenance and
upgrade is at an early stage as compared to research into ERP implementation issues or the
work done on in-house software maintenance over the past two decades.
This study of the management of ERP maintenance and upgrade2 (from the practical
perspective) specifically aims to minimize ERP software lifecycle costs (thus, total cost of
ownership) and to facilitate benefit-realization from the ERP system. These aims are achieved
in this study by investigating the nature of ERP maintenance and upgrade activities, and
proposing appropriate mechanisms and methodology for effective and efficient maintenance
management in the context of ERP. These include ERP maintenance taxonomy, maintenance
effort model, maintenance and upgrade (MU) decision framework, maintenance methodology,
and maintenance-data-model3. These tools and techniques are believed to facilitate effective
and efficient management of ERP MU activities.4 They are useful and important for
1 SAP software is the main focus in this thesis because: (1) the case firm in this study uses SAP software, (2) SAP is a top-tier ERP software, and (3) majority of research done so far are based on SAP software. Thus, this can facilitate the author in making references, associations and comparisons with existing studies or knowledge relevant to this thesis. 2 Some authors use software evolution as a synonym for software maintenance (Chapin et al. 2001, pg, 21). In this thesis, the author simply uses the term ERP maintenance and upgrade as it is more straightforward, intuitive and simple to understand. 3 Definition for the commonly used terms in this thesis is given in Appendix A. 4 Though only five research areas (i.e. maintenance taxonomy, determinants of maintenance effort, maintenance and upgrade decision framework, maintenance methodology and maintenance-data-model) are covered in this thesis and are believed to be fundamental to the
Exe-2
classifying maintenance requests, having an appreciation of the key drivers of ERP
maintenance effort, making better-quality maintenance and upgrade decisions, efficiently and
effectively performing MU activities, and retaining information and knowledge about
maintenance and upgrade activities.
From the research perspective, this study aims to determine if the existing literatures which
are largely based on in-house software are sufficient in the context of ERP. Thus, this study
aims to identify:
(1) A clear and concise definition of ERP maintenance;
(2) Dimensions for classifying ERP maintenance requests, and propose an ERP
maintenance taxonomy;
(3) Project characteristics affecting ERP maintenance effort;
(4) Factors affecting ERP maintenance and upgrade (MU) decisions, and develop an ERP
MU decision framework;
(5) Activities involved in ERP maintenance preparation, maintenance procedures and
software upgrade, and develop an ERP maintenance methodology;
(6) Fundamental measurable ERP maintenance request’s attributes, and develop an ERP
maintenance-data-model.
This study addresses the following research questions:
Q1 - What is ERP maintenance?
Q1.1 - What activities comprise ERP maintenance?
Q1.2 - How can ERP maintenance activities be usefully classified?
Q1.2.1 - What are useful dimensions for classifying ERP maintenance activities?
Q1.2.2 - Are the existing maintenance classifications appropriate?
Q2 - What attributes of maintenance effort are captured by an ERP-using organization?
Q2.1 - Which of these attributes are useful predictors of maintenance effort?
Q2.2 - How can maintenance effort be measured?
Q3 - What are the factors that should be considered in making ERP maintenance and upgrade
decisions?
Q3.1 - What are the major factors influencing ERP patch-maintenance costs?
Q3.2 - What are the major factors influencing ERP upgrade costs?
management of ERP maintenance and upgrade, other areas such as maintenance request prioritization and scheduling, maintenance productivity, and maintenance performance are also worth future research.
Exe-3
Q3.3 - What are the opportunity costs for not doing ERP maintenance and upgrade?
Q3.4 - Are these factors that should be considered in an ERP upgrade decision (i.e.
replacing an existing version with a newer version from the vendor) differed from
those captured in the existing in-house software replacement models?5
Q3.5 - How could these factors be included into software maintenance and upgrade cost
functions?
Q4 - What activities and tasks should be incorporated and reflected in an ERP maintenance
methodology?
Q4.1 - What are the activities associated with an ERP maintenance methodology?
Q4.2 - Is the existing standard for software maintenance methodology appropriate in the
context of ERP?
Q4.3 - What are the activities and tasks that are unique to ERP maintenance environment?
Q5 - What are the important ERP maintenance request’s attributes that should be captured in
an ERP maintenance management environment?
Q5.1 - Do the attributes captured in in-house software environment sufficient in the
context of ERP?
Q5.2 - What are the unique ERP maintenance request’s attributes?
The significance of this study is summarized as follows6.
(1) ERP Maintenance Taxonomy: A maintenance taxonomy that considers the business-
benefits of each maintenance request is central to identifying potential business opportunities
and minimizing user opportunity costs (costs of delaying or not doing maintenance). It is
important to distinguish different types of requests for example emergency requests that
require immediate attention from enhancement requests. It facilitates maintenance request
prioritization and scheduling, record-keeping, and effective maintenance management.
(2) ERP Maintenance Effort Model: To efficiently plan and maintain the ERP system,
managers must have an appreciation of the key drivers of maintenance effort so that
maintenance effort can be estimated, and maintenance costs can be projected for charge-back
to the user-department.
5 The author is not equating ERP upgrade with in-house software replacement but to investigate whether the factors considered in existing replacement/rewrite models are useful and relevant in the context of ERP. It is noted that replacement is an important issue to ERP vendors and upgrade is to ERP clients. However, vendors’ replacement issues are not the focus in this thesis. 6 The significance of the research areas discussed here are not necessarily specific to ERP.
Exe-4
(3) ERP Maintenance and Upgrade Decision Framework: A decision framework, capturing
the fundamental ERP MU characteristics, decision factors and the respective cost functions,
provides important insights into impacts of different decision alternatives thereby facilitating
evaluation and justification of maintenance and upgrade decisions.
(4) ERP Maintenance Methodology: A maintenance methodology, detailing all relevant
activities important for initiating, planning, organizing, managing, executing, monitoring, and
closing MU projects, is essential for an effective and efficient maintenance management.
(5) ERP maintenance-data-model: A maintenance-data-model with well-defined maintenance
attributes (i.e. what, how, where, when, why, who), is fundamental to measuring maintenance
performance, tracking and monitoring maintenance activities, facilitate maintenance decision-
making, and recording previous and current maintenance knowledge for future reference.
In order to provide answers to the research questions, case study research method is used. An
exploratory, descriptive, revelatory and collaborative case study is justified as this is a new
area of research endeavor (Yin, 1994). The case study encompasses five embedded sub-
studies: taxonomy sub-study, effort sub-study, decision sub-study, methodology sub-study,
and data sub-study. These five sub-studies are embedded within an over-arching case study
conducted at a large Government Agency, Corporate Services Agency (CSA), in Australia.
CSA is a corporate services provider (including ERP systems) to other Government
Departments, as well as an ERP-using organization itself. It is analogous to an ERP
maintenance department in a large organization with many user departments (i.e. itself + other
Government Departments). Throughout this thesis, the stated maintenance and upgrade
questions are addressed by studying this ERP-using organization (CSA).
Salient characteristics of the five sub-studies are listed in Figure 1 and addressed in detail in
Chapters 4 through 8. While each sub-study in many respects stands alone, Figure 1
demonstrates how the sub-studies are complementary, with each contributing to the
subsequent sub-studies. Outputs or findings of the taxonomy sub-study, effort sub-study and
decision sub-study are incorporated in the methodology sub-study to improve the overall
effectiveness and efficiency of ERP maintenance and upgrade management. On the other
hand, the output from the methodology sub-study is used to facilitate and enhance the
identification of maintenance attributes to be captured in the data sub-study. In practice, an
ERP maintenance-data-model in turn is useful for facilitating request categorization,
Exe-5
cost/benefit justification of maintenance requests, charging user departments for their
maintenance requests, making better informed maintenance and upgrade decisions, and
forecasting future maintenance demand based on the historical maintenance data.
Exe-6
E R PM a in te n a n ceT a x o n o m y
E R PM a in te n a n ce
E ffo rtD e te rm in a n t
In ve s tig a te a c tiv itie sin vo lve d in m a in te n a n ce
p re p a ra tio n , m a in te n a n cep ro ce d u re a n d so ftw a re
u p g ra d e
Id e n tifyd im e n s io n s fo r
c la ss ify in gm a in te n a n ce
re q u e s t
E R PM a in te n a n cea n d U p g ra d e
(M U ) D e c is io nF ra m e w o rk
E xa m in e fa c to rsa ffe c tin g
m a in te n a n cee ffo rt
S u b -s tu d y :
P rim a ryR e s e a rc h
O b je c tiv e :
R e s e a rc hQ u e s tio n :
W h a t is E R P m a in te n a n ce ?W h a t a c tiv itie s co m p riseE R P m a in te n a n ce ?H o w ca n E R P m a in te n a n cea c tiv itie s b e u se fu llyc la ss ifie d ?W h a t a re u se fu l d im e n s io n sfo r c la ss ify in g E R Pm a in te n a n ce a c tiv itie s?A re th e e x is tin gm a in te n a n ce c la ss ifica tio n sa p p ro p ria te ?
W h a t a c tiv itie s a n d ta skssh o u ld b e in co rp o ra te d a n dre fle c te d in to a n E R Pm a in te n a n ce m e th o d o lo g y?W h a t a re th e a c tiv itie sa sso c ia te d w ith a n E R Pm a in te n a n ce m e th o d o lo g y?Is th e e x is tin g s ta n d a rd fo rso ftw a re m a in te n a n cem e th o d o lo g y a p p ro p ria te inth e co n te x t o f E R P ?W h a t a re th e a c tiv itie s a n dta sks th a t a re u n iq u e toE R P m a in te n a n cee n v iro n m e n t?
W h a t a re th e fa c to rs th a t sh o u ldb e co n s id e re d in m a k in g E R Pm a in te n a n ce a n d u p g ra d ed e c is io n s?W h a t a re th e m a jo r fa c to rsin flu e n c in g E R P p a tch -m a in te n a n ce a n d u p g ra d e co s ts?W h a t a re th e o p p o rtu n ity co s ts fo rn o t d o in g E R P m a in te n a n ce a n du p g ra d e ?A re th e se fa c to rs th a t sh o u ld b eco n s id e re d in a n E R P u p g ra d ed e c is io n d iffe re d fro m th o seca p tu re d in th e e x is tin g in -h o u seso ftw a re re p la ce m e n t m o d e ls?H o w co u ld th e se fa c to rs b ein c lu d e d in to co s t fu n c tio n s?
E R PM a in te n a n ce -
d a ta -m o d e l
E R PM a in te n a n ce
M e th o d o lo g y
D e te rm in e th efu n d a m e n ta lm e a su ra b le
m a in te n a n cere q u e s t’s a ttr ib u te s
D e te rm in e fa c to rsd riv in g m a in te n a n ce
a n d u p g ra d ed e c is io n s
is re q u ire d toid e n tify w h ic h
a c tiv ity issu p p o s e d toc o lle c t w h a t
d a ta
is re q u ire d toh a ve a n
a p p re c ia tio n o fth e ty p e o f
m a in ten a n c ea c tiv it ie s
is u s e d toh a ve a n
a p p re c ia tio no f fa c to rsa ffe c tin g
m a in te n an c ee ffo rt
W h a t a ttr ib u te s o fm a in te n a n ce e ffo rt a reca p tu re d b y th e ca sefirm ?W h ich o f th e sea ttr ib u te s a re u se fu lp re d ic to rs o fm a in te n a n ce e ffo rt?H o w ca n m a in te n a n cee ffo rt b e m e a su re d ?
W h a t a re th e im p o rta n tE R P m a in te n a n cere q u e s t’s a ttr ib u te s th a tsh o u ld b e ca p tu re d ina n E R P e n v iro n m e n t?D o th e a ttr ib u te sca p tu re d in in -h o u seso ftw a re e n v iro n m e n tsu ffic ie n t in th e co n te x to f E R P ?W h a t a re th e u n iq u eE R P m a in te n a n cere q u e s t’s a ttr ib u te s?
is re q u ire d tom a k e b e tte rq u a lity M Ud e c is io n s
is req u ire d to p la n fo r m a in te n an ce re so u rce s a n d s ta ffing
is re qu ire d to id e n tify th e typ e s o f m a in ten a nce req u e s t
is re qu ire d fo r m a in ten a n ce c la ss ifica tion
P rim a ryD a ta
S o u rc e :
In te rv ie w , ch a n g e -re q u e s td a ta b a se , u se r-su p p o rtd a ta b a se
In te rv ie w , ch a n g e -re q u e s t d a ta b a se ,d o cu m e n ta tio n
In te rv ie w , ch a n g e -re q u e s td a ta b a se , p a tch -su p p o rt d a ta b a se ,m o d ifica tio n d a ta b a se ,d o cu m e n ta tio n
In te rv ie w , ch a n g e -re q u e s t d a ta b a se
In te rv ie w , m a in te n a n ce -re q u e s t fo rm s , ch a n g e -re q u e s t d a ta b a se
M a inD e liv e r-
a b le
M a in te n a n ceT a xo n o m y
M a in te n a n ceM e th o d o lo g y
M a in te n a n ce a n d U p g ra d eD e c is io n F ra m e w o rk
M a in te n a n ce E ffo rtM o d e l M a in te n a n ce -d a ta -m o d e l
is re q u ire d to ass ign a re q u es t typ e to a m a in te n an ce re q ue s tD e te rm in e the d a ta re q u ire d fo rre q ue s t c la ss ifica tio n pu rp ose
Figure 1: Salient characteristics of the five sub-studies
Exe-7
The contributions and findings from this thesis are as follows.
(1) Taxonomy sub-study
Observations made from the analysis of CSA ERP maintenance activities are: (1) the ERP-
using organization does not only maintain internally originated change-requests, but also
implements maintenance introduced by the vendor; (2) requests for user-support concerning
the ERP system behavior, function and training constitute a main part of ERP maintenance
activity; and (3) similar to the in-house software environment, enhancement is the major
maintenance activity in the ERP environment, making up almost 64% of total change-request
effort (this is consistent with the findings from Glass and Vessey (1999)). In light of these and
other findings, ERP maintenance is defined as post-implementation activities until the system
is disposed from the production system; targeting at keeping the system running correctly,
operating well in a changed environment and providing user-support, as well as realizing
more business benefits (e.g. best business practices, enhanced system integration, cost
reduction) and maintaining the installed system a supported version; and covering both
internally and externally originated maintenance requests. ERP maintenance requests can be
usefully characterized along three salient dimensions: (1) source of the maintenance request;
(2) the existence of any business-benefits; and (3) the existence of any impact of the
maintenance on the client’s installed ERP module(s).
It is found that ERP maintenance is not an instance of in-house software maintenance. The
existing in-house maintenance taxonomies are not sufficient to capture the characteristics of
ERP maintenance activities. They lack consideration for some important ERP maintenance
characteristics, i.e. the role of the external party – the software vendor – in maintaining ERP
software; and the (categorization of) business benefit of undertaking the maintenance. Thus,
an ERP-specific maintenance taxonomy tailored to the ERP environment is proposed.
(2) Effort sub-study
The attributes of maintenance effort captured by CSA are maintenance category, task
complexity, and tailoring option. Maintenance effort is measured (by CSA) using the number
of hours spent in servicing the request. The findings suggest that among the three maintenance
project characteristics or independent variables of maintenance category, task complexity and
tailoring option, task complexity is the most influential variable explaining 32% of variance in
maintenance effort at CSA’s site. The second influential variable is maintenance category,
Exe-8
which explains 7% of variance in maintenance effort at CSA’s site. These variables are
statistically significant at the 0.001 levels for explaining variance in maintenance effort at
CSA’s site. These two factors including their interaction term yield adjusted R2=0.395. On the
other hand, the findings for tailoring option variable did not provide convincing evidence that
it is a significant determinant of ERP maintenance effort at CSA’s site.
The supported hypotheses are: (1) maintenance category is a significant predictor of
maintenance effort; and (2) maintenance effort will increase curvilinearly with task
complexity. These findings are consistent with the in-house software study conducted by
Jørgensen (1995). The rejected hypotheses are: (1) configuration-related requests will require
lesser maintenance effort than programming-related maintenance requests; (2) other requests
(non-configuration and non-programming) will require less maintenance effort than
programming-related maintenance requests; and (3) configuration-related requests will require
less maintenance effort than other (non-configuration and non-programming) maintenance
requests. These are counter-intuitive findings.
(3) Decision sub-study
It is found that on average a patch is almost as effort demanding as a user-enhancement
request. Patch-maintenance effort is driven by the number of modification-enhancements, and
type of enhancement done to the standard ERP code.
Upgrade implementation cost also depends on the version-gap or migration-path between an
existing and a new upgrade version. CSA conducts technical upgrades because of the
withdrawal of vendor support for its current version. Benefit-realization is the primary
objective for CSA in considering a functional upgrade. Upgrade cost is a major issue, and
prohibitive for CSA in considering upgrades to its ERP system. These findings are consistent
with those reported in the trade press, see (AMR, 2002; McDonnell, 2000; Thompson, 2001).
It is found, however, that after the upgrade the number of modification-enhancements done
decrease by one-third of the original total. Analysis of the number of notes showed that the
total number of notes and patches decreased by about 21% from an older version to a newer
version.
Results from this study on the ERP maintenance and upgrade environment, show that (1) user
opportunity and benefit realization, (2) reduction in the number of previous modification-
Exe-9
enhancements, and (3) potential reduction in the number of future patch-maintenance
activities are important characteristics of an ERP maintenance and upgrade decision model.
Found in this research is that in-house software replacement models are inappropriate in the
context of ERP. In-house software replacement models are: (1) irrelevant because of the
following characteristics considered in the models: software technology, system size and
system age; and (2) insufficient because they do not capture the benefits and user opportunity
associated with maintenance requests, the availability of maintenance support from the
vendor, and do not incorporate the reduction in number of previous modification-
enhancement in a newer version. Although user opportunity and reduction in the number of
future maintenance activities may also be applicable in in-house software maintenance, they
were not considered in the existing literature. Reduction in the number of previous
modifications is unlikely to be an in-house software replacement-driver because internal
system enhancements are unlikely to be available from external sources and therefore could
not be replaced or reduced. In light of the insufficiencies, a specific ERP maintenance and
upgrade decision framework is proposed.
(4) Methodology sub-study
A comparison between the synthesized CSA’s ERP maintenance methodology and IEEE/EIA
12207.2-1997 (1997) standard for software maintenance methodology shows that although
IEEE/EIA 12207.2-1997 is generic and comprehensive, it lacks certain unique characteristics
of ERP. The major issues overlooked in IEEE/EIA 12207.2-1997 are: (1) availability of
vendor-support; (2) readily available new versions for upgrades; (3) the importance of user-
support activities; and (4) modifying vendor’s codes and replacing custom code with vendor’s
code. This is because IEEE/EIA: (1) constrains its focus to in-house software maintenance;
and (2) emphasizes change-requests activities only (thus, it does not include user-support
request activities.)
While CSA’s ERP maintenance methodology is well-organized and well-managed, there is
still room for improvements. The activities that could enhance the effectiveness and
efficiencies in maintenance management and facilitate better maintenance and upgrade
decision-making are: (1) computing the ongoing user-enhancement maintenance and
forecasting maintenance demands by capturing more related maintenance data; (2) identifying
the repetitive maintenance activities that are best automated; and (3) using a quantitative
mechanism to make better quality maintenance and upgrade decisions.
Exe-10
(5) Data sub-study
A comparison of the synthesized CSA’s ERP maintenance-data-model with the SEI
maintenance-data-model (Florac, 1992) showed that there are strengths and weaknesses in
these two data-models. SEI is generic and comprehensive but in some way is insufficient in
the context of ERP. It lacks consideration of certain maintenance attributes, some of which are
relevant to software in general and some that are ERP-specific. These attributes are: major
functional area, service desk reference, estimate time, quote, quote type, client cost centre,
action to be taken, issues of consideration, vendor change-request number, analyst, and
programmer. These deficiencies could be due to: (1) SEI constrains its focus to defect and
problem reporting only; and (2) the unique characteristics and nature of ERP software
maintenance, such as business benefit oriented maintenance requests, and that it is a cross-
functional software system that is vendor-supported, with the software code belonging to the
vendor.
On the other hand, it is found that there is room for improvement in CSA’s maintenance-data-
model. Maintenance attributes found to be relevant and useful in the context of ERP are
uniqueness (recommended by SEI), rationale for request, existence of business benefit,
existence of impact on installed module(s), benefit category, business value, implementation
cost, ongoing maintenance cost, task complexity, number of patches and modification-
enhancements implemented, details before software modification, details after software
modification, error detection difficulty, and method/tool for detection. These attributes are
believed to be useful in estimating maintenance and upgrade effort and costs, and benefits
quantification, as well as facilitating ERP maintenance and upgrade decision-making. Thus, a
new ERP maintenance-data-model is proposed based on CSA and SEI maintenance-data-
models, and additional relevant attributes. The proposed maintenance-data-model could serve
as: (1) a repository of maintenance activities and maintenance knowledge; (2) a maintenance
controlling and monitoring system; and (3) a maintenance improvement and decision-support
tool.
The main practice-stakeholder in the study is the ERP-using organization that performs ERP
maintenance and upgrade (MU) activities (it is noted that the case organization in the study
has particularly benefited from context specific findings of the study). However, useful
implications are also drawn for the ERP vendor and consultants. The stakeholders considered,
in drawing implications from the study findings, are defined as follows:
Exe-11
(1) ERP-using organization7 – organization that maintains an installed SAP R/3 system, and
whose (i.e. the maintenance departments) responsibilities for ERP maintenance include
initial planning and preparation for ERP maintenance, acting on maintenance requests
from its system users or user-departments, implementing patch-maintenance from the
vendor, and conducting ERP system upgrades (introduced by the vendor) when
appropriate.
(2) ERP vendor – organization that develops the SAP software, continuously maintains and
improves the system, and provides maintenance support such as patches and new
releases/versions for its clients (i.e. ERP-using organizations).
(3) ERP consultant – consulting firm that assists SAP-using organizations with their SAP
maintenance and upgrade activities.
The implications of the main outcomes from this thesis for research and practice are
summarized in Table 1 and are addressed in detail in Chapters 4 through 8.
7 Note that this study does not address ERP-using organizations that do not do ERP maintenance and upgrade - in example, clients of an application service provider (ASP) or outsourcer. An ERP ASP or outsourcer hosts, provides access to, and offers management (including maintenance and upgrade activities) of an ERP system from a facility based on a contract. An ERP outsourcer may find this study relevant to its role as maintainer of ERP systems.
Exe-12
Table 1: Implications of the research outcomes for research and practice
Main outcome Research ERP-using organization ERP-vendor ERP consultant ERP
maintenance
definition
• Defines the bounds and
scope of ERP maintenance.
• Establishes a foundation
upon which further research
can be based.
Can be used to:
• Describe the scope of the
maintenance activity.
• Define the role of the
maintenance team.
• Recruit staff and consultants.
• Shows the vendor’s role in
ERP-using organizations
maintenance activities.
• Helps to identify the type of
maintenance knowledge
required.
ERP
maintenance
taxonomy
• Surveys, and longitudinal
and multiple case studies
from different industries
could be conducted to
enhance and validate the
generalizations and reliability
of the proposed
maintenance taxonomy.
• Could be used to classify
maintenance request more
accurately.
• Can be used to prioritize
maintenance requests based on
the importance of associated
net business benefit.
• Could be utilized to assist in
choosing the most appropriate
upgrade version of ERP.
• Facilitates identification and
minimization of user opportunity
costs.
• Can be used to improve
vendor’s understandings of its
role and impacts on ERP-using
organizations’ maintenance
activities, so that it can:
o Provide a more effective
patch-maintenance
support and minimize the
frequency of patches, and
o Incorporate increased
business value in its new
version(s) of the ERP
system.
• Provides benefit-
perspective, which is
particularly useful to show
to prospective clients the
benefits and potential
savings involved in doing an
upgrade to an existing
version or from outsourcing
maintenance.
ERP
maintenance
effort model
• Findings highlight the value
of further experimental
research aimed at further
• Estimates effort and cost for a
maintenance request.
• Plans for maintenance budget.
• The effort determinants could
also be applicable to the
vendor’s in determining its
• Can be used to estimate
maintenance effort of a
maintenance project for an
Exe-13
Main outcome Research ERP-using organization ERP-vendor ERP consultant confirming the findings. • Allocates maintenance staff to
maintenance job.
software maintenance effort. ERP-using organization.
ERP
maintenance and
upgrade (MU)
decision
framework
• Findings highlight the value
of incorporating the risk
factors in MU project and
vendor-switching costs in the
proposed decision
framework.
• Provides a more
comprehensive illustration of
factors affecting and variables to
be considered in making MU
decision.
• Could be used to plan for long-
term MU strategy, and control
the frequency of upgrades.
• Can be used as a guideline for
ERP managers to evaluate the
costs and benefits of MU
decision-alternatives.
• Facilitate minimizing the total
ERP software lifecycle costs
and maximizing benefits-
realization.
• Can be used to improve the
vendor understanding of key
drivers influencing the clients’
MU decisions. Thus, the vendor
could emphasize the
appropriate “variable(s)” (by
increasing or decreasing the
variables’ values) in order to
achieve their market strategies
(e.g. limit their support for a
version of the software,
increase sales revenue).
• Provides insight into impacts of
vendor maintenance strategy,
policy and initiation on ERP-
using organization’s ERP
software lifecycle costs.
• Could be used to encourage
clients to upgrade their installed
versions.
• Could use the framework as
a tool to justify a MU
decision for an ERP-using
organization.
ERP
maintenance • Surveys, and longitudinal
and multiple case studies
• Provides a methodology for
preparing maintenance and
• Could be used to further
enhance and extend its existing
• It could be used as an ERP
maintenance and upgrade
Exe-14
Main outcome Research ERP-using organization ERP-vendor ERP consultant methodology from different industries
could be conducted to
enhance and validate the
generalizations and reliability
of the proposed
maintenance methodology.
upgrade project, initiation of
request, tracking progress of a
project, and closing a project.
• Provides guidelines for
modifying vendor’s code.
• Provides recommendation for
tools to support cost and benefit
justification (or decision tool).
• Facilitates maintenance and
upgrade project risk
minimization.
• Facilitate identification of best
practice for maintenance and
upgrade processes in the future.
• Facilitates management control.
• Provides visibility of
maintenance activities.
• Provides communication tool
among all parties involved, and
improved team productivity.
maintenance and upgrade (MU)
‘change management’ system.
This could be fully automated
and used as a MU methodology
to help the ERP-using
organization to speed-up, plan
and prepare for MU activities,
particularly for the small- and
medium-sized enterprises
(SME) market sector. This is
analogous to the objectives of
the accelerated SAP (ASAP)
methodology. However, ASAP
aims at (saving time and cost
in) SAP implementation,
whereas this methodology
facilitates the post-
implementation activities – i.e.
maintenance and upgrade
projects.
(MU) methodology to assist
in preparing MU activities
for an ERP-using
organization.
ERP
maintenance-
data-model
• Survey and longitudinal and
multiple case studies from
different industries could be
It can be used:
• As a repository of maintenance
activities and maintenance
• Could be used to identify
whether the proposed
maintenance-data-model is
• Could be used to plan and
prepare a maintenance-
data-model for an ERP-
Exe-15
Main outcome Research ERP-using organization ERP-vendor ERP consultant conducted to enhance and
validate the generalizations
and reliability of the
proposed maintenance-data-
model.
• Findings highlight the value
of proposing maintenance
attributes at maintenance
preparation stage and
software upgrade stage in
order to develop a complete
maintenance-data-model.
knowledge to provide immediate
access to all information past
and current.
o To estimate the ongoing
user-enhancement
maintenance costs.
o To forecast maintenance
demand.
o To enhance the reporting
and visibility of
maintenance activity.
• As a maintenance controlling
and monitoring system
(especially if computerized).
• Support maintenance and
upgrade decision-making.
applicable to its environment
and revise if there is any
attribute not currently recorded
in its existing change
management system (for
example, the Change and
Transport System (CTS)
provided by SAP to its clients to
manage and record all details
about the changes/maintenance
done to the SAP R/3 system.)
using organization.
i
Table Of Contents LISTS OF FIGURES
LIST OF TABLES
1 Introduction.................................................................................................................... 1-1
1.1 Study Context.......................................................................................................... 1-1
1.2 Background ............................................................................................................. 1-3
1.3 Motivation For The Study....................................................................................... 1-5
1.4 Nature Of The Study............................................................................................... 1-7
1.5 Objectives For The Study ....................................................................................... 1-8
1.6 ERP Maintenance Taxonomy (Taxonomy Sub-study) ........................................... 1-9
1.7 ERP Maintenance Effort Model (Effort Sub-study) ............................................. 1-11
1.8 ERP Maintenance and Upgrade Decision Framework (Decision Sub-study) ...... 1-12
1.9 ERP Maintenance Methodology (Methodology Sub-study)................................. 1-14
1.10 ERP Maintenance-data-model (Data Sub-study).................................................. 1-16
1.11 Research Strategy.................................................................................................. 1-19
1.12 Thesis Structure .................................................................................................... 1-24
1.13 Summary ............................................................................................................... 1-27
2 Literature Review .......................................................................................................... 2-1
2.1 ERP Maintenance.................................................................................................... 2-1
2.1.1 Client-Initiated Maintenance: Enhancement................................................... 2-2
2.1.2 Patch-Maintenance.......................................................................................... 2-9
2.2 ERP Upgrade ........................................................................................................ 2-11
2.2.1 Upgrade Decision.......................................................................................... 2-12
2.2.2 Upgrade Cost Drivers ................................................................................... 2-14
2.2.3 Plan For An Upgrade .................................................................................... 2-15
2.2.4 Execution Of An Upgrade ............................................................................ 2-16
2.3 Benefit-realization................................................................................................. 2-17
2.3.1 Organizational-Level Perspective................................................................. 2-19
ii
2.3.2 Business Perspective..................................................................................... 2-22
2.3.3 Similarities Between Organizational-Level And Business Perspectives...... 2-25
2.3.4 Business Value In ERP ................................................................................. 2-27
2.4 Recap – ERP Literature Review ........................................................................... 2-30
2.5 In-house Software Maintenance ........................................................................... 2-31
2.5.1 Software Maintenance Definition ................................................................. 2-32
2.5.2 Classification of Maintenance Activities ...................................................... 2-32
2.5.2.1 Swanson’s Classical Classification........................................................... 2-32
2.5.2.2 Chapin et al.’s New Classification............................................................ 2-34
2.5.3 Determinants of In-house Software Maintenance Effort .............................. 2-36
2.5.4 In-house Software Replacement Model........................................................ 2-39
2.5.5 Standard Software Maintenance Methodology............................................. 2-40
2.5.5.1 IEEE Standard 1219-1998 and ISO/IEC 12207........................................ 2-41
2.5.5.2 IEEE Standard 1219-1998 Versus ISO/IEC 12207 .................................. 2-42
2.5.5.3 IEEE/EIA 12207.2-1997........................................................................... 2-42
2.5.5.4 Maintenance Activities Included In IEEE/EIA 12207.2-1997 ................. 2-43
2.5.6 SEI Maintenance-Data-Model ...................................................................... 2-48
2.6 Recap – In-House Software Literature ................................................................. 2-50
2.7 Contrast of ERP and In-house Software Characteristics ...................................... 2-51
2.8 Gaps In Existing Literature................................................................................... 2-58
2.8.1 Maintenance Taxonomy................................................................................ 2-58
2.8.2 Determinants Of In-House Software Maintenance Effort ............................ 2-60
2.8.3 In-house Software Replacement Model........................................................ 2-61
2.8.4 IEEE/EIA 12207.2-1997............................................................................... 2-62
2.8.5 SEI Maintenance-Data-Model ...................................................................... 2-63
2.9 Summary ............................................................................................................... 2-63
3 Research Methodology .................................................................................................. 3-1
3.1 A Single-Case Study ............................................................................................... 3-1
3.1.1 The Case Background ..................................................................................... 3-2
3.1.2 Units Of Analysis............................................................................................ 3-4
iii
3.1.3 Case Protocol .................................................................................................. 3-5
3.2 Data Collection ....................................................................................................... 3-5
3.2.1 Semi-Structured Interviews ............................................................................ 3-7
3.2.2 Change-Request Database ............................................................................ 3-10
3.2.3 User-Support Database ................................................................................. 3-13
3.2.4 Patch-Support Database ................................................................................ 3-13
3.2.5 SAP System Modification Database............................................................. 3-14
3.2.6 Documentation.............................................................................................. 3-14
3.2.7 Maintenance-Request Forms ........................................................................ 3-14
3.3 Data Analysis ........................................................................................................ 3-15
3.3.1 Taxonomy Sub-study .................................................................................... 3-15
3.3.2 Effort Sub-study............................................................................................ 3-16
3.3.3 Decision Sub-study ....................................................................................... 3-18
3.3.4 Methodology Sub-study................................................................................ 3-21
3.3.5 Data Sub-study.............................................................................................. 3-24
3.4 Validity And Reliability Of The Research Design ............................................... 3-25
3.5 Summary ............................................................................................................... 3-32
4 An ERP Maintenance Taxonomy................................................................................. 4-1
4.1 CSA’s ERP Maintenance Requests: Description.................................................... 4-2
4.2 CSA’s ERP Maintenance Requests: Basic Descriptive Statistics........................... 4-7
4.2.1 Internally Originated Maintenance Requests: User-Support .......................... 4-7
4.2.2 Internally Originated Maintenance Requests: Change-Requests.................... 4-8
4.2.3 Distribution Of Change-Requests Versus User-Support Requests............... 4-10
4.2.4 Externally Originated ERP Maintenance Requests: Patches ........................ 4-12
4.3 ERP Maintenance Definition ................................................................................ 4-13
4.4 Salient Dimensions For Characterizing ERP Maintenance Requests................... 4-15
4.4.1 Maintenance Source...................................................................................... 4-15
4.4.2 Business Benefit............................................................................................ 4-15
4.4.3 Impact On Installed Module(s) ..................................................................... 4-16
4.4.4 An Illustration Using CSA As An Example ................................................. 4-16
iv
4.5 Mapping CSA’s ERP Maintenance Requests Onto Existing Maintenance
Classifications ................................................................................................................... 4-19
4.5.1 Results From Swanson’s Classification........................................................ 4-19
4.5.2 Results From Chapin et al.’s Classification.................................................. 4-20
4.6 The Proposed ERP Maintenance Taxonomy ........................................................ 4-22
4.7 Summary ............................................................................................................... 4-27
5 Characteristics of The Maintenance Project Affecting ERP Maintenance Effort .. 5-1
5.1 Hypothesis............................................................................................................... 5-2
5.2 Basic Descriptive Statistics: The Independent Variables ....................................... 5-6
5.2.1 Maintenance Category .................................................................................... 5-6
5.2.2 Task Complexity............................................................................................. 5-7
5.2.3 Tailoring option .............................................................................................. 5-8
5.3 Regression Analysis................................................................................................ 5-8
5.4 Multivariate Linear Regression Model ................................................................. 5-14
5.4.1 Regression Model Without Interaction Term ............................................... 5-15
5.4.2 Regression Model With Interaction Term .................................................... 5-16
5.5 Comparability Of The Findings With Prior Studies ............................................. 5-19
5.6 Summary ............................................................................................................... 5-22
6 An ERP Maintenance and Upgrade Decision Framework ....................................... 6-1
6.1 Factors Affecting External Change-Requests Costs ............................................... 6-3
6.1.1 Patch-Maintenance.......................................................................................... 6-3
6.1.2 New Version Upgrade..................................................................................... 6-5
6.1.2.1 Impact On Previous Modification-Enhancement........................................ 6-5
6.1.2.2 Impact On Future Patch-Maintenance ........................................................ 6-7
6.2 Reasons To Do Maintenance And Upgrade............................................................ 6-8
6.2.1 User Opportunity Cost Quantification: A Simple Method ............................. 6-9
6.2.2 Benefit-Realization Quantification: Examples ............................................. 6-10
6.2.3 User Opportunity Cost Quantification: An Example.................................... 6-13
6.2.4 Summary of Findings.................................................................................... 6-15
v
6.3 Implication of Findings From This Research ....................................................... 6-15
6.4 A Framework For ERP Maintenance And Upgrade Decisions ............................ 6-19
6.4.1 Characteristics Of The Decision Framework................................................ 6-19
6.4.2 Assumptions Made In The Decision Framework ......................................... 6-19
6.4.3 Decision Alternatives.................................................................................... 6-20
6.4.4 Trade-offs Involved In Decision Alternatives .............................................. 6-20
6.4.4.1 System Users Maintenance Requests........................................................ 6-20
6.4.4.2 CSA-Enhancement.................................................................................... 6-22
6.4.4.3 Vendor’s Patches ...................................................................................... 6-23
6.4.4.4 Upgrade..................................................................................................... 6-23
6.4.5 An Illustration Of The Application Of The Decision Framework: For
Recurrent Decision Making .......................................................................................... 6-30
6.5 A General ERP Maintenance And Upgrade Decision Model............................... 6-38
6.5.1 Characteristics Of The General Decision Model .......................................... 6-38
6.5.2 Cost Components .......................................................................................... 6-38
6.5.3 An Illustration Of The Application Of The General ERP Decision Model:
For One-Time Decision-Making................................................................................... 6-39
6.6 Summary ............................................................................................................... 6-53
7 An ERP Maintenance Methodology............................................................................. 7-1
7.1 CSA’s ERP Maintenance Methodology ................................................................. 7-2
7.1.1 Maintenance Preparation ................................................................................ 7-3
7.1.2 Maintenance Procedure................................................................................... 7-7
7.1.2.1 Servicing Maintenance Requests From The System Users And IT-Staff... 7-7
7.1.2.2 Servicing Maintenance Requests From The Vendor ................................ 7-14
7.1.3 Software Upgrade ......................................................................................... 7-16
7.2 Discussion On Deficiency In IEEE/EIA 12207.2-1997 ....................................... 7-20
7.2.1 Maintenance Preparation .............................................................................. 7-21
7.2.2 Maintenance Procedure................................................................................. 7-21
7.2.3 Software Upgrade ......................................................................................... 7-22
7.2.4 Further Thoughts........................................................................................... 7-23
vi
7.3 Strengths of IEEE/EIA 12207.2-1997 .................................................................. 7-24
7.4 Insufficiencies in CSA’s ERP Maintenance Methodology................................... 7-24
7.5 The Proposed ERP Maintenance Methodology.................................................... 7-26
7.5.1 Maintenance Preparation Stage (P)............................................................... 7-27
7.5.2 Maintenance Procedure Stage (M)................................................................ 7-30
7.5.3 Software Upgrade Stage (U)......................................................................... 7-32
7.5.4 Maintenance Request And Its Maintenance Procedure ................................ 7-35
7.5.5 The Benefits Of An ERP Maintenance Methodology To Client-
Organization.................................................................................................................. 7-35
7.6 Summary ............................................................................................................... 7-38
8 An ERP Maintenance-Data-Model .............................................................................. 8-1
8.1 CSA And SEI Maintenance-Data-Models .............................................................. 8-2
8.2 Differences Between CSA And SEI Maintenance-Data-Models ........................... 8-7
8.2.1 Investigation Phase ......................................................................................... 8-9
8.2.2 Resolution Phase........................................................................................... 8-11
8.2.3 Delivery Phase .............................................................................................. 8-11
8.3 The Proposed ERP Maintenance-Data-Model...................................................... 8-11
8.3.1 Additional Attributes For Consideration ...................................................... 8-12
8.3.2 The Maintenance-Data-Model ...................................................................... 8-16
8.4 Benefits From The Proposed Maintenance-Data-Model ...................................... 8-18
8.4.1 A Repository Of Maintenance Activities And Maintenance Knowledge..... 8-19
8.4.2 A Maintenance Controlling And Monitoring System................................... 8-19
8.4.3 A Maintenance Improvement And Decision-Support Tool.......................... 8-20
8.5 Summary ............................................................................................................... 8-21
9 Summary And Future Research................................................................................... 9-1
9.1 Summary Of The Research Problem, Objectives And Methodology..................... 9-1
9.2 Summary Of Research Findings, Main Outcomes, And Contributions.................. 9-2
9.2.1 Taxonomy Sub-study ...................................................................................... 9-3
9.2.2 Effort Sub-study.............................................................................................. 9-4
vii
9.2.3 Decision Sub-study ......................................................................................... 9-4
9.2.4 Methodology Sub-study.................................................................................. 9-5
9.2.5 Data Sub-study................................................................................................ 9-6
9.3 Validity And Reliability Of The Study................................................................. 9-14
9.4 Limitations ............................................................................................................ 9-19
9.4.1 Generalizations ............................................................................................. 9-19
9.4.2 Scope Of The Sub-Studies ............................................................................ 9-21
9.5 Implication Of The Research ................................................................................ 9-22
9.5.1 Implications For Research ............................................................................ 9-22
9.5.2 Implications For ERP-Using Organization................................................... 9-23
9.5.3 Implications For ERP-Vendor ...................................................................... 9-27
9.5.4 Implications For ERP Maintenance Consultant............................................ 9-28
9.6 Future Research .................................................................................................... 9-28
9.6.1 Taxonomy Sub-study .................................................................................... 9-28
9.6.2 Effort Sub-study............................................................................................ 9-29
9.6.3 Decision Sub-study ....................................................................................... 9-30
9.6.4 Methodology Sub-study................................................................................ 9-31
9.6.5 Data Sub-study.............................................................................................. 9-32
9.6.6 The Big Picture ............................................................................................. 9-33
9.7 Conclusions........................................................................................................... 9-34
APPENDICES
A. Glossary
B. Comparison between the IEEE Standard 1219-1998 (IEEE, 1998), and ISO/IEC
12207 (ISO/IEC, 1995) Software Maintenance Methodology
C. Case Protocol
D. Case Study Database
BIBLIOGRAPHY
viii
List Of Figures Figure 1.1: Interconnectivity, research ideas, primary research objectives, and research
questions for the five sub-studies.................................................................................. 1-18
Figure 1.2: Research design.................................................................................................. 1-23
Figure 1.3: Thesis chapters diagram ..................................................................................... 1-26
Figure 2.1: Standards referenced .......................................................................................... 2-43
Figure 3.1: CSA’s organization chart ..................................................................................... 3-3
Figure 3.2: Data source and research output........................................................................... 3-6
Figure 3.3: Data analysis process for CSA’s ERP maintenance classification..................... 3-16
Figure 3.4: Data analysis process for the decision framework ............................................. 3-19
Figure 3.5: A protocol for decision framework .................................................................... 3-20
Figure 3.6: Data analysis process for CSA’s ERP maintenance methodology..................... 3-23
Figure 3.7: Data analysis process for CSA’s ERP maintenance-data-model ....................... 3-25
Figure 3.8: Detailed study design ......................................................................................... 3-35
Figure 4.1: The flow of Chapter 4 .......................................................................................... 4-1
Figure 4.2: Number of change-requests and user-support requests over time...................... 4-10
Figure 4.3: Dimensions for characterizing ERP maintenance request ................................. 4-17
Figure 4.4: The process of identifying client-benefits oriented taxonomy of ERP
maintenance .................................................................................................................. 4-23
Figure 4.5: Level-1 of the client-benefits oriented taxonomy of ERP maintenance ............ 4-24
Figure 4.6: Connectivity among the business benefit categories.......................................... 4-26
Figure 5.1: The flow of Chapter 5 .......................................................................................... 5-2
Figure 5.2: Illustration of regression model 4.3 – maintenance effort.................................. 5-19
Figure 6.1: Connection between Chapter 5 and Chapter 6 ..................................................... 6-2
Figure 6.2: The flow of Chapter 6 .......................................................................................... 6-3
Figure 6.3: SAP versions with the respective number of patches and notes .......................... 6-7
Figure 6.4: ERP decision framework: decision alternatives, trade-offs, and cost
functions........................................................................................................................ 6-29
Figure 6.5: Trade-off between user opportunity cost and maintenance cost ........................ 6-30
ix
Figure 6.6: Request-1 and request-2: ongoing maintenance cost payment .......................... 6-31
Figure 6.7: Comparison in annual and cumulative maintenance costs between the two
options........................................................................................................................... 6-50
Figure 6.8: Savings from upgrading the installed version .................................................... 6-51
Figure 7.1: The flow of Chapter 7 .......................................................................................... 7-2
Figure 7.2: Flowchart of CSA’s maintenance procedure for requests from system user
and IT-staff.................................................................................................................... 7-13
Figure 7.3: Flowchart of CSA’s maintenance procedure for patch-maintenance................. 7-16
Figure 7.4: Major activities involved in ERP maintenance methodology............................ 7-28
Figure 8.1:The flow of Chapter 8 ........................................................................................... 8-2
Figure 8.2: The proposed ERP maintenance-data-model for maintenance procedure
stage.. ............................................................................................................................ 8-17
Figure 9.1: Suggestions for improvement............................................................................. 9-26
Figure 9.2: Model of ERP maintenance taxonomy and user opportunity cost ..................... 9-29
Figure 9.3: Model of modification-enhancements, patch-maintenance and upgrade effort . 9-31
Figure 9.4: Model of ERP maintenance methodology, maintenance management control
and productivity ............................................................................................................ 9-32
Figure 9.5: Model of ERP maintenance-data-model, maintenance knowledge,
productivity and decision-making................................................................................. 9-33
Figure 9.6: ERP maintenance management model ............................................................... 9-34
x
List Of Tables Table 1.1: Primary data type, data analysis method, inputs and main deliverable in each
sub-study....................................................................................................................... 1-20
Table 1.2: Main focus in each chapter .................................................................................. 1-21
Table 2.1: SAP categorization of software tailoring............................................................... 2-4
Table 2.2: Researchers categorization of SAP software tailoring .......................................... 2-5
Table 2.3: Factors considered in SAP (1998) and Brehm et al. (2001) categorizations of
tailoring options .............................................................................................................. 2-5
Table 2.4: Matching between researchers and SAP tailoring typologies ............................... 2-6
Table 2.5: SAP patch types..................................................................................................... 2-9
Table 2.6: List of potential ERP systems’ benefits from the organizational-level
perspective. ................................................................................................................... 2-20
Table 2.7: Benefit categories from business perspective...................................................... 2-24
Table 2.8: Similarity between the organizational-level and business perspectives .............. 2-26
Table 2.9: Examples of benefit-realization from ERP systems. ........................................... 2-28
Table 2.10: Recap of the known and unknown about ERP maintenance and upgrade ........ 2-30
Table 2.11: Swanson’s categories of maintenance activities................................................ 2-33
Table 2.12: Comparison of two studies on maintenance effort distribution among
different maintenance categories .................................................................................. 2-34
Table 2.13: Chapin et al.’s evidence of maintenance activities............................................ 2-34
Table 2.14: Software attributes in SEI maintenance-data-model ......................................... 2-49
Table 2.15: Recap - In-house software maintenance literature............................................. 2-50
Table 2.16: Summary of differences between ERP and in-house software.......................... 2-56
Table 2.17: Strengths and weaknesses of the existing maintenance classifications ............. 2-60
Table 2.18: Previous study in maintenance project characteristics ...................................... 2-61
Table 2.19: Summary of the gaps in the literature in the context of ERP ............................ 2-64
Table 3.1: Sub-study and unit of analysis............................................................................... 3-4
Table 3.2: Change-request table ........................................................................................... 3-10
Table 3.3: Timesheet table.................................................................................................... 3-12
xi
Table 3.4: Personnel table..................................................................................................... 3-12
Table 3.5: Company table ..................................................................................................... 3-12
Table 3.6: Work type table.................................................................................................... 3-12
Table 3.7: Product table ........................................................................................................ 3-13
Table 3.8: Variables and the corresponding field names in change-request table................ 3-17
Table 3.9: Criteria to judge the quality of case study research............................................. 3-28
Table 3.10: Construct and internal validity of this study...................................................... 3-29
Table 3.11: Criteria for judging the generalization of this study’s results............................ 3-30
Table 3.12: Reliability tactics applied in this study.............................................................. 3-31
Table 3.13: Summary of the data sources and data analysis in each sub-study.................... 3-33
Table 4.1: CSA’s maintenance request classification............................................................. 4-2
Table 4.2: Objective and activity-evidence of CSA’s ERP maintenance requests................. 4-5
Table 4.3: Distribution of maintenance effort in in-house software and ERP........................ 4-7
Table 4.4: Frequency count for internally originated change-requests................................... 4-9
Table 4.5: Effort distribution among the internally originated change-requests .................... 4-9
Table 4.6: Rate of change in number of requests per month ................................................ 4-11
Table 4.7: Patch-maintenance............................................................................................... 4-13
Table 4.8: CSA’s maintenance request and Swanson’s maintenance classification ............ 4-20
Table 4.9: CSA’s maintenance categories and Chapin et al.’s maintenance classification.. 4-21
Table 4.10: Benefit categorization in ERP maintenance request.......................................... 4-26
Table 4.11: ERP maintenance category and business benefit category................................ 4-27
Table 5.1: List of independent variables considered in the study........................................... 5-5
Table 5.2: Characteristics of maintenance project and the measurements ............................. 5-6
Table 5.3: Maintenance category and maintenance effort ...................................................... 5-6
Table 5.4: Task complexity and maintenance effort............................................................... 5-7
Table 5.5: Tailoring option and maintenance effort ............................................................... 5-8
Table 5.6: Reference categories for the independent variables .............................................. 5-9
Table 5.7: Linear and polynomial models for task complexity ............................................ 5-12
Table 5.8: Cross-tabulation between maintenance category and tailoring option ................ 5-14
Table 5.9: The multivariate regression model (without interaction term) ............................ 5-16
Table 5.10: The multivariate regression model (with interaction term) ............................... 5-17
xii
Table 5.11: Collinearity statistics and diagnostics................................................................ 5-18
Table 5.12: Hypotheses results ............................................................................................. 5-21
Table 5.13: Similarity in findings between ERP and in-house software maintenance......... 5-22
Table 6.1: Patch-maintenance effort ....................................................................................... 6-4
Table 6.2: Comparison of total number of modification-enhancements before and after a
new version upgrade ....................................................................................................... 6-6
Table 6.3: Examples of maintenance requests and benefit quantifications .......................... 6-12
Table 6.4: User opportunity costs and maintenance request priorities ................................. 6-14
Table 6.5: Comparison of characteristics considered in the existing replacement models
and fundamental characteristics of ERP maintenance and upgrade environment ........ 6-17
Table 6.6: Impact of modification-enhancement on software code, and maintenance
effort.............................................................................................................................. 6-18
Table 6.7: Description of variables considered in the decision framework.......................... 6-26
Table 6.8: Maintenance requests: total maintenance costs ................................................... 6-33
Table 6.9: Maintenance requests: total opportunity costs..................................................... 6-35
Table 6.10: Maintenance requests: decision policy .............................................................. 6-37
Table 6.11: Historical data on CSA's internally and externally originated change-
requests.. ....................................................................................................................... 6-45
Table 6.12: User-enhancement and patch-maintenance effort ............................................. 6-46
Table 6.13: User opportunity cost for not upgrading............................................................ 6-47
Table 6.14: Impact of upgrade on enhancement-done and patch-maintenance.................... 6-47
Table 6.15: Total annual and cumulative ERP maintenance costs ....................................... 6-49
Table 6.16: Sensitivity analysis between cumulative ERP maintenance cost and upgrade
timing ............................................................................................................................ 6-51
Table 6.17: Decision problem and the application of the proposed decision framework..... 6-52
Table 7.1: Maintenance request and its maintenance procedure discussion section .............. 7-8
Table 7.2: Summary of deficiencies in IEEE/EIA 12207.2-1997 ........................................ 7-23
Table 7.3: Maintenance category and the expected maintenance procedure........................ 7-35
Table 8.1: Cross-reference of the CSA and SEI maintenance request’s attributes................. 8-4
Table 8.2: Summary of main differences................................................................................ 8-8
Table 8.3: The additional attributes for ERP maintenance-data-model................................ 8-15
xiii
Table 9.1: Summary of findings ............................................................................................. 9-8
Table 9.2: Validity and quality of this study......................................................................... 9-15
Table 9.3: Criteria for judging the generalization of this study’s results.............................. 9-17
Table 9.4: Generalization of the findings ............................................................................. 9-19
Table 9.5: Alternative explanation for research findings...................................................... 9-35
1-1
1 Introduction
This chapter aims to provide an overview of the study, Management of Enterprise Resource
Planning (ERP) Maintenance and Upgrade. This includes: (1) the study context, background,
motivation (the big picture), nature and objectives of the study, (2) specific motivations,
research questions, contributions and significance of each sub-study, (3) research strategy
adopted, and (4) the thesis structure. It proceeds as follows. Section 1.1 presents the study
context – ERP software and its functionality, history, market value, vendor details, and
installed customer base. Section 1.2 provides background to the study and highlights its
relationship with a larger project. Section 1.3 discusses the motivation for the study,
identifying the primary research problems and foci of this research. Section 1.4 describes the
nature and characteristics of this research project. Based on the study motivation, Section 1.5
describes the objectives of the research. Section 1.6 presents the taxonomy sub-study’s
specific motivations, research questions, contributions and significance. Section 1.7 describes
the effort sub-study’s specific motivations, research questions, contributions and significance.
Section 1.8 provides the decision sub-study’s specific motivation, research questions,
contributions and significance. Section 1.9 produces the methodology sub-study’s specific
motivation, research questions, contributions and significance, whereas section 1.10 reports
the data sub-study’s specific motivation, research questions, contributions and significance.
Section 1.11 presents the research strategy. Section 1.12 details the structure of the thesis.
Lastly, Section 1.13 gives a summary of this chapter. (A glossary of the common terms used
throughout this thesis is given in Appendix A.)
1.1 Study Context
Over the last decade, many large organizations have moved from developing in-house
business application software to licensing and installing large off-the-shelf software packages
commonly known as Enterprise Resource Planning (ERP) systems. ERP has become a basic
business information data processing requirement for today’s large organizations. ERP are
fully integrated, enterprise-wide business applications offering not only a complete set of
traditional business modules such as finance, human resources management, sales and
1-2
distribution, and manufacturing and logistics, but also providing extensions such as supply
chain management (SCM), data warehousing, customer relationship management (CRM) and
e-Commerce. McKinsey Quarterly claims that in the past decade, approximately $300 billion
has been invested in ERP worldwide (James et al., 2000).
ERP provides the information management infrastructure for automation (Morphy, 1999) and
a high-level view of processes taking place in an organization (Slater, 1999). Some authors
believe that ERP has evolved from Manufacturing Resource Planning (MRPII) (Farley, 2000;
Jakovljevic, 2000c; Klaus et al., 2000; Norris et al., 2000). This is not without controversy.
Turban and Aronson (2001) state that “the name ERP is somewhat misleading because the
software does not concentrate on either planning or resources” (pg. 331) but it focuses on
integration across a company for all departments and functions into a single computer system
to serve the entire enterprise needs. It employs a single relational database system and a
uniform user interface across all of its modules. A widely and well implemented ERP can
facilitate more informed corporate decisions that take all major areas and interactions in the
corporation into consideration (Fontana, 1998; Hicks et al., 1995), as well as facilitating
operational cost reduction. However, its deployment can involve considerable business
process analysis and change, as well as employee retraining and cultural change, as it drives
the way an organization does business.
In the early 1990s, demand for ERP from large enterprises having revenue of more than $250
million with multi-site operations, plant, headquarters, and subsidiaries around the world
increased dramatically. Since then, it has gone through several stages of industry adoption.
Beginning in the mid 1990s, the market for ERP grew more than 50% every year, with the
market value of ERP sales rising from US$5.7B in 1995 to US$16.6B in 1998, according to
AMR research in (Jakovljevic, 2000a). This growth was driven by demand for fully integrated
and automated systems, system standardization, Y2K problems and the introduction of the
Euro currency. Subsequent to 1998, the ERP market slowed, with the annual growth rate
dropping to approximately 25% (Jakovljevic, 2000a). This is believed to be due to market
saturation in large enterprises, unstable demand from Small- and Medium-Enterprises
(SMEs), post Y2K, and the economic slump in Asia. However, upgrades to the installed base
of ERP, together with continued demand from SMEs, mean that ERP sales are expected to
grow to US$55B-60B of the world software market by 2003 (Jakovljevic, 2000a). According
to AMR Research, the enterprise applications market (including ERP, customer relationship
1-3
management – CRM and supply chain management – SCM) will grow to US$70B by 2006
(2002a).
The top five ERP vendors are SAP (capturing 32% of ERP market share worldwide as at year
2001), Oracle (14.5%), PeopleSoft (9%), J.D. Edwards (5%), and Baan (2.7%) (Jakovljevic,
2001b). Trade reports indicate that there are tens of thousands of organizations using ERP and
millions of licensed users (Girard, 2000). SAP reports that in the year 2002 there are more
than 18,000 companies in over 120 countries running more than 50,000 installations of SAP
software (2002).
1.2 Background
This research contributes to a project named Cooperative Enterprise Resource Planning (ERP)
Lifecycle Knowledge Management. Implementing large packaged application software is
typically a long-term investment, having long-term maintenance implications. Thus, decisions
concerning the source of the application software, as well as the source of support for its
maintenance, implicitly reflect the long-term maintenance strategy (Gable et al., 1998). The
client-organization, vendor and consultants are not only isolated stakeholders, but important
actors, and ostensibly partners, in a relationship that may span the life of the software. Across
the ERP lifecycle, client-organizations, vendors, and consultants work together to realize ERP
benefits in a way suggestive of an extended virtual organization (Sieber et al., 1999a). For
example, organizational virtualness recognizes that modern organizations have moved to
explicit and implicit models of shared services and have outsourced non-core activities
(Bennett et al., 2000). The overriding objectives of the larger project are to better understand
what knowledge is required in support of the health and longevity of the ERP system, and
how the three key players (client-organization, vendor and consultants) can collaborate most
effectively in the generation, supply and maintenance of this knowledge across the ERP
lifecycle. This research project supports and contributes to the ideas of the Cooperative
Enterprise Resource Planning (ERP) Lifecycle Knowledge Management Project by focusing
on the knowledge of ERP maintenance and upgrade.
Quinn et al. (1996) report that knowledge is associated with professional intellect in
organizations, which centers around know-what, know-how, know-why and self-motivated
1-4
creativity. Specifically, this research project addresses the knowledge surrounding ERP
maintenance and upgrade (MU) by identifying the ‘know-what’, ‘know-how’ and ‘know-
why’, which ultimately will facilitate the development of knowledge infrastructure for ERP
post-implementation activities. They are as follows.
(1) Identifying the following know-what aspects of ERP maintenance and upgrade
activities (within an ERP-using organization):
a. Definition of ERP maintenance.
b. Dimensions for classifying maintenance requests (maintenance taxonomy).
c. Factor(s) affecting ERP maintenance effort.
d. Important factors to consider in making maintenance and upgrade decisions.
e. Sequence of activities involved in ERP maintenance preparation, maintenance
procedure, and software upgrade (maintenance methodology).
f. Fundamental maintenance request’s attributes to record.
(2) Using the identified know-what factors, propose and describe the know-how to utilize,
manage and capture know-what:
a. Maintenance taxonomy – to describe how to classify requests, and how to
identify what business-benefit a request brings.
b. A quantification method and decision framework could be utilized as tools – to
quantify benefits, and illustrate how a better-informed decision can facilitate
benefit maximization and can minimize the ERP software lifecycle costs or
total cost of ownership.
c. Maintenance methodology – to describe how to initiate/prepare, plan, organize,
manage, execute, monitor, and close maintenance and upgrade projects.
(3) Explaining the know-why about know-what:
a. Rationale behind each of the activities involved in ERP maintenance
preparation, maintenance procedure, and the upgrade process (e.g., identify the
significance of the activities, implications of not performing the task and so
forth).
b. Rationale for capturing measurable maintenance attributes (e.g., to forecast
future maintenance demand, determine maintenance performance and so forth).
1-5
The emphasis in this study is limited to ERP-using organizations. Although the ERP vendor is
a stakeholder to the extent that it influences, is involved in, and has a stake in the ERP-using
organization, vendor maintenance of ERP is not the focus of this study.
1.3 Motivation For The Study
Although research into ERP is not new, most of the prior research and trade literature looks at
the packaged software implementation issues. There has been relatively little research on the
post-implementation issues of ERP, and in particular, maintenance and upgrade. Sample
implementation studies address ERP implementation strategies and approaches (Brown et al.,
1999; Koch et al., 1999), hidden costs in ERP implementation (Slater, 1998), critical
dimensions in shaping organizational change during the adaptation phase of software
implementation (Volkoff, 1998), and so forth. Most attention has been given to critical
success factor (CSF) for implementation of an enterprise system, see (Clemons, 1998; Scott,
1999; Sumner, 1999). These studies emphasize fundamental issue such as business process
knowledge (ASAP World Consultancy et al., 1996; Bancroft et al., 1998), project complexity
(Holland et al., 1998), change management (Barnes, 1999), cultural issues (Shanks et al.,
2000), ERP implementation pitfalls (Ross et al., 2000) and working in partnership with
software and hardware vendors, consultants and third-party vendors (Simon, 1997). Research
done by Sieber et al. (1999b) describe the benefits of implementing an ERP system at the
University of Nebraska, whereas Glover et al. (1999) provide the implications and impacts of
poor ERP implementation for an organization.
Following ERP system implementation is the post-implementation or maintenance activities.
Worldwide, ERP-using organizations are now facing the costs and challenges of maintaining
the large packaged software. Three major maintenance-related costs an ERP-using
organization needs to consider are annual maintenance-support fees (payable to the vendor),
annual user maintenance costs, and upgrade costs. Annual maintenance-support charges for
ERP systems are typically 12-20% of the software license fee (Jakovljevic, 2001a) and are
payable to the vendor in order to obtain maintenance support such as bug fixes or patches.
This fee is paid for a pre-specified period of maintenance-supported time, which is typically
three years. On the other hand, the annual user maintenance costs include the costs of
implementing the patches introduced by the vendor, and implementing maintenance requests
1-6
originating from internal system users and IT staff. A study conducted by Glass and Vessey
found that on average the ongoing annual maintenance costs are roughly 25% (5-50%) of the
original implementation costs (Glass et al., 1999). In addition to the annual maintenance-
support fees and user maintenance costs, an upgrade effort (for additional functionality,
including the upgrade preparation and execution) is reported to be as much as 25-33% of the
initial ERP implementation costs (Carlino et al., 2000). If an ERP was used for 10 years and
upgrade took place three times, then the upgrade would cost about 22% and maintenance 56%
of the total ERP software lifecycle costs. Although the upgrade cost is significant, most of the
ERP-using organizations continue to upgrade in order to utilize the new functionality or
business ‘opportunities’ of a new version (AMR, 2002b).1 Three success stories, from Canada
Post, the Tyrolit Group and Brother International, report a variety of benefits from mySAP
CRM (a software extension introduced by SAP), with estimated return on investment ranging
from 26% to 124% and break-even in two years time (SAP, 2002).
In the nutshell, the study of the management of ERP maintenance and upgrade (MU) has been
neglected in the past. Determining the appropriate mechanisms, tools and methodology for the
management of ERP MU so that these activities can be managed more effectively and
efficiently is not trivial for ERP-using organizations as evident from the cost and effort
already spent and to be spent. In light of the gap in existing literature and non-trivial ERP
maintenance and upgrade costs and challenges faced by ERP using-organizations, this
research project aims to address this literature gap by exploring and examining the suitable
mechanisms and methodology for effective and efficient management of ERP maintenance
and upgrade2. Effective and efficient management of ERP MU activities will allow resources
to be allocated efficiently and economically; facilitate MU cost control; enable decisions to be
made accurately; allow MU knowledge identification, storage, retrieval and reuse; and as a
whole it facilitates cost minimization and benefit maximization. As a result, this study begins
by seeking to understand: (1) What types of ERP maintenance requests (i.e. maintenance
taxonomy) are involved in the ERP maintenance environment, the determinants of ERP
maintenance effort, factors affecting ERP maintenance and upgrade (MU) decisions, activities
involved in maintenance and upgrade methodology, and maintenance data that need to be
captured in order to facilitate decision-making (i.e. a maintenance-data-model); (2) How to
1 Also, ERP vendor such as SAP requires their customers to upgrade their systems after a certain period of time depending on the software version (SAP, 2002a). 2 Some authors use software evolution as a synonym for software maintenance (Chapin et al. 2001, pg, 21). In this thesis, the author simply uses the term ERP maintenance and upgrade as it is more straightforward, intuitive and simple to understand.
1-7
effectively classify maintenance requests, estimate maintenance effort, make better-informed
MU decisions, manage MU activities and identify fundamental maintenance request’s
attributes; and, (3) Why maintenance taxonomy, effort determinants, related decisions,
methodology and data are important.
1.4 Nature Of The Study
This research is an exploratory, descriptive, revelatory and collaborative case study. It is
exploratory and descriptive because ERP maintenance and upgrade (MU) is a relatively new
research area about which little is known compared to existing literature that is primarily
based on in-house software or mainly focussed on ERP implementation. It is worth some
research endeavors to understand if prior studies that are primarily based on in-house software
are applicable in the context of ERP, and to determine if ERP maintenance and upgrade is
merely an instance of in-house software maintenance. The study is also revelatory, in that the
author has comparatively advantageous access to previously inaccessible, detailed ERP MU
evidence. It is a collaborative study with both the participating case firm (a Queensland
Government agency) and SAP3 being stakeholders, both having interest in relatively more
pragmatic observations and outcomes. In addition to these partners, other key beneficiaries of
the study findings include the consulting firms that often ‘partner’ ERP-using organizations
on their ERP implementations and in ongoing supports.
In light of the revelatory nature of this study – “an opportunity to observe and analyze a
phenomenon previously inaccessible to scientific investigation” (page 40), a single case study
(research approach) is justified (Yin, 1994). Both the revelatory and collaborative nature of
this study promote attention to breadth over depth, in order to maximally describe the new
research setting and to open new research areas, and yield more practical research outcomes.
As the nature of this study is an exploratory, revelatory and descriptive which is to examine a
new research area, to observe and analyze a phenomenon previously inaccessible to scientific
investigation and to broadly describe this phenomenon, non theory-based inquiry and
approach is justified in this case.
3 SAP software is the main focus in this thesis because: (1) the case firm in this study uses SAP software, (2) SAP is a top-tier ERP software, and (3) majority of research done so far are based on SAP software. Thus, this can facilitate the author in making references, associations and comparisons with existing studies or knowledge relevant to this thesis.
1-8
1.5 Objectives For The Study
One of the main objectives in this study (from the research perspective) is to understand if
prior studies that are primarily based on in-house software are applicable in the context of
ERP, and to determine if ERP maintenance and upgrade is merely an instance of in-house
software maintenance.
In light of the dearth of research on the management of packaged software in general and ERP
in particular, and given the high cost of maintenance and upgrade activities and non-trivial
decisions faced by ERP-using organizations, in addition to a definition of ERP maintenance,
this research project intends to empirically identify and develop:
1. Dimensions for classifying ERP maintenance requests, and propose an ERP
maintenance taxonomy.
2. Project characteristics affecting ERP maintenance effort, and develop an ERP
maintenance effort model.
3. Factors affecting ERP maintenance and upgrade (MU) decisions, and develop an ERP
MU decision framework.
4. Activities involved in ERP maintenance preparation, maintenance procedure and
software upgrade, and develop an ERP maintenance methodology.
5. Fundamental measurable ERP maintenance request’s attributes, and develop an ERP
maintenance-data-model.
Effective and efficient management of ERP maintenance and upgrade is practically believed
to be important aides to containing ERP maintenance and upgrade costs and facilitating
benefits-realization from ERP through proper:
Maintenance taxonomy—to facilitate maintenance requests prioritization based on
business benefit perspective and thus minimization of user opportunity costs, resolving
emergency requests quickly, allowing progress tracking and ease of reference to a
request.
Identification of factors affecting maintenance effort—for estimating maintenance
effort and facilitating decision-making related to maintenance (and upgrade).
Justification and quantification of ERP maintenance and upgrade decisions—for
minimizing total ERP lifecycle costs and facilitating more benefit-realization.
1-9
Planning for maintenance and upgrade activities—to improve the effectiveness and
efficiency in maintenance management.
Recording of measurable maintenance request’s attributes—for justifying maintenance
decisions, and forecasting maintenance demand.
In order to achieve these goals, five main research areas are studied. They are: (1)
maintenance taxonomy, (2) maintenance effort determinants, (3) maintenance and upgrade
decision framework, (4) maintenance methodology, and (5) maintenance-data-model. Note
that this does not necessarily imply that they are the only five fundamental research problems
in the management of ERP maintenance and upgrade (a relatively new and under-studied
discipline). Other promising research areas such as maintenance productivity, performance,
human capital and determinants of software maintenance expenditures are also worthy of
research. However, due to limited resources and data, these are not included in this study.
Each of the mentioned research areas is in fact a sub-study, namely taxonomy sub-study,
effort sub-study, decision sub-study, methodology sub-study, and data sub-study respectively.
Interconnectivity among the five sub-studies – In order to facilitate maintenance requests
prioritization and management, ERP maintenance managers must usefully classify
maintenance requests (i.e. taxonomy sub-study). To plan for efficient maintenance, managers
must have an appreciation of the key drivers of ERP maintenance effort (effort sub-study). In
order to make better-quality maintenance and upgrade decisions, ERP maintenance managers
require a decision tool or framework (decision sub-study). In initiating, planning, organizing,
managing, executing, monitoring, and closing maintenance and upgrade projects, a
comprehensive maintenance methodology is important (methodology sub-study). More
broadly, in order to perform maintenance activities increasingly efficiently and effectively,
and to facilitate benefit-realization from ERP system, appropriate information and knowledge
about maintenance and upgrade activities must be retained (data sub-study).
1.6 ERP Maintenance Taxonomy (Taxonomy Sub-study) Motivation – Like traditional in-house software, ERP also requires ongoing maintenance.
And, though the software vendor is responsible for certain maintenance (for example bug
fixes, continuous improvement or enhancements) of ERP package, maintenance activities for
1-10
ERP-using organizations (originated form the system users) are substantial (Glass et al.,
1999). In the process of managing maintenance requests, one of the fundamental tasks of an
ERP maintenance manager is to classify maintenance requests that arrive. There has been
little examination of what constitutes ERP maintenance activity. No definition of ERP
maintenance could be found in the existing ERP literature. While the Institute of Electrical
and Electronics Engineers (IEEE) Standard for Software Maintenance (IEEE, 1998) defines
software maintenance as the “modification of a software product after delivery to correct
faults, to improve performance or other attributes, or to adapt the product to a modified
environment”, ERP maintenance is known to also cover activities necessary to keep the
software system current and up to the vendor’s requirements, and to realize benefits. Some
interesting research questions are as follows. Would an explicit classification of ERP
maintenance requests based on business benefit perspective be important? Does this
difference warrant a new classification for ERP maintenance requests? Two software
maintenance taxonomies (Chapin et al., 2001; Swanson, 1976) are available in the in-house
software literature. But, there is very little investigation of ERP maintenance taxonomy. Prior
studies related to ERP maintenance requests involved comparing the percentage of ERP
enhancement maintenance with the in-house software, and the type of modifications done to
the ERP (Glass, 1998; Glass et al., 1999). A more recent study was conducted by Nah et al.
(2001). They classified ERP maintenance activities based on the maintenance tasks. However,
the study did not examine in great detail whether (these two) existing in-house software
maintenance taxonomies are sufficient.
Research questions –:
• What is ERP maintenance?
o What activities comprise ERP maintenance?
o How can ERP maintenance activities be usefully classified?
What are useful dimensions for classifying ERP maintenance activities?
Are the existing maintenance classifications appropriate?
Contributions – A definition of ERP maintenance; an ERP maintenance taxonomy; and
business benefit perspective (technique) in classifying ERP maintenance requests – to
facilitate benefit-realization and minimization of user opportunity costs.
1-11
Significance – Identifying the dimensions and ways to classify maintenance activities is as
important in the ERP environment as in the in-house software context. It is useful to make
distinctions among the types of maintenance activities so that frequency and effort
distributions for each maintenance category are identifiable (for in-house software, see (Abran
et al., 1991; Lientz et al., 1980)). This will allow an organization to prioritize each
maintenance request based on its urgency, criticality or business benefit; and to visualize the
type of maintenance that consumes the most Information System (IS) resources. Besides, it
will also provide a foundation for any further studies on ERP maintenance activities. This will
include further investigation into the cause(s) and the reasons underpinning each type of
maintenance request, classification of determinants of maintenance profiles (see (Kemerer et
al., 1997) study on the in-house software), and identification of the measures that can be taken
in order to reduce maintenance requests.
1.7 ERP Maintenance Effort Model (Effort Sub-study) Motivation – Maintenance effort determinants are the crux of maintenance effort estimation,
an important element in making maintenance decisions, and assisting in planning for staffing
requirements at the maintenance preparation stage. However, in the context of ERP, little is
known about the factors influencing ERP maintenance effort. While some researchers have
conducted surveys, field studies and empirical tests to determine the maintenance effort
drivers in traditional in-house software (see (Banker et al., 1998; Lientz et al., 1980)), others
have measured possible cost drivers in order to find the effort driver (see (Banker et al., 1993;
Niessink et al., 1998)). (The heuristic rule in their studies is, increased effort will be reflected
in terms of cost.) Management that is better-informed of maintenance effort drivers could
better plan, decide, and allocate maintenance resources. Thus, they could have a better
understanding of the costs attached to each maintenance category. Ultimately, besides other
factors, they could decide whether to implement, delay or do nothing in response to a request.
This sub-study focuses on the characteristics of maintenance projects that affect ERP
maintenance effort. While maintenance project characteristics such as maintenance category
(Abran et al., 1993; Jørgensen, 1995; Lientz et al., 1980; Niessink et al., 1998), task
complexity/size (Jørgensen, 1995) and maintenance option or the type of changes done to
software (Jørgensen, 1995; Niessink et al., 1998) have been examined in prior studies, they
1-12
have been studied under a different context – that of traditional in-house software. Are these
factors applicable in the context of ERP? The characteristic of ERP maintenance projects such
as tailoring option (that describes how changes are done) is worth research endeavor, in order
to identify whether this factor is affecting ERP maintenance effort.
Research questions –:
• What attributes of maintenance effort are captured by an ERP-using organization?
o Which of these attributes are useful predictors of maintenance effort?
o How can maintenance effort be measured?
Contributions – An ERP maintenance effort model; and the maintenance effort model could
be used as a tool to estimate maintenance effort – to improve efficiency in planning and
making maintenance decisions.
Significance – In estimating the amount of effort required to complete a maintenance project,
a maintenance manager needs to have knowledge of the variables/factors that can be used to
conduct this estimation. Maintenance effort determinants allow projection of maintenance
resource (i.e. effort) requirements, and making maintenance decisions. Thus, effort
determinants are important because resources (time, manpower and money) can be estimated,
planned, prepared and allocated accordingly. Besides this, this knowledge is important to
conduct future study in maintenance productivity, see (Banker et al., 1987; Banker et al.,
1994).
1.8 ERP Maintenance and Upgrade Decision Framework (Decision Sub-study)
Motivation – One of the most important activities, and the main aspect of management, in
ERP maintenance and upgrade, is to make a better-informed decision on whether to
implement a maintenance request and when to do an upgrade. In order to guarantee a better-
informed ERP maintenance and upgrade decision, the salient characteristics of the ERP
maintenance and upgrade environment, such as factors affecting ERP maintenance and
upgrade effort and costs, need to be identified.
1-13
The more is known about the characteristics affecting ERP maintenance and upgrade, the
better one should be able to understand and estimate, and ultimately control, the maintenance
and upgrade costs, and allows early benefits-realizations from the system. Although there are
a couple of in-house software replacement models (see (Chan et al., 1996; Gode et al., 1990;
Gupta et al., 1988)) prescribing an optimal timing for software replacement, little
investigation of ERP is conducted in this area.4 The meager trade reports on ERP upgrade
policies (400-Group, 1998a; 400-Group, 1998b; Collins, 1999; Marion, 1999) provide mostly
anecdotal evidence of practitioners’ experiences, pitfalls to avoid, and factors to consider prior
to upgrading.
Research questions –:
• What are the factors that should be considered in making ERP maintenance and
upgrade decisions?
o What are the major factors influencing ERP patch-maintenance costs?
o What are the major factors influencing ERP upgrade costs?
o What are the opportunity costs for not doing ERP maintenance and upgrade?
o Are these factors that should be considered in an ERP upgrade decision (i.e.
replacing an existing version with a newer version from the vendor) differed
from those captured in the existing in-house software replacement models?
o How could these factors be included into software maintenance and upgrade
cost functions?
Contributions – An ERP maintenance and upgrade (MU) decision framework; and the
decision framework could be utilized as a tool to assist in making and quantifying ERP
maintenance and upgrade decisions – (with the objective) to minimize ERP software lifecycle
costs.
Significance – It is critical to note that the decision to maintain a change-request (depending
on its impact on the vendor’s code) or to upgrade an ERP software is not a trivial one.
Maintaining enhancement (or modification) requests that involve making changes to the
vendor’s code, integrating third-party software or adding custom functionality will not only
cost time and a lot of effort, but also could complicate future maintenance (for example,
4 The author is not equating ERP upgrade with in-house software replacement/rewrite but to investigate whether the factors considered in existing replacement models are useful and relevant in the context of ERP. It is noted that replacement is an important issue to ERP vendors
1-14
patch-maintenance and future upgrades). In contrast, if a maintenance request is not satisfied,
user opportunity costs could be very high to the ERP-using organization. Unlike upgrading of
small and stand-alone packages, such as word-processing or spreadsheet software, purchasing
and implementing ERP upgrades is a costly and lengthy endeavor (Stein, 1999). In fact,
because of the cost and time involved, many organizations may decide not to upgrade at all or
to upgrade only after a long period of time, in which they could have missed a lot of user
opportunities. However, even if an organization decides to upgrade its ERP system sometime
in the future, it is still faced with the decision-problems - when is the right time to upgrade?
On one hand, if the organization upgrades too early, it will miss some of the state-of-the-art
designs or new functionality introduced in newer versions for packaged software in general
(Davis, 1988). On the other hand, if the organization upgrades its ERP too late, it has to incur
higher user opportunity costs and allocate a larger budget provision for maintenance of the
existing system (Swanson et al., 1989). To assist ERP-using organizations in making these
decisions – in order to alleviate this burden (i.e. ERP maintenance and upgrade decision) and
minimize the total ERP system lifecycle costs – a decision framework is needed.
1.9 ERP Maintenance Methodology (Methodology Sub-study)
Motivation – Several standards or reference models (or methodologies) for software
maintenance developed by standardization bodies—describing the activities and the sequence
of activities for planning, managing and implementing maintenance requests and software
replacement are available in the literature. Examples include ISO 12207: Information
Technology – Software Life Cycle Processes (ISO/IEC, 1995), and IEEE/EIA 12207.2-1997
Guide for Information Technology – Software life cycle processes – Implementation
Considerations (IEEE/EIA, 1997). The reported benefits of a maintenance methodology,
besides codifying best practices, increase productivity, improved human communication and
increase the understanding of software process (Brotbeck et al. 1999; Heineman et al., 1994;
Ferguson et al., 1998), is assumed to be analogous to the implementation methodology, such
as Accelerated SAP (introduced by SAP, (Brand, 1999)), and FastForward (by Oracle,
(Niccolai, 2000)) – that is, to implement the relevant activities in a relatively shorter time and
for a lower cost. While existing standard software maintenance methodology is most suited
and upgrade is to ERP clients. However, vendors’ replacement issues are not the focus in this thesis.
1-15
for in-house developed software, there is no standard specifically meant for packaged
software – like ERP. Is it necessary to propose a new maintenance methodology for ERP in
order to describe ERP maintenance and upgrade activities?
Research questions –:
• What activities and tasks should be incorporated and reflected in an ERP maintenance
methodology?
o What are the activities associated with an ERP maintenance methodology?
o Is the existing standard for software maintenance methodology appropriate in
the context of ERP?
o What are the activities and tasks that are unique to ERP maintenance
environment?
Contributions – An ERP maintenance methodology; and the ERP maintenance methodology
could be used as a methodology to initiate, plan, organize, manage, execute, monitor, and
close ERP maintenance and upgrade projects – (in order) to provide effective and efficient
maintenance management.
Significance – According to Pigoski (1997), a maintenance model or methodology helps to
define the activities of the maintenance, improve maintenance processes, facilitate the process
of modifying the software, and reduce the effort and cost of maintenance (page 40). A
standard maintenance methodology is a useful method for managing software change
(Schneidewind, 1989). It provides the guiding principles, strategies and framework for
practitioners to plan and conduct maintenance procedures and manage software replacement
in a systematic manner, by adapting the methodology to their organizations’ requirements and
environment. It is believed that ERP-using organizations could also benefit from such
maintenance methodology, provided the standard is sufficient in the context of ERP.
Maintenance methodology could improve the effectiveness and efficiencies in ERP
maintenance management because it can help reducing effort and cost incurred in planning,
organizing and managing these activities.
1-16
1.10 ERP Maintenance-data-model (Data Sub-study) Motivation – An important issue besides the maintenance methodology is the maintenance
database or maintenance-data-model for capturing the fundamental maintenance request’s
attributes or details of activities in maintenance. A maintenance-data-model is useful for
making assessment and prediction on process (Fenton, 1991; Fenton et al., 1997), more
precisely the maintenance process in this case. The existing literature provides a maintenance-
data-model, called Software Quality Measurement: A Framework for Counting Problems and
Defects (Florac, 1992). The data-model is proposed by the Software Engineering Institute
(SEI), a federally funded research and development center operated by Carnegie Melon
University sponsored by the U.S. Department of Defense. SEI is recognized by software
professionals from the industry, academia, and government, who have participated in its
development. It has also been used in prior study. For example, Kajko-Mattsson (1998)
validated the SEI data-model using three European industrial maintenance systems. The
proposed maintenance-data-model emphasizes capturing measurable maintenance request’s
attributes at the maintenance procedure stage only. (Some examples of the common
measurable attributes of a change-request include: request-type, timing, software components
affected, impacts on other software properties, and staff involved.) Nonetheless, there has
been little research on maintenance-data-model in the context of ERP. Would the SEI
maintenance-data-model suffice, such that it can be readily applied to the ERP context?
Research questions –:
• What are the important ERP maintenance request’s attributes that should be captured
in an ERP maintenance management environment?
o Do the attributes captured in in-house software environment sufficient in the
context of ERP?
o What are the unique ERP maintenance request’s attributes?
Contributions – An ERP maintenance-data-model, which provides a repository of
maintenance activities – to allow for retaining maintenance knowledge in an organization,
tracking maintenance project, monitoring maintenance performance, productivity and
problems, and making prediction or forecasting.
1-17
Significance – In order to extend the usefulness and benefit of a maintenance methodology,
other researchers perceive a well-defined and well-designed maintenance-data-model as
important (Florac, 1992; Kajko-Mattsson, 1998) to define the maintenance request’s attributes
to be captured during the maintenance activities. Florac (1992) suggests that a well-defined
maintenance-data-model integrates and gives structure to the discovery, reporting, and
measurement of software problems; facilitates estimation, planning, and tracking of various
software processes; and provides consistent data measurements (for quantitatively expressing
requirements, goals and acceptance criteria, monitoring progress and anticipating problems,
quantifying tradeoffs used in allocating resources, and predicting the software attributes for
schedule, cost, and quality). Some examples from the real world that use measurement
program to improve product quality are as follows. (Note that these measurement programs
may be exactly the same as the SEI, but the emphasis here is the usefulness of software
measurement in practice.) Smith (1993) reports that, by expressing the quality goal (i.e. total
customer satisfaction) in a well-defined and measurable way (such as number of defects per
unit of finished product, ratio) and followed by monitoring, controlling and evaluating the
production performance, Motorola has improved its product quality; and therefore the total
customer satisfaction. Fenton and Pfleeger (1997) describe that AT&T improves its product
quality by continuously measuring, monitoring and improving the process performance until
the desire organizational goals for the process are achieved. Other benefits of software
measurement are improvement to software maintenance process experienced by Burrough
Corporation (Rombach et al., 1989), supporting a detailed assessment of problem areas and
addressing risks and problems earlier (Clark, 2002), making better decisions (Rus et al.,
2002), effort estimation, and facilitating uncertainty and causal modeling (Fenton et al., 2002).
An interesting question is: Should the existing maintenance-data-model be suitable in the
context of ERP so that ERP-using organizations can also obtain the mentioned benefits.
The interconnectivity of the five sub-studies, as well as the research objectives and research
questions are shown in Figure 1.1. The inputs into each sub-study are illustrated in Table 1.1.
1-18
ERPM aintenanceTaxonom y
ERPM aintenance
EffortDeterm inant
Investigate activitiesinvolved in m aintenance
preparation, m aintenanceprocedure and software
upgrade
Identifydim ensions for
classifyingm aintenance
request
ERPM aintenanceand Upgrade
(M U) DecisionFram ework
Exam ine factorsaffecting
m aintenanceeffort
Sub-study:
Prim aryResearch
Objective:
ResearchQuestion:
W hat is ERP m aintenance?W hat activities com priseERP m aintenance?How can ERP m aintenanceactivities be usefu llyclassified?W hat are usefu l dim ensionsfor classifying ERPm aintenance activities?Are the existingm aintenance classificationsappropriate?
W hat activities and tasksshould be incorporated andreflected into an ERPm aintenance m ethodology?W hat are the activitiesassociated w ith an ERPm aintenance m ethodology?Is the existing standard forsoftware m aintenancem ethodology appropriate inthe context of ERP?W hat are the activities andtasks that are unique toERP m aintenanceenvironm ent?
W hat are the factors that shouldbe considered in m aking ERPm aintenance and upgradedecisions?W hat are the m ajor factorsinfluencing ERP patch-m aintenance and upgrade costs?W hat are the opportunity costs fornot doing ERP m aintenance andupgrade?Are these factors that should beconsidered in an ERP upgradedecision d iffered from thosecaptured in the existing in-housesoftware replacem ent m odels?How could these factors beincluded into cost functions?
ERPM aintenance-data-m odel
ERPM aintenance
M ethodology
Determ ine thefundam entalm easurable
m aintenancerequest’s attributes
Determ ine factorsdriving m aintenance
and upgradedecisions
is required toidentify which
activ ity issupposed tocollect what
data
is required tohave an
appreciation ofthe type of
m aintenanceactiv ities
is used tohave an
appreciationof factorsaffecting
m aintenanceeffort
W hat attributes ofm aintenance effort arecaptured by the casefirm ?W hich of theseattributes are usefulpredictors ofm aintenance effort?How can m aintenanceeffort be m easured?
W hat are the im portantERP m aintenancerequest’s attributes thatshould be captured inan ERP environm ent?Do the attributescaptured in in-housesoftware environm entsufficient in the contextof ERP?W hat are the uniqueERP m aintenancerequest’s attributes?
is required tom ake betterquality M Udecisions
is required to plan for m aintenance resources and staffing
is required to identify the types of m aintenance request
is required for m aintenance classification
is required to assign a request type to a m aintenance requestDeterm ine the data required forrequest classification purpose
Figure 1.1: Interconnectivity, research ideas, primary research objectives, and research questions for the five sub-studies
1-19
1.11 Research Strategy
In order to address the research questions, five embedded sub-studies within an over-arching
case study were conducted at a large government agency (the Corporate Service Agency –
CSA within the Queensland Government) in Australia. CSA is a corporate information
systems provider (including ERP system) to other government departments, and it also uses
the ERP system itself. It is analogous to an ERP maintenance department in a large
organization with many user departments (i.e. itself, and other government departments). As
indicated in earlier sections, the five sub-studies are: taxonomy sub-study, effort sub-study,
decision sub-study, methodology sub-study, and data sub-study.
Case study research method is used in this relatively new and under-studied research field.
According to Yin (1994), the strengths of a case study methodology in these circumstances
include the ability to collect multiple sources of data for data triangulation, and allowing the
researcher to explore an event in which s/he has no control over behavioral considerations.
However, it is noted that there are also some criticisms of the case study method; it is
perceived as lacking in rigor and as providing little basis for scientific generalization (Yin,
1994). This study attempts to overcome the biased views influencing the directions of the
findings and conclusions by documenting procedures involved in the case study, using
multiple sources of evidence, and using pattern-matching technique in analyzing data, see
(Yin, 1994). The findings generalizations are made by stating clearly the assumptions and
context under which the (analytical) generalizations are applicable. The case study strategy
adopted in this study uses a combination of qualitative data and quantitative data. The inputs
and main deliverable from each sub-study are shown in Table 1.1. The main focus in each
chapter (with the respective sub-study) is illustrated in Table 1.2.
1-20
Table 1.1: Primary data type, data analysis method, inputs and main deliverable in each sub-study
1 2 3 4 5
Sub-study Taxonomy Effort Decision Methodology Data
Chapter 4 5 6 7 8
Primary data type Qualitative Quantitative Quantitative Qualitative Qualitative
Data analysis
method
Pattern matching,
Descriptive statistics,
Comparing the data
with the in-house
software
Pattern matching,
Descriptive statistics,
Regression analysis
Pattern matching,
Descriptive statistics,
Comparing the data with
the in-house software,
Mathematical modeling
Pattern matching,
Comparing the data with
the in-house software
Pattern matching,
Comparing the data with
the in-house software
Study Inputs Others CSA maintenance
request type (chapter
4) + others
CSA maintenance
request type (chapter 4) +
ERP maintenance effort
determinants (chapter 5)
+ others
ERP maintenance
taxonomy (chapter 4) +
ERP maintenance effort
determinants (chapter 5) +
ERP MU decision
framework (chapter 6) +
others
ERP maintenance
activities at the
maintenance procedure
stage (chapter 7) + others
Main Deliverable Maintenance Taxonomy
Maintenance Effort Model
Maintenance and Upgrade Decision Framework
Maintenance Methodology
Maintenance-Data-Model
Research strategy Case study
1-21
Table 1.2: Main focus in each chapter
Chapter in the thesis Focus 4 – Taxonomy sub-study Maintenance, upgrade
5 – Effort sub-study Maintenance
6 – Decision sub-study Maintenance, upgrade
7 – Methodology sub-study Maintenance, upgrade 8 – Data sub-study Maintenance
The high-level case study protocol carried out in this research is as follows:
(1) The objectives of each sub-study are determined.
(2) The anticipated data are determined based on the objectives of each sub-study.
(3) Multiple sources of evidence are gathered.
(4) Chain of evidence pointing to the same inquiries is consolidated in each sub-study.
(5) Case description is used in synthesizing the descriptions, explanations and interpretations
of the case firm’s maintenance environment and activities; and for quantitative data, basic
descriptive statistics and/or regression analysis are conducted.
(6) The synthesized information and knowledge about the case firm’s maintenance
environment (i.e. maintenance taxonomy, maintenance effort, maintenance and upgrade
decision, maintenance methodology, and data-model) is analyzed and compared with the
findings in the prior studies and trade literature (whenever available and applicable),
using pattern-matching technique.
(7) If the existing literature is found to be insufficient, an improved maintenance taxonomy,
effort model, maintenance and upgrade decision framework, maintenance methodology,
or maintenance-data-model is developed based on what has been learnt from the (ERP)
case firm, and the prior literature on in-house software; and/or recommendations that are
supported by other relevant literature in similar contexts.
The research design for this study is illustrated in Figure 1.2, and is adapted from Gable
(1994). Of note is that these sub-studies are inter-related such that output from one sub-study
contributes to the subsequent sub-studies. The outcomes or findings of maintenance
taxonomy, effort determinants and decision framework sub-studies are incorporated in the
maintenance methodology to provide a means to improve the overall effectiveness and
efficiency in ERP maintenance management. On the other hand, the ERP maintenance
methodology is used to facilitate the subsequent identification of pertinent maintenance
1-22
request’s attributes to be captured in the maintenance-data-model. A comprehensive ERP
maintenance-data-model in turn is useful for facilitating request categorization, cost and
benefit justifications for maintenance requests, charging user-departments for their
maintenance requests, making better-informed maintenance and upgrade decisions, and
forecasting future maintenance demand based on the historical maintenance data.
1-23
5.Develop an
Empirical Modelfor ERP
MaintenanceEffort
4.Propose an ERP
MaintenanceTaxonomy
7.Develop an ERP
MaintenanceMethodology
ERP maint.category
ERPmaintenanceeffort model
ERPMaintenanceTaxonomy
(published inICSM 2001,JSS 2002)
ERP-Maintenance
Model(published inHICSS 2003,PACIS 2003)8.
Develop an ERPMaintenance-data-model
interview, change-req. db
interview, change-req. db, patch -support db, mod. db, documentation
Main contributions (oroutputs) from the study :
Data found from:- existing literature,- the case firm
ERPmaintenance-data-model
(published inACIS 2001)
1.Define Research
Questions
2.Review Literature
Researchproblem
Researchcontext andquestions
interviews,change-req. db,user-support db,patch-support db,
mod. db,documentation,
maint. req. forms
ERP:maintenance
activities,enhancement
optionsIn-house sw
maintenance:taxonomy,
effortdeterminant,replacement
model,methodology,SEI maint.-data-model
ERP maint.case protocol
interview, change-req. db, documentation
interview, maint. req. forms, change-req. db
IEEE/EIA 12207.2-1997
SEI maintenance-data-model
ERP upgrade cost drivers and elements
A decisionframework
for ERP MU(published inAMCIS 2001,JSME 2001)
in-house maint. taxonomies
interview,change-req.
db, user-support db
9.Summary,
Implications, andFuture Research
Implications toresearchers andpractitioner, andfuture research
directions
3.Develop Case
Protocol &Conduct Case
Study
ERP maint.activities(at maint.procedure
stage)
6.Construct ERP
Maintenance andUpgrade Decision
Framework
Figure 1.2: Research design
1-24
1.12 Thesis Structure
Having defined the research context and questions, a detailed literature review on ERP
maintenance and upgrade is conducted in Chapter 2. This includes ERP enhancement
maintenance activities, identifying the types of patch-maintenance (from the ERP vendor),
and procedures or activities involved in ERP maintenance and upgrade. Due to a lack of
existing theories and studies in ERP maintenance and upgrade (as observed in the ERP
literature), the literature on in-house software maintenance and replacement model is
consulted. The objectives of this literature review are to identify: (1) what has been done in
the five main areas of in-house software maintenance: maintenance taxonomy, determinants
of maintenance effort, and replacement models, maintenance methodology and maintenance-
data-model; and (2) explore whether prior studies are applicable to the ERP environment.
With a better understanding of the research context and research questions (Chapter 1) and
background of what has been done in prior research (Chapter 2), Chapter 3 elaborates on the
research method, including data collection and data analysis techniques used in each sub-
study.
Chapter 4 presents the sub-study on ERP maintenance taxonomy. Detailed investigations are
focused on analyzing the case firm’s existing ERP maintenance request classification, and
characteristics of each maintenance category. The results of this investigation are then
compared with the existing in-house software maintenance classifications. In light of the
insufficiencies in existing classifications, an ERP maintenance taxonomy is proposed.
Chapter 5 describes the sub-study on ERP maintenance effort determinants. Empirical data
analysis is conducted on change-request projects data to identify the characteristics
influencing ERP maintenance effort. An empirical model for ERP maintenance effort is
developed.
Chapter 6 presents the sub-study on an ERP maintenance and upgrade decision framework. It
identifies the factors driving ERP maintenance and upgrade decisions. The cost elements of
ERP upgrades are determined and the knowledge of ERP maintenance effort drivers (detailed
in Chapter 5) is considered in formulating the maintenance cost factor for different types of
1-25
ERP maintenance requests (explained in Chapter 4). A decision framework for prescribing
ERP maintenance and upgrade decisions is proposed.
Chapter 7 describes the sub-study on ERP maintenance methodology – the activities and
tasks involved in ERP maintenance and upgrade processes. This is then compared with the
existing standard software maintenance methodology. An ERP maintenance methodology is
proposed.
Chapter 8 presents the sub-study on ERP maintenance-data-model. Findings from the case
study are linked and evaluated against the Software Engineering Institute (SEI) maintenance-
data-model to determine whether the SEI model is adequate in the context of ERP. The
strengths and weaknesses of the case’s existing maintenance-data-model are identified. An
ERP maintenance-data-model is proposed for activities involved in maintenance procedures –
a stage proposed in the ERP maintenance methodology in Chapter 7.
Chapter 9 provides a summary of the project, revisits the findings and contributions of the
research project, and discusses the implications of the results from the researcher’s
perspective and the practitioner’s perspective. Discussions on future research directions are
also provided in considerable details.
The thesis chapters are depicted in Figure 1.3.
1-26
C h ap ter 6 :E R P M a in tenan ce and U pgrade D ec is ion F ram e w ork
C h ap ter 1 :In trodu c tion and S tu dy M o tiva tion s
C h ap ter 2 :L ite ra tu re R ev iew
C h ap ter 3 :R esearch M e th odo logy
C h ap ter 5 :E R P M a in tenan ce E ffo rt M o de l
C h ap ter 4 :E R P M a in tena nce T axonom y
C h ap ter 8 :E R P M a in tenan ce -da ta -m ode l
C h ap ter 7 :E R P M a in tenan ce M e tho do logy
C h ap te r 9 :S um m ary , Im p lica tio ns and F u tu re R esea rch
Figure 1.3: Thesis chapters diagram
1-27
1.13 Summary
In summary, this study is mainly focused on ERP packaged software, and in particular the
management of ERP MU maintenance and upgrade activities of ERP-using organizations. It
contributes to project named Cooperative ERP Lifecycle Knowledge Management. The high-
level motivations for this study are that: (1) there is a large installed base of ERP and the topic
of ERP maintenance and upgrade is receiving increased attention as many organizations are
facing this problem, and (2) costs associated with ongoing maintenance and upgrade activities
are not trivial in most ERP-using organization Information System (IS) budgets. This research
is an exploratory, descriptive, revelatory and collaborative case study. This study discovers
and describes the nature of ERP MU activities, and proposes appropriate mechanisms and
methodology for effective and efficient maintenance management in the context of ERP. It
seeks to generate both research outcomes and applied outcomes for the industry partners.
From the practice perspective, this study specifically aims to minimize ERP software lifecycle
costs (thus, total cost of ownership) and to facilitate benefit-realization from the ERP system.
These aims are achieved in this study by investigating and then proposing suitable ERP
maintenance taxonomy, maintenance effort model, MU decision framework, maintenance
methodology, and maintenance-data-model. The main research questions addressed in this
thesis are: What is ERP maintenance? What attributes of maintenance effort are captured by
an ERP-using organization? What are the factors that should be considered in making ERP
maintenance and upgrade decisions? What activities and tasks should be incorporated and
reflected in an ERP maintenance methodology? What are the important ERP maintenance
request’s attributes that should be captured in an ERP maintenance management
environment?
This study makes the following contributions:
(1) taxonomy sub-study – a definition of ERP maintenance; an ERP maintenance taxonomy;
and benefit-perspective (technique) in classifying ERP maintenance requests;
(2) effort sub-study – an ERP maintenance effort model; and the maintenance effort model
could be used as a tool to estimate maintenance effort;
(3) decision sub-study – an ERP maintenance and upgrade (MU) decision framework; and the
decision framework could be utilized as a tool to assist in making and quantifying ERP
maintenance and upgrade decisions;
1-28
(4) methodology sub-study – an ERP maintenance methodology; and the ERP maintenance
methodology could be used as a methodology to initiate, plan, organize, manage, execute,
monitor, and close ERP maintenance and upgrade projects; and
(5) data sub-study – an ERP maintenance-data-model, which provides a repository of
maintenance request’s attributes.
The proposed five tools and techniques are important and significant because they are
believed to facilitate effective and efficient management of ERP MU activities. In order to
facilitate maintenance requests prioritization and management, ERP maintenance managers
must usefully classify maintenance requests. To plan for efficient maintenance, managers
must have an appreciation of the key drivers of ERP maintenance effort. In order to make
better-quality maintenance and upgrade decisions, ERP maintenance managers require a
decision tool or framework capturing the fundamental characteristics and decision factors, and
the respective cost functions. In initiating, planning, organizing, managing, executing,
monitoring, and closing maintenance and upgrade projects, a comprehensive maintenance
methodology is important. More broadly, in order to perform maintenance activities
increasingly efficiently and effectively, and to facilitate benefit-realization from ERP system,
appropriate information and knowledge about maintenance and upgrade activities must be
retained.
In conducting this study, case study research method is used. The case study encompasses
five embedded sub-studies: taxonomy sub-study, effort sub-study, decision sub-study,
methodology sub-study, and data sub-study. These five sub-studies are embedded within an
over-arching case study conducted at a large Government Agency, Corporate Services
Agency (CSA), in Australia. The structure of the thesis is shown in Figure 1.3.
2-1
2 Literature Review
Having defined the research context and questions in Chapter 1, the literature review is
conducted in this chapter. The objectives in this chapter are: (1) to determine if ERP software
(in general, maintenance and upgrade in particular) is different from in-house software (in
general, maintenance and replacement1 in particular), and (2) to identify the gaps in the
literatures. This chapter is constructed as follows. Section 2.1 describes the fundamental ERP
maintenance activities – enhancement and patch maintenance. Section 2.2 discusses ERP
upgrade – the upgrade decision, plan and cost drivers. Section 2.3 describes some examples of
the ERP benefit-realization from the system and its business value to ERP clients. Section 2.4
recaps the discussions in the previous three sections and highlights what is known and
unknown about ERP maintenance. In light of the lack of ERP maintenance literature in the
five research areas investigated in this thesis, Section 2.5 reviews the related in-house
software literature. Section 2.6 summarizes the review of the in-house software literature.
Section 2.7 presents the distinctions between ERP and in-house software. The deficiencies in
existing in-house software literature in the context of ERP are discussed in Section 2.8, and
finally, Section 2.9 summarizes the gaps in the literature.
2.1 ERP Maintenance
What is ERP maintenance? – The existing ERP literature does not provide a definition for
ERP maintenance. In an ERP environment, maintenance requests include those initiated both
by the ERP client, and by the vendor. The former are mostly enhancement requests. The latter
comprise support packages or patches and upgrade versions, which are distributed by the
vendor but implemented by the ERP client on its ERP system. A support package or patch
contains corrections and further adjustments resulting from legal changes, and corrections for
errors in the repository or data dictionary in an already installed version. A new version for
functional upgrade purposes contains substantial enhancements and new functionality.
Although in reality the clients’ ERP maintenance also includes corrective, and user-support,
1 The author is not equating ERP upgrade with in-house software replacement/rewrite but to investigate whether the factors considered in existing replacement models are useful and relevant in the context of ERP. It is noted that replacement is an important issue to ERP vendors and upgrade is to ERP clients. However, vendors’ replacement issues are not the focus in this thesis.
2-2
to the knowledge of the author very little is known or has been written about them. As a
result, no further discussion of these two categories is undertaken in this literature review.
2.1.1 Client-Initiated Maintenance: Enhancement
A survey conducted by Glass and Vessey (Glass et al., 1999) on ERP maintenance has
indicated that most maintenance requests introduced within an ERP-using organization are
enhancement-driven. Enhancement is needed to change existing functionality in order to
operate in a way that is desired and/or better than the original ‘vanilla’ software could offer.
According to SAP (1998b) and consultant (Kessler, 1999), there are five fundamental choices
for making tailoring to the SAP2 standard. These are: customization; enhancement using
customer exits; enhancement using business add-ins; assisted modification; and modifications
to the SAP standard.
Customizations or configuration are activities that involve changes done within the standard
vendor code, usually by setting system parameters via SAP’s configuration tables. In SAP
R/3, the configurable elements that can be accessed through the implementation guide (IMG)
are central functions, organizational elements, control elements, data validation, and system
control (Bancroft et al., 1998). These are defined as follows:
a. The configuration of the central functions basically relates to the operating
environment of a company, for example, the currency, country, rounding rules,
calendar year and unit of measure.
b. Organizational elements are associated with the organization (or structure) of a
company and include, for example (in SAP parlance), company code, controlling area,
functional area, plants, sales organization, and so forth.
c. The control elements3 are the programs and configuration tables used to configure
documents or operations.
2 SAP software is the main focus in this thesis because: (1) the case firm in this study uses SAP software, (2) SAP is a top-tier ERP software, and (3) majority of research done so far are based on SAP software. Thus, this can facilitate the author in making references, associations and comparisons with existing studies or knowledge relevant to this thesis. 3 According to Bancroft et al. (1998), these are the most challenging part of configuring the SAP R/3. Bancroft provides an illustration of this complexity, in the sales and distribution area (version R/3 3.0): There are 40 different sales documents types. Each document can have line item categories, and each line item category must be chosen from among 70 line item categories. On the other hand, each line item category can have schedule line categories. There are 40 schedule line categories with R/3 (pp. 91).
2-3
d. The data validation table is a simple configuration table for maintaining text
information that appears as straight output only.
e. System control is an element for configuring the Basis System of R/3. This may
include, for instance, the ABAP/4 development environment, user authorizations,
printer setup, and so forth (page 85-93).
In general, enhancements done under the customization or configuration category have no
major impact on subsequent upgrade efforts and will not be modified by new version
upgrades.
Customer exits are predefined exit points from the SAP source code that allow ERP client
organizations to insert their custom code and locally enhance the standard software without
having to dive into SAP application logic. They are bound by two-system infrastructure, i.e.
SAP and the ERP client organization (Kessler, 1999). Enhancement using customer exits
involves enhancements related to programs, menus and screens.
Unlike the restrictions imposed by customer exits, business add-ins (also predefined exit
points) not only allow ERP client organizations to add their custom code or use one of the
standard supplemental solutions provided by SAP, but also permit third-party software
development to be incorporated in the standard code (Kessler, 1999). Business add-ins are
designed to accommodate the specific user requirements of attaching additional software to
the standard SAP code.
Assisted modification is modification done using the modification assistant – a tool provided
by SAP primarily to assist its client-organizations in performing these tasks. According to
Kessler (1999), the modification assistant works behind the scenes to register all
modifications made to objects in the standard system in the ABAP workbench. Kessler
reports that changes made using a modification assistant could be re-imported automatically
during a release upgrade. It is integrated into the ABAP workbench tools, which facilitates
client-organizations to append and delete the source code; change the screen layout; modify
the flow logic; insert, replace and delete menu entries; add a customer function module to an
SAP function group; add new parameters to a function module; and add new text and modify
existing text.
2-4
Modification refers to making changes or directly modifying the SAP standard objects. This
type of tailoring option has a major impact on the effort required to implement future
upgrades and vendor support (Thompson, 2001b). Upgrading usually entails the re-
application of any previous modification unless those modifications are also incorporated in
the new version. A summary of the SAP enhancement option is given in Table 2.1.
Table 2.1: SAP categorization of software tailoring
Tailoring option Description* 1. Customization Involves changes done within the standard vendor code by setting
system parameters via SAP’s configuration tables.
2. Enhancement using
customer exits
Is for requirements that are not included in the standard SAP.
Customer exits are incorporated in the standard as empty
modification ‘shells’. Customers fill the ‘shell’ with their own coding.
Upward compatibility is assured.
3. Enhancements using
business add-ins
Accommodates specific user requirements to attach additional
software (including third-party software products) to the standard
SAP code.
4. Assisted
modifications
Create customer-specific objects within the customer name range,
for example, screen layout, and function key assignment.
5. Modifications to the
SAP standard
Involve modifying SAP standard objects.
*Source: SAP (1998) and Kessler (1999).
SAP tailoring categorization is technical-oriented and emphasizes how (or what tool to use) to
perform a tailoring task and how to achieve the objective of a request. A more detailed
analysis of the tailoring option is given in the academic literature, see Brehm et al. (2001).
Brehm et al. propose nine types of SAP tailoring options (see Table 2.2) and describe the
tailoring options from the technical perspective (including how they are done), as well as what
is changed/modified and the layers (i.e. interface, application and database) involved. This
categorization is obtained from an analysis of the implementation literature and the authors’
interviews with MIS directors (from SAP client-organizations). The primary objective of
Brehm et al.’s paper is to provide guidance to the complexity and amount of maintenance
effort required to implement the different types of tailoring options. Table 2.3 shows the
factors considered in these two categorizations of SAP tailoring options.
2-5
Table 2.2: Researchers categorization of SAP software tailoring
Tailoring option* Description* Maintenance effort required* 1. Configuration Setting of parameters (or tables), in order to choose between different
executions of processes and functions in the software package.
None / slight.
2. Bolt-on Implementation of a third-party package designed to work with ERP
system and provide industry-specific functionality.
Depending on coordination between
ERP and bolt-on vendor.
3. Screen masks Creating new screen masks for input and output of data. Slight / moderate.
4. Extended reporting Programming of extended data output and reporting options. Moderate / heavy.
5. Workflow programming Creating non-standard workflow. Moderate / heavy.
6. User exits Programming additional software codes in an open interface. Heavy.
7. ERP programming Programming additional applications without changing the original source
code (using the computer language of the vendor).
Heavy, if data from the ERP
application is used.
8. Interface development Programming interfaces to legacy systems or third party products. Heavy / very heavy.
9. Package code modification Changing the source-codes (ranging from small changes to changing
whole modules).
Very heavy.
*Source: Brehm et al. (2001) Table 2.3: Factors considered in SAP (1998) and Brehm et al. (2001) categorizations of tailoring options
Factors considered What tool (or how)? Impact on effort required What is involved or is to be changed? Which layer(s) are involved?
SAP X X — — Brehm et al. X X X X
2-6
Table 2.3 shows that there are similarities in the factors considered in both SAP and
researchers categorizations of tailoring options. The author believes that due to the additional
factors considered, Brehm et al.’s classification produces more detailed types of tailoring. By
comparing the description of each tailoring option from the SAP (1998b) and Brehm et al.
(2001), it is found that SAP’s definition of customization, customer exit and business add-in
corresponds to Brehm et al.’s classification of configuration, user exit and bolt-on
respectively. In addition, both SAP and Brehm et al. have a common understanding of the
term modification. However, it is found that Brehm et al.’s tailoring type of screen masks,
extended reporting, workflow programming, ERP programming and interface development
are most likely to come under SAP’s category of assisted modification. The matching
between them is illustrated in Table 2.4.
Table 2.4: Matching between researchers and SAP tailoring typologies
Brehm et al. (2001) tailoring type of Corresponds to SAP’s definition of Configuration Customization
User exits Enhancement using customer exits
Bolt-on Enhancement using business add-in
Screen masks, Extended reporting, Workflow
programming, ERP programming, Interface
development
Assisted modifications
Package code modification Modifications to the SAP standard
It is observed that there is currently no standard definition for ERP tailoring (or maintenance)
options among the researchers. For instance, in another version of maintenance options given
by Glass and Vessey (1999) the SAP term – i.e. customization is used to refer to the
configuration activities – for changes made to ERP functionality via internal configuration
switches. On the other hand, “extension” in (Glass et al., 1999) is used to describe changes
associated with user exits, bolt-ons and custom code add-ons.
For consistency with the existing literature, this study uses the terminology proposed by
Brehm et al. (2001). For example, configuration is used to define changes done through
standard configuration tables or switches provided by the vendor. However, a new term,
“modification-enhancement” is used in this study to refer to any of the tailoring options (2) to
(9) listed in Table 2.2. Their categorization is referenced in Chapter 5 (effort sub-study) and
Chapter 6 (decision sub-study).
2-7
The best approach to tailoring an ERP system is minimizing any changes to the standard
vendor code. This is because modifying or changing the standard code requires in-depth and
comprehensive understanding of the logic of the application. Modifications to the SAP
standard or changes that are far away from the standard involve higher maintenance
requirements (application logic, programming knowledge, testing and integration effort) and
higher costs. Moreover, they will complicate an upgrade effort. This is because they (the
modifications) would be wiped out when a new version is installed. Re-applications of the
previous modifications or changes may be required. A new version upgrade implies that the
logic of the new version has to be revised first before re-application of previous modifications
can be implemented. Hence, whenever changes cannot be implemented within the standard
procedures provided by the vendor, the option of writing code external to SAP programs is
preferable to writing code within SAP programs. The amount of modification needed is
dependent on the degree of fit between the ERP system and the organization’s existing (or
desired) business processes, and the willingness of the organization to adapt its way of doing
business to the package (Brehm et al., 2001).
It is of note that the tailoring options reviewed here are not limited only to enhancement
requests (they are non request-type specific) but encompass other types of requests such as
corrective or adaptive changes.
Maintenance implementation process – A maintenance request, regardless of enhancement,
corrective or adaptive, which is valid and approved, will be implemented. Changes made in
servicing a maintenance request (for example enhancement) are done in the development
system. Development system is an instance of an ERP system where it is an offline system
and changes made to it will have no impact on the real-time or production system. It is where
the resolutions or new developments for maintenance requests are first made. It doesn’t
necessarily have a recent copy of all the production data. Therefore, its data may not be up-to-
date or reflecting the current state of a business transaction. Once the change(s) have been
made and completed in the development system, a change-request in SAP system will be
created. (More details about this change-request will follow.) This will ensure that the details
of this request are documented. This (enhancement) is then delivered to the quality assurance
system for business process testing and verification. Quality assurance system is also an
instance of an ERP system and it is an offline system. The data in this system is periodically
2-8
copied from the production system to keep it up-to-date and it is relatively more recent than in
the development system. It is “almost” an instance of the production system, is used for
testing the correctness of the maintenance resolution and/or integrity of the new development,
and conducting user acceptance tests before the maintenance resolution is delivered to the
production system. Subsequently, it will be transported to the production system for
operation. (Production system is the most critical and an online version of the ERP system. It
is the system which users are using for day-to-day operations, conducting traditional business
processing and functions, and which stakeholders use for business transactions.) This is
supported by SAP through the Change and Transport System (CTS). CTS is SAP’s change
management system, and consists of the Change and Transport Organizers (CTO), the
Transport Management System4 (TMS) and the operating system transport tools5 – tp and
R3trans (McFarland, 1999).
CTO provides functions for the creation, documentation, and release for change-requests
generated during customizing and development projects. It comprises the Customizing
Organizer, Workbench Organizer, and Transport Organizer. While the Customizing Organizer
manages customizing change-requests that are client-specific6 only, Workbench Organizer
deals with the workbench requests that are client-independent such as the repository objects
maintained from ABAP workbench (McFarland, 1999). A change-request is created using the
CTO, as a customizing change-request or workbench change-request. The transport tools in
combination with TMS control the imports (or the exported R/3 changes) into R/3 systems.7
This knowledge of how enhancement requests (for instance) are implemented and transported
from one environment to another (for example, from a development system to a quality
assurance system and so forth) is important, as it is part of ERP maintenance methodology.
This is detailed in Chapter 7.
4 TMS organizes, monitors and performs imports for all R/3 systems within a system landscape. For instance, it is used to import change requests into the quality assurance system. 5 Operating system transport tools are executables used to communicate with the R/3 system, the database and files generated during the export and import process. 6 This refers to an instance of the SAP system. It could be the development, quality assurance, or production, for example. 7 The transport tool – tp automatically marks the requests for import into subsequent system and TMS automatically forwards the specified request to the target/delivery systems.
2-9
2.1.2 Patch-Maintenance
ERP-using organizations obtain maintenance support services through a maintenance contract
with an ERP vendor, for example SAP. The annual maintenance fee is usually between 12 and
20% of the initial software license fee (Butler, 2001). In providing efficient maintenance
support to its clients, SAP posts the patch support in the on-line system, or on a website
known as Online Support Systems (OSS) or Online Correction Support (OCS) (SAP, 1998c).
This system offers various patch types dedicated to fixing program bugs in particular areas.
Sometimes, patch also includes enhancements for the software system. Examples of the most
common patches are illustrated in Table 2.5.
Table 2.5: SAP patch types
Patch type* Description
SPAM update (PAT) Contains improvements and extensions of the SAP Patch Manager
(SPAM).
Hot Package (HOT) Is a collection of corrections for serious errors in the Repository.
Legal Change Patch (LCP) Contains corrections and further adjustments due to legal changes
for the SAP Human Resources (SAP HR) component.
Add-On Patch (AOP) Is valid for a single Add-On with a particular release.
Business Warehouse Patch
(BWP)
Contains a collection of corrections for the SAP Business Information
Warehouse (SAP BW) component.
General Component Patch
(COP)
Is valid for a single software component (SAP_BASIS, SAP_APO)
and contains corrections for serious errors in the Repository and
ABAP Dictionary for this component only.
Conflict Resolution
Transport (CRT)
Is used to resolve conflicts that may arise between a patch (Hot
Package or Legal Change Patch) and an Add-On.
FCS Final Delta Patch (FFD) Brings a First Customer Shipment (FCS) system to the final state
before Hot Packages (or Legal Change Patches) can be applied. For
example, in order to bring an R/3 system to its final state after the
upgrade process, it is necessary to apply an FCS Final Delta Patch
(FDP).
*For Version 4.5B and later.
Patch-maintenance implementation process – While some client organizations may apply
the critical patches as soon as they arrive, some would batch these patches, as recommended
by SAP, in order to save the repetitive individual activities. Several patches could be applied
2-10
in one queue and are placed in a patch queue. The patch queue will show the order of the
patches. The SAP Patch Manager (SPAM), the patch management tool, ensures that only the
appropriate patches for the system are displayed in the queue (SAP, 1998c). Patches that are
meant for another release or Add-On will not appear in the queue, even if they were loaded in
the R/3 System.
Anecdotal evidence suggests that the more modifications done to the system at
implementation time, the higher the billable hours or cost per patch-maintenance project (400-
Group, 1998b) will be. This is because implementing a patch-maintenance project will
overwrite some of the custom code and previous modifications or changes that vary from the
standard. Therefore, more effort is required to conduct impact analysis to verify the effects of
each patch (or support package) on each of the previous modifications (Collins, 1999). Re-
application and re-testing of (some of) the previous modifications are required if they have
been overwritten by an LCP. SAP provides two transactions called SPDD and SPAU to
facilitate the viewing and adjustments for client’s modification(s) after the patch or upgrade
process occur. More discussion on SPDD and SPAU is given in 2.2.4.
This knowledge of the patch-maintenance implementation process is crucial, as it constitutes a
component in an ERP maintenance methodology, required in Chapter 7.
Besides patches, ERP vendor also produces new and improved versions of the software for
replacing the older versions. The ERP upgrade topic is huge and is discussed separately in
Section 2.2. However, it is worth highlighting here the distinctions between patches and new
upgrade version. Some of the main differences observed are: (1) patch has a relatively smaller
impact on an installed ERP-code whereas a new version upgrade will overwrite an installed
version with a new one; (2) patches are introduced more frequently than new versions for
upgrade purposes; (3) while (most of the) patch is mandatory (in order to keep an installed
version up to date), a new upgrade version is an option as long as an installed version is still
supported by the vendor (or the client is willing to take the risk of running an unsupported
version); (4) a new version upgrade is much more complex, expensive, and lengthy to
implement than a patch implementation; and (5) functional upgrades provide more extensive
new functionality than patches.
2-11
2.2 ERP Upgrade
What is an ERP upgrade? - An ERP upgrade involves replacing an installed ERP version
with a newer version available from a vendor. It could mean a technical or functional upgrade.
It may cause custom code/objects being overwritten after an upgrade. Also, it usually happens
more than once in an ERP software lifecycle.
The size of an ERP upgrade may be classified according to two main dimensions: upgrade-
version, and upgrade-scope. Basically, the two categories of upgrade-version are minor and
major upgrade. A minor upgrade is described as an upgrade involving the same version series,
such as from 3.1H to 3.1I or 4.0B to 4.6C, whereas a major upgrade is a migration to a
different series, for example from three series to four series or higher. The upgrade-scope
dimension includes technical upgrade and functional upgrade. A technical upgrade is a ‘like
to like functionality replacement’. On the other hand, a functional upgrade delivers major
business improvements and enhancement benefits.
An ERP client could upgrade the installed version with a version readily available, (nearly
always) from the same vendor in the market. Upgrading an installed version to a new version
is part of ERP post-implementation activities. In contrast to patch maintenance (which is
meant for bug fix and occasionally minor enhancements), organizations typically upgrade to a
new ERP version in order to realize the benefits of substantial new functionality (SAP, 2002;
Stein, 1999a), and new technologies or business opportunities (such as enterprise portals, data
warehousing, and e-commerce) (Callaway, 2000). According to McDonnell (2000), the vast
majority of ERP-organizations tend to avoid major upgrades and stay on an older release, for
as long as it can meet their business needs. While there are few who upgrade their systems in
order to squeeze out even more business process improvements, some organizations feel
compelled to upgrade, as the vendor withdraws support for old versions. ERP vendors impose
a fixed time period for maintenance support for each version of the system (Collins, 1999;
Craig, 1999; Stedman, 1999). A supported version of ERP system is eligible for helpdesk
supports, and patch-supports. After the support window is closed, ERP clients will be entirely
on their own in maintaining their systems. (In some cases, the vendors offer a service
monitoring the unsupported systems for their clients but this support is very limited and incurs
a fee.)
2-12
2.2.1 Upgrade Decision
What is an ERP upgrade decision? – An ERP upgrade decision is about deciding when to
replace an installed ERP version with a newer version available from a vendor. This decision
is usually made more than once in an ERP software lifecycle. The introduction of new
versions of ERP by the vendors (such as SAP, Oracle, PeopleSoft, Baan, and J. D. Edwards)
is important (for them) in order to stay competitive. However, from the organizations’ point
of view, regular upgrades to new versions may not be manageable or affordable. According to
AMR Research, an upgrade may cost as much as one-third to one-fourth of the initial
investment (Carlino et al., 2000). On the other hand, organizations can not ignore the
importance of upgrading the software (AMR, 2002b). Each time a new version is released, an
enterprise will need to put some effort into making a ‘smart’ decision in determining whether
to upgrade to the new version, wait for the next version, or skip several versions. Even though
some vendors include significant upgrade discounts for several years, an enterprise may not
need to upgrade to some of these versions, or upgrade at all during that period. In making the
decision to upgrade, one has to consider several factors pertinent to the upgrade needs, and the
urgency of frequency of upgrade.
New functionality and personnel – Collins (1999) suggests that in making an upgrade
decision one has to consider the availability of the desired functionality (i.e. upgrade needs),
for example the e-commerce infrastructures (Ohlson, 2000), and Euro compliance for
European Monetary Union (EMU) organizations (Boulanger, 2001). This is consistent with
McDonnell (2000) who suggests that for a successful ERP upgrade, ERP client organizations
should outline the strategic, tangible, business and operational benefits of the upgrade;
determine methods to measure success in achieving them; and assign accountability and
authority for those goals. Besides these, McDonnell argues that unanimous top management
support for the business goals, and thus the upgrade decision, is also very important.
Upgrading does not confer any benefit if the new version does not have the functionality
required. Instead, upgrading without consideration will cause unnecessary expenses. The
availability of the right personnel and sufficient manpower are relatively crucial to the success
of an upgrade. In addition, organization will also need to retrain staff with new technical
skills, and with job skills that will be needed after the upgrade. The issue of user familiarity
also needs to be taken into account. An enterprise has to be sensitive to the comfort and
familiarity of its users with the ERP software system (400-Group, 1998a). Upgrading
2-13
frequently without allowing sufficient time for the users to become familiar with the software,
and for software stability will cause inefficiency and lack of productivity and confidence in
using the system.
Upgrade path and support window – In considering the frequency of upgrades, Collin
(1999) notes that the vendor’s upgrade path availability and support window play the major
roles. Upgrade path availability indicates the viability of upgrading from one version to
another. If an upgrade path from one version to another is available then technical and
procedural complications will be minimal. Nevertheless, the stability of the new version has
to be taken into account (Collins, 1999). An unstable version may cause production
downtime. SAP, for instance, supports their customers’ ERP, based on the time elapsed since
the release and the type of release. Longer periods of support are given for the full general
availability release, than for functionality releases. SAP functionality releases such as 3.0E,
3.1G, 4.0A, 4.5A, and 4.6A will have a much shorter support period than the full general
availability releases, for example 3.1F, 3.1H, 3.1I, 4.0B, 4.5B, 4.6B, 4.6C, which usually have
a support length of three years after the initial release. Further, the platform of the operating
system and database is also taken into consideration in providing support. Collins notes that
during this support window, an enterprise is eligible for help desk support for any problems
that may be encountered with the software, any flaw or bug in the software will be the
responsibility of the vendor, and discounted upgrades will be given for any new version with
improved features. Different ERP vendors provide different types of support to their users.
After the support window, limited support will be given depending on the currency of the
software version kernel and platform.
Modification and changes to the standard software – Modification to the original ERP
code done during ERP implementation and the subsequent maintenance in order to follow its
legacy system or add additional functionality to the software can complicate an upgrade
decision (Brehm et al., 2001). It has a great impact in making an upgrade decision. Upgrading
to a new version does not only overwrite all of the initial modifications but also require
redevelopment and re-testing of the whole system. This may lead to a much higher upgrade
cost than expected, regardless of the upgrade path constraints for the subsequent new version
or the support window provided by vendors to help with the upgrade cost (Collins, 1999).
Thus, modifications should be avoided unless it is really necessary and inevitable. In order to
minimize the effort and problems associated with upgrading a customized ERP code, Collins
2-14
has suggested three steps to be taken in dealing with ERP modification processes. Firstly,
maintain a development standard to recognize the changes made to the ERP code,
modification design and documentation. For instance, in an SAP software environment, all
customer-developed objects are prefixed with ‘Y’ or ‘Z’. Secondly, create new system
objects, instead of modifying the existing object, to minimize the upgrade risks. Thirdly,
thoroughly document the changes, and the business reason behind each of the modifications.
2.2.2 Upgrade Cost Drivers
Nevertheless, most of the trade press has cited that cost is prohibitive in considering an
upgrade in ERP systems (Carlino et al., 2000). Upgrade cost can be as high as 25-33% of the
initial ERP implementation costs (Ohlson, 2000). Similar to the initial ERP implementation
and acquisition cost, upgrade expenses (including technical and functional upgrade) include
the software cost, hardware cost, user training cost, consultant fees, the upgrade
implementation cost, and post-implementation turmoil.
Software cost – A new version of an ERP system, which has more functionality, flexibility,
and extensibility, will generally cost more to upgrade. It is perceived that an organization is
most likely to upgrade to the latest version of the ERP system. Some of the advantages for
upgrading to the latest version of ERP are: (1) a minimal number of future upgrades, (2) a
longer period of maintenance support from the vendor, and (3) a gain in competitive
advantage through early utilization of new technologies.
Hardware cost – Upgrading to a new version of an ERP system often entails purchase of
additional and more powerful hardware (Jakovljevic, 2000d), or new hardware that is
compatible with the new system.
User training cost – User training costs, associated with re-training the ERP system’s users,
is driven by changes in user interface and/or new functionality in a new system (Ohlson,
2000). An increase in cost is anticipated if these features are dramatically different from those
of an existing system.
Consultant fees – An ERP upgrade is a complex and large project requiring a wide range of
knowledge and expertise, for example in the areas of software functionality, system
2-15
configuration, system integration, project management, change management, and other
technical aspects of new software and hardware. This knowledge and expertise is necessary
for a successful upgrade of an ERP system (Marion, 1999; Pearson, 1998; Wee, 1999).
However, not all of this knowledge and expertise is available internally, particularly for the
first ERP upgrade project. Hence, most of the time, external consultants are required.
Upgrade implementation cost – On the other hand, the upgrade implementation cost
involves the cost of data conversion, system analysis, system integration and testing, and post-
implementation turmoil (Jakovljevic, 2001a; Slater, 1998). In general, upgrade
implementation costs are driven by the complexity of the upgrade project, which in turn is
determined by the number of modules to be implemented and the number of business units
involved.
Post-implementation turmoil – Post-implementation turmoil here refers to the potential
system disruptions (e.g. a dip in operational efficiency and effectiveness) (Thompson, 2001a)
or downtime in relation to the implementation of an upgrade or installation of a new system.
It includes change management (400-Group, 1998a; Clemons, 1998; Glover et al., 1999).
Literature review (in Section 2.2.1 and 2.2.2) and discussion so far is fundamental to
understand the factors affecting ERP upgrade decision and cost. These details are referenced
in Chapter 6 where an ERP maintenance and upgrade decision framework is proposed.
2.2.3 Plan For An Upgrade
Collins (1999) identifies four steps involved in planning for an ERP upgrade. First step – The
first step is preparing an inventory of custom development objects pertinent to the gathering
of the documentation of all tailoring in the software and processes of the previous and original
installation. Shi et al. (2001) state that this documentation (the information for each custom
development object) should include the object name, description, type, associated transaction
code and function module, business criticality (i.e. a link between a modification and the
business reason for the modification), and so forth. Shi et al. report that classifying the custom
development objects is crucial in order to plan and thus estimate the amount of effort required
to complete the development tasks.
2-16
Second step – The second step, according to Collins (1999), is developing documentation of
the current technical environment (i.e. database, operating system, server) to support the
evaluation of the requirement of a new version against the current one.
Third step – Thirdly, build an understanding of the functional and technical elements of the
new release. This will be followed by estimations of the hardware requirements and software
reworks. Once the upgrade scope and impact are determined, a resource and budget plan can
be developed. The estimations involved in the hardware are the CPU, disk, and network. On
the other hand, some of the rework elements related to the software are the custom report,
programs, table, screen modification, user exits, ABAP and data dictionary changes. With
these elements in mind, the effort required for re-applying, and verifying them in the new
version of ERP could be estimated. Besides this, preparing the system landscape (e.g. keeping
the production system synchronized with the development during upgrade), and creating a
detailed test plan are important (Shi et al., 2001). This test plan includes a functional test,
integration test, business process validation and so forth.
Fourth step – Lastly, the focus is on the upgrade process itself. This may involve the time
spent to acquire the hardware and software, freezing the development for the current release,
project team management, and performing the actual production upgrade (Collins, 1999).
2.2.4 Execution Of An Upgrade
One of the fundamental issues in upgrading is making sure that all patches for the existing
version are implemented beforehand. This procedure is automated by the SPAM. In fact,
SPAM is integrated into the SAP upgrade procedure (SAP, 1998c). Impact analysis and the
initial upgrade will be performed in the development system. In this step, the customized
reports, interfaces, batch processes, and on-line modification will be analyzed as to how they
will be impacted by the new release and their discrepancies (Collins, 1999). These customized
objects can be viewed and adjusted (during the upgrade process) using two transactions
supported by SAP: SPDD and SPAU.
SPDD, an integral part of the upgrade process, is used for adjusting most of the data
dictionary objects, and prevents data loss due to changes in data dictionary objects. All SPDD
adjustments are grouped under one change-request and marked for transport, which is used to
2-17
upgrade subsequent systems (quality assurance system and production system) (Shi et al.,
2001). On the other hand, SPAU is for adjusting Repository objects (such as report, function
module, menu, screen, interface, etc.) and a few data dictionary objects (Shi et al., 2001). It is
done after the upgrade (in the development system). For each object presented for adjustment
in the SPAU list, a decision as to whether to keep the modification has to be made. All the
overwritten modifications are either re-applied to the new system or replaced with the
vendor’s standard code. After all modification adjustments in the development system are
completed, they would be transported/ released. Similar to SPDD, all SPAU adjustments are
grouped under one change-request (i.e. a Workbench change-request, using the Workbench
Organizer in the Change and Transport Organizer) and marked for transport (by the Transport
Management System in the Change and Transport System) to facilitate an upgrade to a
subsequent system. All these change-requests are then exported/ released to the quality
assurance system.
All business processes are re-tested and verified for system functionality accuracy in the
quality assurance system. User acceptance, system performance and integration tests are
conducted to verify the data conversion (Collins, 1999). After the successful trial upgrades in
both development and quality assurance systems, the last step is the production system
conversion. The R/3 upgrade control program will detect the SPDD and SPAU change-
requests during the test phase of the production system upgrade, and all modification
adjustments in the change-requests are automatically applied to the system (Shi et al., 2001).
Eventually, the current application is upgraded to the new release.
Literature review in Section 2.2.3 and 2.2.4 are used to cross-check with this study’s case
firm’s ERP upgrade process and are referred in Chapter 7 where ERP maintenance
methodology is proposed.
2.3 Benefit-realization
The ERP vendor continuously updates, improves, and develops ERP software. These business
improvements or enhancements and latest technologies are delivered to its clients in the forms
of support package or patch, and new versions for upgrade. In order to continue realizing
more benefits from ERP systems, ERP-using organizations are required to incorporate support
2-18
packages, and upgrade to the newest version of an ERP system. (This is also important to the
vendor in order to contain its maintenance costs and focus its development efforts on one or a
few versions.)
Benefit-realization is the fundamental factor influencing and driving ERP maintenance and
upgrade activities. According to Ross et al. (2000), in the period immediately after an ERP
implementation, ERP-using organizations usually experience performance dip due to new
learning curve for the system users and major organizational change. After the system users
are familiar with the system, ERP-using organization will then start realizing benefits from
the system. Most of the time, this is achieved by continuously maintaining (for example by
adding functionality through new modules, bolt-on) and upgrading the installed ERP system
(to enhanced and with state-of-the-art technology new version. Benefit-realization (from an
installed ERP system) is also known (among the practitioners) as ERP’s second wave. In this
study, benefit-realization refers to:
achieving fuller capabilities and benefits (or business values) from ERP systems
through continuous systems maintenance and upgrade.
It is believed that the benefits and rationale driving an ERP implementation decision are also
the drivers for maintaining the system and influencing maintenance-related decisions. These
maintenance activities could be beneficial to ERP clients from cost reduction to generation of
business opportunities (Fontana, 1998; Morphy, 1999; Mullin, 1997; Ross et al., 2000;
Weston, 1998; Whearly, 1999). While some authors describe ERP benefits from the
organizational-level perspective as consisting of three dimensions – strategic, tactical and
operational (see (Irani et al., 2001; Jakovljevic, 2000b; Shang et al., 2000)), others define
those benefits from a business perspective and consider competitive advantage, globalization,
integrated systems, best practice and cost reduction (Davenport, 1999; Freedman, 1999;
Gable, 1998; Heald et al., 1999; Holland et al., 1998; Markus et al., 1999; Markus, 2001;
Vernadat, 1996; Weston, 1998).
This thesis has chosen to describe ERP (maintenance) benefits from the business perspective
because it has direct link to the terminology used by practitioners. Section 2.3.1 presents
examples of the ERP or its predecessor’s benefits from the three organizational levels
perspective. These examples are then mapped into the business benefit dimensions based on
clear and precise definition of the business benefit dimensions.
2-19
2.3.1 Organizational-Level Perspective
According to Harris (in (Irani et al., 2001)), investment decisions typically fall into three
categories: strategic, tactical and operational. Table 2.6 provides a list of benefits of using an
ERP system and its predecessor – Manufacturing Resource Planning (MRPII)8 – from
strategic, tactical and operational perspectives. The benefit examples shown in Table 2.6 may
not be a complete representation of all the possible benefits delivered in an ERP system and
its extensions (such as Customer Relationship Management, Supply Chain Management, E-
business and so forth). Three studies considered in this literature review, that describe ERP
system benefits from any or all of these three organizational levels, are by Irani and Love
(2001), Shang and Seddon (2000) and Jakovljevic (2000b). The research by Irani and Love
(2001) is conducted using a case study in a leading U.K. manufacturing business, adopting the
MRPII, whereas the study by Shang and Seddon (2000) on ERP systems benefits is carried
out using Web case analysis with a sample of 233 ERP-using organizations worldwide. The
trade literature by Jakovljevic (2000b), at the Technology Evaluation Center, is based on ERP
market research and observations.
8 This is not without controversy. Turban and Aronson (2001) state that “the name ERP is somewhat misleading because the software does not concentrate on either planning or resources” (pg. 331) but focuses on integration across a company for all departments and functions into a single computer system to serve the entire enterprise needs.
2-20
Table 2.6: List of potential ERP systems’ benefits from the organizational-level perspective.
Example of benefit (or business value) Organizational-level perspective
Irani and Love (2001) Shang and Seddon (2000)
Jakovljevic (2000b)
Strategic Improve growth and
success.
Leader in new technology.
Improve market share.
Market leadership.
Enhance competitive
advantage.
Support current and
future business growth.
Effectively and efficiently
support business alliance
– consolidate newly
acquired companies in
standard business
practices.
Build business
innovation.
Build cost leadership – by
achieving economies of
scale through streamlined
processes or shared
services.
Enhanced product
differentiation.
Build external linkage
with suppliers, distributors
and related business
parties.
Enable worldwide
expansion – multi-
currency capability, and
global market
penetration.
Enable e-business –
getting closer to customer
Enable new business
strategies.
Enable globalization.
Enable growth
strategies.
Extend supply/demand
chain.
Increase customer
responsiveness.
Tactical Improved flexibility.
Improved response to
changes, product quality,
and teamwork.
ND* Improved productivity.
Improved flexibility.
Improved integration
with other business
2-21
Example of benefit (or business value) Organizational-level perspective
Irani and Love (2001) Shang and Seddon (2000)
Jakovljevic (2000b)
Promotes open culture.
Improved integration with
other business functions.
Increased plant efficiency.
Reduced delivery lead-
times, and lead-times.
Improved capacity
planning, data
management,
manufacturing control,
accuracy of decisions.
functions.
Integrate acquisitions.
Standardize business
processes.
Improve specific
business
processes/performance.
Operational Reduced raw material
inventory.
Reduced labor costs.
Reduced manufacturing
costs.
Increased throughput.
Reduced raw material
inventory.
Reduced labor costs.
Increased throughput.
Reduced administrative
expenses.
Reduced cycle time in
customer support,
employee and supplier
support activities.
Quality improvement –
reduction in error rate and
duplicates, and improved
accuracy rate and
reliability.
Improved customer
services – ease of
customer data access
and enquiries.
ND*
*ND = not discussed explicitly in the article.
2-22
2.3.2 Business Perspective
On the other hand, benefit categories from the business perspective most frequently quoted in
the research report and trade literature are competitive advantage (Deloitte-Touche-Tohmatsu,
1999b; Heald et al., 1999; Irani et al., 2001; Shang et al., 2000; Travis, 1999; Weston et al.,
1998), globalization (Freedman, 1999; Gable, 1998; Holland et al., 1998; Vernadat, 1996),
integrated systems (Davenport, 1999; Jakovljevic, 2000c; Markus, 2001), best practice
(Carlino et al., 1999b; Deloitte-Touche-Tohmatsu, 1999a; Deloitte-Touche-Tohmatsu, 1999b;
Jakovljevic, 2000a; Markus, 2000) and cost effectiveness/reductions (Carlino et al., 1999a;
Markus, 2001; Norris et al., 2000; Shanks et al., 2000).
Competitive advantage – ERP provides the opportunity, infrastructure and advanced
technologies that allow organization to (1) gain competitive business advantage by preparing
the organization for future challenges (Heald et al., 1999; Travis, 1999) and the need to
remain competitive, according to Advanced Manufacturing Research in (Weston et al., 1998);
(2) dynamically adapt, grow and extend businesses (Irani et al., 2001) and adopt new business
strategies or develop new partnerships (Deloitte-Touche-Tohmatsu, 1999b) by having an open
system and the capacity to operate worldwide; (3) increase customer responsiveness, data
access and satisfaction by reducing customer service time and facilitating worldwide access
and distribution of information about company, product and sales (Jakovljevic, 2000b) by
using the customer relationship management application; and (4) build cost leadership by
achieving economies-of-scale through streamlined processes or shared services (Shang et al.,
2000).
Competitive advantage is quoted by many authors (Davenport et al., 2002) to be achieved
from modifying the software code or from developing custom extensions. The author
perceives that competitive advantage can be also be achieved by other means for example by
using new technology/functionality to generate business opportunities, and to facilitate
improvements to existing business process(s) to better compete and attain business goals (see
also (Dunn, 2003; Davenport, 2002)). Different organizations may have different views on
what gives competitive advantage to their organizations. This can be determined based on
their unique business objectives or goals. Different technology /functionality can be used to
achieve/facilitate different goals, and the same technology can also be used to achieve
different goals. Many organizations may be using the same system but it is how they use it in
2-23
their contexts, and for what purpose that gives them the edge. Competitive advantage for one
organization does not mean that it is so for the other.
Globalization – The functionality in ERP allows organizations to do business in multiple-
currencies and languages, and the uniform interface of ERP product across national borders
have helped facilitate progress towards globalization and global market development
(Freedman, 1999; Gable, 1998; Holland et al., 1998). Globalization enables organizations to
operate in the worldwide market (see (Vernadat, 1996)), provide equivalent levels of service
to customers worldwide (Jakovljevic, 2000c), overcome the problem of information
fragmentation, and improve information flow to and from customers, suppliers and business
partners. Once achieved, e-commerce and e-business become possible through second-wave
applications such as supply-chain management (SCM), online procurement, and customer
relationship management (CRM) (Jakovljevic, 2000c).
Integrated system – ERP brings the benefit of full business processes integration and
standardization (Deloitte-Touche-Tohmatsu, 1999a; Jakovljevic, 2000b; Markus, 2000;
Markus, 2001; Stein, 1999b; Whearly, 1999). The availability of a wide range of applications
and modules in ERP packages has meant that user-organizations can satisfy most of their
application needs with the single ERP. This has eliminated integration complexities
associated with applications from multiple-vendors and has enhanced information flow
among internal processes. An integrated and centralized system has provided support for
complete data visibility for all levels of organizational management, thereby facilitating
corporate and strategic decision-making (Hicks et al., 1995; King, 2000; Ross et al., 2000).
Best business process – According to Davenport and Short (1990), business process is
defined as “a set of logically related tasks performed to achieve a defined business outcome”
(pp. 12). ERP serves as a more controlled and coherent contact point among the internal
business units, regardless of geographical separation has improved the overall business
processes and practices (Barnes, 1999; Bingi et al., 1999; Davenport, 1999; Hammer et al.,
1996; Sieber et al., 1999). It has also facilitated improved business performance (Deloitte-
Touche-Tohmatsu, 1999a) and shortened product cycle times (Minahan, 1998).
Cost effectiveness/reduction – The characteristics of a real-time, single centralized database,
and the availability of maintenance support from the vendor have allowed: (1) operational
2-24
cost reductions, for example reduction in time and cost associated with order re-entry errors,
data entry, incorrect shipment and administrative burdens for the sales force (SAP, 2002); (2)
savings in integration expenses for different applications from different vendors (Stein,
1999b); (3) shortened cycle times and reduced inventories (Minahan, 1998); and (4) lower
maintenance costs, as the cost is spread over many other users (Butler, 1999; Hicks et al.,
1995; Markus, 2001; Whearly, 1999).
Based on the studies mentioned above, the definition and description of the five most sought
after dimensions of business benefits are distilled as follows. ‘Competitive advantage’ is
described as strategy or policy undertaken to increase the capabilities to compete with other
competitors, and presumably results in cost reduction to the customer and/or increased service
or product quality to the customer. ‘Globalization’ refers to the flexibility to operate
worldwide with business partners, customers, and suppliers, transact business in multiple-
currencies and communicate in multiple-languages, present a unified interface, and support
merger and acquisition activities. On the other hand, ‘integrated system’ relates to further
improvement to the integration and communication among internal business processes. The
main difference between globalization and integrated system benefits is that while
globalization is aimed at enhancing information flow external to an organization, an
integrated system is meant for a seamless internal information flow. Best business process or
practice is re-defined as a set of logically related tasks performed to achieve a best defined
business outcome. ‘Cost effective / reduction’ is described as cost cutting in activities related
to business administration and processing, and system maintenance. Table 2.7 summarizes the
definition, primary objective and the characteristics of ERP that drive these five categories of
business benefits.
Table 2.7: Benefit categories from business perspective
Category Distilled definition or description from the literature
Primary objective or intention for maintenance
Characteristics of ERP
Competitive
advantage
Increase and improve the
capabilities and power to
compete with other
competitors.
Increase market share,
business opportunity
(thus, enhance revenue
generation), customer
loyalty, customer
satisfaction, service
Advanced
technologies, best
practice, integrated
system, worldwide
interoperability.
2-25
Category Distilled definition or description from the literature
Primary objective or intention for maintenance
Characteristics of ERP
quality.
Globalization Enhance information flow to
and from customers,
suppliers, and other business
partners outside the
enterprise in a tightly coupled
mode, and flexibility to
operate in worldwide market.
Facilitate global access to
customer, supplier and
business partners, and
vice versa.
Unified interface,
multiple-currency and
language, integrated
system.
Integrated
system
Improve the flow of
information through
centralized system, better
system integration and
communication among
internal business processes.
Improve integration
among internal business
processes, enhance data
management and
accuracy of decisions.
Cross-functional, a
single vendor
application.
Best business
process /
practices
Improve business processes
and practices, and business
performance.
Enhance efficiency and
effectiveness in business
processes and business
performance/revenue, and
shorten cycle times
Standardized
processes, integrated
system, off-the-shelf
software.
Cost
reduction
Reduce operating and
maintenance cost; and
ensure ongoing system
support from the vendor.
Minimize cost (to the
company)
Real-time, single and
centralized database,
integrated system,
best practice,
maintenance support.
2.3.3 Similarities Between Organizational-Level And Business
Perspectives
Using the examples of benefits shown in Table 2.6 and description and definition of the
benefit categories given in Table 2.7, the dimensions of benefits from the organizational-level
and business perspectives are compared and matched. The results are shown in Table 2.8. As
anticipated, there are similarities and overlaps between the organizational-level and business
perspective of ERP systems’ benefits. The second-column in Table 2.8 combines the benefits
discussed by Irani and Love (2001), Shang and Seddon (2000) and Jakovljevic (2000b) in
Table 2.6. (The benefit examples given in Table 2.8 may not be a complete representation of
2-26
all the possible benefits delivered in an ERP system and its extensions (such as Customer
Relationship Management, Supply Chain Management, e-business and so forth)). In general,
the descriptions of competitive advantage and globalization benefit-categories are covered
under the strategic dimension, whereas best practice and integrated systems are under the
tactical. On the other hand, cost reduction is under the operational dimension. However, for
the benefit examples presented from the organizational-level perspective that are not
consistent with the respective definition of business benefit dimensions are omitted in Table
2.8.
Table 2.8: Similarity between the organizational-level and business perspectives
Organizational-level perspective
Example of benefits a Business perspective
Improve growth and success.
Build business innovation.
Enable new business strategies.
Build cost leadership – by achieving
economies of scale through streamlined
processes or shared services.
Enhance product differentiation.
Increase customer reponsiveness.
Leader in new technology.
Improve market share.
Market leadership.
Enhance competitive advantage.
Strategic
Effectively and efficiently support business
alliance – consolidate newly acquired
companies in standard business practices.
Built external linkage with suppliers,
distributors and related business parties.
Enable worldwide expansion – multiple-
currency capability, and global market
penetration.
Enable e-business – getting closer to the
customer.
Enable globalization.
Extend supply/demand chain.
Globalization
Competitive Advantage
2-27
Organizational-level perspective
Example of benefits a Business perspective
Improved flexibility.
Standardize business processes.
Improve specific business
processes/performance.
Improved productivity.
Improved response to changes, product
quality, and teamwork.
Promotes open culture.
Increased plant efficiency.
Reduced delivery lead-times, and lead-
times.
Tactical
Improved capacity planning, data
management, manufacturing control,
accuracy of decisions.
Improved integration with other business
functions.
Integrate acquisitions.
Operational Reduced raw material inventory.
Reduced labor costs.
Reduced manufacturing costs.
Reduced administrative expenses.
Reduced cycle time in employee and
supplier support activities.
Quality improvement – reduction in error
rate and duplicates, and improved
accuracy rate and reliability.
a It is not necessarily a complete list of all possible benefits.
2.3.4 Business Value In ERP
Sections 2.3.1-3 show the organizational-level and business perspectives of the benefits (or
business values) of implementing, and therefore, maintaining an ERP system. In this section,
some figures or quantification of the benefits or business values are given. (Knowing the
business value is imperative in order to quantify monetary value.) Katz (1993), in a survey
conducted with 29 organizations in the U.S., finds that in order to measure business value an
organization needs to assess the performance of the information system (IS) functions (e.g.
Cost Reduction
Best Practice
Integrated System
2-28
meeting target delivery date, IS cost reduction, system reliability and availability), and the
impacts of information technology (IT) on the organization (such as increased productivity,
reduced head count and so forth). Table 2.6 shows some of the business values derived from
MRPII (ERP’s predecessor) and ERP systems. They are directly related to either the IS
performance or IT impact of the manufacturing company. Table 2.9 below provides some
illustrations of how these benefits were realized and quantified by some of the ERP clients.
Table 2.9: Examples of benefit-realization from ERP systems
Organizational-level benefit category
Business benefit category
Quantification examples
Competitive
advantage • Autodesk, a leading maker of computer-aided design
software, uses an enterprise system and is now able to
deliver 98% of its orders to customers within 24 hours as
compared to two-weeks delay with the legacy system
(Davenport, 1999). This makes Autodesk competitive
among its rivals.
• Fujitsu Microelectronics achieved a reduction in the cycle
time for filling orders from 18 days to a day and a half
(Davenport, 1999).
Strategic
Globalization • In the petrochemical industry, an enterprise system that
facilitates information flow through geographical
distributed supply chain and electronic information sharing
is of paramount importance for survival (Davenport, 1999).
Best business
practice • Amherst Corporate Computer Sales & Solutions, an online
seller of IT products and services, has experienced a 20%
(equivalent to $71,000) productivity increase in terms of
sales per employee through best business practices in the
ERP system (McDonnell, 2000).
Tactical
Integrated
system • Owens Corning, an international goods supplier, had its
spare-parts inventory reduced by 50% (an estimated
saving of $65 million) from its integrated enterprise system
(Davenport, 1999), which links financials, supply chain,
and order management processes seamlessly.
• Integrated systems are utilized in high-tech companies to
inject more discipline into the organization, exert more
management control, and impose more uniform business
processes (Davenport, 1999).
2-29
Organizational-level benefit category
Business benefit category
Quantification examples
Operational Cost reduction • Elf Atochem North America, a $2 billion regional chemical
subsidiary, was expecting to reduce annual operating
costs by tens of millions of dollars from its enterprise
system (Davenport, 1999).
According to Davenport, Harris and Cantrell (2002), there are three fundamental drivers of
business value for enterprise solution: integrate, optimize and informate. They are called
drivers of value because they steer organizations to meet their unique business vision. While
integrate refers to “unify and harmonize enterprise solutions, data and processes with an
organization’s unique existing environment, and use the systems to better connect
organizational units and processes, as well as customers and suppliers”, optimize relates to
“standardize most processes using best practices embodied in enterprise solutions software,
mold and shape processes to fit the unique or strategic needs of the business, and ensure that
processes flow and fit with the systems themselves” (pg. 6). On the other hand, informate
associates with “transforming enterprise solutions data into context-rich information and
knowledge that supports the unique business analysis and decision-making needs of multiple
work forces” (pg. 6).
In terms of definition, each of the five business benefit categories discussed earlier falls under
one of the three business value drivers. For instance, globalization and integrated system are
under the integrate-driver; competitive advantage and best process/practices under the
optimize-driver; and cost reduction under informate-driver. However, similar to the five
business benefit categories (which is discussed in detail in Chapter 4), the drivers of value are
unlikely to be mutually exclusive such that a value driver may trigger or lead to another value
driver(s).
Section 2.3 discusses in great details about the benefits and business values of an ERP system.
This literature review is of paramount important as it leads to better understanding of the
major characteristic of ERP system. As a result, benefit perspective is argued to be a crucial
element in classifying ERP maintenance requests (see Chapter 4 – taxonomy sub-study), and
2-30
user opportunity is said to be an issue if maintenance or upgrade decision is ignored or
delayed (see Chapter 6 – decision sub-study).
2.4 Recap – ERP Literature Review
The literature review so far indicates that very little is known about ERP maintenance
taxonomy, effort determinant, decision framework/model, methodology and data-model.
Table 2.10 provides a summary of what is known and yet to be known about ERP
maintenance and upgrade, particularly in the five research areas covered in this thesis.
Table 2.10: Recap of the known and unknown about ERP maintenance and upgrade
Research area covered in this thesis
What is known (from the literature)?
What is not known? (particularly in the context of ERP client organization)
ERP maintenance
taxonomy
(taxonomy sub-study)
Enhancement is the major
maintenance activity (Glass et al.,
1999).
ERP vendor provides maintenance
support in the form of patches and
new versions for upgrades to its
ERP clients.
Definition of ERP maintenance.
Maintenance taxonomy.
ERP maintenance effort
determinant
(effort sub-study)
Patch-maintenance and upgrade
effort depends on the degree of
modification to the installed version
– this is open for hypothesis
testing.
Effort required to implement a
change-request depends on the
tailoring option (Brehm et al., 2001)
– this is open for hypothesis
testing.
Hypothesis testing (empirical
results) on the determinant(s) of
maintenance effort.
ERP maintenance and
upgrade decision
framework
(decision sub-study)
Upgrade cost drivers.
Driver of maintenance and upgrade
decision.
Impact of upgrade on future
maintenance effort.
Decision framework.
ERP maintenance
methodology
Upgrade process – consultant
perspective (Collins, 1999; Shi et
Maintenance preparation process.
The process of managing and
2-31
Research area covered in this thesis
What is known (from the literature)?
What is not known? (particularly in the context of ERP client organization)
(methodology sub-study) al., 2001).
The process of documenting and
delivering maintenance changes
such as patch-maintenance, into
an ERP system (SAP, 1998a)–
vendor instructions for its clients.
executing internal maintenance
requests.
A methodology that integrates and
provides guidelines for all
processes involved.
ERP maintenance-data-
model
(data sub-study)
- Maintenance-data-model – the
measurable attributes of ERP
client’s maintenance request.
2.5 In-house Software Maintenance
Due to a lack of: (1) existing theories and studies on ERP maintenance and upgrading (as
observed in the previous sections), and (2) comprehensive study of packaged software in
general (Gable et al., 1997; Gable, 1998), prior studies and research in the traditional in-house
software maintenance and replacement model literatures have been consulted. Note that this
thesis focuses on comparing ERP packaged software with in-house software (homegrown
software). Although it is worth making similar comparison between ERP and other packaged
software – commonly known as commercial off-the-shelf or COTS even though the literature
is limited, this is not the primary intention of this thesis. Thus, such a comparison is not
covered in detail here but is a suitable topic for future research.
In-house software maintenance has been studied extensively and has been grounded since the
1970s. The author’s objectives here is to identify what has been done in the five research
areas investigated in this thesis from the in-house software maintenance perspective:
maintenance taxonomy, determinants of maintenance effort, software replacement models,
standard for software maintenance model/process/methodology, and maintenance-data-model
(i.e. measurable maintenance request’s attributes). This section focuses on what is known
about in-house software maintenance in the five areas under investigation. Section 2.6
provides a summary of the in-house software literature review. More discussion of the
2-32
differences between ERP and in-house software is given in Section 2.7, and the gaps in prior
studies on in-house software will be given in Section 2.8.
2.5.1 Software Maintenance Definition
According to the Institute of Electrical and Electronics Engineers (IEEE) Standard for
Software Maintenance (IEEE, 1998b), software maintenance is defined as the “modification
of a software product after delivery to correct faults, to improve performance or other
attributes, or to adapt the product to a modified environment”. Other authors such as Ogdin
(Ogdin, 1972) views software maintenance as the “continuing process of keeping the program
running, or improving its characteristics…” whereas Lientz and Swanson perceive that
maintenance constitutes a large part of continued software development (Lientz et al., 1980).
Other researchers argue that maintenance is unavoidable and its occurrence is unpredictable
based on changes in user requirements and environment (Gremillion, 1984). Each
maintenance request will entail maintenance effort and cost; and the maintenance phase alone
consumes around 50-70% of the total software cost in the software life cycle (Banker et al.,
1991; Glass et al., 1981).
2.5.2 Classification of Maintenance Activities
Classifying a maintenance request is one of the primary tasks to do after its arrival.
Maintenance classification, as a tool, is imperative in order to facilitate modification
investigation and avoid delay in servicing emergency maintenance, such as bug fixes.
Literature review of in-house software maintenance taxonomy shows that there are two
classifications for maintenance activities. The first was proposed by Swanson in 1976 (see
(Swanson, 1976)). The second is a more recent development by Chapin, Hale, Khan, Ramil
and Tan (see (Chapin et al., 2001)). The following sections will provide more detail about
these two maintenance taxonomies.
2.5.2.1 Swanson’s Classical Classification A widely accepted and applied classification of software maintenance differentiates
corrective, adaptive, and perfective maintenance activities (Swanson, 1976). The main
criterion that differentiates these three categories is the purpose of the maintenance request
2-33
(which is usually to remedy the cause of the request). The corrective and adaptive
maintenance categories are respectively meant to keep the system up and functioning
correctly, and able to operate well in a new environment. Perfective maintenance seeks to
improve the cost effectiveness of the program, and to better serve the system users’ needs.
Detailed descriptions of each of these three categories are given in Table 2.11.
Table 2.11: Swanson’s categories of maintenance activities
Maintenance category Objective* Corrective Correct errors in a program (i.e. processing failure), fix programs that
do not perform satisfactorily (i.e. performance failure), and repair
violations (if any) of the predetermined programming-standards (i.e.
implementation failure).
Adaptive Adapt a program to a changed environment (data and/or processing
environment); e.g. logical restructuring of a database, installation of a
new hardware or operating system version, recoding an existing
program.
Perfective** Eliminate program processing inefficiency such as inferior
computational algorithm, inappropriate language features or poor use
of computer operator time; enhance program performance such as
reformat report to improve the readability, add new data elements to
a report, add new functionality; and improve program maintainability
(to allow the program to be more easily modified when it must be
modified) such as insert certain comments in a program, rewrite
program documentation.
* Source: Swanson (1976), pp. 492-493.
** In a later study (Lientz el at., 1980), it is found that enhancement for users, which is a sub-category under perfective
maintenance, accounted for 42% of the total maintenance effort, on the average.
It is noted that Swanson’s classical maintenance classification does not consider user-support
maintenance requests, which were found, in a study by Abran et al. (1991; 1993), to account
for 22% of the total software maintenance effort. User-support requests are associated with
consulting with and supporting user requests relating to the system’s behavior, rules and
functions. They are different from corrective, adaptive and perfective because servicing them
does not result in any changes made to the software system.
2-34
Distribution of maintenance effort among different maintenance categories based Lientz et al.
(1980), and Abran et al. (1993) is summarized in Table 2.12.
Table 2.12: Comparison of two studies on maintenance effort distribution among different
maintenance categories
Maintenance category Lientz et al. (1980) Abran et al. (1993) Corrective 20% 30%
Adaptive 25% 8%
Perfective 50% 41%
User-support - 22%
Others 5% -
2.5.2.2 Chapin et al.’s New Classification A more recent maintenance classification proposed by Chapin et al. (2001) differentiates
twelve types of software maintenance based on evidence of: (1) activities involved in
interface support; (2) usage and changes to documentation; (3) changes to software properties;
and (4) changes to software functionality. The 12 types are enhancive, corrective, consultive,
training, groomative, evaluative, reformative, updative, preventive, performance, adaptive,
and reductive. Table 2.13 provides characteristics of these classes of maintenance activities.
Table 2.13: Chapin et al.’s evidence of maintenance activities
Maintenance category Evidence of activities* Training Conducting classes for customer personnel, doing training ranging
from on-site on-the-job to vestibule on-the-road training, and using
existing training materials.
Consultive Fielding questions at a help desk for customer personnel about the
software, conferring with customer personnel or managers about the
effective use of a system or about the making of changes to the
software, and advising customers or managers or other stakeholders
about the likely time, cost, activities, or effort needed to do requested
or contemplated evolution or maintenance work. Sup
port
Inte
rface
Evaluative Auditing, searching, examining, regression testing, studying
diagnostic testing, providing protected testing environments,
calculating metrics about, or creating an understanding of the
software without changing the software.
2-35
Maintenance category Evidence of activities* Reformative Altering the format or coverage of a user manual, preparing training
materials, incorporating the effects of a changed local standards
manual, and changing the form or format of the non-code
documentation by modifying the use of a CASE tool.
Doc
umen
tatio
n
Updative Updating the content and coverage, and polishing the non-code
documentation by such activities as replacing obsolete non-
documentation with current accurate documentation, and filling in
gaps in the non-code documentation such as by incorporating test
plans, narrative overviews, UML models, etc., without changing the
code.
Groomative Doing recompilations, replacing components or algorithms with more
elegant ones, creating code backups, changing personal or level
access authorizations, changing source code comments or
annotation lines, changing data naming conventions, altering code
readability or understandability, providing less-cryptic error
messages, and preparing source code for pretty-printing.
Preventive Restructuring the code to improve maintainability and put in place a
base for making a future change to some new technology.
Performance Reducing the amount of internal storage used, improving system up
time, reducing the duration of out-of-service periods, speeding
execution as by replacing components or algorithms with faster
ones, and improving system reliability and robustness. Sof
twar
e P
rope
rties
Adaptive Making the system work on a different platform or with a changed
operating system or with a different kind of database, reallocating
functions among components or subsystems, increasing COTS
utilization, changing communication protocol supported, altering the
system’s interoperability, and changing design and implementation
practices such as moving to object-oriented technology.
Reductive Limiting or eliminating some business rules from the implemented
repertoire, as by replacing or constraining or removing part or all of
some components or algorithms or subsystems or data flows.
Corrective Refining and making more specific the implementation of the existing
business rules to handle exceptions and mishandled cases better,
usually by adding additional precision to the internal logic of some
components or algorithms or subsystems, or by adding more
defensive programming. Bus
ines
s R
ules
(S
oftw
are
func
tiona
lity)
Enhancive Inserting new components, algorithms, or subsystems, and altering
existing ones to enlarge or extend their scope, including adding new
data flows and redirecting existing data flows.
2-36
*Source: Chapin et al. (2001), pp. 9-14.
It is observed that Chapin et al.’s classification is comprehensive, and empirical data is
required in order to test whether it is sufficient in the context of ERP.
2.5.3 Determinants of In-house Software Maintenance Effort
The importance of software maintenance (which consumes 50-70% of total software costs
(Banker et al., 1991; Glass et al., 1981)) is recognized among the researchers, and this has
motivated a large number of studies on the software maintenance effort, cost drivers,
productivity and economics of software maintenance. All these studies have a common
objective – to contain software maintenance costs by identifying factors driving maintenance
effort, cost, performance and productivity.9 Among the variables found to affect the
maintenance effort are the maintenance category (Abran et al., 1993; Jørgensen, 1995; Lientz
et al., 1980; Niessink et al., 1998), the task complexity (Jørgensen, 1995), business system (in
terms of volatility of the system’s functionality) (Kemerer et al., 1997a), the maintenance
option (the types of changes made to the software) (Jørgensen, 1995; Niessink et al., 1998),
the application software complexity10 (Banker et al., 1993; Banker et al., 1989; Banker et al.,
1998; Gibson et al., 1989; Slaughter et al., 1996), the system’s size (Banker et al., 1993;
Banker et al., 1998; Kemerer et al., 1997a), system age (Lientz et al., 1980; Martin et al.,
1983), quality of the (original) software code (Lientz et al., 1980), the amount of maintenance
9 The existing literature (see (Banker, 1987; Banker, 1991; Banker, 1994) on software maintenance productivity conceptualizes software maintenance as a production process model, where inputs are labor hours and outputs are function points and source lines of code (SLOC) of the resulting maintenance product. By using the function points counting rules proposed by Albrecht et al. (1983), the size of the modified software functionality is measured; this involves counting the number of function points added, deleted or changed by the maintenance project. Added, changed or deleted SLOC are counted based on the rules reported by Jones (1986). A non-parametric methodology known as Data Envelopment Analysis (DEA) that employs the linear programming technique estimates the functional relationship between maintenance inputs and outputs – called the DEA efficiency score. Factors that are found to affect software maintenance productivity from these studies are project size, personnel capability, personnel application experience, personnel data processing experience, deadline pressure, volatility of the software and hardware environment, structured analysis and programming methodology, quality of documentation, response time of the system, quality of the output/product, and so forth. As software maintenance productivity is a function of labor hours (input), function point and SLOC of the resulting product (output), these factors are potential candidates affecting maintenance effort. These researchers believe that the amount of input is somehow dependent on the amount of output and on other environmental variables and so forth. However, this thesis focuses on the factors affecting the amount of input (effort – in man-hours). Thus, neither here nor in the effort sub-study (in Chapter 5) is there any attempt to make reference to the maintenance productivity literature. 10 Previous studies on software complexity are from the psychological perspective. Software maintenance is conceptualized as a cognitive, human information-processing task in which input informational clues (maintenance problems, application functionality, application-specific knowledge and programming knowledge) are processed, interpreted and manipulated to create outcomes (i.e. source line of code, program procedures). While some researchers measure software complexity in terms of data density/component complexity, decision density and decision volatility (see (Slaughter et al., 1996)), some use coordinative complexity and dynamic complexity (see (Banker et al., 1998)). Data density refers to the number of data elements embedded in each procedural line of software code, decision density relates to the extent of decision branching/path between modules. Decision volatility describes the number of decision paths that are dynamically altered at software execution time ((Slaughter et al., 1996), page 198). Component complexity refers to the number of distinct information cues that must be processed in the performance of a task, whereas coordinative complexity defines the form, strength and interdependencies of the relationships between the information cues. Dynamic complexity is related to changes in the relationships between information clues over time during task performance ((Banker et al., 1998), page 435).
2-37
done (Gode et al., 1990), number of maintenance requests (Dekleva, 1992), software code
structure and quality deterioration (Lehman et al., 1980; Lehman et al., 1976), the volatility of
the user environment (Banker et al., 1987; Chan et al., 1994), and the human capital
(programming, application and domain knowledge) of the programmer (Chan et al., 1996).
Note that in this study, the author is interested, in particular, in the characteristics of the
maintenance project that may affect maintenance effort such as maintenance category (request
type), task complexity/size, and maintenance option (or tailoring).
Maintenance category (request type) – A survey, conducted by Lientz et al. (1980), of
computer application software maintenance in 487 data processing organizations in the United
States and Canada, with participants who were employed in Director/Manager/Supervisor of
data processing roles, found that more than 50% of the annual maintenance effort is devoted
to perfective11 maintenance. Abran et al. (1993) report that perfective maintenance, in a large
Canadian financial institution investigated, consumed 32-49% (on average 41%) of total
maintenance effort. In their study, other maintenance request types such as corrective12,
adaptive13 and user support14 are found to expend 26-34% (on average 30%), 4-12% (on
average 8%) and 21-22% (on average 22%) respectively of the total maintenance effort (page
80). Another research project implemented by Jørgensen (1995), in a large Norwegian
organization also found that a large portion, i.e. 45%, of total maintenance effort is spent on
perfective maintenance. Only a very small percentage 9% of the total maintenance effort is
devoted to corrective maintenance. Preliminary findings published from a separate study by
Niessink et al. (1998) conducted in the IT Department of two large Dutch organizations,
indicate that maintenance category is mentioned by these organizations as a driver of
maintenance costs. The only hypothesis testing on the maintenance request type variable is
given by Jørgensen (1995). He finds that, by using the t-test, a significant difference in mean
values exists between: (1) corrective and adaptive, and (2) corrective and perfective. But, no
significant difference in mean values is discovered between adaptive and perfective.
11 According to Lientz et al. (1980), perfective maintenance is related to activities meant to improve the cost effectiveness of the program, to better serve the system users’ needs and user enhancements. (The figure – 50% – is obtained by summing 41.8% + 5.5% + 4.0% (page 73).) 12 Corrective maintenance defined in Abran et al.’s (1993) study follow the definition given by Swanson (1976). Corrective is changes to correct program failures, performance failure and implementation failures. 13 Note that the term – adaptive maintenance in Abran et al.’s study refers to perfective maintenance as originally defined by Swanson (1976). On the other hand, perfective maintenance in Abran et al.’s study refers to adaptive maintenance as originally defined by Swanson (1976). 14 User support as per definition by Abran et al. (1993) is request related to information on the software components only.
2-38
Task complexity – It is noted that much of the early research on maintenance complexity
issues is focused on the application software complexity (Banker et al., 1993; Banker et al.,
1989; Banker et al., 1998; Gibson et al., 1989; Slaughter et al., 1996). This stream of literature
believes that the cognitive load/amount of information cues, static and dynamic relationships
among the information which a programmer needs to comprehend and digest along the path to
providing resolution for a maintenance request determines the complexity of the maintenance
job. Little attention is given to the task complexity/size/difficulty of the project. The principal
finding in this area is the work published by Jørgensen (1995). In the study, Jørgensen
interviews the maintainers and asks their perception of the complexity of the project
(immediately after the maintenance project was finished) based on a response scale of high,
medium and low. With a total of 109 maintenance projects, 12% were considered by the
respective maintainers to have a high complexity. Although the percentage is relative small,
the time spent on high complexity projects represents 25% of the total maintenance effort. In
spite of this, no regression analysis is conducted to prove whether task complexity is a good
predictor of maintenance effort.
Maintenance/tailoring option – Maintenance option refers to the types of changes done to
the software (e.g. the code) due to a maintenance project. According to Jørgensen (1995),
there is no standard categorization for the maintenance changes. The five categories of
maintenance changes used in Jørgensen’s study are: introduction/deletion of module (e.g.
introduction of procedures, functions and subroutines); change of interface (e.g. change of
calls to another software module, file system, screen, user input, printer or operating systems);
change of data declaration, change of control flow (for example, change of IF statement); and
change of data (for instance, change of data assigned to a variable, or data stored in
file/database). It is found that 22% of the total maintenance projects, in which (one of) the
major type of changes to the software is involved in the introduction/deletion of module,
consume 40% of total maintenance effort. On the other hand, a separate study conducted by
Niessink et al. (1998), finds the category of new code, i.e. the number and size of new files,
programs and modules, to be an influential variable and increases the explained variance for
total maintenance effort.
2-39
2.5.4 In-house Software Replacement Model
Maintenance costs increase as the useful life of software products increases (McKee, 1984).
In order to control and reduce ever-increasing software maintenance costs, the old software
system needs to be replaced (Lientz et al., 1980). Software systems are replaced for economic
reasons (Norman, 1987).15 Gupta et al. (1988) state that software replacement is necessary
when an information system becomes less effective after repetitive maintenance, is costly to
maintain, results in a loss of competitive advantage and is risky because of dependence on a
handful of technical specialists. Additions to the lists are changes made (to the system) those
are not fully documented and naming conventions not being strictly followed. Studies of the
economics of in-house software maintenance conducted by Gode et al. (1990), and Chan et al.
(1996) suggest that there may be an optimal time to replace the existing code by rewriting the
software system.
There are three papers on in-house software rewriting. These models are useful to understand
the factors and relationship among factors that affect software maintenance cost and
replacement decision. The first paper was published in 1988 by Gupta et al. (1988). The
proposed model is developed based on reliability theory. They develop the first mathematical
model for determining the optimal replacement time of an information system with
alternatives of modifying an existing system or replacement with a new one. The main idea in
this model is to find the trade-off between the estimated maintenance cost of the existing
system and the replacement cost of the system. In order to use the model, data on the system
replacement cost, maintenance cost per unit time, and time when the maintenance request(s)
arrived are required.
15 While many researchers on software replacement decision argue that software is retired for economic reasons (Lientz et al., 1980; Norman, 1987; Gupta et al., 1988; Gode et al., 1990; Chan et al., 1996), author such as Glass in (Glass, 1991; Glass, 2002; Glass, 2003) has different view saying that business functionality is the primary reason for this decision. The author believes that these two schools of thoughts are inter-related and compliment one another at different stages of software lifecycle. At the early stage of software lifecycle and software code is still fresh and flexible for changes, maintenance cost can be mainly driven by the business requirements (provided there are any and they can be counted by the number of enhancement requests). However, when the software reaches its final stage where “the product has been pushed through accumulated change to the ragged edge of its design envelope” (pg. 112, (Glass, 2002)), software becomes more complex and lengthy to incorporate new business requirements, the maintenance cost would be most likely driven by deteriorating software code structuredness, quality and complexity. Software replacement point is when it becomes difficult (if not impossible) to incorporate business requirements and not economic to continue maintaining the software. Several potential explanations for not (explicitly) considering business needs in prior software replacement models are: (1) they assume that business requirement is one of the main factors contributing to the economic reason, (2) they assume that all business requirements can be met, (3) they put emphasis on the technical aspects such as software code size, maintainability, quality, and complexity in their mathematical/economic models, (4) they focus on the final stage of software lifecycle, and (5) business needs are not always clear (to the users), fixed over time or tangible/quantifiable, thus, it is not easy to determine or incorporate this factor. (This factor is considered and incorporated in the ERP decision framework given in Chapter 6.)
2-40
Gode et al. (Gode et al., 1990) argue that as frequency of maintenance modification increases,
software complexity will also increase. Consequently, more maintenance time is required for
the subsequent maintenance due to the deterioration of code, and thus leads to cost increases.
The authors suggest that software rewrite will reduce the software complexity, and can
therefore reduce maintenance costs per request. They propose an economic model to
determine the optimal rewriting point(s) over a finite planning time. The in-house software
factors considered in this model are the impact of system size, structuredness of the
underlying software technology and the availability of superior technologies on the rewriting
time(s) and total lifecycle costs. Assumptions made in this model are that superior technology
results in more structured systems and is expected to reduce the maintenance cost; no a priori
assumptions are made with respect to the initial acquisition and learning costs resulting from
switching to superior technologies; and software replacement could take place
instantaneously.
In the most recent research, Chan et al. (1996) propose a new economic model to justify the
optimal timing to rewrite and replace aged software. Their model is an extension of Gode et
al’s model; they relax the assumption of instantaneous replacement by considering an
extended software rewrite period. In addition, their model also incorporates the factors of the
volatility of user environment (determined by the number of maintenance requests), system
maintainability/structuredness of the new system, and productivity of the maintenance team.
They model the software maintainability as a function of software functionality complexity
(in terms of function points) and quality. The proposed model states that the total cumulative
effort of rewriting and replacing in-house software is the sum of cumulative effort in
maintaining the existing software system (from the time it starts operating until it is replaced),
cumulative effort in maintaining the new system (from the time rewriting begins until the end
of the planning time horizon), and the rewriting efforts. The optimization policy is to
minimize the rewriting period, the period where duplicate efforts in maintaining the existing
and new systems occur. It assumes a single application in the model. Like the earlier two
models, it is a deterministic model.
2.5.5 Standard Software Maintenance Methodology
In order to provide guidelines to practitioners in defining, managing, organizing and
implementing maintenance activities, a software maintenance methodology is required. A
2-41
maintenance methodology/model/process is used to reflect and capture the essence of an
organization’s software maintenance process (Pigoski, 1997). It helps to define the
maintenance activities, and improves maintenance processes (IEEE, 1998b; ISO/IEC, 1995).
Therefore, maintenance methodology is used to plan and manage maintenance, and as a guide
to modify the software, and help to reduce the effort and cost of maintenance.
2.5.5.1 IEEE Standard 1219-1998 and ISO/IEC 12207 A review of the literature reveals two well-recognized, standards for software maintenance
methodology. The first, the IEEE Standard for Software Maintenance (IEEE Standard 1219-
1998), from the Institute of Electrical and Electronics Engineers (IEEE), is a revision of IEEE
Standard 1219-1992 (1998b). (The last four digits of the standard number represent the year
of IEEE Standards Association (IEEE-SA) Standards Board approval.) The IEEE standard is
recognized by the American National Standards Institute (ANSI). This standard is highly
regarded, and is intended for a wide ranging audience including software development
managers, maintainers, software quality assurance personnel, software configuration
management personnel, programmers, and researchers. This standard states that there are
seven phases involved in the in-house software maintenance methodology: (1)
problem/modification identification, classification and prioritization; (2) analysis; (3) design;
(4) implementation; (5) regression/system testing; (6) acceptance testing; and (7) delivery.
The second is from the International Organization for Standardization and International
Electrotechnical Commission (ISO/IEC), named Information Technology – Software Life
Cycle Processes (ISO/IEC 12207). ISO/IEC 12207 is a standard for software life cycle
processes, covering acquisition, supply, development, operation and maintenance processes
(ISO/IEC, 1995). ISO was established in 1947, and is a worldwide federation of national
standards bodies. Each of the participating countries is represented by a single national
standards body. The objective of ISO is to promote the development of international standards
in order to facilitate exchange of goods and services (see (ISO, 2002)), e.g. in technological
activity – like software maintenance. ISO has a strong collaboration with IEC, whose scope of
activities complements ISO’s, on all activities and matters of electrotechnical standardization.
Besides the two national bodies of ISO and IEC, other international organizations, as well as
governmental and non-governmental organizations, participated in the development of the
ISO/IEC 12207. It was prepared by Joint Technical Committee ISO/IEC JTC1, Information
2-42
Technology, Subcommittee SC7, Software Engineering (ISO/IEC, 1995). In the current study
context, discussion on ISO/IEC 12207 is focused on the maintenance process only. It lists six
main activities in the in-house software maintenance methodology, namely: (1) process
implementation; (2) problem and modification analysis; (3) modification implementation; (4)
maintenance review and acceptance; (5) migration; and (6) software retirement.
In the following Section 2.5.5.2, IEEE standard 1219-1998 and ISO/IEC 12207 are analyzed
and compared in order to identify their strengths and the distinctions between them.
2.5.5.2 IEEE Standard 1219-1998 Versus ISO/IEC 12207 The IEEE Standard 1219-1998 defines a software maintenance methodology based on the old
definition of software maintenance (as in (IEEE, 1993)), and mainly emphasizes the activities
after software delivery. Both software pre-delivery and software retirement activities are
discussed as appendices to the standard. In contrast, the ISO/IEC 12207 views software
maintenance more broadly, to also comprise pre-delivery activities and software retirement.
Comparatively, IEEE Standard 1219-1998 (basic process model) includes input, process,
output and control for software maintenance; and focuses more on the measures/metrics of
maintenance effort, determinants of maintenance effort, error rates, and projecting future
maintenance needs. On the other hand, the ISO/IEC 12207 basic process model involves only
the process for software maintenance. (A detailed comparison of clauses and sub-clauses
between IEEE 1219-1998 and ISO/IEC 12207 is given in Appendix B.)
2.5.5.3 IEEE/EIA 12207.2-1997 In 1995, the Software Engineering Standards Committee (SESC) of the IEEE Computer
Society, having endorsed the policy of adopting international standards, decided to adopt
ISO/IEC 12207 and use it as a basis for life cycle processes within the IEEE Software
Engineering Collection (IEEE/EIA, 1997). One of the outcomes of the IEEE and Electronic
Industries Association (EIA) adaptation of ISO/IEC 12207 is the IEEE/EIA Guide for
Information Technology – Software Life Cycle Processes – Implementation Considerations
(IEEE/EIA 12207.2-1997). This is illustrated in Figure 2.1.
2-43
Figure 2.1: Standards referenced
The following discussion of an in-house software maintenance methodology is focused on
IEEE/EIA 12207.2-1997 (IEEE/EIA, 1997). The primary reason for choosing IEEE/EIA
12207.2-1997 (instead of selecting IEEE Standard 1219-1998 or ISO/IEC 12207) is that it
includes pre-delivery activities and software retirement (i.e. the ISO/IEC 12207
characteristics), as well as quantification factors and metrics for the measurable maintenance
attributes (e.g. maintenance effort, replacement policy, and so forth). The latter is generally
the strength of IEEE standards.
2.5.5.4 Maintenance Activities Included In IEEE/EIA 12207.2-1997 Basically, IEEE/EIA 12207.2-1997 uses the same activity-names as in ISO/IEC 12207, see
(IEEE/EIA, 1997). As mentioned above, the first activity in the maintenance methodology is
called ‘process implementation’, which covers most of the maintenance preparation and
initialization tasks. These include developing plans for conducting maintenance activities,
outlining workflow of a maintenance request from its arrival to its implementation and
delivery, defining a maintenance organization, and describing the arrangement for resource
allocations and performance tracking. A formal statement of anticipated future maintenance
requirements is incorporated (e.g. expected external regulatory changes, expected internal
2-44
adaptations to new user requirements, new system functionality and technologies, future
business expansion and new lines of business that need to be supported). Additionally, factors
influencing maintenance effort are identified and are used for estimating and quantifying
maintenance effort.
Other tasks considered are establishing controls, rules and methods to record and track
maintenance requests (e.g., a numbering scheme to identify each request uniquely);
classifying maintenance requests (using suitable maintenance taxonomy); prioritizing and
assigning requests (based on some predefined criteria); and setting up a charge-back system
for sending quotations for maintenance requested by system users. A software configuration
management (SCM) process for managing modifications to the existing system is also
established and implemented in the first activity in this standard. According to the IEEE
Standard for Software Configuration Management Plans, that is IEEE Standard 828-1998
(1998a), this would cover items such as:
• Configuration identification – to identify and name the documented physical and
functional characteristics of the code, specifications, design, data elements,
documentation, user manual, test plans, programming tools and so on to be controlled,
and describe how the items and structures are to be maintained.
• Configuration control – to detail each configuration control board (CCB) and its level
of authority for approving proposed changes, and list the activities for verifying and
implementing an approved change, coordinating multiple changes, reconfiguring the
controlled items and determining a new baseline.
• Configuration status accounting – to define types of status accounting reports to be
generated, information to be collected, stored and retrieved.
• Configuration audits and review – to describe procedures for the audit, participants
involved, documentation required for review, procedure for recording any
deficiencies, corrective actions, approval criteria and actions to occur upon approval
• Interface control – to distinguish the external items with which the project software (or
controlled item) interfaces and how the interfaces’ coding, documentation and data are
to be controlled.
• Vendor control – to describe how the software will be received, tested, and placed
under SCM, how changes to the supplier's software are to be processed and how the
supplier will participate in the project's change management process.
2-45
The second activity is problem and modification analysis, third – modification
implementation, and fourth – maintenance review and acceptance. These activities are
repetitive activities which would be triggered each time a new request arrives. However, in
cases where inter-related maintenance requests are batched, the third and fourth activities
could be done once only for each of the activities. Note that the second activity – problem and
modification analysis – provides guidelines for identifying, classifying, and analyzing a
maintenance request. The main tasks involved are as follows:
• Assign id to the request and classify maintenance request.
• Determine the criticality and priority of the request.
• Replicate or verify the problem and analyze the impact of the problem report or the
modification request on the organization, existing system and interfacing system.
• Determine whether to accept the request.
• Identify alternative solution, and conduct analysis of conversion requirements, safety
and security implications (including understanding the existing code).
• Conduct preliminary estimation for the modification’s size, scope, short-term and
long-term costs, value of the benefit of undertaking the maintenance and time to
modify the request.
• Document the request, analysis results, and implementation options.
• Obtain approval for the selected modification option.
• Carry out a detailed analysis – that is, define firm requirement(s) for the modification,
identify the element to be modified, safety and security issues, devise a test strategy,
and develop an implementation plan and schedule for implementation.
After a request has been approved and detailed requirement and modification analysis has
been conducted, modification implementation of the request will be carried out. IEEE/EIA
12207.2-1997 suggests that the fundamental tasks to be covered in the modification
implementation activity are:
• Identifying the affected module.
• Modifying software module documentation.
• Creating test cases for the new design, safety and security issues, and regression test.
• Detailing documentation to be updated, and updating modification list.
• Defining and documenting the criteria for testing and evaluating the modified and
unmodified parts of the system.
2-46
• Coding, conducting unit testing, and integrating the modified software with the
system.
• Conducting regression tests – to ensure and revalidate the complete and correct
implementation of the new and modified requirements; that unmodified requirements
were not affected and system functional integrity and stability of the unchanged
software parts remain intact, and to identify any unacceptable impacts.
• Carrying out risk analysis – detect software defects, which can cause software failure
and quantify the potential loss due to failure.
• Implementing a test-readiness review to assess preparedness for a system test.
Once the modification has been completed and is ready for testing, the maintenance
(modification) will be reviewed and tested for user acceptance. Major tasks expected to occur
in the maintenance review and acceptance activity (see (IEEE/EIA, 1997)) are conducting:
• Review(s) with the modification authorizer’s organization to determine the integrity of
the modified system.
• System functional test.
• Interface test.
• Regression test.
• Acceptance tests at the functional level.
• Interoperability testing.
• Functional configuration audit (FCA) to affirm that the software product satisfies the
functional requirement stipulated in the request, and physical configuration audit
(PCA) to assure that all software, hardware and documentation have been delivered.
• Notification to the user community of the product delivery schedule.
• An archival version of the system for backup.
• Installation and training at customer site.
In a situation when a software product is to be migrated from an old to a new operational
environment, IEEE/EIA 12207.2-1997 proposes an activity called migration – the fifth
activity described in the maintenance process in the standard (IEEE/EIA, 1997). The primary
tasks under this activity are as follows:
• Develop, document, and execute a migration plan (which includes requirement
analysis and definition of migration, development of migration tools, conversion of
2-47
software product and data, migration execution, migration verification, and support for
the old environment in the future).
• Notify users of the migration plans (i.e. reasons for not supporting the old
environment, description of the new environment and its availability, and other
support options (if any) once the old environment support has been removed).
• May conduct parallel operations in the old and new environments, and provide the
necessary training.
• Notify the relevant parties of the migration schedule.
• Conduct a post-operation review to assess the impact of changing to the new
environment, and send the result of the review to the appropriate authorities for
information, guidance and action.
• Archive the data, documentation, logs and code used by or associated with the old
environment.
After some time in service, a software product would be retired (based upon a request from
the owner). This is usually when the software product can no longer meet the changes in the
system users’ requirements or a new operating environment, and/or the software product has
reached its limit of maintainability – i.e. become too difficult and not economic to maintain.
According the Swanson (1999), a maintainable system is economical to maintain provided it
has the characteristics of extensibility, usability, integrity, comparability, stability, simplicity
and/or familiarity. ‘Software replacement’ will ensue when the maintainability limit is
reached. IEEE/EIA (1997) reports that the primary tasks included in this activity are similar to
those of the migration activity and involve the following:
• Develop a software replacement policy by taking into consideration the replacement
drivers.
• Develop a retirement plan (that includes cessation of full or partial support after a
certain period of time, archival for software product and its associated documentation,
responsibility for any future residual support issues, transition to new software
product, and accessibility of archive copies of data).
• Notify users of the retirement plans and activities (e.g. description of the replacement
or upgrade with its date of availability, statement of why the software is no longer
supported, description of other support options (if any), once support has been
removed).
2-48
• Parallel operation of the retiring and new software product, and providing user
training.
• Notify those involved in the retirement schedule.
• Archive the data, documentation, logs and code used or associated with the retired
software product.
The result of reviewing the maintenance methodology in IEEE/EIA 12207.2-1997 Guide for
Information Technology - Software life cycle processes - Implementation considerations
(IEEE/EIA, 1997) suggests that it is comprehensive, well documented, and generic and could
be well-suited for most organizations.
2.5.6 SEI Maintenance-data-model
Central to the maintenance methodology is a maintenance-data-model for capturing
fundamental details and defining the measurable attributes and characteristics of a
maintenance request, from the first maintenance request until the software system is retired
from production.
From the literature, it is found that the Software Engineering Institute (SEI) proposes a
maintenance-data-model, called Software Quality Measurement: A Framework for Counting
Problems and Defects (Florac, 1992) for capturing measurable maintenance attributes. SEI is
a federally funded research and development center operated by Carnegie Melon University
and sponsored by the U.S. Department of Defense. The proposed maintenance-data-model
emphasizes maintenance attributes collection after software delivery stage. It is recognized by
software professionals from the industry, academia, and government who have participated in
its development. It has also been used in prior study. For example, Kajko-Mattsson (1998)
validated the SEI data-model using three European industrial maintenance systems. The SEI
data-model proposed by Florac (1992) defines measurable attributes common to software
problem and defect counting. Although little has been reported on the use of the SEI data-
model in the practice in the literature, the success stories about using measurement framework
or program to improve product quality have been published based on Motorola (Smith, 1997)
and AT&T (Fenton et al., 1997), and to improve software maintenance process based on
Burrough Corporation (Rombach et al., 1989) success. Florac suggests twenty attributes in
this data-model (see Table 2.14).
2-49
Table 2.14: Maintenance request’s attributes in SEI maintenance-data-model
Attribute name Attribute measurement meaning* 1. Identification (Problem
ID, and Product ID)
What software product or software work product is involved?
2. Finding Activity What activity discovered the problem or defect?
3. Finding Mode How was the problem or defect found?
4. Criticality How critical or severe is the problem or defect?
5. Problem Status What work needs to be done to dispose of the problem?
6. Problem Type What is the nature of the problem? If a defect, what kind?
7. Uniqueness What is the similarity to previous problems or defects?
8. Urgency What urgency or priority has been assigned?
9. Environment Where was the problem discovered?
10. Date/time of Occurrence When was it discovered?
11. Problem Status Dates When was the problem reported? When the problem changed
status?
12. Originator Who reported the problem?
13. Defects Found In What software artifacts caused or contain the defect?
14. Changes Made To What software artifacts were changed to correct the defect?
15. Related Changes What are the prerequisite changes?
16. Projected Availability When are changes expected?
17. Released/Shipped When the fix is released or shipped?
18. Applied When was the change applied to the problem-originating site?
19. Approved By Who approved the resolution of the problem?
20. Accepted By Who accepted the problem resolution?
*Source: Florac (1992), pp. 11-12.
Florac believes that the data-model is an integrated and systematic method for discovery,
reporting, and consistent data measurement of software problems. Measurements have direct
application to estimating, planning, and tracking various software maintenance processes.
Consistent data measurements provide data for: quantitatively expressing requirements, goals,
and acceptance criteria; monitoring progress and anticipating problems; quantifying trade-offs
used in allocating resources; and predicting the software attributes for effort and cost.
Thus, a maintenance-data-model would improve the maintenance methodology/process and
software life cycle process in general, and among others help organization to better control
software costs.
2-50
2.6 Recap – In-House Software Literature
Overall, comprehensive studies, particularly in maintenance taxonomy, replacement models
and maintenance methodology, have been conducted in the in-house software. There are a
number of published studies on software maintenance effort but most do not directly focus on
effort determinants and effort predictor models (for example (Banker et al., 1991; Banker et
al., 1993; Banker et al., 1989; Banker et al., 1998; Banker et al., 1987; Banker et al., 1994;
Kemerer et al., 1997a; Kemerer et al., 1997b; Lientz et al., 1980; Slaughter et al., 1996;
Swanson, 1999; Swanson et al., 1989)). However, this literature does provide indications of
factors influencing in-house software maintenance effort. A review of the SEI publication
website (www.sei.cmu.edu) shows that a maintenance-data-model defining the measurable
attributes of a maintenance request is available. To the knowledge of the author, there is still
lack of studies of maintenance-data-models for software pre-delivery activity and software
retirement activity. Table 2.15 summarizes the literature review of in-house software
maintenance in the five research areas covered in this thesis.
Table 2.15: Recap - In-house software maintenance literature
Topic of interest to this thesis
In-house literature
Maintenance
taxonomy
Classic – based on objective (Swanson, 1976).
Recent – based on evidence of activities (Chapin et al., 2001).
Effort determinants Maintenance category
• (Jørgensen, 1995): By using the t-test, a significant difference in mean
values exists between: (1) corrective and adaptive, and (2) corrective
and perfective. But, no significant difference in mean values is
discovered between adaptive and perfective.
Task complexity/size
• (Jørgensen, 1995): A relatively larger portion of maintenance effort is
required for a group of high complexity projects than the low
complexity projects.
Maintenance/tailoring option
• (Niessink et al., 1998): Introduction/deletion of module consumes 40%
of total maintenance effort; the category of new code (i.e. the number
and size of new files, programs and modules) is found to be an
influential variable and increases the explained variance for total
maintenance effort.
2-51
Topic of interest to this thesis
In-house literature
Replacement model • (Gupta et al., 1988): Decision alternatives are modifying an existing
system and replacement with a new one; trade-off considered is
between the subsequent estimated maintenance cost of an existing
system and the replacement cost of the system.
• (Gode et al., 1990): Optimal rewriting point(s) are over a finite
planning time; factors incorporated are the impact of system size and
structuredness of the underlying software technology; assumptions
made are that superior technology results in more structured systems
and is expected to reduce the maintenance cost, and that software
replacement can take place instantaneously.
• (Chan et al., 1996): Examine the optimal timing to rewrite software;
relax the assumption of instantaneous replacement by considering an
extended software rewrite period; factors considered are volatility of
user environment (determined by the number of maintenance
requests), system maintainability and structuredness of the new
system, and productivity of the maintenance team.
Maintenance
methodology • (IEEE/EIA, 1997): The maintenance methodology consists of six
primary activities – (1) process implementation, (2) problem and
modification analysis, (3) modification implementation, (4)
maintenance review and acceptance, (5) migration, and (6) software
replacement.
Maintenance-data-
model • (Florac, 1992): Measurable attributes of a maintenance request.
2.7 Contrast of ERP and In-house Software Characteristics
With the objectives of identifying whether existing in-house software literature on
maintenance taxonomy, maintenance effort determinants, software replacement models,
maintenance methodology, and maintenance-data-models are sufficient in the context of ERP,
the general characteristics of ERP and in-house software are compared along the software
lifecycle phases, i.e. from selection through replacement.
2-52
System selection and acquisition method – Selection of an ERP system is found to involve
not only choosing the software system (i.e. software functionality, and its technological
environment) that fits an organization’s business processes or requirements, but also selecting
a vendor who is reliable and stable, with a reasonable installed base of customers and a good
record of customer service and ongoing maintenance support (Jakovljevic, 2000a; Wilson,
1999). Conversely, no such effort (or system selection stage) is required for in-house
software. Indeed, custom development involves system specification, physical system design,
architecture, interface, database and files design. At the acquisition stage, ERP is considered
relatively easier to acquire (i.e. bought off-the-shelf) than in-house software (i.e. involves
software development). For ‘vanilla’ (as-is) implementations of ERP (and packaged software
generally), little if any system analysis, design or coding are required (Davis, 1988).
However, like packaged software in general, ERP is a generic enterprise solution, often
requiring customization and (some) unavoidable modifications. Alternatively, organizations
may accept some degree of misfit (Martin et al., 2002; Soh et al., 2000; Stedman, 2000), and
adapt their business processes or operations to the software (Bingi et al., 1999; Davenport,
1999; Glover et al., 1999; Greenbaum, 1996; Hecht, 1997). In-house software, on the other
hand, is tailor-made and developed based on the organization-specific structures, culture and
business processes (Brehm et al., 2001).
Deployment method and level of decision support – Five main benefits (motivations)
sought from ERP implementation are competitive advantage (Deloitte-Touche-Tohmatsu,
1999b; Heald et al., 1999; Irani et al., 2001; Shang et al., 2000; Travis, 1999; Weston et al.,
1998); globalization (Freedman, 1999; Gable, 1998; Holland et al., 1998; Vernadat, 1996);
integrated system (Davenport, 1999; Jakovljevic, 2000c; Markus, 2001); best business
processes/practices (Bingi et al., 1999; Carlino et al., 1999b; Deloitte-Touche-Tohmatsu,
1999a; Deloitte-Touche-Tohmatsu, 1999b; Jakovljevic, 2000a; Markus, 2000; Sieber et al.,
1999); and cost reduction (Butler, 1999; Carlino et al., 1999a; Hicks et al., 1995; Markus,
2001; Norris et al., 2000; Shanks et al., 2000; Stein, 1999b). These have been key motivations
for the rapid deployment of ERP over the past ten years (Jakovljevic, 2000b), and are based
on the business perspective (Markus et al., 1999). The characteristics of ERP that contribute
to those five benefit categories are a fully integrated business management application, a real-
time system and a centralized database system. These facilitate data warehousing and
complete data visibility for all levels of organizational management, and corporate and
strategic decision-making (Gray, 1998a; Hicks et al., 1995; Ross et al., 2000).
2-53
In contrast, in the past, some traditional in-house software development focused more on
technical aspects such as programming and advanced software engineering techniques
(Gibson et al., 1999). (This does not mean that in-house software does not (or will not
possibly) bring competitive advantage at all to user-organizations.) Although benefits are
considered in the feasibility study during the in-house software development, they are
primarily meant to get expenditure approval. Once the expenditure is approval, little further
attention is paid to benefits, and most effort is expended on technical implementation (Ward
et al., 1999). In some cases, technology was utilized to speed up existing processes but the
performance deficiencies of these processes were not addressed (Hammer et al., 1996). Some
organizations use technology (i.e. the system) as administrators’ tool to establish control
(Dhillon, 2000) as opposed to delivering benefits. Most of these in-house applications are
designed to support an individual operational or tactical area. Hence, integration among these
individual applications and business processes is not only loosely coupled but also prohibits
and complicates centralized decision making processes.
Implementation staff – Implementation of a large ERP system requires not only substantial
time and effort, but also a wide range of expertise and knowledge (besides knowledge of
existing business processes) of the functional aspects of the package, system configuration
and system integration, technical knowledge of the related hardware and software, project
management and change management, managing knowledge transfer, and organizing system
users’ training. ERP-adopting organizations typically lack this expertise and usually outsource
these activities to the ERP vendor, hardware vendor, and consulting firms (Holland et al.,
1998; Simon, 1997; Sumner, 1999). Implementing in-house software may not demand such a
wide range of expertise, as the software is usually constrained to the expertise and knowledge
of the in-house system developers and system users. Also, while having a balanced project
team with both internal business people and IT staff is crucial for ERP implementation
projects (Shanks et al., 2000), traditional in-house software has been largely IT driven except
during requirement determination (at the beginning) and user testing and system acceptance
(at the end) of software development lifecycle.
Implementation success factors – In addition to commonly understood critical success
factors (CSFs) such as obtaining and maintaining top management support (Bingi et al., 1999;
Sumner, 1999), well-defined implementation scope, and project goal management (Clemons,
2-54
1998)), two of the most important CSFs in ERP implementation are: (1) choosing the right
business processes (Ross et al., 2000); and (2) ensuring minimal customization and system
modification (Davis, 1998; Martin et al., 2002). In contrast, the latter two factors are less
pivotal for in-house software.
Maintenance originator, activities and motivation – In the maintenance phase, there are
several obvious differences between ERP and in-house applications. While ERP change-
requests may come from either the software vendor or system users and IT-staff (these are
discussed in detail in Chapter 4), in-house software maintenance requests generally originate
internally (i.e. system users and IT-staff) only. With ERP, maintenance support for bug fixes
(Songini, 2000) and regular functionality enhancements (Gray, 1998b; Stein, 1999a) are
available from the ERP vendor. Although this support may not cover all (internal) user
maintenance requests, it distinguishes ERP from in-house software that must be fully
supported internally. Traditionally, the process of in-house software maintenance involves
maintenance problem area analysis (including identification of the causes, solutions, and
trade-offs among different solutions), designing the modifications, writing and implementing
modifications, system and user acceptance testing, and final delivery of the changes into
production (IEEE, 1998b). With ERP, neither system design nor coding is required if the
maintenance originates from the vendor. However, extensive impact analysis may be required
for implementing patches introduced by the vendor, in order to determine whether re-
application of prior modifications is needed. These must be re-tested and re-verified to ensure
that the system is working properly following the patch. Finally, the changes are transported
to the production environment (Collins, 1999). The primary motivation for ERP enhancement
maintenance is to realize more business benefits. In contrast, in-house software system
enhancement has mainly focused on: (1) cost effectiveness of the programs (see (Swanson,
1976)), for instance improving software code quality, maintainability and enhancing software
performance; (2) providing new reports and adding data to existing reports (Lientz et al.,
1980); and (3) improving quality of documentation (Lientz et al., 1978). It is more focused on
the act of doing maintenance rather than business benefits.
Impact on other application modules and drivers of maintenance complexity – ERP is
comprised of tightly integrated application modules. Given its breadth and integration, it is
argued that each change to ERP can cause more extensive ripple effects and impacts on its
existing code (or other integrated application modules) than typical standalone in-house
2-55
application software. On the other hand, if maintenance patches supplied by the vendor have
been thoroughly tested prior to release to clients, user organizations should be largely shielded
from these ripple effects (our experience in the case study suggests that this is not always the
case; this is an interesting area of further research). The complexity of in-house software
maintenance is reported to be a function of the system’s size (Banker et al., 1993; Banker et
al., 1998; Kemerer et al., 1997a) and system’s age (Banker et al., 1989; Lientz et al., 1980;
Martin et al., 1983), quality of the original system (Krogstie et al., 1994), initial planned
functionality (i.e. its design envelope) of the original system (Glass, 2002; Glass, 2003), the
amount of maintenance done previously (Gode et al., 1990; Swanson et al., 1989), and
software development practices (such as the use of a code generator and structured
techniques) (Slaughter et al., 1996). While these may also be the drivers of ERP maintenance
complexity for the vendor, the complexity of ERP maintenance for the client organization
(when implementing the vendor’s patches) is largely dependent on the amount of
modification done during initial implementation (400-Group, 1998b) and post-
implementation. This is because the application of patches may cause previous modifications
to be overwritten or to no longer function correctly. As a result, each modification may cause
extra effort in impact analysis, re-configuration, and re-testing.
Drivers of software replacement and disposal method – Software replacement is one of the
activities in software maintenance. In-house software replacement happens only once per
system, however: (1) it involves a lot of planning, mainly on what, how and when a new
system is going to replace the old one, besides analyzing the whole old system’s from
functional and technical aspect; (2) its execution will usually involve a lot of system backup
and documentation of the old system; and (3) it costs a lot of time, money, effort and skills
relatively much more than a change-request in general. In-house software replacement is
driven by increasing deterioration of the code structure and design envelope resulting from
cumulative maintenance over time (Lehman et al., 1980; Lyons, 1981; Swanson et al., 1989;
Glass, 2002; Glass, 2003). As the code structure deteriorates over time, it becomes
increasingly difficult, and requires more effort, to maintain. Thus, maintenance becomes more
costly over time. In light of this, it is argued in the existing literature that over time it becomes
increasingly more economic to replace the old code by rewriting16 the software from scratch
(Chan et al., 1996; Gode et al., 1990; Gupta et al., 1988); that is, when the projected lifecycle
16 This is an extreme case. In practice, this option assumes that all the relevant documentation and people, who are familiar with the system (in relation to what and how the software system functions), are available in an organization (Glass, 1991)
2-56
costs of maintaining the old system are greater than the costs of rewriting or re-engineering
and maintaining a new system. In contrast, the decision to upgrade ERP is usually not driven
by code deterioration or anticipated reduction in maintenance costs alone, but by the desire to:
(1) realize more business benefits from a new version (Davenport, 2000a; Deloitte-Touche-
Tohmatsu, 1999a; Deloitte-Touche-Tohmatsu, 1999b); and (2) avoid vendor support17
termination (Craig, 1999; Stedman, 1999). The ERP-using organization does not have to
develop and re-write the ERP system itself but rather it replaces (or upgrades) the old version
with a readily available new version from the ERP vendor. A summary of differences
between ERP and in-house software is given in Table 2.16.
Table 2.16: Summary of differences between ERP and in-house software
Phase Issue ERP In-house System
selection
Requires detailed selection
process for the right ERP
system from the right vendor.
System is developed internally
and therefore no vendor or
software selection is required.
Acquisition
method
Bought off-the-shelf; there is
some misfit; and most of the
time customization and/or
modification are required.
Tailor-made.
Deployment
purpose
Gain competitive advantage*,
achieve globalization, adopt
best business practices,
benefit from an integrated
system, and outsource
maintenance support.
Speed up business processes,
utilize advanced software
engineering techniques, and
facilitate management support
in each individual functional
area (loose integration among
business processes).
Level of
decision
support
Facilitates top
management/executive
corporate and strategic
decision-making.
Mainly to support lower- and
middle-level management to
carry out operational and
tactical planning and tasks.
Selection,
acquisition, and
implementation
Implementation
staff
Involves outsourcing to the
ERP vendor, hardware
vendor, and consulting firms;
and require a balanced project
team of business and IT staff.
Involves mainly internal (both
IT and system users) staff.
17 Vendors withdraw support for older versions in order to contain and minimize their own maintenance costs, and to guarantee availability of human resources, skills and services support for their clients. Hence, they must focus their maintenance support resources on one or a few version(s). While this is of interest, this thesis focuses on maintenance of ERP from the client perspective.
2-57
Phase Issue ERP In-house Implementation
success factors
Choosing the right business
processes; ensuring minimal
system modification.
Relatively lesser effort is
required to choose business
processes or to conduct
system modifications.
Maintenance
originator
Vendor, and system users and
IT-staff.
System users and IT-staff.
Maintenance
activities
No coding or system design is
required if the request is from
the vendor; may involve
extensive impact analysis,
reconfiguration, re-applying
the previous modifications,
and re-testing the whole
system.
Understand the existing code,
system design, architecture
design, program design,
interface design, database and
files design, coding, and unit
testing.
Maintenance
motivation
Realize more business
benefits: competitive
advantage*, globalization, best
business practices, improved
system integration, cost
reduction*.
Focused on the act of doing
maintenance rather than
business benefits – program
maintainability and
performance, and
documentation quality.
Impact on other
application
modules
Ripple effects across tightly
integrated modules can be
extensive and complex;
however, for patches these
are usually borne by the
vendor in advance of release
of the patch.
Each maintenance task has
relatively lesser impact on the
other application modules.
Maintenance
Drivers of
maintenance
complexity
Amount of previous
modifications or changes
made to the software –
including add-ons/extensions
done during the initial
implementation, and post-
implementation.
System’s age, size, amount of
maintenance done previously,
and the original software
quality, design envelope, and
development practice.
Drivers of
software
replacement
Driven by benefit realization,
and vendor support
termination.
Driven by increasing code
structure deterioration, and
maintenance and rewrite costs.
Replacement**
Disposal
method
Upgrade to readily available
new version from the market.
Rewrite the software from
scratch with fresh code.
2-58
* This does not mean that in-house software does not (or will not possibly) bring competitive advantage or cost reduction at all
to user-organizations.
**The author is not equating ERP upgrade with in-house software replacement/rewrite but to investigate whether the factors
considered in existing replacement models are useful and relevant in the context of ERP. It is noted that replacement is an
important issue to ERP vendors and upgrade is to ERP clients. However, vendors’ replacement issues are not the focus in this
thesis.
2.8 Gaps In Existing Literature
The literature review in Section 2.7 has indicated that ERP maintenance is not merely an
instance of in-house software maintenance. It is unique in fundamental ways such that some
of the in-house software findings become insufficient in the context of ERP. The primary
objective of this section is to discuss the inadequacies of in-house software literature in the
five research areas intended in this thesis: maintenance taxonomy, maintenance-effort
determinant, software replacement model, maintenance methodology, and maintenance-data-
model.
2.8.1 Maintenance Taxonomy
Of note in Swanson’s (1976) classification is lack of consideration for user-support requests18.
Taking into consideration the fact that ERP is an enterprise-wide system entailing fully
integrated application modules and business processes, it is believed that responding to user-
support requests may constitute a significant ERP maintenance activity, possibly even more
significant for ERP than for in-house software.
Preventive maintenance is believed to be less substantial in the ERP maintenance
environment. Firstly, the nature of maintenance in an ERP environment is relatively more
reactive than for typical in-house software. While in-house maintainers are familiar enough
with homegrown software systems (which are relatively smaller in size) to do periodic
inspections, familiarizing and gaining full understanding of an ERP system represents a
daunting challenge (if not impossibility) to ERP maintainers because of the system’s size, and
complicated application logic. Secondly, this type of system inspection is more likely to be
initiated and monitored by the vendor rather than the ERP-using organization partly because
18 User-support requests are associated with consulting with and supporting user requests relating to the system’s behavior, rules and functions. They are different from corrective, adaptive and perfective because servicing them does not result in any changes made to the software system.
2-59
of limited access to the system code and the availability of maintenance support from the
software vendor, and because of apprehensions about the ripple effects that may result should
this maintenance be implemented by the client organization. Brehm et al. (2001) too suggest
that preventive maintenance is a task for the vendor, not clients.
Chapin et al.’s (2001) maintenance classification, while valuable, is believed to be deficient in
an ERP context because it does not explicitly consider or incorporate the category(s) of the
(business) benefit of doing maintenance. ERP software implementation is a business-project
(or business-driven, not simply an IT initiative) (Davenport, 2000b), having huge impact on
an organization’s business processes and strategies (Bingi et al., 1999; Davenport, 1999;
Deloitte-Touche-Tohmatsu, 1999a). ERP implementation is led by the business people with
the IT personnel playing a much smaller role than in traditional in-house software projects.
Both Swanson and Chapin et al.’s maintenance taxonomies place much emphasis on the act of
doing maintenance. As a consequence, the Swanson and Chapin et al.’s taxonomies are not
intuitive to business people who are interested in business benefits (if any) of a request. Most
organizations implementing ERP systems aim to derive benefits from the systems, and this
factor is undoubtedly the driver for continual maintenance of these systems. However, the
traditional taxonomies do not facilitate cost and benefit justification of doing ERP
maintenance. The strengths and weaknesses of these two classifications are summarized in
Table 2.17.
2-60
Table 2.17: Strengths and weaknesses of the existing maintenance classifications
Existing Maintenance Classification Strengths
Weaknesses (in the context of ERP)
Classical
(Swanson,
1976)
Based on the objective of the
maintenance activity.
Provides fundamental classes of
maintenance activities: corrective,
adaptive, and perfective.
Does not include maintenance
activities that are intended to (see
Chapter 4 for details):
Provide help-desk support (or
user-support) to system users.
Keep the installed system up to
the vendor’s standard version.
Maximize business benefit of
doing the maintenance.
Modern
(Chapin et al.,
2001)
Based on evidence of activities of
interface support, documentation,
software properties, and/or
software functionality.
Provides comprehensive
classification of maintenance
activities: enhancive, corrective,
consultive, training, groomative,
evaluative, reformative, updative,
preventive, performance, adaptive,
and reductive.
Does not consider (see Chapter 4
for details) the evidence of:
Maximizing the business benefit
of doing the maintenance
activities (or categories of
business benefit).
2.8.2 Determinants Of In-House Software Maintenance Effort
Previous studies of maintenance project characteristics affecting maintenance effort and effort
distribution, such as maintenance category, task complexity and maintenance/tailoring option
(defined by type of changes mad
e to the software) are mainly based on in-house software. While all these studies cover the
basic descriptive statistics and most of them include statistical test, the study on task
complexity did not test whether the variable is a good predictor of maintenance effort (see
Table 2.18).
2-61
Table 2.18: Previous study in maintenance project characteristics
Statistical analysis Characteristics of maintenance project
Dependent variable
Basic descriptive* Statistical test
1. Maintenance category Effort a, b, c, d c
(t-test)
2. Task complexity Effort c -
3. Maintenance option Effort c, d d
(regression
analysis)
* e.g. effort distribution and frequency count.
a = Lientz and Swanson (1980), b = Abran and Nguyenkim (1993), c = Jørgensen (1995), d = Niessink and van Vliet (1998)
To the knowledge of the author, there is no literature available on empirical studies in ERP
maintenance effort determinants or research investigating whether the abovementioned
maintenance project characteristics (found in previous studies) influence ERP maintenance
effort. Therefore, it would be useful to conduct an empirical investigation to examine if these
factors are good predictors of ERP maintenance effort.
2.8.3 In-house Software Replacement Model
The first software replacement model developed by Gupta et al. (1988) does not consider
factors that are critical to ERP software. ERP system upgrading is more complicated to model.
Considering only the dollar value of the ERP upgrade and the maintenance costs is not
sufficient. In the ERP environment, not only the upgrade and maintenance costs need to be
considered but also the costs of not upgrading and maintaining the software system. On the
other hand, Gode et al.’s model assumes that software replacement could take place
simultaneously19 (1990), where the rewrite of an old system starts and ends at the same time.
This assumption is unrealistic and not valid in the context of ERP because an upgrade takes
several months. Chan et al.’s model, though it relaxes the assumption of simultaneous
software replacement (Chan et al., 1996), does not consider the business benefits of doing a
replacement, or user opportunity costs associated with a replacement decision.
19 In-house replacement in general will take significantly longer than ERP upgrade. A system of any consequence may well take years to replace.
2-62
2.8.4 IEEE/EIA 12207.2-1997
IEEE/EIA 12207.2-1997 standard is comprehensive and detailed, covering most of the
fundamental tasks in each of the salient maintenance activities. However, the standard focuses
on the maintenance methodology for in-house software. It does not include activities related
to off-the-shelf packaged software such as researching available maintenance support from
the vendor (patches and updates, see (Nah et al., 2001)), and implementing (upgrading to)
readily available new versions from the vendor (Shi et al., 2001).
As regards roles, the IEEE/EIA 12207.2-1997 standard mainly addresses the roles of the
users, maintainer, and maintenance manager. This is appropriate, given a focus on internally
maintained software. Although the acquisition process in the IEEE/EIA 12207.2-1997 does
consider software purchased from a vendor, discussion of the maintenance process is
restricted to in-house maintained software only. This is perceived as a major shortcoming, as
the software vendor plays a significant role in ERP maintenance. Hirt et al. (2001) have
identified new roles and relationship among the different parties involved in ERP
maintenance environment; they are user, external parties, application systems, and IS staff.
From the maintenance category perspective, the ‘modification implementation’ activity in the
standard focuses on software modification to the custom code; it does not provide
considerations for software modification to the vendor (standard) code, nor for patch-
maintenance originated from the vendor. Also, the standard has omitted discussion on user-
support requests, which may constitute a major part of ERP maintenance activities.
In relation to effort, the ‘modification implementation’ in the IEEE/EIA 12207.2-1997
standard emphasizes writing software code. That is not where most time and effort is
expended on patch maintenance or ERP upgrades. These requests entail relatively more effort
on impact analysis of the installed version’s functionality versus the new version’s
functionality, between existing user-enhancements and the new version’s features, and
deciding what knowledge workers for example external consultants to hire for the upgrade
process and how to retain new knowledge from the upgrade.
2-63
2.8.5 SEI Maintenance-Data-Model
Though existing, general-purpose maintenance-data-model may be sufficient to meet the basic
needs for the management of ERP maintenance activities, they may not be robust enough to
allow detailed monitoring of ERP-specific maintenance problems, resources and conditions.
For instance, unlike traditional in-house software that is usually a standalone software
application, ERP software is cross-functional. Thus, it may be important to record the
functional area associated with a request or software problem. It is argued in previous studies
that ERP-using organizations maintain ERP systems in order to realize more benefits from the
systems. However, the attribute of business benefit/value of doing maintenance is not
included in the SEI maintenance-data-model. In addition, ERP-using organizations are not
usually expected to support all of the system’s maintenance activities internally, relying as
well on maintenance support from the vendor (see Chapter 4 for more details). Therefore, it
would be useful to identify if a maintenance request/problem was solved using readily
available maintenance support (i.e. standard code) or custom code in order to facilitate the
process of tracking the (custom) changes made to the software during a patch-maintenance or
an upgrade process. Besides this, in general the SEI maintenance-data-model also lacks
consideration of the cost implication of a maintenance request.
2.9 Summary
This chapter, through the literature reviews, thus highlights that ERP and traditional in-house
software differ in fundamental ways. This suggests that it is important to further investigate
the activities involved in the ERP maintenance environment, and to collect empirical data to
bridge the gaps in the literature discussed in Section 2.8. This is summarized in Table 2.19.
2-64
Table 2.19: Summary of the gaps in the literature in the context of ERP
ERP Research area of interest to this thesis
Available in in-house software Suitable Not
suitable
Not available in in-house software but relevant to ERP
Based on objective of a
request (Swanson,
1976).
@ Provide help-desk support
(or user-support) to system
users.
Keep the installed system up
to the vendor’s standard
version.
Maximize business-benefit of
doing the maintenance.
Maintenance
taxonomy
Based on evidence of
activities (Chapin et al.,
2001).
@ Maximizing the business-
benefit of doing the
maintenance activities.
Effort
determinants
Maintenance category,
task complexity,
maintenance option.
Predictor of maintenance effort. *
Replacement
model
Factors incorporated
are: system size,
maintainabilility /
structuredness of the
underlying software
technology, volatility of
user environment, and/or
productivity of the
maintenance team (see
(Gupta et al., 1988),
(Gode et al., 1990) and
(Chan et al., 1996)).
Benefit realization (Davenport,
2000b), user opportunity, vendor-
support termination (Craig,
1999).
Maintenance
methodology
IEEE/EIA 12207.2-1997
(1997).
Researching for available
maintenance support from the
vendor (patches and updates,
see (Nah et al., 2001)).
Implementing (upgrading to)
readily available new versions
from the vendor (Shi et al.,
2-65
ERP Research area of interest to this thesis
Available in in-house software Suitable Not
suitable
Not available in in-house software but relevant to ERP
2001).
Software vendor or external
parties play a significant role in
ERP maintenance (Hirt et al.,
2001).
Modifying the vendor (standard)
code implementing patch-
maintenance originated from the
vendor.
Performing user-support request.
Impact analysis of the installed
version’s functionality versus the
new version’s functionality.
Deciding what knowledge
workers to hire for the upgrade
process.
Determining how to retain new
knowledge from the upgrade.
Maintenance-
data-model
SEI’s framework for
counting problems and
defects (Florac, 1992).
Request attributes such as
functional area, vendor-support,
business benefit and value,*
cost.*
* This may not only be required in the ERP context but also in in-house software. However, the main focus in this thesis is on
ERP.
It is partially suitable. @ It is suitable but not necessarily sufficient.
3 Research Methodology
With better understanding of the research context in Chapter 1, and background of what have
been done in prior research in Chapter 2, this chapter elaborates the research methodology. As
presented in Section 1.11, this research project uses case study research method. The
objectives in this chapter are: (1) to describe the research method, including the participating
case firm in this study, (2) to define data required for this study and how data are collected,
and, (3) to detail how the data are analyzed. The organization of this chapter is as follows.
Section 3.1 presents the details about the participating case firm. Section 3.2 describes the
data collections from the case study. With the data sources, Section 3.3 provides details on
how the data analysis procedures are carried out in order to obtain the findings and answers to
the proposed research questions. Section 3.4 discusses the validity and reliability of this
study’s research design. Lastly, Section 3.5 summarizes the research method, data sources,
data collected and data analysis used in addressing the research questions proposed in this
thesis. A detailed illustration of the research design is also given.
3.1 A Single-Case Study
Why – This research is an exploratory, descriptive, revelatory and collaborative case study.
This is driven by the fact that (1) ERP maintenance and upgrade (MU) is a relatively new
research area, (2) there is a need to understand if prior studies that are primarily based on in-
house software are applicable in the context of ERP, and to determine if ERP maintenance
and upgrade is merely an instance of in-house software maintenance, and (3) the author has
comparatively advantageous access to previously inaccessible, detailed ERP MU evidence. In
light of the revelatory nature of this study – “an opportunity to observe and analyze a
phenomenon previously inaccessible to scientific investigation” (p. 40), a single case study
(research approach) is justified (Yin, 1994).
Among the studies done on ERP, most researchers conduct their studies using case studies and
interviews, see (Clemons, 1998; Holland et al., 1998; Parr et al., 2000; Volkoff, 1998). This is
because theory-based research is not appropriate as ERP is a new phenomenon and there is
3-1
very little guiding theory available. Benbasat, Goldstein and Mead (1987), Yin (1994) and
Gable (1994) state that under these circumstances the case study is a most appropriate
research method.
Objective – This study discovers and describes the nature of ERP maintenance and upgrade
activities. The empirical data are then compared with the previous results in-house software
maintenance to determine if ERP is simply an instance of in-house software and whether
existing literature is sufficient.
Case selection – The criteria set in choosing the right case study are an organization has
implemented and maintained an ERP system internally for more than one year, and keeps a
log of all its maintenance activities done to the ERP system.
3.1.1 The Case Background
Business mission – The case firm studied in this research project is the Corporate Service
Agency (CSA) to the Queensland Government, in Australia. CSA is an internal unit of the
Department of Natural Resources (DNR) and gets budget allocation from this Government
Department. This agency was set up in 1996 and its initial objective is to provide corporate
services to both Department of Natural Resources (DNR), and Department of Primary
Industries (DPI). Now, it plays a major role in providing SAP services not only to these two
Government Departments but also to the State Water Projects (SWP), and Forestry. CSA itself
is an internal client for the corporate services that it provides. The collaboration of these five
organizations begins in 1997 and is to share the Information System resources and to reduce
their departments’ IS/IT expenditures. The provision of corporate services to these agencies is
according to the Service Level Agreement (SLA) between CSA and its clients.
SAP implementation – In 1994, the SAP R/3 version 3.1H Finance (FI) module was selected
to replace the Queensland Government Financial Management System (QGFMS) of the Dunn
and Bradstreet. This module went live since November 1998. Following the initial decision
on using the SAP R/3 Finance, the SAP R/3 Human Resources (HR) is then chosen to replace
its previous Human Resources Management System (HRMS), which was not Y2K compliant.
This module was up in late April 1999. Owing to the issue of support termination for version
3-2
3.1H, CSA has recently upgraded the SAP system to version 4.6C. The upgrade was
completed on 3rd April 2002.
Outsourcing – CSA outsource the hardware from CITEC. CITEC, the Queensland
Government computer center, is a service provider to CSA through bureau
agreement/arrangement. CITEC owns and manages the hardware and R/3 system for CSA.
CITEC’s main functions are to monitor the SAP system hardware performance for CSA, and
transport SAP system maintenance changes to the production system.
CSA’s organization chart and maintenance staffs – CSA is under the administration of a
General Manager. There are three working groups in CSA: the Corporate Information System
(CIS), Business Advisory Services, and Support Services. While part of CIS duties is to
manage and maintain the SAP R/3, the other part of its duties are to maintain, monitor and
manage a number of legacy systems for its clients. Particularly, the Department of Natural
Resources, who looks after titling and leases of land in Queensland, uses very specialized
legacy systems to manage those applications. These legacy systems are integrated with the
SAP system through interfaces. CIS consists of two working teams specifically responsible
for managing software maintenance activities. They are: technical team and development
team. This is shown in Figure 3.1.
Corporate Service AgencyG eneral M anager
CorporateInform ation
System s (C IS)Support Services
Developm ent TeamSystem s Developm ent
M anager
Technical TeamSystem s O perations
M anager
BusinessAnalysts
(10)
ABAPProgram m er
(4)
Adm in istrator(1)
Service Desks(3)
Support S ta ff(for data entry)
(200)
BusinessAdvisory Services
Figure 3.1: CSA’s organization chart
3-3
Development Team – The development team is part of the SAP R/3 development group. The
development group consists of a senior manager – Systems Development Manager, ten
business analysts, and (at present) four contract ABAP1 programmers. The distributions of the
business analysts among the modules are Payroll – 3, Human Resources – 2, Accounts
Receivable/Accounts Payable – 1, Financial Accounting – 1, Financial Performance
Management – 1, Materials Management – 1, and Asset Accounting – 1. Hundred percent of
this team’s effort is devoted to R/3.
Technical Team – The technical team is part of the SAP R/3 operations support group. The
operations support group consists of a senior manager – Systems Operations Manager, three
service desk (or BASIS or SAP technical) staff, and one system administrator. This group is
responsible for ensuring the continuing operations of the R/3 and liaises with the service
bureau (i.e. CITEC), which provides the technical/hardware service for the R/3 operations.
Although the members in this operations support group are also responsible for non-SAP R/3
related operations, 80% of its effort and time is devoted to R/3.
The Business Advisory Services provides business and improvement advices to CSA’s
clients. Whereas, the Supporting Services is primarily supplying data entry services; it has
more than 200 staffs.
3.1.2 Units Of Analysis
Five embedded sub-studies (within an over-arching case study) conducted at CSA are:
taxonomy sub-study, effort sub-study, decision sub-study, methodology sub-study, and data
sub-study. The units of analysis in these five sub-studies are as shown in Table 3.1.
Table 3.1: Sub-study and unit of analysis
Sub-study Unit of analysis Taxonomy Maintenance request
Effort Maintenance request
Decision Maintenance decision, and upgrade decision
Methodology Maintenance lifecycle
Data Maintenance request
1 ABAP stands for Advanced Business Application Programming, and is the SAP proprietary programming language for application development purposes for example software tailoring as discussed in Table 2.1 in Chapter 2.
3-4
3.1.3 Case Protocol
The high-level case protocol followed in this research is as follows:
(1) The objectives of each sub-study are determined.
(2) The anticipated data are determined based on the objectives of each sub-study.
(3) Multiple sources of evidence are gathered.
(4) Chain of evidence pointing to the same inquiries is consolidated in each sub-study.
(5) Case description is used in synthesizing the descriptions, explanations and interpretations
of the case firm’s maintenance environment and activities; and for quantitative data, basic
descriptive statistics and/or regression analysis are conducted.
(6) The synthesized information and knowledge about the case firm’s maintenance
environment (i.e. maintenance taxonomy, maintenance effort, maintenance and upgrade
decision, maintenance methodology, and data-model) is analyzed and compared with the
findings in the prior studies and trade literature (whenever available and applicable), using
pattern-matching technique.
(7) If the existing literature is found to be insufficient, an improved maintenance taxonomy,
effort model, maintenance and upgrade decision framework, maintenance methodology,
or maintenance-data-model is developed based on what has been learnt from the (ERP)
case firm, and the prior literature on in-house software; and/or recommendations that are
supported by other relevant literature in similar contexts.
3.2 Data Collection
There are seven sources of data collection: semi-structured interviews, the change-request
database, user-support database, patch-support database, SAP system modification database,
documentation (i.e. reports or documents) – Upgrade Business Case and SAP R/3 Upgrade
Planning Resources, and maintenance request forms. These varieties of data sources are
discussed in detail in Sections 3.2.1–3.2.7. They are used to examine whether existing in-
house software maintenance literature is sufficient in the context of ERP; and are also used for
data-triangulation in developing the respective ERP maintenance tools and techniques. This is
summarized in Figure 3.2.
3-5
Docum entation
ERP M aintenanceTaxonom y
InterviewTranscripts
Change-request
Database
User-supportDatabase
Patch-supportDatabase
M odificationDatabase
ERP M aintenanceEffort M odel
ERP M aintenanceand Upgrade
DecisionFram ework
ERP M aintenanceM ethodology
ERP M aintenance-data-m odel
Data Source Research Output
M aintenanceRequest Form s
Figure 3.2: Data source and research output
From Figure 3.2:
(1) Data from interviews, change-request and user-support databases are examined to analyze
and propose an ERP maintenance taxonomy (see Section 3.3.1, and Chapter 4).
(2) Data from interviews and change-request database are collected to analyze and determine
the factors driving ERP maintenance effort (see Section 3.3.2, and Chapter 5).
(3) Data from interviews, change-request, patch-support and modification databases, and from
maintenance and upgrade documentation are studied to analyze and develop an ERP
maintenance and upgrade decision framework (see Section 3.3.3, and Chapter 6).
3-6
(4) Data from interviews, change-request database, and maintenance and upgrade
documentation are used to analyze and develop an ERP maintenance methodology (see
Section 3.3.4, and Chapter 7).
(5) Data from interviews, maintenance request forms, and change-request database are
gathered to analyze and propose an ERP maintenance-data-model (see Section 3.3.5, and
Chapter 8).
3.2.1 Semi-Structured Interviews
Interviewees’ roles – The interviewees (participants) in this study, from CSA, were: the
General Manager, Systems Development Manager, Systems Operations Manager, and
Business Analyst. The General Manager is in charge of executive matters in CSA. He sets up
the organization’s business objectives, rules and the general administration policies,
determines future directions of the organization, and makes strategic decisions. The main
responsibility of the Systems Development Manager is the development (i.e. bug fixes, and
enhancement) of the SAP system. He approves maintenance requests, provides quotations for
enhancement requests (for those initiated by CSA’s clients), prioritizes maintenance requests,
assigns or allocates maintenance jobs to his staff, plans for future upgrades, and keeps track of
all the change-requests. The Systems Operations Manager is responsible for ensuring the
continuing operation of the system, monitoring system administration, and liaising with the
service bureau that provides facility management support. He also monitors the SAP system
performance and system usage by different clients; is in charge of the provision of user
support to the system users; gives advice on the security issues of the SAP system; and
approves maintenance requests. On the other hand, the Business Analyst (in this case) is
responsible for investigating and monitoring maintenance support—often called patches—
provided by the vendor; searching for bug fixes for corrective maintenance requests in the
Online Support System (OSS) notes; determining whether a maintenance request qualifies as
a change-request; and designing resolutions for maintenance requests.
Interview process and interview questions – The interview process consists of two stages.
The initial stage was designed as an “introductory” interview. These interviews were
unstructured and conducted during the very early stage of the study. The purpose of this first
stage is to gather background information about CSA and its ERP maintenance activities. This
includes the business nature, types of maintenance activities, and the people involved and
3-7
responsible for the maintenance. Three sessions of “introductory” interview were conducted
and the total time spent was about five hours.
Some of the questions asked in the introductory interviews are:
• What are the types of ERP maintenance activities performed in your organization?
• Who is the main group of maintenance initiator and what are the objectives of the
maintenance requests?
• Who is responsible and involved in planning, managing, monitoring and executing
ERP maintenance activities?
• What is the distribution of effort on work related to ERP maintenance?
All of the interviews were either tape-recorded and/or written down as notes during the
interviews. The tapes were transcribed and interview notes were elaborated immediate after
each interview. Within a week the transcript was sent to the interviewee(s) at CSA in order to
counter-check the interpretation and validate the content of the interview.
With sufficient information gathered from the preliminary interviews, the second-stage of
“detailed” interviews began. At this stage the interviews were conducted in a semi-structured
way. The main purposes of these interviews were:
• To determine the reasons for doing each category of maintenance requests (objective:
to contrast existing in-house software maintenance taxonomies).
• To identify factors affecting the ERP maintenance effort (objective: to determine if
the factors are similar to the in-house software).
• To discuss factors influencing and driving ERP maintenance and upgrade decisions
(objective: to identify whether they are distinct from those for an in-house software
environment).
• To get a better understanding of the activities and tasks involved in ERP maintenance
and upgrade process (objective: to compare results with the existing standard for
software maintenance methodology).
• To confirm the objectives and meaning of each data attribute found in CSA’s change-
request database (objective: to make comparison with the in-house software
maintenance-data-model).
3-8
Four sessions of interview were conducted and the total interview time was approximately
eight hours. Some of the interview questions were as follows.
• What are the activities involved in processing a change-request (corrective,
enhancement), and user-support request? Do you have any strategy in managing your
ERP change-requests?
• How does the process of maintaining a bug in the custom code differ from that for a
bug found in the vendor’s code?
• Do you need to re-apply the prior modifications after the implementation of a patch,
and an upgrade project?
• Is maintaining a patch (introduced by the vendor) different from maintaining a
change-request (initiated by your system users or IT-staff)?
• How does skipping some of the earlier patches impact on your subsequent
implementation of the later patches?
• Do you perform any system analysis and programming for the implementation of
patch from the vendor?
• How do you know when the vendor introduces a new patch/LCP?
• What factors do you take into consideration when making maintenance decision (for
patch and change-request)?
• Why do you maintain your ERP system?
• Do your maintenance activities affect the SAP standard code?
• What are the activities involved in an upgrade process?
• What constitutes an ERP upgrade cost?
• What is your organization’s ERP upgrade strategy/policy?
• What are the factors driving an upgrade decision?
• Do you adopt any standard software maintenance methodology in your (ERP)
maintenance practice?
• Has CSA adopted any framework or standard for recording maintenance problems
and defects (such as the one proposed by Software Engineering Institute (SEI))?
• Are you happy with your existing maintenance-data-model?
Similar to the “introductory” interviews, all interviews conducted at this stage were tape-
recorded, and then transcribed and later verified by CSA. The data analysis for this data
source is further discussed in Section 3.3.
3-9
3.2.2 Change-Request Database
The change-request database consists of six tables. They are: change-request table, timesheet
table, personnel table, company table, and work type table. These tables are kept in the
Microsoft Access database. The details of the data captured in each of these tables are shown
in (Table 3.2 – Table 3.7). The change-request table (Table 3.2) contains all the details on the
maintenance change-requests inclusive of both completed and in-progress maintenance
requests/projects. This table has secondary keys pointing to the remaining five tables. At the
time of data collection, it contained a total of 1616 data points or maintenance requests, which
had been documented between 2 Nov 1998 and 27 June 2000. This database consists of
enhancement requests, corrective requests and patch-maintenance. The timesheet table (
) comprises records of each individual staff member participating in any of the
maintenance projects (as recorded in the change-request table), and the time spent on the
projects. On the other hand, the personnel table (Table 3.4) contains personnel details. While
the company table (Table 3.5) describes CSA’s clients (who are basically the Government
Departments), the work type table ( ) defines the types of maintenance request
performed at CSA for its clients. Product table (Table 3.7) shows the (maintenance) unit that
will receive the maintenance fee charged on CSA’s client(s).
Table
3.3
Table 3.6
The data from this source was used to examine the types of ERP maintenance requests, and
the activities involved in resolving the maintenance (to propose an ERP maintenance
taxonomy, in Chapter 4); to compute the time spent on each category of maintenance requests,
and conduct empirical data analysis for ERP maintenance effort determinants (to develop an
ERP maintenance effort model, in Chapter 5; and to develop ERP maintenance and upgrade
decision framework, in Chapter 6); to have an idea of the activities or tasks occurred along
ERP maintenance process (to develop ERP maintenance methodology, in Chapter 7); and to
identify the essential (ERP) maintenance request’s data captured by CSA (to develop ERP
maintenance-data-model, in Chapter 8).
Table 3.2: Change-request table
Field Name Meaning / Purpose SIRNumber Unique code assigned to each maintenance request issued by the
user/vendor.
DateRaised Record the date change-request is brought to attention.
ServiceDeskXRef Reference number issued at the Helpdesk when the user introduces the
3-10
Field Name Meaning / Purpose maintenance request.
TestPhase Represents the major functional area, e.g. “finance”, “human resource”, or
“basis”.
Priority Represent criticality of the request. Its value is either “high”, “medium”, “low”,
or “deferred”.
FunctionalArea Represents the high-level business process in the maintenance problem, e.g.,
Payroll, OH & S, Time Recording, Employment, Workplace Analysis, Leave
Management, Recruitment & Selection, Procurement, A/R (accounts
receivable), Management Expenses and Revenue, A/P (accounts payable),
Establishment Management, Assets Management, Training & Development,
Management Finance Performance, Inventory Mgmt, Finance/Human
Resources Integration, and Others).
ProblemType Describe the major type of change done to the software (e.g. security,
configuration, ABAP / SAPscript, documentation, form, technical, business
process, reports, batching, process flow, table contents, data, program, report
tree, Interface and Conversion, and others).
ProblemDescription Description of the maintenance problem.
RaisedBy Stores the PersonID (found in the personnel table) of the staff member who
raised the maintenance request.
Analyst Stores the PersonID (found in the personnel table) of the staff member who
analyses the maintenance problem.
Programmer Stores the PersonID (found in the personnel table) of the staff member who
programs the maintenance code.
Company Stores the CompanyID (found in the company table) of the company that
initiated the maintenance request.
Estimate Estimate of time (in hours) to complete the change-request.
Quote Indicates the estimated cost of implementing the maintenance request (for
CSA, this attribute is used for the user-initiated enhancement request only).
Resolution Describes how the maintenance problem is to be resolved, what must be
done, and contact person (fixer) for the problem.
ProductID Stores ProductID (found in product table) that Indicates which unit receives
the fee charged; is used for billing purposes.
ClientWBS Indicates the client "cost centre" code to charge; is used for billing purposes.
WorkType Stores the WorkTypeID (found in WorkType Table) of the maintenance work,
which indicates the type of maintenance request.
Status Indicates the job-status for the maintenance project. May store value of
“closed”, “in-progress”, “assigned”, “on hold”, “user testing”, “CIS testing”,
“awaiting specification”, “quote with client”.
DateActioned Records last date status changed.
3-11
Table 3.3: Timesheet table
Field Name Purpose PersonID Store the PersonID (from Personnel Table) of the staff member(s) who
maintain / service the maintenance request.
WorkDate The date the maintenance is serviced.
SIRNumber Stores an ID number of a change-request.
WorkTime Time spent on maintaining a change-request (in hour).
Table 3.4: Personnel table
Field Name Meaning / Purpose PersonID Unique Code number assigned to each staff member involved in the
maintenance. Networklogin Records the login name of the user to the network. Surname Stores the family name of the staff member. GivenName Stores the given name of the staff member. EmailAddress Keeps the email address of the staff member. Current Indicates the staff member is in the Corporate Information Systems area.
Table 3.5: Company table
Field Name Purpose CompanyID To store the unique code number representing the company receiving the
corporate service (SAP FI and/or HR) from CSA, and requesting for
maintenance.
Company Description of the company code number.
Table 3.6: Work type table
Field Name Purpose WorkType ID Unique code number for the type of maintenance. Its value is in the range of
1-4.
WorkType Indicates the type of maintenance request. The types are:
- “master data change”, related to master data file updates;
- “corrective”, associated with correcting fault(s) in the system;
- “CSA-enhancement”, enhancement initiated by CSA; and
- “user-enhancement”, enhancement initiated by the system user.
3-12
Table 3.7: Product table
Field Name Purpose ProductID To store the unique code number representing the unit receiving the fee
charged.
ProductDesc Description of the product ID, e.g. Systems Development, Systems
Operations, etc.
3.2.3 User-Support Database
This database contains requests pertaining to user-support on CSA’s SAP system; it captures
information on the types of user-support request, support problem description, and details of
the requestors and maintainers. This data source was studied to identify the objectives or the
reasons for requesting and doing the user-support requests (to understand the nature of ERP
maintenance and to propose an ERP maintenance taxonomy, in Chapter 4). The primary data
field of interest in this database was request-description. The data analyzed were user-support
requests dated between 2 November 1998 and 27 June 2000. Data analysis using this data
source is further explained in Section 3.3.1.
3.2.4 Patch-Support Database
Unlike the change-request database and user-support database that record maintenance
requests initiated by system users and IT-staff, the patch-support database is a repository,
where all the patches from the (R/3 system’s) vendor are stored. It is connected to the Online
Service System (OSS) from CSA’s R/3 system. It is controlled by an application (from SAP)
called SAP Patch Manager (SPAM), which allows the download and application of patches
within an R/3 system. The data from this source, which were readily available at the time of
(the author’s) data collection, were used to examine the frequency of patch introduction for a
number of SAP R/3 versions; and investigate whether a newer version would have a positive
impact on (minimizing) the number of future (patch) maintenance requests (to develop the
ERP maintenance and upgrade decision framework, in Chapter 6). The specific data fields
considered in this study are version-number, number-of patches, and number-of-notes. Data
analysis using this data source is further explained in Section 3.3.3.
3-13
3.2.5 SAP System Modification Database
This database was developed by a consultant firm, appointed by CSA to investigate the
number of modification-enhancements done to CSA’s SAP R/3 system (version 3.1H). It
contains details about the modification-enhancements that require re-application, and
estimations of the amount of effort needed to reapply those modifications in an upgrade. This
data source is useful for studying the implications and impacts of an upgrade on current and
future maintenance (this is useful in developing the ERP maintenance and upgrade decision
framework, in Chapter 6). The essential data fields used in this study were number-of-
existing-enhancement, and number-of-enhancement-needed. Data analysis using this data
source is further explained in Section 3.3.3.
3.2.6 Documentation
The documentation (i.e. reports or documents) collected from CSA was Upgrade Business
Case and SAP R/3 Upgrade Planning Resources. This documentation contains details on the
preparation activities and activities for an ERP upgrade, factors affecting CSA’s upgrade
decision, expected benefits from an upgrade exercise, and new functionality found in the latest
versions. These were utilized in this study to verify the factors influencing ERP maintenance
and upgrade decisions, and to facilitate formulation of the relationships among these
variables/factors (to develop an ERP maintenance and upgrade decision framework, in
Chapter 6); and to determine activities and procedures involved in an ERP upgrade
preparation and execution, and the responsibilities of each party participating in the upgrade
exercise (this data is used in developing the ERP maintenance methodology, in Chapter 7).
Data analysis using this data source is further explained in Section 3.3.3 and 3.3.4.
3.2.7 Maintenance Request Forms
Maintenance request forms, i.e. system-investigation form and SAP-transport-request form,
are used by CSA to record details (or attributes) of a change-request from the moment it is
introduced, by the system users or IT-staff, until it is completed and delivered to the system
users. They are also used to collect information on who approves the delivery of the change-
request and which system(s) the resolution is delivered to, and what activities are involved
and why. Each change-request requires a separate system-investigation form and a SAP-
3-14
transport-request form. These forms are the “information backbone” of CSA’s whole
maintenance execution. Although most of the maintenance attributes on these forms are also
recorded in the change-request database (discussed earlier in Section 3.2.2), some of them are
not. Data from this source (i.e. forms) was used to identify essential maintenance attributes
captured in order to synthesize CSA’s ERP maintenance-data-model (objective: to identify
whether they differ from those found in in-house software environments, and develop an ERP
maintenance-data-model, in Chapter 8).
3.3 Data Analysis
The databases – change-request, user-support, patch-support and modification – were
analyzed using the SPSS statistical packaged software. Basic descriptive statistics (such as
mean, standard variance, number of cases) were used to analyze the frequency and effort
distribution of different maintenance request types, task complexity and tailoring options.
Other statistical procedure includes regression analysis to study the explained variance in
maintenance effort.
For data and information that could not be retrieved and used directly from any of these
databases, (C++) programming code has been written in order to produce the required data –
such as the total maintenance effort for each completed maintenance project/request, number
of staff participated in each project, and so forth. The following discussions on data analysis
are divided into the five sub-studies covered in this thesis.
3.3.1 Taxonomy Sub-study
In analyzing CSA’s maintenance taxonomy, the following procedures were undertaken. Tape-
recorded interviews were transcribed following the interviews. The transcripts were
referenced to provide a reliable description of CSA’s maintenance environment, including the
objectives of doing each category of maintenance requests and benefits of maintaining its ERP
system. The interview transcripts were re-examined throughout the process of data analysis to
ensure reliable and valid data interpretation. The change-request database and user-support
database were analyzed in detail for evidence of activities involved in each category of
3-15
maintenance requests; and descriptive statistics were used to identify the frequency and effort
distributions across CSA’s maintenance categories.
Next, with these observations and a better understanding of CSA’s ERP maintenance
objectives and activities, its maintenance categories were mapped onto the Swanson (1976)
and Chapin et al. (2001) in-house software maintenance classifications (see Figure 3.3). The
objective here was to investigate whether existing maintenance taxonomies are sufficient to
classify CSA’s ERP maintenance activities. Findings in this research area are discussed in-
depth in Chapter 4. An ERP maintenance taxonomy is proposed in that chapter, with further
substantiation from existing ERP literature.
CSA's ERPMaintenanceCategories
Dimensions for classifyingmaintenance request
Objectivesof
Evidence ofthe activities
for
Benefits of ERP
Evidence ofthe activities
aremapped into
Objectivesare
mapped into
InterviewTranscripts
Change-request
Database
User-supportDatabase
ERP Literature
TheProposed
ERPMaintenanceTaxonomy
Swanson'sSoftware
MaintenanceTaxonomy
Chapin etal.'s SoftwareMaintenanceTaxonomy
check forconsistency
(1)Mapped onto
(2)Compared with
CSA's (ERP)Environment
In-house SoftwareEnvironment
(3)Proposed in
Figure 3.3: Data analysis process for CSA’s ERP maintenance classification
3.3.2 Effort Sub-study
The main source of data for identifying the factors affecting (CSA’s) ERP maintenance effort
is the change-request database. The database contains details of maintenance effort,
maintenance category, tailoring option (or type of changes made to the software), module
involved, the staff participating in the project, and so forth. At the time of the study, there
3-16
were 1616 maintenance projects recorded in CSA’s change-request database. A total of 1438
projects had been completed. However, only 593 out of 1438 projects had recorded the time
spent in completing the projects. As a result, 593 maintenance projects were used in the
maintenance effort data analysis.
The data analysis of maintenance effort, in this study, involves one dependent variable:
maintenance effort; it is the time spent to complete a change-request. Literature review in
Chapter 2, Section 2.5.3 shows that maintenance category, task complexity, and tailoring
option are potential factors (i.e. maintenance project characteristics) influencing in-house
maintenance effort. These factors or maintenance attributes were also recorded and/or
available in CSA’s change-request database. Thus, they were used as independent variables in
effort sub-study. (This does not imply that these three variables are the only factors affecting
maintenance effort; due to the limited amount of data available, this sub-study has limited to
only the four project characteristics.) Table 3.8 shows the variables with their corresponding
field names in the change-request table (i.e. Table 3.2).
Table 3.8: Variables and the corresponding field names in change-request table
Variable Description Corresponding to the field name in change-request table
Maintenance
category
Type of maintenance request WorkType
Task complexity Degree of difficulty or complexity
associated with a maintenance
project
-
(CSA’s Systems Development Manager
was later interviewed and requested to
give a rank to each maintenance project
in the change-request table.)
Tailoring option Type of changes done to the
software
ProblemType
Maintenance effort Time spent in servicing a
maintenance project/request
-
(program code was written to retrieve
this data from the timesheet table)
Basic descriptive statistical analysis was run on the independent variables. The statistics
analyzed were cases, mean and standard deviation. The primary objective of this analysis was
to explore: (1) the frequency counts of each categorical variable within each of the
independent variables – to ensure that there are sufficient cases for data analysis; and (2) the
3-17
average/mean and variability of maintenance effort spent by each categorical variable within
each of the independent variables – to have a “feel” for the average time required to complete
different categories of maintenance request, tailoring option and so forth.
Multivariate regression analysis was performed on the independent variables with respect to
the dependent variable to identify how much variance (in the dependent variable) could be
explained by the independent variables. The beta coefficients of the independent variables
were used to indicate the relative weight of each of the variables in the regression equation.
Regression test was performed using the standard method of entry (ENTER), where all the
variables are entered in one block, and can be specified more than once (Coakes, 1999).
3.3.3 Decision Sub-study
In decision sub-study of ERP maintenance and upgrade decision framework, the data analyses
conducted were as follows. Findings from the interview transcripts and evidence from the
documentation (Upgrade Business Case) were utilized to identify the factors driving ERP
maintenance and upgrade decisions. CSA’s patch-support database was explored to study the
trend of patches, introduced in a series of SAP R/3 versions, distributed by the vendor. On the
other hand, CSA’s SAP modification database was analyzed to research the impact of an
upgrade on its previous modification-enhancements. This analysis process is summarized in
. Figure 3.4
3-18
Change-request
Database
Patch-supportDatabase
InterviewTranscripts
ModificationDatabase
Documentation
MU decision driver
Maintenanceeffort-driver
Patch intro.pattern
Upgrade impacton prev.
modifications
MU cost drivers
The ProposedERP
Maintenanceand Upgrade
DecisionFramework
CSA's (ERP)Environment
In-house SoftwareEnvironment
(3)Proposed in
ERP Literature
MU cost drivers
check forconsistency
Replacementmodels
Factors affectingERP
Maintenanceand Upgrade
(MU) Decisions
(1)Mapped onto
(2)Compare with
Figure 3.4: Data analysis process for the decision framework
Descriptive data analysis was conducted on: (1) the number of modification-enhancements
required before and after the upgrade – from the modification database; and (2) the number of
patches in each version, and number of notes in each patch – from the patch-support database.
Prior data analysis done in 3.3.1-3.3.2 is also re-usable in this section. For instance, the nature
of ERP maintenance and details on the maintenance requests done by CSA (discussed in
Section 3.3.1); and empirical analysis on the factors to be considered in estimating
maintenance effort (discussed in Section 3.3.2). Figure 3.5 shows how the cost components,
cost drivers, factors affecting effort and tradeoffs were identified and determined from CSA’s
case study.
3-19
1.What are the
factors affectingmaintenance andupgrade decision?
4.How do I make
maintenance andupgrade decision?
3.Why am I makingmaintenance andupgrade decision?
2.What are the
decisionalternatives?
6.How to estimate
my costs?
7.What are thebenefits if Iupgrade (ormaintain)?
5.What will happen if
I do not makemaintenance andupgrade decision?
ReflectionQuestions
DataSource
ExpectedOutputData
Factors or costcomponents ConstraintsCost driversDecision
alternatives
Factors affectingcost/effort, cost
drivers
Tradeoffs, decisiondrivers
Tradeoffs, decisiondrivers
InterviewDocumentation
InterviewChange-requestDatabase
InterviewDocumentation -UpgradeBusiness Case
InterviewDocumentation -UpgradeBusiness Case
InterviewDocumentation -UpgradeBusiness Case
Change-requestDatabase
Patch-supportDatabaseModificationDatabase
Figure 3.5: A protocol for decision framework
3-20
These empirical results were applied to extend the existing knowledge on ERP maintenance
and upgrade, and propose a better representation or model of the ERP maintenance and
upgrade decision process. For instance, reduction in the number of previous modification-
enhancements after an upgrade is incorporated into the decision framework proposed later on.
The interview transcripts and Upgrade Business Case were used to determine the reliability of
the ERP maintenance and upgrade decision factors identified from the existing ERP literature.
For example, it was found that benefit-realization is one of the main drivers for ERP
maintenance and upgrade decision – to be consistent between the two sources.
3.3.4 Methodology Sub-study
Adopting the new2 definition of software maintenance given by the ISO/IEC (1995) and
Pigoski’s (1997), maintenance methodology3 in this thesis is defined as a maintenance model
or process used to describe activities covered in: software maintenance preparation stage,
software maintenance procedure stage, and software upgrade stage.
There were two phases involved in the data analysis of CSA’s ERP maintenance
methodology. Phase-1 involved mapping the relevant data collected on maintenance and
upgrade activities to synthesize CSA’s (ERP) maintenance methodology, comparing CSA’s
maintenance methodology with IEEE/EIA 12207.2-1997 maintenance methodology, and
identifying deficiencies (if any) in IEEE/EIA 12207.2-1997 in the ERP (CSA) context. Phase-
2 included in-depth analysis of CSA’s maintenance methodology.
Phase-1 – Data gathered from the interviews, related to maintenance preparation and initial
planning, maintenance procedure or workflow, and the upgrade process, were mapped onto
the respective maintenance preparation, maintenance procedure, and software upgrade stages
in CSA’s (ERP) maintenance methodology. This is shown in Figure 3.6. CSA implicitly
follows these stages. Data collected from the databases (i.e. change-request and user-support
databases) associated with request type and maintenance activities were mapped onto the
2 Note that software maintenance methodology previously proposed in IEEE Standard for Software Maintenance (1998) did not pay much attention to the maintenance preparation and software replacement stages (see also (Pigoski, 1997)). 3 Note that these three stage-names are proposed in this study, rather than using the maintenance activity-names given in the existing standard (i.e. ISO/IEC 12207), because the proposed terms are believed to be less ambiguous and more intuitive. For instance, maintenance preparation is more intuitive than process implementation; and software upgrade is more generally used in the ERP context than software retirement. Maintenance preparation is involved in planning for software maintenance management issues, and maintenance process. Maintenance procedure describes the sequence of activities involved in organizing, managing, handling, controlling and executing a software maintenance request. Software upgrade explains the activities that take place in upgrading an existing software system with a new version (for technical and/or functional upgrade).
3-21
maintenance procedure stage. Information from the upgrade business case and upgrade
planning resources documentation that are connected to ERP maintenance preparation and
software upgrade, was mapped onto the maintenance preparation and software upgrade stages
(of CSA’s maintenance methodology) respectively.
For making comparisons between CSA’s maintenance methodology and IEEE/EIA 12207.2-
1997 maintenance methodology, and IEEE/EIA 12207.2-1997’s process implementation
activity was mapped onto the software maintenance preparation stage; problem and
modification analysis, modification implementation and maintenance review and acceptance
were mapped onto the maintenance procedure stage; and the migration and software
retirement, as well as problem and modification analysis, modification implementation and
maintenance review and acceptance were mapped into the software upgrade stage. The CSA’s
maintenance methodology was then compared with the IEEE/EIA 12207.2-1997 maintenance
methodology task-by-task, activity-by-activity, and stage-by-stage. The objective is to
determine whether IEEE/EIA 12207.2-1997 is sufficient in the context of ERP.
Phase-2 – The synthesized CSA’s ERP maintenance methodology was studied in great detail
to identify how CSA could do better based on evidence from various literature sources. With
this, a preliminary ERP maintenance methodology is proposed and its benefits are also
provided in Chapter 7.
3-22
InterviewTranscripts
Change-request
Database
User-support
Database
Softwaremaintenancepreparation
Documentation
Softwaremaintenance
procedure
Softwareupgrade
Softwareupgrade
Softwaremaintenance
procedure
Softwaremaintenancepreparation
(1)Mapped onto
(2)Compared with
The SynthesizedCSA's ERP
MaintenanceMethodology
IEEE/EIA 12207.2-1997MaintenanceMethodology
TheProposed
ERPMaintenanceMethodology
RelatedLiterature(ERP and
packaged sw)
(3)Proposed in
Phase-1 Phase-2
Figure 3.6: Data analysis process for CSA’s ERP maintenance methodology
3-23
3.3.5 Data Sub-study
In synthesizing and analyzing CSA’s ERP maintenance-data-model, the following steps were
involved. All maintenance attributes in CSA’s maintenance request forms (i.e. system-
investigation-request form, and SAP-transport-request form) and change-request database
were mapped into the CSA’s ERP maintenance-data-model. Interviews were also conducted
in order to facilitate and validate the process of synthesizing CSA’s ERP maintenance-data-
model. All attributes in the Software Engineering Institute (SEI) problem and defect counting
framework (Florac, 1992) were mapped into the SEI maintenance-data-model (see Figure 3.7
below). Each of these attributes was compared and cross-referenced with all the attributes in
CSA’s ERP maintenance-data-model. The mapping of CSA attributes onto SEI was based on
the key objectives of these attributes, and was validated through an iterative-feedback process
with the CSA senior managers to enhance the accuracy and reliability in mapping the
attributes. (The purpose of this activity is to determine is SEI sufficient in the ERP context.)
Findings from this sub-study are elaborated in Chapter 8. In lights of the findings, an ERP
maintenance-data-model is proposed. It consists of attributes found in both CSA’ ERP
maintenance-data-model and SEI; attributes in the CSA’ ERP maintenance-data model but not
in the SEI maintenance-data-model; relevant attributes in SEI maintenance-data-model but not
in CSA’s ERP maintenance-data-model. Related literature was consulted to further improve
the quality and relevance of the proposed ERP maintenance-data-model.
3-24
SEI Framework
SEIMaintenance-data-model
TheSynthesizedCSA' ERP
Maintenance-data-model
The ProposedERP Maintenance
-data-model
relevantattributes
in SEI
attributes not considered in SEI butimportant in the context of ERP
Related literature(from in-house
software &packaged sw)
MaintenanceRequest Forms
attributes in themaint. request
forms (but not inchange-request
database)
Change-request
Database
InterviewTranscripts
Data required to utilizethe proposedmaintenance
taxonomy, effortdeterminant, decision
framework, andmethodology
(1)Mapped onto
(2)Compared with
The Synthesized CSA's ERPMaintenance-data-model
SEI Maintenance-data-model
(3)Proposed in
Figure 3.7: Data analysis process for CSA’s ERP maintenance-data-model
3.4 Validity And Reliability Of The Research Design
According to Maxwell (1996), threat to qualitative research design’s validity comes from
personal biases of the researcher and the participant’s reaction to the study. Some remedies
suggested by Maxwell are (1) give the study’s participants a chance to react to the study’s
data, the researcher’s interpretation of the data and study’s conclusions; (2) attempt to collect
3-25
comprehensive and descriptively rich data to lessen the likelihood of significant omissions;
(3) employ audiotape, and verbatim transcription of text (to minimize threat of inaccuracy);
and (4) seek “member checks” (i.e. to minimize threat of poor understanding or invalid
interpretation). These suggestions are very similar to Yin’s (1994) recommendations for
judging and dealing with qualitative research design quality. Yin reports that there are four
design tests common to all social science methods; they are construct validity, internal
validity, external validity and reliability. Yin, using the definitions given in (Judd et al., 1991),
explains that construct validity establishes correct operational measures for the concepts being
studied; internal validity establishes a causal relationship whereby certain conditions are
shown to lead to other conditions distinguished from spurious relationships; external validity
establishes the domain to which a study’s findings can be generalized; and reliability
demonstrates that the operations of a study can be repeated with the same results. Yin
proposes several tactics (for the four design tests) where the quality of a case study research
can be judged. They are multiple sources of evidence, chain of evidence, pattern-matching
and case protocol. More details for these tactics are tabulated in Table 3.9. Other authors such
as Merriam (1998), and Newman and Benz (1998) report that peer examination – asking
colleagues to comments on the findings as they emerge is useful for enhancing research
design’s validity. Most of these tactics are employed in this research in order to ensure and
establish the construct and internal validity. This is illustrated in . Table 3.10
External validity or generalization from qualitative research, as noted by Kvale (1996) in Lee
(1999) can be addressed through three judgments – naturalistic generalization, statistical
generalization and analytical generalization. Naturalistic generalization is based on the
researcher’s personal experience, whereas statistical generalization is based on formal notions
of random sampling, estimating parameters, and derivation of standard errors. Kvale states
that it would likely be a challenging endeavor to provide a compelling case for the former, and
the applicability of the latter is limited for qualitative research in general due to lack of
random sampling capabilities. Thus, Kvale advocates the use of the third approach –
analytical generalization. Similarly, Yin (1994) also agrees on using this analytical technique
in making generalizations from results obtained from case study (qualitative research)
method. This generalization is “a “reasoned judgment” [that] is made about whether the
results from one qualitative study, along with its particular context, can legitimately guide
inferences for another study, along with its particular context” ((Lee, 1999), page 158). In this
approach, an analysis of the similarities and differences between the contexts of two studies is
3-26
required. The stronger the similarities between the two studies the stronger the inference for
analytical generalization. Newman and Benz (Newman et al., 1998) find that the tactics to
improve the (analytical) generalizabilities of the results from qualitative research are (1)
applicability – establish the criteria that could allow comparable sample to be easily
identified, (2) context limited (transferability) – show that the findings are not context
dependent, and (3) replicability (consistency) – determine the factors/effects that could affect
the findings. Table 3.11 describes the tactics used to allow and enhance the generalization of
the findings in this research. More discussion the findings generalization will be given in each
sub-study and in Chapter 9, when sub-studies findings are sequentially and logically
presented.
Yin (1994) suggests in ensuring the reliability of a case study research design, two strategies
can be employed. There are writing a thorough case protocol and creating the case study’s
database. The case protocol should contain the following (pp. 64-65): (1) an overview of the
case study project, including the project objectives, case study issues and relevant readings
about the topic being investigated, (2) field procedures, case study questions, general and
potential sources of information, and (3) a guide for the case study report. On the other hand,
the case study’s database should list the physical data gathered from the case firms(s) in order
to lend itself to external inspection and reanalysis. Both of these strategies are used in this
study (see Appendix C and D) so that this study can be repeated. This is summarized in
.
Table
3.12
3-27
Table 3.9: Criteria to judge the quality of case study research
Research design validity test (Yin, 1994)
Tactics/Criteria to judge the quality of a study (Yin, 1994) in (Lee, 1999)
Construct validity 1. Use multiple sources of evidence (or triangulation) to achieve data triangulation in order to confirm the emerging
findings.
2. Establish chain of evidence – the obtained data should result from a sequential process that follows a clear and
compelling logic.
3. Have study-participants review draft case study report (member checks) in order to avoid incorrect interpretation
of the study’s data by researcher.
Internal validity 1. Pattern-matching – researcher generates a series of theoretically and conceptually relevant predictions and then
collects empirical data to test those predictions.
2. Explanation-building – researcher states an initial theory or a set of propositions and then examines the findings
from an initial case for its consistency with the theory or propositions. The initial propositions may be modified
depending on the judged fit. Researcher examines additional cases, judges them for fit and makes modifications.
3. Time-series designs – for causally connected event, researcher can examine case study data to verify the
predicted time sequence and infer evidence for internal validity to the extent that the time sequence is found hold.
External validity / generalization The case must be replicated in another situation – this focus on the analytical generalizability, which refers to the
extent an existing theory can serve as a template for evaluating the results of a case study.
Reliability 1. Write a thorough case protocol – it should specify an overview of the case study’s objectives and research issues,
field procedures and sources of information, case study questions and data analysis method, and the structure of
the case study report.
2. Create the case study’s database – listing of the physical data in order to lend itself to external inspection and
reanalysis.
3-28
Table 3.10: Construct and internal validity of this study
Construct validity tactics Internal validity tactics*
Sub-study Multiple source of evidence
Chain of evidence
Participant review Pattern-matching
Peer review/ examination (via paper submission for publication considerations)
Taxonomy X X X*
(Comparison is made with in-
house software maintenance
taxonomies)
5 reviewers
(2 – Journal of Systems and Software, 3 - IEEE
International Conference on Software Maintenance
2001)
Effort X X X
(Hypothesis testing)
-
Decision X X X*
(Comparison is made with in-
house software replacement
models)
6 reviewers
(3 – Journal of Software Maintenance: Research and
Practice, 3 – Americas Conference on Information
Systems 2001)
Methodology X X X X*
(Comparison is made with
Standard IEEE/EIA 12207.2-
1997)
7 reviewers
(3 - IEEE International Conference on Software
Maintenance 2002, 2 – Pacific Asia Conference on
Information Systems 2003, 2 – Hawaii International
Conference on System Sciences 2003)
Data X X X X*
(Comparison is made with SEI
– Framework for counting
problems and defects)
2 reviewers
(Australasian Conference on Information Systems
2001)
X = indicates that the tactic was used in the respective sub-study. * = this thesis shows that existing software maintenance taxonomies, replacement models, maintenance methodology, or maintenance-data-model is insufficient in the context of ERP.
3-29
Table 3.11: Criteria for judging the generalization of this study’s results
Criteria (Newman et al., 1998)
Characteristics of this study
Applicability
- Criteria that could allow
comparable sample to be
easily identified
Comparable sample
1. Government organization.
2. Service provider and a user itself.
3. The ERP system is the SAP R/3 system.
4. The installed SAP R/3 modules are Finance and Human Resources.
5. It maintains, as well as uses the ERP system.
Context limited
(transferability)
– Show that the findings are
not context dependent
Taxonomy sub-study
1. Widely accepted maintenance taxonomies from Swanson (1976) and Chapin et al. (2000) are studied and compared in
this sub-study.
2. Related ERP literature is compared with the sub-study’s findings to determine if the pattern(s) are similar.
Decision sub-study
1. Three major in-house software replacement models from Gupta et al. (1988), Gode et al. (1990), and Chan et al. (1996)
are studied and compared in this sub-study.
2. Related ERP literature is compared with the sub-study’s findings to determine if the pattern(s) are similar.
Methodology sub-study
1. Well-recognized maintenance methodologies from IEEE 1219 (1998) and IEEE/EIA 12207.2 (1997) are studied and
compared in this sub-study.
2. Related ERP literature is compared with the sub-study’s findings to determine if the pattern(s) are similar.
Data sub-study
1. Well-recognized maintenance-data-model by researcher and practitioner from SEI is studied and compared with the
findings in this sub-study.
2. Related ERP literature is compared with the sub-study’s findings to determine if the pattern(s) are similar.
3-30
Replicability (consistency)
– Determine the
factors/effects that could
affect the findings
All data obtained, captured and recorded are from an ERP organization that had implemented the SAP R/3 system and made
an upgrade decision for the first time.
It is a Government organization; service provider and a user itself; the ERP system is the SAP R/3; the installed SAP R/3
modules are Finance and Human Resources; and it maintains, as well as uses the ERP system.
Table 3.12: Reliability tactics applied in this study
Tactic (Yin, 1994) Is it used in this study? Case protocol X
(see Appendix C)
Case study’s database X
(see Appendix D) X = Yes, the reliability tactic is used in this study.
3-31
3.5 Summary
This chapter has discussed the case firm and case study method used in this research project.
Data collection and analysis methods and techniques are also discussed in detail. Table 3.13
summarizes the research method, data sources, data collected and data analysis used in
addressing the research questions proposed in this thesis. F , adapted from Gable
(1994), provides a detailed illustration of the research design in this research project.
igure 3.8
3-32
Table 3.13: Summary of the data sources and data analysis in each sub-study
Sub-study Research question Research method and data source
Data collected (from CSA)
Data analysis (on CSA’s data)
Taxonomy What is ERP maintenance?
What activities comprise ERP maintenance?
How can ERP maintenance activities be usefully
classified?
What are useful dimensions for classifying ERP
maintenance activities?
Are the existing maintenance classifications
appropriate?
Case study – interview,
change-request database,
user-support database.
Types of
maintenance
requests,
maintenance
problem type,
reason to do
maintenance,
request problem
description.
Pattern matching,
descriptive statistics,
comparing the data with the in-
house software.
Effort What attributes of maintenance effort are captured by
the case firm?
Which of these attributes are useful predictors of
maintenance effort?
How can maintenance effort be measured?
Case study – interview,
change-request database.
Time spent
servicing the
request,
characteristics of
maintenance
project.
Pattern matching,
descriptive statistics,
regression analysis.
Decision What are the factors that should be considered in
making ERP maintenance and upgrade decisions?
What are the major factors influencing ERP patch-
maintenance costs?
What are the major factors influencing ERP upgrade
costs?
Case study – interview,
change-request database,
patch database,
modification database,
documentation.
Factor affecting
maintenance and
upgrade decisions,
maintenance effort
drivers, upgrade
cost drivers.
Pattern matching,
descriptive statistics,
comparing the data with the in-
house software,
mathematical modeling.
3-33
Sub-study Research question Research method and data source
Data collected (from CSA)
Data analysis (on CSA’s data)
What are the opportunity costs for not doing ERP
maintenance and upgrade?
Are these factors that should be considered in an
ERP upgrade decision differed from those captured in
the existing in-house software replacement models?
How could these factors be included into cost
functions?
Methodology What activities and tasks should be incorporated and
reflected into an ERP maintenance methodology?
What are the activities associated with an ERP
maintenance methodology?
Are the existing software maintenance methodologies
appropriate in the context of ERP?
What are the activities and tasks that are unique to
ERP maintenance environment?
Case study – interview,
change-request database,
documentation.
Procedure and
steps involved in
maintenance and
upgrade activities,
maintenance
methodology.
Pattern matching,
comparing the data with the in-
house software.
Data What are the important ERP maintenance request’s
attributes that should be captured in an ERP
environment?
Do the attributes captured in in-house software
environment sufficient in the context of ERP?
What are the unique ERP maintenance request’s
attributes?
Case study – interview,
maintenance request
forms, change-request
database.
Maintenance data-
attributes.
Pattern matching,
comparing the data with the in-
house software.
3-34
5.Develop an
Empirical Modelfor ERP
MaintenanceEffort
4.Propose an ERP
MaintenanceTaxonomy
7.Develop an ERP
MaintenanceMethodology
ERP maint.category
ERPmaintenanceeffort model
ERPMaintenanceTaxonomy
(published inICSM 2001,JSS 2002)
ERP-Maintenance
Model(published inHICSS 2003,PACIS 2003)8.
Develop an ERPMaintenance-data-model
interview, change-req. db
interview, change-req. db, patch -support db, mod. db, documentation
Main contributions (oroutputs) from the study :
Data found from:- existing literature,- the case firm
ERPmaintenance-data-model
(published inACIS 2001)
1.Define Research
Questions
2.Review Literature
Researchproblem
Researchcontext andquestions
interviews,change-req. db,user-support db,patch-support db,
mod. db,documentation,
maint. req. forms
ERP:maintenance
activities,enhancement
optionsIn-house sw
maintenance:taxonomy,
effortdeterminant,replacement
model,methodology,SEI maint.-data-model
ERP maint.case protocol
interview, change-req. db, documentation
interview, maint. req. forms, change-req. db
IEEE/EIA 12207.2-1997
SEI maintenance-data-model
ERP upgrade cost drivers and elements
A decisionframework
for ERP MU(published inAMCIS 2001,JSME 2001)
in-house maint. taxonomies
interview,change-req.
db, user-support db
9.Summary,
Implications, andFuture Research
Implications toresearchers andpractitioner, andfuture research
directions
3.Develop Case
Protocol &Conduct Case
Study
ERP maint.activities(at maint.procedure
stage)
6.Construct ERP
Maintenance andUpgrade Decision
Framework
Figure 3.8: Detailed study design
3-35
4-1
4 An ERP Maintenance Taxonomy1
The objectives of this chapter are to: (1) produce a clear and concise definition of ERP
maintenance; (2) identify the salient dimension for characterizing ERP maintenance requests;
(3) determine if existing maintenance classifications are sufficient; and (4) propose a new
ERP maintenance taxonomy. This chapter aims to address the following research questions:
What is ERP maintenance? What activities comprise ERP maintenance? How can ERP
maintenance activities be usefully classified? What are useful dimensions for classifying ERP
maintenance activities? Are the existing maintenance classifications appropriate? The data
collection and data analysis process for this chapter was described in Section 3.3.1.
The organization of this chapter is as follows. Section 4.1 discusses the maintenance requests
and activities handled by CSA. Section 4.2 provides the descriptive statistics for these
maintenance requests. With better understanding of what is involved in an ERP maintenance
environment, Section 4.3 provides a definition of ERP maintenance. By analyzing the
information in Section 4.1 consolidated from multiple sources of evidence, Section 4.4
describes the dimensions for characterizing ERP maintenance requests. In order to determine
whether existing maintenance classifications are sufficient in the context of ERP, Section 4.5
demonstrates the results of mapping CSA’s maintenance requests onto existing maintenance
classifications. Addressing the insufficiencies identified in the existing maintenance
classifications, Section 4.6 presents the proposed ERP maintenance taxonomy. Lastly, Section
4.7 summarizes this chapter. This is summarized in Figure 4.1.
4.1 and 4.2CSA's ERP
MaintenanceRequests
4.6The Proposed
ERP MaintenanceTaxonomy
4.5Mapping ontoSwanson andChapin et al.'sMaintenanceClassification
4.4Salient
Dimensions forCharacterizing
ERP MaintenanceRequests
4.3Definition of ERP
Maintenance
4.7Summary
Figure 4.1: The flow of Chapter 4
1 Part of this chapter has been published in the International Conference on Software Maintenance (see (Ng et al., 2001c)) and this chapter has been published in the Journal of Systems and Software (see (Ng et al., 2002)).
4-2
4.1 CSA’s ERP Maintenance Requests: Description
CSA differentiates ERP maintenance activities into seven categories: CSA-enhancement,
user-enhancement, corrective, master-data-change, user-support, patch, and upgrade. CSA-
enhancement, user-enhancement, corrective, master-data-change, and user-support are
internally originated maintenance activities. Internally originated maintenance requests are
produced by two groups: CSA’s IT-staff, and the government departments (i.e. CSA’s clients,
including CSA itself) that outsource SAP to CSA. These government departments are referred
as the system users. CSA-enhancements are initiated by CSA IT-staff only, whereas user-
enhancements and user-support requests are introduced by the system users only. Corrective
and master-data-change can be initiated by either group.
Patch and upgrade activities are introduced by the software vendor, SAP. While system users
incur no incremental cost (from CSA) for maintenance requests related to master-data-change,
corrective, CSA-enhancement, user-support, patch or upgrade, costs associated with user-
enhancement does flow back to the system users. A change-request in this study refers to
either master-data-change, corrective, CSA-enhancement, user-enhancement, patch or
upgrade. CSA maintenance activities are summarized in Table 4.1.
Table 4.1: CSA’s maintenance request classification
Type Request Originator Database
Internal External
Sour
ce
Users CSA-IT Vendor
User-support User-support X User-support
Change-request User-enhancement X Change-request
Master-data-change X X Change-request
Corrective X X Change-request
CSA-enhancement
Inte
rnal
X Change-request
Patch X Change-request
Upgrade Exte
rnal
X Change-request
The SAP patches, implemented by CSA, are called legal-change-patches or LCP(s) by CSA
(more discussion is given in Section 4.2.4). Although the term LCP is used by CSA (see also
the direct quote from the interviews with CSA’s senior managers), it actually covers all types
4-3
of patches that are related CSA’s installed SAP R/3 system. According to CSA’s senior
manager, in version 3.1H LCPs contain not only corrections and adjustments for legal
changes in the Human Resources module, but also for the Finance module:
[…] These bug fixes and enhancements could be meant for any module in SAP. Hence,
an LCP may comprise some fixes and enhancements for manufacturing, some for
accounting, others for payroll, etc.— Systems Development Manager, March 2001.
Although the vendor distributes patches on a regular basis, it is the responsibility of the client
organization to implement them into their ERP systems. Interviews with CSA senior
managers found that CSA implements these patches for three main reasons, to:
(i) fix bugs in the existing system;
(ii) adapt to external environmental changes such as changed Government regulations;
and
(iii) keep the installed system up to the standard required by the vendor.
As regards point (iii), patches are sometimes implemented even though they may not be
relevant, useful or have impact on the functionality, programs or sub-modules (or the module
installed) used by the client-organization:
Some of these LCPs cover modules that are not used [in CSA]. Overall, the patches
have impact on 30% of our [CSA] implementation. However, for LCPs that cover the
modules used [by CSA], in particular modules such as HR where extensive changes to
the system have been made, then extensive impact analysis has to be done. Any
overwritten custom code will be carefully evaluated and tested. Irrespective of the
extent of impact an LCP introduced, only a small fraction (1-5% (max)) of the LCP is
deemed really useful [to CSA]. Despite the cost associated with incorporating LCP,
[CSA] has to incorporate all the LCPs to ensure that their implementation remain a
“standard SAP”— Systems Development Manager, June 2000.
Keeping an existing system up to the vendor’s requirements by applying the patches is
important. One of the senior managers notes:
4-4
This is because of two reasons: (1) a later LCP works only if earlier LCPs have been
incorporated. Thus, to ensure that [CSA] is able to exploit an LCP that may be useful,
it must also incorporate those that are not; and (2) upgrade cannot be done unless all
the LCPs prior to the new version have been incorporated— Systems Development
Manager, May 2000.
On the other hand, CSA upgrades to a new version for two main reasons2:
(i) to obtain new software functionality and more business improvement – i.e.
functional upgrade; and
(ii) to keep the system a supported-version – i.e. technical upgrade.
For point (ii) here, CSA’s Systems Development Manager notes:
Given the huge cost associated with upgrade […], CSA would not have decided to
upgrade if not for the fact that the vendor is withdrawing support for the version we
are currently using— Systems Development Manager, June 2000.
Table 4.2 includes detailed descriptions of the objectives and sample of activities of each
category of CSA maintenance requests. (The objectives and evidences of CSA’s ERP
maintenance categories are studied in detail here because they are the fundamental
characteristics addressed in Swanson and Chapin et al.’s maintenance classifications. The
objectives of these maintenance categories (i.e. in the second-column of Table 4.2) have been
gathered from interviews with CSA’s senior managers, whereas the evidence of maintenance
activities (i.e. in the third-column) is from data captured in the change-request and user-
support databases. The activities listed in Table 4.2 may not be comprehensive, but they
represent the majority of activities involved in each maintenance request category undertaken
by CSA. CSA patch-maintenance in this study is divided into three sub-categories based on
distinct maintenance objectives. Similarly, upgrade activity is usefully divided into two sub-
categories of activities that are different in nature and meant for different purposes. This table
will be intensively referenced in: (1) Section 4.4, where the dimensions for characterizing
ERP maintenance requests are identified; and (2) Section 4.5, where CSA’s maintenance
requests are mapped into Swanson and Chapin et al.’s maintenance classifications.
2 Note that no data analysis on upgrade requests is possible in this chapter because CSA was just considering its first upgrade decision during the initial data collection for this research project.
4-5
Table 4.2: Objective and activity-evidence of CSA’s ERP maintenance requests
CSA maintenance request category
Objective(s) (Obtained from interviews with CSA’s senior
managers.)
*Sample activities from change-request and user-support databases
(1) CSA-
enhancement
(Initiated by
CSA IT-staff
only)
Aimed at obtaining benefit (e.g.
best business practice,
integrated system) from the
SAP system, reducing the costs
of managing and operating the
system; and adapting the
system to a changed
environment.
Create report and error-message; change
interface and printing format; add
program; simplify reconciliation report;
additional functionality; update process
flow; check the accuracy of a program;
audit review; test efficiency of program;
prepare documentation; migrate
database; and restructure the new SAP
Unix environment.
(2) User-
enhancement
Meant to improve the
requesting system user’s
business process, including
modifying the SAP system to
satisfy unique user’s business
processes; and adapt the
system to the user’s operating
environment.
Develop new report and new feature in a
report; generate interface; create new
program or software functionality;
improve existing program functionality;
and make enhancement and change to
existing report.
(3) Corrective Aimed at fixing bugs in the SAP
system.
(However, whenever possible
for bugs in standard code, only
the relevant code in a patch is
applied not the whole patch.)
Correct duplicate records, incorrect
information and missing field in a report;
and fix computation error, rounding error,
page format, program error and interface
error.
(4) Master-data-
change
Deal with updates to the master
data file; documentation to
record the changes involved in
the system; and adapt to
changed environment.
Improve data file accuracy and
consistency; update the system
configuration file database; and add
access to report tree, table, functional
area, transactions processing and
program functions.
(5) User-support Meant to provide consultation
and assistance to the system
users regarding the system
functions, behaviors and any
difficulties associated with
Provide training details for the ERP
module; explain how the system is
functioning, operating and behaving;
describe how to interact with the system,
how to find and enter information into the
4-6
CSA maintenance request category
Objective(s) (Obtained from interviews with CSA’s senior managers.)
*Sample activities from change-request and user-support databases
human-computer interaction;
and provide education to the
system users on the software
functionality.
system, how to complete a transaction
using the system and how to get
something (report, receipt, printout) out of
the system; clarify details on the system
error-message; and confirm that a
transaction is done correctly.
(i) Fix bugs that are found in
the (vendor’s) standard
code by applying the whole
patch.
Implement patches supplied by the
vendor; and re-apply previous
modifications (if required).
(A patch may have very low or high
impact on CSA’s ERP system.)
(ii) Adapt the ERP system to
conform to a changed
environment, such as
Government regulations.
Implement patches supplied by the
vendor; and re-apply previous
modifications (if required).
(A patch may have very low or high
impact on CSA’s ERP system.)
(6) Patch
(iii) Keep the existing system
up to the vendor’s standard
version.
Implement patches supplied by the
vendor; and re-apply previous
modifications (if required).
(A patch may have very low or high
impact on CSA’s ERP system.)
(i) Technical upgrade, “like to
like functionality
replacement,” – to keep the
existing system vendor-
supported.
Replace existing system with a new
version (supported by the vendor) with the
same functionality (but a better technical
platform and performance); and re-apply
previous modifications (may result).
(An upgrade version has high impact on
CSA’s ERP system.)
(7) Upgrade
(ii) Functional upgrade –
providing major business
improvements and
enhancement benefits.
Add new functionality and enhanced
functionality.
* The activities evidence listed here may not be comprehensive but they represent good or dominant examples of the activities
involved in that maintenance request category.
4-7
4.2 CSA’s ERP Maintenance Requests: Basic Descriptive Statistics
This section presents the basic descriptive statistics, i.e. frequency and effort distributions, of
CSA’s ERP maintenance requests (as mentioned in Section 4.1) from the user-support and
change-request databases. Sections of 4.2.1-3 focus on CSA’s internally originated user-
support requests, and change-requests. This is followed by discussion on ERP vendor-
initiated maintenance activities – patches – in Section 4.2.4. Note that CSA batches the patch-
maintenance, therefore substantially reducing their frequency counts; this method does not
allow any comparison (of frequency counts) with the other maintenance categories.
4.2.1 Internally Originated Maintenance Requests: User-Support
User-support requests are introduced by CSA’s system users. These requests are for
consultation or assistance with the system functionality and usage, or training in the SAP
system. They are recorded in the user-support database. The data analyzed in this section is
based on the maintenance data recorded by CSA from 2 Nov 1998 to 27 June 2000. The
number of completed requests and the effort spent on this category of requests are shown in
Table 4.3.
Table 4.3: Distribution of maintenance effort in in-house software and ERP
In-house software * ERP (This study) Maintenance request
% of total effort
% of total effort
Sum of effort (hrs)
% of total # of
requests
# of completed requests
User-support 22 32 10,920 59 2,048
Change-
request
78 68 22,232 a 41 1,438
*Source: Abran et al. (1991)
a = based on the mean value for 593 completed maintenance projects.
A study by Abran et al. of in-house software maintenance showed that user-support requests
accounted for 22% of annual total maintenance effort (Abran et al., 1991). In this study, user-
support requests constitute 32% of total maintenance effort, over the study period of 20
months. (Note that this percentage is conservative, as the total maintenance time for 1438
change-requests is computed using the mean value (=15.5) from 593 completed maintenance
4-8
projects – more detail is provided later. If the median statistic (=5.24) is used, user-support
requests will constitute 59% of total maintenance effort. On the other hand, if the mode
statistic (=1) is used, user-support requests will account for 88% of total maintenance time. A
wide variance exists among the mean, median and mode statistics because the effort
distribution does not follow a perfect normal curve, and there are a number of complex
maintenance projects that required much larger amount of maintenance effort.) It is noted that
the external validity of this finding is limited because the cases compared here are both based
on a single organization.
In general, this finding supports the earlier suggestion that user-support in an ERP
environment may be more important than it is for in-house software. This may be because for
in-house software, system users participate in the software development process (such as
prototyping system development), and the system is built based on their business processing
requirements and in a way akin to how they always do business. Consequently, the system
users do not require as much user-support from the IT-staff as is required in an ERP
(packaged software) environment. Nevertheless, longitudinal study of the distribution of ERP
user-support requests would be valuable to further validate the findings in this section.
4.2.2 Internally Originated Maintenance Requests: Change-
Requests
Analysis of CSA’s internally originated change-requests (total of 1616 requests) shows that
64% (n=1031) are CSA-enhancement and 5% (n=81) are user-enhancement requests (see
Table 4.4). Reasons for the relatively smaller amount of system user-enhancements are: first,
a desire by requesting users to minimize incremental costs of CSA services; and second, CSA
tends to restrict user-enhancements, which usually involve writing custom code or making
changes to SAP code. Though the users pay for their enhancement work, CSA absorbs future,
ongoing costs of maintaining these enhancements. Corrective maintenance requests account
for 21% (n=347) of total requests, whereas master-data-change constitutes about 10% of the
total. (Of note is that the corrective requests, collected from CSA, comprise bugs found in
both customized code and in the standard SAP code.)
4-9
Table 4.4: Frequency count for internally originated change-requests
Frequency Count Internal change-requests
# (%)
CSA-enhancement 1031 64%
User-enhancement 81 5%
Corrective 347 21%
Master-data-change 157 10%
Total 1616 100%
Although there were 1616 maintenance requests in the CSA change-request database, only
1438 of these had been completed. From that figure, only 593 requests recorded the
effort/time spent in completing the requests. Table 4.5 shows the effort distribution among
CSA-enhancement, user-enhancement, corrective and master-data-change maintenance
requests for the 593 completed and valid maintenance requests.
Table 4.5: Effort distribution among the internally originated change-requests
Effort* Internal Change-requests
(hrs) (%)
CSA-enhancement 3857 42%
User-enhancement 2031 22%
Corrective 2585 28%
Master-data-change 695 8%
Total 9168 100%
* It is based on 593 valid data points.
It is observed that 64% of CSA’s total maintenance effort on internally originated change-
requests was spent on enhancement requests (Table 4.5); this is inclusive of both CSA-
enhancements and user-enhancements. Corrective requests command only 22% of the total
effort, whereas master-data-change requests take 8% of the total effort. In general, this study
confirms the findings of Glass and Vessey (1999), that enhancement maintenance is a major
ERP maintenance activity.
4-10
4.2.3 Distribution Of Change-Requests Versus User-Support
Requests
A time series is plotted in Figure 4.2; it shows the number of change-requests and user-
support requests arrived from 2 Nov 1998 to 27 June 2000. (The readers need to be careful,
since frequency count here is not representative of the amount of maintenance effort.) Figure
4.2 shows that the number of user-support requests is relatively larger than change-requests
during the first six to seven months after the SAP system was introduced at CSA. This is
because the CSA ERP system is: (1) a new system with which the users were not familiar, and
(2) a large system with substantially different interfaces from their earlier system. As a result,
they tended to seek advice, training and assistance during the first few months of using and
interacting with the system. It is further noted that during the first six months both the change-
requests and user-support requests were continually decreasing.
0
50
100
150
200
250
300
350
400
450
500
Nov-98
Dec-98
Jan-99
Feb-99
Mar-99
Apr-99
May-99
Jun-99
Jul-99
Aug-99
Sep-99
Oct-99
Nov-99
Dec-99
Jan-00
Feb-00
Mar-00
Apr-00
May-00
Jun-00
# of
Req
uest
s
# of Change-Requests # of User-Support Requests
HR introduced
FI introduced
Figure 4.2: Number of change-requests and user-support requests over time
Table 4.6 includes the rate of decrease based in the following formula:
Decrease rate (for current month) = (# of requests in previous month - # of requests in current
month) ÷ (# of requests in previous month) X 100%
In the seventh month (May 1999), both change-requests and user-support requests were found
to spike suddenly over 1580% and 100% respectively. This sharp increase in demand for
maintenance coincides with the introduction of an SAP Human Resources module (in late
April 1999). (The first peak, in November 1998, is in conjunction with the introduction of the
SAP Finance module.)
4-11
Table 4.6: Rate of change in number of requests per month
Change-request User-support requestMonth # Rate # Rate
Nov-1998 195 NA 459 NA
Dec-1998 109 -44% 205 -55%
Jan-1999 65 -40% 123 -40%
Feb-1999 34 -48% 134 +9%
Mar-1999 16 -53% 111 -17%
Apr-1999 12 -25% 118 +6%
May-1999 202 +1583% 241 +104%
Jun-1999 171 -15% 157 -35%
Jul-1999 180 +5% 115 -27%
Aug-1999 99 -45% 58 -50%
Sep-1999 74 -25% 58 0%
Oct-1999 64 -14% 29 -50%
Nov-1999 52 -19% 27 -7%
Dec-1999 51 -2% 36 +33%
Jan-2000 65 +27% 27 -25%
Feb-2000 52 -20% 40 +48%
Mar-2000 47 -10% 31 -23%
Apr-2000 35 -26% 20 -35%
May-2000 46 +31% 33 +65%
Jun-2000 47 +2% 26 -21%
Total 1616 - 2048 -
NA = not applicable
After the first seven months – i.e. when the users had become more familiar and confident
with the ERP system, the frequency of change-requests and user-support requests began to
decrease slowly over the subsequent 13-month period (Figure 4.2). In fact, after using the
ERP system for (the first) seven months, user-support requests became relatively fewer than
change-requests.
Alternatively, from the installation per module perspective, it is observed that (from Figure
4.2) the number of user-support requests will stabilize after two to three months of a
successful module implementation. It takes two months for the demands for user-support
requests for the Finance module to settle down and three months for both the Finance (FI) and
Human Resources (HR) modules. In general, it makes sense to expect a large number of user-
4-12
support requests during the first month after a new module is implemented (e.g., in November
1998 and May 1999). Such requests drop dramatically in the second (in December 1998 and
June 1999) and third months (of July 1999), and eventually the number of requests becomes
more or less the same thereafter. This finding provides some insights into human resources
requirements for helpdesk and other maintenance support, to management. As for change-
request, a consistent pattern between the FI and HR modules, in terms of changes in demand,
is also observed. However, the demand for change-requests seems to become stable five
months after both FI and HR go live.
4.2.4 Externally Originated ERP Maintenance Requests: Patches
There are only three patch-maintenance records for version 3.1H – in the change-request
database: two were completed, and one was still in progress during the first data collection
period. CSA batches the patches for maintenance purposes (refer to Table 4.7).
We have chosen to batch LCPs and apply the LCPs based on business need, this
becomes a problem when there is an LCP addressing a legislative requirement that we
require urgently as we then have to apply a backlog of LCPs. SAP seems to assume
that you are up to date — General Manager, May 2001.
For example, the first patch-maintenance consisted of 34 legal-change-patches (LCPs)
numbered 29 to 62. Note that the implementation of LCPs numbered 1 to 28 was not recorded
in the change-request database as they were done during the initial SAP system
implementation. The second patch-maintenance consisted of a batch of ten LCPs, numbered
63 to 72, and the third was a batch of eight LCPs, numbered 73 to 80. Essentially CSA
batches LCPs in this way to achieve economies-of-scale. CSA’s General Manager suggests:
[…] Implementing each patch individually would require several times the substantial
effort already expended here, and would take up 80% of CSA’s maintenance
resources. […] How one manages LCPs can have a huge impact on the costs of
maintenance, and, that one’s management strategy is to batch these periodically, and
to monitor patches for cumulative benefits and wait until the perceived benefits justify
the effort— General Manager, May 2001.
4-13
Table 4.7: Patch-maintenance
Maintenance Number of patches * Main objective Request-1 34 Keep the system up to the standard SAP.
Request-2 10 Keep the system fully Y2K compliant (for
adaptation).
Request-3 a 8 Adapt the system to the new taxation regulation –
GST.
Total 52 b
*For version 3.1H; a It was still not completed during the data collection period. b Does not necessarily represent the exact number of LCPs introduced by the vendor during the study period.
It was found that the first patch-maintenance request was primarily intended to keep the
system up to the standard SAP, in order that the second patch-maintenance could be
implemented. The second patch-maintenance was stimulated by the need to become fully
Y2K compliant, whereas the third patch-maintenance was motivated by the need to deal with
new tax regulations (i.e. Goods and Services Taxation – GST) in Australia.
To summarize findings so far, ERP-using organization maintains both maintenance originated
from system user and IT-staff and the vendor. The empirical data analysis on CSA ERP
maintenance activities supports the earlier suggestion that requests for user-support
(concerning the ERP system behavior, function and training) constitute a main part of CSA’s
ERP maintenance activities. It is observed that the number of user-support requests will
increase dramatically in the first two to three months of a successful module implementation,
and subside and stabilize thereafter. Benefit-realization is one of the main drivers for ERP
maintenance. Similar to in-house software environment, enhancement is the major
maintenance activity in CSA’s ERP environment, encompassing almost 64% of total change-
requests effort.
4.3 ERP Maintenance Definition
Based on the empirical data, discussed in Sections 4.1 and 4.2, this study defines ERP
maintenance as:
Post-implementation activities related to the packaged application software undertaken
by the client-organization from the time the system goes live (i.e. successfully
4-14
implemented and transported to the production environment) until it is retired from an
organization’s production system, to:
⇒ keep the system running,
⇒ adapt to a changed environment in order to operate well,
⇒ provide helps to the system users in using the system,
⇒ realize benefits from the system (best business processes, enhanced
system integration, cost reduction), and
⇒ keep the system a supported-version and meet the vendor’s
requirements for standard code.
These activities include:
⇒ implementing internal change-requests (initiated by an ERP-using
organization’s system users and IT-staff),
⇒ responding or handling user-support requests (initiated by an ERP-
using organization’s system users),
⇒ upgrading to new versions/releases (introduced by the vendor), and
⇒ performing patches (support provided by the vendor).
The first two objectives of ERP maintenance are similar to the objectives of in-house software
maintenance given by Swanson (1976). However, the third objective is not included; and the
fourth and fifth objectives are not fully applicable in the context of in-house software
maintenance. Both internal and external change-requests would entail changes to the system
properties such as data dictionary, programs, screens, user interfaces, and/or documentation.
(These comprise bug fixes, adaptation to the external environment, enhancement to existing
functionality, additional functionality, and maintaining the system up to the vendor’s
requirements (patches and new releases or upgrade versions). User-support is usually related
to software system training, and consultation on the system usage and functionality.)
4-15
4.4 Salient Dimensions For Characterizing ERP Maintenance Requests
Based on the analysis and discussions in previous sections, it is observed that ERP
maintenance requests can be usefully characterized along three salient dimensions: (1) source
of the maintenance request; (2) existence of any business benefit; and (3) the existence of any
impact of the maintenance on the client’s installed ERP module(s).
4.4.1 Maintenance Source
As demonstrated from CSA’s maintenance activities, both internally originated and vendor
originated maintenance are substantial. Thus, this dimension “maintenance source” comprises
the two main players: ERP-client and ERP-vendor.
4.4.2 Business Benefit
An observation from Table 4.2 in Section 4.1 is that some of the maintenance requests (such
as CSA-enhancements and user-enhancements) are implemented in order to realize more
business benefits from the system. Some of the CSA-enhancements are meant for obtaining
benefits, for example best practice/business processes, integrated system and cost reduction
from the SAP system, and some of the user-enhancements are to improve the requesting
system user’s business processes. CSA’s Systems Operations Manager states:
[…] In addition to cost reduction, a main driver of ERP maintenance and upgrade is
to maximize business benefit realization— Systems Operations Manager, June 2001.
This dimension, “business benefit”, distinguishes maintenance requests which bring business
benefits from those that do not. The classic maintenance intentions for keeping an installed
version up and running correctly and adapting the software to a changed environment, as well
as providing user-support are assumed to be mandatory and basic requirements before an
organization considers possible business benefit. A maintenance request can contribute to one
or more of the business benefits such as best practice or business processes, integrated system
and operational cost reduction. A request is perceived to bring business benefit if it:
4-16
(1) improves or enhances the way an organization does business – to streamline best
practice or business processes and enhance system integration;
(2) improves or enhances the existing ERP functionality; and/or
(3) could keep an existing version away from vendor-support termination – i.e. cost
effective.
4.4.3 Impact On Installed Module(s)
Based on the earlier discussion in Section 4.1 of the reasons, given by CSA’s senior manager,
for doing patch-maintenance and upgrades, it is found that while some of the maintenance
(support) introduced by the vendor has been useful, some not. A maintenance support is
perceived to be useful if it is related to and has impact on the module(s) installed on CSA’s
ERP system. Patches incorporating bug fixes (or improved functionality) for a module which
is not used by CSA, are perceived as having no impact on CSA’s ERP system. Besides
external requests, internal maintenance requests such as user-support requests also do not
affect the installed ERP module(s) when they are serviced or handled. Therefore, they have no
impact on the installed ERP module(s).
This dimension “impact on installed module(s)” indicates whether a maintenance request has
any impact in terms of:
(1) repairing, improving or enhancing, adding and/or deleting the functionality of the
client’s installed ERP module(s); and/or
(2) making changes to the ERP software properties, such as configuration files, reports,
tables, screens, interfaces, program documentation, documentation and so forth in the
client’s ERP module(s).
A request is said to have no impact if its implementation does not result in any changes at all
to the client’s ERP system’s functionality and/or ERP software properties.
4.4.4 An Illustration Using CSA As An Example
Figure 4.3 illustrates how different categories of CSA’s maintenance requests (presented in
Table 4.2) appear on a 3-D illustration of the three identified dimensions.
4-17
ERP-CLIENT ERP-VENDOR
Impact oninstalled
module(s)
HIGH
LOW(no
impact)
HIGHLOWBusinessBenefit
Maintenance Source
A
Legend:A = (Source: Client, Benefit: Medium/High, Impact: High; e.g. CSA-enhancement and user-enhancement)B = (Source: Client, Benefit: Low, Impact: Medium/High; e.g. corrective)C = (Source: Client, Benefit: Low, Impact: Medium; e.g. master-data-change)D = (Source: Client, Benefit: Low, Impact: Low; e.g. user-support)E = (Source: Vendor, Benefit: Low, Impact: Low/High; e.g. patch-maintenance for bug fix and adaptation)F = (Source: Vendor, Benefit: Medium, Impact: Low/High; e.g. patch-maintenance for standard code andtechnical upgrade)G = (Source: Vendor, Benefit: High, Impact: Medium/High; e.g. functional upgrade)
Impact oninstalled
module(s)
HIGH
LOW(no
impact)
HIGHLOWBusinessBenefit
A G
FE
D
C
B
Figure 4.3: Dimensions for characterizing ERP maintenance request
Area-A in Figure 4.3: Maintenance categories (1) CSA-enhancement and (2) user-
enhancement (refer to Table 4.2) are more likely located around Area-A, in Figure 4.3
because:
They are initiated by an ERP-client, i.e. CSA’s system users and IT-staff.
Some of them, which enhance business processes/practices, system integration and
existing functionality, or add new functionality to the system, will bring business
benefit(s) to CSA and system users.
These activities (obviously) impact on CSA’s (the client’s) ERP module(s), since they
are requested in order to make changes to the system.
Area-B in Figure 4.3: On the other hand, category (3) corrective (from Table 4.2) is more
likely to be found in Area-B, in Figure 4.3: it is an internal originated request. It does not
bring any additional business benefit but has impact on CSA’s ERP system installed
module(s).
Area-C in Figure 4.3: Maintenance category (4) master-data-change (from Table 4.2) –
pertinent to updating the master data file and documentation falls into Area-C of Figure 4.3
4-18
since it is introduced internally. This activity is mandatory for adapting to a changed
environment; however, it is unlikely to increase any business benefit to CSA (although if it is
not implemented, barriers to business benefits may result). This category impacts upon the
installed module(s) as it involves making changes to software properties such as tables, data
fields and data definition.
Area-D in Figure 4.3: Category (5) user-support – associated with the system training,
behavior, operation, usage and functionality (refer to Table 4.2) are likely situated in Area-D,
in Figure 4.3 as it is internally originated, but does not bring any business benefit since user-
support does not improve or change the installed module(s). Therefore, it does not have any
impact on CSA installed ERP module(s).
Area-E in Figure 4.3: Conversely, categories (6-i) patch-maintenance (for bug fixes) and (6-ii)
patch-maintenance (for adaptation to the client’s changing environment, refer to Table 4.2)
are likely situated at Area-E, in Figure 4.3.
They are introduced by the vendor.
These requests are for correcting bugs, and/or adapting the system to a changed
environment, where CSA is operating. However, they would not contribute to any
business benefit (although if they are not implemented, barriers to business benefits
may result).
They are perceived to have high impact on CSA’s installed module(s) if the patches
are relevant to its module(s).
Area-F in Figure 4.3: The maintenance categories (6-iii) patch-maintenance (for standard
code, and (7-i) technical upgrade (from Table 4.2) are more likely located around Area-F, in
Figure 4.3. This is because
They are vendor initiated.
They are likely to bring some business benefit to CSA because they keep an existing
version standard and avoid vendor-support termination.
They have impacts on CSA’s installed ERP module(s) as they would replace some (or
all) of the custom code in the client’s installed version with the vendor’s standard
code. In this case, reapplying previous modification-enhancements may result,
depending on CSA’s system users’ requirements.
4-19
Area-G in Figure 4.3: Maintenance category (7-ii) functional upgrade (refer to Table 4.2) is
likely located Area-G, in Figure 4.3. This is because:
It is a vendor-introduced maintenance activity.
A functional upgrade (involving substantially improved and new functionality
required by CSA) would allow CSA to realize significant business benefits from the
new system.
It is perceived as highly relevant to CSA’s ERP system functionality as it provides
new and improved functionality required by the client. (It is presumed that functional
upgrade will only be carried out provided the new functionality is perceived to be
useful.)
4.5 Mapping CSA’s ERP Maintenance Requests Onto Existing Maintenance Classifications
With further observations made in the previous section (specifically, the three salient
dimensions for characterizing ERP maintenance request) and better understanding of CSA’s
ERP maintenance activities, in this section, CSA’s ERP maintenance activities are mapped
into the existing in-house software maintenance classifications. The main objective is to
investigate whether the existing maintenance classifications are sufficient in the context of
ERP. CSA’s ERP maintenance activities in Table 4.2 are compared with Table 2.11
(Swanson’s software maintenance classification) in Section 2.5.2.1, and with Table 2.12
(Chapin et al.’s maintenance classification) in Section 2.5.2.2.
4.5.1 Results From Swanson’s Classification
Each of the CSA maintenance request categories is mapped onto Swanson’s (1976)
classification (refer to Table 2.11 in Section 2.5.2.1) based on the objectives or intentions of
undertaking maintenance (i.e. in column-2 of Table 4.2). The purpose is to discover which of
Swanson’s maintenance category(s) are relevant for describing CSA’s ERP maintenance
activities. The results are shown in Table 4.8.
4-20
Table 4.8: CSA’s maintenance request and Swanson’s maintenance classification
Swanson’s Category of Maintenance Activities CSA Maintenance Request Corrective Adaptive Perfective
CSA-enhancement — X X
User-enhancement — X X
Corrective X — —
Master-data-change — X —
User-support — — —
Patch (bug fix) X — —
Patch (adaptation) — X —
Patch (standard code) — — —
Technical upgrade — — —
Functional upgrade — — X
X = The maintenance activity falls under the proposed maintenance category.
Note that these mappings are approximations only; they are not one-to-one nor are they exact-
matches. For instance, it is found that CSA-enhancement fits both the adaptive and perfective
maintenance categories defined in Swanson’s maintenance taxonomy. This does not
necessarily imply that CSA-enhancement covers all activities described (in adaptive and
perfective) for the in-house software environment. For instance, CSA-enhancement does not
include the effort to improve the maintainability of the R/3 programs (used by CSA).
Results in Table 4.8 indicate that user-support, patches (for standard code), and technical
upgrades are not covered by Swanson’s maintenance classification. None of Swanson’s
maintenance categories are intended to encompass help desk or user-support, nor are intended
to keep the installed system a vendor supported-version.
4.5.2 Results From Chapin et al.’s Classification
The evidence of CSA’s maintenance activities (i.e. in column-3 of Table 4.2) is then mapped
into Chapin et al.’s (2001) maintenance classification (refer to Table 2.12 in Section 2.5.2.2),
which are defined based on the evidence of the maintenance activities, to identify which of
Chapin et al.’s maintenance category(s) are appropriate to explain CSA’s ERP maintenance
activities. The results are shown in Table 4.9.
4-21
Table 4.9: CSA’s maintenance categories and Chapin et al.’s maintenance classification
Chapin et al.’s category of maintenance activities Support interface Documentation Software properties Business rules
Maintenance category
Train-
ing
Consul-
tive
Evalua-
tive
Reforma-
tive
Upda-
tive
Grooma-
tive
Preven-
tive
Perfor-
mance
Adap-
tive
Reduc-
tive
Correc-
tive
Enhan-
cive
CSA-enhancement — — — X X — — X X X — X
User-enhancement — — — — — — — X X X — X
Corrective — — — — — — — — — — X —
Master-data-change — — — X X X — — — — — —
User-support X X X — — — — — — — — —
Patch (bug fix) — — — — — — — — — — X —
Patch (adaptation) — — — — — — — — X — — — Patch (standard code) — — — — — — X — X — — — Technical upgrade — — — — — — X — X — — — Functional upgrade — — — — — — — X X X — X
X = The maintenance activity falls under the proposed maintenance category.
4-22
From Table 4.9, it is noted that, technically, all CSA’s ERP maintenance activities could be
described by one or more categories of maintenance activities in Chapin et al.’s maintenance
classification. However, it is observed that Chapin et al. classification does not take into
account an important ERP maintenance characteristic, i.e. the business benefit of undertaking
the maintenance (see the characteristics of some of ERP maintenance requests in Figure 4.3).
Neither is this factor considered in Swanson’s maintenance classification.
This factor (i.e. business benefit of doing maintenance) is probably neglected in Swanson and
Chapin et al.’s maintenance taxonomies because they are mainly focused on the act of doing
maintenance such as enhancing program maintainability, improving the performance and
efficiency of programs (Swanson, 1976), operational efficiency (Vessey et al., 1983), and
system maintainability (Martin et al., 1983, page 85). In addition, traditional information
system (IS) is sometimes used for transaction processing and/or as an administrators’ tool to
establish control, as reported in (Davenport, 2000; Dhillon, 2000; Hammer et al., 1996). On
the contrary, ERP system maintenance is more focused on the business benefits (see also
(Irani et al., 2001; Murphy et al., 2002)). The primary motivation for ERP enhancement
among others is to realize more business benefits.
4.6 The Proposed ERP Maintenance Taxonomy
The analysis so far shows that the existing in-house software maintenance classifications are
lacking in the context of ERP. Thus, a new ERP maintenance taxonomy is required. The
proposed maintenance taxonomy consists of two levels. Level-1 of this taxonomy helps in
determining whether a maintenance request requires the taxonomy’s second level – benefit
categorization. The reason for this two-level maintenance taxonomy is that some ERP
maintenance requests bring business benefits but the mandatory maintenance requests do not.
Requests that could bring business benefits need to be identified and carefully treated in order
to quantify the benefits or opportunities of the requests and justify maintenance decisions. The
process involved in classifying an ERP maintenance request in the proposed maintenance
taxonomy is demonstrated in Figure 4.4.
4-23
Unclassifiedmaintenance
request
Level-1:Identifying
MaintenanceCategories
Has businessbenefit?
Level-2:Identifying Benefit
Categories
The Process of Identifying Client-Benefit Oriented Taxonomy in
ERP Maintenance
No
Yes
Classifiedmaintenance
request
Classifiedmaintenancerequest with
benefitidentified
(e.g.enhancement,
upgrade, patch(for standard
code))
(e.g. corrective, adaptive, user-support,patch (for correction and adaptation))
Figure 4.4: The process of identifying client-benefits oriented taxonomy of ERP maintenance
Level-1 includes classifying a maintenance request based on the three salient dimensions (for
characterizing ERP maintenance requests) identified and discussed in Section 4.4. This is
done by determining: (1) who the maintenance source is; (2) why it is important to service the
request – whether there is any business benefit; and (3) what – whether there is any impact of
implementing the request on the installed module(s). Figure 4.5 shows how the nine
categories of ERP maintenance requests are classified. The nine categories are enhancement,
adaptive, corrective, user-support, functional upgrade, technical upgrade, patch-maintenance-
adaptive, patch-maintenance-corrective, and patch-maintenance-standard.
4-24
Figure 4.5: Level-1 of the client-benefits oriented taxonomy of ERP maintenance
4-25
Level-2 involves classifying those requests with business benefit implications into the
respective category(s) of business benefits. From Figure 4.5, the four categories of ERP
maintenance requests that require further benefit categorization are enhancement, functional
upgrade or minor enhancement, technical upgrade, and patch-maintenance – for keeping the
installed system up to the standard required by the vendor. Based on the literature3 in Section
2.3, this study proposes five main categories of benefits for ERP maintenance activities.
These five categories are competitive advantage, globalization, integrated system, best
practices or business processes, and cost reduction. These benefit categories are also partially
substantiated by the empirical findings from CSA. The categories of integrated system, best
business practices, and cost reduction have been mentioned by CSA’s senior managers as the
benefits of maintaining their ERP system but not the competitive advantage, and globalization
categories. This is not surprising due to CSA’s role as a government organization.
The viewpoint of a senior manager (IT-manager and/or business manager) is assessed in
categorizing maintenance requests from the business benefit perspective. This is determined
based on the business reason, objective, or intention of doing the maintenance request. Table
4.10 shows the primary objectives or intentions of the five business benefit categories distilled
from the prior studies and trade literature on ERP benefits, as well as the types of changes
(maintenance) that could be made to the system. It is argued that, depending on the
maintenance objective(s) or intention(s) and scope, a maintenance request is not necessarily
contributing to a single benefit only. For instance, a request whose primary business benefit is
to provide a better integrated system could also trigger, lead to and result in other benefits
such as cost reductions in producing and manufacturing a product, facilitating the
implementation of a best practice that was previously not possible, enhancing the potential for
operating in worldwide markets, and/or providing opportunities for new markets. This
example can be traced using Figure 4.6 which provides a snapshot of the possible inter-
connectivity among the business benefit categories. In sum, it is important for a manager to
first determine the primary objective of a maintenance request in order to precisely and
unambiguously identify the benefit category(s) to which it is contributing. Details of a method
for quantifying the benefit(s) delivered in a maintenance request are shown in Chapter 6.
Table 4.11 shows the benefits potentially delivered by the four ERP maintenance categories.
3 The advantages of developing the benefit categorization from the existing literature are that validity is increased, and that generalization of the proposed benefit categorization is enhanced.
4-26
Table 4.10: Benefit categorization in ERP maintenance request
Category Primary objective or intention Type of changes (maintenance) Competitive
advantage
Increase market share, business
opportunity (thus, enhance revenue
generation), customer loyalty,
customer satisfaction, service quality
Adopt advanced technology
Add new functionality
Globalization Facilitate global access to customer,
supplier and business partners, and
vice versa
Enhance information flow and system
integration with customers, suppliers
and business partners
Integrated
system
Improve integration among internal
business processes, enhance data
management and accuracy of
decisions
Improve integration among
application modules and processes in
the system
Best practices /
business
processes
Enhance efficiency and effectiveness
in business processes and business
performance/revenue, and shorten
cycle times
Reengineer or redesign processes
Cost reduction Minimize cost (to the company) Upgrade to supported version
Replace custom code with standard
code
Integrated System
CompetitiveAdvantage
Cost Effective /Reduction
GlobalizationBest Practice /
BusinessProcesses
Figure 4.6: Connectivity among the business benefit categories
4-27
Table 4.11: ERP maintenance category and business benefit category
The proposed business benefit categories Maintenance category Best
practices Competitive advantage Globalization
Integrated system
Cost reduction
Enhancement X X X X X
Patch-maintenance
(standard code) — — — — X
Technical upgrade — — — — X
Functional upgrade X X X X X
X = Indicate that the maintenance activity has the potential to deliver the benefit-category.
4.7 Summary
Observations made from the analysis of CSA ERP maintenance activities are: (1) the ERP-
using organization does not only maintain internally originated change-requests, but also
implements maintenance introduced by the vendor; (2) requests for user-support concerning
the ERP system behavior, function and training constitute a main part of ERP maintenance
activity; (3) benefit realization is one of the main drivers for ERP maintenance; and (4)
similar to the in-house software environment, enhancement is the major maintenance activity
in the ERP environment, encompassing almost 64% of total change-request effort (this is
consistent with the findings from Glass and Vessey (1999)). In light of these and other
findings, ERP maintenance is defined as post-implementation activities until the system is
disposed from the production system; targeting at keeping the system running correctly,
operating well in a changed environment and providing user-support, as well as realizing
more business benefits and maintaining the installed system a supported version; and covering
both internally and externally originated maintenance requests.
ERP maintenance requests can be usefully characterized along three salient dimensions: (1)
source of the maintenance request; (2) the existence of any business benefits; and (3) the
existence of any impact of the maintenance on the client’s installed ERP module(s). The
findings show that ERP maintenance is not an instance of in-house software maintenance. The
existing in-house maintenance taxonomies are not sufficient to capture the characteristics of
ERP maintenance activities. They are lack consideration for an important ERP maintenance
characteristic, i.e. the involvements of the external party (the software vendor) in maintaining
4-28
an ERP software; and the (categorization of) business benefit of undertaking the maintenance.
Thus, an ERP-specific maintenance taxonomy tailored to its environment is proposed.
The proposed ERP maintenance taxonomy represents an extension beyond the modern-view
of maintenance activities classification, in two ways: (1) it covers vendor-initiated
maintenance activities; and (2) it classifies the relevant maintenance activities based on the
benefit perspective. Although enhancement activities in in-house software may also have
significant impact on the way the employing-organizations do business, (to the knowledge of
the author) there is no maintenance taxonomy proposed to classify the maintenance category
based on the benefit perspective.
This understanding of the types of CSA’s ERP maintenance requests and activities are used:
(1) to study whether maintenance request type is a good determinant of maintenance effort in
Chapter 5; and (2) as part of the decision alternatives in developing an ERP maintenance and
upgrade decision framework in Chapter 6. The proposed ERP maintenance taxonomy is: (1)
recommended as the technique to use in classifying ERP maintenance requests in the ERP
maintenance methodology suggested in Chapter 7; and (2) used as a guide to determine the
maintenance attributes to be gathered, in Chapter 8, in order to facilitate categorization of
maintenance requests (using the proposed maintenance taxonomy).
5 Characteristics Of The Maintenance Project Affecting ERP Maintenance Effort
The objective of this chapter is to identify the maintenance project characteristics affecting
ERP maintenance effort, and build an empirical effort model. The primary research question
addressed in this thesis is: What attributes of maintenance effort are captured by an ERP-
using organization? Which of these attributes are useful predictors of maintenance effort?
How can maintenance effort be measured? The data collection and data analysis processes for
this chapter were described in Section 3.3.4. Of note is that, this chapter focuses on the
characteristics of a maintenance project affecting ERP maintenance effort. The data available
(from CSA) for analysis is only those of the internally originated change-requests, which have
been discussed in great detail in Chapter 4. Effort determinants for user-support requests, and
externally originated change-requests, such as patch-maintenance and upgrades, are not
included in this chapter or in this thesis. But, more discussions on factors affecting the
externally originated change-requests are given in Chapter 6.
The organization of this chapter is as follows. Section 5.1 discusses the hypotheses for the
sub-study. Section 5.2 presents the basic descriptive statistics on the independent variables.
(One of the independent variables considered in this sub-study is CSA’s ERP maintenance
category, which was covered in the previous sub-study.) Section 5.3 describes how strong
each of the independent variables is in explaining the variance in maintenance effort.
Variables that are found to be influential in explaining ERP maintenance effort are used in
Section 5.4, where multivariate linear regression analysis is conducted. Section 5.5 presents
some discussions on the comparability of the findings in this chapter with prior studies.
Section 5.6 provides a summary of the chapter. This is illustrated in Figure 5.1.
5-1
Chapter 4:Taxonomy
Chapter 5:Effort
CSA's ERP maintenance categories
5.2Basic DescriptiveStatistics for the
independentvariables
5.3Regression
Analysis
5.4Multivariate LinearRegression Model
5.5Comparability of
findings with priorstudies
5.6Summary
5.1Hypothesis
Figure 5.1: The flow of Chapter 5
5.1 Hypothesis
Literature review in Chapter 2, Section 2.5.3 shows that maintenance category, task
complexity, and tailoring option are potential factors (i.e. maintenance project characteristics)
influencing in-house maintenance effort. These factors or maintenance attributes were also
recorded in CSA’s change-request database. Thus, they were used as independent variables in
this sub-study. Only three variables are considered in this sub-study, due to the limited
amount of data available. The following section describes the characteristics of the three
independent variables and their hypotheses.
Maintenance Category
CSA classifies their internally originated change-requests into four main categories:
corrective, CSA-enhancement, user-enhancement and master-data-change. Corrective is a
bug-fix request in order to keep the system operational. While CSA-enhancement is system
enhancement initiated by CSA’s IT-staff (to improve the efficiency and effectiveness of the
whole SAP system), user-enhancement is requested by the system users (to enhance business
processes related to their user departments). Master-data-change is related to maintaining data
accuracy and consistency, and updating the master data file in the SAP system. Thus, this
independent variable consists of four categorical variables.
The categorical variable named corrective is considered as the reference category. It is chosen
because (i) it has some substantive importance, such that it is a common request and yet it is
crucial to keep the software system up and running, and (ii) it contains a sufficient number of
5-2
cases, where the means can be estimated reasonably precisely for making comparison with the
other pertinent categories (Bryman et al., 2001).
Hypothesis: Different maintenance requests involved different maintenance activities and
different amount of maintenance effort. For instance, enhancements are subject to a larger
amount of effort for requirements analysis, designing solutions, and conducting impact
analysis, verification and testing, whereas other requests require minimal effort for system
verification and testing.
Therefore, it is expected that:
Maintenance category is a significant predictor of maintenance effort.
Task Complexity
CSA ranks task complexity based on a 5-point scale, where “1” denotes very low and “5”
very high task complexity. This is independent variable is an ordinal variable.
Hypothesis: Higher task complexity projects will likely require more maintenance effort than
the lower task complexity, as higher task complexity projects are likely to cover more difficult
and complicated tasks. In practice, it is expected that increase in task complexity does not
keep pace with increase in maintenance effort. This is because there is a ceiling to task
complexity rank (i.e. 5 – in this case). Based on scatter plot of CSA data set between
maintenance effort and task complexity, no linear relationship is observed. Thus, it is
expected that:
Maintenance effort will increase curvilinearly with task complexity.
Tailoring Option
CSA classifies each of the maintenance requests/projects into several tailoring options (or
types of changes made to the software) to facilitate problem resolution. They include
configuration, ABAP/SAPscript2, extended reporting, interface development, other
programming activities, technical, documentation, security, business process, process flow,
and so forth (see Tables 3.2, ProblemType). Due to the limited number of cases for most of
these tailoring options, ABAP/SAPscript, extended reporting, interface development and
other programming activities were grouped together and named “programming”. These
2 SAPscript form is a template provided by SAP to facilitate and simplify clients’ business forms design process.
5-3
categories were grouped together because they have similarities: they are involved in
developing custom objects and are related in some sort of programming or coding activities.
More than 87% of the completed maintenance projects are in the category of configuration or
programming. Similarly, in order to avoid having an insufficient number of cases, all the
remaining categories (such as technical, documentation, security, business process, process
flow, and so forth) are collapsed into a category called “other.”
A maintenance project is classified as configuration if the system configuration file(s) need to
be modified or changed in order to resolve the problem. On the other hand, if a project is
identified as programming, this means that programming activities are involved – either by
using code from the vendor3, writing new or changing existing code, interface, report and/or
user screen. (As discussed in the literature review in Section 2.1.1, there are nine types of
ERP system tailoring option: configuration, user exit, bolt-on, screen masks, extended
reporting, workflow programming, ERP programming, interface development and package
code modification (Brehm et al., 2001). CSA’s configuration tailoring option corresponds to
Brehm et al.’s configuration type. On the other hand, CSA’s programming tailoring option
may relate to any one of Brehm et al. definitions for – user-exit, extended reporting, workflow
programming, ERP programming, interface development and package code modification.)
The ‘other’ category will cover requests which are non-configuration and non-programming.
Thus, tailoring option comprises three categorical variables.
Hypothesis: Programming-related requests are likely to require more maintenance effort than
configuration-related maintenance requests, as programming-related requests involve greater
amounts of effort in analyzing, designing, developing, verifying and testing custom objects
(compared to configuration-related requests, which are handled by setting the configuration
tables provided by the vendor). On the other hand, configuration-related request (handled by
setting parameters or configuration tables) are likely to require less maintenance effort than
other (i.e. non-configuration and non-programming) requests. As a consequence, it is
expected that:
Configuration-related requests will require less maintenance effort than programming-
related maintenance requests.4
3 This does not include implementing a ‘whole’ patch; only the relevant standard code is applied. 4 Brehm et al. (2001) hypothesize that the greater the impact of tailoring in the ERP system (configuration is assumed to have the least impact), the more likely an ERP-using organization will experience difficulties (i.e. more effort is required) when attempting to upgrade. Their study focuses more on upgrade effort. This study hypothesizes that configuration maintenance activities will require less maintenance
5-4
Other (non-configuration and non-programming) requests will require less
maintenance effort than programming-related maintenance requests.
Configuration-related requests will require less maintenance effort than other (non-
configuration and non-programming) maintenance requests.
Details on the variable names and variable data types for each group of independent variables
(or factors affecting maintenance effort) are shown in Table 5.1.
Table 5.1: List of independent variables considered in the study
Factor Variable name Variable type
Description
Corrective Dummy* A corrective maintenance project is designed for
fixing bugs in the system (does not include the
activities of implementing a patch from the
vendor).
User-
enhancement
Dummy An enhancement maintenance project initiated by
the system-user.
Master-data-
change
Dummy A maintenance project meant for updating the
master data files.
Maintenance
category
CSA-
enhancement
Dummy An enhancement maintenance project initiated by
CSA’s IT-staff.
Task
complexity
Complexity Ordinal Represents the task complexity of a project; it is
ranked on a 5-point scale, where “1” denotes very
low and “5” very high task complexity.
Programming Dummy * Indicates that a maintenance option is related to
writing or modifying code using the vendor’s
proprietary programming language.
Configuration Dummy Indicates that a maintenance option is related to
the system’s configuration file(s).
Tailoring
option
Other Dummy Indicates that a maintenance option is NOT
related to either the program code or system
configuration file(s).
* Indicates that the dummy variable is used as the reference category.
effort than is required for programming maintenance activities. More emphasis is given to maintenance (i.e. servicing the request) effort than to upgrade effort.
5-5
5.2 Basic Descriptive Statistics: The Independent Variables
As mentioned in Section 3.3.2, only 593 out of 1438 projects recorded the time spent in
completing the projects. As a result, 593 maintenance projects were used in the data analysis
and discussion. These 593 completed maintenance projects required 1,146 working days (of 8
working-hours per working-day) to complete. In this chapter, the terms ‘maintenance project’
and ‘completed maintenance request’ are used interchangeably. The measurements for these
variables are shown in Table 5.2.
Table 5.2: Characteristics of maintenance project and the measurements
Characteristic Measure Maintenance category Change-request type
Task complexity A 5-point scale, where “1” denotes very low
and “5” very high task complexity
Tailoring option Type of changes to the software
5.2.1 Maintenance Category
Out of 593 maintenance projects, 45% of them are enhancement (38% is CSA-enhancement
and 7% is user-enhancement), and 38% is corrective maintenance (see Table 5.3). The rest of
the maintenance activities are master-data-change.
Table 5.3: Maintenance category and maintenance effort
Effort (hours) Request Maintenance category
Min Max Mean Std.
deviation Sum % N % Corrective 0.25 154.15 11.59 18.12 2585.04 28 223 38
User-enhancement 0.25 482.61 47.23 92.09 2030.78 22 43 7
Master-data-change 0.08 124.36 7.02 17.736 694.57 8 99 17
CSA-enhancement 0.18 194.9 16.92 30.63 3857.03 42 228 38
Total - - 15.46 35.05 9167.42 100 593 100
Both Table 5.3 and Table 4.5 in Chapter 4 show that 64% of total maintenance effort was
spent on enhancement activity, and 28% on corrective maintenance. In other words, corrective
5-6
maintenance projects seem to cost 2.5 times less effort than enhancement projects. It is
revealed that on average, each enhancement request initiated by the system’s user took much
longer time to satisfy than any other types of requests; it is almost three times (47.23 hours)
the average time taken to satisfy the enhancement requested by CSA IT-staff (16.92 hours).
This is because unlike user-enhancement, CSA-enhancement is usually made around the
standard SAP code. By comparison, the average amount of effort to service a corrective
maintenance request (12 hours/request) and master-data-change (7 hours/request) are
relatively lesser than the average effort required in a CSA-enhancement maintenance request.
This is described by the actual task involved in corrective and master-data-change. Corrective
maintenance involves activities such as correcting page formats, reports, error-messages, and
user interfaces. Master-data-changes comprise simpler tasks such as updating master file and
database (see Table 4.2 in Chapter 4).
5.2.2 Task Complexity
More than 38% of CSA maintenance projects have very low task complexity (see Table 5.4).
Approximately 38% of the total projects have low task complexity. Twenty-one percent of the
projects are ranked medium task complexity; the remaining 3% are ranked high task
complexity. (From the collected maintenance projects data, no project has very high task
complexity. According to CSA’s Systems Development Manager, very high complexity is for
an upgrade project.) In general, the mean effort increased as the complexity of maintenance
projects increased.
Table 5.4: Task complexity and maintenance effort
Effort (hours) Request Complexity rank
Min Max Mean Std.
Deviation Sum % N % 1 (= very low) 0.08 95.25 6.66 11.54 1511.78 16.5 227.0 38.3
2 0.18 106 9.96 15.10 2230.99 24.3 224.0 37.8
3 0.68 181.86 27.52 36.53 3494.92 38.1 127.0 21.4
4 16.06 482.61 128.65 131.77 1929.73 21.0 15.0 2.5
5* (= very high) - - - - - -
Total - - 15.46 35.05 9167.42 100 593 100 * is usually for an upgrade project.
5-7
5.2.3 Tailoring Option
The average time taken to fulfill a programming-related maintenance request (15.02 hours)
was found to be almost identical to that for a configuration request (14.27 hours). CSA spent
47% of its maintenance effort on programming-related project and 36% of the maintenance
effort on problems related to configuration (Table 5.5). The former indicates that
configuration-related requests (or maintenance requests involved in making configurations to
an ERP system) may not be as simple as they sound. Depending on the types of configuration,
some configurations are complicated (Bancroft et al., 1998).
Table 5.5: Tailoring option and maintenance effort
Effort (hours) Request Tailoring option
Min Max Mean Std.
deviation Sum % N % Programming 0.18 482.61 14.85 35.63 3771.04 41 254 43
Configuration 0.08 280.37 14.27 30.73 3338.03 36 234 39
Other 0.25 252.15 19.60 42.04 2058.36 23 105 18
Total - - 15.46 35.05 9167.42 100 593 100
5.3 Regression Analysis
The objectives of this section are to:
Test the hypotheses, explained and stated in Section 5.1 and summarized in Table 5.6.
Examine and identify which of the independent variables are the most influential, and how
much of the variance is explained.
Table 5.6 presents the reference category for each of the dummy variables for the factors (i.e.
independent variables) considered and the respective hypotheses tested in this study. As
mentioned in Section 5.1, a reference category is chosen based on the following criteria: (1) it
has some substantive importance, for example corrective maintenance is a common request
and yet it is crucial to keep the software system up and running; and (2) it contains a sufficient
number of cases, where the means can be estimated reasonably precisely for making
comparison with the other pertinent categories (Bryman et al., 2001).
5-8
Table 5.6: Reference categories for the independent variables
Hypothesis Factor
Reference category
Other category Relationship* DescriptionUser-
enhancement
+
Master-data-
change
-
Maintenance
category
Corrective
(model 1)
CSA-
enhancement
+
Maintenance category is a significant predictor of maintenance effort.
Task
complexity
NA
(model 2.1 – linear
model, model 2.2-2.4
– polynomial models)
NA NA Maintenance effort will increase nonlinearly with task complexity.
Configuration - Configuration-related requests will require less maintenance effort than
programming-related maintenance requests.
Programming
(model 3.1)
Other - Other requests (non-configuration) will require less maintenance effort than
programming-related maintenance requests.
Tailoring
option
Other
(model 3.2)
Configuration - Configuration-related requests will require less maintenance effort than other
(non-configuration and non-programming) maintenance requests.
* It is relative to reference category.
5-9
The statistics considered in the following discussion on linear regression models are the
coefficient βi, adjusted R2, and R2. The coefficient βi measures the difference between the
dummy or interval variable representing the variable of interest and the reference category.
The adjusted R2 statistic is studied in order to learn more about the results of regression
equation. According to Myers et al. (1995), in comparison with R2, adjusted R2 provides a
more realistic indication of how well the population is fit by the sample regression equation
(p. 509). Models 1 to 3 are linear regression models, which consider a single independent
variable one at a time.
Model 1
Model 1 consists of three dummy variables for the three categories of CSA’s change-requests,
with corrective as the reference category. It is as shown:
Y = β10 + β11D11 + β12D12 + β13D13 + µ Model 1
where Y = maintenance effort (in hour)
D11 = 1 if maintenance category was “user-enhancement”
D12 = 1 if maintenance category was “master-data-change”
D13 = 1 if maintenance category was “CSA-enhancement”
D11 = D12 = D13 =0 if maintenance category is “corrective”
µ = sample error
The results obtained are5:
Ŷ = 11.592 + 35.635D11 + (-4.576)D12 + 5.325D13
Adjusted R2 = 0.07, F-value =15.837
Model 1 is significant, even though the adjusted R2 is small (0.07). The adjusted R2 shows
that the model explains about 7% of the variance in maintenance effort at CSA’s site.
The coefficient for user-enhancement is significant but not for master-data-change and CSA-
enhancement. The significant coefficient for user-enhancement means that it consumes more
effort than is consumed by corrective maintenance. The difference between these two groups’
5 The estimates of β0, β1, β2 and β3 were obtained using the least-squares criterion, where b0, b1, b2 and b3 were obtained such that the prediction equation minimized the mean squared error, MSE = (1/N)Σ(Y – Ŷ)2, the measure of prediction error (Myers et al., 1995).
5-10
mean is 35.635 hours. Note that the constant term (i.e. 11.592) is equal to the mean for
corrective maintenance (see also Table 5.3). Conversely, master-data-change does not require
less effort than corrective, and CSA-enhancement does not require more effort than corrective
because their coefficients are not significant.
In general, result in model 1 shows that, the hypothesis that maintenance category is a
significant predictor of maintenance effort, is supported.
Model 2
Model 2.1 is a linear model, and comprises an ordinal independent variable for the task
complexity. Model 2.2-2.4 are polynomial models. This is summarized as:
Y = β20 + β21X + µ Model 2.1
Y = β20 + β21X + β22(X)2 + µ Model 2.2
Y = β20 + β21X + β22 (X)2 + β23 (X)3 + µ Model 2.3
Y = β20 + β21X + β22 (X)2 + β23 (X)3 + β24 (X)4 + µ Model 2.4
where Y = maintenance effort (in hour)
X = the complexity rank for maintenance project
µ = sample error
In light of X, X2, X3, and X4 in polynomial models often will be highly correlated and
therefore, can cause multicollinearity or collinearity problem, the predictor (X) is centered (in
order to reduce multicollinearity substantially (Neter et al., 1999)). Thus, the predictor
variable in model 2.1 to 2.4 is centered around its mean ( X ) and written as:
Y = β20 + β21x+ µ Model 2.1’
Y = β20 + β21x+ β22(x)2 + µ Model 2.2’
Y = β20 + β21x + β22 (x)2 + β23 (x)3 + µ Model 2.3’
Y = β20 + β21x + β22 (x)2 + β23 (x)3 + β24 (x)4 + µ Model 2.4’
where XXx −=
5-11
All of the above models are significant at the 0.001 level; this is summarized in Table 5.7.
Based on R2 statistics, model 2.3’ and 2.4’ are better fit than model 2.1’ and 2.2’. Even
though improvement to model 2.3’ compared to model 2.2’ is not a very large one, the scatter
plot based on the predicted value of y versus task complexity rank (for both models 2.2’ and
2.3’) lead the author toward the cubic model as a better fit for this relationship. On the other
hand, both model 2.3’ and 2.4’ have the same R2 (i.e. 0.323) but only the most simple and
parsimonious model is preferred. Thus, the hypothesis that maintenance effort will increase
curvilinearly with task complexity, is supported.
Table 5.7: Linear and polynomial models for task complexity
Variables Coefficient Model 2.1’ Model 2.2’ Model 2.3’ Model 2.4’ Intercept b20 15.426 3.425 10.177 9.009
Complexity b21 17.067 9.872 -2.334 7.665
Complexity-power-2 b22 17.56 2.971 2.069
Complexity-power-3 b23 11.552
Complexity-power-4 b24 4.658
R2 0.163 0.287 0.323 0.323
Adjusted R2 0.161 0.284 0.320 0.320
F-test 114.706 118.697 93.756 93.756
Model 3
Model 3.1 includes two dummy variables for the two categories of tailoring option, with the
programming as the reference category. This is as shown:
Y = β30 + β31D31 + β32D32 + µ Model 3.1
where Y = maintenance effort (in hour)
D31 = 1 if tailoring option was “configuration”
D32 = 1 if tailoring option was “other”
D31 = D32 = 0 if tailoring option was “programming”
µ = sample error
The results obtained are:
Ŷ = 15.021 + (-0.756)D31 + 5.824D32
Adjusted R2 = 0.000, F-value = 1.044
5-12
Model 3.2 includes two dummy variables for the two categories of tailoring option, with the
other as the reference category. This is as shown:
Y = β33 + β34D33 + β35D34 + µ Model 3.2
where Y = maintenance effort (in hour)
D33 = 1 if tailoring option was “configuration”
D34 = 1 if tailoring option was “programming”
D33 = D34 = 0 if tailoring option was “other”
µ = sample error
The results obtained are:
Ŷ = 19.603 + (-5.338)D33 + (-4.757)D34
Adjusted R2 = 0.000, F-value = 0.908
All the coefficients in Model 3.1 and Model 3.2 are insignificant except for the constant term.
As observed from model 3.1, maintenance projects/ requests that are related to configuration
does not save maintenance effort by 0.756 hour compared to programming tailoring option;
and other tailoring options do not require 5.824 hours more that programming-related
problem. The adjusted R2 for the model is 0.000, which indicates that the tailoring option
factor explains none of the variance in maintenance effort at CSA’s site. From model 3.2, it is
also observed that configuration-related requests do not necessarily require lesser
maintenance effort than other (i.e. non-programming and non-configuration) maintenance
requests. This finding is consistent and reconfirms one of CSA’s senior manager’s
observations that tailoring option is not a significant predictor of ERP maintenance effort.
The hypotheses, that configuration-related and other (i.e. non-configuration) requests will
require lesser maintenance effort than programming-related maintenance requests, are
rejected. In addition, there is no evidence that configuration-related tailoring option will
require a lesser maintenance effort than is required for other (i.e. non-configuration and non-
programming) maintenance requests. Some examples of the configuration related project
requiring large amount of maintenance effort are: changing wage types linked to some
symbolic accounts, creating an event to extend temporary end date, creating leave type code
5-13
for temporary extension, and incorporating a new center holiday. On the other hand, examples
of non-configuration and non-programming projects requiring large amount of maintenance
effort are those associated with large reporting project, improving accuracy of the leave
entitlement and finance posting, year-end processing issues, and testing efficiency of some
program. More explanation of this phenomenon is given in Table 5.12. Further research is
required to confirm this finding. For instance, it would be interesting to perform a cross-
analysis of different types of tailoring options with respect to different categories of CSA’s
maintenance requests, observe how maintenance (or upgrade) effort is affected by different
tailoring options and determine if the hypotheses proposed by Brehm et al. in (Brehm et al.,
2001) are supported. However, due to limited data, this further analysis is not possible here.
Table 5.8 shows the data available and the real data analyzed in Model 3.
Table 5.8: Cross-tabulation between maintenance category and tailoring option
Tailoring option Maintenance category Programming Configuration Others
Total
Master-data-change 2 77 20 99
CSA-enhancement 102 76 50 228
User-enhancement 27 11 5 43
Corrective 123 70 30 223
Total 254 234 105 593
In conclusion, among the independent variables of maintenance category, task complexity,
and tailoring option, task complexity is the most influential variable, explaining 32% of
variance in maintenance effort at CSA’s site. The second influential variable is maintenance
category, which explains 7% of variance in maintenance effort at CSA’s site. Tailoring option
fails to provide convincing results to that they are significant determinants of ERP
maintenance effort.
5.4 Multivariate Linear Regression Model
The results from the linear regression analysis in Section 5.2 indicate that task complexity and
maintenance category independent variables are significant predictors of maintenance effort at
CSA’s site. In this section, multivariate regression model incorporating the dominant
5-14
predictors of ERP maintenance effort is proposed, and interaction effects between predictors
are examined.
(Analysis of influential points was conducted using the Cook’s distance measure. It is used to
quantify “changes in all the residuals when a given case is deleted and thus is a measure of
influence of that case on the regression equation” (SPSS, 2001, p. 6-2). There is only one data
point having Cook’s distance exceeding 1 (i.e. 1.88). However, this extent of the influence
may not be large enough to call for consideration of remedial measures. Thus, it is included in
the prediction equation (the multivariate regression model) so that the prediction equation
presents all the cases collected from CSA site.)
5.4.1 Regression Model Without Interaction Term
The multivariate regression model (without interaction effect) is as follows:
Y = β0 + β1D1 + β2D2 + β3D3 + β4x + β5 (x)2 + β6 (x)3
+ µ Model 4.1
where Y = maintenance effort (in hour)
D1 = 1 if maintenance category was “user-enhancement”
D2 = 1 if maintenance category was “master-data-change”
D3 = 1 if maintenance category was “CSA-enhancement”
D1 = D2 = D3 =0 if maintenance category was “Corrective”
x = centered/deviation score for the complexity rank of the maintenance project
= XX −
µ = sample error.
The fitted response function is:
Ŷ = 8.581+ 23.5D1 + (-1.705)D2 + 1.569D3 + (-2.074)x + 2.582(x)2 + 10.980(x)3
Details of the multivariate regression model are as illustrated in Table 5.9. The constant term
indicates the expected maintenance hours when all dummies for the maintenance category are
set to zero, including the task complexity variable. This (the constant term) is equivalent to a
scenario where the maintenance request is a corrective and the task complexity is set to zero.
Since task complexity cannot be zero the intercept has no substantive meaning here. But it
5-15
must be included so that the dummy/indicator variables can be properly calculated and
interpreted.
Table 5.9: The multivariate regression model (without interaction term)
Variables Coefficient Estimate Standard error
t-value p-value*
Intercept b0 8.581 2.676 3.207 0.001** User-enhancement b1 23.5 4.783 4.913 0.000** Master-data-change b2 -1.705 3.44 -0.496 0.62 CSA-enhancement b3 1.569 2.837 0.553 0.58 Complexity b4 -2.074 2.709 -0.765 0.444 Complexity-power-2 b5 2.582 3.084 0.837 0.403 Complexity-power-3 b6 10.98 2.021 5.432 0.000** R2 0.353
Adjusted R2 0.346
F-test 53.226
s=0.000** *Two-tailed test; ** is significant.
5.4.2 Regression Model With Interaction Term
The multivariate regression model (with interaction terms) is as follows:
Y = β0 + β1D1 + β2D2 + β3D3 + β4x + β5 (x)2 + β6 (x)3
+ β7D1 x+ β8D2x + β9D3 x + µ
Model 4.2
where D1 x = interaction term between user-enhancement and complexity
D2 x = interaction term between master-data-file and complexity
D3 x = interaction term between CSA-enhancement and complexity
In order to test for the presence of interaction effects, the t-statistic is utilized (Table 5.10).
For level of significance 0.05, it is required that t (0.975, 593-10-1=582) = 1.96. The
interaction term between user-enhancement and complexity with | t | = 6.837 > 1.96 is
significant. However, since for interaction between master-data-change and complexity | t | =
1.855 < 1.96, and interaction between CSA-enhancement and complexity | t | = 0.178 < 1.96,
it is concluded that their interaction effects are not supported by the two-sided P-value for the
t-tests. Therefore, only the first interaction effect will be included in the final multivariate
regression model. In comparison with model 4.1, the regression model 4.2 is a better fit for
5-16
the data set with R2 = 0.406, which means that it explains 41% of variance in maintenance
effort at CSA’s site.
Table 5.10: The multivariate regression model (with interaction terms)
Variables Coefficient Estimate Standard error
t-value p-value*
Intercept b0 6.979 2.621 2.663 0.008**
User-enhancement b1 21.729 4.614 4.709 0.000**
Master-data-change b2 0.593 3.676 0.161 0.872
CSA-enhancement b3 3.836 2.82 1.36 0.174
Complexity b4 -3.737 3.111 -1.201 0.23
Complexity-power-2 b5 4.761 3.101 1.535 0.125
Complexity-power-3 b6 7.936 2.014 3.941 0.000**
Interaction between user-
enhancement and complexity
b7 31.659 4.63 6.837 0.000**
Interaction between master-data-
change and complexity
b8 8.503 4.584 1.855 0.064
Interaction between CSA-
enhancement and complexity
b9 0.623 3.499 0.178 0.859
R2 0.406
Adjusted R2 0.397
F-test 44.241
s=0.000** *Two-tailed test; ** is significant.
With these results, regression analysis on model 4.2 but omitting the mentioned two
insignificant interaction terms is re-run. The regression model and fitted response function are
respectively:
Y = β0 + β1D1 + β2D2 + β3D3 + β4x + β5 (x)2 + β6 (x)3
+ β7D1 x Model 4.3
Ŷ = 7.802+ 21.528D1 + (-2.443)D2 + 3.119D3 + (-2.432)x + 3.88(x)2 + 8.311(x)3 +
30.176D1 x
R2 = 0.402, Adjusted R2 = 0.395, F-value = 55.22
Model 4.3 is significant at 0.001 level, and it explains 40% of variance in maintenance effort
at CSA’s site. Collinearity statistics and diagnostics are also conducted on model 4.3; they are
5-17
shown in Table 5.11. The results are as follows: (1) the tolerance values are not in the danger
area (i.e. around 0.01), (2) the variance inflation factor (VIF) is not very large, (3) the
eigenvalues are not close to zero, and (4) the condition index is not greater than or equal to
value of 30 (SPSS, 2001).
Table 5.11: Collinearity statistics and diagnostics
Collinearity statistics Collinearity diagnostics Variables
Tolerance VIF Dimension Eigenvalue Condition index
Intercept 1 2.912 1
User-enhancement 0.877 1.14 2 1.76 1.286
Master-data-change 0.822 1.216 3 1.096 1.63
CSA-enhancement 0.706 1.416 4 0.934 1.766
Complexity 0.27 3.709 5 0.655 2.108
Complexity-power-2 0.233 4.296 6 0.421 2.63
Complexity-power-3 0.113 8.832 7 0.17 4.143
Interaction between user-
enhancement and complexity 0.793 1.262 8 0.052 7.487
The response function for model 4.3 can be rewritten in an earlier form by substituting XXx −= , where the mean for task complexity, X = 1.88. This gives us:
Ŷ = 7.802+ 21.528D1 + (-2.443)D2 + 3.119D3 + (-2.432)(X – 1.88) + 3.88(X – 1.88)2 +
8.311(X – 1.88)3 + 30.176D1 (X – 1.88)
and is simplified as:
Ŷ = 8.311X3 + (-42.994)X2 + 71.101X + (30.176X – 35.203)D1 + (-2.443)D2 + 3.119D3 +
(-29.132)
In general, user-enhancement with task complexity =1 has the lowest maintenance effort that
any other maintenance request types. However, for the task complexity greater than 1 the
maintenance effort required for user-enhancement request is about 2 to 6 times greater than
other maintenance request types. This is demonstrated in Figure 5.2. The effect of maintaining
a master-data-change, controlling for the effect of task complexity, is predicted to result in a
reduction of 2.443 hours in maintenance effort (as compared with the corrective), holding
other explanatory variables constant. In contrast, an increase of 3.119 hours in maintenance
5-18
effort is expected for a CSA-enhancement request (as compared with the corrective). Note
that this coefficient is different from those shown in Model 1 because it depends upon the
other variables in the equation. The coefficient of each variable, in the joint regression with
maintenance category and task complexity, is computed by controlling for the other variables
in the model. The estimated coefficient for the task complexity variable in the multivariate
model indicates that a one point increase in the task complexity, holding other explanatory
variable constant, leads to curvilinear increase in maintenance effort.
0
20
40
60
80
100
120
140
160
180
200
1 2 3 4
Task complexity
Mai
nten
ance
effo
rt (Y
)
If D1=1 (user-enh.) If D2=1 (master-data-file)if D3=1 (CSA-enh.) D1=D2=D3=0 (corrective)
Figure 5.2: Illustration of regression model 4.3 - maintenance effort
5.5 Comparability Of The Findings With Prior Studies
The statistical analysis suggests that, among the four maintenance project characteristic
variables, maintenance category, task complexity, and tailoring option, the task complexity
and maintenance category variables are significant predictors of maintenance effort at CSA’s
site. On the contrary, tailoring option is insignificant predictors of maintenance effort. Table
5-19
5.12 summarizes the results of the hypotheses tested in this study and attempts to provide
possible explanation for and implications of the rejected hypotheses.
Note that no direct comparison of the findings in this study can be made with previous studies
summarized in Table 2.17 in Section 2.8.2. This is not due to the nature of the software but
because of:
Differences in unit of measurement for the independent variables:-
For example the studies results from in-house software (Abran et al., 1993; Jørgensen,
1995; Lientz et al., 1980; Niessink et al., 1998) divide maintenance activities into
perfective, adaptive and preventive. However, preventive requests are unlikely to be
comparable with any of CSA’s maintenance categories.
Also, low-levels of details on the types of changes done to the software in previous
studies, such as changes of module, control flow, data declaration and interface
(Jørgensen, 1995; Niessink et al., 1998), would not produce an accurate comparison if
they are to compare with the high-level of details on the type of changes done to ERP
software in this study, for instance configuration and programming.
However, there are a few findings from this study which are found to be consistent with prior
results on in-house software. This is summarized in Table 5.13.
5-20
Table 5.12: Hypotheses results
Hypothesis Result Explanation for the rejected Maintenance category is a significant predictor of
maintenance effort.
Supported -
Maintenance effort will increase nonlinearly with
task complexity.
Supported -
Configuration-related requests will require less
maintenance effort than programming-related
maintenance requests.
Rejected This is a counter-intuitive finding. It indicates that configuration related maintenance
activities (overall) are unlikely to require less effort than programming related
maintenance activities. This could be because of the complexity associated with
configuration. According to Gulla et al. (2000), SAP system has more than 8,000
configuration tables. Bancroft et al. (1998) hint that the complexity of configuration
depends on the type of configuration (see Section 2.1 in Chapter 2 for more details).
Other requests (non-configuration) will require
less maintenance effort than programming-related
maintenance requests.
Configuration-related requests will require less
maintenance effort than other (non-configuration
and non-programming) maintenance requests.
Rejected It is not surprising that this category does not produce a convincing result. It is meant to
combine all the different sub-categories of tailoring options, from modifying the business
process to documentation. Thus, this implies that whenever possible it may be better to
analyze each of these categories separately. (As mentioned in Chapter 3, Section 3.3.2,
the (physical separation of these sub-categories) is not possible in this study because
the number of cases for each of these categories is insufficient, compared with
configuration and programming categories. In some instances there was only one
instance for each category!)
5-21
Table 5.13: Similarity in findings between ERP and in-house software maintenance
Maintenance factor
Findings
Maintenance
category
Finding from the basic descriptive statistics in this study shows that significant
difference in mean values exists between corrective and user-enhancement. This
agrees with Jørgensen’s (1995) finding that proves significant difference in mean
values exists between corrective and perfective (as well as, between corrective
and adaptive).
Task
complexity
This study finds that higher task complexity will require more maintenance effort
than lower task complexity. This is consistent with Jørgensen’s (1995) finding that
there is a positive association between task complexity and maintenance effort.
5.6 Summary
The attributes of maintenance effort captured by CSA are maintenance category, task
complexity, and tailoring option. Maintenance effort is measured (by CSA) using the number
of hours spent in servicing the request. The findings so far suggest that among the three
maintenance project characteristics or independent variables of maintenance category, task
complexity and tailoring option, task complexity is the most influential variable explaining
32% of the variance in maintenance effort at CSA’s site. The second most influential variable
is maintenance category, which explains 7% of variance in maintenance effort at CSA’s site.
The tailoring option variable fails to provide convincing results to be significant determinants
of maintenance effort.
The supported hypotheses are: (1) maintenance category is a significant predictor of
maintenance effort; and (2) maintenance effort will increase curvilinearly with task
complexity. These findings are consistent with the in-house software study conducted by
Jørgensen (1995). The rejected hypotheses are: (1) configuration-related requests will require
lesser maintenance effort than programming-related maintenance requests; (2) other requests
(non-configuration and non-programming) will require less maintenance effort than
programming-related maintenance requests; and (3) configuration-related requests will
require less maintenance effort than other (non-configuration and non-programming)
maintenance requests. These are counter-intuitive findings. On top of this, a multivariate
5-22
regression model with interaction term is developed and the model could explain 40% of
variance in maintenance effort at CSA’s site.
These findings (of the determinants of maintenance effort) are: (1) incorporated in the
proposed ERP maintenance and upgrade decision framework in Chapter 6 as factors to be
considered in estimating the amount of maintenance effort required for a maintenance project;
(2) included in the proposed ERP maintenance methodology as factors to consider in planning
for maintenance budget allocation; and (3) integrated in the proposed ERP maintenance-data-
model in Chapter 8 as part of the fundamental maintenance attributes to be collected.
5-23
6 An ERP Maintenance and Upgrade Decision Framework1
The objectives of this chapter are: to identify the factors affecting ERP maintenance and
upgrade decisions, to investigate if existing replacement models are adequate in the context
of ERP, and to develop an ERP MU decision framework. ERP maintenance and upgrade
decisions in this study refer to identifying the amount of ERP client-initiated maintenance
requests and vendor-introduced patches to implement, and/or the timing to upgrade an
installed ERP system with a readily available version (from the same vendor). Maintenance
and upgrade (MU) decisions will be used together because they are inextricably inter-related
(as the upgrade can be postponed by continuing to maintain the existing system), and upgrade
is a major maintenance activity. This study addresses the following research questions: What
are the factors that should be considered in making ERP maintenance and upgrade decisions?
What are the major factors influencing ERP patch-maintenance costs? What are the major
factors influencing ERP upgrade costs? What are the opportunity costs for not doing ERP
maintenance and upgrade? Are these factors that should be considered in an ERP upgrade
decision (i.e. replacing an existing version with a newer version from the vendor) differed
from those captured in the existing in-house software replacement models?2 How could these
factors be included into software maintenance and upgrade cost functions? The data
collection and data analysis process for this chapter is described in Section 3.3.5.
This chapter is organized as follows. Section 6.1 describes the factors affecting (ERP)
external change-requests (e.g. patch-maintenance and upgrade) costs. Section 6.2 discusses
the main driver for ERP maintenance and upgrade (MU) activities. Section 6.3 compares the
findings on ERP MU decision making environment with the in-house software replacement
models, and provides the implication for these findings. Section 6.4 presents a decision
framework for ERP maintenance and upgrade. Various research findings and results from
previous chapters are used and incorporated in the proposed decision framework. For
1 Majority of the findings in this chapter have been published in the Journal of Software Maintenance and Evolution (Ng, 2001a). Preliminary work on this chapter has been published in the Americas Conference on Information Systems (Ng, 2001b). 2 The author is not equating ERP upgrade with in-house software replacement but to investigate whether the factors considered in existing replacement/rewrite models are useful and relevant in the context of ERP. It is noted that replacement is an important issue to ERP vendors and upgrade is to ERP clients. However, vendors’ replacement issues are not the focus in this thesis.
6-1
instance, better understanding of CSA’s ERP maintenance requests outlined in Chapter 4 has
allowed identification of the (possible) MU decision alternatives at CSA. The factors
influencing ERP maintenance effort, described in Chapter 5, are utilized in the proposed MU
decision framework as additional factors to consider in estimating maintenance effort. The
link between the output from Chapter 5 and this chapter is illustrated in Figure 6.1. A
numerical example is given to illustrate how the framework could be used to make some
maintenance decisions. Section 6.5 shows a general ERP maintenance and upgrade decision
model and a numerical example is provided to show how the model can be used to make an
upgrade decision. Lastly, Section 6.6 summarizes the chapter. This is shown in Figure 6.2.
Figure 6.1: Connection between Chapter 5 and Chapter 6
6-2
Chapter 4:Taxonomy
Chapter 5:Effort
6.1Factors AfectingExternal Change-requests Costs
6.3Implication fromthe Findings forthis Research
6.4A Framework for
ERP Maintenanceand Upgrade
Decisions
6.5A General ERP
Maintenance andUpgrade Decision
Model
6.2Reasons to Do
Maintenance andUpgrade
Chapter 6:Decision
6.6Summary
CSA's ERP maintenance classification
ERP internal change-requests(maintenance) effort determinants
Figure 6.2: The flow of Chapter 6
6.1 Factors Affecting External Change-Requests Costs
From the literature review in Section 2.1-2.3 and observations made in Chapter 4, it is known
that ERP-using organization implements both internal maintenance requests, originating from
systems users or IT-staff; and external maintenance requests for patch-maintenance and new
version upgrade, coming from the ERP software vendor. Chapter 5 has discussed the potential
maintenance project characteristics influencing the internally originated change-requests
effort (thus, the costs) whereas this section focuses on externally originated change-requests
effort and costs.
6.1.1 Patch-Maintenance3
Data analysis on CSA’s two large patch-maintenance projects shows that the average effort
per patch is 46 hours (see Table 6.1). By comparison with CSA’s internally originated
change-requests, it is found that on average a patch is almost as effort demanding as a user-
enhancement request (refer to Table 5.2 in Chapter 5). The average number of hours per
patch for the first project (57 hrs/patch) is observed to be much larger than the second (10
hrs/patch). This could be explained by the following factors: (1) experience (with the first
patch-maintenance) has effectively improve efficiency in maintenance effort; (2) the batch
size of 34 (resulting in 57 hrs/patch) may not be as effective as the batch-size of 10 (resulting
3 Patch-maintenance is called legal change patch (LCP) at CSA site.
6-3
in 10 hrs/patch; and (3) the number of and characteristics of the modules involved in a patch
may have impacts on total effort required for maintenance. However, based on the data in
Table 6.1, the number of notes per patch (in this case) does not seem to be a critical factor
influencing patch-maintenance effort, as they are almost the same in both projects and yet the
average number of hours per patch in these projects is considerably different. ‘Notes’ refer to
either a bug fix or a minor enhancement in a patch. Nonetheless, characteristics of these notes
are worth further investigation. More empirical data is required in order to validate the
significance of these findings.
Table 6.1: Patch-maintenance effort
Patch Project # of patches
# of Notes Notes/patch
Effort (Hrs) Hrs/Note Hrs/patch
Project-1*
(Patch # 29-62) 34 4406 130 1918 0.44 57
Project-2
(Patch # 63-72) 10 1212 121 99 0.08 10
Total 44** 5618 128 2017 0.36 46
*The project for patch # 1-28 had been implemented earlier but was not recorded in the change-request database.
**Does not necessarily represent the exact number of patches introduced by the vendor during the study period.
Patch-maintenance accounts for approximately 18% (or 2017 hours) of CSA’s total ERP
maintenance effort. Consistent with the literature (400-Group, 1998; Collins, 1999),
interviews with CSA’s Systems Development Manager confirm that patch-maintenance effort
is driven by the amount of modification done and type of tailoring already made to the
standard ERP code.
Anything that you can’t do using standard configuration then it becomes modification.
If you’ve got customized changes, the patch or upgrade will overwrite them [for those
objects changed by both ERP client and the vendor] and bring them back to standard
code. Modifications cause us the grief. They’re our actual task to continually do—
Systems Development Manager, March 2001.
They [modifications] will revert to the SAP standard, so you’ve got to reapply [them].
Anything that you change […] prior to a patch implementation, you will have to go
6-4
through each of the [previous] changes or modifications to determine if the patch
changes any of them— Systems Operations Manager, March 2001.
6.1.2 New Version Upgrade
Interviews with CSA’s senior managers and review of the Upgrade Business Case show that,
on top of the cost of data conversion, system analysis, system integration and testing, and
post-implementation turmoil (Jakovljevic, 2001; Slater, 1998) (see also Chapter 2, Section
2.2.2), an upgrade implementation cost depends on the version-gap or migration-path between
an installed and a new upgrade version.
For instance, if we go from 3.1H to 3.1I that won’t be a very tough process at all
because they are in the same three-series. The cost is not going to be very substantial
at all, probably about $200 thousand. However, in implementing a major upgrade,
which involves migrating from the three-series to four-series and there are input
screen changes, it is going to cost around $2-3 million just to do technical upgrade.
Also, due to the changes in input screen, all documentation has to be changed and
extensive re-training of staff is required. This will be a big cost driver. Basically, the
cost depends on the magnitude of change with respect to the architecture, and
screen— Systems Development Manager, June 2000.
Consistent with the trade press, upgrade cost is a major issue, and prohibitive for CSA in
considering its ERP system upgrade.
6.1.2.1 Impact On Previous Modification-Enhancement4 CSA is an example of an ERP client that upgrades its ERP system (for technical upgrade)
because of the withdrawal of the vendor’s support for its current version of 3.1H. An upgrade
process will replace the installed ERP system by the standard / vanilla ERP version of the new
version. Previous enhancements that were done by setting system parameters, or using
customer objects or customer exits, which adhered to SAP strict naming conventions, will not
be affected by the upgrade process (nor a patch implementation). Modification-enhancements,
or enhancements involving modifications of SAP code or software objects will be
4 It refers to enhancement that has impact on upgrade effort.
6-5
overwritten. Basic steps involved in an upgrade (or patch implementation) to identify its
impacts on previous enhancements are: (1) analyzing if the previous developments (e.g. those
built using system parameters, customer exits or customer objects) are working properly in
light of the changes to SAP standard code or objects; and (2) investigating if all the previous
enhancements, which were developed by using the tailoring options from (2) to (9) discussed
in Chapter 2, Table 2.2, are affected or overwritten. This is usually signaled in the form of a
warning/error message to inform the client organization of these changes. Chapter 7 provides
more details on the activities involved in an upgrade process. Depending on the new
functionality in the new version, some of the overwritten enhancements may need to be re-
applied. Re-testing will be required after re-entering the previous modification-enhancements.
This will impact on the upgrade cost.
An analysis of the number of modification-enhancements done on the installed version of
SAP system, from the system implementation date until the system-development-is-frozen-
for-upgrade date, was conducted by a consulting firm for CSA. An interesting result of the
impact of an upgrade on previous modification-enhancements was found. Based on the
consulting firm’s investigation on CSA’s installed version 3.1H, and new capabilities and
functionality in version 4.6C, the number of modification-enhancements to be done on the
upgrade decreased by one-third of the original total already done on the old version (see Table
6.2). These enhancements were done using the tailoring options from (2) to (9), discussed
earlier in Chapter 2, Table 2.2. Note that these enhancements will have an impact on the total
effort required for upgrading the SAP system (or for implementing a patch-maintenance
project in the future).
Table 6.2: Comparison of total number of modification-enhancements before and after a new
version upgrade
Before Upgrade* Immediately After the UpgradeNumber of previous
modification-
enhancements
730 498
* From system-implementation date until the system-development-is-frozen
Existing literature and empirical data from this study (see Section 6.1.2) suggest that support
package or patch-maintenance effort is driven by the number of modification-enhancements.
In light of this, together with the decrease in the total number of modification-enhancements
6-6
after upgrade, it is expected that maintenance cost and effort on a new upgrade version would
be reduced compared to the continuing maintenance of an existing / installed version. This
could be a significant advantage for organizations considering an upgrade option. The
decrease is mainly because of the modification-enhancements are either now available in the
new version, or are no longer required. This benefit factor should be considered as one of the
trade-offs in considering an ERP upgrade decision.
6.1.2.2 Impact On Future Patch-Maintenance An analysis of the number of notes, where each note represents a fix or a minor enhancement
or improvement to the ERP system, introduced in each of the patches initiated in the SAP R/3
version 3.1H, 3.1I, 4.0B, 4.5B, 4.6B, and 4.6C (up to the end of June 2001 only), shows that
the total number of notes and patches decreases from an older version to a newer version (see
Figure 6.3). It is found that, on average, the number of notes decreases by about 44% (from
one version to another) since the last three versions (from 4.0B to 4.6B). On the other hand,
the number of patches decreases by about 21% from an older version to a later version.
Hence, with this incentive it is expected that ERP-using organizations would be able to trade-
off this cost reduction (in addition to the cost component mentioned in Section 6.1.3.1)
against the upgrade cost in order to better justify their upgrade decision (instead of delaying
the upgrade decision, which also leads to delays in benefit-realization and higher maintenance
costs for the installed version).
1006617725
48179
11801 10425 95450
10000
20000
30000
40000
50000
60000
3.1H 3.1I 4.0B 4.5B 4.6B 4.6C (st illgoing on)Version of SAP
# of
Not
es
0102030405060708090100
# of
LC
Ps
# of Notes # of LCP
Figure 6.3: SAP versions with the respective number of patches and notes
It is noted that factors such as the characteristics of each version, number of users associated
with each version, and external technology changes, are also worth further investigation in
6-7
order to refine the findings here. For example, a larger number of users will lead to more
frequent usage of the system. When this happens, the opportunities of identifying the
limitations and discovering bugs in the system will be higher and this will be reported to the
vendor. Thus, more enhancements and bug fixes (or patch-maintenance) may occur. On the
other hand, as the system matures and stabilizes, less patches or notes would be expected.
6.2 Reasons To Do Maintenance And Upgrade
Existing trade reports argue that maintenance and upgrade are fundamentally driven by
benefit-realization from the ERP system. Consistent with these reports, CSA maintains its
existing system and upgrade (i.e. for future functional upgrade) to a new version of ERP is
mainly aimed at realizing benefits from the system. Essentially, it aims for operational cost
reduction, integration between finance and human resources systems, and adopting the best
practice / business processes. With this purpose in mind, Chapter 4 has proposed maintenance
taxonomy to classify the ERP maintenance activities based on the ERP client’s benefit
perspective. The benefit-oriented classification of maintenance requests differentiates five
primary categories of benefits, which are identified as “integrated system”, “best business
practice”, “competitive advantage”, “globalization”, and “operational cost reduction” (see
Chapter 2, Section 2.3 for details). These are the prevailing benefits of ERP systems to the
clients and recognizing this benefit component is crucial in order to conduct cost and benefit
justifications for the dominant and expensive enhancement, patch-maintenance or upgrade on
ERP systems.
While continual maintenance and regular upgrades may allow organizations to achieve most/
some of the benefits mentioned (though sometimes at a high price), delaying these requests
(regardless of whether they are enhancement, corrective or patch) and upgrades will incur
user opportunity cost to the organizations (because of forgoing an earlier benefit-realization
from the requests and upgrade) (see also Nellemann (1993) in his discussion on opportunity
cost associated with ‘doing nothing’). Thus, ERP-using organizations should consider this
factor as one of the trade-offs in justifying maintenance and upgrade decisions.
6-8
6.2.1 User Opportunity Cost Quantification: A Simple Method
While in Chapter 2, Section 2.3.4, Table 2.9 shows some examples of benefit-realization for
ERP systems after the maintenance or upgrade was done, some ERP clients may pay very
little attention to quantifying user opportunity cost of not implementing the maintenance
requests and upgrades. By omitting this quantification step, an organization could be
uncertain if it is an accurate or “a best” decision on maintenance and upgrade. This section
illustrates a simple method to quantify user opportunity cost, which is basically translated
from the unrealized benefit(s) provided.
It is assumed that all maintenance requests and new version upgrade can be mapped onto one
or more of the benefit categories identified (i.e. “competitive advantage”, “globalization”,
“integrated system”, “best business practice”, and “operational cost reduction”). This is
particularly true with new version upgrade as it introduces a substantial number of new
enhancements and additional functionality. This assumption is also reasonable because
ERP/SAP clients are informed of the objectives and benefits of each patch and upgrade
version once they are made available to them. The same is applied to enhancement requests,
which originate from the system users or IT-staff. The objectives and benefits are required to
identify the business reason(s) behind the requests.
In quantifying user opportunity cost, the proposed method is a two-step “weighting”
approach. This is done by first “weighting” the benefit categories based on their degree of
importance or criticality to an ERP client’s business objectives, using a scale of 1 to 3, where
‘1’ indicates least important and ‘3’ indicates most important. For example, “operational cost
reduction” is highly important to CSA’s business mission, hence its importance level is
assigned as ‘3’. On the other hand, “integrated system” and “best practice / business
processes” have intermediate impact on CSA’s business mission. Therefore, these benefit
categories are given a value of ‘2’. Given the nature and background of CSA (i.e. a
Government agency), “competitive position” and “globalization” are the least important. The
objective of this step is to allow strategic evaluation to be incorporated in the user opportunity
cost quantification (Sarkis et al., 2001).
(An alternative to the above simple and direct assignment of weight to each benefit category
is a slightly complicated analytical hierarchy process (AHP) (Saaty, 1994; Forman et al. 2001;
6-9
Beynon, 2002). It involves: (1) pairwise comparison between all benefit categories in
assigning weight, (2) building (1) in a matrix (N x N) and normalizing each column by
dividing each element in column by its column’s sum, and (3) computing the average of each
row of the normalized matrix. This row average is called the relative importance weight. Each
benefit category will have its relative importance weight computed in its own row. The sum
of all benefit categories’ relative importance weight is equal to 1.)
The second step involves identifying the benefit(s) delivered by a request and quantifying
them (the unrealized benefits) in terms of dollar values, such as those found in literature
described in Chapter 2, Section 2.3. Hence, the amount of user opportunity cost for an
unfulfilled request is defined as:
Opportunity cost = jj
j xW∑=
5
1Equation (1)
The subscript j, taking value from 1 to 5, represents one of the five benefit-categories. Wj
denotes a degree of importance or criticality of benefit-j to an ERP client’s business mission,
and xj indicates the unrealized benefit value of the request evaluated under benefit-j. The
judgment of which benefit categories a request falls under, and for how much, is assessed by
senior managers and based on objective(s) of a request.
6.2.2 Benefit-Realization Quantification: Examples
For illustration purposes, assume that there are three maintenance requests received by CSA.
The request objectives and benefit-descriptions are taken from the benefit-realization
instances published in Queensland Government Financial Management (QGFMS) Benefit-
realization Guidelines (Queensland Treasury, 2000) and are as illustrated in Table 6.3. The
hypothetical benefit value quantifications for these benefits are also given in Table 6.3.
Maintenance-request-1, which will reduce time spent and cost of manually matching receipts
and invoices, is perceived to provide the benefit of “operational cost reduction” only; the
monetary value for this benefit is computed to be a labor saving of $25,050 per month.
Maintenance-request-2, which provides more accurate sales planning and better information
to inform managers of customer history when negotiating payment or contract terms, is found
to deliver “competitive advantage”, and “globalization” benefits only. The monetary values
6-10
are evaluated as an increase in revenue generation by $10,000 and a savings of $1,500 per
month respectively. On the other hand, maintenance-request-3, which offers the opportunity
of reduction in the number of disparate third party and legacy systems maintained and
reduction in lead-time for the production of monthly reports, contributes to “integrated
system” and “best practice / business processes” benefits. These are assessed to be savings of
$10,000 and $3, 000 per month respectively.
6-11
Table 6.3: Examples of maintenance requests and benefit quantifications
Objective of the maintenance request
Benefit descriptions Benefit quantifications
Maintenance-request-1:
Electronically matched payments against
open invoices
• Reduced time and cost spent manually
matching receipts and invoices
“Cost reduction” category
# of staff involved X total time (in hours) taken to
complete a match-transaction X # of match-transactions
per month X staff hourly rate
E.g.:
3 staff X 0.25 hour X 334 transactions X $100 = $25,050
• More accurate sales planning.
“Competitive advantage” category
Additional unit of sales per month X net revenue per unit
sales
E.g.:
50 sales unit X $200 = $10,000
Maintenance-request-2:
Easy access to, and reports of current
and historical sales information
• Better information to inform managers of
global and local customer history when
negotiating payment or contract terms.
“Globalization” category
Amount of time saved in dealing with a customer X # of
customers per month X manager’s hourly rate
E.g.:
0.5 hour X 20 customers X $150 = $1,500
• Reduction in the number of third party and
legacy systems maintained
“Integrated system” category
# of legacy systems X maintenance cost per month
E.g.:
2 systems X $5,000 = $10,000
Maintenance-request-3:
Integrated Accounts Payable and
Accounts Receivable modules; providing
business units with an up to date cash
flow information • Reduction in lead time for the production
of monthly reports
“Best practice / business processes” category
# of reduced lead time (day) X # of reports X cost of
lead time
E.g.:
3 days X 50 reports X $20 = $3,000
6-12
It is noted that while some benefits are tangible and quantifiable, others are intangible and
difficult to measure. However, in assessing intangible benefits, the quantification technique
proposed by Hares and Royle (1994) is adopted. Hares and Royle suggest four steps in order
to quantify the intangible benefits. The first step involves identifying the benefits. The second
is to make the benefits measurable, by expressing them in terms of percentage of sales
increase, increase of sales price, decrease of error or downtime, number of new customers,
time saved and so forth. The third is to predict the benefit in physical terms, whereas the
fourth is to evaluate the benefits in cash terms. Note that the third and fourth steps are
basically similar to the examples shown in the third column of Table 6.3.
6.2.3 User Opportunity Cost Quantification: An Example
If the three maintenance requests provided as examples in Section 6.2.2 are delayed, the
benefit values computed in Table 6.3 become the unrealized benefit values. Using the data in
Table 6.3, Table 6.4 provides details about the total basic user opportunity costs. The total
basic user opportunity costs per month is computed using equation (1) (see Section 6.2.1), and
maintenance-request-1 is found to be the most costly solution. Hence, in order to minimize
total user opportunity costs (incurred now and in the future), maintenance-request-1 and
maintenance-request-3 should be implemented prior to maintenance-request-2, assuming that
all requests are independent.
6-13
Table 6.4: User opportunity costs and maintenance request priorities
Benefit categories (Thousand $) Maintenance request Competitive
advantage (W4 = 1)
Globalization (W5 = 1)
Integrated system (W2= 2)
Best practice (W3 = 2)
Cost reduction (W1 = 3)
Total basic user opportunity costs (per month) (Thousand $)
Maintenance request priority rank
Request-1 0 0 0 0 25.05 75.15 1st
Request-2
10 1.5 0 0 0 11.5 3rd
Request-3 0 0 10 3 0 26 2nd
6-14
6.2.4 Summary of Findings
This section revisits the key findings outlined in Sections 6.1 to 6.2. These are summarized as
follows:
• On average, doing a patch-maintenance is almost as effort-demanding as doing a user-
enhancement request.
• New version upgrade reduces the number of ERP client modification-enhancement-
done.
• New version upgrade potentially reduces the number of patch-maintenance
requirements in the future.
• Benefit-realization is one of the main drivers for an ERP client to maintain and
upgrade its ERP system.
6.3 Implication of Findings From This Research
The findings obtained from the previous section (on factors driving ERP maintenance and
upgrade decisions) are compared with the existing in-house software and hardware
replacement models to determine if they (the existing models) are adequate in the context of
ERP. The results are summarized in Table 6.5.
The existing in-house software replacement models (see (Chan et al., 1996; Gode et al.,
1990)) consider characteristics such as software technology, source code size and age as the
main drivers influencing software replacement decisions. Software technology is referred to
the programming language and environment used to develop and maintain the system; it has
an impact on the program structure (Bergland, 1981) and therefore it affects the software
maintainability and maintenance effort. A better technology, for example 4GL (Fourth
Generation Language), is argued to contribute to a better program structure. Therefore, it is
expected to have a higher maintainability and requires less maintenance effort than 3GL or
lesser programs. A large system generally implies more source code, and for this reason more
effort is required to comprehend the program before debugging (Lientz et al., 1980). As a
system ages it tends to be less well ordered (Lientz et al., 1980), and also becomes more
complex (Banker et al., 1989). As a consequence, it will require more effort to maintain.
These factors are unlikely to be applicable in software packages because: (1) usually ERP-
6-15
using organizations do not have a choice of the software technology that is used in a particular
package system that they want to purchase; (2) source code size plays a limited part in ERP
clients’ maintenance effort because the organizations make relatively small
changes/modifications to the system, and most of the ERP software maintenance are shielded
and shouldered by the vendor; and (3) ERP-using organizations have no control over the
system age as the software code is managed by the vendor.
In contrast, factors such as task complexity and number of previous modification-
enhancements are found to have an impact on both in-house developed and ERP packaged
software maintenance decisions. However, previous modification-enhancements have slightly
different impacts and implications on software code and maintenance effort required for in-
house, and ERP software. This is summarized in Table 6.6. In the context of in-house
software, it is argued that the more modifications are made to the system the more likely it is
the deteriorations in the software code structure and quality (Lehman et al., 1980; Lehman et
al., 1976). This increases the difficulties in understanding the existing code and making
changes to it. As a result, more effort is necessary in both source code comprehension and
programming phases. In contrast, the larger the number of ERP enhancements (that are
initiated by ERP client and involve changing the standard code or writing custom-code), the
higher the amount of custom code and/or standard code being changed and affected. This
increases the amount of effort required for analyzing the impacts of a patch or new version
upgrade on these enhancements. If applicable, some of these enhancements will need to be re-
applied, re-tested and integrated.
The hardware literature (see (Rajagopalan, 1992; Rajagopalan et al., 1998)) argues that
hardware capacity and utilization deteriorates as it ages. However, software does not
deteriorate by itself or when it is used. In contrast, software deterioration is caused by the
maintenance work done on the source code over time (Lyons, 1981). This is the opposite for
hardware, as maintenance work repairs hardware deterioration (Brooks, 1979). Hopp et al.
have relaxed this assumption by assuming that hardware does not deteriorate, and consider
factors such as costs and revenues (or output) generated by the new hardware or technology
(Hopp et al., 1991). They presume that costs and revenues for technologies are known, and
revenues are constant over time. The latter assumption is not realistic in software systems
because their revenues are believed to change depending on software functionality and
timeliness of the software functionality. Moreover, revenue generation should not be the only
6-16
benefit measurement in the context of ERP. Other benefits measurement such as cost savings,
and the intangible benefits (such as integrated system, best practice, competitive advantage)
also need to be taken into consideration. Other models such as the one proposed in (Scarf et
al., 1999) are also not applicable for software as it considers (hardware) acquisition size a
determinant of replacement decision.
Results from this study, on ERP maintenance and upgrade environment, show that user
opportunity (or benefit-realization), reduction in number of previous modification-
enhancements, and reduction in number of future patch-maintenance projects are important
characteristics for ERP maintenance and upgrade decision framework. Though user
opportunity and reduction in number of future maintenance may also be applicable for in-
house software and hardware, they were not considered in the existing literature. On the other
hand, reduction in the number of previous modification-enhancements is unlikely to be an in-
house software replacement driver because its internal system enhancements are unlikely to
be available from external sources and therefore could not be replaced or reduced. It is also
logically impossible to apply this factor in a hardware replacement model, as hardware is less
malleable and usually more enhanced than its predecessor hardware. In light of these
differences, a specific ERP maintenance and upgrade decision framework is needed and
proposed in the next section.
Table 6.5: Comparison of characteristics considered in the existing replacement models and
fundamental characteristics of ERP maintenance and upgrade environment
Characteristics considered In-house software models *
Hardware models **
ERP MU decisions
Software technology, system size and
age
X NA NAa
Task complexity X NA X
Number of previous modification-
enhancements
X NA Xb
Hardware capacity NA X NA
Hardware utilization NA X NA
Fix revenue (or output) generated NA X NA
Hardware acquisition size NA X NA
User opportunity (Benefit-realization) NC NC X
6-17
Characteristics considered In-house software models *
Hardware models **
ERP MU decisions
Reduction in previous user-
enhancement
NA NA X
Reduction in number of patch-
maintenance
NA NA X
X = considered, NA = not applicable, NC = applicable but not considered
* Refers to articles in (Chan et al., 1996; Gode et al., 1990); ** Refers to articles in (Hopp et al., 1991; Rajagopalan, 1992;
Rajagopalan et al., 1998; Scarf et al., 1999); a As per finding reported in this study; b It will affect ERP patch-maintenance.
Table 6.6: Impact of modification-enhancement on software code, and maintenance effort
Modification-enhancement* Request-type
influenced by this request (in future)
Impact on software code
Impact on maintenance effort
In-house
software
All types of maintenance
requests – corrective,
adaptive, and
perfective/enhancement,
software replacement
• Source code
structure and quality
deterioration
• Software size may
increase but they
are all custom code
• Increase effort for
source code
comprehension
• Increase effort for
programming
ERP packaged
software
Patch or support
package maintenance,
and software upgrade
ONLY
• Standard code is
changed/affected,
and/or
• Custom code
increases
• Increase effort for
impact analysis
before and after the
patch or support
package
implementation, and
software upgrade
process
* Modification-enhancement refers to activities, which involve making changes to the (standard) software code or software
properties; it is associated with enhancements initiated by the ERP client but not those from the vendor.
6-18
6.4 A Framework For ERP Maintenance And Upgrade Decisions
The main areas covered in this section are the assumptions, decision alternatives, and trade-
offs involved in the decision alternatives. An example of how a maintenance decision is made
using the proposed framework is also presented.
6.4.1 Characteristics Of The Decision Framework
The decision framework in this text is a descriptive and mathematically based model. It is
developed and designed to investigate the consequences of various alternative courses of
action under different configurations of inputs (i.e. the uncontrollable variables or factors
influencing ERP maintenance and upgrade decisions). Thus, it is used to assist in identifying a
good enough solution for a given set of values for the inputs within a certain set of courses of
action. As a result, optimization or the best solution should not be expected from the proposed
descriptive decision framework. The purpose of the decision framework is to illustrate the
trade-offs between maintenance, upgrade, and opportunity cost.
6.4.2 Assumptions Made In The Decision Framework
Major assumptions made in developing the decision framework are as follows:
There is no risk involved in the maintenance or upgrade project.
All benefits and costs, regardless of whether they are tangible or intangible, are
quantifiable using the approach suggested by Hares and Royle (1994). Thus, all user
opportunity costs are quantifiable.
Upgrade options (regarding which ERP version to upgrade) are limited to those
introduced by the same vendor of the installed ERP version.
Other assumptions related to the structural form of the cost functions, and relationships
among variables in the equations, are discussed as they are presented in Section 6.3.3.
6-19
6.4.3 Decision Alternatives
The proposed decision framework (for CSA) takes into account six fundamental types of
change-request at CSA’s site. They are: (1) the three types of system user change-requests,
namely user-enhancement, corrective and master-data-change; (2) CSA’s enhancement
maintenance; (3) patch-maintenance; and (4) a new version upgrade.
The decision framework could be used to decide (1) whether to undertake a change-request,
and (2) prioritize a batch of change-requests. For the former case, the decision alternatives are
to do-the-change-request and do-nothing. In latter case, the framework can be used to yield a
decision policy prescribing requests with the highest priority to the lowest and thus should be
implemented in the prescribed order in order to minimize the total software life cycle costs.
6.4.4 Trade-offs Involved In Decision Alternatives
The discussion of the decision framework is structured around the initiators and decision
alternatives of CSA’s maintenance activities and is summarized in Figure 6.4. Descriptions of
the variables used are provided in Table 6.7.
6.4.4.1 System Users Maintenance Requests As mentioned earlier, there are three types of system users’ change-requests: enhancement,
corrective, and master-data-change. The decision to implement a user-enhancement request is
based on the trade-offs between the ongoing maintenance cost and user opportunity cost of
not implementing it. This enhancement implementation cost (in CSA’s case) is charged back
to the user, and does not incur cost to CSA. As a result, it is not included in the total user-
enhancement maintenance cost in the framework. In contrast, ongoing maintenance cost for
user-enhancement, which follows each patch-maintenance project (Section 6.1.2 for details)
and upgrade (Section 6.1.2.1), is borne by CSA. Hence, each user-enhancement that is done
using any of the tailoring options (2) to (9) as summarized in Chapter 2, Table 2.2, is defined
as:
Ongoing maintenance cost = (number of patch projects + number of upgrades) X (a
fraction of enhancement implementation cost) Equation (2)
6-20
where, a fraction of enhancement implementation cost = K X implementation cost,
K is a scalar.
On the other hand, user opportunity cost will be incurred if this enhancement request is
ignored. However, there is a possibility that this enhancement would be introduced in the next
version by the vendor. The user opportunity cost is formulated as:
Opportunity cost for user-enhancement = [(probability of being not available in the
next version) X (opportunity cost of the request)] + {(probability of being available
in the next version) X [(opportunity cost of the request) - (ongoing maintenance
cost)]}, Equation (3)
where opportunity cost of the request is the total basic user opportunity costs, and equals to
the sum of each benefit category weight multiplied by the unrealized benefit value for that
benefit category (see Equation (1) in section 6.2.1 for details.) Also, note that the relationship
between the probability of an enhancement being available and not available in the next
version is as follows:
Probability of being available in the next version = 1 - (probability of being not
available in the next version) Equation (4)
For other types of requests such as corrective and master-data-change, the maintenance cost is
simply computed as follows:
Maintenance cost for corrective = (estimated number of hours) X (cost per labor
hour) Equation (5)
Maintenance cost for master-data-change = (estimated number of hours) X (cost per
labor hour), Equation (6)
where estimated number of hours can be estimated by considering the task complexity and
maintenance category (see Chapter 5, Section 5.3), and other factors.
Likewise, the cost of forgoing this request(s) is calculated as:
6-21
Opportunity cost for corrective = ∑ [(benefit category weight) X (unrealized benefit
value for that benefit category)] Equation (7)
Opportunity cost for master-data-change = ∑ [(benefit category weight) X
(unrealized benefit value for that benefit category)] Equation (8)
6.4.4.2 CSA-Enhancement As mentioned earlier, CSA – the service provider, introduces enhancement maintenance for
ongoing support of the SAP system, and improving the performance of the system. The cost
of performing this request is equated as follows:
Maintenance cost for CSA-enhancement = (estimated number of hours) X (cost per
labor hour) + ongoing maintenance cost Equation (9)
Note that ongoing maintenance cost in the above equation is similar to that for user-
enhancement. It is incurred if CSA-enhancement falls under any of the tailoring options (2) to
(9) as detailed in Chapter 2, Table 2.2.
On the other hand, the effect of not doing anything with this request is the user opportunity
cost. Similar to the user opportunity cost formulation for user-enhancement discussed earlier,
there are possibilities and uncertainties whether this enhancement would be introduced in the
next version. Thus, user opportunity cost for CSA-enhancement is as follows:
Opportunity cost for CSA-enhancement = [(probability of being not available in the
next version) X (opportunity cost of the request)] + {(probability of being available
in the next version) X [(opportunity cost of the request) - (ongoing maintenance
cost)]} Equation (10)
Note that for CSA-enhancement that has no impact on future patch-maintenance effort or
upgrade effort, the formulation for this opportunity cost is the same as for corrective or
master-data-change maintenance request.
6-22
6.4.4.3 Vendor’s Patches In contrast to the system user- and CSA-enhancement maintenance, patch-maintenance cost is
not only driven by the estimated number of hours and cost per labor hour but also by the
number of modification-enhancements done during implementation project (see Chapter 2,
Section 2.1.2), and number of enhancements done to the existing version during post-
implementation (as supported by evidence in Section 6.1.1) and is calculated as follows:
Maintenance cost for patch = [(estimated number of hours) X (cost per labor hour)] X
[(number of modification-enhancements done during implementation project +
number of modification-enhancements done during post-implementation) X (a fraction
of enhancement implementation cost)] Equation (11)
where, a fraction of enhancement implementation cost = K X implementation cost,
K is a scalar.
Of note is that modification-enhancements here refer to enhancement done by using any of
the tailoring options (2) to (9) detailed in Chapter 2, Table 2.2. “K” is a scalar or multiplier to
indicate the effect of modification-enhancements on patch-maintenance effort. It is assumed
that each modification-enhancement has a linear relationship with patch-maintenance cost,
such that if there are two enhancements then the total patch-maintenance costs are more costly
by two times the value of “K”.
While cost is incurred when the patch is implemented, user opportunity is incurred if it is
delayed. This is calculated as:
Opportunity cost for patch = ∑ [(benefit category weight) X (unrealized benefit
value for that benefit category)] Equation (12)
6.4.4.4 Upgrade Upgrade cost is calculated as the sum of the following elements (see Chapter 2, Section 2.2.2
for more detailed discussion on these cost elements):
6-23
Upgrade cost = software license cost + hardware cost + user training cost +
consultant fees + previous modification-enhancement reapplication cost + upgrade
implementation cost Equation (13)
The previous modification-enhancement reapplication cost refers to the cost of reapplying
previous modification-enhancements, which were done using any of the tailoring options (2)
to (9) (see Chapter 2, Table 2.2) onto a new upgrade version (as discussed in Section 6.1.2.1),
and is calculated as:
Previous modification-enhancement reapplication cost = (total number of
modification-enhancements still required after upgrade) X (number of hours per
modification-enhancement) X (cost per labor hour) Equation (14)
Upgrade implementation cost depends on the complexity or scope of the upgrade (which is an
subjective evaluation based on the number of modules to be implemented and number of
business units involved), version gap between the existing and new (upgrade) version, system
integration and testing, and system disruption cost, and is calculated as,
Upgrade implementation cost = [complexity X version gap] X [(system integration
and testing cost) + (system disruption cost)] Equation (15)
An assumption made here is that both system integration and testing cost, and system
disruption cost, are increased by the compound factors of both upgrade complexity and
version gap.
While it may be cheaper not to do an upgrade, upgrade has a positive impact on future
maintenance cost (refer to section 6.1.2.1 and 6.1.2.2). The reduction in maintenance costs
comprises two components: the number of previous modification-enhancements (for ongoing
maintenance), and the number of patch-maintenance, and are calculated as follows:
Reduction in maintenance cost = - [(total number of modification-enhancements in
the existing version – total number of modification-enhancements still required after
upgrade) X (ongoing maintenance cost)] + [(decrease in number of patches) X
(average annual patch-maintenance cost)] Equation (16)
6-24
In addition, if the upgrade option is forgone it is expected to contribute to greater user
opportunity costs. Therefore, for the upgrade option, it is defined as:
Opportunity cost for upgrade = ∑ [(benefit category weight) X (unrealized benefit
value of the new version for that benefit category)] Equation (17)
(In an extreme case, where the vendor withdraws supports for an installed version, the total
user opportunity costs would be extremely high under the “cost reduction” benefit category.
In this situation, an upgrade decision would obviously be the most feasible option.)
A summary of the ERP maintenance and upgrade decision framework is illustrated in Figure
6.4 (note that the variable names have been abbreviated in the following framework).
6-25
Table 6.7: Description of variables considered in the decision framework
Cost component
Maintenance initiator
Variable involved Description
Maint_cost_enh Cost for maintaining user-enhancement request.
Implement_cost Cost of implementing a user-enhancement request (i.e. the initial cost). Its cost
factor depends on task complexity and maintenance category, and other factors.
Maint_cost_corr Cost for maintaining user corrective request.
System users
(CSA’s clients)
Maint_cost_master_data Cost for maintaining user master-data-change request.
Ongoing_maint_cost Ongoing maintenance cost entailed in the modification-enhancement.
#_of_modification Represents the total number of modification-enhancements in the existing version,
including those done during system implementation.
System users,
CSA
A_fraction_of_implement_cost Represents a certain/small portion of an enhancement’s implementation cost.
CSA Maint_cost_prov_enh Cost for implementing CSA-enhancement.
Maintenance
cost
Vendor Maint_cost_patch Patch-maintenance cost (driven by number of modification-enhancements).
Vendor, CSA,
system user
Oppor_cost User opportunity cost incurred when the respective patch maintenance, new version
upgrade, corrective or master-data-change maintenance is not satisfied.
System user Oppor_cost_user_enh User opportunity cost incurred when user-enhancement modification request is not
satisfied, taking the uncertainty factor into consideration.
CSA Oppor_cost_CSA_enh User opportunity cost incurred when CSA-enhancement request is not satisfied,
taking the uncertainty factor into consideration.
Benefit_category_weight
Importance of a benefit category to an ERP client’s business objectives (i.e.
measured on a scale of 1-3).
System users,
CSA, vendor
Unrealized_benefit_value Unrealized benefit value of a request evaluated based on a benefit category.
User
opportunity
cost
Vendor New_version_unrealized_
benefit_value
Unrealized benefit value of a new version evaluated based on a benefit category.
6-26
Cost component
Maintenance initiator
Variable involved Description
Upgrade_cost Total cost incurred in an upgrade exercise.
Software Cost of licensing a new upgrade version.
Hardware Cost associated with purchasing additional hardware.
Reapply_modification_cost Cost incurred in order to re-apply/implement previous modification-enhancements.
Modification_required Number of previous modification-enhancements still required after an upgrade.
Hour_per_modification Average hours required in order to re-implement one unit of previous modification-
enhancements.
User_training_cost Cost for educating and training the system users.
Consultant_fees Cost for hiring consultants for upgrade.
#_of_consul_hour Total number of consultant-hours required for an upgrade.
Consul_cost_per_hour Consultant’s rate per hour.
Upgr_implementation _cost Upgrade implementation cost.
Complexity Complexity of an upgrade project (i.e. high, medium, low). It is determined by the
number of modules to be implemented and number of business units involved.
Version_gap Version gap between existing and new version upgrade (i.e. functionality, upgrade
path, technical aspect of upgrade).
Integration_and_testing_cost Cost involved in integrating and testing a new system.
Sys_disruption_cost Cost of system downtime and disruption during the implementation and testing time,
and change management, following a new system upgrade.
Reduce_maint_cost Reduction in maintenance cost following a new version upgrade.
Patch_decrease_rate An average rate at which the number of patches decrease from one version to
another.
New version
Upgrade
Vendor
Ave_annual_patch_cost Average annual patch maintenance cost.
6-27
Cost component
Maintenance initiator
Variable involved Description
Maintenance
request
System users,
CSA, vendor
#_of_hour Total number of hours, an estimation of # of staff required and project duration –
based on task complexity, maintenance category, etc. for completing a request (as
assessed by a senior manager).
Organizational
factor
CSA Cost_per_hour Maintainer and analyst’s hourly rate.
CSA #_of_patch_project An estimation of total patch projects over a time horizon. Patch project
CSA K A scalar or multiplier to indicate the impact of a modification-enhancement on patch-
maintenance effort.
Upgrade
project
CSA #_of_upgrade An estimation of total upgrade projects over a time horizon.
Prob_avail Probability that an enhancement requested by a system user / CSA will be available
in the next upgrade version.
External
uncertainties
System user,
CSA
Prob_not_avail Probability that an enhancement requested by a system user / CSA will not be
available in the next upgrade version.
6-28
Initiator
Trade-off
Cost Function
MaintenanceActivities
System users:
IT-staff:
Vendor (patch):
Maintenance cost
Maint_cost_prov_enh = #_of_hours*** X cost_per_hour + ongoing_maint_cost**
User opportunitycost
Maintenance cost
Maintenance cost
User opportunitycost
User opportunitycost
Oppor_cost_CSA_enh = (prob_not_avail X Oppor_cost) + [prob_avail X(Oppor_cost - ongoing_maint_cost)]
Oppor_cost = (benefit_category_weight X unrealized_benefit_value)
Maint_cost_patch = (#_of_hours X cost_per_hour) + [(#_of_modification) X a_fraction_of_implement_cost]
Oppor_cost = (benefit_category_weight X unrealized_benefit_value)
Vendor (NewVersion Upgrade):
Reduction inMaintenance cost
User opportunitycost
Upgrade cost
Upgrade_cost = software + hardware + user_training_cost + consultant_fees + + reapply_modification_cost +upgr_implementation_cost
reapply_modification_cost = modification_required X hour_per_modification X cost_per_hourconsultant_fees = #_of_consul_hour X consul_cost_per_hourupgr_implementation_cost = (complexity X version_gap) X (integration_and_testing_cost + sys_disruption_cost)
Oppor_cost = (benefit_category_weight X new_version_unrealized_benefit_value)
reduce_maint_cost = - [ (#_of_modification - modification_required) X ongoing_maint_cost +(patch_decrease_rate X ave_annual_patch_cost) ]
Notes:* The user-enhancementimplementation cost ischarged back to therequestor's organization.Therefore, this cost wouldnot be included in CSA'sERP Decision Framework.
** This cost is incurred if theenhancement done isaffected by the futurepatch-maintenance orupgrade.
*** The number of hours forthe client-initiatedmaintenance activities isestimated by considering thetask complexity andmaintenance category, andother factors.
****Corrective or master-data-change requests couldalso be initiated by IT-staff.
∑
∑
∑
If corrective or master data change****Oppor_cost = (benefit_category_weight X unrealized_benefit_value)∑
If corrective****maint_cost _corr = #_of_hours*** X cost_per_hour
If enhancementmaint_cost_enh = implement_cost * + ongoing_maint_cost**implement_cost = #_of_hours*** X cost_per_hourongoing_maint_cost = (#_of patch_project + #_of _upgrade) X (a_fraction_of_implement_cost)
If enhancementOppor_cost_user_enh = (prob_not_avail X Oppor_cost) + [prob_avail X (Oppor_cost -
ongoing_maint_cost)]Oppor_cost = (benefit_category_weight X unrealized_benefit_value)∑
If master-data-change****maint_cost _master_data = #_of_hours*** X cost_per_hour
Figure 6.4: ERP decision framework – decision alternatives, trade-offs, and cost functions
6-29
6.4.5 An Illustration Of The Application Of The Decision
Framework: For Recurrent Decision Making
Using the three hypothetical maintenance requests discussed in Section 6.2.3, further
information about these requests follows. Request-1 and request-2 are user-
enhancements, whereas request-3 is a CSA-enhancement. They arrive at the same
time. The decision problem is to determine which maintenance request(s) to maintain
at the beginning of the first month. (Assuming that the required resources would be
available, and more than one maintenance project can be started at the same time.)
The maintenance decision is assessed over a three years period, and is based on trade-
offs between the total user opportunity costs and total maintenance costs evaluation
(see Figure 6.4). The relationship between these two cost components is provided in
Figure 6.5, where it is shown that total user opportunity costs can be reduced by
satisfying the maintenance request(s) but at the expense of maintenance costs.
Conversely, total maintenance costs could be contained by delaying maintenance
request(s) or doing nothing but at the expense of total user opportunity costs. The
objective function is to minimize the total costs of ERP software. Thus, the course of
actions is determined based on which action has the minimal cost.
Maintenance cost
User
Opportunity cost
Figure 6.5: Trade-off between user opportunity cost and maintenance cost
Project requirements for the three maintenance-requests, such as number of staff
required and project duration, are as described in Table 6.8. Though no maintenance-
implementation cost is incurred to CSA for requests related to user-enhancement,
ongoing maintenance cost is (as it would be affected by a patch project or an upgrade-
6-30
project in the future). This ongoing maintenance cost is calculated using Equation (2).
Assuming that the ongoing maintenance cost for request-1 is 10% of its project
implementation cost and request-2 is 15%, and the ongoing maintenance costs (for the
first month) are evaluated at $9,600 and $10,080 respectively. Note that the ongoing
maintenance costs for request-1 and request-2 are incurred each time a patch project
or an upgrade project is implemented. It is assumed that CSA would implement a
patch project once a month and there would be an upgrade at end of the third year.
With adjustment to the expected project completion for request-1 and request-2, there
would be only 34 ongoing maintenance cost payments (or 34 patch-projects) for
request-1 and 35 ongoing maintenance cost payments for request-2 in that three-year
time period. This is illustrated in Figure 6.6.
0End of year-2
End of year-1
End of year-3
End of the 1st month – project completion
Ongoing maintenance periods = 35 months
Note: Patch project is implemented at the beginning of each month.
Request-2:
End of the 2nd month – project completion
0 End of year-2
End of year-1
Request-1:
End of year-3
Ongoing maintenance periods = 34 months
Beginning of the 1st month
Figure 6.6: Request-1 and request-2: ongoing maintenance cost payment
Assuming that the inflation rate is 10% per annum and is constant for the three-year
time horizon, the maintenance cost per month is expected to increase with the
inflation rate. The maintenance implementation cost for CSA-enhancement is
computed using Equation (9). It is assumed that the enhancement in request-3 has no
impact on future maintenance or upgrade effort. Thus, its ongoing maintenance cost is
basically zero. The total cumulative maintenance costs, for the three requests, over
three year’s time are shown in Table 6.8.
6-31
The total basic user opportunity costs incurred in the first month for the three requests
are as computed in Table 6.9. User opportunity costs per month are assumed to
decrease with the inflation rate. The total cumulative opportunity costs by the end of
year-3 for the three requests are also illustrated in Table 6.9. While the total user
opportunity costs for user-enhancements are calculated using Equation (3), Equation
(10) is used for CSA-enhancement. The probabilities of enhancements in request-1
and request-2 being available in the next version are 50% and 75% respectively.
The maintenance decision policy with respect to these assumed data is to maintain
request-1 and request-3 but disregard request-2 for the time being (see Table 6.10).
The net present values (NPV), using discount rate of 10%, for these three
maintenance projects are also provided in Table 6.10. Sensitivity analysis is also
conducted on the marginal error for the estimated variables for ongoing maintenance
cost, maintenance implementation cost, user opportunity cost, and probability factor.
It is found that the decision policy remains unchanged even when the marginal error is
as high as 50%.
6-32
Table 6.8: Maintenance requests: total maintenance costs
Maintenance implementation cost Ongoing maintenance cost Maintenance Request Category
Implementation attributeImplementation quantifier
Implementation cost
Maintenance attribute
Maintenance quantifier
Cost (for 1st month)
Total ongoing maintenance cost for 3 yrs
Request-1 User- # of staff required 3 % of implement cost10% $ 9,600.00 $394,768.03 enhancement Project duration (month) 2 Staff hourly rate $ 100.00 $ 96,000.00 Request-2 User- # of staff required 4 enhancement Project duration (days) 21 Staff hourly rate $ 100.00 $ 67,200.00 % of implement cost15% $10,080.00 $424,670.43 Request-3 CSA- # of staff required 5 enhancement Project duration (month) 1 Staff hourly rate $ 120.00 $ 96,000.00 # of hours per man-month = 160 # of hours per man-day = 8 Inflation rate (per annum) = 10% Inflation rate (per month) = 0.8% Total number of months = 36 Ongoing maintenance cost:
Item details Monetary value Actual cumulative ongoing maintenance cost after 3 years
Request-1 $ 9,600.00 $ 394,768.03 Request-2 $ 10,080.00 $ 424,670.43
6-33
Request-1 Request-2 Month Increment cost Cumulative cost Increment cost Cumulative cost 1 $ 9,600.00 $ 9,600.00 $ 10,080.00 $ 10,080.00 2 $ 9,680.00 $ 19,280.00 $ 10,164.00 $ 20,244.00 3 $ 9,760.67 $ 29,040.67 $ 10,248.70 $ 30,492.70 4 $ 9,842.01 $ 38,882.67 $ 10,334.11 $ 40,826.81 5 $ 9,924.02 $ 48,806.69 $ 10,420.22 $ 51,247.03 6 $ 10,006.72 $ 58,813.42 $ 10,507.06 $ 61,754.09 7 $ 10,090.11 $ 68,903.53 $ 10,594.62 $ 72,348.71 8 $ 10,174.20 $ 79,077.72 $ 10,682.91 $ 83,031.61 9 $ 10,258.98 $ 89,336.71 $ 10,771.93 $ 93,803.54 10 $ 10,344.47 $ 99,681.18 $ 10,861.70 $104,665.24 11 $ 10,430.68 $ 110,111.85 $ 10,952.21 $115,617.45 12 $ 10,517.60 $ 120,629.45 $ 11,043.48 $126,660.93 13 $ 10,605.25 $ 131,234.70 $ 11,135.51 $137,796.43 14 $ 10,693.62 $ 141,928.32 $ 11,228.30 $149,024.74 15 $ 10,782.74 $ 152,711.06 $ 11,321.87 $160,346.61 16 $ 10,872.59 $ 163,583.65 $ 11,416.22 $171,762.83 17 $ 10,963.20 $ 174,546.85 $ 11,511.36 $183,274.19 18 $ 11,054.56 $ 185,601.40 $ 11,607.28 $194,881.47 19 $ 11,146.68 $ 196,748.08 $ 11,704.01 $206,585.49 20 $ 11,239.57 $ 207,987.65 $ 11,801.55 $218,387.03 21 $ 11,333.23 $ 219,320.88 $ 11,899.89 $230,286.92 22 $ 11,427.67 $ 230,748.55 $ 11,999.06 $242,285.98 23 $ 11,522.90 $ 242,271.46 $ 12,099.05 $254,385.03 24 $ 11,618.93 $ 253,890.39 $ 12,199.88 $266,584.91 25 $ 11,715.75 $ 265,606.14 $ 12,301.54 $278,886.45 26 $ 11,813.38 $ 277,419.53 $ 12,404.05 $291,290.50 27 $ 11,911.83 $ 289,331.35 $ 12,507.42 $303,797.92 28 $ 12,011.09 $ 301,342.45 $ 12,611.65 $316,409.57 29 $ 12,111.19 $ 313,453.64 $ 12,716.75 $329,126.32 30 $ 12,212.11 $ 325,665.75 $ 12,822.72 $341,949.04
Request-1 Request-2 Month Increment cost Cumulative cost Increment cost Cumulative cost
31 $ 12,313.88 $ 337,979.63 $ 12,929.58 $354,878.61 32 $ 12,416.50 $ 350,396.13 $ 13,037.32 $367,915.93 33 $ 12,519.97 $ 362,916.10 $ 13,145.97 $381,061.90 34 $ 12,624.30 $ 375,540.40 $ 13,255.52 $394,317.42 35 $ 12,729.50 $ 388,269.90 $ 13,365.98 $407,683.39 36 $ 12,835.58 $ 401,105.48 $ 13,477.36 $421,160.76 Upgrade $ 12,942.55 $ 414,048.03 $ 13,589.67 $434,750.43
6-34
Table 6.9: Maintenance requests: total opportunity costs
Basic opportunity costs Adjustment to user-enhancement’s opportunity costs Maintenance Request Category
Total for the first month
Total by the end of year-3
User-enhancement attribute User-enhancement quantifier
Total opportunity costs
Request-1 User- $ 75,150.00 $2,345,693.57 Probability avail in upgrade version 50% enhancement Probability not avail in upgrade version 50% Total opportunity costs for 3 yrs $ 2,345,693.57 Total ongoing maintenance cost for 3 yrs $ 394,768.03 Difference between total oppor. and maint. cost $ 1,950,925.54 $ 2,148,309.56 Request-2 User- $ 11,500.00 $ 358,955.10 Probability avail in upgrade version 75% enhancement Probability not avail in upgrade version 25% Total opportunity costs for 3 yrs $ 358,955.10 Total ongoing maintenance cost for 3 yrs $ 424,670.43 Difference between total oppor. and maint. cost $ (65,715.33) $ 252,787.50
Request-3 CSA- $ 26,000.00 $ 811,550.67 enhancement Inflation rate (per annum) = 10% Inflation rate (per month) = 0.8% Total number of months = 36
Opportunity costs: Item details
Monetary value
Cumulative monetaryvalue after 3 years
Request-1 $ 75,150.00 $2,345,693.57 Request-2 $ 11,500.00 $ 358,955.10 Request-3 $ 26,000.00 $ 811,550.67
6-35
Request-1 Request-2 Request-3
Month Value after
depreciation Cumulative
value Value after
depreciationCumulative
value Value after
depreciation Cumulative
value 1 $ 75,150.00 $ 75,150.00 $11,500.00 $ 11,500.00 $26,000.00 $ 26,000.00 2 $ 74,523.75 $ 149,673.75 $11,404.17 $ 22,904.17 $25,783.33 $ 51,783.33 3 $ 73,902.72 $ 223,576.47 $11,309.13 $ 34,213.30 $25,568.47 $ 77,351.81 4 $ 73,286.86 $ 296,863.33 $11,214.89 $ 45,428.19 $25,355.40 $102,707.21 5 $ 72,676.14 $ 369,539.47 $11,121.43 $ 56,549.62 $25,144.11 $127,851.31 6 $ 72,070.50 $ 441,609.97 $11,028.75 $ 67,578.37 $24,934.57 $152,785.89 7 $ 71,469.92 $ 513,079.89 $10,936.85 $ 78,515.22 $24,726.78 $177,512.67 8 $ 70,874.33 $ 583,954.23 $10,845.71 $ 89,360.93 $24,520.73 $202,033.40 9 $ 70,283.71 $ 654,237.94 $10,755.33 $100,116.25 $24,316.39 $226,349.79 10 $ 69,698.02 $ 723,935.96 $10,665.70 $110,781.95 $24,113.75 $250,463.54 11 $ 69,117.20 $ 793,053.16 $10,576.82 $121,358.77 $23,912.80 $274,376.34 12 $ 68,541.22 $ 861,594.38 $10,488.68 $131,847.44 $23,713.53 $298,089.87 13 $ 67,970.05 $ 929,564.43 $10,401.27 $142,248.71 $23,515.92 $321,605.79 14 $ 67,403.63 $ 996,968.06 $10,314.59 $152,563.31 $23,319.95 $344,925.74 15 $ 66,841.93 $1,063,809.99 $10,228.64 $162,791.95 $23,125.62 $368,051.36 16 $ 66,284.92 $1,130,094.91 $10,143.40 $172,935.35 $22,932.91 $390,984.27 17 $ 65,732.54 $1,195,827.45 $10,058.87 $182,994.22 $22,741.80 $413,726.06 18 $ 65,184.77 $1,261,012.22 $ 9,975.05 $192,969.27 $22,552.28 $436,278.35 19 $ 64,641.56 $1,325,653.79 $ 9,891.92 $202,861.19 $22,364.35 $458,642.69 20 $ 64,102.89 $1,389,756.67 $ 9,809.49 $212,670.68 $22,177.98 $480,820.67 21 $ 63,568.69 $1,453,325.37 $ 9,727.74 $222,398.43 $21,993.16 $502,813.83 22 $ 63,038.96 $1,516,364.32 $ 9,646.68 $232,045.11 $21,809.88 $524,623.72 23 $ 62,513.63 $1,578,877.95 $ 9,566.29 $241,611.40 $21,628.14 $546,251.85 24 $ 61,992.68 $1,640,870.64 $ 9,486.57 $251,097.97 $21,447.90 $567,699.75 25 $ 61,476.08 $1,702,346.71 $ 9,407.52 $260,505.49 $21,269.17 $588,968.92 26 $ 60,963.78 $1,763,310.49 $ 9,329.12 $269,834.61 $21,091.93 $610,060.85 27 $ 60,455.75 $1,823,766.24 $ 9,251.38 $279,085.98 $20,916.16 $630,977.01 28 $ 59,951.95 $1,883,718.19 $ 9,174.28 $288,260.27 $20,741.86 $651,718.87 29 $ 59,452.35 $1,943,170.53 $ 9,097.83 $297,358.10 $20,569.01 $672,287.88 30 $ 58,956.91 $2,002,127.45 $ 9,022.02 $306,380.11 $20,397.60 $692,685.48 31 $ 58,465.60 $2,060,593.05 $ 8,946.83 $315,326.95 $20,227.62 $712,913.10 32 $ 57,978.39 $2,118,571.44 $ 8,872.28 $324,199.22 $20,059.06 $732,972.16 33 $ 57,495.24 $2,176,066.68 $ 8,798.34 $332,997.56 $19,891.90 $752,864.05 34 $ 57,016.11 $2,233,082.79 $ 8,725.02 $341,722.58 $19,726.13 $772,590.19 35 $ 56,540.98 $2,289,623.77 $ 8,652.31 $350,374.89 $19,561.75 $792,151.94 36 $ 56,069.80 $2,345,693.57 $ 8,580.21 $358,955.10 $19,398.73 $811,550.67
6-36
Table 6.10: Maintenance requests’ decision policy
Request Total maintenance costs Total opportunity costs Net present value (NPV) Decision
Request-1
(User-enhancement)
$ 394,768.03
(ongoing maintenance cost)
$ 2,148,309.56 $576,548.48 Maintain
Request-2
(User-enhancement)
$ 424,670.43
(ongoing maintenance cost)
$ 252,787.50 -$1,954.41
Do nothing
Request-3
(CSA-enhancement)
$ 96,000.00
(implementation cost)
$ 811,550.67 $146,982.93
Maintain
6-37
6.5 A General ERP Maintenance And Upgrade Decision Model
While the decision framework in Section 6.4 is used for making periodical or short-term
maintenance decision, a general ERP maintenance and upgrade decision model (in this
Section 6.5) is intended to assist in making long-term planning and determining when (is the
timing) to do a software upgrade.
6.5.1 Characteristics Of The General Decision Model
The proposed general decision model is a descriptive and mathematically based model.
Similar to the decision framework, it is utilized to investigate the consequences of various
alternative courses of action under different configurations of inputs (i.e. the uncontrollable
variables or factors influencing ERP maintenance and upgrade decisions). Thus, it assists in
identifying a good enough solution for a given set of values for the inputs within a certain set
of courses of action (i.e. the upgrade timing). As a result, optimization or the best solution
should not be expected from the proposed descriptive general model. It is not the intention in
this text to provide a normative analytically based model but a quantitative illustration of how
an ERP upgrade decision can be made.
6.5.2 Cost Components
Using the decision framework illustrated in Figure 6.4, as well as incorporating the initial
implementation costs and annual maintenance fees payable to the vendor, the total lifecycle
costs or total cost of ownership for ERP software, Z, is the sum of the total initial
implementation costs, total user maintenance costs (i.e. user-enhancement, corrective, master-
data-change, CSA-enhancement, patch-maintenance), upgrade, user opportunity costs, and
annual maintenance-support fees. The general ERP decision model is as shown below and the
objective function is to minimize total lifecycle costs of ERP software, that is
6-38
minimize,
∑∑∑∑∑∑∑∑∑ ++++++++= ANNUALx
OX
Ux
Px
Gx
Mx
Cx
EIMP CCCCCCCCCZ7654321
,
where CIMP = initial implementation cost,
CE = user-enhancement cost,
CC = corrective cost,
CM = master-data-change cost,
CG = CSA-enhancement cost,
CP = patch-maintenance cost,
CU = upgrade cost,
CO = user opportunity cost,
CANNUAL = annual maintenance-support fees payable to the vendor,
x1 = number of user-enhancement,
x2 = number of corrective,
x3 = number of master-data-change,
x4 = number of CSA-enhancement,
x5 = number of patches (or batch of patches), and
x7 = number of ‘doing nothing’
The decision variable is denoted as:
X6 = timing of upgrade
The general model allows one to compute the timing for an upgrade decision, i.e. X6, if the
values of all the uncontrollable variables including x1, x2, x3, x4, x5, and x7 are known.
6.5.3 An Illustration Of The Application Of The General ERP
Decision Model: For One-Time Decision-Making
It is assumed that CSA is now looking at long-term economic planning and decision-making
on whether to do an upgrade or continuing to maintain the current/installed system over the
next 10 years planning horizon. Information on the internal-originated and external-originated
maintenance requests, based on historical maintenance data (as reported in Chapters 4, and 5
and earlier in this chapter), is available as follows:
6-39
To estimate patch-maintenance activities and costs:
In Chapter 4 (Section 4.2.4 of CSA’s patch-maintenance activities), it is reported that the
vendor introduced a patch every fortnight for a supported version. From the historical data
(see Chapter 4, Table 4.7), it is observed that instead of implementing the patch as it
arrives, CSA batches them in groups. Patch-maintenance was implemented approximately
twice a year. Since CSA does not practically batch the patch into any particular number of
patches, it is assumed that, on average, CSA could do 13 patches in each patch-
maintenance project. It is found that the average maintenance hours per patch are 46 (see
Table 6.1).5 Therefore, a patch-maintenance is expected to take (46 hours X 13 patches =)
598 billable hours.
To determine the frequency distribution and average maintenance effort of the internally-
originated change-requests:
The average number of requests per month and average maintenance effort for user-
enhancement, corrective, master-data-change and CSA-enhancement requests are obtained
from the empirical data shown in Chapter 5, Table 5.2.
Based on the data shown in Chapter 4, Table 4.6, it is observed that the number of change-
requests decrease from month to month and then become stable (see Chapter 4, Section
4.2.3 for more details). As a result, it is reasonable to assume that the total of these
requests would probably decrease from year to year and would become more stable after
the first few years. This is illustrated in Table 6.11.
To determine the characteristics and impact of modification-enhancements done on patch-
maintenance:
From Chapter 5, Table 5.7, it is found that 37% of the user-enhancements were done
through configuration and within the standard vendor’s code, whereas the remaining (or
so called modification-enhancements in this text) were done using the tailoring options (2)
to (9) detailed in Chapter 2, Table 2.2. The remaining 63% are believed to have some
impact on a patch-maintenance or an ERP upgrade. Thus, in implementing a patch-
5 It is acknowledged that the 46 hours per patch (from CSA archival records) is most likely inclusive of reapplying previous modification-enhancements. As no additional data is available for the author to separate or determine the average effort for implementing patches without reapplying any modification-enhancement, 46 hours is the only basis used for patch-maintenance effort. Thus, the computed cost associated with patch-maintenance is most likely has been overestimated in the given hypothetical example.
6-40
maintenance project, all of these (63%) user-enhancements may need to be checked to
determine if they are overwritten. Assuming all CSA-enhancements are done within the
standard using configuration option only. The total patch-maintenance cost is computed
using Equation (11) and is shown in Table 6.12. It is assumed that at the beginning of
year-1 the newly installed version is free from any modification-enhancement.
Assuming that CSA would have sufficient resources to implement change-requests as they
arrive at the helpdesk without much delay and to perform the patch-maintenance (i.e. two
batches of patch-maintenance in a year – the first-batch in the middle of the year and the
second-batch at the end of the year), and (thus) the user opportunity costs for these requests
would be insignificant.
With this maintenance management strategy, CSA have to decide whether to continue
maintaining the existing system in order to avoid upgrade and wait until they have obtained
the return on (previous) investment, or do an upgrade immediately after the vendor withdraws
support for the installed version. A typical support window for a version of ERP software is
three years, which means that after the third year CSA’s (existing) ERP system will be no
longer supported by the vendor. This implies that the vendor will stop supplying any further
patches for the old version. Thus, CSA can just focus all its maintenance resources on internal
originated maintenance requests. However, usually the vendor introduces a new version of
ERP system with more functionality and state-of-the-art technology, and with potential
benefits such as improved system integration, best practice, operational cost reduction,
competitive advantage and globalisation. Hypothetically, CSA has some reliable information
about the benefits and business improvements delivered in a new version that will be in the
market sometime before the vendor’s support for CSA’s installed version expires. This is a
realistic scenario as the ERP vendor will occasionally provide details about their new product
functionality and conduct demonstration presentations at the client’s site, according to CSA.
Therefore, CSA would be able to estimate the business value of this new version to their
organization and user-organizations.
As described in Section 6.4.4.4, there are two options available for an upgrade decision that is
either not doing an upgrade or perform an upgrade. The following discusses the costs and
benefits associated with these two options.
To predict the cost of not doing the upgrade:
6-41
While an upgrade will incur a huge cost, not upgrading may result in CSA missing all of
the business opportunities or the benefits delivered in the new version. The longer they
postpone this upgrade, the more costly the user opportunity cost will be. Hypothetically, it
is estimated that the total opportunity costs in this new version are valued at $1 million per
year6, using the same method as described in Section 6.2.3 and Equation (17). With the
new version in production, as well as continuous business improvements to the system, it
is expected to provide an additional 30% increase in business benefits each year. This is
summarized in Table 6.13.
To determine the benefits and costs of the upgrade:
If CSA decides to upgrade not only will the organization could realize the (potential)
business benefits from the system but it will also benefit from the reduction in number of
existing user-enhancements (by one-third of the total number of user-enhancements in the
previous version, based on the empirical evidence provided in Section 6.1.2.1) and the
decrease in number of patches to maintain by 21% (see Section 6.1.2.2). The calculation
for this is shown in Table 6.14. Based on CSA’s previous upgrade experience, this new
upgrade cost is expected to cost about $3 million. In practice, this cost is calculated by
considering all the cost elements listed in Equation (13), and using Equation (14) – (16) in
Section 6.4.4.4.
Using historical data and forecasting data, the total ERP software maintenance costs for both
options (of not upgrading and upgrading to the new version) are shown in Table 6.15. Net
present values (NPV), using discount rate 10%, for these two decisions are also shown in
Table 6.15. The cumulative total ERP maintenance costs or lifecycle costs for these two
options are estimated to be approximately $12.9 million for not upgrading and $11.5 million
for upgrading. Note that even though the phrase ‘total lifecycle costs’ is used in this section,
the initial implementation costs and annual maintenance fees (payable to the vendor) are not
included in computing the total costs as these cost components are constant and do not affect
an upgrade decision. This is shown in Table 6.15. CSA’s objective is to minimize the
cumulative total ERP lifecycle cost over the planning horizon. Therefore, the optimal decision
is to upgrade immediately after termination of vendor support for the installed version (see
Figure 6.7). It is observed from Figure 6.7, based on the annual ERP maintenance cost, that 6 Note that this is a hypothetical figure. In reality, in order to estimate this monetary value, a thorough examination of the new system functionality would be required to determine how it will impact on the client’s business organization and user-requirements in achieving the benefits of cost reduction, best practice, improved system integration, competitive advantage and/or globalization.
6-42
the new version is cheaper to maintain than the installed version. Even though the upgrade
cost is very high during the first year, the cumulative ERP lifecycle cost for the new version
yields a less expensive dollar value than the other option. Figure 6.8 shows the savings earned
from upgrading to the new version.
A sensitivity analysis is provided in Table 6.16 to determine the impact of delaying upgrade
on user opportunity cost, upgrade cost, patch-maintenance cost and cumulative ERP software
maintenance costs. With this the underlying assumption is that internal change-request
demands are independent from the upgrade timing. Table 6.16 demonstrates that the
cumulative ERP lifecycle maintenance cost increases with an increase in the upgrade time for
the installed version. In this particular (hypothetical) example, this effect is mainly due to the
large amount of opportunity costs attached to the new version. Sensitivity analysis is also
conducted on the marginal error, in estimating the patch reduction rate, modification-
enhancement reduction rate, K (i.e. a scalar to indicate the impact of a modification-
enhancement on patch-maintenance effort), user opportunity cost (if delay or forego upgrade),
upgrade cost, the percentage of additional benefits from continuous business improvement
and inflation rate, on the cumulative ERP maintenance cost. It is found, based on an 10%
increase in each of the variables’ estimated value (one at a time), user opportunity cost has the
most impact (i.e. 5.4%) on the cumulative ERP lifecycle maintenance cost, if no upgrade is
implemented. On the other hand, if upgrade option is selected then the estimated upgrade cost
is the most influential factor (i.e. 3.3%) affecting the cumulative ERP lifecycle maintenance
cost (based on the hypothetical example given in this thesis). This is followed by the
estimated value for inflation rate, the percentage of additional benefits from continuous
business improvement, K, patch reduction rate and modification reduction rate. The
sensitivity of this marginal error on upgrade timing is also conducted. It is observed (from the
given hypothetical example) that even with a marginal error as large as 50%, the upgrade
timing still remains the same, i.e. upgrade by the end of the third year. (This is because the
cumulative ERP maintenance cost increases if the upgrade is delayed.) However, when the
marginal error in user opportunity cost, upgrade cost, the percentage of additional benefits
from continuous business improvement and inflation rate are combined, holding other
factors/variables constant, the upgrade timing is affected.
6-43
Table 6.17 summarizes the various decision problems that can be resolved using the proposed
decision framework and general model, and highlights the information required for usefully
applying the proposed decision framework.
6-44
Table 6.11: Historical data on CSA's internally and externally originated
change-requests
Staff hourly rate = $ 100.00 Inflation rate per year = 10% Internally originated maintenance requests
Number of request Maintenance effort
Change- request type
Total (in 20-mths)
Ave. (#/ month)
Mean (hours)
Hours / month
Total cost/month
Annual cost
User-enhancement 43 2.15 47.23 101.54 $10,154.45 $121,853.40 Corrective 223 11.15 11.59 129.22 $12,922.85 $155,074.20Master-data-change 99 4.95 7.02 34.74 $ 3,474.90 $ 41,698.80 CSA-enhancement 228 11.4 16.92 192.88 $19,288.80 $231,465.60 $550,092.00
Externally originated maintenance requests: patch-maintenance
# of patch/ year
# of patch-maint./ year
Ave. # of patches
Ave. # of hours/ patch
Total patch-maint. cost/ patch-maint.
Annual patch-maint. cost
Patch-maintenance 26 2 13 46 $ 59,800.00 $119,600.00
Estimated number of (internally originated) change-requests over the next 10 years Number of change-requests
Year Decrease rate
User-enhancement Corrective
Master-data-change
CSA-enhancement
1 NA 26 134 59 137 2 25% 19 100 45 1033 15% 16 85 38 874 5% 16 81 36 835 3% 15 79 35 806 1% 15 78 35 807 0% 15 78 35 808 0% 15 78 35 809 0% 15 78 35 8010 0% 15 78 35 80
6-45
Table 6.12: User-enhancement and patch-maintenance effort
Percentage of user-enhancements potentially affected by patch-maintenance = 63% Impact of modification-enhancement on patch-maintenance effort Number of patches Number of user-enhancement Cumulative # of user-enhancements
Year # / batch # / year Affected by patch-maintenance Cumulative value
Affected by the patch-maintenance
Affected by the 1st batch of patch-maintenance
Affected by the 2nd batch of patch-maintenance
1 13 26 16 26 16 8 16 2 13 26 12 45 28 22 283 13 26 10 62 39 34 394 0 0 10 77 49 44 495 0 0 10 92 58 53 586 0 0 9 107 68 63 687 0 0 9 122 77 72 778 0 0 9 137 87 82 879 0 0 9 152 96 91 9610 0 0 9 167 105 101 105
The impact of modification-enhancements on patch-maintenance effort is -- an additional cost computed based on the following formula: K X [# of modification-enhancements X the modification-enhancement implementation cost] where K = is the scalar for the impact of modification-enhancement on patch-maintenance effort Additional patch-maintenance cost
Patch-maintenance cost (without modification-enhancement) K=0.1
Year Batch-1 Batch-2 Total cost Batch-1 Batch-2 Total patch-maintenance cost (involving modification-enhancement)
1 $ 59,800.00 $59,800.00 $119,600.00 $ 3,838.38 $ 7,676.76 $ 131,115.15 2 $ 62,790.00 $65,780.00 $128,570.00 $ 11,083.33 $ 14,777.77 $ 154,431.10 3 $ 68,770.00 $71,760.00 $140,530.00 $ 18,263.50 $ 21,993.93 $ 180,787.43
6-46
Table 6.13: User opportunity cost for not upgrading
Additional (percentage of) benefit from continuous business improvements = 30% User Opportunity Cost for not Upgrading
Year Business benefit for having the new version
Continuous business improvement Total opportunity costs
4 $ 1,000,000.00 $ - $ 1,000,000.00 5 $ 900,000.00 $ 270,000.00 $ 1,170,000.00 6 $ 810,000.00 $ 243,000.00 $ 1,053,000.00 7 $ 729,000.00 $ 218,700.00 $ 947,700.00 8 $ 656,100.00 $ 196,830.00 $ 852,930.00 9 $ 590,490.00 $ 177,147.00 $ 767,637.00 10 $ 531,441.00 $ 159,432.30 $ 690,873.30 Table 6.14: Impact of upgrade on enhancement-done and patch-maintenance
Reduction in number of modification-enhancements = 0.33333 x total number of modification-enhancements If upgrade happens at the beginning of year-4:
The total number of user-enhancements (by the end of the 3rd year) will reduce from: 62 to 41
and the total number of modification-enhancements will reduce from: 39 to 26. The new version would probably reduce the number of patches by: 21% of the number of patches in the previous version Thus, the number of patches introduced per year = 21 Therefore, number of patches in each patch-maintenance project would theoretically reduce to = 10 (assuming that CSA continue to maintain the patch only twice in a year) Percentage of user-enhancements potentially affected by patch-maintenance = 63%
6-47
Number of patches Number of user-enhancements Cumulative number of user-enhancements done
Year Patches/ batch
Patches/ year #
# affected by the patch-maintenance #
# affected by the patch-maintenance
# affected by the 1st batch of patch-maintenance
# affected by the 2nd batch of patch-maintenance
4 10 21 16 10 57 36 31 36 5 10 21 15 10 72 45 40 456 10 21 15 9 87 55 50 557 0 0 15 9 102 64 59 648 0 0 15 9 117 74 69 749 0 0 15 9 132 83 78 8310 0 0 15 9 147 93 88 93 Staff hourly rate = $ 100 Inflation rate = 10% Average hour/patch = 46
Patch-maintenance cost (without user-enhancement)
Additional patch-maintenance cost (K=0.1)
Year Batch-1 Batch-2 Total cost Batch-1 Batch-2
Total patch-maintenance (involving user-enhancement)
4 $ 59,052.50 $61,414.60 $ 120,467.10 $ 18,179.34 $ 21,928.52 $ 160,574.95 5 $ 63,776.70 $66,138.80 $ 129,915.50 $ 25,816.01 $ 29,928.99 $ 185,660.51 6 $ 68,500.90 $70,863.00 $ 139,363.90 $ 34,234.77 $ 38,763.78 $ 212,362.45 7 $ - $ - $ - $ - $ - $ - 8 $ - $ - $ - $ - $ - $ - 9 $ - $ - $ - $ - $ - $ - 10 $ - $ - $ - $ - $ - $ -
6-48
Table 6.15: Total annual and cumulative ERP maintenance costs
Total ERP software maintenance and opportunity costs: continuing maintaining the old system* Maintenance Cost
Year User-
enhancement Corrective Master-data-
change CSA-
enhancementPatch-
maintenance User opportunityTotal annual ERP
costs
Cumulative total ERP maintenance and opportunity costs
1 $ 121,853.40 $ 155,074.20 $41,698.80 $231,465.60 $ 131,115.15 $ - $ 681,207.15 $ 681,207.15 2 $ 100,529.06 $ 127,936.22 $34,401.51 $190,959.12 $ 154,431.10 $ - $ 608,257.00 $ 1,289,464.15 3 $ 93,217.85 $ 118,631.76 $31,899.58 $177,071.18 $ 180,787.43 $ - $ 601,607.81 $ 1,891,071.96 4 $ 95,936.70 $ 122,091.86 $32,829.99 $182,235.76 $ - $ 1,000,000.00 $ 1,433,094.31 $ 3,324,166.26 5 $ 100,216.96 $ 127,539.03 $34,294.71 $190,366.28 $ - $ 1,170,000.00 $ 1,622,416.98 $ 4,946,583.24 6 $ 106,301.56 $ 135,282.47 $36,376.89 $201,924.23 $ - $ 1,053,000.00 $ 1,532,885.15 $ 6,479,468.39 7 $ 113,388.33 $ 144,301.30 $38,802.01 $215,385.85 $ - $ 947,700.00 $ 1,459,577.49 $ 7,939,045.89 8 $ 120,475.10 $ 153,320.14 $41,227.14 $228,847.46 $ - $ 852,930.00 $ 1,396,799.84 $ 9,335,845.72 9 $ 127,561.87 $ 162,338.97 $43,652.27 $242,309.08 $ - $ 767,637.00 $ 1,343,499.18 $ 10,679,344.90 10 $ 134,648.64 $ 171,357.80 $46,077.39 $255,770.69 $ - $ 690,873.30 $ 1,298,727.82 $ 11,978,072.73 Total ERP software maintenance costs: upgrade to the new version** Maintenance Cost
Year User-
enhancement Corrective Master-data-
change CSA-
enhancementPatch-
maintenance Upgrade Total annual ERP
costs Cumulative total ERP
maintenance costs 1 $ 121,853.40 $ 155,074.20 $41,698.80 $231,465.60 $ 131,115.15 $ - $ 681,207.15 $ 681,207.15 2 $ 100,529.06 $ 127,936.22 $34,401.51 $190,959.12 $ 154,431.10 $ - $ 608,257.00 $ 1,289,464.15 3 $ 93,217.85 $ 118,631.76 $31,899.58 $177,071.18 $ 180,787.43 $ - $ 601,607.81 $ 1,891,071.96 4 $ 95,936.70 $ 122,091.86 $32,829.99 $182,235.76 $ 160,574.95 $ 3,000,000.00 $ 3,593,669.26 $ 5,484,741.22 5 $ 100,216.96 $ 127,539.03 $34,294.71 $190,366.28 $ 185,660.51 $ - $ 638,077.48 $ 6,122,818.70 6 $ 106,301.56 $ 135,282.47 $36,376.89 $201,924.23 $ 212,362.45 $ - $ 692,247.60 $ 6,815,066.30 7 $ 113,388.33 $ 144,301.30 $38,802.01 $215,385.85 $ - $ - $ 511,877.49 $ 7,326,943.79 8 $ 120,475.10 $ 153,320.14 $41,227.14 $228,847.46 $ - $ - $ 543,869.84 $ 7,870,813.63 9 $ 127,561.87 $ 162,338.97 $43,652.27 $242,309.08 $ - $ - $ 575,862.18 $ 8,446,675.81 10 $ 134,648.64 $ 171,357.80 $46,077.39 $255,770.69 $ - $ - $ 607,854.52 $ 9,054,530.34 *NPV =-$3,416,544.45; **NPV =-$2,330,398.18
6-49
Total ERP Annual Maintenance Costs
$-$500,000.00
$1,000,000.00$1,500,000.00$2,000,000.00$2,500,000.00$3,000,000.00$3,500,000.00$4,000,000.00
1 2 3 4 5 6 7 8 9 10
No Upgrade Upgrade
Cumulated ERP Maintenance Costs
$-$2,000,000.00$4,000,000.00$6,000,000.00$8,000,000.00
$10,000,000.00$12,000,000.00$14,000,000.00
1 2 3 4 5 6 7 8 9 10
No Upgrade Upgrade
Figure 6.7: Comparison in annual and cumulative maintenance costs between the two options
6-50
Savings from upgrading
-$2,500,000.00-$2,000,000.00-$1,500,000.00-$1,000,000.00
-$500,000.00$-
$500,000.00$1,000,000.00$1,500,000.00
1 2 3 4 5 6 7 8 9 10
Year
-$2,500,000.00-$2,000,000.00-$1,500,000.00-$1,000,000.00
-$500,000.00$-
$500,000.00$1,000,000.00
1 2 3 4 5 6 7 8 9 10
Year
Savings from upgrading
Figure 6.8: Savings from upgrading the installed version
Table 6.16: Sensitivity analysis between cumulative ERP maintenance costs and upgrade timing
Delay in upgrade (# of years)
Reduction in patch-maintenance cost*
Increase in upgrade cost**
Increase in opportunity cost***
Impact on cumulative ERP maintenance costs
Changes in the cumulative ERP maintenance costs
0.5 -$ 77,231.84 $150,000.00 $ 500,000.00 Increase $ 572,768.16 1 -$ 160,574.95 $300,000.00 $ 1,000,000.00 Increase $ 1,139,425.05 2 3
-$ 346,235.46 -$ 558,597.91
$600,000.00 $900,000.00
$ 2,170,000.00 $ 3,223,000.00
Increase Increase
$ 2,423,764.54 $ 3,564,402.09
*See Table 6.14 (this reduction is because some patches can be implemented together during an upgrade project). **Assume an increase of $300,000 per annum (based on 10% inflation rate). *** See Table 6.13.
6-51
Table 6.17: Decision problem and the application of the proposed decision framework
Decision problem Course of action
Mechanism to use Information requirement / assumption
Should I do the request? Do-it or do-
nothing
One of the cost functions in the
decision framework
The next upgrade period is known in advance.
When should I upgrade? Timing General model (1) The ERP client organization has a clear plan for future
business directions and goals.
(2) The pattern of the vendor patch-introduction and new
version / release policies are known to the ERP client
organization.
(3) Internal ERP maintenance demands’ pattern are
predictable, based on historical data.
Which request should I
implement first?
Decision policy Two or more cost functions in the
decision framework
The next upgrade period is known in advance.
6-52
6.6 Summary
It is found that on average a patch is almost as effort demanding as a user-enhancement
request. Patch-maintenance effort is driven by the type of enhancements done to the standard
ERP code, and the amount of modification-enhancement done. Upgrade implementation cost
also depends on version-gap or migration-path between an existing and a new upgrade
version. Upgrade cost is a major issue, and prohibitive for CSA in considering its ERP system
upgrade. These findings are consistent with those reported in the trade press, see (AMR, 2002;
McDonnell, 2000; Thompson, 2001). It was found, however, that after the upgrade the
number of modification-enhancements done decrease by one-third of the original total.
Analysis of the number of notes showed that the total number of notes and patches decreased
by about 21% from an older version to a newer version.
Results from this study on ERP maintenance and upgrade environment show that (1) user
opportunity and benefit-realization, (2) reduction in number of previous modifications, and (3)
potential reduction in number of future patch-maintenance are important characteristics (or
factors) for an ERP maintenance and upgrade decision environment. Furthermore, findings
from this chapter show that in-house software replacement models are inappropriate in the
context of ERP. In-house software replacement models are: (1) irrelevant because of the
following characteristics considered in the models: software technology, system size and
system age, and (2) insufficient because they do not captured the benefits and user opportunity
associated with maintenance/ upgrade requests, do not consider the availability of
maintenance support from the vendor, and do not incorporate the reduction in number of
previous modification-enhancement in a newer version. Though user opportunity and
reduction in the number of future maintenance requests may also be applicable for in-house
software, they were not considered in the existing literature. Reduction in the number of
previous modification-enhancements is unlikely to be an in-house software replacement driver
because its internal system enhancements are unlikely to be available from external sources
and therefore could not be replaced or reduced. In light of these differences, a specific ERP
maintenance and upgrade decision framework is proposed.
The proposed decision framework is used and incorporated in the ERP maintenance
methodology proposed later in Chapter 7.
6-53
7-1
7 An ERP Maintenance Methodology1
The objective of this chapter is to: examine the fundamental activities and tasks in ERP
maintenance methodology, investigate if the existing maintenance methodology is appropriate
in the context of ERP, and develop an ERP maintenance methodology. A maintenance
methodology in this study is defined as a maintenance model or process used to describe
activities covered in: software maintenance preparation stage, software maintenance
procedure stage, and software upgrade stage. This sub-study has been limited to comparing
IEEE/EIA 12207.2-1997, which is mainly meant for in-house software maintenance, with an
ERP maintenance methodology synthesized from CSA. Although comparison between an
ERP maintenance methodology and commercial off-the-shelf (COTS) related maintenance
activities is important, it deserves separate discussion and is not the focus in this study.
The research questions addressed in this chapter are: What activities and tasks should be
incorporated and reflected in an ERP maintenance methodology? What are the activities
associated with an ERP maintenance methodology? Is the existing standard for software
maintenance methodology appropriate in the context of ERP? What are the activities and
tasks that are unique to ERP maintenance environment? The data collection and data analysis
process for this chapter is detailed in Chapter 3, Section 3.3.4.
The organization of this chapter is as follows. Section 7.1 presents CSA’s ERP maintenance
methodology. Section 7.2 discusses the deficiencies in the existing standard software
maintenance methodology based on the empirical data in Section 7.1. Section 7.3 reviews the
strengths of IEEE/EIA 12207.2-1997 in comparison with CSA’s maintenance methodology
(from Section 7.1). Founded on observations in Section 7.1 and Section 7.3, Section 7.4
describes how CSA can improve its existing ERP maintenance methodology. Section 7.5
presents an ERP maintenance methodology based on findings from CSA (Section 7.1 and
7.4), previous chapters and existing ERP literature. The main research outputs from previous
1 The findings and discussions in Section 7.1 and 7.2 of this chapter were submitted to the International Conference on Software Maintenance (ICSM 2002). Although the initial paper was rejected, Section 7.1 and 7.2 have now been revised appropriately according to the reviewers’ feedbacks and have been published in the Proceedings of Pacific Asoa Conference on Information Systems (see (Ng et al., 2003a)). The findings and discussions in Section 7.4 and 7.5 have mostly been published in the Proceedings of IEEE Hawaii International Conference on System Sciences (see (Ng et al., 2003b)).
7-2
chapters incorporated in the proposed ERP maintenance methodology are: (1) the proposed
ERP maintenance taxonomy (in Chapter 4), for classifying maintenance requests; (2) the
factors driving ERP maintenance effort (in Chapter 5), for estimating maintenance effort; and
(3) the recommended ERP maintenance and upgrade (MU) decision framework (in Chapter
6), for making MU decisions. The benefits of this methodology are also discussed. Lastly,
Section 7.6 provides the chapter summary. This is summarized in Figure 7.1.
Chapter 4:Taxonomy
Chapter 5:Effort
7.1CSA's ERP
MaintenanceMethodology
7.2Discussion onDeficiency in
IEEE/EIA 12207.2-1997
7.4Discussion on
Improvements to CSA'sERP Maintenance
Methodology
7.5The Proposed
ERP MaintenanceMethodology
7.6Summary
Chapter 6:Decision
Chapter 7:Methodology
ERP MU decision framework
ERP maintenance effort determinantsERP maintenance taxonomy
7.3Strengths of IEEE/EIA 12207.2-1997
Figure 7.1: The flow of Chapter 7
7.1 CSA’s ERP Maintenance Methodology
Adopting the new2 definition of software maintenance given by the ISO/IEC (1995) and
Pigoski’s (1997) maintenance methodology in this thesis is defined as a maintenance model
or process used to describe activities covered in: software maintenance preparation stage,
software maintenance procedure stage, and software upgrade stage. These three stage-names
are renamed in this study rather than using the maintenance activity names given in the
Institute of Electrical and Electronics Engineers and Electronic Industries Association
(IEEE/EIA) Guide for Information Technology – Software Life Cycle Processes –
Implementation Considerations (or IEEE/EIA 12207.2-1997) because the proposed terms are
believed to be less ambiguous and more intuitive. (IEEE/EIA 12207.2-1997 is an adaptation
of the International Organization for Standardization and International Electrotechnical
Commission (ISO/IEC) Information Technology – Software Life Cycle Processes (or
7-3
ISO/IEC 12207).) For instance, maintenance preparation is more intuitive than ‘process
implementation’ (from IEEE/EIA 12207.2-1997); and software upgrade is more generally
used in the ERP context than ‘software retirement’.
Maintenance preparation in this study is defined as activities involves in initiating and
planning for software maintenance management issues and maintenance process.
Maintenance procedure describes the sequence of activities involved in organizing, managing,
executing, and monitoring a software maintenance request. Software upgrade explains the
activities that take place in replacing an installed ERP version with a new release/version
from the same vendor. However, it does not include activities involved in replacing an
installed ERP version with a custom system or an ERP system from a different vendor.
In this section, CSA’s ERP maintenance methodology is synthesized. This is done by
mapping the relevant information from different data sources onto the corresponding stages,
i.e. maintenance preparation, maintenance procedure and software upgrade stages (see
Chapter 3, Section 3.3.4 for details on data analysis). Discussion and an explanation of the
activities and tasks done by CSA in these three stages are illustrated in indented paragraph in
Sections 7.1.1 to 7.1.3.
7.1.1 Maintenance Preparation
It is observed that senior management of CSA participate actively in the maintenance
preparation stage. They pay considerable attention to vendor support issues, benefit-
realization (from the ERP system), maintenance expenditures, maintenance services provided
to user departments, and other maintenance management issues.
The following is a summary of the basic activities involved in ERP maintenance preparation
stage. It has been distilled from data collected in the interviews with CSA’s senior managers
and CSA’s documentation (i.e. Upgrade Business Case, and SAP R/3 Upgrade Planning
Resources). (Chapter 3, Figure 3.6 provides an illustration of this.) Activities identified are:
Define the core objectives of maintenance and/or revisit the initial objectives of
ERP project implementation.
2 Note that software maintenance methodology previously proposed in IEEE Standard for Software Maintenance (1998) did not pay much attention to maintenance preparation stage and software replacement stage (see also (Pigoski, 1997)).
7-4
The core objectives for CSA to maintain the system are to: continue to
maximize business value from the system; facilitate information flows
demanded by partnership in a global environment and local organizational
environment; keep the system up-to-date; and protect the initial investment and
continuously “re-invest in the investment”.
Identify the scope, benefits, costs, and risks of the system.
The scope of ERP maintenance for CSA involves mainly the two installed
modules –Human Resources and Finance.
The benefits which CSA aims to achieve from the systems are to: operate with
leading functionality to continue to provide vital public and government
services at a standard competitive with leading businesses; achieving
effectiveness in delivery services and efficiency in internal processes; retaining
highly valued staff; and improving processes and information services in the
future.
The major costs associated with the system are labor cost, maintenance cost
and upgrade cost.
Risks associated with the ERP software are the cost (escalation) and funding;
uncertainties involved in benefit-realization; the software not being supported
by the vendor; and that it may require more than a single upgrade step to bring
the system to a current level (if CSA falls too far behind in its upgrade path).
Estimate resources required and/or outsourcing needs.
CSA considerations, in this matter, include: determining the demand for the
system based on the number of users to serve, number of business units,
departments and software modules involved; deciding the criteria for service
level agreement (SLA); identifying the knowledge worker and the number of
staff required; and justifying if outsourcing is needed. In fact, CSA outsources
the facilities management of its SAP system to an external organization (see
also Chapter 3, Section 3.1.1).
Outline maintenance support from the vendor such as the support window3 for the
software, conditions to remain eligible for maintenance support, the types of
maintenance support available from the vendor, how and where to get them.
3 Support window is a time period, during which a client-organization is eligible for helpdesk support, bug fixes, and new and/or improved features from the vendor. Typically a vendor will support a given version of its software for 2-3 years, though the length of this period varies greatly.
7-5
Vendor support for CSA’s existing (a newly replaced) version of 4.6C of R/3
system is expected to expire in March 2005. The primary condition for a
software version to remain eligible for maintenance support is to stay on the
recommended software upgrade path. The types of support available to CSA
are patches and a new version for upgrade. This vendor support information is
obtained from the SAP’s extranet called Online Support Systems (OSS).
Define a maintenance organization, for instance maintenance unit(s) or team(s),
and maintenance team(s) responsibilities and job specifications.
There are two maintenance teams at CSA responsible for managing ERP
maintenance activities, namely the development team and the technical team.
The development team is part of the SAP R/3 development group and is
headed by the Systems Development Manager. One hundred percent of this
team’s effort is devoted to R/3. This includes implementing bug fixes (or
patches) and making functionality changes and enhancements to the system.
The Technical Team is part of the SAP R/3 operations support group. This
team is managed by the Systems Operations Manager and is responsible for
ensuring the continuing operations of the R/3. It liaises with the service bureau,
which provides the technical/hardware service for the R/3 operations.
Although the members in this operations support group are also responsible for
non-SAP R/3 related operations, 80% of their effort and time is devoted to R/3.
Define the maintenance management issues: all the environments needed for
maintenance, a mechanism to identify, and classify maintenance requests.
CSA keeps three environments of the ERP system: development (DEV),
quality assurance (QAS), and production (PRD). The DEV is an archive of the
version/instance of the existing system where the resolutions or new
developments for maintenance requests are first made. QAS, which is “almost”
an instance of the production system, is used for testing the correctness of the
maintenance resolution and/or integrity of the new development, and
conducting user acceptance tests before the maintenance resolution is delivered
to the production system. PRD is the most critical and an online version of the
ERP system; it is the system which users are using for day-to-day operations,
conducting traditional business processing and functions, and which
stakeholders use for business transactions.
7-6
Unique identification numbers will be issued to all the maintenance requests (if
they are qualified).
CSA classifies its maintenance requests into seven categories: user-support,
user-enhancement, CSA-enhancement, corrective, master-data-change, patch-
maintenance, and new version for upgrade. (Details on these maintenance
requests are discussed in Chapter 4.)
Establish maintenance strategies, including how each maintenance category is
serviced (for example batch, or ad-hoc).
CSA batches the patches and attempts to minimize the number of upgrades as
much as possible in order to contain the total cost of ownership (TCO) for the
ERP software.
Maintenance requests such as bug fix and adaptation to the external
environment will have a higher priority than enhancement requests. Other
maintenance requests involving queries such as ERP system functionality and
system operation issues will be solved ad-hoc whenever possible. Maintenance
activities related to the Human Resource (HR) module are more critical than
those on the Finance (FI) module. Hence, bugs on HR are often given higher
priority than bugs on FI.
Define maintenance service for the system users, for example the types of
maintenance support available to the users, how and where to access them, types
of maintenance requests required to be charged back to the user’s organization,
and what criteria the fees will be based on.
All types of maintenance requests related to user support, training, system
functioning and behavior, error report, enhancement and software change are
required to be reported at the helpdesk at CSA. While no extra cost will incur
to the users’ organizations in most cases, requests related to the system
enhancement will incur a fee.
Establish a software configuration management (SCM) plan.
The configuration items4 are identified by the vendor and are kept in the
version archive. SAP R/3 does provide an automated software configuration
management tool for its clients. It is called Change and Transport System
(CTS). Section 7.1.2.1 will provide more details on this.
4 According to Carney et al (2000) the configuration items kept in the version archive should include an assessment of risks – including probable type of failure, severity of the effect to the system and user if the components should cease to function as expected) (pg. 372)
7-7
Maintenance requests associated with user-support and access authorization
need to be approved by the Systems Operations Manager, whereas the Systems
Development Manager approves requests related to changes to the software.
Develop training and helpdesk policies, including deciding how much training is
needed, and what types of training should be provided to the maintenance staff,
system users and stakeholders be provided.
Training needs for the users are dependent on the degree of change between
the existing system and the new system after the maintenance or upgrade.
Refresher classes are also available to the users based on demand.
Training will also be provided to staff when there are needs for learning new
techniques or software systems.
Define the maintenance procedure, and the sequence of the maintenance activities
involved.
Details of the maintenance procedure are provided in Section 7.1.2.
7.1.2 Maintenance Procedure
CSA’s maintenance activities are initiated from essentially two sources: the system users and
IT-staff, and the software vendor. The former source introduces requests such as user-support,
corrective, master-data-change and enhancement. These requests, except the user-support, are
called change-requests. The latter introduces patches and new versions for upgrade. (More
discussions on CSA’s maintenance request classification were given in Chapter 4.) As these
two groups have different maintenance procedures (in some steps), they are discussed
separately in this section. Activities detailed in this section are synthesized from interviews
conducted with CSA’s senior managers and/or substantiated by information in CSA’s change-
request and user-support databases (as illustrated in Chapter 3, Figure 3.6).
7.1.2.1 Servicing Maintenance Requests From The System Users And IT-Staff
Maintenance requests are usually reported to CSA’s helpdesk. They can be received via
telephone call, email, request form, or verbally. Once a request has arrived, all its
maintenance details will be recorded in the relevant database. Steps involved in processing the
system user and IT-staff maintenance requests are dependent on the type of requests and
7-8
whether vendor support is available. These are discussed separately in sub-sections A to E,
and are depicted in Table 7.1.
Table 7.1: Maintenance request and its maintenance procedure discussion section
Vendor support Type Request
Yes No
Discussed in sub-section
User-support User-support NA NA A
Corrective, master-data-change X — B
Corrective, master-data-change — X C
User-, CSA-enhancement X — D
Change-request
User-, CSA-enhancement — X E
NA = not applicable.
A. User-support request
Create and issue a request form.
This is addressed by the technical team. A user-support request form is created.
Classify and prioritize request.
The request is analyzed – by studying the root of the problem (for example,
inadequate training, or need for consultation on software functionality). It is
classified by the helpdesk (if applicable), and prioritized by the Systems
Operations Manager, and implemented by the technical team.
Resolve the problem/request directly and/or direct the request to the right person
for solution.
Simple security issues and training requests are handled by the helpdesk (the
1st tier support), whereas for requests concerning functional aspects or the
usage of a module in SAP, expert in that functional area (the 2nd tier support) is
contacted for further assistance in resolving the request. Requests which cannot
be resolved by the 2nd tier support are passed on to the Business Analyst (the
3rd tier support) for that module. The Business Analyst will then determine
whether a change-request should be issued.
If a request is classified a change-request, it will be further classified and approved by CSA’s
Systems Development Manager for further maintenance investigation. A maintenance-request
form will be created and the request will be prioritized (based on the request category). The
subsequent activities that follow are based on the category of the request.
7-9
B. Corrective/master-data-change (- related to vendor’s code)
Search for maintenance support and/or report the bugs to the vendor.
Requests pertinent to bug fixes found in the vendor’s code are handled by the
technical team. This is usually done by first searching for the available bug
fixes from the vendor through the Online Support System (OSS) notes. (OSS is
a Web-based system where information regarding bug fix and enhancement is
distributed by the vendor worldwide, and is also where SAP clients can send
requests for maintenance support.) The vendor’s code will be used to solve the
bug whenever vendor support is available. If the bug fix is not available from
the vendor, the bug will be reported back to the SAP through the OSS with the
assistance of a Business Analyst.
Apply vendor’s code and conduct impact analysis.
After the bug fix has been applied to the development system (DEV), a
detailed impact analysis will be conducted in the system to examine the
impacts of the vendor’s code on the CSA’s previous modification-
enhancements.
Perform modification-enhancement adjustment, system testing, user acceptance
test, and deliver the new system to user.
Bug fixes or changes that have no impact on the previous modification-
enhancements do not require any adjustments. They will be grouped and
organized by using the Change and Transport Organizers (CTO) (see Chapter
2, Section 2.1.1 for more details) and will be transported to the quality
assurance system (QAS) using Transport Management System (TMS). Both
CTO and TMS are in the SAP’s Change and Transport System (CTS). (TMS
organizes, monitors, and performs imports for all R/3 systems within a system
landscape (McFarland, 1999). CTS is the SAP change management system.) In
the QAS, system testing and user acceptance testing will be conducted.
Conversely, if re-application of the previous modification-enhancements is
needed, the SPDD and SPAU transactions will be used. These two transactions
are provided by SAP to facilitate viewing and adjustment of client’s
modification-enhancements. These changes are then grouped using CTO and
transport to the QAS using TMS. A whole system testing is required in the
QAS, prior to transporting to the PRD.
7-10
C. Change-request: corrective/master-data-change (- related to custom code or objects)
Design solution for the problem and update the relevant documentation.
The solution for the request will be designed. The related documentation will
be reviewed and updated.
Implement changes.
The changes are then implemented in the development system (DEV). These
changes are grouped and organized by using the CTO prior to transporting
them to the QAS.
Transport changes to the system for testing and verification.
These changes are transported by the technical team from the DEV system into
the quality assurance system (QAS) using the TMS for testing and verification
of the business processes.
Transport the new system into the production.
After the changes have been tested and the system users are satisfied, the
changes are then transported into the production system (PRD).
D. User-enhancement/CSA-enhancement (- support available from the vendor)
Conduct cost-estimation for the maintenance.
The Systems Development Manager will estimate the cost of the enhancement
maintenance.
Issue a quotation to the user (if the request is a user-enhancement).
The respective system user organization will be informed of the quotation for
the work. A quotation form will be issued for this purpose.
Obtain approval from the user-department (if the request is a user-enhancement)
and maintenance manager, and prioritize request based on the criticality and
urgency of the request.
Once the system user organization has agreed to pay the price, the Systems
Development Manager will approve, prioritize, and assign the request for
implementation.
Apply the vendor’s code and conduct impact analysis in the DEV system.
After the solution has been applied, the changes will be grouped and
organized, a detailed impact analysis will be conducted to examine the impacts
of the vendor’s code on CSA’s previous modification-enhancements.
7-11
Perform modification-enhancement adjustment, system testing and user
acceptance test in the QAS system.
Bug fixes or changes that have no impact on the previous modification-
enhancements do not require any adjustments, and the changes will be
transported to the quality assurance system (QAS) for system testing and user
acceptance testing and then delivered to the production system (PRD).
Conversely, if re-application of the previous modification-enhancements is
needed, the SPDD and SPAU transactions will be used. These changes are then
grouped using CTO and transport to the QAS using TMS. A whole system
testing is required in the QAS.
Deliver the new system to user
The technical team will liaise with the system bureau to transport the changes
from the QAS system to the production system.
E: User-enhancement/CSA-enhancement (- no support available from the vendor)
Report the request to the vendor.
The Business Analyst in that functional area will investigate if the vendor has
recently released the requested enhancement. If it is not available, this new
requirement will be reported back to the vendor for future development.
Propose and approve solution.
The Business Analyst will propose a solution for the request. The solution will
be submitted to the Systems Development Manager for assessment, who is a
member of the configuration control board (CCB).
Conduct cost-estimation for the maintenance.
The Systems Development Manager will estimate the cost of the enhancement
maintenance. (If it is a user-enhancement, the implementation cost is paid by
the user department, but ongoing maintenance costs for this maintenance are
absorbed by CSA.)
Issue a quotation form to the user, and obtain approval from the user (if the request
is a user-enhancement).
The respective system user organization will be informed of the quotation for
the work. A quotation form will be issued for this purpose.
Approve and prioritize request based on the criticality and urgency of the request.
7-12
Once the system user organization has agreed to pay the price, the Systems
Development Manager will approve, prioritize and assign the request for
implementation.
Design solution and update the relevant documentation.
The solution for the request will be designed. The related documentation will
be reviewed and updated.
Implement changes.
The changes are then implemented in the DEV. These changes are grouped and
organized by using the Change and Transport Organizers (CTO), in the SAP’s
Change and Transport System (CTS), prior to transporting them to the QAS.
Transport changes to the QAS system for testing and verification.
These changes are transported by the technical team from the DEV system into
the QAS system using the Transport Management System (TMS) (in the CTS)
for testing and verification of the business processes.
Transport the new system into the production.
After the changes have been tested and the system users are satisfied, the
changes are then transported into the PRD system.
Note that for corrective and master-data-change requests, regardless of the originator (either
the system users or IT-staff) the same maintenance procedure is followed. The main
difference between the procedure for a system user initiated enhancement, and that for an IT-
staff initiated enhancement, is that the latter will not incur a cost to the system users5. Figure
7.2 (derived from the interviews with CSA) shows the flowchart of maintenance procedure
for requests initiated by system users and IT-staff at CSA.
5This is based on the particular charge-back arrangements it has with the system users’ departments. This situation is not unique to ERP or service provider. However, increased research attention to maintenance implications of outsourcing and shared services is warranted.
7-13
1.Request for
maintenance
13.Proposesolution
8..2Report back to
the vendor
14.Approve the
proposedsolution
15.Issue a
quotation forthe
maintenance
7.Prioritize thecorrective /
master-data-change request
11.Approve the
enhancementrequest for
furtherinvestigation
6.Approve thecorrective /
master-data-changerequest
5.Assign ID &
Classifymaintenance
request
4.Create a user
supportrequest and
prioritizerequest
16.Accept the
maintenancequotation
2.Log the details
into the database& conductpreliminary
analysis
3.Should achange
request beissued?
Yes(changerequest)
No(user support)
8.1Does the bugfix available in
the vendorOSS notes?
No
DEV = Development SystemPRD = Production SystemQAS = Quality Assurance System
20.Update
documentation
18.Design solution
19.Implement the
solution
10.Check theimpacts onprevious
enhancementmodification(s)
9.Implement bugfixes / patches
10.1Is re-
application ofprevious
modificationrequired?
Yes
21.Transport to QAS
for testing,verification, and
integration
22.Transport to
PRD
10.2Reapply the
previousmodifications in
Dev
4.1Resolve and
providefeedback to the
requestor
System users /IT-staff
System users /IT-staff
12.2Report to the
vendor forfuture
development
17.Prioritize
enhancementrequest
8.Bug found inthe vendor's
code?
Yes
No
12.Does the
enhancementavailable inthe vendor
OSS notes?
= Activities not included in IEEE/EIA 12207.2-1997
Yes
No
= Decision not considered in IEEE/EIA 12207.2-1997
12.1Is it a user-
enhancementrequest?
Yes
No
Yes
No
5.1Is it an
enhancementrequest?
No
Yes
19.1Is vendor
support used?
No
Yes
Figure 7.2: Flowchart of CSA’s maintenance procedure for requests from system user and IT-staff
7-14
7.1.2.2 Servicing Maintenance Requests From The Vendor As previously stated, maintenance requests from the vendor come in two forms: patches, and
new versions/releases for upgrade. These two types of maintenance requests are discussed
separately. The following sections provide a brief and precise description of what is done by
CSA and activities involved in the patch-maintenance procedure. Details of the upgrade
process are given in Section 7.1.3.
Patch-maintenance
Create and issue a maintenance-request form.
CSA’s development team addresses the patch-maintenance activities. Patches
are implemented using the SAP Patch Manager (SPAM) system. SPAM is a
SAP tool for downloading patches requested from the Online Support System
(OSS), and for applying patches to the R/3 system. It is the client’s end of
Online Correction Services (OCS). (Its objective is to automate the
management of patches (SAP, 1998c).) CSA usually batches patch-
maintenance in order to achieve economy of scales.
A change-request is created for each batch of patches.
Apply the patches.
The SPAM program is used to apply the patches into the existing ERP system.
A patch will overwrite the existing code with its standard code, until it
identifies the client’s modified code. For each of the custom code found or
when there are discrepancies in the client’s version of the ERP system as
compared to the uncustomized version of ERP, the program will display a
message or give a notice to the maintainer before overwriting the code. The
maintainer has to confirm whether he would like to copy the standard code
over or to keep the custom code by acknowledging the message and interacting
with the program.
(For each custom code that has been overwritten (namely, changes made to the
client’s custom code, program and/or screen), this program will then produce a
report of transports (i.e. an output of all the changes that the patch has made
onto the client’s version of ERP). A unique number is assigned (by the
program) to each of the custom codes it has overwritten. This is important
7-15
because it is where all the changes or the overwritten modifications can be
easily tracked down.)
Conduct detail impact analysis of the patches on each of the previous
modification-enhancements.
A thorough checking of the impact of the patch on each of the previous
modifications will ensue. This is because the implementation of a patch may
bring part of the existing custom code back to the standard code.
Make modification-enhancement adjustments (if necessary).
If the patches do what the previous modification-enhancements were meant to
perform then the standard ERP code will be adopted instead of reapplying the
custom code. Alternatively, the previous modification-enhancements will have
to be re-applied onto the system. In this case, SPDD and SPAU are used to
facilitate modification-enhancement adjustments activity. (More details on this
are given in Chapter 2, Section 2.1.2.)
Transport changes to the quality assurance system (QAS).
These changes will be grouped using Change and Transport Organizers (CTO),
and transported to the QAS system using Transport Management System
(TMS). A complete re-testing of system performance and integration will have
to be carried out in the QAS system.
Transport the new system to the production.
The technical team will liaise with the system bureau to transport the changes
from the QAS system to the production system.
Figure 7.3 summarizes the maintenance procedure involved in implementing a patch (or a
batch of patches).
7-16
Figure 7.3: Flowchart of CSA’s maintenance procedure for patch-maintenance
7.1.3 Software Upgrade
According to CSA, the upgrade process is very similar to the patch-maintenance procedure,
with the main differences being that upgrade requires more thorough planning and business
justification, more effort for impact analysis and re-application of previous modifications or
user-enhancements (if the new version has not incorporated the required functionality), longer
time to complete, more money and resources to implement, and serious considerations of
potential system downtime.
The basic activities included in this section are distilled from CSA’s upgrade documentation
and/or further substantiated by the interview transcripts (as shown in Chapter 3, Figure 3.6).
The activities are as follows.
Design a project methodology for the upgrade.
CSA uses the Accelerated SAP R/3 (ASAP) (introduced by the SAP vendor) as
a guideline for planning and implementation of its upgrade project. It divides
the four high level stages (project preparation, business blueprint, realization
and final preparation) into six major phases: planning, business blueprint (or
project preparation), analysis / construction (or development), user acceptance
testing, trial upgrades, and conversion (or go live).
Research for available upgrade options; and determine their availability dates, pros
and cons, the stability (if possible), and the support window (i.e. vendor
maintenance support completion dates) of each option.
7-17
From CSA’s survey (as at May 2000), it found that there were five upgrade
options applicable for its upgrade considerations: 3.1I, 4.0B, 4.5B, 4.6B, and
4.6C. While most of these releases are stable and are able to offer greater
functionality capabilities, only the latest releases 4.6B and 4.6C were being
considered seriously by CSA’s maintenance managers and were recommended
by the vendor. Release 4.6B was available in late 1999, and 4.6C in June 2000.
The (extended) support windows for these two releases are August 2003 and
March 2005 respectively.
Decide on the type of upgrade (technical or functional).
CSA is considering a technical upgrade – that is, the like for like functionality
replacement. This is to minimize the project risk, complexity and scope. This
upgrade is important for establishing a superior technical platform for CSA to
implement future additional functionality on the new system.
Develop a business case to justify the upgrade decision, and identify the factors
influencing this decision.
According to CSA, its technical upgrade decision is primarily dependent on the
availability of funding, vendor support termination date, and desire to avoid
costly consecutive upgrades in the future.
Plan for the upgrade date.
The upgrade project itself was estimated to take six months. CSA planned for
the upgrade go-live date to be the Easter or Christmas break in order to
minimize work disruptions and downtime.
Evaluate costs for the whole upgrade, and develop a detailed plan for budget
allocations (including the hardware and training costs), and personnel
requirements.
The maintenance managers carried out detailed cost estimation. This includes
project details such as: project duration, number of different personnel (project
managers, programmers, consultants, technical team, testing team, change
management team) required, labor rate per hour, government taxes, and
operating costs (such as hardware costs, PCs costs, training costs). The
assumptions made under this cost estimation are also highlighted.
Assess project risks.
In assessing the upgrade project risks, CSA considers factors such as pressure
to include additional functionality as part of the upgrade, inadequate system
7-18
and procedural documentation, various possible types of delay, availability and
ability to retain resources with appropriate knowledge and skills, number of
change-requests raised during the course of the project (which require
implementation in the upgraded solution), number of patches issued during the
upgrade project, stability and security impact of the upgrade version, funding
allocation, and possible cost escalation.
Make full assessment of the new features or functionality in each upgrade option
and for each module as needed, consider how new functionality benefits the
organization, and draft a plan for benefit realization for the new business
improvements.
Thorough assessments of new and improved functionality provided in each
release candidate (i.e. release 4.6B and 4.6C) for each module used by CSA are
examined.
Some of the identified new and improved functionality in version 4.6B and
4.6C for benefit-realization are graphical user interface, Employee Self Service
(ESS), time/leave management, improved reporting capability, combining
several screens into one, drag and drop functionality, improved consistency
and standardization.
Make recommendation for the upgrade release / version.
Based on the documentation at the time it was drafted, the recommended
release for CSA’s upgrade was 4.6B, as (it perceives that) 4.6C should only be
used in conjunction with mySAP.com functionality, (mySAP.com is an
Internet initiative; it enables e-business functionality for customer relationship
management, supply chain management, electronic commerce, and business
intelligence integrated with an existing R/3 system).
However, at a later stage due to some changes, CSA decided to upgrade to
version 4.6C.
Conduct impact analysis between the new upgrade version and the existing
version.
Under this activity, CSA (i) lists potential business processes that are not yet
used, and customer processes, transactions and reports not used (which
therefore, might not need to be considered for the upgrade) (note that this
could be done using SAP’s reverse business engineer tool); (ii) investigates
the number of modifications on the existing system; (iii) identifies which
7-19
modifications are still needed and those not needed, and (iv) quantifies the
amount of effort required in the upgrade process.
Besides making this assessment internally, CSA also recruited an external
consulting firm to study the modification-enhancements in the installed 3.1H
version. This result from this engagement is details on the number of
modifications done, modifications no longer required, and a soft estimate of
effort to re-implement those modifications still required.
Examine the impacts of the upgrade on user training, interfaces and desktop,
reporting capability, supporting documentations, change management, testing and
security.
In CSA’s situation, extensive re-training of staff and completely new
supporting documentation is required due to the new user interface. Moreover,
reapplying the previous interfaces and reporting capabilities are necessary
whenever they are not available in the new version.
Study the impacts of the upgrade on hardware sizing, database and application
server capacity, and network loading requirements.
According to CSA’s investigation, in relation to upgrade to 4.6 releases (from
3.1 releases), the additional or increment of technical requirements are:
application server 87-103%, disk space 20%, network loading three-fold of the
existing, and some additional PC hardware requirements.
Install the new version onto the development system (DEV).
For CSA’s SAP repository switch, this involves: (i) copying all CSA-
developed objects, and SAP objects that were changed by CSA and not
changed by SAP for this release to the new R/3 Repository; (ii) writing a
version to the version database for those SAP objects that were changed by
CSA and by SAP; (iii) applying all the previous patches (if necessary) onto the
new ERP system; and (iv) merging the new system with the new R/3
Repository, and then merging with the version database.
After merging these two versions, modification-enhancement adjustments are
required. The modified/customized objects can be viewed and adjusted (during
the upgrade process) using two transactions supported by SAP: SPDD and
SPAU (see Chapter 2, Section 2.2.4 for more details).
Construction (or development) – reapplying previous modification and re-
developing previous reporting capability (if necessary).
7-20
All previous developments such as reporting capabilities, interfaces and
function modules are overwritten during the new version upgrade. SPAU lists
all these modified objects, and a decision can be made on whether to reapply
them onto the new system or replace then with the code provided by the
vendor. After all modification-enhancement adjustments are completed in the
DEV, they are grouped in a workbench change-request (using CTO) and
transported/released (using TMS) to upgrade the subsequent system (quality
assurance system and production system).
Conduct a thorough performance, user acceptance, business process validation and
integration test.
CSA conducts system performance, user acceptance, business process
validation and integration tests in the quality assurance system (QAS) to
ensure that the system is functioning properly. User acceptance tests are
important to guarantee that the new system is up and running, and meets the
user requirements and expectations.
Carry out the trial upgrades.
Trial upgrade(s) conducted in the DEV system and QAS system are designed
to practice the upgrade process and to guarantee a successful upgrade to the
production system later on.
Conversion (or go live).
Deliver the well-tested system, as well as the SPDD and SPAU modification-
enhancement adjustment change-requests, into the production system.
7.2 Discussion On Deficiency In IEEE/EIA 12207.2-1997
Having reviewed in detail the activities involved in maintaining and upgrading CSA’s ERP
system, it is observed that there are deficiencies in the Institute of Electrical and Electronics
Engineers (IEEE) and Electronics Industries Association (EIA) Guide for Information
Technology – Software Life Cycle Processes – Implementation Considerations (IEEE/EIA
12207.2-1997), in the context of ERP. This observation is made by analyzing and comparing:
(1) IEEE/EIA 12207.2-1997 software maintenance preparation stage with the synthesized
CSA’s ERP software maintenance preparation stage (see in Section 7.1.1); (2) IEEE/EIA
12207.2-1997 software maintenance procedure stage with the synthesized CSA’s ERP
7-21
software maintenance procedure stage (see Section 7.1.2); and (3) IEEE/EIA 12207.2-1997
software upgrade stage with the synthesized CSA’s ERP software upgrade stage (see Section
7.1.3). These are discussed in Section 7.2.1 to 7.2.3.
7.2.1 Maintenance Preparation
Unlike traditional in-house software, ERP packaged software is not only maintained by the
ERP-using organization but also by the vendor. This observation is consistent with the study
by Hirt et al. (2001). The software vendor plays a significant role in the client/user
organization’s maintenance activities. The vendor introduces maintenance activities (e.g.
patches and new versions) and is responsible for continuous research and development of the
software. This clearly influences an ERP-using organization’s maintenance and upgrade
decisions, strategies and policies. Thus, in preparing for ERP-vendor maintenance support,
issues such as the magnitude and frequency of vendor patch support, and the projected timing
of withdrawal of vendor support for a given version, must be considered. Although the
IEEE/EIA 12207.2-1997 standard for software maintenance methodology is comprehensive in
general, the issue of vendor maintenance support is not considered.
Moreover, some of the maintenance effort-drivers discussed in the standard may not be
applicable in the context of ERP, for example the system age factor. This is because system
age is often an unknown factor (or is transparent) to the ERP-adopting organizations. In
contrast, the number of previous modification-enhancements which change the standard
code/objects is found to affect the magnitude of patch-maintenance effort (this is supported by
the empirical data provided in Chapter 6), yet this is not included in the standard.
7.2.2 Maintenance Procedure
Consistent with the results reported in (Nah et al., 2001), searching for vendor bug fixes, bug
reporting to the vendor, and enquiries regarding new functionality from the vendor are some
of the main maintenance activities in ERP environment. An additional activity found in ERP
maintenance is reapplying previous modifications (whenever necessary) every time patch-
maintenance (or upgrade) is implemented. This is because custom code could be overwritten
by a patch (or a new version). Thus, in order to retain the customized functionality, re-
7-22
application of the previous modification(s) is required. However, these activities were
excluded during the development of the IEEE/EIA 12207.2-1997 standard.
Additionally, the standard does not incorporate the maintenance activity of resolving user
support requests but merely addresses software change-requests. According to more recent
software maintenance taxonomies for in-house software (see (Chapin et al., 2001)) and ERP
software (as discussed previously in Chapter 4), user-support requests are part of the software
maintenance activity. The existing standard for software maintenance methodology needs to
change to reflect this new idea.
7.2.3 Software Upgrade
An ERP upgrade is done by installing a new version readily available from the vendor. Before
the upgrade, an ERP client-organization has to explore all the new versions available (at that
time) in order to decide the right version to implement. This includes fully assessing the new
functionality available in each of the new versions (note that this implicitly assumes that not
all organizations will realize sufficient benefits to implement all new versions); and preparing
for the process of functionality comparison between a new version and the installed version
during impact analysis. These activities are not considered in software migration or software
retirement in IEEE/EIA 12207.2-1997. On the contrary, the standard focuses on the effort and
procedures needed to develop, re-engineer and/or rewrite an existing system; these activities
are usually and relatively less important, if required at all in an ERP environment.
In addition, functionality assessment and impact analysis between the new version and the
installed version must be done in an ERP environment. (This assumes that some modification-
enhancements are unavoidable.) This activity includes deciding which of the previous
modification-enhancements to keep (and reapply to the new version once installed), and
which are no longer required. Again, IEEE/EIA 12207.2-1997 does not include this activity.
This is understandable because in-house software, for which the standard is catered for, is
fully tailored to an organization’s business requirements. In comparison, ERP packaged
software is generic and it most likely does not fit perfectly with any organization’s culture and
business processes.
7-23
7.2.4 Further Thoughts
Table 7.2 summarizes the deficiencies identified (from the maintenance activity perspective)
in IEEE/EIA 12207.2-1997. Note that the symbol ‘X’ means that the deficiency is ERP-
specific.
Table 7.2: Summary of deficiencies in IEEE/EIA 12207.2-1997
Stage in maintenance methodology
Activity ERP-specific
Maintenance preparation 1. Inclusion of vendor maintenance support issue X
2. Search for vendor’s maintenance support X
3. Report maintenance requests to the vendor X
4. Reapply previous modification-enhancements X
Maintenance procedure
5. User support activities —
6. Research on available upgrade options X
7. Make functionality assessment and perform impact
analysis between new version(s) and an installed version
X
Software upgrade
8. Make decisions on prior modification-enhancements (i.e.
keep, replace or abort) and reapply them (if necessary)
X
In brief, Table 7.2 shows that IEEE/EIA 12207.2-1997 should include user-support activities
for both in-house software and ERP packaged software. It further indicates seven main
deficiencies of the standard in the ERP context: (1) inclusion of vendor maintenance support;
(2) searching for maintenance support from the vendor; (3) reporting maintenance requests to
the vendor; (4) reapplying prior modification-enhancements (if applicable); (6) researching on
available upgrade options; (7) making functionality assessment and performing impact
analysis between new version(s) and an installed version; and (8) deciding whether to keep
prior modification-enhancements during upgrade, and reapplying previous modification-
enhancements.
7-24
7.3 Strengths of IEEE/EIA 12207.2-1997
The IEEE/EIA 12207.2-1997 makes reference to IEEE 1219-1998, IEEE Standard for
Software Maintenance (1998), which provides consideration for quantifying the long-term
cost of a maintenance request, and costs and benefits of a maintenance request at the
feasibility analysis. These ideas are valuable to further enhance CSA’s ERP maintenance
methodology.
7.4 Insufficiencies in CSA’s ERP Maintenance Methodology
The following text focuses on what CSA could do better in order to effectively plan and
efficiently manage maintenance activities through knowledge management, automation (to
economize on maintenance management effort), and decision tool (to make better quality
maintenance and upgrade decisions).
Effective planning for maintenance activities through knowledge management
CSA engaged a consulting firm to investigate the number of modification-enhancements in its
installed version, and to conduct a full functionality assessment between the installed version
and the targeted upgrade version. Part of this process could have been effectively managed by
CSA’s internal resources through systematic and consistent recording of the modification-
enhancements details (Carney et al., 2000). This activity may seem excessive and distracting
in the short-term but in the long run can help to contain upgrade costs, by eliminating the need
for external party’s evaluation.
Also, systematic recording of user-enhancement information (including the number of user-
enhancements, risk assessment, their business benefits) is also important for identifying the
pattern of ongoing maintenance cost of user-enhancement. CSA charges the system user
department(s) only for the cost of implementing the user-enhancement; CSA could not charge
for the ongoing maintenance cost because it does not have a guideline for deriving this cost
value. This ongoing maintenance cost is mainly due to reapplication of this modification-
enhancement, each time it is overwritten by the standard code. With sufficient data related to
user-enhancement, increases of effort from a patch-maintenance to another can be computed;
7-25
thus, CSA will be in a better position to charge-back the ongoing maintenance cost of the
enhancement to the respective user department. Alternatively, this information can be used to
convince the system user department to delay or forego the maintenance, based on a more
accurate assessment of total perceived benefits and estimated costs (see Chapter 8 for more
details on maintenance attributes to be captured at the maintenance procedure stage). Thus, a
new activity of ‘computing ongoing maintenance costs for user-enhancements’ is suggested as
one of the major tasks in the quotation activity (in the maintenance procedure stage). This
activity is also suggested in the IEEE 1219-1998, IEEE Standard for Software Maintenance
(1998), and this cost component is identified as long-term costs.
In addition, with the historical maintenance data at hand, CSA could predict the demand for
different types of requests over the lifetime of a new version (of similar characteristics) and
estimate the amount of effort required, and even identify how user-enhancement requests
evolve (see for example (Kemerer et al., 1997)). This is useful to estimate maintenance
workload and effort. It also facilitates planning for maintenance budget and human resources.
Thus, maintenance staff can be assigned accordingly. A new activity suggested for this
purpose is ‘forecasting the maintenance workload for different maintenance categories’ in the
resource estimation activity (in the maintenance preparation stage).
Economize maintenance management effort by identifying the repetitive maintenance
activities that are at best automated
Routinely, managers need to analyze, classify, and prioritize each maintenance (change)
request as they arrive. These activities are not always trivial and may be time-consuming, as
the information supplied by the requestor could be unclear or insufficient. Time may be
wasted on iterative information gathering and delivery between the requestor and maintenance
staff. In order to achieve more effective use of these human resources, these maintenance
activities can be automated. Polo et al. (Polo et al., 2001) state that a methodology without an
automatic tool is perceived as a major drawback to managers and programmers. Note that an
automated tool will not only save the maintenance time and money but also shorten the
turnaround time for completing a maintenance request for a system user, thereby improving
service quality.
In addition, an expert system can be incorporated in order to classify and prioritize requests.
This system will capture the knowledge (of the manager) required for these tasks. The
7-26
fundamental requirements for this (system) are knowledge in classifying and prioritizing
requests (i.e. type of requests, requestor, objective and urgency of the request), and a set of
procedures and logic to follow or criteria to be satisfied before drawing conclusions (i.e.
inference engine and rules) (Marakas, 1998). With this expert system, a helpdesk can
accurately and professionally classify and prioritize maintenance requests. This will not only
reduce personnel cost, thus increasing productivity (Turban et al., 2001) but can also free up
the maintenance manager for more important management issues such as authorizing the
request, strategic maintenance planning, and so forth. Thus, it is crucial to incorporate the
activity of ‘identifying the repetitive maintenance activities that are at best automated’ at the
maintenance preparation stage.
Make better quality maintenance and upgrade decision by using appropriate decision
tool
It is observed that maintenance and upgrade decisions are mostly done through qualitative
evaluation with limited quantification. For instance, although CSA has conducted a detailed
cost analysis for upgrading to the system, very little hard dollar value quantification for the
benefits is carried out in detail. The IEEE 1219-1998, IEEE Standard for Software
Maintenance (1998), suggests that costs and benefits analysis is required in order to determine
to feasibility of a maintenance request. The preliminary work done in this area, specific to
ERP, is outlined in Chapter 6. A new activity of ‘maintenance and upgrade decision
quantification’ is suggested in the maintenance procedure and software upgrade stages.
7.5 The Proposed ERP Maintenance Methodology
In light of the deficiencies in IEEE/EIA 12207.2-1997 and potential improvements to CSA’s
existing ERP maintenance methodology, a preliminary ERP maintenance methodology is
proposed in this study. However, the upgrade activities are limited to technical upgrade only
because empirical data for functional upgrade was not available at CSA during the author’s
research project’s time. The rationale behind each of the anticipated activities is given. Figure
7.4 provides details of the proposed ERP maintenance methodology. The symbol “*”
indicates that an activity is new and/or unique to the ERP environment. The top section of the
box provides the name of the major maintenance activity, whereas the bottom section of the
box gives details of the expected participants for the activity. Note that the methodology (as
7-27
described later) offers maintenance information from the behavioral viewpoint (why) and
details of the tasks from functional viewpoints (what) in Section 7.5.1 to 7.5.3, as well as the
implementation viewpoint (when and who) in Figure 7.4. These viewpoints are part of the
requirements for an ideal approach to software process modeling as suggested by SEI (Kellner
et al., 1988).
The proposed ERP maintenance methodology consists of: (i) the (condensed) empirical data
collected from CSA’s existing maintenance methodology (as shown in Chapter 3, Figure 3.6);
(ii) author’s data analysis and suggested improvements to CSA’s existing ERP maintenance
methodology based on the strength of IEEE/EIA 12207.2-1997 and other literature (see
Section 7.4.2); and (iii) the rationale for each activity and task. Some of these findings are
consistent and substantiated by the relevant literature; this has already been discussed in
Section 7.2. More considerations for the benefits of the proposed methodology are given in
Section 7.5.5.
7.5.1 Maintenance Preparation Stage (P)
P.1 Define maintenance – Tasks involved are as follows: define maintenance objectives; state
future maintenance mission; and identify benefits, costs and risks involved in maintenance.
Rationales for these tasks are to ensure that maintenance activities are aligned to the business
objectives; and secure top management support and confidence.
P.2 Estimate resources requirement – Tasks are: determining the user requirements for the
system; forecasting the maintenance workload for different maintenance category; identifying
the knowledge worker and the number of staff required; justifying if outsourcing is needed;
and deciding the criteria for service level agreement (SLA). Rationales are to: ensure that
resources are sufficient for managing, operating and supporting the system software and
users; and obtain budget allocation.
7-28
P .1D e fin e
m a in te n a n c e
T M , M
P .9S k e tc h th e
d e s ire dm a in te n a n c e
p ro c e d u re
M
P .8D e v e lo p tra in in g
a n d h e lp d e s kp o lic ie s
M
P .7E s ta b lis h
c o n fig u ra tio nm a n a g e m e n t
p la n
M
P .6D e fin e
m a in te n a n c es e rv ic e fo r
s y s te m u s e rs
M
P .5D e fin e th e
m a in te n a n c em a n a g e m e n t
is s u e s
M
P .4E s ta b lis h th em a in te n a n c eo rg a n iz a tio n
MT M , M
P .3D e te rm in e th e
v e n d o rm a in te n a n c e
s u p p o rt *
P .2E s tim a te
re s o u rc e sre q u ire m e n t
T M , M
T M = T o p M a n a g e m e n t, M = M a in te n a n c e M a n a g e r, H = H e lp d e s k , A = B u s in e s s A n a ly s t, U = S y s te m U s e r, P = P ro g ra m m e r, T = T e s te r, I = In te g ra to r , C = C o n s u lta n t
* = A n A c tiv ity is n e w a n d /o r u n iq u e to th e E R P e n v iro n m e n t.A c tiv ity n a m eP a rtic ip a n ts
M .1M a in te n a n c e
re q u e s tid e n tif ic a t io n
H , A
M .1 0D e liv e r th e
c h a n g e s to th eu s e rs
P , M ,T , I
M .9C o n d u c t te s tin g
A , P , T , I , U , M
M .8C o n d u c t im p a c t a n a ly s is ,a n d p e rfo rm m o d if ic a t io n -
e n h a n c e m e n tsa d ju s tm e n t*
A , P
M .7Im p le m e n t th e
s o lu tio n
P
M .6D e s ig n s o lu tio n
A , P
M .5Is s u e q u o ta tio n
M , U
M .4P ro p o s es o lu tio n s
M , A , P
M .3S e a rc h fo r
a v a ila b ility o fm a in te n a n c e
s u p p o rt *
A
M .2M a in te n a n c ec la s s if ic a tio n ,a p p ro v a l, a n dp rio r it iz a tio n
M , U
U .1D e s ig n a n
u p g ra d e p ro je c tm e th o d o lo g y
M
U .1 0C a rry o u t th etr ia l u p g ra d e s
M , A , P , T , I
U .9C o n d u c t a
th o ro u g h te s t in go f th e u p g ra d e
s y s te m
M , A , P , U , T , I
U .8C o n s tru c t th e n e w s y s te m ,a n d p e rfo rm m o d ific a t io n -e n h a n c e m e n ts a d ju s tm e n t
A , P , I
U .7In s ta ll th e n e w
v e rs io n o n to th ed e v e lo p m e n t
s y s te m
M , A , P
U .3D e v e lo p a
b u s in e s s c a s e
T M , M
U .2R e s e a rc h fo r
u p g ra d e o p tio n sa v a ila b le *
M
U .1 1G o liv e a n d
d e liv e r th e n e ws y s te m
M , P , T , I
U .5M a k e fu ll a s s e s s m e n ts o fth e n e w fu n c tio n a lity a n dte c h n ic a l re q u ire m e n ts in
e a c h u p g ra d e o p tio n *
M , A , C
U .6C o n d u c t im p a c t a n a ly s is
b e tw e e n th e n e w u p g ra d ev e rs io n a n d th e c u rre n t
v e rs io n *
M , A , P
ERP
Mai
nten
ance
Prep
arat
ion
ERP
Softw
are
Upg
rade
ERP
Mai
nten
ance
Proc
edur
e
M , A , C
U .4M a k e fu ll a s s e s s m e n t o f th em o d ific a tio n -e n h a n c e m e n ts
a n d te c h n ic a l e n v iro n m e n t o fth e c u rre n t v e rs io n
Figure 7.4: Major activities involved in ERP maintenance methodology
7-29
P.3 Determine the vendor maintenance support* – Tasks include: determining the contractual
issue6 with the vendor; and identifying the types of maintenance support provided by the
vendor, and how and where to get them. The objectives are to: utilize maintenance support
from the vendor so that total maintenance costs can be contained; and establish long-term
business partner relationship with the software vendor.
P.4 Establish the maintenance organization – Tasks involved are as follows: identify the
maintenance unit(s) or team(s); and outline the maintenance team(s) responsibilities,
functional role/job specifications, and scope of authority. The reasons are to: facilitate future
process of planning, managing, organizing, controlling, and executing maintenance activities;
facilitate cooperation and avoid miscommunication among maintenance teams; and provide
information of who is responsible in each maintenance activity.
P.5 Define the maintenance management issues – Tasks are: identifying the numbering
system for maintenance requests; deciding what data is to be collected; identifying the
taxonomy of maintenance requests; establishing maintenance strategies; and determining how
each maintenance category is serviced (batch, on-the-fly or weekly), and tracked. Rationales
are to: manage the maintenance systematically; retain maintenance knowledge; improve
maintenance efficiency and guarantee for economy of scale in maintenance activities;
minimize change-request backlog; and reduce maintenance bottleneck.
6 According to Carney et al. (2000), the ‘contractual issues’ to be considered are: (1) contractual details on the vendor's long-term
responsibility for maintenance, such as the term of the existing licenses, the expected frequency of releases, and the vendor's policies
concerning emergency updates (e.g. in case of patches to repair vulnerabilities); (2) prediction by the vendor of the expected upward
compatibility of future releases of the software; (3) contractual details of the vendor's responsibility for maintenance of the modified form of
the software – including the validity of licenses, liability in case of component failure, and availability of source code. Authors such as
Gurbaxani et al. (1991) suggest that other issues to consider are: (1) functional specifications; (2) acceptance-testing procedures; (3)
protection of trade secrets; (4) liabilities due to failures; (5) required documentation; (6) options to terminate the agreement; (7) software
price; (8) number of licenses; (9) payment schedule; and (10) a timetable of the delivery process.
Information suggested by Carney et al. (2000) to be obtained from the vendor regarding any proposed modification to the vendor’ software
is: (1) statement concerning the functional effect of the modification, together with any other technical factors (e.g. changes to performance,
safety, reliability) affected by the requested modification; (2) a statement concerning the business effect of the modification (this shall
include license issues, ongoing cost issues, and liability issues); (3) a statement concerning upward compatibility with future releases of the
component – including projected costs for duplicating the modification in future releases, and the potential for the modification becoming
part of the standard product; (4) a statement concerning the cost, available schedule, and available resources to perform the modification; and
(5) a statement concerning the risks associated with making the modification, together with the fallback plan if the modification is not
successful (p. 374).
7-30
P.6 Define maintenance service for system users (and stakeholders) – The tasks are:
describing the types of maintenance support available to the users, how and where to access
them; and defining the types of maintenance requests required to be charged back to the user’s
department; and deciding what criteria the fees will be based on. The reasons are to: foster
mutual agreement and understanding of the service level between the maintenance team(s)
and user department(s); and foster trust and confidence between them.
P.7 Establish configuration management plan – This includes: deciding who should evaluate
and approve maintenance requests; defining software configuration plan and control;
establishing guidelines for modifying vendor’s software. The objectives are to keep control of
the coordinated updates and release, and ensure the software remains valid for vendor-
support.
P.8 Develop training and helpdesk policies – The tasks are deciding frequency, and type of
training to be provided for the maintenance staff, system users and other stakeholders. This is
meant to ensure efficient and proper use of the system, and update stakeholder knowledge of
the system from time to time.
P.9 Sketch the desired maintenance procedure – Tasks are to outline the activities involved
from request initiation to changes delivery, and identify repetitive activities that are at best
automated. This will ensure that all parties involved are familiar with the maintenance
procedure and understand their roles in making the procedure successful.
7.5.2 Maintenance Procedure Stage (M)
M.1 Maintenance request identification – This will involve determining the nature of the
request, which is useful for distinguishing a software change-request from user-support
request.
M.2 Maintenance classification, approval and prioritization – Tasks are to assign an ID to the
request; classify maintenance request (see Chapter 4 for details); approve a request for further
investigation; estimate maintenance effort; and quantify maintenance decision and prioritize
maintenance request (see Chapter 6). This will facilitate processing, tracking, storage and
7-31
retrieval of maintenance requests. Thus, improve the effectiveness in managing maintenance
requests and facilitate identifying the significance/urgency and criticality of a request.
M.3 Search for availability of maintenance support from the vendor* – Tasks involved are as
follows: determine if the solution for a maintenance request is provided by the vendor from
the online support system; and report the bug / modification request back to the vendor (if
necessary). Objectives are to utilize maintenance support provided by the vendor; and reduce
maintenance costs and avoid any effort redundancy.
M.4 Propose solutions – The tasks include: proposing solution – developing solution
alternatives and methodologies; identifying elements/modules impacted by the solution;
determining the software object(s) to be modified; and approving the proposed solution. This
is meant to: investigate and identify the solution for the problem; estimate the resources
required for the request; evaluate the effect of changes on the deliverables and their impact on
project resources; and ensure that only the best solution is chosen.
M.5 Issue quotation – This will include providing an estimate of the maintenance time and
maintenance implementation cost; determining the ongoing maintenance cost for user-
enhancement; issuing a quotation for the maintenance; and prioritizing the request, after the
quotation is accepted by the user department. This will help to provide a better quantitative
analysis for a maintenance request, assist in making a better-informed decision, and ensure
that only unavoidable modification is done on the system.
M.6 Design solution – The tasks are: identifying affected module and functional areas;
identifying documentation to be modified; designing implementation strategies; and devising
test strategy (see also IEEE Std. 1219-1998 (1998)). This helps to plan and facilitate the
subsequent implementation of the solution.
M.7 Implement the solution – This covers coding, modifying code or applying code from the
vendor, and unit testing. The objective is to fix bug and/or enhance existing system
functionality and business processes.
M.8 Conduct impact analysis, and perform previous modification-enhancements adjustment*
– This activity includes: identifying the modification-enhancements that have been
7-32
overwritten; performing modification-enhancements adjustment; and recording the
maintenance changes into the system. This is to: ensure that the system functions correctly
after the change, and unaffected software system operates properly as before and remains
intact; and limit retesting to relevant software parts.
M.9 Conduct testing – The tasks are as follows: conduct quality test; perform regression test;
do performance testing; carry out business process verification; perform integration test;
conduct functional configuration audit (FCA); update all documentation including user
manual; and conduct user acceptance (see also IEEE Std. 1219-1998 (1998)). The purpose is
to: secure user reliance on the system; and ensure that the system is achieving the expected
performance, the system integration is intact, and business processing is functioning well.
M.10 Deliver the changes to the user – The tasks are: notifying user of the maintenance
delivery; conducting physical configuration audit (PCA); updating all documentation
including user manual and training material; and (4) making archival copy of the old version
(see also IEEE/EIA 12207.2-1997 (1997)). The ultimate objective is to deliver the system for
business operation and benefit-realization.
7.5.3 Software Upgrade Stage (U)
U.1 Design an upgrade project methodology – The tasks are: identifying the best
methodology from the software vendor or other organizations’ successful upgrade projects,
and tailor it for internal use; and listing upgrade tools and services available from the vendor
for its clients. This activity and the information gathered will serve as a project blueprint or
guideline to success, and is used as a measurement of project progress.
U.2 Research for upgrade options available* – This covers tasks such as: research for
available upgrade options and their availability dates; analyze pros and cons, and the stability
of each upgrade option; and identify the support window for each version. Rationales for
these tasks are to: ensure the chosen upgrade version is the optimal solution based on the
organization’s business objectives; ensure the latest technology and business potentials are
known and have been considered; and ensure all options that can potentially contribute to
business benefits (in particular) are carefully considered in the business case.
7-33
U.3 Develop a business case – The tasks involved are: determining the objectives, business
drivers to upgrade, and the nature of the proposed upgrade; developing a business case to
justify an upgrade decision; identifying the factors influencing the upgrade decision;
describing how the upgrade effort enhances corporate value; planning for the upgrade date;
evaluating costs for the upgrade; evaluating the benefits of an upgrade; developing a plan for
budget allocations, and personnel requirements; assessing project risks and evaluate the lost
opportunity cost of not pursuing an upgrade project; and quantifying upgrade decision (for
instance using the general decision model in Chapter 6). The objectives are to: make solid
business case for ERP upgrade; ensure that the upgrade project follows the management’s
direction, and is used as a management tool which benefits are measured against; and ensure
that better-informed upgrade decision is made.
U.4 Make full assessment of modification-enhancements and technical environment of the
current version – This includes: investigating the number of modification-enhancements on
the existing system; identifying which modifications are still required and which are not;
linking a modification-enhancement with business reasons; and quantifying the amount of
effort required for reapplying the previous modification-enhancements in the upgrade process.
The purpose is to improve the precision of the upgrade cost computation, and ensure that all
unnecessary modification-enhancements are not included in the new upgrade version.
U.5 Make full assessments of the new functionality, and technical requirements in each
upgrade option* – The tasks are as follows: assess the new features / functionality in each
option for each ERP module needed; evaluate benefits of the functionality to the organization;
assess the technical requirements in each option; draft a plan for benefit-realization from the
new business improvements; make recommendation for the upgrade version; and implement
change management. The tasks are meant for: identifying whether some of the modification-
enhancements are now available in a new version; providing and serving as a project blueprint
and guideline to success in achieving upgrade objectives; facilitating quantification of
tangible and intangible benefits; and ensuring that the right version is selected for upgrade.
U.6 Conduct impact analysis between the new upgrade version and the current version* – The
tasks are to highlight existing business processes that are affected in an upgrade and not used;
examine the impacts of the new version on user training and supporting documentation;
analyze the impacts and discrepancies of the new version on previous modification-
7-34
enhancements such as interfaces, screens, program modules and reporting capabilities; and
study the impacts of the upgrade on hardware, server capacity, and network loading
requirements. This is an important step to: minimize future maintenance cost (if applicable);
and ensure that requirements for the project are identified so that budget, time, and manpower
can be allocated accordingly
U.7 Install the new version onto the development system – This covers installing the new
version into the development system; applying all the previous patches for the new version;
and merge custom code with the new version to create a customized application on the new
version. This is to ensure that the new version is up-to-date by incorporating all the earlier bug
fixes and enhancements.
U.8 Construct the new system and perform modification-enhancements adjustment – All
previous development (reporting capability, interfaces, and modification) overwritten during
the new version upgrade will be re-developed or re-applied on the new system (if necessary).
This is to ensure that all competitive business processes remain in the new system.
U.9 Conduct a thorough testing of the upgrade system – The tasks are: verifying accuracy of
the system functionality; conducting system testing, user acceptance test, integration test, and
performance test; and verifying data conversion. The purpose is to ensure that the new system
still meets the user requirements and is aligned to the business objectives.
U.10 Carry out the trial upgrades – Trial upgrade(s) between the development system and
testing system are conducted. The objectives are to exercise the upgrade process before the
real upgrade takes place in the production system, and to identify errors or potential problems
(if any) that would happen during the actual upgrade.
U.11 Go live and deliver the new system – The well-tested system is delivered into the
production system. This will guarantee that the new version is transparent to the users, and
ensure the version in-use remains a vendor-supported version.
7-35
7.5.4 Maintenance Request And Its Maintenance Procedure
Based on the discussion in Section 7.1.2 and the proposed ERP maintenance methodology,
Table 7.3 briefly shows the different maintenance paths or procedures required by different
maintenance categories. Note that the names of the activities involved in each maintenance
procedure for each maintenance category are based on the activity-name as shown in Figure
7.4. This table is not meant to be exhaustive for all possible ERP requests, but it covers the
dominant ERP maintenance requests. The main objective of this table is to highlight that
different maintenance categories have different maintenance objectives, trigger different
maintenance activities, and require different emphasis in effort in order to accomplish.
Table 7.3: Maintenance category and the expected maintenance procedure
Category Reason for the request Expected maintenance procedure
Bug(s) in custom code M.1-M.2, M.6-M.7, M.9-M.10 Corrective
Bug(s) in vendor’s code * M.1-M.3, M.7-M.10
Vendor support is not available M1-M7, M.9-M.10 Enhancement
Support available from vendor M1-M3, M5, M7-M.10
User support Consultation and user training M.1
Patch Keep the system up to the
vendor’s requirements, adapt to
legal change and/or minor
enhancement
M.2, M.7-M.10
* Sometimes only the relevant piece of code in a patch is used.
7.5.5 The Benefits Of An ERP Maintenance Methodology To
Client-Organization
The benefits of the proposed maintenance methodology for ERP client-organization are as
follows:
(1) Provide a methodology for initiation and tracking of maintenance and upgrade projects
An appropriate methodology can be used for preparing maintenance and upgrade projects,
initiation of requests, tracking a project’s progress, and closing a project. This increases all
parties’ understanding of the maintenance policies and strategies, and the maintenance
procedure involved. In addition, it enhances the maintenance managers’ credibility as efficient
7-36
managers with adequate tools or methodology to manage the resources under their control
(Abran et al., 1993).
(2) Provide guidelines for modifying vendor’s code
The methodology incorporates the ‘contractual issue,’ which helps the client-organization to
identify the fundamental issue to be considered with respect to vendor maintenance-support
(indicated as item P.3 in Figure 7.4); and ‘guidelines for modifying vendor’s product’ to
remind the maintenance organization of the procedure and factors to be taken into account
before modifying the software (highlighted as item P.7 in Figure 7.4).
(3) Provide decision tools to assist in making better quality maintenance and upgrade
decisions
The methodology proposes the business-case approach in making the upgrade decision
(indicated by item U.3 and U.7, in Figure 7.4). This includes identifying all the benefits and
costs in an upgrade in order to ensure a successful upgrade (McDonnell, 2000), and linking a
modification-enhancement to a business reason (Collins, 1999). In addition, an ERP decision
framework is suggested for quantifying and making better informed maintenance and upgrade
decisions (see Chapter 6 for more details).
(4) Facilitate maintenance and upgrade projects’ risk minimization
Risks involved in a maintenance project and upgrade could be minimized because they are
identified at an early stage in maintenance preparation (in item P.1 of Figure 7.4), and the
upgrade process (in item U.1, Figure 7.4). The methodology allows ERP organizations to be
aware of what they are doing in the maintenance preparation stage, maintenance procedure
stage and software upgrade stage; sequence of these stages; who should participate; and the
reason for the activities. With these details, organization can achieve the maintenance and
upgrade project more reliably (Zvegintzov, 1994, p. 10)
(5) Facilitate identification of best practice for maintenance and upgrade process in the future
The methodology can be used as a reference model or checklist for maintenance and upgrade
tasks, and as a tool to manage and improve the maintenance process. For instance, under the
ERP software upgrade stage, the items labeled U.6 – U.11 in Figure 7.4 are also
recommended by consultants and practitioners (see also (Shi et al., 2001) for details) for best
practices in an ERP upgrade process.
7-37
(6) Facilitate management control and involvement
The methodology shows that top management participation is expected at the initial stage of
maintenance preparation (P.1 – defining the maintenance objectives, P.2 – funding allocation
and P.3 – establishing long-term business partners with the vendor), and upgrade preparation
(U.3 – approving the upgrade business case). This methodology is an important guideline for
top management to ensure that (1) maintenance project requirements, policies and processes
are defined and aligned to the business objectives, and (2) business objectives and missions
are incorporated and are given sufficient considerations in ERP maintenance and upgrade
activities. This includes how the system will support and facilitate future business expansion,
how future upgrades help in realizing benefits and improving business processes to obtain
return on investment, and how maintenance support from the vendor is beneficial to the
business in terms of the ongoing operation and maintenance cost.
(7) Provide visibility of maintenance activities
Visibility of maintenance activities in an organization allows a manager to monitor, organize,
and manage maintenance activities easily. For example, deficiencies or bottlenecks in the
maintenance process can be detected faster, and can be corrected by improving the
maintenance process and/or by process-reengineering. Visibility also facilitates the
identification of areas for benefit-realization, revenue generation or maintenance cost
minimization. In addition, organizations could easily identify and determine the maintenance
attributes to collect during maintenance preparation, maintenance procedure, and software
upgrade (this is described in Chapter 8). Besides data, inputs, controls and outputs of each
activity can also be determined more precisely (see (IEEE, 1998)).
(8) Provide a common communication tool for all parties involved
Providing common communication tools assists the maintainers’ understanding of the
workflow of the maintenance process and improves communication among business analyst,
programmer, integrator and tester, and to the system users because each activity/subtask and
its objective(s) is defined. Thus, this could enhance the maintainers’ productivity. The
participants will also be aware when their involvement is needed in the maintenance process.
While most of the listed benefits from the proposed ERP maintenance methodology are
similar to an in-house software maintenance methodology, some are unique to ERP due to the
7-38
added activities which are unique to ERP maintenance and upgrade environment. (This means
that some of the listed benefits may not be relevant to the in-house software maintenance
environment.) The added activities require different emphasis in effort, different factors to
consider in making a decision for an activity and different roles in managing the maintenance
activities. For instance, the proposed maintenance methodology will benefit the ERP-using
organizations (in the same way with other packaged software) when appropriate attention is
given to ensure that before and after the software modification, the software would remain
eligible for maintenance support from the vendor. It is found that factors affecting ERP
maintenance and upgrade decisions are different from those fundamentally considered in in-
house software environment (see Chapter 6). Therefore, different factors for evaluating the
cost and benefit are required in the context of ERP. Unlike the in-house software maintenance
methodology (where it focuses on the technical roles), the proposed ERP maintenance
methodology also includes the roles of business users and top management (who will ensure
that major maintenance and upgrade projects are aligned with the primary business
objectives).
7.6 Summary
Data analysis between CSA’s ERP existing maintenance methodology and IEEE/EIA
12207.2-1997 (1997) shows that although IEEE/EIA 12207.2-1997 is general and
comprehensive, it lacks certain unique characteristics of ERP. The major issues overlooked in
IEEE/EIA 12207.2-1997 are: (1) availability of vendor-support, (2) readily available new
version for upgrade, (3) the importance of user-support activities, and (4) modifying vendor’s
code and replacing custom code with vendor’s code. This is because IEEE/EIA: (1) constrains
its focus on in-house software maintenance, and (2) emphasizes on change-requests activities
only (thus, it does not include user-support requests activities.) While CSA’s ERP
maintenance methodology is well-organized and well-managed, there is still room for
improvement. The activities that could further enhance the effectiveness and efficiencies in
maintenance management and facilitate better quality maintenance and upgrade decision-
making are: (1) computing the ongoing user-enhancement maintenance and forecasting
maintenance demands by capturing more related maintenance data; (2) identifying the
repetitive maintenance activities that are at best automated; and (3) using quantitative
mechanism to make better informed maintenance and upgrade decisions. Therefore, a new
7-39
ERP maintenance methodology, capturing the fundamental characteristics and activities
required in the context of ERP is proposed.
The major activities in the maintenance procedure stage proposed in the ERP maintenance
methodology are referenced in Chapter 8, where an ERP maintenance-data-model is
proposed.
8 An ERP Maintenance-Data-Model1
The objectives of this chapter are to: determine the fundamental ERP maintenance request
attributes; investigate if the existing maintenance-data-model is appropriate in the context of
ERP; and develop an ERP maintenance-data-model. By definition, a data-model in this study
is a data definition and repository. It defines and captures fundamental details, such as the
measurable attributes and characteristics, of a maintenance request. This sub-study has been
limited to maintenance request’s attributes for activities in the maintenance procedure stage
only. (Attributes of an ERP upgrade request for activities occurring at software upgrade stage,
and so forth are interesting but they are not covered in this thesis.) Thus, this chapter aims to
address the following research questions: What are the important ERP maintenance request’s
attributes that should be captured in an ERP maintenance management environment? Do the
attributes captured in in-house software environment sufficient in the context of ERP? What
are the unique ERP maintenance request’s attributes? The data collection and data analysis
processes for this chapter are described in Chapter 3, Section 3.3.5.
This chapter is organized as follows. Section 8.1 discusses the maintenance attributes
considered in the synthesized CSA’s ERP maintenance-data-model and Software Engineering
Institute (SEI) maintenance-data-model. Section 8.2 presents the differences between these
two maintenance-data-models. In light of the deficiencies in both data-models, Section 8.3
describes the additional attributes important for better management of maintenance activities,
and proposes a new ERP maintenance-data-model. The proposed data-model incorporates
findings from previous chapters and other related literature. The main research findings from
previous chapters included in the proposed ERP maintenance-data-model are: (1) dimensions
for characterizing ERP maintenance requests (from Chapter 4); (2) factors driving
maintenance effort (from Chapter 5); (3) data required for making ERP maintenance and
upgrade (MU) decisions (from Chapter 6); and (4) activities involved at CSA’s maintenance
procedure stage (from Chapter 7). Section 8.4 shows the benefits of the maintenance-data-
model for practice. Section 8.5 provides a summary of the chapter. This is summarized in
. Figure 8.1
1 The earlier version of this chapter had been published in the Australasian Conference on Information Systems (ACIS 2001), and the paper was short-listed for best-paper award (see (Ng et al., 2001d)).
8-1
Chapter 4:Taxonomy
Chapter 5:Effort
8.2Differences
Between CSA andSEI Maintenance-
Data-Models
8.3The Proposed
ERP Maintenance-Data-Model
8.4Benefits of theProposed ERP
Maintenance-Data-Model
8.5Summary
Chapter 6:Decision
Chapter 7:Methodology
Chapter 8:Data
Data for making maintenancenance and upgrade decisions
Attributes/factors affecting maintenance effortDimensions for characterizing maintenance request
Activities in maintenanceprocedure stage
8.1CSA and SEIMaintenance-Data-Models
Figure 8.1:The flow of Chapter 8
8.1 CSA And SEI Maintenance-Data-Models
The data analysis between (the synthesized) CSA’s ERP maintenance-data-model and the
Software Engineering Institute (SEI) maintenance-data-model – the Problem and Defect
Counting Framework proposed by Florac (1992), is described in detail in Chapter 3, Section
3.3.5. This sub-study seeks to analyze and/or reverse-engineer specifications and rationales
from two maintenance-data-models employed in two different but substantially overlapping
software maintenance environments: (1) large packaged software, or more specifically ERP;
and (2) custom in-house software.
By comparing CSA’s ERP maintenance-data-model and the SEI maintenance-data-model, it
is found that the SEI maintenance-data-model includes most of the fundamental ERP
maintenance attributes. Nonetheless, it is quite general and insufficient to capture: (1) more
specific ERP maintenance attributes such as the ‘vendor change-request number’ (to indicate
that a request was satisfied using readily available patches from the vendor) and ‘major
functional area’ (representing the cross functional business application area involved in a
change-request); (2) more specific service provider maintenance attribute for example
‘company of the originator’; and (3) other relevant maintenance attributes such as ‘work type’
(to identify different types of requests), ‘service desk reference’ (an identification number
assigned to each maintenance request that arrives at the service desk or helpdesk), and ‘client
cost centre’ (to indicate a cost centre to charge for a maintenance work). Deficiency found in
the CSA’s ERP maintenance-data-model is lack of the attribute ‘uniqueness’ to determine the
8-2
rareness of a change-request, and ‘finding mode’ to determine whether a problem is
encountered in an operational environment.
Table 8.1
Table 8.1
provides a detailed cross-reference of the attributes between the CSA and SEI
maintenance-data-models. The first column of the table displays the fundamental maintenance
attributes common to these activities. The second and third columns show the attributes
observed (present indicated by the symbol “X” and not present by the symbol “–”) in the CSA
and SEI maintenance-data-models respectively. Where CSA uses a different descriptor for an
SEI attribute, the CSA term is displayed in the CSA column in parentheses. The last column
in describes the objective of each attribute. These objectives are distilled from
interviews with CSA senior managers and/or supported by SEI.
8-3
Table 8.1: Cross-reference of the CSA and SEI maintenance request’s attributes
Attribute CSA SEI Objective*Investigation Problem ID X (SIRa #) X Uniquely identify each change-request.
Product ID X X Identifies the software product to which problems refer; also used by CSA for billing
purposes.
Problem type X (Work type) X Identify the maintenance category; and facilitate problem resolution.
Criticality X (Priority) X Measure of the importance of a request to system user(s).
Urgency – b X Priority of a request assessed by the senior maintenance managers.
Finding activity X (Problem description) X Refers to the activity, process, or operation which takes place when a problem is
encountered.
Finding mode – X Identifies whether a maintenance problem is discovered in an operational or in a non-
operational environment.
Date of occurrence X (Date raised) X Date at which a problem occurs.
Time of occurrence X X Relative time at which a problem occurs.
Originator X (Raised by, Company
of the originator)
X Determines the originating person and company/organization; helpful in identifying the
environment-specific and source-specific problem; and is important for billing purpose.
Major functional area c X – Represents a major functional area associated with a change-request.
Environment X (Functional area) X Determines if problem is uniquely related to a functional area; identify if a particular
functional area tends to generate abnormally large numbers of change-requests.
Service desk reference X – Reference number issued when a system user initiates a change-request at the helpdesk.
Projected availability X X The date when the request resolution is committed to be available.
Estimate time X – Estimate of time (in hours) to complete a change-request.
Quote X – Indicates the estimated cost of implementing a change-request; and CSA uses it for the
user-enhancement request.
8-4
Attribute CSA SEI Objective* Quote type d X – Indicates which maintenance team receives the fee charged.
Client cost centre e X – Indicates a client "cost centre" code to charge for a maintenance work.
Action to be taken X – Shows whether a request is approved by maintenance manager(s); and allow identification
of the number of requests accepted, rejected or deferred.
Issues of consideration X – Identifies future issues related to a change-request that is deferred.
Uniqueness – X Differentiates between a unique and a duplicate maintenance problem.
Tailoring option f X – Classifies the type of changes made to the software; and facilitate problem resolution.
Defect found in X (Description of
changes, Resolution)
X Identifies the software object(s) containing defects, which cause a problem; identify
software units that are prone to errors from one release to another.
Resolution Problem status X (Status) X Indicates the job status of a change-request (such as in-progress, user-testing, on-hold,
awaiting client quote, closed).
Problem status date X (Date actioned) X Records the date of a request when its status changes; and important to track the time
spent on analyzing and resolving the request, and to identify delays incurred.
Changes made to X (Description of
changes, Resolution)
X Identifies the software object(s) changed to resolve the discovered problem; identify
software units prone to change; and discover software volatility.
Related changes X X List of non-software object(s) required to be changed to resolve the problem in question;
useful to estimate time required to resolve a request.
Approved by X X Indicates that maintenance manager(s) have approved a maintenance solution.
Analyst X – Identifies staff who analyze a maintenance problem.
Programmer X – Identifies staff who program maintenance code.
Vendor change-request
number
X – Identifies whether a change-request is satisfied by using the readily available patches
distributed by the vendor.
8-5
Attribute CSA SEI Objective* Released X (Completed, and
approval to migrate)
X The date when a maintenance solution is released; useful to identify the efficiency of the
maintenance project management in meeting the projected deadlines.
Delivery
Applied X (Transported on) X The date when maintenance solution is applied to the originator’s site.
Accepted by X X Indicates that a maintenance solution has been accepted by a system user. * These objectives are distilled from interviews with CSA senior managers and/or supported by SEI. a An abbreviation for System Investigation Request; b Partially followed by CSA; c It identified as ‘TestPhase’ in CSA’s change-request database; d It is identified as ‘ProductID’ in CSA’s change-
request database; e It identified as ‘ClientWBS’’ in CSA’s change-request database; and f It identified as ‘ProblemType’ in CSA’s change-request database.
8-6
8.2 Differences Between CSA And SEI Maintenance-Data-Models
It is assumed that those attributes that are common to both maintenance-data-models are
valid, and thus the subsequent discussion is focused on those found to be unique to either
CSA or SEI. Observations made on differences between the CSA and SEI maintenance-data-
models are summarized in Table 8.2. Discussion in this section is organized around the
following three sub-headings: (1) investigation phase; (2) resolution phase; and (3) delivery
phase. These three phases are identified and embedded in CSA’s ERP maintenance procedure
stage.
The investigation phase, which corresponds to activities M.1-M.5 shown in Chapter 7,
Figure 7.4, is defined as the initial step where a change-request is defined, categorized,
analyzed and approved. The resolution phase, which includes activities M.6-M.9 given in
Chapter 7, Figure 7.4, is where the cause(s) of a change-request are examined thoroughly the
strategy to satisfy a request is designed; available source of information is consulted and the
newly acquired knowledge pertinent to a request solution is documented; a solution for a
change-request is implemented and approved for transporting from the development system
(DEV) to quality assurance system (QAS); and the changes are tested and user acceptance test
is conducted in the quality assurance system. The delivery phase, which covers activity M.10
listed in Chapter 7, Figure 7.4, includes delivering the new changes to the production system
(PRD).
8-7
Table 8.2: Summary of main differences
Attribute CSA SEI ERP-specific Why the attribute is not considered?
Investigation Urgency –* X It is included by CSA but it is based on day-to-day maintenance demand.
Finding mode – X Not relevant to CSA or ERP environment.
Major (cross) functional area X – X Not relevant (to SEI) in the traditional in-house software environment.
Service desk reference X – SEI does not consider the helpdesk concept in software maintenance system.
Estimate time X – Not the focus of SEI.
Quote X – Not the focus of SEI.
Quote type X – Not the focus of SEI.
Client cost centre X – Not the focus of SEI.
Action to be taken X – SEI assumes that all change-requests arrived will be accepted.
Issues of consideration X – SEI assumes that all change-requests arrived will be accepted.
Uniqueness – X -
Tailoring type X – X Not relevant (to SEI) in the traditional in-house software environment.
Resolution Analyst X – Not important to SEI.
Programmer X – Not important to SEI.
Vendor change-request number X – X Not relevant (to SEI) in the traditional in-house software environment. * Partially followed by CSA
X=the attribute is considered in the maintenance-data-model.
8-8
8.2.1 Investigation Phase
Attribute(s) in CSA but not SEI (refer to Table 8.2)
CSA’s ERP maintenance-data-model suggests that the SEI maintenance-data-model may be
improved (in the context of ERP) by capturing the ‘major functional area’ attribute of a
change-request. Unlike the traditional single functional area in-house software, ERP software
comprises cross functional area business applications. This attribute is useful in an ERP
context to determine the major functional area that is more strategic and volatile or error-
prone, so that more monitoring and investigations into the reason(s) can be focused.
The attribute of a ‘service desk reference’ is also not considered in the SEI maintenance-data-
model. A service desk or helpdesk is employed at CSA’s maintenance unit to effectively help
and liaise with system users regarding the ERP system usage, training, software functionality
and maintenance problems, and to report change-requests to CSA’s maintenance teams. The
‘service desk reference’ helps management to easily identify a request.
Four maintenance cost related attributes found in CSA’s ERP maintenance-data-model, but
not in SEI are ‘estimate time’, ‘quote’, ‘quote type’, and ‘client cost centre’. The first attribute
is an estimation of the amount of effort required for a change-request. It is particularly
important for an enhancement request as it is a good determinant for a quotation for a
maintenance work. Similarly, ‘quote’ is also crucial for an enhancement request for CSA as a
service provider, in order to: (1) confirm a system user’s willingness to pay for the
maintenance, (2) keep track of maintenance charges for each system user, and (3) issue an
invoice to system user(s). ‘Quote type’ and ‘client cost centre’ describe who will receive the
maintenance fee and who is responsible for paying it. However, these four attributes are
neither unique to an ERP context nor a service provider because the concept of a ‘charge-back
system’ is also practiced in the in-house software enhancement maintenance activities (Martin
et al., 1983, p. 418).
Attributes ‘action to be taken’, and ‘issues of consideration’ are used by CSA to record
whether a change-request is approved for further processing, and is implementable. For
instance, if a request is deferred the latter attribute will describe the issue(s) that need to be
addressed before maintenance job can be carried out in the future. A possible explanation of
8-9
why these attributes are not considered in SEI maintenance-data-model is that it assumes all
change-requests are valid and therefore will be accepted.
Another maintenance attribute considered in CSA but not SEI maintenance-data-model is
‘tailoring option’, which is for identifying the type of changes made to the software in
resolving a change-request. Examples of ‘tailoring option’ (as described in Chapter 2, Table
2.2) are configuration, bolt-on, user-exit, workflow programming, package code modification,
and so forth. This attribute is believed to be unique to the ERP context because unlike in-
house software, an ERP-using organization has a variety of option available from an ERP
vendor and/or third-party vendor(s) for making changes to the software. This attribute is
useful for estimating the future ongoing maintenance cost.
Attribute(s) in SEI but not CSA (refer to Table 8.2)
The SEI maintenance-data-model incorporates most of the attributes of a change-request at
the investigation phase. The attributes ‘criticality’, and ‘urgency’ allow both system users and
maintenance managers to indicate the importance of a change-request from their perspectives.
These attributes provide information required to prioritize change-requests. It is observed that
the CSA maintenance-data-model does not explicitly capture the attribute of ‘urgency’, which
can be an important factor in cost and benefit justification of a change-request. In contrast,
CSA assigns the ‘urgency’ of a request dynamically based on day-to-day maintenance
demand.
CSA does not record the ‘finding mode’ that describes whether a problem is found in an
operational environment. This attribute is important for understanding a problem’s behavior
in in-house software in order to reproduce the error. However, this attribute is perceived to be
less useful by CSA in its ERP maintenance environment as all the change-requests reported
by users are expected to occur in the operational mode (i.e. in the production system). ERP-
using organizations do not usually perform formal reviews of the ERP software or conduct
software inspections. Therefore, problems are unlikely to be found in the non-operational
environment.
One of the attributes suggested in SEI maintenance-data-model to aid in resolving a change-
request, and identifying a unique request is ‘uniqueness’. While ‘uniqueness’ is perceived to
be important by SEI as a warning mechanism to identify duplicate request problems, CSA’s
8-10
ERP maintenance-data-model does not capture this attribute. However, in a later interview
with CSA’s Systems Operations Manager indicates that CSA will consider using this attribute
in the future.
8.2.2 Resolution Phase
Attribute(s) in CSA but not SEI (refer to Table 8.2)
Deficiencies of the SEI maintenance-data-model observed in CSA context include: (1)
recording who is involved in resolving a change-request (‘analyst’ and ‘programmer’); and
(2) indicating whether maintenance support is available from the vendor (i.e. ‘vendor change-
request number’). In general, ‘analyst’ and ‘programmer’ are essential because it facilitates
the identification of experienced maintainers who can be recruited for similar maintenance
problem areas. On the other hand, the attribute of ‘vendor change-request number’ is unique
to an ERP maintenance environment. It is necessary to identify whether customized objects
(such as menu, screen, report, interface, and program) are developed or standard code
(distributed by the vendor) was (previously) applied to satisfy a change-request. This piece of
information is highly critical to determine whether it will be affected by future patch-
maintenance or software upgrade. (If the standard code had been used, it would have no
impact on future patch-maintenance or new version/release upgrade.) This attribute is also
fundamental to avoid any unnecessary maintenance efforts and to shorten the turnaround time
in servicing some change-requests, particularly the corrective maintenance.
8.2.3 Delivery Phase
Both CSA and SEI maintenance-data-models consider similar maintenance attributes in
delivery phase. The attributes considered are ‘applied’ (to indicate the date when new changes
are applied to a system user’s site), and ‘accepted by’ (to record the system user who accepts
the new changes.)
8.3 The Proposed ERP Maintenance-Data-Model
In the previous discussion, it is found that both the CSA and SEI maintenance-data-models
have their strengths and limitations. In addition, it is observed that SEI maintenance-data-
8-11
model, i.e. the Problem and Defect Counting Framework (Florac, 1992), is not sufficient in
the context of ERP (see summary in Table 8.2). This is because SEI does not consider some
ERP-specific attributes such as cross functional business applications, availability of vendor’s
maintenance support; and lacks of considerations for maintenance effort and cost attributes of
a change-request. Thus, this suggests a need to derive a new and more comprehensive ERP
maintenance-data-model.
This section proposes a new ERP maintenance-data-model by first integrating the essential
attributes seen in the former two maintenance-data-models, and then incorporating additional
fundamental ERP maintenance attributes that are perceived to be highly relevant in the
context of ERP. The latter is done by identifying the additional, essential and relevant
maintenance attributes needed for: (1) efficient and effective maintenance management; and
(2) using the proposed ERP maintenance taxonomy (see Chapter 4), maintenance effort
determinants (see Chapter 5) and MU decision framework (see Chapter 6). An ERP
maintenance-data-model (for maintenance procedure stage) is described in the following
section.
8.3.1 Additional Attributes For Consideration
Request classification – Chapter 4 suggests three salient dimensions for characterizing ERP
maintenance requests: maintenance source (originator); existence of business benefit; and
existence of maintenance impact on the installed module(s). While the first attribute is
captured in CSA maintenance-data-model, the second and third are not. Thus, additional
attributes recommended in the new maintenance-data-model are: rationale for change-request;
existence of business benefit; and existence of maintenance impact on installed module(s).
Business benefit classification – The attribute of benefit category is also important in order
to facilitate quantification of the business value of doing a benefit-oriented change-request,
and to justify maintenance and upgrade decisions.
Maintenance effort – Chapter 5 finds that, based on maintenance data at CSA’s site, two
significant factors for estimating ERP maintenance effort, are maintenance category and task
complexity. Since the R2 for the regression model (empirical maintenance effort model) is
only 0.395, this thesis suggests that maintenance can be better estimated by also considering
8-12
additional attributes such as object modified, programming knowledge and experience, and
familiarity with the application area.. Other maintenance attributes relevant to patch-
maintenance (as observed in Chapter 6) are number of modification-enhancements and
number of patches implemented. These attributes would help in estimating patch-maintenance
effort and indicate how up-to-date the installed version is compared to the vendor’s
expectations.
Maintenance cost estimation – As reported by Brehm et al. (2001), there is a range of
tailoring options available in order to accomplish a maintenance request. These include using
the system configuration switches/tables, user-exits, bolt-on, workflow programming, ERP
programming, interface development, writing reports and screens, and modifying package
code. It is argued by Brehm et al. (2001) that different tailoring options pose different effort to
accomplish and therefore different costs to implement. Some of the tailoring options have
more impact on the future ERP maintenance effort than others. This is because some change-
requests may involve making changes to the standard ERP code or other software objects
such as data dictionary object, menu, screen, program, and etc. Consequently, each
modification also has its associated ongoing maintenance cost or effort. (The ‘ongoing
maintenance cost’ may be calculated based on some patterns from historical data.) These are
included because they are important in order to: (1) justify whether to approve a modification-
enhancement request in an ERP system; (2) facilitate minimization in total maintenance cost
or total ERP software costs, by controlling the types of enhancement request to implement;
(3) help in making better quality decisions on ERP maintenance; and (4) reduce the time
required to plan for future maintenance and upgrade project (because information on the
number of modification-enhancements, area of enhancement, method used in the
enhancement activity, and the impact of the enhancements on future maintenance, would be
readily available).
Vendor’s code modification – According to the guidelines given by Carney et al. (2000, p.
369) with respect to modifying the vendor’ software, the following details are to be recorded
before the software is modified: (1) the primary cause of the modification; (2) the reason that
no other solution is possible; (3) a precise description of the planned modification; (4)
evidence of approval to perform the modification from the appropriate and authoritative
Control Board; (5) evidence that the vendor has been consulted about the technical effect of
intended modification, and any response from the vendor concerning any resulting technical
8-13
or functional behavior of the item; (6) evidence that the vendor has been consulted about the
contractual effect of the modification, including precise explanation of any changes in license
fees and changes in any guaranteed short-term maintenance and support; and (7) evidence that
the product's vendor has been consulted regarding predictions on the probability that the
modified version will become part of its standard commercial offering, vendor’s intended
release date and licensing information, and predictions of the ongoing costs for additional
modifications to future releases of the product.
Carney et al. (2000, p. 370) further suggest that after the modification, the following
information should be recorded in the version archive: (1) a technical description of the
modification; (2) all applicable test data, including verification that the modified
configuration-item(s) passed all tests satisfactorily; (3) working versions of any tools used to
make the modification; and (4) the identity of the person(s)/organization(s) that actually
performed the modification.
Corrective requests – Other attributes primarily for corrective request are: (1) difficulty of
detecting and correcting error (Martin et al., 1983); and (2) method and tool used for problem
discovery (Glass et al., 1981, p. 147).
Based on these studies, the additional attributes suggested in the new ERP maintenance-data-
model are as summarized in Table 8.3.
8-14
Table 8.3: The additional attributes for ERP maintenance-data-model
Additional attribute Rationale Investigation Rationale for request Classify maintenance request.
Existence of business benefit Classify maintenance request.
Existence of maintenance impact on
installed module(s)
Classify maintenance request.
Benefit category Identify the benefit category(s) delivered by a benefit-oriented change-request; and facilitate quantification
of benefits or user opportunity cost.
Implementation cost Estimate the cost of implementing a change-request.
Ongoing maintenance cost Justify a maintenance decision.
Task complexity Estimate maintenance effort.
Number of modification-enhancements Helpful in estimating patch-maintenance effort
Number of patches implemented Indicate how up-to-date an installed version is.
Error detection difficulty Determine how rare the occurrence of the bug is; and is an indication of higher maintenance effort.
Method/tool for detection Facilitate planning for system performance test and user acceptance test.
Business value Estimate the value of the benefit(s) delivered by a benefit-oriented change-request; and justify maintenance
or upgrade decision(s).
Resolution
Details before software modification Ensure that important sources are consulted and documentation is updated accordingly before the
modification takes place; and minimize potential conflicts with vendor maintenance support (if not avoided).
Details after software modification Ensure that a detailed description of a software modification, test data, version of the system and the
persons involved are archived.
8-15
8.3.2 The Maintenance-Data-Model
Figure 8.2 consists of two sections. The top section describes the maintenance activities
involved in the ERP maintenance procedure stage (of the proposed ERP maintenance
methodology presented in Chapter 7, Figure 7.4); the lower section shows the proposed ERP
maintenance-data model. The proposed maintenance-date-model comprises the general-
purpose SEI maintenance attributes relevant to the ERP environment, CSA’s ERP
maintenance-data-model, and the additional ERP maintenance attributes discussed earlier.
The attributes name in Figure 8.2 are taken from Table 8.1 (either from the attribute name
given by SEI or CSA, depending on which is more intuitive) and Table 8.3. The ERP
maintenance procedure stage covers activities (for a change-request), starting from the point
when a request is initiated (in the investigation phase) until the changes are delivered to the
system users in the production system (in the delivery phase).
It is assumed that the request attributes proposed in the maintenance-data-model are available
and/or can be obtained for recording. According to the proposed maintenance-data-model (as
illustrated in Figure 8.2), when a system user encounters a problem with an ERP software and
reports it at the helpdesk, the ‘maintenance request identification’ activity will occur. The
measurable attributes that should be collected are: problem ID, product ID, service desk ID,
originator, date and time of occurrence, criticality, major functional area, functional area,
problem description, rationale for request, existence of business benefit, and existence of
impact on installed module(s). Once these attributes are obtained, the change-request will be
classified, approved and prioritized. Additional maintenance attributes resulting from this
activity (‘maintenance classification, approval, and prioritization’) are the type of
maintenance request (maintenance category), the benefits delivered by the change-request
(benefit category), and urgency of this request (urgency) assessed by a maintenance manager.
8-16
Investigation P hase R eso lu tion P hase D elivery S tage
M ain tenance ac tiv ity M ain tenance a ttribu tes to be co llec ted
- m ain tenancecategory (problemtype)- benefit category- urgency- problem ID- product ID- serv ice desk ID- orig inator- da te and tim e o foccurrence- critica lity- m a jor func tiona la rea- func tiona l a rea- problemdescrip tion- ra tiona le fo rrequest- exis tence o fbusiness benefit - exis tence o fim pact on ins ta lledm odule(s)
- num ber o fpatchesim plem ented- num ber ofm odification-enhancem ents- m a in tenancecategory (p rob lemtype)- benefit ca tegory- u rgency- p rob lem ID- p roduct ID- serv ice desk ID- o rig ina tor- da te and tim e ofoccurrence- critica lity- m a jor functiona larea- functiona l a rea- p rob lemdescrip tion- ra tiona le fo rrequest- exis tence o fbus iness benefit - exis tence o fim pact on insta lledm odu le(s )
- changes m adeto- analyst- program m er- prob lem s ta tus- prob lem s ta tusdate- approved by- pa tch num ber(vendor changerequest)- de ta ils be fore swm odifica tion- bus iness va lue- im p lem enta tioncost- ongo ingm ain tenance cost- task com plexity- quote- quote type- c lien t cost centre- un iqueness- pro jectedavailab ility- es tim ate tim e- ac tion to be taken- Issues o fcons ideration- ta ilo ring op tion- de fec t found in- erro r de tectiond ifficu lty- ..........
- approval tom igrate- re la ted changes- de ta ils a fte r swm odifica tion- re leased- changes m ade to- ana lys t- program m er- problem s ta tus- problem s ta tusdate- approved by- pa tch num ber(vendor changerequest)- de ta ils be fore swm odifica tion- bus iness va lue- im p lem enta tioncost- ongo ingm ain tenance cost- task com plexity- quote- quote type- c lien t cost centre- un iqueness- pro jectedavailab ility- es tim ate tim e- ac tion to be taken- ................
- problem status- problem statusdate- approved by- patch num ber(vendor changerequest)- deta ils before swm odification- business va lue- im p lem enta tioncost- ongo ingm aintenance cos t- task com plexity- quote- quote type- c lien t cos t centre- un iqueness- p ro jec tedava ilab ility- estim ate tim e- action to be tak en- Issues o fconsidera tion- ta ilo ring op tion- de fec t found in- e rro r de tec tiondifficu lty- m ethod fo rde tec tion- ..........
- re lated changes- deta ils a fter swm odification- re leased- changes m ade to- ana lys t- p rogram m er- p rob lem sta tus- p rob lem sta tusdate- approved by- pa tch num ber(vendor changerequest)- de ta ils be fore swm odification- business va lue- im p lem enta tioncost- ongo ingm ain tenance cost- task com plexity- quote- quote type- c lien t cos t centre- un iqueness- p ro jectedava ilab ility- estim ate tim e- action to be taken- Issues o fconsidera tion- ta ilo ring op tion- .............
- un iqueness- pro jectedavailab ility- estim ate tim e- action to be taken- Issues ofconsideration- ta iloring option- defect found in- error detectiondifficu lty- m ethod fo rdetection- num ber o f pa tchesim plem ented- num ber o fm od ifica tion-enhancem ents- m a in tenancecategory (p rob lemtype)- benefit ca tegory- u rgency- p rob lem ID- p roduct ID- serv ice desk ID- o rig ina tor- da te and tim e o foccurrence- critica lity- m a jor functiona la rea- functiona l area- ..........
- app lied- accepted by- approval tom igra te- re la ted changes- de ta ils a fte r swm odifica tion- re leased- changes m ade to- ana lys t- p rogram m er- p rob lem s ta tus- p rob lem s ta tusdate- approved by- pa tch num ber(vendor changerequest)- de ta ils be fore swm odifica tion- business va lue- im p lem enta tioncost- ongo ingm ain tenance cost- task com plexity- quote- quote type- c lient cost centre- un iqueness- p ro jectedava ilab ility- ............
- business value- im plem entationcost- ongoingm aintenance cost- task com plexity- quote- quote type- c lient costcentre- un iqueness- p ro jectedava ilab ility- estim ate tim e- action to be taken- Issues o fconsidera tion- ta ilo ring op tion- de fect found in- e rro r de tec tiond ifficu lty- m ethod fo rde tec tion- num ber o fpa tchesim plem ented- num ber o fm od ification-enhancem ents- m a in tenancecategory (p rob lemtype)- benefit ca tegory- ...........
M .1M ain tenance
requestidentifica tion
M .10D eliver the
changes to theusers
M .9C onduc t tes ting
M .8C onduct im pact ana lys is ,and perfo rm m odifica tion-enhancem ents ad jus tm ent
M .7Im plem ent the
solution
M .6D es ign so lu tion
M .5Issue quotation
M .4P roposeso lu tions
M .3S earch fo r
ava ilab ility o fm ain tenance
support
M .2M ain tenancec lass ifica tion ,approva l, andprio ritiza tion
- problem ID- product ID- service desk ID- orig inator- date and tim e ofoccurrence- criticality- m ajorfunctional area- functional area- problemdescription- rationale fo rrequest- ex istence ofbusiness benefit - ex istence ofim pact oninsta lledm odule(s)
Figure 8.2: The proposed ERP maintenance-data-model for maintenance procedure stage
8-17
If the request is approved by the maintenance manager for further investigation, the online
vendor’s maintenance support system will be consulted to determine whether the solution for
the request is available (‘search for availability of maintenance support’). In this activity,
number of patches and modification-enhancements already implemented in the installed
version are also investigated. Next, solution for this request is proposed (‘propose solution’).
Maintenance attributes associated with this activity are: uniqueness, projected availability,
estimate time, action to be taken, tailoring option, defect found in, error detection difficulty,
and method for detection.
However, if the request (due to some reasons) is rejected by the maintenance manager, the
system user will be informed of the reasons (i.e. issues of consideration). In contrast, if the
request is accepted, the maintenance manager will produce a quote for the maintenance work
(‘issue quotation’). Thus, the subsequent maintenance request’s attributes to gather are:
business value, implementation cost, ongoing maintenance cost, task complexity, quote, and
quote type. Provided the system user agrees to pay for it, the attribute client cost centre will
be collected.
As observed from Figure 8.2, the subsequent activities will be designing and implementing
the change-request, conducting impact analysis and modification-enhancement adjustment (if
necessary), performing testing, and finally delivering the changes to the system user. Along
with each of these activities, additional maintenance attributes will be collected, see Figure
8.2 for details.
8.4 Benefits From The Proposed Maintenance-Data-Model
In practice, the proposed ERP maintenance-data-model is useful to ERP-using organizations
for three main purposes: a repository of maintenance activities and maintenance knowledge, a
maintenance controlling and monitoring system, and a maintenance improvement and
decision-support tool.
8-18
8.4.1 A Repository Of Maintenance Activities And Maintenance
Knowledge
The proposed model consists of measurable, well-defined and organized attributes for
maintenance activities in maintenance procedure stage. All the knowledge regarding the
maintenance activities, for instance, the causes and effects of maintenance problems, remedies
for similar maintenance issues, status or progress of maintenance jobs, up-to-date
documentation of maintenance changes, and staff involved in all maintenance activities, are
captured in the proposed ERP maintenance-data-model. This provides immediate access to all
information past and present. Most importantly, this can facilitate subsequent monitoring of
maintenance progress, ensuring that maintenance staff are communicating in the same
language and reporting the maintenance activities accurately, and allowing quality-data for
future data-mining and for forecasting the future maintenance activities, for example in
predicting the upcoming maintenance requests (as in the study done by Burch et al. (1997)).
Attributes such as ‘problem type’, and ‘tailoring option’ allow maintenance organizations to
quantify the number of different types of maintenance requests, and tailoring options per
month and/or per year. A well-organized maintenance system allows the maintenance
manager to be well informed about maintenance activities in his maintenance organization,
and enables an ERP-using organization to maintain all maintenance knowledge (current, past
and future) within the organization.
8.4.2 A Maintenance Controlling And Monitoring System
With the maintenance-data-model, maintenance managers can be alerted of any abnormally
large amounts of certain maintenance categories (‘problem type’), that increases over time
(see also (Florac, 1992)). They can then decide on appropriate action(s) by justifying whether
it is aligned with the organization’s business objectives. Otherwise action can be taken to
alleviate and control the quantity of that request category.
On the other hand, if there are a large number of duplicate maintenance requests (by
referencing the ‘uniqueness’-attribute), the maintenance manager will be warned and
appropriate action can be taken such as revising the testing procedures, rewriting the error-
prone code or re-assessing the procedures involved in capturing system user’s requirements.
8-19
By checking the attributes of ‘changes made to’ and ‘related changes’, the maintenance
managers can easily judge the impact of a change-request, and also justify whether user
training is required for the maintenance.
Comparison can be made between the ‘date raised’ and the actual ‘applied’ date of the
maintenance solutions to identify whether the system users are facing any serious delays; and
then the ‘problem status’ and ‘problem status date’ attributes can be used to determine the
maintenance bottleneck. The maintenance backlog can then be easily calculated. With these
indicators, appropriate control can be carried out before an unexpected situation deteriorates.
8.4.3 A Maintenance Improvement And Decision-Support Tool
With the core maintenance information readily available, ERP managers are better informed
about the status of their ERP systems and maintenance conditions. For instance, with the
attributes of ‘urgency’ and ‘criticality’, requests with highest priority can be easily identified.
With attributes such as ‘tailoring option’, ‘benefit category’, ‘business value’,
‘implementation cost’, and ‘ongoing maintenance cost’, managers can quantify the costs and
benefits (or trade-offs) of implementing a change-request. Maintenance managers can then
make better-informed maintenance decisions. Making the right decision(s) is crucial to
reducing the total ERP software lifecycle costs.
ERP maintainers can respond to change-requests more efficiently and effectively as users’
requirements are collected in an organized and systematic manner. Fundamental maintenance
data is easily accessible from the proposed maintenance-data-model. This can increase
maintenance productivity as time is not wasted looking for or collecting the required
information. Thus, more maintenance requests can be completed in a given time period.
By comparing the maintenance priorities (i.e. both ‘urgency’ and ‘criticality’) of each change-
request with its expected time for completion (i.e. using the attribute of ‘estimated time’),
managers can easily allocate and schedule maintenance staff to each change-request. With the
historical data on maintenance categories (‘problem type’ and ‘tailoring option’) over time, a
manager can forecast the amount of different types of maintenance requests and can estimate
whether the existing maintenance task force is sufficient to meet future maintenance requests
demand.
8-20
The benefits from the proposed ERP maintenance-data-model are nothing more or less than
the benefits of the SEI maintenance-data-model for in-house software maintenance. However,
a new ERP maintenance-data-model is needed because the SEI maintenance-data-model
cannot be readily used in the context of ERP due to lack of some ERP software maintenance
attributes.
8.5 Summary
The comparison between CSA’s ERP maintenance-data-model and the SEI maintenance-data-
model shows that there are strengths and weaknesses between these two data-models. SEI is
generic but it is insufficient in the context of ERP. It lacks some maintenance attributes (some
of) which are ERP-specific or lack of consideration for some aspect in software maintenance.
These attributes are related to the nature of the software, maintenance effort estimation,
maintenance-related cost, patch-maintenance, and tailoring option. These could be due to: (1)
SEI constraining its focus on defect and problem reporting only and neglecting the issues of
maintenance effort and cost; and (2) the unique characteristics, and nature of ERP software
maintenance such as vendor-supported, software code belongs to the vendor, business benefit
oriented maintenance request and cross-functional software system.
There is also room for improvement in CSA’s ERP maintenance-data-model. Maintenance
attributes found to be relevant and useful in the context of ERP are: uniqueness
(recommended by SEI), business benefit of doing a change-request, impact of a change-
request on installed module(s), business value, ongoing maintenance cost, maintenance task
complexity, number of patches and modification-enhancements implemented, details before
software modification, details after software modification, error detection difficulty, and
method/tool for detection. These attributes are believed to be useful to estimate maintenance
and upgrade effort and costs, and benefits quantification, as well as facilitate ERP
maintenance and upgrade decision-making. Therefore, a new ERP maintenance-data-model is
proposed based on CSA and SEI maintenance-data-model, and additional relevant attributes.
The new ERP maintenance-data-model, capturing the fundamental characteristics of ERP
maintenance environment, can facilitate: (1) maintenance-request classification using the
8-21
proposed ERP maintenance taxonomy (described in Chapter 4); (2) maintenance effort
estimation using the effort determinants (described in Chapter 5); and (3) benefits and user-
opportunity costs quantification for making maintenance and upgrade decision(s) (detailed in
Chapter 6). The proposed maintenance-data-model could be served as: (1) a repository of
maintenance activities and maintenance knowledge; (2) a maintenance controlling and
monitoring system; and (3) a maintenance improvement and decision-support tool.
8-22
9 Summary And Future Research
This chapter provides the summary of this research project. The organization of this chapter is
as follows. Section 9.1 revisits the research problem, objectives and methodology. Section 9.2
summarizes the research findings, main outcomes and contributions from this study. Section
9.3 discusses how the validity and reliability for research findings are addressed. Section 9.4
highlights the limitations of the research. Section 9.5 reviews the implications of the findings
for research and practice. Section 9.6 assesses the future research from this project. Lastly, the
conclusions from the project are given in Section 9.7.
9.1 Summary Of The Research Problem, Objectives And Methodology
This study was motivated by lack of research in the area of ERP maintenance and upgrade,
although this area has been found to be problematic and costly by ERP-using organizations.
This research addresses this problematic area from the perspective of effective and efficient
maintenance management. The nature of this study is descriptive, exploratory, revelatory and
collaborative. It aims to provide research outcomes, as well as practical outcomes for the
industry partners (i.e. ERP-using organizations, ERP vendor (SAP) and consultants).
The main research objectives of this thesis are to examine the nature of ERP maintenance and
upgrade (MU), and to determine whether existing literatures are applicable in the context of
ERP. The efforts involved are: (1) providing a definition of ERP maintenance, identifying
dimensions for classifying ERP maintenance requests and proposing an ERP maintenance
taxonomy; (2) identifying project characteristics affecting ERP maintenance effort and
developing an ERP maintenance effort model; (3) identifying factors affecting ERP
maintenance and upgrade (MU) decisions and developing an ERP MU decision framework;
(4) identifying activities involved in ERP maintenance preparation, maintenance procedure
and software upgrade and developing an ERP maintenance methodology; and (5) identifying
fundamental measurable ERP maintenance request’s attributes and developing an ERP
maintenance-data-model. For practice, the mentioned elements are believed to be important
9-1
aides to containing ERP maintenance and upgrade costs, and facilitating benefit-realization
from the ERP software.
The existing maintenance tools and mechanisms (all of which to date have been largely based
on studies of custom in-house software systems) compared and tested in this study include
Swanson’s (1976) and Chapin et al.’s (2001) software maintenance taxonomies; software
replacement models (Gupta et al., 1988, 1996; Gode et al., 1990; Chan et al.); software
maintenance methodology – IEEE/EIA 12207.2-1997 (1997), and the framework for counting
problems and defects proposed by the Software Engineering Institute (SEI) (Florac, 1992).
They were examined and assessed to ascertain whether prior studies are applicable in the ERP
environment.
In addressing this relatively new research area suffer from a lack of appropriate theory, case
study research method (Benbasat et al., 1987; Gable, 1994; Yin, 1994) was adopted. A single
case study was conducted at a Government agency, named Corporate Service Agency (CSA),
in the Queensland State, Australia. According to Yin (1994), in light of the revelatory nature
of the study, which provides an opportunity to observe and analyze a phenomenon previously
inaccessible to scientific investigation, a single case study is justified (p. 40). CSA is a
recognized SAP service provider, who provides application services to other Government
departments. However, it also uses the SAP R/3 system as well as maintains it. In order to
achieve the study’s objectives, five embedded sub-studies were carried out within the
overarching case study on CSA. They are: taxonomy sub-study, effort sub-study, decision
sub-study, methodology sub-study, and data sub-study. Theses sub-studies are interconnected
such that the outcomes from one or more sub-studies serve as inputs to another sub-study(s).
9.2 Summary Of Research Findings, Main Outcomes, And Contributions
This thesis has focused on comparing an ERP packaged software environment with the in-
house or custom software, or homegrown software environment, maintenance tools and
mechanisms. It is worth making a similar comparison between ERP and other packaged
software literature, commonly known as commercial off-the-shelf (COTS). However, besides
a lack of study on COTS (Gable et al., 1997; Kemerer, 1998), this is not the primary intention
9-2
of this thesis. Thus, the comparison with COTS is not covered in detail here but is reserved
for future research. This section recaps the key findings and contributions in the five sub-
studies.
9.2.1 Taxonomy Sub-study
Observations made from the analysis of CSA ERP maintenance activities are: (1) the ERP-
using organization does not only maintain internally originated change-requests, but also
implements maintenance introduced by the vendor; (2) requests for user-support concerning
the ERP system behavior, function and training constitute a main part of ERP maintenance
activity; and (3) similar to the in-house software environment, enhancement is the major
maintenance activity in the ERP environment, making up almost 64% of total change-request
effort (this is consistent with the findings from Glass and Vessey (1999)). In light of these and
other findings, ERP maintenance is defined as post-implementation activities until the system
is disposed from the production system; targeting at keeping the system running correctly,
operating well in a changed environment and providing user-support, as well as realizing
more business benefits (e.g. best business practices, enhanced system integration, cost
reduction) and maintaining the installed system a supported version; and covering both
internally and externally originated maintenance requests. ERP maintenance requests can be
usefully characterized along three salient dimensions: (1) source of the maintenance request;
(2) the existence of any business-benefits; and (3) the existence of any impact of the
maintenance on the client’s installed ERP module(s).
It is found that ERP maintenance is not an instance of in-house software maintenance. The
existing in-house maintenance taxonomies are not sufficient to capture the characteristics of
ERP maintenance activities. They lack consideration for some important ERP maintenance
characteristics, i.e. the role of the external party – the software vendor – in maintaining ERP
software; and the (categorization of) business benefit of undertaking the maintenance. Thus,
an ERP-specific maintenance taxonomy tailored to the ERP environment is proposed.
The proposed ERP maintenance taxonomy represents an extension beyond the modern-view
of maintenance-activity typology in two ways: (1) it covers vendor-initiated maintenance
activities; and (2) it classifies the relevant maintenance activities based on the benefit
perspective. Although enhancement activities in in-house software may also have significant
9-3
impacts on the way the employing-organizations do business, to the knowledge of the author
there is no maintenance taxonomy proposed to classify maintenance request based on the
benefit perspective.
9.2.2 Effort Sub-study
The attributes of maintenance effort captured by CSA are maintenance category, task
complexity, and tailoring option. Maintenance effort is measured (by CSA) using the number
of hours spent in servicing the request. The findings suggest that among the three maintenance
project characteristics or independent variables of maintenance category, task complexity and
tailoring option, task complexity is the most influential variable explaining 32% of variance in
maintenance effort at CSA’s site. The second influential variable is maintenance category,
which explains 7% of variance in maintenance effort at CSA’s site. These variables are
statistically significant at the 0.001 levels for explaining variance in maintenance effort at
CSA’s site. These two factors including their interaction term yield adjusted R2=0.395. On the
other hand, the findings for tailoring option variable did not provide convincing evidence that
it is a significant determinant of ERP maintenance effort at CSA’s site.
The supported hypotheses are: (1) maintenance category is a significant predictor of
maintenance effort; and (2) maintenance effort will increase curvilinearly with task
complexity. These findings are consistent with the in-house software study conducted by
Jørgensen (1995). The rejected hypotheses are: (1) configuration-related requests will require
lesser maintenance effort than programming-related maintenance requests; (2) other requests
(non-configuration and non-programming) will require less maintenance effort than
programming-related maintenance requests; and (3) configuration-related requests will
require less maintenance effort than other (non-configuration and non-programming)
maintenance requests. These are counter-intuitive findings.
9.2.3 Decision Sub-study
It is found that on average a patch is almost as effort demanding as a user-enhancement
request. Patch-maintenance effort is driven by the number of modification-enhancements, and
type of enhancement done to the standard ERP code.
9-4
Upgrade implementation cost also depends on the version-gap or migration-path between an
existing and a new upgrade version. CSA conducts technical upgrades because of the
withdrawal of vendor support for its current version. Benefit-realization is the primary
objective for CSA in considering a functional upgrade. Upgrade cost is a major issue, and
prohibitive for CSA in considering an upgrade to its ERP system. These findings are
consistent with those reported in the trade press, see (AMR, 2002; McDonnell, 2000;
Thompson, 2001). It is found, however, that after the upgrade the number of modification-
enhancements done decrease by one-third of the original total. Analysis of the number of
notes showed that the total number of notes and patches decreased by about 21% from an
older version to a newer version.
Results from this study on the ERP maintenance and upgrade environment, show that (1) user
opportunity and benefit realization, (2) reduction in the number of previous modification-
enhancements, and (3) potential reduction in the number of future patch-maintenance
activities are important characteristics of an ERP maintenance and upgrade decision model.
Found in this research is that in-house software replacement models are inappropriate in the
context of ERP. In-house software replacement models are: (1) irrelevant because of the
following characteristics considered in the models: software technology, system size and
system age; and (2) insufficient because they do not capture the benefits and user opportunity
associated with maintenance requests, and the availability of maintenance support from the
vendor. Although user opportunity and reduction in the number of future maintenance
activities may also be applicable in in-house software maintenance, they were not considered
in the existing literature. Reduction in the number of previous modifications is unlikely to be
an in-house software replacement-driver because internal system enhancements are unlikely
to be available from external sources and therefore could not be replaced or reduced. In light
of the insufficiencies, a specific ERP maintenance and upgrade decision framework is
proposed.
9.2.4 Methodology Sub-study
A comparison between the synthesized CSA’s ERP maintenance methodology and IEEE/EIA
12207.2-1997 (1997) standard for software maintenance methodology shows that although
IEEE/EIA 12207.2-1997 is generic and comprehensive, it lacks certain unique characteristics
of ERP. The major issues overlooked in IEEE/EIA 12207.2-1997 are: (1) availability of
9-5
vendor-support; (2) readily available new versions for upgrades; (3) the importance of user-
support activities; and (4) modifying vendor’s codes and replacing custom code with vendor’s
code. This is because IEEE/EIA: (1) constrains its focus to in-house software maintenance;
and (2) emphasizes change-requests activities only (thus, it does not include user-support
request activities.)
While CSA’s ERP maintenance methodology is well-organized and well-managed, there is
still room for improvements. The activities that could enhance the effectiveness and
efficiencies in maintenance management and facilitate better maintenance and upgrade
decision-making are: (1) computing the ongoing user-enhancement maintenance and
forecasting maintenance demands by capturing more related maintenance data; (2) identifying
the repetitive maintenance activities that are best automated; and (3) using a quantitative
mechanism to make better quality maintenance and upgrade decisions.
Thus, a new ERP maintenance methodology based on the synthesized CSA’s ERP
maintenance methodology (capturing the fundamental ERP maintenance and upgrade
activities, some of which are overlooked in IEEE/EIA 12207.2-1997); IEEE/EIA 12207.2-
1997’ strengths; and other related literature, is proposed.
9.2.5 Data Sub-study
A comparison of the synthesized CSA’s ERP maintenance-data-model with the SEI
maintenance-data-model (Florac, 1992) showed that there are strengths and weaknesses in
these two data-models. SEI is generic and comprehensive but in some way is insufficient in
the context of ERP. It lacks consideration of certain maintenance attributes, some of which
are relevant to software in general and some that are ERP-specific. These attributes are: major
functional area, service desk reference, estimate time, quote, quote type, client cost centre,
action to be taken, issues of consideration, vendor change-request number, analyst, and
programmer. These deficiencies could be due to: (1) SEI constrains its focus to defect and
problem reporting only; and (2) the unique characteristics and nature of ERP software
maintenance, such as business benefit oriented maintenance requests, and that it is a cross-
functional software system that is vendor-supported, with the software code belonging to the
vendor.
9-6
On the other hand, it is found that there is room for improvement in CSA’s maintenance-data-
model. Maintenance attributes found to be relevant and useful in the context of ERP are
uniqueness (recommended by SEI), rationale for request, existence of business benefit,
existence of impact on installed module(s), benefit category, business value, implementation
cost, ongoing maintenance cost, task complexity, number of patches and modification-
enhancements implemented, details before software modification, details after software
modification, error detection difficulty, and method/tool for detection. These attributes are
believed to be useful in estimating maintenance and upgrade effort and costs, and benefits
quantification, as well as facilitating ERP maintenance and upgrade decision-making. Thus, a
new ERP maintenance-data-model is proposed based on CSA and SEI maintenance-data-
models, and additional relevant attributes. The proposed maintenance-data-model could serve
as: (1) a repository of maintenance activities and maintenance knowledge; (2) a maintenance
controlling and monitoring system; and (3) a maintenance improvement and decision-support
tool. Table 9.1 summarizes the findings reported in the five sub-studies.
9-7
Table 9.1: Summary of findings
Existing literature (based on studies of in-house software systems) Sub-study Is/are they appropriate in the context of ERP? Why not?
Is the insufficiency ERP-specific?
What is now known, from this thesis about ERP maintenance and upgrade?
1. Previous studies have mainly
focused on internally originated
maintenance requests; therefore
they are lack consideration of
maintenance requests originated
from an external party – i.e. the
software vendor.
Yes.
1. Taxonomy No, for Swanson
(1976) and Chapin
et al.’s (2001)
maintenance
taxonomies.
2. They focus on the act of
implementing a maintenance
request but lack emphasis on the
business benefit of undertaking the
maintenance.
Not necessarily.
1. The ERP-using organization, in addition to
addressing internally originated change-
requests, also implements maintenance
introduced by the vendor.
2. User-support constitutes a main part of ERP
maintenance activities; the rate of user-support-
requests will increase dramatically in the first 2-
3 months of a successful module
implementation and become stable thereafter.
3. Enhancement maintenance is a major ERP
maintenance activity.
4. A definition of ERP maintenance has been
proposed (see Chapter 4, Section 4.3).
5. The salient dimensions for characterizing ERP
maintenance requests are: source of the
maintenance request; the existence of any
business benefits; and the existence of any
impact of the maintenance on the client’s
installed ERP module(s).
9-8
Existing literature (based on studies of in-house software systems) Sub-study Is/are they appropriate in the context of ERP? Why not?
Is the insufficiency ERP-specific?
What is now known, from this thesis about ERP maintenance and upgrade?
2. Effort No definitive
conclusion could
be drawn.
While some factors are found to affect
maintenance effort (similar to the in-
house software), factor such as
tailoring option does not.
Further studies and experiments are
required in order to confirm findings
reported here.
No. 1. Among the three attributes of maintenance
effort (i.e. maintenance category, task
complexity, and tailoring option) captured by
CSA:
a. Task complexity is the most influential
variable, explaining 32% of variance in
maintenance effort at CSA's site.
b. The second influential variable is
maintenance category, which explains
7% of variance in maintenance effort at
CSA's site.
c. The findings for tailoring option variable
did not provide convincing evidence
that it is a significant determinant of
ERP maintenance effort.
d. Together with the interaction term, task
complexity and maintenance category
yield 40% of variance in maintenance
effort at CSA's site
2. Maintenance effort is measured (by CSA) using
the number of hours spent in servicing the
request.
9-9
Existing literature (based on studies of in-house software systems) Sub-study Is/are they appropriate in the context of ERP? Why not?
Is the insufficiency ERP-specific?
What is now known, from this thesis about ERP maintenance and upgrade?
3. Decision
No. In-house software replacement models
are:
1. Irrelevant because of the following
characteristics considered in the
models: software technology,
system size, and system age.
2. Insufficient because they do not
capture the benefits and user
opportunity associated with
maintenance requests, and the
availability of maintenance-support
from the vendor.
Yes.
No, except for
the availability of
maintenance-
support from the
vendor.
Patch-maintenance:
1. It was found that on average a patch is almost
as effort-demanding as a user-enhancement
request.
2. Patch-maintenance effort is driven by the
amount of modification-enhancements done
and type of enhancements done to the
standard ERP code.
Upgrade:
3. Upgrade implementation cost also depends on
version-gap or migration-path between an
existing and a new upgrade version.
4. CSA conducts technical upgrade because of
the withdrawal of the vendor's support for its
current version.
5. Benefit-realization is the primary objective for
CSA in considering for a functional upgrade.
6. Upgrade cost is a major issue, and prohibitive
for CSA in considering its ERP system upgrade.
9-10
Existing literature (based on studies of in-house software systems) Sub-study Is/are they appropriate in the context of ERP? Why not?
Is the insufficiency ERP-specific?
What is now known, from this thesis about ERP maintenance and upgrade?
7. It is found that after the upgrade the number of
modification-enhancements done decreases by
one-third of the original total.
8. Analysis of the number of notes shows that the
total number of notes and patches decreases
by about 21% from an older version to a newer
version.
Decision framework:
9. Benefit realization, reduction in number of
previous modification-enhancements, and
reduction in number of future patch-
maintenance requests are important
characteristics for an ERP maintenance and
upgrade decision model.
9-11
Existing literature (based on studies of in-house software systems) Sub-study Is/are they appropriate in the context of ERP? Why not?
Is the insufficiency ERP-specific?
What is now known, from this thesis about ERP maintenance and upgrade?
4. Methodology No. 1. IEEE/EIA 12207.2-1997 lacks
consideration for the following major
issues:
a. availability of vendor-support;
b. readily available new versions
for upgrades;
c. the importance of user-
support request activities; and
d. modifying vendor’s code and
replacing custom code with
vendor’s code.
2. This is because IEEE/EIA 12207.2-
1997:
a. constrains its focus on in-
house software maintenance;
and
b. emphasizes change-requests
activities only.
Yes, except for
the user-support
request activities.
1. The fundamental maintenance activities considered
in the synthesized CSA’s ERP maintenance
methodology but not in IEEE/EIA 12207.2-1997 are:
(a) inclusion of vendor maintenance support; (b)
searching for availability of maintenance support
from the vendor; (c) reporting maintenance requests
to the vendor; (d) reapplying prior modification-
enhancements (if applicable); (e) user support
request activities; (f) researching upgrade options;
(g) fully assessing new functionality in each
(potential) upgrade version; and (h) deciding
whether to keep prior modification-enhancements
during upgrade.
2. The areas for improvements in CSA’s ERP
maintenance methodology are: (a) computing the
ongoing user-enhancement maintenance and
forecasting maintenance demands by capturing
more related maintenance data; (b) identifying the
repetitive maintenance activities that are at best
automated; and (c) using quantitative mechanism to
make better-informed maintenance and upgrade
decisions.
9-12
Existing literature (based on studies of in-house software systems) Sub-study Is/are they appropriate in the context of ERP? Why not?
Is the insufficiency ERP-specific?
What is now known, from this thesis about ERP maintenance and upgrade?
No.
5. Data
No. (The SEI
maintenance-data-
model proposed by
Florac (1992).)
These could be due to:
1. previous study constrains its focus
on defect and problem reporting
only; and
2. the unique characteristics, and
nature of ERP software
maintenance such as vendor-
supported, software code
belonging to the vendor, business
benefit oriented maintenance
requests and cross-functional
software system.
Yes.
1. Maintenance attributes considered in CSA’s
ERP maintenance-data-model but not in SEI
are: major functional area, service desk
reference, estimate time, quote, quote type,
client cost centre, action to be taken, issues of
consideration, vendor change-request number,
analyst, and programmer.
2. Other maintenance attributes suggested in the
ERP maintenance-data-model are: rationale for
request, existence of business benefit,
existence of impact on installed module(s),
benefit category, business value, tailoring
option, implementation cost, ongoing
maintenance cost, maintenance task
complexity, number of patches and
modification-enhancements implemented,
details before software modification, details
after software modification, error detection
difficulty, and method/tool for detection.
9-13
9.3 Validity And Reliability Of The Study
Yin (1994) suggests that for judging and dealing with qualitative research design quality there
is four design tests common to all social science methods; they are construct validity, internal
validity, external validity and reliability. This section will describe and summarize what had
been done and how these validity tests are satisfied in each sub-study.
Multiple sources of evidence, chain of evidence, participants review, pattern-matching and
member checks are used to ensure the construct validity (i.e. correct operational measures for
the concepts being studied) and internal validity (i.e. certain conditions are shown to lead to
other conditions distinguished from spurious relationships) of this study (see (Maxwell, 1996;
Merriam, 1998; Newman et al., 1998; Yin, 1994)). Table 9.2 summarized what validity tactics
are used and how these are done in each sub-study. Analytical technique, a reasoned judgment
for guiding inferences for another study based on similar context (Lee, 1999), is used in
making generalizations of the research results obtained from this study. In this approach, an
analysis of the similarities and differences between the contexts of two studies is required.
The stronger the similarities between the two studies the stronger the inference for analytical
generalization. Newman et al. (1998) suggest that analytical generalizabilities of the results
from qualitative research can be improved by: (1) establishing the criteria that could allow
comparable sample to be easily identified (applicability), (2) showing that the findings are not
context dependent (context limited or transferability), and (3) determining the factors that
could affect the findings (replicability or consistency). shows the criteria where the
results from this study can be generalized to other cases. Two methods employed in this study
to ensure the reliability of a case study research design are by writing a case protocol and
creating the case study’s database (Yin, 1994). They are meant to lend itself to external
inspection and reanalysis; they are given in Appendix C and D.
Table 9.3
9-14
Table 9.2: Validity and quality of this study
Sub-study Construct validity tactics Internal validity tactic Multiple sourceof evidence
Chain of evidence
Participant review
Pattern-matching
Peer review/ examination (via paper submission for publication considerations)
Taxonomy X
(Interview,
change-request
database, user-
support
database)
X X*
(Comparison is made with
in-house software
maintenance taxonomies)
5 reviewers
(2 – Journal of Systems and Software, 3 - IEEE
International Conference on Software Maintenance
2001)
Effort X
(Interview,
change-request
database)
X X
(Hypothesis testing)
-
Decision X
(Interview,
change-request
database, patch-
support
database,
modification
database,
documentation)
X X*
(Comparison is made with
in-house software
replacement models**)
6 reviewers
(3 – Journal of Software Maintenance: Research
and Practice, 3 – Americas Conference on
Information Systems 2001)
9-15
Sub-study Construct validity tactics Internal validity tactic Multiple sourceof evidence
Chain of evidence
Participant review
Pattern-matching
Peer review/ examination (via paper submission for publication considerations)
Methodology X
(Interview,
change-request
database,
documentation)
X
(maintenance
process)
X X*
(Comparison is made with
Standard IEEE/EIA
12207.2-1997)
7 reviewers
(3 - IEEE International Conference on Software
Maintenance 2002, 2 – Pacific Asia Conference on
Information Systems 2003, 2 – Hawaii International
Conference on System Sciences 2003)
Data X
(Interview,
maintenance-
request forms,
change-request
database)
X
(maintenance
procedure)
X X*
(Comparison is made with
SEI – Framework for
counting problems and
defects)
2 reviewers
(Australasian Conference on Information Systems
2001)
X = indicates that the tactic was used in the respective sub-study. * = this thesis shows that existing software maintenance taxonomies, replacement models, maintenance methodology, or maintenance-data-model is insufficient in the context of ERP. ** The author is not equating ERP upgrade with in-house software replacement but to investigate whether the factors considered in existing replacement/rewrite models are useful and relevant in the context of ERP.
9-16
Table 9.3: Criteria for judging the generalization of this study’s results
Criteria* Characteristics of this study Applicability
- Criteria that could allow
comparable sample to be
easily identified
Comparable sample
1. Government organization.
2. Service provider and a user itself.
3. The ERP system is the SAP R/3 system.
4. The installed SAP R/3 modules are Finance and Human Resources.
5. It maintains, as well as uses the ERP system.
Context limited
(transferability)
– Show that the findings are
not context dependent
Taxonomy sub-study
1. Findings from the case study agree with those reported in the trade press and research reports. Moreover, findings from
related ERP literature are also considered in the proposed ERP taxonomy.
2. Widely accepted maintenance taxonomies from Swanson (1976) and Chapin et al. (2001) are studied and compared with
CSA’s ERP maintenance activities in this sub-study.
Decision sub-study
1. The proposed decision framework consists of fundamental factors affecting ERP maintenance and upgrade decision.
These factors are found to be similar between the empirical data obtained from CSA and existing trade press; and some
of these factors are identified and synthesized from the literature.
2. Factor like reduction in number of modification-enhancements after upgrade is also supported in the latest research
findings from the AMR research.
3. Factor for example potential reduction in number of patch-maintenance from an older version to a newer version is non-
case specific.
Methodology sub-study
1. The key findings in this sub-study are believed to be the fundamental activities in an ERP maintenance environment.
They are activities related to preparing for ERP maintenance (e.g. identifying vendor’s maintenance support), planning for
an upgrade (e.g. investigating the upgrade options available), and performing maintenance and upgrade processes (e.g.
9-17
Criteria* Characteristics of this study conducting impact analysis and reapplying previous modifications). They are not case-specific characteristics and
perceived to be typical and basic maintenance and upgrade activities/tasks across most ERP-using organizations.
2. Well-recognized maintenance methodology – IEEE/EIA 12207.2-1997 is studied and compared with the synthesized
CSA’s ERP maintenance methodology in this sub-study.
Data sub-study
1. Majority of the maintenance attributes identified from the synthesized CSA’s ERP maintenance-data-model are general
for a typical software environment and ERP in specific. This is because they are based on the general characteristics of
ERP software environment.
2. SEI maintenance-data-model, well-recognized by researcher and practitioner, is studied and compared with CSA’s ERP
maintenance-data-model in this sub-study.
Replicability (consistency)
– Determine the
factors/effects that could
affect the findings
1. All data obtained, captured and recorded are from an ERP organization that had implemented the SAP R/3 system, and
made an upgrade decision for the first time.
2. It is a Government organization; service provider and a user itself; the ERP system is the SAP R/3; the installed SAP R/3
modules are Finance and Human Resources; and it maintains, as well as uses the ERP system.
3. Maintenance management practice of CSA, for example (i) batch the patch-maintenance (introduced by the vendor) until
the cumulated benefits exceed the maintenance costs, (ii) keen to minimize the ERP system operational costs, and (iii)
control the number of modification-enhancements to the ERP system. * Source: (Newman et al., 1998)
9-18
9.4 Limitations
This section discusses the limitations of this study in terms of the generalizations of the main
findings reported here; and the scope of the study covered in the sub-studies.
9.4.1 Generalizations
It is acknowledged that only a single case study was conducted in this project. However, the
criteria by which to judge the quality and generalization of this study and how this research
meets those criteria had been illustrated in Table 9.2 and Table 9.3. This approach to justify
the validity and reliability of a qualitative research design such, among other qualitative
method researchers, is also solicited by Markus et al. (1999, p. 36). Using the unique
characteristics of CSA given in Table 9.3, this section describes how they will affect the
generalization of the main outcomes from the five sub-studies. This is summarized in
. Explanations are also given here on how the main outputs that have not been observed
(under different ERP software and maintenance function) might differ from those reported
here.
Table
9.4
Table 9.4: Generalization of the findings
Sub-study Are findings affected by the following unique characteristics of CSA? Government
organization Service provider SAP R/3 system +
FI and HR modules Maintain the ERP system
Taxonomy Yes. No. Yes. Yes.
Effort Yes. No. Yes. Yes.
Decision Yes. No Yes. Yes.
Methodology Yes. No. Yes. Yes.
Data Yes. No. Yes. Yes.
Government organization – CSA is a Government organization. Although majority of the
findings and the main outcomes from CSA: (1) agree with those reported in trade press and
research reports, (2) general and relevant ERP literature is referenced in developing the
proposed ERP maintenance mechanisms and methodology, and (3) widely accepted
maintenance taxonomy, standard for software maintenance methodology, and data-model
(which largely based on in-house software) from well-recognized research and institute are
9-19
studied and used to make comparison with CSA’s maintenance activities, maintenance
methodology and maintenance-data-model, there are no evidence the argue that they are
applicable to other types of organizations (such as the private or non-profit organizations).
Service provider – CSA is a service provider for the SAP system to other Government
departments in Queensland State in Australia. Yet, CSA itself also uses the SAP systems.
Thus, the findings here are not only applicable to service provider but also ERP organizations
that use and maintain a similar system. (In practice, there are a lot of difference between an
organization that manages ERP maintenance activities for other organization (service
provider) and an organization that manages its own ERP maintenance activities but the main
outputs in this study are applicable for both cases.)
SAP R/3 system with Finance and Human Resources modules – This research focused on
an SAP R/3 ERP system. Thus, the discussions are structured around this particular ERP
software system, and the findings may be limited to this study context. For instance,
taxonomy sub-study – different software vendor may introduce different type of (patch)
maintenance and new version of upgrade for different purposes, and imposes different
maintenance strategy and policies on its clients. This can constrain the applicability of the
proposed ERP maintenance taxonomy. Effort sub-study – different software platform (e.g.
client-server vs. mainframe) and domain knowledge (required in different application module)
may result in a different level of complexity to understand the application logic, and may
require different approach or mechanism to perform maintenance. Thus, it may need different
amount effort to implement. Decision sub-study – similarly, different ERP software and
vendor may use slightly different strategy and bring different types of implication and benefits
in attracting its clients to upgrade their existing ERP systems. As a result, the cost function for
the upgrade decision could be slightly different depending on factors affecting this decision.
Methodology sub-study – different software vendor may use method in delivering patch
maintenance to its clients and recommend slightly approach in the software upgrade.
Therefore, activities and tasks for monitoring and implementing a patch and software upgrade
could be slightly different. This warrants further research. Data sub-study – likewise to
maintenance methodology, maintenance-data-model for different ERP software could also be
different depending on the attributes and information needs for patch-maintenance, for
example.
9-20
Maintain the ERP system – The applicability of the main outputs from this research are not
ERP organizations that maintain SAP R/3 systems. For organizations that use the system but
do not maintain the systems at all, the outputs from this study may be of little use to them.
This is because they do not classify maintenance requests and estimate maintenance effort,
have limited control (in most cases) over when the outsourcers should do software upgrade
and maintenance decision-making, do not manage ERP software maintenance and upgrade
activities and tasks, and generally do not capture much maintenance request attributes or
details. In more precise, the results reported in this thesis are generalizable to cases or
organizations that use and maintain or maintain SAP R/3 systems.
9.4.2 Scope Of The Sub-Studies
Taxonomy sub-study – The taxonomy does not cover the issues of how changes are made,
and whose software properties are changed. The former would cover the tailoring options, and
the latter is important because an ERP system can have both standard and custom properties.
Effort sub-study – Other factors influencing maintenance effort such as human capital and
programmer experience are not considered in the maintenance effort model due to lack of
data. The model is limited for estimating maintenance effort for CSA internal change-request
but not for patch-maintenance effort, or an upgrade effort.
Decision sub-study - The proposed decision framework represents a simplistic model of ERP
maintenance and upgrade (MU) decision domain. This framework may not be complete. At
current-state, the proposed decision framework provides insights into the factors/variables to
be considered in making ERP maintenance and upgrade decision. It assumes that MU projects
have no risks, and that new versions for upgrade are from the same vendor. A fix pattern of
maintenance requests arrival and serviced is assumed when an upgrade decision is to be made.
The decision framework is not an analytical model but a quantitative model which requires
exhaustive computation for a decision solution.
Methodology sub-study – The proposed maintenance methodology incorporates the
fundamental issues of what the maintenance activities are, who are involved, the order they
are performed and why they performed. However, it does not describe: (1) how they are
performed (see (Kellner et al., 1988)), and (2) the input, output, control and feedback involved
9-21
in each maintenance activity. In addition, from the upgrade perspective, it covers the technical
upgrade only (activities involved in a functional upgrade is also worth future research
endeavor). Moreover, the proposed upgrade activities are meant for software replacement
involving software from the same vendor (same as an installed version).
Data sub-study – In addition, the proposed maintenance-data-model focuses on maintenance
attributes at the maintenance procedure stage only; maintenance attributes at the ERP
software maintenance preparation and software upgrade stages are not covered in this thesis.
9.5 Implication Of The Research
This section sums up the implications or inferences made from the findings in this study for
research and practice. The implications drawn for practice cover the three key players
involved in ERP lifecycle support – the clients or ERP-using organizations, the vendor (SAP),
and consultants.
9.5.1 Implications For Research
Surveys, and longitudinal and multiple case studies across other government agencies and
private sector organizations of all sizes and industries, are warranted in order to: (1) extend
the generalizations of the proposed ERP maintenance tools and mechanisms; (2) identify the
similarities and differences in the cases through comparison; and (3) extend the outputs from
this research – the ERP maintenance taxonomy, effort determinants, the MU decision
framework, maintenance methodology, and maintenance-data-model.
The findings from the effort sub-study highlight the value of further experimental research
aimed at further confirming the findings here. The empirical data for testing the
characteristics of ERP maintenance projects affecting maintenance effort should be designed
and collected using predefined procedures from the researcher rather than obtaining these data
from the organization’s archival records. Following structured procedures for this purpose is
intended to reduce/minimize data collection error.
9-22
The findings from methodology sub-study highlight the value of incorporating the risk factors
in MU project and vendor-switching costs in the proposed decision framework. Risk is one of
the main factors considered in CSA’s upgrade business case.
Findings from the data sub-study highlight the value of proposing maintenance attributes at
maintenance preparation stage and software upgrade stage in order to develop a complete
maintenance-data-model.
9.5.2 Implications For ERP-Using Organization
The term ERP-using organization in this section refers to an organization that maintains an
installed ERP system. Its responsibilities for ERP maintenance would include initial planning
and preparation for its ERP maintenance activities, supporting maintenance requests from its
system users and IT-staff, and implementing patch maintenance from the vendor. It would
also carry out ERP system upgrades (introduced by the vendor) whenever necessary. CSA,
which has been discussed throughout this thesis, is good example of an ERP-using
organization. The following are implications of the research outputs, discussed in Chapter 4 –
8, for ERP-using organizations.
Taxonomy sub-study – The ERP maintenance definition could be used to describe the scope
of the maintenance, to define role of the maintenance team, and to recruit staff and
consultants. The ERP maintenance taxonomy and business benefit perspective of
classification can to be utilized by ERP-using organizations to (1) classify maintenance
request more accurately; (2) prioritize maintenance requests based on the importance of the
benefit to the organization’s business objectives; (3) assist in choosing the most appropriate
upgrade version of ERP; (4) facilitate evaluation of costs and benefits associated with
maintenance requests; and (5) facilitate user opportunity costs minimization.
Effort sub-study – The proposed ERP maintenance effort model provides some indications of
drivers of maintenance cost. As a result, these factors could be considered in estimating effort
and cost of a maintenance request, planning for the maintenance budget, and allocating
maintenance staff to maintenance jobs.
9-23
Decision sub-study – The proposed decision framework: (1) provides a more comprehensive
illustration of factors and variables to be considered in making MU decisions; (2) could be
used to plan long-term MU strategy, and control the frequency of upgrades; (3) can be used as
a guideline for ERP managers to evaluate the costs and benefits of difference MU decision
alternatives; and (4) facilitates minimizing the total ERP software lifecycle costs and
maximizing benefit-realization. Further insights from the findings are that ERP-using
organizations should not be myopic by avoiding upgrades, although upgrades seem expensive
in the short-term. Functional upgrades, resulting in additional and enhanced functionality,
could bring more business benefits. Moreover, an upgrade could also save organization’s
future maintenance costs with reductions in the number of modification-enhancements done
in a new system and potential reduction in future patch-maintenance.
Methodology sub-study – Detailed discussion on the benefits of the proposed maintenance
methodology for practice (for examples see ( Abran et al., 1993; Zvegintzov, 1994)has been
provided in Chapter 7, Section 7.5.5. Each of the identified benefits is believed to provide
useful insights and implications for an ERP-using organization. Its benefits are to: (1) provide
a methodology for preparing maintenance and upgrade projects, initiation of requests,
tracking a project’s progress, and closing a project; (2) provide guidelines for modifying
vendor’s code; (3) provide recommendation for tools to support cost and benefit justification
(or decision tools); (4) facilitate maintenance and upgrade projects’ risk minimization; (5)
facilitate identification of best practice for maintenance and upgrade processes in the future;
(6) facilitate management control; (7) provide visibility of maintenance activities; and (8)
provide a communication tool for all parties involved. The overall result, thus, is improved
team productivity.
Data sub-study – The implications of the proposed ERP maintenance-data-model for practice
are drawn from the benefits for practice elaborated in Chapter 8, Section 8.4. ERP
maintenance managers can use the maintenance-data-model as: (1) a repository of
maintenance activities and maintenance knowledge to provide immediate access to all
information past and present – to estimate the ongoing user-enhancement maintenance cost, to
forecast maintenance demands and to enhance the reporting and visibility of maintenance
activity; (2) a maintenance controlling and monitoring system (especially if computerized) –
to monitor maintenance performance and maintenance problems; and (3) support for
maintenance and upgrade decision-making – to make better-informed decisions.
9-24
These implications are illustrated in Figure 9.1, using the case study – CSA – as an example.
It is believed that CSA can benefit from each of the research outputs in the following ways.
The findings (i.e. areas for improvement for CSA) from the ERP taxonomy sub-study, effort
sub-study, decision sub-study, methodology sub-study, and data sub-study can be utilized to
further improve CSA’s existing ERP maintenance methodology.
The proposed maintenance request’s attributes that are:
(1) essential for future maintenance planning or maintenance-demand forecasting (e.g.,
ongoing maintenance cost for user-enhancement, and details about software modification);
and
(2) required for quantifying benefits/user opportunity (e.g., benefit category, business value,
and classifying maintenance requests), can be valuable to be included in CSA’s maintenance-
data-model.
The proposed maintenance taxonomy with business benefit perspective/dimension can be
used to strengthen CSA’s existing ERP maintenance classification, and enhance cost and
benefit justification for maintenance decision. The identified determinants of maintenance
effort could be used to assist in estimating the maintenance effort required in an internally
originated maintenance project. On the other hand, the proposed MU decision framework can
be utilized to evaluate and justify each CSA’s MU decision in the future.
9-25
M ain researchareas in th is
thesis:
B enefits /im plications o fthese findings
to C S A :
Findings: P rojectcharacteristics thathave im pacts onm ain tenance e ffo rt
B enefit perspective o fm ain tenanceclassifica tion
There are room s forim provem ents in :
record ing o f user-enhancem entm ain tenancem anagem ent e ffort(autom ation)quantifica tion o f M Udecis ion
M ain tenance m anagem entm ethodo logyG uide lines fo r m odify ingvendor's codeD ecis ion support too lFacilita te m anagem entcontro lV is ib ility o f m ain tenanceactiv ities.C om m unication too lFacilita tes identifica tion o fbest p ractice fo r M Uprocess in the fu ture
R eposito ry ofm aintenanceactiv ities andm aintenanceknow ledgeP rovide data fo r M Udecision-m aking,and charge-backthe ongo ingm aintenance cost tothe system userForecastm aintenancedem and
Evaluate and justify thebusiness reason fordo ing m ain tenance andupgrade activ ities
Im prove and assist inthe accuracy injustify ing andevaluating E R Pm ain tenance andupgrade activ itiesE ventua lly, it is a im edto m in im ize E R Plifecycle costs
Factors a ffecting E R Pm ain tenance andupgrade decis ionIm pact o f upgrade onexisting m odifica tion-enhancem ents andfu ture patch-m ain tenance
Estim ate m ain tenanceeffortC onta in m ain tenancecost
helps tofurther
im provem aintenance
p lann ing
R ecom m en-dations to
C S A :
use to se lect the respective cost function
utilize toestim ate
m ain tenanceeffort
There are som eother im portantm aintenanceattribu tes that a reusefu l to record
(The p roposed)E R P
M ain tenanceTaxonom y
(The proposed)E R P
M ain tenanceEffort M odel
(The p roposed)E R P M aintenance
and U pgradeDecision
Fram ew ork
(The proposed)E R P
M ain tenance-Data -M ode l
(The proposed)ER P M aintenance
M ethodology
fac ilita te m ain tenance c lassifica tion
facilita te quantifica tion o f benefit o r user opportun ity cost
enhance existing c lassifica tion
use to im prove m ain tenance e ffo rt/cost estim ation
eva luate andjustify M Udecision
E R PM ain tenanceTaxonom y
E R PM aintenance
EffortD eterm inant
E R PM ain tenance-
data -m ode l
ERP M ain tenanceM ethodology
is required toidentify w hich
activ ity issupposed toco llect w hat
data
is required tohave an
apprec ia tion o fthe type of
m ain tenanceactiv ities
is used tohave an
apprec ia tiono f fac torsa ffecting
m ain tenanceeffort
is requ ired tom ake be tte rquality M Udecis ions
is requ ired to p lan fo r m ain tenance resources and sta ffingis requ ired to identify the types o f m ain tenance request
is requ ired fo r m aintenance c lassifica tion
is requ ired to assign a request type to a m aintenance requestD eterm ine the data requ ired fo rrequest c lassifica tion purpose
E R P M aintenanceand U pgrade (M U )
DecisionFram ew ork
Figure 9.1: Suggestions to CSA for improvement
9-26
9.5.3 Implications For ERP-Vendor
Taxonomy sub-study - The proposed ERP maintenance definition and taxonomy show that
vendor’s MU strategies play an important role in their client-organizations maintenance
activities. The definition and taxonomy could be used to improve the vendor’s understanding
of its roles and impacts on ERP-using organizations’ maintenance activities. Vendors may
then take the appropriate action by (1) providing more effective patch-maintenance support
and reducing the frequency of patch introduction, and (2) incorporating more business value
in its new version(s) of the ERP system.
Effort sub-study – The effort determinant(s) could also be applicable to the vendor’s
maintenance effort. This is because the vendor also does similar maintenance activities, for
example corrective and enhancement to the same software with different level of task
complexity. Thus, they can be considered in estimating effort required in maintaining the
same software product.
Decision sub-study – The decision framework can be used to improve the vendors’
understanding of the key drivers influencing clients’ MU decisions. Thus, the vendor could
emphasize the appropriate “variable(s)” (by increasing or decreasing the variables’ values) in
order to achieve their market strategies (e.g., limit their support for a version of the software,
increase sales revenue, and so forth). It provides insight into the impacts of vendor
maintenance strategy on client ERP lifecycle costs. It could be used to encourage clients to
upgrade their installed version and so forth.
Methodology sub-study – The proposed methodology model could be used to further enhance
and extend existing maintenance and upgrade (MU) change management systems. It could be
fully automated and used as a maintenance methodology to help ERP-using organizations
speed-up, plan and prepare for MU activities, particularly for the small- and medium-sized
enterprises (SME) market sector. Note that this is analogous to the objectives of the
accelerated SAP (ASAP) methodology. However, the difference is that while ASAP aims at
(saving time and cost in) SAP implementation, the methodology proposed in this thesis
facilitates the post-implementations activities – i.e. maintenance and upgrade projects.
9-27
Data sub-study – The proposed data-model could be used to reflect whether the proposed
maintenance-data-model is applicable to its environment and revised if there is any attribute
not currently recorded. It can be used to determine useful data to be captured in the change
management system, i.e. the Change and Transport System (CTS), provided by SAP to its
clients to manage and record all details about the changes/maintenance done to the SAP R/3
system.
9.5.4 Implications For ERP Maintenance Consultant
The outputs from this study could be useful in the following ways: (1) a clear definition of
ERP maintenance is helpful to identify the type of knowledge a consultant needs to possess;
(2) the benefit perspective of the taxonomy is particularly useful to show clients the benefits
and potential savings involved in doing an upgrade to an existing version and undertaking
maintenance; (3) the determinants of maintenance effort could be used to estimate
maintenance effort of a maintenance project for a client; (4) the proposed decision framework
could be used as a tool to justify a MU decision for an ERP client; (5) the proposed ERP
maintenance and upgrade (MU) methodology could be used to assist in preparing MU
activities; and (6) the proposed ERP maintenance-data-model could be used to plan and
prepare a maintenance-data-model for an ERP client.
9.6 Future Research
The following section discusses the future research in the areas examined in this research
project.
9.6.1 Taxonomy Sub-study
As discussed in Chapter 4, Section 4.6, the benefit perspective used in classifying
maintenance requests is meant to facilitate identification and quantification of the business
benefit(s) and value(s) for (the relevant) ERP maintenance request(s). Using this, it is
expected that maintenance requests can be prioritized and acted upon in a manner that reduces
the user opportunity costs and therefore total ERP software lifecycle costs. Higher
benefit/opportunity requests would be implemented first so that the benefits could be realized
9-28
earlier. Therefore, it would be worthwhile to test this proposition ( ). This can be
done by having two study groups. The first group consists of ERP-using organizations that
classify and prioritize their maintenance requests based on their own criteria (but have nothing
to do with benefit-related criterion), whereas the second group comprises organizations that
have been given special treatments and will be using the proposed taxonomy to classify and
prioritize maintenance requests. Data related to user opportunity cost associated with each
maintenance request will then be assessed for these two groups. The unit of analysis for this
purpose is the maintenance request.
Figure 9.2
Figure 9.2: Model of ERP maintenance taxonomy and user opportunity cost
- ERP user opportunity
costs
ERP maintenance taxonomy:
benefit perspective
Besides this, for future research, it would be useful to further sub-categorize the main ERP
maintenance categories into more detailed and refined levels. For instance, ERP enhancement
could be further categorized into enhancement involving: (1) system properties belonged to
the vendor; (2) system properties belonging to the ERP client; (3) functionality that can be
implemented within the standard ERP code; (4) functionality that has to be custom-made; (5)
different tailoring options, and so forth. The main objective of this endeavor is to provide a set
of comprehensive and pragmatic guidelines to ERP maintenance managers to make more
accurate estimations of the costs and benefits of maintenance requests. Longitudinal study
would be required to identify whether maintenance patterns or characteristics exist over a time
period that would allow ERP maintenance managers to make predictions and plan for their
future maintenance activities.
9.6.2 Effort Sub-study
In prior studies, variables such as: (1) maintenance personnel – experience and capability,
project management – deadline pressure and manpower loading, user-environment – number
of user organizations, technical-environment – documentation validity and structured
methodology, and code quality (see (Banker et al., 1989; Niessink et al., 1998)); and (2)
human capital – application area knowledge, programming knowledge and domain knowledge
9-29
(Chan, 1997) are found to effect maintenance effort. Research questions that warrant further
research effort are as follows. Are these variables relevant in the context of ERP? Do they
have the same impact on ERP maintenance effort?
9.6.3 Decision Sub-study
Findings from the qualitative data in this sub-study show that the number of modification-
enhancements done to the installed ERP system affects the patch-maintenance effort. This
finding is consistent with existing reports in the trade press. However, there is no hypothesis
testing or empirical test for this. Interesting questions are: How does this factor drive the
patch-maintenance effort? Would the patch-maintenance effort increase linearly with the
number of modification-enhancements (as assumed in the proposed decision framework)? Or
would it be a curvilinear or nonlinear relationship? Similarly, empirical testing is required to
determine how upgrade effort would be influenced by the number of modification-
enhancements done; and how would the future patch-maintenance efforts be affected by an
upgrade (see Figure 9.3). This can be achieved by systematically recording all modification-
enhancements done to an installed version, followed by careful observation and measurement
of any effort increase in each subsequent patch-maintenance. Alternatively, experiment can be
conducted in two different scenarios, i.e. ‘vanilla’ versus heavily customized installed version.
Patch-maintenance will then be implemented and the maintenance effort is then recorded for
comparison and data analysis purpose. This unit of analysis is the modification-enhancement.
-
Future patch-maintenance
effort
+
+ Patch-
maintenance effort
Upgrade effort
Modification-enhancements
9-30
Figure 9.3: Model of modification-enhancements, patch-maintenance and upgrade effort
This framework also poses further questions as follows. How could the user opportunity cost
be evaluated systematically in the ERP MU context and to what extent? How would the
proposed framework be implemented and used to generate solutions (i.e. ERP maintenance
and upgrade policies) for ERP-using organizations, as well as empirically tested and validated
the framework (see (Gass, 1983))? What are the factors driving patch-maintenance efforts,
besides the number of previous modification-enhancements? What are the underlying factors
influencing the reduction-rate in maintenance costs after an upgrade?
9.6.4 Methodology Sub-study
Based on the discussion in Section 7.5.2, it is also worthwhile to empirically test whether: (1)
the effectiveness i.e. the degree in which maintenance objectives are achieved in ERP
maintenance management will be improved by a maintenance methodology (which provides a
methodology for initiation, planning, managing, tracking, executing and monitoring of MU
projects; provides guidelines for modifying vendor's code; facilitates management control and
involvement; and provides visibility of maintenance activities); and (2) the efficiency i.e.
better resource utilization, for example manpower, effort and time in ERP maintenance
management will be improved by a maintenance methodology (which provides
recommendations for tools to support cost and benefit justification or decision tools;
facilitates maintenance and upgrade projects’ risk minimization; facilitates identification of
best practice for maintenance and upgrade processes in the future; and provides a common
communication tool for all parties involved). This is illustrated in Figure 9.4. This can be
done by measuring the effectiveness and efficiency in maintenance management in a number
of ERP-using organizations that will adopt the proposed maintenance methodology. This will
then be compared with the effectiveness and efficiency measures collected (from the same
participating organizations) before the proposed maintenance methodology is administered.
The unit of analysis is the maintenance lifecycle.
9-31
Figure 9.4: Model of ERP maintenance methodology, maintenance management control and
productivity
+
+ Effectiveness in
ERP maintenance management
Efficiency in ERP
maintenance management
ERP maintenance methodology
Besides this, further studies into activities involved in a functional upgrade, and upgrade
activities involving replacing an installed software version with a software from different
vendor would also be interesting.
9.6.5 Data Sub-study
The study proposes an ERP maintenance-data-model that is designed for recording the
essential attributes of a maintenance request, from the point of request initiation to completion
of the maintenance job, with the main objective to improve effectiveness and efficiency in
managing ERP maintenance procedure. However, it would be worthwhile to empirically test
and validate whether a well-defined, i.e. defined maintenance attributes and attributes’
meaning, maintenance-data-model is actually helpful and useful to: (1) retain maintenance
knowledge within an organization, measured by the availability of some fundamental
maintenance attributes; (2) improve management productivity, measured by the ratio of
maintenance request arrival rate to request serviced rate; and (3) reduce the time and cost
involved in making a maintenance decision, measured by the time taken to make the
respective decision. This is because there is always a trade-off between the benefits of a well-
documented maintenance procedure with the relevant maintenance data and the amount of
resources (e.g., time, effort and cost) inputted to the process. Thus, three new hypotheses are
(see Figure 9.5):
A well-defined maintenance-data-model will retain maintenance knowledge within an
organization.
9-32
A well-defined maintenance-data-model will improve management productivity.
A well-defined maintenance-data-model will reduce the time and cost involved in
making a maintenance decision.
This can be done by measuring the amount/availability of relevant maintenance attributes
captured in an organization, time and costs spent in making ERP maintenance and/or upgrade
decision, and so forth in ERP-using organizations that use the proposed ERP maintenance-
data-model versus organizations not using it. The unit of analysis is the maintenance request.
-
+
Time and cost for ERP
maintenance decision-making
ERP maintenance knowledge
retained
+ ERP maintenance productivity
ERP maintenance-data-model
Figure 9.5: Model of ERP maintenance-data-model, maintenance knowledge, productivity and
decision-making
In addition, it would be interesting to identify how the attributes of a ERP maintenance
request differ from those of an upgrade request. What are the fundamental attributes in ERP
software preparation stage? What knowledge is needed and what documentation needs to be
retained in the software system in order to keep an existing ERP system a supported-version
and not difficult to maintain? How do the attributes of user-support requests and change-
requests differ?
9.6.6 The Big Picture
The previous five sections proposed the hypothesis testing research questions with respect to
the perceived and potential benefits the proposed maintenance taxonomy, effort model,
9-33
decision framework, methodology and data-model could bring. In general, all these
hypotheses could be tested using the general ERP maintenance management model as shown
in Figure 9.6. This can be done by conducting a longitudinal study and administering the five
research outcomes from this study to a group of ERP-using organizations (the experiment
group). Observations and data collection on software costs and benefit-realization throughout
the ERP software lifecycle (of the same software) will be conducted in these organizations.
Similarly, same observation and data collection will also be conducted in ERP-using
organizations (the control group) that do not use any of the proposed research outcomes. This
study will involve multiple unit of analysis: maintenance request, maintenance lifecycle, and
maintenance function.
Effective and EfficientManagement
that use the proposed(1) maintenance taxonomy,
(2) effort determinants,(3) decision framework,
(4) maintenance methodology,(5) maintenance-data-model
(Minimize:)ERP software
Costs orTotal Costs of
Ownership
Faciliate(Maximization of:)
BenefitRealization
-
+
Figure 9.6: ERP maintenance management model
Overall, this thesis has investigated the suitability of the in-house software findings, in the
five research areas of interest, in the context of ERP. In brief, in-house software literature is
not appropriate because of the unique characteristics of ERP such as such as business benefit
oriented maintenance requests, and that it is a cross-functional software system that is vendor-
supported, with the software code belonging to the vendor. However, more research effort is
required to explore and examine whether prior commercial off-the-shelfs (COTS) studies are
applicable in the context of ERP.
9.7 Conclusions
To conclude, this thesis has contributed to existing pool of knowledge by identifying the
nature of ERP maintenance and upgrade environment, providing empirical evidence that
9-34
existing literature on in-house software maintenance tools and mechanisms are not sufficient
in the context of ERP, and developing tools mechanism specific for ERP maintenance
environment. They are as follows.
First, it shows that the existing literature is not sufficient in the ERP context, due to
maintenance support and new versions for upgrade being readily available from the vendor,
the software code belonging to the vendor, the likelihood of business benefit oriented
maintenance requests and that ERP is a cross-functional software system. Table 9.5 attempts
to provide alternative explanations for these findings from the in-house software perspective.
Table 9.5: Alternative explanation for research findings
Findings Alternative explanation Existing in-house software maintenance
taxonomies, replacement models,
maintenance methodology and
maintenance-data-model are insufficient
in the ERP context.
Some of the ERP maintenance tools and mechanisms
proposed in this study could be insufficient and/or
irrelevant in the in-house software context.
ERP is not an instance of the in-house
software.
In-house software maintenance is also not an instance
of ERP software maintenance.
No one maintenance tool or mechanism is a perfect fit
for all circumstances, particularly if the nature of a
software environment is largely differed from the
intended environment.
No explicit business benefit
categorization/classification is included in
in-house software maintenance
taxonomies.
Should a business benefit perspective for classifying in-
house software maintenance requests exist, it would
most likely focus on local (vs. global) business unit
benefits. Thus, distinction between in-house and ERP
maintenance benefit will still exist, such that ERP
business benefit is more concentrated on the enterprise-
wide (or global) business benefits.
The author expects that best practice, integrated system
and globalization to be the main business benefit that
differentiate ERP from in-house software.
Second, ERP maintenance is defined as post-implementation activities until the system is
disposed from the production system; targeting at keeping the system running correctly,
operating well in a changed environment and providing user-support, as well as realizing
9-35
more business-benefits and maintaining the installed system a supported version; and
covering both internally and externally originated maintenance requests.
Third, an ERP maintenance taxonomy was developed which characterizes maintenance
requests based on maintenance initiator (who), the existence of business-benefit (why), and
the existence of impact of the maintenance on installed module(s) (what). It facilitates
maintenance requests classification and prioritization, and thus minimizes user opportunity
costs, fix emergency requests quickly, and allow progress tracking and ease of reference to a
request.
Fourth, the characteristics of maintenance projects such as maintenance category and task
complexity have been shown to be significant predictors of ERP maintenance effort.
Conversely, tailoring option variable is refuted as predictor of maintenance effort. The
significant predictors can be used to estimate maintenance effort for a project, and facilitate
decision-making related to maintenance (and upgrade).
Fifth, an ERP maintenance and upgrade decision framework has been developed which
captures the fundamental factors driving the maintenance and upgrade decision, for example
user opportunity and implications of an upgrade. It can be utilized to assist in making better-
informed ERP MU decisions in order to minimize total ERP lifecycle costs and facilitate
better benefit-realization.
Sixth, an ERP maintenance methodology was developed. It defines the basic maintenance and
upgrade activities, fundamental to enhance the effectiveness and efficiencies in maintenance
management.
Seventh, an ERP maintenance-data-model (for the maintenance procedure stage) has been
proposed. The data-model describes the fundamental measurable maintenance attributes for
classifying requests, evaluating maintenance and upgrade decisions, and monitoring
maintenance performance and problems.
The main outcomes from the five sub-studies are important for developing an integrated ERP
maintenance methodology and maintenance system, and are useful for future study in
maintenance workflow planning, management and automation.
9-36
In conclusion, research results implicitly show that in general CSA is learning and improving
its management of ERP maintenance and upgrade activities. There is a lot of research
potential in ERP maintenance. Nevertheless, there is a lot which one can learn from prior
studies in in-house software and COTS literature. However, these literatures are mostly
required some extensions and/or adjustments before applying to an ERP environment.
Although traditionally maintenance is perceived as a boring topic, the author believes that
maintenance in ERP environment will bring different view. This is because in the context of
ERP, maintenance and business activities are interrelated such that they have some similar
and related target(s) – realizing more benefits for the ERP system!
9-37
Appendix A – Glossary
• ABAP/4
It is an abbreviation for Advanced Business Application and Programming. It is the
SAP proprietary 4GL programming language.
• Benefit-realization
Benefit-realization is referred to achieving fuller capabilities and benefits (or business
values) from ERP systems through continuous systems maintenance and upgrade.
• Database (in Chapter 3)
It is the same as archival records or a collection of tables.
• Development system (DEV)
Development system is an archive of an ERP system where it is an offline system and
changes made to it will have no impact on the real-time or production system. It is
where the resolutions or new developments for maintenance requests are first made. It
doesn’t necessarily have a copy of all the production data. Therefore, its data may not
be up-to-date or reflecting the current state of a business transaction.
• Documentation (in Chapter 3)
It refers to reports or documents.
• ERP customization / configuration
Customization or configuration is described as the effort used to parametize or to
configure a generic/industry-specific ERP system using the switches/tables provided
by the vendor in order to personalize the ERP system to support an organization’s
business practices, and requirements.
• ERP enhancement or user-enhancement
It is a part of ERP maintenance activities, which is satisfied either through ERP
customization / configuration or ERP modification. It requires changing or adapting
A-1
the standard setting, code process, procedures, business rules or technical aspects of
the ERP system to meet current system, and users’ requirements and needs.
• ERP maintenance
Post-implementation activities related to the ERP packaged application software
undertaken by the client-organization from the time the system goes live (i.e.
successfully implemented and transported to the production environment) until it is
retired from an organization’s production system. (For interested reader, a detail
definition of ERP maintenance is given in Chapter 4.)
• ERP maintenance and upgrade (MU) decision
ERP maintenance and upgrade decisions refer to identifying the amount of ERP client-
initiated maintenance requests and vendor-introduced patches to implement, and/or the
timing to upgrade an installed ERP system with a readily available version (from the
same vendor).
• ERP maintenance methodology
It is a maintenance model or process used to describe activities covered in: software
maintenance preparation stage, software maintenance procedure stage, and software
upgrade stage.
Maintenance preparation in this study is defined as activities involved in initiating and
planning for software maintenance management issues and maintenance process.
Maintenance procedure describes the sequence of activities involved in organizing,
managing, handling, executing and monitoring a software maintenance request.
Software upgrade explains the activities that take place in replacing an installed ERP
version with a new release/version from the same vendor. However, it does not
include activities involved in replacing an installed ERP version with a custom system
or an ERP system from a different vendor.
• ERP maintenance-data-model
It is a data definition and repository. It defines and captures fundamental details, such
as the measurable attributes and characteristics, of a maintenance request.
Some of the common measurable attributes of a maintenance/change request include:
A-2
timing, request objective, request type, solution method, software components
affected, effect on other software properties, staff involved, maintenance effort,
request benefits, and request costs.
• ERP modification
It is referred to maintenance activities, which result in changes being made to the
existing ERP (standard) code or custom objects being created. This is inclusive of
bolt-on, user exit, writing ERP programming for additional application functionality,
workflow programming, writing user interface, screen or report. It has a major impact
on the effort required to implement future patch-maintenance and upgrades.
• ERP MU
It is ERP maintenance and upgrade.
• ERP upgrade
An ERP upgrade involves replacing an installed ERP version with a newer version
available from a vendor. It could mean a technical or functional upgrade. It may cause
custom code/objects being overwritten after an upgrade. Also, it usually happens more
than once in an ERP software lifecycle.
• ERP upgrade decision
An ERP upgrade decision is about deciding when to replace an installed ERP version
with a newer version available from a vendor. This decision is usually made more than
once in an ERP software lifecycle.
• LCP
It is an abbreviation for Legal Change Patch. It is the patch support provided by the
SAP vendor.
• Modification-enhancement
It is used in this study to refer to any or a combination of the following tailoring
options: user exits, bolt-on, screen masks, extended reporting, workflow
programming, ERP programming, interface development, and package code
A-3
modification.
• Notes
Refer to either a bug fix or a minor enhancement in a patch.
• Production system (PRD)
PRD is the most critical and an online version of the ERP system. It is the system
which users are using for day-to-day operations, conducting traditional business
processing and functions, and which stakeholders use for business transactions.
• Quality assurance system (QAS)
Quality assurance system is also an instance of an ERP system and it is an offline
system. The data in this system is periodically copied from the production system to
keep it up-to-date and it is relatively more recent than in the development system. It is
“almost” an instance of the production system, is used for testing the correctness of
the maintenance resolution and/or integrity of the new development, and conducting
user acceptance tests before the maintenance resolution is delivered to the production
system.
• User-support requests
User-support requests are associated with consulting with and supporting user requests
relating to the system’s behavior, rules and functions. They are different from
corrective, adaptive and perfective because servicing them does not result in any
changes made to the software system.
A-4
Appendix B – Comparison between the IEEE Standard 1219-1998 (IEEE, 1998), and ISO/IEC 12207 (ISO/IEC, 1995) Software Maintenance Methodology
IEEE Maintenance Methodology ISO/IEC Maintenance Methodology Who? Clause Phase or activity involved Clause Activity Who?
A.3 Maintenance planning: 5.5.1 Process implementation: A.3.2 Determine current
maintenance process: To describe the flow of work from receipt of a request to its implementation and delivery.
5.5.1.1,5.5.1.2
Develop plans and procedures for conducting maintenance activities and tasks.
A.3.5 Develop maintenance plan covering the areas of: Maintenance process Organization Resource allocations Performance tracking
5.5.1.3 Implement the configuration management process for managing modifications to the existing system.
Mai
ntai
ner
Mai
nten
ance
man
ager
ial,
tech
nica
l peo
ple A.3.1
A.3.3 A.3.4
Determine maintenance effort: (based on) System age, # and type of changes during life, usefulness of the system, types and # of requests received for changes, quality and timeliness of documentation, existing performance statistics (CPU, disk I/O, etc.) Quantify maintenance effort. Project maintenance requirements.
- -
-
B-1
4.1 Problem modification identification, classification, and prioritization:
5.5.2 Problem and modification analysis:
Use
r, m
aint
enan
ce m
anag
er 4.1.2 (i) Assign ID to the
request. (ii) Classify maintenance
request. (iii) Determine whether to
accept the request. (iv) Preliminary estimate
of the modification size.
(v) Prioritize the maintenance request.
(vii) Schedule for implementation.
5.5.2.1 5.5.2.2
Analyze the impact of the problem report or the modification request on the organization, the existing system and the interfacing system. Classify the problem report or modification request. Determine the scope, size, cost, and time to modify the request. Determine the criticality of the request. Replicate or verify the problem.
Mai
ntai
ner
4.2 Analysis:
4.2.1 Feasibility analysis: (i) Impact of the
modification. (ii) Alternative solution. (iii) Analysis of conversion
requirements. (iv) Safety and security
implications. (v) Human factors. (vi) Short-term and long-
term costs. (vii) Value of the benefit of
making the maintenance.
5.5.2.3 Develop options for implementing the modification.
Syst
em a
naly
st, r
eque
ster
, im
plem
ente
r, us
er
4.2.2
Detailed analysis: (i) Define firm
requirement for the modification.
(ii) Identify the element to be modified.
(iii) Identify safety and security issues.
(iv) Devise a test strategy. (v) Develop an
implementation plan.
5.5.2.4 5.5.2.5
Document the request, analysis results, and implementation options. Obtain approval for the selected modification option.
Mai
ntai
ner
B-2
4.3 Design: 5.5.3 Modification implementation:
Engi
neer
ing
staf
f, so
ftwar
e de
sign
er
4.3.2 (i) Identify affected module.
(ii) Modify software module documentation.
(iii) Create test cases for the new design, including safety and security issues.
(iv) Create regression test.
(v) Identify documentation to be updated.
(vi) Update modification list.
5.5.3.1 Conduct analysis. Document or update the related documentation, software units, and versions needing to be modified.
4.4 Implement:
Req
uest
er, s
oftw
are
engi
neer
, dom
ain
expe
rt,
softw
are
deve
lope
r, pr
ojec
t man
ager
4.4.2.1 4.4.2.2 4.4.2.3 4.4.2.4
Coding and unit testing. Integrate the modified software with the system, and perform integration and regression test. Identify any unacceptable impacts. Risk analysis: (i) Detect software
defects, which can cause software failure.
(ii) Quantify the potential loss due to failure.
Test-readiness review to assess preparedness for system test.
5.5.3.2 Part of Clause 5.3 – development process: Software coding and testing, software integration, software qualification testing, system integration, system qualification testing, and software installation. Define and document the test and evaluation criteria for testing and evaluating the modified and unmodified parts of the system. Ensure correct implementation of the modified requirements, and that unmodified requirements were not affected.
Mai
ntai
ner
4.5, 4.6, 4.7
System test, Acceptance test, Delivery
5.5.4 Maintenance review and acceptance:
4.5 System test:
Test
per
sonn
el
4.5.2 System functional test. Interface test. Regression test. Test-readiness review to assess preparedness for acceptance test.
5.5.4.1 5.5.4.2
Conduct review(s) with the modification authorizer’s organization to determine the integrity of the modified system. Obtain approval for the satisfactory completion of the modification as specified.
Mai
ntai
ner,
requ
esto
r(s)
B-3
Acceptance test: U
ser,
deve
lope
r
4.6 Perform acceptance tests at the functional level. Perform interoperability testing. Perform regression test.
4.7 Delivery: 5.5.5 Migration:
Proj
ect m
anag
er, t
rain
ers
Conduct a physical configuration audit (PCA). Notify the user community. Develop an archival version of the system for backup. Perform installation and training at custom site.
5.5.5.1 5.5.5.2 5.5.5.3 5.5.5.4 5.5.5.5 5.5.5.6 5.5.5.7
Migrate system or software product (including data) from an old to a new operational environment in accordance with this international standard. Develop, document, and execute a migration plan. Notify users of the migration plans. Parallel operations of the old and new environment may be conducted. Provide the necessary training. Notify the relevant parties of the migration schedule. Archive all associated old environment’s documentation, logs, and code. Conduct post-operation review to assess the impact of the changing to the new environment. Archive the data used by or associated with the old environment.
Mai
ntai
ner
A.13 Software replacement policy a
5.5.6 Software retirement:
- - 5.5.6.1 5.5.6.2 5.5.6.3 5.5.6.4 5.5.6.5
Develop retirement plan. Notify users of the retirement plans and activities. Parallel operation of the retiring and new software product. Provide user training. Notify those involved in the retirement schedule. Keep an archive of the associated development documentation, logs, and code. Archive the data used or associated by the retired software product.
Mai
nten
ance
man
ager
, use
rs
B-4
Mai
nten
ance
man
ager
A.13 Software replacement
policy: (determined by) System outages or failure rate Code > n years old Complex system structure or logic New hardware Excessive resource requirements Missing or deficient documentation or design specifications
- - -
a Although A.13 and 5.5.6 are meant for the same purpose, i.e. planning for software replacement, different emphasis is applied in the two standards.
B-5
Appendix C – Case Protocol
C.1 Project Objectives This study discovers and describes the nature of ERP maintenance and upgrade activities, and
proposes appropriate mechanisms and methodology for effective maintenance management in
the context of ERP. This research is an exploratory, descriptive, revelatory and collaborative
case study. It seeks to generate both research outcomes and applied outcomes for the industry
partners (i.e. vendor – SAP, its clients – ERP-using organizations, and consultants). The main
focus of this study is ERP maintenance and upgrade activities of ERP-using organizations.
The case protocol used in this study is given in Table C.1.
C-1
Table C.1: Case protocol – an overview
Sub-study
Taxonomy Effort Decision Methodology Data
Objective Determine whether in-
house software
maintenance
taxonomies suffice in the
context of ERP.
Identify the nature of
ERP maintenance, and
dimensions for
classifying ERP
maintenance requests.
Propose an ERP
maintenance taxonomy
Examine project
characteristics affecting
ERP maintenance
effort.
Develop an ERP
maintenance effort
model
Investigate whether
existing replacement
models are adequate in
the context of ERP.
Factors affecting ERP
maintenance and
upgrade (MU)
decisions.
Develop an ERP MU
decision framework.
Determine whether the
existing standard for
software maintenance
methodology is sufficient.
Investigate activities
involved in ERP
maintenance preparation,
maintenance procedure
and software upgrade.
Develop an ERP
maintenance
methodology.
Determine whether the
existing the software
maintenance-data-model
is adequate in the context
of ERP.
Identify fundamental
measurable ERP
maintenance request’s
attributes.
Develop an ERP
maintenance-data-model.
Issues What is ERP
maintenance?
What attributes of
maintenance effort are
captured by the case
firm?
What are the factors
that should be
considered in making
ERP maintenance and
upgrade decisions?
What activities and tasks
should be incorporated
and reflected into an ERP
maintenance
methodology?
What are the important
ERP maintenance request
attributes that should be
captured in an ERP
environment?
Relevant
readings
(Swanson, 1976; Chapin
et al., 2001)
(Jørgensen, 1995;
Kemerer et al., 1997;
Niessink et al., 1998)
(Gupta et al., 1988;
Gode et al., 1990;
Chan et al., 1996)
(IEEE, 1998; IEEE/EIA,
1997; ISO/IEC, 1995)
(Florac, 1992)
C-2
C.2 Field Procedures And Case Study Questions
This project is conducted at Corporate Services Agency (CSA) – a Government organization in
the Queensland State in Australia. This agency had several years of experience in maintaining its
ERP system and was selected for several reasons: (1) CSA’s comprehensive ERP maintenance
records; (2) the Information Systems Management Research Group’s (ISMRG) strong
relationship and involvement with State Government in collaborative research; and (3) the
ISMRG’s ongoing, existing collaborative projects with CSA. The details on field procedures and
case study questions are given in Table C.2.
C-3
Table C.2: Case Protocol – field procedures and case study questions
Sub-study
Taxonomy Effort Decision Methodology Data
Sub-study
questions
What is ERP
maintenance?
What activities
comprise ERP
maintenance?
How can ERP
maintenance
activities be usefully
classified?
What are useful
dimensions for
classifying ERP
maintenance
activities?
Are the existing
maintenance
classifications
appropriate?
What attributes of
maintenance effort
are captured by an
ERP-using
organization?
Which of these
attributes are useful
predictors of
maintenance effort?
How can
maintenance effort be
measured?
What are the factors that
should be considered in
making ERP maintenance and
upgrade decisions?
What are the major factors
influencing ERP patch-
maintenance, and upgrade
costs?
What are the opportunity cost
for not doing ERP
maintenance and upgrade?
Are these factors that should
be considered in the ERP
context already sufficiently
captured in the existing in-
house software replacement
models?
How could these factors be
included into software
maintenance and upgrade
cost functions?
What activities and
tasks should be
incorporated and
reflected in an ERP
maintenance
methodology?
What are the activities
associated with an ERP
maintenance
methodology?
Are the existing
software maintenance
methodologies
appropriate in the
context of ERP?
What are the activities
and tasks that are
unique to ERP
maintenance
environment?
What are the important
ERP maintenance
request attributes that
should be captured in
an ERP maintenance
management
environment?
Do the attributes
captured in in-house
software environment
sufficient in the context
of ERP?
What are the unique
ERP maintenance
attributes?
C-4
Sub-study
Taxonomy Effort Decision Methodology Data
Primary
Data
Source(s)
Interview, change-
request database,
user-support
database
Interview, change-
request database
Interview, change-request
database, patch-support
database, modification
database, documentation
Interview, change-
request database,
documentation
Interview,
maintenance-request
forms, change-request
database
Data
analysis
method
Pattern matching,
Descriptive statistics,
Comparing the data
with the in-house
software
Pattern matching,
Descriptive statistics,
Regression analysis
Pattern matching, Descriptive
statistics, Comparing the data
with the in-house software,
Mathematical modeling
Pattern matching,
Comparing the data
with the in-house
software
Pattern matching,
Comparing the data
with the in-house
software
Main
Deliverable
Maintenance Taxonomy
Maintenance Effort Model
Maintenance and Upgrade Decision Framework
Maintenance Methodology
Maintenance-Data-Model
C-5
C.3 A Guide For The Case Study Report The format for the narrative in each sub-study is as shown in Table C.1. Table C.1: Guide for the case study report
Main step Step
Research
problem
1. The objectives and research questions of a sub-study are defined. (These are also defined in Chapter 1.)
Literature
review
2. Literature review is conducted, but this has already described in Chapter 2.
Data
collection and
data analysis
procedures
3. Multiple sources of evidence (or chain of evidence) pointing to the same inquiries or related to a sub-study topic are
consolidated. The data analysis procedure for a sub-study is discussed. But, this section is mostly done in Chapter 3.
4. Relevant research findings from other (earlier) sub-study(s), which serve as input to a sub-study, are described.
Data analysis
and
interpretation
5. Case description method is used in synthesizing the descriptions, explanations and interpretations of the case firm’s
maintenance environment and activities; and for quantitative data, basic descriptive statistics and/or regression analysis are
conducted.
6. The synthesized information and knowledge about the case firm’s maintenance environment (i.e. maintenance taxonomy,
maintenance effort, maintenance and upgrade decision, maintenance methodology, and data-model) is analyzed and
compared with the findings in the prior studies and trade literature (whenever available and applicable), using pattern-
matching technique.
Findings and
discussion
7. If the existing literature is found to be insufficient, an improved maintenance taxonomy, effort model, maintenance and
upgrade decision framework, maintenance methodology, or maintenance-data-model is developed based on what has been
C-6
learnt from the (ERP) case firm, and the prior literature on in-house software; and/or recommendations that are supported by
other relevant literature in similar contexts.
Conclusion
and summary
8. Conclusions and summaries are made by discussing the following issues:
a. Why new maintenance mechanism or methodology for ERP maintenance and upgrade is needed?
b. Why the proposed maintenance mechanism or methodology is new?
9. Generalizations and implications of the research findings are discussed in Chapter 9.
C-7
Appendix D – Case Study’s Database
There are seven sources of data collection sources: semi-structured interviews, the change-
request database, user-support database, patch-support database, SAP system modification
database, documentation – Upgrade Business Case and SAP R/3 Upgrade Planning Resources,
and maintenance request forms.
D.1 Semi-structured interviews
D.1.1 Interviewees:
The interviewees (participants) in this study, from CSA, were: the General Manager, Systems
Development Manager, Systems Operations Manager, and Business Analyst.
The General Manager – is in charge of executive matters in CSA. He sets up the organization’s
business objectives, rules and the general administration policies, determines future directions of
the organization, and makes strategic decisions.
The main responsibility of the Systems Development Manager – is the development (i.e. bug
fixes, and enhancement) of the SAP system. He approves maintenance requests, provides
quotations for user-enhancement requests, prioritizes maintenance requests, assigns or allocates
maintenance jobs to his staff, plans for future upgrades, and keeps track of all the change-
requests.
The Systems Operations Manager – is responsible for ensuring the continuing operation of the
system, monitoring system administration, and liaising with the service bureau that provides
facility management support. He also monitors the SAP system performance and system usage by
different clients; is in charge of the provision of user support to the system users; gives advice on
the security issues of the SAP system; and approves maintenance requests.
D-1
On the other hand, the Business Analyst (in this case) – is responsible for investigating and
monitoring maintenance support—often called patches—provided by the vendor; searching for
bug fixes for corrective maintenance requests in the Online Support System (OSS) notes;
determining whether a maintenance request qualifies as a change-request; and designing
maintenance resolutions for maintenance requests.
D.1.2 Interview process and interview questions:
The interview process was two stages.
1. The initial stage was designed as an “introductory” interview. These interviews were
unstructured and conducted during the very early stage of the study. The purpose of this first
stage was to gather background information about the organization and its ERP maintenance
activities. This included the business nature, types of maintenance activities, and the people
involved and responsible for the maintenance. The three sessions of “introductory” interview
were conducted and the total time spent was about five hours.
Some of the questions asked in the introductory interviews were:
• What are the types of ERP maintenance activities performed in your organization?
• Who is the main group of maintenance initiator and what are the objectives of the
maintenance requests?
• Who is responsible and involved in planning, managing, monitoring and executing
ERP maintenance activities?
• What is the distribution of effort on work related to ERP maintenance?
All of the interviews were either tape-recorded and/or written down as notes. The tapes were
transcribed and notes were elaborated immediate after each interview. Within a week the
transcript was sent to the interviewee at CSA in order to counter-check the interpretation and
validate the content of the interview.
2. With sufficient information gathered from the preliminary interviews, the second-stage of
“detailed” interviews began. At this stage the interviews were conducted in a semi-structured
way. The main purposes of these interviews were:
D-2
• To determine the reasons for doing each category of maintenance requests (objective: to
contrast existing in-house software maintenance taxonomies, and propose an ERP
maintenance taxonomy).
• To identify factors affecting the ERP maintenance effort (objective: to determine if the
factors replicate those for in-house software, and verify the empirical results on ERP
maintenance-effort determinants).
• To discuss factors influencing and driving ERP maintenance and upgrade decisions
(objective: to identify whether they are distinct from those for an in-house software
environment, and develop an ERP maintenance and upgrade decision framework).
• To get a better understanding of ERP maintenance and upgrade activities and current
practices in maintenance management (objective: to compare results with the in-house
software findings, and develop an ERP maintenance methodology).
• To confirm the objectives and meaning of each data attribute found in CSA’s change-
request database (objective: to make comparison with the in-house software findings, and
propose an ERP maintenance-data-model).
Four sessions of interview were conducted and the total interview time was approximately eight
hours. Some of the interview questions were as follows.
• What are the activities involved in processing a change-request (corrective,
enhancement), and user-support request? Do you have any strategy in managing your
ERP change-requests?
• How does the process of maintaining a bug in the custom code differ from that for a bug
found in the vendor’s code?
• Do you need to re-apply the prior modifications after the implementation of a patch, and
an upgrade to a new version of ERP?
• Is maintaining a patch (introduced by the vendor) different from maintaining a change-
request (initiated by your system users or IT-staff)?
• How does skipping some of the earlier patches impact on your subsequent
implementation of the later patches?
• Do you perform any system analysis and programming for the implementation of LCP
from the vendor?
D-3
• How do you know that an LCP is available for a request?
• How do you know when the vendor introduces a new patch/LCP?
• What factors do you take into consideration when making maintenance decision (for
patch and change-request)?
• Why do you maintain your ERP system?
• What is the impact of each of your maintenance activities on the SAP standard code?
• What are the activities involved in an upgrade process?
• What constitutes a huge ERP upgrade cost?
• What is your organization’s ERP upgrade strategy/policy?
• What are the factors driving the upgrade decision?
• Do you adopt any standard software maintenance methodology in your (ERP)
maintenance practice?
• Do you adopt any framework or standard for recording maintenance problems and
defects (such as the one proposed by Software Engineering Institute (SEI))?
• Are you happy with your existing maintenance-data-model?
Similar to the “introductory” interviews, all interviews conducted at this stage were tape-
recorded, and then transcribed and later verified by CSA.
D.2 Change-Request Database
The change-request database consists of five tables. They are: Change-request table, Timesheet
table, Personnel table, Company table, and Work Type table. The Change-request table contains
all the details on the maintenance change-requests inclusive of both completed and in-progress
maintenance requests/projects. This table has secondary keys pointing to the remaining four
tables. At the time of data collection, it contained a total of 1616 data points or maintenance
requests, which had been documented between 2 Nov 1998 and 27 June 2000. This database
consists of enhancement requests, corrective requests and patch-maintenance. The Timesheet
table comprises records of each individual staff member participating in any of the maintenance
projects (as recorded in the change-request database), and the time spent on the projects. On the
D-4
other hand, the Personnel table contains personnel details. While the Company table describes
CSA’s clients (who are basically government departments), the Work Type table defines the
types of maintenance performed at CSA for its clients (i.e. the government departments).
The data from this source was used to examine the types of ERP maintenance requests, what was
modified and the activities involved in resolving the problem; to compute the time spent on each
category of maintenance requests, and conduct empirical data analysis for ERP maintenance-
effort determinants; to determine factors influencing maintenance cost; to verify some of the ERP
maintenance activities, to identify participants in the project, and to have an idea of the activities
or tasks which occurred and other related information collected along the maintenance procedure;
and to identify the essential (ERP) maintenance request’s data captured by the case study.
D.3 User-Support Database This database contains requests pertaining to user-support on the CSA’s SAP system; it captures
information on the types of user-support request, support problem description, and details of the
requestors and maintainers. This data source was studied to identify the objectives or the reasons
for requesting and doing the user-support requests. The data fields of interest in this database
were request-date, and request-description.
D.4 Patch-Support Database Unlike the change-request database and user-support database that record maintenance requests
initiated by system users and IT-staff, the patch-support database is a repository, where all the
patches from the (R/3 system’s) vendor are stored. It is connected to the Online Service System
(OSS) from CSA’s R/3 system. It is controlled by an application (from SAP) called SAP Patch
Manager (SPAM), which allows the downloading and application of patches within an R/3
system. The data from this source was used to examine the frequency of patch introduction for a
number of SAP R/3 versions over a time period; and investigate whether a new version would
have a positive impact on (minimizing) the number of future (patch) maintenance requests. The
D-5
specific data fields considered in this study are version-number, patch-number, and number-of-
notes.
D.5 SAP System Modification Database This database was developed by a consultant firm, appointed by CSA to investigate the number
of modification-enhancements done to CSA’s (then) SAP R/3 system; to determine the
modification-enhancements that have require re-application; and to estimate the amount of effort
needed to reapply previous modifications in the whole upgrade process. This data source is useful
for studying the implications and impacts of an upgrade on current and future maintenance, user
opportunity and upgrade cost (to develop the ERP maintenance and upgrade decision framework,
in Chapter 6). The essential data fields used in this study were existing-enhancement,
enhancement-required, and estimated-effort-to-reapply.
D.6 Documentation The documentation collected from CSA was Upgrade Business Case and SAP R/3 Upgrade
Planning Resources. This documentation contains details on the preparation and activities for the
ERP upgrade, factors affecting upgrade decisions, expected benefit from the upgrade exercise,
and new functionality found in the latest versions. They were utilized in this study to verify the
factors influencing ERP maintenance and upgrade decisions, and to facilitate formulation of the
relationships among the variables involved; and to determine activities and procedures involved
in upgrade preparation and execution, issues resolved during the process, and the responsibilities
of each party participating in the upgrade exercise.
D.7 Maintenance Request Forms
Maintenance request forms (the system-investigation form and SAP-transport-request form) are
used by CSA to record details (or attributes) of a change-request from the moment it is
D-6
introduced, by the system users or IT-staff, until it is completed and delivered to the system
users; as well as information on who approves the delivery of the change-request and which
system(s) the resolution is delivered to, why and what is involved. Each change-request requires
a separate system-investigation form and a SAP-transport-request form. These forms are the
“information backbone” of CSA’s whole maintenance execution. Although most of the attributes
on these forms are also recorded in the change-request database (discussed earlier), some of the
maintenance attributes on the forms are not. Data from this source (i.e. forms) was used to
identify essential maintenance request’s attributes captured in CSA’s ERP maintenance-data-
model (objective: to identify whether they differ from those found in in-house software
environments).
D-7
Bibliography
400-Group "Boston Beer Co. Minimizes Coding Changes, Foregoes to Keep SAP
Running Smoothly," in: I/S Analyzer, 1998a, p. 13-15.
400-Group "Mitsubishi Electric Outlaws Internal SAP Customization Endeavors After
Struggling Early," in: I/S Analyzer, 1998, p. 2-6.
Abran, A., and Nguyenkim, H. "Analysis of Maintenance Work Categories Through
Measurement," Conference on Software Maintenance, IEEE Computer Society:
Los Alamitos CA, Sorrento, Italy, 1991, p. 104-113.
Abran, A., and Nguyenkim, H. "Measurement of the Maintenance Process from a
Demand-based Perspective," Journal of Software Maintenance: Research and
Practice (5) 1993, p. 63-90.
Albrecht, A.J., and Gaffney JR., J.E. "Software Function, Source Lines of Code, and
Development Effort Prediction: A Software Science Validation," IEEE
Transactions on Software Engineering (9:6) 1983, p. 639-648.
AMR "AMR Research Predicts Enterprise Applications Market Will Reach $70 Billion
by 2006," AMR Research, 2002a.
AMR "AMR Research Report Evaluates the Costs, Challenges, and Added Benefits of
ERP Upgrades," AMR Research, 2002b.
ASAP World Consultancy, and Blain, J. Using SAP R/3, (Special ed.) Que, Indianapolis,
IN, 1996, p. 1138.
Bancroft, N.H., Seip, H., and Sprengel, A. Implementing SAP R/3, (2nd ed.) Manning
Publications, Greenwich, CT, 1998, p. 310.
Banker, R.D., and Kemerer, C.F. "Factors Affecting Software Maintenance Productivity:
an exploratory study," The Eighth International Conference on Information
Systems, International Conference on Information Systems: New York NY, 1987,
p. 160-175.
Banker, R.D., and Slaughter, S. "Project Size and Software Maintenance Productivity:
Empirical Evidence on Economies of Scale in Software Maintenance,"
International Conference on Information System, 1994, p. 279-289.
Bib-1
Banker, R.D., Datar, S.M., and Kemerer, C.F. "A Model to Evaluate Variables Impacting
the Producitvity of Software Maintenance Projects," Management Science (37:1)
1991, p. 1-18.
Banker, R.D., Datar, S.M., and Zweig, D. "Software Complexity and Maintainability,"
International Conference on Information Systems, International Conference on
Information Systems: New York NY, Boston, USA, 1989, p. 247-255.
Banker, R.D., Datar, S.M., Kemerer, C.F., and Zweig, D. "Software Complexity and
Maintenance Costs," Communications of the ACM (36:11) 1993, p. 81-94.
Banker, R.D., Davis, G.B., and Slaughter, S.A. "Software Development Practices,
Software Complexity, and Software Maintenance Performance: A Field Study,"
Management Science (44:4) 1998, p. 433-450.
Barnes, M. "Customization of ERP Apps Requires Development Skills," in:
InformationWeek, 1999, p. 9A-9D.
Benbasat, I., Goldstein, D.K., and Mead, M. "The Case Research Strategy in Studies of
Information Systems," MIS Quarterly (11:3) 1987, p. 369-386.
Bennett, C., and Timbrell, G. "Application Service Providers: Will They Succeed?"
Information Systems Frontiers (2:2) 2000, p. 195-211.
Bergland, G.D. "Structured Design Methodologies," in: Tutorial: Software Design
Strategies, G.D. Bergland and R.D. Gordon (eds.), IEEE Computer Society, Los
Angeles, CA, 1981, p. 475-493.
Beynon, M. "DS/AHP Method: A Mathematical Analysis, Including an Understanding of
Uncertainty," European Journal of Operational Research (140) 2002, p. 148-164.
Bingi, P., Sharma, M.K., and Godla, J.K. "Critical Issues Affecting an ERP
Implementation," Information Systems Management (16:5) 1999, p. 7-14.
Boulanger, D. "Smaller Companies Likely to Miss Euro Deadline, and Larger Partners
Will Suffer," AMR Research, 2001.
Brand, H. SAP R/3 Iimplementation with ASAP: The Official SAP Guide SYBEX, San
Francisco, Calif., 1999, p. 591.
Brehm, L., Heinzl, A., and Markus, M.L. "Tailoring ERP Systems: A Spectrum of
Choices and Their Implications," 34th Hawaii International Conference on Systems
Bib-2
Sciences, IEEE Computer Society: Los Alamitos, CA, Hawaii, USA, 2001, p. on
CD.
Brooks, F.P. The Mythical Man-Month: Essays on Software Engineering Addison-
Wesley, Reading, MA, 1979, p. 195.
Brotbeck, G., Miller, t., and Statz, J. "A Survey of Current Best Practices and Utilization
of Standards in the Public and Private Sectors," TeraQuest Metrics, Inc., 1999.
(http://www.dir.state.tx.us/eod/qa/bestprac.htm)
Brown, C., and Vessey, I. "ERP Implementation Approaches: Toward A Contingency
Framework," International Conference on Information Systems, International
Conference on Information Systems: New York NY, Charlotte, USA, 1999, p. 411-
416.
Bryman, A., and Cramer, D. Quantitative Data Analysis with SPSS Release 10 for
Windows: A Guide for Social Scientists Taylor & Francis, Hove, England, 2001, p.
295.
Burch, E., and Kung, H.J. "Modeling Software Maintenance Requests," International
Conference on Software Maintenance, IEEE Computer Society: Los Alamitos CA,
Bari, Italy, 1997, p. 40-47.
Burch, J.G., and Grupe, F.H. "Improved Software Maintenance Management,"
Information Systems Management (10:1) 1993, p. 24-33.
Butler, J. "Risk Management Skills Needed in a Packaged Software Environment," in:
Enterprise Systems Integration, J.M. Myerson (ed.), Auerbach, Boca Raton, FL,
2001, p. 439-448.
Butler, J. "Risk Management Skills Needed in a Packaged Software Environment,"
Information System Management (16:5) 1999, p 15.
Callaway, E. ERP - The Next Generation: ERP is Web Enabled for E-Business, (1st ed.)
Computer Technology Research Corp., Charleston, 2000, p. 166.
Carlino, J., and Kelly, J. "AMR Reseacrh Unveils Report on Enterprise Application
Spending and Penetration," AMR Research, 1999a.
Carlino, J., and Kelly, J. "AMR Research Announces Evolution of ERP to Network
Business Systems (NBS)," AMR Research, 1999b.
Bib-3
Carlino, J., Nelson, S., and Smith, N. "AMR Research Study Reveals SAP R/3 Upgrade
Cost Users 25-to 33 Percent-of Initial Investment," AMR Research, 2000.
Carney, D., Hissam, S.A., and Plakosh, D. "Complex COTS-based Software System:
Practical Steps for Their Maintenance," Journal of Software Maintenance:
Research and Practice (12:6) 2000, p. 357-376.
Chan, T. "Three Essays on the Economics of Software Maintenance," Department of
Information Systems and Computer Science, National University of Singapore,
Singapore, 1997, p. 175.
Chan, T., Chung, S.L., and Ho, T.H. "An Economic Model to Estimate Software
Rewriting and Replacement Times," IEEE Transactions on Software Engineering
(22) 1996, p. 580-598.
Chan, T., Chung, S.L., and Ho, T.H. "Timing for Software Replacement," 15th
International Conference of Information Systems, International Conference on
Information Systems: New York NY, 1994, p. 291-307.
Chapin, N., Hale, J.E., Khan, K.M., Ramil, J.F., and Tan, W.-G. "Types of Software
Evolution and Software Maintenance," Journal of Software Maintenance and
Evolution: Research and Practice (13) 2001, p. 3-30.
Clark, B. "Eight Secrets of Software Measurement," IEEE Software (September/October)
2002, p. 12-14.
Clemons, C. "Successful Implementation of an Enterprise System: A Case Study,"
Americas Conference on Information Systems, Association for Information
Systems: Atlanta, GA (on CD), Baltimore, Maryland, 1998, p. 109-191.
Coakes, S.J. SPSS: Analysis Without Anguish: Version 7.0, 7.5, 8.0 for Windows
Jacaranda Wiley, Brisbane, 1999, p. 283.
Collins, K. "Strategy and Execution of ERP Upgrades," Government Finance Review
(15:4) 1999, p. 43-47.
Craig, R. "Laurier Enterprise System Upgrade," International Conference of Information
Systems, International Conference on Information Systems: New York NY,
Charlotte, USA, 1999, p. 654-662.
Davenport, T.H. "In Search of ERP Paybacks," in: Computerworld, 2000, p. 42.
Bib-4
Davenport, T.H. "Putting the Enterprise into the Enterprise System," in: Harvard
Business Review: On the Business Value of IT, Harvard Business School Press,
Boston, 1999, p. 159-185.
Davenport, T.H. "The Future of Enterprise System-Enabled Organizations," Information
Systems Frontiers (2:2) 2000a, p. 163-180.
Davenport, T.H., and Short, J. "The New Industrial Engineering: Information Technology
and Business Process Redesign," Sloan Management Review (31:4) 1990, p. 11-27.
Davenport, T.H., Harris, J.G., and Cantrell, S. "The Return of Enterprise Solutions: The
Director's Cut," Accenture Institute for Strategic Change, Cambridge, MA, 2002,
p. 1-53.
Davenport, T.H. "A "Bifocal" Approach to Enterprise Solutions," Accenture Institute for
Strategic Change, Cambridge, MA, 2002, p. 1-4.
Davis, G.B. "Information Systems To Buy, Build, or Customize?" Accounting Horizon
(March) 1988, p. 101-103.
Davis, J. "Scooping Up Vanilla ERP," InfoWorld, 1998.
Dekleva, S.M. "The Influence of the Information Systems Development Approach on
Maintenance," MIS Quarterly (16:3) 1992, p. 355-372.
Deloitte-Touche-Tohmatsu "ERP's Second Wave - Maximizing the Value of ERP
Enabled Processes (Part 1)," Deloitte Touche Tohmatsu, 1999a.
Deloitte-Touche-Tohmatsu "ERP's Second Wave - Maximizing the Value of ERP-
Enabled Processes (Part 2)," Deloitte-Touche-Tohmatsu, 1999b.
Dhillon, G. "Interpreting Key Issues in IS/UT Benefits Management," Hawaii
International Conference on System Sciences: on CD, IEEE Computer Society: Los
Alamitos, CA, Hawaii, 2000.
Dunn, A. "Competitive Edge," in: SAP INFO, SAP AG, 2003, p. 74-75.
Farley, G.A. "Defining Enterprise Resource Planning," APICS, 2000.
Fenton, N.E. Software Metrics: A Rigorous Approach Chapman & Hall, London, 1991, p.
337.
Fenton, N.E., and Pfleeger, S.L. Software Metrics: A Rigorous & Practical Approach,
(2nd ed.) PWS Publishing Company, Boston, MA, 1997, p. 638.
Bib-5
Fenton, N.E., Krause, P., and Neil, M. "Software Measurement: Uncertainty and Causal
Modeling," IEEE Software (July/August) 2002, p. 116-122.
Ferguson, J., and Sheard, S. "Leveraging Your CMM Efforts for IEEE/EIA 12207," IEEE
Software (September/October) 1998, p. 23-28.
Florac, W.A. "Software Quality Measurement: A Framework for Counting Problems and
Defects," CMU/SEI-92-TR-22, Software Engineering Institute (SEI), Carnegie
Mellon University, Pittsburgh, Pennsylvania, 1992, p. 75.
Fontana, J. "Breaking the ERP barrier," Internetweek, 1998, p. 19.
Forman, E.H., and Gass, S.I. "The Analytic Hierarchy Process - An Exposition,"
Operations Research (49:4), July-August 2001, p. 469-486.
Freedman, R. "ERP Beyond Y2K," in: PC Magazine, 1999, p. 219.
Gable, G., Heever, R.V.D., Scott, J., and Erlank, S. "Large Packaged Software: The Need
for Research," Third Pacific Asia Conference on Information Systems, Association
for Information Systems: Brisbane, Australia, Brisbane, Australia, 1997, p. 381-
388.
Gable, G.G. "Integrating Case Study and Survey Research Methods: An Example in
Information Systems," European Journal of Information Systems (3:2) 1994, p.
112-126.
Gable, G.G. "Large Package Software: A Neglected Technology?" Journal of Global
Information management (6:3) 1998, p. 3-4.
Gable, G.G., Scott, J.E., and Davenport, T.D. "Coorperative ERP Life-cycle Knowledge
Management," Ninth Australasian Conference on Information Systems,
Australasian Conference on Information Systems: Sydney, Australia, Sydney,
Australia, 1998, p. 227-240.
Gass, S.I. "Decision-aiding Models: Validation, Assessment, and Related Issues for
Policy Analysis," Operations Research (31) 1983, p. 603-631.
Gibson, N., Holland, C.P., and Light, B. "Enterprise Resource Planning: A Business
Approach to Systems Development," Hawaii International Conference on System
Sciences, IEEE Computer Society: Los Alamitos, CA, Hawaii, USA, 1999.
Gibson, V.R., and Senn, J.A. "System Structure and Software Maintenance
Performance," Communications of the ACM (32:3) 1989, p. 347-358.
Bib-6
Girard, K. "Back-office Rebirth," Business 2.0, 2000.
Glass, R.L. "Enterprise Resource Planning - Breakthrough and/or Term Problem?," The
Data Base for Advances in Information Systems (29:2) 1998, p. 14-16.
Glass, R.L. "The Re-Engineering Decision: Lessons from the Best of Practice," in: The
Software Practitioner, 1991, p. 5-7.
Glass, R.L. Facts and Fallacies of Software Engineering, (1st ed.) Addison Wesley
Professional, Boston, MA, 2003, p. 195.
Glass, R.L., and Vessey, I. "Enterprise Resource Planning Systems: Can They Handle
the Enhancement Changes Most Enterprises Require?" in: The Software
Practitioner, 1999, p. 1-12.
Glass, R.L. "Predicting Future Maintenance Cost, and How We're Doing It Wrong,"
IEEE Software, 2002, p. 112-113.
Glover, S.M., Prawitt, D.F., and Romney, M.B. "Implementing ERP," Internal Auditor
(61:1) 1999, p. 40-45.
Gode, D.K., Barua, A., and Mukhopadhyay, T. "On the economics of the software
replacement problem," The Eleventh International Conference on Information
Systems, International Conference on Information Systems: New York NY, 1990,
p. 159-170.
Gray, L. "ERP: Decisions, decisions," in: PC Week, 1998a, p. 6.
Gray, L. "Oracle Overhauls ERP Architecture," PC Week, 1998b.
Greenbaum, J.M. "SAP changes course," in: Software Magazine, 1996, p. 32-36.
Gremillion, L.L. "Determinants of Program Repair Maintenance Requirements,"
Communications of the ACM (27:8) 1984, p. 826-832.
Gulla, J.A., and Brasethvik, T. "On the Challenges of Business Modeling in Large Scale
Reengineering Projects," Proceedings of the 4th International Conference on
Requirements Engineering, Schaumburg, Ill, 2000, p. 17-26.
Gupta, Y.P., and Raghunathan, T.S. "A Preliminary Model for Information System
Replacement," Management Science (16:4) 1988, p. 289-296.
Gurbaxani, V., and Whang, S. "The Impact of Information Systems on Organizations
And Markets," Communications of the ACM (34:1) 1991, p. 59-73.
Bib-7
Hammer, M., and Champy, J. Reengineering the Corporation: A Manifesto for Business
Revolution Allen & Unwin, St Leonards, N.S.W., 1996, p. 232.
Hares, J., and Royle, D. Measuring the Value of Information Technology J. Wiley, New
York, 1994, p. 268.
Heald, K., and Kelly, J. "AMR Research Foresees that Implementing Technologies Will
Lead to Competitive Advantage," AMR Research, 1999.
Hecht, B. "Choose the right ERP software," in: Datamation, 1997, p. 56-58.
Heineman, G.T., Botsford, J.E., Caldiera, G., Kaiser, G.E., Kellner, M.I., and Madhavji,
N.H. "Emerging Technologies That Support A Software Process Life Cycle," IBM
Systems Journal (33:3) 1994, p. 501-520.
Hicks, D.A., and Stecke, K.E. "The ERP Maze: Enterprise Resource Planning and Other
Production and Inventory Control Software.," IIE Solutions (27:8) 1995, p. 12-16.
Hirt, S.G., and Swanson, E.B. "Emergent Maintenance of ERP: New Roles and
Relationships," Journal of Software Maintenance and Evolution: Research and
Practice (13:6) 2001, p. 373-397.
Holland, C., Light, B., and Gibson, N. "Global Enterprise Resource Planning
Implementation," American Conference on Information Systems, Association for
Information Systems: on CD, Balltimore, Maryland, 1998, p. 421-423.
Hopp, W.J., and Nair, S.K. "Timing Replacement Decisions Under Discontinuous
Technological Change," Naval Research Logistics (38) 1991, p. 203-220.
IEEE IEEE Standard for Software Maintenance, IEEE Std 1219-1998 Institute of
Electrical and Electronics Engineers, New York, 1998, p. 47.
IEEE IEEE Standard for Software Configuration Management Plans, IEEE Std 828-
1998, Institute of Electrical and Electronics Engineers, Inc., New York, 1998a, p.
22.
IEEE The New IEEE Standard Dictionary of Electrical and Electronics Terms - IEEE
100-1992, (Fifth ed.), Institute of Electrical and Electronics Engineers, Inc., New
York, 1993, p. 1619.
IEEE/EIA IEEE/EIA 12207.2-1997 Guide for Information Technology - Software life
cycle processes - Implementation considerations, Institute of Electrical and
Electronics Engineers, Inc., New York NY, 1997, p. 99.
Bib-8
Irani, Z., and Love, P.E.D. "The Propagation of Technology Management Taxonomies
for Evaluating Investments in Information Systems," Journal of Management
Information Systems (17:3), Winter 2001, p. 161-177.
ISO "Why is international standardization needed?" ISO, 2002.
ISO/IEC ISO 12207: Information Technology - Software Life Cycle Processes ISO/IEC,
Geneva, Switzerland, 1995, p. 57.
Jakovljevic, P.J. "Enterprise Resources Planning (ERP) Market - Dismal 1999, the New
Millennium to bring Relief (for Some)," TechnologyEvaluation.Com, 2000a.
Jakovljevic, P.J. "Essential ERP - Its Functional Scope," TechnologyEvaluation.Com,
2000b.
Jakovljevic, P.J. "The Essential ERP - It's Genesis and Future,"
TechnologyEvaluation.Com, 2000c.
Jakovljevic, P.J. "Essential ERP - Its Underpinning Technology,"
TechnologyEvaluation.Com, 2000d.
Jakovljevic, P.J., Talarico, L., and Spencer, B. "How Some ERP Vendors Demonstrated -
Warts And All Part 2 - Results," TechnologyEvaluation.Com, 2001.
Jakovljevic, P.J. "ERP Beginner's Guide In So Many Words,"
TechnologyEvaluation.Com, 2001a.
Jakovljevic, P.J. "The ERP Market 2001 and Beyond," TechnologyEvaluation.Com,
2001b.
James, D., and Wolf, M.L. "A Second Wind for ERP," in: The McKinsey Quarterly,
2000, p. 100-107.
Jones, C. Programming Productivity McGraw-Hill, New York, 1986, p. 280.
Jørgensen, M. "An Empirical Study of Software Maintenance Tasks," Journal of
Software Maintenance: Research and Practice (7:1) 1995, p. 27-48.
Judd, C.M., Smith, E.R., and Kidder, L.H. Research Methods in Social Relations, (6th
ed.) Holt, Rinehart and Winston, Fort Worth, 1991, p. 573.
Kajko-Mattsson, M. "A Conceptual Model of Software Maintenance," International
Conference on Software Engineering, IEEE Computer Society: Long Beach CA,
Kyoto, Japan, 1998, p. 422-425.
Bib-9
Katz, A.I. "Measuring Technology's Business Value," Information Systems Management
(10:1) 1993, p. 33-39.
Kellner, M.I., and Hansen, G.A. "Software Process Modeling," CMU/SEI-88-TR-9,
Software Engineering Institute (SEI), Carnegie Mellon University, Pittsburgh,
Pennsylvania, 1988, p. 58.
Kemerer, C.F. "Progress, Obstacles, and Opportunities in Software Engineering
Economics," Communications of the ACM (41:8) 1998, p. 63-66.
Kemerer, C.F., and Slaughter, S.A. "A Longitudinal Analysis of Software Maintenance
Patterns," International Conference of Information Systems, International
Conference on Information Systems: New York NY, 1997, p. 476-477.
Kemerer, C.F., and Slaughter, S.A. "Determinants of Software Maintenance Profiles: an
Empirical Investigation," Journal of Software Maintenance: Research and Practice
(9) 1997, p. 235-251.
Kessler, K. "Extending and Modifying the SAP Standard with Business Add-Ins and the
New Modification Assistant," SAP Professional Journal (1:1) 1999, p. 3-16.
King, J. "R/3 Users Look Beyond SAP for Business-to-Business Help," Computerworld,
2000.
Klaus, H., Rosemann, M., and Gable, G.G. "What is ERP?," Information Systems
Frontiers (2:2) 2000, p. 141-162.
Koch, C., Slater, D., and Baatz, E. "The ABCs of ERP," CIO Magazine, 1999.
Krogstie, J., and Solvberg, A. "Software Maintenance in Norway: A Survey
Investigation," International Conference on Software Maintenance, IEEE
Computer Society: Los Alamitos CA, Canada, 1994, p. 304-313.
Lee, T.W. Using qualitative methods in organizational research Sage Publications,
Thousand Oaks, Calif., 1999, p. 192.
Lehman, M.M., and Belady, L.A. Program Evolution Processes of Software Change
Academic Press, London, 1980, p. 538.
Lehman, M.M., and Parr, F.N. "Program Evolution and Its Impact on Software
Engineering," The 2nd International Conference on Software Engineering, IEEE
Computer Society: Long Beach CA, San Francisco, California, 1976, p. 350-355.
Bib-10
Lientz, B.P., and Swanson, E.B. Software Maintenance Management: A Study of the
Maintenance of Computer Application Software in 487 Data Processing
Organizations Addison-Wesley Publishing, Reading MA, 1980, p. 214.
Lientz, B.P., Swanson, E.B., and Tompkins, G.E. "Characteristics of Application
Software Maintenance," Communications of the ACM (21:6) 1978, p. 466-471.
Lyons, M.J. "Salvaging Your Software Asset (Tool Based Maintenance)," AFIPS
Conference Proceedings of the 1981 National Computer Conference, vol. 50,
AFIPS Press: Reston VA, 1981, p. 337-341.
Marakas, G.M. Decision Support Systems in the 21st Century Prentice Hall, Upper
Saddle River, NJ, 1998, p. 506.
Marion, L. "Mastering ERP's "Dirty Dozen": How to Identify and Overcome ERP's "Top
12" Obstacles," in: ERP News: ERPWorld.org, 1999.
Markus, L., and Tanis, C. "The Enterprise Systems Experience -- From Adoption to
Success," in: Framing the Domains of IT Management: Projecting the Future
Through the Past, R.W. Zmud and M.F. Price (eds.), Pinnaflex Educational
Resources, Cincinnati, OH, 1999, p. 173-207.
Markus, M.L. "Enterprise Systems – The Trajectory of Business, Systems, and
Technology Market Change," Financial Times Mastering Information
Management, November 20, 2000.
Markus, M.L. "Viewpoint: Reflections on the Systems Integration Enterprise," Business
Process Management Journal (7:3) 2001, p. 171-180.
Markus, M.L., and Lee, A.S. "Special Issue On Intensive Research In Information
Systems: Using Qualitative, Interpretive, And Case Methods To Study Information
technology - Foreword," MIS Quarterly (23:1), March 1999, p. 35-38.
Martin, E.W., Brown, C.V., DeHayes, D.W., Hoffer, J.A., and Perkins, W.C. Managing
Information Technology Prentice Hall, Upper Saddle River, NJ, 2002, p. 761.
Martin, J., and McClure, C. Software Maintenance: The Problem and its Solutions
Prentice Hall, Englewood Cliffs, New Jersey, 1983, p. 472.
Maxwell, J.A. Qualitative Research Design: An Interactive Approach Sage Publications,
Thousand Oaks, Calif., 1996, p. 153.
Bib-11
McDonnell, S. "Squeezing More Out of ERP," in: Computerworld, Computerworld, Inc.,
2000, p. 56-57.
McFarland, S. "An Insider's Guide to the SAP Change and Transport System (CTS),"
SAP Professional Journal (1:1) 1999, p. 55-70.
McKee, J.R. "Maintenance as a Function of Design," National Computer Conference,
AFIPS, 1984, p. 187-193.
Merriam, S.B. Qualitative Research and Case Study Applications in Education Jossey-
Bass Publishers, San Francisco, 1998, p. 275.
Minahan, T. "Enterprise Resource Planning: Strategies Not Included," in: Purchasing,
1998, p. 112-127.
Morphy, E. "When ERP meets ROI," Export Today (15:5) 1999, p. 42-47.
Mullin, R. "ERP Software: The next Generation.," Chemical Week (159:20) 1997, p. 40-
41.
Murphy, K.E., and Simon, S.J. "Using Cost Benefit Analysis for Enterprise Resource
Planning Project Evaluation: A Case for Including Intangibles," in: Enterprise
Resource Planning: Global Opportunities and Challenges, L. Hossain, J.D. Patrick
and M.A. Rashid (eds.), Idea Group Publishing, Hershey, 2002, p. 245-266.
Myers, J.L., and Well, A.D. Research design and statistical analysis L. Erlbaum
Associates, Hillsdale, N.J, 1995, p. 713.
Nah, F., Faja, S., and Cata, T. "Characteristics of ERP Software Maintenance: A Multiple
Case Study," Journal of Software Maintenance and Evolution: Research and
Practice (13:6) 2001, p. 399-414.
Nellemann, D.O. "World Class Cost Management and CIM Justification: The Way of the
90s," in: Enterprise Information Exchange: A Roadmap for Electronic Data
Interchange for the Manufacturing Company, V.O. Muglia (ed.), Computer and
Automated Systems Association of the Society of Manufacturing Engineers,
Dearborn MI, 1993, p. 163-171.
Neter, J., Kutner, M.H., Nachtsheim, C.J., and Wasserman, W. Applied Linear
Regression Models, (3rd ed.) McGraw-Hill Companies, Inc., New York, 1999, p.
720.
Bib-12
Newman, I., and Benz, C.R. Qualitative-quantitative research methodology: exploring
the interactive continuum Southern Illinois University Press, Carbondale, 1998, p.
218.
Ng, C.S.P. "A Decision Framework for Enterprise Resource Planning Maintenance and
Upgrade: A Client Perspective," Journal of Software Maintenance and Evolution:
Research and Practice (13:6) 2001a, p. 431-468.
Ng, C.S.P. "A Framework for Enterprise Resource Planning Maintenance and Upgrade
Decisions," Americas Conference on Information Systems, Association for
Information Systems: Atlanta, GA (on CD), Boston, Massachusetts, 2001b, p.
1026-1029.
Ng, C.S.P., Chan, T., and Gable, G.G. "A Client-benefits Oriented Taxonomy of ERP
Maintenance," International Conference on Software Maintenance, IEEE Computer
Society: Los Alamitos CA, Florence, Italy, 2001c, p. 528-537.
Ng, C.S.P., Gable, G.G., and Chan, T. "A Maintenance-data-model of Enterprise
Resource Planning," Australasian Conference on Information Systems, Southern
Cross University, Coffs Harbour, Australia, 2001d, p. 483-492.
Ng, C.S.P., Gable, G.G., and Chan, T. "An ERP-client Benefits-oriented Maintenance
Taxonomy," Journal of Systems and Software, (64) 2002, p. 87-109.
Ng, C.S.P., Gable, G.G., and Chan, T. "A Revelatory Case Study into the Adequacy of
Standard Maintenance Models in an ERP Context," Pacific Asia Conference on
Information Systems, Adelaide, Australia, 2003a, p. [In press].
Ng, C.S.P., Gable, G.G., and Chan, T. "An ERP Maintenance Model," Hawaii
International Conference on Systems Sciences, IEEE Computer Society: Los
Alamitos, CA, Hawaii, USA, 2003b, p. on CD-ROM.
Niccolai, J. "Oracle promises speedy deployment of ERP apps," IDG News Service,
2000.
Niessink, F., and van Vliet, H. "Two Case Studies in Measuring Software Maintenance
Effort," International Conference on Software Maintenance, IEEE Computer
Society: Los Alamitos CA, Bethesda, Maryland, 1998, p. 76-85.
Norman, F.S. "The State of Software Maintenance," IEEE Transactions on Software
Engineering (13:3) 1987, p. 303-310.
Bib-13
Norris, G., Hurley, J.R., Hartley, K.M., Dunleavy, J.R., and Balls, J.D. E-Business and
ERP: Transforming the Enterprise John Wiley & Sons, New York, 2000, p. 194.
Ogdin, J.L. "Designing Reliable Software," Datamation, 1972, p. 71-78.
Ohlson, K. "Study: R/3 Users Face High Costs for Upgrades," Computerworld, 2000.
Parr, A.N., and Shanks, G. "A Taxonomy of ERP Implementation Approaches," 33rd
Hawaii International Conference on System Sciences, IEEE Computer Society: Los
Alamitos, CA, Maui, Hawaii, 2000.
Pearson, D. "Complex Compromises - Outsourcing ERP," CIO Magazine, 1998.
Pigoski, T.M. Practical Software Maintenance: Best Practices for Managing Your
Software Investment John Wiley & Sons, Inc., New York, 1997, p. 384.
Polo, M., Piattini, M., and Ruiz, F. "MANTOOL: A Tool for Supporting Maintenance
Process," Journal of Software Maintenance and Evolution: Research and Practice
(13:2) 2001, p. 77-95.
Ptak, C.A., and Schragenheim, E. ERP: Tools, Techniques, and Applications for
Integrating the Supply Chain St. Lucie Press / APICS series on Resource
Management, Boca Raton, 2000, p. 424.
Queensland Treasury, QGFMS Benefit Realization Guidelines The State of Queensland
(Queensland Treasury), Brisbane, 2000, p. 34.
Quinn, J.B., Anderson, P., and Finkelstein, S. "Managing Professional Intellect: Making
the Most of the Best," Harward Business Review (74:March-April), 1996, p. 71-80.
Rajagopalan, S. "Deterministic capacity expansion under deterioration," Management
Science (38:4) 1992, p. 525-539.
Rajagopalan, S., Singh, M.R., and Morton, T.E. "Capacity Expansion and Replacement in
Growing Markets with Uncertain Technological Breakthroughs.," Management
Science (44:1) 1998, p. 12-30.
Rombach, H.D., and Ulery, B.T. "Improving Software Maintenance Through
Measurement," Proceedings of the IEEE (77:4) 1989, p. 581-595.
Ross, J.W., and Vitale, M.R. "The ERP Revolution: Surviving vs. Thriving," Information
Systems Frontiers (2:2) 2000, p. 233-241.
Rus, I., and Lindvall, M. "Knowledge Management in Software Engineering," IEEE
Software (May/June) 2002, p. 26-38.
Bib-14
SAP, "BC Change and Transport Organizer," SAP AG, 1998a.
SAP, "BC Enhancements to the SAP Standard," SAP AG, 1998b.
SAP, "BC Transport Control," SAP AG, 1998c.
SAP, "SAP Customers Report Significant Return On Investment from mySAP™ CRM,"
SAP AG, 2002.
SAP "SAP Offers Maintenance Extension for SAP R/3 Releases," SAP AG, 2002a.
Saaty, T.L. "How to Make a Decision: The Analytic Hierarchy Process," Interfaces
(24:6), November-December 1994, p. 19-43.
Sarkis, J., and Sundarraj, R.P. "A Decision Model for Strategic Evaluation of Enterprise
Information Technologies," Information Systems Management (18:3) 2001, p. 62-
72.
Scarf, P.A., and Bouamra, O. "A Capital Equipment Replacement Model For A Fleet
With Variable Size," Journal of Quality in Maintenance (5:1) 1999, p. 40-49.
Schneidewind, N.F. "Software Maintenance: The Need for Standardization," Proceedings
of the IEEE (77:4) 1989, p. 618-624.
Scott, J.E. "The FoxMeyer Drugs' Bankruptcy: Was it a Failure of ERP?," The Fiftth
Americas Conference on Information Systems, Association for Information
Systems: Atlanta, GA (on CD), Milwaukee, Wis., 1999, p. 223-225.
Shang, S., and Seddon, P.B. "A Comprehensive Framework for Classifying the Benefits
of ERP Systems," Americas Conference on Information Systems, Association for
Information Systems: Atlanta, GA (on CD), Long Beach, California, 2000.
Shanks, G., Parr, A., Hu, B., Corbitt, B., Thanasankit, T., and Seddon, P. "Differences in
Critical Success Factors in ERP Implementation in Australia and China: A Cultural
Analysis," European Conference on Information Systems, Vienna University of
Economics and Business Administration, Vienna, Austria, 2000, p. 537-544.
Shi, S., and Qian, J. "Upgrading to R/3 Release 4.5 and Beyond: An ABAP Developer's
Guide," SAP Professional Journal, 2001, p. 3-26.
Sieber, P., and Griese, J. "Virtual Organization Net," International VoNet Workshop on
Organizational Virtualness and Electronic Commerce, Stampfli AG, Bern, Zurich,
1999a.
Bib-15
Sieber, T., Siau, K., Nah, F., and Sieber, M. "Implementing SAP R/3 at the University of
Nebraska," International Conference on Information Systems, International
Conference on Information Systems: New York NY, Charlotte, USA, 1999, p. 629-
649.
Simon, L. "Making the Most of Enterprise Resource Planning," Chemical Market
Reporter (251:19) 1997, p. 30-31.
Slater, D. "An ERP Package for You...and You...and You...and Even You," CIO
Magazine, 1999.
Slater, D. "The Hidden Cost of Enterprise Software," CIO Magazine, 1998.
Slaughter, S., and Banker, R.D. "A Study of the Effects of Software Development
Practices on Software Maintenance Effort," International Conference on Software
Maintenance, IEEE Computer Society: Los Alamitos CA, Monterey, California,
1996, p. 197-205.
Smith, B. "Six-sigma Design," IEEE Spectrum (30:9), September 1993, p. 43-47.
Soh, C., Sia, S.K., and Tay-Yap, J. "Cultural Fits and Misfits: Is ERP A Universal
Solution?" in: Communications of the ACM, 2000, p. 47-51.
Songini, M.L. "Users Vent Complaints about Oracle Application Upgrades,"
Computerworld, 2000.
SPSS Advanced Techniques: Regression, SPSS Inc., 2001, www.spss.com/training/. Stedman, C. "Order Entry Flexibility an ERP Issue," in: Computerworld, 2000, p. 10.
Stedman, C. "Peoplesoft Acts on Dip in User Satisfaction," in: Computerworld, 1999, p.
6.
Stein, T. "ERP Overhaul for Lawson -- Strategic Ledger Among New Features,"
InformationWeek, 1999a, p. 42.
Stein, T. "Making ERP Add Up," in: InformationWeek, 1999, p. 59-63.
Sumner, M. "Critical Success Factors in Enterprise Wide Information Management
Systems Projects," The Fifth Americas Conference on Information Systems,
Association for Information Systems (on CD), Milwaukee, Wis., 1999, p. 232-234.
Swanson, E.B. "IS Maintainability: Should It Reduce the Maintenance Effort," ACM
SIGCPR, ACM, New Orlean, 1999, p. 164-173.
Bib-16
Swanson, E.B. "The Dimensions of Maintenance," International Conference on Software
Engineering, IEEE Computer Society: Long Beach CA, San Francisco, 1976, p.
492-495.
Swanson, E.B., and Beath, C.M. Maintaining Information Systems in Organizations John
Wiley & Sons Ltd., England, 1989, p. 255.
Thompson, O. "Should You Modify An Application Product?"
TechnologyEvaluation.Com, 2001b.
Thompson, O. "The "Old ERP" Dilemma: Replace or Add-on,"
TechnologyEvaluation.Com, 2001.
Travis, D.M. "ERP Selection," in: APICS - The Educational Society for Resource
Management, 1999.
Turban, E., and Aronson, J.E. Decision Support Systems and Intelligent Systems, (6th ed.)
Prentice Hall, Upper Saddle River, New Jersey, 2001, p. 867.
Vernadat, F.B. Enterprise Modeling and Integration: Principles and Applications, (1st
ed.) Chapman & Hall, London, 1996, p. 513.
Vessey, I., and Weber, R. "Some Factors Affecting Program Repair Maintenance: An
Empirical Study," Communications of the ACM (26:2) 1983, p. 128-134.
Volkoff, O. "A Grounded Theory of Enterprise Application Software Implementation,"
American Conference on Information Systems, Association for Information
Systems: on CD, Baltimore, Maryland, 1998, p. 1170.
Ward, J., Taylor, P., and Bond, P. "Evaluation and Realization of IS/IT Benefits: An
Empirical Study of Current Practice," European Journal of Information Systems (4)
1999, p. 214-225.
Wee, S. "Juggling Toward ERP Success: Keep Key Factors High," in: ERP News:
ERPWorld.org, 1999.
Weston, R. "ERP Users Find Competitive Advantages," in: Computerworld, 1998, p. 24.
Weston, R., and Stedman, C. "Forget ROI - Just Install It," in: Computerworld, 1998, p.
1, 14.
Whearly, M. "Resourceful Enterprise Planners (ERP Market)," Financial Director
(November) 1999, p. xix--xx, xxii.
Wilson, T. "Oracle Suite Integrates ERP, E-business Apps," in: InternetWeek, 1999, p. 1.
Bib-17
Yin, R.K. Case Study Research: Design and Methods, (2nd ed.) Sage Publications,
Thousand Oaks, California, 1994, p. 171.
Zvegintzov, N. "The Management of Software Change: Managing Software," Software
Management News (12:3) 1994, p. 1-15.
Bib-18