# Semi-automated BP Integration in Virtual Organizations

Katarzyna Adamiak, Hodjat Soleimani Malekan, Hamideh Afsarmanesh

## ► To cite this version:

Katarzyna Adamiak, Hodjat Soleimani Malekan, Hamideh Afsarmanesh. Semi-automated BP Integration in Virtual Organizations. 17th Working Conference on Virtual Enterprises (PRO-VE), Oct 2016, Porto, Portugal. pp.87-100, 10.1007/978-3-319-45390-3_8. hal-01614606

HAL Id: hal-01614606

https://inria.hal.science/hal-01614606

Submitted on 11 Oct 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Semi-automated BP Integration in Virtual
Organizations

Katarzyna Adamiak¹, Hodjat Soleimani Malekan², Hamideh Afsarmanesh²

¹Barbusselaan 72, 1102 TX Amsterdam, The Netherlands

²Informatics Institute, University of Amsterdam, P.O. Box 94323, 1090 GH Amsterdam, The Netherlands

adamiakkasia@yahoo.com

{ h.soleimanimalekan, h.afsarmanesh } @uva.nl

**Abstract.** Organizations frequently form various types of partnerships, of which one form is the virtual organization (VO). In VOs, members share part of their capabilities and capacities to seize bigger market opportunities. For effective collaboration however, also sharing knowledge and details about their business processes (BPs) and services is required. If achieved, VO can act as a large and more capable organization, with a repository/pool of services. But to mimic large organizations, VOs need to both drop less optimized overlapping services from this repository and integrate similar services. Our stepwise semi-automated methodology facilitates creating a most optimized pool of BPs with clean and valid integrated processes/services for the VO. A chain of software tools is also introduced in the methodology next to some partially manual steps. The presented solution is applied and evaluated in a real construction industry.

**Keywords:** Virtual organizations, business process integration.

# 1 Introduction

Due to globalization and increased dynamism of industrial environment, organizations increasingly form partnerships, such as virtual organizations (VOs), in order to improve their performance and increase their competitive advantage. In VOs, organizations share knowledge, skills and resources to seize market opportunities, create innovative products, and provide value-added services [1]. As such they become a great enabler to increase enterprise agility, consequently ensuring better ability to survive in dynamically changing market conditions. In this research we adopt the following definition of the VO: "an association of legally independent organizations (VO partners) that come together and share resources and skills to achieve common goals, such as acquiring and responding to a market/society opportunity [1]". We further focus on addressing the BPs that are practiced by individual VO partners, and how they can be effectively shared, integrated, and used for the benefit the VO as a whole.

This paper introduces our semi-automated approach through one real example case of cooperation from the construction industry, which also serves as the proof of concept to validate our approach. In construction industry, partnership formation is traditionally a popular practice; however, often performed in an unstructured way. In a typical
project, different organizations specialized in various disciplines are required to jointly fulfil multiple construction tasks. In our real example scenario, organizations co-work during the life time of every project, while they do not share and/or lend their business processes (BPs) to each other. In other words, each involved organization provides a set of own services needed for each construction project, and executes its services during different stages of the project. But currently organizations do not share/lend their processes, which prohibit them from working more efficiently together and/or delivering composed value-added services in the VO, as it typically happens among different departments within one large organization.

A collaborative operation in a niche market in construction industry is exemplified here, involved in construction of eco-friendly buildings. This type of projects is currently popular, with increasing number of interested investors. However, construction of eco-friendly buildings requires the use of novel technology, materials, and expertise from various disciplines. Through cooperation among a set of organizations however, a VO can successfully deliver such niche projects. This provides more opportunities and increases the reputation of the VO, consequently bringing more profit to the involved smaller organizations and increasing their chance of survivability in market turbulences. Continued collaboration among organizations and sharing all their abilities in the VOs create the base for partners to provide more efficient as well as a wider range of services and scope of operation. For instance, to enable proper management of their joint operations in VOs, participating organizations need to share their BPs. In the past, organizations who worked only in one project were reluctant to share and/or merge their BPs. They considered this against their autonomy and confidentiality concerns. However today, once negotiating a VO collaboration contract, organizations are more willing to do so; especially once realizing advantages resulted from their BP integration in VOs. BP integration helps organizations to standardize their practiced BPs and use each other's experiences and best practices. Furthermore, it helps with getting to know about the expertise of other organizations, which also underpins the potential of their additional collaboration in future. Another advantage that is the target of this paper is that the BP integration facilitates formation of an optimized and consistent repository of BPs at the VO level. Such processes can then support formalizing the VO collaboration plans among different organizations, so that together they can act as one larger organization. As such our approach guarantees the lack of redundancy in the BO pool, which can be resulted from simply storing all BPs of all organizations in one VO repository.

