Page 1 of 1

Limitations of System dynamics?

Posted: Mon Apr 15, 2002 11:21 am
by zenabraham@aol.com
Greetings,

My personal point of view, due to spark controversy, is that nothing is too
complex to represent with System Dynamics. The only limitation is the
knowledge and imagination of the researcher / programmer, and the software
that person is using.

Moreover, and perhaps for reasons known best to you, I didnt receive a
great, detailed explanation of what youre doing. Its a bit laden with
jargon that seems to be unique to your business. If you can explain what
youre doing in baby steps of detail, that would help.

Zennie Abraham
From: zenabraham@aol.com

Limitations of System dynamics?

Posted: Mon Apr 15, 2002 2:37 pm
by Latin Hypercube
In my experience SD is very applicable to modelling business situations, that
is it can be used to map out the critical aspects of a business and evaluate
options - strategic or tactical. The key seems to be not to try to model the
whole business as it operates but to pick out the key resource stocks and
flows and build an explanatory model. Ideally, one will also have historical
data from the business against which to test the fit of your model.

I greatly recommend Kim Warrens book Competitive Strategy Dynamics for its
focus on using SD in business/strategy with John Stermans Business
Dynamics an excellent resource for detailed models of SD in use and some of
the more technical aspects of the approach.

Alan Coughtrey
From: Latin Hypercube <latinhypercube@ntlworld.com>

Limitations of System dynamics?

Posted: Mon Apr 15, 2002 3:28 pm
by "Jos De Neve/ESG"
Some advice

Be conscious of dynamics; (time, variations over time, delays)
no dynamics ... No SD
(a non cartesian way of thinking is mandatory; that is the most
difficult)

Be conscious therefore: no loops, no system, no dynamics

Many business problems are quite sizeable;
is yours sufficiently fence-able/containable?
Do you have sufficiently feasible data?
Do you sufficiently know the problem and the problem construct?

Make an exercise using a rather simple problem

Hope to have helped a bit


_______________________
jos de neve
From: "Jos De Neve/ESG" <executive.support.group@pandora.be>

executive support group
snepkaai 6
B 9000 gent - belgium
http://www.esg-int.com

Limitations of System dynamics?

Posted: Mon Oct 14, 2002 12:30 pm
by "Woncheol Kwak"
Dear SD-er worldwide,

I am new to System dynamics and struggling to find some ways to applying
it to a commercial project. The project is agent-based simulation
building and I dont have much experience in it either. -.-; (My
profession was Database and mobile programming) At first I tried to use
UML as in most other SW projects but soon I realized that its not that
fit for this area, and it threatened the effective communications
between my customer and programmers. Then I came across System Dynamics
(John Stermans book) and was immediately attracted in it. However, it
was not that easy for me to model my customers extremely complex
business logic with SD. Now what Im wondering is, whether this
difficulty is due to my lack of experience in SD or another bad choice.

My question:
Does anyone have a comprehensive list of pros and CONS of using System
Dynamics in business modeling?
Can anyone tell me the limitations of System Dynamics and the cases in
which Id better not use it?

The entities in my customers business process seem to be too complex to
me to model with System Dynamics and I dont have much time to
thoroughly examine the potentials of SD...if its the right choice,
everybody will be happy. But if its not, itll be too late after I
realize that.

Thanks in advance.

Woncheol Kwak
Director/Project Manager
HUMANEX, Inc.
Korea
woncheol.kwak@humanex.net

Limitations of System dynamics?

Posted: Tue Oct 15, 2002 10:31 am
by "Jim Hines"
Woncheol Kwak wonders about whether he should use system dynamics:

>The entities in my customers business process seem to be too complex to
>me to model with System Dynamics and I dont have much time to
>thoroughly examine the potentials of SD.

Woncheol,

The good news is that the process is not too complex. The bad news is
you dont have enough time to learn system dynamics and then take a
system dynamics approach to the problem.

