An approach to estimate the size of ERP package using package points

    Efficiency analysis of ERP projects-customization perspective Sudhaman Parthasarathy, Srinarayan Sharma PII: DOI: Reference:

S0920-5489(15)00118-X doi: 10.1016/j.csi.2015.10.003 CSI 3072

To appear in:

Computer Standards & Interfaces

Received date: Revised date: Accepted date:

19 August 2015 14 October 2015 14 October 2015

Please cite this article as: Sudhaman Parthasarathy, Srinarayan Sharma, Efficiency analysis of ERP projects-customization perspective, Computer Standards & Interfaces (2015), doi: 10.1016/j.csi.2015.10.003

This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

ACCEPTED MANUSCRIPT EFFICIENCY ANALYSIS OF ERP PROJECTS-CUSTOMIZATION PERSPECTIVE Sudhaman Parthasarathy 1, Srinarayan Sharma2 1

Indian Institute of Management (IIM) Kashipur Uttarakhand, India [email protected]

MA

NU

2

SC

RI

PT

Department of Computer Applications Thiagarajar College of Engineering Madurai, India [email protected] [Corresponding Author]

D

Abstract

TE

Enterprise Resource Planning (ERP) packages developed by ERP vendors are designed not only to standardize the existing business processes of the implementing organization, but also to bring in some of

AC CE P

the best practices of the industry. There are previous research studies on the assessment of the efficiency of standard ERP projects; however, to date no research has been conducted to assess the efficiency of ERP projects from the point of view of customization. Assessing the efficiency of ERP projects is vital for benchmarking the best-of-breed ERP projects. In this study we examine the efficiency of customized ERP projects using Data Envelopment Analysis (DEA). We also examine the relationship between the degree of customization in an ERP project and its efficiency. The results suggest that the ERP system customization significantly affects the efficiency of ERP projects. We also discuss the implications of the results for research and practice. Keywords: Enterprise Resource Planning (ERP), Data Envelopment Analysis (DEA), customization, efficiency, software projects.

1

ACCEPTED MANUSCRIPT AN APPROACH TO ESTIMATE THE SIZE OF ERP PACKAGE

PT

USING PACKAGE POINTS

Abstract:

RI

Enterprise Resource Planning (ERP) packages are information systems that automate the

SC

business processes of organizations thereby improving their operational efficiency substantially. ERP projects that involve customization are often affected by inaccurate estimation of efforts.

NU

Size of the software forms the basis for efforts estimation. Methods used for effort estimation either employ function points (FP) or lines of code (LOC) to measure the size of customized

MA

ERP packages. Literature review reveals that the existing software size methods which are meant for custom-built software products may not be suitable for COTS products such as customized ERP packages. Hence, the effort estimation using conventional methods for customized ERP

D

packages may not be accurate. This paper proposes a new approach to estimate the size of

TE

customized ERP packages using Package Points (PP). The proposed approach was validated with data collected from 14 ERP projects delivered by the same company. A positive correlation was

AC CE P

observed between Package Points (PP) and the efforts of these projects. This result indicates the feasibility of our proposed approach as well as the positive climate for its utility by the project managers of future ERP projects. Lastly, we examine the implication of these results for practice and future research scope.

Keywords: Customization, ERP projects, Efforts, Function points, Package points

2

ACCEPTED MANUSCRIPT 1.0 Introduction Enterprise Resource Planning (ERP) systems are packaged software solutions that automate the business processes of an organization. Analyst firms, such as AMR Research

PT

(Eschinger, 2005; Jacobson et al., 2007; Hamerman, 2008) indicate that there exists a growing demand for such information systems across manufacturing industries and business firms. The

RI

high rates of troubled ERP implementations, delayed ERP deployments and outright

SC

cancellations calls for review of the effort estimation practices to systematically deal with the software size measurement in ERP projects.

NU

ERP systems are information systems that have different development cycle and deployment methods when compared to traditional software products (Parthasarathy and

MA

Sharma, 2014). Conventional wisdom holds that “vanilla implementations” of ERP packages such as SAP R/3 are much more likely to be successful than customized ERP package implementations (Brehm et al., 2001). However, several previous studies ((Brehm et al., 2001;

D

Aslam et al., 2012; Millet, 2013; Parthasarathy and Daneva, 2014; Parthasarathy and Sharma,

TE

2014) have observed that many implementing organizations have had to modify ERP package to meet essential business needs and hence mandates customization during implementation.

AC CE P

Project managers involved in the development of customized ERP packages have to measure their package size in iterations as the requirements would keep changing due to customization. In such ERP projects, estimating the project efforts based on the package size using the existing methods would be a herculean task. Recent studies (Daneva, 2010; Tsai et al., 2012; Chou and Wu, 2013; Sudhaman and Thangavel, 2015) also indicate that the effort estimation for ERP projects is mostly inaccurate. This is quite obvious; as software size forms the basis for effort estimation (Boehm et al., 2000).Hence accurate effort estimation for ERP projects is possible only when software size could be measured accurately in these projects. Today, it is well known that a typical ERP project includes business process customization and system customization, each of which matches the business needs of the client organization (Daneva, 2010). This in turn, implies that the package size in these projects needs to be measured afresh and accordingly the project efforts and costs have to be re-estimated. A potential factor that can affect the accuracies of the established effort estimation models is the size of the software package (Wilkie et al., 2011). For ERP project managers to be adequately 3

ACCEPTED MANUSCRIPT prepared for this endeavor, they need to look at alternate approaches for package size measurement in their ERP projects. Previous research on ERP projects (Stensrud, 2001; Stamelos et al., 2003; Janssens et al.,

PT

2008) reveal that the existing methods for estimation of efforts of standard ERP implementation and customized ERP packages are found to be the same. However, these methods which are

RI

meant for custom-built software products may not be suitable for COTS products such as

SC

customized ERP packages (Daneva, 2010; Tsai et al., 2012; Chou and Wu, 2013; Sudhaman and Thangavel, 2015). Hence, efforts estimated for such customized ERP packages may not be

NU

accurate (Stensrud, 2001). Examples of underestimated ERP projects (Markus et al., 2000; McAffee, 2003; Daneva and Wieringa, 2008) suggest that making average assumptions might

MA

have a profound long-term effect on the ERP adopter, meaning a failure to meet growth targets (Markus, 2000), a loss of market edge (Daneva and Wieringa, 2008), or even a bankruptcy (McAfee, 2003).Thus, this paper proposes an approach to estimate the size of customized ERP

D

package using Package Points (PP).

TE

Existing methods (Stensrud, 2001; Jorgensen and Shepperd, 2007) for effort estimation of customized ERP packages either use function points (FP) or lines of code (LOC) to size the

AC CE P

software. The term ‘efforts,’ also called ‘project efforts,’ refers to the manpower required for the development of the software product in a software project (Boehm et al., 2000). The FP are a unit of measurement to express the amount of business functionality of an information system (as a product) provides to a user. Function points represent software size. The LOC is a software metric used to measure the size of a computer program. The size is captured by counting the number of lines in the text of the program's source code. The complexity in function point measurement process grows exponentially as the software projects grow in size (Lavazza et al., 2013). Hence, in our approach, we measure the size of customized ERP packages using package points instead of the FP and the LOC. We define the term “Package Points (PP)” as the frame of reference or unit of measure for the size of an ERP package. Package points are calculated based on the tasks points and complexity associated with the different ERP package customization approaches namely configuration, functionality, RICE (Reports, Interfaces, Conversions, and Extensions also known

4

ACCEPTED MANUSCRIPT as Enhancements) and user interface design (Brehm et al., 2001; Luo and Strong, 2004; Dittrich et al., 2009).

