Page History

...

Milestones (in the process diagram depicted by a diamond ) are used as goal for each phase. A milestone is merely a decision and is based on data and artifacts. The milestone for the phase Apply for instance is only true (and therefor reached) when the application is complete, meaning all mandatory data is provided and necessary documents are uploaded. Milestones are used to steer the phases at a high level. In theory each phase has one milestone that ends the phase and each phase (except the first one) will only be opened when the milestone of the previous phase is reached. It is very uncommon and nt advisable to design a process that can be in two phases at once or no phase at all.

Process changes

Maintainability

Benefits of the design

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

First of all, this design is really flexible. When an activity is added to the process, all that needs to be done is add it 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 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.