Jim Hines
From: "Jim Hines" <jhines@MIT.EDU>
MIT

Limitations of System dynamics?

Posted: Wed Oct 16, 2002 6:30 pm
by Timothy Fong
Alan,

Im trying to work with a client to model the marketing of a
new product. They dont have historical data or even
normalizing industry-wide data, and so cant see how SD can
help them understand and make decisions on how they can market
and what the range of revenue could be based on various
variables.

Have you had experience with that in business simulations? I
think the problem is relatively well-defined. But the
challenge is they want data. Thanks.

Tim


---------------------------------------------------------
Timothy Fong
timfong@ureach.com
---------------------------------------------------------

Limitations of System dynamics?

Posted: Wed Oct 16, 2002 9:17 pm
by Bill Harris
Woncheol Kwak wrote:

> Does anyone have a comprehensive list of pros and CONS of using System
> Dynamics in business modeling?
> Can anyone tell me the limitations of System Dynamics and the cases in
> which Id better not use it?

Better than pros and cons, I sometimes find Gomez and Probsts
taxonomy of problems and approaches to solutions helpful:

Simple problems: small number of variables, low coupling among
them. I find approaches such as Kepner-Tregoes helpful for these.
(Simple is not necessarily the same as easy.)

Complicated problems: large number of variables, relatively strong
cross-coupling. Stable structure with little dynamic behavior.
Operations research often deals with this sort of issue.

Complex problems: complicated problems in which the interaction
among variables changes over time. This is the domain where system
dynamics shines.

Thats summarized from pp. 14-15 of Die Praxis des ganzheitlichen
Problemlösens, 2. Auflage.

I agree with Jim Hines and others, though. If youre just learning
system dynamics from a book, its too risky for a time-critical
customer project. Youd certainly be better off doing it your own way
this time or bringing in outside help. You might want to consider
preparing for future opportunities by getting some training and
experience.

Regards,

Bill
From: Bill Harris <bill_harris@facilitatedsystems.com>
--
Bill Harris 3217 102nd Place SE
Facilitated Systems Everett, WA 98208 USA
http://facilitatedsystems.com/ phone: +1 425 337-5541

Limitations of System dynamics?

Posted: Thu Oct 17, 2002 12:01 pm
by Alan Graham
Trouble is, SD is an extremely malleable process -- at heart, its just the
scientific method, with many potential tools and processes available.
Effective SD engagements can look like everything from group facilitation to
econometrics.

In practice, the limitations that most often constrain applicability (along
with schedule and budget) are much more with the system dynamicist than the
disciplines collective tools and processes. As Jim Hines has remarked in
this forum, beginners are pretty much constrained to applications for which
there are already well-known precedents and models that can be imitated
directly and fully.

So the most practical answer to Woncheol Kwaks question is: Ask whoever is
likely to be working the problem (potentially, just yourself). Ask them.
If they dont know, youre back to the beginners track.

cheers,

alan

Alan K. Graham, Ph.D.
PA Consulting Group

Alan.Graham@PAConsulting.com
One Memorial Drive, Cambridge, Mass. 02142 USA

Limitations of System dynamics?

Posted: Thu Oct 17, 2002 12:07 pm
by "Tom Forest"
UML produces static, detailed, non-runnable flowchart-like models. Think
Visio. System dynamics produces dynamics, general, runnable simulation
models in time series. They complement each other, but in my experience
do not overlap much. Think Powersim, Vensim, or iThink.