PT

ERP package size measurement and efforts estimation remain critical components in the ERP requirements engineering process (Daneva, 2010). Our objective is to provide ERP project

RI

managers with a support vehicle which helps them (i) achieve an increased understanding of the customized ERP package size measurement (ii) estimate effort based on package size for ERP

SC

projects , and (iii) gain awareness of how package size and efforts estimation in ERP projects matter in terms of efficiency of projects.

NU

Our approach demonstrates that it is possible to find a trade-off between ERP projects that require more effort than expected and those that require less. The practical implications of

MA

our approach is that an ERP project manager (i) no longer must live with the current less reliable methods for software size measurement and effort estimation based on these size measures and (ii) can make decisions such as how to accelerate the ERP project in a way that can cause a

TE

intact.

D

desired effect on the efficiency of the project while keeping the package size and the efforts

We suggest our approach should be used in ERP projects that deal with the development

AC CE P

of a customized ERP package. We validated this approach with data collected from 14 ERP projects delivered by the same company. A positive correlation was observed between the Package Points (PP) of the customized ERP packages and the actual efforts of these projects. This result indicates the feasibility of the proposed approach and the positive climate for its utility by the project managers of future ERP projects. The remainder of this paper proceeds as follows. In Section 2 we provide background information on the need for accurate estimation of ERP project efforts based on package size. Also, we present the limitations in the existing methods for customized ERP package size measurement and effort estimation practice for ERP project. We describe our proposed approach in Section 3. Our application of the case study research method is explained in Section 4. It is followed by a brief discussion on the ERP data we used to validate our approach. Section 5 presents a discussion on our results and their implications for practice, followed by validity concerns. Section 6 presents concluding remarks and areas for future research.

5

ACCEPTED MANUSCRIPT 2.0 Background and related work This section provides background of size and effort estimation in ERP projects and summarizes related research works emphasizing the need for accurate size estimation of

PT

customized ERP packages. Second, it explores current approaches used for ERP package size

SC

2.1 Need for accurate estimation of ERP package size

RI

measurement and the limitations as observed from previous research studies.

For large scale IT projects such as ERP, accurate effort prediction becomes a difficult

NU

task for the project managers (Stensurd and Myrtveit, 2003; Parthasarathy and Anbazhagan, 2008; Huang et al., 2008). Researchers and practitioners acknowledge the need for better software size measurement methods and thereby a better effort prediction systems for ERP

MA

projects (Daneva, 2010; Wilkie et al., 2011; Parthasarathy, 2012). In the past decade, a great deal of work has focused on understanding the reasons for

D

inaccurate estimation of project efforts in traditional software projects as well as COTS projects

TE

such as ERP (Stensrud, 2001; Stamelos et al., 2003; Daneva, 2010; Tsai et al., 2012; Chou and Wu, 2013;) the factors that influence the process of efforts estimation for ERP projects (Menzies

AC CE P

et al., 2006; Morgenshtern et al., 2007; Jorgensen and Shepperd, 2007; Abrahao et al., 2010), and the impact of efforts over efficiency of ERP projects (Stensurd and Myrtveit, 2003; Parthasarathy, 2012; Sudhaman and Thangavel, 2015) however, till date, no research study has come out with an exclusive method or a model to deal with size estimation of customized ERP package.

ERP packages have been developed by ERP vendors in response to new technologies and emerging business requirements (Parthasarathy and Sharma, 2014). Although these packages provide competitive benefits to the implementing organizations, Requirements Engineering (RE) based issues (for e.g., effort estimation, ERP package size measurement) in ERP projects are a major concern (Daneva, 2004; Subramanian et al., 2007; Chou and Chang, 2008; Ceke and Milasinovic, 2015). About 72% of ERP projects fail to deliver the anticipated benefits (Parthasarathy and Daneva, 2014). Some of these projects have ended in failure due to poor management of RE processes (Anbazhagan, 2008; Nozdrina, 2009; Ram et al., 2013; Parthasarathy and Daneva, 2014). These observations from the previous research works are mostly masked as the ERP 6

ACCEPTED MANUSCRIPT projects are focused largely from managerial aspects than software engineering perspective. It is observed that ERP package size can be a useful metric for predicting the effort required to develop customized ERP package successfully (Janssens et al., 2008). Also, Kusters et al.,

RI

2.2 Current approaches for ERP package size measurement

PT

(2007) observe the size of an ERP package as a major cost driver in ERP projects.

The very nature of development of ERP packages differ from traditional software

SC

packages (Stensurd and Myrtveit, 2003; Parthasarathy and Daneva, 2014). Development of ERP packages involves collecting requirements from multiple sources. For example, in the case of a

NU

banking application, requirements are collected from the stakeholders of different banks - both private sector and public sector located in different geographical locations. Hence, in packaged

MA

software solutions like ERP systems, it is difficult to completely mould the system to fit the existing business processes of the implementing organization. As a result, in many ERP projects,

D

some degree of customization of both ERP systems and business processes is required (Ram et al., 2013; Parthasarathy and Sharma, 2014).

