Process Science

On the following web pages we show how we approach the issue of agile process management with declarative process management technology.

Why agility? Because our work life is agile. Swenson states that "[...] only 20-40% of current processes are routine processes […]" – here, routine processes are meant to be the complement to agile processes. Our observations made over the last two decades in a variety of industrial projects support this statement. However, there is room for both: agile and routine (strict) processes. This is why our framework is capable of supporting both types of processes. This is what practical process management distinguishes.

We apply latest research in all the different phases of the process lifecycle. The process lifecycle comprises the following phases.

Language Design

In cases where the expressivity of standard notations like BPMN or CMMN does not suffice, the modelling language needs to be customized in an intuitive way. The modelling notation may be extended by domain-specific elements directly within a diagram.

Process Modelling

Business Process Modelling techniques are concerned with mapping to enable understanding, analysis and positive change. Describing the process in diagrams or or textual models are a central feature of the methodology. Following the terminology of programming languages, there are two paradigms of describing business process models: the imperative and the declarative style. The imperative way corresponds to imperative or procedural programming. Every possible path must be foreseen at design time and encoded explicitly. If a path is missing then it is considered not allowed. In declarative modeling, on the other hand, only the undesired paths and constellations are excluded so that all remaining paths are potentially allowed and do not have to be foreseen individually. As the so-called agile type of business processes incorporates many often unforeseen paths, the declarative approach is best suited for it.

Process Enactment

If business process execution involves humans then it should be seen as a decision support system instead of a means of automation. As a consequence, an according system should propose actions and support them but it should never enforce them. This requirement goes along with the call for process management systems “to provide directions and guidance ra-ther than enforcing a particular route” whereas they are com-pared to navigation systems. An important characteristic of decision support is explanation and so-called meta-knowledge. Proposals made by the system need to be justified and explained so that sound choices can be made. For process execution, this means that certain proposed actions must be marked as recommended and that discouraged actions can be traced back to and explained by the according parts of the business process model. A declarative and therefore less rigid form of business processes leads to a greater amount of possible paths. So, especially in the declarative area, the capability of explanation comes into value.

Process Analysis

For purposes of compliance and process improvement, organisations are interested in the way their processes are actually executed. Process mining aims at discovering processes by extracting knowledge from event logs, e.g., by generating a process model reflecting the behaviour recorded in the logs.

Process support for routine (strict) processes has well developed over the last years. BPMN 2.0 is a good example for a framework that copes with strict processes. There is a bunch of tools out there that supports modeling and execution of strict processes. However, support for agile processes – although predominant in real life applications – is rare. This is why our research has focused agile process management. Modeling and executing agile processes implicates the following issues:

Declarative Process Modelling

Following the terminology of programming languages, there are two paradigms of describing business process models: the impera-tive and the declarative style. The imperative way corresponds to imperative or procedural programming where every possible path must be foreseen at design time and encoded explicitly. If a path is missing then it is considered not allowed. Classic approaches like the BPEL or BPMN follow the imperative style and are therefore limited to the automation type of processes. In contrast to imperative modelling, declarative models concentrate on describing what has to be done and the exact step-by-step execution order is not directly prescribed. Here, only the undesired paths and constellations are excluded so that all remaining paths are potentially allowed and do not have to be foreseen individually. As knowledge- and decision-intensive business processes often incorporate many unforeseen paths, the declarative approach is best suited for it.

Cross-Perspective Modelling

Declarative modelling is based on constraints that relate events of the process and exclude or discourage from certain correlations. Both constraints and events must be able to involve all the perspectives of a business pro-cess like, e.g., incorporated data, agents performing the work and utilized tools. On this way it becomes possible to express realistic correlations like, e.g., the actual performing agent of a step affecting the type of data used in another step.

Different Modalities and Explanation

A business process usually consists of several “facets” like, e.g., a legal framework (mandatory, “must”) and best practice (recommended but facultative, “should”). Classic approaches like the BPMN only allow for describing one of these facets per model. Combining both of them in one model greatly enhances its documentary character and allows for a BPM system to act more flexibly. An action that, e.g., is contrary to best practice but conforms to the legal framework is offered but marked as discouraged. The BPM system may even explain why the action is not recommended by tracing it back to the process model.