QUERY Models, Problems and Systems

This forum contains all archives from the SD Mailing list (go to http://www.systemdynamics.org/forum/ for more information). This is here as a read-only resource, please post any SD related questions to the SD Discussion forum.
Monte Kietpawpan <kietpawpan@
Junior Member
Posts: 12
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by Monte Kietpawpan <kietpawpan@ »

Posted by Monte Kietpawpan <kietpawpan@yahoo.com>

PROBLEM

However novice modelers carry out SD projects,
they will rarely get simple models. This is a big problem
when they should build a simple model.
The problem has been discussed in the recent issues of
SDR, but its root cause has not yet been clearly stated.
As far as I see, the problem is caused by the adoption
of conventional modeling processes proposed in
classic SD texts. Following these texts, modelers will
always define the model purpose BEFORE they
build a model. And by accepting the ultimate purpose
of SD (i.e., to improve the system performance),
they will set similar purposes and will conceptualize all
components considered relevant to their purposes.
Such a model purpose reflects an implicit assumption
that modelers are either managers or managers' consultants
who are interested in solving the existing dynamic
problems that jeopadize the sustainability of the systems
they are in. They are not scientists who are free to select
issues to investigate and to publish their investigation
results in journals. They are not those who should build
simple models that are easy to develop, to write, to review,
and to publish quickly.

MY SOLUTION
To get a simple model, I altered the SD paradigm by
inversing some initial steps in the SD modeling process.
The model purpose was defined only AFTER an initial
model was developed. This process led to the simple
model (first-order system) circulated via
http://www.gotoknow.org/file/philosophist/P-003.pdf

Here, it is essential that we ask not what structure
might address the stated model purpose, but ask
for what purposes a given simple model can serve.
In this way, I am more like a scientist who builds
a (simple) theory looking for concrete application than
a manager who identifies concrete problems looking for
(usually necessarily complex) theoretical formulation.

Regards,
M. Kietpawpan
Posted by Monte Kietpawpan <kietpawpan@yahoo.com>
posting date Wed, 7 May 2008 02:00:19 -0700 (PDT)
_______________________________________________
""Kim Warren"" <Kim@strategyd
Member
Posts: 36
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""Kim Warren"" <Kim@strategyd »

Posted by ""Kim Warren"" <Kim@strategydynamics.com>

SDMAIL Dr John P Weldon wrote:
> The 'rule' therefore needs to be substantially redefined along the lines
> below.
>
> If a genuine 'problem' can be identified of smaller content and
> scope than that of the system in which it resides, modeling shall be
> confined to entities (below the number needed to model the system
> itself) that can adequately explain and resolve the 'problem'. In
> all other cases modeling of the system shall be regarded as
> appropriate and necessary.

I'd like to build on John's post, because I too have been puzzled by
where this mantra of 'model the problem, not the system' came from and
what its justification might be. We 'model systems' in all kinds of
ways, whether it is designing an aircraft, assessing the weather,
designing a piece of software and so on. And we use those models to
allow us to manage the resulting system, where that may be possible.
There seem to be two broad problems with just 'modeling the problem'

1. Unless we are very careful, we may miss factors that are significant
contributors to the problem because we decide on boundaries that seem to
make sense, but are not in fact comprehensive. Consequently, we may
solve *this* occurrence of the problem, but leave the organization
exposed to recurrences that are due to different factors - e.g. we fix
service quality now by modelling and identifying how best to develop a
service-support team, but next week the problem comes back because the
sales force manages to sell a different mix of products.

2. We do not leave management with any means of continuing to manage the
system as a whole. This would seem to be like giving an aircraft pilot a
sequence of indicators and instructions to get out of a tail-spin, but
no overall control system or procedures for actually flying the plane in
general.

I can see circumstances where modelling a problem would be valuable,
with caveats about 1 and 2 above, but would we not rather models to
provide a set of policies for managing things well so we don't get into
trouble in the first place?

Kim Warren
Posted by ""Kim Warren"" <Kim@strategydynamics.com>
posting date Wed, 7 May 2008 08:14:32 +0100
_______________________________________________
Jean-Jacques Laublé <jean-jac
Senior Member
Posts: 61
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by Jean-Jacques Laublé <jean-jac »

Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr>

Hi Kim

I have a different understanding of the mantra :
model the problem and not the system.

Of course some years ago, I did not understand
this the same way I understand it to day from the
lessons of experience.

I try strictly to model a problem and not a system
because I set a clear objective to my model: solve the
problem or answer a precise question that will alleviate it.

I will after my modelling effort, be able to compare the results
obtained with the initial objective.

If I model a system, there is no clear objective and only a vague
hope that something positive might come out of it.

Modelling the problem is too much simpler and less pretentious.

Of course I do not deny that the scope of that way of working is
limited and that it can generate limited policies but I think that
it has the great advantage of being simpler and quicker to model and
it is always possible to change the model later on or make another one
once there is a first understanding although eventually limited of the
whole system.

Another reason of working toward a problem and not a system is that
a system is difficult to define, entailing a lack of rigour when defining it.

On the contrary a problem may be much more precisely defined at the
beginning.
Regards.
Jean-Jacques Laublé Eurli Allocar
Strasbourg France
Posted by Jean-Jacques Laublé <jean-jacques.lauble@wanadoo.fr>
posting date Wed, 7 May 2008 15:39:21 +0200
_______________________________________________
Jack Harich <register@thwink.
Member
Posts: 39
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by Jack Harich <register@thwink. »

Posted by Jack Harich <register@thwink.org>


Jack Harich wrote:
> '... the SD rule of don't model a system, model a problem. Or in
> science, solve the specific problem first, and then develop a more
> powerful generalization from that. The latter is the real payoff'.

Dr John P Weldon replied:
> Strong indications, that all is not well with the above 'rule', are
> provided by the following:
> * The Ingalls case (/Interfaces/, K Cooper, 1980); one of the
> brightest jewels in the SD crown.
> * Corporate models that are used for system-wide activity and
> resource control, planning, budgeting, and accountability etc.

He then offers an improved rule:
> If a genuine 'problem' can be identified of smaller content and scope
> than that of the system in which it resides, modeling shall be
> confined to entities (below the number needed to model the system
> itself) that can adequately explain and resolve the 'problem'. In all
> other cases modeling of the system shall be regarded as appropriate
> and necessary.
> The existing 'rule' is pernicious because it discourages modeling at
> the *system level* in cases where that is appropriate. It also
> contributes to confusion on the part of potential clients for SD
> applications. The existing 'rule' is part of the baggage that needs to
> be jettisoned, if the SDS is to have any real prospect of growing the
> SD field.
I agree. But a model at the ""system level"" is not the same as the
modeler who sets forth to model a ""system"" instead of a problem. In the
second use of the word ""system,"" the model will likely end up being of
little value, due to being too large, too hard to comprehend, too
expensive, too hard to maintain, and most of all, not enough focus on
particular problems that arise in the system.

John Sterman, in Business Dynamics page 89, writes that:

""The most important step in modeling is problem articulation. What is
the issue the clients are most concerned with? What problems are they
trying to address? What is the real problem, not just the symptom of
difficulty? What is the purpose of the model?

""A clear purpose is the single most important ingredient for a
successful modeling study.

""Beware the analyst who proposes to model an entire business or social
system rather than a problem. [This essentially says don't model a
system, model a problem.] Every model is a representation of a system --
a group of functionally interrelated elements forming a complex whole.
But for a model to be useful, it must address a specific problem and
must simplify rather than attempt to mirror an entire system in detail.""

And Jay Forrester writes in Urban Dynamics, page 113 that:

""The first step in modeling is to generate a model that creates the
problem.""

I can't find where I ran across the rule ""Don't model a system, model a
problem."" But I think the above quotes try to say what that (overly?)
short rule really says. We build models to solve problems, not to model
whole systems and then hope such models will be useful.

For example, Sterman writes that ""Ingalls spent several years pursuing
the claim [an expected $500 million cost overrun], but traditional
project management tools did not provide a means to quantify the ripple
effects. Ingalls turned to system dynamics to quantify the delay and
disruption created by Navy design changes. The model, developed by
Pugh-Roberts Associates of Cambridge, Massachusetts, simulated all
phases of the DD and LHA projects, from the award of the contract to the
delivery of the last ship, then 5 years in the future.""

So the impetus was to model a problem. That this required modeling all
phases of the DD and LHA projects caused the model to be quite large.
Yes it was a system. But it was not the whole system, even of the
project part of Ingalls. It was a subset, just enough necessary to
achieve the model goal, which was to quantify extra costs due to Navy
design changes.

Now suppose someone had modeled Ingall's system of projects, with no
thought to what problems it would be used for. The model would then
include all sorts of things that would have been of little use here,
like inclusion of safety principles (these are a big deal in engineering
these days), staff retention and training, weather and supply chain
disruptions, etc.

Instead, page 58 of Sterman shows how the dynamic hypothesis focused on
these work phase stocks: Work to be Done, Work Really Done, Known Work,
and Undiscovered Work. The model grew from there.

Even big system models are built to address problems. Company wide
models are build so that management can make better decisions. They
reduce the problem of not enough structural or quantitative data, which
leads to better analysis and better solution alternatives evaluation.
Such models emphasize areas where a particular company expects it will
most run into problems, rather than modeling the whole equally.

National models do the same thing but the problems are different. But
all national models focus somewhat on addressing particular areas, so
that they may be better understood and managed.

The short rule is so terse it's easily misleading, so I like your
attempt at improving it.

But to me the short form says it all: When you're modeling, don't think
about mimicking a system. Instead, ""generate a model that creates the
problem"" in the system of interest.

Thanks, John, for such a thoughtful post.

> Posted by ""Kim Warren""
> SDMAIL Dr John P Weldon wrote:
>
>> The 'rule' therefore needs to be substantially redefined along the
>> lines below.
>>
>> If a genuine 'problem' can be identified of smaller content and
>> scope than that of the system in which it resides, modeling shall be
>> confined to entities (below the number needed to model the system
>> itself) that can adequately explain and resolve the 'problem'. In all
>> other cases modeling of the system shall be regarded as appropriate
>> and necessary.
>
> I'd like to build on John's post, because I too have been puzzled by
> where this mantra of 'model the problem, not the system' came from and
> what its justification might be. We 'model systems' in all kinds of
> ways, whether it is designing an aircraft, assessing the weather,
> designing a piece of software and so on. And we use those models to
> allow us to manage the resulting system, where that may be possible.
It's a fine point I raised, with the maxim ""Don't model a system, model
a problem."" Stated this way, it emphasizes the model boundary question:
What should be in a model and what should not? What will help to
understand and solve the problem should be included. The rest of what's
in a system should not.

Thus one is actually never (?) modeling a system, but a problem
expressed as part of a system. Perhaps that's the nub, as Mark Twain
would have said. :-)

