Most Read Articles
The software question: To buy or build?
Candy makers Just Born Inc. and The Hershey Company may be household names for a lot of great-tasting reasons, but supply chain network optimization isn't one of them. The consumers who buy Just Born's Peeps Marshmallow Candies and Hershey's Kisses Brand Chocolates are unaware of the complex webs of facilities and people that ensure the sweet treats are in retail stores on time and at the right price. Like many companies these days, the confectioners are faced with rising raw material and energy costs. This changing cost picture led them both to undertake projects to evaluate and redesign their supply chain networks. But that's where the similarity ends. Just Born commissioned a custom-designed model and algorithm from researchers at Lehigh University, while in its analysis, Hershey used commercially available supply chain optimization software.
Is one software approach better than the other? In this article we will explore that question by briefly summarizing these two network optimization projects and discussing the key questions, solutions, and results for each one. We will then compare the two proj- ects and show why one benefited from a more customized approach, while the other was more suited for ready-to-use software. Finally, we will present some "lessons learned" from both projects that may be helpful for anyone who is engaged in a supply chain modeling exercise.
Just Born's customized solution
Just Born Inc., located in Bethlehem, Pennsylvania, USA, was founded in 1923 and is now the eighth-largest confectioner in the United States. The company's most famous brands include Peeps, Mike and Ike, Hot Tamales, and Peanut Chews. The candy is manufactured in Bethlehem, and then is shipped from there to a warehouse located 75 miles to the north in Scranton, Pennsylvania. From Scranton, product ships out to customers nationwide, in either less-than-truckload (LTL) or truckload (TL) shipments. Just Born serves LTL customers via distribution centers known as "pool points." There, third-party logistics (3PL) providers break down truckloads into smaller shipments for delivery. Full truckloads, meanwhile, move directly from Scranton to customers' facilities.
In 2007, Just Born began a major re-engineering of its supply chain network. As part of the redesign process, it had to answer questions like the following:
- Which customers should the company serve by direct truckload, and which by LTL?
- Which of the 28 pool points in the distribution network should Just Born continue to use?
- How should the company route product through its network, in what quantities, and when?
To answer these questions, Just Born decided to seek help from outside the company. Supply chain managers received bids from several consulting companies as well as a proposal from researchers at the Center for Value Chain Research (CVCR) at Lehigh University, also located in Bethlehem.
Just Born opted to work with the Lehigh researchers, who proposed to build a mathematical model for opti- mizing the company's distribution network. One of the primary considerations in that decision was cost; the research team could develop the model more economically than the consultants could. (Other considerations will be discussed later in this article.)
Just Born and Lehigh scoped out the requirements for the project, and the Lehigh team then designed and built the mathematical model. The model's objective is to minimize the manufacturer's average transportation cost per week. This includes line-haul costs for truckloads to pool points and direct customers as well as the per-pound cost to ship to LTL customers. The model is capable of deciding, for a representative week, which of the 28 available pool points should be used and how much volume each pool point should handle; which customers should be served by direct truckload and which by LTL; and how truckload shipments should be scheduled throughout the network.
To keep the model's size reasonable, the researchers aggregated Just Born's customers to the three-digit ZIP (postal code) level, and they excluded customers that typically receive small or infrequent shipments. The resulting data set modeled roughly 85 percent of the manufacturer's average weekly volume.
The Lehigh research team formulated the problem as a mixed-integer programming (MIP) model—a mathematical optimization model that can be solved using commercially available software, even though the model itself was custom-built. They also wrote a graphical user interface (GUI) that processes the data and displays results in a user-friendly format that is similar to what you might see on a personal computer screen. A computer then solves the model behind the scenes, finding the optimal solution based on the given data.
The model revealed that Just Born's existing network was too costly and not as efficient as it could be. For example, there were too many pool points—the optimal number turned out to be 22, rather than 28, locations. But the researchers found that the shipper had some leeway in that regard; it could still achieve near-optimal results with anywhere from 20 to 24 pool points.
One surprising finding was that Just Born was doing too much direct truckload shipping, which people tend to assume will be less costly than LTL. The study found that the optimal ratio of direct truckload to LTL customers is approximately 40:60, a reversal of the existing ratio of roughly 60:40.
The model further showed that a number of lanes were not cost-effective. The new solution it devised avoids low-volume pool points as well as lanes where outbound line-haul rates are high because little volume is available for backhauls in the region.
Those are just some of the main findings of the researchers' analysis. Just Born has acted on several of the model's recommendations, but it is too soon to confirm the resulting savings. Nevertheless, the new solution is estimated to save the company approximately 1 percent to 2 percent of its total logistics costs per year. That may sound small, but with an annual logistics spend of about US $10 million, those savings will add up to a significant amount of money.
Hershey's commercial application
When faced with a similar need to optimize its network, The Hershey Company took a different approach and opted for commercially available software. Hershey is the largest confectionary manufacturer in North America, producing such brands as Hershey's, Reese's, Kit Kat, and Twizzlers. The company ships more than 4 billion pounds of finished goods per year, over 90 percent of it via truckload. The Hershey, Pennsylvaniabased company's North American supply chain includes seven major distribution centers in the United States, Canada, and Mexico.
Rapidly escalating raw material and input costs led Hershey in February 2007 to announce a supply chain transformation initiative. The initiative's primary goal was to restructure the company's U.S. and Canadian manufacturing network by significantly improving U.S. manufacturing efficiency. The project also aimed to increase manufacturing flexibility through greater use of specialty manufacturers, and by constructing a flexible, cost-effective production facility in Monterrey, Mexico. By far the largest supply chain project in Hershey's history, the initiative was expected to generate US $170 million to $190 million in annual savings by 2010 while allowing the company to continue to produce 90 percent of the items sold in the United States and Canada in those same two countries.
Early on, it looked like the savings generated by restructuring the manufacturing network would be partially offset by higher freight costs. At first, supply chain managers were willing to accept that tradeoff. But they soon undertook an additional study to determine whether that freight-cost penalty could be mitigated by restructuring Hershey's distribution network. The key questions addressed by this second study were:
- 1. Could the incremental freight expense be mitigated with a distribution network redesign?
- What other opportunities might there be for savings?
- What new distribution strategies might be enabled by inventory improvements?
Those questions were addressed using a model built in LogicNet, a software application sold by LogicTools (a division of ILOG, which IBM acquired in 2008). Hershey partnered with the St. Onge Company, a manufacturing and logistics consulting firm, to leverage its extensive experience with this software.
Hershey went into the modeling project with several objectives. The first was to validate the planners' recommendation to close the 550,000-square-foot Redlands, California, distribution center and add one or more new distribution centers farther east. Another was to determine the optimal locations, sizes, and service territories for the remaining distribution center network while simultaneously evaluating potential distribution center alternatives.
Also under consideration was co-locating syrup manufacturing and bottle production at a new distribution center, which would represent a significant shift from current operating strategy. While an informal analysis suggested that this plan would be economically feasible, Hershey needed objective quantification to support its capital planning. And finally, managers wanted to use the model to quantify the network impact of inventory-optimization opportunities, including those related to safety-stock levels, consolidation, and product sourcing.
Modeling generally begins with mapping the current network and then building a baseline of that network in the software. Essentially, the purpose of the baseline is to replicate current product flows, network flows, and cost structures within the tool's constructs. Hershey's team members began this process by building a rolling transaction history consisting of numerous data inputs for the 12 months prior to the supply chain transformation. They aggregated customers into geographic regions, and stock-keeping units (SKUs) into product groups. The team members vigorously validated and tweaked the model until they were comfortable with its level of accuracy. This was a critical milestone, as the baseline would be the framework for all future decisions. "What if" scenarios were performed for more than 20 candidate distribution center locations, including various size and location combinations and some fairly unconventional scenarios. The model used actual freight rates for transportation costs, and a combination of historical and publicly available data for fixed and variable costs for potential locations.
As expected, the resulting analysis confirmed the wisdom of closing the Redlands, California, distribution center and suggested that Hershey commission a large facility near Salt Lake City, Utah. It also confirmed that it would make economic sense to colocate syrup manufacturing and bottle production for West Coast markets at the Salt Lake City location.
At the same time, it became clear that fewer but larger distribution centers would be more efficient and economical for Hershey. Through various modeling iterations, analysts were able to quantify and illustrate how operations at a distribution center in Kennesaw, Georgia, could be integrated into the Hershey, Pennsylvania-area distribution facilities, thus reducing the number of U.S. distribution centers from five to four. Specifically, the analysis showed that this could be accomplished by expanding one existing distribution center by 80,000 square feet and by changing some rack design and sourcing profiles.
All together, the resulting savings from Hershey's distribution network redesign are expected to total in excess of US $15 million per year.
Benefits and drawbacks
Both commercially available and customized software have their advantages and disadvantages. As Just Born can attest, customized software may offer more flexibility because it can be designed to reflect a company's unique problems, including cost factors, variables, and constraints that are not included in commercially available packages.
Furthermore, the total costs associated with customized software often are less than those for commercially available versions. The cost of commercial supply chain optimization software ranges from tens of thousands to hundreds of thousands of U.S. dollars— and that does not include the cost of the internal staff resources and outside consultants that may be required to support the software. In Just Born's case, its customized, rather straightforward software was developed at a very reasonable cost in comparison to the total cost for a commercially available package.
There was another, less easily quantified factor that influenced Just Born's decision. Many companies wish to foster relationships with universities, both for philanthropic reasons and because they expect to directly benefit from the research. By sponsoring a research project at Lehigh University, Just Born gained a new network optimization tool and insights about its supply chain while also continuing its decades-long commitment to invest in the Lehigh Valley, the region in which both the company and the university are located.
There are disadvantages to commissioning a software research project, the most significant being the time factor. It usually takes much longer to custombuild a software package than to select, install, and master a ready-to-use product. Moreover, university faculty and students usually cannot work on such projects full time. Commercial packages, by contrast, typically are ready to install in a fairly short time because their mathematical frameworks and main functionality already exist. Furthermore, software vendors and consulting firms often provide dedicated staff for the duration of the project.
Commercially available supply chain optimization packages have other advantages. These solutions often include useful features that the team charged with selecting the software didn't anticipate needing when it initially scoped the project. The packages can be very flexible, but this has its own downside: Modelers need to be quite savvy if they are to use the tool to its fullest potential.
Once a commercial software solution has been set up and the initial models have been built, users are able to think differently in a "safe" environment. From a change management perspective, a safe environment is one that is free of historical prejudices and bias against ideas that were "not invented here." In such protected conditions, users are able to capitalize on the software's flexibility to discover, explore, and quickly quantify far-reaching, cross-functional scenarios. In other words, they can formulate possibilities while supporting them with objective quantification. Commercial tools also tend to be more stable and less prone to "bugs" (errors), run on more platforms, and offer better technical support in comparison to customized software.
One danger of commercial supply chain packages is that people who are not experienced modelers tend to think that the software always provides perfect solutions. It does not. Like any modeling endeavor, optimizing a supply chain using commercial software requires careful data collection and processing, a thorough understanding of how the model might misrepresent the real-life supply chain, and a critical evaluation of the proposed solutions.
Another concern inherent in commercial software is that such packages may be unnecessarily complex and costly for some supply chain analyses. Moreover, using the software is not a simple matter; modeling a real supply chain takes a good deal of time to set up, and this setup time makes these tools impractical for addressing simpler problems. In fact, Excel spreadsheets may continue to be all that is really necessary to answer many supply chain questions.
In short, when faced with the task of optimizing a supply chain, supply chain managers should not automatically reach for a commercial solution. Instead, they should carefully compare the costs along with the advantages and disadvantages of customized versus commercially available tools to select the best solution for their companies.
At a Center for Value Chain Research symposium held last year at Lehigh University in Bethlehem, Pennsylvania, USA, supply chain leaders from Just Born Inc. and The Hershey Company shared some of the lessons they learned from their supply chain optimization projects. These lessons apply equally well to customized and commercially available software. Here is a sampling of their observations:
- You need to see the end before you begin. The project must have a clear direction and must seek to answer specific questions. Otherwise, it will peter out before it accomplishes anything.
- If you don't get the data right, your answer will be wrong. Data is prone to errors at every level, from data-entry mistakes to misinterpretations of key metrics. Expect to spend months with your data before any model output is produced. (And expect people to keep asking what's taking so long ...)
- Insights from the tools are generally correct, but the numerical output should be viewed with a bit of skepticism. For example, if the model says, "Make 50 percent more x," the recommendation to "Make more x" is probably correct, but the optimal number might be higher or lower than 50 percent. Inaccuracies and real-world uncertainties could potentially result in numerical outputs that are no better than general estimates.
- No model captures every detail of a real supply chain. Optimization models provide one piece of evidence to be used when making supply chain decisions, but their recommendations may be overruled by other, counterbalancing factors.
- Software is not a substitute for strategy. Successful supply chain operations require strategy and vision on the part of their leaders, and no optimization model can replace these. Modeling does not relieve leaders from making difficult business decisions. In fact, it will prompt many new decisions.
- Seek the lowest data levels. Most supply chain models involve some amount of aggregation—of stock-keeping units (SKUs), customers, and so forth. Nevertheless, seek the finestgrained data available. This allows you to control the degree of aggregation and also permits future changes to the aggregation strategy without requesting more data.
- Averaging averages will lead to mistakes when it comes to locating distribution centers and warehouses. Be very specific when calculating transportation costs, as they, more than anything else, will determine location. For example, if you are 90-percent confident about the inbound and outbound costs for a particular transportation lane, you have just created one origin/destination pair with 81-percent reliability (90 percent x 90 percent). Do this a few hundred times across a network, and you might end up locating in Phoenix, Arizona, when you really should have been in Salt Lake City, Utah.
- One person must "own" the data. Multiple data owners can easily make simultaneous (and conflicting) changes, process different pieces of data in incompatible ways, or make other autonomous decisions that interfere with one another and render the data unreliable. The team needs one person to handle questions about the data and manage access to that information.
- Constantly assess whether the model's output makes sense. Checking high-level data outputs is critical for identifying errors and inappropriate modeling choices. Look for costs, shipping volumes, and other outputs that seem radically different from your baseline or are greatly out of proportion to one another.
- If you don't change your thinking, you will end up with what you already have. It is all too easy to build a model to validate existing strategies. Your goal should be to make significant changes—otherwise, you should not be undertaking a modeling project.
Join the Discussion
After you comment, click Post. If you're not already logged in, you will be asked to log in or register.
We Want to Hear From You! We invite you to share your thoughts and opinions about this article by sending an e-mail to ?Subject=Letter to the Editor: Quarter 1 2009: The software question: To buy or build?"> . We will publish selected readers' comments in future issues of CSCMP's Supply Chain Quarterly. Correspondence may be edited for clarity or for length.