Page History

...

This article is a follow-up on the article mentioned above and discusses a clear and insightful process design, using phases, (ad-hoc) tasks, decisions and milestones. Below a schematic outline of such a process is shown.

(Diagram will be replaced with actual phases and tasks)

Process design

One of the aspects of the process design shown here is that at the highest level, we speak of phases rather than processes. A phase is a moment within the entire process when you are free to perform a lot of tasks that are applicable in that phase and contribute to the goal of the phase. The goal of the phase is called a milestone (depicted by a diamond ). Whether a milestone is reached or not is merely a decision, based on availability of data and artifacts, not on the completion of tasks.

...

An example of a process with four phases is given below.

(Diagram will be replaced with English version, without precondition on RegisteringContact)

The phases are quite linear; Submit, Pay, Decide, Register. In circumstances where there is no eligibility to register, the phase registering is skipped right after deciding. Throughout the process, it is possible to register some sort of contact between applicant and the back office, for instance by mail or telephone or in person. After the final phase, the process will not end (since this will end the Blueriq-application). A conditional node (that will never ever become true) will keep the process from ending.

(Diagram will be replaced with English version)

In the process diagram of the first phase (Submit), we see a hybrid process, containing automated tasks as well as manual tasks, and flow-oriented orchestration of these tasks and orchestration by means of preconditions. This is a very strong feature of this process design; with Blueriq it is possible to design processes that contain the best of both worlds. The task ReadDataFromCivilRegister must always be performed first, this is why the task is connected to the start event of this phase by means of a flow-arrow. All other tasks can be performed in the phase as well, but the order is not set in stone, neither is the applicability of these tasks. Preconditions tell us when the tasks may be performed and (as mentioned in How to use Decision Requirements Graphs to visualize ad-hoc tasks in business process modeling) a Decision Requirements Graph will tell what the precondition is, as shown below for the task <>RequestProduct.

 Image Added