After adjustment, a single Calculation is run to effectuate changesCustomer/supplier size factor⇐ Set it such that 1st legend value becomesiCenters‑of‑Gravity size factorFlow size factori
Customer/supplier opacityCenter‑of‑Gravity opacityCenter‑of‑Gravity colorLabel font sizeDisplay transport-rated volumesiDisplay Centers‑of‑Gravity as fixed-sized circlesiDisplay customer flowsDisplay supplier flowsSupplier flows colorSupplier flows arrow sizeiScale arrows
Save all map settings asunder button
Reload: click a button
⇒ Your custom settings used at startupii
Latitude | Longitude | Demand | Warehouse_ID (opt) | Group (opt) | Shipment_size (opt) | Lead_time_distance (opt)
Latitude | Longitude | Supply | Warehouse_ID (opt) | Shipment_size (opt) | Supply_option
Warehouse_ID | Latitude | Longitude | Move_limit (km) | Capacity (opt) | Transport_rate_index (opt)
- Warehouse_ID (= link to table Predefined warehouses) is used to assign a customer to a predefined warehouse. If left empty, the software decides to which Center‑of‑Gravity the customer will be assigned. If you specify Warehouse_ID, then the customer will be assigned to that warehouse, regardless Group.
- Group - free format, for example "UK" - is used to force all customers within a group to be delivered by a single warehouse only , the one that comes with the lowest sum of weighted distances for this group of customers. What group means, is up to you - often used is country. Warehouse capacity constraints may cause some customers of a group to get reassigned to another warehouse. You can fill group for some customers (treated as group), and leave group blank for others (treated individually).
- Shipment_size is used to calculate an individual customer transport rate.
- Given two customers with equal demand, the customer with smaller shipments will pull the Center‑of‑Gravity harder than the customer with larger shipments, as transporting many small shipments is more expensive than tranporting a few large shipments. So, customers with smaller shipments will pull a Center‑of‑Gravity relatively less and vice versa.
- The impact of individualized shipment sizes on Centers‑of‑Gravity locations will be marginal, if small and large (shipment) customers are scattered all around, which is usually the case. You can start without individualized shipment sizes.
- Transport rates - including logic behind transforming shipment size into transport rate - are explained under section "Optional constraints and parameters".
- Lead_time_distance (km) represents lead time requirement expressed as the maximum allowed distance from the warehouse. Customers are colored in black if warehouse distance exceeds leadtime distance. This provides a visual clue of where lead times are compromised. You can then decide to increase the number of warehouses, or to setup a predefined warehouse at a location closer to these customers (with a zero or limited move range), or accept that some customers will have a longer lead time (like in reality; a few small far-away customers should not be driving your supply chain network design!).
- Warehouse_ID (= link to table Predefined warehouses) is used to assign a supplier to a warehouse. If left empty, the software decides which Center(s)-of-Gravity is/are supplied by the supplier. If set, then this supplier will not supply all warehouses directly, even if supply option "Each supplier delivers to each warehouse directly" has been selected.
- Shipment_size is used to calculate a supplier specific transport rate. Transport rates are explained under section "Optional constraints and parameters".
- Supply_option is used to overrule the generic supply option as selected under section "Optional constraints and parameters".
- Supply closest warehouse onlyi
- Supply each warehousei
- Supply each warehouse via closest warehousei
- 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).
- Move_limit = 0 means a fixed location, whereas Move_limit > 0 (in km, not miles!) means a moveable location that may move within its Move limit around its coordinates.
- Capacity is used to limit the demand that can be assigned to a warehouse. Capacity constraints may 'break' customer groups.
- 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).
|Sum of weighted distances||
Distance / lead time / service levelFactor to convert as-the-crow-flies-distance into fastest route road distanceiColor customers black if warehouse distance exceeds lead time distancekmiImprove service leveli
Closest city nameDisplay CoG closest cityiOnly consider cities with a population larger than
- City name appears as Center-of-Gravity name on the map and in reports, if you have checked 'Display closest city name'.
- But warehouse_ID is shown as name in case of a predefined immovable warehouse.
- When determining closest city, only cities with a population larger than the population threshold are included.
- The database contains cities that have a population larger than 15,000, as depicted below.
-costs-increase-areas around Centers‑of‑Gravityi
Randomize each demand quantity ±
; using a
Apply constraintsPredefined warehouse locationsFixed customer-warehouse assignmentsFixed supplier-warehouse assignmentsCapacity limitsCustomer groupsi
Supply optionsActivate supplyEach supplier delivers to closest warehouse onlyi
Each supplier delivers to each warehousei
Each supplier delivers to each warehouse via closest warehousei
Auto-size shipments per individual customeri
% FTL costs
iCosts/km iTransport rate FTL Customer Supplier Interdepot Ratio supplier rate/customer rate = Transport cost of a customer = demand × distance warehouse-customer × customer transport rate (that becomes
customer specific if shipment size is specified in customer table - same rate logic as shown above applicable).
- Transport rates enable differentiation between relatively less expensive FTL-like (supplier) transport and relatively more expensive LTL-like (customer) transport.
- In order to minimize transport costs a Center‑of‑Gravity should move closer towards a customer than towards a supplier, if their volumes would be equal.
- The ratio between supplier and customer transport rate is more important than the rates as such.
- Under map settings you can choose to display location sizes as transport-rated volumes (volume × rate ratio), instead of plain volumes. Suppliers will then appear relatively smaller than customers, thus properly reflecting the force with which a location pulls a Center‑of‑Gravity (though in case of a supplier, this force may be split across all warehouses, dependent on selected supply option).
- You may even enter shipment size per individual customer, to differentiate transport rates between customers. However, impact on Centers-of-Gravity locations will be marginal, if small and large (shipment) customers are scattered all around.
- LTL transport is relatively more expensive than FTL transport. An LTL shipment size of 50% FTL brings 72% FTL costs, approximately. Thus, per each unit transported LTL transport is 1.44 times more expensive than FTL transport.
Shipment costs curvei LTL cost factor as % FTL cost Shipment size as %FTL
Point X Y Start point (P0) % % Start control point (P1) % % End control point (P2) % % End point (P3) % % Just a specific point on the curve % %
- Check constraint "Fixed customer-warehouse assignments" to assign customers to a warehouse. Demo data: customers in UK/Ireland are assigned to the predefined Birmingham warehouse (field Warehouse_ID set to "Birmingham"), and customers in Spain/Portugal to the Madrid warehouse.
- Check constraint "Customer groups" to have all customers within a group delivered by the same single warehouse. Demo data: all customers have field Group filled with a 2-letter ISO country code. In this case group means country: each country is delivered by one warehouse only.
Predefined warehouses table (optional)
- Check constraint "Predefined warehouse locations" to activate predefined warehouses and include those in the solution. Demo data: there is one warehouse in Birmingham/UK (cannot move, field Move limit set to 0) and one in Madrid/Spain (can move within a 200 km range around Madrid, field Move limit set to 200).
- Check constraint "Capacity limits" to limit warehouse throughput capacities. Demo date: field Capacity is set for both Birmingham and Madrid.
Suppliers table (optional)
- Check parameter "Activate supply" to activate supply. Demo data: there is one supply location in harbour Rotterdam/The Netherlands (supplies 71% total demand volume), and one in Bologna/Italy (supplies 29% total demand volume).
- Suppliers - like customers - pull Centers‑of‑Gravity which will tend to move towards suppliers, as supply volumes are usually high compared to individual customer demand volumes. However, supplier transport is - due to larger shipment sizes - relatively less expensive than customer transport. Transport rates express how much less. Supplier quantity × supplier transport rate = supplier pull force. Suppliers will appear relatively smaller on the map - reflecting pull force as used in the calculations - if you check Map Settings option "Display transport rated volumes".
- Flows from suppliers to customers via warehouse(s) are constructed automatically. Under Supply options you can chose from three options. Option “each supplier delivers to each warehouse” is the default option, and means that the supplier volume to each warehouse is pro rata the customer demand assigned to each warehouse.
|Distance||Demand cum||Demand||Customers cum||Customers||# Customers|
CoG_ID | Latitude | Longitude | Demand | Total_demand_% | Utilization | Closest_city | Distance_to_Closest_city
Latitude | Longitude | Demand | Warehouse_ID | Group | Ship_size | Leadtime_dist | CoG_ID | Distance | Transport_rate | Transport_costs
SERVICE LEVEL DISTANCES
Distance | Demand_cum_% | Demand_% | Customers_cum_% | Customers_% | Number_of_customers
Current situation0 optimization freedom
• All warehouses as is
• All customer assignments as is,
so warehouse capacity constraints
adhered to as well
Realistic scenarioSome optimization freedom
• Some warehouses as is
• Some warehouses closed
• Some warehouses extended
• Some warehouses newly added
• Some customers reassignable
• Some capacity constraints
Greenfield100% optimization freedom
• Free amount of new warehouses
at Centers-of-Gravity locations
• All customers reassignable
• No capacity constraints
|100% ←- Optimization freedom -→0%|
- Fill out input table Customers.
- Select the number of Centers‑of‑Gravity, and press Calculate.
- View map and other outputs. Then change the number of Centers‑of‑Gravity and see how it affects sum of weighted distances (transport costs indicator) and service level distances.
To understand how the software calculates you can read page How to determine Centers‑of‑Gravity.
- Fix warehouses at their current location by filling out table Predefined warehouse with field Move_range set to 0, and checking constraint "Predefined warehouse locations".
- Assign customers to their current warehouse by entering field Warehouse_ID in the Customers table, and checking constraint "Fixed customer warehouse assignments".
You can quickly (un)check those constraints to see how those affect outcomes.
Once you have replicated the current situation you can gradually allow more optimization freedom while keeping constraints activated.
- Investigate if current locations are optimal - given fixed customer assignments - by increasing Move_range of (some) predefined warehouses.
- Investigate if current customer assignments are optimal - given fixed warehouse locations - by removing Warehouse_ID of (some) customers, or by unchecking constraint "Fixed customer-warehouse assignments".
- Investigate where to open a next new warehouse by increasing the number of Centers‑of‑Gravity beyond the number of predefined warehouses. Make sure you allow (some) customers to get (re)assigned to this new warehouse.
Relaxing some constraints, you may want to implement other types of constraints:
- Limit warehouse capacities - to constrain demand volume that can be assigned to a warehouse - by filling field Capacity in the Predefined warehouses table and activating constraint "Capacity limits". Keep in mind that in the future capacity limits may not be applicable anymore, if additional space can be rented or the owned facility expanded.
- Group customers for single sourcing to enforce all customers within a group (free format, what group stands for is up to you) to be assigned to a single warehouse, by filling field Group in the customers table (for some or all customers) and activating constraint "Customer groups". (In the demo group stands for country. Customers are grouped per country. Group is used to avoid that customers in the western part of France are delivered by a warehouse in the UK.)
Besides, you can run a sensitivity analysis that indicates how much transport costs increase if a warehouse is located outside the Center-of-Gravity. An area around the Center-of-Gravity is drawn. At the area border the transport costs of the warehouse would increase x%. The higher x is set, the larger the (irregularly shaped) area becomes.
A Center‑of‑Gravity analysis usually focuses on the demand side with its relatively high transport costs and lead time requirements. But you can add the supply side to optimize supply transport costs as well. Adding the supply side becomes more relevant if there are a few major supply locations, such as a harbour, in which case a warehouse should move towards the harbour.
Because supplier shipments are larger than customer shipments - which makes supplier transport relatively cheaper - suppliers pull Centers‑of‑Gravity relatively less than customers. Differentation between customer and supplier transport rate is handled in subsection "Optional constraints and Parameters".
Flows from suppliers to customers are constructed automatically. You chan choose from 3 supply options:
- Each supplier delivers to closest warehouse* only
- Each supplier delivers to each warehouse
- Each supplier delivers to each warehouse via closest warehouse** Closest warehouse (auto-detected) can be overruled by specifying a predefined warehouse in the supplier table
Under option 1 each supplier - like a customer - pulls one warehouse (though relatively less).
Under options 2 and 3 each supplier - unlike a customer - pulls all warehouses.
Demand side onlyCenters‑of‑Gravity are pulled by customers only
Supply option 2All Centers‑of‑Gravity are pulled towards a major supplier.
Supply option 3Especially the closest warehouse is pulled towards a major supplier.
You can quickly (de)activate the supply side and see how this affects the Centers‑of‑Gravity locations. Note that you can no longer directly compare the solution value to the value of a model without supply.
Run sensitivity analysisThe software supports:
- the creation of an area around each Center-of-Gravity on the map that shows where it can be located before its transport costs would increase more than X%.
- the randomization of the demand quantity of each customer with ±X%, after which you can investigate how it affects the solution.
Remark: broader supply chain network design perspectiveTransport costs are only a part of supply chain costs, and the optimal number of warehouses and their locations are driven by many quantitative and qualitative factors, such as (future) transport and warehousing rates, future demand, lead time requirements, inventory effects, supply chain risk/redundancy, contractual obligations, distance to parcel/logistics hubs, workforce availability/public transport connections, et cetera.. Nevertheless, it is common practice to do a Center‑of‑Gravity-analysis in a supply chain network design, as it provides useful insights.
Collect customer adresses and demand quantitiesRetrieve customer addresses and demand quantities and/or shipment data from your system. Ideally, express demand quantities in the main transport cost driver applicable for your business: weight, volume or volumetric weight.
- Consider seasonality: take a full year of data if your business is seasonal.
- Demand can be based on sales order quantities × item master dimensions. But most likely, your item master will not be 100% clean. It may contain items that accidentally got 'kilogram' instead of 'gram' as UoM. This may cause large errors when calculating volumes. So, if available, then collect shipment data with actual (pay)weight or volumes.
- Validate your input data
- Check for zero and empty values.
- Check item master (sold products only). For example, does kilogram/m3 make sense?
- Check for outliers. For example, calculated shipment sizes that exceed truck capacity.
- Check completeness. For example, compare number of orderlines to a warehouse productivity report.
- Check top-X customers list. Major customers missing? Unknown/small customers appearing?
- Check demand map. Gaps? Unknown large locations?
- Though not used as input by the Centers‑of‑Gravity Calculator, product groups and sales channels may become relevant when designing your supply chain network in more detail. Define relevant product groups/levels - related to your network design questions - before data collection.
Include growth projectionsDesign for the future: include growth projections if those are substantial and different (per product group) per region.
Geocode adresses (and aggregate demand)Geocoding is the process of converting addresses (like a street address) into geographic coordinates (latitude and longitude). Those are used for creating locations and flows on the map, and in (distance) calculations. See Free Batch Geocoder or Batch Geocoder if you still need to retrieve latitudes and longitudes of locations.
Consider aggregating demand per latitude/longitude (using an Excel pivot table), especially when creating a demand map. Without aggregation customers with the same latitude/longitude are plotted on top of each other and a relatively small dot will appear on the map. After aggregation a bigger dot will appear, which better reflects underlying volumes.
Consider harboursIf far-away-customers are delivered via an exit harbour, then put the aggregated far-away-customers' demand on top of that harbour, instead of their original location in the demand country. The harbour may be located in opposite direction of the demand country, seen from a warehouse perspective, and a warehouse should be pulled in the right direction in the optimization process!
Consider regional setupsYou may want to split your data set. For instance, if you already know that you will operate a warehouse/warehouses in the UK to deliver UK/IE customers only, then split your data set into 'UK data' and 'mainland Europe data' and run the model for both sets separately. If it is about a single UK warehouse only, then - alternatively - you can link UK/IE customers to a predefined UK warehouse (that is allowed to move), without having to split the data set.
Optional: Collect supplier adresses and supply quantitiesYou may want to add suppliers so supplier (and interdepot) transport costs are also taken into account when optimizing Centers‑of‑Gravity.
Software performanceCenters‑of‑Gravity Calculator runs much faster - like a few seconds versus several minutes - than Llamasoft (test 2017) and Excel Solver (test 2018), and finds the same optimal locations (basic model test).
AlgorithmsCore algorithms are explained in full on this separate webpage How to calculate Centers-of-Gravity