Supply Chain Simulation Workgroup

"Beer, Bullwhips, and Agents"
The Supply Chain Simulation Workgroup
Santa Fe Institute Business Network - October 15-16 2002

Summary

A collaboration with Argonne National Laboratory, Los Alamos National Laboratory, Sandia Labs, and Sun Labs has been organized under the Santa Fe Business Network. The goal of the collaboration is to explore extreme volatility in the retail supply chain, and discover means to minimize this volatility through increased visibility of the entire supply chain. One tool for increased visibility is the AutoID project underway within Sun Lab's Project Epsilon, thus our interest in the collaboration. As a first step, the team members met in an Extreme Programming session to modify an existing simulation, the Beer Game, to instrument it for optimizing local knowledge decision making, augmented by increased visibility of the supply chain. The goal is to quantify the worth of increased visibility and suggest policies for managing it.

Extreme Volatility in Inventory, click for large view.

Introduction

The Sun Lab's Project Epsilon is exploring use of the AutoID Center's radio frequency tags. These tags are meant to increase the efficiency of the supply chain connecting producers, distributers, wholesalers, retailers and consumers. To better understand this technology, Project Epsilon is creating an AutoID Appliance which simplifies the deployment of the standard AutoID infrastructure. This includes ease of installation of an AutoID reader and associated tags, and the first tier of software needed to integrate the tags and readers into the enterprise.

One key goal for the AutoID technology is the increase of knowledge of the current state of the supply chain. This increased "visibility", along with good integration into existing IT frameworks, promises to vastly reduce inventory costs. One key cost is that of the extreme volatility in inventory management, the so-called Bullwhip Effect.

To become more expert in the supply chain volatility problem, I took advantage of Sun's involvement in the Santa Fe Institute's Business Network. The BusNet had an on-going interest in supply chain research, embodied in their Value Network workgroup. A simulation experiment was suggested and an initial meeting held at Intel August of 2002. There we decided on a two-phase approach: first build a simulation environment, second run a set of experiments suggested by a panel of experts. The simulation team decided on an "extreme programming" session at the Santa Fe Institute, the results of which would be presented at the November BusNet Meeting.

First, some history.

Beer and Bullwhips

The Bullwhip effect surprised Proctor and Gamble's Pampers division. The calculation is simple. N babies. B bowel movements per day. N*B pampers per day demand. But when P&G examined their inventory management system, they found huge swings in weekly demand and orders within their supply chain. Investigations showed that, although several elements such as sales, hoarding, delivery quanta (partial truck costs) and other details were important, one key issue was uncertainty and delay within the supply chain. Inventory managers would hedge their orders to avoid stock out, and delays in ordering and shipping would amplify uncertainty.

One well known investigation into this extreme variability is the Beer Game, created by MIT's John Sterman. In it the players represent four nodes in a idealized supply chain for a Beer company: Retailer, Wholesaler, Distributer, Factory. In it uncertainty and delay play a key role.

Players hold an inventory, at a cost of $0.50 per week for storage overhead. If the inventory reduces so much that orders cannot be filled, there is a $2.00 cost per barrel per week for back order. A customer orders 4 barrels a week for 4 weeks, then starts ordering 8 per week from then on. The players make orders upstream and fill orders downstream. There is a 1 week delay in receipt of orders and a 2 week delay for shipping.

Each turn of the game represents one order cycle of a week. Players try to keep inventory low enough to save costs but high enough to avoid expensive stock outage.

Play of the game produced volatility much like that observed in real supply chains. The cost the players produced was roughly 10 times optimal! Sterman and his researchers attempted to model the behavior of the players, which in turn was used to create computer simulations which model human game play.

Now back to the trip report.

RePast, Argonne's Beer Dock, and Open Source

The simulation team decided to base their work on a RePast simulation already built as a "docking" experiment for the Beer Game. Docking is using two or more different simulations to exhibit the same results, proving the simulation. Argonne National Laboratory had used Swarm, RePast and Mathematica to achieve the same results as earlier work by Sterman, thus proving the validity and interoperability of these tools.

We decided to make the project an open source project. This would allow implementors to collaborate even though separated physically. It would allow for late joiners to the project. And it would allow for tournament play of the game at a later date, for competition for the best ordering algorithms.

Simulation Team; Click for Large Picture

In order to kick start the work, the team decided to meet at the Santa Fe Institute before the November BusNet meeting. This would allow some initial results to be presented and form the hub of a panel discussion for where to go from here. We met Oct 15 & 16 in Pod A of SFI which included good phone, network, table and white board facilities, as well as a beautiful environment.

Extreme Beer with IDEA

IDEA; Click for large image

The four team members, myself, Ed MacKerrow (LANL), Michael North (ANL) and Charles Macal (ANL) met at SFI, hosted by Susan Balotti, the BusNet director. We initially "synched" with each other, getting our programming environments connected into the CVS tree on SourceForge. Three environments were used: Mathematica (Charles), Java w/ IDEA (Owen and Ed) and Java w/ Eclipse (Michael). The Mathematica work was separate from the RePast Java simulation both to provide "docking" (validation) and to explore separately visualization and animation techniques more easily achieved with Mathematica. The three Java programmers began by making minor changes and using CVS to update and synchronize.

