Introduction
In the knowledge base 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. Many people are concerned that - when using ad-hoc tasks - the business process model becomes difficult to understand and maintain.
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.
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.
The tasks within a phase are mostly ad-hoc or automated, but this is not necessary. 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 the availability and necessity of the tasks depends on the availability of data and artifacts, and not on the completion of other tasks.
As mentioned before, phases consist of tasks. These tasks produce data - which is entered into the system, for instance about an applicant or about desired product. Tasks also produce artifacts, such as uploaded documents, pictures etc. and generated documents. Preconditions are decisions that tell when the tasks can be (or even must be) performed. These decisions are all based on data and artifacts.
In the design shown above, a row is reserved for the roles that participate in each phase. Although absolutely necessary, it is left out of scope in this article.
Example
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 <>.
Overview
Content Tools