Supply chain resilience requires bandwidth

Joannes Vermorel

The last couple of years haven’t been kind to supply chains. In fact, the only thing that hasn’t been in short supply appears to be forces of disruption: lockdowns, wars, inflation, etc. As a result, a newfound interest in ‘resilient’ supply chains has emerged.  Naturally, the usual suspects - consultants, professors, and software vendors (including yours truly) – have been busy figuring out ‘solutions’ that would, at the very least, mitigate the extent of the impact of those disruptions, and would, at best, eliminate classes of disruptions altogether. However, my casual observations indicate that those ‘solutions’, no matter their perceived merit, are usually nothing more than wishful thinking.

Indeed, during the last decade, I have observed that most supply chain directors, and their teams, are already buried under micro-crises, even during periods mostly devoid of any kind of large-scale disruptions. Thus, most supply chain divisions don’t have the luxury to even think about crisis-management (or any kind of grand strategic plan): they are entirely committed to putting out a never-ending stream of fires.

A few decades ago, the software industry coined a term to refer to this very problem: lacking bandwidth, when management cannot even afford to think about yet another issue because their attention is spread too thin across too many issues already. What makes the concept of bandwidth so relevant to software and supply chain alike is that, in both situations, the usual corporate response to an excessive workload – i.e., put more people on the case – does not work. This is the essence of Brooks’ Law: adding additional manpower to a software project that is already behind schedule serves to merely delay it even further. In the software industry, one that boasts some of the most profitable companies that have ever operated in free markets, this bandwidth problem is most vexing. While the company might be profitable enough to double the workforce and its management, it wouldn’t make a dent in the problem ¹. 

Perhaps surprisingly (or maybe not), the root cause of this endless stream of supply chain micro-crises is almost exclusively software. Counterintuitively, it’s not the war in Ukraine or the possibility of having another one in Asia that drains the bandwidth of the supply chain division, but typically issues that would be best qualified as “entirely anecdotal”, such as the WMS being out of sync with the ERP (…again); or politicking with IT to get an extra database custom field for “reserved” stocks ²; or chasing some wholly unreasonable forecasts as delivered by the S&OP process. 

In a rogues’ gallery of bandwidth-sapping software, analytical products are, by far, the worst offenders. These tools – especially planning ones - frequently require not only hefty manpower to operate, they also generate their own mini bureaucracies. As a result, the management of the supply chain troubleshoots software-related issues, in addition to troubleshooting process-related ones generated by the bureaucracy itself. This process becomes frustratingly reflexive and squanders ever more bandwidth.

Lokad, being part of this analytical software ecosystem, is not immune to this problem. Years ago, we did, however, develop the antidote through the fourth point of our manifesto ³: Being in control requires automation of every mundane task. We realized that there was a careful balancing act to be struck between management and optimization. For example, if generating the daily purchase/production orders consumes the supply chain division’s entire bandwidth budget, that leaves nothing in the coffers for improvement (in terms of resilience or anything else).

On the contrary, if all the mundane tasks are entirely automated, this frees up a massive amount of bandwidth from the supply chain organization. This process, however, takes time. It is not an accident that when Lokad starts working for a client, it usually takes us about a year before we can start focusing directly on any subject that would be considered as strategic (such as resilience). Lokad not only has to get to production (which takes about 6 months), but the organization also must learn to relinquish control of all the processes that have now been automated (requiring another 6 months, more in larger organizations).

By automating away the mundane decisions, however, supply chain teams regain something that they usually lost decades ago when their organization went digital: the ability to pick their battles. This is probably the single most important benefit of automation, dwarfing the productivity savings. I am not saying that transitioning to a digital supply chain in the 1980s and 1990s, operated through a collection of ERPs, MRPs, and APSs, wasn’t the right move. Simply put, while this digital path was necessary, it came with severe downsides: (free market) companies have never been so entrenched in their own applicative landscape, where migrations and upgrades are typically measured in years. Many supply chains have been engulfed in their “digital firefighting” for so long that few employees remember starting the workday without an endless stream of alerts, exceptions, and issues. This is to say nothing of the correspondingly endless stream of meetings to address said alerts, exceptions, and issues. All these processes have bottom line costs in terms of bandwidth, and the mental tab is always running.

By way of anecdotal evidence, let’s consider that in less than 5 years (1903 to 1908), Henry Ford went from nothing to the Model T. Ford revolutionized industrial production, introducing more than a dozen models in the process (Model A, Model B, Model C, etc.), all while juggling an ever-shifting supply and demand. Ford didn’t have it easy either: the Panic of 1907 was one of the greatest and most severe financial crises of all time. Nowadays, given 5 years of “business as usual”, many (most?) companies can’t even finalize the upgrade of their ERP.

Thus, to become resilient, a supply chain must free up bandwidth. Resilience is a difficult, elusive subject, thus, a lot of bandwidth is needed, making it all the more challenging. Worse, the paucity of disposable bandwidth in supply chain, as the software industry discovered decades ago, can’t simply be fixed by throwing around vast sums of money ⁴. Rather, the best path to resilience is an indirect one: ruthlessly automate mundane decisions to gain the freedom to think and execute the strategic ones, resilience included.