One of the surest paths to failure in supply chain management is the “learn to walk before you run” mindset. This analogy is misleading as it outlines progress as some kind of preordained journey. This mindset can be referred to as Incrementalism, and for many large companies operating equivalently large supply chains, incrementalism is the one of the biggest driving forces preventing any improvement from happening, sometimes for periods as long as a decade.
Plain inaction should not be confused with incrementalism, as it is much more benign. Indeed, unlike inaction, incrementalism requires hefty ongoing investments of resources. Furthermore, incrementalism is a massive source of distraction for upper management, while inaction, on the contrary, gives leeway to deal with other pressing matters.
Incrementalism usually starts with the intent of improving a performance indicator: improving the forecasting accuracy, improving the service level, reducing the stock level, reducing the lead time, etc. The quantitative nature of the indicator grounds the initiative as a “rational” - scientific even - undertaking. In order to improve the performance indicator, a piece of the organization is identified as the “bottleneck”: the forecasting engine, the S&OP process, the planning software, etc. Then, a corporate initiative is formed to improve this piece.
Corporate-wise, the default acceptance level for incrementalism is high. No feathers are ruffled. The power structures within the organization are not touched. The mission stays the same. Nobody gets marginalized or superseded. The bar is merely set a notch higher for one, or a tiny few, performance indicators. This could add pressure on a few teams if the goal wasn’t trivially achievable anyway by compromising on something else somewhere else. For example, raising service levels is trivial as long as you don’t pay attention to the ongoing generation of dead stocks; reducing the supplier lead times is also trivial as long as you don’t pay attention to delayed price increases. Teams instinctively know this as well, hence, their lack of resistance.
Incrementalism is fueled by corporate silos. Every silo comes with its own cohort of experts who only look at the problem from the very angle dictated by the silo itself:
- The forecasting team thinks in terms of forecasting accuracy.
- The purchasing team thinks in terms of purchase price.
- The replenishment team thinks in terms of service levels.
- The pricing team thinks in terms of price elasticity.
Yet, in supply chain, incrementalism nearly always invariably fails. The Blockbuster replenishment teams most likely congratulated themselves for their ever-improving service levels until the very end, when Netflix drove them out of business entirely. More generally, incrementalism fails whenever systems are involved. Indeed, systems are more than the sum of their parts, and as a consequence, what is good for a part of the system is not what is good for the system as a whole.
An automotive analogy is enlightening: a more powerful engine doesn’t make a car better. Such an engine adds weight, and thus, it increases the fuel consumption, it increases the fatigue for many mechanical parts, it lowers the brake efficiency, etc. The best car design is a careful balance between the parts, not a coalition of “better” parts1.
A supply chain suffers from the exact same sort of problems. Higher service levels imply more capital expenditure, more waste, more dead stocks, less inventory turns, reduced agility, etc. However, as supply chain systems tend to be relatively opaque, the downsides associated with a supposed improvement may be hard to see. Yet not seeing the downsides won’t protect the company from incurring the actual financial penalty that comes with the downsides.
- The reduced percentage of error does not translate into less dollars of error.
- The forecasts may be less numerically stable, yielding more operational chaos.
- The software may be less reliable, causing production downtimes.
- The software might be less secure, leading to cybersecurity accidents.
- The software might be more opaque, vastly increasing the maintenance costs.
More generally, incrementalism fails in supply chains because it emphasizes to do “more of the same”. Unfortunately, for most companies, the supply chain game has been played for decades. Whatever low hanging fruits may have existed, those have been picked decades ago. Whatever “linear” improvements remain, those tend to be difficult to achieve, usually well beyond the point of negative net returns.
Conversely, incrementalism dismisses tough problems, no matter how important they are:
- Uncertainty about the future is irreducible.
- Data analytics antagonize the design of the database that runs them.
- The enterprise software vendor is incentivized for failure.
- Cannibalizations and substitutions are all over the place.
For most truly difficult problems, the initial baseline is either inexistent or wrong.
The notion of lead time forecast remains wholly absent from classic forecasting systems2. As a result, as lead times are not approached statistically, there is nothing to improve upon in the system. As bizarre as it may be, nowadays, most forecasting systems in large companies, while being complex and very expensive, ignore the lead times. Lead time forecasts are the archetype of the inexistent baseline.
Conversely, investing in ad hoc software developments to cope with a software vendor’s design defects is a self-defeating move. The improvements delivered on top of the bad vendor are only going to entrench the vendor within the company. The larger the organization, the more difficult it becomes to deal with sunken costs. Extravagant spendings on defective solutions occur routinely3 as illustrations of wrong baselines.
The one major difficulty to tackle non-incremental improvements is not of a technical nature, but of a social one. As it is better to be approximately correct than exactly wrong, it is usually technically straightforward to improve, at least a little, a system by making it slightly less dysfunctional at tackling something that was wholefully disregarded so far.
Non-incremental improvements in supply chain are a tough sell, because there is nobody to sell them to. Let’s take the example of pricing and planning. It is obvious that changing the price changes the demand. If the demand changes, then planning (e.g. production) has to change as well. Yet, few companies, and even fewer software vendors, are trying to tackle this basic problem, namely the entanglement of pricing and planning. Indeed, a pricing solution (resp. planning solution), even an internal one, can be sold to the pricing team (resp. to the planning team). However, a pricing+planning solution might only be sold to the CEO - or maybe a member of the board. Unfortunately, if both a planning team and a pricing team are in place, then, by definition, those topics should not concern the CEO directly, and concerns about pricing+planning get forwarded to the relevant teams, to be hastily discarded as neither the responsibility of the pricing team nor being the one of the planning team.
Sometimes it’s possible to improve a part without degrading anything else. Those improvements are highly desirable because, when they happen, the system as a whole gets a “free lunch”. For example, the 2021 paper automemcpy: A framework for automatic generation of fundamental memory operations achieves exactly this: the entire fleet of computers operated by Google got a 1% performance improvement through the re-implementation of 3 memory manipulation primitives. Unfortunately, such self-contained improvements are very difficult to achieve. ↩︎
Rule-based systems to cope with lead times do not count, in my book, as doing anything of statistical significance as far as the forecasting of lead times is concerned. ↩︎
Between 2011 and 2018, Lidl famously wasted 500M€ trying to fix SAP’s inventory replenishment solution. Such outcomes are frequent, yet they are rarely disclosed to the general public (though Lidl’s adventure made it to the mainstream news due to its magnitude), as they are an equal source of embarrassment for both the vendor and the client’s management team. ↩︎