• Environment data: The data object is part of the business process execu- tion environment; it can be accessed by process activities during process enactment.
Data interaction patterns describe how data objects can be passed between activities and processes. Data objects can be communicated between activities of the same business process, between activities and subprocesses of the same business process, and also between activities of different business processes.
Data can also be communicated between the business process and the business process management system.
Data transfer is the next dimension to consider. Data transfer can be performed by passing values of data objects and by passing references to data objects. These data transfer patterns are very similar to call-by-value and call- by-reference, concepts used in programming languages to invoke procedures and functions.
In data-based routing, data can have different implications on process enactment. In the simplest case, the presence of a data object can enable a process activity. Data objects can also be used to evaluate conditions in business process models, for instance, to decide on the particular branch to take in a split node.
Workflow data patterns are an appropriate means to organize aspects of business processes related to the handling of data.
M2: Metamodel (organization meta model)
M1: Model (organization model)
M0: Instance (persons, e.g., knowledge workers, managers)
describes
describes
Notation (organization model
notation, e.g., Organization Chart)
exp resses Instance-of
Instance-of
Fig. 3.25.MOF levels of organization aspect
allows filling positions according to an overall organizational plan. In addition, the company can cope better with changes in personnel. Organizational units are permanent groupings of persons based on their positions. Organizational teams or project teams are specific organizational units without a permanent nature. They are conceptualized in the object model shown in Figure 3.26.
Person Position
occupies
Role
participates in can delegate
work to
Organizational Unit is member
of
Organizational Team reports to
Fig. 3.26.Organization metamodel
Figure 3.27 shows an organizational chart of a fictive enterprise. In or- der for us to not overload that figure, it contains positions only at the top levels, the chief executive level and the department level. Departments are organizational units with a set of member positions.
The link between the organizational structure of an enterprise and the business processes is accomplished by work items. Work items represent activ- ity instances to be performed, and work items are associated with knowledge workers to facilitate their selection by knowledge workers. In particular, when
Lena CEO
Nicole BTP Head
Charles CSG Head
Paul DSC Head
Jane Administration
Alan Public Relations
Anna
Emma
Richard
Jens
Mary
Peter
Hans
Claus
Lars
Marlene
Theo
Betty Petra
Michael Assistant
Fig. 3.27.Sample organizational chart
the business process management system determines that a certain activity instance enters the ready state, a work item is offered to a set of knowledge workers.
Each work item is associated with exactly one activity instance. The selec- tion of the process participants is subject to resource allocation mechanisms, which will be discussed below. When a knowledge worker completes the ac- tivity instance, the business process management system is informed, so that the process instance can be continued accordingly.
In order to discuss the resource allocation principles, a state transition diagram of work items is considered, and a relationship of activity instances to the respective state transitions is provided. The state transition diagram of work items is shown in Figure 3.28.
The assignment of process participants to activities in a business process can be classified by resource patterns. A rich set of resource patterns have recently been introduced; in this book, the most relevant resource patterns are discussed.
Direct Allocation
In direct allocation, an individual person, rather than a position in an organi- zation, is allocated to all activity instances of a particular activity model. This resource allocation is useful in cases where there is exactly one person who is suitable for performing these activities, such as the chairperson of a company, who has to finally decide on investments exceeding a certain threshold.
done
created offered completed
withdrawn selected
suspended
offer select
withdraw
suspend resume
Fig. 3.28. State transition diagram of work items, representing activity instances in human interaction workflows
Direct allocation can always be simulated by role-based allocation, dis- cussed next, simply by providing a role with one member, in our example the company owner. However, if this property of the organization will remain stable over a long period of time, introducing a separate role (owner) is not required, so direct allocation can be used. The limitations of direct allocation will be discussed in the context of role-based allocation.
Role-Based Allocation
Role-based allocation is the standard way of allocating work to the members of organizations. It is based on the understanding that all members of a certain role are somehow functionally equivalent, so that any member of the role can perform a given unit of work.
To each activity model in a business process model, a is role assigned, indicating that all members of the role are capable of performing the respec- tive activity instances. The mapping of role information to specific knowledge workers is called role resolution. Current information on the availability of the knowledge worker is used during role resolution.
There are two ways of realizing role-based allocation. In the first way, when an activity instance enters the ready state, the work item is communicated to the members of the group. Once one member of the group selects a work item, the work items associated with the other group members are deleted. In the second way, only one person is selected to perform the activity instance, so only one work item is created.
Role-based allocation provides a set of interesting advantages with respect to direct allocation, all of which are related to enhancing the flexibility of business processes. Firstly, the business process model does not need to be changed when there are changes in the personnel, i.e., employees retire and new employees are hired. When using direct allocation, any change in the
personnel related to the directly allocated persons would result in a change in the business process model.
Secondly, by role resolution at run time of the business process, only avail- able persons are selected to perform activities. This approach avoids situations in which persons are selected to perform activity instances that are currently not available, for instance, due to meetings or absence. In direct role reso- lution, when the person is not available, there is no way of continuing the business process.
Deferred Allocation
In deferred allocation, the decision about who performs an activity instance is only made at run time of the business process. To this end, there is no distinction between deferred allocation and role-based allocation. However, in deferred allocation, rather than using the role information defined during design time, the allocation is performed as an explicit step in the business process, and not influenced by role information.
Authorization
Authorization allocates persons to activity instances based on their positions.
So, a list of positions is enumerated that specifies the persons who can per- form the activity instance. This could also be achieved by adding a new role that captures the authorization. A specific type of authorization that uses capabilities of the knowledge worker to perform allocation is also possible.
Separation of Duties
The separation of duties allocation scheme relates different allocations within one business process. For instance, a document needs to be signed and coun- tersigned by two employees with a common role. In role-based allocation, these activities could be performed by the same employee. Separation of duties al- lows relating allocations in a way that this is ruled out, so that each document is signed by two different employees.
Case Handling
In the case handling allocation scheme, certain activities in a business process require an understanding of the overall case. In these environments, it is use- ful that the same knowledge worker deals with all activities of one business process instance. This avoids errors and reduces processing time, because the knowledge worker already knows the case, and so can solve the issues at hand more efficiently than a colleague to whom the case is not known. This is a key concept in case handling, which is discussed in more detail in Section 7.5. The
“retain familiar” allocation scheme is very similar to case handling; however, not all activity instances of a case are allocated to one specific knowledge worker, but rather only a subset of them.
History-Based Allocation
The idea of history-based allocation is that a person is allocated to an activity instance based on what this person worked on previously, i.e., on the history of the activity instance that he or she completed. This includes other business process instances. The goal is to allocate work to persons according to their personal experiences and expertise that is not represented in the role infor- mation. While this is not part of a role specification, this information needs to be represented in the business process management system so that it can decide on the allocation based on the history and personal experiences. This allocation scheme is useful for realizing a “one face to the customer” strategy, in which for each customer there is a dedicated individual responsible for all aspects of communication with it.
Organizational Allocation
If organizational allocation is used, not roles but the positions within the overall organization are used to allocate activity instances. For instance, to authorize expenditure, the manager of the organizational unit that requested the expenditure needs to approve. Depending on the particular language used to express organizational allocation, complex allocation rules can be realized, all of which take advantage of the organizational structure of the company.