Task Models and Business Process Models

The term “task” has partially overlapping, but different meanings in the areas of Human-Computer Interaction (HCI) and Business Process Management (BPM). HCI research considers tasks as low-level interactive activities, such as providing generic system input (e.g. writing text in word processors or web forms), browsing or searching (e.g. in text documents or on the web), and aims to facilitate the understanding of how interactive user tasks can be supported in an efficient and user-friendly manner. Different methods for task modeling and analysis have been developed for this purpose. A widely spread generic method for investigations of human performance that involves computer systems is Hierarchical Task Analysis (HTA) [AS00, Ann04]. HTA focuses on the goals that should be achieved through a given task and enables goal decomposition and definition of operations and sub-operations for achievement of the identified goals. Plans are further considered, which define rules for the operations’ sequence in different circumstances. The principles of HTA about goal definition and decomposition have been adopted by further HCI methods for task analysis such as Goals, Operators, Methods, and Selection rules (GOMS) [JK06a, JK06b, Joh03]. These methods originate from applied information-processing psychology [CMN83] and provide a cognitive model of user behavior which focuses on the goals that users want to achieve through interacting in computer systems.

Limitations of GOMS like strictly sequential task ordering, and weak tool support for pragmatic application in real-life settings are addressed in a further task modeling framework called Concur Task Trees (CTTs) [PMM97, Pat04]. CTT enables system designers to describe the logical activities that an interactive application should support and facilitate model-driven software engineering from requirements analysis [MPS02] to user interface design [KK05]. The CTT notation is highly expressive and includes temporal relationships between tasks, hierarchical work break-down, and different task types such as interactive, human or (automated) application tasks.

Further approaches like Groupware Task Analysis (GTA) [vdVLB96] combine task analysis methods from HCI with ethnographic methods as used in Computer Supported Cooperative Work (CSCW) towards comprehensive methodologies for requirements analysis and design of

groupware applications. GTA has been adopted and extended by further methods for design of complex interactive systems [vdVvW04]. A detailed discussion and comparison of different task modeling approaches for user interface design is provided in [LV04].

Some similarities can be found between task modeling approaches from the HCI area and business process modeling approaches from the area of BPM. For example, the task types of CTT: user task, interaction task, and application task [PMM97], share similar meaning correspondingly with the basic BPMN task types – user task, manual task, and service task [OMG06]. BPMN gateways on the other hand resemble task flow gateways from the task modeling methods adopted by GTA [vdVLB96]. However, in contrast to the area of HCI where task models refer to low-level interactive activities and are used for designing interactive systems, BPM literature considers tasks as high-level steps in business processes [vdABV+99, vdAvH02].

A business process is generally considered to handle a specific case, e.g. a tax declaration or an insurance claim. Thereby human activities comprise cases which are handled through performing sequences of tasks by using appropriate resources [vdABV+99]. The task sequences determine the overall process flow, whereas business process models do not provide detailed specification of the necessary interactions for performing a given task on system level. Business process models preserve a certain level of abstraction to be able to support process automation on different technological platforms. The models need to be interpreted by a BPM system or by a workflow management system, which links human participants with the appropriate applications and supplies them with the right information to perform their tasks [vdAvH02].

To sum up, task modeling approaches from the area of HCI do not share the purposes of business process modeling and do not provide adequate techniques to represent process aspects such as control flow, data flow, event flow and involved human actors. Merging both modeling approaches - task modeling from the HCI field, and business process modeling, can lead to new methodologies for designing customizable BPM systems. Such systems can benefit from model-driven user interface design and provide BPM environments with adaptable, process-specific and task-specific interfaces. Such considerations exceed the scope of the current thesis.

The thesis is focused on the creation and adaptation of business process models by end users and adopts the notion of “task” introduced in BPM literature [vdABV+99, vdAvH02] (cf.

Definition 1.2). A task is considered as a fine-granular building block of a business process, which defines a generic business activity that should be performed to achieve the desired business goal of the process. Thereby no interactions on system level for executing a given task are specified. For example, typical tasks in a process for selling goods to a customer on credit would be to check the customer’s credit history and to get approval from management for credits above a given limit. The corresponding task models in the business process model can define parameters or business rules for these tasks but may not define interactions on system level, such as e.g. input of customer name or credit amount in interactive forms, to keep the process model generic. The interactions are implementation-specific and depend on the concrete system on which these tasks are executed.

4.2 Task Patterns as Knowledge Artifacts for Ad-Hoc Process Support Conventional workflow management systems are bound to rigid process definitions and do not provide sufficient flexibility to support ad-hoc, knowledge-intensive processes [Sch01]. For supporting such processes [Sch01, Sch03] propose a task-based approach, where processes emerge as hierarchical task structures that are composed during process execution from ad-hoc, user defined task representations. Available task models for recurring cases are provided as building blocks for emergent process models at runtime, whereas task instances represent copies of the reused task models within a concrete process execution [Sch03].

The idea of dynamically composing ad-hoc processes by using reusable task structures is further adopted in [RRMvdA05]. The latter study proposes the use of “task patterns” and

“process patterns to support ad-hoc processes by facilitating the reuse of process knowledge.

[RRMvdA05] proposes separation of work knowledge into independent“Task Information Units (TIUs)” which“can describe data aspects, e.g., concrete customer data, but also process aspects, e.g., steps required to file a patent”. [RRMvdA05] further suggest that users deal with task patterns and task related information in that they provide information to characterize the task they want to accomplish, and based on this information the system provides“different kinds of TIUs:

