Monday, July 13, 2009

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

Classification of Business Processes

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.
As discussed earlier in this chapter, there are multiple ways to implement
business processes, ranging from written procedures and policies of the organization
to the use of process enactment platforms. In any case, implemented
business process refers to a specification that allows the enactment of the
process on a given platform, be it organizational or technical.

Intraorganizational Processes versus Process Choreographies

As defined above, each business process is performed by a single organization.
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.

Degree of Automation

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.

Degree of Repetition

Business processes can be classified according to their degree of repetition.
Examples of highly repetitive business processes include business processes
without human involvement, such as online airline ticketing. However, business
processes in which humans are involved can occur frequently, for example,
insurance claim processing. If the degree of repetition is high, then investments in modelling and supporting the automatic enactment of these processes pay
off, because many process instances can benefit from these investments.
At the other end of the repetition continuum, there are business processes
that occur a few times only. Examples include large engineering efforts, such
as designing a vessel. For these processes it is questionable whether the effort
introduced by process modelling does in fact pay off, because the cost of
process modelling per process instance is very high.
Since improving the collaboration between the persons involved is at the
centre of attention, these processes are called collaborative business processes.
In collaborative business processes, the goal of process modelling and enactment
is not only efficiency, but also tracing exactly what has actually been
done and which causal relationships between project tasks have occurred.
This aspect is also present in the management of scientific experiments,
where data lineage is an important goal of process support. Since each experiment
consists of a set of activities, an increasing fraction of the experimentation
is performed by analyzing data using software systems. The data
is transformed in a series of steps. Since experiments need to be repeatable,
it is essential that the relationship of the data sets be documented properly.
Business processes with a low degree of repetition are often not fully automated
and have a collaborative character, so that the effort in providing
automated solutions is not required, which lowers the cost.

Degree of Structuring

If the business process model prescribes the activities and their execution
constraints in a complete fashion, then the process is structured. The different
options for decisions that will be made during the enactment of the process
have been defined at design time. For instance, a credit request process might
use a threshold amount to decide whether a simple or a complex credit check
is required, for instance, 5000 euros. Each process instance then uses the
requested amount to decide on the branch to take.
Leymann and Roller have organized business processes according to dimensions
structure and repetition. They coined the term production workflow.
Production workflows are well structured and highly repetitive. Traditional
workflow management system functionality is well suited to supporting production
workflows.
If process participants who have the experience and competence to decide
on their working procedures perform business process activities, structured
processes are more of an obstacle than an asset. Skipping certain process activities
the knowledge worker does not require or executing steps concurrently
that are ordered sequentially in the process model is not possible in structured
business processes.
To better support knowledge workers, business process models can define
processes in a less rigid manner, so that activities can be executed in any order
or even multiple times until the knowledge worker decides that the goals of these activities have been reached. So called ad hoc activities are an important
concept for supporting unstructured parts of processes.
Case handling is an approach that supports knowledge workers performing
business processes with a low level of structuring and, consequently, a high
level of flexibility. Rather than prescribing control flow constraints between
process activities, fine-grained data dependencies are used to control the enactment
of the business process.

No comments:

Post a Comment