Chapter 11 Cost/Flow Baseline

Transcription

1 Chapter 11 Cost/Flow Baseline 11.1 Introduction Overview A cost/flow baseline in SAILS serves two purposes: to establish model validity, and to provide a basis for comparing the results of a given optimization scenario with the current system. Both purposes are important to the success of a SAILS study. Theories About Simplified Models All models, whether physical or mathematical, are simplifications of the reality they are meant to represent. The simplifications are obvious for most physical models: the map with colored pins and strings on the office wall is not the real logistics network any more than the wooden model of a sailing ship is a seaworthy vessel. In such instances, we have little or no difficulty identifying the differences between model and reality. Moreover, if the model is properly designed, we accept these simplifications because the model still conveys a great deal of useful information to us. Concerns About Simplifying the Model With the mathematical models found in SAILS, simplifying the model isn t always so straightforward. The simplifications are clear enough: commodity, customer and time aggregation, average facility costs, weighted average freight costs, customer service expressed in terms of distance, and so on. The problem lies with acceptance we worry that in simplifying the model, we fail to accurately represent the underlying logistics network. Moreover, logisticians tend to be detail-oriented, and sacrificing detail might cause some to feel they are betraying the profession. In this environment, a confidence booster is clearly in order! User Experience: Validating the Model Most experienced SAILS users know the ultimate test of model validity: whether or not the model recommendations, when implemented, yield the predicted results. Their experience serves as their primary validation criterion.

2 11-2 CHAPTER 11: COST/FLOW BASELINE Introduction, continued User Experience: Validating the Model, continued However, beginning SAILS users as well as experienced users with new models cannot rely on previous studies. They must deal with model validity prior to results implementation. In such instances, the time-honored approach is to look backward prior to looking forward. Theory of Cost/Flow Baseline In SAILS, we attempt to replicate the logistics flows and costs for a given historical base time period. We then compare model results with known historical values and assess model accuracy. The underlying rationale is simple: if we can reasonably replicate history, then our willingness to accept recommendations about the future increases. However, failure to replicate known historical values calls into question the results of forward-looking scenarios. The process of replicating a historical set of network flows and costs is known as constructing a cost/flow baseline, or simply, a baseline. In this Chapter The Cost/Flow Baseline chapter is organized as follows: Section Page 11.1 Introduction 11-1 Overview 11-1 Theories About Simplified Models 11-1 Concerns About Simplifying the Model 11-1 User Experience: Validating the Model 11-1 Theory of Cost/Flow Baseline 11-2 In this Chapter Strategy for Creating the Baseline 11-5 Overview 11-5 What You Need to Know First Outbound Transaction File 11-6 Prerequisites for Creating the Baseline 11-6 Importance of the Origin DC Location Baseline/Solver Consistency 11-6 Overview Commodity Flow Requirements 11-7 Overview 11-7 Flow Balance Commodity Flows: ODS Baseline 11-8 Overview 11-8 continued on the next page

3 SAILS OPTIMIZATION SOFTWARE 11-3 Introduction, continued In this Chapter, continued Section Page Customer Demands and Outbound 11-8 Flows Replenishment Flows 11-9 Sources of Replenishment Flow Percentages Finished Product Production Requirements Commodity Flows: OPTIMA Baseline Overview Customer Demands and Outbound Flows Replenishment and Transfer Flows Potential Problems Finished Product Production Allocation Intermediate Product Requirements Computation Intermediate Product Flow Allocation Intermediate Product Production Raw Material Requirements Computation Raw Material Inbound Flows Raw Material Supplier Requirements Cost/Flow Baseline: ODS Models Procedure Cost/Flow Baseline: OPTIMA Models Procedure Accounting and Model Baselines Overview The Accounting Baseline The Model Baseline When the Model Baseline is Used Output Reports and Files Overview Written Reports Graphics Package Input File Machine-Readable Solution Files continued on the next page

4 11-4 CHAPTER 11: COST/FLOW BASELINE Introduction, continued In this Chapter, continued Section Page 11.7 Action Plan Data Requirements Frequency of Use Model Validation Beware of Independent Accounting Data A Final Perspective Chapter Summary 11-31

5 SAILS OPTIMIZATION SOFTWARE Strategy for Creating the Baseline Overview The primary method used to establish SAILS model validity is to construct a historical cost/flow baseline, which is then compared with corresponding known values. The broad outline of the procedure is described below. Step Action 1 Establish historical customer demand levels. 2 Establish historical flows for each transportation link, by commodity. 3 Establish historical flows for each facility location, by commodity. 4 Multiply each transportation link flow by the corresponding unit transportation cost. 5 Multiply each facility location flow by the corresponding unit cost (procurement, manufacturing, DC). 6 Establish the fixed cost for all corresponding facilities with positive flow (plants, production lines, DC locations). 7 Add the results from Steps 4 through 6. 8 Compare volumes and costs with known historical values and assess overall model validity. NOTE: Steps 1 through 7 are executed by a special cost/flow baseline module in SAILS. You must perform Step 8 outside of SAILS. What You Need to Know First This chapter describes the detailed, step-by-step procedures that SAILS uses to establish cost/flow baselines for the ODS and OPTIMA models. However, we first discuss the following topics, which are essential to your understanding of a SAILS baseline: outbound transaction file requirement baseline/solver consistency commodity flow requirements commodity flows: ODS baseline commodity flows: OPTIMA baseline

