Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Analysis and optimization of business processes. Course of lectures
.pdf
valid business process instances are reflected by the business
process model.
Simulation techniques can be used to support validation,
because certain undesired execution sequences might be simulated
that show deficits in the process model. Simulation of business
processes also allows stakeholders to walk through the process in a
step-by-step manner and to check whether the process actually
exposes the desired behavior. Most business process management
systems provide a simulation environment that can be used in this
phase.
Business processes involving multiple participants play an
increasing role to foster the collaboration between enterprises.
Business process modelling has an evolutionary character in the
sense that the process model is analyzed and improved so that it
actually represents the desired business process and that it does not
contain any undesired properties. Deadlock is such a property, in
which all activities in a business process come to a halt.
The conclusions on the topic
1.Basic principles of management business processes
2. Given the concept of the life cycle of a business process
3.Describes the principles of design and analysis of business
processes
Questions
1. Tell us about the main principles of management business
processes.
2. Give the definition of the life cycle.
3. List the basic principles of design and analysis of business
processes.
21
TOPIC 2. BUSINESS PROCESS MODELLING FOUNDATION
Plan of the lecture
2.1. Conceptual Model and Terminology
2.2. Abstraction Concepts
2.2.1. Horizontal Abstraction
2.2.2. Vertical Abstraction
2.3. From Business Functions to Business Processes
2.1. Conceptual Model and Terminology
Figure 2.1 introduces a model of the concepts at the core of
business process management. While the terms mentioned have
been used in the previous chapters informally, the concepts behind
these terms and their relationships will now be discussed in more
detail, using conceptual models. These models are expressed in the
Unified Modeling Language, an object-oriented modelling and
design language.
Business processes consist of activities whose coordinated
execution realizes some business goal. These activities can be
system activities, user interaction activities, or manual activities.
Manual activities are not supported by information systems. An
example of a manual activity is sending a parcel to a business
partner.
User interaction activities go a step further: these are activities
that knowledge workers perform, using information systems. There
is no physical activity involved. An example of a human interaction
activity is entering data on an insurance claim in a call center
environment. Since humans use information systems to perform
these activities, applications with appropriate user interfaces need to
be in place to allow effective work. These applications need to be
connected to back-end application systems that store the entered
data and make it available for future use.
Some activities that are conducted during the enactment of a
business process are of manual nature, but state changes are
entered in a business process management system by means of user
22
interaction activities. For instance, the delivery of a parcel can be
monitored by an information system. Typically, the actual delivery of
a parcel is acknowledged by the recipient with her signature. The
actual delivery is important information in logistics business
processes that needs to be represented properly by information
systems. There are several types of events during a logistics process.
These events are often available to the user as tracking information.
While the activities are of manual nature, an information system –
the tracking system – receives information on the current status of
the process.
Figure 2.1. Business processes: conceptual model
System activities do not involve a human user; they are
executed by information systems. An example of a system activity is
retrieving stock information from a stock broker application or
checking the balance of a bank account. It is assumed that the
actual parameters required for the invocation are available. If a
human user provides this information, then it is a user interaction
activity. Both types of activities require access to the respective
software systems.
23
Certain parts of a business process can be enacted by workflow
technology. A workflow management system can make sure that the
activities of a business process are performed in the order specified,
and that the information systems are invoked to realize the business
functionality. This relationship between business processes and
workflows is represented by an association between the respective
classes. We argue that workflow is not a subclass of business
process, since a workflow realizes a part of a business process, so a
workflow is not in an “is-a” relationship with a business process, but
is an association. With regard to the types of activities mentioned,
system activities are associated with workflows, since system
activities can participate in any kind of workflow, system workflow or
human interaction workflow. User interaction activities and manual
activities, however, can only participate in human interaction
workflows.
2.2. Abstraction Concepts
To capture the complexity in business process management,
different abstraction concepts are introduced.
A traditional abstraction concept in computer science is the
separation of modelling levels, from instance level to model level to
metamodel level, denoted by horizontal abstraction.
Even when using horizontal abstraction, separate subdomains
need to be investigated. In order to follow the divide-and-conquer
approach, these subdomains need to be represented separately.
Aggregation can also be used to cope with complexity,
motivating another type of abstraction. At a higher level of
abstraction, multiple elements of a lower level of abstraction can be
grouped and represented by a single artefact.
For example, a set of functional activities of small granularity
can contribute to a particular business function at a higher level of
granularity: a coarse-grained business function “order management”
might aggregate many smaller-grained activities, like receiving an
incoming order, checking the inventory, and confirming the order.
This type of abstraction is called aggregation abstraction, because
24
the coarse-grained business function aggregates activities of smaller
granularity.
Aggregation abstraction is different from horizontal abstraction,
because all activities (the small-grained and the coarse-grained) are
at one horizontal level of abstraction, for example, the instance level.
Aggregation abstraction is primarily used in the functional
subdomain, where functions of smaller granularity are combined to
create functions of larger granularity.
2.2.1. Horizontal Abstraction
Along the lines of the levels of abstraction identified by the
Object Management Group, the metamodel level, the model level,
and the instance level play important roles in the design and
analysis of complex systems in general and software systems in
particular. It is instructive to explain these levels in am bottom-up
order, starting with the instance level.
The instance level reflects the concrete entities that are involved
in business processes. Executed activities, concrete data values, and
resources and persons are represented at the instance level.
To organize the complexity of business process scenarios, a set
of similar entities at the instance level are identified and classified at
the model level.
For instance, a set of similar business process instances are
classified and represented by a business process model. In object
modeling, a set of similar entities is represented by a class, and in
data modeling using the Entity Relationship approach, a set of
similar entities is represented by an entity type, and similar
relationships between entity types are represented by a relationship
type.
Models are expressed in metamodels that are associated with
notations, often of a graphical nature. For instance, the Petri net
metamodel defines Petri nets to consist of places and transitions
that form a directed bipartite graph.
The traditional Petri net notation associates graphical symbols
with metamodel elements. For instance, places are represented by
25
circles, transitions by rectangles, and the graph structure by directed
edges.
Figure 2.2. Levels of abstraction
In data modelling, the Entity Relationship metamodel defines
entity types, relationship types, and connections between them.
Typical graphical notations of the Entity Relationship metamodel are
rectangles for entity types and diamonds for relationship types,
connected by lines.
While often there is one graphical notation for one approach, a
one-to-one correspondence between notation and metamodel is
not mandatory. In a Petri net, the concept of a transition could also
be represented by another symbol in a graphical notation. There are
26
different notations for representing Petri nets, which differ in the
graphical representation of transitions. While some use rectangles,
others use solid bars.
Therefore, it is important to distinguish between the concepts
of a modeling approach and the graphical notation used to
represent these concepts.
The complete set of concepts and associations between
concepts is called metamodel. A metamodel becomes useful if there
is a notation for this metamodel that allows expressing models in a
convenient way that allows communication between stakeholders in
the modelled real-world situation.
The different levels of abstraction and their relationships are
shown in Figure 2.2. A notation associated with a metamodel allows
expressing the concepts of that particular metamodel. Each model is
described by a metamodel, and is expressed in a notation
associated with the metamodel.
2.2.2. Vertical Abstraction
Vertical abstraction in business process modelling is depicted in
Figure 2.3, where distinct modelling subdomains are identified. As
depicted, process modeling is at the centre of the modelling effort,
because it also integrates the modelling efforts that are conducted
in the other subdomains.
Function modelling, data modelling, organization modelling,
and modeling of the operational information technology landscape
are required to provide a complete picture of a business process.
While these subdomains are the most important ones, additional
subdomains can be defined if they are relevant.
The functional model investigates the units of work that are
being enacted in the context of business processes. The
specification of the work can be done at different aggregation
levels, from coarse-grained business functions to finegranular
functions at the operational level that are realized by knowledge
workers and information systems.
27
Figure 2.3. Business process modelling includes multiple modelling domains,
integrated by process modelling
The specification of these functions can be informal, using
English text or formal, using syntactic or semantic specifications of
functions. While informal descriptions are mostly done at the coarse
business level, more precise specifications are required in the
software layer when it comes to implementation of certain functions
using information systems.
The investigation and proper representation of data in business
processes is important, because decisions made during a business
process depend on particular data values. Also data dependencies
between activities need to be taken into account in process design,
to avoid situations in which a function requires certain data not
available at that time.
The proper representation of the organizational structure of a
company is an important requirement. Activities in the business
process can then be associated with particular roles or departments
in the organization. Many activities in a business process are
performed by or with the assistance of information systems. The
operational information technology landscape, that is, the
information systems, their relationships, and their programming
28
interfaces, needs to be represented to use the functionality provided
by the information systems.
Process modelling defines the glue between the subdomains. A
process model relates functions of a business process with
execution constraints, so that, for instance, the ordering and
conditional execution of functions can be specified. Data aspects are
covered because particular process instances may depend on the
structure and value of data involved in a particular business process.
For example, in a credit approval business process, the type of
approval depends on the credit amount requested. In addition, data
dependencies between activities need to be taken into account in
process model design.
2.3. From Business Functions to Business Processes
Value chains provide a high-level organization of the functions
that an enterprise performs. To provide a more detailed view, these
top-level business functions are broken down to functions of smaller
granularity and, ultimately, to activities of operational business
processes.
Functional decomposition is the technique of choice.
A partial functional decomposition of a value chain is shown in
Figure 2.4, where a value system represents the highest level of
aggregation. Each value system consists of a number of value
chains, characterized by the class diagram on the left hand side in
Figure 2.4.
The ordering of the value chains in the value system is not
represented in this structure diagram because it does not have any
formal meaning. There are complex interactions between these
companies, so that, obviously, not all activities in the supplier value
chain occur before all activities conducted by enterprise E.
The functional decomposition of the value chain of enterprise E
is exemplified for one particular path of functions in the marketing
and sales top-level business function. Among many other functions,
marketing and sales includes a business function, Order
Management, that contains functions related to the management of
29
incoming orders. Order management is decomposed further into
business functions for getting and checking orders. To check orders,
they need to be analyzed, and there are functions for simple and
advanced checking of orders.
Figure 2.4. Functional decomposition from value chain
to business functions
As shown in Figure 2.4, there are different symbols for business
functions and for functions of the finest granularity: business
functions are represented by rectangles, while functions of the finest
granularity are represented by rectangles with rounded corners.
Functions at the leaf level of the functional decomposition are also
called activities.
Traditionally, functional decomposition was used to describe
enterprises based on the functions they perform. Concentrating on
30
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]