Ventana software support forum

Posted by Martin Schaffernicht <martin@utalca.cl>
Hi,

I have a question regarding the early steps of the modeling process.

We urge SD students to model a problem, not ""the system""; the (mental model of the) problem thus acts as key for abstracting relevant items from the real system. The modeler is advised to identify these variables in the problem statement and set up the reference modes, and then a preliminary dynamics hypothesis is developed.

Sounds logical and almost easy. But for modelers with little experience it does not seem to be easy. How can you be reasonably sure to be on a useful path before you see the Stock-and-flow model that you can simulate, analyze and test? Is this a matter of skill (experience) and the unexperienced will have to iterate (switch back and forth between the steps)?

To me it seems to be. I guess I can usually find my way through this, but I find it really difficult to explain to my students how to do it.

Is there a set of rules like ""best practices"" or something like the ""DOs and DO-NOTs""?

Thanks for helping me,

Martin Schaffernicht
Universidad de Talca
Talca - Chile
Posted by Martin Schaffernicht <martin@utalca.cl>
posting date Thu, 13 Oct 2005 10:45:42 +0200

Posted by Justin Lyon <justin1028@yahoo.com>
Martin,

For structuring an SD problem before sitting in front
of a computer, I would recommend developing an
architecture of the problem to be studied on a
whiteboard using Dr. Warren's insights in competitive
strategy dynamics.

Check out two resources: http://justinlyonandsimulation.blogspot.com/

and

http://www.strategydynamics.com/jl/

I find if I do the whiteboard work first, it makes it
easier when I sit down to create the SD model. Unlike
casual loop diagramming, Kim's method incorporates the
logic of stocks and flows thus avoiding possible
mistakes that many early SD novices make when trying
to figure out what accumulates and what is filling up
or draining the stocks. Let me know what you think of
his stuff.

Best,
Justin Lyon
Posted by Justin Lyon <justin1028@yahoo.com>
posting date Fri, 14 Oct 2005 06:31:52 -0700 (PDT)

Posted by ""Zagonel-Santos, Aldo A"" <aazagon@sandia.gov>

In my paper ""Model Conceptualization in Group Model Building: A Review of the Literature Exploring the Tension Between Representing Reality and Negotiating a Social Order"" (ISDC, Palermo, 2002) I essentially agree with Martin that the leap from problem definition to model conceptualization remains an art with little practical guidance available for the novice modeler. I argue, however, that this ""top down"" approach to modeling is not always used, and spend the entire paper exploring a tension I observed in the existing literature and in my experience in GMB between two competing approaches which I chose to label ""micro world"" and ""boundary object"" modeling. In the absence of easy to use guidelines (or perhaps in spite of them if they existed), I think that this richer discussion of model conceptualization is useful to students. In an extreme case, when the problem is so messy and involves lots of stakeholders, the modeler is hard pressed to work with a dynamic hypothesis. Then, an alternative approach is needed to begin this conversation and steer the analysis towards a simulation model.

Aldo

Aldo Zagonel
Albuquerque, NM
Posted by ""Zagonel-Santos, Aldo A"" <aazagon@sandia.gov> posting date Fri, 14 Oct 2005 09:41:24 -0600

Posted by Bill Braun <bbraun@hlthsys.com>
Causal loop diagrams are a good tool start that conversation. I ask students to state the problem as they perceive it (their mental model of the problem symptom) and then to form an hypothesis of what is giving rise to the problem symptom in the first place (their mental model of the underlying problem).

We then start to explore the problem symptom based on their hypothesis. For example, if they hypothesize that A influences B, we inquire into a number of possibilities. 1. Does A completely determine B? If not what else is acting upon B? 2. If a change in A influences a change in B, what might be influencing A (including the possbility of B)? 3. If B is changing, what might B be influencing. 4. What else might A be influencing when it changes.

Causal loops almost always emerge from this discussion (sometimes with a little help and a nudge). We then look at the CLD and identify stocks, and then clarify the flows.

At this point, they have a sketch of an SD model that is a good point of departure.

Bill Braun
Posted by Bill Braun <bbraun@hlthsys.com>
posting date Fri, 14 Oct 2005 09:57:18 -0400

