Page History

Table of contents

Introduction

Today's business processes have to address many, complex requirements. Mass customization leads to personalized, contextual products being offered by governments and enterprises and, as a result, the business processes for selling and offering these products are divers and contextual as well. At the same time, regulations in the area of compliance and a growing rate of change introduce additional complexity. These developments pose major challenges to the field of business process modeling (BPM). Conventional process modeling, in terms of activities and the flow they are executed in, has proven to lead to complex and often rigid business processes. Dynamic processes, as part of dynamic case management, are an answer to the problems and challenges that conventional business processes face.

...

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.

...

Main process

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

...

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

The process above shows different types of tasks and phases.

Sequential phases

The phases in this process are quite linear; Apply, Pay, Decide, Register. In the vast majority of business processes, phases are singular and linear, meaning a case or process will always be in one phase and after that phase, another phase will follow.

Skipped phase

Sometimes a phase can be skipped.
In circumstances where registration is rejected on grounds of inadmissibility, the phase registering is skipped right after deciding. In this particular case rejection Rejection because of inadmissibility is done when the application is not complete or documents are not valid and the applicant is not able to provide the necessary information. When the application is complete and all documents are valid, registration could still be denied. This is because 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.

Always available tasks

Throughout the process, it is always possible to register some sort of contact between applicant and the back office, for instance by mail or telephone or in person. This is done using a repeatable task without a precondition.

Life events

Events such as relocation or death of the applicant or, in other cases divorce or unemployment, will trigger the process from outside. For these life events, message events are used.

Process end

After the final phase, the this particular process will may not end (since this will end the Blueriq-application). In this design, a conditional node (that will never ever become true) has been added to keep the process from actually ending.
(In Blueriq, ending a process will end the Blueriq-application)

Phases

Shown below is one particular phase of our example process, containing five tasks.

(Diagram will be replaced with English version)

Hybrid process

In the process diagram of the first phase (Apply), we see a hybrid process, containing automated tasks as well as manual tasks. Furthermore, we see flow-oriented orchestration of these tasks by means of arrows and ad–hoc ad-hoc 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.

Preconditions

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.

Milestones

Bla

Maintainability

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.