مدل سازی ERP : رویکردی جامع
|کد مقاله||سال انتشار||مقاله انگلیسی||ترجمه فارسی||تعداد کلمات|
|12194||2003||18 صفحه PDF||سفارش دهید||7336 کلمه|
Publisher : Elsevier - Science Direct (الزویر - ساینس دایرکت)
Journal : Information Systems, Volume 28, Issue 6, September 2003, Pages 673–690
We present a generic reverse engineering process, aimed at developing a model that captures the available alternatives at different application levels of an Enterprise Resource Planning (ERP) system. Such a model is needed when ERP systems are aligned with the needs of the enterprise in which they are implemented. In order to support the ERP implementation process, the model should describe the entire scope of the ERP system's functionality and the alternative business processes it supports, as well as the interdependencies among them. We analyze the desired properties a modeling language should satisfy to be applied in constructing an ERP system model. This analysis, which follows the Cooperative Requirements Engineering With Scenarios classification framework in its adapted ERP modeling form, results in a set of criteria for evaluating modeling languages for this purpose. Using these criteria, we evaluate the Object–Process modeling Methodology and apply it for generating a detailed ERP system model. The generic process and detailed criteria we develop can serve for comprehensive ERP modeling, as well as for obtaining a model of other process-supportive off-the-shelf systems that are of generic and configurable nature.
Enterprise Resource Planning (ERP) systems are off-the-shelf software packages that support most of the key functions of an enterprise, such as logistics, sales, and financial management. These systems are generic, and the functionality they provide can serve a large variety of enterprises. The implementation of an ERP system involves a process of customizing the generic package and aligning it with the specific needs of the enterprise. The alignment process simultaneously defines the software configuration and the enterprise business solution. Due to the need to adapt the enterprise to the software package rather than the other way around, it often results in redesigned business processes  and . Enhancing the system's functionality through software customizations, although not desired , is sometimes required. The business process alignment, affected by various environmental aspects, such as existing information systems prior to the ERP implementation  and organizational culture , bears crucial consequences on the success of the ERP implementation project and on the future business practice of the enterprise . This work is motivated by the need to provide support for the alignment process in enterprises whose business processes are unique and form their competitive edge. Such enterprises do not necessarily wish to standardize all their processes due to ERP implementation, as is often the case. Common tools that support the alignment process refer to predefined “best practice” models and configurations ,  and , and therefore do not support the needs of these enterprises. Preserving their unique processes may require these enterprises to make software customizations in the ERP system, and take risks of a long implementation time and high costs for maintenance and upgrades in the future . However, the functionality of ERP systems is in many cases rich enough and capable of supporting business processes that are not included in the “best practice” solutions. A requirement-driven alignment approach ,  and  enables the enterprise to identify the ERP configuration that satisfies stated requirements that do not necessarily match any predefined “best practice” solution, and the gaps—the requirements that are not satisfied by the system. Such an approach matches specifications of the enterprise requirements with a model, specifying the ERP system capabilities. This requires the model of the ERP system capabilities to represent the entire scope of options available in the ERP system in a manner that enables matching with the enterprise requirements. A common basis of semantics and representation is needed for both the ERP system model and the enterprise requirements. The enterprise requirements, discussed in detail in , are obtained through a requirements engineering process and represented formally in order to be matched with the ERP system capabilities. Some ERP systems, such as SAP and Baan, have embedded enterprise models, which represent their capabilities and “best practice” solutions  and . The model embedded in an ERP system may serve as a basis for matching the system with the requirements. Thus, it makes sense to represent the requirements using the same modeling approach. However, some ERP systems have no embedded business model, and others apply different modeling conventions, addressing different aspects of the enterprise. The Architecture of Integrated Information Systems (ARIS)  and , applied in the reference models of SAP, incorporates five representation views. These include a function view, decomposing activities in a top-down manner, a business process view, represented as Event-driven Process Chains (EPC), a resource view, representing organizational units and other resources, a data view represented by Entity-Relationship Diagrams (ERDs), and an output view, representing physical inputs and outputs. The Dynamic Enterprise Modeling (DEM) , applied in the Baan reference models, incorporates a business control view, which represents business functions, their structure and interaction, an organizational structure view, an enterprise structure view, showing geographically distributed inner supply chain, and a business process view, represented as Petri Nets . Due to the lack of a standard modeling language, the enterprise requirements must be represented differently when implementing different ERP systems in order to be matched with the ERP system capabilities. Furthermore, in order to be matched, the issues addressed by the enterprise requirements must correspond to the issues addressed by the modeling method applied in the package, which is being implemented. This does not make much sense, since the issues addressed by the enterprise requirements are independent of the specific ERP package implemented. Rather than relying on the models embedded in the various ERP packages, our goal was to establish a proper ERP model and determine what modeling language is most appropriate for representing the ERP system capabilities to be matched with the enterprise requirements. For this purpose the desired model should represent business processes and their corresponding underlying information objects , and capture the entire scope of alternative options provided by the ERP system and their interdependencies. Constructing an abstract model of an existing system is a process of reverse engineering. Reverse engineering processes are generally composed of three main activities: restructuring, comprehension, and production of an abstract model of the system under investigation . Restructuring, which is the process of transforming the structure of a system without changing the level of abstraction, is applied when error correcting or recovery of structure and consistency is needed, which is not our case. Existing reverse engineering approaches (e.g.,  and ) that provide methodologies for obtaining a model from an information system, typically address legacy systems, and therefore do not focus on capturing optionality. Other works, addressing complex and configurable systems  and product families , deal with the system's architecture in support of its evolution, rather than its possible configuration options. Providing a reverse engineering focus on optionality, which is essential for ERP modeling, is one of the contributions of the present work. We start by outlining the steps that enable systematic construction of a model that captures the entire scope of alternative ERP system options and the interdependencies among them. These steps are generic and not specified for any particular modeling language. They provide a basis for discussing the nature of modeling languages suitable for our purpose. The discussion is based on the Cooperative Requirements Engineering With Scenarios (CREWS) classification framework of modeling languages , which was adapted for ERP representation in , and results in a set of evaluation criteria for a modeling language to be applied in ERP modeling. The modeling steps are refined into a modeling procedure that applies the Object–Process Methodology (OPM)  as a modeling language. OPM has been introduced and evaluated in  for modeling the requirements posed by an enterprise. Therefore, applying it for representing the ERP system provides a basis for aligning the system with the requirements. The OPM modeling procedure can be applied as is, or serve as a meta-model for constructing a modeling procedure, which is implemented with any other modeling language that fits the defined selection criteria. The remainder of the paper is organized as follows: Section 2 outlines the generic ERP modeling procedure. The desired characteristics of a modeling language that is useful for describing an ERP model and implementing the modeling procedure are discussed in Section 3 and form selection criteria for such a language. Section 4 briefly introduces the OPM and presents an ERP modeling procedure that follows the steps outlined in Section 2. Discussion and concluding remarks are given in Section 5.
نتیجه گیری انگلیسی
The ERP modeling approach suggested in this paper addresses the construction of an ERP model, for the purpose of aligning an ERP system with the needs of an enterprise.The contribution of the paper is threefold. First, we introduce generic ERP modeling steps, aimed at capturing the entire scope of process variants supported by the ERP system and the interdepen- dencies among them. These generic steps may be applied using a variety of modeling languages. However, the complexity of the problem poses requirements on properties that a modeling language should satisfy to be suitable for this task. The second contribution of the paper is the analysis and characterization of these properties, which results in a set of evaluation criteria for modeling languages. This analysis extends the ERP-adapted CREWS classification framework  . The main addition to the framework is the consideration and representation of possible de- pendencies among variants and options in the ERP system. The analysis and evaluation criteria established led to the selection of OPM as the modeling language of choice for ERP modeling. Since OPM has been evaluated in  and found adequate also for representation of enterprise requirements, it is now shown to be applicable as a basis for ERP-enterprise alignment. Finally, the third contribution is a detailed ERP modeling procedure that we present in Section 4. The modeling procedure can be used as is, or serve as an example showing how the generic modeling steps are refined into a detailed procedure. The ERP modeling process has been applied and proven useful in obtaining a model of the parts of the Baan ERP system as part of a requirement-driven alignment experiment. The model construc- tion was labor-intensive and required studying the details of the ERP system and the processes it supports. Nevertheless, this is a one-time effort, which produces a model that can serve repeatedly for any number of implementation projects. The modeling process, although developed for ERP systems, is not limited only to this type of systems. The levels of optionality included in ERP systems appear also in other off-the-shelf cus- tomizable information systems. Therefore, the modeling process may be relevant to any pro- cess-supportive generic off-the-shelf information system. It may also be of importance to reverse engineering of product families, which include parametric variability. Future research addresses the application of the ERP model in ERP-enterprise alignment. It can also apply the evaluation criteria for evaluating and comparing other modeling languages, and developdetailed modeling procedures for those languages that are found suitable on the basis of the generic modeling steps. Another research direction is to relate our modeling process, which deals with optionality, to the architectural- oriented reverse engineering approaches of product families.