CBG-Framework: A bottom-up model-based approach for Collaborative Business Process Management

CBG-Framework: A bottom-up model-based approach for Collaborative Business Process Management M.A. Barcelona a,b , L. García-Borgoñón b , M.J. Escalona b , I. Ramos b a Aragón Institute of Technology, c/ María de Luna 7, 50018 Zaragoza, Spain b University of Seville, Escuela Técnica Superior de Ingeniería Informática, Av/ Reina Mercedes S/N, 41012 Seville, Spain Keywords: Business process modelling Bottom-up modelling Model-based engineering Collaborative decision making A B S T R A C T Nowadays most existing products and services are the result of the collaboration of a large number of companies that form a value chain known as Supply Chain (SC). Then individual Business Process Management (BPM) requires a holistic vision that incorporates an inter organizational view that supports SC decision making. This study proposes a novel idea trying to address collaborative BP modelling problem with a new perspective, a bottom-up approach, reusing process models that each organization may have created with a different modelling language. Collaborative Business Generation (CBG) Framework, following Model-Driven Engineering (MDE) paradigm, includes a meta model, a method, a set of model transformations and a support tool to create collaborative BP models from individual ones, maintaining privacy and autonomy in decision making. This paper presents main CBG-Framework elements as well as a real world case study for early validation. 1. Introduction Nowadays most existing products and services are the result of the collaboration of a large number of companies that form a value chain, known as Supply Chain (SC). Globalization and information technologies have helped that currently complex and dynamic SCs exist. Although each organization has its own goals and interests, its ability to optimize decisions is increasingly conditioned by the decisions taken by those companies that are part of its SC. Competition no longer exists among individual organizations but among SCs. In this way, organizations collaborate to optimize decisions that go beyond single improvements. Individual Business Process Management (BPM) requires a holistic vision that incorpo-rates an inter organizational view that supports SC decision making. To achieve efficiency organizations manage their BPs and create models for analysis, improvement, optimization and to ensure their use in a systematic way. There are many BPs Modelling Languages (BPMLs) that support process modelling, although most of them are focused on the individual perspective rather than SC collaboration. Those which cover collaboration propose a top-down approach, based on the design of the overall process and subsequently detailing individual behaviour, so that all organizations must agree on a single language which in practice prevents reuse of the individual perspective. This work provides a novel idea trying to address collaborative BP modelling problem with a new perspective, a bottom-up model-based approach, reusing process models that each organization may have created with their BPML. This proposal is known as Collaborative Business Generation (CBG) Framework, composed by a meta model, a method, a set of model-to-model (M2M) transformations and a support tool, to create collaborative BP models from individual ones, maintaining privacy and autonomy in decision making. The rest of the paper is structured as follows. Section 2 presents the problem definition and the research hypothesis. Literature review is exposed in Section 3. Section 4 summarizes the methodology followed. Section 5 presents the main CBG- Framework elements which are illustrated with a real world case study, detailed in Section 6. Section 7 discusses the proposal and main findings derived from the case study. Finally, Section 8 exposes conclusions and future work. 2. Problem definition and hypothesis Organizations define their BPs individually but then in the real world interact with other companies, customers and suppliers, forming business value chains commonly known as SCs. To define their BPs, organizations choose from the large number of existing BPMLs, betting on a method to redesign, monitor or even execute their individual BPs. In the BPM domain, a collaboration may be seen by three perspectives: (1) Collaborative Business Processes (CBPs), which describe the interaction between two business entities from a neutral perspective, capturing all interactions among the partners [1]; (2) Inter Organizational Business Processes (IOBPs), executed by two or more autonomous organizations, in which at least one of them exposes its internal process as a white box to visualize the collaborative process flow control [2]; and (3) Supply Chain Business Processes (SCBP), as a specific vision of inter organizational collaboration, in which, in addition to different and autonomous organizations, there are dependencies among internal and external processes at various levels, since it requires vertical and horizontal coordination [3,4]. This third interpretation of Business Processes (BPs) drives this work. In order to have a view of the BPs throughout the entire SC, it is usual to generate from scratch a new BP model that incorporates the actions carried out by the different participants. This approach forces a company to duplicate the work and maintain the consistency between that individual vision of its activity and the integrated one in each SC in which it participates. SC are very dynamic, participants enter and leave, new behaviours and policies are added, and decisions are taken in a distributed way, so it is necessary to have flexible and adaptable BP models. If models are modified without considering the changes in the individual BPs it distances it from reality, since each organization will continue to maintain its decisions and information autonomously conditioning the operations in the rest of the SC. To address SCBP modelling there are two major approaches, the top-down and the bottom-up [5], typically used to planning and forecasting demand problems [6].  A top-down approach: when BPs, systems and information flows are defined first at a global level and then each organization adapts its internal behaviour. This model is appropriate in SC where there is a central stakeholder that dominates the collaboration and secondary organizations have few options to influence in SC decisions.  A bottom-up approach: when collaborative BPs emerge from the individual views of each organization, which are adapted to foster collaboration through information exchange and decision making in a coordinated way. This model is appropriate for dynamic SCs, composed by equal pairs, which can be formed in a temporary way and when new actors arise. Typically, a SC is composed by cooperating organizations and their BPs are modelled with different BPMLs, which hampers their interaction and joint representation. So far most initiatives have proposed a top-down approach in which the general SCBP is defined and later the individual BPs are adapted, but in this case all organizations must maintain the same BPML to model both their internal operation and their SC collaboration. But nowadays a company participates in several SCs, so that this work has to be reproduced for all collaborations, something which is really difficult to address in practice. This research proposes the usage of BP modelling as a practical tool to support decision making, in the context of BP re-engineering, considering how individual BP changes may affect SC performance as well as how SC changes may alter individual behaviour. The question is, why all organizations should be forced to create BP models with the same BPML? To achieve collaborative BPM each organization must first manage its internal BPs [7]. Then each company has defined its individual BPs by using the BPML that best suits its needs to describe its internal operations. So the approach presented in this paper tries to reuse these existing BP models and support a diversity of BPMLs using a bottom-up model-based approach. This research considers as a hypothesis the following statement: MDE is a valid paradigm to achieve BPs modelling with an inter organizational approach and can be used to convert SCBP modelling into a way to support collaborative decision making. 3. Literature review In the latest years many proposals have been suggested to cover BP and collaboration modelling, but most of them from the perspective of an individual organization and have not had an inter organizational approach [8]. After a literature review of existing SCBPs modelling languages, shown in Table 1, the main conclusions are shown as follows:  Only UEML allows the usage of different modelling languages. In all the others, all SC participants must share a common one.  The multi-organizational vision and the assignment of tasks to participants is the element best covered in general by most of them.  More than 80% of the proposals do not allow explicitly establishing which elements of the individual process model are public and which are private.  The consistency between the individual view and the collaborative view is one of the elements least covered by the existing proposals, due to the top-down modelling approach. The top-down approach, which starts from the description of the SCBP, and the lack of interoperability among languages and models, obliges to agree to all the organizations in the use of a same BPML to represent both internal operative and SC collaboration, which makes it very difficult to adopt in practice, which is evidenced by the lack of empirical studies on the subject. To the best of our knowledge, and to justify the proposed approach, there is no existing BPML that covers all these following features: Table 1 SCBP modelling languages. Name Ref Petri Nets [9] EPCs (Event-Process Chains) [10] IDEF3 (Integrated DEFinition Methods) [11] UEML (Unified Enterprise Modelling Language) [12] ECA (Enterprise Collaboration Architecture) [13] UMM (UN/CEFACT  S modelling methodology) [14] ebXML BPSS (ebXML Business Process Specification Schema Technical Specification) [15] PIM4SOA (Platform-Independent Model for Service-Oriented Architecture) [16] SCOL (Supply Chain Ontology Language) and SCML (Supply Chain Markup Language) [17,18] BPM for multi-enterprise cooperation [19] SUDDEN DSVL (Domain-Specific Visual Modelling Language) [20,21] VECCF (Virtual Enterprise Chain Collaboration Framework) [22] SCML (Supply Chain modelling Language) [23] UMM for local choreographies [24] BPMN 2.0 (Business Process Model and Notation) [25] IOBPM (inter Organizational Business Process Metamodel) [26] ArchMDE (Architecture-centric Model Driven Engineering) [27] SysPEM (System Process Engineering Metamodel) [28] SimulValor Extension [29] AD UML 2.5 (Activity Diagrams, Unified modelling Language) [30] CSSPEM (Collaborative Software Systems Process Engineering Metamodel) [31]  Privacy: allows establishing which elements of the individual model are visible in the collaboration and which are not.  Bottom-up approach: allows generating the SCBP model reusing the individual models and thus ensuring consistency between both views.  Multi BPML: Support for each organization to use the most appropriate BPML. 4. Research method and solution approach 4.1. Research method To this end, the Action Research [32] method has been used which is an iterative process where experimental parameters are modified according to observation outcomes. It is based on these steps: (1) Planning: where problems are identified and work lines are defined; (2) Action: when tasks are developed; (3) Observation: tasks are carried out by using case studies in order to collect the information needed to obtain a quantitative analysis of the implementation of the proposal; and (4) Reflection: when data are analysed and reviewed to improve the proposal. 4.2. Solution approach In view of the context presented in Section 2, it is emphasized that organizations need to address BP modelling with a SC perspective, which include the interaction among individual and autonomous BPs of each participant. As a conclusion of the literature review, it has been evidenced the difficulty in choosing a BPML. Then the problem may be summarized as the need for a solution that allows creating SCBP models, in other words, to model choreographies of BPs that represent the interactions that are made between black boxes of individual BPs which are carried out by different organizations. The proposed solution approach brings a novel idea, in terms of the ability to address the problem with a bottom-up perspective, reusing BP models that each organization could have created with its BPML, adding to that individual view its collaboration perspective in terms of privacy and choreography restrictions. Then this approach, described in Fig.1, is based on the following steps: (1) Precondition: individual BP models are defined by each SC participant by using any BPML; (2) Step 1: All individual BP models are transformed to achieve their conformance to INROMA metamodel [33]; (3) Step 2: All organizations describe their view of the collaboration in terms of autonomy and privacy at tasks, work products and decision making tasks. As a result, individual BP models include their own view of the collaboration and conform to CBGProcess metamodel; and (4) Step 3: The collaborative BP model is created taking the public elements from the individual perspective of the collaboration, and maintaining the traceability among collaborative and individual BP models. 5. Collaborative business generation framework 5.1. CBGProcess metamodel The first element in the framework is the CBGProcess metamodel, a language to support CBG definition. It has been created as an extension of INROMA [33], a software process modelling language, conceived as an auxiliary language with the aim of facilitating the interoperability and maintainability of software processes. INROMA gives support to describe BPs following a bottom-up approach, although it lacks some features to cover the collaborative view, in particular: (1) No multiorganizational approach; (2) No cooperation tasks; (3) No collaborative work product; and (4) No collaborative metrics nor indicators. Despite its initial scope was software domain, it may be applied to any BP modelling domain and as it is UML-based, it offers the extension mechanisms to be adapted to the CBP specific domain. This way, CBGProcess is shown in Fig. 2 where new elements have been highlighted in yellow:  PrivateActivity metaclass represents the activities of the process that the organization wishes to keep private and that will not be part of the collaborative process. Fig. 1. Solution approach.  PrivateIndicator metaclass represents how an organization wants to individually measure a BP from the associated metrics.  PrivateMetric metaclass constitutes a quantitative measure that will allow us to evaluate a certain aspect of the process at the individual level.  PrivateProduct metaclass represents any piece of information consumed (input), produced (output) or modified (input and output) during the execution of an activity that is to be kept private outside of the collaborative process.  Organization metaclass constitutes a business entity that is part of a collaboration. In addition, there is a set of INROMA elements whose semantics changes, as they represent elements of a collaborative BP:  Activity metaclass constitutes an activity of a collaborative process.  Indicator metaclass represents the way in which all organizations at a global level want to measure a process from the associated collaborative metrics.  Metric metaclass constitutes a quantitative measure that will allow us to evaluate a certain aspect of the process at the collaborative level.  Product metaclass any piece of information consumed (input), produced (output) or modified (input and output) during the execution of a collaborative activity. To complete the language definition a set of OCL-based [34] restrictions are detailed as follows. Fig. 2. CBGProcess metamodel.  A CBP is a single entry process so that there is exactly one single start element in the process. OCL fragment 1 describes this restriction. Restriction 1  A CBP is a multi-output process so that at least there is one final element in the process. OCL fragment 2 describes this restriction. Restriction 2  A CBP has at least one Activity. OCL fragment 3 describes this restriction. Restriction 3 5.2. Model transformations This section exposes how using the model-to-model (M2M) transformations from the MDE domain, individual BP models can be converted to collaborative BP models, as it is shown in Fig. 3. As there is still no established basis on how M2M transformations can be described [35] and there are different approaches [36], Query/View/Transformation (QVT) Relations [37] has been selected to define M2M transformations due to: (1) It is a OMG standard; (2) It is bi-directional; and (3) It has a graphical representation. This way, Fig. 4 shows the top relation which generates the rest of the elements by the recursive invocation of MapActivities, MapIndicators, MapInitial, MapFinal and MapConditional relations. This M2M transformation includes 13 relations that have been defined by their QVT Relations view. 5.3. CBGProcess methodology This section details the step by step method that allows, from the individual view of a collaboration described by a CBGprocess compliant model, with public and private elements, defining the collaborative BP model. To this end it is necessary: (1) To separate the individual from the collaborative view of a BP of an organization; (2) To maintain organization privacy and autonomy in decision making when it is required; and, (3) To share BP activities and products that any organization want to publish in a collaborative BP. The method, exposed in Fig. 5, is defined by a list of steps at the theoretical level, since to facilitate their adoption some of these actions will be automatically supported by a tool as described in Section 5.4. In the first place, preconditions are exposed as the conditions to be satisfied just before the beginning of the method, which are the Fig. 3. M2M INROMA2CBGProcess transformation in the CBG-Framework. Fig. 4. QVT relations view of Process2Process relation in the inroma2CBGProcess M2M transformation. following: (1) Precondition 1 (PRE1): there is a collaborative BP scenario based on a set of individual BPs from different organizations; and (2) Precondition 2 (PRE2): there is an INROMA compliant model for all individual BPs. From the preconditions, the method is defined by a sequence of actions: (1) Activity 1 (A1): all individual BPs that form part of the collaboration must be identified and labelled to their corresponding organization, thus generating the relevant instances of the Organization; (2) Activity 2 (A2): each organization defines what input and output information elements it wants to receive or share in the collaborative view. This will identify the Product that will be part of the collaborative BP and those PrivateProduct that will be kept privately in each organization; (3) Activity 3 (A3): based on the previously identified collaborative products and on the activities described individually by each organization, it will be necessary to identify those activities that are carried out in Fig. 5. CBGProcess methodology to define collaborative BP model from individual ones, described by an INROMA process diagram. collaboration. To ensure traceability with individual process models, all activities that are maintained autonomously and individually will become PrivateActivity on individual models; (4) Activity 4 (A4): Once the fundamental elements of the collaboration have been identified, then the flow of the collaborative activities has to be defined, following the flow elements of the metamodel, noting the participants and the products resulting from them; and (5) Activity 5 (A5): finally, metrics and indicators have to be established. These gures allow quantitatively analyzing the collaborative process, elements that will be annotated as Metric and Indicator respectively. It is possible that the metrics and indicators coincide with the individual ones, be they a set of the previous ones or be new, although the usual thing will be that the way in which a process is measured at individual level does not coincide with the aggregated view of a collaboration, so the last scenario will be the most usual. The way an organization measures and evaluates the process at the individual level will be maintained as PrivateMetric and PrivateIndicator. Finally, as a result of the method, there is a postcondition: Postcondition 1 (POST1): model of collaborative BP defined from the individual processes of the organizations conforms to CBGProcess metamodel. 5.4. CBG-Tool Finally, the framework includes a support tool known as CBG- Tool to facilitate the creation of models and the execution of transformations from a practical point of view in order to achieve its industrial usage. CBG-Tool is developed as an add-in over Enterprise Architect (EA) [38] tool. To support model editors, UML extension mechanism has been opted by creating a UML profile [39], so that languages based on an industry-wide standard can be adopted and favouring compatibility with UML compliant tools. CBGProcess support is achieved by the definition of its UML profile, which is observed in Fig. 6. Notice that the concept Activity is shown twice because one refers to CBGProcess element which extends the UML Action and the other refers to the UML concept which leads the CBGProcess Process element. Additionally, a concrete syntax for CBGProcess has been defined as it is exposed in Fig. 7. Model transformations have been implemented in C#.NET, and are automatically executed in the editor canvas using a contextual menu, as it is shown in Fig. 8. 6. Case study Due to the Action Research method followed in the study, there were several projects where preliminary outcomes were applied and, sometimes, redefined. To validate the first CBG-Framework release, a real world project has been chosen and it is described in this Section. Lessons learned are detailed in Section 7. Information Technologies for the Collaborative Supply Chain Project (ITChain, TSI-020302-2010-80) was a research project funded by Spanish Ministry of Industry, Energy and Tourism during 2009–2013. The project had, among others, the objective to achieve a collaborative decision making through the modelling of collaborative BPs and the simulation of scenarios. There were three real pilots and this research will be focused on the specific case that covers the collaborative BP modelling in the fresh fish SC, developed by CARREFOUR and ITAINNOVA. This scenario includes the global process from acquiring freights in fish market to distributing them to the point of sales, through logistics platforms of manipulation and storage of the product scattered throughout the national territory. During the project more than 10 SCBP models were defined, and redefined, following a top-down approach. Then the problem which motivates this study was evidenced. This way, this study reproduces again the same problem with the new CBG-Framework, in order to validate the initial hypothesis. In this SC, there are more than 15 different companies that need to collaborate with a common mission. These organizations play three roles: (1) Buyers: a set of individual buyers who participate in the auction coordinated by a central agent; (2) Logistics managers: Fig. 6. CBGProcess UML profile. responsibles of warehouses and logistics platforms in charge of handle orders, deliveries and receptions in a synchronized way with transport; and (3) Transport managers: who receive a transport plan and responsibles for taking freights in time. Following the CBG methodology, first the individual BP models from each company have been taken, conform to their specific BPML, and they have been transformed to a INROMA compliant model. Fig. 9 shows the purchase coordinator individual BP model. Then, using the M2M transformations and the method, it has been defined how each company has an individual view of the collaboration. As a result, a CBGProcess compliant model is achieved which includes the collaborative (public) and individual (private) activities, products, metrics and indicators. Fig. 10 shows the individual view of the collaboration from the purchase coordinator point of view. Finally, taking all public elements from individual BP models, the collaborative BP model is created as it is shown in Fig. 11. This work has been done to all stakeholders and organizations that support the process of buying and distributing fresh fish, from the markets to the point of sale, through logistics platforms in Spain. This real complex scenario has allowed us to early validate qualitatively that CBG-Framework supports a reliable method to create a collaborative BP model – in less time, with fewer errors – and facilitates the BP models maintainability. But the most valuable contribution, according to case study findings, is that it allows organizations to be focused on their own BPs and how each collaboration may affect them to achieve an overall efficiency, making continuous decisions and changes to BPs with the guarantee that individual BP models are aligned and traced to SC model. Fig. 7. CBGProcess concrete syntax. Fig. 8. CBG-Tool screenshot. 7. Discussion This section summarizes the context of the study and main findings derived from the case study. On one hand, nowadays competition in the markets is not among the individual companies but among SCs, so that organizations need to improve their BP with this collaborative perspective when the goal is to achieve an overall efficiency based on the interactions among activities performed by different SC stakeholders. On the other hand, the same organization can be part of a large number of SCs, playing a different role in each. Its internal operations and decisions are defined and quantified individually, trying to give value to all SCs but focused on its organizational goals, metrics and indicators. In this dynamic context, creating value chain models entails a greater complexity than modelling the individual BPs since each member wants to preserve: (1) Its privacy in its internal process and the information managed; and (2) Its autonomy in decision making, maximizing their goals while fulfilling the commitments acquired with the rest of the SC. This problem has been addressed in the literature, but always with a top-down approach. It is worth mentioning some initiatives developed in specific domains such as GS1 [40] (formerly RosettaNet [41]) for logistics, OTA [42] for tourism, HL7 [43] for health or SWIFT [44] for financial services among others, who have Fig. 9. Individual BP model of the purchase coordinator conforms to INROMA.