Where it comes from
The beer distribution game was designed at the MIT Sloan School of Management around the start of the 1960s, in Jay Forrester's system dynamics group. Its subject was never beer, but a demonstration: that the behaviour of a system cannot be deduced from the behaviour of its parts.
It is originally played on a cardboard board, with tokens standing for cases. That simplicity is part of the device: nobody can blame the outcome on a computer model they do not understand.
The rule
A linear chain of four links — retailer, wholesaler, distributor, factory. Each one communicates only with its two immediate neighbours, and only through purchase orders. No discussion between positions is allowed.
On every turn, which stands for a week, each player:
- receives the goods shipped by their supplier two turns earlier;
- reads their customer's order and serves it, up to available stock;
- records what could not be shipped — the backlog, which stays owed and has to be served later;
- places their own order with their supplier, which will arrive two turns later.
Two lead times therefore stack at every stage: order transmission and delivery. It is that latency, not the difficulty of the arithmetic, that makes the game hard.
The score, and why it matters
Each player pays two costs per turn: a holding cost on what they hold, and a shortage cost on what they owe and have not shipped. In the classic settings, shortage costs twice as much as holding — which reflects something simple: a lost sale costs more than a pallet sitting still.
The team score is the sum of the costs of all four links. That rule is decisive: it makes it impossible to win by optimising your own position at your neighbour's expense, and that is exactly what everyone does for the first half of the game.
What happens
Final customer demand stays flat for a few turns, then rises once — typically from four to eight cases a week — and stays constant until the end. A single step, once and for all, with no further surprise.
The sequence is documented: in 1989, in Management Science, John Sterman published the experimental analysis that remains the reference. It describes the following sequence:
- stocks fall to zero and backlogs pile up for several turns, the time it takes for orders to travel up the chain;
- players, seeing nothing arrive, order again — and then again;
- all those orders end up being delivered at once, and stocks overshoot far beyond any need;
- the swing is small at the retailer and enormous at the factory.
This is the bullwhip effect, produced in front of the participants without any of them looking for it.
What it actually proves
Sterman traces that result to a specific mechanism: players systematically underweight the supply line — the orders already placed and not yet delivered. Seeing nothing arrive, they re-order what they have already ordered. This is not carelessness; it is a general difficulty in reasoning about a system with delays.
In the room, revealing the actual scenario — one single rise in final demand — is the moment the session turns: until then, everyone was looking for the cause at their neighbour's end.
The lesson is therefore not that people decide badly. It is that the structure of a system — its lead times, its compartmented information — produces behaviour that individual intentions are not enough to correct. Changing the people changes nothing; changing the structure changes everything.
Running it well
The game produces the material; the debriefing produces the learning. Three precautions follow directly from what precedes, and each one protects a condition without which the demonstration no longer holds.
Announcing the scenario
Saying in advance that demand will only move once destroys the demonstration: players then hunt for the right answer instead of deciding blind, which is precisely the situation you are trying to reproduce.
Letting players talk to each other
Compartmented information is not an arbitrary constraint: it is the subject. A room negotiating out loud will not produce the effect, and will leave convinced the problem is solved by talking — which is true, but is not what you set out to demonstrate that day.
Debriefing without the curves
The decisive moment is when you overlay final demand — almost flat — with the factory's orders. A debriefing that stays verbal, without showing those two lines side by side, lets everyone leave with their own version of events.
That leaves the questions to ask, and the simplest ones will do: at what point did you decide to order more than you were selling? what would you have done differently if you had seen your customer's stock? and — the most useful one in a company — where, in our real chain, do those two lead times sit?
Its limits
The original game is sixty years old, and it shows. Its chain is perfectly linear: no alternative supplier, no make-or-buy trade-off. Its board version demands a great deal of manual recording and arithmetic, often at the expense of the debriefing — which is the only part where anything is learned.
To which add a limit of scope, worth facing squarely: of the four causes of the bullwhip effect, the beer game stages only one — demand signal processing. No promotions, no order batching, no organised shortage.
On reflection, that is also what makes its demonstration so strong: the amplification appears while none of the other three causes is present. The game therefore proves the hardest point to accept — the structure of information alone is enough.
The version played online
The S&OP Game keeps the beer game mechanics and lifts the first two limits: the chain can hold several suppliers and poses the "make / team / buy" trade-off, and both calculations and charts are produced automatically — the time saved on housekeeping goes back into the debriefing. Six roles instead of four on the reference chain, and a report available the second the game stops.
The limit of scope, on the other hand, stands — and it is worth saying: prices and promotions are not modelled there either. The S&OP Game puts information flow, dual sourcing and inventory sizing under tension; not pricing policy.