Stocks and flows and word-and-arrow diagrams

[George Richardson]

We seem to be getting ourselves in knots over the question of whether to
use stocks and flows ("tubs and pipes with valves") in our systems
diagrams or whether to limit ourselves to words and arrows without
explicit recognition of stocks and flows.

Cant we treat this as we treat a number of other issues, by agreeing to
fit "best" practice to audience and purpose and the nature of the system
under discussion? The purpose of our diagrams is always to communicate --
usually to others, but sometimes to ourselves as we immerse ourselves in
the conceptualization and formulation of a model. If stocks and flows
enhance communication, we should represent them in our models, both in
the conceptualization stage or the reporting phase. If stocks and flows
dont help the communication or understanding, which sometimes happens,
then we should feel ok to not represent them in our diagrams.

Examples: 1) The flow of individuals from one accumulation to another
(e.g., new workforce to experienced workforce, work in process to finished
inventory, susceptibles to the sick population) is difficult to see in
causal-loop form and easy to see in stocks and flows. [In the causal-loop
form, the single flow from stock A to stock B has to be represented as two
arrows, one subtracting from A and another adding to B, thus obscuring
that there is one flow between the two stocks.] So in such a chain of
accumulations one should almost always use explicit stocks and flows,
no matter what the audience, since everyone will find the stock-and-flow
picture to be the clearest representation.

2) In a recent group model conceptualization process, we were talking
about communication and trust in a working group and the resulting
dynamics of effectiveness of teams and team learning. The stocks were
very unclear to the group at the outset, so it seemed most appropropriate
to begin the conceptualization using nothing but words and arrows (causal
loops, influence diagrams). A clear stock emerged at one point in the
distinction between "Teamwork" and "Experience with Teamwork" -- the group
saw the latter as a stock of experience whose rate of growth depended on
the amount of teamwork present at any given time. Trust later seemed to
have the character of a stock, so we identified it as such later. We made
much headway by not restricting ourselves to identifying stocks and flows
at the outset.

So let us treat the stock-and-flow / word-and-arrow issue as a judgment
call a professional makes as he or she is developing views of system
structure. Use the representation that is most helpful at the time.
Highlighting clear stocks is usually helpful, so there ought to be a bias
to representing clear stocks and flows where they clearly exist. But the
judgment also must include the characteristics of the audience one is
communicating with and the purpose of the diagrams.

I guess my conclusion is
form of representation = f ( audience, purpose, system )

Im hoping this apparent equivocation is satisfying to all, including
those of us who have specific biases, and is scientifically respectable as
well. It does seem to reflect "best practice."

...GPR

-----------------------------------------------------------------------
George P. Richardson G.P.Richardson@Albany.edu Rockefeller College of
Public Affairs and Policy Phone: 518-442-3859 University at Albany - SUNY,
Albany, NY 12222 Fax: 518-442-3398
-----------------------------------------------------------------------

["JOHN MORECROFT"]

I have enjoyed the dialogue so far on stocks-flows and word-arrow
diagrams. Model conceptualisation is an area that has always
interested me, and the question of which representation to adopt is a
natural and fundamental part of conceptualisation.

I have come to realise (after many different projects) that
conceptualisation is essentially a creative process, so you would not
want to unduly restrict the ways in which a credible feedback model
takes shape. Basically I agree with Georges advice: 1. use the
representation scheme that is most helpful at the time; and 2.
recognise that representation is a function of audience, purpose,
and system. There is no recipe for building a good system dynamics
model any more than there is a recipe for composing an effective
novel or piece of music. However, we all share a discipline for
discovering the essence of dynamic complexity in practical
situations. Sometimes our discipline leads us to recognise critical
stocks and flows; and sometimes to detect feedback processes.

I can recall projects that definitely took shape around pure causal
maps (the stocks and flows came later). However, for me, these are
in the minority. I can certainly recall projects that took shape
around stocks and flows. For example, the market migration model
presented in my paper "Strategy Support Models" (Strategic Management
Journal, 5: 215-229, 1984) grew from a picture of stocks and
flows (representing the movement of customers from old to new
technology products), drawn by a participant (Jim Cleary) in an MIT
summer session many years ago. From this basic stock and flow
network we then went on to map the behavioural decision functions (or
policies) of customers and the firm that control the rate of customer
migration - thereby discovering a rich and dysfunctional network of
(information) feedback loops. Interestingly our current work at
London Business School on what we are calling a "dynamic resource
based view" of the firm is re-emphasising the importance of stock and
flow networks as the starting point for a broad class of strategic
business problems. Well be saying more in Istanbul.

