Journal of Software Engineering

Year: 2015 | Volume: 9 | Issue: 2 | Page No.: 203-216
DOI: 10.3923/jse.2015.203.216

ERP Integration: A Reuse Based Approach, Evaluation and Prospect

Mohamed Ramzi Bouzid, Naoufel Kraiem and Henda Ben Ghezala

Abstract: One of the critical points in an Enterprise Resource Planning (ERP) integration project is matching the ERP functionalities with the organizations’ requirements, so as to define how to adapt the system and/or the organization to reach an efficient functioning. A number of approaches have been elaborated to solve the issues posed by this matching activity in particular one of the conceptual mismatch between different kinds of used models. Moreover, one aspect is not often considered in these approaches. It is the opportunity to reuse experience from one ERP implementation project to another. This study presents a reuse-based requirements elicitation approach for ERP integration. The suggested approach has been subsequently tested through a series of experiments aimed to evaluate the efficiency of reusing generic domain knowledge in the matching activity. The case study showed that starting requirements elicitation and matching at the generic domain level is always more efficient than starting it directly at the organizational specific level.

Keywords: ERP integration, reuse process, requirements engineering and evaluation

INTRODUCTION

In the domain of requirements specification, several studies (Van Lamsweerde, 2009; Berenbach et al., 2009; Pohl, 2010; Ernst et al., 2014) have shown that implementation failures of computer systems in an enterprise are mainly due to the poor identification and/or comprehension of the business needs that these systems attempt to answer.

In general, from these poorly expressed requirements, the developer realizes a solution that does not fully meets, in whole or in part, with the initial needs desired by stakeholders.

To meet their needs through the integration of a new system, an organization has usually:

When integrating a software solution, one of the major problems facing the buy approach is that the matching between the business need of the organization and the features of out-sourced system. The success of the whole project depends directly on this matching (Esteves and Pastor, 2003; Kolovos et al., 2009; Bellahsene et al., 2011).

The difficulty of the matching between the organizational requirements and the system functionality resides in the difference between the levels of abstraction these two words express. Indeed, while the stakeholders express problems and requirements in their own languages (mostly in plain text), the buy approach expresses a solution in technical concepts. This results in a mutual misunderstanding incomprehension between, on the one hand, the business experts who speak in terms of objectives, goals and strategies to achieve (with a minimum of operational details) and the actors of the operational level who speak in terms of solution and technical details.

To address this matching issue, several studies and researches such as by Davenport (2000), Giunchiglia et al. (2007), Chen et al. (2011) and Shvaiko and Euzenat (2013) are mainly interested in developing metrics to match user needs with features offered by a system in to meet the conceptual discordance that exists between these two worlds (business and system).

Most of these approaches consider projects mapping as being completely independents, even if it remains in the same activity domain. Thus, these approaches leading to lose the acquired experience and to implement each new project from scratch. Yet, very few approaches are based on this generic aspect of requirements elicitation (Kensche et al., 2009; Schneider et al., 2011; Hull et al., 2011; Mussbacher and Kienzle, 2013).

Moreover, in the case of the Small and Medium-sized Enterprises (SMEs), there is still a real problem because of solution based approach followed. In fact, this type of companies generally can’t develop and express their own requirements freely without being influenced by the solution imposed by editors and integrators.

Among these different problems, we are interested, in this study, on the domain reuse because very few ERP implementation methods are able to propose a concrete model of knowledge reuse at the requirements level (Daneva, 2000, 2001; Ettlie and Kubarek, 2008; Chernak, 2012; Orawski et al., 2013).

For implementing ERP, this study presents a requirements reuse based approach using three levels of requirements modeling: Domain, Enterprise and ERP. This study mainly aims to:

STATE OF THE ART

Davenport (1998) defined it as “A package that promises the transparent integration of all the information in the company: information on finance, human resources, supply chain and customer base”.

Rowe (1999) notes that “Technological innovation ERP carries the old dream of a single repository of information system of the company. With such systems, the actors of the company operate daily with a common language. As well the tool responds to the leaders’ desire of real-time control”.

ERP can then be presented as a “Ready to implement” software package (developed by an editor) that can, in general, covers all organization processes allowing it to manage and optimize all of its resources through several adaptable modules.