And now for a bit of humor. Pale faced analysts and this list need a bit
of that now and then. See:
http://www.timsheppard.co.uk/story/dir/twain.html
where Twain uses ""nub"" six times. This story has long been a favorite of
mine, though the ending dialect is a little dated.

So what is the nub of this discussion?

> There seem to be two broad problems with just 'modeling the problem'
> 1. Unless we are very careful, we may miss factors that are
> significant contributors to the problem because we decide on
> boundaries that seem to make sense, but are not in fact comprehensive.
> Consequently, we may solve *this* occurrence of the problem, but leave
> the organization exposed to recurrences that are due to different
> factors - e.g. we fix service quality now by modelling and identifying
> how best to develop a service-support team, but next week the problem
> comes back because the sales force manages to sell a different mix of
> products.
>
> 2. We do not leave management with any means of continuing to manage
> the system as a whole. This would seem to be like giving an aircraft
> pilot a sequence of indicators and instructions to get out of a
> tail-spin, but no overall control system or procedures for actually
> flying the plane in general.
Certainly good points. This builds on Sterman on page 89 (see earlier
post) when he says ""What is the real problem, not just the symptom of
difficulty?"" As far as I can tell, your suggestions go beyond the
original problem and get to additional real problems, ones management
probably doesn't even know they have. This is, of course, one of the
hallmarks of a good analyst.
> I can see circumstances where modelling a problem would be valuable,
> with caveats about 1 and 2 above, but would we not rather model to
> provide a set of policies for managing things well, so we don't get
> into trouble in the first place?
Touché! Proactive is always better than reactive solution of difficult
problems, as the world is about to find out on the sustainability problem.


Jack
Posted by Jack Harich <register@thwink.org>
posting date Wed, 07 May 2008 20:53:12 -0400
_______________________________________________
""Kim Warren"" <Kim@strategyd
Member
Posts: 36
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""Kim Warren"" <Kim@strategyd »