We then began looking at the core Sterman model representing how players react to volatility. It was decided to refactor the system slightly to make alterations to the player strategies easier to code. While this work was underway, subteams naturally formed to discuss what strategies might perform well, and how to formalize the notion of visibility.

We rather quickly settled into natural rhythms -- coding, planning, discussing .. and naturally pizza! I won't go into details but simply highlight our findings over the two days:

Methodology:

IDEs: I have always avoided IDEs because they had not in the past been flexible enough for the systems programming I do with Java. Typically IDEs are too "I" (Integrated). It is difficult to have multiple IDEs within a single project. This has changed over the last few years, especially if GUI building is not part of the project. Of the IDEs used (IDEA and Eclipse), neither imposed structure on the files or directory hierarchy. The two systems interoperated well without conflict. [Note: Eclipse is the IBM IDE which clearly chose its name to denote interfering with Sun. Sigh.]
CVS: The lock-free CVS system had always put me off a bit, I felt the merge overhead too great. Wrong! There are tools to help and often the merging occurs without your even knowing it. We had only one difficult merge occur over several dozen commits and it was solved easily by two of us. I'm hooked.
Refactoring: One of the reasons I had avoided IDEs is that they never seemed to do what I cared about .. writing programs easily. Times have changed, especially with the refactoring tools. These use knowledge of the Java object model to make vast changes of the project very easy. They provide templates for automagically creating very useful code fragments like enumerators, constructors, getter/setter pairs. It was interesting to see how everyone was fearless of making huge changes. No worries, we can clean it up easily. And it was true.
Extreme Programming: I found it really embarrassing initially to try to hack as a group. But the fascinating thing that emerged was "comfort zones", individual areas of expertise. I found myself comfortable with issues on the overall code architecture .. because I had read over the code a good bit (out of fear!) I had a good feel for how we could make simple changes quickly . For example, adding new strategies to the agents and so on. Another team member was more expert at understanding agent modeling and quickly introduced us to how they work and how we could make the existing system more efficient from the agent standpoint. Another was more sophisticated at visualization and quickly build a 3D model of the supply chain. Another had excellent understanding of the various obscuriies of RePast. Diversity is quickly amplified into synergy in these sessions. I'm impressed!

Modeling:

EOQ: Our initial model simply played as people do giving the Sterman studies. One of our modelers (currently working on simulating terrorism, by the way) suggested integrating a new strategy based on a common inventory technique, Economic Order Quantity. This system is based on minimizing orders due to the overhead of making orders. It identifies an optimal order and a trigger point for making the order. Think of it as "zero inventory chicken" .. attempting to hold off on ordering to the last minute. This got us into more interesting modeling of inventory and hopefully into more flexible architecture.
Visibility: We spent considerable time thinking about visibility and how to implement it. Our initial idea is to simply expose the pipelines, both supply and order. This would mean that the agent would have complete knowledge of the outstanding orders and the number of orders shipped and how long it will take for them to arrive.
Forecasting: We quickly found that in both the EOQ and the Sterman model, forecasting plays a role. It is basically a business policy for deciding orders based on past experience. Thus it goes beyond visibility of concrete state into probabilities. This lead to a new concept: Transparency.
Transparency: We posited that exposing the forecasting used by the agents would augment the forecasting element of the supply chain. Thus one agent should be able to ask a "what if" question of another. We did not get to complete this, but are in the midst of modifying the models so that different forecasting techniques can be used. We are also adding complete history to each agent so that they can try different forecast techniques based on past history. Under transparency, agents can ask each other for forecasts as well as current status.

Downsides

Naturally there are downsides to this sort of work. The primary one is that the code becomes a "work in progress", i.e. it gets left in shambles as N different programmers quickly add new features. To fix this we decided that the various cleanups would be assigned as homework. Another drawback was that some changes proved difficult to complete quickly, thus made it difficult to do the later merges because several quick fixes intervened. In our case, the EOQ integration proved to be difficult and is still incomplete. Meeting in an unknown site caused a few problems. For example, the SFI firewall made it difficult to use CVS in the standard way. This forced one of us (me) to not use the IDE CVS features, doing it via command-line instead.

Summary and Future Directions

The two day effort proved effective, both for building the foundation for the RePast model, and for designing the capabilities we need for modeling aspects of interest in the supply chain. The tools worked, surprisingly enough, and getting the team working effectively took far less time than I would have thought. In the few days since the meeting, each team member has made further additions to the models, working on homework assigned at the end of the meeting.

One surprise for us was that another researcher, Mark Kimura, learned of our project and shortly after our meeting joined in with his own experimental system, with some rather interesting findings on how to damp out the volatility with only local knowledge. This was one of our hopes for the open source research, to attract others interested in supply chain modeling.

Next, we plan to present our current state of affairs to the BusNet meeting Nov 1. We will meet with the Sandia researcher who is planning the experiments we will be running. In addition, John Sterman will be attending the meeting and has offered to look at our work and to make suggestions for how to proceed.

"Beer, Bullwhips, and Agents" The Supply Chain Simulation Workgroup Santa Fe Institute Business Network - October 15-16 2002