During ERP integration, the main observed difficulties can be classified in three categories:

Organizational difficulties: One of the most important steps in the ERP integration process is to ensure, throughout the project, that the system to implement meets the requirements expressed by different users.

Another difficulty, as important and relevant, is that many enterprises, making the choice to implement an ERP, are tempted or forced to align their needs with the ERP functionalities (and not the reverse) to avoid the cost of customization work, often expensive in terms of time and money. These enterprises then choose features that already exist in the ERP that does not exactly meet the need initially expressed and are therefore obliged, first, to remove one or more requirements and secondly, to increase their reliance on ERP, its publisher and its integrator (Malhotra and Temponi, 2010; Addo-Tenkorang and Helo, 2011).

Indeed, it’s usually difficult for an organization to disregard the existing solutions and only focus on its requirements. The organization is therefore forced to align its processes, business objectives and organizational model to those proposed by the solution of Aloini et al. (2007) and Hwang and Grant (2011).

In addition to these difficulties faced by most SMEs/SMIs, there are other obstacles that may face companies in an ERP implementation project:

Technical difficulties: ERP is particularly difficult to implement and a low system control can have a significant impact on the entire project. Indeed, the integrated nature of the ERP and the complexity of the system make the success of the integration work very critical and risky. It’s therefore important to control all ERP components to carry out their integration with other components of the organization information system.

In addition, for enterprises with very specific needs, it is often very difficult for an ERP to support such requirements (Davenport, 1998). The enterprise asks then the adaptation of functionality offered by ERP to take into account its specific processes. These adaptations are made through the customization of the concerned module or through new components integration. This choice is usually very expensive for SMEs/SMIs.

Another alternative that may be adopted by the project manager is that to “Co-exist” the old system that supports the specific requirements of the organization with the new ERP system. This choice reduces the integrated aspect of the ERP and is not technically simple to implement since it requires a delicate task to maintain the overall coherence of information system. This choice is often costly and ultimately ineffective.

In addition to these limitations, other obstacles and difficulties may face the system solution:

Human resources difficulties: Generally, modification or upset of information access and handling, raised after the ERP implementation, causes reluctance and resistance of many actors in the organization that deals with change.

The obstacle facing this kind of project can be also related to the lack of management commitment (Aloini et al., 2007) that does not invest enough to support the project with staff. Laudon and Laudon (2001) also cited the resistance to change usually due to lack of support staff during an ERP implementation.

Indeed, an ERP implementation project transform, in various degrees, existing jobs within the organization (Malhotra and Temponi, 2010), old professions become obsolete and new occupations appear. Other authors have mentioned, through literature, various obstacles related to this human aspect. Among these problems, it was mentioned:

However, very few requirements engineering approaches are proposed to provide an effective response to these various challenges, especially organizational one. We believe, as some authors (Bush and Finkelstein, 2002; Zoukar et al., 2004; Kolovos et al., 2009; Chen et al., 2011), when implementing an ERP system, remains to match ERP functionalities with various organization requirements.

In this regard, the following focuses on the analysis of the literature concerning the matching between business needs and system functionalities.

Matching process: A quick survey of the literature allows us that several definitions of the matching exist. This concept of matching has been defined by Klein (2001) as “A set of relationships between the elements of two representations (ontologies, database schemas, etc.), indicating a relative similarity according to a given measure”. Other authors, such as Xu and Embley (2003) and Giunchiglia et al. (2007) described the matching process as “A process of defining a functions set for specifying correspondences between terms”.

Another definition given by Shvaiko and Euzenat (2005) and Shvaiko and Euzenat (2013) presented the matching process as “A critical operation in various domains. It takes as input two schemas/ontologies and determines as output existing relationships between these entities”.

The process of “Matching” is done to reduce differences that may exist between two models or two diagrams. In this regard, several solutions have been proposed to provide an answer to the problems of matching (Aumueller et al., 2005; Fagin et al., 2009; Chen et al., 2011; Bellahsene et al., 2011).

