Data Tips for Supply Chain Network Design Part I: Preparation

In a previous blog, we explored 3 best practices for supply chain network design. Defining your data requirements is one of them. Preparing data to feed into your network model is one of the biggest tasks you will encounter in supply chain design. It’s worth investing time in thinking about how you will prepare your data before importing it. Follow these tips and tricks for network design data preparation. 

1. Keep it simple

Supply chain network design is a strategic activity. Your data doesn’t have to be detailed and accurate to the nth degree.  You can afford to take some shortcuts, use aggregated instead of detailed data, and make some assumptions.  As a rule of thumb, keep your data as simple as possible, without compromising the quality of the answers you produce.  The simpler your data is, the easier it will be to collect, validate, clean, and enter it into any template.  Your results will also be easier to interpret, and there will be runtime advantages as well. 

2. Remove the noise

ERP data often contains information that is necessary for ERP purposes but creates an unnecessary distraction in network design modeling.  Consider removing data around: 

• Credit notes 
• Samples 
• Returns 
• Transfers between virtual locations 
• Tiny volume products 
• Retired products 

Extract transactions that represent physical flows and filter out transactions that represent virtual flows. 

3. Aggregate your products

Unless your business only has a few SKUs, or you need SKU-level results, modeling at the SKU level rarely makes sense for network design. Create the minimum number of aggregate “model” products that capture the complexity you need.  These can be but do not necessarily have to be, the same product groups or product families that you have in your ERP system. As a rule of thumb, a number of model products in the 10s is okay; products in the 100s are too many.   

4. Aggregate your demand nodes

You may be tempted to model every customer at the street address level as a separate demand node.  But this is often unnecessary for network design. Using aggregated demand may give you the same answers and insights, with less hassle. Aggregated demand has big advantages in terms of data capture, result interpretation, model runtime, and clarity on the map. A good rule of thumb: 1,000 demand nodes is good, and more than 5,000 start to cause problems.   

5. Remove virtual locations 

Your ERP might make a distinction between several virtual locations, which are actually at the same physical location.  There are good reasons to do this in the ERP. Namely, to manage the transactional flows in the business. In network design, however, your goal is to model physical flows and associated costs. So, combine all virtual locations into single physical locations if possible. This is especially true for DC locations, where the separate virtual codes in the ERP can be combined into one physical DC location for network modeling purposes. 

6. Choose your Units of Measure with care 

Ideally, you should use one unit of measure (UoM) throughout the model.  For example, if you can model “tons” or “cases” throughout the network, and are able to capture demand volumes, supply volumes, DC throughput, DC costs and transport costs for one UoM, then normalize your model to this single UoM.   

This might not always make sense.  If you do need multiple UoMs to capture different volumes and costs at different points in the supply chain, try to keep these to a minimum.  For example, there might be many different case sizes in the business. Using one “average” case to specify volumes and then one weight measure, such as kg, to specify transport costing, may be sufficient.  Consider removing UoMs from the model for very small volumes.   

7. Use capacity constraint assumptions

Capacity constraints at production facilities, suppliers, and DCs are not always easy numbers to obtain. Asking your production or DC manager for a max throughput capacity can sometimes trigger a large exercise in understanding nameplate capacity and how these changes depend on product mix, etc.   

Consider using the throughput from your base case data as an initial proxy for capacity. The actual production/throughput from last year’s data is often an easy number to get.  When you run the model, you can relax these proxy “constraints” and see how much the model does over or under the number from last year.  The discussion with your production or DC manager will go more smoothly in this case.  Instead of asking “how much can your DC handle,” you can ask: “can your DC handle 15% more throughput?”  This is often an easier question to answer. It provides the same insights and can reveal exactly where you need to sharpen the pencil on capacity numbers, rather than trying to establish them across the board from the beginning.

8. Calculate transport rates

Transport rates are often the most difficult piece of data to obtain. Transport rate structures can be very detailed and complex. You should simplify this to the right level of detail for network design.  You don’t need to capture the cost of every single load; look for ways to average out transport cost data so that it is directionally correct, and comprehends the different geographical differentials between freight rates. 

9. Avoid multi-period models, unless you need the complexity

Single-period models are easier to populate, run, and interpret than multi-period models. So, if you can avoid creating multi-period models you should. For example, if you are worried about seasonality, consider running a peak month and an average month as 2 separate single-period datasets, instead of running a multi-period model with 12 months.  The answers you are looking for may be more apparent this way, without the additional overhead of all the months in between. 

There are some good reasons to create multi-period models. For example: 

• If you want to model how capacity requirements for DC throughput and transport service providers change on a month-to-month basis in a seasonal supply chain. 
• If you want to model the transition between your base case year and your future state year to support decisions around which locations to open/close and when.  

If you need this level of complexity, using a tool like AIMMS Network Design can be very helpful. 

10. Model Bill of Materials (BOMs) only when necessary

Similar to multi-period models, models with BOMs and bill of resources add complexity in terms of data collection, populating your model, and interpreting results. So, you should be sure you need this complexity in order to achieve the results you are trying to get.  If not, consider modeling without BOMs. Most outbound studies, and projects where you have no ability to influence the location of manufacturing facilities and volumes, often do not require modeling with BOMs. 

Modeling with BOMs is useful when you need to: 

• Capture the costs and flows of raw materials and intermediate products, as well as final products. 
• Decide where to build your next factory 
• Understand the potential of moving manufacturing equipment from one site to another. 
• Decide where to perform value-adding activities at storage locations (for example, packaging or de-stuffing containers at a DC, or blending components at a tank farm). 
• Evaluate where to process intermediate products like chemical components or parts assembly. 

11. Use model groups

Model groups can be a great way to simplify data capture. For example, if you have 20 products, 10 DCs and 1,000 customers, this requires a transport rate for 200,000 (20x10x1000) lanes.  Instead of capturing 200,000 rows of data, you could create: 

• a product grouping called “all products,” 
• a DC grouping called “all DCs,”  
• and a customer grouping called “all customers.”   

You can then use these groupings to capture one line of distance-based cost data for “all products” from “all DCs” to “all customers.” 

12. Mind the Business Rules

When compiling your first data set, your first focus is often (and should be) the base case data.  However, you should also keep an eye on future scenarios that you want to run.  There are many business rules that are inherently captured in base case flows. These business rules are typically restrictions for certain product flows in certain locations. 

You can model all of these business rules as constraints, so that when the model optimizes, it doesn’t do things that immediately prompt the business to say  “that’s not possible.” You should also explore whether your business rules are really hard and fast constraints, or whether they are built-in assumptions. To find out if you can ignore certain rules, you can run a scenario with the business rule in place, and then another scenario where the business rule is relaxed.  

We hope these tips help you prepare your model data successfully. If your model data is well-designed, your life will be a lot easier! In Part II of this series, we have delved into data collection best practices, see – Data Tips for Supply Chain Network Design Part II: Data Collection.

For more supply chain network design implementation tips download our guide.