Survey on ERP’s customization-driven requirements engineering

Abstract

Since the dawn of time, the implementation of an information system has always been useful to represent an organization and its processes. ERP was then quickly adopted by organizations, because it is composed of the standard generic processes and good practices. Many scholars agreed that it is cheaper for an organization to mould its business process to an ERP and vice versa. The challenge now is to customize the ERP, so that it may be in adequacy with the business process of the organization and keep all its innate advantages. This document is, therefore, an introspection in the ERP domain and, particularly, its customization based on requirements engineering.

Introduction

Governments because of their social obligations, their high public and legislative responsibilities, willing to double the efficiency of their actions and, to offer a best quality of service to their citizens, migrate more and more towards the Enterprise resource planning (ERP) (Kumar et al. 2002). ERP is a definable computer science application modular an integrated which aims at federating and optimizing the organization management process by proposing a unique referential, coherent, and basing upon rules of the standard management (Pérotin 2004). ERP is, therefore, a tool enabling the use of a unique information system, identical to the organization and, that allows an integration of all these processes, and a flow of information and activities.

The implementation of ERP is the focus of many research works believing altogether that one of the greatest challenges of this activity is its contextualization or customization to the environment of the organization (Purohit et al. 2012). It is a matter of assuring the adequacy between the requirements of the organization and the functionalities of the information system (Tobie et al. 2016). Developed at the base for generic business processes and of “best practices” of the organization’s processes, ERP does not offer the same quality of service for business processes specialized and specific to the organization (Rohde and Zhong 2014).

This document is, therefore, interested in the empirical works on implementation of ERPs in a particular way. It emphasizes on fields like implementation phases of the ERPs in a particular way; reasons that brought their customization, critical elements for the success of an ERPs customization, methods, models, and techniques existing of customization of an ERP. These subjects not being the only affordable for a complete view on past works concerning ERPs, we shall evoke the limits of past works in the matter of customization of ERPs.

The concept of ERP’s customization

Agreeing with Luo and Strong (2004) (Parthasarathy and Sharma 2016), the customization of an ERP is a process that implies the modification of an ERP, so that it may correspond to the company’s process. They summarize customization into three operations, namely: the selection of modules of the native ERP, configuration of tables, and code modification. This definition contrasts light ones (2001) who, in a less procedure oriented perspective, consider customization as an activity, producing changes or adding to the existing functionalities on the ERP. In opposition to the previous views, Davenport (1998) thinks that: customization of an ERP is just a choice, the configuration of modules and tables. Adaptation and modification terms of an ERP are also used to designate the customization of an ERP. Brehm et al. (2001) define adaptation as the setting of module parameters of ERP, to reflect the business process of the organization. They define modification as changes operated on the source code of modules of the ERP to improve it to make it equivalent to the business process. The difference between these two terms is clearly situated in the fact that, to perform a modification, an organization needs an external expert, whereas the possibilities of configuration are innate to the ERP.

Hong and Kim (2002) describe modification as that alteration of the source code of modules that do not change the identity of the basic ERP. In their research, they talk about adaptation to describe the eight (08) types of adjustment referenced to in the research of Brehm. They also talk about customization, extension, and modification as designated in glass researches (1998).

From what precedes, it is clear that there are many interpretations and conceptualizations of the term customization of the ERP in the existing literature. To clarify these different terms that all referred to customization, the Table 1 explains what is understood by each of these authors to express their ideas.

Table 1 Different types of customization in the previous works (Tasanen 2018)

The words: configuration, modification, adaptation, customization, and extension have the value of synonyms but with different meanings and understandings. This impacts on the implementation of an ERP which may differ from one organization to another. This difference can be justified by the reasons that led to the customization of this ERP.

Reasons leading to customization of ERPs

The reason mostly used for customization of an ERP is that it enables to fill the gap between the functions of an innate ERP and the business process existing in the organization (Luo 2004; Brehm et al. 2001). In spite of the functional differences, the other reasons for customizing an ERP can be noticed according to their influence upon the beneficiary social groups. Following Luo (2004), these reasons can be presented according to the different steps of the lifecycle of an ERP, knowing: “before implementation” and “after implementation”. The reasons of customization before implementation are: resistance to change, the uniqueness of the business process, and unadaptation of the functions of the innate ERP. The reasons of customization before implementation are: maturity of the organization, maturity of the ERP, and the changes due to the needs of the final users.