(1) Process Patterns that can be used to structure the task into suitable sub-tasks; (2) Task Related Information, which support the execution of task, e.g., regarding experts who can be consulted or external services on which the user can draw; and finally (3) relations between these information units and the task or specific sub-tasks of a chosen process pattern”. To decrease the effort that end users need to spend for organizing the work and for providing task descriptions, [RRMvdA05] further consider observing users’ desktop activities, interactions with applications such as e.g. email, browser, text editors or document repositories to build and leverage a user’s context and try to figure out a generic task, i.e. task pattern that the user is executing. Ad-hoc processes are then supported through capturing and providing task patterns for reuse in recurring business cases. For managing task patterns [RRMvdA05] further suggest that “task patterns require repositories containing descriptions of cases, which have been executed, including all relevant task constituents. Context, goal, and planning information must be stored and can be used to identify appropriate task patterns”. [RRMvdA05] uses the terms“TUIs”,“task patterns”

and“process patterns” in an interleaved manner without providing explicit, strict definitions of a process, a task, a process pattern or a task pattern. Both, tasks as well as processes can be fully executed in a common application environment, and each process as well as each task has a given goal. However, [RRMvdA05] does not discuss any boundaries where a task with a generic goal becomes a process, e.g. through further decomposition and delegation of sub-tasks, or where a task pattern becomes a process pattern, i.e. through abstraction and generalization of the corresponding goal and contained information. On the one hand, the term “task pattern” seems to relate to reusable information units that are based on captured desktop activities of a system user and provide information about used applications and executed interactive tasks, such as opening a document or browsing on the internet. On the other hand, task patterns seem to relate to generic task structures that define the overall goal that has been pursued in a given business case, and the sub-steps that have been performed to achieve this goal. Thus, task patterns can serve also as process patterns or task models [Sch01, Sch03], i.e. as building blocks that are used to compose dynamically ad-hoc processes during their execution based on previous experience.

The concept of task patterns for supporting ad-hoc, knowledge-intensive processes introduced in [RRMvdA05] is further developed in the NEPOMUK project [NEP06]. [GOR+07] proposes dynamic composition of ad-hoc processes in the form of task hierarchies. This composition is based on a task management model where“Task Patterns describe a kind of active task templates that provide information that helps users to organize their own task. A task pattern can be regarded as an abstraction of a class of similar cases and thus describes a kind of best practice for the execution of specific tasks. In this respect, a task pattern can contain all kind of reusable information resulting from cases” [GOR+07]. The latter study considers various static task pattern information such as possible sub-tasks, dependencies between sub-tasks, decisions, and completion measures, and dynamic task pattern information such as information objects and statistics. [GOR+07] further suggests, that“task patterns are created by an abstraction process and task instances are created from patterns in an instantiation process”. Thus, task patterns serve as task models (cf. also [Sch03]) that can be used to compose task hierarchies, i.e. ad-hoc processes, by reusing previous process knowledge such as task decomposition, associated information artifacts and expertise.

Further developments of the concept of task patterns for supporting ad-hoc, knowledge work

can be found in [RCKM06, OGR07, JGOR07, Sch09]. The latter studies leverage the role of task patterns as reusable, explicit task structures that capture personal and organizational knowledge on recurring business cases in the context of pattern-based task management. [Sch09] describes an enhanced personal task management system that has been developed in the NEPOMUK project [NEP06] to provide support for task patterns as reusable knowledge artifacts in ad-hoc processes. In the described system, task patterns are developed explicitly based on task representations in a hierarchical to-do list [Sch09]. No automated detection of interactive tasks from users’ desktop activities is performed for recognition and capturing of a task pattern as initially proposed in [RRMvdA05]. Thus the role of task patterns is primarily to serve as reusable building blocks for ad-hoc processes that are based on explicit task representations in a task management system and provide personal and organizational process knowledge.

The thesis focuses on business process composition based on personal task management.

Similarly to [RCKM06, OGR07, JGOR07, GOR+07, Sch09], a task pattern is considered as reusable task structure that describes how a given generic business task can be accomplished. The concrete task pattern definition that is adopted in the thesis is provided later on. Here it is important to stress that task patterns serve as building blocks for weakly-structured, knowledge-intensive business processes. These processes are based on hierarchical task decomposition rather than on formal workflow models [Sch03, RCKM06] as discussed further in the thesis. For example a task pattern for selling goods on credit can contain sub-tasks for checking the customer’s credit history and acquiring approval from a senior manager for credits exceeding a given limit, as well as information about required documents and related experts. This pattern can be used as best-practice in an ad-hoc sales process, if the customer is not able to pay the complete amount of the ordered goods. The task pattern can be combined with the task structure and information from the conventional sales process to compose a sales process involving ordinary payment and credit. Thus the adopted notion of task patterns refers to task patterns as task models, i.e. as building blocks for dynamic composition of ad-hoc business processes.

The notion of task patterns that is adopted in the thesis has to be clearly distinguished from task patterns for interactive systems design. Such patterns are discussed in HCI literature as reusable structures for task models of interactive applications [Pat00, GSSF04, PB04, Sin04] and describe recurring situations during the user interaction with a software system. For example an

“Evaluation Task Pattern” is used to model situations in which the user selects a set of data that needs to be evaluated and inserts parameters required during the evaluations [Pat00]. Other typical examples for such task patterns are search and login operations or filling out a form [GSSF04]. The notion of task pattern in the area of interactive systems’ design thus refers to recurring user activities at interaction level rather than to recurring, generic business cases on process level. The different notions of task patterns result from the different interpretations of tasks in the fields of BPM and HCI discussed in Section 4.1.