Posted by ""Kim Warren"" <Kim@strategydynamics.com>

Thanks Jack - I guess I'm questioning the assumption that we always build models
*because* there is 'a problem' - surely people commonly want models [of whatever
kind] to help understand and better-manage something, in the absence of any
immediate problem they are seeking to solve. I see that problem-oriented models
can be necessary and useful, but are not system-wide ones also?

Kim Warren
Posted by ""Kim Warren"" <Kim@strategydynamics.com>
posting date Thu, 8 May 2008 09:01:58 +0100
_______________________________________________
Bill Braun <bbraun@hlthsys.co
Member
Posts: 43
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by Bill Braun <bbraun@hlthsys.co »

Posted by Bill Braun <bbraun@hlthsys.com>

John Weldon asks if the SD problem focus rule is deficient, citing some
examples of systemic models that delivered results. Kim Warren, in
response to Weldon, notes, ""I too have been puzzled by where this mantra
of 'model the problem, not the system' came from and what its
justification might be.""

The seminal works in SD are all systemic in scope - the problem focus
for Industrial Dynamics was the ""success of the enterprise"" (p 13), for
Urban Dynamics it was ""urban decay and revival"" (p ix), and for World
Dynamics the ""behavior of the world system"" (p ix). All broad and still
problem focused.

I suspect that the admonition on modeling the problem is not meant to
limit scope, but to remind us to model only what is necessary to produce
reference mode behavior. It may be that ""only what is necessary"" is
complex and far reaching.

A quick review of SDR papers on group model building reveals they all
stress diversity of mental models. A number of books off the shelf all
consistently point to variables, reference mode, and dynamic hypothesis
for model construction. (I rely on a paper by Jim Hines, with minor
variations.)

While reference modes (and the dynamic hypothesis) may change as
additional mental models are brought into the conversation (i.e., the
iterative nature of conceptualization), would they not by themselves
define the scope of the model, whether that turns out to be ""problem"" or
""systemic"" in nature? The model boundaries are less a matter of a
declaration early in the process and more a matter of what emerges from
the reference modes.

Bill Braun
Posted by Bill Braun <bbraun@hlthsys.com>
posting date Fri, 09 May 2008 05:33:01 -0400
_______________________________________________
""Nabil"" <nabil@xlnt-perform
Newbie
Posts: 1
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""Nabil"" <nabil@xlnt-perform »

Posted by ""Nabil"" <nabil@xlnt-performance.com>

Hi every body

I am a new comer to the SD society and have been following with much
interest the discussions on strategy and other technical issues. I am
puzzled that some of the issues are of basic character as for example
the exchange of opinions on whether to model the system or the problem.
I thought the system is derived from the problem. How can one define the
boudaries of the system without first defining the problem ? isn't it
so that system is a model of the problem,

so what´s the problem

Nabil Mikati
Posted by ""Nabil"" <nabil@xlnt-performance.com>
posting date Thu, 8 May 2008 14:34:58 +0200
_______________________________________________
j-d <jaideep@optimlator.com&g
Junior Member
Posts: 10
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by j-d <jaideep@optimlator.com&g »

Posted by j-d <jaideep@optimlator.com>

I think modeling a system is fine - it can be a small abstract model
or a large, detailed model of the system. The exercise of modeling the
system can in itself shed light on some problems and/or help
understand things better.

I think the mantra of ""modeling the problem, not the system"" may have
come out of consultancy experience in which groups of people would
lose sight of the problem they were trying to solve and keep on adding
to the model, irrespective of whether the additions led to more
understanding or any solutions to the problem. I have seen it myself
when the models become lop-sided because of group-think and
loud-mouthed screamers. In such a case, the facilitator may rope the
herd by insisting on modeling the problem, not the whole system.

Other than that I see nothing wrong with modeling a system if one has
the time and money (more a luxury in academia than in business);
mathematics, physics and economics are full of such examples. Problems
may start or motivate the modeling process, but they don't have to -
why did the apple hit my head (gravity - Newton); what will I see if I
am in an elevator traveling at the speed of light (Special Theory of
Relativity - Einstein); what if we had more than three dimensions
(vector algebra - don't know who invented this).

Best regards

Jaideep Mukhejee, Ph. D.
Posted by j-d <jaideep@optimlator.com>
posting date Thu, 8 May 2008 15:09:46 -0500
_______________________________________________
<George.McConnell@selex-comms
Junior Member
Posts: 2
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by <George.McConnell@selex-comms »

Posted by <George.McConnell@selex-comms.com>

If I may put in my 2p-worth on the subject of ""model the problem not the
system""...

I have, I guess two relevant points to make on this. The first is that
whatever is modelled is ""a system"" because we have defined it as such
therefore the dictum is rendered rather meaningless in my view.

The second is that I think that the 'spirit' of the dictum (as against
the actual words) is something that it is necessary to take on board
when carrying out any modelling (not just SD). Too often I am asked to
""build a model"" - the person asking me to do this has rarely considered
what this is to be a model of - they expect a model of ""the system""
without really considering what particular ""system"" is of interest in
their problem. My response of ""what do you want a model of?"" usually
results in a significant period of ""umming and ahhing"" indicative of the
fact that the reality is that they haven't a clue.

I've seen many models of ""the system"" consume much resource and produce
little worthwhile output - they are usually large models that are close
to as difficult to understand as ""the system"" itself. As Kim says, in
many cases we actually want a model that will allow us to manage the
system - I would argue that the model is still not a model of ""the
system"", but of ""the system that manages the system"" (I hope that
doesn't come across as mere play on words) and this latter is actually
""the problem"" that we are managing.

Sorry if that is not clear, it is one of those subjects where the
language gets in the way of itself!

regards
*George*
Posted by George.McConnell@selex-comms.com
posting date Thu, 8 May 2008 14:05:08 +0100
_______________________________________________
Jack Harich <register@thwink.
Member
Posts: 39
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by Jack Harich <register@thwink. »

Posted by Jack Harich <register@thwink.org>

Kim.

If ""people commonly want models to help understand and better-manage
something"" - Then that is the problem the model is solving. It's just
thinking at a higher level than specific, bird-in-the-hand problems.
It's solving a general class of expected problems, as well as
opportunities, rather than a single issue that's already arrived.

A classic example of this approach may be seen in the following quote,
from one of the most successful cases in the history of modeling:

""Large oil companies have long been big users of scenario building. The
popularity is often attributed to one early success. In the 1970's, a
planning group at Shell Oil generated scenarios that could affect the
price of oil, an uncertainty important to many of the company's
projects. One scenario was that prices would remain stable. Another was
that OPEC would demand much higher prices. As the latter scenario was
developed, it became increasingly clear to the team that the scenario
was not just plausible, it was highly likely. However, when the team
warned upper management, no changes in company decisions could be
observed. So, the team went one step further. They described the logical
ramifications of the scenario in terms that leadership would understand
— it meant slow growth for the industry and the possibility that OPEC
countries would take over Shell's oil fields. When the Arab oil embargo
did occur in 1973, only Shell was reasonably prepared.""

From: http://www.prioritysystem.com/reasons4b.html

Also, I have a small problem with the terminology in your post. As soon
as a problem solver starts thinking in terms of a ""system-wide"" model,
their work begins to drift away from being a ""problem-oriented"" model.
This is the danger the ""don't model a system, model a problem"" principle
warns us against.

Perhaps there are better terms?

Jack
Posted by Jack Harich <register@thwink.org>
posting date Thu, 08 May 2008 09:54:07 -0400
_______________________________________________
""Jay Forrest"" <systems@jayf
Junior Member
Posts: 6
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""Jay Forrest"" <systems@jayf »

Posted by ""Jay Forrest"" <systems@jayforrest.com>

Thanks for bringing this up, Kim!

I sympathize with your question for though the nature of system dynamics
includes consideration of boundaries, there is a certain tension between the
concepts of modeling the problem and modeling the system. It would seem to
me that in an ideal world the boundary examination related to modeling the
problem SHOULD expose the pertinent factors outside the problem details that
deserve consideration. In practice, I have to question that the boundary
examination is routinely adequate and would suggest that the ideal path
involves some balance between modeling the problem and modeling the system.

System modeling tends to be difficult for the resulting models are: 1) too
large, 2) increasingly involve extraneous variables and inputs beyond
control, and 3) likely to increasingly involve interpretation rather than
observable, clearly pertinent issues, as perhaps three of the most
significant barriers. And, as Jack suggests, the meaning and goal for the
model grows fuzzier as one models the system.

