Page History

...

The main question one might ask is why the design described here should be used. What are the benefits?

Flexibility

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.

Understandability

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. 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 complexity is not in the process itself, but in the activities. 

Insight?

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.

Execution

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?