Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Analysis and optimization of business processes. Course of lectures
.pdf
adapter is realized that hides the heterogeneity of the legacy
systems from higher levels. But there can also be existing software
systems that do not require the enterprise application integration
middleware layer.
In the example shown in Figure 3.14, the software component
Order 324 does not require the enterprise application integration
middleware. This is the case if the system exposes an interface with
a suitable and well-documented interface, such as a Web services
interface.
Different types of services are also shown in Figure 3.14: Atomic
services provided by individual legacy systems via service-enabling
or via enterprise application integration middleware subsystems and
composed services, which are built on top of atomic services.
These composed services provide a high-level abstraction layer
to be used in the business process layer. In particular, the
AnalyzeOrder business process activity is realized by the Analyze
Order Service, a composed service that uses atomic services
provided either by enterprise application integration middleware or
by a service-enabled software system.
The conclusions on the topic
1. Describes process models and process instances
2. Describes activity models and activity instances
3. Describes principles of the modelling process data
4. Describes principles of the modelling organization
Questions
1. Tell us about process models and process instances
2. What do you know about modelling process data?
3. What do you know about modelling organization?
4. What do you know about activity models and activity
instances?
61
TOPIC 4. BUSINESS PROCESS FLEXIBILITY
Plan of the lecture
4.1. Explicit Process Representations
4.2. Organizational Modelling66
4.3. Standardized Software Interfaces
4.4. Architecture of Process Execution Environments
The quest for flexibility can be regarded as the main driving
force behind business process management, both at an
organizational level, where strategic business processes are
investigated, and at an operational level, where human interaction
workflows and system workflows are important concepts for
realizing business processes.
According to Wikipedia, flexibility refers to the “ability to easily
bend an object or the ability to adapt to different circumstances.” In
today’s dynamic market environments, “different circumstances” are
induced by changes in the market environment of the company.
Business processes are objects that need to adapt easily to changes.
Since products that companies provide to the market are generated
by business processes, flexible business processes are an important
asset for coping with market changes in an effective manner.
Different aspects have to be taken into account when
considering flexibility. First of all, flexibility is provided by explicit
representation of business processes, because adaptations of
explicit, graphically specified business processes is much easier than
adaptation of written organizational procedures or business policies
buried in software code.
Enactment platforms, such as workflow management systems,
provide powerful mechanisms for enacting business processes in
diverse technical and organizational environments. One area specific
to human interaction work flows is the assignment of knowledge
workers to process activities. In typical workflow environments, such
as system workflows and human interaction workflows, information
systems are required for enacting workflow activities. The interfaces
62
to these systems might be hardcoded in the adapters of the
workflow management system. In dynamic software landscapes,
where functionality is provided through standardized interfaces, the
ability to change the binding of particular software to workflow
activities is another source of flexibility.
4.1. Explicit Process Representations
Business process management systems are created to narrow
the gap between business goals and their realization by means of
information technology. The main way to provide this flexibility is
based on explicit representations of business processes at different
levels. While organizational business processes have a coarsegrained structure and are typically specified textually by forms,
operational business processes consist of process activities, and
execution constraints that relate them.
Graphical notations are well equipped to support
communication about these operational business processes
between different stakeholders involved in the design and
realization of business processes.
Explicit process representations provide flexibility, since
changes to the current process can be discussed and agreed upon
by the different stakeholders involved in the design of the business
process. In this context, flexibility is achieved by changes at the
business process model level that are immediately translated to
actual business process instances.
Figure 4.1. Sample business process model
63
A simple ordering process is shown in Figure 4.1, illustrating the
concepts introduced. This process features a sequence of activities,
where the first activity to store the order is preceded by a start
event. After the order is stored, the inventory is checked. This
version of the business process rules that the shipment is prepared
only after the invoice is sent and the funds are received.
Finally, the goods are shipped and the process terminates. Due
to the somewhat cautious policy realized by the business process –
prepare shipment only after receiving the funds – business process
instances based on this process model might suffer from long
processing times, resulting in insufficient customer satisfaction.
In order to solve this problem, the process owner starts a review
of this business process by inviting process participants and process
consultants to a joint workshop. The business process model is used
as a communication platform for these stakeholders at this
workshop.
Discussing the problem of the process instances, the
stakeholders find out that concurrency can be exploited within the
process. If activities can be executed concurrently, their order of
execution is irrelevant. For instance, the preparation of the invoice
can be started before the shipment is handled. The new and
improved version of the business process is shown in Figure 4.2.
Figure 4.2. Sample business process model, improved version
with concurrency
Although in this example the deficits of the business process
are obvious, the improvement of the process by introducing
64
concurrency shows quite well how an explicit process model can
foster response to change.
The translation of the business process model to the actual
operational environment can be realized in different ways. If the
business process is realized by a human interaction workflow, then
the modified business process model needs to be deployed in the
workflow management system. Deployment typically includes
enrichment of the business process model with information to make
the process executable.
In particular, there needs to be a translation from the graphical
model to an executable format that is specified in a particular
workflow language or – in case the system workflow is realized in a
service-oriented environment – in a service composition language.
In any of these realizations, the explicit representation of business
process models provides the flexibility to change the process and to
finally enact the modified process.
New process instances would then follow the new, improved
business process model. If, on the other hand, business processes
are enacted without any system support, then the business process
model is translated manually to a consistent set of procedures and
policies that the knowledge workers need to follow.
The flexibility resulting from the explicit modelling of business
processes is fundamental to business process management
applications. Looking at flexible workflow management, advanced
flexibility properties will be discussed that allow us to change the
structure of running workflow instances, providing an even higher
degree of flexibility.
4.2. Organizational Modelling
The modelling of organizational aspects also provides flexibility
in business process management. In this section, role resolution in
an intra-company setting is discussed, in which different approaches
are investigated to associate knowledge workers with business
process activities. In the case of human interaction workflows, the
enactment environment of the business process has to take into
65
account the organizational structure of the company that runs the
business process. Flexibility in organizational modeling is achieved
by assigning roles to process activities, and not to specific
individuals.
By associating roles with activity models at design time and
mapping roles to personnel that is skilled, competent, and available
to perform the activity at run time, flexibility is improved, because
changes in the personnel structure of the organization do not affect
the business processes.
For instance, absent knowledge workers are not with associated
with specific activity instances, as are persons who are currently
available. Thereby, the dynamic aspect in the organization –
knowledge workers might be temporarily absent or there might be
changes in the work force – can be represented at the model level.
Consequently, changes in the personnel are hidden from the
process, as long as the roles defined in the model can actually be
filled by persons in the organization.
Figure 4.3. Simple business process model with role information
Consider a business process with a set of activities that need to
be executed sequentially. An example of such a business process in
a banking environment is in shown in Figure 4.3. These activities
involve entering a credit request (Enter Credit Request), gathering
information on the financial situation of the client (Analyze client),
proposing a decision on the credit request, and reviewing and
submitting the decision.
A subset of these activities is assigned the same role. In the
example, a clerk is responsible for the first three activities, whereas
66
the clerk’s boss finally decides and submits the decision. This
situation can be represented in a business process model by
associating the role Clerk and the role Boss with their respective
activities.
For each process instance by role resolution, the system offers
these activities to knowledge workers who can fulfill the respective
role. Figure 4.4 shows a situation in which three different knowledge
workers with the role Clerk are associated with the activity instances
of that role.
Figure 4.4. Simple business process instance with knowledge workers associated
with activities
While this role resolution is correct from a formal point of view,
this situation is undesirable in most cases because each clerk needs
to understand the context of the case, which leads to longer process
durations and potentially incorrect decisions.
In the example, the hand-over of work from Peter to Charles
and from Charles to Anne leads to delays in process executions and
should therefore be avoided. In addition, Charles needs to get
familiar with the case entered by Peter, and Anne needs to get
familiar with the case that Charles analyzed beforehand.
This figure also shows that at the business process instance
level, knowledge workers are associated with activity instances, while
67
at the business process model level, roles are associated with activity
models.
To provide adequate support through role resolution, the
business process model needs to contain the information that
whoever conducted the first clerk activity also has to conduct the
other two clerk activities. In this case, all clerk activities are
associated with Charles, who then can perform them much quicker
than the three persons in the previous setting. This beneficial role
resolution is shown in Figure 4.5.
Figure 4.5. Simple business process instance with one knowledge worker
associated with clerk activities
This advanced role resolution works well if the same knowledge
worker is available during the whole business process instance – or
at least during the steps that the person conducts. But there are
cases where a person has started on a process instance by
conducting the first activity, but then becomes unavailable.
In this case, a decision needs to be made: either the process is
delayed until the person returns to work or the case is transferred to
another clerk. This clerk needs to understand the overall context of
the case before he can start processing the activity. This decision is
influenced by multiple factors, such as the type of business process,
the expected delay, and the effect of the delay, and therefore cannot
be performed automatically in general. Selection of Business
68
Partners in Process Choreographies The modelling of organizational
aspects in business process management can be extended to
business partners, which is important in the context of business-tobusiness processes.
Consider a business process choreography with multiple
business partners, each of which plays a specific role in the
choreography. If there is a role Shipper specified according to the
requirements for shipping goods, it can be bound to specific
enterprises that can perform the work. Additional flexibility is gained
because the organizations participating in a choreography are not
hardwired, but represented at the model level.
There are different options for selecting a particular shipper.
The selection can be done before a particular process instance
starts. This alternative is useful if sufficient information on the goods
to be shipped is available before the process starts.
In scenarios where only during run time of the process instance
are the goods and the sender and receiver determined, the dynamic
selection of a shipper is useful. Based on the information on the
shipment and on its additional properties – such as dangerous
goods – an appropriate shipper can be selected at run time.
An example involving a customer, a broker, and a set of
suppliers is shown in Figure 4.6. In this example, a customer uses a
broker to select a supplier. Before the process choreography can be
realized, the broker requires information on the suppliers available.
This information is gathered by the broker in a separate process
choreography, whose message flow is not shown in the figure.
The process choreography starts with the creating of an order
by the customer. Then, the customer sends a Request Supplier Info
message to the broker. The broker receives this message and uses
local information to find the supplier most suitable for fulfilling the
order. In the Send Supplier Info message, the broker informs the
customer about this supplier.
69
Figure 4.6. Business partner selected at run time, using a broker
The customer receives this message and uses the information
received to send an order to the selected supplier, Supplier-A in this
case. When the supplier has processed the order, the supplier sends
the goods to the customer, and the process completes.
In the example shown, the selection is performed using a third
party, the broker. While this is a valid option in scenarios where a
broker has rich information on a set of business partners, the
selection can also be done locally, that is, without the involvement
of a third party.
In this case, the actual selection can be performed as a manual
activity, using information on suppliers available and capable of
fulfilling the order. Role resolution in this case is not performed by
the business process management system, but by a knowledge
worker. This task also matches the service-oriented approach, where
a service requestor (the knowledge worker) uses the broker to select
70
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]