This site is dedicated to documenting research and experiences in the area of business process configuration. The study here presented has been conducted by QUT's Business Process Management (BPM) Research Group - Brisbane, Australia, in collaboration with TU/e's BPM Reseach Group - Eindhoven, The Netherlands, and supported by the Australian Research Council (ARC) Discovery Grant "Next Generation Reference Process Models". Some of the case studies have been prepared in collaboration with the Australian Film Television & Radio School (AFTRS), as part of the ARC Centre of Exellence "BPM for the Creative Industries".

This research project led to the development of the Synergia toolset - a software package for business process configuration. Synergia is open-source, it can be downloaded from the Tools section. The Documentation section provides an updated list of academic publications and presentations related to this project, while the Links section lists the project contributors among providing some interesting links on the process configuration topic.

Business process configuration - an introduction

What is process configuration and what is it for? Process configuration deals with the problem of managing familities of business processes, i.e. business processes that are similar to one another in many ways, yet differ in some other ways from one organization, project or industry to another. This problem arises for example in the context of multinational companies that need to localize their business processes to different legislations, compliance regulations, quality requirements, etc. It also manifests itself in the context of acquisition projects, where an organization needs to merge their own processes with the ones of the acquired organization.

Process configuration proposes to address this problem by merging a set of similar processes (i.e. a set of process variants) into a single integrated artifact - the configurable process model. In line with methods from the field of Software Product Line Engineering, a configurable process model explictly captures process variants by means of variation points. Business analysis can then configure this model to their specific needs by choosing the proper process variant for each variation point. This approach provides an alternative to designing process models from scratch. Meanwhile, it can foster the systematic reuse of proven or common practices in a given industry domain.

To understand how a configurable process model is constructed, let us consider a concrete example. This example is extracted from a family of process models for post-production, that we documented in collaboration with several stakeholders from the AFTRS. In the film industry it is difficult to come up with standardized process models because virtually every screen project has its own characteristics and, thus, its own business processes. Yet, these processes share many commonalities.

The figure below shows two variants of the post-production process, represented in the Business Process Modeling Notation (BPMN). These variants reflect two common practices in post-production: the first, 'shooting on tape', is typically followed when a project is shot on tape, the other, 'shooting on film', is followed when a project is shot on film. Post-production starts with the preparation of the footage for editing and continues with the offline editing. We can observe that this sequence of activities is common to both the practices, regardless of the shooting medium. However, after this, an online editing is carried out if the footage is shot on tape, while a negmatching is carried out if the footage is shot on film. Online editing is a cheap editing procedure well suited for low-budget movies which typically shoot on tape. Negmatching offers better quality results although requires higher costs; thus it is more suitable for high-budget productions which typically shoot on film. The choice between online editing and negmatching represents a variability in the post-production process: depending on drivers such as budget, creativity and type of project, one option or the other needs to be taken.

The right-hand side of this figure shows a configurable process model for post-production. This model is a merger between the two process variants with a variation point represented by a configurable gateway. This inclusive split gateway has been marked with a thicker, red border: unlike a "normal'' BPMN gateway, it does not represent a choice or a parallel split that will have an effect when the process is executed or simulated. Instead, a configurable gateway represents a design choice, i.e. a choice that will need to be made by an analyst to adapt the configurable process model to a particular setting, such as a project or an organization. In our example the configurable gateway captures the fact that one needs to choose for a given screen project whether to select one path (tape shooting) or the other (film shooting), or possibly both.

Therefore a core feature of configurable process models is the explicit representation of variation points and their variants. A variation point can be indicated in different ways, e.g. it could also be a special activity. A configurable process model will typically feature many variation points, each capturing a decision that needs to be taken during process design. An analyst can configure this model by picking the most suitable variant for each variation point. Once all these decisions have been taken, the configured process is individualized by removing those variants that are no longer relevant, leading to an individualized process model. The latter can be used for further analysis, for simulation, or to produce an executable specification for a given set of requirements. Thus, a configurable process model can foster the adoption of common or proven practices in a given domain, and reduce the modeling effort.

The configurable process model lifecycle

Let us come back to the difference between a variation point, like the configurable gateway in the above example, and a traditional gateway. The decision associated with a variation point is a design-time decision. It is not based on data values available when the process is actually performed (e.g., the amount of an expense in a procurement process), but, rather, on the requirements of the project or organization for which the model is to be used. As mentioned before, many can be the drivers behind the configuration of a process: organizational culture, national or regional regulations, compliance requirements, cost, etc. Therefore, to exploit configurable process models in the PAIS lifecycle, the traditional design phase is split into two phases: one where the configurable process model is designed from the consolidation of selected process variants, and another where the model is actually configured and individualized to fit a particular setting, as shown below:

Aims of this research

Despite their benefits, configurable process models have not yet succeeded in being adopted to capture process families. This is primarily because the concept of process model configuration is not yet mature enough. For example, it is still not clear how interdependencies among variation points should be captured, how individualizations can be derived and how the correctness of these individualized processes can be guaranteed.