A successful, clean, problem-oriented model is a wonderful thing and can be
highly influential for its obvious pertinence and relative clarity. But it
seems critical to consider at some point the larger systems with which the
problem oriented model fits and functions. At risk of being overly
simplistic, imagine modeling a brake problem on a car that has a cracked
block or a leaking radiator. Failure to recognize the implications of other
areas are likely to result in model results that are locally valid but
trivial or meaningless to the entity in question.

If the goal is to provide insights that have maximum value, I must conclude
that some balance between problem and system oreintation are necessary and
feel it is appropriate to ask the possibly painful question, ""Is it possible
that overly narrow modeling has contributed to the failure of SD to achieve
the impact on business, industry, and government that we all (I think) feel
it is capable of?"" The same question could also be asked of system-wide
models. Again, it seems clear that each problem demands some different
balance between focus on problem and whole system.

Thanks!
Jay Forrest
Posted by ""Jay Forrest"" <systems@jayforrest.com>
posting date Thu, 8 May 2008 09:49:37 -0500
_______________________________________________
""Jack Homer"" <jhomer@comcas
Member
Posts: 21
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""Jack Homer"" <jhomer@comcas »

Posted by ""Jack Homer"" <jhomer@comcast.net>

Re: modeling problems rather than systems.
I have been a little dismayed to see extended discussion of yet another
question that was answered in our field decades ago; see, for example,
Industrial Dynamics (JWF, 1961), section 5.1, page 60:

""In practice there will be no such thing as THE model of a social
system, any more than there is THE model of an aircraft...In designing a
dynamic simulation model of a company or economy, the factors that must
be included arise directly from the questions that are to be answered.
In the absence of an all-inclusive model, which we are unlikely to
achieve, there may well be different models for different classes of
questions about a particular system. And a particular model will be
altered and extended as each new question is explored.""

Some of the discussion here has considered ""system"" to be broader than
""problem"", and has therefore wondered whether the ""model a problem not a
system"" dictum may be too limiting. In practice, however, much of the
value in the dictum has been to give us permission to model variables
BEYOND those normally considered in a narrow conception of what the
system is. The ""system"" is often considered in a physical sense
(perhaps coming from a traditional operations research perspective) to
comprise only the production division and not the sales division, or
only the company and not its suppliers and customers, or only the
hospital and not the community that surrounds it. We are properly urged
to model problems (or, as they are sometimes known, issues or questions)
rather than systems, not only because systems are potentially without
limit in breadth and detail (where do we draw the boundary? when do we
stop disaggregating?), but also because the common view of systems is
actually TOO constraining with respect to boundaries, leading to the
kind of silo thinking and suboptimization that has been forever the bane
of operations research.

We should always emphasize with novices to our field the importance of
modeling problems/issues/questions rather than systems, and should not
blur the lines of this important principle.

- Jack Homer
Posted by ""Jack Homer"" <jhomer@comcast.net>
posting date Fri, 9 May 2008 09:15:50 -0400
_______________________________________________
""Kim Warren"" <Kim@strategyd
Member
Posts: 36
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""Kim Warren"" <Kim@strategyd »

Posted by ""Kim Warren"" <Kim@strategydynamics.com>

Thanks for all the responses on this. Maybe my thinking is too
simplistic, but I thought the implied distinction concerned [a] trying
to solve a specific, if complicated challenge at a point in time [though
it may recur] vs. trying to guide performance of a system through a
potentially wide variety of circumstances in which an equally wide
variety of specific problems may arise.

I have heard it said that SD models should be treated like Kleenex -
used once and thrown away, because the next problem will always be
different. Yet we have models like People Express, and many others,
where multiple decisions need taking, or policies developed, to deal
with all kinds of possible circumstances. Surely sustaining profitable
growth for a large, successful airline is a quite different 'problem'
from rescuing a small, declining, and about-to-be-bankrupt one? Yet the
fundamental structure of the system is the same, and the model of that
system is certainly useful.

What I guess many of us try to do is leave people with a model - whether
a fully whirring and churning simulation or just a robust, quantified
diagrammatic picture - that continues to help them avoid problems and
sustain performance for long continuous periods, and also helps them
respond when specific problems turn up. I would certainly concede that
such a general-purpose model may need updating, developing or extending,
but at its heart has a continuing life. I would also concede [and as
others suggest, this may be where the guidance originated] the danger in
trying to model the entire system in all its detail.

