Management of Enterprise Resource Planning (ERP ... · in Enterprise Resource Planning (ERP) implementation and lifecycle support. This research is an exploratory, descriptive, revelatory

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


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


• 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.


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.


of proposing maintenance

attributes at maintenance

preparation stage and

software upgrade stage in

order to develop a complete


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


• 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.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.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.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


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.


• 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.


• 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?


• 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?


• 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,


Regression analysis

Pattern matching,


Comparing the data with

the in-house software,

Mathematical modeling

Pattern matching,


the in-house software

Pattern matching,


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) +


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.


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


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,


Improved integration with other business

functions.

Integrate acquisitions.

Operational Reduced raw material inventory.


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.


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


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


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


Change-request

Database

User-supportDatabase

ERP Literature

TheProposed


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


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



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


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


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


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.


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.


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.


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?


change-request database.

Time spent

servicing the

request,

characteristics of

maintenance

project.

Pattern matching,


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?



patch database,

modification database,

documentation.

Factor affecting

maintenance and

upgrade decisions,

maintenance effort

drivers, upgrade

cost drivers.

Pattern matching,



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?



documentation.

Procedure and

steps involved in

maintenance and

upgrade activities,

maintenance

methodology.

Pattern matching,


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?


maintenance request

forms, change-request

database.

Maintenance data-

attributes.

Pattern matching,


house software.

3-34

5.Develop an

Empirical Modelfor ERP

MaintenanceEffort

4.Propose an ERP

MaintenanceTaxonomy

7.Develop an ERP


ERP maint.category

ERPmaintenanceeffort model


(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


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.






(6) Patch

(iii) Keep the existing system

up to the vendor’s standard

version.






(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





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,


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


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


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


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


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


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


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


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



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.







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


Model

6.2Reasons to Do

Maintenance andUpgrade

Chapter 6:Decision

6.6Summary

CSA's ERP maintenance classification

ERP internal change-requests(maintenance) effort determinants


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


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


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


programming

ERP packaged

software

Patch or support

package maintenance,

and software upgrade

ONLY

• Standard code is

changed/affected,

and/or

• Custom code

increases


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



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

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



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


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


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



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


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


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


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


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.






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,


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


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.




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.







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.



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



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.


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.


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


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




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




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




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




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




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


Taxonomy X

(Interview,

change-request

database, user-

support

database)

X X*


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*


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


Methodology X

(Interview,

change-request

database,

documentation)

X

(maintenance

process)

X X*


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*


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


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

Susan Leggett

Depending on the style you are required to use (Harvard, Chicago, APA, etc.) inverted commas will need to be checked in the final version. In most systems, direct quotes have double inverted commas (except where they are reproduced in an indented block), and familiar or jargon terms are enclosed in single inverted commas.

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.


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.


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?


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?


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.


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,


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


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


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


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


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


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,


Comparing the data

with the in-house

software

Pattern matching,


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


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

Susan Leggett

Just checking that you don’t mean adopt? Or: Has CSA adopted any framework or standard …

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

Documents

Management of Enterprise Resource Planning (ERP ... · in Enterprise Resource Planning (ERP) implementation and lifecycle support. This research is an exploratory, descriptive, revelatory