Having worked with a number of online supermarkets in the past couple of years, I found that there are two strategic approaches to making eGrocery operations profitable. And which one can work for you is largely dependent on one particular constraint.
Two Paths to Happiness
The first approach is based on a high degree of automation. This approach is capital-intensive and risky. In this approach, what can be automated will be automated. Technologically, it is based on large scale automated storage and retrieval systems (AS/RS) to power a high-pace good-to-person picking system and a shipping buffer. Also, the AS/RS holds most of the inventory, typically complemented by a pallet storage, manual or automated, for additional replenishment inventory. Project size tends to be upwards of 80 million euros just for automation hardware and software. For that amount of money, customers are getting a huge chunk of technology that can do just about everything. Whether the AS/RS is based on a shuttle system, AutoStore, Ocado’s proprietary hive robot, or any of the newer technologies (Exotec, Attabotics…) does not really matter — in principle, this can be done with any of the technologies (your trusted sales manager will disagree, of course). Sometimes, the AS/RS will be complemented by a zone picking system for the faster-moving share of the product range, which is a smart thing to do to lower the cost for the AS/RS and for the overall system.
This first approach, going all-in with a high automation degree, could be labelled the Ocado or the Picnic approach: both companies are following this strategy, having recognized that scale is important to manage unit economics. Note that Ocado and Picnic have some of the brightest people in the eGrocery industry.
Besides the obvious challenges with this approach (extremely high CAPEX, limited flexibility once the system is in place) there is but one serious weakness for the customer: as the customer, you will get married to the automation provider. And with some probability, it is a relationship in which you make yourself completely dependent on your spouse. Moreover, the cost of breaking up is very high, if not prohibitively high. You’ll be locked in. This can be alright or not, and as with every relationship you will only know later.
Now, you could say that this risk is imminent for any large-scale automation project. I disagree: it’s a much bigger risk for eGrocery than for projects in other industries. I will elaborate on this point in a brief moment.
The second approach is that you settle for a light-weight automation system with low complexity. Some processes will remain manual and automation technology mostly covers picking support. No large-scale AS/RS. Low CAPEX, smart and lean processes. And, importantly, continuous improvement.
Continuous Improvement vs. Dinosaur Software
The last point, continuous improvement, is crucial. Continuous improvement is one thing that sets great organizations apart from mediocre ones. And continuous improvement is something that is exceedingly difficult when you follow the first strategy and you deploy large-scale automation systems.
In order to operate large, complex automation systems, you need large, sophisticated software systems. These systems typically come with the automation system; all warehouse automation providers have their comprehensive software packages. And this is where the true intelligence lies (anybody can build shuttles and conveyors). Every warehouse process needs to be embedded in the software, else, for all practical matters, it does not exist. Now, these software packages allow parameterization — to some extent. But changing processes, or implementing new processes, often requires modification to the source code. Customers do not have access to the source code. And even if they had, they would have a hard time working with the dinosaur monolith-like systems these huge software packages are. And even if they had the technical abilities to do so, they’d waive their warranty for the entire system. The consequences of tampering with the source code are even more far-reaching and could involve serious safety risks (can maintenance staff be sure that shuttles and lifts really are switched off when entering an aisle?). In short: it is not an option.
This implication for continuous improvement is obvious: you cannot do it. What you can do is submit a change request. The automation provider will review the request, which can take weeks or months. They will send you an offer, typically with a price tag that will seem unreasonably high, based on the number of man-days they expect will be needed to incorporate the changes (or maybe more realistically: which they expect to not exceed your pain threshold). Once the initial offer was met with indignation and was negotiated down to acceptable levels, it will take months before resources are available to begin the work. When the changes finally are incorporated, chances are they are either no longer needed, or they will have to be modified extensively so as to meet new requirements from all the learning that happened in the meantime. In short: again, it is not an option.
In the second approach, you develop and run your own, self-developed software system. You will have to learn how to integrate and control light-weight automation (e.g., conveyors), which, in contrast to controlling large-scale shuttle systems, is not rocket science. You maintain full control of the system and thus of all the processes. You can maintain a continuous improvement process, and you can deploy changes and updates virtually every day. In order for the software development effort to stay manageable, system complexity has to stay low. You may need to give up some presumed productivity benefits of large-scale automation systems, but you can come a very long way before that is even relevant. And chances are the differences will become negligible over time. Besides that, your CAPEX for the system is so much lower that you can afford slightly lower productivity.
The role of continuous improvement for eGrocery systems is quite important. Yes — continuous improvement is always a good idea. With eGrocery, however, the mix of requirements is so complicated that it is close to impossible to get everything right from the beginning. You start off with a system that is well thought through and makes sense, but even then some things will turn out fine while others won’t work. Plus, requirements change: maybe you want to increase your share of same-day delivery, maybe you want to increase your distribution range and therefore build up a hub and spoke distribution system, maybe you want to include fresh meat in your offering that will require a separate zone in the warehouse for order preparation: in each case you will have to adjust your processes or introduce new ones. Regardless how well your initial system was planned out, you cannot anticipate all future changes.
There is a reason why all successful eGrocery companies are software companies in disguise. I will go so far as to say that there is no future for eGrocery companies that are not. Those still exist and they will survive for some more time on investor money, but it is unlikely they will be able to ever stand on their own feet.
Both approaches, very high automation and very light-weight automation, can work and can lead to profitability. There is proof for both. What will not work, however, is some half-assed automation approach in the middle: too small to reap the benefits of scale, too complicated to be controlled and continuously improved with the customer’s own software.
Which Way to Go? SKU Count as a Strategic Decision
Now, can you freely choose which strategy to follow? No, you cannot. Because there are certain parameters that will force you into one direction. The most important parameter is the number of SKUs you want to offer. Simply speaking, when the aim is to offer tens of thousands of different products, you can only make this work efficiently with a large-scale goods-to-person system. If you are happy with less than, say, 8.000 – 10.000 products, you can go either way.
No senior manager of a food retailer will be surprised to hear that the number of SKUs on offer is a strategic decision. Most will be surprised to hear, however, that the number of SKUs can make or break their eGrocery strategy. SKU count is the number one predictor for warehouse productivity with manual processes. Also, it is the number one predictor for cost escalation when planning automated systems. You can build highly productive manual and light-weight automated systems with a low SKU count. You cannot do it with a high SKU count. Aldi and Lidl with their very low SKU count could have the most efficient online fulfillment systems in the world. Thankfully, they don’t know this and still use fax machines, because otherwise they would crush a market with many hopeful startups who want to replace them.
The assumption that an established supermarket chain can take their value proposition, which typically includes the great number of SKUs they offer, simply transfer it to the internet and with help of some magic bullet at some point can become profitable doing so, is wrong.
