Business Process Management (Part-1 Foundation[Chapter I Introduction] ) Sec D -- By Mathias Weske

Enactment
Once the system configuration phase is completed, business process instances
can be enacted. The process enactment phase encompasses the actual run time
of the business process. Business process instances are initiated to fulfil the
business goals of a company. Initiation of a process instance typically follows
a defined event, for instance, the receipt of an order sent by a customer.
The business process management system actively controls the execution
of business process instances as defined in the business process model. Process
enactment needs to cater to a correct process orchestration, guaranteeing that
the process activities are performed according to the execution constraints
specified in the process model.
A monitoring component of a business process management system visualizes
the status of business process instances. Process monitoring is an important
mechanism for providing accurate information on the status of business
process instances. This information is valuable, for instance, to respond to a
customer request that inquires about the current status of his case.
Detailed information on the current state of process instances are available
in a business process management system. In Section 3.4, the states and
state transitions of activity instances are investigated, while Section 3.5 covers
process instances. State information can be used to visualize and monitor
process instances. Visualization techniques can be based on colours, so that,
for instance, an enabled activity is shown in green, a running instance is
marked in blue, and a completed process instance is represented in grey. Most business process management systems provide monitoring information that is
based on states of active business processes.
During business process enactment, valuable execution data is gathered,
typically in some form of log file. These log files consist of ordered sets of log
entries, indicating events that have occurred during business processes. Start
of activity and end of activity is typical information stored in execution logs.
Log information is the basis for evaluation of processes in the next phase of
the business process lifecycle.

Evaluation

The evaluation phase uses information available to evaluate and improve business
process models and their implementations. Execution logs are evaluated
using business activity monitoring and process mining techniques. These techniques
aim at identifying the quality of business process models and the adequacy
of the execution environment.
For instance, business activity monitoring might identify that a certain
activity takes too long due to shortage of resources required to conduct it.
Since this information is useful also for business process simulation, these
phases are strongly related.
Similar considerations apply to process mining, which has recently developed
into an active field of research. There are different applications of process
mining. If the execution logs are generated by traditional information systems,
they collectively can be used as a starting point to develop business process
models. The evaluation of existing business process models is another application
area of process mining. The evaluation phase is not covered in detail in
this book; for further information, the reader is referred to the bibliographical
notes in the end of this part.


Administration and Stakeholders

There are numerous artefacts at different levels of abstraction in business
process management scenarios that need to be organized and managed well.
Structured storage and efficient retrieval of artefacts regarding business process
models and information on business process instances as well as the organizational
and technical execution environment need to be taken into account.
Especially in large organizations with hundreds or thousands of business
process models, a well-structured repository with powerful query mechanisms
is essential. In addition to business processes, knowledge workers with their
organizational roles and skills, as well as the information technology landscape
of the enterprise, need to be represented properly.
The business process domain is characterized by several types of stakeholders
with different knowledge, expertise, and experience; these are classified into
the following roles:
• Chief Process Officer: The chief process officer is responsible for standardizing
and harmonizing business processes in the enterprise. In addition, he
or she is responsible for the evolution of business processes in the presence
of changing market requirements. Installing an explicit role of chief
process officer acknowledges the importance of business process management
at the top level management.
• Business Engineer: Business engineers are business domain experts responsible
for defining strategic goals of the company and organizational
business processes. Often, business engineers have a nontechnical educational
background, so that convenient and simple-to-use process modelling
notations are required to communicate about business processes with these
stakeholders.
• Process Designer: Process designers are responsible for modelling business
processes by communicating with business domain experts and other
stakeholders. Very good analytical capabilities and excellent communication
skills are important for a process designer.
• Process Participant: Process participants conduct the actual operational
work during the enactment of business process instances. They also play
an important role during business process modelling, because they are
knowledgeable about the activities conducted and their interrelationships
with activities conducted by other process participants. It is the task of
the process designer to assemble from this information a consistent overall
view and capture it as a business process model.
• Knowledge Worker: Knowledge workers are process participants who use
software systems to perform activities in a business process. Knowledge
workers are equipped with detailed knowledge of the application domain,
and they can perform activities, or even parts of business processes, autonomously.
• Process Responsible: Each business process model is assigned an individual
who is responsible for the correct and efficient execution of all business
processes using this model. He or she is responsible for detecting inefficiencies
in the process and for improving it, in close collaboration with the
process participants and the process designers.
• System Architect: System architects are responsible for developing and
configuring business process management systems so that the configured
business process management system enacts the business processes in the
context of the information systems infrastructure at hand.
• Developers: Developers are information technology professionals who create
software artefacts required to implement business processes. The implementation
of interfaces to existing software systems is an important
area of work for developers.
These different types of stakeholders need to cooperate closely in designing
business processes and in developing adequate solutions for enacting them.

