14. Creating a Group and Running a Project
In this chapter, we will discuss how you actually complete network studies within a company. We will cover how you build a group and how you run a project.
Typical Steps to Complete a Network Design Study
In a typical project, you are likely to run into problems with the data as well as organizational challenges of working on a project that impacts many people within a firm. To get a network design study done, you need to treat it as a project and manage it as you would manage any complex project within a company. Of course, there are elements unique to a network design study. In this section, we will cover the typical steps that you want to include in your network design project plan. Broadly, any network design project can be broken into five main steps or phases:
1. Model scoping and data collection phase
2. Data analysis and validation phase
3. Baseline development and validation phase
4. What-if scenario analysis
5. Final conclusion and development of recommendations
Each step is critical and has its own specific purpose. It is important for the project team to go through all the phases, irrespective of the scope and complexity of the supply chain being analyzed or the amount of time available to complete the analysis.
Step 1: Model Scoping and Data Collection
Before you start any project, it is important to first understand the questions that are to be answered and the associated parts of the supply chain that may be impacted. This step may seem trivial and is often overlooked, but it is very important to have a clear understanding of what decisions are being made, and which parts of the supply chain are open to change and which parts are not. In this phase of the project, you are applying the lessons learned from Chapter 12, “The Art of Modeling,” and specifically the section “Understanding the Supply Chain.”
For a retailer that recently acquired another retail company, the key questions are likely to be:
• What is the optimal combined distribution network that minimizes logistics costs and maximizes service to stores and customers?
• Which existing distribution center locations are redundant and can be closed?
• What is the best way to distribute products to the newly combined store network?
For a consumer-products company that is looking to develop their long-term manufacturing strategy to support growth, the questions would be similar to the following:
• Should we expand existing plants or build new plants? If so, where and when?
• Which products should we manufacture internally and for which products should we use contract manufacturers?
• Is there an opportunity to source products across various regions?
These are just two distinct examples; every supply chain network design study will have a different scope.
What is the same between all projects however is that it is critical that you get everyone on the team to agree to the scope and questions the optimization will answer from the start. If you have to go back and make changes to this later, you will likely lose a significant amount of time and may have to effectively start over.
After the scope and questions to answer are finalized, the project team will need to come up with a list of all data that needs to be collected to build the model. This step needs to include a detailed discussion on the level of aggregation and what systems or third party sources the data will come from.
Depending on the model, you will then want to use the knowledge you gained from previous chapters in this book to determine what data goes into this specific model and how you should think about aggregating this data. After you have gone through the exercise of building your list of required data, you now need to collect the data. Collecting the data can often be a very time-consuming and frustrating experience.
Based on our experience, here are some tips to make your data collection efforts more successful and to help you determine how much effort you should anticipate. Note that in this phase we are looking to just access and extract the data. In the next phase we will do a thorough validation of the all the data.
1. Be prepared to collect data from outside a firm’s internal systems. There is data that exists in existing systems and data that does not. The purpose of a network design study is to understand the impact of running your supply chain in a different way. This may mean using different plants and warehouses, using new transportation lanes, making products in new locations, and so on. The key is that you need to be prepared to collect data or extrapolate from internal data for new elements you will want to consider in the analysis.
2. If multiple IT systems store the same type of data (say demand), you will need to spend more time collecting and validating the data. There is a chance that the systems will have different fields, that they will have different data definitions, and that the ID fields may not match up.
3. IT systems may be set up for accurate accounting and financial reporting, not necessarily for good supply chain analysis. So your existing systems may not have all the fields you need, and some data might not match up as you would expect.
4. When you gather cost information for new data elements, make sure that it matches with existing data. For example, firms will often have good transportation rates on lanes they use. These rates are often the result of negotiation with the carriers. If you ask for new transportation rates for new lanes, make sure that they are not the “retail” rates or they will be much higher than existing rates. As previously discussed in Chapter 6, “Adding Outbound Transportation to the Model,” if retail rates do need to be used, ensure these rates are used for both new and old lanes alike.
5. Make sure you understand the accounting cost data before using it. Often, accounting systems will allocate fixed and variable costs to a product in ways that do not make sense for network design studies. See Chapter 7, “Introducing Facility Fixed and Variable Costs,” for a thorough discussion of this topic.
6. It is usually better to collect raw data and not aggregated data. Although you have a plan for how you will aggregate, it will not save you time to pull aggregated data from your systems. Most likely, you will want to tweak the aggregation strategies or will need to validate the data that goes into aggregated items. It is best to ask for the raw data and do the simple step of aggregation yourself.
If the data collection is proving to be an extremely difficult task, don’t forget to review the lessons learned in Chapter 12 and Chapter 13, “Data Aggregation in Network Design.” You may be trying to collect more data than you actually need in order to get the answers to your defined network design questions.
Step 2: Data Analysis and Validation
After the data is collected, it is important to analyze and understand the data to ensure that it is clean and accurately reflects the way the business operates. Because you will be communicating the results of the study to other people in the organization, this phase of the project serves an important purpose of ensuring that you have a good set of data that you can explain to others and that others will agree to.
This phase includes a combination of the following activities: data cleansing, data analysis, data validation, and data aggregation.
Data Cleansing
After the initial data is collected, the first step is to review and fix obvious issues. Examples include:
• Missing or invalid ZIP Codes—For example, ZIP Codes in New England start with 0 (zero). Excel tends to drop the leading 0 which then either converts the ZIP Code 06457 (Middletown, Connecticut) into 6457, an invalid ZIP Code or, worse, leads someone to think that the location is in Missouri (ZIPs Codes starting with 645 are in Missouri).
• Shipment data with missing or invalid weights or cube (cube is a transportation term for the cubic size of a shipment)—For example, there may be truckload shipments showing shipment weights greater than the legal limits (for example, over 45,000 pounds in the U.S.).
• Order or shipment data with invalid origins or destinations—For example, the shipment origin may reflect the location of the supplier’s headquarters as opposed to the actual plant or warehouse the shipment originated from.
Data Analysis
After initial data cleansing is completed, the next step is to analyze the data to understand what it is saying. This can be accomplished by creating tables and summaries that aggregate and present data so that it can be evaluated. Summary reports may include:
• Total outbound volume shipped by wareshouse
• Total inbound volume received into each warehouse
• Number of products with active demand and Pareto analysis showing volume breakdown across products
• Total weight shipped by mode and by warehouse
• Total demand by state or region
• Total volume shipped by vendor or plant
• Cost per pound or or some other standard unit of weight (like hundredweight, ton, kilo, and so on) by mode for inbound and outbound shipments
• Average shipment weight by mode for inbound and outbound shipments
These reports will help paint a picture of how the supply chain operates and how products flow. They will also often point out obvious issues with data quality. For example, the total outbound volume shipped by a warehouse should be generally similar to the total inbound volume received by that warehouse in the same timeframe. If there is a large difference, it could be attributed to one of the following:
• Missing inbound or outbound data
• Dramatic inventory buildup or drawdown at specific locations or for specific products
• Incorrect data fields pulled from systems
Data Validation
After data summaries have been created, the next step is to validate the information with the business stakeholders overseeing the appropriate functions. For example, information summarizing the logistics costs, transportation mode assignments, or average shipment weight should be validated with the Logistics team. Information related to production costs or capital should be validated with the Finance team. This will serve two purposes for the project:
1. It ensures that the data has been validated by the appropriate owners of this information.
2. It gets people from all parts of the organization engaged upfront in the project so that when the results of the analysis are presented, they are more likely to be comfortable with the results and the recommendations because the underlying data was approved by them.
The data validation process may also help identify other issues with the data that may not have been obvious during the original data cleansing, necessitating a revised pull of data. The steps around data cleansing, analysis, and validation need to be repeated until the respective stakeholders feel comfortable that the data portrays a valid representation of their supply chain.
A side benefit of the data validation process is that it may quickly identify areas for improvement in the current supply chain even before any optimization is actually run. For example, a simple table summarizing the total volume and costs for out-of-region shipments from each warehouse can quickly provoke management to assign someone to fix the problems. This may seem surprising but the data validation exercise provides the ability to summarize and visualize existing data that may not be reported on by the firm on a regular basis.
Data Aggregation
After the data has been validated by the appropriate stakeholders, the next step is to start aggregating the data for the purposes of the network design model. After the previous steps are complete, this step should be relatively simple.
Step 3: Baseline Development and Validation
After the data has been validated and aggregated, it is now time to start building the actual model. When it comes to building a model, it is always best to start with a small, simple working model and add complexity incrementally while ensuring feasibility at each step.
The first model is built to represent the historical or as-is state representing how the supply chain operated historically. This model is referred to as the “baseline” model and it serves a couple of purposes:
• It helps validate that the model designed and developed is accurate. Because we are creating a representation of the current supply chain in the software, it is important to be able to compare model outputs against historical financial results for the same input data.
• It serves as the basis for creating additional what-if scenarios in the model.
To prepare for the baseline model build, you need to create the required data tables for importing into the network modeling software. The actual tables and the sequence of data imports may vary depending on the specific software application used.
When building the baseline model, do not think you will load every data element and run. As mentioned previously, it is best to start simple and then add more and more complex data elements as you go. Surprisingly, because this is what makes a baseline a baseline, we have often found that the last thing you want to add to the model is the historical flows of products. After the model is working and all the costs are loaded, you then finally add the historical flows.
It is important to be aware that adding the historical flows can get complicated if your data does not match. For example, let’s say that you ship 25.4 million pounds out of your Riverside warehouse and the Bridgewater warehouse ships 45.1 million pounds (see Figure 14.1). Assume that you have validated these shipments and these are the correct numbers you would like to use. However, when you analyze the shipments into the Riverside and Bridgewater warehouses from the Waco and Des Moines plants, you notice that the inbound and outbound numbers do not match up (also shown in Figure 14.1). This may be caused by various things, including poor data quality, accounting procedures, or warehouse transfers. One simple solution is to leave the results as they are. Then, a subsequent version of the baseline would have you make an adjustment to the inbound flows so that they match up with the outbound flows. This is shown in Figure 14.1 where we calculate the actual percentage mix coming from each of the plants and then multiply that by the total outbound shipments from the warehouses to come up with an inbound flow that equals the outbound flow. Remember, when the optimization scenarios run, the results will show an inbound flow that matches the outbound flow. Therefore it is important for us to maintain the same equality in the baseline so we can compare back to it.
Figure 14.1. Example Showing Balancing of Inbound and Outbound Flows in Baseline Modeling
After the baseline model starts providing reasonable results, the next step is to start comparing the outputs against actual financial results or original systems data from the same time period. The focus is primarily on model cost versus actual costs, but you may also want to validate volumes and capacity utilization. Besides validating the total costs, you may also want to validate the costs of various categories such as:
• Inbound transportation costs by mode
• Outbound transportation costs by mode
• Warehouse fixed costs
• Warehouse variable costs
• Manufacturing variable costs (if applicable)
• Manufacturing fixed costs (if applicable)
• Sourcing costs
The results need to be validated, usually within 1% to 10% of actual costs. After validation, you want to run the appropriate optimized baseline model. For a more detailed discussion on validation and the optimized baseline model, see Chapter 8, “Baselines and Optimal Baselines.”
After the baseline and optimized baseline scenarios are completed, it is time to document all the data assumptions, the business rules, and a summary of the baseline model results and present them to the project team and stakeholders. This is a major milestone in the project life cycle and it requires validation and sign-off from all the appropriate sponsors and stakeholders.
Step 4: What-If Scenario Analysis
After the baseline model is developed and approved, we are now ready to start running what-if scenarios. This phase represents the “fun” part of a project, and the phase where the real focus lies in ensuring all the key project questions get addressed.
Before we start running any scenarios, it is important to review the key questions that were stated during the project scoping phase and develop a list of scenarios that would makes sense to run in order to address those questions.
The most important scenarios to run are those that answer the key questions. For example, if the key question is to find the best three, four, and five warehouses, you want to run those scenarios. But, you want to hit the run button more than just three times. To best answer the key questions, you have to understand different what-if questions. A project will have many different what-if questions. Here are three basic ones.
• What if we picked a different set or different number of facilities?
• What if demand was higher, what if demand was lower?
• What if our projected costs were higher, what if they were lower?
The goal with the what-if scenarios is to make sure you have a solid answer, to make sure you can explain your answer, and to make sure the answer is robust.
The more scenarios you run, the better the answer you will have. You will trust that the model has been set up correctly and well-tested, you will have explored many solutions and have a good understanding of the best solution, and you will be able to understand when different solutions have similar costs. It is important to find different solutions with similar costs. There will be many non-quantifiable factors that the team will want to consider. By having a range of solutions to choose from, you can better factor the non-quantifiable costs into the decision-making process.
The more scenarios you run, the better you will be able to explain your answer. The scenario runs allow you to understand what factors are most important to the solutions. For example, what is driving the answer? Is it transportation costs or manufacturing costs or the need to be located close to customers? Remember, we need to explain the results to a wide range of people who are not as familiar with the model or network modeling, in general. The better you can understand and explain the results, the higher the chance that others will understand it as well.
The more scenarios you run, the better you can understand how robust the solutions are. Many of the inputs to a network design model are forecasts or projections. For example, demand and transportation costs next year are not known. You want to run the model to test different forecasts and projections. You want to understand how the answer changes as key input values change. But, also, what you are doing is trying to understand how well your solutions hold up if the forecasts and projections are wrong. For example, a solution that is “great” for one set of input data but terrible if that input changes may not be as good as a solution that is just “good” for one set of input data but still “good” if that input changes.
Also, don’t be afraid to run a lot of different scenarios that may not directly address the key questions. You have now seen examples of many different types of scenario runs throughout this book. Feel free to experiment and use your creativity.
We will learn something new with each scenario, which will in turn raise more questions requiring the running of additional scenarios with more specific variations and changes. This is typical in a network design project; it is a healthy process and illustrates the power of the iterative what-if scenario analysis. Ultimately, the model will help us learn what factors are really driving the recommended structure of the network.
Step 5: Final Conclusion and Development of Recommendations
No matter how fun the scenario analysis is, we eventually have to come to a conclusion. So after we have run a sufficient number of scenarios to test various alternatives, and understand the best solutions, it is time to compile the results along with supporting analysis for presenting to the management team.
At a high level, this may seem straightforward given that the hard work of collecting the data, building the model, and running the scenarios is complete. However, this step is often the most important and critical part of the entire project. This is because this phase is where we present and sell the results of the entire analysis—even if the study was based on sound analysis and extensive due diligence, it may end up as a futile exercise if it is not presented with all of the compiled information and recommendations summarized in a concise manner that helps management understand and make better decisions.
When you are developing the final recommendation(s), it is important to consider both qualitative and quantitative factors that are not covered as part of the model as well. These may include:
• Complexity of implementation (related to how many new sites are opened and how many are closed; the higher the number of changes, the higher the complexity)
• Availability of labor and space (if new plant or warehouse sites are recommended)
• Impact of network changes on customer perception and demand
• Timeline and road map for implementation of changes
• Dependence on other factors such as IT system changes/availability, integration with third-party vendors
• Tax and regulatory implications
Following is a high-level overview of a good structure for a final presentation:
• Project Objectives and Scope Review
• The objectives of the study should be clearly outlined, specifying the questions that are being answered by the analysis.
• It is equally important to highlight the key questions that are not part of the scope of the study, especially if this study focuses on a subset of the overall initiative. This can help the presentation go much more smoothly, making it easier for the audience to understand the context and to set their expectations appropriately from the start.
• Executive Summary (Optional)
• When the audience includes senior executives, it is useful to include a one-slide summary of the key findings and recommendations to make the best use of the limited time you are given with them.
• Project and Data Assumptions
• This section covers a quick summary of the detailed scope and a review of the data assumptions, calling out those that were used to bridge gaps in data.
• Baseline Validation (Optional)
• It may be beneficial to quickly touch on the baseline model results to remind the audience about this intermediate milestone.
• It is also important to touch on how the baseline scenario was validated against the financials, and therefore is a legitimate basis to compare against future scenarios.
• Scenario Analysis
• The first section focuses on the scenarios tied to the main questions that were evaluated as part of the analysis.
• The second (shorter) section focuses on sensitivity analysis run on the key finalized recommendation(s) to test impact of key variables. It would also make sense to address other qualitative factors such as labor or space availability, implementation complexity, and so on.
• Final Summary and Recommendations
• The final recommendations section should list the best solution(s) for further evaluation and analysis. Note that this type of exercise is meant to provide decision support to management, and is not intended to yield a single best solution. Depending on the recommended solution(s), additional follow-on validation exercises may be required, including developing a detailed financial business case (with ROI and cash flow analyses), especially if the final solution requires extensive capital investment.
• Next Steps
• A typical network design study rarely ends with the final presentation—there are often additional scenarios or follow-on analyses as a result of discussions in these meetings.
• Once these additional scenarios and follow-on analyses are run, and discussed, and decided upon, the project team then develops the implementation plan to turn the strategy into a reality.
Setting Up a Modeling Group
The preceding steps are the ones you will follow for any network design project. An important question we have not yet discussed often arises directly after the initial need for the study has been determined. Should a firm do the project themselves or have a third-party consulting firm perform it on their behalf?
While there is no correct answer to this question, the following guidelines are helpful for making the decision.
It may be better for a firm to do this work internally if any of the following situations is true:
• The firm’s supply chain is large, dynamic, and changes frequently. It may be changing through acquisitions or through the need to analyze each of your distinct markets, like North America, South America, Europe, Asia, and so on.
• The firm may have many different divisions or business units that require separate analysis.
• A single firm may have many different network optimization needs such as the ability to do budgeting and capital planning, reconfiguring warehouse territories, planning for seasonal spikes or seasonal changes to their supply chain.
• A firm needs to rerun scenarios or tweak the solutions during the implementation so they can adjust as time passes and the new supply chain takes shape.
Of course, the opposite of the preceding list gives you reasons for using a consulting firm. In addition, there are a few unique items to add to the reasons for working with a consultant:
• Unannounced acquisitions, potential major layoffs, or new product introductions may require dealing with very sensitive data and therefore using third parties to analyze may provide the needed anonymity.
• The firm has an especially hard project and needs to bring in people who are experts at network design models and who can add value in other aspects of the project management as well.
• The firm has a very tight deadline on the timing of the project’s completion and therefore needs additional experienced team members quickly to ensure its completion in time. We have seen this occur when companies want to validate a new location before starting to implement a major decision previously made without the validation of network modeling.
• In some cases, the political environment is such that it is best to have a third party work on the project. Unannounced acquisitions, potential major layoffs, or new product introductions may deal with very sensitive data and therefore utilizing third parties to analyze may ensure the needed anonymity.
If a firm decides to build a modeling group in-house, they need to consider the best way to structure and staff the team. The firm should determine whether to structure this group centrally or deploy to the regions and business units. The benefit of a central group is better capturing and sharing of knowledge across the business units and may enable a better balance of the workload generated by many different projects. The benefit of regional groups or groups by business units is that firms can push the knowledge deeper in the organization. Often, large firms do not have to choose between the two extremes though. There can be a small central group that supports the regions and business units. The central group may be called in for the more difficult models and facilitate the sharing of information across the organization.
A firm will also need to determine how they will pay for the group and how it will generate projects. They may want to set up the group as a function that is paid by the corporate office conducting projects that help the entire business. They may also set up the group so that each region or business unit pays for their own support. For projects, there may be mandatory projects that groups need to run, or each business unit may need to come to the group with their own request for an analysis. Also, the group may be responsible for generating demand for their work. However, we have seen many cases in which the initial successes of a group like this creates its own demand through word of mouth within the firm.
A firm then needs to determine how they will staff this group. It is clear that people are needed to do the modeling. The number of modelers however, obviously depends on the amount of work you expect this team to complete. In addition to modelers, the team will also need a manager for the group and/or several project managers to oversee and guide the end to end work of each analysis. The number here again varies with the size of the group, and a person may sometimes play the role of a modeler and a manager at the same time. The modeler, often called an analyst, is responsible for collecting data, validating the data, building the baseline, running scenarios, and assisting with the final presentation. The manager is responsible for running projects, determining the scope, presenting recommendations, and helping the modeler get work done when required. Besides this core group, the team also needs to decide whether full or part time IT experts (for data collection) and subject matter experts (transportation or manufacturing) will be needed on the team to assist in their area of expertise. If these people are not on the team, their help will still be needed for key questions regarding extraction and clarification of modeling data. The larger the group, the more likely the team will have full-time demand for this expertise. Otherwise, it is probably best to share this expertise with other groups.
When thinking about the optimal skillset for people on the modeling team, a firm will want people who are relatively technical and able to work with large data sets. They need to be able to communicate with a wide range of people in the organization and have a good understanding of or willingness to learn the functions across the entire supply chain. Also, equally important, these people must be comfortable with some level of ambiguity. Network modeling is not accounting. There will always be a margin of error in the results and decisions need to be made with confidence in the data and assumptions used in the model. A good deal of time can be wasted when modelers become too intent on very granular levels of data and poor aggregation strategies which inevitably leads to a disastrous project timeline.
Lessons Learned
It is important to follow the methodology for running a network design project in order to ensure that the questions are appropriately answered and the project is successful. These are large projects and touch many people in the organization. Firms need to manage this like a project and not treat this just as a technical exercise.
There are valid reasons for doing this work internally and for having a third party consulting firm do it. If you build the group yourself, it is important that you structure the group in a way that ensures a high likelihood of success from the start.
End-of-Chapter Questions
1. If you are considering closing a warehouse and opening a new one, what people in the organization might be impacted and how might they react to the project?
2. Name other reasons a firm may want to build a group and other reasons they may use a consulting firm. Describe a hybrid approach (there is an in-house capability and a consulting firm is also used to help with the analysis) and the pros and cons of a hybrid approach.
3. When collecting data, you find that the demand data is listed by total units sold to each ship-to location, but the transportation that shows which customer was served by which warehouse only provides the total weight moving between the sites. You would like to be able to match up the files but cannot because you don’t have product information in the transportation file. Setting aside your needs, why might this data be perfectly fine for the rest of the organization?
4. When validating the demand information, you discover that the customer information is given as the bill-to address. Why won’t this help you?
5. During the scenario analysis stage, why is it important to determine specific scenarios you want to run? Why is it also important to experiment?
6. In the final presentation step, why is it important to review the data collection?