TE

On the contrary, in traditional software projects, products are designed and built for a

AC CE P

particular client organization. These projects use conventional software process models to collect requirements at the initial stage of development, with the anticipation that the resulting product will meet these requirements. Hence the existing approaches to measure the software size in traditional projects are not able to measure the size of the customized packaged software which is being developed in iterations to make it a mature software system. Most of the existing software size measurement systems have been designed with custom software projects in mind (Stensrud, 2001; Idri et al., 2015). Unlike projects that use a single size measure such as function points or lines of code, typical ERP size measures during the process of customization include counts of the following: users, sites, business units or legal entities, software interfaces, EDI interfaces, data conversion software and data conversions, customdeveloped reports, modified screens and ERP modules (Stensrud, 1998; Stensrud, 2001; Parthasarathy and Anbazhagan, 2008; Rosa et al., 2013). Existing methods for ERP package size measurement has its own limitations to handle these customization parameters.

7

ACCEPTED MANUSCRIPT Many effort estimation methods have been proposed during the last two decades. These methods include estimation by experts (Jorgensen and Sjoberg, 2004), analogy-based estimation (Jorgensen et al., 2003) and parametric estimation (Kaczmarek and Kucharski, 2004). From the

PT

literature, we find that effort prediction systems based on software size (FPs or LOCs) include parametric models such as Checkpoint (Ferens, 1996), Price S/SP (Cuelenaere et al., 1987),

RI

SASET (Ferens, 1996), SEER-SEM (Ferens, 1996), SLIM (Ferens, 1996) and (Kemerer, 1987),

SC

JENSEN (Cuelenaere et al., 1987; Martin, 1988), ESTIMACS (Kemerer, 1987), BYL (Kemerer, 1987), WICOMO (Kemerer, 1987), SYSTEM-3 (Kemerer, 1987), SPQR/20 (Kemerer, 1987),

NU

object oriented models (Jenson and Bartley, 1991; Zhou et al., 2014) and Non-parametric model such as ANGEL (Nozdrina, 2009). These models have the same limitations as COCOMO 2.0

or FPs (Stensrud, 2001; Daneva, 2010).

MA

with respect to the choice of predictor variables where the main predictor variable is either LOC

Very few papers in the literature investigated the size of software applications based on

D

the function point analysis (e.g. IFPUG, COSMIC) (Stensrud, 2001; Abrahao et al., 2010;

TE

Daneva, 2010; Martino et al., 2011; Rosa et al., 2013). Overall, in the last two decades, only a handful of research studies investigated the accuracy of early size estimation approaches. In

AC CE P

particular, these studies indicate the limitations of the effort estimation based on software size measures (FPs or LOCs). For instance, they were depending on functional size of ERP package (Hericko and Zivkovic, 2008; Abrahao et al., 2010), they were not designed to handle multiple outputs from ERP package (Stensurd and Myrtveit, 2003; Parthasarathy and Anbazhagan, 2008; Lavazza et al., 2013), they were not developed to deal with business process complexity (Daneva, 2004; Tsai et al., 2012) or did not consider the ERP package customization requirements (Chou and Wu, 2013; Sudhaman and Thangavel, 2015). None of the existing research studies on ERP projects offer specific algorithms, exclusive methods or models to help the ERP project managers to measure the ERP package size and accurately estimate the project effort from it. Thus, we observe that there is a need for an alternate approach to measure the ERP package size that would consider the customization aspects of ERP that have not been taken care of in function point analysis.

8

ACCEPTED MANUSCRIPT 3.0 The Approach: Package Points based ERP package size estimation (PPSE) In the field of IS/IT projects, various research studies have studied the phenomenon of

PT

ERP customization from the perspective of software cost and effort estimation (Subramanian et al., 2007; Daneva and Wieringa, 2008; Lee et al., 2008; Parthasarathy and Anbazhagan, 2008;

RI

Akkiraju and Geel, 2010; Rosa et al., 2013). The sizing approach for ERP packages discussed in the literature relies either on the functional size of the package or the RICE (Reports, Interfaces,

SC

Conversions, and Extensions also known as Enhancements) components (Rosa et al., 2013). However, the customization practices adopted by ERP vendors during the implementation

NU

involve four different types of customization requirements (Brehm et al., 2001; Luo and Strong, 2004; Dittrich et al., 2009). They are: (i) Configuration requirements (ii) New functional

MA

requirements (iii) RICE components (iv) User Interface Design requirements. During ERP customization, configuration requirements are fulfilled by just configuring the ERP packages. These requirements are implemented by changing the parameters or

D

properties in the tables of ERP database to reflect organizational features. Other requirements are

TE

met by adding new functionality. This requires writing new codes and modifying the database. Some requirements are met through RICE components, while few requirements may demand

AC CE P

modifying the user interface design without altering the existing database design or source code. We note that the existing approaches for ERP package size measurement assume bottomup thinking where the ERP system is segmented in terms of business requirements. Based on this, various functional and non-functional requirements are quantified to size the ERP package. The package focuses on the level of business processes of the implementing organization and proceeds with package size estimation pertaining at that level. However, these studies offer very few guidelines for the estimation of ERP packages size while considering the different customization requirements discussed above. This leaves a gap in the literature and which we seek to fill through this paper.

9

NU

SC

RI

PT

ACCEPTED MANUSCRIPT

MA

Figure 1 PPSE: a high level view Without capturing requirements precisely, a software package won’t be able to deliver software that addresses the needs of the customers. Even small imprecisions in the requirements

D

need to be corrected to keep the software project on the right track. It's essential that our software

TE

package meets our customers' needs or market opportunity which it’s intended to address. As such, the proposed approach does not define any sub-routine to verify the completeness and

AC CE P

consistency of requirements, as it is beyond the scope of this study. We expect the ERP team to consider some existing methods published in the software engineering literature such as (Alagar et al., 2005; Soffera et al., 2005; Ai et al., 2013) that were specifically developed to verify the consistency and completeness of the requirements specified by the customer. Capturing all the requirements from the customer at an early stage of a software project (whether it is traditional or packaged software like ERP) is a difficult task (Erasmus and Daneva, 2013). In this study, we have not included any sub-routine to the “PPSE” approach to verify the completeness and consistency of requirements, as it is beyond the scope of this study. However, we make a note that the proposed approach captures the customer’s requirements for customized ERP packages from four different dimensions namely configuration, new functionality, reusability, and design interface than the existing practice of classifying the requirements as functional and non-functional. We deem that such requirement analysis at macro level would certainly reduce the degree of incompleteness in the software requirements specification (SRS) used by the Requirements Engineering (RE) team of ERP projects. 10

