Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Analysis and optimization of business processes. Course of lectures
.pdf
Figure 3.9. Organization metamodel
Figure 3.10. Sample organizational chart
Each work item is associated with exactly one activity instance.
The selection of the process participants is subject to resource
51
allocation mechanisms, which will be discussed below. When a
knowledge worker completes the activity 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.11.
Figure 3.11. State transition diagram of work items, representing activity
instances in human interaction workflows
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.
3.3.1. Direct Allocation
In direct allocation, an individual person, rather than a position
in an organization, 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.
52
Direct allocation can always be simulated by role-based
allocation, discussed 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.
3.3.2. 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 role is
assigned, indicating that all members of the role are capable of
performing the respective 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, that is, 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 available
53
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 resolution, when the person is not available,
there is no way of continuing the business process.
3.3.3. 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.
3.3.4. Authorization
Authorization allocates persons to activity instances based on
their positions. So, a list of positions is enumerated that specifies the
persons who can perform 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.
3.3.5. 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 countersigned by two
employees with a common role. In role-based allocation, these
activities could be performed by the same employee. Separation of
duties allows relating allocations in a way that this is ruled out, so
that each document is signed by two different employees.
3.3.6. 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 useful that the same knowledge worker
54
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.
3.3.7. 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, that is, 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
information. 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.
3.3.8. 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.
55
3.4. Modelling Operation
While business process management organizes the work that a
company performs by focusing on organizational and functional
aspects, the realization of business process activities also needs to
be taken into account. Activities can be distinguished depending on
the level of software system support. The terms system workflows
and human interaction workflows were introduced to characterize
the different kinds of business process enactment.
A classification of activities in business processes was
introduced in Figure 3.12, consisting of system activities, user
interaction activities, and manual activities. To recapitulate, system
activities are performed by software systems without user
interaction, user interaction activities require the involvement of
human users and manual activities do not involve the use of
information systems.
During the enactment of human interaction workflows,
knowledge workers perform activity instances. When a knowledge
worker starts working on a specific activity, the respective
application program is started, and the input data as specified in the
process model is transferred to that application program.
When the knowledge worker completes that activity, the output
data generated is collected in the output parameters. These
parameter values can then be stored in the application program.
They can also be transferred by the business process management
system to the next activity, as specified in the business process
model.
Business process modelling aims at mapping high-level and
domain-specific features of the application process; the technical
details – the main components of the operational perspective – are
taken into account in the configuration phase of the business
process management lifecycle. The heterogeneous nature of
information technology landscapes led to various kinds of interface
definitions, most of which did not prove to be compatible. With the
advent of service-oriented computing, the operational aspects of
56
business processes are represented by services, providing the
required uniformity.
This section discusses how activities realized by software
functionality can be modelled. Conceptually, the same levels of
abstraction apply to modeling the operational perspective as to
modelling the other perspectives: at the metamodel level, interface
definition languages reside. They describe specific interface
definitions at the model level. At the instance level executing
software code is categorized.
This approach fits the modelling of activity instances (and,
therefore, also to process instances) well, because activity instances
can be realized by executing software code. It also fits the
organizational perspective in which persons reside at the instance
level. Persons are – at least in human interaction workflows –
responsible for performing activity instances.
In order to automatically invoke this software functionality,
business process management systems require concepts and
technology to access these systems. The operational perspective of
business process modelling provides the information that equips a
business process management system with information required to
invoke the functionality of external application systems.
The operational perspective includes the invocation
environment of application programs, the definition of the input and
output parameters of the application program, and their mapping to
input and output parameters of business process activities.
Therefore, functional requirements need to be detailed in order for
us to evaluate whether a certain software system provides the
required functionality in the context of a business process.
This perspective is not limited to functional requirements. Nonfunctional requirements also need to be represented, for instance,
security properties and quality of service properties of the invoked
applications or services, such as execution time and uptime
constraints. In service-oriented architectures, these properties are
typically specified in service-level agreements between collaborating
57
business partners. These service-level agreements are part of a legal
contract that the parties sign.
Figure 3.12. MOF levels of operational perspective
Interface definition languages are used to specify the usage of
procedures and functions, implemented by software system. They
are also essential to connect software systems that have been
developed independently from each other. Therefore, they are
essential for middleware systems. Middleware based on serviceoriented architectures play an increasingly important part as
realization platforms for enacting business processes. The remainder
of this section discusses aspects of service-oriented architectures
that are relevant for business process management.
The creation of service wrappers that encapsulate businessrelevant functionality of existing information systems is called
service-enabling. While there are environments in which one service
is realized by one information system, the typical case is where
business functionality is realized by the interplay of multiple existing
application systems, making service-enabling a costly and complex
matter.
58
Figure 3.13. Service-enabling closes gap between technical infrastructure and
business processes
Service-enabling closes the gap between business process
activities and the technical infrastructure for realizing them. This
situation is depicted in Figure 3.13, where the business process
activity AnalyzeOrder is realized by a service called Analyze Order
Service which combines the functionality of three underlying
software systems that run on a technical infrastructure. While the
definition and realization of the Analyze Order Service is a complex
and challenging task, this book assumes that dedicated business
functionality is available and can be used to realize activities in
business processes.
Service-oriented computing also facilitates the dynamic binding
of services to particular business process activities. This situation is
represented in the conceptual model of these layers by a many-tomany relationship between activity and service. This means that a
given activity can be realized by multiple services. Advanced
59
concepts in service engineering facilitate the dynamic binding of a
business process activity to a service at run time, providing the
potential to increase fault tolerance by selecting from a set of
possible services a service that is currently operational.
Figure 3.14. Detailed view on service-enabling, with atomic services
and composed services
A more detailed picture is provided in Figure 3.14, where
enterprise application integration middleware is explicitly shown.
Two legacy systems provide their functionality via enterprise
application integration middleware. For each of these systems, an
60
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]