Posted by ""Jim Thompson"" <james.thompson@strath.ac.uk>
Bill Braun wrote: Causal loop diagrams are a good tool start that conversation. I ask students to state the problem as they perceive it (their mental model of the problem symptom) and then to form an hypothesis of what is giving rise to the problem symptom in the first place (their mental model of the underlying problem).

Bill's reply strikes me as being like, ""Breakfast is a good way to start the day."" My question is: what is he serving for breakfast?

Clients who are engaged in problem-solving are 'students' to a degree. For the most part, they have a messy complicated problem that has resisted solutions and, sometimes in desperation, turn to consultant-facilitated SD to help.

There are two significant challenges to working with clients in this state: one is helping them understand SD methodology, and the second is to help them use the methodology to make sense of their problem. In consulting engagements, these occur in parallel, not in sequence.

In my current research, it appears that the Aha for each individual comes when s/he grasps the notion of negative feedback and applies it to a systemic problem characterised by interconnected negative feedback loops.

I would be interested to speak with SD consultants to confirm or disconfirm this observation. Jim Thompson james.thompson@strath.ac.uk Posted by ""Jim Thompson"" <james.thompson@strath.ac.uk> posting date Sat, 15 Oct 2005 09:33:02 -0400

Posted by =?iso-8859-1?Q?Jean-Jacques_Laubl=E9?= <jean-jacques.lauble@wanadoo.fr> Hi Martin I have not the pretensionsness to help you in this difficult matter but your query can still be studied methodically. <We urge SD students to model a problem, not ""the system""; the (mental <model of the) problem thus acts as key for abstracting relevant items <from the real system. The notion of problem and system need to be clarified. These notions are currently used in the literature but I would like to know the exact definition of them. There is too a confusion with the problem and the objective of the model. For instance you can have a problem: by example poverty in a class of population, the objective being first to increase their education. I mean that there is first the necessity to identify a problem, the problem definition and secondly to decide what is possible to do to reduce the problem, the objective. Seeing things this way may clarify the first step of the modelling process, by insisting on the fact that there can be a problem, and many objectives possible. Deciding on the objective is of course a matter of experience. it needs probably dozens of modelling projects to get a feel of what objectives can be reachable in the context of the problem at hand, the stakeholders, that amount of the effort necessary, the expected profit etc. About the mental models: do you mean the mental model of the students about the problem? If the problem does not belong to them, the mental model will be theoretical, and not based on any experience of the problem. < The modeler is advised to identify these < variables in the problem statement and set up the reference modes, and < then a preliminary dynamics hypothesis is developed.

The variables that need to be identified depend on the problem, but mostly on the objective. Defining the variables, is not easy, and in a method I learned in a distant course, the list of possible variables were proposed by the client or the people representing the client. I think that by defining the variables, you already define too early the path that will take the solution of the problem. Defining the variables, presume that you know already the kind of solution. It is then normal that these students feel uneasy when asked to define the variables and by consequence the path of the solution. By defining the reference mode, you ask the students, to decide which variables will represent better the reality of the problem, when trying by example to calibrate the model. This is not easy too.

I do not say that this method is bad, but it will necessitate a lot of rework, when the difference between the assumed solution derived by the early definition of the variables and the later solution proposed by the model will become apparent. < How can you be reasonably sure to be on a < useful path before you see the Stock-and-flow model that you can < simulate, analyze and test? You cannot be sure to be on a useful path, especially if you decide on the solution before you try to find it. I think that the definition of the problem and the early steps of the modelling process is not very clear not to mention that I have learned two different methods. One supposed to be standard: 1. Draw a complete CLD of the problem 2. Model the firs loop. 3. Model the second 4. Etc.

The second explained in the Vensim user guide.
Build a first simple model, based on the principal feed back hypothesis. Build step by step, the second hypothesis etc.. In the Sterman's book, the advices look more like the second solution.

