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].


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.


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.


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.


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).


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.


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.


See references, and the web, searching for the Beer Game.


[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.