Posted by Jim Duggan <JAMES.DUGGAN@NUIGALWAY.IE>
Hi,
I'd be interested to hear people's views on what
the best teaching model(s) are to start with when moving
from Causal Models to Stock and Flow models.
Ideally, I think such a model should be close to
its causal loop equivalent, have interesting feedbacks,
have one or two stocks, and not require more advanced
system dynamic concepts.
The one I'm considering at the moment is the Lotka Volterra Predator-prey system (as described in George Richardson's text ""Feedback Thought in Social Science and Systems Theory""), which has a causal model with 5 feedback loops, and a set of equations that map directly to this. The model also gives interesting feedback behaviours and would allow students to activate/deactive various loops and see the resulting change in system behaviour.
regards,
Jim.
Dr. Jim Duggan
Lecturer, Department of Information Technology,
NUI, Galway.
http://corrib.it.nuigalway.ie
Posted by Jim Duggan <JAMES.DUGGAN@NUIGALWAY.IE>
posting date Tue, 13 Sep 2005 20:56:08 +0100
Best first stock-flow model?
-
Jim Duggan JAMES.DUGGAN NUIGALWA
- Junior Member
- Posts: 6
- Joined: Fri Mar 29, 2002 3:39 am
-
Bill Braun bbraun hlthsys.com
- Member
- Posts: 29
- Joined: Fri Mar 29, 2002 3:39 am
Best first stock-flow model?
Posted by Bill Braun <bbraun@hlthsys.com>
I use two variations. In the first, I use traditional CLD modeling and put a box around stocks. It is not always real clear how the flows are connected to the stock (into and out of), but it does make accumulation explicit and students seem to be able to latch onto it pretty easily.
The other is to make all stocks and flows explicit (traditional SD
modeling) and fill in the rest using traditional CLD modeling.
I am experimenting with both and at present I do not have a feel for the clear benefit of one over the other.
Bill Braun
Posted by Bill Braun <bbraun@hlthsys.com>
posting date Wed, 14 Sep 2005 09:49:42 -0500
I use two variations. In the first, I use traditional CLD modeling and put a box around stocks. It is not always real clear how the flows are connected to the stock (into and out of), but it does make accumulation explicit and students seem to be able to latch onto it pretty easily.
The other is to make all stocks and flows explicit (traditional SD
modeling) and fill in the rest using traditional CLD modeling.
I am experimenting with both and at present I do not have a feel for the clear benefit of one over the other.
Bill Braun
Posted by Bill Braun <bbraun@hlthsys.com>
posting date Wed, 14 Sep 2005 09:49:42 -0500
-
John Gunkler jgunkler sprintmail
- Member
- Posts: 30
- Joined: Fri Mar 29, 2002 3:39 am
Best first stock-flow model?
Posted by ""John Gunkler"" <jgunkler@sprintmail.com>
Jim (and others),
I don't know if my approach applies in whatever context you're working, but with people who are employed and working on understanding their own processes, here's what I do:
1. I teach them traditional ""process flowcharting"" (a matter of about five
minutes) -- but without all of the iconic trappings. That is, I only have them use boxes, arrows, and something to represent delays. 2. I have them divide into small groups and create a process flowchart for a process that is at least somewhat familiar to all of them. (In homebuilding, for example, I use the process of installing drywall.) 3. After the groups present their flowcharts, I then challenge them to draw them again -- this time using the arrows for the ""processes""!! [Instinctively, almost everyone does it the other way initially -- that is, they put ""processes"" or activities inside the boxes, then just thoughtlessly connect the boxes with arrows, and don't label or even think about what the arrows mean.]
- This creates, for them, a very interesting learning opportunity: To think about what to write in the boxes (if the arrows represent activities or processes.) We discuss this a little, and I help them through a couple of examples from their first flowcharts -- and they come to understand that what go in the boxes are ""stocks"" or accumulations.
- I have also taught them the basic ""process model"" (Input - Process - Output) and given them a definition of ""process"" that includes ""transformation."" That is, if the Input and Output don't differ, there is no process; if you have something at time 1 and it becomes something different at time 2, there MUST have been at least one process
(transformation) between time 1 and time 2.
4. I also teach them to see that the nature of our definition of ""process"" dictates that on their new process flowcharts arrows and boxes MUST alternate! [If a box followed a box, either the two boxes contained exactly the same thing -- in which case there is really only one box -- or they contain different things, in which case there must have been at least one transformation between them. They grasp this immediately and without complaint, by the way.]
- An interesting question comes up here about delays. Is the ""widgets"" box different from the ""widgets in storage"" box? I insist that the two boxes are different -- and that there is a delay process between them (here, the delay might be called ""storage"" -- which, when further analyzed, turns out to be several processes, including transportation, stowing, perhaps inventorying, perhaps security inspection, etc.) Also, in order to further transform the stored goods, there is another process (or
more) required, involving removing the items from storage and transporting them to where the next process will occur.
Obviously, the ""arrows as processes, boxes as stocks"" flowcharts are actually stock-and-flow diagrams -- although there may be some additional thinking required to see that what they describe as ""processes"" can also be described as ""flows.""
I am doing all of this in the context of Lean Enterprise -- teaching people how to see their processes more clearly so they can eliminate or reduce the ""wastes"" built into them. That's why there's no equivocation about whether ""widgets"" is different from ""widgets in storage."" All of the activities required to transform ""widgets"" into (and out of) ""widgets in storage"" is waste and our process maps must show these wastes if we are to do anything about them. In addition, from a dynamic perspective, we know that delays often affect the dynamics of a system. Posted by ""John Gunkler"" <jgunkler@sprintmail.com> posting date Thu, 15 Sep 2005 10:35:31 -0500
Jim (and others),
I don't know if my approach applies in whatever context you're working, but with people who are employed and working on understanding their own processes, here's what I do:
1. I teach them traditional ""process flowcharting"" (a matter of about five
minutes) -- but without all of the iconic trappings. That is, I only have them use boxes, arrows, and something to represent delays. 2. I have them divide into small groups and create a process flowchart for a process that is at least somewhat familiar to all of them. (In homebuilding, for example, I use the process of installing drywall.) 3. After the groups present their flowcharts, I then challenge them to draw them again -- this time using the arrows for the ""processes""!! [Instinctively, almost everyone does it the other way initially -- that is, they put ""processes"" or activities inside the boxes, then just thoughtlessly connect the boxes with arrows, and don't label or even think about what the arrows mean.]
- This creates, for them, a very interesting learning opportunity: To think about what to write in the boxes (if the arrows represent activities or processes.) We discuss this a little, and I help them through a couple of examples from their first flowcharts -- and they come to understand that what go in the boxes are ""stocks"" or accumulations.
- I have also taught them the basic ""process model"" (Input - Process - Output) and given them a definition of ""process"" that includes ""transformation."" That is, if the Input and Output don't differ, there is no process; if you have something at time 1 and it becomes something different at time 2, there MUST have been at least one process
(transformation) between time 1 and time 2.
4. I also teach them to see that the nature of our definition of ""process"" dictates that on their new process flowcharts arrows and boxes MUST alternate! [If a box followed a box, either the two boxes contained exactly the same thing -- in which case there is really only one box -- or they contain different things, in which case there must have been at least one transformation between them. They grasp this immediately and without complaint, by the way.]
- An interesting question comes up here about delays. Is the ""widgets"" box different from the ""widgets in storage"" box? I insist that the two boxes are different -- and that there is a delay process between them (here, the delay might be called ""storage"" -- which, when further analyzed, turns out to be several processes, including transportation, stowing, perhaps inventorying, perhaps security inspection, etc.) Also, in order to further transform the stored goods, there is another process (or
more) required, involving removing the items from storage and transporting them to where the next process will occur.
Obviously, the ""arrows as processes, boxes as stocks"" flowcharts are actually stock-and-flow diagrams -- although there may be some additional thinking required to see that what they describe as ""processes"" can also be described as ""flows.""
I am doing all of this in the context of Lean Enterprise -- teaching people how to see their processes more clearly so they can eliminate or reduce the ""wastes"" built into them. That's why there's no equivocation about whether ""widgets"" is different from ""widgets in storage."" All of the activities required to transform ""widgets"" into (and out of) ""widgets in storage"" is waste and our process maps must show these wastes if we are to do anything about them. In addition, from a dynamic perspective, we know that delays often affect the dynamics of a system. Posted by ""John Gunkler"" <jgunkler@sprintmail.com> posting date Thu, 15 Sep 2005 10:35:31 -0500