Besides, throughout the application, next to a field you may see symbol
i
Moving your mouse over it will show you more info.To run a basic greenfield Center of Gravity analysis, all you need to enter are customers. Only reading section Customers will do.
Using the software - logical steps
If where to open (a) new warehouse(s)? is the main question, then use Calculate Center of Gravity locations.
Summary
- Step 1 is running a greenfield Center of Gravity analysis. You only need to enter demand.
- Step 2 is replicating the current situation, to get figures to compare scenario's against, such as average customer distance. You enter current warehouses and fix customer assignments.
- Step 3 is creating a realistic scenario that sits somewhere between the current situation and greenfield. Constraints of step 2 are partly relaxed, like "only some of the current warehouses remain as-is, but others may move to a Center of Gravity".
- Step 4 (optional) is adding suppliers to include supplier transport costs in the optimization.
- Step 5 is selecting a proper warehouse location for each Center of Gravity, once calculated.
1. Greenfield analysis100% optimization freedom
|
3. Realistic scenarioSome optimization freedom
|
2. Current situationZero optimization freedom
|
100% ←------ Optimization freedom ------→0% |
A first run
- Fill out table Customers under section Input tables.
- You can start with only the 4 obligatory fields filled: Customer_ID, Latitude, Longitude, Demand.
- All fields are explained in user manual section Customers.
- Select the number of Center of Gravity locations under section Calculate Center of Gravity locations
- Press Calculate to run the greenfield Center of Gravity analysis. That's it!
- Main output - including Center of Gravity locations - is found in section Output - Reports. All reports can easily be copied into Excel.
- Always validate your input data! For example, check the (demand) map. Does it show large unknown customers? Does it show gaps where you expected to see customers? In general, check outliers, such as an extremely small or extremely large demand quantity. If your input data is invalid, then outcomes of the Center of Gravity analysis are (potentially) invalid as well.
Assess service levels
- View the service level distance metrics under section Output - Service level distances showing percentage of demand and customers reached within a certain distance (estimated road distance between warehouse and customer). This indicates if more warehouses should be opened, or if some could be closed.
- View the service level distance chart under section Output - Service level distances showing percentage of demand and customers reached within a certain distance (estimated road distance between warehouse and customer). This indicates if more warehouses should be opened, or if some could be closed.
-
Check option "distance based customer coloring" under Map settings below map. Customers beyond acceptable lead time distance (set under Parameters & Constraints - subsection Service level) become black. Based on this map you may decide to add/relocate warehouses. Or accept that some customers will have a longer lead time - which is probably already the case in reality. A few far-away customers should not be driving your supply chain network design!
- Check option "Improve service level" under section Parameters & Constraints - subsection Service level and rerun. Service level will be improved at the expense of increased transport costs.
Run sensitivity analyses
- Go to section Parameters & constraints - subsection Sensitivity analysis.
- Check option "Randomize each demand quantity" and rerun. Each customer demand temporarily changes between −X% and +X%. See how it affects Center of Gravity locations.
- Check option "Display cost-increase-areas" and rerun. A grey area around each Center of Gravity appears. If the warehouse would be located at the dotted border, then its transport costs would increase X%.
Enter current warehouses
- To enter current warehouses:
- Fill input table Predefined warehouses with current warehouses.
- Set field Move_limit to 0, to fix the warehouse location.
- Check constraint "Predefined warehouses" under section Parameters & constraints - subsection Constraints to activate those predefined warehouses, and rerun.
Fix customer-warehouse assignments
- To assign customers to their current warehouse:
- Enter field Warehouse_ID in table Customers
- Check constraint "Fixed customer warehouse assignments" under section Parameters & constraints - subsection Constraints, and rerun.
- Displaying current warehouse-customer links may already reveil some room for improvement.
- Fixing current customer-warehouse assignments automatically means that current capacity limits will be respected, so there is no need to enter field Capacity in Predefined warehouses table, yet.
Gradually relax some constraints
- Investigate if current locations are optimal - given fixed customer assignments:
- Increase value of field Move_limit of (some) predefined warehouses, and rerun.
- Investigate if current customer assignments are optimal - given fixed warehouse locations:
- Empty field Warehouse_ID of (some) customers, and rerun
- Or uncheck constraint "Fixed customer-warehouse assignments" under section Parameters & constraints - subsection Constraints, and rerun.
- Investigate where to open a next new warehouse:
- Increase the number of Center of Gravity locations beyond the number of predefined warehouses, and rerun.
- Make sure you allow (some) customers to get (re)assigned to this new warehouse.
Activate other types of constraints
- Limit warehouse throughput capacities:
- Enter field Capacity in the Predefined warehouses table.
- Check constraint "Capacity limits" under section Parameters & constraints - subsection Constraints, and rerun.
- Keep in mind that current limits may not apply in future, if additional space can be rented or the owned facility expanded!
- Group customers for single sourcing:
To enforce all customers within a group to be assigned to the same, single warehouse:
- Enter field Group in table Customers.
- Activate constraint "Customer groups" under section Parameters & constraints - subsection Constraints, and rerun.
Intro
A Center of Gravity analysis focuses on the demand side with its relatively high transport costs and lead time requirements. But you can add suppliers (locations and supply quantities) to include supply transport costs in the Center of Gravity analysis. Adding suppliers becomes more relevant in a Center of Gravity analysis if there are a few dominant supply locations (such as a large plant or entry harbour), in which case a warehouse should move towards that location.Note that a supplier may pull all warehouses, whereas a customer only pulls one.
Suppliers
Enter suppliers - at least obligatory fields Supplier_ID, Latitude, Longitude, Supply - in input table Suppliers.Supplier transport rate
Supplier shipments are usually larger than customer shipments, on average. This makes supplier transport relatively cheaper. The lower transport rate makes suppliers pull Center of Gravity relatively less than customers do.Enter supplier and customer transport rate under section Parameters & Constraints - subsection Transport rates.
Supply flows
Check "Suppliers" under section Parameter & constraints - subsection Supply options.Select 1 of the 4 supply options in the same subsection. The selected option determines how supply flows are constructed.
Non-unique products
- Each supplier delivers to closest warehouse only
Used for a scenario in which local suppliers supply non-unique products to local warehouses.
Closest warehouse (auto-detected) can be overruled by specifying a predefined warehouse in the supplier table. - LP optimized supply flows - with auto-sized suppliers
Used for a scenario in which suppliers supply non-unique products to warehouses. This Linear Programming procedure creates supplier-warehouse flows that minimize supplier-warehouse transport costs, while adhering to available supply quantities (and fixed supplier-warehouse assignments**). You may give suppliers "infinite" supply, as this LP procedure makes supply match demand exactly. It auto-sizes suppliers.
** If fixed supplier-warehouse assignments make it impossible for supply to reach demand, then these assignments are (partly) ignored. A supplier will then also supply warehouses other than the one you assigned it to. This causes a cost penalty. The LP procedure avoids penalties, as long as possible. If a penalty was unavoidable, then you will get a message. Penalties are excluded from costs outcomes as reported.
Unique products
- Each supplier delivers to each warehouse → This is the default supply option.
Used for a scenario in which suppliers supply their unique products to each warehouse directly. The supplier volume to each warehouse is pro rata the customer demand assigned to each warehouse. - Each supplier delivers to each warehouse via closest warehouse
Used for a scenario in which suppliers supply their unique products to each warehouse - via the closest warehouse (2-echelon) - pro rata demand assigned.
Closest warehouse (auto-detected) can be overruled by specifying a predefined warehouse in the supplier table.
Notes
- If you have specified a fixed warehouse at a supplier (to 1) but also selected option 3 (to all), this causes a logical inconsistency. In that case - in background - option 3 is converted into option 4.
- You can specify the supply option at individual supplier level. It will overrule the generic setting. Thus you can create a mixture of options 1/3/4.
Under options 2/3/4 each supplier - unlike a customer - pulls several/all warehouses.
Demand side onlyWarehouses are pulled by customers only |
Supply option 3All warehouses are pulled towards a major supplier. |
Supply option 4All warehouses - but especially the closest warehouse - are pulled towards a major supplier. |
Activating supply will make the Center of Gravity analysis more complex, and the supply chain picture as well.
Select a proper location for each Center of Gravity
Once the Center of Gravity locations have been calculated (based on road distance estimations), select a proper warehouse location for each Center of Gravity (that may have ended up on top of a mountain or in the middle of a lake).
Under Map Settings, select ESRI map and decrease Center of Gravity size factor or opacity to see the road network.
Consider locations within the 1%-costs-increase-range around the Center of Gravity - the visual outcome of the sensitivity analysis as described under step 1.
If the Center of Gravity sits on top of a dominant customer or supplier, then search for a highway/expressway junction close by. In this case, the 1%-costs-increase-range will be relatively small.
Else, search for a location where two expressways cross each other. At such crossing, transport in any direction will not cause a detour. Whereas if a location is only near an east-west expressway, then transport to the north or south means a detour to reach the north-south expressway. Moving the location to the crossing will remove that detour for 3 directions, but add it to 1 direction (east). If demand is almost equally divided across all 4 directions - which is usually true for a Center of Gravity - then this move lowers the sum of weighted road distances.
Under Map Settings, select ESRI map and decrease Center of Gravity size factor or opacity to see the road network.
Consider locations within the 1%-costs-increase-range around the Center of Gravity - the visual outcome of the sensitivity analysis as described under step 1.
If the Center of Gravity sits on top of a dominant customer or supplier, then search for a highway/expressway junction close by. In this case, the 1%-costs-increase-range will be relatively small.
Else, search for a location where two expressways cross each other. At such crossing, transport in any direction will not cause a detour. Whereas if a location is only near an east-west expressway, then transport to the north or south means a detour to reach the north-south expressway. Moving the location to the crossing will remove that detour for 3 directions, but add it to 1 direction (east). If demand is almost equally divided across all 4 directions - which is usually true for a Center of Gravity - then this move lowers the sum of weighted road distances.
Even better would be to score locations using transport tariffs. But - most likely - you will not have all tariffs. You can obtain those by organizing an RFQ/RFP process - asking logistics service providers to quote for the transport operation (and warehousing operation, covering other/qualitative factors as well). Of course, there may be no warehouse space for rent/sale at your intended location.
If which warehouse(s) to open and which to close? is the main question, then use Select best warehouses.
Mandatory
- Enter your data in the input tables. Predefined warehouses is no longer optional input, but mandatory.
- Under section Select best warehouses: Press button "Read input data". Specify the number of warehouse to be selected (per group) and make your solver selection from 3×3 matrix. Press button "Select best warehouses".
Optional
- Enter warehouse capacity limits. Keep in mind that current limits may not apply in future, if additional space can be rented or the owned facility expanded!
- Enter fixed customer-warehouse assignments, if some customers definitely need to be delivered from a specific warehouse.
- You may override the transport costs input as calculated by the software with your own transport costs based on your own costing method / on actual rate tables / on actual road distances that can be retrieved using Batch Driving Distances Calculator (Google Maps based).
Transport rates for new warehouses may be unknown. Or transport rates from a current warehouse to customers that are currently delivered from another warehouse may be unknown. Unknown rates is often a cumbersome part in supply chain network design, and reason to use a simpler costing method that is - more or less - similar to the one embedded in this software. - Enter warehouse fixed/variable costs, so these can be taken into account as well in the optimization.
How to activate constraints
Constraint | Supported | How to activate |
---|---|---|
Predefined warehouses | yes | Always active (regardles constraint setting). |
Fixed customer-warehouse links | yes | By checking constraint in Parameters & Constraints - subsection Constraints |
Capacity limits | yes | By using Greedy solver or LP solver (not by checking constraint). |
Customer groups | no | |
Suppliers | yes | By checking constraint in Parameters & Constraints - subsection Constraints. Supply option 3 is activated in background. Other options not supported. |
Border crossing points | yes | By checking constraint in Parameters & Constraints - subsection Constraints. |
User input
Customers
- Customer_ID is a free format identifier.
- Latitude and Longitude are both decimal numbers and the result of converting a textual ship-to address (not sold-to adress) into geographic coordinates - a process called geocoding. You can use:
- Batch Geocoder - Free
- Batch Geocoder - Paid
- Excel interfaces with Google Maps / TomTom / BING geocoding api
- or any other geocoder
- Double check postal codes on missing leading zeroes. If - for example - you notice German or French postal codes with only 4 digits instead of 5, then a leading zero might be missing. This issue is quickly caused in/by Excel if you have not set your postal code column to type "text". Incorrect postal codes may cause geocoding problems. And if you would aggregate customer demand at 2-digit postal code level (often seen in European supply chain models), you will end up with demand at the wrong location! For example, demand of postal code 05700 - incorrectly 5700 - will end up on 57 instead of 05.
- Put aggregated demand of far-away-customers delivered by sea/air (on a country's overseas island, for example) on exit harbour/airport (latitude/longitude), to ensure that Center of Gravity locations are pulled in the right direction, and to avoid that one of the Center of Gravity locations ends up in such remote customer area. Or simply remove such customers completely from the model, if their aggregated demand is marginal.
- Demand is the total yearly future demand of a customer, ideally expressed in your transport cost driver: volume or (volumetric) weight.
- Collect a full year of demand data if your business is highly seasonal. Otherwise, one month × 12, or one quarter × 4, may do.
- Design for the future: include demand growth percentages (only/especially if it is not just a single overall percentage).
- If available, then use shipment data with volumes or weights Otherwise, demand can be calculated based on sales order quantities × item dimensions. But beware: item masters are often not 100% clean, which may cause large calculation errors. In both cases, check for shipments that exceed truck capacity or are extremely small.
- If a sales budget would be the only info available (new market entry), then use demographics to create a geographical demand proxy.
- Though not obligatory, it is advised to enter demand figures as whole numbers (easier to read).
- Try to keep your model small. If you have 5,000‑20,000 customers, then - most likely - this amount can be greatly reduced by aggregation, while keeping the model valid. Customer aggregation will make your model run (much) faster and prevent performance issues. Of course, you may first try to run without aggregating.
-
You may simply round each customer latitude and longitude to two decimals, then aggregate demand per rounded latitude, rounded longitude. By rounding a customer may shift 0.78 km (0.5 mile) from its original position, at most. This 0.78 km is the as-the-crow-flies distance between (latitude, longitude) point (0.000, 0.000) and (0.005, 0.005). The further away from the Equator, the smaller this maximum shift becomes. At a 'European' latitude of 44.000 it become 0.68 km, at most. On average, a customer will shift approx. 0.37 km - which is unnoticeable on the map. Moreover, all customer shifts together will counterbalance each other to a large extent, so Center of Gravity locations will shift like 0.0-0.1 km only, which is completely negligible.
The exercise becomes more precise if using weighted average latitude and longitude within each aggregation category as customer coordinate (instead of rounded coordinates as such).
You could also - for example - round to nearest 0.025 instead of 0.01. Of course, the higher this number, the less accurate the aggregation becomes.
Below input table Customers you will see button "Aggregate" - It does exactly the above.
-
Or you may aggregate demand per 2-digit postal code, per country if creating a supply chain model for total Europe. Each country becomes 100 customers, at most. For example, customer DE-13 stands for all German customers with postal code 13XXX (ISO Alpha-2 country code for Germany is DE). (Side note: transport rate tables often use aggregated postal code zones, so are only accurate to that level as well.)
Add 2-digit postal code to each customer. Create a pivot table to sum demand per 2-digit postal code. Use geocodes of largest customer with that 2-digit postal code to locate aggregated demand (no need to geocode all customers). Or use geocodes from (use file at your own risk).
If your case is about a single country, then aggregating at 3-digit postal code level may be more appropriate. This will result in a model with 1000 customers, at most.
-
Or you may (if the above would not have helped enough to reduce the amount of customers)
- Remove UK customers from your European dataset, if you know upfront that UK will have its own warehouse(s), and run your Center of Gravity analysis for UK and mainland Europe separately.
- Split your data into 20% top customers - 80% tail customers (Pareto), and aggregate tail customers only.
- Use a higher level of aggregation for (the hinterland of) areas that have fixed warehouses.
- ...
-
You may simply round each customer latitude and longitude to two decimals, then aggregate demand per rounded latitude, rounded longitude. By rounding a customer may shift 0.78 km (0.5 mile) from its original position, at most. This 0.78 km is the as-the-crow-flies distance between (latitude, longitude) point (0.000, 0.000) and (0.005, 0.005). The further away from the Equator, the smaller this maximum shift becomes. At a 'European' latitude of 44.000 it become 0.68 km, at most. On average, a customer will shift approx. 0.37 km - which is unnoticeable on the map. Moreover, all customer shifts together will counterbalance each other to a large extent, so Center of Gravity locations will shift like 0.0-0.1 km only, which is completely negligible.
- Always validate your data! Check top-X customers list. Are major customers missing? Or do unknown customers appear? Check the demand map. Are gaps seen? Or do large unknown locations appear?
- Default customer opacity is 0.9 (see map settings under the map), to make customers sitting behind each other still visible. You may also sort your customers from large to small, by clicking on field header Demand, so small customers are plotted on top of large ones (not behind). But still. Customers with the same latitude/longitude are plotted on top of each other. Only a relatively small dot will be seen on the map, that does not properly reflect total demand on that location. By aggregating demand, you may get a more insightful demand map.
- Once you have entered all obligatory customer fields you can select the number of Center of Gravity locations under section Calculate Center of Gravity locations, and press button Calculate to run a basic greenfield Center of Gravity analysis.
Optional fields
- Warehouse_IDs is used to assign a customer to a predefined warehouse, so it should match to a Warehouse_ID as defined in table Predefined warehouses. If left empty, then no fixed assignment applies.
- Create a fixed assignment by entering a single warehouse_ID.
- Create a semi-fixed assignment by entering a subset of warehouses_IDs that the solver is allowed to select from.
Use / as separator between the warehouse_IDs. For example, Birmingham/Madrid/WH05.
Check constraint "Fixed customer-warehouse assignments"to activate, via section Parameters & constraints - subsection Constraints - Group - free format - is used to force all customers within the same group to be delivered by the same single warehouse only (single-sourcing). What group stands for, is for you to decide. For example, a country. The group is assigned to the warehouse that comes with the lowest sum of weighted distances for this group of customers. Underlying cost calculation is still done at individual customer level. For more info, read user manual section Center of Gravity algorithms - subsection Customer grouping.
A fixed customer-warehouse assignment takes precedence over a customer group. Warehouse capacity limits may cause a customer group to get broken up.Check constraint "Customer groups"to activate, via section Parameters & constraints - subsection Constraints. - Shipment_size translates into an individual customer transport rate. If specified, then it overrules the general customer shipment size. See user mnual section Transport rates for more explanation. Make sure it does not exceed truck capacity.
- Lead_time_distance is the individual maximum allowed distance from the warehouse. If specified, then it overrules the general lead time distance as set under section Parameters & constraints - subsection Service level. Customers are colored in black if the leadtime distance is exceeded, indicating where service is compromised. Enter the distance in the correct distance unit, miles or kilometers, as you have selected under section Parameters & constraints - subsection Distance.
- Border_group links the customer to a border group. A border group has specific border crossing points to enter or exit the bordered area. Those border crossing points are defined in table Border Crossing Points. A flow from a warehouse to a customer will go via one of the border crossing points, unless the warehouse and customer are both inside the bordered area. Check constraint "Border crossing points"to activate, via section Parameters & constraints - subsection Constraints.
Optional fields for "Select best warehouses" functionality only
- Qty_1 to 5 are the warehouse cost driver quantities of a customer, such as #orders, #order lines, #unit_picks, #carton_picks, #pallet_picks. You may decide yourself what each qty stands for.
Predefined warehouses (optional)
- Check constraint "Predefined warehouses"to activate and include predefined warehouses in the solution, via section Parameters & constraints - subsection Constraints.
- Warehouse_ID - free format, for example "Birmingham" - is used in the Customers and Suppliers table to assign customers or suppliers to this warehouse (instead of having the software assign customers and suppliers).
- Latitude, Longitude is the result of converting a textual address into geographic coordinates - a process called geocoding. For more info, read the help text for fields Latitude, Longitude of Customers.
Optional fields
- Move_limit = 0 (default) means a fixed location, > 0 means a location that may move away from its initial coordinates but no further than its move limit. To be expressed in either miles or kilometers, as you have selected under section Parameters & constraints - subsection Distance.
- Capacity is used to limit the demand that can be assigned to a warehouse. It is total throughput capacity (in relation to demand data period), not storage capacity. Yearly througput capacity = storage capacity × yearly stock turns. If your demand data is about one quarter, then divide yearly throughput capacity by four, or else multiply all demand (and supply) by four.
Warehouse capacity limits may cause customer groups to 'break'.Check constraint "Capacity limits"to activate, via section Parameters & constraints - subsection Constraints. - Transport_rate_index is used to adjust customer transport rates of all customers supplied from this warehouse. An index below 100 means transport from this warehouse to customers is relatively cheaper, an index larger than 100 means more expensive. Customer transport rates are multiplied by the warehouse Transport rate index/100, for all customers assigned to the warehouse. The lower this index, the more customers a warehouse will get assigned (unless other constraints prevent this).
- IsSatellite = 0 (no) or 1 (yes) and is used to distinguish main warehouses from satellite warehouses. This is relevant if suppliers are activated and parameter "Link supplier to closest Main warehouse" is checked. Even if suppliers have not been activated, main→satellite warehouse flows are generated.
- Color overwrites the default warehouse color. Format: #rrggbb (red,green,blue hexidecimal values)
Pick color → Color =
Optional fields for "Select best warehouses" functionality only
- Whs_group (opt)
- Valid entries are 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', or 'j'. If left empty, default 'a' is used.
- Group 'j' is a special 'must-be-included' group. All warehouses in group 'j' will always be included in the selection (which of course may affect the selection of warehouses from other groups).
- Group can be interpreted as geographical region. By grouping warehouses per region you can ensure that each region gets a warehouse, if you set the number to be selected from that group higher than 0.
- Fixed_costs are in fact binary-fixed costs, the fixed costs apply if a warehouse is selected.
- Rate_1 to 5 are the warehousing cost per unit throughput for up to 5 cost drivers (and linked to your customer table). Example: if customer X has Qty_1 = 10 and Qty_2 = 5, and warehouse Y has Rate_1 = 2.50, and Rate_2 = 3.75, then the variable costs of this customer X at warehouse Y are 10×2.50 + 5×3.75.
Suppliers (optional)
- Check constraint "Suppliers"to activate and include suppliers, via section Parameters & constraints - subsection Constraints.
- Supplier_ID: free format identifier.
- Latitude, Longitude is the result of converting a textual address into geographic coordinates - a process called geocoding. For more info, read the help text for fields Latitude, Longitude of Customers.
- Supply is the total yearly future supply of a supplier. Usually, the supply of all suppliers should - more or less - match the demand of all customers. Unless supply is about the dry ingredients of liquid finished products, for example.
Optional fields
- Warehouse_IDs (= link to table Predefined warehouses) is used to assign a supplier to a warehouse or subset of warehouses (similar to assigning a customer to a warehouse or subset of warehouses). If left empty, the software decides which Center of Gravity location(s) is/are supplied by the supplier. If specified, then this supplier will not supply all warehouses directly, even if supply option "Each supplier delivers to each warehouse directly" has been selected. Check constraint "Fixed customer-warehouse assignments"to activate, via section Parameters & constraints - subsection Constraints.
- Shipment_size translates into an individual supplier transport rate.
- Supply_option (1, 3, or 4) can be set to overrule the general supply option (1, 3, or 4) as selected under section Parameters & constraints - subsection Supply options. If you select overall option 2 "LP optimized supply flows", then individual supplier settings are ignored.
More info about suppliers, supplier transport rates and supply options is found in user manual section Logical steps - subsection Step 4. Add suppliers (optional)
Border crossing points (optional)
- Check constraint "Border crossing points"to activate, via section Parameters & constraints - subsection Constraints.
- The use of border crossing points may improve distance accuracy and direction in which a Center of Gravity is pulled.
- If an area can only be entered/exited at some specific points, you may enter these border crossing points.
- A transport flow has to go via a border crossing point if
- a warehouse is outside the bordered area and the customer inside ("entry")
- a warehouse is inside the bordered area and the customer outside ("exit")
- A flow via a border crossing point means a detour. The border crossing point causing the smallest detour is auto-detected. It also means that the warehouse is pulled towards this point instead of the customer, until the border has been crossed.
- Border_group - free format - is the name of the bordered area with all its crossing points (latitude, longitude) entered in this table. Field border_group is also found in the customers table and used to specify which customers belong to the border group (thus defining its geographic shape). To function properly at least some customers of a bordered area should be located within a 50 km range of the border point.
- In the picture on the right the border crossing points in the northern part of Italy prevent extreme shortcuts across the Adriatic Sea. If ferries are a valid transport option, then you may remove all border crossing points or add ferry harbours as points.
- Current implementation handles only one border crossing point per flow, not multiple. A warehouse area exit point takes priority over a customer area entry point: "exit before entry".
Intro
By (un)checking constraints (optional)in section Parameters & constraints - subsection Constraints you (de)activate parts of your input data. This way you can quickly investigate the impact of a constraint on goal value and supply chain network structure.The following explains the links between constraints and input tables/fields. Similar info is found in previous help sections about user input tables. But this section is more focused to constraints only. It also describes demo data, so you can check how a constraint has been set up.
Customers table
- Check constraint "Fixed customer-warehouse assignments" to assign customers to a predefined warehouse (or subset of predefined warehouses).
Demo: field Warehouse_IDs is set to "Birmingham" for all customers in UK/Ireland to assign them to the predefined Birmingham warehouse. It is set to "Madrid" for all customers in Spain/Portugal. - Check constraint "Customer groups" to have all customers within the same group delivered by the same single warehouse that can deliver the group against lowest transport costs. These costs are still calculated at individual customer level, see example in user mnual section Center of Gravity algorithms - subsection Customer grouping.
Demo: field Group is filled with the applicable 2-letter ISO country code for all customers. So - in the demo - group stands for country. This prevents customers in Western France to get delivered by the UK warehouse. - Check constraint "Border crossing points" to activate border crossing points.
Demo: field Border_group is filled for customers in UK, IE, Italy, and Iberia.
Predefined warehouses table (optional)
- Check constraint "Predefined warehouses" to include predefined warehouses in the solution.
Demo: contains one predefined warehouse in Birmingham (UK) and one in Madrid (Spain), with field Move limit set to 0 for the Birmingham warehouse (it cannot move), and set to 200 for the Madrid warehouse (it can move within a 200 km range). Demo also contains several other main and satellite warehouses that can move freely around. - Check constraint "Capacity limits" to limit warehouse throughput capacities.
Demo: field Capacity is set for both predefined warehouses Birmingham and Madrid.
Suppliers table (optional)
- Check "Suppliers" to include suppliers.
Demo: contains one supplier in Rotterdam (The Netherlands - Entry harbour supplying 71% total demand), and one in Bologna (Italy). - Flows from suppliers via warehouses to customers are constructed automatically, dependent on the selected Supply option as set in section Parameters & constraints - subsection Supply options.
- Check constraint "Fixed customer-warehouse assignments" to assign suppliers to a predefined warehouse. It links to field Warehouse_ID. If filled, then the supplier will only supply this warehouse. And via this warehouse to each other warehouse, if supply option "Each supplier delivers to each warehouse via closest warehouse" is selected. (If field Warehouse_ID is filled, then a supplier will never supply all warehouses directly, even if supply option "Each supplier delivers to each warehouse directly" has been selected.)
Border crossing points table (optional)
- Check constraint "Border crossing points" to activate border crossing points.
Demo: field Border_group relates to the same field found in the customer table and specifies which border crossing points (if any) are applicable for which customers. The demo contains a limited amount of border crossing points in Italy, Iberia, UK/Ireland, just to show you how this concept works.
Intro
In section Parameters & Constraints - subsection Transport rates you set transport rates to differentiate between customer and supplier transport. You may also adjust the cost curve that expresses how much - relatively - more expensive smaller shipments (LTL-like transport) are compared to larger shipments (FTL-like transport).Transport costs curve
Smaller shipments being relatively more expensive than larger shipments is expressed in the transport cost curve. The default cost curve shows that a shipment size of 50% FTL brings 72.4% FTL costs, meaning that - per each unit transported - it is 1.45 times more expensive than FTL transport. You can adjust the curve by dragging control point handles or entering control point values in the cost curve settings below the chart.Small customer shipments versus large supplier shipments
Smaller shipments to customers are relatively more expensive than larger shipments from suppliers. Average customer and supplier shipment sizes - as set in the transport rates table - are translated into rates by applying the cost curve.Small customers shipments versus large customers shipments
Similarly, shipments to small customers are relatively more expensive than shipments to large customers. To differentiate you can enter individual shipment sizes at individual customer (and also at individual supplier level). The impact of individual shipment size on Center of Gravity locations may be small, if smaller and larger customers are scattered all around.Ratio between customer and supplier rate
To minimize transport costs a Center of Gravity should move closer towards a customer than towards a supplier, if their total transport volumes would be equal (regardless distance!). The ratio between supplier rate and customer rate is more important than rates as such. This ratio affects the Center of Gravity position, as shown in the animation below of a simplified example. For more info see also user manual section Center of Gravity algorithms - subsection Including supply-side.- Above chart (showing solver outcomes) has been verified by geometry that brings a formula for the Center of Gravity x‑position.
X‑position = max(0, 100 + 50 × F / √(1 - F2) ), with F = (1 - 3 × ratio)/2. F stands for pull force in horizontal direction - of both customer C1 and C3 - required to reach an equilibrium state. - Easy to see: X-position becomes exactly 100 at ratio 1/3, as supply quantity (= 3) × 1/3 equals C2 quantity (= 1).
- For a ratio ≥0.93 the supplier pull force outweighs customer pull forces, so the Center of Gravity ends up on top of the supplier. This 0.93 is in fact (1+2×1/√(12+0.52))/3 = (1+4/√5)/3 = 0.9296...
Transport-rated volumes on the map
Under map settings you can choose to display location sizes as transport-rated volumes (volume × rate ratio), instead of plain volumes (default setting). Suppliers will then appear relatively smaller than customers, which better reflects the Center of Gravity 'pull forces' of suppliers and customers.Two options to model warehouse → warehouse flows
A default model looks like: (suppliers →) warehouses → customersBut you can also model: (suppliers →) warehouses → warehouses → customers
In general, try to keep your model simple.
There are two options to model warehouse → warehouse flows.
- In a model with suppliers:
Select supply option "Each supplier delivers to each warehouse via closest warehouse".
Closest warehouse can be overruled by specifying a predefined warehouse in field Warehouse_IDs of the supplier table. Supply quantities (that are related to demand quantities) determine warehouse-warehouse flow quantities. - In a model without suppliers:
Set up predefined warehouses, some as main warehouse (field IsSatellite=0), some as satellite (IsSatellite=1).
Each satellite gets supplied by its closest warehouse. Satellite demand quantities determine warehouse-warehouse flow quantities.
Example 1: model with suppliers
Suppliers
(linked to plant)
→ (linked to plant)
Plant
(main warehouse)
→ (main warehouse)
Distribution centers
(main warehouses)
→ (main warehouses)
Customers
(linked to DCs)
(linked to DCs)
In above model plant and distribution center locations are optimized simultaneously. But if the plant is fixed, then there is no possibility to optimize suppliers → plant flows, so you might as well replace suppliers and plant by a single fake supplier at the plant location. You will then no longer have a model depicting the full supply chain network, but such picture can be made with MapMaker.
Example 2: model without suppliers
Warehouses (main warehouses) | ↗ Online customers (linked to warehouses) |
↘ Stores → (satellites) In-store customers (linked to stores) |
Imagine a company planning to enter a new geographical market. As you will not have actual sales data, you may construct customers based on demographics (population per city/village), an assumption about sales per capita and split between online and in-store sales. In above model, store and warehouse locations are optimized simultaneously (each store will move a bit towards its warehouse).
Note: a two-echelon warehouses → warehouses structure is not supported by the "Select best warehouses" routine.
Calculate Center of Gravity locations
Center of Gravity analysis - goal value
Goal value to be minimized is the sum of weighted distances. In a basic approach distances are weighted by quantities only. Centers-of-Gravity Calculator uses two weights. Distances are weighted by transport quantity (1st weight) × transport rate (2nd weight). The transport rate converts distances and quantities into costs. Primary reason for adding transport rate as a second weight is to make suppliers (larger shipments, FTL-like transport) pull Center of Gravity locations relatively less than customers (smaller shipments, LTL-like transport) do, rather than to come up with highly accurate transport costs.The percentual change in goal value of future scenario compared to baseline can be applied to your actual baseline costs (derived from your financial reports) to estimate the transport costs effect of the future scenario. Because transport costs partly consist of (un)loading costs that will not change, you may add some factor to dampen the costs effect.
Baseline | Future scenario | |
---|---|---|
Baseline transport costs from your financials | USD 12,000,000 | |
Goal value Centers-of-Gravity Calculator | 10,000,000 | 9,000,000 |
Goal value change (as %) | -10% | |
Dampening factor (value assumed at 0.80) | 0.80 | |
Goal value change × dampening factor | -8% | |
Transport costs effect | - USD 960,000 | |
Future scenario costs | USD 11,040,000 |
For more info about transport rate differentiation between customers and suppliers, see user mnual section Transport rates.
By the way, a supplier pulls one/several/all warehouses (dependent on selected supply option), whereas a customer pulls only one warehouse, so a difference in transport rate is not the only difference between a customer and supplier.
In case of an owned truck operation, see section Parameters & Constraints - subsection Own truck operation. It supports the estimation of transport mileage. That mileage can be used to estimate transport costs effects more precisely.
Center of Gravity analysis - algorithms - How to calculate Center of Gravity locations
This section explains in detail how Centers-of-Gravity Calculator calculates Center of Gravity locations. Several (interactive) animations visualize what happens during a run of an algorithm.Center of Gravity locations are indicative warehouse locations that minimize transportion costs. In fact, Center of Gravity locations are those locations that minimize the sum of weighted distances, given the amount of warehouses. Weighted distance is the distance from warehouse to customer multiplied by customer demand. If a customer has a demand of 10 and is located 25 kilometers from its warehouse, then its weighted distance is 250 kilometers. This sum of weighted distances of all customers acts as an indicator for transport costs.
Single Center of Gravity algorithm - Introductory thoughts
Upfront: there exists no mathematical formula that can calculate the Center of Gravity.Imagine a case with two customers only. Customer A has a demand of 10 and customer B of 1. Where is the Center of Gravity? Somewhere on line A-B, closer to A?
Well, you could say that customer A pulls 10 times harder than customer B. If the 'Center of Gravity' * moves a distance d towards A the sum of weighted distances decreases (10 × d) – (1 × d) = 9 × d.
* If put between quotes then it refers to a location under investigation which is not yet the true Center of Gravity.
So, the Center of Gravity is right on top of customer A, not somewhere in between A and B!
The resultant pull force - sum of all customer pull forces - is leading. It always points in the direction that the 'Center of Gravity' should move into to decrease the sum of weighted distances. This resultant pull force is constructed by linking all customer pull forces together, head to tail.
However, the sum of weighted distances will only decrease if the 'Center of Gravity' moves the right distance! The resultant pull force does not tell how far to move. Move this far?
Or this far?
The smaller the move distance, the less chance of 'overshooting' the Center of Gravity, but the many more moves to be made. Therefore, it is better start with big moves. In case of 'extreme overshooting' the sum of weighted distances will have increased instead of decreased, and the resultant force arrow changed - or even completely reversed - its direction. By then, the move size needs to be reduced in order to get closer to the Center of Gravity. Else, the next move would end up at the previous position, followed by getting stuck in a loop of going back-and-forth without ever getting any closer. By reducing the move size each time the sum of weighted distances increased the 'Center of Gravity' ends up on top of the Center of Gravity.
Of course, the above was an extreme example. Usually, there is no single dominant customer, and the Center of Gravity will be somewhere in the center of all customers. Also then, the Center of Gravity is found by moving in the direction of the resultant pull force, but not too far. The resultant pull force becomes smaller the closer the location gets to the Center of Gravity (which implicates that the length of the resultant pull force somehow does relate to the distance to be moved). It becomes zero on top of the Center of Gravity, with all underlying pull forces (F) in a state of equilibrium in both x and y direction: ΣFx=0, ΣFy=0. All forces linked together start and finish at exactly the same location = zero resultant force.
Except if one dominant customer outweighs all other customers. Then the Center of Gravity is on top of this dominant customer, but the resultant force is not zero.
Another exceptional case, rather theoretical, is one in which there are only two customers, A and B, with equal demand. Then the resultant force is zero for all points between A and B on line A-B. Each of these points is Center of Gravity.
Calculating the Center of Gravity is not so much about distances as such, as it is about pull forces and directions. If in the above example customer 2 would be located 10 times further away in the same direction, this would not affect the Center of Gravity at all.
Single Center of Gravity location algorithm
There exists no mathematical formula that can calculate the Center of Gravity. It takes an iterative approach.The Single Center of Gravity algorithm works like this on an x,y plane:
- Initialization: locate the 'Center of Gravity' at an initial (random) position, and give the move distance a large value.
- Calculate the resultant pull force. Move the 'Center of Gravity' in that direction, at move distance.
- Calculate the sum of weighted distances. If it increased, then divide the move distance by two.
- Repeat steps 2 and 3 until the move distance becomes very small.
Determining the Center of Gravity is like finding the x and y coordinate of the lowest point (x,y,z) in a bowl-shaped 3D‑chart - visualizing the sum of weighted distances z = f(x,y) for each x and y - by going into the direction of steepest descent as pointed to by the resultant pull force. During this descent the direction gets adjusted after each move made/step taken.
There are methods to determine a proper move distance (a.k.a. step size) per iteration. But these are rather complex and (thus) time-consuming. Luckily, there is no urgent need for those, because the method of step 3 works and is fast.
Single Center of Gravity algorithm - Summary
- Initialization: locate the 'Center of Gravity' at an initial (random) position, and give the move distance a large value.
- Calculate the resultant pull force. Move the 'Center of Gravity' in that direction, at move distance.
- Calculate the sum of weighted distances. If it increased, then divide the move distance by two.
- Repeat steps 2 and 3 until the move distance becomes very small.
Single Center of Gravity algorithm - Steps more detailed
- Initialization: locate the 'Center of Gravity' at an initial (random) position, and give the move distance a large value.
- A good initial position is the weighted average x and y coordinates of its customers. It is often near-optimal, but not the Center of Gravity, though you may have read elsewhere it is. Theoretically, it can be even 100% worse!
Often only 0-5% worse...
Often, the sum of weighted distances of the weighted average x,y position versus that of the true Center of Gravity will be 0-5% worse, but more than 5% worse is also possible, as sometimes will happen/can be seen in the simulation further below.
...but theoretically even 100% worse is possible!
Imagine a case with only two customers, customer A with demand 1000 at x,y position (0, 0) and B with demand 1 at position (100, 0). The weighted average x,y position is (0.0999, 0), with 0.0999 calculated as (1000×0 + 1×100)/(1000+1). If the 'Center of Gravity' moves a distance d towards customer A the goal value improves 1000×d (closer to A) − 1×d (further from B) = 999×d. So the Center of Gravity is on top of customer A, not at the initial weighted average x,y position! The Center of Gravity has a sum of weighted distances of 1000×0 (customer A) + 1×100 (customer B) = 100, whereas the initial position has a value of 1000×0.0999 (customer A) + 1×99.9 (customer B) = 199.8, which is 99.8% worse!
- A random location within the customer cloud can be used just as well, as the remainder of the algorithm will always find the Center of Gravity, in almost equal time.
- It is better to start with a bit too large move distance (100 kilometers) than with a bit too small, because if too small then it will take many iterations before the Center of Gravity is reached.
- A good initial position is the weighted average x and y coordinates of its customers. It is often near-optimal, but not the Center of Gravity, though you may have read elsewhere it is. Theoretically, it can be even 100% worse!
- Calculate the resultant pull force. Move the 'Center of Gravity' in that direction, at move distance.
- Sum up all pull forces (vectors) to get the resultant pull force (vector) with a certain size (less relevant) and direction (most relevant) by summing up x and y components separately. For each customer pull force F: Fx = length demand vector × (customer_x − CoG_x)/(distance from customer to CoG), or shorter: Fx = demand × cosinus(angle F). Fy = demand × sinus(angle F).
- Normalize this resultant pull force (a vector with origin at 0,0 and end point at x,y) by dividing x by its length √(x2 + y2) and y by its length. The vector keeps pointing in the same direction, but its length becomes 1, which makes it a unit vector.
- Multiply x and y values of this unit vector with the step size to get the move vector representing move distance in x and y direction.
- If the move vector's tail starts at the current 'Center of Gravity' position, then its head ends at the next 'Center of Gravity' position. So, add the move distance in x direction to the current x position of the 'Center of Gravity', and add distance in y direction to its current y position. This brings the next 'Center of Gravity' position.
- Calculate the sum of weighted distances. If it increased, then divide the move distance by two.
- This approach originates from the binary search algorithm - a.k.a. half interval search - to find the position of a target value within a sorted array. See half-interval search (wikipedia).
- Optional: move the 'Center of Gravity' back to its previous position if the sum increased, so with each 'accepted move' the solution always improves (or remains equal, but never worsens).
- Repeat steps 2 and 3 until the move distance becomes very small.
- Then the Center of Gravity hardly changes anymore, and the sum of weighted distances converges.
- The Center of Gravity may be in the middle of a lake or on top of a mountain.
Single Center of Gravity algorithm - Visual simulation
Press button Next process step to start the simulation.Earth is a globe - Required adjustments translating Cartesian into Spherical coordinate system
X,y on a flat plane (Cartesian coordinate system) becomes latitude,longitude on a globe (Spherical coordinate system). The algorithm involves summing up vectors with a length and an angle. The distance between two points on a globe is calculated with the Haversine formula, and the angle with a Bearing formula. Demand vectors are mapped to a flat tangent space before summing up, and the result is translated back to the globe - see also the picture of section 'Weiszfeld's algorithm as alternative'. |
"No, it's not
a flat plane." |
|
Latitudes and longitudes in both formulas need to be expressed in radians = degrees × 𝜋/180. Haversine formula - in 2 steps
See Excel - As-the-crow-flies distance function for an Excel implementation. Excel's atan2 function takes its arguments in reversed order!
Bearing formula
Bearing = atan2(sinus(longitude_customer − longitude_Center of Gravity) × cosinus(latitude_customer) , cosinus(latitude_Center of Gravity) × sinus(latitude_customer) − sinus(latitude_Center of Gravity) × cosinus(latitude_customer) × cosinus(longitude_customer − longitude_Center of Gravity)
Bearing is measured against the vertical longitude axis, not the horizontal latitiude axis, so you need to swap the use of cosinus/sinus when calculating forces in x and y direction. |
Weiszfeld's algorithm as faster alternative
Weiszfeld's algorithm - see also Geometric median (wikipedia) - is simpler (but less intuitive) and works like this on an x,y plane:- Initialization: locate the 'Center of Gravity' at an initial (random) position.
- Calculate each customer weight as demand divided by distance to 'Center of Gravity'.
- Calculate the weighted average x,y of customers as the next 'Center of Gravity'.
- Repeat steps 2 and 3 until the sum of weighted distances converges.
Differences between Single Center of Gravity and Weiszfeld's algorithm
Major difference between Single Center of Gravity algorithm and Weiszfeld's algorithm is that the Single Center of Gravity algorithm uses an explicitly controlled move distance that - indirectly - enables an advanced feature: you can limit the move range of predefined warehouses. The optimal location may then be somewhere at the border of this limited range and Weiszfeld's algorithm cannot handle this.That difference is also the reason that Weiszfeld's algorithm converges approx. 10% faster.. Because, if the initial move distance is set too low, it will take many iterations to move a Center of Gravity to its final destination, so it is better to initialize it too high. But as a result, the first few iterations will often be useless overshoots (ignored - after which step size is divided by two - and then it quickly catches up with Weiszfeld's algorithm).
Centers-of-Gravity Calculator uses both algorithms
Centers-of-Gravity Calculator uses both algorithms: the faster Weiszfeld's algorithm as its default, and Single‑Center of Gravity algorithm in case of predefined warehouses with limited move range (and some other specific cases).Multiple Center of Gravity locations algorithm
Below, 'Center of Gravity' and warehouse are used interchangeably.A single run of the Multiple Center of Gravity locations algorithm does the following:
- Initialization: locate each warehouse at a random location within the customer cloud.
- (Re)assign each customer to its closest warehouse.
- Move each warehouse to the Center of Gravity of its assigned customers.
= apply Single Center of Gravity location algorithm / Weiszfeld's algorithm per warehouse - Repeat steps 2 and 3 until the sum of weighted distances converges.
Similarity with K-means Clustering
The above algorithm is similar to K-means Clustering (wikipedia) used for cluster analysis in data mining and machine learning.Animations of the Multiple Center of Gravity locations algorithm
The animations show what happens during a single run of the Multiple Center of Gravity locations algorithm. Customers are assigned to their closest warehouse, warehouses move to the Center of Gravity of their assigned customers, customer are reassigned, warehouses move, et cetera, until the final situation is reached where none of the customer assignments change anymore, and none of the warehouse positions.Although - in the first three examples below - each run starts with different initial random locations, the solution found is the global optimum with a minimal sum of weighted distances.
Run 1 - global optimum (50 iterations) | Run 2 - global optimum (33 iterations) | Run 3 - global optimum (21 iterations) |
Run 4 - local optimum (32 iterations) |
Beware of an overseas customer, far, far away
As seen in the previous section, calculating a single Center of Gravity location is not so much about distances as it is about pull forces and directions, finding the spot where all forces summed up together become zero.An exceptional multiple Center of Gravity locations case in which distance may become "directly relevant" is a case in which one customer is located thousands of miles away from all others, on some overseas island that belongs/belonged to a country. Then one of the Center of Gravity locations may end up on top of that customer. But locating a warehouse over there would make no sense. So you better remove such customer from your input data, or relocate it to exit harbor or airport.
Underlying assumptions
A major underlying assumption is that transport cost = rate/kilometer × distance. This assumption is only partly valid. For instance, parcel rates are often distance independent within a region. Macro-economic imbalances cause direction-dependent rates. Different transport companies may have different rates for the same route because they have a different customer base that may enable efficiencies (or not). From that perspective, it would be better to calculate with costs based on actual carrier rates. But most often you will not have transport rates for each and every possible warehouse location to every customer location. So then you have to rely on transport costs estimators.Distances used are not actual road distances, but estimated road distances. Estimated road distance = as-the-crow-flies distances × distance circuity factor. An important reason for using as-the-crow-flies distances is because run-time would become too long when having to calculate (extremely) large amounts of road distances.
Note that from a cost perspective the fastest route is more relevant than the shortest route, as driver and truck cost are more time-related than distance-related. Google Maps retuns fastst route by default. Which is fine. But fastest route may depend on time of the day, day of the week, time of the year, roadworks, or vary between routes that are nearly-equivalent. So, even actual road distance might still be an estimation, to some extent.
Calculating Center of Gravity locations is not so much about distances as it is about pull forces and directions, finding the spot where all forces summed up together become zero, as explained in the section about the Single Center of Gravity location algorithm.
As distance estimation errors occur in each and every direction (one customer distance might be a bit too large, another a bit too small), errors tend to cancel each other out, and the Center of Gravity locations (indicative warehouse locations) become pretty accurate. The use of as-the-crow-flies distance is usually not an issue, if the road network is dense. Approximations are acceptable, and commonly used in network design software.
Broader supply chain network design perspective
Of course, transport costs are only a part of supply chain costs. The optimal number of warehouses and their locations are driven by many quantitative and qualitative factors such as (future) transport and warehousing space and labor rates, future demand (and supply), lead time requirements, inventory effects, supply chain risk/redundancy, contractual obligations, taxes, distance to parcel/logistics hubs, workforce availability/public transport connections, et cetera.Nevertheless, it is common practice to run a Center of Gravity analysis to get a view on which logical warehouse locations to consider in a supply chain network design.
A completely different alternative approach
A completely different alternative approach is one in which a large set of possible warehouse locations is pre-generated, after which the k best ones are selected (see Combination - wikipedia).Advantages are that the warehouse-customer cost matrix can be based on various transport rate structures and accurate road distances, and that it may take into account binary-fixed and variable warehousing costs as well.
Disadvantages are that (much) more input is required, that there is a risk that the set of possible warehouse locations does not contain optimal locations, and that runtime may become an issue.
See section Select best warehouses to apply this approach.
Add-ons
This section explains some additional functionality of Centers-of-Gravity Calculator.LP optimization = Vogel's approximation + MODI + Stepping stone
If predefined warehouses have a limited capacity, a transportation problem arises. A transportation problem can be solved with the well-known Simplex method (LP). But it can be solved 50-100 times faster with a combination of Vogel's approximation + MODI + Stepping Stone method that generates an optimal solution. This combination has been implemented in Centers-of-Gravity Calculator. Detailed descriptions of each separate method (standard as such) can be found on the internet. For a demo case that shows the speed difference, see Transportation problem solverNote that if a customer receives from two warehouses in the optimal transportation problem solution (in which warehouse utilization never exceeds 100%), then this customer gets assigned in full to the warehouse that supplies the most, as Centers-of-Gravity Calculator is based on 'single sourcing'. This non-optimal, post-step may cause utilization to exceed 100%, usually less than 1%, as it involves a few customers only.
LP optimization ignores customer groups. But LP optimization will only get activated if warehouses still exceed capacity, after first having tried to solve capacity issues at group level if customer groups are applicable.
Superfast, greedy algorithm (if customer groups are relevant)
Centers-of-Gravity Calculator also contains a superfast, greedy algorithm as alternative that can be used if Vogel + MODI + Stepping Stone method runtime would become too long in case of an extremely large amount of customers and warehouses. As an extra, it will also try to keep customer groups intact. Roughly described, it works like this.- Assign customers to warehouses as if capacities are unlimited
- Loop through all warehouse, and while the capacity of a warehouse is exceeded shift that customer to that other warehouse that will increase the costs the least (and only if the customer still fits in that warehouse if it is a warehouse earlier in the loop).
Including supply-side
Suppliers come with supplier transport costs. Including suppliers means that Center of Gravity locations should move towards suppliers. But only as long as total transport costs decrease.Besides customers, suppliers also pull Center of Gravity locations, but in 'opposite' direction, and usually relatively less hard, as supplier transport is relatively less expensive than customer transport. See section Parameters & Constraints - subsection Transport rates.
Centers-of-Gravity Calculator supports 4 supply options that determine how supply flows are constructed.
- Each supplier delivers to closest warehouse onlyi
- LP optimized supply flows - with auto-sized suppliersi
- Each supplier delivers to each warehousei
- Each supplier delivers to each warehouse via closest warehousei
Each supplier causes (multiple) flows to warehouses. Each flow translates into a pull force (supplier or interdepot transport rate weighted) comparable to a customer pull force (customer tranport rate weighted) but pulling in 'opposite' direction. All forces are fed into the Single Center of Gravity algorithm that determines the position that minimizes total transport costs.
Besides, the customer assignment procedure of the Multiple Center of Gravity locations algorithm (step 2) takes into account (expected) supply-side transport costs when determining to which warehouse a customer gets assigned to.
Customer grouping (single-sourcing)
A customer group is used to force all customers within a group to be delivered by a single warehouse only (single-sourcing). The group is assigned to the warehouse that comes with the lowest sum of weighted distances for this group of customers. Underlying cost calculation is still done at individual customer level.What group stands for, is up to you to decide. For example, a group can be used to group customers per country, so each country is delivered from a single warehouse only.
A fixed customer-warehouse assignment takes precedence over a customer group. Warehouse capacity limits may cause a customer group to 'break'.
Select best warehouses
Select best warehouses goal value
Goal value to be minimized is the sum of customer plus supplier transport costs + warehouse binary‑fixed costs + warehouse variable handling costs. The "Select best warehouses" routine selects those warehouses from a predefinced set that minimize the goal value.- Customer transport cost if customer c is delivered from warehouse w = demand qty of customer c × as-the-crow-flies-distance between warehouse w and customer c × distance circuity factor × customer transport rate (= transport cost/distance unit/qty unit).
- Distance is based on coordinates of the predefined warehouse. (So, not the coordinates of Center of Gravity in case a warehouse was allowed to move. You may want to copy Center of Gravity coordinates back into your predefined warehouse table.)
- Distance includes detour via a border crossing point if applicable.
- You can adjust cost input via section "Override warehouse-customer transport costs input (optional)".
- Supplier transport cost (optional) for each supplier s = supply qty of supplier s × as-the-crow-flies-distance between warehouse w and supplier s × distance circuity factor × supplier transport rate * warehouse qty/total demand. This is conform supply option 3.
- Warehouse binary-fixed costs (optional) of warehouse w are its fixed costs and apply only if warehouse w is opened.
- Warehouse variable handling costs (optional) if customer c is delivered from warehouse w = productsum(customer c's whs quantities × warehouse w's variable rates). Note that customer field Demand (= transport qty) is irrelevant in this formula.
How to activate constraints
Constraint | Supported | How to activate |
---|---|---|
Predefined warehouses | yes | Always active (regardles constraint setting). |
Fixed customer-warehouse links | yes | By checking constraint in Parameters & Constraints - subsection Constraints |
Capacity limits | yes | By using Greedy solver or LP solver (not by checking constraint). |
Customer groups | no | |
Suppliers | yes (partly) | By checking constraint in Parameters & Constraints - subsection Constraints. Supply option 3 is activated in background. Other options not supported. |
Border crossing points | yes | By checking constraint in Parameters & Constraints - subsection Constraints. |
Select best warehouses algorithms - Summary
The selection of best warehouses is handled by two separate procedures.- One procedure that generates valid warehouse combinations = close/open decision (0/1) for each warehouse. The Enumeration solver simply generates all possible warehouse combinations, whereas the other two solvers generate only "promising" combinations (so they run relatively much faster, but may miss out the optimal combination).
- One procedure that handles warehouse capacity limits, given the close/open decisions. If "ignore / n.a. (not applicable)" is selected, then each customer can simply be assigned to that open warehouse that brings the lowest costs. Otherwise, a (so called) transportation problem must be solved. The Greedy solver solves quickly, but may produce sub-optimal customer assignments. The LP solver solves relatively slow, but produces optimal customer assignments.
Best is to run Enumerations Solver, in combination with LP Solver if warehouse capacity limits still apply in future.
If run time is too long, then stop the run and
- use K-means Clustering Solver (with a limited number of runs) or Superfast Selection Solver to generate valid warehouse combinations.
- and/or use Greedy Solver to handle warehouse capacity constraints. Especially LP Solver is relatively slow.
Warehouse combinations generation
Enumeration Solver
Generates all possible valid warehouse combinations, so it will always find the optimum. But the higher the number of permutations, the longer the run time. It may even take hours. Reason to develop the other two solvers, that run quickly and will almost always find the optimal solution, however without guarantee. Because all combinations are generated and evaluated, the Enumeration Solver can produce a "top 20" list of warehouse combinations.Superfast Selection Solver
Problem-specific solver, invented by Stelling Consulting. Found optimal solutions in almost all tests, or else 0-2% worse. Roughly described, it works like this:- Open 1 by 1 the next best warehouse, until the amount of opened warehouses exceeds the amount to be opened with X. Then close X worst warehouses 1 by 1.
- Swap N open warehouses with N closed ones (within 1 to N groups). Run for all possible swaps, enumeration-wise. Revert swap if solution got worse.
K-means Clustering Solver
Problem-specific solver, custom developed by Stelling Consulting. Performs a K-means-Clustering-like procedure.Single run
- Initialisation: for each group, select a random warehouse within the group and open it, until the amount of warehouses to be opened for this group has been reached.
- As long as costs still decrease, keep looping through all open warehouses, and
- Close this open warehouse.
- Find the closed warehouse within this group that will decrease costs the most (or increase the least), if it is opened.
- Open that warehouse. (It might be the same warehouse as the one that just has been closed.)
- Perform the single run procedure multiple times (each starting with different randomly selected warehouses).
- Often, this best solution will have been found in several times of those runs. (Just like the Center of Gravity calculation procedure that will find the same solution several times doing N runs.).
Speed is usually in the same ballpark as Superfast Selection Solver. But if a high number of warehouses and (relatively) high number to be opened is applicable, then the limit on number of runs makes it finish faster than Superfast Selection Solver.
Warehouse capacity limits handling
Greedy Solver
Greedy Solver runs a fast, greedy algorithm that works likes this:- Assign customers to warehouses as if capacities are unlimited
- Loop through all warehouse, and while the capacity of a warehouse is exceeded shift that customer to that other warehouse that will increase the costs the least (and only if the customer still fits in that warehouse if it is a warehouse earlier in the loop).
LP Solver
LP Solver runs Vogels' approximation + MODI + Stepping Stone a much faster equivalent of LP optimization by Simplex method. If predefined warehouses have a limited capacity, a transportation problem arises. A transportation problem can be solved with the well-known Simplex method (LP). But it can be solved 50-100 times faster with a combination of Vogel + MODI + Stepping Stone method that generates an optimal solution. This combination has been implemented. Detailed descriptions of each separate method (standard as such) can be found on the internet. For a demo case that shows the speed difference, see Transportation problem solverNote that if a customer receives from two warehouses in the optimal transportation problem solution (in which warehouse utilization never exceeds 100%), then this customer gets assigned in full to the warehouse that supplies the most. This non-optimal, post-step may cause utilization to exceed 100%, usually less than 1%, as it will involve/apply to a few customers only.