Typical mistakes when scaling the network - Part 2/4: Location
Aktualisiert: 24. Juli 2019
"Real estate is the key cost of physical retailers. That's why there's the old saw: location, location, location." (Someone at Amazon)
Last week we have covered the matter of timing when scaling up your logistics network. In a nutshell: how to find out at which point in time additional processing or storing capacities need to be created? That’s not necessarily the first thing to cover, but it is a commonly known issue with a rather intuitive method as possible solution. A different question, also comparatively easy to follow but not quite as easily mastered, is where to place these new capacities on a map.
Typically, the topic of determining locations arises right after the timing aspect has been covered (as it should be on a regular basis). “We will need a new location up and running in 2.5 years. Now, where should we build it?” In this article we will talk about the nature of this problem and possible ways of solving it.
How to find a location for new logistics capacities
The field of Logistics consists of planning, steering, optimizing and handling the flow of goods, information and people. In the context of e-commerce we usually deal with flows of goods. The location aspect does matter quite a bit for people flows, but for us it is a rather rare use case. One easily forgets that the flow of information was dependent on location until not too long ago. By now it has been reduced to the mere question of where information is physically stored and who has access to it.
Therefore, in e-commerce logistics we are, for the most part, in charge of moving goods through our networks. These networks consist of nodes and connections between these nodes. From an abstract point of view one could say that goods are processed and/or stored at nodes on the one hand but moved along the connections on the other. Ignoring detailed routing decisions, one could say that connections are merely a result of the nodes’ locations, reducing the location decisions of a network to the placement of nodes across the European map, or even the entire Globe.
Not all nodes can be placed freely. We will not be able to get our end customers to move to another town by offering them discount codes in return. Hardly any e-commerce company already disposes of its own delivery network and relies on partners to cover the last mile. Similar setups are true for the (often neglected) sourcing side of the supply chain: production sites are often not managed by the company itself, making their coordinates rather fixed.
If inbound as well as outbound side of the network are a given one may (have to) limit location-wise optimization to the own network, typically classic fulfillment centres or warehouses. There are two types of variables to be considered: those that depend on the node locations of the network and those depending on the length and location of the resulting connections.
Two rather obvious connection variables come to mind: time and cost. Quite simply put, a linehaul transport from Erfurt to Barcelona will cost you both: transportation cost for each shipment and additional lead time to your Spanish customers.
Time and cost are also relevant node variables, while in that context cost receive the lion’s share of the attention, since time as a node variable is oftentimes assumed insensitive to node location. Processing cost (since very dependent on blue collar wages) on the other hand vary greatly from location to location. In that context one must consider said wages as well as rents, required investments and interest rates, taxes and other aspects. Additional node variables include the availability of customers and workforce within a determined radius as well as infrastructure and complexity of application processes for permits and alike. To make things more interesting, suitable real estate objects in the most attractive areas of Europe have become increasingly scarce.
So, the location problem for any given logistics network seems complicated enough even when just considering one location change or addition. It is advisable to run a proper due diligence in order to not forget anything and setup an elaborated rating system to facilitate the decision process.
Most of the aforementioned variables can be covered by (a good deal of) research or purchasing information from suitable entities. Time and cost though are typically too individual to just assume, they should rather be modeled. Models like that exist in different levels of complexity. I like to differentiate between models for visualization and those for optimization.
Visualization models limit themselves to give a detailed overview of the cost and time required by any option from a manageable amount of possible solutions. These results can then be considered in an agreed rating system and thereby support the decision process. This type of approach is best suited for initial orientation or decisions under time pressure or with limited options. It does not necessarily require expensive software and can be done properly in a reasonable amount of time.
Optimization models on the other hand identify the best option(s) from a very large set of possible solutions. They are typically based on mathematical concepts and imply either programming languages or specialized software. This rather elaborate setup makes most sense in large networks with significant growth, when several locations are placed simultaneously or in longterm strategic decision processes.
Both approaches function via weighted connections and cost-factors and identify the solution with the lowest sum (of all cost or of all times) while adhering to previously defined conditions and limitations. This concept is sometimes duped Centre of Gravity Analysis in the context of logistics.
This short overview can of course merely scratch the surface of how this works in reality. Countless interesting questions may be discussed in this context, as for example how to define a good proxy for perceived end customer lead time or how to weigh time against cost in a combined target variable. Gladly I will exchange standpoints on these topics with anyone interested, via LinkedIn / Xing / Contact.