This particular path of model development (from stocks and flows to
policies and then to feedback loops) brings me to one additional
approach to conceptualisation that has received no attention so far
in this e-mail dialogue. The conversation has assumed that one
either begins from stocks and flows OR from causal loops. However, I
have often found it useful to begin model conceptualisation around
policies. For example, if you want to explain the persistence of
costly inventory cycles in the Beer Game it seems quite natural to
start by deciding which policies in the supply chain are most
relevant to the coordination of supply and demand. Of course there
is some room for debate, but it is not hard to come up with a policy
list that includes ordering, inventory control, backlog management
and supply line control. From this starting list the remaining (and
significant) modelling challenge is twofold: 1. to properly
portray the information available in each policy ( and by implication
the information that is not available); and 2. to identify the key
stocks that accumulate policy actions. Then, as the stocks and flows
are united with policies, feedback loops become visible. The
advantage of this approach to model conceptualisation is that it
opens-up a very fruitful line of communication to policy-makers huge
database of experience and knowledge. Most business people can tell
you how policies for inventory control, pricing , hiring and capital
investment really work. Within their descriptions you will often
find the information deficiencies that lie at the heart of
dynamically interesting feedback structures. For example, in a model
of the Beer Game a crucial question in thinking about supply-line
control is whether players really know the state of the supply-line.
Where on the board do you look to form an accurate impression of the
accumulation of past orders? In practice such information is simply
not available, and even if it were how would you, as (maybe) a
retailer, know the real significance for this weeks order of (say)
50 orders residing in the factory?

When I look back on my training, this emphasis on policy as a
starting point for model conceptualisation arose from the great
emphasis the MIT group of the 70s and 80s placed on rate equation
formulation. No doubt the emphasis lives-on. So policy mapping
became an integral part of my approach to model conceptualisation,
and remains important today. I first outlined the approach in a
paper called "A Critical Review of Diagramming Tools for
Conceptualising Feedback System Models" (Dynamica 8, I: 20-29, 1982).
I still often use policy maps as a way to gain resolution on
the feedback structure of information networks (as for example in
"Modeling the Oil Producers", Modeling for Learning Organizations,
chapter 6: 147-174, Productivity Press 1994).

In conclusion I find myself right back at Georges thought that
prompted my message: use the representation that is most helpful at
the time. Be flexible and creative. Be prepared to switch between
stocks and flows, policies and feedback loops in the creative effort
to discover and portray dynamic complexity (as realistically yet
compactly as possible).

John




John Morecroft, London Business School
Sussex Place, Regents Park, London NW1 4SA UK
tel +44 171 262 5050 x3252 fax +44 171 724 7875
e-mail J.MORECROFT@LBS.LON.AC.UK

[Alexandre J G P Rodrigues]

I would like to add to this discussion an element of comparison between
"word and arrows" influence diagrams (ID), and "level
ate" diagrams (LRD):
the level of formality.

Although this might only reflect personal experience, it seems to me that
the emergence of the ID representation reflected a possibly better
suitability (or even elegance) to represent feedback loops and general
feedback structures. Forrester (1961) initial proposal was to use
level
ate type of diagrams, where the model is conceptualised using from
the very beginning: levels, rates, information links, and auxiliaries. From
here to simulation remains the quantification of relationships. This
undoubtedly "forces" the classification of the "words" in the diagram as
accumulations (levels), policies or system changes (rates), structured
information about the system (auxiliaries), or information flows.
Therefore, whatever the level of understanding the modeller has, if model
conceptualisation starts by using an LRD, at this level one is forced into
the discipline of classifying the systems elements in this way. It is
arguable whether this is the more immediate and natural way of perceiving a
system (specially when there is a poor understanding about the system).
However, this may by the case when one sees the system in the first place
as consisting of entities of different types, flowing throughout a
life-cycle (open or closed) -- this starting point to model
conceptualisation is referred to in the literature as the "entity-
state-transition" approach (Wolstenholme 1990, Coyle 1996).

On the other hand, IDs are visually weaker in representing the life-cycle
of a systems entities. However, if used at a high level perspective IDs do
not necessarily impose any classification: they can be used simply to
represent high level *concepts* about the system (structure or behaviour),
identify highly aggregated influences, and identify general but perhaps the
fundamental feedback loops and overall feedback structure of a system. It
looks to me that IDs are better at doing this. Another strength of IDs is
that one can easily develop individual maps representing different parts of
a same system, or putting different emphasis in particular feedback loops
of a same system. It is not difficult to accept that these maps refer to
the same system and that a comprehensive description would merge the
different maps. In my opinion, level
ate diagrams (LRDs), because of their
formality, are weaker at doing this.

Systems are complex and regardless of efforts to aggregate, models can also
get complex (and important cases of practical applications reported in the
literature refer sometimes to complex models). Whilst a complex LRD may
still preserve a clear view of the life-cycle of the systems entities, the
same is not true for feedback loops. A complex ID may also become
cumbersome, as many loops are present in the diagram, and are difficult to
individualise.

I find the best role of an ID as remaining at the high level, or just
representing a particular set of feedback loops. When developing a
simulation model using a more detailed LRD, the modeller must ensure that
the fundamental feedback loops in the ID are being captured in the model,
possibly through may more intermediate variables and sub-loops. At that
level of detail, or discipline, where one clearly sees the system as levels
and flow-rates, the LRD is of course more appropriate as it clearly
benefits from its "visual" form.

