logo
 
Overview

This site documents 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 the Software Engineering Group at the University of Tartu, Estonia. In the past, it was supported by the Australian Research Council (ARC) Discovery Grant "Next Generation Reference Process Models". Some of the case studies were 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 and can be downloaded from the Tools section. The Documentation section provides an updated list of academic publications and presentations related to this project. The Links section lists the project contributors and some links related to the process configuration topic.

News

  • 23/07/14: Version 0.6 of ProcessMerger and ProcessSimilarity are now available. A non-determinism problem arising in certain cases when computing the similarity between process models has been fixed.
  • 10/07/14: Apromore now has a fully-integrated version of Quaestio and C-Mapper. The latter has been redesigned from sratch with a new UI to support mappings from questionnaire models to configurable models in C-BPMN. The next step is to extend these tools to work with other configurable models within Apromore, such as C-YAWL and C-iEPCs.
  • 21/08/13: We are integrating Quaestio with Apromore for real-time configuration of process models. This video shows a preview of this feature using C-BPMN 2.0 models (yes, we will also support this language). Stay tuned: we will soon release the new tools.
  • 28/05/13: There is a new version of Process Individualizer (version 0.6) with minor fixes in the way files are handled.
  • 3/08/11: There are new versions of almost all Synergia tools. Go to the Download page to grab the latest version of these tools (now also available for MAC). Also, C-Mapper has finally be released. Here is an overview of the major changes:
    • Quaestio 0.8: this new version incorporates Process Configurator and Process Individualizer, so that it is now possible to link a configurable process model to a questionnaire model directly from Qauestio, and automatically individualize the process model once the respective questionnaire has been completed. In other words, one doesn't need to use Process Configurator and Process Individualizer anymore
    • Process Configurator 0.5 and Process Individualizer 0.5: besides bug-fixing, these two tools have now been open-sourced under the Eclipse Public Licence (EPL) 1.0. This makes all tools at processconfiguration.com open-source
    • C-Mapper 1.3: this tool closes the gap in the lifecycle of configurable process models. It is now possible to link questionnaire models to configurable process models (as C-EPCs and C-YAWL models), so that these c-mappings can then be used in Quaestio 0.8 or Process Configurator 0.5 to configure and individualize a process model. C-Mapper is available for both Win and Mac
    • Questionnaire Designer has now been released for Mac too
    • The set of examples has been extended with new C-YAWL and questionnaire models
    • The c-mapping format (.cmap) has now 3 new attributes: "qml" (to specify the linked questionnaire model), "epml" (to specify the linked C-EPC model) and "yawl" (to specify the name of the yawl model). These files are expected by C-Mapper to be in the same folder as the c-mapping file. If so, the tool will automatically load these files when opening an existing c-mapping, otherwise it will ask the user for the files' locations.

Business process configuration - an introduction

What is process configuration and what is it for? Process configuration deals with the problem of managing families 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.

Business process configuration relates to the lifecycle of configurable process models, from their design through to their configuration and individualization.

Business process configuration proposes to address this problem by representing a process family (i.e. a collection of process model variants) via a single integrated artifact - the configurable process model. In line with methods from the field of Software Product Line Engineering, a configurable process model makes use of variation points to capture the differences among the process variants. 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.

A configurable process model is an integrated representation of multiple variants of a same business process in a given domain, such as multiple variants of an order-to-cash business process operating in different markets. A configurable process model offers the following benefits over traditional process models:

  • eliminates redundancies in a process family,
  • fosters standardization and reuse of proven practices,
  • enables a clear distinction between commonalities (those parts that are shared by all process variants) and variability (those parts that are specific to certain process variants) in a process family,
  • keeps track of which process variant(s) each element in the configurable model originates from,
  • can be configured to meet specific requirements, such as those of a new organization, product or brand, thus generating a new process model.

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.

An example of configurable process model

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:

The configurable process model lifecycle

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 common parts and 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. Furthermore, 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 resources that participate in the process and in the business objects that are created, used and consumed in the process. Last but not least, configurable process models are createdby manually merging the models in a process family. This is a long, tedious and error-prone activity.

Specifically, we identified the following issues that hinder the wide applicability of 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 behavioral anomalies (e.g., deadlocks), which are typically 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. First, 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. Second, incorrect individualized models cannot be directly used by developers to derive executable process specifications, thus requiring further effort.
  1. 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, SCOR, ITIL) extremely hard, as these are typically characterized by numerous variation points with complex and intricate interdependencies.
  1. Lack of expressiveness - configurable process models are only concerned with the control-flow aspects of a process, neglecting other equally important aspects. A business process model is intended to provide an aggregated view over an organization by bringing together different organizational aspects in a consistent way. Thus, besides the control-flow, describing which tasks have to be performed and in which order, other equally important aspects 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 these other process aspects leads to limited expressive power. First, it is not possible for process modelers to capture the unavailability of given entities in the process, such as human resources or physical artifacts. Second, 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.
  1. Lack of design-time support - configurable process models are built manually by merging a set of process model variants. The problem of merging similar process models frequently occurs in the context of company mergers and restructurings, where multiple alternative processes previously belonging to different companies or units, must be consolidated into a single one. To this end, teams of business analysts manually compare similar process models so as to identify commonalities and differences, and to create an integrated process model that can be used to drive the process consolidation effort. This process model merging effort is tedious, time-consuming and error-prone. Thus, there there is a need to assist business analysts by providing automated support for merging process models.

In light of the above issues, we identified the following research objectives:

Establish a conceptual foundation for configurable process models - 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.

Link configurable process models to business 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.

Extend process configuration to different process aspects - by understanding how different aspects of a business process can interact with each other, languages 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.

Automate the construction of configurable process models - by automating the merging of similar process variants into configurable process models, the number of similarities identified among process variants can be maximized and a considerable time can be saved. In this way the resulting merged model will eliminate redundancies in the process family and faciliate standardization and reuse.

With these objectives in mind, we developed Synergia, an integrated framework to manage variability in process-aware information systems. Synergia:

  • allows an incremental configuration of process models, while ensuring the correctness of the derived process models with respect to both model syntax and behavior;
  • relies on interactive questionnaires to present business decisions to domain experts, and uses the answers to the questionnaires to configure process models;
  • provides a language to model variability along different process aspects, such as business objects and resources, and to capture their interplay;
  • relies on sophisticated graph-matching techniques to identify the best mapping among similar process models, and use this as input to automatically create a configurable process model in a matter of seconds.