Through literature study, it appears that often ERP functionalities don’t fully cover the business needs of an organization. These specific requirements that are not met by the system to implement, must then be treated through one of the three following alternatives in order to reduce mismatches (Martin et al., 1999) (Fig. 1):

MATERIALS AND METHODS

Description and evaluation of the approach:To carry out this study, a literature review relating to the existing approaches was conducted dealing with the problem of mismatch and the difference of abstraction level between business needs and system functionality.

Then, the interest focused on the weaknesses and limitations that can represent this kind of approaches. Among aspects that these approaches do not allow to take into account. The ability is mainly cited to capitalize on the expertise acquired from previous projects to help the requirements specification and the matching process with an ERP.

By following this literature review, various hypotheses were made that could overcome the identified limitations of existing approaches namely the relevance of introducing a domain level allowing the reuse of generic requirements.

Based on these hypotheses, a requirements engineering approach was suggested that aims to assist: (1) The elaboration of the specific needs mode of a well-defined organization and (2) The construction of the model representing the matching of these needs with the system functionalities during an ERP implementation process.

This stage is followed by an empirical study conducted as a series of controlled experiments in order to assess the impact of the suggested approach on different hypotheses that was made through this research study.

Few methods can guide the matching process with a real balance between organizational business needs and functionalities of the system. We think, as several authors and Gulla (2004) and Bernstein et al. (2011) that such matching must be made in the intentional level.

MAP formalism: It is necessary to use some sort of formalism that is able to represent the three different levels of the framework. It should be noted that this formalism must already have shown its effectiveness in several domains and more particularly in the ERP implantation project.

It was proposed to use the MAP formalism (Rolland and Prakash, 2000; Nurcan et al., 2005) that include several positive aspects among which:

For all above mentioned reasons and in order to better assess the impact of our model, we have chosen to use the MAP in order to provide a unified view on the enterprise requirements as well as on the ERP functionalities.

MAP is a directed graph in which nodes are labeled with goals and edges labeled with strategies. The directed nature of the graph is a way to represent the flow of goals. A goal aims at some situation that an organization wants to reach through one or several business processes. Strategies define approaches, means or manners to achieve goals.

A section is the key element of a map. It is a triplet <Gi, Gj, Sij> and represents a way to achieve the target goal Gj from the source goal Gi following the strategy Sij. Each section of the map captures the condition to achieve a goal and the specific manner in which the process associated with the target goal can be performed.

Suggested approach: The framework (Fig. 2) is based on a review of the literature of requirements reuse (Baxter et al., 2008; Wang et al., 2010; Chernak, 2012; Orawski et al., 2013) and requirements elicitation (Berenbach et al., 2009; Pohl, 2010; Ernst et al., 2014).

In this framework, the organization is modeled according to three levels:

This framework (Bouzid and Kraiem, 2012) is established in order to take in to account the knowledge reuse aspect. In this respect, the suggested approach would initially consist in the matching of the generic requirements (Generic Model GM) with the functionalities offered by the ERP (Solution Model SM).

At the domain level, the process consists on an analysis of similarities between requirements domain and ERP features. A certain number of information of matching are thus collected (Generic Matched Model GMM) and form a reusable knowledge for the specific analysis.

The next step is to build the specific map of the enterprise (Requirements Model) from the domain map (Generic Model GM). To do so, the first step is to conduct an analysis of similarities and differences between Generic Model and organization’s specific needs. Based on these differences and similarities, the Requirements Model RM can be built by derivation.

Once the generic matching conducted, the specific matching will be considered that consists, in a first step, in identifying the differences and similarities between the domain requirement map and the specific needs of the enterprise. Using the reuse of acquired knowledge in the matching of the domain level, the Requirements Model will be then matched with the SM to obtain the Requirements Matched Model RMM.

It may be seen that the process of matching at the specific level, unlike the generic level is based on the analysis of the variations between domain requirements and specific requirements. It should be recalled, in this regard, that few differences exist between two levels that facilitate the analysis and make it much more reliable. More details for the description and the application of the suggested approach are available in Bouzid (2012).

Evaluation of the approach: In order to perform this approach, an application domain that is original (for ERP), random and that doesn’t require a long phase of learning was adopted.