ACCEPTED MANUSCRIPT Any degree of ERP customization requires any one of the four types of customization requirements listed in Figure 1 or a combination of it to be fulfilled by the vendor. Hence, during the process of estimating the size of the customized ERP packages, different customization

PT

requirements should be taken into consideration. In this paper, we propose a unique approach, referred as PPSE, to size customized ERP packages. The steps involved in the “PPSE” are shown

RI

in Figure 1. From the figure, we find that the business requirements from the customer are

SC

initially received by the ERP team as part of the ERP customization process. From these business requirements, the configuration requirements (CR), the functional requirements (FR), the RICE

NU

components (RC) and the user interface design requirements (DR) are identified by the Requirements Engineering (RE) team members of the ERP projects. For each of these four types

MA

of requirements (CR, FR, RC, DR), the tasks points are estimated. We define the term tasks points (TP) as the summation of the number of tasks and processes required to implement a requirement while taking into account its complexity. To

D

implement each requirement (CR, FR, RC or DR), we must execute a number of tasks/processes.

TE

The complexity of each task will vary from one requirement to another. The task complexity may be induced by the demand for features such as multi-currency, multi-lingual, concurrent

AC CE P

users, network architecture, remote access, legacy system complexity, hardware/infrastructure requirements, etc. As a result, we rated the complexity of each task, which we refer to as the complexity value (CV).

Consistent with function point analysis (Boehm et al., 2000), in our approach, ERP vendors are expected to develop criteria to determine whether the complexity of a particular task is low, medium or high. Nonetheless, the determination of complexity is somewhat subjective. In our approach, if there is no complexity for a given task, the CV is 1. Similarly, it is 2 for low, 5 for medium and 7 for high complexity. Once the tasks points are calculated for each of CRs, FRs, RCs and DRs, the summation of these tasks points would yield the package points (PP). This denotes the size of customized ERP package. Below, we present mathematically, the definition of the package points.

11

ACCEPTED MANUSCRIPT

NU

SC

RI

PT

(1)

At the time of our case study execution, the company Axys invited their Requirements

MA

Engineering (RE) team members to operationalize the processes of the proposed approach “PPSE” (please refer to Fig. 1). Initially, all the business requirements (BR) of the customer were

D

documented completely using a Microsoft Excel Sheet. Then, extracting the CR, the FR, the RC and the DR from these BR was carried out by RE team and recorded the same in the Microsoft

TE

Excel Sheet. To make the computation of the Package Points (PP) easier, a tool was developed

AC CE P

and used by the authors in our case study. This tool would take the Excel sheets as input and provides user interface for the RE team to provide values for the Task Points (TP) and the Complexity Values (CV) and finally computes the Package Points (PP) for the ERP package. 4.0 Research method

In this section, we describe the research method we chose to validate our approach “PPSE”. Second, we describe the ERP data set used in this study for the application of the “PPSE”. Later, we discuss the obtained results and our inference from it. This paper uses the case study research method (Yin, 2013). Our case study in which we used the steps from Figure 1 was executed by following the research practices suggested by Yin (2013). The choice of the case study method was motivated by previous research on software projects that were carried out as per the recommendations of research methodologists in software engineering (Basili and Zelkowitz, 2007; Daneva, 2010; Wohlin, 2012). Though Yin (2013) observes case study research is more suitable when a ‘how’ or ‘why’ question is being investigated upon some existing methods or practices, the software engineering researchers 12

ACCEPTED MANUSCRIPT (Basili and Zelkowitz, 2007; Daneva, 2010; Wohlin, 2012) underline that case study research also helps the researcher to find a solution to the problem that is confined to ‘which is better’ question (Basili and Zelkowitz, 2007, Wohlin, 2012). The latter is what we are after in this

PT

research work.

The case study was carried out in the company “Axys” (pseudonym). The Axys is a

RI

midsize IT Services Company in India which has over 32,000 users from 200-plus client

SC

organizations across the globe. Axys had a dedicated team for managing the ERP projects. The team consisted of a few technical team members who studied the business requirements of the

NU

client organization and worked for the requirements engineering (RE) cycle of their project and prepared the software requirements specification for a specific ERP module. Apart from

MA

technical members (such as developers/programmers, data analysts, solution architect), the team also had a business analyst as well as experienced functional and technical consultants. The consultants had at least 10 years of configuration and integration experience with a

D

specific ERP functional module. A couple of requirements engineering (RE) team members of

TE

these ERP projects supported us to implement the steps outlined in the Figure 1 for the chosen 14 ERP projects. They helped estimate the Package Points (PP) for these projects. This allowed us

AC CE P

to consider and include 14 ERP projects in our case study. Finally, using our case study data we calculated the correlation among the estimated PP, the estimated efforts using the PP and the actual efforts for 14 ERP projects. We deem that the actual efforts would show a positive correlation with the estimated efforts using the PP. 4.1 ERP Data set

Our data came from 14 ERP projects implemented in the case study company “Axys”. The projects were carried out between May 2006 and October 2012. We applied our approach “PPSE” to 14 ERP projects of Axys, each of which deals with the development of a customized ERP package in a client organization. These projects were either known in Axys for delayed implementation or were found to have deviation when comparing their actual efforts and estimated efforts. We deliberately chose 14 projects with these characteristics for our case study, as we foresee that inaccurate efforts estimation due to inaccurate package size measurement as one primary reason for the discussed shortcomings in these projects.

13

ACCEPTED MANUSCRIPT The ERP projects used in our study followed a modular approach during ERP implementation. That is, a module of the ERP was implemented than the complete ERP package consisting of various modules. Different ERP modules implemented by these 14 ERP projects

PT

include: Finance, Materials Management, Human Resource Management, Quality Management

RI

and Sales and Distribution. 4.2 Validation of PPSE

SC

We tested our approach “PPSE” using the following steps suggested in Abrahao et al.,



NU

(2010).

We extracted the data set (function points (FP) and actual efforts (AE)) for

MA

14 completed ERP projects (Ai) delivered by the company Axys from their project database (PDB). The PDB is a repository of completed IT/IS projects maintained by an IT Company. This database was designed and developed as