6 11-6 CHAPTER 11: COST/FLOW BASELINE 11.2 Strategy for Creating the Baseline, continued Outbound Transaction File Prerequisites for Creating the Baseline The SAILS cost/flow baseline module can be used only if an outbound transaction file is available and has been processed. Both full and miniature versions are acceptable. SAILS extracts two types of information from the outbound transaction file to create the baseline: 1 Total historical customer demand for each customer region/customer class/ finished product group. 2 Total historical flow for each outbound (DC-to-customer) transportation link, broken down by customer class and product group. NOTE: SAILS ignores manually-supplied demands when establishing a baseline. They could be used to satisfy item 1, but manually-supplied demands lack the lane-specific detail required for item 2. Importance of the Origin DC Location Lane-specific detail can be reconstructed from an outbound transaction file because each entry contains an origin DC location, a destination customer location, a customer class designator, and a finished product stock code. The origin DC location, completely ignored by the SAILS solvers, establishes the starting point of each historical outbound shipment. Therefore, the origin DC location must be the true ship-from location, and not some other accounting entry Baseline/Solver Consistency Overview The SAILS cost/flow baseline module uses the same customer demand, freight cost, and facility data as the solver uses. In addition, it uses the outbound link product flow history, and certain special flow allocation tables, which serve to lock up the remaining network flows into historical patterns. The only exception to this convention, as previously stated, is that manually-supplied customer demands are ignored by the baseline module.

7 SAILS OPTIMIZATION SOFTWARE Strategy for Creating the Baseline, continued Overview, continued In the SAILS cost/flow baseline, data consistency means that customer demands are extracted from the outbound transaction file freight costs and facility data are selected using the scenario generation procedures outlined in Chapter 10 all data scaling options are recognized Commodity Flow Requirements Overview In Chapter 10 (and again in Chapter 12), we discussed an idea of central importance to the SAILS solvers: for every commodity, whether raw material, intermediate product, or finished product, the total quantity demanded must equal the total quantity supplied. Furthermore, the SAILS user provides the demands for finished products via the manual and/or outbound transaction file options. Demands for intermediate products and/or raw materials, however, are derived by SAILS as a function of both finished product demand and the applicable commodity conversion coefficients (recipes) described in Chapter 7. In other words, the SAILS solvers work backwards, beginning with finished product demand, to establish the corresponding requirements for intermediate products and/or raw materials. In short, finished product demand drives the entire cost/flow baseline process. Flow Balance Flow balance is an extension of the requirement that demand must equal supply for each commodity. Recall from Chapter 10 that, if a given commodity is to be shipped from or consumed at a given location, an identical quantity must originate at or be shipped into the same location. In other words, what goes out must come in.

8 11-8 CHAPTER 11: COST/FLOW BASELINE 11.2 Strategy for Creating the Baseline, continued Flow Balance, continued Supply/demand equality and flow balance requirements are important in the cost/flow baseline, and much of SAILS design is based on them. Remember: the key to establishing an accurate baseline is to get the commodity flows locked up into a historically accurate pattern. Once that is accomplished, each flow is multiplied by a corresponding variable cost (whether transportation or facility), fixed costs are added in, and the results are totaled. If the bottom line is wrong yet the flows are correct, that usually means that the cost values are in error (also, the accounting data reference standard could be incorrect and cause this problem, as described later). But if the commodity flows are wrong, then the entire baseline is flawed. In this case, the results will inevitably be incorrect, and it will be considerably more difficult to isolate the problem(s). IMPORTANT: Be sure that you get the commodity flows as accurate as possible Commodity Flows: ODS Baseline Overview This section describes how finished product network flows are established for an ODS baseline. Even if you are an OPTIMA user you should read this section carefully. ODS is less complicated than OPTIMA and the baseline logic is easier to follow. Moreover, we illustrate certain essential flow allocation conventions that we assume you understand when we cover the OPTIMA baseline procedure. This section describes only the procedure for establishing flows. In Section 11.3, we describe the complete ODS cost/flow baseline procedure. Customer Demands and Outbound Flows The ODS baseline module first establishes the total demand for each customer region/customer class/finished product group using the values extracted from the outbound transaction file. It then traces these demands backward to the originating DC locations. In the process, all historical lane-by-lane outbound flows are recorded, as is the total quantity shipped from each DC location to all of the customers it services.

