Aligning People to Business Processes
Experience Report
Tomas Andersson, Ilia Bider, Rogier Svensson
IbisSoft AB, Box 19567, SE 10432 Stockholm, Sweden
{tomas|ilia|rogier}@ibissoft.se
Abstract. Business process orientation requires some kind of a business processes
support system. However, building a proper system is not enough for introducing
process orientation, the organization should ensure that the system is routinely used
by all people involved in the processes. The latter task may be more complicated
than the one of building the system. This paper summarizes an experience of
building business process support systems and introducing them into operational
practice acquired over some period of time. The paper describes and explains
difficulties of marketing such systems and introducing them into the operational
practice, as well as shows examples of how these difficulties could be overcome.
In conclusion, it suggests an approach to introducing business process orientation,
called a “reverse” evolutionary approach, that is suitable for some business
contexts.
1. Introduction: basic assumptions and structure of the paper
This paper represents an experience report from a small consulting company that
considers its mission as promoting business process orientation. The material is written
having practitioners in mind. The number of references was intentionally kept to the
minimum to make the paper easier to read for the intended audience. Despite the
practical orientation of the paper, some parts of it might be also of interest for the
researchers as a raw material to support/disprove certain theories, or serve as an impulse
for creating new ones.
In the paper, we assume that a process-oriented organization of work is better than the
traditional functional or project-oriented organization; for argumentation on this topic
see classical publications, e.g., [Hammer & Champy, 1994]. Under process orientation,
we understand not the way of “thinking process oriented”, but the way of “working
process oriented” [Bider, 2005]. The latter includes genuine cooperation between all
process’s participants independently of to which department they belong, and whether a
particular process instance follows the standard pattern, or deviates from it. It also
means motivated involvement of process participants who understand their own roles in
the process and the roles of others (including the management). Business process
orientation as a way of working also means that the experience gathered from
previously completed processes is directly used in operational practice.
2
Business process-orientation (as a way of working) is difficult (if ever possible) to
achieve without a specially constructed Business Process Support (BPS) system. Such
system among other things should:
• Give to each process participant easy access to the state of the affairs in any particular
process instance. This includes information on what has been achieved so far (process
state), how it has been achieved (process history), and what is going to be done in the
nearest future (process plan).
• Give to each process participant easy access to all process instance he/she is
participating, including information on what he/she is supposed to do in the frame of
each process instance and when.
• Provide participants with effective communication channels along the process
instance lines.
• Provide easy accesses to the organization’s experience, e.g., already finished
processes, so that it can be analyzed, and participants can learn by example.
Naturally, a BPS system should also help processes participants to complete activities
within the frame of each process instance. This function of a BPS system is the same as
in traditional business applications, while the above listed properties are specific for
BPS systems.
Due to its specific functionality, a BPS system is often regarded not just as a system
that automates part of human operations, but also as a tool of organizational change.
Introduction of such a system in operational practice should be considered as part of the
task of creating the fit between business processes and support system. This part
consists of adjusting the people to business processes by making them routinely use the
support system in all every day operations. This task is not a trivial one, because,
usually, most of the workers have no practical (and/or theoretical) experience of
working in the process-oriented way.
This paper describes our experience in building and introducing BPS systems in
operational practice, with all its setbacks and achievements. The experience is divided
in 2 periods, the early period from 1989 to 1992, and the later one from 1998 up to now.
We did not work much with BPS systems in between these two periods. The discussions
are focused mostly on the introduction of BPS systems into operational practice; the
issues related to the technical development can be found in other works that we refer to
in the main text.
The paper is structured in the following way. In Section 2, we give a brief description
of the state-oriented view on business processes that was and still is used in our BPS
systems, and describe the main ideas behind the system architecture. Section 3 describes
our early experience in building and marketing BPS systems. Section 4 presents the
experience of the period from1998 to Spring 2004, while Section 5 presents our latest
strategy that is in place at the moment of the writing. Section 6 contains concluding
remarks that suggest a “reverse” evolutionally approach to building and introducing
BPS systems. “Reverse” means that the goal of evolution is not to develop a system that
satisfy the customers needs, but rather to “develop” people so that they could fully
exploit the possibilities built in the BPS system architecture.
3
2. State oriented view on business processes
The BPS systems that we discuss in the paper were built based on the state-oriented
view on business processes as described in [Khomyakov & Bider, 2000, Bider 2002].
This view focuses on changes produced by activities executed in the frame of a given
process instance over its lifespan. The main concept of the state-oriented view is the
process’s state. The process’s state is aimed to show how much has been done to
achieve the operational goal of the process instance and how much is still to be done.
The state does not show what activities have been executed to reach it; it only shows the
results achieved so far.
A state of a business process is defined by a “construct” that reflects the relevant part
of the “business world” at a given moment of time. The internal structure of the state
construct depends on the business process type to which the current instance belongs.
An example, of such structure for a business process related to a customer order is
represented on Fig. 1. The state structure includes: (a) attributes (variables), like To pay,
Paid, Ordered, etc., and (b) references to various human and non-human participants of
the process, like customer, product, etc.
A goal of a business process can be defined as a set of conditions that have to be
fulfilled before a process instance can be considered as finished (end of the process
instance trajectory in the space state). A state that satisfies these conditions is called a
final state of the process. The set of final states for the process in Fig. 1 can be defined
as follows: (a) for each ordered item Ordered = Delivered; (b) To pay = Total + Freight
+ Tax; (c) Invoiced = To pay; (d) Paid = Invoiced. These conditions define a “surface”
in the state space of this process type.
The process is driven forward through activities executed either automatically or with
a human assistance. Activities can be planned first and executed later. A planned
activity records such information as type of action (goods shipment, compiling a
program, sending a letter), planned date and time, deadline, name of a person
responsible for an action, etc.
The process’s state is used as a primary tool in deciding on what should be done to
reach the process’s goal from the current state. However, in some cases, a history of the
process’s evolution in time is important when deciding on actions. The history is
defined as a time-ordered sequence of all previous states.
All activities planned and executed in the frame of the process should be aimed
diminishes the distance between the current state of the process instance and the nearest
final state. The meaning of the term distance depends on the business process in
question. Here, we use this term informally. For example, activities to plan for the
process in Fig.1 can be defined in the following manner:
• If for some item Ordered > Delivered, shipment should be performed, or
• If To pay > Invoiced, an invoice should be sent, etc.
4
Figure1. State representation of order processing.
All activities currently planned for a process instance make up the process plan. The
plan together with the “passive” state (attributes and references) constitute a so-called
generalized state of the process, the plan being an “active” part of it (engine). The
process plan on Fig. 2 corresponds to the process instance state shown on Fig. 1.
When an activity is executed, a process changes its generalized state. Changes may
concern the passive and/or active parts of the state. At the minimum, the executed
activity disappears from the plan. In addition, changes are introduced in attributes and
references and/or new activities are planned to drive the process forward.
Figure 2. Process’s plan that complements the state from Fig. 1.
When an activity is executed in the frame of a process instance, an event is registered. A
registered event is a record that links the change in the state of a process to the reality
outside the process. For example, it can record the date-time when the event happened
and/or was registered, name the responsible for the event, register comments on the
event at the moment of registration (or even later), etc. A list of all events that happened
within the frame of a given process constitutes the chronicle of the process, i.e. its
written history.
The heart of a BPS system based on the state-oriented view consists of:
• Historical database that automatically stores information on all events and all past
states of all processes, documents, and other business objects.
• Principle of dynamic and distributed planning. Dynamic means planning when
needed, distributed means planning to each other. Planning for each other constitute a
communication channel between process participants along business process
instances. Planning can be partly manual, partly automatic.
5
• Navigational system that allows the end user to freely navigate through the space of
interconnected processes in the present and past.
When using a state-oriented BPS system, executing of an activity in the frame of a
process instance conceptually consists of (at maximum) three steps: (1) introduce
changes in the process state, (2) plan new activities, (3) register an event of current
execution.
3. First period
Our first experience of dealing with BPS systems goes back to 1989-1990, when we
built a system to support sales and marketing activities of a trading company [Bider,
1997]. The system was called DealDriver to highlight that it helped the workers to
"drive" their deals from the beginning (e.g., getting an order) to the end (e.g., receiving
payment). The order processing process had automatic planning programmed in it;
Fig.1,2 represent screen snapshots from this part of DealDriver. Sales and marketing
activities were planned manually. The system was developed for the character-based
environment and run under DOS over a PC LAN.
This system has been used internally at IbisSoft for 13 years. The main advantage of
the system for us was that it gave full control over all communication with the external
world in the past and future (plans). First, the system was used only by the people who
developed it, but later, new sales persons were trained to use the system. We
encountered no serious problems in teaching new people how to work with the system.
The efforts of marketing our BPS ideas at that period were not successful. In our
view, the main reasons for that were as follows:
• Our inexperience in sales and marketing in general.
• Low readiness of the market: the ideas of business process orientation were unknown
to the majority of companies, and, definitely, BP was not a buzzword.
• Wrong focus of marketing and sales. The system was marketed as a system not as
new way of working. As a result, marketing efforts were wasted on IT personnel who
could not see what was special with the system in comparison to all other systems in
the given application domain.
Still, our efforts lead to getting commissions for building a couple of prototypes based
on our ideas, but the recession of early nineties forced us to abandon the BPS business
activity for some time.
In parallel, our colleagues in Moscow built another BPS system based on the
DealDriver ideas and its source code. The system, called SoftMotors, fully supported
business processes at a car service station (service and repair). The system had all
features incorporated in DealDriver but one, it had no planning component (neither
automatic, nor manual). Communication between process participants was along
changes in the states of process instances. When urgent attention was required, non-
computer means were used, like banging on the wall that separated the neighboring
department.