D

an in-house product by the IT Company for storing the details of their

Normally, a PDB of an IT Company is composed of the following details:

AC CE P



TE

previously completed IT/IS projects.

actual efforts used in the project, function points, lines of code, project planning and scheduling activities, software quality assurance measures (for e.g., defects) and risk information sheets (Albrecht and Gaffney, 1983). 

Using the equation (1), the package points (PP) for the ERP projects (Ai)

was estimated with the help of the Requirements Engineering (RE) team members of the Axys Company (Please see Sec 4.0). The members derived values for the tasks points (TP) and the complexity values (CV) from the software requirements specification document of these projects. 

The estimation of efforts (EE) for the ERP projects (Ai) using the package

points were carried out using the conventional method namely COCOMO II for effort estimation (Boehm et al., 2000).

14

ACCEPTED MANUSCRIPT 

The FP measurement for these ERP projects was done using the most

prominently used method namely Function Point Analysis (FPA) which was initially proposed by Albrecht (1979). This method can be considered as the

PT

first software sizing method in software engineering literature. According to this method, a software system consists of logical files and functions that

RI

perform transactions using or altering the data in the logical files. The amount

SC

of data (types) ‘handled’ by a logical file or transactional function determines the amount of functionality that the software delivers, hence its functional



NU

size.

As suggested by previous research (Ferrucci et al., 2010; Ceke and

MA

Milasinovic, 2015), we evaluated the estimation accuracy of the proposed approach “PPSE” using correlation analysis for the variables, the FP and the

D

AE; the PP and the EE; the PP and the AE.

TE

5.0 Results

In this section we report our results with respect to:

AC CE P

(i) what we observe from the correlation between the function points (FP) and the actual efforts (AE) of the 14 ERP projects (Ai) and (ii) the correlation between the estimated package points (PP) and the estimated efforts (EE) of Ai and (iii) finally the correlation between the estimated package points (PP) and the actual efforts (AE) of Ai.

In this study, we initially recorded the function points and the actual efforts for the ERP projects (Ai) which is shown in Table 1. Next, we started measuring package points as per the procedure described in the Figure 1. Next, the efforts required to develop the customized ERP packages for 14 ERP projects was measured using package points. The outcome of this exercise is reported in Table 2, which shows the package points and the efforts (both actual and estimated) for the ERP projects (Ai).

15

ACCEPTED MANUSCRIPT Table 1 Function Points and Efforts for 14 ERP Projects (Ai)

RI

PT

Actual Efforts (AE) (Person-Months) 2.56 8.93 10.51 27.71 32.2 41.02 4.65 6.63 17.89 7.1 27.05 15.93 5.32 8.24

NU

SC

Function Points (FP) 167 3860 185 1191 9940 1809 245 980 1820 9430 10760 7320 6860 13970

MA

Project ID (Ai) A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14

Table 2 Package Points and Efforts for 14 ERP Projects (Ai)

D

172.8 602.775 709.425 1869.75 2176.875 1968.85 313.875 447.525 1216.52 544 1839.4 1083.24 361.76 1240

AC CE P

A1 A2 A3 A4 A5 A6 A7 A8 A9 A10 A11 A12 A13 A14

Estimated Size (Package Points) (PP)

TE

Project ID (Ai)

Estimated Efforts (EE) (PersonMonths) 2.09 8.35 12.43 26.09 31.06 43.07 4.88 6.56 16.79 6.3 26.4 16.72 4.29 9.4

16

Actual Efforts (AE) (Person-Months) 2.56 8.93 10.51 27.7 32.25 41.02 4.65 6.63 17.89 7.1 27.05 15.93 5.32 8.24

MA

NU

SC

RI

PT

ACCEPTED MANUSCRIPT

AC CE P

TE

D

Figure 2 Correlation between FP and AE of 14 ERP projects (Ai)

Figure 3 Correlation between PP and EE of 14 ERP projects (Ai)

17

MA

NU

SC

RI

PT

ACCEPTED MANUSCRIPT

Figure 4 Correlation between PP and AE of 14 ERP projects (Ai)

D

As discussed in Sec 4.2, we examined the correlation between the variables – the FP and

TE

the AE, the PP and the EE, and the PP and the AE for the ERP projects (Ai) using Karl Pearson’s coefficient of correlation (R) (Berenson and Stephan, 1999). Coefficient of correlation (R) for

AC CE P

function points (FP) and actual efforts (AE) is 0.10, whereas it is 0.93 for package points (PP) and estimated efforts (EE) for 14 ERP projects (Ai). Similarly, for the projects, the coefficient of correlation (R) for package points and actual efforts is found to be 0.94. The correlation analysis for the variables – the FP and the AE, the PP and the EE and the PP and the AE are shown in the Figure 2, Figure 3 and Figure 4 respectively. From our results, we infer the FP and the AE are very weakly related, whereas the PP and the EE are strongly related. Similarly, the PP and the AE are also strongly related for the 14 ERP projects (Ai). A typical ERP package involves configuring the application to suit the business requirements of the implementing organization and this is achieved by creating custom or RICE objects to bridge the gaps in the application. These define the scope of the ERP solution and forms an essential part of the ERP package size. It should be noted that external factors and other non-functional requirements such as user design interface which may be complex to implement also contribute to the ERP package size. 18

ACCEPTED MANUSCRIPT 5.1 Discussion The process of measuring software size using function points takes into account the

PT

number of ways a system interacts with its users. This would employ counting and weighting five data and process logical components. The data components are the so-called logical internal

RI

files and external interface files, and three transactional components are external inputs, external outputs, and external queries (Daneva, 2010). However, the IFPUG community (e.g., (Boehm et

SC

al., 2000; Jones, 2008)) observes that the software size measurement using function points falls short in providing details relative to emerging technologies, business process complexity and

NU

customizing configuration settings, for example, ERP among others. Our results indicate that the customized ERP package size estimation based on the

MA

function points stands far away from the actual efforts spent for the 14 ERP projects (Ai). However, we find the estimated package points were positively related to the amount of actual effort that was spent in these projects. Also, the estimated efforts for these projects maps very

D

well with the estimated package points.

TE

The results of our case study indicate that an increased understanding of customized ERP package size measurement methods is necessary to accurately estimate efforts for ERP projects.

AC CE P