The main aims of our BP integration in VOs are twofold: (i) creating a shared BP repository while removing redundancies, thus reducing the size and enhancing common understanding about existing BPs by all VO organizations, and (ii) facilitating creation of composed value-added services. While the methodology presented in this research primarily addresses the former aim above, its last two stages are also applicable to the latter aim of supporting BP integration.

To build a reliable research background for the area of BP integration and to verify the existing approaches against requirements for our research, an extensive Systematic Literature Review (SLR) [2] is performed, identifying research gaps in the area. Accordingly, it is shown that step-wise definition of a BP integration methodology is missing in approaches introduced in related research, such as in [10, 11]. The results of this extensive SLR, is the subject of a forthcoming paper. We therefore aim at
introducing a semi-automated methodology needed to constitute the optimized set of
processes in the VO context. Our general research question (RQ) is: *How to ensure
successful co-creation of clean and valid integrated-processes among member
organizations in a VO?* Three partial research questions follow this main RQ, as
follows: RQ.1 *Which steps are needed to be taken by VO member organizations for
creating a common set of integrated-processes?* RQ.2 *How to ensure the created
integrated-processes are clean (i.e. syntactically correct)* ? RQ.3 *How to ensure the
methodology is valid and applicable to the VO context?*

The paper is structured as follows. Section 2 introduces the methodology applied for
achieving an optimized pool of BPS and for BP integration. Section 3 addresses the
suitability of our introduced methodology in an example case from construction
industry. Finally, the paper is concluded, addressing a few areas of future research.

## 2 Methodology for BP Integration

This section addresses the RQ.1 and RQ.2 We design a semi-automated methodology, guiding the process of integrating BPs within a VO. The methodology consists of a set of practical steps that can be performed using the suggested tool chain, in order to successfully introduce a collection of clean and valid integrated-processes for collaborating organizations. Depending on some specific situations, when the BPs of an organization are already formalized, the steps 1 and 2 can be omitted (see Fig. 1). Also some other steps might need to be applied multiple times, e.g. the steps 4 and 5 that for instance need to be executed multiple times when a specific merge candidate group includes more than two BPs. Also, if more than one *merge candidate groups* are found in the VO, the part of the methodology from steps 4 to 6 must be executed multiple times. Please note that the steps in our methodology, while mostly automated, apply different methods varying among: manual, semi-automated and automated methods. All mentioned steps are captured in Fig. 1 that illustrates the BP integration methodology flowchart. Each step, from 1 to 6 in Fig. 1, is then described in more details in sub-sections 2.1 to 2.6 respectively. We furthermore introduce justifications for design of our methodology based on its compliance to [3] – Design Science guidelines. Section 3 provides the validation of our proposed methodology, based on its application to a real construction case study.

### 2.1. Formalize Representations of BPs

Each VO member organization performs a number of business processes (BPs) within its individual operations. Those processes are not always formalised, and sometimes described only textually or in another ad hoc manner. For the purpose of processes' comparison, analysis, and integration, a collection of relevant BPs must be formalized in a consistent and common manner along all participating organizations. The formalization includes: process identification, process discovery and process model design [4]. In real-life, organizations formalize the design of their BPs in various ways, e.g. with use of workflow charts, UML Activity Diagrams, BPMN process models, EPC process models, etc. Different business process modelling languages (BPMLs)
were evaluated in [5], who defined the Business Process Model and Notation (BPMN) as the most suitable BPML for use in CNOs. Therefore, BPMN is decided as the language used in our methodology. Varieties of tools are available for designing the BPMN process models. We indicate the web-based Signavio software, as one of the top tools and most used to support the BP design [6]. Please note that we use Signavio as the base environment to better represent the executed processes.

