A Method for Composition of Structured Process ModelsModels

The method discussed in this chapter extends the conceptual framework of the thesis with capabilities to derive structured workflow models from weakly-structured task delegation graphs.

Such derivation enables a seamless transition from user-defined to formal process models towards automation of rigidly recurring processes (R7). The introduced method further enables extension of structured workflow models based on deviations in workflow instances through ad-hoc tasks.

The method founds on the task management model introduced in Chapter 4.

6.1 From Email and To-Do to Formal Process Models

The previous chapters have described a task management model and a method for the composition of weakly-structured process models based on personal task management. Weakly-structured process models are composed dynamically in the form of task delegation graphs through definition and hierarchical task decomposition of explicit task representations in light-weight to-do lists, and through task delegation over email. Task patterns can be extracted from task delegation graphs and reused as process examples that abstract from a specific process instance to reconstruct ad-hoc business processes for recurring cases. Through this capturing and repeated execution of ad-hoc processes, programming by example [Cyp93, Lie01] of weakly-structured process models is enabled on enterprise level. The composition of weakly-weakly-structured process models requires manual activities for managing ad-hoc task instances and task patterns and does not support process automation (R7).

Process automation can be supported through conventional workflow management systems based on structured process models [vdAvH02, vdAHW03]. Additionally, a need has been discussed (cf. Table 3.1, Section 3.1.1.5) to integrate the business and technology perspectives on business processes by enabling process tailoring as collaboration between end users, process designers and developers [MM00]. Task delegation graphs are based on hierarchical task decomposition and delegations (cf. also Definition 4.1). Additionally, a task instance change history is maintained for each ad-hoc task instance as discussed in the task management model (cf. Section 4.4.2). The change history of an ad-hoc task instance captures various stages in the elaboration of that task instance and allows evaluation of temporal relationships between ad-hoc task instances in the course of an ad-hoc process instance. Thus, the structural relationships between tasks in a task delegation graph and the task instance change history can be used to derive control flow for ad-hoc task instances. The discussed task management model further provides artifact (cf. Section 4.6) and human actor (cf. Section 4.7) associations to ad-hoc task instances. Hence, process automation can be enabled through transformation of a task delegation graph to a structured workflow model by using user-defined information on task flow, document flow, and involved human actors in terms of task assignments from a real-life process execution in a task management system. Such transformation can additionally deliver a shared context for process model interpretation and tailoring between end users, process designers and developers.

Hierarchical task decomposition is proposed by a large body of research for supporting ad-hoc processes [ADMG97, Ber00, Sch03, HRD+06, RRMvdA05, GOR+07, Sch09]. However, methods for transformation of user-defined, ad-hoc task hierarchies to structured workflow models are not discussed in related literature. [Ber00] discusses integrated ad-hoc and procedural process support that is based on light-weight task hierarchies. For process automation [Ber00]

suggests using imperative workflow scripts that direct the execution of tasks whereas the overall process remains based on task hierarchies. [ADMG97] presents a system, where automation is

supported through explicit process modeling in a simplified visual notation without considering transformation of hierarchical task structures from a provided to-do list to a workflow model.

On the other hand, workflow management and business process management studies focus on embedding flexibility in structured workflows [vdABV+99, Jor04, vdAWG05, Ber05]. The latter studies consider having an initial, preliminary workflow model and do not discuss derivation of formal models from ad-hoc task hierarchies. The lack of conceptual work on the transformation of ad-hoc processes or process fragments in the form of task hierarchies to structured workflow models motivates the introduced method. The method discusses the transformation of task delegation graphs to structured workflow models by focusing on three major aspects: control flow, document flow, and human actors’ information in terms of task assignments.

6.2 Control Flow Transformation

The major difference between task delegation graphs and workflow models is that the first provide structural decomposition and delegation flow of tasks whereas the second specify the control flow in processes, i.e. the sequence in which tasks are executed. To clarify the transformation of task structure to task sequence flow, the thesis first provides a brief introduction to the relevant terminology for workflow graphs, and introduces some basic terms related to the transformation of task delegation graphs.

6.2.1 Terminology

Workflow graphs are based on two-terminal graphs [VVK08]. A two-terminal graph is a directed graphG [Die00] such that there is a unique source nodes and a unique sink nodet s and each node v is on a directed path from s to t. The thesis considers a workflow graph as a series-parallel graph with distinguishable node and edge types, where branching is modeled through gateways in a block-oriented fashion (cf. also [RD98, RRD03]). The thesis further considers only entities and relationships that can be derived from a task delegation graph and defines a derived workflow model as follows.

In the above definition the term “task” is used as a synonym for “workflow task model”, i.e. a workflow model is a model of an operational business process, which is composed of workflow task models as fine-granular building blocks (cf. Definitions 1.4 and 1.5). Workflow tasks models in a workflow model result from task instances in a task delegation graph, and process data elements from artifacts. The definition does not include entities that cannot be derived directly from a task delegation graph such as looping. After the transformation of a task delegation graph to a workflow model, the process modeler is able to extend the derived workflow model with additional elements according to the concrete formal modeling notation. Aworkflow graph is the graph representation of a derived workflow model. A workflow graph is correct if (cf. [RRD03]):

