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 (nonnegativity of allocations, sum of
shares = 1, etc.).
Id like to make a few observations that abstract from the merits of allocp
vs MNL.
A good modeler will first try to capture the way the processes relevant to
the clients purpose actually work, "warts and all." After the modeler and
client have confidence that the model captures the structure and decision
making behavior of the people in the system appropriately for their purpose
they can consider new policies including better resource allocation
schemes, and here optimization methods are useful. These two different
phases of modeling have been confused in the discussion. There has been
much concern in the discussion so far that various formulations may
generate a condition in which some customers receive more than the resource
they request. This is viewed by some as a flaw because it is suboptimal or
leads to anomalous model behavior.
Certainly, some formulations can give far too much to some customers under
some circumstances. However, in the real world resource allocation is
often imperfect, and customers often receive more than they request or is
optimal even while others are starved. In actual situations, extra
resources are sometimes detected (often imperfectly and with delays) and
then the allocations are re-adjusted (that is, a set of negative loops work
to correct imbalances). The most important contribution to the discussion,
I think, was Jack Homers observation that these imbalances accumulate in
stocks (e.g. backlogs of work to be done) and that the model should
represent these stocks explicitly. These backlogs generate pressures that
adjust resource allocation, so that the errors created by the imperfect
forecasting and allocation routines managers actually use (e.g. to allocate
staff time to different activities in a project) are eventually detected
and corrected. This netork of compensating negative loops sometimes leads
to "pretty close to optimal" allocations. If there are long delays in
detecting or responding to the imbalances, however, then there can be
extended periods of suboptimal allocation, instability, and other
dysfunctional dynamics, all of which are frequently observed in real
systems.
Accurate modeling of resource allocation procedures in organizations or
markets may in fact require a formulation that allocates resources
suboptimally. Far from being a flaw, the inability of a resource
allocation model to give each customer exactly the resource they demand (or
their priority-weighted share when the resource is scarce) may be a
desirable feature. 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.
Part of the problem comes from models in which people omit this important
stock and flow structure and instead attempt to treat the resource to be
allocated as a pure flow. For example, a modeler may treat the work to be
done in a project as a flow, and attempt to allocate time to different
activities so that the flow of work completed equals the desired flow in
every phase. By glossing the network of negative feedbacks that balance
the omitted backlogs of work in the real system, the modeler must come up
with a formulation that prevents overallocation because the model lacks the
real world structure that corrects the imbalances created by the actual
allocation process. As is often the case, modelers get into trouble when
they omit the network of feedbacks that in the real system responds to
discrepancies between the desired and actual states of the system and the
stock and flow structures that create disequilibria and enable inflows to
processes to differ from outflows.
In the real world, the disequilibrium stock and flow structures and
negative loops that regulate the stocks compensate for errors in the mental
or formal models managers use to allocate resources. These same loops
similarly compensate for the uncertainty and errors in the model parameters
and formulations capturing the priorities (attractiveness functions or
utilities) associated with each customer and their demand for resources.
Any formulation that only "works" for a particular or very narrow range of
parameter values is suspect since it is unlikely the modeler can estimate
these parameters to the accuracy required. Clients should beware of models
that require a particular value of the "width" parameter in allocp or that
only work if the underlying utilities in the MNL model are Weibull and not
Gaussian.
(One exception to the principle that one should explicitly model the stock
and flow structure of systems and the negative loops that respond to
imbalances arises when the equilibrating loops operate on time scales much
shorter than those of other dynamics of interest. Such circumstances can
lead to the stiff system problem in the numerical solution of differential
equations. There are various numerical methods to handle such situations
(none of which are, I believe, implemented in any of the popular simulation
software packages). It is then sometimes appropriate to treat these fast
processes as always being in equilibrium. A good example is provided by
Erik Mosekildes model of chaos in the rat nephron, in which pressure
equilibration in the nephron is very fast relative to the diffusion of
waste products and the neurotransmitters that regulate the porosity of the
capillary/nephron boundary. This nifty model is available on Tom
Fiddamans web site <
http://home.earthlink.net/~tomfid/>, then go to the
model library.)
A second comment on the specific case where worker time is the resource to
be allocated, for example in a project setting: Many problems arise
because time not spent working on the project is modeled as a residual, and
not as an activity with a priority that competes against the pressure to
work on various project activities. In the real world, as some pointed out
in the discussion, you build up a backlog of non-work related activities
when you spend more time on the project. The greater your workweek, the
smaller the time spent sleeping, being with friends and family, maintaining
your personal capital stocks (car, house, clothes, inventories of food and
supplies, bill paying and record keeping), and on personal health and
hobbies. As your sleep deficit builds, the complaints of your family and
friends grow, and the piles of dirty laundry spread, your ability to work
long hours on the project declines. Thus just as you should model the
backlogs of tasks to be done and the negative loops that adjust time
allocations among the various work-related activities, you should model the
stock of non-work tasks to be done. Such models give more realistic
behavior (you can work long hours for a little while, but then have to cut
back to work off the debt you built up to non-work activities). These
models can also easily be extended to include other important feedbacks:
if, despite the pressure, you continue to spend too much time at work, your
friendships fade, your non-work social skills and hobbies erode, and you
may find yourself divorced or without a meaningful relationship with your
children. These conditions feed back to productivity, absenteeism, and
employee turnover. Omitting these feedbacks in a human resource model may
be far more serious than the choice of allocp vs MNL.
The more general point is that all the uses for resources should be
explicitly modeled, without treating one as a residual. That is, the set
of resource demands in an allocation model should be mutually exclusive and
exhaustive. Most of the formulation problems people have pointed to in the
discussion of time allocation so far result from failing to include all the
demands on peoples time in the model.
John Sterman
From: John Sterman <
jsterman@MIT.EDU>