This may not be possible for ERP project managers through the use of brand-new tools or project-specific models which would suit a standard ERP package implementation and not a customized version of it. On the other hand, it is suggested that they should make use of some alternative approaches such as package points based ERP package size measurement during effort estimation process.

Our proposed approach “PPSE” goes beyond the conventional methods for ERP package size measurement in several ways. In this study, we view the ERP package size from customization requirements perspective and, in that we leverage existing empirical knowledge on efforts estimation for software projects. This provides us three consequences: first, it led to the focus on ERP customization requirements at macro level; second it allowed us to explore the tasks and sub-processes required for each of the customization requirements; third, the complexity associated with these tasks/processes. Our results support the claim in the literature (Daneva, 2010; Chou and Wu, 2013; Sudhaman and Thangavel, 2015) that effort estimation methods grounded on the different types 19

ACCEPTED MANUSCRIPT of customization requirements at a more detailed level (shorter activities, smaller tasks) contributes to the accuracy of the estimates and may reduce the size of the estimation errors. The proposed approach “PPSE” considers the different ERP customization requirements and

PT

accordingly measures the size of the customized ERP package. To better understand the significance of the “PPSE”, we studied the literature on requirements change impact analysis

RI

(Dorr et al., 2008; Leitner and Kreiner 2010) and requirements traceability management

SC

techniques (Torkar et al., 2012). These studies deals primarily with techniques helping ERP team members understand how customizations affect project efforts, software size and its behaviour.

NU

We infer that the ERP customization does not happen in isolation, but it is being carried out considering the ERP system as a whole. Given this state, different customization

MA

requirements (say, configuration requirements, RICE requirements, functional requirements) implemented by the ERP vendors have to be taken into account while estimating the customized ERP package size. In the absence, of such an initiative, one could not really understand the

D

critical efforts required for the development of customized ERP package. This has been taken

TE

care of in the proposed effort estimation method “PPSE” grounded on package points. This has lead the “PPSE” approach to produce better results for software size measurement and efforts

AC CE P

estimation when compared to other conventional methods in practice for ERP projects. One needs to understand the very nature and development of ERP packages. These application packages developed by ERP vendors are rooted in various common business requirements captured from various sources so as to bring the best industry practices. Such best practices include the process flows and granularity of captured data. In order to measure the size of such ERP packages, we need to get into the package structure in terms of its solution scope. Defining the ERP solution scope would involve mapping the business requirements of the client organization onto ERP application modules and required business processes onto application processes or functionality.

20

ACCEPTED MANUSCRIPT The proposed approach is a package-independent, parametric-sizing method. This research has some implications for ERP project managers. The significant benefits of this approach are: requirements based package size measurement with decreased person dependency,

PT

enhanced productivity of projects, and increased effort estimation accuracy. The present study uses the package points (PP) for ERP package size measurement and the PP relies on the

RI

different ERP customization requirements. Such a schema would enable the ERP project

SC

managers to better understand how complex the customer’s requirements are, efforts required to implement it and the size it would occupy as a whole for the ERP system. This in turn would

NU

facilitate the project managers for better decision making when accepting the customization request from the client organization.

MA

To practicing project managers, our research suggests that even though it’s little bit hard to extract the different customization requirements from the business requirements of the customer, attempting to think about and measuring the package size estimate accordingly would

TE

D

pay off in the long run and save costs, time and other resources. 5.2 Evaluation of Validity Concerns

AC CE P

We consider this research study as a first step toward a better understanding of the customized ERP package size measurement to reduce uncertainty in ERP effort estimation. As suggested by Yin (2013), we did an early assessment of the validity threats. We investigated the following threats which could influence the results. 

Our study considers 14 ERP projects for package points and effort estimation. Many previous studies (Parthasarathy and Anbazhagan, 2008; Daneva, 2010; Ceke and Milasinovic, 2015; Sudhaman and Thangavel, 2015) dealing with the software size and effort estimation models have considered small data sets with 10–15 IT/IS projects to validate their proposed methods and obtained significant results like we did in our study. We followed Wieringa’s approach (2014), according to which a newly proposed approach needs first to be tried out in a setting that allows isolating effects and drawing some first lessons learnt about the real-world use of the approach. However, future research shall 21

ACCEPTED MANUSCRIPT experiment our proposed approach for large number of ERP projects (say, 25 to 40 projects). Another possible threat could be due the fact that all the 14 ERP projects

PT



considered in this study were delivered by the same company. Future research

RI

will include data from different ERP packages deployed by several ERP vendors. This may help us observe the influence of package size measurement



SC

over project efforts at macro level.

For the generalization of the results, it is necessary to use data set from ERP

NU

packages developed on different platforms such Open Source and Microsoft



MA

technologies.

Errors in the measurement of effort, function points (FP), package points and lines of code are inevitable (Boehm et al., 2000). It is hard to make out the

D

extent of measurement errors for the variables such as FP. Previous research

TE

on software engineering (Albrecht and Gaffney, 1983) suggest that the FP count does not work for software projects where the project schedule has been

AC CE P

compressed and over utilization of project resources are anticipated. This research work did not handle errors in the datasets of software projects of customized ERP packages. 6. Conclusion

The main objective of this paper is to show that it is possible to size customized ERP packages based on customization requirements (package points) rather than relying on its functionality (function points) alone. To the best of our knowledge, this is the first of its kind in ERP research. We have outlined a procedure to measure the customized ERP package size based on customization requirements and accordingly, the efforts estimation for such ERP projects. Our research study not only supported previous research works on software size and effort estimation for IT/IS projects but it also shows that our approach is suitable and generated good effort estimation for the chosen 14 ERP projects. The purpose of this study is not to undermine the existing approaches but rather to suggest that more multi-technique-based approaches should be proposed for the ERP context. 22

ACCEPTED MANUSCRIPT Hence, in our approach, to overcome the weaknesses of the existing techniques being used, we captured different types of ERP customization requirements and the complexity associated with its implementation.

PT

This research was an initial trial of our approach and one of the goals of this research was to determine if there is a relationship between the customized ERP package size and efforts used

RI

in these ERP projects. This study lays the foundation for researchers to analyse effort estimation

SC

for ERP projects from the perspective of customization. We have also provided areas for future

NU

research in our discussion of validity threats. References

MA

Abrahao, S., Gomez, J., Insfran, E., Validating a size measure for effort estimation in modeldriven Web development, Information Sciences 180(20) (2010) 3932-3954.