If we define 'good management of the system' to be 'the problem' then
all we are left with is semantics and as other posts have noted, surely
the guiding rule is meaningless?

Kim Warren
Posted by ""Kim Warren"" <Kim@strategydynamics.com>
posting date Fri, 9 May 2008 14:23:15 +0100
_______________________________________________
George Richardson <gpr@albany
Member
Posts: 20
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by George Richardson <gpr@albany »

Posted by George Richardson <gpr@albany.edu>

The suggestion that we can ""model systems"" seems to me like the
assignments that buffaloed me when I was an undergraduate: ""Write a
2000-word essay on Hamlet,"" or ""...19th century England,"" or ""...the
U.S. criminal justice system."" I remember doing very badly on such
assignments and thinking it was because I couldn't write.

Later I realized it was not because I couldn't write but because I had
nothing to say. I needed a more targeted problem statement before I
could have thoughts worth writing down, and as an undergraduate I didn't
have tools to help me craft a more targeted writing purpose.

""Build a model of New York City"" would be something like these undergrad
essay assignments that left me clueless. That's why I tend to be one of
those that repeats the mantra that we can't model systems but must model
problems. We'd have to know what it is about NY City that we would be
trying to address. I think of whatever that is as ""the problem.""

We, and our clients and students, need tools to help us focus. The
tools that I suggest for my students to begin a system dynamics study
are named in the following list:

*Problem focus
*Problem dynamics
*Context
*Audience
*Model purposes
Model boundaries
Temporal - what's the time horizon?
Conceptual - what's included and what's excluded?
Causal - what's endogenous and what's exogenous?
Aggregation
Reference modes
Initial policy options
Model sectors
Important processes in each sector
Important levels and associated rates in each process and/or sector
Apparently important feedback loops
Next steps

The first five are starred because they seem to be the really crucial
ones, involved in almost anyone's suggestions for how to begin to tackle
a serious study. The unstarred ones that follow are more specially
useful for projects that are aimed at building a system dynamics model
or a well-grounded stock-and-flow/feedback map.

These steps or stages, or something like them, move us pretty quickly
from thoughts about modeling ""a system"" to thoughts about what it is
that we or our clients really want to understand.

One last thought about ""systems"": Systems theorists and thinkers have
historically had a tough time defining what a ""system"" is. It has
helped me to think that the pictures, maps, and models that emerge from
the stages listed above are ""the system"" we are talking about. I'd even
go so far as to say ""the system"" doesn't exist until we think it into
existence. As Adam Smith once so insightfully said, ""a system is an
imaginary machine invented to connect together in the fancy those
different movements and effects which are already in reality
performed."" We don't know ""the system"" until we think about something
systemically.

We should be able to drop the discussion of modeling a problem versus
modeling a system, in favor of talking wisely about how smart systems
thinkers and modelers suggest how we should go about getting started on
a study. The wisdom we need is in those details, not in ""problem""
versus ""system.""

..George

George P. Richardson
Chair of public administration and policy
Rockefeller College of Public Affairs and Policy
University at Albany - SUNY, Albany, NY 12222
Posted by George Richardson <gpr@albany.edu>
posting date Sat, 10 May 2008 09:24:20 -0400
_______________________________________________
""Jay Forrest"" <systems@jayf
Junior Member
Posts: 6
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""Jay Forrest"" <systems@jayf »

Posted by ""Jay Forrest"" <systems@jayforrest.com>

Hi Jack!

That was beautifully written and well said! Bravo!

I have no qualms with the modeling of systems. My experiences working with
clients with Barry Richmond led me to deeply appreciate the insights
available from simple, pertinent, problem oriented models. Two issues
regarding problem oriented models seem pertinent and I would welcome your
perspectives.

The first issue relates to boundaries and perception. When we set the
boundaries of a model we effectively define the universe. The implication
that nothing else is pertinent and tends to restrict subsequent broader
exploration and consideration. As a result the setting of the boundaries
seems critical (and it is my impression that most of the SD community would
agree). The broader, omitted interconnectivity of problem-oriented models
opens them to failure over time due to both unrecognized influences and
unintended consequences. It seems critical to me to discuss the system
within which the problem oriented model resides such that the clients will
appreciate the limits to the validity of the problem oriented model and
possible implications. Discussions with clients who have used SD suggest to
me that a significant portion of their failure to pursue SD over time is
that they tend to find SD answers don't work over time - which is ultimately
IMO a failure of them to appreciate the limits of the model. And please
note...this is not a plea for modeling the system but rather recognizing the
system - a case IMO where causal loop diagramming or even clever extraneous
variables shown but not included in the model might be helpful. It seems
critical that the client be given (or develop in the client) an appropriate
appreciation of the limits of the model.

The second issue relates to boundaries, but in a different way. If we let
the client define the problem we can easily become focused on a reductive
facet of a closely integrated system. If you go into a transmission shop and
ask them to replace your transmission and the car has a cracked block,
should they replace the transmission and ignore the block and let it fail
later. I have to suspect that some SD work has lost credibility specifically
due to similar fate. It seems to me that, as a professional, the
modeler/facilitator has an ethical responsibility to strive to recognize the
key dynamics of the system and to guide the client to a broader perspective
of the system under study when appropriate.

I would welcome your comments!

Thanks in advance!
Jay Forrest
Posted by ""Jay Forrest"" <systems@jayforrest.com>
posting date Sat, 10 May 2008 08:58:02 -0500
_______________________________________________
""Jack Homer"" <jhomer@comcas
Member
Posts: 21
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""Jack Homer"" <jhomer@comcas »

Posted by ""Jack Homer"" <jhomer@comcast.net>

Jay Forrest writes:

""Discussions with clients who have used SD suggest to me that a
significant portion of their failure to pursue SD over time is
that they tend to find SD answers don't work over time - which is
ultimately IMO a failure of them to appreciate the limits of the model.
And please note...this is not a plea for modeling the system but rather
recognizing the system - a case IMO where causal loop diagramming or
even clever extraneous variables shown but not included in the model
might be helpful. It seems critical that the client be given (or develop
in the client) an appropriate appreciation of the limits of the model.""

""It seems to me that, as a professional, the modeler/facilitator has an
ethical responsibility to strive to recognize the
key dynamics of the system and to guide the client to a broader
perspective of the system under study when appropriate.""

