Transcript Research hypotheses

Predicting the implementation effort
of ERP projects: empirical evidence
on SAP/R3
Summary of the following paper: Francalanci, C. Predicting the
implementation effort of ERP projects: Empirical evidence on SAP/R3.
Journal of Information Technology, 16, (2001), 33-48.
指導老師: 吳思佩




教授
922543 陳佑任 922516 陳煥文
922503 林建旻 922522 蔡佳倫
922549 張書勳 922528 侯秉逢
922505 莊晏禎
Introduction

A common experience among
companies that have undertaken ERP
projects is incurring high expenditures,
which frequently outgrow their initial
budgets by significant percentage
values.

The objective of this paper
is theoretical discussion and empirical
testing of a model for predicting ERP
implementation costs.
Predicting software costs: from
code to ERPs.
Two methods of predicting human
resources for software development.
1.Analogical
Base on database.
2.Parametric
A measure of the size of a software
system to the human resources needed
to implement it.

Size is easier to estimate than effort.
 Implementation effort has been
demonstrated to be accurate.
 System size is still held as a driver of
implementation effort.

Prediction models generalizing case
knowledge are mostly commercial.
 Professional methods seem to focus on
traditional technical expenses.

Research hypotheses

Size and complexity －

general drivers of the implementation effort that
conceptually apply to both traditional and ERP
software projects .
Their operating definition should conform to －
the changes in the implementation
process and in the nature of its tasks ,
which differentiate ERP projects from software
development .
ERP implementation phases and objectives ：

Phase 1：requirements analysis and
specification
Def. for ERPs ：
It analyses organizational processes and compares them
with the procedures embedded in the ERP package in order to
distinguish between modules that can be parameterized and
modules that need reprogramming
Functional and data requirements are specified for
modules that need reprogramming
Def. for traditional software development ：
It defines users’ functional and data requirements in a nontechnical language

Phase 2： conceptual design
Def. for ERPs ：
It parameterizes modules that do not need reprogramming
and produces a technical specification of the functional and data
requirements for modules that need reprogramming
Def. for traditional software development ：
It produces a specification of the functional and data
requirements in a technical , unambiguous language as a
reference for code development

Phase 3：code development and verification
Def. for ERPs ：
It develops and verifies software code for modules that
need reprogramming
Def. for traditional software development ：
It develops and verifies software code according to
requirements specifications

Phase 4：testing and installation
Def. for ERPs ：
It tests all modules against requirements as well as quality
parameters
Def. for traditional software development ：
It tests code against requirements as well as quality
parameters
Module：

A module is a part of a software system that
exchanges information and services with
other modules , but is not affected by their
change as long as their interface are not
modified

ERP suppliers emphasize modularity as one
of their chief quality goals , which enables
their clients to implement a package
incrementally by plugging and playing with
different modules

By assuming that ERPs are modular , as they
are supposed to be , it is correct to consider
parameterization and reprogramming as
independent design phases and to regard
modules as separate parts of a system which
can be implemented and modified in isolation

From a theoretical standpoint , the number of
modules represents a measure of project
size , which is also conceptually similar to
traditional function points since it is related to
the number and variety of functionalities
required by an organization
Hypothesis：

H1：
There exists a positive correlation between the
size of an ERP project measured as the number of
modules that are implemented and the
implementation effort measured as the human time
devoted to implementation activities

H2：
There exists a positive correlation between the
effort of implementing a module of an ERP
system measured as the human time devoted to
implementation activities and the size of the module
measured as the number of submodules that are
implemented

H2 does not imply H1

H3：
There is a positive correlation between
organizational size and implementation effort
measured as the human time devoted to
implementation activities for individual modules and
for the whole ERP system

H4：
There is a positive correlation between the
number of final users and the implementation
effort measured as the human time devoted to
implementation activities for individual modules and
for the whole ERP system
Drivers of the implementation effort of an ERP project：
size of the software product and contextual drivers of
organizational requirements for customization
Contextual factors
Organizational size
Total number of users
Per-module number of users
Size
•Total number
of modules
•Per-module number
of submodules
Implementation
process
Implementation effort
Human resources
Summary：

Testing hypotheses H1~H4 helps make a
distinction between technical and
organizational drivers of the implementation
effort for ERPs
 The impact of the size of ERPs provides an
assessment of the theoretical implementation
effort and resulting costs predicted from a
technical perspective , while contextual
factors help explain the variance in costs due
to the organizational complexity of the project
Variable definition and operationalization

SAP/R3(a main stream ERP package)
In order to measure all variables within the
same time-frame
 The beginning of the implementation phase
 The end of the implementation phase
Implementation effort
The effort for whole project
 Total man month
Improve the accuracy of effort as a proxy
of cost
Size of ERP package
The size of a module is operationalized as
the number of sub-modules that are
implemented in a particular project.
The overall size of the package is defined
as the summation of module size
Contextual variables
Organization size:
 Total revenue
 Total number of employees
The number of users for a module can be
operationalized as the number of
licences that grant access to that
module
Methodology and results
 Preliminary

interview
Consulting companies were invited to a
colloquium(學術討論會)
 A questionnaire was prepared for
collecting quantitative data and
qualitative description
Methodology and results
Results

Conducted during 1996-2000 and lasted 18
month
 Client companies were mostly
European(95%) with an average revenue

of $200 million
Belonging to a cross-section (跨地區)
manufacturing industries
Methodology and results

The average implement cost of $1.7
million
Consulting companies rate as medium to
high for European market
 Approximately 60% of the total cost include :

