=Paper=
{{Paper
|id=Vol-109/paper-5
|storemode=property
|title=Goal-Oriented Patterns for Business Processes
|pdfUrl=https://ceur-ws.org/Vol-109/paper3.pdf
|volume=Vol-109
|dblpUrl=https://dblp.org/rec/conf/gbpm/BiderJP02
}}
==Goal-Oriented Patterns for Business Processes==
https://ceur-ws.org/Vol-109/paper3.pdf
Goal-Oriented Patterns for Business Processes
Goal-Oriented Patterns for Business Processes
Position paper for GBPM’02
(For full version see http://www.ibissoft.se/English/Patterns.pdf)
Ilia Bider: IbisSoft AB, Stockholm, Sweden,
ilia@ibissoft.se
Paul Johannesson, Erik Perjons: Department of Computer and Systems Sciences
Stockholm University/Royal Institute of Technology, Stockholm, Sweden,
{pajo, perjons}@dsv.su.se
Abstract: Organizations of today are becoming ever more focused on their business
processes. This has resulted in an increasing interest in business process patterns, which
can be used in order to understand where from one can adopt best practices, or how to
build computer systems supporting business processes. However, to fully exploit
patterns, they need to be defined in a structured, and even formal way. This paper
proposes to explore the state-oriented approach for defining and formalizing patterns
based on the notion of goal rather than the sequence of events/activities.
1. Motivation
Most of the research and practice connected to business processes has one aim: to make
business processes more cost-effective, which means reducing costs, time, increasing
quality, etc. One of the proven approaches in this field is reengineering of the processes
by using best practices, which can also include adoption of information systems used in
these best practices.
Borrowing a best practice from another organization cannot be done literally. We always
need to abstract from the details in order to introduce the best practice in a new
environment. What is more, before trying to take over somebody else’s best practice, we
need to be sure that we are borrowing from the process that has the same nature that the
one we want to substitute with the best practice.
Abstracting from enough details to see the similarity of the phenomena that can look
different at the first glance is often referred as to finding a common pattern. Patterns are
used in many application fields from construction to software design. We believe that the
idea of patterns can be useful for business process reengineering, especially for finding an
appropriate best practice.
The most important aspect to consider when looking for a better organized process is
whether the goal of this process is the same as the one we want to substitute. Thus, the
notion of goal is central for defining business-process patterns. In order to fully exploit
patterns, they need to be defined in a structured, and even formal way. Below, we
propose one approach to constructing such definitions.
1
Goal-Oriented Patterns for Business Processes
The rest of the text is structured in the following way. In section 2, we present an
example of informal definition of a generalized process, i.e. pattern. In section 3, we
demonstrate how this pattern can be described formally. In section 4, we give a definition
of business process pattern. In section 5, we compare our approach with those of others.
In section 6, we summarize the results achieved, and draw plans for future research.
2. An example of generalized processes - sales/collection
The idea of generalized description of business processes is not new. For example,
[Denna et. al., 1995] identifies three most important business processes for industrial
organizations: acquisition/payment, conversion, and sales/collection. Each such process
is described in a sequence of activities, called business events in the terminology of
[Denna et. al., 1995]). The events may be defined with more or less level of details. For
example, the “sales/collection” process may be described as:
• Accept customer order
• Select, inspect, and package merchandise
• Ship merchandise
• Receive customer payment
The same process may be described in less details:
• Ship merchandise
• Receive payment
According to [Denna et. al., 1995], the sequence of events may differ from organization
to organization, and from customer to customer. Therefore, the generalized
sales/collection process cannot be defined as a prescribed sequence of events, but rather
as a set of business objectives, i.e. the goal of the business processes. The objectives of
the sales/collection process can be defined as achieving the state of the business world in
which the following two propositions are true:
• The customer has the merchandise he ordered
• The organization received the payment agreed upon with the customer
We believe that such definition can give us a clue of how to define a generalized business
process (i.e., a pattern) in a formal way.
3. Structured representation of the example
To define a generalized process from the previous section in a structured way we use the
state oriented view on business processes from [Khomyakov & Bider, 2000]. According
to the most general definition of a business process, see for example [Hammer et. al.,
1994], a business process is a set of partially ordered activities aimed at reaching a well-
defined goal. The state-oriented view is focused on the changes that each activity
introduces in the part of the world that is relevant to the given process, each change
moving the process closer to the goal.
2
Goal-Oriented Patterns for Business Processes
The state oriented view considers a business process as a trajectory in a multidimensional
state space. An example of a state space constructed for the sales/collection process taken
from our previous work [Khomyakov & Bider., 2000] is presented in Fig. 1. Let us
analyze the most important characteristics of this space. We have two dimensions for
each product being sold: ordered and delivered. The number of such pairs of dimensions
can be considered as variable, or as equal to the size of the company’s assortment.
Denote the product dimensions as X1,…, Xn (ordered) and Y1,…, Yn (delivered).
Additionally we have two dimensions that concern payment; invoiced and paid; denote
them as Zin, and Zpa.
Having introduced the above dimensions, we can represent a sales/collection process as a
point moving in the state space we just defined. The operational goal of this process may
be express as reaching the surface in the state space defined by the equations:
x1 = y1,…, xn = yn, zin = k1x1 + … + knxn, zpa = zin, where k1, …, kn represent prices of the
products ordered.
Fig.1 State space of the sales/collection process from [Khomyakov & Bider, 2001].
After defining the state space and the goal, we can classify the movements along the
various axes. Moving along X-axes normally means the customer changes his order.
Moving along Y-axes forward means delivery. Moving along Y-axes backward means
return. Moving along Zin-axes forward means invoicing. Moving along Zin-axes backward
means crediting. Moving along Zpa-axes forward means receiving payment. Moving
along Zpa-axes backward means paying back (for example after return).
Classification of the movements gives us the possibility to compare activities in different
sales/collection processes independently how they are called and how they are done, and
in what order. We just need to understand in which direction each activity moves the
position of the process in the state space.
3
Goal-Oriented Patterns for Business Processes
4. Pattern definition
Based on the discussion in Section 3, we can define an operational procedure for
comparing business processes. Two business processes are considered as similar if:
1. Their state spaces have a similar topology. It means that there is a mapping m from
one state space into another that possesses some kind of “morphism”. The strong
similarity requires isomorphism, but other types of mappings could be considered as
well.
2. They have similar goals. Goals are defined as surfaces in the state space. Similarity of
goals means that the goal of the second process can be obtained via mapping the goal
of the first process by applying mapping m defined above.
3. They have the same kind of valid movements in the state space towards the goal.
Again, it means that valid movements of the second process can be obtained by
applying mapping m to the valid movements of the first process.
According to our objective to find similarities when comparing different business
processes, we consider patterns as means for defining practically interesting sets of
business processes. We believe that for this end, a pattern can be defined as a triad
P=
complemented with properties of a mapping function m (e.g. isomorphism) that can be
used for comparing the state-space of a particular business process with the one of the
pattern. A business process is considered belonging to pattern P if there is a mapping m
that satisfies the properties defined by the pattern, and maps this process’s state space,
goal and set of valid movements into p-state-state, p-goal, p-movements respectively.
The above definition is more conceptual than formal. To make it formal, we need to
understand what kinds of state spaces can be useful for representing business processes,
and what kind of properties the mapping functions should possess. However, even now,
this definition can be used as a leading thread when comparing the state pictures of the
type represented on Fig.1. We use such pictures in our analysis practice to present a
business process model to non-technical participants of the business process.
5. Related research
There are a number of research works that concern patterns for business process. The one
that is most closed to us is described in [Malone et al., 1999]. A process pattern is defined
as a number of abstract activities of the type discussed in section 2.1. The general pattern
is then specialized (synthesis) by specializing each of the abstract activities and
establishing a particular order in the flow. A large collection of general and specialized
patterns has been built based on this approach, and it is in use for process improvement
purposes (analysis and synthesis).
The approach in [Malone et al., 1999] requires to distinguish some abstract activities
before creating a pattern. In our analysis practice, we often had situations when the nature
of activities was not clear in the beginning, and we needed to start with defining state-
4
Goal-Oriented Patterns for Business Processes
space and goals first. Our valid movements in state space are similar to the abstract
activities from [Malone et al., 1999]. However, they differ from the latter in two respects.
In one respect, our movements are more abstract as they refer only to the changes in the
constructed state-space, not to what happens in the real world. In another respect, they are
more concrete as they are tied to concrete movements in the state space.
6. Conclusion
With this work, we made only the first step to formal definition of goal-oriented patterns
for business processes. The definition is based on the notions of state-space, goal (as a
surface in the state space), and valid movements towards the goal. The suggested
approach allows to abstract from the most of the details, without loosing the essential
nature of a particular business process. We believe that the suggested approach can be
useful for the task of identifying the nature business processes in order to understand
wherefrom one can adopt best practices, or computer support systems.
In this work, we concentrated on patterns for analysis. However, patterns for analysis are
only half-useful if we cannot add to them solutions for synthesis, i.e. (re)engineering.
Synthesis (specialization in terms of [Malone et al., 1999]) from the state-oriented pattern
can be done in two directions:
• Specializing valid movement by adding an operational procedure of what should be
done in the real world to move the process from one state to another. This
corresponds to the external action of activity, discussed in [Andersson et al., 2002].
• Establishing constrains on the permissible trajectories of the process in state space,
i.e. introducing some order in activities. This can be done by rules of dynamic
planning discussed in [Khomyakov & Bider, 2000].
References
[Denna et. al., 1995] Denna, E.L., Perry, L.T, and Jasperson, J. Reengineering and REAL Business Process
Modeling. In: Grover V., and Kettinger, W.J. Business Process change: Concepts, Methods and
Technologies, Idea Group Publishing (1995)
[Hammer et. al., 1994] Hammer, M., and Champy, J., Reengineering the Corporation – A Manifesto for
Business Revolution, Nicholas Brealey Publishing, London (1994).
[Khomyakov & Bider, 2000] Khomyakov, M., and Bider, I. Achieving Workflow Flexibility through
Taming the Chaos. OOIS 2000 - 6th international conference on object oriented information systems,
pp.85-92, Springer (2000)
[Malone et. al., 1999] Malone, T.W., Crowston K., Lee J., Pentland B., Dellarocas C., Wyner G., Quimby
J., Osborn C.S., Bernstein A., Herman G., Klein M., and O´Donnell E.: Towards a handbook of
organisational processes, Management Science 45(3), pp 425-443 (1999)
5