9 SAILS OPTIMIZATION SOFTWARE Strategy for Creating the Baseline, continued Replenishment Flows Since DC transfer links are not recognized by ODS, the only remaining flow assignment task is to trace the DC requirements back to the plant level. It is at this point that the supply/demand and flow balance conventions come into play. By model requirement, for any given commodity the total amount shipped from a DC location (outbound flows) must equal the total amount shipped to the location (replenishment flows). We see immediately that we cannot use the absolute plant/dc location historical flow quantities. It is likely that, for any given DC location/product group, the total quantity received will not be exactly equal to the total quantity shipped. In other words, there was at least some inventory net drawdown or buildup during the base period. But the flow balance requirement mandates equality. What is the solution? The answer is to express the replenishment flows as percentages instead of as absolutes. For any given DC location/product group combination, we wish to know the percentages of the total amount received by the DC for the given product group that was shipped by each plant location. We then allocate the total DC requirement (sum of all outbound shipments) to the plant locations using these percentages. By following this convention, supply must necessarily equal demand and flow balances are necessarily preserved. Moreover, we have now established all replenishment flows and plant location production requirements. Network flows have been successfully traced from the bottom of the ODS network (customer regions) through the DC locations and to the top (plant locations). To illustrate this procedure, consider the simple example in Figure Customer regions 1 and 2 demand 100 and 200 units, respectively, of product group X. Assume that both were serviced in their entirety from DC location A. Therefore, DC A shipped a total of 300 units of product X via outbound links and, to preserve flow balance, must receive 300 units of X via replenishment links.

10 11-10 CHAPTER 11: COST/FLOW BASELINE 11.2 Strategy for Creating the Baseline, continued Replenishment Flows, continued Plant 1 Plant 2 Flow = 240 (0.80) Flow = 60 (0.20) DC Location A Throughput = 300 Flow = 100 Flow = 200 * * Customer Region 1 Demand = 100 Customer Region 2 Demand = 200 Figure Establishing flows in the SAILS ODS cost/flow baseline. Customer demands and outbound link flows are derived from an outbound transaction history file. SAILS then rolls up these requirements to the origin DC level. From there, percentages guide the allocation back to the plants, whether the percentages are derived from a replenishment transaction history file or supplied by the user. Similar schemes are used to establish an OPTIMA baseline; however, more types of flow allocation percentages are required due to increased model complexity. Next, assume that two plants, P 1 and P 2, manufacture X and that 80% of the total amount of X received by DC A was from P 1, while 20% of the total was from P 2. Therefore, the replenishment flows from P 1 and P 2 to DC A for product group X are 240 and 60, respectively. NOTE: The percentages shown in Figure 11-1 are established with respect to the volume received by DC A. They do not necessarily mean that plants P 1 and P 2 manufactured 80% and 20%, respectively, of the systemwide demand for product X.

11 SAILS OPTIMIZATION SOFTWARE Strategy for Creating the Baseline, continued Sources of Replenishment Flow Percentages Two sources are available for obtaining replenishment flow percentages. The first is a replenishment transaction file. As discussed in Chapter 6, SAILS processes the file and automatically prepares a flow allocation table for use in the baseline module. The second source is a manually-supplied table. You can provide a table of replenishment flow allocation percentages, either in conjunction with or in lieu of, a replenishment transaction file. If both sources are available, SAILS merges them automatically as follows: for each DC location/product group that you supply, SAILS will override (replace) corresponding values from the replenishment transaction file. Otherwise, it uses data extracted from the file. What if flow allocation percentages are unavailable from either source for a given DC location/product group combination? In this instance, SAILS allocates the requirement equally across all plant locations that are eligible to make the given product (see our discussion of eligibility tables in Chapter 10). For example, consider once again the situation in Figure 11-1, but this time assume that replenishment flow allocation percentages have not been supplied. Also, assume that both plants are eligible to manufacture the commodity. In this instance, SAILS would establish an allocation percentage of 0.50 for each plant as shown in Figure If three plants were eligible, then each would be assigned 0.33 of the DC requirement; if four, then each would be assigned 0.25, and so on.

12 11-12 CHAPTER 11: COST/FLOW BASELINE 11.2 Strategy for Creating the Baseline, continued Sources of Replenishment Flow Percentages, continued Plant 1 Plant 2 Flow = 150 (0.50) Flow = 150 (0.50) DC Location A Throughput = 300 Flow = 100 Flow = 200 * Customer Region 1 Demand = 100 * Customer Region 2 Demand = 200 Figure The result when flow allocation data is not supplied. Whenever SAILS cannot establish flows from one echelon to another, it allocates the requirement (in this example 300 at DC A) equally across all possible (eligible) origins. Is the equal allocation assumption realistic? Of course not! Then why is it used by SAILS at all? Primarily to get your attention! It is invoked only when flow allocation data is unavailable, in this instance, for any given DC location/product group. Other conventions, such as selecting the least cost source, are unacceptable because they assume too much. The real message here is that an accurate baseline requires accurate flow allocation data. Finally, replenishment flow allocation percentages are never required for products that are available from only one plant location. SAILS can figure that one out without additional guidance from you! Finished Product Production Requirements SAILS establishes production requirements for each plant by adding together the originating replenishment flows at each plant location. No additional allocations are required ODS does not recognize production lines, and we have reached the top of the network.