License
Maintenance for a 5-year period
Statistical approach and
methodology
Independent variables were standardized in
order to be able to compare the magnitude
of their correspond coefficients and
evaluate their weight in explaining the
implement effort.
Standardized variables can be more useful as
prediction benchmarks(基準點) than nonstandardized variables
Fitted regression models

Model M1,M2 tested the correlation
between implementation effort and
independent variables for the Whole
ERP package

Model M3,M4 verified the correlation for
individual modules
Fitted regression models
M1: IE = C11 + C12 SP+ C13TR + C14TNU
M2 : IE = C11 + C12 SP+ C13NE+ C14TNU
M3 : IE = C11 + C12 SM+ C13TR + C14MNU
M4 : IE = C11 + C12 SP+ C13NE+ C14MNU
(1) IE = implementation effort (2) SP = size of package (套裝) (3) TR = total revenue (總收入)
(4) NE = number of employees (員工人數) (5) TNU = total number of users (所有使用者人數)
(6) MNU = per-module number of users (每個模組使用者的人數)
Fitted regression models

Empirical(過去經驗的) testing was also
performed by controlling for two critical
variables
(1) high turnover of personnel within
consulting companies
(2) technical feature of
legacy system
Discussion
The models were statistically significant
indicating that the technical size and
organizational complexity of relevant driver of
implementation effort
From a statistical perspective ,models
that include both technical and organizational
drivers of effort provide more accurate
estimate than software engineering
prediction models , which traditionally
take an exclusively technical perspective.
Findings
1)
2)
The model variables were more
significant for individual modules than
for the whole package.
The significant of the size of package
and size of module verified the
modularity of SAP/R3 at both a
package and module level.
=> Each sub-module was estimated to add between 12 to 32
person days to the implementation effort of the corresponding
module.
=> 19 person days (on average) to the overall implementation effort
Findings
3)
Significant intercept/ Nonsignificant intercept
=>A significant negative intercept for the financial
module was related to four mandatory submodules. (ledger, accounts receivable, accounts
payable and asset accounting)
=>A Non-significant intercept
for other modules and
the whole package would indicate that companies
can choose to implement any number of submodules.
Findings
The number of users is a primary
driver of the reprogramming effort.
=>At a module level, the number of
users showed a higher standardized
coefficient than the total revenue and
number of employees for modules
providing functionalities to line
organizational units.
4)
Findings
line organizational units:
=>Users in line units are more likely to be
able to exert an individual resistance
to change, since their work is mission
critical and their rejection of new
software procedures would have
immediate negative effects.
Findings
The controlling module’s measurable
effort was primarily related to the
number of sub-modules that were
require, which showed the highest
value of the standardized coefficient.
=> The implementation effort for the
controlling module showed a
significant correlation with the number
of sub-modules and total number of
users
5)
Limitations

1.The technical and organizational
complexities in this research was
specific to SAP/R3 ,so, the
quantitative(與數量有關的) results cannot
be applied in(應用在) the prediction of
implementation efforts(導入成果) for other
ERP packages.
Limitations

2.Technical manuals(手冊) of ERP
packages typically include a high-level
classification of modules , but they do not
document submodules systematically.
Limitations

3.Additional testing for a broader(較廣泛
的) range of total person months(人力時間)
could be helpful in uncovering possible
scale efforts and refining(使其完美)
prediction models accordingly.
Limitations

4.The organizational complexity of
projects has an impact not only on
implementation effort(導入成果), but also
on the cost of organizational changes
subsequent to the deployment of the
package.
Conclusion and implications

The technical size of software is not
sufficient(足夠) predicting the
implementation effort of an ERP system
accurately, while organizational
measures of project complexity are also
critical(重要) drives of effort.
Conclusion and implications

In this study, size was found to explain a
significant percentage of the variance in
implementation effort and the inclusion of
more specific variables should be guided
by a strong theoretical basis(理論基礎)
that ensures coherent, cumulative
results .
Conclusion and implications

Companies implement a package or a
module for the majority or all of their
potential users. The large organizational
breadth of projects may be related to the
conviction that parameterization involves
fixed cost(固定成本) independent of the
number of users and subject to
economies of scale.
Conclusion and implications

The magnitude of the variable(多變的)
organizational costs reduces returns from
economies of scale and suggests that
prototyping ERPs for a subset of their
users may yield economic benefits.
Conclusion and implications

A primary(主要) concern(擔心) of
managers during budgeting is defining
the scope of ERP projects in terms of the
modules to be implemented.
Findings(研究結果) have proved that
this lack of detail is likely(可能) to affect
managers’ ability to formulate accurate
budgets and control related expenses.
Conclusion and implications

Predicting the implementation effort for
individual modules separately is
advisable(必要的) in order to select the
most appropriate(適合) set of predictors
and obtain more reliable(可靠)
estimates(預估).
Conclusion and implications

Technical and organizational drives of costs
show a similar magnitude, both for individual
modules and for the whole package.
Research hypotheses(假設,前提) have been
formulated by making a distinction(區別)
between parameterization and reprogramming
efforts and assuming that the former(前者) is
proportional to the technical size of the project,
while the latter(後者) is a consequence of the
organizational resistance to change.
Conclusion and implications

On average, parameterization and
reprogramming involve a similar effort
during implementation.
Conclusion and implications

If this study were to be replicated(複製)
for different ERPs, quantitative results
could be used as benchmarks(檢查標準)
for supporting managers while choosing
a package and comparing
implementation budgets.
Conclusion and implications

As technical evolves(發展) and new modules
of SAP are implemented, organizational
expenses are likely to remain a heavy
component of the total implementation costs.
Companies should realize that assessing(估
價) the magnitude of organizational costs from
the beginning is critical in building a strategy(策
略) for ERP deployment that does not
consistently exceed(超過) initial(最初) budgets.