<figure><img src="image_2.png" /><figcaption>Fig. 1. BP integration methodology flowchart</figcaption></figure>

In summary, our formalization of BP representations includes following sub-steps:

* BP identification – presenting a list of relevant BPs performed by all VO member organizations and providing the appropriate naming of the identified BPs,

* BP discovery – collecting the data regarding each BP and investigating it to properly describe the overview of actions performed in the specific BP,

* BP design – illustrating the described BP by designing its graphical model representation in BPMN.

## 2.2. Check Quality of Inputs

The input BP models must be executable. This means, the XML logs of the entire designed BPs must be correct and readable by the software. Existence of any modelling
errors disables the further comparison, analysis and proper integration of the BPs. Therefore, all the possible inconsistencies, including dead-lock or live-lock incidents, must be identified and removed at this early stage. Also we use Signavio, as it incorporates the functionality that provides the check of BP model's correctness.

## 2.3. Find the Qualifiers for Merge

Multiple similar BPs may exist among various organizations. In case of forming a VO, we need to collect all its member organizations' BPs in a shared repository, which may contain redundancy occurrence among the BPs in the repository. What is more, the repository may contain a number of BPs with repeated process instances, which are difficult to analyse. Therefore, as a first step we identify the similar BPs within a VO, to enable their merge in the further steps thus, aiming to reduce the size of the BP repository to the extent possible.

A number of process similarity evaluation algorithms are introduced by the researchers and a few are implemented in open source software. One such algorithm, in [7] provides the graph similarity calculation based on labelling, structural and behavioural analysis of the input processes. This algorithm is implemented in ProM 5.2 tool that is used in our methodology as the means for performing the BPs similarity check.

However, by only evaluating the similarity among all gathered BPs, the merge qualifiers' identification is not possible. In other words, here we are not searching for the similar pairs of processes, but the potential groups of BPs that are similar with each other and can be merged. To provide the more accurate semi-automatic merge qualifiers identification we identified two sub-steps. Those steps require pre-processing of BP collection, by word similarity checking on the names of processes.

### A. *BP outliers potential*: Exclusion candidates identification

First sub-step aims at retrieving a set of BPs, which stand highly individual in the BP repository and can be excluded from the further analysis for similarity with other BPs. The main goal here is to potentially narrow the number of BPs included in the analysis.

### B. *BP cluster potential*: Merge candidates identification

Second sub-step aims at providing a set of potential merge candidate groups that will be next analysed to consequently form a final set of BPs to be merged.

Both sub-steps are supported by semi-automatic identification of the BP clusters and BP outliers, based on the semantic distances related to their names. A function that displays the process names' map (illustrating the string semantic distances) is available in the WordStat software [8], trial version, which we have used. Based on the obtained word map, we can manually draw the circles around observable identified clusters, at the same time indicating the BP outliers.

## 2.4. Find Commonalities and Differences

The particular BP models located within the identified groups of BPs (the final merge candidates) at this stage must then be compared with each other to enable the merge.
In [9] technique to compare BP models and indicate their differences is suggested, which is implemented in ProM 5.2 software. However, such detailed analysis can only be performed only on pairs of two BPs. Therefore, we approach both the differences identification and merging activities in hierarchical steps. In the provided hierarchy, we compare pairs of the most similar BPs with each other, define their differences, and at the same time their commonalities (containing the same fragments), and merge the processes as described in the next step. Next, one pair of merged processes is next compared with another pair of merged processes (or a single BP), their commonalities and differences are examined, and they are merged at a higher hierarchical step. This iteration lasts until we reach the top level of the hierarchy and all the BPs in a merge candidate group are integrated forming one final integrated-process. The abstraction of this approach is illustrated on Fig. 2.

<figure><img src="image_3.png" /><figcaption>Fig. 2. Identifying differences in the merge hierarchy</figcaption></figure>

