Article Preview
Top1. Introduction
Nowadays organization’s business environments become more and more complex, dynamic, and evolving due to internal and external factors such as economic changes, technologic innovations and sanitary conditions. So, disturbances can affect their business routines, requiring Business Processes (BP) capable of adapting to frequent changes. Thus, for surviving in such environment, organizations have to face an important issue in Business Process Management (BPM) area; it's about the Business Process Flexibility (Barba et al., 2021; Jemal et al., 2018; van Eck et al., 2015).
Business Process flexibility is defined as the ability of a business process to accommodate organizational, functional and/or operational changes occurring in its operating environment (Chaâbane et al., 2010). In order to feature this requirement, several taxonomies have been proposed in the literature. The more suitable one is given in (Reichert & Weber, 2012). This taxonomy highlights two different times when process flexibility is considered: flexibility at design-time, which refers to foreseeable changes that can be taken into account in modeled process schema, and flexibility at run-time, which refers to unforeseeable changes occurring during process executions. In addition, this taxonomy identifies four needs of flexibility: (i) variability, for representing a process differently, depending on the context of its execution, (ii) adaptation, for handling occasional situations or exceptions which have not been necessarily foreseen in process schema, (iii) evolution, for handling changes in processes, which require occasional or permanent modifications in their schema, and (iv) looseness, for handling processes whose schema are not known a priori and which correspond to non-repeatable, unpredictable, and emergent processes.
To address process flexibility in BPM, several contributions have recommended (i) variant-based approach (Aysolmaz et al., 2017; Hallerbach et al., 2010; Milani et al., 2016; Natschläger et al., 2016; Reichert et al., 2015; Rosa et al., 2009; Tealeb et al., 2014), which recommends reuses a set of variants of the process components (i.e., the process itself, its sub-processes and its tasks), each variant being convenient to a given context, and (ii) version-based approach (Chaâbane et al., 2010; Chaâbane et al., 2020; Ekanayake et al., 2011; Ellouze et al., 2017; Ellouze et al., 2016; Lassoued et al., 2016; Zhao & Liu, 2013), which is an extension of the variant-based as it allows using a set of alternative versions (equivalent to variants), on the one hand, and defining consecutive versions of the process (following evolutions of some versions), on the other hand. A version corresponds to one of the significant states that a process component (the process itself, or its sub-processes or tasks) may have during its life cycle (Chaâbane et al., 2010). In fact, evolution and versioning are related not only to the ability to perform updates on a process, a sub-process or a task model, but also to the ability to keep track of these updates. This is why we adopt the version-based approach. The latter consists in the specification of several schema versions of each process to take into account the significant changes occurred in that process and its components (i.e., activities, information and resources involved in its execution). Each new version must be defined by derivation from previous one forming a derivation hierarchy. The notion of version has been recognized as a key notion to deal with flexibility issue (Reichert & Weber, 2012).