Article Preview
TopIntroduction
A Collaborative Process (CP) is defined as a set of independent intra-organizational processes, where several partners are involved in one global process, while each has its own intra-organizational process (Aalst, 2000). Therefore, the CP describes the way the processes of involved partners interact together using web-based technologies (Rittgen, 2010). Management of Collaborative Processes (CP) is now considered as a mature area for CP which do not evolve over time. However, flexibility of CP, which corresponds to the ability of CP to evolve over time, has not been deeply investigated and it is still an open issue in Business Process Management (BPM) (Dumas, La Rosa, Mendling, & Reijers, 2018). This issue is very important as the strong competition among organizations lead them to frequently change and adapt their CP to face new client’s requirements or to benefit from new collaboration opportunities.
In the literature, the version-based approach is appropriate to deal with the flexibility of intra-organizational processes and of CP. In fact, many research contributions have recommended the version-based approach (e.g., (Ben Said, Chaâbane, Bouaziz, & Andonoff, 2016; Chaâbane, Bouzguenda, & Bouaziz, 2011; Dadam & Reichert, 2009; Ellouze, Chaabane, Bouaziz, & Andonoff, 2016; Ekanayake, La Rosa, ter Hofstede, & Fauvet, 2011; Kradolfer & Geppert, 1999; Zhao & Liu, 2013)) for several reasons. On the one hand, it is the basic reality in companies: new technologies, governmental rules, organizational contexts or the adoption of new standards lead them to define several versions of their processes. On the other hand, it helps address three main needs of process flexibility (Reichert & Weber, 2012): (1) flexibility by evolution, since the different significant changes on processes are modeled within process versions, (2) flexibility by variability, since it is possible to model alternative versions, depending on the context of their execution, and (3) flexibility by adaptation, since it is possible to model versions for occasional situations or anticipated exceptions.
There is no doubt that the works cited above are very interesting and are a step forward with respect to versioning for process flexibility. However, they do not address the question of reusing these versions of process. This question is of utmost importance in a multi-version environment, where numerous versions co-exist. More precisely, in such an environment, BPM practitioners (i.e., BPM end-users and designers) have to face the problem of selecting, among different versions of CP, the most appropriate one. This selection is required both at run-time, if BPM practitioners have to select the version of CP to be executed, and at design-time, if they have to select an old CP version to be used to make up a new CP version.
As each version is required in a specific context, it becomes crucial to consider the context to choose the appropriate CP versions. In the BPM area, the notion of context is defined as “…the minimum of elements containing all relevant information that impact the design and the execution of a process…” (Rosemann, Recker, & Flender, 2008). Actually, several taxonomies have been proposed in order to classify these elements of context (e.g., (Brocke, Zelt, & Schmiedel, 2016; Rosemann et al., 2008; Saidani, Rolland, & Nurcan 2015; Wang, Zhang, Gu & Pung, 2004)). We outline the largest one provided by (Rosemann et al., 2008) which distinguishes four types of context (1) immediate context, which covers elements on process components, namely context of activities, events, and resources, (2) internal context, which includes elements on the internal environment of an organization that impacts the process (3) external context, which encompass elements relating to external stakeholders of organizations, and finally (4) environmental context, which contains elements related to external factors.