Business Process Management (Part-1 Foundation[Chapter I Introduction] ) Sec C -- By Mathias Weske

Business Process Lifecycle
The goal of this section is providing an overall understanding of the concepts
and technologies that are relevant in business process management, using a
business process lifecycle. This lifecycle is also useful for scoping the contents
of this book.
The business process lifecycle is shown in Figure 1.5; it consists of phases
that are related to each other. The phases are organized in a cyclical structure,
showing their logical dependencies. These dependencies do not imply a strict
temporal ordering in which the phases need to be executed. Many design
and development activities are conducted during each of these phases, and
incremental and evolutionary approaches involving concurrent activities in
multiple phases are not uncommon.
Chapter 8 extends this lifecycle by proposing a methodology for the development
of business process applications.

Design and Analysis

The business process lifecycle is entered in the Design and Analysis phase, in
which surveys on the business processes and their organizational and technical
environment are conducted. Based on these surveys, business processes are
identified, reviewed, validated, and represented by business process models.
Explicit business process models expressed in a graphical notation facilitate
communication about these processes, so that different stakeholders can
communicate efficiently, and refine and improve them. Chapter 4 investigates
languages to express business process models.
Business process modelling techniques as well as validation, simulation,
and verification techniques are used during this phase. Business process modelling
is the core technical subphase during process design. Based on the survey
and the findings of the business process improvement activities, the informal
business process description is formalized using a particular business process
modelling notation.
Once an initial design of a business process is developed, it needs to be
validated. A useful instrument to validate a business process is a workshop,
during which the persons involved discuss the process. The participants of the
workshop will check whether all 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 behaviour. 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. The design and analysis of
interacting business processes is subject of Chapter 5.
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. Chapter 6 investigates the verification of business process models
with respect to correctness properties.

Configuration
Once the business process model is designed and verified, the business process
needs to be implemented. There are different ways to do so. It can be implemented
by a set of policies and procedures that the employees of the enterprise
need to comply with. In this case, a business process can be realized without
any support by a dedicated business process management system.
In case a dedicated software system is used to realize the business process,
an implementation platform is chosen during the configuration phase. The
business process model is enhanced with technical information that facilitates
the enactment of the process by the business process management system.
The system needs to be configured according to the organizational environment
of the enterprise and the business processes whose enactment it
should control. This configuration includes the interactions of the employees
with the system as well as the integration of the existing software systems
with the business process management system.
The latter is important, since in today’s business organizations, most business
processes are supported by existing software systems. Depending on the
information technology infrastructure, the process configuration phase might
also include implementation work, for instance, attaching legacy software systems
to the business process management system.
The configuration of a business process management system might also
involve transactional aspects. Transactions are a well-known concept from
database technology, where a transaction manager guarantees that application
programs run as transactions and obey the ACID principle: atomicitiy,
consistency, isolation, and durability. This means that transactions are executed
in an atomic all-or-nothing fashion, they transfer a consistent database
state into another consistent database state, they do not interfere with other
transactions, and transaction results are durable and survive future system
failures.
While in business process management database applications with transactional
properties play an important role to realize process activities, transactional
properties can also be defined at the business process level; a subset
of the process activities form one business transaction, so that either all ac tivities in this set are performed successfully or none is executed, realizing the
atomicity property.
Unfortunately, the techniques that guarantee transactional behaviour in
database systems cannot be used for business process transactions, since they
are based on preventing access to data objects by locking, and locking data
objects during process instances is no valid option. Business transactions are
currently at the research stage; therefore, this book does not investigate them
further.
Once the system is configured, the implementation of the business process
needs to be tested. Traditional testing techniques from the software engineering
area are used at the level of process activities to check, for instance,
whether a software system exposes the expected behaviour.
At the process level, integration and performance tests are important for
detecting potential run time problems during the configuration phase. Once
the test subphase is complete, the system is deployed in its target environment.
Depending on the particular setting, additional activities might be required,
for instance, training of personnel and migration of application data to the
new realization platform.