– for each split node (fork) there is a unique join node

– S is structured following a block concept, i.e. control blocks (sequences, forking) can be nested but must not overlap

Definition 6.1: (Derived Workflow Model) A derived workflow model is a tuple S = (V, D, VT, CtrlE, DataE)where:

- V is a set of tasks andD a set of process data elements

- VT: V {StartFlow, EndFlow, Task, AndSplit, AndJoin, XOrSplit, XOrJoin } - CtrlE V × V is a precedence relation

- DataE V × Dis a set of data links between tasks and data elements

The block concept plays an intrinsic role in the transformation of task delegation graphs to structured workflows. A block in a workflow graph is a hierarchy of sub-workflows that have a single entry and a single exit of control [VVK08]. The notion of block introduced by the latter study is adopted in the thesis, where a block is considered as a connected sub-graph with unique entry and exit nodes. For the transformation of task delegation graphs to workflow graphs, a block is considered as a hierarchy of sub-workflows that is derived from a set of ad-hoc task instances and represents a part of the structured workflow model.

An evaluation set, contains all task instances produced through ad-hoc task management, which are evaluated to form a block in the workflow model. The transformation of a task delegation graph to a workflow model is performed through assembling evaluation sets and producing respective task sequence blocks - first for the root task, and then iteratively for all tasks with sub-tasks throughout a task delegation graph. Depending on the interpretation of task decomposition and delegation flow, evaluation sets can comprise tasks from different parent tasks, accepted tasks or ad-hoc processes as discussed throughout this chapter.

Anassociated evaluation setfor a given task from the task delegation graph, is an evaluation set that is used to generate the workflow block containing the corresponding workflow task node for this task. Recall that according to the runtime task management model (cf. Figure 4.2) a task instance can have an associated workflow task model. In the following, this workflow task model is the task node that is produced from the task instance in the generated workflow graph.

Atask delegation graph in the following refers to the ad-hoc process fragment that has been selected for transformation. The thesis suggests that a user should be able to initiate workflow transformation from an arbitrary task in a task delegation graph. This enables formalization only of those facets of an ad-hoc process, which a user finds appropriate for automation.

Aroot task in the following refers to the root of the task delegation (sub-)graph that is being transformed and does not necessarily coincide with the root task for an overall ad-hoc process.

Anatomic task is a task from a task delegation graph, which has no sub-tasks. A task from a task delegation graph that has sub-tasks is referred to asnon-atomic task or asparent task.

An initial taskis a task from a task delegation graph which can be interpreted differently during process model transformation. Tasks that contain sub-tasks are marked as initial tasks when their parent task is processed as discussed later in this chapter. The final type of an initial task in the workflow model is determined in a subsequent transformation step.

Aninitial nodeis a node in the workflow graph, which represents an initial task from the task delegation graph. The final type of an initial node is determined in a subsequent processing iteration, i.e. when the corresponding initial task is transformed.

Atarget node during process model transformation is a node in a workflow graph where the workflow block from the next transformation step should be inserted.

A target graph is a workflow graph in which the generated workflow block from a transformation step should be inserted. The transformation of a single task delegation graph can result in multiple workflow graphs, representing a main process and multiple sub-processes as discussed further in the transformation method.

A strict delegation sub-graph for a given delegated task in a task delegation graph is the graph which encompasses the task, and iteratively all its recipients’ tasks and their recipients’

tasks excluding any hierarchical decomposition. A strict delegation sub-graph is shown in Figure 6.1 and defined formally as follows. LetG (V, E) be a task delegation graph, whereV is the set of all user-defined task instances, andE = Ed Eh is the set of all edges, withEd being the set of edges representing delegations, i.e. connecting requester tasks with recipient tasks, andEh being the set of edges representing hierarchical decomposition, i.e. connecting parent tasks with their respective sub-tasks. A sub-treeGA (VA, EA) with root nodeA V is called astrict delegation sub-graph forA, ifEA Ed andEA Eh= .

A₁ B D A

A₂ B₁

B₂

D₁ D₂

C

… D_2.1

E₁

E Dn

U1 U2 U4

U3

… A_2.m A_2.1 Task delegation graph:

Strict delegation sub-graph for A₁:

A₁ B

C

C

D E

Ux

F

F

Figure 6.1: Strict delegation sub-graph for a task in a task delegation graph 6.2.2 Traversing a Task Delegation Graph

The thesis suggests enabling a step-wise, iterative transformation of a task delegation graph to a workflow model. Step-wise transformation enables users to better evaluate the reflection of user-defined process models into formal workflow graphs. This approach further allows derivation of workflow models with different granularity, i.e. the user can interrupt the transformation after only a set of high-level tasks in the hierarchy have been transformed. The generic algorithm for traversing a task delegation graph is provided in the following.