Designing a supply chain network often starts with a demand Centers-of-Gravity analysis that will provide a first good view on what warehouse locations to consider.
This page visualizes and describes in detail how to determine and calculate Centers-of-Gravity, covering the basic core algorithms of Centers‑of‑Gravity Calculator.

The page concludes with notes about data preparation and things to consider when doing a Centers-of-Gravity analysis.

The page concludes with notes about data preparation and things to consider when doing a Centers-of-Gravity analysis.

Centers-of-Gravity are those locations that minimize the sum of weighted distances. Weighted distance is the distance from warehouse to customer multiplied by demand. If customer A has a demand of 10 and is located 25 kilometers (km) from its warehouse, then the weighted distance is 250 km. The sum of weighted distances over all customers acts as an indicator for transport costs.

In an extended version weighted distance is defined as distance × demand (1

Underlying assumption of the Centers-of-Gravity analysis is:

This assumption is only partly valid. Parcel rates are often distance independent within a smaller country or region, FTL pallet rate/km is lower than LTL pallet rate/km, macro-economic imbalances cause direction-dependent rates. And (upscaled) as-the-crow-flies distances are used as an approximation of road distances.

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 rates, future demand (and supply), lead time requirements, inventory effects, supply chain risk/redundancy, and contractual obligations. Nevertheless, it is common practice to run a Centers‑of‑Gravity-analysis to get a view on what warehouse locations to consider, when designing a supply chain network.

Customer A has a demand of 10 and customer B a demand of 1.

Where is the Center-of-Gravity (CoG)? Somewhere on line A-B, closer to A?

Well, customer A pulls 10 times harder than customer B.

If the CoG moves a distance d towards A the

So, the CoG is right on top of customer A,

Though the goal value is the

The overall demand force is leading. In the example it has a length of 9 and points towards customer A.

The overall demand force points the right direction, but it does

Or this far?

The smaller the move distance, the less chance of bypassing the CoG, but the more moves to be made. So, start with big moves. If the CoG is bypassed ('overshooting') then the sum of weighted distances will have increased instead of decreased, and the move size should be reduced to half of its size. By then, the force arrow will have reversed its direction (it always points in the right direction). By taking smaller steps each time having bypassed the CoG you will finally end up on top of it! You may stop moving back-and-forth if the move size has become very small. Or alternatively: do not move to a next position if it would increase the sum of weighted distances, but lower step size first (then the force arrow will never completely reverse its direction).

Below you will find a real-time generated animation that visualizes the above process, step-by-step.

All forces pulling the Center-of-Gravity need to be summed up to get the overall pull force, which is a vector with a size (irrelevant) and a direction.

- Step 1: locate Center-of-Gravity at an initial position, and initiate 'move distance' at a large value, for example 100 kilometers.
- Step 2: calculate the overall pull force and move the Center-of-Gravity in that direction, at move distance.
- Step 3: calculate the sum of weighted distances. If it has increased, then move back to the previous position, and divide move distance by two.
- Repeat steps 2 and 3 until the move distance has become sufficiently small.

This algorithm resembles the gradient descent method.

Note that X,Y on a flat plane (Chartesian coordinate system) needs to be translated into latitude, longitude on a globe (Spherical coordinate system). All principles remain the same, but formulas become more complicated. |
Flat plane? |

Each single run of this algorithm does the following:

- Step 1: locate warehouses at a random location

Optional: then assign customers given those random locations, calculate the weighted X,Y of assigned customers, and use this weighted X,Y as initial position of the warehouse. - Step 2: (re)assign each customer to the closest warehouse.
- Step 3: move each warehouse to the Center-of-Gravity of its customers = apply Single-Center-of-Gravity algorithm.
- Repeat steps 2 and 3 until the sum of weighted distances does not decrease anymore.

Multiple runs are done, each run starting with different random locations. The best solution out of those runs is presented as final outcome. The higher the number of runs, the more likely the optimal solution will be found. Usually, this optimal solution will then have been found multiple times as well.

The animation shows what happens during a single run of this algorithm: customers (circles) are assigned to the closest warehouse (triangles), warehouses move to their center-of-gravity, customer are reassigned, warehouses move, et cetera, until the final situation is reached where none of the asssignments and warehouse positions change anymore.

START(index 100) |
→ | RUN |
→ | FINISH(index 68) |

On a side note, the problem and algorithm are comparable to

**Collect customer data: adresses, demand (and number of shipments). And always validate your data!**

- Retrieve data from your ERP system: customer addresses and demand.
- Express demand in the transport cost driver applicable for your business: weight, volume or volumetric weight.
- Demand can either be derived from sales (item master based) or from shipments (carrier based). If available and trustworthy, then use shipment data. Item masters are not always '100% clean'. For example, some items accidentally got 'kilogram' instead of 'gram' as Unit of Measurement causing large kilogram errors. Of course, best is to compare both, check outliers, check if M3/KG make sense, check top-X customers, check on the map, et cetera: data validation!
**Optional**: incorporate number of shipments in the calculations (using a more advanced definition of 'weight' than simply 'demand'). This may add accuracy. However, its impact on Centers-of-Gravity will often be marginal. Therefor, considered optional.

**Optional: collect supplier data: adresses, supply (and number of shipments)**

- You may want to consider both demand and supply, as supply pulls a warehouse as well.
- Take into account that supplier transport is usually more FTL-like (relatively less expensive) and customer transport more LTL-like: reduce supplier sizes.

**DEMAND ONLY****DEMAND AND SUPPLY: CoG has moved 165 kilometers up north****Geocode adresses**

Geocode customer (and supplier) locations. Geocoding is the process of taking input text, such as an address or the name of a place, and returning a latitude/longitude location on the Earth's surface for that place. Those latitudes/longitudes are required for the distance calculations.

The analysis is usually based on total demand per customer, not on individual shipments. You may even want to aggregate demand up to regional level. Within Europe a 2-digit postal code level is usually accurate enough. In general, data aggregation keeps models smaller and run faster. It may also make a map more clear: a few larger dots are more easily compared to each other than tens of thousands tiny dots. However, geocoders - such as this**Geocoder**- will run at (postal code) address level, not at 2-digit postal code level.**Consider harbours**

If far-away-customers are delivered via an exit harbour, then put the aggregated far-away-customers' demand on top of that harbour, instead of the customer country. The harbour may be located in opposite direction of the demand country, seen from a warehouse perspective. A warehouse should be pulled in the right direction!**Consider regional setups**

You may want to split your data set. For instance, if you already know that you will operate a warehouse in the UK to deliver UK customers, then split your data into 'UK data' and 'mainland Europe data' and run the model for both sets separately.