## 2.5. Merge

Based on the information retrieved in the previous step, we can merge the processes by identifying the common fragments and resolving the differences. Some BP merging algorithms are available in research and implemented in an open source software, e.g. “EPC merge” function introduced in ProM 5.2 in [10]. We evaluate the identified automated merging algorithm, by comparing the automatically obtained result with the desired manually created integrated-processes. Based on evaluation of this algorithm, after applying it on our construction case study (see section 3.5), we decided to provide this task manually. This was mainly due to the maturity level of the involved companies. The manual merging is performed mostly according to a method of [11] and is provided with the use of Signavio as the base environment. The main merging tasks include:

- Deciding on final labelling of equivalent nodes (e.g. deciding on using a more descriptive label)

- Adding a node (preceded by “XOR” split) that is not present on one of the merged models
- Rearranging the structure of fragments, which represent different sequence; e.g. if two nodes are provided in two BPs in an opposite sequence, we rearrange them into a parallel structure preceded by “AND” split

- Adding gateways where necessary, e.g. if two BPs contain different nodes placed on the same position, both nodes should be included in a merged process, preceded by an added “XOR” gateway

- Merging gateways, e.g. if two BPs contain different gateways (“AND” and “XOR”) placed on the same position, these gateways should be merged into a configurable gateway (“OR”)

The processes build upon each other, by adding the next BPs within the specific merge candidate group. After merging a pair of BPs, we return to step 2.4 to define the commonalities and differences of the next pair of BPs and merge this pair into one BP. This iteration lasts until all BPs in a specific merge candidate group are merged. Consequently, we obtain an integrated-process that includes all the nodes, structures and behaviours included in its entire set of initial BPs.

## 2.6. Check Quality of Outputs

This step together with step 2.2. on *Check quality of inputs*, address concerns of RQ.2. Cleanness of the output processes is examined in the same way, as for the input processes, i.e. by Signavio automatic process quality check. The indicated errors and/or structure warnings must be reviewed, after which the process can be improved. After obtaining a clean integrated-process, we proceed to integrating the next merge candidate group’s BPs, by returning to step 2.4. This iteration lasts until we obtain a complete set of integrated-processes.

## 2.7. Methodology Justification

The purpose of the presented solution is to contribute to development of the field by introducing a semi-automated BP integration methodology for organizations that co-operate in a VO. It is important to ensure that the presented solution is relevant and useful in practice. Therefore, the methodology was created in compliance with seven guideline criteria for proper design science research, as introduced in [3] and briefly explained below.

1) *Design as an Artifact* – our methodology of BP integration is a viable academic artifact aiming to provide practical support in the operation phase of formed VO.

2) *Problem relevance* – the solution supports an important and relevant business problem: sharing processes among partners in VOs, of special interest to SMEs.

3) *Design evaluation* – our methodology is evaluated based on a real case study of ten individual organizations in a VO, to examine its usability and usefulness.

4) *Research contributions* – the proposed methodology is innovative, effectively supports VO formation, and contributes to partners’ BP sharing and integration.

5) *Research rigor* – the rigorous research methods is applied to both: identifying the gaps and building research foundations, through the SLR, and evaluating every step of the proposed solution through the real case study in section 3.
6) *Design as a search process* – addressing the identified gaps, each methodology step is designed applying the state of the art in research, when it addresses the needs of the step, e.g. algorithms needed for the BP graph similarity evaluation.

7) *Communication of research* – we aimed at designing a methodology that is understood and usable by both technical and managerial staff at the organizations for their effective BP integration in VOs. Additionally, we aimed to provide the base for software system engineers and designers that intend to develop software to support the automated BP integration in VOs, thus at providing a set of guidelines for building the new software architecture.

**3 Evaluation of BP Integration Methodology**

