created with NetLogo
view/download model file: beergame.nlogo
WHAT IS IT?
-----------
An agent based model of John Sterman's Beer Game. The beer game studies irrational decision behavior induced by delays in supply chain management. It uses a board game and cards to simulate the supply chain flow. See ref [5].
HOW IT WORKS
------------
The supply chain consists of four components (suppliers):
retailer, wholesaler, distributor and factory. The customer makes an
order to the retailer. The retailer (and the rest of the supply chain in
turn) performs these tasks:
1 - Get new stock from previous pending orders (variable name:
received)
2 - Get new requests for beer from downstream (variable name:
demand)
3 - Supply beer for the request and backorders (variable name:
supply)
4 - Make an upstream order based on inventory (variable name: ordered)
Thus: +---------+
supply < | | < received
| | [pending]
demand > | | > ordered
+---------+
It takes one time slot (1 week) for an order to be received by the
upstream supplier, and two time slots (2 weeks) for an order to be
filled by that supplier, thus a three week lag in all. These pending
orders are remembered by each agent (variable name: pending).
Scoring is done by cost: Inventory cost is stock on hand * $0.50,
but backorder cost (when you cannot supply enough thus have the demand
unfulfilled, carrying over to the next move) is more expensive: $2.00
per unfulfilled request.
Each supplier shows its inventory in a box just below its building.
It turns red when the inventory is negative, showing the existance of
backorders. Similarly, supplied orders are red if they are part of the
backorder .. i.e. are less than the requested number of cases of beer.
HOW TO USE IT
-------------
Clicking on "setup" initializes the game with all players having the
same inventory: 12 cases of beer, and the same pipeline of 3 * 4 orders
pending.
The customer orders 4 cases each week for four weeks. This lets the
game settle into an equilibrium. The 5th order goes to 8 cases and stays
there for the rest of the game, generally a year (54 ticks) or two (108
ticks)
The key of the game is to successfully manage volitility: variations
in demand.
Three monitors show the values for cost, average cost, and the
current tick. The cost is the sum of the four supplier's cost for this
tick. The average keeps a sum of this cost for all ticks and divides by
the tick count.
The three main plots show the inventory, orders and cost for each of
the suppliers, color coded to be the same color as the supplier in the
model. The inventory plot shows a zero line to show the times of
backorder vs healthy inventory, while the orders plot includes the
customer order.
The cost plot can show either the current cost, showing the cost
volatility, or the total cost, showing the expense so far of the run.
This is controled by the switch just above the plot. The final plot is a
phase plot (value for a given variable, at time T and T-1), which can
plot any of several variables, chosen by a menu just above the plot.
Sterman discovered a formula which matches human behavior, which the
game implements. Note the game does not try to optimize the supply
chain! Instead the purpose of the model is to mimic human behavior and
attempt to help it, in this case by increased knowledge down the supply
chain (visibility). Other aids to human reasoning can easily be added.
THINGS TO NOTICE
----------------
The key surprise here is the extreme volatility and lack of
convergence to steady state for certain of the parameter settings. This
is achieved with no random choices in the model at all, it is entirely
deterministic. It has been called the Bull Whip Effect [2] and is well
documented in management and control studies.
THINGS TO TRY
-------------
First, simply click setup and go, noticing the volatility for these
parameter settings. The model stops after a bit .. click go again, and
it will go on indefinitely.
Notice the inventory and supply change to red when the supplier
cannot fill an order.
There are four controls just under the setup/go/step buttons,
explained below. For now, rerun the model with Visibility switched to
"on". Note the volatility is removed. Now change visibility back to
"off" and try a Demand Style of square, then sign. Note the difference
in average cost for the two. Then try random Demand Style. Any
surprises?! Finally try SlowMo? set "on". You can toggle it any time
during the run.
Visibility: This is a true/false switch which normally is false.
Make a run (setup & go) with it set to true to see how adding a small
amount of knowledge reduces the volatility. In this case, we simply let
each supplier know what the upcoming demand will be when calculating the
next order to make.
Demand Style: This is simply a way to try customer demand other than
the usual step function. Sine and Square vary the demand over a 52 week
period, min of 0 and max of 8, thus can be thought of as seasonal
variation. Random simply chooses random numbers between 0 and 8.
SlowMo?: A true/false switch which will slow down each order event
enough to be visible. Sorta interesting to see panic build!
StopAt: This makes it easy to stop at a particular point. Set to be
in increments of 52 ticks (year intervals).
EXTENDING THE MODEL
-------------------
The current help for the suppliers is to provide "visibility",
simulating increased knowledge provided by the internet or by RFID tags.
Think of other aids and insert them into the model, mainly changing the
ordering strategy in simple human ways. Remember the idea is NOT to
optimize the supply chain, but to help the human decision making
process.
NETLOGO FEATURES
----------------
This model was initially done in RePast, using work done in The Beer
Dock [4]. This was later used by the Santa Fe Institute's Business
Network Value Network project [3]. Also see:
http://backspaces.net/SCSim/
I decided to rebuild the model in NetLogo to better simulate the
actual board game used by Sterman. This was prompted by submitting a
paper [1] to the Self-Star workshop on self organization, see
http://www.cs.unibo.it/self-star/
The "physicality" of NetLogo exposed interesting issues that had
been noted by earlier simulations. One example is that the orders are
actually spacially arranged in both the board game and in the NetLogo
simulation. But in some earlier investigations, the orders were kept in
queues which could be of variable length. These sometimes violated the
rules of the board game by having too many items in the queues during
part of the play. NetLogo nicely enables simulation of the actual
physical board game itself.
A second reason to use NetLogo was work done by Complexity Workshop,
urging RePast and NetLogo to be used as synergistic tools, rather than
either/or choices. Basically, NetLogo is wonderful for quick "what if"
questions during the early phase of designing complex models, while
RePast, with its access to GIS, CAD, 3D etc packages is appropriate for
extremely complicated models. We like to say that, in NetLogo, you think
more about modeling than programming, while the reverse is true in
RePast. Both are important at different phases of projects. Thus I was
interested to see how far I could get in NetLogo and was delighted to
see the basic game and visibility assist were both quite easily done,
while the Mesh Network assist done in RePast might have proven
difficult.
RELATED MODELS
--------------
See references, and the web, searching for the Beer Game.
CREDITS AND REFERENCES
----------------------
[1] Densmore, O. The Emergence of Stability in Diverse Supply
Chains. SELF-STAR: International Workshop on Self-* Properties in
Complex Information Systems, June 2004.
[2] Lee, H.L., Padmanabhan, V. and Whang, S. The Bullwhip Effect in
Supply Chains. Sloan Management Review, pages 93--102, 1997.
[3] Macal, North, MacKerrow, Danner, Densmore, Kim. Information
Visibility and Transparency in Supply Chains. Lake Arrowhead Conference
on Human Complex Systems, March 2003.
[4] North, M.J., Macal, C.M. The Beer Dock: Three and a Half
Implementations of the Beer Distribution Game. SwarmFest 2002.
[5] Sterman, J.D. Modeling Managerial Behavior: Misperceptions of
Feedback in a Dynamic Decision Making Experiment. Management Science,
35(3), 321-339, 1988.