These are both important points. The way I like to put them together in
practice is this: First, during the conceptualization stage, I guide
the client toward a broader view of their issue, going beyond the usual
organizational boundaries to include more actors and levels of influence
than are typically considered and over a longer time frame. The result
of this exploration is a rich causal-loop diagram, a ""big picture"".
But, for a variety of practical reasons, the formal simulation model
(though still having its share of dynamic complexity) often ends up
focusing on only a portion of the big picture, namely those aspects that
spark the response, ""These are the things we most need to understand
right now for our next steps in planning or consensus building or
decision making."" But later, as the lessons of the somewhat narrower
formal model are being absorbed, the modeler needs to remind the client
again of the bigger picture. This review of the bigger picture may
suggest moving on to further phases of formal modeling, or, if not that,
at the least a discussion of how the findings of the formal model should
be qualified based on the broader context that surrounds it.

This is an approach I have taken frequently in recent years, especially
with highly multidimensional and multiscale public health issues; for
example, in studies of antibiotic resistance, diabetes, obesity, and
most recently, cardiovascular disease.

Jack Homer
Posted by ""Jack Homer"" <jhomer@comcast.net>
posting date Sat, 10 May 2008 23:22:34 -0400
_______________________________________________
""John Gunkler"" <jgunkler@sp
Member
Posts: 20
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""John Gunkler"" <jgunkler@sp »

Posted by ""John Gunkler"" <jgunkler@sprintmail.com>

How many of us, working with a real client, would ever stop our interview
when the client says they want to ""better manage the system""? I certainly
never did. It begs questions such as:

""Why do you feel you need to better manage the system? What's wrong now?""
[Obvious answer would state or imply the existence of a problem.]
Or, ""What do you need to do better?""
[Obvious answer would state or imply the existence of an opportunity
for improvement.]

So, at this point we have something to work on together -- solving a problem
or finding a way to create or take advantage of an opportunity.

And we're then modeling problems (or opportunities), not ""systems.""

John Gunkler
Posted by ""John Gunkler"" <jgunkler@sprintmail.com>
posting date Sat, 10 May 2008 10:17:25 -0400
_______________________________________________
""Kim Warren"" <Kim@strategyd
Member
Posts: 36
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""Kim Warren"" <Kim@strategyd »

Posted by ""Kim Warren"" <Kim@strategydynamics.com>

Thanks for your wise guidance Jack. I'd just ask, though, that we not
discourage people from resurrecting old questions [and answers].

First, there is a continuing risk that sound guidance be misunderstood
or misapplied. In the context of this particular topic, I have
repeatedly come across professionals interpreting the slogan 'model the
problem, not the system' to mean that *no* model should ever be expected
to have a continued validity or usefulness. This stance brings dangers
of its own - e.g. [a] the model might seem to 'solve the problem', but
has insufficient scope so that small changes in the problem situation
means it gives incorrect conclusions we under-sell the value of SD
models because our audience thinks the often-large effort and cost has
no continuing value.

Next, new-comers face a daunting challenge in finding and identifying
exactly the nuggets of gold in the seminal books and articles. Even if
they could, there's additional value to be had from hearing more and
understanding the nuances of long-established principles, as opposed to
just reading the words in print.

Then, there's always the possibility - heaven forbid - that accepted
wisdom is not always entirely correct! No field moves forward without
challenge.

Kim Warren
Posted by ""Kim Warren"" <Kim@strategydynamics.com>
posting date Mon, 12 May 2008 07:46:42 +0100
_______________________________________________
""Douglas Franco"" <dfranco@c
Junior Member
Posts: 8
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""Douglas Franco"" <dfranco@c »

Posted by ""Douglas Franco"" <dfranco@cantv.net>

George and Jack insightful remarks concerning the modeling a problem or
a system is quite useful. The Yogi Berra' advice, ""If you do not know
where are you going, you may not get there"", comes into play. However,
some models of a problem, may lead to modeling a system, when the model
transcend the scope of the original problem. For instance, take the
classical Inventory- Backlog model. As we all know, increasing
inventories diminish delivery delay (increases customer quality), and
recover market share. The dynamic of quality and productivity is
endogenously implied. If you think of stocks as accumulation of
resources(like machines, finished products, man-hours, money and even
knowledge) and backlog as accumulation of customer needs, as Kim Warren
has suggested, then Quality = Shipment/Backlog, and Productivity =
Shipment/Inventory. , are faces of the same coin. Total Quality
Management, TQM, means satisfying customer needs, while Total
Productivity Maintenance, TPM, means using inventories of resources.
System Dynamics creates a new paradigm where two apparent contradictory
management approaches are integrated in a powerful fancy, able to
address thousands of problems at the same time, diminishing the waste of
resources, by diminishing the waste of opportunities (shipment over
backlog). The so called quality paradox, ""worse before the better"",
becomes a small part of the graphical display of the results, as John
Sterman has pointed out. In this case your are modeling a problem, but
at the same time you are modeling a system, because, you are addressing
simultaneously millions of problems who share the same fancy, firmly
catch by our stock and flow hooks. The classical John Sterman paper
about the Kuhn theories certainly illuminates this path which leaves
behind problems and systems. After all, DYNAMO was built to model a
problem and ends up modeling many of them. Sometimes, the ""root cause""
is not only to represent managers' mental models, but to change them, as
pointed out by Peter Senge (one of the dimensions of the fifth
discipline: the personal growth). It takes purposes to model a system.
The model is a means, but it can also be an end.

Douglas
Posted by ""Douglas Franco"" <dfranco@cantv.net>
posting date Sun, 11 May 2008 12:58:16 -0400
_______________________________________________
""Douglas Franco"" <dfranco@c
Junior Member
Posts: 8
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""Douglas Franco"" <dfranco@c »

Posted by ""Douglas Franco"" <dfranco@cantv.net>

Jay Forrest ask about our experience making SD efforts last.

You can make SD work over time, if you want to do so. Management
Information Systems have implicit rules which may determine behavior,
because their implied policies drive the system elsewhere. John
Morecroft developed principles relating SD models with Information
Systems, which are useful to incorporate the model findings into the
company operation. Levels mirror into files, rates mirror into computer
programs, and policies command decisions. You have to align company
resources with the implementation of the new policies. In the language
of nonlinear dynamics, ""we have to create a stable node around
management objectives"", without this effort, SD intervention may not
last, because Information Systems, budgets and other endogenous
influences also determine behavior.

