Reference Model Design: An Approach and its Application - IEEE Xplore

doi:10.2498/iti.2012.0419

Reference Model Design: An Approach and its Application Dejan Pajk, Mojca Indihar-Štemberger, and Andrej Kovai University of Ljubljana, Faculty of Economics, Kardeljeva pl. 17, 1000 Ljubljana, Slovenia E-mails: [email protected], [email protected], [email protected]

Abstract. The main idea of reference modelling is to reuse business knowledge to create efficient business processes to be deployed inside an organisation. Reference models provide a set of generally accepted recommended practices. One of the management challenges facing today's organisations involves the development and reuse of business process reference models. We present a reference model design approach with a focus on a business process merging phase. Process merging is an approach that brings together several business process models with the objective to create a new model. We base our findings on a case study of three big Slovenian companies from the metal industry sector.

Keywords. Reference models, Reference model design, Process merging, BPMN

1. Introduction The past decade has seen the rise of business process management (BPM) as a general approach to improving business processes. The demand for BPM is grounded in the pressure to align all aspects of an organisation with the wants and needs of its clients. BPM attempts to improve processes continuously. There is strong industry interest in process standards, for example the widely accepted BPMN (Business Process Modelling Notation), or business process reference models, such as ITIL (Information Technology Infrastructure Library), SCOR (Supply Chain Operations Reference model) or the SAP R/3 reference model. Reference models are generic conceptual models that formalise recommended practices for a certain domain [15]. As organisations reach higher levels of BPM, they tend to gather large collections of business process models. Nowadays, one challenge for management is the formalisation and reuse of the company’s best practices. Developing process models from scratch is a time-consuming and methodologically challenging task. Reference

models can be used as a starting point to develop specic conceptual models [2]. Two main scenarios make use of reference models. The first involves application of a reference model, e.g. when that model is adapted to the specific needs of an organisation. The second scenario entails the design of a reference model. In the paper the term reference model design relates to all activities that are necessary to design and develop reusable business process reference models. In the literature we can find some suggestions for reference model design methods [7, 13]. However, we were unable to find an approach that considers a reference model for merging processes based on existing business process models within the specific industry. This paper aims to suggest an approach to the design of process reference models based on collections of an organisation’s business process models. The paper’s structure is as follows: the opening section introduces and generally describes reference models. The next section explains an approach to the design of a process reference model based on existing research, while the last section presents the application of the suggested approach in a case study based on a European project.

2. Reference models Process design is a key phase in the redesign of business processes. The resulting model forms the basis for implementation and execution. Ensuring such modelling quality can be very time-consuming. The use of process templates significantly increases the efficiency and effectiveness of the process design phase. Process templates are generally called business process reference models [10]. A reference model encompasses one or more pre-engineered and integrated organisational views. For example, one type of reference model might be a business process reference model, or a depiction of data flows [4]. It integrates the

455



   

           