As case study, a charity association was chosen whose main objectives are to improve life quality of hospitalized children and to reduce their isolation by providing laptops and software. It aims to facilitate communication, education and entertainment for children. It’s the “Docteur Souris” Association (DS) (Bouzid, 2012).

This experienc gave us an opportunity to assess:

In this context, these experiments were mainly conducted to evaluate the different hypotheses made by this study. These hypotheses are formulated as follows:

In order to ensure a measurable and objective analysis of our approach, the experimental activities were assigned to work groups according to Table 1.

Measures: To objectively evaluate the effectiveness of different tools used in each of these approaches, we are based on Precision P, Recall R and Effectiveness F measures (Olson and Delen, 2008).

Precision and Recall are two widely used statistical classifications. Precision can be seen as a measure of exactness or fidelity and Recall as a measure of completeness.

A measure that combines Precision and Recall is the Effectiveness Fβ (where β = Importance Recall/Importance Precision). Three commonly used F measures are the F1 measure (recall and precision are evenly weighted), the F2 measure (which weights recall twice as much as precision) and the F0.5 measure (which weights precision twice as much as recall). More details of the experimental protocol are available in Bouzid and Kraiem (2012).

RESULTS

Figure 3 shows, for each of the 4 groups, precis and recall and 3 values of effectiveness F according to different values of Beta (β = 0.5, 1 and 2).

A quick look on these first results can already make the following findings:

Alongside each of these tasks, it was said that each different group to draw a graph representing the evolution of his model (in terms of sections number) versus time. The 3rd group was also the fastest to have constructed its model followed respectively by groups 2, 1 and 4.

From these results, it was concluded that reliance on a provided generic model helps to build a more rich and coherent requirements Model than groups who have a completely specific approach (hypothesis H3). It also helps to build RMM faster mainly thanks to learning time that was significantly lower since this group relied on the acquired knowledge from the generic model (hypothesis H1 and H2).

DISCUSSION

After following the experimental protocol and results achieved, it was found that there are minimal differences between the Generic Model GM and the specific Requirements Model RM. This observation allows us to note the relevance of generic requirements to build an organization’s specific Requirements Model easier than other approaches starting from scratch (Zoukar et al., 2004; Nurcan et al., 2005). Moreover, it should be noted that by using predefined generic model helps to significantly reduce the learning and the elicitation time. This will allow a faster work of specification, modeling and matching (Bouzid and Kraiem, 2012).

Despite their relevance, the results could be discussed because of a possible bias introduced by the use of measures P, R and F related to reference RMM that was developed.

To address this potential bias, it was decided to recalculate the values of precision, recall and effectiveness for different groups compared to a new reference model. This “updated” RMM will include new Intentions and Sections Map from RMM models, proposed by different groups, which may logically be added to the initial RMM.

The results obtained from the second evaluation confirm and consolidate those obtained during the first experiment.

Indeed, the group 3 which had the best results in terms of Precision, Recall and efficiency is the group that identifies the most coherent new sections to be included in the updated RMM.

As part of approach, this capitalization process of acquired knowledge enriches the Domain models already developed.

From the obtained results, it was seen that to follow an approach based on the Domain knowledge reuse to identify the specific requirements mainly allows to:

So, the aspects of a top-down reasoning (generic to specific) and of the domain expertise reuse in addition to the capitalization process mainly reflect the power and relevance of the suggested approach. Moreover, the illustration of the approach by a case study has served to illustrate the applicability of different steps of the suggested approach and to demonstrate its feasibility in a real context.

The results, observations and measurements made have therefore demonstrated, on the one hand, the advantages of the approach for specifying business requirements of an organization and their matching with an ERP system and on the other hand, validated the formulated research hypotheses.

It was noted that our experience has shown its relevance in the evaluation of our approach. However, despite these results, a self-critic made about the followed experimental protocol can raise some limitations:

CONCLUSION

The work presented in this study opens the way to different perspectives and can be continued in several directions. These perspectives can be related to two levels: that of continuity of the work done and the enlargement of the research area:

On the other hand, the large number of manipulated data (for big structures) makes very difficult the manual application of the matching process. So, the automation of the approach seems essential for using it in large projects. A software environment would be a logical continuation of this study.

REFERENCES