What MLB Season Scheduling Means to Your Supply Chain
By Paul Homchick-Oracle on Mar 11, 2014
For the entire history of Major League Baseball from its founding in 1869 until 2004, the game schedules were developed by hand.
Great strides in operations research were made in World War II with the adoption of linear programing techniques, and great armies and navies were deployed and supplied using the new science of operations research, but baseball scheduling was more complex than that, and still done by hand. In the 1960s computing power exploded, with IBM placing powerful machines in most major corporations, but baseball scheduling was too hard, and it was still done by hand. Thirty years on, microprocessors brought down the cost of computing so that you could easily buy sixty-four or one-hundred twenty-eight, or two-hundred and fifty-six computers and set them all to working on the same problem. But the programmers still couldn't come up with a better schedule than Henry and Holly Stephenson could generate by hand.
ESPN has a 30 by 30 short documentary on "The Schedule Makers" detailing how the Stephensons scheduled major league baseball for twenty five years, only to eventually be replaced by a computer program in 2004. Why did it take so long for the computer scientists to solve the problem? Michael Trick, one of the researchers who worked on the problem explains that until 2004 computers just weren't fast enough:
"I began working on baseball scheduling in 1994, and it took ten years of hard work (first Doug and me, then the four of us) before MLB selected our schedule for play. ... Why were we successful in 2004 and not in 1994? At the core, technology changed. The computers we used in 2004 were 1000 times faster than the 1994 computers. And the underlying optimization software was at least 1000 times faster. So technology made us at least one million times faster. And that made all the difference. Since then, computers and algorithms have made us 1000 times faster still. And, in addition, we learned quite a bit about how to best do complicated sports scheduling problems. ... Another way to see this is that in 1994, despite my doctorate and my experience and my techniques, I was 1 millionth of the scheduler that the Stephensons were."
Those of you who have gotten this far are no doubt aware of the relationship between some of the example above and supply chains. They both move material around in space and time, and both make schedules. Since we started using computers to model and manage our supply chains in the 1980s, the incredible improvements in computing power have allowed us to use more and more data, and to build increasingly accurate supply chain models. These better models have vastly improved customer service while making much more efficient use of resources at all levels of the supply chain. But the data explosion associated with the Internet forces many companies to play catch-up in applying all this new information to building better and more accurate models and plans.
One of the Holy Grails of supply chain management is to make sure that no customer who wants to buy your product fails to do so because of a stock-out, while doing this with the absolute minimum of inventory. Solving this problem requires store-level demand forecasting and replenishment. If you have a company with world wide coverage and a reasonably wide product line, the number of forecasts you need to generate can easily be counted in the 100s of millions. And you need to do this weekly. Until recently, this level of data crunching had not been available to anyone but the National Security Agency.
Fortunately, computers keep getting faster, and software keeps getting better, and some times, a leading software company like Oracle will buy a leading hardware manufacturer like Sun, and release a combined product that can solve previously unsolvable problems like store level forecasting and replenishment. It is here now. Take a look at Oracle's In-Memory Value Chain Planning applications. They will allow you to do things you never thought possible.