Business Process Management (Part-1 Foundation[Chapter I Introduction] ) Sec B -- By Mathias Weske

The ordering process shown can be used as a blueprint that allows the
reseller company to organize its work. The company will receive many orders,
each of which can be processed as described in the blueprint. This observation
gives rise to important concepts in business process management: business
process models and business process instances.
The blueprint shown in Figure 1.1 is the business process model. Each
order that is processed according to this model is a business process instance.
Therefore, there is a one-to-many relationship between business process models
and business process instances. Conceptual models of business process
models and instances will be the subject of Chapter 3.
Definition 1.4 A business process model consists of a set of activity models
and execution constraints between them. A business process instance represents
a concrete case in the operational business of a company, consisting of
activity instances. Each business process model acts as a blueprint for a set
of business process instances, and each activity model acts as a blueprint for
a set of activity instances. 
If no confusion is possible, the term business process is used to refer to
either business process models or business process instances. Analogously,
activity is used to refer to either activity models or activity instances.
Business process models are the main artefacts for implementing business
processes. This implementation can be done by organizational rules and policies,
but it can also be done by a software system, using a business process
management system. In this case, according to Definition 1.3, the software
system is driven by explicit process representations.
The business process model shown in Figure 1.1 can be used to configure
the business process management system accordingly. The resulting system
makes sure that all business process instances are executed as specified in the
business process model and that, for instance, after receiving an order, the
Send Invoice and the Ship Product activities are executed concurrently.
Since business processes are performed in a single organization by definition,
the ordering of activities can be controlled by a business process
management system as a centralized software component run by the reseller
company. This centralized control is very similar to a conductor who centrally
controls the musicians in an orchestra; therefore, business processes are also called process orchestrations. Chapter 4 will investigate languages to express
process orchestration.
The business process model shown in Figure 1.1 represents activities that a
reseller performs to process an incoming order. This business process interacts
with the business process of a corresponding buyer. The buyer sends an order,
receives payment information, settles the invoice, and receives the ordered products.
The business process of the buyer is shown in Figure 1.2. It starts with its
placing an order, before two concurrent branches are opened. In one branch,
the invoice is received and the invoice is settled. In the other branch, the
product is received. When both branches complete, the business process of
the buyer completes.
Definition 1.1 indicates that each business process is enacted by one organization,
and that business processes can interact with each other. The business
processes of the reseller and the buyer can, for instance, interact with each
other in the following way.
1. The buyer sends an order message to the reseller (Place Order activity).
2. The reseller accepts the order message in the Receive Order activity. The
order information is then extracted from the message, and order processing
continues.
3. The reseller sends an invoice (Send Invoice) and ships the ordered products
(Ship Products).
4. The buyer receives the invoice in the Receive Invoice activity.
5. The buyer sends the payment in the Settle Invoice activity.
6. Finally, the buyer receives the ordered products in the Receive Products
activity.
The interacting business processes are shown in Figure 1.3. Interacting activities
of the reseller business process and the buyer business process are related
to each other by dotted arcs, representing the flow of messages. Message flow
can represent electronic messages sent, but also the transport of physical objects,
such as ordered products.
The interactions of a set of business processes are specified in a process
choreography. The term choreography indicates the absence of a central agent that controls the activities in the business processes involved. The interaction
is only achieved by sending and receiving messages. In order to realize correct
interactions, the interacting business processes need to agree on a common
choreography before they start interacting.
This situation is similar to dancers who need to agree on a common choreography
before the show starts. During the performance, however, each dancer
behaves autonomously but in line with his or her part in the choreography.
Process choreographies will be discussed in detail in Chapter 5.
The representation of the business process choreography is shown in Figure
1.3; it also represents start events and end events of the interacting business
processes, marked by circles.
This process choreography allows for multiple concrete implementations,
in which the degree of software support can differ. Traditional ways of ordering
goods that are not supported by information systems are well captured by this
business process interaction. A buyer browses a paper catalogue of a reseller,
selects a set of products, fills a postcard with ordering information, and sends
the postcard to the reseller.
This postcard effectively implements the message flow from the buyer to
the reseller. On receiving the postcard, the reseller sends the products and
the invoice. The buyer receives the products and, assuming everything is fine,
settles the received invoice, for instance, by money transfer. Once the money
arrives at the reseller, the interacting business processes complete.
Pressing the submit button submits the order, i.e., it realizes the message
flow from the buyer to the reseller. The message flow from buyer to reseller
is no longer implemented by surface mail, but by Internet protocols. The
buyer’s Web browser sends a message to the reseller’s Web server, which calls
a software module that places the order in the reseller’s ordering system.
In case intangible goods have been ordered, such as music or software,
sending the products can also be realized by software systems. The same
applies for invoicing and billing, where online billing services can be integrated into the business process.
Graphical representations of business processes, as shown in the examples, focus on the process structure and the interactions of the participating parties rather than on technical aspects of their realization. This is an important aspect in business process modelling, since the definition of business processes and their interaction behaviour does not prescribe certain implementation
strategies or platforms.

