Keywords

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-Sects. 2.1, 2.2, 2.3, 2.4, 2.5 and 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.

Fig. 1.
figure 1

BP integration methodology flowchart

Full size image

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.

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.

  1. 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.

  2. 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.

Fig. 2.
figure 2

Identifying differences in the merge hierarchy

Full size image

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 Sect. 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. (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. (2)

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

  3. (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. (4)

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

  5. (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 Sect. 3.

  6. (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. (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 Sect. 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 Sect. 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). Figure 3 provides a context model for their typical interactions in a construction project, where the ten companies are classified as contractors.

Fig. 3.
figure 3

Construction case study context model

Full size image

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 Subsects. 3.1, 3.2, 3.3, 3.4, 3.5 and 3.6, the application of the steps introduced in Sect. 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.

Fig. 4.
figure 4

E2 process formalization (“SP-M” – supplier of materials)

Full size image

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.

3.2 Check Quality of Inputs

All designed BPs are quality checked by Signavio software for potential syntactic 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.

Fig. 5.
figure 5

Quality check by Signavio - process with error and warnings next to XOR

Full size image

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 Sect. 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.

Fig. 6.
figure 6

Process names word map and clustering

Full size image

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.

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 1. Merge candidate groups’ results overview
Full size 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.

Fig. 7.
figure 7

BP models C2 and T2 before merging

Full size image

3.5 Merge

At this stage common fragments are identified and differences are resolved manually to reach the merged BP, as described in Sect. 2.5. The manual merge is however provided step-wise, according to the merging hierarchy developed in Sect. 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.

Fig. 8.
figure 8

Merged model C2 + T2

Full size image

Note that, as mentioned in Sect. 2.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.

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 Sect. 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.