In this section RQ.3 is addressed by applying and thus evaluating the methodology introduced in section 2 on a real large example case from building industry. This exercise proved fruitful, and the lessons learned and encountered limitations during this practical exercise, provides the base for future research in this area, as addressed in Section 4. This industry case concerns ten SMEs operating in the Polish market. These organizations have different complementary expertise, including: medium-size Construction (CC), Plumbing (P), Heating/Ventilation and Air-Conditioning (H), and Landscaping (LC), as well as some very small (one-person) SMEs including the Electrician (E), Carpenter (C), Surveyor (S), Excavator (EX), Tiler (T), and Roofer (R). Fig. 3 provides a context model for their typical interactions in a construction project, where the ten companies are classified as contractors.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Construction case study context model</figcaption></figure>

A commonly used name for “customer” in building industry is investor. The investor is usually not a specialist in a construction domain, so the help of control inspectors is
often needed during the project. Control inspector is a source of practical information for the architect and the investor, and is a representative of the investor on the construction site, controlling the quality of provided services.

At present, contractors operate individually at the construction site. While the same group of companies usually work together in similar projects, there is currently no long-term agreement for collaboration among the involved organizations. Therefore, the situation does not support process sharing and delivering value-added services by them. However, the construction industry remains increasingly competitive, and difficult to survive in, especially for SMEs that are analysed in our case study. They are continuously surpassed by large construction companies that offer fast services, which are cheaper but with lower quality. Therefore, the emergence of niche high quality construction projects enables SMEs collaboration through VOs, to increase their profitability, survival rate, and seizing more market opportunities. In the remaining of this section we briefly address in subsections 1 to 6, the application of the steps introduced in section 2 for our BP integration methodology, to the real case study of ten collaborating contractor companies, as represented in Fig. 3.

## 3.1. Formalize Representations of BPs

For the ten contractor members in this VO, a total number of 82 BPs are identified. Using textual descriptions of these BPs provided by companies, their BPMN models are developed. One example such process, for “supplying materials” performed by the Electrician company [E], is presented in Fig. 4 and preceded by its textual description.

Electrician - supply materials [process E2]: *Supplying starts when a need for materials appears. Then, Electrician calculates the amount of needed materials, in parallel with searching other suppliers' offers. As an outcome of these tasks, a materials request is created and sent to another specific supplier. In the end, both the requested materials and an invoice are delivered and the process ends.*

<figure><img src="image_5.png" /><figcaption>Fig. 4. E2 process formalization (“SP-M” – supplier of materials)</figcaption></figure>

## 3.2. Check Quality of Inputs

All designed BPs are quality checked by Signavio software for potential syntactic
<figure><img src="image_6.png" /><figcaption>Fig. 5. Quality check by Signavio - process with error and warnings next to XOR</figcaption></figure>

problems. As an example, imagine that by mistake for E2 we generate the BP in Fig. 5. Running Signavio on it indicates some problems found for Electrician's "supplying materials" process (E2), as indicated in Fig. 5, with red "!" next to the XOR operation (in the center). The cleaned process is then produced to correct the syntactical errors, as shown in Fig. 4.

### 3.3. Find the Qualifiers for Merge

Analysing the formalized 82 BP models can spot several BPs that are more or less repeated by a number of organizations within this VO. Identification of the so called *merge qualifier processes* is the necessary first step in BP integration. Supported in semi-automated manner, this step identifies similarities among such processes.

Candidate BPs for both classes introduced in Section 2.3 – potential BP outliers and potential BP clusters – are identified based on two similarity checks: first on name similarity analysed with WordStat software, and second on graph similarity analysed with ProM 5.2 software. Note that only cross-organizational BP similarity is checked and not intra-organizational similarities. Then using the Link Analysis function a word map is created visualizing all similarities. Using the map, we first manually cluster potential candidate BPs for merge, as presented in Fig. 6. Each of the eight groups indicates a potential candidate for clustering and the rest are 27 potential outliers among the 82 BPs. The applied logic is explained further below.

*Exclusion/outlier candidate identification* – Running the two automated similarity checks identify that 27 out of 82 processes have little similarity (up to 6.7%) to any other BP. Therefore these processes are 93.3% different than others. Hence, produced results indicate BP outliers, and are excluded from further steps of this methodology.
<figure><img src="image_7.png" /><figcaption>**Fig. 6.** Process names word map and clustering</figcaption></figure>