Having spent most of the last dozen years developing custom software, I
know what Woncheol Kwak is referring to. UML is Unified Modeling Language. Quoting from Grady
Booch, "UML User Guide:" "[It] is a graphical language for visualizing,
specifying, constructing, and documenting the artifacts of a
software-intensive system. The UML gives you a standard means of writing
the systems blueprints, covering conceptual items such as the business
processes and system functions as well as concrete items such as classes
written in a specific programming language, database schemas, and reusable
software components." To my eyes, it looks like flow charting. Its a
language for building static models, of listing the steps in a process
(say, ordering or production), which one can then use as a blueprint from
which to write software. I use it after having done the system dynamics
model to identify the critical process(es) that need improved
implementations. Do you have a reference mode of problematic behavior
that you want to explore? Do you have question about priorities and what
the critical processes are for improvement? Do you want to try different
policy implementations and explore their effects on the system as a whole?
Do you want to build a shared consensus between people about any or all
of these thins? System Dynamics can help. Having decided on the critical
process(es) for improvement and what the new policies and procedures in
that process are, do you want to clarify what software objects youll
need, what properties/methods/events they should have, and how they should
be organized to maximize software performance, flexibility and
maintainability? UML can help.

Tom Forest
tforest@prometheal.com

Limitations of System dynamics?

Posted: Thu Oct 31, 2002 9:59 am
by Latin Hypercube
Sorry for the long delay in replying, my travel schedule has kept me away from
email lists.

Ive made comments on my experience and your situation below. Its good to
hear from someone wanting to use the best tools available in client
engagements, I applaud you. That said, and as no doubt others will have
pointed out, Id advise strongly against trying to learn and apply SD at the
same time. Either get some help or spend some of your spare time(!) on this
project learning and trying to use SD to generate insights for yourself, not
your client. I think you can expect a great benefit from doing that.

Regards UML etc. I think it can be useful to pick bits out of that method to
approach your problem. I can see that you can generate generic use cases
which map on to the flows from one stock to another, e.g. potential customer
places and order :: potential customers -1, customers awaiting delivery +1.

Otherwise I dont think UML fits your situation. Ive quite extensive
experience with UML from having run several large software development
projects but I dont attempt to use it in any way for business
strategy/planning work which is what I think youre trying to tackle.

First, some comments on my experience with using SD.

I can tell you that I have used SD as part of several larger engagements with
some success. These have included studies for european mobile telecoms
operators on the introduction of GPRS (2.5G) and UMTS (3G) services to the
market, the product/service development process for a very large mobile
operator and (in a more limited way) the R&D process of a pharmaceuticals
manufacturer. These are all mission critical issues with huge financial
implications which will take time to play out but the clients and I have been
very happy with what weve achieved.

Of course, using SD techniques in a management situation is not necessarily
straightforward. I can tell you the way I have approached things, at the
risk of opening myself up for (deserved :-)) criticism:

1. At the strategy level, we use some of the tools with management to explore
the business situation. This is but a method by which to explore a
"perceived reality" and generate some agreement on key aspects of the
situation. What is useful here are the concepts of stocks and flows and how
they are affected by a variety of factors and the consequences of delays in
feedback. This allows us to get at the important aspects of the situation
and build understanding of the dynamics.

One important achievement at this stage is to generate in the team, a sense of
the issues for resource allocation as the business situation develops through
time. In my view, organizations can too easily lock-in early resource
allocation decisions through their organizational and career structures -- if
you have a head of marketing, a head of fulfilment, a head of customer
support, each will naturally try to do their job and further their career by
maximising/minimizing the usual things of sales, expenses etc. and easily
make decisions which dont recognize the changing state of the business as a
whole. This brings us to another key issue -- the business situation can be
expected to change through time and you already have a mental model of how
that might happen -- you have to collect data and analyze information
continuously now to tell you where you are in the process (and potentially to
challenge your assumptions/business design). Data gathering needs to built
into the business and will itself require some substantial resource
allocation.

(Note that Ive not usually tried to introduce SD as a method to management
teams. Certainly, if one is not a master of this topic, and I am not, to do
so can be very hard going. That said, my pharma client did get into SD in
some detail which was helpful but my telecoms clients really didnt want to
know; probably a consequence of managing in businesses that havedoubled in
size each year of operation! This is where I expect criticism from the list
-- one shouldnt really be using a "black box" to give answers to a
management team that hasnt understood the scope and limitations of the
mechanism contained in that box. In my defence, I see that managing a
business all comes down to an exercise of managerial judgement and Im just
doing the best I can to inform that judgement and that my recommendations are
only a part of the whole decision process.)


