Strengthening your supply chain one link at a time.
Network Optimization – The devil is in the detail (of the analysis)
We have all heard the phrase, “the devil is in the detail.” This common phrase refers to matters that might seem simple on the surface, but when you look deeper, you may find minor issues that could have a great impact on the direction of the matter. Never has this phrase been more relevant than in the network optimization process. I have over 100 network optimization projects under my belt in my 24 years at St. Onge Company. I have also evaluated, at the client’s request, more than a few network optimization projects performed by others. All of this experience tells me that the devil really is in the detail.
Recently, a client requested that I evaluate a distribution network study (manufacturing was fixed) performed by another consulting firm. I initially reviewed their final PowerPoint presentation. At a high level, it checked all of the boxes. They made sure to include all freight elements (inbound and outbound), facility costs (fixed and variable), and inventory carrying cost impacts (as the number of distribution locations varied for each scenario). On the surface, the analysis looked fairly complete. As a next step, I spent a day going through the project details with the client’s project manager, and this is where I became concerned. I discovered many issues that would greatly influence the final results, in both the number and locations chosen, as well as the costs and service levels reported. It was all due to not going to the appropriate level of detail. Network optimizations are difficult efforts. You cannot be afraid to get your hands dirty, in the data, to produce a quality and valid result. Here are some important elements to keep in mind to make sure you have a reliable network model:
Base data timeframe. A network optimization should be based on a foundation of clean and representative data. It is typically recommended to have a year of detailed data, which can be tied back to historical financials, whether that be a calendar year or a fiscal year. COVID has certainly added a wrinkle to what is “representative” data, but we will save that discussion for another day.
SKU–level data versus shipment-level data. SKU-level details in the base data (for a distribution-focused study) can be important when you have a wide variety of manufacturing/vendor locations that span multiple geographies. For example, if you are modeling the North American distribution network, and all of the product is sourced from Asia, shipment-level base data might suffice. This is true as long as the distribution facilities will carry the full product line. Any product-specific scenario modeling will always lead you to SKU-level base data.
Shipment profiling. Just because a model incorporates all the relevant modes of inbound and outbound transportation (ocean, TL, LTL, parcel, air, intermodal, rail, etc.), doesn’t mean it is complete. Again, the devil is in the detail. For example, most companies ship to a wide variety of customer locations, and these can range from a large distribution center, to a small distributor, to a customer’s home. You should not take a “one size fits all” approach to shipment profiling.
Customer aggregation. Your customer aggregation strategy goes hand-and-glove with shipment profiling. Large-volume customer locations should be modeled discretely, as opposed to lumping them into the three-digit zip code where they reside because they might have a vastly different transportation shipment profile (e.g., 100% full truckload) than smaller customers in that same geography. In addition, separating prepaid and collect customers is essential to make sure you can isolate the freight dollars you are directly responsible for paying.
Candidate locations. I will address this further in an upcoming blog, so I’ll keep it simple by stating that you should always err on the side of having more, rather than less, candidate locations for the network model to choose from (as long as model run times are reasonable). This will ensure your results are not misleading due to having too few candidate locations.
In network modeling, I often say, “I don’t want to bring a gun to a knife fight.” This means that you shouldn’t necessarily go overboard and model every single SKU and customer location discretely just because you can. But again, this is not a “one size fits all” process. Once you have clearly defined the scope and scenario expectations on the front end, and have reviewed the data that is available, you can properly decide what level of detail is appropriate for your network optimization project.