Moreover, while a configurable process model represents both the standard process and its variations, it does not easily allow analysts to understand what these variations share, what their differences are in relation to the business domain, and thus why and how these differences occur. Last but not least, the scope of process configuration has so far been restricted to the process' control-flow, tending to oversimplify other important aspects such as variants in the human resources and business objects that participate in the process.

Specifically, we identified the following issues in existing approaches for managing configurable process models:

1. Error-prone configuration - first and foremost, there is a lack of understanding of what process model configuration means from a language-independent point of view. This uncertainty has led to the employment of manual methods to configure process models, which are error-prone. In particular, these methods cannot guarantee the individualized models to be correct, whether syntactically or semantically. For example, if a model element or an entire path in a configurable process model is removed during configuration, the remaining model elements need to be re-connected to maintain syntactic correctness. Even worse, the configuration of variation points attached to parallel splits, decision points and synchronization points may lead to the introduction of semantic problems (e.g., deadlocks), which are much more difficult to spot. Although this issue is technical in nature, its consequences are very practical. In fact analysts are left with the burden of ensuring the correctness of the individualized process models and of manually fixing errors. This leads to limitations. Firstly, it is not possible to guarantee that a given set of configuration choices always leads to the same individualized model, thus leaving room for interpretation. Secondly, incorrect individualized models cannot be directly used by developers to derive executable process specifications, thus requiring further effort.

2. Lack of decision support - configurable process models do not provide support for the actual selection of alternatives. They do not guide the user as to what might be a recommended configuration given the user's environment. Consequently, it is not easy to estimate the impact of configuration decisions on the process model. The lack of an explicit link between variation points in the process model and business decisions, requires that the user possesses expertise both in the application domain and in the modeling language the process model has been built in. Therefore, the user who carries out the configuration must not only be a domain expert but also be skilled in reading and configuring process models. This assumption represents an adoption obstacle in domains where experts are unfamiliar with modeling notations (e.g. in the screen business). In addition, this lack of abstraction from the modeling notation makes the configuration of industry reference models (e.g. VICS) extremely hard, as these are typically characterized by numerous variation points with complex and intricate
   interdependencies.

3. Lack of expressiveness - configurable process models, and existing languages for representing reference process models, are only concerned with the control-flow aspects of a process, neglecting other equally important aspects. Indeed, business processes provide an integrated view over an organization by bringing together different organizational aspects in a consistent way. Therefore, besides the control-flow, describing which tasks have to be performed and in which order, other aspects (or process perspectives) need to be considered. These primarily include the organizational resources (humans and machines/applications) participating in the process, and the business objects (software and physical artifacts) that are produced and consumed by the process. The lack of techniques for representing variations in the various process perspectives leads to limited expressive power. Firstly, it is not possible for process modelers to capture the unavailability of given entities in the process, such as human resources or physical artifacts. Secondly, it is not possible to understand the impact this can have on the tasks of the process. For example, in post-production, the unavailability of the role Negcutter leads to projects being edited exclusively on tape. Despite the fact that these situations occur quite often in reality, there is currently no technique to capture them in process models.

In light of the shortcomings identified, the core objectives of this research are to:

• release analysts from the burden of manually checking models for correctness during process configuration;
• enable non-modeling experts to leverage the benefits of configurable (reference) process models;
• offer modelers holistic support for process model configuration.

The first objective stems from the usage of error-prone methods to configure process models. The second one is motivated by the lack of decision support in existing process model configuration approaches. The last objective is the result of a need to cover the lack of expressiveness in capturing process model configuration. This research aims to achieve the above objectives by:

clarifying the concept of process model configuration - by establishing a language-independent conceptual foundation for process model configuration it is possible to reason on the correctness of the individualized models. Techniques can then be designed that guarantee the preservation of model correctness during configuration, thus releasing analysts from using manual methods to check model correctness. These techniques in turn can smooth the transition from process model design to implementation (given that the individualized models are correct), thus aiding developers in preparing the individualized models for execution.

sheading light on the relationship between process model configuration and domain decisions - by making explicit how business decisions can impact variation points in configurable process models, approaches can be formulated that enable abstraction from process modeling notations and provide decision support for the actual selection of alternatives. This in turn provides a means to manage the complexity induced by configurable process models, thus enabling non-modeling experts to fully exploit the potential of configurable (reference) process models.

exploring the interplays across different process perspectives - by understanding how different aspects of a business process can interact with each other, mechanisms can be defined to enable modelers to capture variability across multiple process perspectives in a coherent and consistent manner. These mechanisms can then be incorporated in a rich meta-model supporting the holistic configuration of business process models.

Following this approach, a satisfactory solution to the shortcomings was achieved by designing, implementing and validating an integrated framework to manage the configuration of business process models, which:

• relies on the use of interactive questionnaires to facilitate the configuration of process models by domain experts, without requiring process modeling knowledge;

• allows an incremental configuration, with the purpose to ensure the correctness of the derived process models, with respect to both syntax and semantics. This in turn reduces the effort of making the derived models ready for execution;

• extends the configuration to other process elements, such as business objects and human roles, beyond the process control-flow, and captures their interplay.