Business Process Management (Part-1 Foundation[Chapter I Introduction] ) Sec A -- By Mathias Weske

Business process management has received considerable attention recently by
both business administration and computer science communities.
Members of these communities are typically characterized by different educational
backgrounds and interests. People in business administration are
interested in improving the operations of companies. Increasing customer satisfaction,
reducing cost of doing business, and establishing new products and
services at low cost are important aspects of business process management
from a business administration point of view.
Two communities in computer science are interested in business processes.
Researchers with a background in formal methods investigate structural properties
of processes. Since these properties can only be shown using abstractions
of real-world business processes, process activities are typically reduced
to letters. Using this abstraction, interesting observations on structural properties
of business processes can be made, which are very useful for detecting
structural deficiencies in real-world business processes.
The software community is interested in providing robust and scalable
software systems. Since business processes are realized in complex information
technology landscapes, the integration of existing information systems is an
important basis for the technical realization of business processes.
The goal of this book is to narrow the gap between these different points of
view and to provide a step towards a common understanding of the concepts
and technologies in business process management.
The introductory chapter looks at the motivation for business process management
from a high-level point of view. The background of business process
management is explained, and major concepts and terms are introduced. An
example featuring an ordering process is used to illustrate these concepts. The
phases in setting up and maintaining business process management applications
are discussed. A classification of business processes and an overview on
the structure of this book complete this chapter.

Motivation and Definitions