*Merge/cluster candidate identification* – Eight groups are manually created on the results from running of the two automated similarity checks addressed above. In order to validate these clusters for merge purposes, we run automated graph similarity calculations once within each group, and once outside of these groups, with the use of ProM 5.2 tool. This task however requires a double conversion of the BPMN models (through Petri Net into EPC), since the automated comparison tool is only available for the EPC models, and to the best of our knowledge, there are no open source software that offers a single conversion between the BPMN and EPC languages. In practice, the first conversion (into Petri Net) was provided in ProM 6.4, and the second conversion (into EPC) was done in ProM 5.2. While this is the shortest possible way, we are certainly aware of the fact that the double conversion may cause some data loss, and thus may influence the results. For the similarity evaluation we used a threshold of 35%, even higher than the acceptable estimation stated in [12] that uses 33% similarity threshold. Table 1 shows positive (above threshold) and negative (below threshold) similarity results, inside and outside each merge candidate group.

<table><caption>**Table 1.** Merge candidate groups' results overview</caption><thead><tr><th rowspan="2">Merge candidate group:</th><th colspan="2">Percentage of results that are: (inside the group)</th><th colspan="2">Percentage of results that are: (outside the group)</th></tr><tr><th>Similar (result > 0,35)</th><th>Not similar (result ≤ 0,35)</th><th>Similar (result > 0,35)</th><th>Not similar (result ≤ 0,35)</th></tr></thead><tbody><tr><td>1</td><td>57,14</td><td>42,86</td><td>26,43</td><td>73,57</td></tr><tr><td>2</td><td>100</td><td>0</td><td>12,50</td><td>87,50</td></tr><tr><td>3</td><td>77,14</td><td>22,86</td><td>13,75</td><td>86,25</td></tr><tr><td>4</td><td>100</td><td>0</td><td>23,56</td><td>76,44</td></tr><tr><td>5</td><td>61,43</td><td>38,57</td><td>8,00</td><td>92,00</td></tr><tr><td>6</td><td>100</td><td>0</td><td>22,47</td><td>77,53</td></tr><tr><td>7</td><td>55,00</td><td>45,00</td><td>10,76</td><td>89,24</td></tr><tr><td>8</td><td>86,67</td><td>13,33</td><td>14,81</td><td>85,19</td></tr></tbody></table>
Based on the right part of Table 1, we assess the usability of the proposed method. We can notice that inside all groups, the rates of their BPs being similar to any of the BPs outside of merge candidate groups (indicated in the 2nd column from right) is significantly lower than the rates of BPs that are not similar (indicated in the 1st column from right). In fact, the positive similarity with BPs outside the group is measured mostly under 25%. Therefore, the method proves its applicability, by showing lack of similarity with other BPs, at a satisfactory level. By analysing the left part of Table 1, we can evaluate the internal group BPs and their candidacy for integration within the specific group. Furthermore, checking similarities inside each group, the similarity among BPs is larger than 50% and sometimes 100% (indicated in the 4th column from right). The main aim here is to identify and suggest to users groups of BPs as candidates for merging and those that are outliers in this process.

To assess the internal structure of each group, we must look closer into individual BP graph similarity check results. Groups 2, 4, and 6 show completely similarity internally, therefore they represent very good candidate for BP clustering. So we then analyse only each remaining group manually by domain experts, examining details of similarity checks among all their BPs, and deciding if they can or cannot be merged.

## 3.4 Find Commonalities and Differences

With automated software, we identify differences in the merge hierarchy for each of the eight groups, and resolve difference with manual help from experts. To give an example, consider merging of two BPs in group 5: C2 for “materials ordering”, and T2 for “procure materials”, which are identified as being highly similar (identified with 79.6% similarity, in previous step), only 4 simple differences are identified by the software. The BP models of these two processes are presented in Fig. 7.

<figure><img src="image_8.png" /><figcaption>Fig. 7. BP models C2 and T2 before merging</figcaption></figure>
## 3.5 Merge