13 SAILS OPTIMIZATION SOFTWARE Strategy for Creating the Baseline, continued Commodity Flows: OPTIMA Baseline Overview Establishing flows for an OPTIMA baseline is considerably more involved than for an ODS model. However, the underlying conventions remain identical: supply must be equal to demand, flow balances must be preserved, and flow allocation tables guide the process. This section describes how to establish network flows. In Section 11.4 we present the entire OPTIMA cost/flow baseline procedure. Customer Demands and Outbound Flows The OPTIMA baseline module first establishes the total demand for each customer region/customer class/finished product group, using the values extracted from the outbound transaction file. It then traces these demands backward to the originating DC locations. In the process, all historical lane-by-lane outbound flows are recorded, as is the total quantity shipped from each DC location to all of the customers it services. This is the only task that is identical to that used for ODS. From here on out, the procedures are quite different. Replenishment and Transfer Flows Once the total quantity shipped from each DC location to customers (outbound flows) is established, it must be traced back to the plant echelon. Because OPTIMA allows DC transfer links, this process is not as straightforward as it is for ODS. Keep in mind that each DC location can receive products via two kinds of links (replenishment and transfer in) and can ship products via two kinds of links (outbound and transfer out). The baseline module establishes replenishment and transfer flows using the corresponding flow allocation tables shown in Figures 11-3 and These tables can be supplied manually, via replenishment and/or transfer transaction files (SAILS extracts the required flow allocation percentages see Chapter 6), or both.

14 11-14 CHAPTER 11: COST/FLOW BASELINE 11.2 Strategy for Creating the Baseline, continued Replenishment and Transfer Flows, continued REPLENISHMENT HISTORICAL FLOW TABLE (EACH DESTINATION DC LOCATION) Origin Plant Locations Finished Products Figure A replenishment historical flow allocation table for OPTIMA. The flow allocation percentages (expressed as decimal fractions) for each finished product must total 1.0 across the possible plant (replenishment) and DC (transfer) origins. The transfer values are shown in Figure A separate table must be supplied for each DC location. Finished Products DC TRANSFER HISTORICAL FLOW TABLE (EACH DESTINATION DC LOCATION) Origin DC Locations Figure A DC transfer historical flow allocation table for OPTIMA. The flow allocation percentages (expressed as decimal fractions) for each finished product must total 1.0 across the possible DC (transfer) and plant (replenishment) origins. The replenishment values are shown in Figure A separate table must be supplied for each DC location. If both sources for a given link type (replenishment or transfer) are available, SAILS automatically merges them together as follows: for each DC location/product group supplied by you, SAILS will override (replace) corresponding values from the transaction file. Otherwise, it uses data extracted from the file.

15 SAILS OPTIMIZATION SOFTWARE Strategy for Creating the Baseline, continued Replenishment and Transfer Flows, continued If flow allocation percentages are unavailable from either source, then SAILS allocates the requirement equally across all plant locations that are eligible to make the given product (see ODS procedure above). In this instance, replenishment flows only are induced the equal allocation logic does not activate DC transfer flows. Potential Problems: Replenishment and Transfer Flows Listed below are some potential problems that you should be aware of: 1 If a given DC location receives a given product group from both replenishment and DC transfer links, the allocation percentages for the DC product must total 100% across the replenishment and transfer flow allocation tables. In other words, it is the sum across all possible sources of resupply that matters. SAILS takes care of this automatically if you supply transaction files, but you must ensure this cross-table integrity yourself if you supply the flow allocation tables manually. See Figures 11-3 and SAILS does not permit reverse flows that is, transfer flows from a DC location at a given echelon level to a DC at a higher level. If such flows are indicated in the flow allocation tables, whether derived from a transaction file or manually supplied, the corresponding data is ignored and the remaining percentages are recomputed. 3 You can set up a circular flow pattern via transfer links. Suppose that DC A is a source for DC B for product group X, and that DC B is a source for DC A for the same product. The two locations will exchange X forever there is no way out! SAILS will issue a warning about a circular flow pattern but cannot unilaterally fix the problem. Moral of story: be sure that every DC is ultimately connected to a plant for each product group it handles, either directly via replenishment links or indirectly via transfer links. Moreover, avoid exchanges of the same product between locations.

