Limitations of System dynamics?

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.
Locked
zenabraham@aol.com
Junior Member
Posts: 18
Joined: Fri Mar 29, 2002 3:39 am

Limitations of System dynamics?

Post 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
"Woncheol Kwak"
Newbie
Posts: 1
Joined: Fri Mar 29, 2002 3:39 am

Limitations of System dynamics?

Post by "Woncheol Kwak" »

"Jim Hines"
Senior Member
Posts: 88
Joined: Fri Mar 29, 2002 3:39 am

Limitations of System dynamics?

Post 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
Bill Harris
Senior Member
Posts: 75
Joined: Fri Mar 29, 2002 3:39 am

Limitations of System dynamics?

Post by Bill Harris »

"Tom Forest"
Junior Member
Posts: 2
Joined: Fri Mar 29, 2002 3:39 am

Limitations of System dynamics?

Post 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
Latin Hypercube
Junior Member
Posts: 2
Joined: Fri Mar 29, 2002 3:39 am

Limitations of System dynamics?

Post 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>
"Ray on EV1"
Member
Posts: 29
Joined: Fri Mar 29, 2002 3:39 am

Limitations of System dynamics?

Post 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>
Locked