Business processes can diverge in the level of automation. There are business
processes that are fully automated, meaning that no human is involved in the
enactment of such a business process. An example is ordering an airline ticket
using Web interfaces. While the process is fully automated on the side of
the airline, the customer is involved with manual activities, such as providing
address information via Web browser interfaces.
Enterprise application integration is another area where automated business
processes can be found. The goal is to integrate the functionality provided
by a heterogeneous software landscape. While there are different techniques to
integrate enterprise applications, process technology is an important technology,
especially since the emergence of service-oriented software architectures
that allow composing services to processes.
Many business processes require manual activities; but they also include
automated activities. Processing an insurance claim is an example of such a
process. Manual activities enter the customer data and determine the settlement
of the damage, while automated activities are used to store data on the
damage in the software systems of the company.
The interaction with the human user is essential in these settings. Early
approaches that prescribe to human users �what to do next� often failed.
User interfaces that accept the knowledge worker as an important source to
improve and control the process provide more user acceptance.
Saturday, August 1, 2009
Organizational versus Operational:
Different levels can be identified in business process management, ranging
from high-level business strategies to implemented business processes. These
levels are depicted in Figure 1.6. At the highest level, the strategy of the
company is specified, which describes its long-term concepts to develop a
sustainable competitive advantage in the market. An example of a business
strategy is cost leadership for products in a certain domain.
At the second level, the business strategy is broken down to operational
goals. These goals can be organized, so that each goal can be divided into a
set of subgoals. Reducing the cost for supplied materials is a sample goal that
contributes to the realization of the business strategy mentioned.
At the third level, organizational business processes can be found. Organizational
business processes are high-level processes that are typically specified
in textual form by their inputs, their outputs, their expected results, and
their dependencies on other organizational business processes. These business
processes act as supplier or consumer processes. An organizational business
process to manage incoming raw materials provided by a set of suppliers is
an example of an organizational business process.
Informal and semiformal techniques are used at these high levels. The
strategy of a company, its goals, and its organizational business processes
can be described in plain text, enriched with diagrams expressed in an adhoc
or semiformal notation. A forms-based approach to express organizational
business processes is discussed in the next chapter.
While organizational business processes characterize coarse-grained business
functionality, typically there are multiple operational business processes
required that contribute to one organizational business process. In operational
business processes, the activities and their relationships are specified, but
implementation aspects of the business process are disregarded. Operational
business processes are specified by business process models.
Operational business processes are the basis for developing implemented
business processes. Implemented business processes contain information on
the execution of the process activities and the technical and organizational
environment in which they will be executed.
from high-level business strategies to implemented business processes. These
levels are depicted in Figure 1.6. At the highest level, the strategy of the
company is specified, which describes its long-term concepts to develop a
sustainable competitive advantage in the market. An example of a business
strategy is cost leadership for products in a certain domain.
At the second level, the business strategy is broken down to operational
goals. These goals can be organized, so that each goal can be divided into a
set of subgoals. Reducing the cost for supplied materials is a sample goal that
contributes to the realization of the business strategy mentioned.
At the third level, organizational business processes can be found. Organizational
business processes are high-level processes that are typically specified
in textual form by their inputs, their outputs, their expected results, and
their dependencies on other organizational business processes. These business
processes act as supplier or consumer processes. An organizational business
process to manage incoming raw materials provided by a set of suppliers is
an example of an organizational business process.
Informal and semiformal techniques are used at these high levels. The
strategy of a company, its goals, and its organizational business processes
can be described in plain text, enriched with diagrams expressed in an adhoc
or semiformal notation. A forms-based approach to express organizational
business processes is discussed in the next chapter.
While organizational business processes characterize coarse-grained business
functionality, typically there are multiple operational business processes
required that contribute to one organizational business process. In operational
business processes, the activities and their relationships are specified, but
implementation aspects of the business process are disregarded. Operational
business processes are specified by business process models.
Operational business processes are the basis for developing implemented
business processes. Implemented business processes contain information on
the execution of the process activities and the technical and organizational
environment in which they will be executed.
Intraorganizational Processes versus Process Choreographies
If there is no interaction with business processes performed by other
parties, then the business process is called intraorganizational. Most business
processes, however, interact with business processes in other organizations,
forming process choreographies. The ordering process choreography discussed
earlier in this chapter is an example of interacting business processes.
The primary focus of intraorganizational business processes is the streamlining
of the internal processes by eliminating activities that do not provide
value. The personnel of the enterprise is represented in organizational models
used to allocate activities to persons who are skilled and competent to perform
these activities. Traditional workflow management systems can be used
to support intraorganizational business processes.
There are a number of issues to address when dealing with interacting
business processes, including not only communication aspects related to the
process structures, but also legal matters. Interactions between business processes
need to be protected by legally binding contracts between the companies
involved.
Also, the technical layer requires more thought, since multiple organizations
have most likely a heterogeneous software infrastructure that hampers
interoperability in the software layer.
parties, then the business process is called intraorganizational. Most business
processes, however, interact with business processes in other organizations,
forming process choreographies. The ordering process choreography discussed
earlier in this chapter is an example of interacting business processes.
The primary focus of intraorganizational business processes is the streamlining
of the internal processes by eliminating activities that do not provide
value. The personnel of the enterprise is represented in organizational models
used to allocate activities to persons who are skilled and competent to perform
these activities. Traditional workflow management systems can be used
to support intraorganizational business processes.
There are a number of issues to address when dealing with interacting
business processes, including not only communication aspects related to the
process structures, but also legal matters. Interactions between business processes
need to be protected by legally binding contracts between the companies
involved.
Also, the technical layer requires more thought, since multiple organizations
have most likely a heterogeneous software infrastructure that hampers
interoperability in the software layer.
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.
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.
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.
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.
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.Business process modelling has an evolutionary
character in the sense thatthe process model is analyzed and improved
so that it actually represents thedesired business process and that it
does not contain any undesired properties.
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.
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.Business process modelling has an evolutionary
character in the sense thatthe process model is analyzed and improved
so that it actually represents thedesired business process and that it
does not contain any undesired 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
activities in this set are performed successfully or none is executed, realizing the
atomicity property.Unfortunately, the techniques that guarantee transactional
behaviour indatabase 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.
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.
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
activities in this set are performed successfully or none is executed, realizing the
atomicity property.Unfortunately, the techniques that guarantee transactional
behaviour indatabase 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.
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.
Subscribe to:
Posts (Atom)