Task Pattern Extraction

The need for global expertise sharing and knowledge management strategies in organizations is largely perceived [Wii04]. Knowledge management is a critical aspect for business process management, where one of the major problems is related to process discovery [Ver04]. [Bar97]

discusses agile processes as“situated planning” and emphasizes that a central point in providing situated support for user-defined plans is to “recognise the function of plans as ways of anticipating and pre-handling events in (working) life based on their recurrent nature, and be able to save and later reuse the experience obtained in handling these events”. Thus, enterprise processes can be seen as plans, which are improved and extended in the actual execution context.

Thereby reuse is a central aspect that needs to be considered to support organizational learning and iterative process discovery and refinement.

The thesis considers extraction of captured real-life processes for further reuse in recurrent cases in the form of task patterns. A task pattern can be extracted from an arbitrary item in a local user’s to-do list. The user can extract only the local hierarchy of a selected task instance as a personal best-practice, i.e. as a captured task execution example from the personal workspace that can be used to execute similar tasks. Further, the overall sub-tree (i.e. sub-task delegation graph, cf. Section 4.3.2) for the selected task can be retrieved from the server. Such extraction allows reuse of overall process structures, which have been developed collaboratively by multiple process participants on enterprise level. In the latter case, different task patterns are created for

the tasks of different users. The decomposition of task delegation graphs during extraction of task patterns and the resulting task pattern relationships are discussed later on. In the next section the focus is first set on the transferred information between task instances and task patterns.

5.2.2.1 Transfer of Task Context Information

Transferred task attributes include only the name and description. All other attributes like priority,start date, due date, status andpercent complete are considered as related to a concrete process instance and the accompanying execution context and are not transferred to task patterns.

Artifactsare transferred to task patterns to preserve all task-related resources for future reuse.

Externally-managed and externalized artifacts are associated to the extracted task pattern independently of its scope. The artifacts can be retrieved from the artifact repository during task pattern viewing, editing or reuse, i.e. according to the repository access policy.

Locally-managed, non-externalized artifacts can be handled in different ways, depending on the declared task pattern scope – local or global. Local task patterns inherit the complete artifact content (in binary form). However, when exchanging local task patterns, the users may not be aware of the confidentiality restrictions for embedded artifacts. Therefore, it is reasonable to consider transforming all artifacts as either externalized or externally-managed. When a global task pattern is extracted from task instances that contain locally-managed artifacts, the latter are either excluded from the task pattern or submitted as externalized or externally-managed artifacts.

5.2.2.2 Transfer of Human Actor Information

The transfer of human actor information focuses on expertise recommendation based on the owner and recipient information of task instances.

Owner information of task instances is transferred to extracted task patterns, based on the user name and (email) address as defined in the task management model in Chapter 4. In task instances the owner is mandatory in order to assign tasks to a given user workspace in task delegation graphs. On the other hand, in task patterns the owner recommends general expertise and does not specify explicitly that only this person should handle the respective task. The task owner specified in a task pattern can be asked for assistance in future cases.

Recipient information is embedded in delegation entities as discussed in the task pattern model in the Chapter 4. These are composed differently depending on whether only a local task hierarchy from a users’ to-do list, or a complete task delegation graph is extracted. In the first case, delegation entities embed only recipient(s) information and denote which persons have processed collaborative tasks in a process instance. No further details about how they have performed the requested tasks are provided. If a task delegation graph is extracted, recipient information involves also accepted recipients’ tasks, resulting from delegation. The recipient information thus specifies not only who has received a delegated task, but how they have processed it further. The thesis suggests decomposition of task delegation graphs into separate task patterns for each recipient, denoting generic business tasks in different expertise areas. Task delegation graph decomposition is discussed in more details in the following section.

5.2.2.3 Decomposition of Task Delegation Graphs into Task Patterns

The decomposition of a task delegation graphs into task patterns during task pattern extraction is shown in Figure 5.3. Task patterns (A’,B’,C’,D’,E’) are denoted as derivations of the respective task instances (A,B,C,D,E). The following important aspects are shown:

Separatetask patterns are extracted for the root task A, and for all accepted tasksB,C, D, andE.

