Iwsm2014 understanding functional reuse of erp (maya daneva) - public release
Transcript of Iwsm2014 understanding functional reuse of erp (maya daneva) - public release
113/04/23 Title: to modify choose 'View' then 'Heater and footer'
1
Understanding Functional Reuse of ERP Requirements in the Telecom Sector
Maya Daneva, University of Twente
22
Agenda
Problem statement What was done to address it? Key results How did we get them? Implications for research and practice
3
Problem Statement
When adopting ERP, adopters want to know how much reuse can be leveraged and what amount of customization is necessary.
Relatively little empirical research exists on the variety of reuse aspects in ERP projects.
Nor on the levels of reuse possibly achiavable for ERP-adopters.
Nor on how same-sector adopters compare in terms of reuse they achieved in their ERP projects.
4
What I Did?
Used published (1999) sets of rules for counting FP from ERP requirements documents.
Worked with three telecom companies (one is my previous employer) to run FP counting based on ERP requirements
The package of this study is SAP
5
Key Findings
Reuse is possible up to 80% at best
While for some modules, the adopters achieves the same levels of reuse, for others, there was a wide variation.
6
How did we conclude this?
Case study settings Three companies, members of ASUG
All used the Accelerated SAP (ASAP) Implementation Roadmap
All used the ASAP Tools and requirements modelling standards
All shared the same attitude towards avoiding unnecessary customization
7
ERP Requirements Documentation Approach
8
Reasoning about Functional Reuse: The Basics
The notion of ‘reuse percent’ (as per IBM, 1998):
SAP_Reuse = (Size of Reused Req) / Size of Total Req) * 100%
FP as the approach to measuring size
Not ALL Reuse is the same!!
9
Reuse Levels
Use of the SAP’s Reference Model: If a requirements does not need modification, it’s termed ‘reusable’
If a requirement needs minor or major enhancement before use, it’s ‘customized’
Process components (e.g. units of functionality in a process model) and data components (an element in a data model, e.g. entity ort a relationship in a ERD)
Level 3: process and data components reused without any change
Level 2: minor enhancements applied to data/ process components
Level 1: major enhancements
Level 0: No reuse at all.
10
FP Counting for SAP: Summary
Mapping the SAP requirements (process and data models) to the FPA counting components (1999): Data entities are mapped to data types
Process concepts – to transaction types
Assigning complexity values to the components
Calculating the final FP count for each SAP ‘scenario’ within an application module.
11
Example of Results: Material Management
MM business process Level 3 Level 2 Level 1 No Reuse
Material Master Data Processing 65% 9% 9% 17%
Purchase Order Processing 56% 25% 10% 9%
Credit Master Data Processing 76% 0% 14% 10%
Invoice Processing with Reference 63% 8% 20% 9%
Process-specific profiles: present levels wrt to a scenario Level-specific profiles: present how req’mts are reused
within a module/project.
12
Comparing Results within a Module: Material Management
MM business process Level 3 Level 2 Level 1 No Reuse
Material Master Processing 65/68/60 9/12/12 9/0/11 17/20/17
Purchase Order Processing 56/50/60 25/30/25 10/6/15 9/9/9
Credit Master Data Processing 76/70/76 0/10/8 14/12/6 10/8/10
Invoice Processing with Reference 63/46/49 8/12/20 20/20/20 9/22/21
1313/04/23Title: to modify choose 'View' then 'Heater and footer' 13
Conclusions
Reuse is possible up to 80 %
For some modules, Level 3 reuse is as little as 30% (that’s not good!)
Reuse varies per scenario within a module, and across modules
Results look like unsurprising
14
Implications Implications for Practice:
The findings confirm previously published results that cast doubts into the fundamental promise of ERP
Project managers who consider reuse a driver, could make more informed decisions
New research questions: What is the most appropriate level of reuse for a particular business sector? Or with respect a specific module?
How do organizations minimize the customization costs and optimize the value of the ‘good reuse’
What are the reasons for the variability in reuse profiles?