=Paper=
{{Paper
|id=Vol-109/paper-11
|storemode=property
|title=Reportage on Workshop
|pdfUrl=https://ceur-ws.org/Vol-109/reportage.pdf
|volume=Vol-109
|dblpUrl=https://dblp.org/rec/conf/gbpm/Alexander02a
}}
==Reportage on Workshop==
https://ceur-ws.org/Vol-109/reportage.pdf
Workshop on Goal Oriented Business Process
Modeling (GBPM'02)
At HCI 2002, London, 2 September 2002
Reportage by Ian Alexander (iany@easynet.co.uk)
Ilia Bider (IbisSoft, Stockholm) led the 3rd GBPM workshop, in memory of his
late collaborator, friend, and co-founder of the workshop, Dr Maxim Khomyakov.
The first workshop looked at OO and BPM; the second at practical issues of
modelling business processes; and this one focused on Goals - what BPM is all about.
Ian Alexander (Independent Consultant) drew the short straw, speaking first
straight after the holiday season. He spoke about Modelling the Interplay of
Conflicting Goals. A scenario was a sequence of activities to achieve a functional
goal desired by an organization, often modelled nowadays as a Use Case. Hostile
agents could also have goals which may directly or indirectly threaten the
organization's goals; these can be modelled as 'Misuse Cases'. Interactions between
Use and Misuse Cases include MC threatens UC; a subsidiary UC mitigates MC; a
UC unintentionally aggravates an MC (while perhaps mitigating another); two UCs
directly conflict.
Depicting agents - possibly systems or parts of the environment (like the weather)
as UML stickmen was a useful anthropomorphism; it enabled people to reason with
their social brains about agent's goals and how to counter them. The approach led to a
simple way of depicting and agreeing on goals, which was useful in specific areas
such as design trade-offs and the identification of safety and security requirements.
Gil Regev (Ecole Polytechnique de Lausanne) spoke about Regulation-based
Linking of Strategic Goals and Business Processes. The basic approach is
attractively simple: businesses can be considered as control systems intending to
maintain a target value, or as organisms with homeostatic goals (such as keeping body
temperature constant), influenced negatively by the environment. To my mind it was
surprising that neither control nor homeostasis were mentioned; instead, Wiener,
Weinberg, Anton, and Checkland were referenced on aspects of systems. Perhaps
different communities use different but isomorphic languages to describe goal-
oriented behaviour.
Constancy or stability sound static, but can be interpreted dynamically (said Ilia
Bider) by talking about constancy of growth (e.g. having a Strategic Goal to increase
market share). You then get an Operational Goal (e.g. increase sales geographically)
which is related to the strategic goal through a Belief that it will help to achieve it -
through the operation of a business process (e.g. set up sales forces in new areas).
Ilia Bider said both these talks were about the Environment and our
understanding of it - which might be true or not; and we could find out if it were true
by modelling the environment and simply by trying out your model in the world and
seeing if it works. Hence there is feedback to bring our understanding closer to real
life, which is itself a higher-level (regulative, if you like Kant) process applied to
lower-level business process interventions.
Erik Perjons (Stockholm University) (in a paper co-authored with Ilia Bider and
Paul Johanneson) spoke about Goal-Oriented Patterns for Business Processes,
focussing on goals rather than on activities. He described a state-oriented approach to
1
describe business process patterns. Quoting Fowler, a pattern is an idea useful in one
context and hoped to be useful in others. Hammer & Champy define a BP as a
partially-ordered set of activities to reach a goal. Different organisations may have
different sequences, or somewhat different sets of activities, but shared goals and
basically similar processes, so perhaps common patterns can be identified.
Approaches include input/output flow as in IDEF0, workflow sequences of
activities as in UML Activity charts (flowcharts), agent-related workflow as in RAD,
and state-flow looking at changes in the world caused by activities (a bit like IDEF3).
This last is Perjons' favourite. Two BPs are similar if they have state spaces with the
same topology, their goals are similar, and they have the same kind of valid
movements in the state space. For instance, ordering increases the number of ordered
goods (on the Y-axis); delivering increases the delivered goods (on the X-axis). To
meet the goal that Ordered = Delivered, the final state must be on the line X=Y; and
similarly for all other dimensions of the pattern. Goals thus become surfaces, not
points, in the state space!
Ann Lindsay said that BPs were about what you know happens, but we need
instead to learn to adapt, and BP modelling isn't helping people to adapt.
Ilia Bider said that to use patterns to synthesize processes, you needed to
specialize them, adding procedures to move from one state to another, and adding
constraints (e.g. you can't move back in time - you can return goods or deliver more,
but not actually undeliver).
Dick Schaap (University of Groningen) spoke on defining a Goal-Reached,
Energy-Used Value pair as a Business Process Measure. His aim is to describe
rather more scientific ways of improving performance than the rather vague ideas in
the literature such as 'eliminate, simplify, integrate, automate' (Peppard and Rowland).
His idea is to plot Goal Reached on the Y-axis, and Energy Used on the X-axis. If
you have some uncertainty or variation in each, you'll get an elliptical GR/EU blob
instead of a point for each activity. You can use a UML-like swimlanes chart to show
the sequence of activities organized by actor, and then construct a table of goals
reached (presumably one can tell if a goal is 100% reached, or less) and actor-time (a
crude measure of energy) per activity. From a flowchart he ran some simulations to
evaluate GR/EU results, getting a family of curves or lines. He admits that both Goal
Reached and Energy Used can become complicated and unrealistic, so the challenge
is to simplify them sufficiently. With multiple processes you also need to address
issues of scheduling people and other resources to avoid conflicts. The ideal process
clearly uses no energy and no time, i.e. is at the origin of the GR/EU chart.
Gil Regev said that in the 1950's, energy and information were seen to be
different - an autopilot uses very little energy but can control a huge ship or plane.
Dick Schaap said that the GR/EU chart makes visible what is happening in terms of
resources applied and results obtained; you might have reasons (not visible on the
chart) for going for goals quickly but at higher energy cost. Ilia Bider said that some
goals have higher value, e.g. hitting the market first may be business-critical as Ian
Alexander said was the case for developing new Jet Engines for specific aircraft
types. And values might change; Ann Lindsay said the same was true in production -
you might rush to meet a critical order for chocolates even if you wasted materials
and labour. Value would have to be a third axis but Dick Schaap had not worked that
out. Ilia Bider said that for some processes, like selling, it is important to have control
over resources for each process instance; sales leads that require too much resource to
complete the sale should be abandoned. Thus, limitation on resources should be
included in the operational goals for such processes.
2
Ip-Shing Fan (Cranfield University) spoke about a Process Model for Diverse
Stakeholder Goals. BPM projects were limited in various ways, but all aimed to
abstract the organization of activities in an organization. Goals were driven by
strategy, eg. quality, lead time, time to market, delivery reliability, design flexibility,
volume flexibility, cost/price, innovation, and trustworthiness. These are extremely
diverse competitive factors. Organizations differ in the factors they choose, and in
their resulting success. It would be useful to understand the reasons for these
variations.
Fan suggested that the largest cause of difference is people; the interaction of
people with processes is complicated. Three perspectives on this are organization,
people, and technology; these might be useful. But BPM's assumption that there is
one single canonical process that everyone should follow is clearly false; so going
from an As-Is model to a single new To-Be model - in classical BP modelling - is a
limiting approach. People naturally desire variability in their work. Quality manuals
indeed deliberately avoid (mechanism) details, sticking to (vague) business goals.
Workflow is often too prescriptive. Instead, we need controlled diversity - not chaos
but an allowed range of process variation. Fan is therefore working on ways of
generating diverse models offering a choice of possible processes. TRIZ, the so-called
theory of inventive problem solving, now available in 2 software forms (Invention
Machine, and The Ideator), is being explored as a BPM tool. TRIZ was invented by
Genrich Althsuller, a Russian who studied 200,000 patents to identify common
features in the invention process; TRIZ is a huge conceptual system.
Ilia Bider said that half of the answer is in the question. Fan had put the wrong
question by imposing Workflow; flexibility was needed in understanding the structure
of the goals. Order is more or less fixed; varying all the orderings would give you too
many answers. Fan said he agreed the that asking the right question is was important.
The dominant types of systems being implemented now are packaged solutions, like
ERP, PDM and even office accounting system. Flexibility is was certainly limited.
Denise Downs' talk on Analysis and Design for Process Support Systems using
Goal-Oriented BPM was presented in her absence. She had argued that you should
define clear goals, vision and values before creating a comprehensive BP model, and
then trace each activity in the model to the software design objects that implemented
it. Neither the OO approach - which tended to jump on isolated use cases - nor the
structured approach - which tended to identify processes and dataflows without
looking at sequence constraints or roles. She therefore creates a process flow model,
which contains 2 kinds of item: triggers and activities. Triggers can be events or by
time; every process flow starts with a trigger. Activities form a chain and identify the
precise sequence required; i.e. the process model defines a canonical "best practice"
process which is used by staff for guidance. This is clearly a simple case (unlike those
raised by earlier speakers) but a perfectly valid one.
Steve Battle (HP Labs, Bristol) and Deb Cooper (Contact24 ltd) spoke on Goal-
Oriented Service Management. We've done what the client asked us to do: why
aren't they happy? We got really frustrated as it happened again and again. So we
devised a practical approach for our outsourced situation. We want to be perceived as
experts, and to learn from every implementation before we face our Board. So
Lessons Learnt are important.
We worked with an organization providing outsourced call centre CRM support
for the financial services industry. There is voice, as well as manual processes, and
web interaction. There's been a big change since Sept. 11th - cutting costs, but also
giving better quality not just quantity. In the USA they just have quantity; the UK
3
public is far more demanding and want their questions answered right first time. And
clients tell us what they want, not what they need: 2 different things.
So, we first identify BPs and participants with use cases. E.g. queries arrive and
are handled by advisors, who forward more specific queries to a well-trained bureau
operator, and complex queries to a dedicated advisor. This analysis leads to the design
of a massive knowledge base for each class of actor. Traceability is established
between client corporate aims, more specific objectives, and then to detailed goals.
However the goals depend on the BP model - if it changes, goals have to be revised.
New goals can be handled temporarily in contingency by simple (often manual)
procedures. If a client asks for anything that doesn't seem to trace back to a strategic
goal, we can ask them why they want it, and maybe thus simplify the process model.
Ian Alexander remarked that it had been said 'all good patterns are obvious'. Ilia
Bider said there was often too much abstraction in the wrong place (academically)
but too little in other places (industrially). Ian replied that we all needed to connect
research with practice and teaching.
Discussion
Ilia Bider led the discussion by asking us to work towards a common notion of
Goal for BPM. Vision was too unquantifiable to be included. Objectives might also be
unmeasurable but were important. Goals had to be measurable. But strategic
objectives could said Gil Regev be qualitatively assessed. Ilia Bider asked us to seek
the kinds of measures that goals should have. E.g. in a homeostatic system a key goal
is to maintain a constant (or constantly growing) market share, etc. Goals could thus
be fixed or dynamic (i.e. having a constant rate of change) with respect to an
environment. Staying still was like walking up the down escalator: there was always
'friction' so you had to take action to stay still. To adapt to other environments you'd
have to change the BP model.
Ilia said that (in a homeostatic or control system) having a goal means the current
state is not the goal state, and a corrective (negative feedback) action should be
applied. Ian replied that even when the current state was the desired one, the goal
(Actual Value = Desired Value, A = d) remained, but no corrective action was
momentarily needed. To follow a trajectory, you had a differential, i.e. dA/dt = D.
This assumed a continuous environment, but (said Ip-Shing) the environment could
suddenly jump.
Goals could be nested, just as processes (and systems) can. Goals change human
behaviour by setting measures on our behaviour (said Ip-Shing). These concepts can
be applied at all levels in an organization, raising issues of the different languages in
the boardroom, in line management, in IT consultancy, and so on.
Every procedure must be measurable against a (functional) goal.
Other goals may not correspond to individual procedures but must be associated
with a measure for the organization to follow, e.g. to conduct business ethically, to
run the railway safely, etc.
© Ian Alexander, September 2002
4