D

Ai, Q., Shu, T., Liu, Q., Zhou, Z., Xiao, Z., A method for determining customer requirement weights based on TFMF and TLR, Enterprise Information Systems 7(4) (2013) 569-580.

TE

Alagar, V. S., Periyasamy, K., Specification of Software Systems (1998) Springer.

AC CE P

Albrecht, A.J. Measuring Application Development Productivity. In Proceedings of the IBM Application Development Joint SHARE/GUIDE Symposium, Monterey, CA, USA (1979) 8392. Albrecht, A.J., Gaffney, J. E., Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation, IEEE Transactions on Software Engineering 9(6) (1983), 639-648. Akkiraju, R., Geel, V. H., Estimating the cost of developing customizations to packaged application software using service oriented architecture. In Web Services (ICWS), IEEE International Conference (2010) 433-440. Aslam U, Coombs C, Doherty N. (2012) Benefits realization from ERP systems: The Role of Customization, Proceedings of ECIS 2012, 142.1 - 142.7 Basili, V. R., Zelkowitz, M. V., Empirical studies to build a science of computer science, Communications of the ACM 50(11) (2007) 33-37. Berenson, M. L., Stephan, D., Statistics for Managers Using Microsoft Excel, Prentice Hall (1999)

23

ACCEPTED MANUSCRIPT Boehm, B., Abts, C., Chulani, S., Software development cost estimation approaches—A survey, Annals of Software Engineering 10(1-4) (2000) 177-205.

PT

Brehm, L., Heinzl, A., Markus, M. L., Tailoring ERP systems: a spectrum of choices and their implications. In System Sciences, 2001. Proceedings of the 34th Annual Hawaii International Conference (2001) 9.

RI

Ceke, D., Milasinovic, B., Early effort estimation in web application development, Journal of Systems and Software 103 (2015) 219-237.

SC

Chou, J. S., Wu, C. C., Estimating software project effort for manufacturing firms. Computers in Industry 64(6) (2013) 732-740.

NU

Chou, S. W., Chang, Y. C., The implementation factors that influence the ERP (enterprise resource planning) benefits, Decision Support Systems 46(1) (2008) 149-157.

MA

Cuelenaere, A. M. E., Van Genuchten, M. J. I. M., Heemstra, F. J., Calibrating software cost estimation model: why and how, Information and Software Technology 29(10) (1987) 558-567.

D

Daneva, M., Balancing uncertainty of context in ERP project estimation: an approach and a case study, Journal of Software Maintenance and Evolution: Research and Practice 22 (5) (2010) 329357.

TE

Daneva, M., ERP Requirements Engineering Practice: Lessons Learnt, IEEE Software 21(2) (2004) 26-33.

AC CE P

Daneva, M., Wieringa, R., Cost estimation for cross-organizational ERP projects: research perspectives, Software Quality Journal 16(3) (2008) 459-481. Dittrich, Y., Vaucouleur, S., Giff, S., ERP customization as software engineering: knowledge sharing and cooperation, IEEE Software 26(6) (2009) 41-47. Dorr, J, Adam, S., Eisenbarth, M., Ehresmann, M., Implementing requirements engineering processes: Using cooperative self-assessment and improvement, IEEE Software 25(3) (2008) 7177. Erasmus, P., Daneva, M., ERP effort estimation based on expert judgments, Proc. of the 8th International Conference on Software Process and Product Measurement (IWSM-MENSURA) and the 23rd International Workshop on Software Measurement, IEEE CS Press (2013) 104–109. Eschinger, C., “Forecast: ERP software, worldwide 2005–2010 update”, Executive Summary, Gartner Research ID G00131025 (2005) 9-21. Ferens, D. V., Software cost estimation in the DoD environment. American Programmer 9 (1996) 28-34.

24

ACCEPTED MANUSCRIPT Ferrucci, F., Gravino, C., Oliveto, R., Sarro, F., Mendes, E., Investigating Tabu search for Web effort estimation. In Software Engineering and Advanced Applications (SEAA), 2010 36th EUROMICRO Conference (2010) 350-357.

PT

Hamerman, P., ERP applications 2008: The battles goes vertical, Forester (July 2008).

RI

Hericko, M., Zivkovic, A., The size and effort estimates in iterative development, Information and Software Technology 50 (7) (2008) 772-781.

SC

Huang, S., Chiu, N. H., Liu, Y. J., A comparative evaluation on the accuracies of software effort estimates from clustered data, Information and Software Technology 50 (9) (2008) 879-888.

NU

Idri, A., Amazal, F. A., Abran, A., Analogy-based software development effort estimation: A systematic mapping and review, Information and Software Technology 58 (1) (2015) 206-230.

MA

Jacobson, S., Shepherd, J., D’Aquila, M., & Carter, K., The ERP market sizing report, 2006– 2011, AMR Research (2007) 29. Janssens, G., Kusters, R., Heemstra, F., Sizing ERP implementation projects: An activity-based approach, International Journal of Enterprise Information Systems 4(3) (2008) 25–47.

TE

D

Jenson, R. L., Bartley, J. W., Parametric estimation of programming effort: an object-oriented model, Journal of Systems and Software 15(2) (1991) 107-114.

AC CE P

Jones, C., Applied Software Measurement: Global Analysis of Productivity and Quality 38 (1) (2008) Jorgensen, M., Indahl, U., Sjoberg, D., Software effort estimation by analogy and regression toward the mean, The Journal of Systems and Software 68 (2003) 253–262. Jorgensen, M., Sjoberg, D.I.K., The impact of customer expectation on software development effort estimates, International Journal of Project Management 22 (2004) 317–325. Jorgensen, M., Shepperd, M., A systematic review of software development cost estimation studies, IEEE Transactions on Software Engineering 33 (1) (2007) 33-53. Kaczmarek, J., Kucharski, M., Size and effort estimation for applications written in Java Information and Software Technology 46 (2004) 589–601. Kemerer, C.F., An empirical validation of software cost estimation models, Communications of the ACM 30(5) (1987) 416-429. Kusters, R. J., Heemstra, F. J., Jonker, A., Determining the costs of ERP implementation, In ICEIS (1) (2007) 102-112. . Lavazza, L., Morasca, S., Robiolo, G., Towards a simplified definition of Function Points., Information and Software Technology 55(10) (2013) 1796-1809. 25