Douglas Franco
Posted by ""Douglas Franco"" <dfranco@cantv.net>
posting date Mon, 12 May 2008 10:21:17 -0400
_______________________________________________
""John Morecroft"" <jmorecrof
Junior Member
Posts: 10
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""John Morecroft"" <jmorecrof »

Posted by ""John Morecroft"" <jmorecroft@london.edu>

Jack (Homer)
I was struck by your observation that a well defined problem situation
can actually be broader than the 'perceived' system. So I ended-up
spending part of a sunny May Sunday thinking about model
conceptualisation.......

I often say to my MBA students at LBS that SD professionals prefer to
model a problem situation, rather than 'the system' in order to be
discriminating about which factors to exclude from the model. Modelling
is the art of 'leaving things out'. A disciplined and reliable way to
converge on essential structure is important. But I accept your
corollary that, if one's starting viewpoint is narrow and event-oriented
then yes, you first need to expand the boundary of factors deemed
relevant. Sterman's multi-loop representation of factors affecting
traffic congestion (BD Chapter 5) is a great example. The question is
when to stop. I explain this winnowing-down of messy situations in
terms of the iterative process of modelling: 'I Spy dynamics in the
complexity of everyday life and can discover (following SD guidelines)
underlying feedback structure'. See my SMBD book Chapter 5 on 'Cyclical
Dynamics and the Modelling Process'.

To begin modelling with problem articulation and a dynamic hypothesis is
both a dictum and distilled wisdom of the field, nicely captured in
figures 3-1 and 3-2 of Sterman's BD chapter 3. However I must admit
that sometimes my own experience of modelling has been different -
perhaps because modelling is fundamentally a creative process. In
particular I remember a modelling project with BBC World Service, a
well-respected international radio broadcaster specialising in news and
current affairs. The stated purpose of the project was to 'develop a
model to explore 10-year strategy scenarios and to support the
organisation's bid to government for future funding'. For this purpose,
World Service was conceived as a dynamical system in which public funds
from Government are deployed in various ways to build broadcasting
assets that collectively attract listeners. There was no explicit
dynamic hypothesis, but nevertheless the project team was able to create
a reasonably compact and focussed model built around eight stock
accumulations. The structure took shape without a particularly clear
up-front or ex-ante view of feedback loops. Did this project depart
from dictum or simply re-interpret the dictum to fit the situation?
(More information about the project and the model can be found in my
1999 article 'Visualising and Rehearsing Strategy', Business Strategy
Review, 10(3) 17-32.)

Was this project experience an anomaly? I doubt it. I think it's
simply a manifestation of a need for 'crafting freedom' during model
conceptualisation (but without losing sight of one's discipline
guidelines). Let me finish with a short story about the art, craft and
science of model conceptualisation. The story is an edited excerpt from
my 2000 article 'Creativity and Convergence in Scenario Modelling',
97-115 in a Festschrift honouring Erich Zahn, (editors Habenicht and
Waeschser), Schaeffer-Poeschel-Verlag, Spring 2000.

************************************************************************
***
Conclusion
Model conceptualisation requires an unusual blend of creative and
convergent thinking. And that is why conceptualisation is such a
rewarding activity. There is no recipe for building a good system
dynamics model of a firm, an industry or a society. There are just
guidelines and principles of feedback systems - the theory, craft and
distilled wisdom of the discipline (as found in the literature and SD
textbooks). In my experience the process is one of discovery with sudden
breakthroughs: using expert knowledge, conversations, the collective
mental database of the modelling team and principles of modelling to
make sense of dynamic complexity. Sooner or later a pattern emerges, a
framework for the model, to be refined and clarified through mapping and
dialogue. But progress toward this framework can be uneven - sometimes
it is very fast, sometimes it is slow.

I am reminded of the time many years ago when I was on the faculty at
MIT's Sloan School. I used to run a semester-long course for MBAs and
PhDs on ""Applications of Industrial Dynamics"". The course required
students to conceptualise and build a model addressing a practical
business problem. These students had already been introduced to the
basic principles of system dynamics and so were ready and eager to
undertake a self-contained project of their own choosing. The course
included some lectures as well as seminar-style discussion of
models-in-progress. I thought it was important to include a lecture on
model conceptualisation, so I invited Jay Forrester to talk about his
experiences. I thought he would talk about the steps he followed in
this creative stage of modelling. He did, but not in the way I had
expected. He picked two quite different examples from his repertoire of
projects: the corporate growth model he built for the fledgling Digital
Equipment Corporation in the early 1960s, and the World Dynamics model
from the early 1970s.

His lecture had a dramatic effect on my students (and me too). He began
by holding-up a single sheet of paper. It contained two large ovals -
one labelled ""company"" and the other labelled ""market"". Between these
two ovals were lots of connecting arrows, some going from the company to
the market and some going the other way. He then went on to explain
that this single page with its ovals and arrows was the result of two
years model conceptualisation while he was sitting on the board of the
newly formed Digital Equipment Company. He stressed that his efforts
were by no means full-time. But more importantly he made the point that
he needed this elapsed time to think how best to approach the problem of
representing Digital as a growth firm. Along the way he had rejected
many possibilities to avoid detail unnecessary for exploring the
dynamics of growth over a ten-year period (for example he chose to
ignore individual product lines, many of which would come and go over
ten years). Thereafter only eight weeks were required to create the
entire growth model of 200 equations.

After explaining much more about the structure of the Digital Equipment
model he then moved to his second example - World Dynamics. At this
point he held-up the two pages of the World Dynamics book that show the
complete stock and flow structure of the model and the information
network (the same picture I mentioned at the start of this article). He
then said he had created a rough sketch of this picture in an 8 hour
transatlantic flight from Paris to Boston following a meeting of the
Club of Rome! (You can now see the original for yourself. It appears
as figure 7 in David Lane's 2007 article, 'The power of the bond between
cause and effect: Jay Wright Forrester and the field of system
dynamics', SDR 23 95-118, the issue celebrating 50 years of system
dynamics).

The contrast between the two examples was dramatic. Two years for a
sector map of Digital Equipment Corporation, and eight hours for a
close-to-complete structural map of World Dynamics. The lesson is that
good model conceptualisation cannot be tightly scheduled. Creativity
and convergence need time. It is much better to wait for a satisfactory
modelling framework to come to mind than to rush into premature equation
formulation and simulation. Sometimes conceptualisation happens very
quickly, as for World Dynamics, and sometimes more gradually as for
Global Oil. Occasionally, as with the Digital model, the right approach
is a long time in gestation. The reward is a framework for thinking
about dynamic complexity with the power to capture the knowledge, time
and attention of policymakers, and even other academics. And that's
where the fun of modelling lies too.

