IADDR:
TO NATIVENAME:bbens@MIT.EDU
IADDR:
Benny,
It has been our experience at DOE-Idaho that causal loops are much more
effective than mathematical models when working with groups. It is difficult to
get group ownership of a model that someone else developed off line.
Causal loops can be an effective tool for developing an understanding of the
dynamics of a system and working through possible changes. You just have to be
cognizant of their limitations.
Bob Blyth
blythrl@inel.gov
Questions about application of SD?
-
"Robert Blyth"
- Junior Member
- Posts: 2
- Joined: Fri Mar 29, 2002 3:39 am
-
Bill Harris
- Member
- Posts: 31
- Joined: Fri Mar 29, 2002 3:39 am
Questions about application of SD?
Benny,
>Has anyone seen similar experience? If so, what should we do to mitigate
>the academic smell so that SD can get the senior managaments attention that
>it deserves?
I had a recent experience that I think was enlightening for me. I was
proposing a possible solution to a financial control system issue that had
been concerning my manager, and I used a stock-and-flow based simulation
(actually using EGO, since I had that on my laptop and iThink was only on
my desktop Mac) to demonstrate that my proposed solution might be superior
to the status quo. I demonstrated a simulation of the status quo that got
(qualititatively) similar performance to what he had observed in real life.
I then changed some feedback paths and demonstrated that the system
performed much more like he wanted it to. Never, in the entire
presentation, did I mention SD, Forrester, MIT, or any of the other
background (okay, I did show a pair of CLDs, but I think the stock-and-flow
diagrams were more useful in this case). In the past, while some of my
proposed solutions have come across as too academic, this was accepted
quite readily.
In other words, I focused directly on the problem and only brought in
enough of SD to illuminate the issue and the proposed solution (barely).
I should confess that my manager is trained as an engineer, so he shouldnt
have any qualms about dealing with differential equations and instability
caused by feedback. On the other hand, I also showed this to a financial
analyst with much the same results. He did question my claim that the
system I had modeled would be capable of generating endogenous (no, I
didnt use that word!) oscillations. I changed one parameter and re-ran
the simulation in his presence, and, voila! When he realized that none of
the pieces of this model were time-varying (except that the initial
conditions were not at a stable point), he became convinced.
> In the process, the clients
>were more interested in defining their challenges than looking for some
>root causes.
While this isnt SD per se, it may be related to the acceptance of SD
interventions: you might find the book "Flawless Consulting" by Peter
Block of interest. As I recall, he has some suggestions about how to
"contract" with clients to proceed on an assignment and on how to present
the final feedback that have been quite helpful every time Ive remembered
to use them.
Regards,
Bill
--
Bill Harris Hewlett-Packard Co.
R&D Productivity Department Lake Stevens Division
domain: billh@lsid.hp.com M/S 330
phone: (206) 335-2200 8600 Soper Hill Road
fax: (206) 335-2828 Everett, WA 98205-1298
>Has anyone seen similar experience? If so, what should we do to mitigate
>the academic smell so that SD can get the senior managaments attention that
>it deserves?
I had a recent experience that I think was enlightening for me. I was
proposing a possible solution to a financial control system issue that had
been concerning my manager, and I used a stock-and-flow based simulation
(actually using EGO, since I had that on my laptop and iThink was only on
my desktop Mac) to demonstrate that my proposed solution might be superior
to the status quo. I demonstrated a simulation of the status quo that got
(qualititatively) similar performance to what he had observed in real life.
I then changed some feedback paths and demonstrated that the system
performed much more like he wanted it to. Never, in the entire
presentation, did I mention SD, Forrester, MIT, or any of the other
background (okay, I did show a pair of CLDs, but I think the stock-and-flow
diagrams were more useful in this case). In the past, while some of my
proposed solutions have come across as too academic, this was accepted
quite readily.
In other words, I focused directly on the problem and only brought in
enough of SD to illuminate the issue and the proposed solution (barely).
I should confess that my manager is trained as an engineer, so he shouldnt
have any qualms about dealing with differential equations and instability
caused by feedback. On the other hand, I also showed this to a financial
analyst with much the same results. He did question my claim that the
system I had modeled would be capable of generating endogenous (no, I
didnt use that word!) oscillations. I changed one parameter and re-ran
the simulation in his presence, and, voila! When he realized that none of
the pieces of this model were time-varying (except that the initial
conditions were not at a stable point), he became convinced.
> In the process, the clients
>were more interested in defining their challenges than looking for some
>root causes.
While this isnt SD per se, it may be related to the acceptance of SD
interventions: you might find the book "Flawless Consulting" by Peter
Block of interest. As I recall, he has some suggestions about how to
"contract" with clients to proceed on an assignment and on how to present
the final feedback that have been quite helpful every time Ive remembered
to use them.
Regards,
Bill
--
Bill Harris Hewlett-Packard Co.
R&D Productivity Department Lake Stevens Division
domain: billh@lsid.hp.com M/S 330
phone: (206) 335-2200 8600 Soper Hill Road
fax: (206) 335-2828 Everett, WA 98205-1298
-
Kim Warren
- Junior Member
- Posts: 3
- Joined: Fri Mar 29, 2002 3:39 am
Questions about application of SD?
Youre right - Ive noticed the same, but we absolutely have to crack this
one. Causal loops are completely inadequate for any serious attempt to
model real situations and test policy options. I guess we all know Jay
Forresters warning that more than 1-2 loops and the systems behaviour
cannot be intuitively guessed at.
But there is a means of getting this idea across. Every manager Ive asked
can relate to the idea of building and maintaining firm resources (capital,
staff, customer-base etc.), and what is a resource if it isnt a stock?
Im working on this one!
Kim Warren - Asst Prof, Strategic Management, London Business School.
kim@farthing.stargate.co.uk
one. Causal loops are completely inadequate for any serious attempt to
model real situations and test policy options. I guess we all know Jay
Forresters warning that more than 1-2 loops and the systems behaviour
cannot be intuitively guessed at.
But there is a means of getting this idea across. Every manager Ive asked
can relate to the idea of building and maintaining firm resources (capital,
staff, customer-base etc.), and what is a resource if it isnt a stock?
Im working on this one!
Kim Warren - Asst Prof, Strategic Management, London Business School.
kim@farthing.stargate.co.uk
-
"John W. Rodat" <71207.2315@Comp
- Newbie
- Posts: 1
- Joined: Fri Mar 29, 2002 3:39 am
Questions about application of SD?
Dear Colleagues:
Ive been lurking on the SD list for well over a year and have found the
discussions to be provocative and often useful. Perhaps I can now make a
contribution regarding Benny Budimans experiences with "senior executives."
Ive learned, often painfully, the following:
1. Try to anticipate what your audiences feedback might be. Consider different
possibilities and prepare for them. Be ready to shift gears quickly.
2. Be alert to potential allies. Be especially alert to the possibility of
making allies out of "strange-bedfellows."
3. Sometimes you find your allies after the analysis and modeling are done and
you work backwards from there. People are much more receptive to a new
perspective on why theyre "right."
4. Translating into somebody elses language is not necessarily "dumbing-down."
Many times, references to SD will be met with blank stares and models will be
viewed as black boxes, but if you know the subject matter well enough, you can
and should translate the model into something the audience relates to. If you
arent sufficiently expert in the subject matter to understand the nuances of
its jargon, then use common metaphors. I use plumbing a lot.
5. Clearly, one should be alert to the needs and capabilities of ones audience.
But what to do when the "answer" is contrary to the audiences beliefs,
expectations, or interests? That is a much more challenging circumstance. If all
you give them is the "wrong answer," theyll reject it and probably you too. You
have to consciously try to figure out what they will connect with, CLDs, models,
or whatever. And youve got to keep coming back at folks over long periods.
Think of if as intellectual guerilla warfare.
Mike Moldaver (formerly of HPS) and I had an eye-opening experience a few years
ago with a very experienced senior executive. He had asked for a presentation
and a computer demo of a model for himself and a colleague. Only a few minutes
into it, he began to fidget and when asked what the problem was, he said, "I
dont care about this (expletive), just give me the answer." In contrast, we
couldnt tear his colleague away from the computer. As a result, we now always
ask ourselves before making a first presentation, which one of the two types
were going to see.
In another case, a prospective client asked us for an analysis to prove his
position was correct. We declined and then virtually dared him to use a joint
model-building process to prove his case to us. If he could, we would support
and validate his position publicly. If he could not, we would not release our
report without his OK and not embarrass him, but he had to agree to go through
the process and to make his final decision based on the results. The results
were contrary to his expectations, but he honored our agreement. Because he was
part of the modeling process, he was able to audit his own thought process and
he had learned some really important and unanticipated things in the meantime.
Hes now a convert.
During the past three years, I used a very different process for a public policy
audience, including lobbyists and legislators. After failed attempts to get
people involved in structuring the problem and models, I changed direction.
Development of CLDs, stock & flow diagrams, and the resulting model/s was in
private. The subject matter, how hospitals in New York are paid, is one about
which I am knowledgeable, but key variables were "bounced off" of a technical
advisory group in one intense meeting and off a range of people in numerous
informal one-on-one discussions. The basic framework and initial results were
presented informally to George Richardson, David Andersen, and a few others at
SUNY, Albany for their comments and criticisms. This was one of those cases
where the model-building forced radical changes in my own thinking and I believe
that my being able to say so in public helped others consider alternative views
of reality that they otherwise would not have been open to.
The results were written in lay language for two articles for a magazine aimed
at the policy/political audience. (A full report was written that included a
detailed explanation of the model and results, but I doubt that many people read
it.) Both business and organized labor responded to the articles and reversed
their historic positions. After that, it was much easier to engage people on how
the conclusions were reached.
The results have been presented to hundreds of people with considerable
expertise in the subject area, but neither SD or ST is ever explicitly
mentioned. Instead, I use presentation software (or lunch time placemats) to
walk audiences through the essential CLDs which are referred to as "plumbing." I
dont ask folks to think out CLDs or model structures from scratch. Instead, I
walk them through a much abbreviated and simplified version of the intellectual
journey that I took. Iask for their reactions/validation as the CLDs are built.
At critical junctures in the presentation, I ask audiences a personal
hypothetical question about their own decision making that leads them to
understand how the system in question can change direction (change of loop
dominance). The graphic results of 3 model runs are presented and by then they
at least understand the basics. In effect, we sneak in the back doors to their
minds.
The results after 2.5 years? First, despite ferocious lobbying by a significant
industry, a thirty year old policy and infrastructure which determined spending
of about $20 billion per year is being dismantled. Second, hundreds of people
have been exposed to CLDs and SD without even knowing it. In the long run, that
may be more important.
Best regards & thanks for listening.
John W. Rodat
Signalhealth
71207.2315@compuserve.com
Ive been lurking on the SD list for well over a year and have found the
discussions to be provocative and often useful. Perhaps I can now make a
contribution regarding Benny Budimans experiences with "senior executives."
Ive learned, often painfully, the following:
1. Try to anticipate what your audiences feedback might be. Consider different
possibilities and prepare for them. Be ready to shift gears quickly.
2. Be alert to potential allies. Be especially alert to the possibility of
making allies out of "strange-bedfellows."
3. Sometimes you find your allies after the analysis and modeling are done and
you work backwards from there. People are much more receptive to a new
perspective on why theyre "right."
4. Translating into somebody elses language is not necessarily "dumbing-down."
Many times, references to SD will be met with blank stares and models will be
viewed as black boxes, but if you know the subject matter well enough, you can
and should translate the model into something the audience relates to. If you
arent sufficiently expert in the subject matter to understand the nuances of
its jargon, then use common metaphors. I use plumbing a lot.
5. Clearly, one should be alert to the needs and capabilities of ones audience.
But what to do when the "answer" is contrary to the audiences beliefs,
expectations, or interests? That is a much more challenging circumstance. If all
you give them is the "wrong answer," theyll reject it and probably you too. You
have to consciously try to figure out what they will connect with, CLDs, models,
or whatever. And youve got to keep coming back at folks over long periods.
Think of if as intellectual guerilla warfare.
Mike Moldaver (formerly of HPS) and I had an eye-opening experience a few years
ago with a very experienced senior executive. He had asked for a presentation
and a computer demo of a model for himself and a colleague. Only a few minutes
into it, he began to fidget and when asked what the problem was, he said, "I
dont care about this (expletive), just give me the answer." In contrast, we
couldnt tear his colleague away from the computer. As a result, we now always
ask ourselves before making a first presentation, which one of the two types
were going to see.
In another case, a prospective client asked us for an analysis to prove his
position was correct. We declined and then virtually dared him to use a joint
model-building process to prove his case to us. If he could, we would support
and validate his position publicly. If he could not, we would not release our
report without his OK and not embarrass him, but he had to agree to go through
the process and to make his final decision based on the results. The results
were contrary to his expectations, but he honored our agreement. Because he was
part of the modeling process, he was able to audit his own thought process and
he had learned some really important and unanticipated things in the meantime.
Hes now a convert.
During the past three years, I used a very different process for a public policy
audience, including lobbyists and legislators. After failed attempts to get
people involved in structuring the problem and models, I changed direction.
Development of CLDs, stock & flow diagrams, and the resulting model/s was in
private. The subject matter, how hospitals in New York are paid, is one about
which I am knowledgeable, but key variables were "bounced off" of a technical
advisory group in one intense meeting and off a range of people in numerous
informal one-on-one discussions. The basic framework and initial results were
presented informally to George Richardson, David Andersen, and a few others at
SUNY, Albany for their comments and criticisms. This was one of those cases
where the model-building forced radical changes in my own thinking and I believe
that my being able to say so in public helped others consider alternative views
of reality that they otherwise would not have been open to.
The results were written in lay language for two articles for a magazine aimed
at the policy/political audience. (A full report was written that included a
detailed explanation of the model and results, but I doubt that many people read
it.) Both business and organized labor responded to the articles and reversed
their historic positions. After that, it was much easier to engage people on how
the conclusions were reached.
The results have been presented to hundreds of people with considerable
expertise in the subject area, but neither SD or ST is ever explicitly
mentioned. Instead, I use presentation software (or lunch time placemats) to
walk audiences through the essential CLDs which are referred to as "plumbing." I
dont ask folks to think out CLDs or model structures from scratch. Instead, I
walk them through a much abbreviated and simplified version of the intellectual
journey that I took. Iask for their reactions/validation as the CLDs are built.
At critical junctures in the presentation, I ask audiences a personal
hypothetical question about their own decision making that leads them to
understand how the system in question can change direction (change of loop
dominance). The graphic results of 3 model runs are presented and by then they
at least understand the basics. In effect, we sneak in the back doors to their
minds.
The results after 2.5 years? First, despite ferocious lobbying by a significant
industry, a thirty year old policy and infrastructure which determined spending
of about $20 billion per year is being dismantled. Second, hundreds of people
have been exposed to CLDs and SD without even knowing it. In the long run, that
may be more important.
Best regards & thanks for listening.
John W. Rodat
Signalhealth
71207.2315@compuserve.com
-
Jay Forrest
- Junior Member
- Posts: 19
- Joined: Fri Mar 29, 2002 3:39 am
Questions about application of SD?
On Thu, 4 Jul 1996, Kim Warren <kim@farthing.stargate.co.uk> wrote:
>Youre right - Ive noticed the same, but we absolutely have to crack this
>one. Causal loops are completely inadequate for any serious attempt to
>model real situations and test policy options.
On this listserve many people refer to SD and causal loop diagrams as
totally separate entities, and perhaps they are at MIT and in other academic
environments. As a primarily self-educated outsider (with an almost
uncomfortable name given the founder of SD) I see the field as much more of
a continuum. A continuum which is partially based on the fact that I do
most of my work in VenSim because it gives me more freedom in modelling and
simulation than Stella. I know my "vision" of SD is NOT "pure" by MIT
standards, but I am also pragmatic and am far more concerned with whether a
model performs properly than the symbols used or what it is called. Note:
This is not a statement that it is okay to be sloppy or unprincipled in
model construction for that would lead to client confusion, but rather that
causal loops and SD are a part of a continuum that more resembles subspecies
or hybrids than totally separate methods.
A question for those more formally educated. "What is a causal loop diagram
which contains formulas and provides graphical output (as can be generated
in VenSim)?" Other than the fact that it violates SD norms so it is
"nonstandard" I see no reason to worry about whether it is SD or not.
Donning my flack jacket, "I look forward to your comments!"
Jay Forrest
Pteragenesis
Chaos, Complexity, System Dynamics, Studies of the Future
pteragen@neosoft.com
http://www.neosoft.com/~pteragen
>Youre right - Ive noticed the same, but we absolutely have to crack this
>one. Causal loops are completely inadequate for any serious attempt to
>model real situations and test policy options.
On this listserve many people refer to SD and causal loop diagrams as
totally separate entities, and perhaps they are at MIT and in other academic
environments. As a primarily self-educated outsider (with an almost
uncomfortable name given the founder of SD) I see the field as much more of
a continuum. A continuum which is partially based on the fact that I do
most of my work in VenSim because it gives me more freedom in modelling and
simulation than Stella. I know my "vision" of SD is NOT "pure" by MIT
standards, but I am also pragmatic and am far more concerned with whether a
model performs properly than the symbols used or what it is called. Note:
This is not a statement that it is okay to be sloppy or unprincipled in
model construction for that would lead to client confusion, but rather that
causal loops and SD are a part of a continuum that more resembles subspecies
or hybrids than totally separate methods.
A question for those more formally educated. "What is a causal loop diagram
which contains formulas and provides graphical output (as can be generated
in VenSim)?" Other than the fact that it violates SD norms so it is
"nonstandard" I see no reason to worry about whether it is SD or not.
Donning my flack jacket, "I look forward to your comments!"
Jay Forrest
Pteragenesis
Chaos, Complexity, System Dynamics, Studies of the Future
pteragen@neosoft.com
http://www.neosoft.com/~pteragen
-
Jay Forrest
- Junior Member
- Posts: 19
- Joined: Fri Mar 29, 2002 3:39 am
Questions about application of SD?
Hi Jim!
I appreciated your comments:
Your comments re: causal loop diagrams and the equations being separate was
at the heart of my comment. As you indicated, SF diagrams and equations are
also separate.
As a chemical engineer I well understand the additional insight provided by
the stock and flow concept of SF over causal loop, but it is the formulas
beneath the diagrams that make the model "click". I use whichever approach
the client is more comfortable with (and to be honest that is often CLD as
stock and flow seems to create some difficulties for some people).
Again, Thanks for your comments!
Jay Forrest
Pteragenesis
Chaos, Complexity, System Dynamics, Studies of the Future
pteragen@neosoft.com
http://www.neosoft.com/~pteragen
I appreciated your comments:
Your comments re: causal loop diagrams and the equations being separate was
at the heart of my comment. As you indicated, SF diagrams and equations are
also separate.
As a chemical engineer I well understand the additional insight provided by
the stock and flow concept of SF over causal loop, but it is the formulas
beneath the diagrams that make the model "click". I use whichever approach
the client is more comfortable with (and to be honest that is often CLD as
stock and flow seems to create some difficulties for some people).
Again, Thanks for your comments!
Jay Forrest
Pteragenesis
Chaos, Complexity, System Dynamics, Studies of the Future
pteragen@neosoft.com
http://www.neosoft.com/~pteragen
-
Jay Forrest
- Junior Member
- Posts: 19
- Joined: Fri Mar 29, 2002 3:39 am
Questions about application of SD?
At 07:13 AM 7/8/96 -0700, Jim Hines wrote:
>I think the approach a client is most comfortable with depends on what the
>problem is and what the level of detail is.
>
>If you are portraying, say, the aging of a workforce; a stock and flow
>diagram will be simpler than a causal loop diagram.
>
>On the other hand, if you are portraying how overtime can cause fatigue which
>can create rework and the need for more overtime; a causal loop diagram will
>be simpler.
I fully agree with your examples. Where obvious accumulators exist the
client can usually understand the logic, but where the accumulators are more
subtle I have found S&F to confuse some clients. My comments focused more
on the clients nature and yours more on the problem. I think you will agree
that in real life both should generally be considered!
Thanks!
Jay Forrest
Pteragenesis
Chaos, Complexity, System Dynamics, Studies of the Future
pteragen@neosoft.com
http://www.neosoft.com/~pteragen
>I think the approach a client is most comfortable with depends on what the
>problem is and what the level of detail is.
>
>If you are portraying, say, the aging of a workforce; a stock and flow
>diagram will be simpler than a causal loop diagram.
>
>On the other hand, if you are portraying how overtime can cause fatigue which
>can create rework and the need for more overtime; a causal loop diagram will
>be simpler.
I fully agree with your examples. Where obvious accumulators exist the
client can usually understand the logic, but where the accumulators are more
subtle I have found S&F to confuse some clients. My comments focused more
on the clients nature and yours more on the problem. I think you will agree
that in real life both should generally be considered!
Thanks!
Jay Forrest
Pteragenesis
Chaos, Complexity, System Dynamics, Studies of the Future
pteragen@neosoft.com
http://www.neosoft.com/~pteragen
-
bbens@MIT.EDU
- Junior Member
- Posts: 10
- Joined: Fri Mar 29, 2002 3:39 am
Questions about application of SD?
Esteemed SDists:
I recently observed that SD has an academic smell that drives away senior
executives. It was my first SD consulting experience in which I worked with
the companys IT staff. My clients, the IT people, are optimistic for the
success of SD or ST in resolving some operational glitches in their company.
One of them, however, is quite shy on the stock-and-flow diagram for its
intimacy with mathematical (differential) equations, numerical integration
and everything else that have an academic "odor" but is very fond of the
causal loop diagram (ST).
Has anyone seen similar experience? If so, what should we do to mitigate
the academic smell so that SD can get the senior managaments attention that
it deserves?
In the last formal meeting, I was facilitating my clients on converting the
small model that we (consultants) had built to a flight simulator in which
managers can perform what-if (scenario) analyses for the strategic planning
effort that this company will eventually do. In the process, the clients
were more interested in defining their challenges than looking for some
root causes. I didnt recall, in my SD training at MIT, seeing an application
of SD (ST) methodology in defining challenges and problems. As a student,
I was shown several techniques of applying SD (ST) methodology to "resolve"
problems (identify root causes). Am I missing anything?
I recalled one of the famous Ackoffs fable in which a problem definition is
as important as its probable solutions. I am wondering if SD is also suitable
for identifying challenges or problems. Has anyone used SD/ST methodology for
this purpose?
Thanks and best regards,
-Benny Budiman-
bbens@MIT.EDU
I recently observed that SD has an academic smell that drives away senior
executives. It was my first SD consulting experience in which I worked with
the companys IT staff. My clients, the IT people, are optimistic for the
success of SD or ST in resolving some operational glitches in their company.
One of them, however, is quite shy on the stock-and-flow diagram for its
intimacy with mathematical (differential) equations, numerical integration
and everything else that have an academic "odor" but is very fond of the
causal loop diagram (ST).
Has anyone seen similar experience? If so, what should we do to mitigate
the academic smell so that SD can get the senior managaments attention that
it deserves?
In the last formal meeting, I was facilitating my clients on converting the
small model that we (consultants) had built to a flight simulator in which
managers can perform what-if (scenario) analyses for the strategic planning
effort that this company will eventually do. In the process, the clients
were more interested in defining their challenges than looking for some
root causes. I didnt recall, in my SD training at MIT, seeing an application
of SD (ST) methodology in defining challenges and problems. As a student,
I was shown several techniques of applying SD (ST) methodology to "resolve"
problems (identify root causes). Am I missing anything?
I recalled one of the famous Ackoffs fable in which a problem definition is
as important as its probable solutions. I am wondering if SD is also suitable
for identifying challenges or problems. Has anyone used SD/ST methodology for
this purpose?
Thanks and best regards,
-Benny Budiman-
bbens@MIT.EDU
-
jimhines@interserv.com
- Member
- Posts: 41
- Joined: Fri Mar 29, 2002 3:39 am
Questions about application of SD?
I have had clients who find causal loops exciting and who dont find stock and flows
exciting. (And, I have also had clients who liked stock and flows, but didnt warm up to
loops). But, the problem with stock-and-flow diagrams has never been expressed to me as
a problem with being overly academic or mathematical. In fact, I have a hard time
understanding your clients feeling. Stocks and flows have a fluid analogy; not a
mathematical one. When I use stocks and flows with a client, I often dont get into any
mathematics at all.
I wonder if what your client objects to is the amount of operational detail in stock and
flow diagrams (he might find it slow-going and boring) or, perhaps, he finds feedback
extremely interesting (which it is) and misses it in the stock and flow diagrams.
As for what to do: If you are creating a model, I think you need the kind of operational
detail that stocks and flows can provide. If this individual has unique information on
the operational detail; the easiest way for him to provide it will be via stock and flow
diagrams -- he just has to bite the bullet. If other folks also have the operational
knowledge, however, perhaps you could use them to get the stock and flow structure. You
could run the structure quickly by your senior client; and then keep this client engaged
with the feedback insights coming out of the simulation. (If he is THE senior manager it
is **critical** to keep him involved!)
Benny, I did not understand what you were saying about "defining challenges", but it
sounded interesting. Could you expand? Thanks.
Regards,
Jim Hines
JimHines@Interserv.Com
LeapTec and M.I.T.
exciting. (And, I have also had clients who liked stock and flows, but didnt warm up to
loops). But, the problem with stock-and-flow diagrams has never been expressed to me as
a problem with being overly academic or mathematical. In fact, I have a hard time
understanding your clients feeling. Stocks and flows have a fluid analogy; not a
mathematical one. When I use stocks and flows with a client, I often dont get into any
mathematics at all.
I wonder if what your client objects to is the amount of operational detail in stock and
flow diagrams (he might find it slow-going and boring) or, perhaps, he finds feedback
extremely interesting (which it is) and misses it in the stock and flow diagrams.
As for what to do: If you are creating a model, I think you need the kind of operational
detail that stocks and flows can provide. If this individual has unique information on
the operational detail; the easiest way for him to provide it will be via stock and flow
diagrams -- he just has to bite the bullet. If other folks also have the operational
knowledge, however, perhaps you could use them to get the stock and flow structure. You
could run the structure quickly by your senior client; and then keep this client engaged
with the feedback insights coming out of the simulation. (If he is THE senior manager it
is **critical** to keep him involved!)
Benny, I did not understand what you were saying about "defining challenges", but it
sounded interesting. Could you expand? Thanks.
Regards,
Jim Hines
JimHines@Interserv.Com
LeapTec and M.I.T.
-
jsterman@MIT.EDU (John Sterman)
- Senior Member
- Posts: 54
- Joined: Fri Mar 29, 2002 3:39 am
Questions about application of SD?
Re: Benny Budimans comments
1. Does SD have an academic smell? I dont appreciate the implication
that we academics are malodorous, and hope that Benny can find a
different metaphor for his complaint
Nevertheless, it seems to me
the odor was largely self-inflicted in this case. A good consultant
tailors the tools and presentation of concepts to the needs, background
and capabilities of the client. Actually, I believe you should try to
stretch the clients mental models a little and not dumb down the
material to the lowest common denominator. This is delicate, and
requires a good relationship with the client. Still, in the end, one
cant go faster than the client. You should not be showing them how
numerical integration works if they dont need to know, want to know, or
if it is not relevant to the issue as they see it. Next time, start
where they are. If it becomes appropriate to build a formal model, then
you can build a formal model; if having seen model output, the client
then wants to know how the model calculates the variables, then you can
explain numerical integration. Consultants do, I think, have a
responsibility to encourage clients to ask these questions if they dont
ask them themselves, but presenting all the details of modeling
methodology before the client has even formed a question or need about
them in their mind is inappropriate and likely to generate defensiveness
and irritation. It seems to me that there are many examples of SD
getting and holding top management attention - and when it does, it is
because the SD consultant or facilitator presented it as a tool in
service of the clients issues, not as a Methodology.
2. Defining challenges: One of the biggest misconceptions about system
dynamics is that it is good for solving problems but not for
articulating them, for identifying challenges, or dealing with the
messes we face (in Ackoffs terms). The origin of this great lie is
unknown, but has been echoed down the years by various folks who lump
system dynamics in with so-called hard OR (operations research)
techniques like linear programming. Good system dynamics practice
encourages people to challenge the boundaries of their mental models,
that is, to reframe and rearticulate their basic conception of the
nature of the problem they face. I and others have written extensively
on this use of SD to identify challenges, and I believe many of the best
consultants in the field are using it effectively for this purpose.
Interested readers might refer to my paper Learning in and about complex
systems, System Dynamics Review, vol 10, 1994, for discussion. Here is
a brief excerpt of a relevant section:
"Some scholars argue that it is not possible to create valid formal
models of human systems; that formal modeling can at best provide
quantitative precision within preexisting problem definitions but cannot
lead to fundamentally new conceptions (for various views see Dreyfus and
Dreyfus 1986 and the discussion in Lane 1993). On the contrary,
formalizing qualitative models and testing them via simulation often
leads to radical changes in the way we construe reality and carve
problems out of `messes (Ackoff 1979). Simulation speeds and
strengthens the learning feedbacks. Discrepancies between the formal
and mental model stimulate improvements in both, including changes in
basic assumptions such as model boundary, time horizon and dynamic
hypotheses (see Forrester 1985 and Homer 1992 for philosophy and an
example). Without the discipline and constraint imposed by the rigorous
testing enabled by simulation, it becomes all too easy for mental models
to be driven by unconscious bias or deliberate ideology."
John Sterman
jsterman@mit.edu
1. Does SD have an academic smell? I dont appreciate the implication
that we academics are malodorous, and hope that Benny can find a
different metaphor for his complaint
Nevertheless, it seems to me the odor was largely self-inflicted in this case. A good consultant
tailors the tools and presentation of concepts to the needs, background
and capabilities of the client. Actually, I believe you should try to
stretch the clients mental models a little and not dumb down the
material to the lowest common denominator. This is delicate, and
requires a good relationship with the client. Still, in the end, one
cant go faster than the client. You should not be showing them how
numerical integration works if they dont need to know, want to know, or
if it is not relevant to the issue as they see it. Next time, start
where they are. If it becomes appropriate to build a formal model, then
you can build a formal model; if having seen model output, the client
then wants to know how the model calculates the variables, then you can
explain numerical integration. Consultants do, I think, have a
responsibility to encourage clients to ask these questions if they dont
ask them themselves, but presenting all the details of modeling
methodology before the client has even formed a question or need about
them in their mind is inappropriate and likely to generate defensiveness
and irritation. It seems to me that there are many examples of SD
getting and holding top management attention - and when it does, it is
because the SD consultant or facilitator presented it as a tool in
service of the clients issues, not as a Methodology.
2. Defining challenges: One of the biggest misconceptions about system
dynamics is that it is good for solving problems but not for
articulating them, for identifying challenges, or dealing with the
messes we face (in Ackoffs terms). The origin of this great lie is
unknown, but has been echoed down the years by various folks who lump
system dynamics in with so-called hard OR (operations research)
techniques like linear programming. Good system dynamics practice
encourages people to challenge the boundaries of their mental models,
that is, to reframe and rearticulate their basic conception of the
nature of the problem they face. I and others have written extensively
on this use of SD to identify challenges, and I believe many of the best
consultants in the field are using it effectively for this purpose.
Interested readers might refer to my paper Learning in and about complex
systems, System Dynamics Review, vol 10, 1994, for discussion. Here is
a brief excerpt of a relevant section:
"Some scholars argue that it is not possible to create valid formal
models of human systems; that formal modeling can at best provide
quantitative precision within preexisting problem definitions but cannot
lead to fundamentally new conceptions (for various views see Dreyfus and
Dreyfus 1986 and the discussion in Lane 1993). On the contrary,
formalizing qualitative models and testing them via simulation often
leads to radical changes in the way we construe reality and carve
problems out of `messes (Ackoff 1979). Simulation speeds and
strengthens the learning feedbacks. Discrepancies between the formal
and mental model stimulate improvements in both, including changes in
basic assumptions such as model boundary, time horizon and dynamic
hypotheses (see Forrester 1985 and Homer 1992 for philosophy and an
example). Without the discipline and constraint imposed by the rigorous
testing enabled by simulation, it becomes all too easy for mental models
to be driven by unconscious bias or deliberate ideology."
John Sterman
jsterman@mit.edu
-
jimhines@interserv.com
- Member
- Posts: 41
- Joined: Fri Mar 29, 2002 3:39 am
Questions about application of SD?
On Thu, 4 Jul 1996, Kim Warren <kim@farthing.stargate.co.uk> wrote:
>Youre right - Ive noticed the same, but we absolutely have to crack this
>one. Causal loops are completely inadequate for any serious attempt to
>model real situations and test policy options.
I strongly disagree with the critism of causal loops. First, our field is
deeply concerned with how real causal loops generate real behavior. As a
consequence, a causal loop representation is often helpful -- not instead of
a stock-and-flow diagram, not instead of a mathematical model -- but
alongside them.
Jim Hines
jimhines@interserv.com
>Youre right - Ive noticed the same, but we absolutely have to crack this
>one. Causal loops are completely inadequate for any serious attempt to
>model real situations and test policy options.
I strongly disagree with the critism of causal loops. First, our field is
deeply concerned with how real causal loops generate real behavior. As a
consequence, a causal loop representation is often helpful -- not instead of
a stock-and-flow diagram, not instead of a mathematical model -- but
alongside them.
Jim Hines
jimhines@interserv.com
-
jimhines@interserv.com
- Member
- Posts: 41
- Joined: Fri Mar 29, 2002 3:39 am
Questions about application of SD?
On Fri, 5 Jul 1996, Jay Forrest <pteragen@neosoft.com> wrote:
> "What is a causal loop diagram
>which contains formulas and provides graphical output...?"
Well, the diagram is a causal loop diagram. The formulas are equations and
the output is simulation output.
A causal loop diagram is only a diagram. It does not contains equations nor
provide graphical output. The equations and output are separate, not part
of the diagram.
The same is true of stock and flow diagrams: Equations and output are
separate.
Regards,
Jim Hines
JimHines@Interserv.Com
> "What is a causal loop diagram
>which contains formulas and provides graphical output...?"
Well, the diagram is a causal loop diagram. The formulas are equations and
the output is simulation output.
A causal loop diagram is only a diagram. It does not contains equations nor
provide graphical output. The equations and output are separate, not part
of the diagram.
The same is true of stock and flow diagrams: Equations and output are
separate.
Regards,
Jim Hines
JimHines@Interserv.Com
-
jimhines@interserv.com
- Member
- Posts: 41
- Joined: Fri Mar 29, 2002 3:39 am
Questions about application of SD?
On Sat, 6 Jul 1996, Jay Forrest <pteragen@neosoft.com> wrote:
>As a chemical engineer I well understand the additional insight provided by
>the stock and flow concept of SF over causal loop ....
The implication that SF provide MORE insight than causal loop diagrams is not
correct. Each kind of diagram provides a DIFFERENT insight. CL helps you see
the feedback; SF helps you see the integrations.
Regards,
Jim Hines
jimhines@interserv.com
>As a chemical engineer I well understand the additional insight provided by
>the stock and flow concept of SF over causal loop ....
The implication that SF provide MORE insight than causal loop diagrams is not
correct. Each kind of diagram provides a DIFFERENT insight. CL helps you see
the feedback; SF helps you see the integrations.
Regards,
Jim Hines
jimhines@interserv.com
-
jimhines@interserv.com
- Member
- Posts: 41
- Joined: Fri Mar 29, 2002 3:39 am
Questions about application of SD?
On Sat, 6 Jul 1996, Jay Forrest <pteragen@neosoft.com> wrote:
> I use whichever approach [i.e. SF or CLD]
>the client is more comfortable with (and to be honest that is often CLD as
>stock and flow seems to create some difficulties for some people).
Jay,
I think the approach a client is most comfortable with depends on what the
problem is and what the level of detail is.
If you are portraying, say, the aging of a workforce; a stock and flow
diagram will be simpler than a causal loop diagram.
On the other hand, if you are portraying how overtime can cause fatigue which
can create rework and the need for more overtime; a causal loop diagram will
be simpler.
A problem where there is a clear, physical "main chain" (to use Barry
Richmonds terminology) translates well into S&F. A problem with intangibles
and a strong loop, translates well into causal diagrams.
When I do begin with a causal loop diagram, I like to translate it into a
stock and flow diagram before writing equations. Although I see how this
step might be dispensed with; it helps me get "operational" (to again use
Richmonds terminology).
Regards,
Jim Hines
LeapTec
JimHines@Interserv.Com
> I use whichever approach [i.e. SF or CLD]
>the client is more comfortable with (and to be honest that is often CLD as
>stock and flow seems to create some difficulties for some people).
Jay,
I think the approach a client is most comfortable with depends on what the
problem is and what the level of detail is.
If you are portraying, say, the aging of a workforce; a stock and flow
diagram will be simpler than a causal loop diagram.
On the other hand, if you are portraying how overtime can cause fatigue which
can create rework and the need for more overtime; a causal loop diagram will
be simpler.
A problem where there is a clear, physical "main chain" (to use Barry
Richmonds terminology) translates well into S&F. A problem with intangibles
and a strong loop, translates well into causal diagrams.
When I do begin with a causal loop diagram, I like to translate it into a
stock and flow diagram before writing equations. Although I see how this
step might be dispensed with; it helps me get "operational" (to again use
Richmonds terminology).
Regards,
Jim Hines
LeapTec
JimHines@Interserv.Com
-
jimhines@interserv.com
- Member
- Posts: 41
- Joined: Fri Mar 29, 2002 3:39 am
Questions about application of SD?
On Mon, 8 Jul 1996, Jay Forrest <pteragen@neosoft.com> wrote:
> My comments focused more
>on the clients nature and yours more on the problem. I think you will agree
>that in real life both should generally be considered!
Absolutely!
Jim Hines
jimhines@interserv.com
> My comments focused more
>on the clients nature and yours more on the problem. I think you will agree
>that in real life both should generally be considered!
Absolutely!
Jim Hines
jimhines@interserv.com