ACCEPTED MANUSCRIPT Leitner, A., Kreiner, C., Managing ERP configuration variants: an experience report KOPLE '10, Proc. of the 2010 Workshop on Knowledge-Oriented Product Line Engineering, 2010.

PT

Lee, J., Chen, S., Shivpuriya, V., & Mohan, R., Service cost estimation for packaged business application-based business transformation. In Service Operations and Logistics, and Informatics, IEEE/SOLI 2008, IEEE International Conference 1 (2008) 890-895.

RI

Luo, W., Strong, D. M., A framework for evaluating ERP implementation choices. Engineering Management, IEEE Transactions on Engineering Management 51(3) (2004) 322-333.

SC

Markus, M. L., Tanis, C., Fenema, V. P. C., Enterprise resource planning: multisite ERP implementations, Communications of the ACM 43(4) (2000) 42-46.

NU

Martin, R., Evaluation of current software costing tools, ACM SIGSOFT Software Engineering Notes 13(3) (1988) 49-51.

MA

Martino, D. S., Ferrucci, F., Gravino, C., Sarro, F., Using web objects for development effort estimation of web applications: a replicated study. In Product-Focused Software Process Improvement, Springer Berlin Heidelberg (2011) 186-201.

TE

D

McAfee, A., When too much IT knowledge is a dangerous thing, Sloan Management Review 44(2) (2003) 83–89.

AC CE P

Menzies, T., Chen, Z., Hihn, J., Lum, K., Selecting best practices for effort estimation, IEEE Transactions on Software Engineering 32 (11) (2006) 883–895. Millet, P. A., Toward a model-driven, alignment-oriented ERP methodology, Computers in Industry 64(4) (2013) 402-411. Morgenshtern, O., Raz, T., Dvir, D., Factors affecting duration and effort estimation errors in software development projects, Information and Software Technology 49 (8) (2007) 827-837. Nozdrina, L., Applying of Fuzzy Logic Modeling for the Assessment of ERP Projects Efficiency, In Proc. 5th Int. Sci. Conf. Project Management: Status and Opportunities 1-2 (2009) Parthasarathy, S., Anbazhagan, N., Evaluating ERP projects using DEA and regression analysis, International Journal of Business Information Systems 3(2) (2008) 140–157. Parthasarathy, S., and Daneva, M., Customer requirements based ERP customization using AHP technique, Business Process Management Journal 20 (5) (2014) 730 – 751. Parthasarathy, S., Research Directions for ERP Projects, International Journal of Business Information Systems 9 (2) (2012) 202–221. Parthasarathy, S., Sharma, S., Determining ERP customization choices using nominal group technique and analytical hierarchy process, Computers in Industry 65 (6) (2014) 1009-1017. 26

ACCEPTED MANUSCRIPT Ram, J., Corkindale, D., Wu, M. L., Implementation critical success factors (CSFs) for ERP: Do they contribute to implementation success and post-implementation performance, International Journal of Production Economics 144(1) (2013) 157-174.

PT

Rosa, W., Packard, T., Krupanand, A., Bilbro, J. W., & Hodal, M. M., COTS integration and estimation for ERP, Journal of Systems and Software 86(2) (2013) 538-550.

RI

Soffera, P., Golanyb, B., Dorib, D., Aligning an ERP system with enterprise requirements: An object-process based approach, Computers in Industry 56 (6) (2005) 639-662.

SC

Stamelos, I., Angelis, L., Morisio, M., Sakellaris, E., & Bleris, G. L., Estimating the development cost of custom software, Information & Management 40(8) (2003) 729-741.

NU

Stensrud, E., Alternative approaches to effort prediction of ERP projects, Information and software technology 43(7) (2001) 413-423.

MA

Stensrud, E., Estimating with enhanced object points vs. function points, In Proceedings, 13 th COCOMO/SCM Forum (1998)

D

Stensurd, E., Myrtveit, I., Identifying high performance ERP projects, IEEE Transactions on Software Engineering 29 (5) (2003) 398-415.

TE

Subramanian, G. H., Jiang, J. J., Klein, G., Software quality and IS project performance improvements from software development process maturity and IS implementation strategies, Journal of Systems and Software 80(4) (2007) 616-627.

AC CE P

Sudhaman, P., Thangavel, C., Efficiency analysis of ERP projects—software quality perspective, International Journal of Project Management 33 (2015) 961-970. Tsai, W. H., Hwang, E. T., Chang, J. C., Lai, C. W., & Lin, S. J., Turning around troubled projects in an ERP implementation project from consultancy project leaders perspectives, International Journal of Business and Systems Research 6(2) (2012) 123-149. Torkar, R., Gorschek, T., Feldt, R., Svahnberg, M., Raja, U. A, Kamran, K., Requirements traceability: a Systematic review and industry case study, International Journal of Software Engineering and Knowledge Engineering 22(3) (2012) 385-434. Wieringa R. J. (2014) Empirical research methods for technology validation: Scaling up to practice. Journal of systems and software (95): 19-31. Wilkie, F.G., McChesney, I.R., Morrow, P., Tuxworth, C., Lester, N.G., The value of software sizing, Information and Software Technology 53 (11) (2011) 1236–1249. Wohlin, C., Runeson, P., Host, M., Ohlsson, M. C., Regnell, B., Wesslen, A., Experimentation in software engineering, Springer Science & Business Media (2012) Yin, R. K., Case study research: Design and methods, Sage publications (2013) 27

ACCEPTED MANUSCRIPT

AC CE P

TE

D

MA

NU

SC

RI

PT

Zhou, Y., Yang, Y., Xu, B., Leung, H., Zhou, X., Source code size estimation approaches for object-oriented systems from UML class diagrams: A comparative study, Information and Software Technology, 56(2) (2014) 220-237.

28

ACCEPTED MANUSCRIPT AN APPROACH TO ESTIMATE THE SIZE OF ERP PACKAGE

PT

USING PACKAGE POINTS

RI

Highlights

A unique approach to measure size of the customized ERP package has been proposed.



Case study research method has been used to validate the proposed approach using data collected from 14 ERP projects delivered by the same company.



A positive correlation was observed between Package Points and the efforts of these projects.



The study presents theoretical and practical implications for better understanding of ERP package size measurement process.

AC CE P

TE

D

MA

NU

SC



29