Rothenberger and Srite (2009) have studied how the customization of an ERP can be produce at a high level. These studied have explored the interrelations between many factors that lead to customization of an ERP. The results showed that high customization can intervene because of the resistance to change, based upon the weak agreement of the ERP project because of the cultural organization or also because of the fear of individual disadvantages linked to change. Moreover, a non-necessary re-development of the functionalities of the innate ERP can lead to the customization of an ERP. This can be linked to the experience of the implementation team or to the misreading of the ERP documentation at the beginning of the project. Moreover, the weak quantity of recommendation done to the implementation team or lack of opposition done to the requests of customization of this team can affect the level of customization applied to the ERP (Light 2005).

To ensure the successful implementation and customization project of an ERP is to explore those activities that guarantee it (Bullen and Rockart 1981; Sherry Finney 2007).

Critical factors of success for the implementation and the customization of ERPs

According to Bullen and Rockart (1981), the critical success factors (CSFs) in information systems are key activities to which the success of their execution is absolutely necessary for the manager of the project warrants the fulfilment of goals. For it to be done, managers that succeed have to concentrate on their most important resource, their most precious, their time, “upon things that make the difference between success and failure”. The CSFs of the implementation of an ERP are conditions that need to be fulfilled, so that the settlement should be done with success (Sherry Finney 2007).

Holland et al. (1999) have divided the critical factors of success according to strategic and tactical frames. The strategic frame gives precision about the necessity of the project, the engagement of the board, and a schedule describing the sequences of individual actions for implementation. The tactical frame concerns communication with all the concerned parties, the recruitment of a staff, the acquisition of technology, and of the expertise necessary for technical actions.

Esteves and Pastor (2000) propose a model grouping the CSFs according to four perspectives: strategic, tactical, organizational, and technological. The organizational perspective is related to organizational concerns such as organizational structure, culture, and business processes. The technological perspective focuses on aspects related to the ERP product, considerations, and related technical aspects such as basic hardware and software requirements. The strategic perspective is linked to core competencies fulfilling the organization’s long-term missions and objectives, while the tactical perspective affects short-term activities and objectives. Tactical and strategic perspectives are sub-perspectives of organizational and technological perspectives, and this gives us four perspectives: an organizational–tactical perspective, an organizational–strategic perspective, a technological–tactical perspective, and a strategic–technological perspective.

In the literature, many CSFs of implementation of an ERP were rediscovered in (Bullen and Rockart 1981; Sherry Finney 2007; Holland et al. 1999; Esteves and Pastor 2000; Moon 2007; Dezdar and Sulaiman 2009; Saade and Nijher 2016; Shaul and Tauber 2013; Arvidsson and Kojic 2017), their number and sense varying from one author to the other. The following board (Table 2) does a transversal of the literature and proposes a categorization of CSFs, the authors who worked on it and the terminology that is linked.

Table 2 Critical factors of success of implementation of an ERP, bibliographical terminologies and reference in the literature (Arvidsson and Kojic 2017)

CSFs such as management commitment, user involvement, change management, project support, business process reengineering, quality, and risk management are CSFs that are focused business process and organizational structure to achieve long-term goals and objectives. Moreover, the composition of an implementation team, communication, the use of consultants, is also focused organizational structure, but aim to ensure short-term goals. The implementation strategy and the selection of the ERP are aimed at the final ERP and all requirements to implement it. It is necessary to note that these factors are dependent significance of the life cycle, models, methods, and techniques used for customization.

Types, approaches, life cycle, models, methods, and techniques of customization of ERPs driven requirements engineering

To have an adequacy between the business process of the organization and the ERP, authors have proposed many typologies of customization of an ERP (Luo 2004; Davenport 1998; Brehm et al. 2001). There is much coherence between these typologies and several inconsistencies that contrast their interpretation. For example, the Brehm typology (Light 2001) includes the programming of the workflow. To implement the workflow of an organization, it requires modification of the source code of the ERP that is a particular category in the typology presented by Luo (Rohde and Zhong 2014), what can bring a confuse. The following shape presents in a summarized way the typologies mentioned above (Fig. 1).

Fig. 1

Typologies of ERP’s customization