2. At the planning level, we use tools and techniques that help us refine
estimates of resource allocations, e.g. how much to spend in marketing, what
size of call centre to build and when, etc. These naturally flow from (1.)
above and really take us down to a level of detail where we can check our
model of perceived reality for consistency and -- with the availability
of real world data and plausible estimates -- check it for sanity. The
various pieces of software that exist to speed up this process are quite
helpful here, e.g. IThink.

As the business rolls forward, it is important to build in data collection to
allow you to see where you are on the map and whether to challenge the map.
Eventually, this is all about doing the best to plan the necessary resource
allocations to support the business goal, manage changes to those resource
allocations and to occassionally see whether the map needs to be re-drawn.
Having a model built up in software that allows you to run what-ifs is of
great utility here as it will save you much time.


Secondly, some comments on the situation you describe.

It is unusual not to have data of any kind, since a "new" product is rarely
unique. In the case of mobile services of course, we are having to look at
all kinds of consumer data to guess/estimate plausible spending potentials
for the new services. (Obviously, we check our assumptions against real data
as we get it from the business in operation.) The discipline really must be
to exhaust yourself looking for data which give you the ability to make
planning investments.

Since I dont know anything about the product/service under consideration
here, I can only offer some very general pointers. Look at the reference
literature for better help. Anyway:

One model of the marketing chain is "AIDA" which describes the journey of an
individual from potential to actual customer. The acronym stands for
Awareness, Interest, Desire, Action. You might use this as a jumping
off point for your thinking about the central chain of stocks and flows
involved. For example, there will be a stock of consumers who are unaware of
your product (the whole universe at this point!). They will presumably
become aware of your product through your marketing efforts and word-of-mouth
recommendations from other customers.

Considering your marketing efforts, quickly brings you to considering the
actions of your rivals in this product market. So as well, as your marketing
effort, you possibly need to look at their marketing effort to work out your
effective "share of voice". (Referring back to an earlier point, if you make
a resource allocation to marketing spending in ignorance of your rivals and
they decide to spend more money you may not generate the awareness per dollar
you assume. You will have to adjust your marketing approach -- spend more or
go about it in a different way. In any case, having a model built in
software that can run what-ifs with will pay dividends.)

And so on along the customer acquisition chain. For example, are you seeding
influencers who will assist word-of-mouth? Do you have a partner programme
which adds utility to your product? When a customer decides to buy, can they
do it easily? Are you filling orders in the time customers expect to wait?
This is all standard marketing stuff but hopefully you can see how you might
look at it afresh with an eye to identifying important stocks, flow and
influencing variables.

Finally, good luck and enjoy!
From: Latin Hypercube <latinhypercube@ntlworld.com>

Limitations of System dynamics?

Posted: Wed Oct 14, 2020 7:31 pm
by "Ray on EV1"
The system dynamics methods are suitable in general. But changing paths in
the middle of a project might be more catastrophic than your current
situation.

You should re-think where you are: Your experienced in UML, your client is
not communicating well with your programmers. Communication difficulties in
UML have two typical sources - the facilitator doesnt know UML that well,
the participants dont really know the field they are expected to be
experienced in. SD has the advantage of not requiring either but you must
understand the methods. Since you are familiar with UML, you might consider
that your client isnt actually a domain expert in the material he is
supposed to provide. This is common for an executive on a tight budget not
wanting to allocate personnel to a project. You might also consider where
as you are familiar with UML and understand the process, you may not be well
versed at carrying (facilitating) others along.

So you are in the middle of a project and dont see the resources you need
to progress. Consider canceling the project and cutting short your clients
losses, or bring in a facilitator for one of the two methodologies.

Ray
From: "Ray on EV1" <rtjoseph@ev1.net>