Theowner for all tasks in a task pattern is the user, who had the original task instances in their to-do list.

Adelegation entityis derived from each task delegation dialog by removing the message

flow and preserving the information about requester task, recipient, and recipient task.

A suggested task pattern is set, which points at the task that can be used to further decompose and handle the delegated task in future process executions.

The provided decomposition of task delegation graphs into task patterns aims to provide incentives to end users to explicitly elaborate on the captured task patterns and to refine them in a meaningful manner. This is discussed in details in the following sections.

5.2.2.3.1 Delegation of One Specific Task to Multiple Recipients

A delegation of one task to multiple recipients can mean that the recipients have to perform the same logical task and deliver a result individually. For example, a chief executive officer requests a quarterly report from several department managers, who have to prepare the reports individually, by following the same general procedure. In this case it is reasonable to have a single guideline for all recipients. By default, this guideline is based on the task decomposition of the first department manager, i.e. in Figure 5.3 taskA1’ receivesB’ as suggested task pattern.

Based on the delegation entities and associated recipient’s tasks of the other department managers, e.g.C’, the person, performing the task pattern extraction (the chief executive officer), is able to follow and evaluate all possible executions of the delegated task. This evaluation allows the user to select the most appropriate task for further decomposition and execution.

Alternatively, the user can merge the task hierarchies of different task recipients to construct an

“optimal” best-practice for the delegated task. The finally selected or constructed best-practice can be set as a suggested task pattern for further reuse. Task patterns for unused recipients’ tasks and the related associations in delegation entities can be removed. Finally, the requester task contains delegation entities, comprising only recipients’ information for all recipients, and one suggested task pattern to be used by all recipients in future process executions.

5.2.2.3.2 Delegation of One Generic Task to Multiple Recipients

A delegation of one task to multiple recipients may further denote that different persons have been asked to do the same thing collaboratively. For example, a chief executive officer asks several department managers to coordinate and prepare a whitepaper for a new product line.

Thereby, different departments may need to take care of different aspects of the document, i.e.

one should prepare the graphical layout of the paper, another product features etc.

The correct way to handle such business case is to decompose the whitepaper task in advance into sub-tasks, which reflect the different facets of the global task. These sub-tasks would then be delegated to the respective departments’ managers according to their areas of expertise. If however a single, generic task is delegated, the resulting lack of structure can be corrected during the task pattern extraction. Correction can be performed in that the person extracting the task pattern for whitepaper preparation (e.g. the chief executive officer) is able to trace how the generic delegated task has been processed by all different recipients.

Different decomposition of the accepted tasks is expected by the different department managers as the delegated tasks refer to different operations from business perspective. These differences can be reflected in the extracted task pattern, by adding department-specific sub-tasks in the generic whitepaper task, and transferring the delegation associations for the respective recipients (department managers) to these sub-tasks. Each of the sub-tasks eventually has one delegation entity, containing only recipient information, and one suggested task pattern pointing at the respective recipient’s task of the associated department manager. Hence, enabling a single suggested task pattern for a given collaborative task requires refinement of a captured task pattern towards correct task assignment based on self-contained tasks.

Figure 5.3: Decomposition of a task delegation graph into task patterns

A1B D

A A2B1 B2D1 D2 C …D2.1 E1

E Dn

U1 U2 U4 U3

… A2.m

A2.1

Task delegation graphExtracted task patterns A1’

A’ A2’ …A2.m’

A2.1’ U2

U1 B’ B1’ B2’ C ’

owner U3 U4

D ’ D1’ D2’ …D2.1’ Dn’

task patterndelegation requester taskrecipients U2 U3

recipient tasks U4 U1

A1’ B1’ D1’

B’ C’ E1’

E’ C

suggested task pattern E’B’ D’

5.2.2.3.3 Delegation to a Single Recipient

In case of task delegation to a single recipient, the requester task in a task pattern receives a single delegation entity, containing only recipient information, and a suggested task pattern. In Figure 5.3 task B’ receives only user information for the recipient U4 and a suggested task pattern reference to task D’. The important aspect here is that decoupling suggestion for further task handling from concrete recipient information enables changing the recipients and the suggestion independently from one another. This enables flexible adaptation of the declared best-practice.