16 11-16 CHAPTER 11: COST/FLOW BASELINE 11.2 Strategy for Creating the Baseline, continued Potential Problems: Replenishment and Transfer Flows, continued NOTE: Circular flows can occur only when transfers are permitted between locations at the same echelon level. If a hierarchical flow pattern is maintained, where each echelon receives a product only from higher echelons, then circular flows are impossible. Finished Product Production Allocation Once the production requirements are established at each plant (by adding together the originating replenishment flows), they must be allocated across production lines. SAILS does so by means of the production line allocation tables that you supply for each plant (see Figure 11-5). FINISHED PRODUCT PRODUCTION LINE FLOW ALLOCATION TABLE (EACH PLANT LOCATION) Finished Products Production Lines = = = 1.00 Figure The OPTIMA finished product production line historical flow allocation table. The production requirement for each finished product eligible for manufacture at a given plant must be allocated across all eligible production lines at that plant. A separate table must be supplied for each plant location. You need to supply this information only for those products at a given plant that are eligible to be manufactured on more than one production line. Therefore, IF only one production line is being modeled at a given plant, OR if every product manufactured at a given plant is eligible on only one line, THEN this table can be omitted for that plant. Finally, if you fail to supply this table for a plant where a given finished product is eligible to be manufactured on more than one production line, then SAILS will allocate the requirement for the finished product equally across all eligible lines.

17 SAILS OPTIMIZATION SOFTWARE Strategy for Creating the Baseline, continued Intermediate Product Requirements Computation Intermediate product requirements are established for each plant as a function of finished product production requirements, and intermediate product to finished product conversion coefficients (recipes). SAILS automatically performs the required computations. Intermediate Product Flow Allocation Intermediate product requirements can be satisfied for a given plant by any combination of intermediate product manufacturing at the given plant interplant intermediate product transfer flows from other plants SAILS allocates the intermediate product requirements across these sources using the intermediate product flow allocation tables that you supply for each plant (see in Figure 11-6). You need to supply this information only if you wish to induce interplant intermediate product transfers. In the absence of this table for a given plant, SAILS assumes that the entire requirement must be manufactured on site.

18 11-18 CHAPTER 11: COST/FLOW BASELINE 11.2 Strategy for Creating the Baseline, continued Intermediate Product Flow Allocation, continued INTERPLANT INTERMEDIATE TRANSFER HISTORICAL FLOW TABLE (EACH DESTINATION PLANT LOCATION) Origin Plant Locations Intermediate Products = = = 1.00 Figure The OPTIMA intermediate product interplant transfer historical flow allocation table. The requirement for each intermediate product at a given plant must be satisfied either via manufacturing at the plant (indicated by a positive value where the origin and destination plants are the same) or via interplant transfers. If this table is omitted, then the requirement is satisfied exclusively via on-site manufacturing no interplant transfers are induced. A separate table must be supplied for each plant location. Intermediate Product Production Once the intermediate product production requirements are established at each plant, they must be allocated across intermediate product production lines. SAILS does so using the intermediate product production line allocation tables that you supply for each plant (see Figure 11-7). INTERMEDIATE PRODUCT PRODUCTION LINE FLOW ALLOCATION TABLE (EACH PLANT LOCATION) Intermediate Products Intermediate Product Production Lines = = = 1.00 Figure The OPTIMA intermediate product production line flow allocation table. The production requirement for each intermediate product eligible for manufacture at a given

19 SAILS OPTIMIZATION SOFTWARE plant must be allocated across all eligible production lines at that plant. A separate table must be supplied for each plant location.

20 11-20 CHAPTER 11: COST/FLOW BASELINE 11.2 Strategy for Creating the Baseline, continued Intermediate Product Production, continued You need to supply this information only for those intermediate products at a given plant that are eligible to be manufactured on more than one production line. Therefore, IF only one intermediate product production line is being modeled at a given plant, OR if every intermediate product manufactured at a given plant is eligible on only one line, THEN this table can be omitted for that plant. Finally, if you fail to supply this table for a plant where a given intermediate product is eligible to be manufactured on more than one line, then SAILS will allocate the requirement for the intermediate product equally across all eligible lines. Raw Material Requirements Computation Raw material requirements are established for each plant as described below: IF intermediate THEN raw material requirements are products established as a function of are being modeled, intermediate product production requirements raw material-to-intermediate product conversion coefficients (recipes) are not being modeled, finished product production requirements raw material-to-finished product conversion coefficients (recipes) SAILS automatically performs the required computations. Raw Material Inbound Flows Once the raw material requirements are established at each plant, they must be allocated across raw material suppliers. SAILS does so using an inbound flow allocation table for each plant, as illustrated in Figure 11-8.

