00:22 Introduction
02:40 Why a product? Because capitalism
08:18 What should the product do?
10:05 Software diseconomies of scale
12:50 Let’s buy a SCO product off the shelf
21:58 SCM vs SCO
25:58 Interlude
28:21 SCO is not your average software product
33:26 Software Ingredients for SCO
42:49 Yet spreadsheets are not the endgame
46:51 Python is not the endgame either
58:52 SC is not a division of IT
01:03:19 In conclusion, two challenges to overcome
01:07:04 Upcoming lecture and audience questions
Description
The goal of a Quantitative Supply Chain initiative is either to deliver or to improve a software application that robotizes a scope of routine decisions (e.g. inventory replenishments, price updates). The application is viewed as a product to be engineered. The supply chain theory is there to help us deliver an application that steers the company toward supply chain performance, while being compatible with all the constraints that the production entails.
Full transcript
Hi everybody, thank you very much for joining this series of supply chain lectures. I am Joannes Vermorel, and I will be presenting “Product-oriented Delivery for Supply Chain Optimization.”
So first, when I’m speaking about a product, I mean a software product. For those of you who have ever had the privilege of investigating what goes under the hood of a modern enterprise piece of software, it might be quite an experience.
For those familiar with the work of H.P. Lovecraft, there are some troubling similarities. Lovecraft has produced a series of novels, and one of the recurrent themes is the idea of forbidden knowledge. It’s not that the universe cannot be known, it can. It’s just that the only thing preserving mankind is ignorance. Ignorance is not a problem; it’s the very thing that protects us from a universe too terrifying for our minds to tolerate. This idea has been recycled into many modern games, especially role-playing games, where in addition to the traditional health points, characters have sanity points. If you do certain things that damage your sanity, you lose sanity points. The challenge with enterprise software is to be able to create it while preserving your sanity, which is one of the requirements to add value for the company. So, let’s proceed.
Why a product, and in particular, a software product? Let’s have a close look at how supply chains operate traditionally. Traditionally, there were many people on the ground moving things around, shuffling packages, driving vehicles, and doing all the manual labor. There were also many people involved in production, as well as in stores. What has gradually been happening over the last couple of decades is that the number of people with blue-collar jobs has been declining steadily. Nowadays, production-wise, things are vastly automated. There are still a few industries, like textiles, where it’s difficult to automate everything, which is why those industries have moved to where manpower is the cheapest. The reality is that raw manpower requirements have been lowered tremendously.
You end up with a fairly odd situation where, if you look ahead with autonomous vehicles looming, many companies will have more white-collar workers dealing with Excel spreadsheets to run the supply chain than they will have people with blue collars on the ground to do the manual labor operations. This is what I’m referring to when I say clerical work.
Another peculiar aspect is that supply chains have been digitalized for many companies for at least two decades. It’s not like we are going to introduce software into supply chains; supply chains are already driven and operated via software. But when we look at the role of humans in these software systems, humans are literally used as human co-processors in your average supply chain system. There are specific types of operations that the regular CPU, the processor in the machine, cannot do, and so the whole task is delegated to a human. In conjunction with simplistic numerical recipes, such as ABC analysis, min-max inventory, and similar recipes, humans end up spending their days firefighting. They’re always dealing with exceptions and conditions that do not fit the standard framework.
From a cost perspective, this is all operational expenditure (OpEx). You need to pay an army of clerks every single day to handle all the mundane decisions your company needs to make daily. These include what to buy, where to place the inventory, whether to move one unit from one warehouse to a store, and many other routine decisions. Humans are taking these decisions and firefighting to cope with the inadequacies of the automatic decisions generated naively by the system.
My proposition for you today is that we want to move from OpEx to capital expenditure (CapEx). That’s the whole point of this product-oriented delivery. We want to build an asset, and why? Because it’s capitalistic. If you look at the top 100 most profitable companies in the world nowadays, half of them, in terms of profit, are software companies. They represent the essence of ultra-capitalistic companies, where you have an investment upfront, and then you end up with a device or artifact that generates added value with minimal marginal investment.
Going back to the topic of my previous lecture, we need robotization to put management back in control. Automation and humans should work together; humans should not be there to deal with the inadequacies of dumb inventory policies like min-max. Instead, they should be there to add value, improve numerical recipes, and act as strategists. There was an old-time IBM motto that stated, “Machines should work; people should think.” That’s the sort of thinking that goes into this presentation. We want to turn supply chain into a capitalistic asset, and to do that, we need to turn supply chain into a machine that delivers a software product.
What does this product actually do? It turns out that it does something fairly simple: it makes decisions. Not arbitrary, open-ended decisions, but the mundane, routine decisions like what to produce, how many units to buy from a supplier, and how many units to move from one location to another. At first glance, it may seem like there are many decisions involved in supply chain management. However, when you survey the tasks, even the most complicated supply chains only require a few dozen types of decisions to be made every single day. This is not overwhelming, and it is quite reasonable in terms of the sheer number of features. Interestingly, these decisions are largely exclusive, so there are limits to what can be done using a divide-and-conquer approach. Once you’ve decided to purchase 100 units from a supplier, you can’t have another subsystem deciding to buy 200 units instead. At some point, you have to make up your mind about how many units to buy and move from one location to another. These decisions are discrete, limited in scope, and largely exclusive. What we want is a piece of software that generates order decisions in a completely automated fashion every single day.
One thing that I believe is often poorly understood about software is the notion of diseconomies of scale. While economies of scale are familiar to most people, the opposite is true in software, where adding a quarter more features can double the cost. This concept explains why small startups can rival large companies – because they focus on a smaller fraction of features, the cost to bring their product to market can be significantly less than that of a large company.
With the idea of diseconomies of scale in mind, we must decide whether to build, buy, or take another approach for our supply chain optimization product. If we choose to buy the product from a vendor, we must consider the features the software vendor will have to deliver to serve the market.
So, let’s consider buying a supply chain optimization product off-the-shelf. On these slides, I provide a review of just a tiny fraction of all the things we need to address. I have first-hand experience with this, as when I started Lokad in 2008, I began with a small software product oriented more towards forecasting than supply chain optimization. As I started working with clients, I realized that there were so many features and capabilities that I didn’t have, and as I moved on to other clients, I found even more missing capabilities. It seemed to be a never-ending process of discovering new requirements.
Let’s have a look at just the core features. First, we have companies that are B2C or B2B, which exhibit completely different patterns in supply chain management. For example, B2B companies typically have fewer clients, but those clients order much larger quantities. This creates different types of risks, such as the risk of losing a single client that accounts for a significant portion of the company’s turnover. Then there are more complex business models like B2B2C or B2B2B.
Consider the various types of sites that need to be covered, such as stores, warehouses, and production facilities. Each type of site comes with its own set of challenges. Stores, for instance, are prone to inventory inaccuracies, even with RFID technology, simply because customers can move products around. Warehouses and production sites, such as farms or mining operations, come with their own specific problems and uncertainties in production yield.
Supply chain networks can have different levels, or echelons, ranging from single-echelon to multi-echelon systems. The complexity of managing the supply chain increases significantly as the number of echelons grows. Network topology is another important aspect to consider. A tree topology is the classical forward supply chain path, where a few production sites dispatch to several warehouses, which in turn distribute to numerous stores. However, other topologies, such as directed acyclic graphs (DAGs), can exist, where one store can be served by multiple warehouses.
So, basically, it’s not just a tree in terms of graphs, it can reconnect, although it’s still only forward. But the same thing can occur with a Directed Acyclic Graph (DAG) when you have multiple suppliers. You can even have loops in your supply chain graph that happens whenever repairs are involved. For example, in the mining industry or the aviation industry, there are tons of repair loops with repairable equipment.
Now, the inventory itself doesn’t just have one nature; it varies a lot. You can’t just say, “Oh, I have this idea that I have SKUs and this is it.” No, not quite, because first, you have raw materials that are literally measured in quantities like grams, kilograms, or volume. Then, you have the units that are the nice, clean units, which are mostly prevalent. But then you can also have lots of inventory that happens very frequently, for example, in pharma or in the food business, where the lot comes with specific expiration dates. Then you can even have completely serialized inventory, where every single unit has its own serial number. In terms of supply chain optimization, that completely changes the game, so it’s a completely different problem when you’re looking at each one of those things.
Then, obviously, you have all the problems of marketplaces. At Lokad, we have clients in literally every single possible situation. We have clients where they sell on a third-party marketplace, they can have their own marketplace, or they can have both. It can be something that is secondary so that they can use it to liquidate the things they didn’t sell. There are many situations.
Now, just for example, think for a moment about what an order is. You have the spot order, where basically you just buy something right off the counter, and it’s yours. But then you can also have an order that says, “I’m buying it, but I don’t want this thing to be delivered immediately; I want it to be delivered one month from now.” Obviously, from a supply chain optimization perspective, it’s a completely different game because if you know in advance that you will have to deliver a certain quantity of stuff at a specific date, you don’t want to forecast that, so it’s a completely different thing.
And then you have a configured order, and that’s, for example, when you buy a computer online and you can choose how much memory, how much hard drive, what type of operating system, what language will be set up for your computer, and what your keyboard will be, among other things. So, you can have a massive configurator, and that changes the landscape again. This also happens for things like bikes or cars and completely changes the landscape when you have these sorts of things because it gives you options and ways to look at the supply chain optimization problem that are completely different.
Even for prices, you can have the per-unit price that is flat, super simple, and super linear, but it’s not the only thing. You can have price breaks, for example, if you buy ten units, then you get a discount. Or you can have loyalty programs where some clients with a loyalty card can get a discount, but only on certain types of products or only depending on certain conditions. And then you can even have, in B2B, very frequent things that are negotiated, so it’s literally a transaction where a lot of things will be sold, but you have a regular catalog price. However, a vendor can give a rebate to a client because they are important, and that’s just the way it’s done. Bottom line, I have barely been speaking for minutes now, and I’ve only covered the core. I haven’t even started to touch the must-have things. So just pause for a moment and try to think about what an off-the-shelf enterprise software product that is supposed to deliver supply chain optimization is going to look like. The number of features to cover is just literally insane, and when you try to think about how to put all those things together into a monolith, you’re literally losing your mind. We are back to this idea that it’s not that the universe cannot be known, it’s just that if you’re exposed to the naked truth of the universe, you lose your sanity.
So, we have a major problem, and here we have to differentiate supply chain management from supply chain optimization. That’s a distinction I already introduced in one of my previous lectures. There is a big confusion going on between the management side and the optimization side. Management is about bookkeeping, supporting workflows, and mostly data entry processes. If you want to represent all of the things I’ve just described, it’s a lot of ground to cover, but it’s doable. An “obese” ERP can do that. Yes, you will end up with 10,000 tables, it’s going to be pretty ugly, but it’s possible. But make no mistake, the ERP (which should be named ERM, Enterprise Resource Management) is not going to do much. It’s merely going to keep track of those things. So you will have tons of entities – MOQs, check; price breaks, check; stores, check; warehouses, check – but you don’t need to have any degree of intelligence. It’s just about mundane digital counterparts to reflect the data, making it possible to enter the data into the system, and that’s it.
It’s possible because, here, we can cheat a little bit about this rule of “one-quarter more features double the cost.” There is something I didn’t really say about it: it works if you keep your features completely segregated. As long as the features do not interact with each other, it’s okay; you’re not subject to this curse of diseconomies of scale. From a data entry perspective, there is no problem. You don’t need to have the user interface that lets you drive the MOQs connected with whatever is letting you add an extra store to the network. Those two things can be completely segregated.
However, when it comes to supply chain optimization, the same is not true. If you have MOQs, they will have profound implications on how frequently you’re ordering, how frequently you will be delivering things from your warehouse to your stores. There are plenty of far-reaching consequences. You can’t segregate things because, ultimately, your supply chain is just one system where everything has an influence on everything. So from a supply chain optimization perspective, you literally have the problem that all those things have to be plugged in if you want to deliver optimization, and that’s where things fall apart.
On the management side, you can potentially end up with a product. However, for supply chain optimization, the answer is that you can’t. I mean, you can pretend to, but literally, you can’t. Even at Lokad, which started not as a supply predictive company that specializes in predictive supply chain optimization, but rather as forecasting as a service. If you go back to the Lokad blog in 2008, I initially started with time series forecasting, which was severely misguided. Nonetheless, that’s how I got started. Even for time series forecasting, which is a tiny subset of the whole problem, it’s unmanageable. That’s my conclusion after being in this business for over 12 years.
If we have to go back to the specific world of producing software, it’s something very unique. Unless you’ve been trained as a software engineer yourself and are familiar with the way large, successful software companies produce software, chances are that you know very little about it. It turns out that it’s a very specific world with plenty of vastly counter-intuitive aspects. Traditional companies, especially those with a classical mechanical engineering mindset or marketing mindset, struggle immensely to wrap their heads around how software works at all.
We will be covering these aspects in greater detail in future lectures, but there is one book that I really like, produced by Joel Spolsky, an ex-Microsoft employee who worked on early teams of Microsoft Excel. He is also the co-founder of Stack Overflow and Trello. In 2004, when I was only a student, I read his book and blog. The book is titled “Joel on Software,” and it humorously gives you a grasp of what running a successful software business looks like. It’s very different from what most people outside this industry expect. I will be adding the details of this book in the video description.
But let’s keep in mind that supply chain optimization is not your average software product. Usually, when you deal with an average software product – I mean, yes, you have some adversarial behaviors, depending on the type of software product. If you’re dealing with a social network, you can have plenty of people posting hateful content, which is a whole different game. However, when dealing with classical enterprise software, like Microsoft Word or Excel, it’s a product where you want to have the right design, but there is no emergency whatsoever. In the case of traditional software products, it’s okay to spend years refining your design and product. It’s a long-term investment, and you have to look decades ahead. There’s no reason to rush anything in terms of development. However, supply chain optimization doesn’t work like that. You don’t get the choice, as things happen all the time, and the terrain is very rugged.
You can have extreme situations like the pandemic or other problems such as ransomware, which can shut down half of your network. You need to make smart decisions to make the most of the capacities you still have at your disposal. You may face fleet grounding due to tragic incidents, political moves like tariffs that disrupt your strategy, or natural disasters like tsunamis or fires and heatwaves, such as those in California or Australia. These events happen, and when they do, you need to be able to react literally in hours.
You have your software product, but you need to bring change, and you want to bring programmatic change. Remember, if you’re in the mindset of delivering a software asset, you have a small team driving the software that, in turn, drives your supply chain. You don’t have an army of clerks doing firefighting all day long. Even if you have an army of clerks, you need to train them, and when something completely unexpected happens, you end up with an army that hasn’t been trained for that specific situation. In my experience, the more people you have to manage, the longer it takes to achieve anything.
Just a few days ago, a cargo ship lost over 1,800 containers due to bad weather conditions. These things just happen, and you cannot hope to eliminate them. Supply chain is not like manufacturing, where you may have a production site with everything tightly controlled. By definition, supply chains happen in a world at large, where most of the time, you have no control over the elements. There are so many forces beyond your control that you need to be able to cope with surprising events. You already know that surprises will happen, so you need to be prepared. Being prepared is not about having everything carefully mapped out; it’s about having a system where you can react in hours if needed. That’s the essence of what you can do to realistically approach the problem.
Now, what do we need in terms of software ingredients for supply chain optimization? First, we need versatile data storage to represent all the diverse types of data sources. There are so many things we want to represent, so we want something very versatile in this regard, with a lot of structure and variety.
Second, you want programmable logic. I’m going back to this idea: if you don’t have programmable logic, how do you cope with all these problems? How do you glue all these things together? You cannot buy a product off the shelf that will have everything pre-programmed for you; that doesn’t work.
Next, you need versatile user interfaces because the way you want to look at your problems will vary enormously from one situation to the next. The KPIs will be completely different from one company to the next, so you need a versatile user interface where you can present the numbers in any way you see fit; otherwise, it’s going to be a big limitation.
You also want collaborative capabilities because supply chain is teamwork by definition. There are many people involved, and it’s distributed, so collaborative capabilities need to be at the core.
Lastly, and perhaps more contentiously, you want programmable capabilities that are accessible to people who aren’t trained software engineers. This is important for several reasons. Firstly, there aren’t many trained software engineers in the job market, so it’s very competitive to hire them. Secondly, it takes so much effort and dedication to become a talented software engineer that it’s challenging to be a supply chain specialist simultaneously.
It’s not very common to find people who have dual competencies in both fields. The same would apply if you were looking for someone who is both a programmer and a lawyer, or a programmer and a doctor. Yes, you’ll find some people with these skill sets, but can you do it at scale or reliably hire more of them every year if you’re a large company? From my experience running Lokad for a decade, it just doesn’t work.
You want something programmable, but you don’t need to be a professionally trained software engineer to deal with the programming. Remember, you need to have someone with supply chain competency because you need to be able to cope within hours to apply the programming corrections to your system without opening a ticket and passing it to IT. If you have to do it that way, then it takes weeks to address issues, not hours. So, what kind of software can actually solve the problem?
Well, Excel can. It’s not pretty, and it might not feel like the pinnacle of modern software, but it does the trick. It ticks all the boxes.
Versatile data storage? Yes, to some extent, you can put a lot of data of any kind in Excel. Programmable logic? Absolutely, Excel is completely programmable. Versatile user interface? Yes, you can have bar charts, line charts, and plenty of ways to present data. In terms of user interfaces, it’s very versatile. It might not be the most polished, but in terms of versatility, it can do a lot.
In terms of collaborative capabilities, it’s a bit crude. You have some versions of Excel that are online, which are marginally better, but fundamentally, you can share your spreadsheets. The problem with the lack of collaborative features is not that it’s a desktop app. The problem is the mindset that goes behind spreadsheets, which is not suitable for intense collaborative work. Usually, if you have a colleague who created a very complex sheet, it’s easier to recreate the sheet rather than trying to figure out what they did. So, the problem with the lack of collaborative features is the mindset that comes with spreadsheets, which inherently has strong limits for collaboration.
However, Excel is completely accessible to non-developers, and there is even Visual Basic for Applications for more complicated tasks. In terms of ingredients, Excel ticks all the right boxes, which, I believe, explains to a large extent the success it has operationally in most supply chains.
In my experience, the majority of the world’s supply chains, from the smallest companies to the largest and from those who have never invested a cent in enterprise software to those that have invested millions of dollars into complicated enterprise software for supply chain optimization, are driven by Excel. There are very few exceptions. Sometimes, people use Excel to revise min-max settings in other software, but the maintenance of these settings is delegated to those working with Excel.
Excel is driving the world of supply chain today, and I believe it’s not an accident. At its core, spreadsheets fundamentally address many of the right issues. Many other options are presented as superior but fail by default if you can’t program. If you can’t program, that means when you face a major problem or emergency, you’re out of luck. People will fall back to Excel spreadsheets in situations like lacking a versatile user interface, or when a solution is not accessible to non-developers. If it’s only an IT team that can bring results, people may initially open tickets and wait patiently, but within three months, everyone will likely fall back to using Excel spreadsheets because it’s faster. Excel is not the end game, but whatever we bring as a superior replacement, it will need to tick the right boxes.
How can we make something better? In terms of versatile data storage, Excel is good but not very scalable. Processing millions of lines becomes an issue, even with modern Excel versions that can handle a million lines. Performance issues arise quickly when operating at scale. Programmable logic in Excel is possible, but it’s very fragile and brittle. If you inadvertently introduce a mistake or bug in your spreadsheet, debugging it and pinpointing the source of the problem becomes a nightmare. The logic is endlessly duplicated, resulting in thousands of copies of the same logic, making it difficult to identify and fix errors.
The user interface is not ideal, as it’s not entirely web-based and the data is always entangled with the interface. Collaborative capabilities exist, but they’re messy. Collaboration should happen at the level of programmable logic. Many supply chain optimization vendors offer collaboration on the outputs, such as tweaking forecasts manually and allowing multiple people to participate. However, this is the wrong approach. Collaborations need to happen, but they need to occur at the logical level, at the level of programmable logic. Excel is very accessible to non-developers, but when you want to do anything slightly more complicated, it becomes challenging. In supply chain management, we want to deal with all possible futures, which means working with probabilistic forecasts, random variables, and addressing uncertainty. While this is possible in Excel, it is quite complicated. Excel is easy for simple tasks, but for more complex situations, you need to become an Excel wizard.
Maintainability matters, as you want to build an asset with growing value over time. With spreadsheets, it’s difficult to achieve this, and it’s hard to create something truly accurate, at least in the sense of a software product.
The buzzwords of the day are AI and Python, with all the trends and hype surrounding data science. However, for supply chain management, I believe Python is inferior to Excel.
Don’t get me wrong; I love Python, and I think it’s a brilliant language. I even teach it to my 10-year-old daughter. However, there are several reasons why Python is not the best choice for supply chain management. First, it requires software engineers. Although Python is one of the most accessible programming languages, when you want to do something more complex, you need a software engineering team, which creates challenges when you need people who are both supply chain experts and software engineers.
Python has nice features, but the way dependencies are handled is quite complex, and package management is poor. Packages are building blocks that provide extra capabilities, and when you say you want to use Python, it’s not just the language but also the entire ecosystem of packages that you’re interested in, such as NumPy, Pandas, TensorFlow, and SciPy – all third-party dependencies or software libraries. Package management has been poor for over a decade, and while it’s improving, the progress is slow. There are many aspects of the system’s design that make it difficult to enhance.
Performance is also poor, mostly by design. Compute performance refers to the quality of the job done by Python to exploit the raw computing power available from your computer. Surprisingly, Microsoft Excel does a much better job in this regard. Excel is highly optimized, leveraging multi-CPU, multi-core systems, and running natively compiled logic. Microsoft has invested a lot in making Excel extremely fast.
In contrast, Python has inherent problems that often result in performance being 100 times slower than what your machine could theoretically deliver. While it may seem acceptable to some, given the power of modern computers, it’s not ideal for companies with transaction volumes exceeding $50 million. You want something that delivers good performance out of the box.
The idea of using a third-party library like NumPy to address Python’s lack of performance only adds complexity. You may be solving the performance problem, but you’re creating a new issue by introducing the added complexity of NumPy, which you need to deal with and maintain over time. This also raises the bar on the software engineering side of the problem.
When attempting to implement Python solutions for real supply chain management, various issues arise, such as null reference exceptions, out-of-memory exceptions, and lengthy computation times. You may find yourself waiting for 20 minutes for a computation to complete, unsure if it will ever finish or if you should just kill the process and restart. I just don’t know, so you want things where you have a very, very good idea of how much time it’s going to take to complete. By the way, if I go back to Excel, nowadays when there is an operation that takes a bit of time to complete, Excel will give you a fairly reliable indicator, a progress bar on how much time it’s going to take. So again, you want, and that’s part of what I refer to as the production readiness. You want to have something that is because, again, the software that you’re producing is most likely going to run unattended, during the night or during the nightly batch, for example. You want something that does not require a data scientist to babysit the whole thing.
And again, if you have the problem with data scientists, then you need the third competency: supply chain expert, software engineering expert, and now a data scientist expert. It’s possible to have all those three qualities in one person, but good luck with hiring more than one person a year, even if you’re a large company that has all those skills. It’s just super rare.
So we want to have something that will improve. By the way, the first thing that we want to improve is defense in depth. Ransomwares are on the rise, and whenever you put something programmable in your organization, you expose yourself to ransomware. Because suddenly, when you have a program, the program on the machine can do tons of things, including hijack the very machine it’s running on. I know that there are tons of ways to mitigate the problems; you can sandbox things, you can restrict, you can have limited rights, and there are tons of ways to limit the problems. Nonetheless, whenever you have something like a generic general-purpose programming language, your attack surface area, that’s a technical term, is absolutely gigantic.
So basically, whenever you’re plugging in code like that, you expose yourself massively in terms of security problems. And remember, the way it’s typically done in a regular software engineering business is that the code is peer-reviewed. So you review the code, you have a code review process, somebody produces the code, and there is a colleague that is going to review the code to make sure that there are no shenanigans in the code. But if I go back to the fact that software has to be rugged, you have to be able to respond within hours. You will not be able, from a supply chain optimization perspective, to have a code review process in place. It’s just not compatible with the delays and the emergencies that you will face.
So, you need to have something that gives you defense in depth by design. Then you want to have something with transparent performance, where yes, things can take time, but you need to be in control. You need to know in advance how much time it’s going to take. If you don’t have that, then you expose yourself to tons of very stupid problems, like you had a two-hour window to deliver results, and you’re late. And you know what? The trucks have already left. It’s too late. So you need to have something where it’s taken care of.
And the same thing goes for transparent upgrades. That’s the beauty of Excel. You don’t have to think about the maintenance of Excel. Microsoft signed a pact in blood decades ago, which was: if you’ve produced an Excel spreadsheet, whatever the next version of Excel that will arrive in the market, it will be able to support your spreadsheets. And the most incredible thing is that if you look at Excel nowadays, it supports many competing Excel formats of competitors that don’t even exist anymore. You can still read spreadsheets that were produced with Lotus Notes and these sorts of things. So Microsoft’s value proposition in terms of transparent upgrades is that the logic you’ve produced will work forever, and yes, they will keep improving Excel for decades, but you know what? It’s taken care of. That’s not something that you see when you look at the transition from Python 2 to Python 3; it was a nightmare, and it took a decade. So, Python is great for many things, but just imagine that those upgrades will happen at the worst moments, where you have the worst pandemic, the worst tariff, the worst emergency, and you need things to be up and ready. You cannot afford to have a six-month downtime just because you need to take care of an upgrade. That’s not something that is compatible with supply chain optimization.
So now we need to think of what if we were to actually consider something where it could be engineered for supply chain in mind? That will be the topic of the next lecture.
Now, also, supply chain is not the division of IT. When I say a product-oriented delivery, again, it’s not that the software is just a means, not an end. You will not be selling your software for licenses or a fee like, let’s say, Microsoft is doing. In this vision that I am drawing in front of you in this lecture, IT is responsible for the core practices, the core IT practices, like what you should do or should not do in terms of security, backups, core infrastructure, your network, how to manage and synchronize everything in terms of data at the company level, and providing all the guidance and coaching.
But the idea is that supply chain needs to own the supply chain decisions. They need to own all the apparatus that generates those supply chain decisions, so that’s their core ownership. In the previous lecture, I said what defines the supply chain scientist: the supply chain scientist is someone who owns the numerical decisions produced by the code. It’s not a system that produces decisions; it’s numerical recipes that have been written down by one or many supply chain scientists, and those supply chain scientists collectively own those numerical decisions. They take ownership in that, and the responsibility of supply chain is to make sure that all the decisions in the company are consistent. If there is a promotion going on or a big marketing push, things need to be produced in time so they are ready to be served. You don’t want to end up in a catastrophic situation where you’re pushing something when you’re already in a near stock-out situation, where you spend money on a marketing push for something that you can’t even sell because you don’t have the stock or the capacity to manufacture them or to provide service on time, etc.
So, we have two divisions that have very different focuses. In my ideal vision of what the IT department should be, the IT department is not a division where you pass tickets. That’s not the way it works. The IT department is in charge of the core infrastructure. It’s the sort of thing that just works seamlessly all the time. You don’t even pay attention, just like the Wi-Fi is working. You don’t pay attention to the Wi-Fi; you only pay attention to the Wi-Fi when it’s not working. A good IT department delivers all the infrastructure so that you don’t even pay attention to them. You don’t even realize they exist because it just works, just like your emails work flawlessly, etc. That’s what good core IT is about. And then, IT is the sort of people that come to you and help you establish all those practices that give you a hand. Programmable logic is a bit hard, so sometimes, where are you going to get the coaching to get a little bit better programming-wise? Well, the answer is it should be IT. They should come not to say, “We are going to code it for you,” but rather, “We are going to coach you so that you can actually implement it yourself. We’ll help you with a few concepts, maybe help you with some things that are a bit more technical than they should be.” Sometimes, you have accidental complexity, so IT is there to support you. But fundamentally, they are not there to do the work for you. They should be mentors and coaches, making sure that nobody is making a terminal mistake that would expose the whole company to something like a risk of ransomware or something that could be a systemic risk, IT-wise, for the company.
As a litmus test, if your interaction between IT and supply chain goes through documents where you list specifications or requirements, this is not the proper way to have a good relationship between those two divisions. When I say a good relationship, I mean something that will actually add value for the company.
In conclusion, we have two challenges here from the traditional supply chain management side, which may have been doing programming but just at the edge for Excel spreadsheets, not even initially realizing that it was already a form of programming. You have to overcome your fears. You have to think that the world of tomorrow, your division, will be in charge of delivering a product that is running like a software product, and that is an enormous change. Yes, but it’s something you can deal with. Why? Because if you have the right tools, yes, there is programming involved, but it’s not fundamentally, radically more difficult than Excel. Again, the challenge is not in the technicality of the tool; it’s literally in the complexity of the supply chain itself. The problem is difficult not because your tool is difficult to handle, but because you have a complicated supply chain in the first place.
For the part of the audience that is maybe more on the data scientist side or the IT side, what you have to overcome is overconfidence. I have seen, again and again, data scientists, and I include myself in this category, who were overconfident in their capacity to bring a prototype to production. This is tough, and supply chains have a way to blow up in your face in the most surprising way. I can only recall one anecdote where years ago, we started with a leading European auto parts e-commerce company. We were handling their part replenishments with our forecasting technology, making suggestions for part replenishments, serving car parts. The next week, we saw that all our forecasts were off by a factor of two. The demand had doubled. What had happened was that their number one competitor had decided to go to multiple countries at the same time, literally at the point in time when we were starting our forecast, one of the competitors had decided to go on all the national TVs and start broadcasting their service online. The interesting thing is that my client was not even aware of that, and they had better search engine optimization results. They were more optimized in terms of SEO, so basically, people were seeing the TV ad for the competitor, but they did not naturally remember the name of the competitor. So, they went to Google and typed “car parts” until they ended up on the website of my client. In order to demonstrate how great Lokad was, the first week when we were starting, we were off by a factor of two, and we were thinking, “What the hell is even going on?” We had to revise everything because when you see that the demand doubles, it’s not that everything doubles; some things are doing 10x, and a lot of things are just untouched.
So that’s the sort of thing, and you need to be able to react swiftly. That’s what it’s about: fear and overconfidence. Thank you very much for the time.
Now, I will be having a look at the questions through the chat.
Question: Can the software make the decision about which supplier to place an extra order with in the event of needing more for tomorrow? For example, 200-gram punnets of strawberries in offices in Australia may have 10 suppliers delivering the same products to the distribution center on the same day.
Absolutely, and here we have to differentiate the two sides of supply chain management and supply chain optimization. There is the supply chain management side, which is literally having all the data pipelines in place, including EDI, where you can push an electronic order to a supplier without any human intervention. So you have an electronic bridge end-to-end. But then, that means you need to have, on the optimization side, a piece of software that runs continuously throughout the day and, at some point, can notify the management side, saying, “Please execute this order.” And then, on the management side, which is going to be managed by IT, they just make sure that this order is completely executed. It’s just a matter of pure transactionality; there is no intelligence anymore. You have received an order that says “this quantity,” and it’s the optimization side that is responsible for making sure that when you generate a certain quantity, you’re compliant with all the constraints, such as the exact list of suppliers that are even eligible to serve these products, whether they have any stock left, and how to make the right choice between all the competing suppliers, etc. There might be plenty of things going on. Absolutely, yes, but we literally have to separate the mundane execution, which is the transactional part that lies on the supply chain management side, from having the optimization ingredient at the point in time when you decide that you need to reorder more.
Question: Do you know you are competing with eSports World Championships right now?
No, I’m not competing with those eSports championships right now, but it’s very cool. By the way, at Lokad, we frequently play Dota 2, so the management team plays as well. Some of our employees want to play League of Legends, but as the CEO of the company, I firmly disapprove.
Question: I’ve seen that many businesses do not have an ERP or WMS in the first place, and that management is working on supply chain optimization.
Well, absolutely. You cannot avoid supply chain optimization from day one; you have to make those decisions. Supply chain optimization was there even before any kind of supply chain management software was in place. Even if we go back 60 years ago when there was no software, people still had to make decisions. So supply chain optimization was already a thing; people were doing it with pen and paper. If you look at the earliest supply chain works, such as the Wilson Formula, also known as the EOQ formula, it is a century old. It clearly precedes software. So yes, supply chain optimization is something that happens from day one, no matter whether you have software or not in your organization.
Now, indeed, you need to have proper IT systems, but it’s a completely different mindset. Supply chain management is about doing mundane tasks very well, such as data entry, potentially with support for barcodes and other things. But it’s about very mundane tasks, just representing the data. The problem is that people want something that does both supply chain management and supply chain optimization, and as a result, you end up with a product that is overcomplicated, usually super buggy, and you need to have bad features like alerts and exceptions, which you should avoid. I will be getting back to that in a later lecture.
Fundamentally, nowadays, deploying a WMS or an ERP, if you don’t already have one, is a matter of weeks. If you already have one, it can be a matter of months if you disentangle this thing from your decisions.
Question: When can management of the business realize it’s time to move from tracking information to optimizing supply chain decisions and eventually start focusing on supply chain optimization?
The first thing is that you even have to realize in the first place that there are two problems, and that the same piece of software will never address both angles. I think that’s the grand illusion, and software vendors have been incredibly confusing in this area. If you look at the biggest ERP vendors, their message is about supply chain optimization, but all that they actually deliver and all the things their product actually does is on the supply chain management side, which is much less sexy because there is no AI or actual intelligence. In the software world, it’s known as CRUD apps (Create, Read, Update, Delete). ERPs are just gigantic collections of CRUD screens where every single screen can create, read, update, or delete lines from a relational database, and that’s it. An ERP is basically, simplifying a bit, a collection of thousands of tables for various entities. For every entity that can be grouped together logically, you have one or two screens, and that’s it. So, if I go back to your question about management, the problem is that if you’re a manager, you read the brochure of the ERP vendor, and the ERP vendors tell you this thing is going to optimize your supply chain. The answer is: no, absolutely not. What it’s going to do is improve productivity and ensure accurate bookkeeping of your supply chain. This is already a lot, as it can dramatically reduce theft, shrinkage, misplaced goods, and improve productivity with barcodes for a warehouse. There is a lot of added value in these products. I’m not dismissing the value that an ERP or WMS brings to the table; it’s enormous, but it’s not about supply chain optimization. A WMS, for example, is by design something that cares about the warehouse; it does not care about the whole supply chain that includes clients and suppliers. It is by design focused on specific locations, not the entire chain.
Question: How can you smoothly transition from Python to Envision or have them work together?
We did have them work together in a few situations historically. For the audience, Envision is a domain-specific programming language designed by Lokad that has been engineered solely for the predictive optimization of supply chains. In the next lecture, I will be demonstrating Envision so that people can have a better grasp of what I’m talking about, with real bits of code.
Historically, we used Python and Envision together because, when we started, Envision had very limited capabilities, so there were many things missing, and we were defaulting to Python in many situations. Over the years, we have gradually expanded Envision’s capabilities, so that we have gradually phased out the need to have Python components. It’s not just Python components; it’s also a series of tools that need to be plugged together, like Airflow.
By the way, the syntax of Envision has, on purpose, been aligned in many aspects to Python. I made the conscious choice to design the syntax of Envision in a way that was not antagonizing Python programmers, so that if you’re familiar with Python, you can learn Envision in a week. It differs in subtle and profound ways, but syntax-wise, there are many aspects that are the same. Python has a lot of merits, like simplicity and purity of design. Even if I say that Python doesn’t tick all the boxes and creates severe problems in production that cannot be recovered, it doesn’t mean that Python is without merits. That is not what I’m saying. I believe Python has a lot of merits. Again, we are talking specifically about how to run supply chains in production, which is a very specific problem.
Question: How would you make a client understand that his ERP is not optimizing anything?
That’s very tough because, frankly, the worst-case situation is when a prospect comes to me and says, “Our ERP, a legacy ERP, is not delivering any value, and now we want to go to the next ERP that delivers supply chain optimization.” That’s a terrible situation for me because I have to tell the client what they’re looking for is not one product but two: one that will replace their ERP and handle the management side better, and one that does the optimization.
When you think about those legacy ERPs, I have a lot of respect for them, especially those AS/400 products with a command-line terminal on old-school IBM mainframes. From the management side of the problem, they are usually doing a very fair job. What the clients are really looking for might be a web interface rather than a command line, but will this make their teams on the ground more productive? I challenge that. Command lines with text terminals can be incredibly snappy and productive with zero distractions.
So, it’s quite difficult because we have to untangle all the nonsense pushed by our competitors. On top of that, we have to explain that the ERP is not going to optimize the supply chain and that there is no such thing as AI or blockchain, just classes of statistical models. Unfortunately, we lose most of our prospects at this stage. That’s one of the reasons why I’m doing these lectures in the first place because it takes hours to get to the bottom of it and explain why we need to see the problem the way I see it.
Question: What’s your recommendation for a platform to address the complexity of planning multiple products with probabilistic demand distribution?
Well, Lokad, of course. But bear in mind that, being the CEO of Lokad and the majority owner of the company, I do have a conflict of interest in my opinion. I’m deeply convinced that Lokad is the platform you need, but please understand that it’s also the company that I own and run. I will do my best to remain objective when it comes to that.
By the way, Lokad has been literally engineered to deal with probabilistic demand distribution, and it’s not just probabilistic demand distribution. It also addresses stochastic lead time distribution, stochastic return distribution, and more. We need to look at all possible futures with probabilities, considering all types of uncertainties. Demand is a very important one, usually the most important one, but it’s not the only one.
I think I have gone through all the questions. Just checking if I missed anything… No further questions. So, thank you everyone for watching this lecture, and see you next week, same day, same time. See you soon. Goodbye.
References
- Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity - By Joel Spolsky, 2004
