A Methodology to Bridge Information Gap in ERP Implementation Life Cycle

Introduction

An ERP system is a commercial and generic packaged software solution that integrates organizational processes through data flows. Bansal and Negi (2008) showed that the information/data flow and its integration results in complexity of ERP packages. The data is stored in a relational database. It provides support for most commercial functions of an organization like sales, finance, purchase etc (Rosemann & Shanks, 2001). RE and configuration are the two most crucial and expensive stages in a successful ERP implementation lifecycle (Parthasarthy, 2008; Genoulaz et al., 2005; Holland & Light, 1999). Daneva (2004) demonstrated that in Requirements Engineering (RE) phase needs of different stakeholders are identified and documented using some standard modeling technique for subsequent communication, analysis and implementation. Configuration involves using models and documents created in the RE phase to map the business processes of the client organization to the ERP software. A desired business process is configured by selecting appropriate tables, attributes, and relationships between these tables. In addition, organizational structure is captured in terms of its people and the functions performed. Master data is set up. Examples of master data are material, customer, vendor etc. for an organization. A set of rules is defined. These rules govern usage of data and transactions. A transaction accesses some data, and produces results that may change the database, generate a report or a document (Hernandez, 2000).

There are four aspects of a business that translate into requirements: namely data/information, processes, business rules, and external requirements. The goal of RE phase is to capture all four business aspects to create documents and models that allow design and configuration to proceed at acceptable risk (Daneva, 2000). Configuration phase uses output of RE phase. The assumption before configuration commences is that information required for configuration is captured in RE phase. However, during RE the focus is on business requirements whereas the focus shifts to ERP software during configuration. The business requirements in RE phase are captured through process modeling techniques that emphasize on the functions, processes, their interactions and required data. However configuration involves defining a business process in terms of data, their interrelationships and interactions to accomplish a task. The process modeling techniques used in RE phase may capture data elements but they fail to show their interactions and interrelationships. Rosemann and Shanks (2001) demonstrated that these techniques do not include data and information required to select various relational tables, attributes or to select among various alternatives or to make decisions during configuration. Thus, there is a considerable gap between the information available and the information required for configuration phase (Negi & Bansal, 2008a). This information gap may result in extensive configuration efforts that may eventually lead to significant implementation cost and business failure. At times implementation cost exceeds software license fees by a factor or five to ten (Davenport, 2000). Research done by Hanafizadeh et al. (2010) and Abdinnour-Helm et al. (2003) suggests that incorrect configuration is one of the main reasons that results in termination of ERP projects. Davenport (1998) and Markus and Tanis (2000) have illustrated examples to show that failed ERP implementation projects even lead to bankruptcy.

To minimize the gap between RE and configuration phases in an ERP implementation major ERP vendors provide reference models. The reference models describe functionality and structure of a system at various abstraction levels. They are in the form of business processes, functions, data, organizational units, and objects with emphasis on process models (Rosemann & Shanks, 2001). However these techniques do not take into account special configuration requirements. Hence there is a need for a solution that allows to model data and its interaction with other data elements and activities. This data centric solution should also be able to capture configuration specific requirements. This paper aims to provide a possible solution for the same.