Supply Chain as a Service

Joannes Vermorel

In terms of predictive optimization, most supply chains are stuck in the early 1990s¹. Larger companies have already gone through a whole series of ‘predictive’ initiatives over the last two decades. However, few of those upgrades had much impact on supply chain.

A decade ago, at Lokad, as we were starting to address the root causes of those failures, Supply Chain as a Service (SCaaS) emerged as our business model, replacing the Software as a Service (SaaS) model. We started selling “software+expert” subscriptions. The expert, namely a supply chain scientist, implements the numerical recipes that generate the decisions, while the software, namely the Lokad platform, gives the expert the infrastructure that they need to operate swiftly and reliably.

During this decade, our SCaaS practice has been a dominant factor, if not the biggest factor, in increasing the success rate of our supply chain initiatives. Yet, objections are frequently raised against the very idea of SCaaS.

We won’t externalize our supply chain competency. This objection implies that there are strategic in-house supply chain competencies to be preserved. This might be the case, but more often than not, this competency does not qualify as “strategic”. Most companies, large ones included, don’t even achieve a score of 10 on our 5min supply chain performance test. Worse, fat initiatives like S&OP, tend to steadily decrease the actual supply chain competency by further fragmenting the decision-making processes.

On the contrary, SCaaS paves the way for the emergence of a true strategic supply chain competency in the company. It starts by robotizing the decision-making processes. Indeed, without automation, supply chain teams can barely afford to think strategically. All the team’s energy is poured into firefighting supply chain edge cases. On the contrary, with SCaaS in place, several clients told us it was the first time in their history that they could take the time to work on hard problems such as cannibalizations or MOQ optimization.

We will do it through easy tools. This objection takes the supply chain teams’ lack of programming skills as an axiom, and thus, rules out entire classes of tools. Supply chain-wise, there are three main types of “easy” tools: vanilla apps, low code apps and spreadsheets.

Vanilla apps feature numerous options and features to cope with all the variations found in supply chain. The app feels easy at first: using the app is merely a matter of configuration and then the workflow takes over. No programming involved. However, in practice, supply chain situations invariably exceed the app’s capabilities. Practitioners facing an “app” fall back to spreadsheets to get the job done.

Low code apps promise the power of programming but without dealing with a programming language. Low code apps typically feature a visual editor of some kind. Unfortunately, the low code approach does not cope well with the complexity faced by even mundane supply chains. On a toy example featuring 2 tables and 10 fields, low code looks great. On a real-world example featuring 20 tables and 500 fields, low code is horrid. When given access to a low code app, practitioners also fallback to spreadsheets to get the job done.

Spreadsheets are, by far, the tool used by supply chain practitioners. While it does the job, there are classes of nuances that simply don’t fit in the spreadsheet paradigm, no matter if it’s Microsoft Excel or some web-based alternative. Probabilistic forecasting and stochastic optimization simply don’t belong to the realm of spreadsheets. As long as spreadsheets are involved, the SCM practice remains stuck in the 1990s era.

SCaaS is the spark it takes to make the supply chain upgrade happen. Challenging practices that have been in place for the last two or three decades is already an uphill battle. SCaaS is the opportunity to fight this battle with veterans who have already been there and done that in other companies.

We will do it with our own data science team. Back in the early 2000s, the objection was phrased as we will do it with our own data mining team. Data mining is dead, long live data science. However, most companies forget the lessons of their failed data mining initiatives from 20 years ago: technology was almost never the root cause of failure, an ivory tower was the problem.

As far as supply chain is concerned, hiring data scientists is almost invariably setting up the initiative for slow and costly failure. Data scientists are typically young engineers who have received some training in a list of open source frameworks and/or languages. As a result, the typical data scientist, much like his data miner predecessor, is looking at the world through technical lenses. A data science team will generate an ongoing stream of “solutions looking for problems”. Talks will be given, demos will be made. Supply chain practitioners will politely congratulate the data science team, and make sure that none of its “solutions” ever gets within close range of actual production. In this regard, practitioners are making the correct judgement call.

SCaaS providers cannot afford to be decorative. Most companies struggle with firing talent, like data scientists, even if those people don’t contribute to the company. However, most companies have no qualm in terminating a third-party service provider that doesn’t deliver enough. SCaaS providers are survivors who manage to prove their ongoing value over and over.

As a SCaaS provider, Lokad rarely hires pure data scientists profiles for its “supply chain scientist” roles. Instead, we favor engineers who are willing to become first and foremost supply chain experts. Statistical models are a means, not the end. Data scientists too frequently lean on pushing numerical models to their limits. Supply chain scientists aren’t trying to get a paper published, they want to get the job done with the minimal amount of fuss. In practice, it makes all the difference between a production-grade solution, and a fancy prototype that never makes it to production.