Mr Odence writes:
>Heres my question: Is there anything fundamentally wrong with a co-flow (a
>rate driven by another rate)? I believe the party line is that such a
>representation is a convenience, and that whats really going on is that both
>rates are being driven by the same stock. I recall that it used to be a
>little tricky in DYNAMO to do this, and that doing so introduced a DT lag,
>ergo there was storage going on, ergo there was really another stock there .
> But I believe that most of todays tools have overcome that issue.
The term "co-flow" usually stands for a formulation crafted to keep track
of an attribute of some quantity that flows and accumulates in the system,
e.g., the book value of inventory, the expertise of a workforce, or the
average interest rate of a banks loan portfolio. It involves a
rate-to-rate connection, but merely as a bookkeeping computation.
The rate-to-rate connection in a coflow is not the difficulty addressed in
Forresters principles of systems that says rates and levels must alternate
around a loop, or that rate-to-rate connections dont exist in reality.
Bookkeeping rate-to-rate connections are fine. But saying, for example,
that management "knows" the current instantaneous rate of production is a
no-no -- there must be information processing lags that mean that
management is basing its perception on information that has to be
accumulated (averaged) somehow, which we frequently capture in a SMOOTH.
>>My feeling is that there are times when a co-flow actuslly gives a more
>realistic or operational picture of the underlying reality than a stock-based
>representation.
>
>There are accounting examples where I think this holds. Isnt is more
>appealing to describe a rate of revenue as =shipments * $ per shipment, than
>to think of revenues as being driven by the level of guys in the shipping
>department? Or, suppose we are hiring and want to track payroll: Increase
>in payroll = hiring * average starting salary. Heres a softer example: To
>model the theory that people learn from experience, wouldnt the rate of
>learning be driven by the rate of experiencing?
>
Id say Mr. Odence is right on -- these are bookkeeping computations where
one flow is simultaneously creating a bookkeeping record directly related
to it. Nothing wrong with this sort of rate-to-rate connection.
But Forresters original prohibition (strong caution) against rate-to-rate
connections is still just as wise as it always ways.
...GPR
.............................................................................
George P. Richardson
G.P.Richardson@Albany.edu
Rockefeller College of Public Affairs & Policy
GR383@Albnyvms.bitnet
State University of New York at Albany Phone: 518-442-3859
Albany, NY 12222 FAX: 518-442-3398
.............................................................................