At this stage common fragments are identified and differences are resolved manually to reach the merged BP, as described in Section 2.5. The manual merge is however provided step-wise, according to the merging hierarchy developed in Section 3.4. For the introduced example case (merging C2 and T2) we can notice that the process C2 actually contains the structure of process T2. The activities of “Searching suppliers offers” and “Calculating material needs” that are organized in a sequence in T2 can be therefore added to that sequence using additional AND split and join for them. However, for the needs of process C2, this sequence can be executed in parallel, as illustrated on its initial model. Concluding this merging instance, the process “C2 + T2” generates exactly the same as process C2, as in Fig. 8.

Note that, as mentioned in section 4.5 we aimed at including all the nodes, structures and behaviours of the initial BPs. However, some additional decisions are always made by expert decision makers, e.g. regarding removal of a node and not including it in the model.

<figure><img src="image_9.png" /><figcaption>Fig. 8. Merged model C2 + T2</figcaption></figure>

## 3.6 Check Quality of Outputs

Since our integrated-processes are also created in Signavio software, we provide the quality (i.e. the syntactical correctness) check the same way as introduced for the section 3.2. In general, the integrated-processes are complex, so there is a higher risk of generating certain gateway inconsistencies, e.g. causing dead-lock errors in the resulted integrated BP. Therefore, it is essential to check if any resulted process includes such errors or ambiguities and if so, to disambiguate them. Semi-automated disambiguation of BP models is the subject of one of our ongoing research area, and will be reported in forthcoming publications.
## 4 Conclusions

The introduced BP integration methodology indicated the main tasks to be performed, and tools to be used by organizations, in order to integrate BPS in an established VO. We have identified that similarity checking based on BP names causes many difficulties for the software, and using shared BP names dictionary would increase the quality of this stage of the methodology. Another aspect indicated in research limitations is that the methodology needs a proper automatic merging tool that ensures a good quality of outcome processes that can be also disambiguated and executable. The step of merging the BPs is currently the most time-consuming task, highly influencing the methodology application time. Therefore, creation of an efficient and accurate merging tool is the next step of improving the BP integration methodology.

## References

1. Afsarmanesh, H., Camarinha-Matos, L.: A framework for management of virtual organization breeding environments. In: Collaborative networks and their breeding environments, Springer, pp. 35--49 (2005)

2. Kitchenham, B., Brereton, P.: A systematic review of systematic review process research in software engineering. Information and software technology, vol. 55(12), pp. 2049--2075 (2013)

3. Hevner, A., Chatterjee, S.: Design science research in information systems (pp. 9--22). Springer US (2010)

4. Dumas, M., La Rosa, M., Mendling, J., Reijers, H. A.: Fundamentals of business process management, Springer, Berlin (2013)

5. Malekan, H. S., Afsarmanesh, H.: Overview of Business Process Modeling Languages Supporting Enterprise Collaboration. In Business Modeling and Software Design (pp. 24--45). Springer International Publishing (2014)

6. Chrobak, P.: Overview of business process modelling software. Prace Naukowe Uniwersytetu Ekonomicznego we Wrocławiu, vol. 205, pp. 84--93 (2011)

7. Dijkman, R., Dumas, M., Van Dongen, B., Käärik, R., Mendling, J.: Similarity of business process models: Metrics and evaluation. Information Systems, vol. 36(2), pp. 498--516 (2011)

8. Pollach, I.: Software Review: WordStat 5.0. Organizational Research Methods (2010)

9. Dijkman, R.: A classification of differences between similar Business Processes. In: Enterprise Distributed Object Computing Conference, 2007. EDOC 2007, 11th IEEE International, pp. 37--37). IEEE (2007, October)

10. Gottschalk, F.: Configurable Process Models. PhD thesis, Eindhoven University of Technology, The Netherlands (2009)

11. La Rosa, M., Dumas, M., Uba, R., Dijkman, R.: Merging business process models. In On the Move to Meaningful Internet Systems: OTM 2010, pp. 96--113. Springer, Berlin Heidelberg (2010)

12. Sirageldin, A., Selamat, A., Ibrahim, R.: Graph-based simulated annealing and support vector machine in Malware detection. In: Software Engineering (MySEC), 2011 5th Malaysian Conference in, pp. 361--364. IEEE (2011, December)