=Paper=
{{Paper
|id=Vol-3272/paper8
|storemode=property
|title=A Size Measurement Method for Enterprise Applications
|pdfUrl=https://ceur-ws.org/Vol-3272/IWSM-MENSURA22_paper8.pdf
|volume=Vol-3272
|authors=Neslihan Küçükateş Ömüral,Onur Demirörs
|dblpUrl=https://dblp.org/rec/conf/iwsm/OmuralD22
}}
==A Size Measurement Method for Enterprise Applications==
https://ceur-ws.org/Vol-3272/IWSM-MENSURA22_paper8.pdf
A size measurement method for Enterprise Applications
Neslihan Küçükateş Ömüral 1 and Onur Demirörs 2
1
Middle East Technical University, Üniversiteler, Çankaya, Ankara, 06800, Türkiye
2
Izmir Institute of Technology, Gülbahçe, Urla, İzmir, 35430, Türkiye
Abstract
Enterprise Applications are known as one of the best practices of software reuse. They are
complex applications, including most of the business processes. In this domain, size
measurements and effort predictions are mostly performed in an ad-hoc fashion, and they
frequently suffer from schedule and budget overruns. We developed a size measurement
method for Enterprise Applications and explained this novel method in this paper. We
categorized transactions as “unchanged”, “changed”, and “new” in this method. We defined a
size measurement unit, Data Transaction Point (DTP), and measured size as DTP in these
categories. We conducted a sample size measurement with a well-known business process to
demonstrate the implementation of the method.
Keywords 1
enterprise applications, enterprise systems, enterprise resource planning, software size
measurement, reuse, data transaction point
1. Introduction
Enterprise Applications are complex and effort-intensive applications that are implemented by most
organizations. These applications initially emerged as MRP (Manufacturing Resource Planning)
Systems, and evolved into ERP (Enterprise Resource Planning) Systems as a result of the need to run
different types of transaction-based back office operations [1], [2]. Later, with the addition of processes
including front office and inter-organizational operations, the scope expanded with applications such
as SCM (Supply Chain Management) and CRM (Customer Relationship Management) [1], [3], [4].
Enterprise Applications are defined as “commercial software packages that enable the integration of
transactions-oriented data and business processes throughout an organization (and perhaps eventually
throughout the entire inter-organizational supply chain)” [4].
Enterprise Applications are referred to by different terms such as “Enterprise Systems”, “Enterprise
Software”, and “Enterprise Software Applications”. In this paper, we use the term “Enterprise
Applications” and define EA projects as the implementation of Enterprise Applications in specific
organizations.
Markus and Tanis [4] defined the following critical characteristics of Enterprise Applications:
Packages: Enterprise Applications are commercial software packages; purchased or leased
from software vendors instead of developed from scratch.
Software Life Cycle: Rather than designing a new software to meet the organization’s needs,
the adopters of Enterprise Applications often try to adjust organization’s business processes to the
EA package.
Proceedings Name, Month XX–XX, YYYY, City, Country
EMAIL: email1@mail.com (A. 1); email2@mail.com (A. 2);
email3@mail.com (A. 3)
ORCID: XXXX-XXXX-XXXX-XXXX (A. 1); XXXX-XXXX-
XXXX-XXXX (A. 2); XXXX-XXXX-XXXX-XXXX (A. 3)
©️ 2020 Copyright for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
CEUR Workshop Proceedings (CEUR-WS.org)
Best Practices: Enterprise Applications are designed to handle generic business processes.
Organizations redesign their business processes to adopt the EA package’s best practices. Business
process reengineering is an essential part of EA projects.
Integration: In many cases, EA adopters need to interface the EA package to the organization’s
existing software.
Configuration: During the EA project, the configuration is done by setting software parameters
based on the business processes to be implemented. The process of configuring an EA package for
an organization is significantly different from software programming.
Evolving: Enterprise Applications are rapidly changing based on industry expectations.
Enterprise Applications include all processes, interactions, and financial transactions of different
organizations on the same platform, which makes their structure complex. Daneva and Wieringa [5]
stated that EA projects, unlike other types of software projects, include thousands of business activities,
require diverse configuration and modification activities, and do not have a master architecture.
Enterprise Applications are distinguished from other software with their high reuse rates by reusing
many of the pre-built functions to meet customer requirements. “Software reuse” is defined as the “use
of existing software or software knowledge to construct new software” [6]. By allowing adopters to
handle various business requirements by configuration and customization, EA projects are considered
as one of the most successful reuse implementations in Software Engineering [7].
In EA projects, applying required changes to the package is performed by using configuration and
customization. “Configuration” is defined as setting necessary business-specific parameters in the
system to run the EA package; configuration does not comprise source code changes. On the other hand,
customization comprises source code changes. Customization is a term in EA that is used for
modifications made to the software to handle the customer’s requirements that are not supported by
pre-built functionalities of the software [8], [9], [10]. Customization is implemented by modifying the
source code of the software. The relationship between customization and reuse is inverse; as
customization increases in an EA project, the reuse rate decreases. Due to the structure of EA projects,
customization is inevitable in these projects. Results of the EA research [11] showed that 64.3% of
organizations participating in the research performed customization in their projects.
Daneva [12] performed an empirical study to explore reuse, and she measured the levels of reuse in
three SAP projects in the same business sector. According to the results of the study, reuse rate was up
to 80% at best, and reuse levels varied based on the type of implemented module. With these findings,
she argued that the reusability of the ERP projects should not be overvalued. She claimed that
companies adopting ERP should be ready to the minimum of 20% (in some cases presenting 40%) of
pre-built functionality would not fit their business requirements, and customization would be inevitable.
In EA projects, size measurements and effort estimations are often performed in an ad-hoc fashion.
They often suffer from time and budget overruns, as demonstrated by many reports such as [11]
published in the field. After Stensrud [13] published the first study claiming that conventional size
measurement and effort estimation methods are not suitable for such complex projects, several research
studies have been conducted handling the EA size measurement problem. Function points-based size
measurement methods were mostly evaluated in these studies, and “Business Blueprint” is the most
used resource for sizing [14].
Software size is used as a major input for project time scheduling, effort estimation, quality
management, productivity measurement, risk management, and outsource management processes. It
could also be used as a base unit for software acquisition, scope changes, and normalization of base
project measures [15]. For software size measurement, various methods have been developed over the
years. Function point-based methods such as COSMIC, IFPUG, and NESMA are widely used in
software engineering [16]. These functional size measurement methods have been evaluated as potential
methods for EA projects. Although many size measurement methods have been studied for EA projects,
none of the methods is widely accepted and validated as a suitable method for EA size measurement
[14].
Considering the features that distinguish EA projects from other software projects, we developed a
size measurement method for EA projects. In this method, “changes”, where pre-built functionality was
insufficient for the customer requirements, are measured. We defined a new size measurement unit,
namely Data Transaction Point (DTP), for EA projects. We counted “data groups” in transactions and
measured “changes” at the transaction level. This paper presents this proposed size measurement
method with a detailed size measurement sample.
The rest of the paper is organized as follows: Section 2 reviews related research regarding software
size measurement and effort estimation for EA projects. Section 3 describes the proposed size
measurement method. In Section 4, a sample size measurement is explained in detail. The main
conclusions are presented in Section 5. In Section 6, possible directions for future work is presented.
2. Background and related work
Size measurement is accepted as one of the most critical processes of software project management.
Ozkan et al. [15] defined functional size as the major input for effort, cost, and schedule prediction, and
they also stated that project scope changes could be measured using functional size. They listed many
other contributions of functional size to software project management, being used as a software
acquisition unit, and normalizing base project measures, such as performance and quality [15].
The first measure for sizing software was the Lines of Code (LOC), where size measurement is done
by counting the lines of source codes of the software. It is an easily applicable and automated size
measurement method, but it cannot be used for measurement at the requirements elicitation phases of
the projects. In order to handle size measurement based project management problems, various size
measurement/estimation approaches have been developed over the years, and the most used ones were
approaches based on measuring functionality [16].
The first study in the literature on this issue was the study of Stensrud [13]. He claimed that existing
effort estimation methods are unsuitable for comprehensive projects such as EA projects. He argued
that specific metrics should be defined for size measurement/effort estimation of these projects and
identified potential metrics, namely modules, software interfaces, business units, users, sites, EDI
interfaces, custom-developed reports, data conversions, and modified screens [13].
Daneva and Wieringa [5] evaluated if existing size measurement and effort estimation methods were
applicable to the EA domain in their study. Daneva defined the existing state-of-art for size and effort
estimation of cross-organizational ERP projects [17]. In this study, asynchronous focus groups,
including representatives from different stakeholders of ERP projects, were constructed; according to
the results, there was no consensus among representatives about how to define and measure size, and
whenever size is used in a project, it was mostly functional size [17]. Daneva [18] proposed to integrate
COCOMO II, Monte Carlo simulation, and portfolio management methods for effort estimation and
validated this approach by a case study. In this study, it was concluded that such an approach increases
the probability of success in projects with high uncertainty.
RICE (Reports, Interfaces, Conversions, Enhancements) objects of EA projects have also been
examined for measuring size. Wilson [19] developed a statistical model to predict size and effort with
RICE objects and conducted a case study. Case study results showed a strong correlation between the
RICE objects and the development effort [19].
Erasmus and Daneva [20] indicated that new in-memory database technologies such as SAP HANA
enabled all ERP solutions to run on the same platform, and this increased the level of uncertainties and
customizations in the projects. They analyzed if the Expert Judgment method could be applicable in
these conditions. Erasmus and Daneva continued their studies [21], [22] with an integrated method
including Function Points and Expert Judgments.
The applicability of Function Point based size measurement methods in EA projects has been
investigated in many studies. Vogelezang [23] measured size with COSMIC-FFP and estimated effort
by using historical productivity rates. Téllez [24] developed and explored a new size measurement
method, namely “eEPC-COSMIC” in his thesis study. Erasmus [25] proposed another function points-
based method, “COSMIC EPC”, in which COSMIC function points were calculated based on business
process models.
The “reuse” concept in EA projects has also been examined in the studies. Daneva [12], [26]
explored how to measure reuse in EA projects, where she used IFPUG function points for measuring
size. In the study [27], an approach to measuring reuse reflective size of EA projects was proposed.
This approach was implemented in an SAP project, and results showed that reuse reflective size led to
more accurate effort estimations.
An SLR (Systematic Literature Review) study [14] was published for size measurement and effort
estimation in this domain. 41 primary studies were reviewed in this study; it was concluded that various
size measurement/effort estimation methods were explored in this domain, and the most used ones were
function point-based ones. The main implication of the study was no consensus occurred on how to
measure the size of these kinds of projects.
Recently, cloud technology has been leading SaaS (Software as a Service) models for Enterprise
Applications as well. In this way, smaller-scale organizations have a chance to implement the EA. EA
has already a big share in the software industry, and by offering cloud-based implementation models,
the market share of EA is expected to increase. One of the most significant shortcomings of the EA
domain is the lack of a valid and effective size measurement method for these projects and the resulting
budget and schedule overruns. As the EA market share grows, this problem will become more visible.
3. The size measurement method
Considering the implications of the SLR [14] and exploratory case studies [27], [28] we conducted,
we developed a size measurement method for EA projects. We concluded that the most critical feature
of these projects that affecting sizing was “high reuse rates”. Reuse rates determines also customization
levels; if reuse rate is low, this means there would be more customization. There could be cases where
pre-built functionality is not sufficient for the customer requirements, even with customization. In these
cases, new transactions could be developed using EA’s programming language. Thus, we need to
measure “changes” where customization is required and “new” transactions are developed.
For measuring “changes” and “new” transactions, we propose to count “data groups” used in each
“transaction”. We defined a novel size unit, namely “Data Transaction Point (DTP)”, as a measure of
EA projects’ size. DTP is a size unit showing the number of data groups executed by transactions; in
other words, it shows data points of a transaction. We claim that a change in a transaction containing
multiple data groups has more effect on size than a change in a transaction containing one data group.
We argue that if a transaction has a large number of data groups, it will have a greater impact on size
since the change in that transaction will be reflected across all data groups.
We list data groups and transactions based on business processes. We defined three categories and
measured the size based on these categories:
Unchanged: For the business process, data groups in “no change required/used as is
transactions” are counted
Changed: For the business process, data groups in “change/customization required
transactions” are counted
New: For the business process, data groups in “new developed transactions” are counted
We calculate size as DTP for all the transactions in these categories and take to reach the size of the
business processes.
This proposed size measurement method has five main steps, which are presented in Figure 1.
•Determine the business processes included in the project
Step 1
•List transactions and data groups for the business processes
Step 2
•Identify required changes in transactions and new transactions needed
Step 3
•Calculate size for business processes
Step 4
•Sum up size for each category (unchanged, changed and new)
Step 5
Figure 1. Steps of the size measurement method
3.1. Determining business processes
In an EA project, based on the customer requirements, several business scenarios are implemented.
A business scenario includes many business processes. A “business process” is defined as a collection
of operations that takes a particular business input and convert it into a valuable business output through
a series of transactions [29].
In the scope determination phase of the EA projects, the business scenarios and corresponding
business processes are determined. In this first step of size measurement, the “Project Scope
Document” is reviewed, and “Business Scenarios” and “Business Processes” are listed for the project,
as presented in Figure 2.
Input(s) •Project Scope Document
•List of Business Scenarios
Output(s)
•List of Business Processes
Figure 2. Determining business processes
3.2. Defining transactions and data groups
The second step of the size measurement is listing “Transactions” and “Data Groups” included in
the business processes. For this step, the “Business Process Repository” of the EA could be used as the
primary resource. Inputs and outputs of this step are presented in Figure 3.
•List of Business Processes
Input(s)
•Business Process Repository of the EA
•List of Transactions
Output(s)
•List of Data Groups
Figure 3. Defining transactions and data groups
A “transaction” is basically defined as executing a program in EA terminology, whether transactions
are called via system-defined/user-specific transaction codes or invoked by other programs [30]. Many
programs in EA are run by users vith transaction codes, but also some programs are run by periodic
jobs or called by integration programs. For example, a report can be created and sent to users via e-mail
by a periodic program, or the included raw data can be transmitted to integrated systems by a program.
Because in all of these programs, data groups are processed to comply business process requirements,
we consider them as transactions, regardless of whether they are run by a user with a transaction code
or not.
In EA, each transaction uses a number of data groups to fulfill the business request. A “data group”
is defined as “a unique, non-empty, non-ordered group of data attributes, explaining the same one object
of interest” [31]. In an EA, there exist two main data categories: master data and transactional data.
Master data is permanent data that contains information for customers, suppliers, materials, etc.,
whereas transactional data is temporary data that contains information for purchase orders, invoices,
etc. [29]. We include both categories in the definition of “data group”.
It may be helpful to use an example to explain the concept of a data group for an EA. In the “sales
order processing” business process, “create sales order”, “change sales order”, and “display sales order”
are the main transaction codes. We can list four main data groups as “Customer”, “Material”, “Pricing”
and “Sales Order” for these transactions. “Customer”, “Material” and “Pricing” are master data
containing the required information to create a sales order. “Sales Order” is the transactional data that
occurred during the execution of the transactions. Consider a business requirement such as “If the
customer is a local customer and the price of the material is higher than 100 $, set the status of the sales
order as to be approved”. In order to apply the required customization to fulfill this requirement, these
four different data groups would be handled. Thus, we count all of these data groups in the size
calculation.
3.3. Identifying required changes and new transactions
Depending on the customer requirements, some transactions are used as is, and some transactions
are used by applying customization or code changes. If customer requirements cannot be met by the
pre-built functionality of the EA, new transactions can be developed using the programming language
of the EA.
In this step of the size measurement, change required transactions, new transaction needs, and related
data groups should be figured out. The main input of this step is “The Business Blueprint/Functional
Requirement Document” of the EA project. By examining in detail the Business Blueprint / Functional
Requirement Document of the project, it should be determined which category (unchanged, changed,
new) each transaction belongs to. Inputs and outputs of this step are presented in Figure 4.
Input(s) •Business Blueprint / Functional Requirement Document
•List of Transactions Requiring No-change
•List of Transactions Requiring Change
Output(s)
•List of New Transactions
•List of Data Groups in the New Transactions
Figure 4. Identifying required changes and new transactions
3.4. Calculating size for business processes
For each business process, the size for each category is calculated as DTP by counting data groups
in the transactions of that business process. The size as DTP for each category is calculated by using
the following equations in which DGi represents the total number of data groups in transaction i.
𝑁 (1)
𝑆𝑖𝑧𝑒𝑢𝑛𝑐ℎ𝑎𝑛𝑔𝑒𝑑 = ∑ 𝑢𝑖 ∙ 𝐷𝐺𝑖
𝑖=1
𝑁
𝑆𝑖𝑧𝑒𝑐ℎ𝑎𝑛𝑔𝑒𝑑 = ∑ 𝑐𝑖 ∙ 𝐷𝐺𝑖
𝑖=1
𝑁
𝑆𝑖𝑧𝑒𝑛𝑒𝑤 = ∑ 𝑛𝑖 ∙ 𝐷𝐺𝑖
𝑖=1
𝟏, 𝑖𝑓 𝑡𝑟𝑎𝑛𝑠𝑎𝑐𝑡𝑖𝑜𝑛 𝑖 𝑖𝑠 𝑎𝑛 𝑢𝑛𝑐ℎ𝑎𝑛𝑔𝑒𝑑 𝑡𝑟𝑎𝑛𝑠𝑎𝑐𝑡𝑖𝑜𝑛
ui = {
𝟎, 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒
𝟏, 𝑖𝑓 𝑡𝑟𝑎𝑛𝑠𝑎𝑐𝑡𝑖𝑜𝑛 𝑖 𝑖𝑠 𝑎 𝑐ℎ𝑎𝑛𝑔𝑒𝑑 𝑡𝑟𝑎𝑛𝑠𝑎𝑐𝑡𝑖𝑜𝑛
ci = {
𝟎, 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒
𝟏, 𝑖𝑓 𝑡𝑟𝑎𝑛𝑠𝑎𝑐𝑡𝑖𝑜𝑛 𝑖 𝑖𝑠 𝑎 𝑛𝑒𝑤 𝑡𝑟𝑎𝑛𝑠𝑎𝑐𝑡𝑖𝑜𝑛
ni = {
𝟎, 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒
3.5. Calculating total size
The total size of an EA project is the total size of the business processes included in that project.
Using the following equations, the total size of the project is calculated as DTP units in this step. BP
used in the equations represents the business processes.
𝑛
(2)
𝑆𝑖𝑧𝑒𝑢𝑛𝑐ℎ𝑎𝑛𝑔𝑒𝑑 = ∑ 𝑆𝑖𝑧𝑒𝑢𝑛𝑐ℎ𝑎𝑛𝑔𝑒𝑑 (𝐵𝑃𝑖 )
𝑖=1
𝑛
𝑆𝑖𝑧𝑒𝑐ℎ𝑎𝑛𝑔𝑒𝑑 = ∑ 𝑆𝑖𝑧𝑒𝑐ℎ𝑎𝑛𝑔𝑒𝑑 (𝐵𝑃𝑖 )
𝑖=1
𝑛
𝑆𝑖𝑧𝑒𝑛𝑒𝑤 = ∑ 𝑆𝑖𝑧𝑒𝑛𝑒𝑤 (𝐵𝑃𝑖 )
𝑖=1
4. Sample size measurement
For a better understanding of the method, we applied the method on a well-known business process,
the “Purchase Order” process. A “Purchase Order (PO)” is an official document showing the
description, quantity, price, and purchase conditions of the ordered products or services. It is created by
the buyer and forwarded to the vendor to start the purchasing process officially. The purchase order
process is included in the MM (Material Management) Module of SAP. The main transactions run for
this process are presented in Figure 7 in Appendix A.
In this process, the PO is created, changed, displayed, reported, and in most of cases an approval
(release) step is applied. A sample view for the PO is presented in Figure 5.
Figure 5. SAP sample view for purchase order display
4.1. Transactions and data groups
We use the Project Scope Document to understand that a process would be implemented within the
scope of that project. A sample section from the Scope Document showing that the PO process is
implemented in the project could be as in Figure 6.
The purchasing process will be carried out through the system for both investment and non-
investment purchases. MRP will be carried out through the system, minimum stock quantities for
materials will be defined, and Purchase Requests will be opened automatically according to the
needs. Purchase Orders will be created for purchase requisitions, and the approval process for both
purchase requisitions and purchase orders will be carried out through the system. The printout of
the purchase orders can be taken over the system or, if desired, sent to the seller by e-mail.
Figure 6. The scope definition for purchase order process
In order to list “Transactions” and “Data Groups” included in the business process, we use the
“Business Process Repository (BPR)” of the EA and EA itself as the resource. As described in the
method, we consider both master data and transactional data when determining Data Groups.
We firstly checked the master data list for the MM module defined in BPR of SAP, as presented in
Table 4 in Appendix B, and determined the master data of the PO process as “Buyer”, “Vendor”,
“Material”, “Conditions”, “Supplement” and “Release Strategy”. “Purchase Order” is the main
transactional data of this process. As described in the scope, PO is created depending on the Purchase
Requisition, so we determined “Purchase Requisition” as another transactional data.
We listed related “transactions” and “data groups” of the PO process as presented in Table 1.
Table 1
Data groups and transactions for the PO process
Business Process Process Step Data Groups Transactions
Purchase Requisition,
Create, Change,
Purchase Order,
Purchase Order Maintain Purchase Maintain Supplement,
Buyer, Vendor,
Processing Order Mass Maintenance,
Material, Conditions,
Display
Supplement
Purchase Order,
Purchase Order Release Purchase Buyer, Vendor, Individual Release,
Processing Order Material, Conditions, Collective Release
Release Strategy
Purchase Order, By Vendor,
Purchase Order Report Purchase
Buyer, Vendor, By Material, General,
Processing Order
Material, Conditions By Purchase Order
4.2. Required changes and new transactions
After listing “transactions” and “data groups”; change required transactions, new transaction needs
and related data groups should be figured out. For this purpose, we use the “Business Blueprint
Document” as the resource. The “Business Blueprint Document” includes both configuration and
customization details of the project, and new transaction requirements are also defined in this document.
For this sample calculation, we listed “customer requirements”, “related transactions”, and “new
transactions and their data groups” for the PO process in Table 2.
Table 2
List of the change requests for the PO process
PO – Required Changes & New Transactions
CR.1 “The purchase order will be only created by entering a purchase requisition as
a reference document. If the entered purchase requisition’s approvals are not
complete, the system will not allow the purchase order creation, and an error
message will return stating that approvals are not complete”
change in purchase order creation
-transactions (create)
CR.2 “When a user tries to change a PO, the purchase order, the system will check
the PO approval status. If any approval is given for the PO, a pop-up will appear
saying, "PO is approved; if you save changes, SAS approvals will be initialized". If
the user approves, the change will be saved, and approvals will be initialized”
change in purchase order change
-transactions (change, mass maintenance)
CR.3 “When an approval for the purchase order is given, the next approver will be
notified by e-mail”
new transaction for PO release, same data groups as individual & mass release
-transactions (e-mail)
CR.4 “A new PO good receipt report is required for PO showing PO details, good
receipt document, batch numbers”
new transaction for PO good receipt report
-transactions (report PO good receipt)
-data groups (purchase order, buyer, vendor, material, conditions, good
receipt document, batch)
4.3. Calculating Size
For the business process, we calculated the size of each category by using the size calculation
equations. The calculation sheet is presented in Table 3.
Table 3
Size calculation for the PO process
Size Size Size
#Data
Transaction Data Groups ui ci ni unchanged changed new
Groups
(DTP) (DTP) (DTP)
Purchase Requisition,
Purchase Order, Buyer,
Create 7 0 1 0 0 7 0
Vendor, Material,
Conditions, Supplement
Purchase Requisition,
Purchase Order, Buyer,
Change 7 0 1 0 0 7 0
Vendor, Material,
Conditions, Supplement
Purchase Requisition,
Maintain Purchase Order, Buyer,
7 1 0 0 7 0 0
Supplement Vendor, Material,
Conditions, Supplement
Purchase Requisition,
Mass Purchase Order, Buyer,
7 0 1 0 0 7 0
Maintenance Vendor, Material,
Conditions, Supplement
Purchase Requisition,
Purchase Order, Buyer,
Display 7 1 0 0 7 0 0
Vendor, Material,
Conditions, Supplement
Purchase Order, Buyer,
Individual Vendor, Material,
6 1 0 0 6 0 0
Release Conditions, Release
Strategy
Purchase Order, Buyer,
Collective Vendor, Material,
6 1 0 0 6 0 0
Release Conditions, Release
Strategy
Purchase Order, Buyer,
Vendor, Material,
E-mail 6 0 0 1 0 0 6
Conditions, Release
Strategy
Purchase Order, Buyer,
Report by
Vendor, Material, 5 1 0 0 5 0 0
Vendor
Conditions
Purchase Order, Buyer,
Report by
Vendor, Material, 5 1 0 0 5 0 0
Material
Conditions
Purchase Order, Buyer,
Report General Vendor, Material, 5 1 0 0 5 0 0
Conditions
Size Size Size
#Data
Transaction Data Groups ui ci ni unchanged changed new
Groups
(DTP) (DTP) (DTP)
Purchase Order, Buyer,
Report by
Vendor, Material, 5 1 0 0 5 0 0
Purchase Order
Conditions
Purchase Order, Buyer,
Vendor, Material,
Report PO GR 7 0 0 1 0 0 7
Conditions, Good Receipt
Document, Batch
46 21 13
Based on these calculations, size of the PO process is as follows:
Size unchanged = 46 DTP
Size changed = 21 DTP
Size new = 13 DTP
5. Conclusions
We developed a size measurement method for EA projects. In this method, we proposed measuring
"changes" and “new” transactions where pre-built functionality does not fulfill customer requirements.
We counted “data groups” in the categorized transactions. Claiming that a change in a transaction with
one data group would not have the same effect on the size as a change in a transaction with multiple
data groups, we defined a novel size measurement unit, namely Data Transaction Point (DTP), for EA
projects. We measured size as DTP in three categories: “unchanged (no change required transactions)”,
“changed (customization required transactions)”, and “new (new developed transactions)”. We defined
five main steps to apply this method as presented in Figure 1. We implemented the method on a well-
known business process, “Purchase Order”.
The main contribution of this study is the proposed size measurement method. This is a novel size
measurement method developed by taking into account the unique characteristics of EA projects. We
claim that this size measurement method can be applied by a novel user with general knowledge about
the implemented EA. Using this method could lead to reducing size measurement variances and
subjectivity. We believe that, as the method is used many times in an organization, productivity values
will be more reliable, and subsequent effort estimations will be more accurate.
The second contribution is the novel size measurement unit DTP for EA projects. This specific size
measurement unit can be used as a base unit for these types of projects. Since size measurement is
performed at the business process level in the proposed method, size measurement unit DTP can be
used for of the project management processes such as monitoring, planning, and control.
Another contribution of this thesis is the useful yet simple definition and application of the concepts
“reuse” and “change” in EA projects. By making these definitions, we have revealed how EA projects
can be evaluated.
6. Future Work
In order to observe the validity of the size measurement method, we plan to conduct a multiple case
study with different EA projects. This size measurement method can also be applied in other change-
intensive project types like software maintenance and upgrade projects. We also plan to extend our
studies to evaluate the method’s applicability for these types of projects.
There exist some EA project tools, such as SAP Solution Manager, which are also used to generate
automatically Business Blueprint document. Since these tools comprise the required data for size
measurement, the proposed method can be automated via these tools. This would reduce the overall
time required for the DTP calculation.
7. Appendices
7.1. Appendix-A
Figure 7. SAP sample view for transactions of the PO process
7.2. Appendix-B
Table 4
BPR master data list for the SAP MM module
Organizational Object
Name Package Module
Area Type
Master
Procurement Buyer BP_LIB_R3MM MM
Data
Master
Procurement Conditions (Procurement) BP_LIB_R3MM MM
Data
Master
Procurement Contract (Purchasing) BP_LIB_R3MM MM
Data
Master
Procurement Delivery Address BP_LIB_R3MM MM
Data
Master
Procurement Manufacturer Part Number BP_LIB_R3MM MM
Data
Organizational Object
Name Package Module
Area Type
Master
Procurement Purchasing Info Record BP_LIB_R3MM MM
Data
Master
Procurement Quota Arrangement BP_LIB_R3MM MM
Data
Master
Procurement Release Strategy with Classification BP_LIB_R3MM MM
Data
Master
Procurement Service Condition BP_LIB_R3MM MM
Data
Master Settlement Accounting for Conditions
Procurement BP_LIB_R3MM MM
Data Requiring Subsequent Settlement
Master
Procurement Source List BP_LIB_R3MM MM
Data
Master
Procurement Standard Service Catalog BP_LIB_R3MM MM
Data
Master
Procurement Sustainability Information Record BP_LIB_R3MM MM
Data
Master
Procurement Vendor Evaluation BP_LIB_R3MM MM
Data
Master
Procurement Vendor Master Record BP_LIB_R3 MM
Data
Master
Procurement Vendor Rebate Arrangements BP_LIB_R3MM MM
Data
Master
Procurement Vendor Sustainability Record BP_LIB_R3MM MM
Data
8. Acknowledgements
We would like to thank the support of the Scientific and Technological Research Council of Turkey
(TUBITAK) ARDEB 1001 [Project number: 121E389] program.
9. References
[1] O. Volkoff, D. M. Strong, and M. B. Elmes, “Understanding enterprise systems-enabled
integration,” Eur. J. Inf. Syst., vol. 14, no. 2, pp. 110–120, 2005.
[2] B. Ramdani, D. Chevers, and D. A. Williams, “SMEs’ adoption of enterprise applications: A
technology-organisation-environment model,” J. Small Bus. Enterp. Dev., 2013.
[3] T. H. Davenport, Mission critical: realizing the promise of enterprise systems. Harvard Business
Press, 2000.
[4] M. L. Markus and C. Tanis, “The enterprise systems experience-from adoption to success,”
Fram. domains IT Res. Glimpsing Futur. through past, vol. 173, no. 2000, pp. 173–207, 2000.
[5] M. Daneva and R. Wieringa, “Cost estimation for cross-organizational ERP projects: Research
perspectives,” Softw. Qual. J., vol. 16, no. 3, pp. 459–481, 2008, doi: 10.1007/s11219-008-9045-
8.
[6] W. B. Frakes and K. Kang, “Software reuse research: Status and future,” IEEE Trans. Softw.
Eng., vol. 31, no. 7, pp. 529–536, 2005.
[7] M. Mijač, R. Picek, and D. Andročec, “Determinants of ERP Systems as a Large-Scale Reuse
Approach,” in MATEC Web of Conferences, 2019, vol. 292, p. 3007.
[8] L. Brehm, A. Heinzl, and M. L. Markus, “Tailoring ERP systems: a spectrum of choices and
their implications,” in Proceedings of the 34th annual Hawaii international conference on
system sciences, 2001, pp. 9-pp.
[9] B. Light, “The maintenance implications of the customization of ERP software,” J. Softw. Maint.
Evol. Res. Pract., vol. 13, no. 6, pp. 415–429, 2001.
[10] M. Keil and A. Tiwana, “Relative importance of evaluation criteria for enterprise systems: a
conjoint study,” Inf. Syst. J., vol. 16, no. 3, pp. 237–262, 2006.
[11] “The 2022 ERP Report,” Panaroma Consulting Group, 2022. https://www.panorama-
consulting.com/resource-center/erp-report/.
[12] M. Daneva, “Understanding functional reuse of ERP requirements in the telecommunication
sector: An empirical study,” in Proceedings - 2014 Joint Conference of the International
Workshop on Software Measurement, IWSM 2014 and the International Conference on Software
Process and Product Measurement, Mensura 2014, 2014, pp. 216–221, doi:
10.1109/IWSM.Mensura.2014.42.
[13] E. Stensrud, “Alternative approaches to effort prediction of ERP projects,” Inf. Softw. Technol.,
vol. 43, no. 7, pp. 413–423, 2001, doi: 10.1016/S0950-5849(01)00147-1.
[14] N. K. Omural and O. Demirors, “Effort estimation for ERP projects - A systematic review,” in
Proceedings - 43rd Euromicro Conference on Software Engineering and Advanced
Applications, SEAA 2017, 2017, pp. 96–103, doi: 10.1109/SEAA.2017.68.
[15] B. Ozkan, O. Turetken, and O. Demirors, “Software functional size: For cost estimation and
more,” in European Conference on Software Process Improvement, 2008, pp. 59–69.
[16] C. Gencel and O. Demirors, “Functional size measurement revisited,” ACM Trans. Softw. Eng.
Methodol., vol. 17, no. 3, pp. 1–36, 2008.
[17] M. Daneva, “Preliminary results in a multi-site empirical study on cross-organizational ERP size
and effort estimation,” Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect.
Notes Bioinformatics), vol. 4895 LNCS, pp. 60–71, 2008, doi: 10.1007/978-3-540-85553-8_5.
[18] M. Daneva, S. Wettflower, and S. De Boer, “Uncertainty in ERP effort estimation: A challenge
or an asset?,” in Lecture Notes in Computer Science (including subseries Lecture Notes in
Artificial Intelligence and Lecture Notes in Bioinformatics), vol. 5338 LNCS, no. i, 2008, pp.
208–222.
[19] W. Rosa, “Empirical effort and schedule estimation for enterprise resource planning projects,”
in Proceedings of the 2012 Joint Conf. of the 22nd Int. Workshop on Software Measurement and
the 2012 7th Int. Conf. on Software Process and Product Measurement, IWSM-MENSURA 2012,
2012, pp. 190–197, doi: 10.1109/IWSM-MENSURA.2012.35.
[20] I. P. Erasmus and M. Daneva, “ERP effort estimation based on expert judgments,” in
Proceedings - Joint Conference of the 23rd International Workshop on Software Measurement
and the 8th International Conference on Software Process and Product Measurement, IWSM-
MENSURA 2013, 2013, pp. 104–109, doi: 10.1109/IWSM-Mensura.2013.25.
[21] P. Erasmus and M. Daneva, “ERP services effort estimation strategies based on early
requirements,” CEUR Workshop Proc., vol. 1342, no. 1, pp. 83–99, 2015.
[22] P. Erasmus and M. Daneva, “An experience report on ERP effort estimation driven by quality
requirements,” CEUR Workshop Proc., vol. 1342, pp. 126–139, 2015.
[23] F. Vogelezang, “Using COSMIC-FFP for sizing, estimating and planning in an ERP
environment,” in 16th International Workshop on Software Measurement and DASMA Metrik
Kongress, 2006, pp. 327–342.
[24] F. M. Téllez, “Solving the size estimation problem in ERP project context : the eEPC- COSMIC
approach,” University of Twente, 2009.
[25] I. P. Erasmus, “The COSMIC EPC method An ERP functional size measurement method
delivering time and cost estimates,” University of Gothenburg, 2012.
[26] M. Daneva, “Integrating reuse measurement practices into the ERP requirements engineering
process,” Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes
Bioinformatics), vol. 4034 LNCS, pp. 112–126, 2006, doi: 10.1007/11767718_12.
[27] O. Demirörs and N. Küçükateş Ömüral, “Exploring reuse levels in ERP projects in search of an
effort estimation approach,” in Proceedings - 44th Euromicro Conference on Software
Engineering and Advanced Applications, SEAA 2018, 2018, pp. 191–197, doi:
10.1109/SEAA.2018.00038.
[28] N. K. Ömüral and O. Demirörs, “Effort estimation methods for ERP projects based on function
points: A case study,” in ACM International Conference Proceeding Series, 2017, vol. Part
F1319, pp. 199–206, doi: 10.1145/3143434.3143464.
[29] E. Monk and B. Wagner, Concepts in enterprise resource planning. Cengage Learning, 2012.
[30] T. Orosz, “Analysis of SAP Development tools and methods,” in 2011 15th IEEE International
Conference on Intelligent Engineering Systems, 2011, pp. 439–443.
[31] “ISO - ISO/IEC 19761:2011 - Software engineering — COSMIC: a functional size measurement
method.” https://www.iso.org/standard/54849.html (accessed Oct. 22, 2021).