2/12/2003

Final Project Proposal: The Beer Game

Introduction

For my final project I propose a HubNet activity -- the Beer Game. This project was recommended in class as an oft-used economic game. In fact, a successful project might even be used regularly in the Kellogg School of Management.

The Beer Game

The Beer Game was developed at MIT in the 1960s to demonstrate the surprisingly difficult troubles with lags in a supply chain. This very simple game often humbles managers and business students who perhaps initially think of the game as being trivially easy.

There are three or four players in the traditional Beer Game, a retailer, a distributor, a factory, and (sometimes) a wholesaler. The players link to form a supply chain which delivers beer to customers through a system of orders and deliveries. The players are not in competition -- they work as team to produce the lowest possible costs.

From where do costs arise? For each participant, there is a cost penalty for each case of beer held in inventory per round. To reduce these costs, participants attempt to keep their inventories small. However, there is another, larger cost that "competes" with keeping a small inventory. If there is ever a backlog (i.e. a customer order which cannot immediately be filled due to low inventory), a larger cost penalty is assessed per round.

There are three "catches." First, customer demand is variable. Presumably, this variability ripples through the supply chain as retailers increase/decrease their orders to distributors who in turn increase/decrease orders to the factory. Second, there is a substantial lag time for all transactions. Different versions contain various rules for supply chain lag, but in general, it takes a round or two for orders to be processed up the chain, and it takes another round or two for deliveries to be made down the chain. The result is that orders of beer made to satisfy changes in customer demand don't execute fast enough for retailers to accurately react to customers. Finally, the participants only have local information. They do not converse or view the actions of their partners -- team members interface only through the placement of orders and the receipt of deliveries.

My Proposal

I will implement the game as a HubNet model. The model won't be a traditional system of many autonomous agents producing emergent phenomena, but I think the task is very suitable to HubNet nonetheless.

I have many choices to make regarding the details of the Beer Game. How do I fluctuate customer demand? What sort of local info do I give to the players? At what amounts/proportions do I set the costs? For what do I use the main window?

I think I will either completely randomize customer demand on every turn or implement of smoothed version of this randomization (where the demand changes only by a random fluctuation added/subtracted from the previous demand). Most versions of the Beer Game have backlog costs per case that are twice the inventory costs per. Whatever costs I choose, I will preserve this ratio.

My big decision concerns the main window. The model I currently envision uses turtles to represent the orders and deliveries physically traveling between supply chain links. The challenge here is to limit the visible scope of the participants while allowing for an omniscient host. I also need to decide whether to be true to the original pencil-and-paper game by having turn-based rounds. The other option is to implement a more fluid, "real-time" version.

HubNet should work well for this task. I hope that any deviations I make from the original Beer Game are intentional design decisions guided by the power of NetLogo and not reluctant limitations hampered by my abilities with NetLogo.