A possible combined use is to try first the feedback loop approach at a
high level of aggregation. Then, using the LRD notation, try identifying
the systems entities and their life-cycle, associate these with governing
policies which affect the rates, identify the information used by these
policies, and relate this information to the elementary system state (i.e.
levels). As loops emerge in the LRD, they must also be captured in the ID
even if at an aggregated level. Working changes in the ID may suggest new
loops which must be captured in the LRD. Both models must be consistent and
complement each other: the fundamental feedback loops clearly seen in the
ID are being simulated in the LRD, eventually in more detail; these
feedback loops exist because the system consists of processes of flowing
entities, which make up the system state, which trigger policies, which
affect these flows. The process structure must be seen clearly in the LRD.

This is not meant to be comprehensive, but only reflect a personal
experience.


Alexandre J G P Rodrigues
Department of Management Science
The University of Strathclyde
Glasgow G1 1QE
United Kingdom
email: alex@mansci.strath.ac.uk

[Chris Schroeder]

Ive been following this discussion in silence, but with great interest.
Id have to agree with Georges conclusion--they both have their place and
should be used where most appropriate.

As an example, Im currently engaged in a project where were using stocks
and flows with one segment of the population (in this case, managers of the
production process), and using words and arrows with others (high level
management and customers). It is our job as facilitators and modelers to
use the tools that will make the most sense to the participants, and then
have the skill to pull it all together into a useful model.

Chris
From: Chris Schroeder <rcs@centrec.com>
Chris Schroeder

AEC/Centrec
3 College Park Court
Savoy, IL 61874
Phone (217)352-1190 Fax (217)352-1425
http://www.centrec.com

[Eric Wolstenholme]

I have watched this space with interest over the past few months and
learned a lot from the interchanges taking place. I would personally like
to thank all contributors.

I often wondered which subject would eventually provoke me to contribute
myself and today discovered what it was - model conceptualisation. In
particular John Morecrofts piece on broadening this discussion away from
the stock/flow v causal loop perspesctive. I would like to broaden the
discussion even further, but then to come back to these tools.

I see managment organisations AND system dynamics as composed of 5
elements - PROCESSES, POLICIES, ORGANISATIONAL BOUNDARIES,INFORMATION AND
DELAYS.

Model conceptualisation can begin with any one of these elements and
spread to the others.

There has been much talk about process based starts and John highlighted
policy starts.
I would like to focus here on the other elements:

BOUNDARIES are the link between power and dynamics in an organisation. We
never used to recognise that boundaries were important in models. I first
introduced these into my own thinking in 1983 (1) to counter the soft
systems criticism of SD that it was base only on a process perspective.
More and more I start models from a boundary perspective. Change
management is often all about moving boundaries of reponsibility and
accountability without thinking how such movement will effect the other
elements of the organisation. BUT boundary changes are usually made from
a power perspective to bring specific process variables within (or move
them out of) the control of the boundary movers. I often talk about
working at the boundary and have used this approch to modelling in Health
Services in the U.K. (2) and (3).

INFORMATION is the communication medium of all organisations but,
amazingly, information is still often treated in isolation and
information systems evaluated in terms of their information processing
capability, rather that their contribution to organisational behaviour. I
have often started models from an information perspective, particularly
studies involving Management Information Systems (4).

DELAYS are one of the major determinants of behaviour and the backbone of
SD. We all know this, but how many people start modelling from this
element. I have done this some times where a proposed management change
is around a time shift which I think has to be viewed in terms of its
effect on the whole organisation. For example, a reduced lead time.

How does all this relate to tools? It should be recognised that using
stock/flow diagrams effectively means starting models from a process
perspective and this is the most commonly used means of model
conceptualisation, particularly when there is no reference mode of
behaviour.Causal maps do not explicitly recognise process and start
models from a behavioral perspective. However, they take process
variables and link these to policies and information and (if you let
them) boundaries. I personally use a hybrid approach which combines a
modular approach to process definition and resolution (see (5) page 26
and (6)) with a causal loop approach.

I look forward to hearing of other starting points for modelling.

Eric Wolstenholme (Eric@COGNITUS.co.uk)

(1) Wolstenholm and Coyle (1983) The Development of System Dynamics as a
Methodology for System Description and Qualitative Analysis. Journal of
the Operational Research Society, 34, 569-581.

(2) Wolstenholme and Crook (1997) A Management Flight Simulator for
Community Care, in Enhancing Decision Making in the NHS, Ed. S. Cropper
and P. Forte, Open University Press, Milton Keynes.

(3) Wolstenholme. A Case Study in Community Care using Systems Thinking.
Journal of the Operational Research Society, Vol. 44, No. 9, September
1993, pp 925-934.

(4) Wolstenholme "Evaluating Management Information Systems",(1993) John
Wiley,(with S.Henderson and A.Gavine)

(5)Wolstenholme (1994) "System Enquiry - A System Dynamics
Approach",John Wiley, 1990. Second Edition 1994.

(6)Wolstenholme (1994) The Conceptualisation of Models, in Modelling for
Learning Organisations, Ed. by J.D.W.Morecroft and J. Sterman,
Productivity Press,1994.


From: Eric Wolstenholme <eric@cognitus.co.uk>