well-known concepts of business process reengineering, benchmarking, and process measurement into a cross-functional framework [18]. A reference model is based on a small number of unifying concepts and may be used as a basis for education and explaining standards to nonspecialists [1]. In the science literature we can find several definitions of reference models. Rosemann [14] defines reference models as generic conceptual models that formalise recommended practices for a certain domain. Fettke and Loos [6] contend that a reference model represents a class of domains. Reference models have the following characteristics [6, 7, 10, 16]: - a representation of best practices (providing best practices for conducting business); - universal applicability (representing a class of domains, not a particular enterprise); and - reusability (they can be understood as blueprints for developing information systems, they can be structured to allow easy adaptability to company-specific situations). Reference models play an increasingly important role in activities such as business engineering [17], information system development [23], customising ERP systems [15] and training and research [19]. In order to be able to use reference models, they must be adapted to the requirements of a specific enterprise. Reference models represent the content of various domains. The most important types are the following [10, 6]: - industry reference models (representing the best practices of a specific industry sector); - software reference models (these can be traditional applications such as ERP systems, or a reference model representing a sub-process supported by service-oriented architecture (SOA); - procedural reference models (e.g., a project management reference model); and - company reference models (representing best practices within a company or a company group). The use of reference models has different economic effects on the modelling process [7, 8, 10, 12]: - a decrease in costs (reference models can be reused so the development costs of the reference model can be saved); - a shortening of modelling time (the knowledge contained in the reference model reduces learning and development time, allowing the

identification of and a direct focus on critical processes); - an increase in model quality (reference models are proven solutions and provide better model quality and an awareness of own deficiencies); - a lessening of modelling risk (the risk of failures during reference model usage can be reduced because reference models are already validated); and - the reference model content usually bridges the business and the IT domains. For example, business process models can be linked with predefined interface definition models and Web service models. Despite the many positive effects for business, they are still rarely used in practice. The reasons for this can be found in the accessibility or complexity of reference models as well as the implementation methodologies. A possible disadvantage of using reference models is that an organisation might lose some advantage of its unique and perhaps better business practices. If a reference model is widely used by an industry sector, then it can hardly represent a source of a company’s competitive advantage.

3. Reference model design approach The initial intention of designing a reference model is to create generally used and easy to understand business processes. The scope of our suggested approach is the phases and activities that are required to design reference models based on existing organisation business process models. The suggested reference model design phases are: Scope definition; Business process modelling; Process merging; and Reference model verification (Fig. 1). Scope Definition

Business Process Modelling

Process Merging

Reference Model Verification

Figure 1. Reference model design approach

3.1. Scope definition The objective is to define the scope of the project. We must identify and select business processes that are reusable and can therefore be classified as process reference models. The questions of why we need a standardised business reference model, what are the costs of designing it and what are the expected positive economic effects should be answered in this

456

phase. It is also important to define all the additional constraints of the suggested project as well as the selection of the modelling language and the modelling tool.

3.2. Business process modelling A business process model is an abstraction of a business that shows how components of the business are related to each other and how they operate. Its ultimate purpose is to provide a clear picture of the enterprise’s current state and to determine its vision for the future [20]. The objective is to develop and describe business process models based on interviews and documentation received. We adopt the business processes modelling methodology used in many Slovenian projects by the Institute for Business Informatics (IPI) at the Faculty of Economics, University of Ljubljana [9].

3.3. Process merging We distinguish between vertical and horizontal scenarios of process merging. Horizontal scenarios involve the merging of process models at the same level of abstraction and usually in the same modelling notation, whereas vertical scenarios involve models at different levels of abstraction. An example is the merging of a business process model and its underlying implementation [12]. Our scenario presented in the next section involves the merging of existing organisational processes (“as-is process 1, company 1” vs. “asis process 1, company 2” vs. “as-is process 1, company 3”) with the objective of designing a reference business process model (“to-be process 1”). This scenario is presented as a purely horizontal process merging scenario. The goal of this phase is to identify a set of activities that are common to the described domain. In order to be more efficient, we can take advantage of comparison tools (e.g. comparison tables, tree structural views, graphical comparison). A key technique for process merging is the ability to establish correspondences or relations between the elements contained in business processes. These relations allow parts of process models to be clearly identified and provide the basis for systematic process merging [12]. The first step is a detailed comparison of the business process reference models in order to detect similarities and differences. The

comparison is not only made on the process level, but on a more detailed, descriptive level. Based on the comparison we can identify the following possible types of relations: - 1-to-1: the as-is 1 activity has a direct relation to as-is 2 activity; - 1-to-0: the as-is 1 activity does not have a related as-is 2 activity; - 1-to-many: the as-is 1 activity has several related activities in the as-is 2 business process model; - many-to-1: several as-is 1 activities have one related activity in the as-is 2 business process model; and - 0-to-1: the as-is 2 activity does not have a related as-is 1 activity. Common problems of business process merging are: - similar activities/processes are named differently; - processes are designed on a different level of detail; - parts of processes are missing; and - processes are too complex to be merged.

3.4. Reference model verification In this phase, the designed reference model is examined with regard to its consistency and the fulfilment of user requirements [6]. Validation can be done by conducting interviews. It is recommended to involve the same people who participated in the business process modelling phase because they are already familiar with the project. The interview should start with a description of the source business process model to ensure that we understand the process in the same way. After that, we present the proposed reference model and validate whether the reference model is a good representation of the business processes. In practice it is hard to validate a designed reference model. One way of validation is to practically apply the reference model in the domain area and measure the degree of fit. Another approach to validating a reference model involves business process simulations. The results of such simulations enable the effects of possible experiments in business process models to be measured [5]. Modelling tools play an important role in business process simulation. With graphs, reports and animation of the simulation, we gain a better insight into the effectiveness of the process. In the first step we need to carry out business process simulations

457

for the as-is business process models and then compare the results with the to-be reference model. Based on the results we update and improve the to-be reference model to achieve a better degree of fit. A limitation of this approach is that the simulation results always depend on the input parameters, which are not always easy to obtain or measure.

4. Case study The case study is used extensively as a research strategy in practice-oriented fields such as management. As a research strategy it has a distinct advantage in situations when “how” or “why” questions are being asked about a contemporary set of events over which the investigator has little or no control [21]. Case studies typically combine data collection methods such as interviews, questionnaires and observations. A consortium of participating companies is dealing with a large number of customers and suppliers. They employ different ways of communication, depending on the existing capabilities. Procurement and sales processes require the intensive exchange of information and documents. These processes are usually carried out through traditional communication channels. This calls for a lot of manual work (e.g. integration) which increases costs, causes delays and can be a source of transaction errors. The consortium of participating companies sees an opportunity in having a shared portal which would solve these problems. The project aimed to develop an environment of open-source services for electronic data exchange with partners in order to increase efficiency and streamline communications. We were involved in this European project as business consultants and as support for the business process team. The team’s purpose was to identify, model and redesign consortium business processes that would represent a basis for implementing the shared e-business platform.

4.1. Scope definition The first issue we dealt with was which business processes to model and at what level of detail. We started the modelling by drawing a geographical map. The map describes material flows in a geographical context [18]. We placed companies in the consortium, their suppliers and customers on the map and connected them with

the physical material and information flows. In addition, for each node we identified level-two SCOR processes. Based on the selected reference model, the key business processes were Source and Deliver SCOR level-two processes: - S1 (Source Stocked Product); - S2 (Source Make-to-Order Product); - D1 (Deliver Stocked Product); and - D2 (Deliver Made-to-Order Product). The selected processes were nominated by key personnel from the consortium companies. These processes represented the starting point of the modelling activities. Next, we selected the modelling standard, the world renowned standard BPMN, and the business process modelling tool iGrafx. We also identified some additional constraints in the proposed project: - to deal only with those processes that represent the basis for implementing the e-business platform; - to identify (but not describe) customer or supplier business processes; and - to treat Source and Deliver business processes separately, and not as one supply chain.

4.2. Business process modelling The processes were modelled by interviewing people from the companies that perform the activities. First we organised workshops at which employees from all three participating companies learned the basics of business process modelling, modelling notation and modelling tools. Each company in the consortium modelled business process models separately. This phase lasted one month. Since the models reflect business operations, key personnel from the companies were involved and the final version of the as-is model was validated by the business process modelling team.

4.3. Process merging We compared the processes and found that they can be largely standardised. The processes were very similar to each other. The reason could be that the companies work in the same industry and are also in the same size range. The comparison was very useful because we identified weaknesses in the as-is processes. We improved the as-is processes for each consortium company. Based on the comparison we identified all types of relations between the activities. If an

458

as-is 1 activity did not have a related as-is 2 activity then it was frequently the case that the activity was missed during the modelling phase. The results of the graphical comparison were to-be reference models that have characteristics of all three participating companies’ business processes.

4.4. Reference model verification The reference models were validated by the key and end-users from the consortium companies. We held two sessions at which we received comments and questions that provided input for redesigning the reference model. In the next phases of the project the reference models designed in this way were also practically validated. They were used as a basis for implementing the new shared e-business platform. To further validate the reference models we also performed business process simulations. All parameters needed to perform the business process simulation were collected during the business process modelling phase. In the first step we identified the performance of the as-is business process models. We compared the results with the designed reference model and modified parameters (activity duration, delay, decision output possibilities etc.) in order to achieve a closer fit. The business process simulations were useful in this situation, but required very precise models and input parameters.

5. Conclusion The design of reference models is often costand time-consuming. The concept of reference modelling has been introduced to overcome these failures and improve the development of enterprise-specific models. The paper’s contribution is the reference model design approach to merging processes based on existing business process models within a specific industry. The suggested approach is still a work in progress and in the future will be validated via additional case studies. Possible future work in the area of reusable subprocesses, as reference model components, could involve use of the parsing technique RPST (refined process structure tree) suggested by Vanhatalo, Völzer and Koehler [22] .

6. References [1] AGIMO. (2007). The Australian Government Business Process Interoperability Framework. [2] Becker, J., Beverungen, D. F., & Knackstedt, R. (2010). The challenge of conceptual modeling for product–service systems: status-quo and perspectives for reference models and modeling languages. Information Systems and E-Business Management, 8(1), 33-66. [3] Bosilj-Vukši, V., & Spremic, M. (2005). ERP System Implementation and Business Process Change: Case study of a pharmaceutical company. Journal of Computing and Information Technology, 13(1), 11-24. [4] Enterprise Integration Inc. (2007). White Paper: What is a reference model? Retrieved from http://www.eiisolutions.net/resourcecenter/What%20Is%20a%20Reference%20 Model.pdf [5] Eriksson, H.E. and Penker, M. (2000), Business Modeling with UML: Business Patterns at Work, Wiley, New York, NY. [6] Fettke, P., & Loos, P. (2003). Classification of reference models: a methodology and its application. Information Systems and eBusiness Management, 1(1), 35-53. doi:10.1007/BF02683509 [7] Fettke, P., & Loos, P. (2007). Reference Modeling for Business Systems Analysis (1st ed.). IGI Global. [8] Hilt, B. (2007). Predefined reference models – a »living guide« containing proven process knowledge that anyone can use. IDS Scheer AG: ARIS Expert Paper. [9] Institute for Business Informatics – IPI (2012). http://www.ef.uni-lj.si/IPI [10] Kirchmer, M. (2009). Reference Models to Empower MPE. In High Performance Through Process Excellence (pp. 85-100). [11] Kovai, A., & Bosilj Vukši, V. (2005). Management poslovnih procesov: Prenova in informatizacija poslovanja s praktinimi primeri. Ljubljana: GV. [12] Küster, J., Koehler, J., & Ryndina, K. (2006). Improving business process models with reference models in business-driven development. Business Process Management Workshops (pp. 35–44). [13]La Rosa, M., Dumas, M., Uba, R., & Dijkman, R. (2010). Merging business

459

process models. On the Move to Meaningful Internet Systems: OTM 2010, 96–113. [14] Rosemann, M. (2003). Application reference models and building blocks for management and control (ERP Systems). Handbook on Enterprise Architecture, 596-616. [15] Rosemann, M., & van der Aalst, W. M. (2007). A Configurable Reference Modelling Language. Information Systems, 32(1), 1-23. [16] Scheer, A. W. (1998). Business Process Engineering Study Edition: Reference Models for Industrial Enterprises (1st ed.). Springer. [17] Scheer, A. (2000). ARIS: Business Process Modeling (3rd ed.). Springer. [18] Supply Chain Council. (2011). Supply Chain Operations Reference Model. Version 9.0. SCOR Overview. [19] Thomas, O. (2006). Understanding the Term Reference Model in Information Systems Research: History, Literature Analysis and Explanation. In Lecture Notes in Computer

Science (Vol. 3812, pp. 484-496). Presented at the Workshop on Business Process Reference Models (BPRM 2005), Nancy, France. doi:10.1007/11678564_45 [20] Trkman, P., Indihar Štemberger, M., Jaklic, J., & Groznik, A. (2007). Process approach to supply chain integration. Supply Chain Management: An International Journal, 12(2), 116-128. [21] Yin, R. K. (2002). Case Study Research: Design and Methods, Third Edition, Applied Social Research Methods Series, Vol. 5 (3rd ed.). Sage Publications, Inc. [22] Vanhatalo, J., Völzer, H., & Koehler, J. (2008). The refined process structure tree. Business Process Management, 100–115. [23] Winter, R. (1994). Formalised conceptual models as a foundation of information systems development. ENTITYRELATIONSHIP APPROACH - ER '94, 881, 437-455.

460