In general, there are only two families of approach prepared to assure the adequacy between the innate ERP and the business process (Davenport 1998; Zoukar et al. 2004), one guided by the requirements of the organization and the other by ERP functionalities. The one guided by the requirements of the organization is, one wished by the work actors to install a system that answers exactly their needs. One guided by the functionalities of the ERP is wished by the editor and the integrators who wish to install standard functions of the ERP for the complexity burdens of customization. Zoukar et al. (2004) proposes an approach that combines the two preceding by trying to find a balance between the requirements of the organization and the solutions proposed by the ERP.

Many life cycles of an ERP have been indexed in the literature and the famous and mostly used by organizations is one proposed by Markus and Tanis (2000) who declines itself into six steps:

• The decision of adoption to satisfy their work needs and techniques, organizations start questioning about the necessity of an ERP system. Actually, the literature on ERPs touches many aspects linked to the adoption of the ERP in a context and the environment of small and medium enterprises;

• Acquisition it refers here to the selection of suppliers and the acquisition of the ERP. This is subsequent to the evaluation of requirements of the organization, of modules of the ERPs and of the suppliers;

• Implementation concerns the real settlement of the ERP system. This step has many activities, like the customization of the system to conform itself to the needs of the organization, the reengineering of the work process, the migration of data, the formation of the final user, etc.

• Use and maintenance the final user starts using the system daily, which implies a daily maintenance;

• Evolution implies the extension and the integration of the ERP system with the other systems as the management of customer relation, of supply chain, etc. It is a non-trivial operation that requires the stability and the maturity of the ERP;

• The withdrawal corresponds to the step, where the system is abandoned or replaced by another system of Information.

This lifecycle has also been found in the work of Esteves and Pastor (2000). For Law and Chen (2010), the ERP project lifecycle could consist of four phases—adaptation, acceptance, routinization, and infusion.

In practice, it is the requirements engineering those acquirers, models, and validates the functional and non-functional needs of an information system based on the requirement of users (Rolland and Prakash 2000). To do an ERP implementation-driven requirements engineering, it is necessary to consider many parameters, as:

• A selection of an ERP to minimize the needs of customization for answering already to most of the needs of the organization;

• The flexibility of the ERP to adapt itself to the evolution of the needs of the organization.

In the research, Rolland and Prakash (2001, 2001) proposed an oriented approach for needs of implementation of an ERP that consists in:

• doing an abstraction of the existing functionalities of an ERP, create a link between the awaited functionalities and the existing ERP;

• effectuate an alignment at the level of needs;

• deduce the aligned functionalities, adaptation and extensions of functionalities chosen using the awaited functionalities of the ERP and the functional links.

Conclusion

This document has presented a survey on ERP’s implementation by evoking the aspect of its customization based on requirements engineering.

The customization of an ERP has ensured the adequacy between it and the business process of the organization (Rolland and Prakash 2001). This is the subject of many researches and controversies, and the very first point of controversy being the meaning linking the term itself to the actions it refers to. Therefore, configuration, modification, adaptation, and extension are terms of the literature with purpose to express the vision and the understanding of each author concerning this term. The impact of this lack of harmonization causes the difference between the approaches, the implantation steps, and the gathered methodologies in the literature. The reasons of an ERP customization are subject to many disputes. Be it technician or decider, the point of view upon this subject is different from one author to the other, implying a differentiation on the critical points for the success of the implementation and customization of an ERP.

Unfortunately, they exist many limits in research on the subject, be it the customization, the management of risks linked to this activity, the formalism of the proposed methods, of the efficient perception of user’s requirements, etc. Talking about the proposed typologies, they cannot stay without presenting the sophisticity of a process or the internal architecture of an ERP (Usman et al. 2012). Concerning the choice of customization of an ERP and the tools referred to in the literature, they suffer from lack of formalism for not disposing a formal proof, instead of practical cases of usage (Luo 2004). The perception process of the user’s requirements and corresponding these with the capacities of the ERP is a weight problem and that of criteria change following the project environment (Zoukar et al. 2004). A proposed solution consists in using help techniques to the decision or the process of analytical hierarchy. For Brehm et al. (2001), the customization options presented do not allow the reduction of risks to link to the implementation of an ERP.

Being aware of these limitations, future researches will be broadly harnessed to correct and contribute to have a formal framework allowing them capture in an optimal way the whole user’s needs by considering the innate possibilities and propose optimal execution schemes and algorithms for the usual processes implementing the organization’s business process.