The differences between the two, is that the first, tries to evaluate the problem as a whole, at the beginning, taking the risk, if the CLD was not accordingly changed during the modelling, to freeze the representation of the reality. The first has the advantage to start the modelling with a whole representation, that can eventually help. You can do both at the same time and reconstruction the whole CLD at every time step. Another problem that breeds uneasiness is that I have mainly distinguished two kinds of problems, exposed in the literature. The fist kind is where one tries roughly to cure a dysfunction or better the operational organisation in a system, like in the beer game. In this case the problem lies into the boundaries of the model. Another kind of problem is by example the one explained at the beginning of Kim Warren's book: The case B A pharmaceutical supplier faces an attack on its major product market by the dominant rival, who is about to launch a near-identical product. The General Manager of this £300m business unit was greeted with the news that he had four weeks to prepare for this competitive onslaught. In this case, the problem does not lie in a dysfunction, but outside of the model, and the solution is to study, how the business works, and to take the decisions, that will better suit the rapidly evolving environment. The case A and C, are of the same kind as there is no dysfunction, and the problem is to adapt to the environment, though it changes more slowly. In the first kind of problem, the environment is relatively stable, and the study of the reference modes, is mandatory, as it helps to spot the dysfunction, and once the solution found, the problem will be cured. In the second kind of problem, the reference modes, may still be useful, as it helps understand the functioning of the system, to help face the environment. But it is now less mandatory and even can be misleading because nothing proves that the behaviour will be stable in the future, as the environment will be changing in an often unpredictable way. I did not remark any distinction between these two kinds of problems in the litterature so far. But if somebody know something about it, I would be glad to know it. Regards. J.J. Laublé Allocar France. Posted by =?iso-8859-1?Q?Jean-Jacques_Laubl=E9?= <jean-jacques.lauble@wanadoo.fr> posting date Sat, 15 Oct 2005 17:11:41 +0200

