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 …
Agile and Routine Processes
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:
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 .
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.
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.
The DPIL Framework provides a tool set for modelling, executing and analysing flexible and resource-aware business processes based on the language DPIL. The framework consists of three modules: the DPIL Modeller, the DPIL Navigator and the DPIL Miner