Business process management is based on the observation that each product
that a company provides to the market is the outcome of a number of activities
performed. Business processes are the key instrument to organizing these
activities and to improving the understanding of their interrelationships.
Information technology in general and information systems in particular
deserve an important role in business process management, because more and
more activities that a company performs are supported by information systems.
Business process activities can be performed by the company’s employees
manually or by the help of information systems. There are also business
process activities that can be enacted automatically by information systems,
without any human involvement.
A company can reach its business goals in an efficient and effective manner
only if people and other enterprise resources, such as information systems, play
together well. Business processes are an important concept to facilitating this
effective collaboration.
In many companies there is a gap between organizational business aspects
and the information technology that is in place. Narrowing this gap between
organization and technology is important, because in today’s dynamic markets,
companies are constantly forced to provide better and more specific
products to their customers. Products that are successful today might not be
successful tomorrow. If a competitor provides a cheaper, better designed, or
more conveniently usable product, the market share of the first product will
most likely diminish.
Internet-based communication facilities spread news of new products at
lightning speed, so traditional product cycles are not suitable for coping with
today’s dynamic markets. The abilities to create a new product and to bring
it to the market rapidly, and to adapt an existing product at low cost have
become competitive advantages of successful companies.
While at an organizational level, business processes are essential to understanding
how companies operate, business processes also play an important
role in the design and realization of flexible information systems. These information
systems provide the technical basis for the rapid creation of new
functionality that realizes new products and for adapting existing functionality
to cater to new market requirements.
Business process management is influenced by concepts and technologies
from different areas of business administration and computer science. Based
on early work in organization and management, business process management
has its roots in the process orientation trend of the 1990s, where a new way
of organizing companies on the basis of business processes was proposed.
In their seminal book Reengineering the Corporation, Michael Hammer
and James Champy advocate the radical redesign of the business processes
of a company. They define a business process as a collection of activities that take one or more kinds of input and create an output that is of value to the
customer.
While it has been argued that a radical redesign of business processes is,
in many cases, not the best choice and that evolutionary improvements are
more promising, the business process definition by Hammer and Champy is a
good starting point for our investigations.
This definition puts emphasis on the input/output behaviour of a business
process by stating its precondition (inputs) and its postcondition (output).
The process itself is described in an abstract way by a collection of activities.
Assuming that the term “collection” neither implies an ordering of the
activities nor any other execution constraints, the definition by Hammer and
Champy is quite liberal with regard to the process aspect.
Execution constraints between activities are identified by Davenport, who
defines a business process as ”a set of logically related tasks performed to
achieve a defined business outcome for a particular customer or market.”
The term “logically related” puts emphasis on the process activities, while
associating the outcome of a business process with a requestor of a product,
i.e., a customer. Davenport also considers the relationship of process activities,
including their execution ordering, by defining a business process as “a specific
ordering of work activities across time and place, with a beginning, an end, and
clearly identified inputs and outputs.” He continues, “business processes have
customers (internal or external) and they cross organizational boundaries, i.e.,
they occur across or between organizational subunits.”
Based on these characterizations of business processes, we adopt the following
definition.
Definition 1.1
A business process consists of a set of activities that are performed
in coordination in an organizational and technical environment. These
activities jointly realize a business goal. Each business process is enacted by
a single organization, but it may interact with business processes performed
by other organizations. 
After a first consideration of business processes, their constituents, and their
interactions, the view is broadened. Business process management not only
covers the representation of business processes, but also additional activities.
Definition 1.2
Business process management includes concepts, methods,
and techniques to support the design, administration, configuration, enactment,
and analysis of business processes. 
The basis of business process management is the explicit representation of
business processes with their activities and the execution constraints between
them. Once business processes are defined, they can be subject to analysis,
improvement, and enactment.
Traditionally, business processes are enacted manually, guided by the
knowledge of the company’s personnel and assisted by the organizational regulations
and procedures that are installed.
Enterprises can achieve additional benefits if they use software systems
for coordinating the activities involved in business processes. These software
systems are called business process management systems.
Definition 1.3 A business process management system is a generic software
system that is driven by explicit process representations to coordinate the
enactment of business processes. 
The definitions introduced so far are illustrated by a sample business process.
Because of its clarity and limited complexity, a simple ordering process is
well suited. In the ordering process, an order is received, an invoice is sent,
payment is received, and the ordered products are shipped.
This textual representation lists the activities of the business process, but
it does not make explicit the ordering according to which these activities
are performed. Graphical notations are well suited to expressing orderings
between activities of a business process.
The ordering process of a reseller company is shown in Figure 1.1. The
process consists of a set of activities performed in a coordinated manner.
The coordination between the activities is achieved by an explicit process
representation using execution constraints. The process starts with the company
receiving an order, followed by activities in concurrent branches. In one
branch, the invoice is sent and the payment is received; in the other branch,
the products are shipped. When both branches complete their activities, the
order is archived, and the business process terminates.
When the business process terminates, the reseller has processed an incoming
order, including shipping the product and receiving the payment, which
realizes a business goal of the reseller.
While there are several graphical notations for business process modelling,
their essence is quite similar. This introductory chapter uses a simplified variant
of the Business Process Modeling Notation. In this notation, activities
are represented by rounded rectangles, marked with the name of the activity.
Execution ordering of activities is expressed by directed arrows.
Branching and joining of nodes is represented by diamonds that can be
marked with different symbols. In the sample process shown in Figure 1.1, a
diamond with a plus sign, a single incoming arc, and multiple outgoing arcs
represents a parallel split, which means that the follow-up activities can be
executed concurrently. Concurrent activities can be executed in any order,
and any overlap in the execution time of concurrent activities is allowed.
The same symbol with multiple incoming arcs and a single outgoing arc is
the respective join node, merging the concurrent branches. In the example, this
join node makes sure that the archiving of the order can only be started once
both concurrent branches have completed.