21 SAILS OPTIMIZATION SOFTWARE Strategy for Creating the Baseline, continued Raw Material Inbound Flows, continued INBOUND HISTORICAL FLOW TABLE (EACH DESTINATION PLANT LOCATION) Origin Raw Material Suppliers Raw Materials = = = 1.00 Figure An inbound historical flow allocation table. The flow allocation percentages (expressed as decimal fractions) for each raw material must total 1.0 across the possible origin raw material suppliers. A separate table must be supplied for each plant location. You can supply this information manually, by means of an inbound transaction file (SAILS extracts the required flow allocation percentages), or both. If both sources are available, SAILS automatically merges the tables where, as before, manually-supplied data overrides any corresponding values generated from the transaction file. A separate such merge decision is made for each plant location/raw material combination. Raw Material Supplier Requirements SAILS establishes raw material requirements for each supplier by adding together the originating inbound flows at each supplier location. Additional allocations are not required we have now reached the top of the OPTIMA network.

22 11-22 CHAPTER 11: COST/FLOW BASELINE 11.3 Cost/Flow Baseline: ODS Models Procedure The complete procedure for establishing a historical cost/flow baseline for an ODS model is as follows: Step Action 1 Establish the total historical demand for each customer region/customer class/ product group combination by obtaining the required values from the outbound transaction file. 2 Establish the total historical flow for each outbound transportation link for each finished product by obtaining the required values from the outbound transaction file. 3 Establish the total historical transportation cost for each outbound transportation link by multiplying the flows from Step 2 by the corresponding outbound weighted average transportation costs selected for inclusion in this exercise (see Chapter 10). 4 Establish the total historical flow (throughput) for each DC location for each finished product by adding together the corresponding (originating) outbound flows from Step 2. 5 Establish the total historical variable cost for each DC location by multiplying the flows from Step 4 by the corresponding unit DC variable costs. 6 Establish the total historical fixed cost for each DC location by obtaining the corresponding fixed cost for each location that had a positive flow in Step 4. 7 Establish the total historical flow for each replenishment transportation link for each finished product by multiplying the DC location flows from Step 4 by the corresponding replenishment flow allocation percentages. 8 Establish the total historical transportation cost for each replenishment transportation link by multiplying the flows from Step 7 by the corresponding replenishment weighted average transportation costs selected for inclusion in this exercise (see Chapter 10). 9 Establish the total historical flow (production volume) for each plant for each finished product by adding together the corresponding (originating) replenishment flows from Step Establish the total historical variable cost for each plant location by multiplying the flows from Step 9 by the corresponding unit production costs.

23 SAILS OPTIMIZATION SOFTWARE Cost/Flow Baseline: OPTIMA Models Procedure The detailed procedure for establishing a historical cost/flow baseline for an OPTIMA model is as follows: Step Action 1 Establish the total historical demand for each customer region/customer class/product group combination by obtaining the required values from the outbound transaction file. 2 Establish the total historical flow for each outbound transportation link for each finished product by obtaining the required values from the outbound transaction file. 3 Establish the total historical transportation cost for each outbound transportation link by multiplying the flows from Step 2 by the corresponding outbound weighted average transportation costs selected for inclusion in this exercise (see Chapter 10). 4 Establish the total historical flow (throughput) that is a function of shipments to customers for each DC location for each finished product by adding together the corresponding (originating) outbound flows from Step 2. 5 Establish the total historical flow for each replenishment and DC transfer link (if any) for each finished product by multiplying the DC location flows from Step 4 by the corresponding replenishment and transfer flow allocation percentages. WARNING: This step is subject to infinite cycling if the DC transfer flow allocation percentages are not prepared with care. See the discussion in Section Establish the true total historical flow (throughput)for each DC location for each finished product by adding together the originating outbound flows from Step 4 and the originating DC transfer flows from Step 5. In other words, the total throughput of a given DC is the sum of all DC transfer and outbound shipments that originate at that DC (it is also equal to the sum of all replenishment and DC transfer shipments that terminate at the given DC). 7 Establish the total historical DC variable cost for each DC location by multiplying the flows from Step 6 by the corresponding unit DC variable costs. 8 Establish the total historical fixed cost for each DC location by obtaining the corresponding fixed cost for each location that had a positive flow in Step 6. 9 Establish the total historical transportation cost for each DC transfer transportation link by multiplying the flows from Step 5 by the corresponding DC transfer weighted average transportation costs selected for inclusion in this exercise (see Chapter 10). 10 Establish the total historical transportation cost for each replenishment transfer link by multiplying the flows from Step 5 by the corresponding replenishment weighted average transportation costs selected for inclusion in this exercise (see Chapter 10). continued on the next page