_________________________________

John Morecroft | Senior Fellow
Management Science and Operations
London Business School
Posted by ""John Morecroft"" <jmorecroft@london.edu>
posting date Mon, 12 May 2008 13:16:45 +0100
_______________________________________________
Bill Harris <bill_harris@faci
Senior Member
Posts: 51
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by Bill Harris <bill_harris@faci »

Posted by Bill Harris <bill_harris@facilitatedsystems.com>

""SDMAIL John Morecroft"" <jmorecroft@london.edu> writes:
> > The contrast between the two examples was dramatic. Two years for a
> > sector map of Digital Equipment Corporation, and eight hours for a
> > close-to-complete structural map of World Dynamics. The lesson is that
> > good model conceptualisation cannot be tightly scheduled. Creativity
> > and convergence need time. It is much better to wait for a satisfactory
> > modelling framework to come to mind than to rush into premature equation
> > formulation and simulation.

John,

Thanks for this. I've been pondering this question since the thread
started. Coincidentally, I was thumbing through my Fink and
Christiansen Electronic Engineer's Handbook (Second Edition) recently
and found their chapter on Systems Engineering. Section 5.12 is called
""Parsimony and Validation,"" and I think the parsimony idea may relate to
this issue. While we wrestle explicitly with validation from time to
time (there's a chapter in Business Dynamics devoted to the subject), I
wonder if we condense the idea of parsimony into ""Model the problem, not
the system."" Parsimony sounds at once more artful and more craft-like,
something emerging from experience at creating models that err on one
side or the other.

Starting as an electrical engineer, I have modeled circuits and systems
since university days. Certainly by the time I was doing engineering
for a living, parsimony was wrapped up in figuring out the essential
pieces to include in a model to gave useful results without creating a
baroque model that obfuscated causality. Sometimes decisions were
obvious; sometimes they were honed from the lessons of failed attempts
that landed in the ditch on either side of the parsimonious road.
""Model the problem, not the system"" may serve as a useful reminder that
parsimony and purpose count, but it's perhaps too high up on a ladder of
abstraction to define parsimony for those midway between starting out
(when it may work well) and well experienced in the field (see ""Before a
person studies Zen, mountains are mountains and waters are waters...""
on http://www.geocities.com/Tokyo/8669/rantsandzen.htm).

Despite our more than occasional desire on this list to make SD easy to
learn quickly (and I am a fan of Barry's goals of doing just that), your
contribution is reminding me that SD is perhaps better seen as a craft,
a skill that grows in somewhat varied ways amongst varied people and
that takes time and practice to ripen. Neither engineers nor violinists
happen overnight, either.

Thoughts?

Bill
- --
Bill Harris
Posted by Bill Harris <bill_harris@facilitatedsystems.com>
posting date Tue, 13 May 2008 09:02:29 -0700
_______________________________________________
""Jack Homer"" <jhomer@comcas
Member
Posts: 21
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""Jack Homer"" <jhomer@comcas »

Posted by ""Jack Homer"" <jhomer@comcast.net>

Kim Warren writes:
""I'd just ask, though, that we not discourage people from resurrecting
old questions [and answers].""

People should be encouraged to ask any question they want, and novices
will, of course, end up asking old questions. That's fine. I'm not
asking questioners to censor themselves, but have rather asked that the
inexperienced think twice before laying out a thousand-word treatise
attempting to answer (from their perspective typically coming from some
other field, and ignorant of ours) something already well answered in
our field. I posted previously about how the extended (and repeated)
discussion of old questions can be dismaying to experienced SD people,
and I have already received a few private emails from experienced SD
people confirming that this is exactly why they have largely disengaged
from the listserve.

Jack Homer
Posted by ""Jack Homer"" <jhomer@comcast.net>
posting date Mon, 12 May 2008 08:32:57 -0400
_______________________________________________
""John Morecroft"" <jmorecrof
Junior Member
Posts: 10
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""John Morecroft"" <jmorecrof »

Posted by ""John Morecroft"" <jmorecroft@london.edu>

Bill
Thanks for your reflections (quoted below) stemming from system
engineering. Yes, parsimony is a good word to describe the convergence
and focus that modellers ultimately seek. However the advice to
iteratively model the dynamical problem situation is probably still the
most reliable way in SD to achieve parsimony..... plus lots of practice
with illustrative models and real world situations.

------------------------------------------------------------------------
--
""Coincidentally, I was thumbing through my Fink and
Christiansen Electronic Engineer's Handbook (Second Edition) recently
and found their chapter on Systems Engineering. Section 5.12 is called
""Parsimony and Validation,"" and I think the parsimony idea may relate to
this issue. While we wrestle explicitly with validation from time to
time (there's a chapter in Business Dynamics devoted to the subject), I
wonder if we condense the idea of parsimony into ""Model the problem, not
the system."" Parsimony sounds at once more artful and more craft-like,
something emerging from experience at creating models that err on one
side or the other"".

_________________________________

John Morecroft | Senior Fellow
Management Science and Operations
Posted by ""John Morecroft"" <jmorecroft@london.edu>
posting date Wed, 14 May 2008 08:58:16 +0100
_______________________________________________
""Christina Spencer"" <Christ
Junior Member
Posts: 2
Joined: Fri Mar 29, 2002 3:39 am

QUERY Models, Problems and Systems

Post by ""Christina Spencer"" <Christ »

Posted by ""Christina Spencer"" <Christina@strategydynamics.com>

Jack Homer says "" I'm not asking questioners to censor themselves, but
have rather asked that the inexperienced think twice before laying out a
thousand-word treatise attempting to answer (from their perspective
typically coming from some other field, and ignorant of ours) something
already well answered in our field.""

I agree that it is perfectly reasonable that people with questions that
may have come up before should investigate before posting old questions
- but how are they supposed to do that?

If you put yourself in the position of a SD-newbie and imagine a
reasonable question you might have - then go hunting around the SD
website and see how easy or hard it is to find an answer.

.. Isn't this precisely what a Wiki is ideal for? I am sure there are
many on this list who know a lot more about them than I ... Suggestions
anyone?

Christina Spencer
Posted by ""Christina Spencer"" <Christina@strategydynamics.com>
posting date Wed, 14 May 2008 13:45:45 +0100
_______________________________________________
Locked