Predicting the implementation effort of ERP projects: empirical evidence on SAP/R3

1. Predicting the implementation effort of ERP projects: empirical evidence on SAP/R3 指導老師: 吳思佩 教授 • 922543 陳佑任922516 陳煥文 • 922503 林建旻922522 蔡佳倫 • 922549 張書勳922528 侯秉逢 • 922505 莊晏禎 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.

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

3. The objective of this paperis theoretical discussion and empirical testing of a model for predicting ERP implementation costs.

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

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

6. Prediction models generalizing case knowledge are mostly commercial. • Professional methods seem to focus on traditional technical expenses.

7. Research hypotheses

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

9. 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 non-technical language

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

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

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

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

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

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

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

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

18. H2： There exists a positive correlation betweenthe 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

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

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

21. 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 effort • Human resources Implementation process

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

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

24. Implementation effort The effort for whole project • Total man month Improve the accuracy of effort as a proxy of cost

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

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

27. Methodology and results • Preliminary interview • Consulting companies were invited to acolloquium(學術討論會) • A questionnairewas prepared for collecting quantitative data and qualitative description

28. 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 across-section(跨地區)manufacturing industries

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

30. 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 non- standardized variables

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

32. 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 (每個模組使用者的人數)

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

34. Discussion The models were statistically significant indicating that the technical size and organizational complexity of relevant driver of implementation effort From astatisticalperspective ,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.

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

37. Findings • Significant intercept/ Non-significant intercept =>A significant negative intercept for the financial module was related to four mandatory sub-modules. (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 sub-modules.

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

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

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

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

42. Limitations • 2.Technical manuals(手冊) of ERP packages typically include a high-level classification of modules , but they do not document submodules systematically.

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

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

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

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

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

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

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

50. 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(預估).