Processing workflows: what is different from single tasks?

The main differences between processing single tasks and a workflow of main task and sub­tasks are the following:

o  Tasks which have data fields in common with main task, peer tasks or subtasks, de­pend on these data fields being released before they can be started or finished. A sub­task may only be started when all its input data shared with other tasks are released; a main task may only be finished when all its output data shared with subtasks have been released. Starting or finishing conditions concerning the release of such data have the same effect.

o  Actions on a main task or on subtasks of a workflow can trigger further actions on other tasks of the workflow. The flow of work within a network of a main task and its sub­tasks is supported

o  by propagating values of shared data fields, whenever they are released, and auto­matically advancing the workflow, e.g. by starting subtasks whose complete input has been released by the start of the main task, or by finishing a main task whose complete output data have been released by execution of subtasks.

o  by withdrawing values of shared data fields, whenever their release has been taken back, and by automatically rolling back the workflow, e.g. by requesting the cor­rec­tion of a sub­task whose output was objected to as input field of a peer task.

Also, all subtasks are cancelled when the main task is cancelled, and all subtasks are reopened when the main task is reopened.

o  When computing the expected completion date of a main task, the expected duration of its subtasks is taken into account, should this be longer than the duration originally specified for the main task.

When a workflow consisting of main task and subtasks is copied, all tasks are treated as when copying single tasks (requestors and eventual data field values and audit trails are removed, status is set to initial); since data fields are copied, the connection between the tasks of the workflow via shared data fields and release conditions stays intact.

Processing support of workflows: an example

As an example we take the task “Requirements” of the analysis phase in our project “Sub­sti­tu­tion of the commission settlement system”. Above, we have split this task into two subtasks “Requirements compilation” and “Requirements approval”. “Requirements compilation” takes its input data from the main task “Requirements” and delivers its output document “Func­tional require­ments definition” to the main task and to the peer task “Requirements approval”. “Requirements approval” delivers its output “requirements approved” (a check box) to the main task as last part of the output data of this task.

When the task “Requirements” is started, also the subtask “Requirements compilation” is started automatically and the contractors are notified. When this subtask is finished, the other subtask “Requirements approval” is started automatically. After the approval has been finished, all output data of the main task “Requirements” are released and the main task is finished automatically, since we had the subtasks defined in such a way that they replace the main task.

Should exceptional situations arise, e.g. the representative of the financial department objects to the functional requirements definition (action   Task    Object  in subtask “Requirements approval”), the workflow is rolled back: the correction of the result of subtask “Requirements com­pilation” is requested automatically, so that its contractors can react to the objection. After “Requirements compilation” has been finished a second time, “Requirements approval” is started again.