Posted by ""John Gunkler"" <jgunkler@sprintmail.com>
I find it useful to ask people to think about ""the process"" that is producing the behavior of interest. [First, of course, we must identify the behavior of interest and create some data about it -- at the very least, a dynamic graph (over an appropriate time period) of the behavior mode(s).] Please note that the behavior of interest is nearly always about something that is being ""produced"" by the system which we count or otherwise measure to create the behavior mode graph. If you cannot identify the ""something"" being produced, you have some more work to do. Also, please note, that this ""something"" must be different at the time you measure it than it was previously -- that is, the system has at least one output (the ""something"" we're interested in) that differs from the system's inputs. By my definition, that's how you know you have at least one ""process"" at work -- because a ""process"" is something that transforms an input into an output. This implies that another useful early step in modeling is to try to understand the system as an Input-Process-Output model -- which implies that you need to try to understand the nature of the ""inputs"" as well as the ""output"" of interest. [Some of the inputs will become ""clouds"" in your diagram eventually.]

I find it very useful to use Value Stream Mapping (from Lean Enterprise/Lean Manufacturing/Lean Office) or a simple variant of it to get a picture of the stocks and flows and delays within the process (or the ""value stream""). Value Stream Mapping does a pretty good job of identifying the bottlenecks and time traps. This is used in Lean to make the process more efficient, but for SD modeling is also a useful clue to where the drivers of interesting dynamic behavior may lie. It identifies time traps/constraints/bottlenecks by looking at the flow/stock pairs within the process and comparing two time measures: ""cycle time"" and ""lead time."" Cycle time is the time it requires for the value-adding process to occur (i.e., how long it takes to do just the things that contribute directly to the outcomes we're interested in.) Cycle time is also called ""value-added time"" or VA time. Note: It usually takes some on-site investigation, often with a stopwatch, to figure out the true cycle time for a process step (flow/stock pair).

Lead time is the total amount of time it takes for whatever is flowing in that part of the process to get from one stock to the next. This takes into account both the VA time plus all the ""waste"" or delays in the process. Wastes come in seven (standard) kinds:

1. Transportation (of materials or work in process, e.g., into and out of
inventory)
2. Inventory (i.e., the building up of ""work in process"" or stocks of items larger than size 1) 3. Motion (movement of people) 4. Waiting (pure delay) 5. Overproduction (making more than necessary to satisfy immediate customer needs, or making things before customers need them) 6. Over-processing (doing rework, paperwork to deal with overproduction or storage and inventory, having too much inspection, etc.) 7. Defects (errors, mistakes, products that don't meet customer needs)

Then, for each process step (each flow/stock pair), compute the ratio of Cycle Time (VA time) to Lead Time. Those process steps with the lowest ratio usually warrant further investigation.

Note: The term ""value stream"" makes immediate sense when referring to systems that are intended to ""add value"" to inputs in order to produce outputs (products and services) that people are willing to pay more for than they would pay for the unprocessed inputs. But Value Stream Mapping, as a method, applies equally well to just about any system that produces outputs that differ from the system's inputs -- in other words, to almost any system with enough complexity to be interesting.

The Lean Enterprise Institute's store (www.lean.org) is a good source of resources for value stream mapping, although most of the books are also available through conventional bookselling outlets. Posted by ""John Gunkler"" <jgunkler@sprintmail.com> posting date Sat, 15 Oct 2005 11:21:19 -0500

Posted by Roy Greenhalgh <rgreenh@attglobal.net>
Jim

An interesting posting.

For my part I do not introduce the two concepts ""..in parallel"". On the contrary, it is only when clients can draw a negative feedback loop, albeit a simple one - and tell me what is going on that I'm willing to move on.

I do agree that the Aha is what one should wait for. And yes, the connected series of negative feedbacks really tests the thinking.

Roy Greenhalgh
Consultant
Posted by Roy Greenhalgh <rgreenh@attglobal.net>
posting date Sun, 16 Oct 2005 14:32:02 +0100

Posted by Bob Eberlein <bob@vensim.com>
Hi Martin,

I think you have posed a very good question, and one that goes to the heart of the distinction that some make between systems thinking and system dynamics. Specifically, you ask:


>> Is this a matter of skill (experience) and
>> the unexperienced will have to iterate (switch back and forth between
>> the steps)?


I agreee with you that the answer to this question is yes, and it is a bit of a dilemma, almost a ""Catch 22"".

Watching someone experienced in doing system dynamics in front of a group conceptualizing a problem and doing some causal loop diagramming is an absolute pleasure. It seems almost as if there is an effortless transition for ordinary discussion, to identified loops, to genuine insights. While the validity of the insights, and especially their relative importance, may be in question - they are definitely relevant to the problem at hand.

I think the reason this works so well is that there is a lot of commonality to dynamic problems. Jay Forrester has often said that there are a handful of relatively simple structures that can be used to understand a very large fraction of dynamic problems. Once these structures are mastered, then the panopoly of things worth looking for is more easily characterized early on. In a nutshell if you have been someplace before it is much easier to recognize when you are on the path to that place.

I do not, however, believe that there is any method other than bulding a simulation models and experimenting with it to develop a thorough understanding of the model. Certainly we can, and do, teach about models, show others what they do, and even give people the models to play with. None of that, however, seems to convey the undersanding that is necessary to actually use the content of these models in problem conceptualization.

The conclusion I come to is that the only way to learn how to do useful causal loop diagraming is to learn how to build and analyze simulation models. The implications of that for pedagogy are clear - always teach people how to build simulation models; complete solutions to simple problems are more effective than partial solution to more interesting problems.

Bob Eberlein
Posted by Bob Eberlein <bob@vensim.com>
posting date Sun, 16 Oct 2005 09:22:30 -0400

Posted by Bill Braun <bbraun@hlthsys.com>
Jim Thompson wants to know what I'm serving for breakfast. It's a good question. Putting my suggestion in the context of a ""messy complicated problem that has resisted solutions"" I would probably have to admit, ""watered down orange juice"".

I've also worked with clients clients who do not have a specific pressing problem currently driving them to distraction (or worse), but who sense that there might be a different way of conceiving and articulating their problems. Sometimes just narratively describing a CLD or a simple SD model (not even reduced to paper) offers them an insight into their own thinking that may, over time, cause a shift in perception.

In my own defense I was only responding to a way to open the conversation and develop a sketch of where to start. I've lost some people's attention as quickly as I've captured others by making any reference to SD methodology. I've not yet found a once size fits all.

I was at breakfast this morning (fortunately some one else was preparing
it) and an aquaintance shared that he is running for city council in his community. I asked what the pressing problems were. He replied, galloping growth. As an example he talked about reducing traffic congestion by expanding road surface area. You know the rest of the story. I'm pretty sure he will think about congestion and road expansion differently from just a three minute conversaton.

Jim, if you are ever Cleveland way, drop me a note. We'll have breakfast. I'll served the orange juice full strength and throw in eggs and a side of bacon. If that works out well we can talk lunch.

Bill Braun
Posted by Bill Braun <bbraun@hlthsys.com>
posting date Sun, 16 Oct 2005 19:00:06 -0400

Posted by ""Alan Graham"" <Alan.Graham@paconsulting.com>
Yes, Jim, consultants have some observations, on how the conceptualizing process is framed, what an appropriate sequence of events is, and usefulness pre-simulation.

The framing of the process as ""modeling the problem, not the system"" is operationally very misleading, and frequently prompts students and practitioners alike to jump immediately to causal diagramming, expecting a dynamic hypothesis to spring to life like Athena came full-grown (and wearing armor, yet) from Zeus' forehead. Yes, extremely experienced practitioners can do that, but that's far from the best way for normal people to approach it.

A better framing is that for every problem, we do model not only the system, but the entire universe. Our choice and challenge is carefully picking whether we model each piece implicitly, simply, or in great detail. Framed this way, the focus is on the choice of matching elements of structure to the problem, which can be done in a more step by step process.

When PA teaches consultants without SD background how to conceptualize, there's a sequence of steps prior to causal diagramming, and it's proven important that each be explicit and discussed among more than one person, and if possible done from a background of familiarity with both the organization and previous SD studies. A few process ""deliverables"" are:

a. Framing question for the modeling--a broad theme to gently focus the discussion

b. Model purpose--a list of ""what ifs"" that are of concern, or a (somewhat redundantly named) 4-quadrant issues statement--1. explicit strategy levers under consideration, 2. external scenarios of concern, 3. outcome metrics, and 4. puzzles or issues. (Students especially need a sharply-defined purpose, even if it's made up; they learn little about making appropriate modeling choices if there's no criterion for making the choices.)

c. Block diagram--3 to 5 broad areas that seem likely to be represented dynamically--""customers"", ""market"" ""operations"" ""finances""--a broad outline of model scope. This lets the modeler start doing boundary adequacy testing before investing time in diagramming dozens of loops- -much more efficient to articulate boundaries earlier than later.

d. Variables and behavior over time--at least one variable for each block in the block diagram (to assure wide coverage) of the problem behavior over time. It can be historical, or hoped for/feared future behavior. This gives something to test the dynamic hypothesis against--does it provide a structural explanation for the behavior?

With these four deliverables created and reviewed, the person or team is in a position to articulate a dynamic hypothesis, preferably starting from system archetypes and making problem-specific elaborations. To put a point on it, this is very far indeed from ""starting the conversation with a causal diagram"".

On the question of usefulness of pre-simulation activities, we have to ask the classic SD question, ""relative to what"". Yes, given the calendar time and resources, there are very few problems that wouldn't be more reliably addressed by going all the way to well-validated simulation analysis. But in the real world, client's needs vary. A lot. For some, there's no way they can get useful answers within the time and budget available to them through simulation. So the question becomes: use qualitative-only methods, or let them flounder? This is the point Geoff Coyle made in SDR a couple years ago. It's one thing to make an academic point that in principle almost all problems are addressable with higher quality if properly-validated simulations are used; it's another thing altogether, and quite untrue, to say ""if you won't simulate, we have nothing to help you.""

PA has many cases where the qualitative-only work was enough to guide the client to answers that, when implemented, clearly improved the system. That guidance is clearly more effective coming from simulation-trained modelers. It's quite arguable that they reached better answers than they would have with the BOGSAT method (Bunch of Guys Sitting Around Talking). I say this even though PA are far from systems-thinking bigots; other clients need factual rigor and auditability that take us far to the other side of typical academic style, with intensive data use and validation activities, and we deliver that. Sometimes in court. The important thing is to do whatever's needed and feasible to improve the system, and that will vary considerably from situation to situation.

I hope this sheds some light on the sometimes-murky process of conceptualization.

Cheers,

Alan



Alan K. Graham, Ph.D.
Decision Science Practice
PA Consulting Group
Alan.Graham@PAConsulting.com
One Memorial Drive, Cambridge, Mass. 02142 USA
Posted by ""Alan Graham"" <Alan.Graham@paconsulting.com>
posting date Mon, 17 Oct 2005 08:07:40 -0400