24 11-24 CHAPTER 11: COST/FLOW BASELINE 11.4 Cost/Flow Baseline: OPTIMA Models, continued Procedure, continued Step Action 11 Establish the total historical production volume for each plant for each finished product by adding together the corresponding (originating) replenishment flows from Step Establish the total historical production volume on each production line for each finished product for a given plant by multiplying the flows from Step 11 by the corresponding finished product production line allocation percentages. 13 Establish the total historical finished product production variable cost for each plant location by multiplying the flows from Step 12 by the corresponding unit production costs. 14 Establish the total historical fixed cost for each finished product production line by obtaining the corresponding fixed cost for each line that had a positive flow in Step Establish the total historical fixed cost for each plant location by obtaining the corresponding fixed cost for each location that had a positive flow in Step IF intermediate products... THEN... are being modeled, complete Steps 17 through 22. are not being modeled, skip to Step Establish the historical requirement for each intermediate product at each plant by applying the intermediate product/finished product conversion factors (recipes) to the finished product production volumes from Step 11 (bill of materials explosion). 18 Establish the total historical production volume for each plant for each intermediate product and the total historical flow for each interplant intermediate product transfer link by multiplying the intermediate product production requirements from Step 17 by the corresponding intermediate product flow allocation percentages. 19 Establish the total historical transportation cost for each interplant intermediate product transfer link by multiplying the transfer flows from Step 18 by the corresponding interplant intermediate product weighted average transportation costs selected for inclusion in this exercise (see Chapter 10). 20 Establish the total historical production volume on each production line for each intermediate product for a given plant by multiplying the production volumes from Step 18 by the corresponding intermediate product production line allocation percentages. 21 Establish the total historical intermediate product production variable cost for each plant location by multiplying the production volumes from Step 20 by the corresponding unit production costs. 22 Establish the total historical fixed cost for each intermediate product production line by obtaining the corresponding fixed cost for each line that had a positive flow in Step 20. continued on the next page

25 SAILS OPTIMIZATION SOFTWARE Cost/Flow Baseline: OPTIMA Models, continued Procedure, continued Step 23 Action IF raw materials... THEN... are being modeled, complete steps 24 through 28. are not being modeled, you are finished with the procedure. 24 Establish the total historical requirement for each raw material at each plant as follows: IF intermediate products... THEN... are being modeled, apply the raw material/intermediate product conversion factors (recipes) to the intermediate product production volumes from Step 18 (bill of materials explosion). are not being modeled, apply the raw material/finished product conversion factors (recipes) to the finished product production volumes from Step 11 (bill of materials explosion). 25 Establish the total historical flow for each inbound transportation link by multiplying the raw material requirements from Step 24 by the corresponding inbound flow allocation percentages. 26 Establish the total historical transportation cost for each inbound transportation link by multiplying the flows from Step 25 by the corresponding inbound weighted average transportation costs selected for inclusion in this exercise (see Chapter 10). 27 Establish the total historical procurement volume for each raw material by adding together the corresponding (originating) inbound flows from Step Establish the total historical variable procurement cost for each raw material supplier location by multiplying the volumes from Step 27 by the corresponding unit procurement costs.

26 11-26 CHAPTER 11: COST/FLOW BASELINE 11.5 Accounting and Model Baselines Overview At the beginning of this chapter, we listed two reasons for construct-ing a cost/flow baseline: 1 to establish model validity, and 2 to provide a basis for comparing the results of a given optimization scenario with the current system. Thus far, we have described a procedure that is primarily designed to support objective 1. In particular, we have placed considerable emphasis on establishing historically accurate commodity flow patterns. We call the result of this exercise an accounting baseline. The Accounting Baseline Unfortunately, a precise emulation of the present logistics network is not necessarily the best vehicle for use in baseline/optimization comparisons. We would prefer that both baseline and solver use the same data and adhere to identical assumptions. We previously established in Section , Baseline/Solver Consistency, that both modules access the same database. However, there is a crucial constraint mandatory in ODS and optional in OPTIMA that is potentially inconsistent with the historical flow replication emphasis in the accounting baseline. Recall from Chapter 10 (and see also Chapter 12) that the SAILS solvers can enforce customer sole sourcing by finished product bundle. By customer sole sourcing, we mean that the solver will find the least cost single origin DC assignment for each customer region/ customer class/product bundle. In particular, split sourcing of a given region/class bundle is not allowed. In most instances, this will generally be at odds with an accounting baseline, where at least some split sourcing can be expected due to stockouts, promotions, weather, strikes, and so on. In other words, we undoubtedly have a preferred DC location from which to service a given region/class/bundle, but realworld complications occasionally force us to ship from a secondary location. The SAILS solvers are unaware of these real-world events and establish a normative solution, which tells us from which DC location each region/class/bundle should be sourced.

