Resource allocation models


"Roderick Brown"
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Resource allocation models

Post by "Roderick Brown" » Mon Apr 03, 2000 5:39 pm

The discussion on time allocation is most interesting...I am currently
concerned with modelling personal time allocation (at least, managerial
time allocation from an individuals rather than a firms point of view)
- any tips gratefully received. Thanks to Kevin Agastein, Jim Hines,
George Richardson and John Sterman (especially the second point)
for their comments which help me too. However, do we
not need to make clear that it is frequently effort we are modelling and
not Father Time per se? I think this is partly what Steve Roderic was
asking when he posed the question.

It is a slightly tricky issue when raised by students on programmes
using the Dynamic Resource System View (Warren, Morecroft) since,
resource we define, in short, as something useful to an organisation, which
accumulates and depletes over time, and to
which is has access. Time sometimes causes confusion. "Time is a
limited resource" is a common expression, "Im short of time", "Time is
running out" etc. but my stock answer (pun intended) is that Time is not
a resource concept but the path along which our dynamic analysis plays
out. When we represent Time in our models, other than as the basis for
sequential differential calculation, we are, in fact, modelling
something more tangible than temporal. Is this a moot or even
significant point?

The most practical way we have found of treating it for managerial
audiences is as follows:
- the total time available may reflect a stock (e.g. number of sales
people, number and capacity of machinery),
- the consequence of time allocation is often an accumulation of other
resources (e.g. 20 sales people with 40 hours/week = 800 hours, of which
150 are devoted to winning new customers, who are won at the rate of 1 per
10 hours effort = 15 new customers/week, or 5 machines producing 20 units
per hour = 100 units of total output, of which 35 are devoted to product A,
so inventory of A rises at 35/hour)
The same concept seems to work for most folk when thinking about their own
time - I have 70 hours per week to produce useful stuff, of which 5 are
devoted to answering SD listserve questions, which I can do at the rate of
2 pr hour, so my accumulated output of replies is rising at 10/week (a gross
exageration!).
In none of these cases is time accumulating or depleting.

It is of course easy to conceive of this time-allocation process as a
zero-sum game
stock and flow model - in scenario modelling of media consumption, we have
conceived of consumers having e.g. 10hours/week of time available for
consuming infotainment, of which they may allocated 2 to newspapers, 3 to
TV, 2 to cinema, etc. Then the extent to which each service provides a
good use of time (dimensionless 0-1), time is dragged from one use to
another. Time-as-a-stock is useful in this case because of the stickiness
of the flow.

The only useful exception we have found is when a firms actual output is
hours of something - e.g. the BBC produces X hours per month of
transittable content, which is added to its library of total content-hours,
i.e. if you sat down today to play every minute of every tape in that
library, it would last Y hours (or decades!)

Happy new year everyone.

Rod.

Roderick Brown

Home Office: +44 (0)1553 631 516
e-mail:
rod@strategydynamics.com

Global Strategy Dynamics Limited

eric
Junior Member
Posts: 14
Joined: Fri Mar 29, 2002 3:39 am

Resource allocation models

Post by eric » Tue Apr 04, 2000 2:48 pm

John Sterman wrote:

>The discussion on formulations for the allocation of resources to multiple
>customers has been interesting; thanks to all for useful contributions.
>The focus of the discussion has often been finding a parsimonious
>formulation (defined as one you can explain successfully to your client)
>that meets various requirements (non negativity of allocations, sum of
>shares = 1, etc.).
>
>Id like to make a few observations that abstract from the merits of allocp
>vs MNL.

John and others,

I agree with you John.

I have followed the discussion on allocation with interest and you will
find in Systems Enquiry (Wiley), page 119 yet another neat allocation
method, which rather than allocating all the resource in proportion to
need sets fixed allocations up to a pre described limit and them
allocates what is left in proportion to need.

However, these types of policy are for use at the stage of modelling
"what might be" rather than " what is". The first step should always be
to model "what is". As John says:

"Of course, the model of resource allocation, like any
model, must be solidly grounded in first-hand observation and data on the
actual process in the real organization - these comments should not be
taken as a justification for sloppy modeling or formulation flaws."

I would go further than John by abstracting from both the merits of
allocation and from allocation itself in making a general comment about
SD which is rarely stated and which might help thinking here.

I perceive a tautology in SD and its software, which I often state as:
the imperfection of SD arises from its perfection. The imperfection is
actually not so much in SD as in the modellers and what they are tempted
to do.

What I mean here is that when the icons of a system dynamics model in
most software packages are initially hooked up, it is easy to assume a
degree of perfection, which never exists in practice. For example,
perfect information availability and usage and optimum policies. It is
only too easy to model some perfect situation, particularly to get a
model up and running, rather than a situation which really exists. There
is a real danger of modelling some modellers perceived answer, rather
than addressing a real issue. Even when modellers are aware of this
temptation, they often unwittingly include some unreal elements in their
models.

To model "what is" means deliberately building into the model many real
life imperfections and starting with the issue of why those imperfections
cause problems. This applies to modelling as a whole, not just resource
allocation modelling. Be aware and on your guard against such temptations!

Eric Wolstenholme (Eric@cognitus.co.uk)


Locked