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.