27 SAILS OPTIMIZATION SOFTWARE Accounting and Model Baselines, continued The Model Baseline In light of the above information and in the interest of consistency, SAILS constructs a model baseline that is used for baseline/solver comparisons. The model baseline logic is identical to that used for the accounting baseline, except for one crucial feature. When establishing the outbound transportation link flows, SAILS assigns each customer region/customer class/product bundle to one DC location. By default, SAILS chooses the single DC location from which a given region/class/bundle obtained the most finished product flow during the base period. You may, however, override these automatic selections with DC location assignments of your own choosing. The resulting model baseline will likely differ from the accounting baseline everywhere in the network because the revised DC throughput levels must now be allocated, per standard SAILS procedure, all the way back to the top of the network. To what degree will the accounting and model baselines differ? The answer depends on the degree to which region/class/bundle combinations were split-sourced during the base period. The difference between the accounting and model baselines provides us with a rough measure of the logistics cost penalty associated with these so-called out-of-area customer shipments. When the Model Baseline is Used There is a subtle reason for using model baseline values when performing baseline/solver comparisons. If we use the accounting baseline numbers, we assume that the projected savings include the permanent elimination of out-of-area shipments, because their cost is included in the accounting baseline totals. However, this is unrealistic: the reasons for these exceptions such as weather, strikes, stockouts, and so on, will not be eliminated because of a logistics network redesign. No logistics system operates perfectly. Therefore, the model not accounting baseline is the appropriate basis of comparison. Since outof-area shipments are excluded in both the model baseline and the solver, the projected savings do not assume that they will be eliminated.

28 11-28 CHAPTER 11: COST/FLOW BASELINE 11.6 Output Reports and Files Overview SAILS generates a wealth of useful information from each solver exercise including the following: summary and detailed written reports a PC-based graphics package input file user-accessible, machine-readable solution files These items are explained briefly in this section and are discussed in detail in the SAILS User Guide and in selected appendices. Written Reports The written reports available from the baseline are summarized in Figure Summary reports are always printed, while detailed reports are available at your discretion. Reports irrelevant to a given model are automatically suppressed (for example, reports concerning raw materials when none are being modeled). Graphics Package Input File A special series of maps, cost pie charts, customer service histograms, and additional written reports are available in a PC-based graphical environment. The file required to drive this program is automati-cally generated each time the baseline module executes. Machine- Readable Solution Files Some SAILS users import the results of baseline exercises into custom data analysis programs, spreadsheets, and database managers. Both summary and detailed machine-readable data files are generated automatically for this purpose. Information ranges from simple volume and cost totals by model component element to individual link-by-link flows for each commodity.

29 SAILS OPTIMIZATION SOFTWARE Action Plan Data Requirements In order for the SAILS cost/flow baseline module to execute successfully, you must accomplish the following: 1 Prepare and process the outbound transaction file successfully. 2 Run SHIPCONS successfully if you are a SHIPCONS user. 3 Enter corresponding commodity conversion coefficients (recipes) if intermediate products are being modeled. 4 Enter corresponding commodity conversion coefficients (recipes), if raw materials are being modeled. 5 Supply all appropriate commodity flow allocation tables OR, if the equal allocation assumption is acceptable, enter the facility eligibility tables. No other elements of the SAILS master database are required, including transportation costs and facility costs. But do note that: Transportation flows for which there is no corresponding freight cost are honored, but the total cost is set to 0. Facility flows for which there is no corresponding variable cost are honored, but the total variable cost is set to 0. Frequency of Use Other than these requirements, the degree to which you complete the SAILS master database before running the baseline module is largely a matter of taste. Some SAILS users prepare a baseline at the earliest opportunity, even if it is incomplete, and continue to do so each time a section of the master database is added. Others wait until the entire database has been assembled. At, we encourage early preparation better to detect data problems early on rather than waiting until the last minute. Model Validation The traditional final step in model validation is to compare results from the SAILS cost/flow baseline with independent values obtained from various accounting records. SAILS facilitates this process by generating the reports and data files summarized earlier.

30 11-30 CHAPTER 11: COST/FLOW BASELINE 11.7 Action Plan, continued Model Validation, continued At what level of detail should you attempt to compare accounting data and model data? Some users never go beyond the bottom line, looking only at systemwide totals. Unless the accounting data is simply unavailable, you may find that this approach is deficient. If possible, examine flow and cost totals at least down to the facility location level, most likely suppliers, plants, and distribution centers, as applicable. Efforts to go beyond this level are generally not worth- while: comparison data by customer region is likely unavailable, and lane-bylane transportation cost comparisons are impossibly detailed. And what about a validation standard? Once again, this is a subjective judgment. suggests that the totals for each cost and flow category should certainly be within 10% of known historical values and preferably within 5%. A surprising number of SAILS users have produced baseline results within 1% of the target a truly remarkable achievement given the amount of aggregation and averaging that is necessarily a part of any strategic model. Keep in mind that validation becomes more difficult the more you pursue it; systemwide totals are relatively easy to certify, facility-by-facility comparisons are more challenging, and lane-by-lane analysis is likely an impossible standard. Beware of Independent Accounting Data Do not make the mistake of placing too much faith in the accuracy of the independent accounting data. More than one SAILS model validation effort has inadvertently revealed major shortcomings in the corresponding information systems, occasionally so severe that validation could not proceed for lack of reliable data. At a minimum, ask yourself the following questions: Are all of the product flows and costs represented in the independent accounting data also in your SAILS database? Have I chosen to exclude segments of my operations from the model? How reliable are the independent accounting data? Do they accurately portray the corresponding flow or cost categories?