Some clarification.

[bbens@MIT.EDU]

Esteemed SDists:

I should make some clarification notes on my last post.

The revelation I had was articulated to me by the IT staff with whom I was
working as a part of the Applications System Dynamics course at MIT. They
were trying to brief a new senior executive in their company and thats the
response they got. We, student consultants, never got a chance to present
our work to the executives in the company; therefore, didnt experience the
"complaint" first hand. I too was uncomfortable with the complaint because
the hard core "academic" content of SD adds tremendous value to the entire
process of problem solving.

I agree with John Sterman satement that "SD is *a tool* yet not a
methodology to resolve clients issues." In fact, it was the approach
I took when turning over our work to the IT staff last month.

The question about SD (ST) to identify challenges problems, rather than root
causes, was brought up by one of my clients, lets say Dilbert, who asked if
STs CLD can be used to shed some light on the issues of concern, e.g., is
low productivity a workforce effectiveness problem or a result of poor
management effort in the organization? Their comment was that such an
identification could happen through hypothesis testings involving a
significant modeling and simulation efforts. They are interested in a tool
that would help perform such a task in the beginning of the process, not at
the end of the process.

I must admit that I have not enough experience to answer such a question;
therefore, I must turn to the experts, esteemed SDists on this list, for
an answer.

My thanks for everyone who has responded either directly or through postings
on this lists. At the moment I am unable to respond in details due to
unfinished thesis work.

Best regards,
Benny
bbens@MIT.EDU

[jimhines@interserv.com]

My friend Benny Budiman asks about the use of system dynamics
in situations where a client has a number of possible
explanations for an issue.

Problems for which there are a number of potential explanations
are tailor-made for what we called the "standard approach" in
the applications class at M.I.T.

As Benny suggests each potential explanation is a hypothesis,
which usually can be articulated as a set of two or three
loops. A full view of the explanations can be created by
connecting the individual loop-hypothesis together. The
diagram is a sort of "blue print" for the subsequent modeling
effort.

The next step is to convert one of the loop-hypotheses into a
stock and flow diagram and then into a simulating model.
Analyzing the model will usually shed additional light on the
hypothesis. The next step is to add another hypothesis to the
growing model, again analyze the model. Etc., etc. In this
way, the model expands at the same rate as your understanding
of it. Not incidentally, insights emerge continually during
the modeling process.

Several things will happen:

A) As far as each of the original hypotheses is concerned,
there are three possibilities
1) You will find that the original hypothesis CANNOT
cause the problem.

2) You will find that the original hypothesis CAN
cause the problem, but your understanding of HOW it can cause
the problem, and under what conditions, will be greatly
expanded

Jim Hines
jimhines@interserv.com