Page History

...

Dynamic processes are processes in which not all possible scenarios are completely delineated upfront. In dynamic processes there is no diagram, model or code available that tells us exhaustively in which order possible scenarios can occur and what to do when in each scenario. In stead Instead of meticulously connecting activities to establish completeness (or define ordered sequence) in flow, in dynamic processes all activities can in theory attribute to the process at any given time. For each activity that is part of the process, a precondition simply states when the activity can, should or must  be performed. Such a precondition is a boolean statement that makes use of the available data, the artifacts in the system and the state or phase the process is in. A dynamic process engine (like Blueriq) will decide at runtime which activities can and must be performed at any given moment in the process. In Blueriq, dynamic preconditioned activities are modeled as ad-hoc tasks.

From a Blueriq point-of-view, it is not mandatory to use preconditions and ad-hoc tasks exclusively, nor is it mandatory to use flow exclusively. One of the unique aspects of Blueriq is that both approaches are available and can be intertwined to get the best of both worlds. So whenever there is an activity that may only be performed when another activity is completed, it can be modeled with flow. Many discussions in the field are about the difference between static and dynamic processes. By allowing both, we allow for a hybrid approach if you need that.

Design

Some people are concerned that - when using ad-hoc tasks - the business process model becomes more difficult to understand and maintain than when flow was is used. In situations where no good design is made upfront, they might very well be right! If a process with a lot of activities is modeled by simply dumping all these activities in one single batch and just create (complex) preconditions for all of these activities, this will have, at model time at least, no benefit over a flowchart.

However, in business processes it is very uncommon that all activities can be applicable throughout the entire process. At a certain point (in dynamic case management terms: when a certain milestone is reached), some activities are simply not part of the possible process anymore. Or not part of the process yet. This is why business processes can be dissected into phases. Using phases, milestones, ad-hoc tasks and preconditions will result in really dynamic and flexible business processes, without the downside of delineating all scenarios upfront and connecting the activities with all possible paths.

...

The tasks within a phase are mostly ad-hoc or automated, but this is not mandatory. Blueriq has the ability to mix ad-hoc and automated tasks with flow-oriented tasks. The most important aspect of this process design is that it , as much as possible, the availability and necessity of the tasks depends on the availability of data and artifacts, and not on the completion of other tasks. 

...

Most processes are - from a high point of view - very linear. So is our example: it consists of the sequential phases Apply, Pay, Decide, Register. In the vast majority of business processes, the phases are singular and linear, meaning a case or process will always be in one phase and after that phase, another phase will follow. When during the design of phases it turns out that many phases can be applicable at once and many different phases might follow a phase, the granularity of the phase is probably off: you are most likely designing tasks/activities in stead instead of phases.

Sometimes however, a phase can be skipped. In this particular example, when registration is rejected on grounds of inadmissibility, the phase registering is skipped altogether. The rejection because of inadmissibility is done when the application is not complete or documents are not valid and the applicant has not been able to provide the necessary information. When the application is complete and all documents are valid, registration could still be denied. Denying and rejecting sound alike, but differ in this example. Denying an application is done when the application is not eligible, although complete and valid. Non-eligible applications are registered as well as eligible applications, but with a negative decision. Rejections, as mentioned before, are not registered at all.

...

First of all, this design is really flexible, similar to the real world the end users live in. When an activity is added to the process, all that needs to be done is add the task to the proper phase and determine its precondition. That's it. In conventional business modeling with activities and flow, adding an activity is much more complex. Most likely the activity can or must be added in more than one part of the flow.

Secondly, this design is much easier to read for business users. Flowcharts tend to be seen as 'technical' or 'IT-like', although that was never the intention of BPM. A process diagram containing phases with activities is much easier to read by business users. In stead Instead of being responsible and accountable for dozens or even hundreds of process diagrams containing complex flow, business users are delighted to see their processes narrowed down to a few simple designs, where the complxity is not in the process itself, but in the activities. 

Of course there are some concerns regarding this approach. The main concern regards insight. In a previous article (How to use Decision Requirements Graphs to visualize ad-hoc tasks in business process modeling), we discussed how Decision Requirements Graphs help visualize ad-hoc tasks. This article was written as a response to often heard comments on ad-hoc task modeling regarding insight and overview when modeling business processes with ad-hoc tasks rather than (work)flow oriented tasks. Using the strategy described in this article, combined with the design as outlined here, will result in dynamic processes which are not only really flexible, but also maintainable.

One should however realize that the real benefit of this approach is not only on the design of the process. In execution, flexibility is needed more and more, and knowledge workers do not do things in a fixed order, do not handle each case in the same way, and might need more freedom to deviate from the path or work with others. This is perhaps best compared to the navigation paradigm. Nobody ever prints a complete route description before stepping into his car. Even more, printing all possible routes to take is practically impossible. Instead, a modern navigation device is continuously adapting to changes; road blocks, traffic jams or other exceptions, and, just in time, calculates a new route. So why try to think of all possible routes in process design?