00:00:00 Deployment chapter and practitioner framing
00:04:35 Simplicity beats mainstream supply chain complexity
00:09:10 Unattended decisions avoid workflow detours
00:13:45 Change management mostly removes needless work
00:18:20 Finalized decisions shorten IT implementation drastically
00:22:55 Messy enterprise data is vendor responsibility
00:27:30 Survival proves data is already sufficient
00:32:05 Supply chain scientists own profitable decisions
00:36:40 One mind prevents fragmented numerical recipes
00:41:15 Explainability needs ownership and white-boxing
00:45:50 Explanations start when decisions actually appear
00:50:25 Insane decisions reveal missing constraints and fields
00:55:00 Profitable decisions may break old habits
00:59:35 Post-deployment means maintenance against structural drift
01:04:10 Continuous improvement expands decision scope over time
01:08:45 No value without endgame decisions
01:13:20 Ten weeks should show real progress
01:17:55 Trust takes months; test hardest problems first
Summary
Joannes Vermorel and Conor Doherty continue their chapter-by-chapter discussion of Introduction to Supply Chain. Chapter ten turns to deployment: the practical work of bringing automated supply chain decisions into production, making them reliable, and ensuring they reshape daily operations rather than remaining a prototype.
Extended Summary
This discussion of deployment cuts through a great deal of fashionable nonsense in enterprise software. The central point is not complicated: the purpose of a supply chain initiative is not to produce dashboards, workflows, scorecards, or other decorative artifacts of management. Its purpose is to produce better decisions. If a so-called deployment does not end in unattended, auditable, economically sound decisions, then much of what precedes it is, at best, ceremony.
A recurring error in the industry is the confusion of complexity with sophistication. Many companies adopt layers of segmentation, overrides, alerts, and approval workflows because these things look prudent. In practice, they often create more code, more exceptions, more ambiguity, and more opportunities for failure. What appears “safer” becomes harder to maintain, slower to improve, and easier to blame on everyone and no one. By contrast, a system designed from the outset to generate finalized decisions is harder in principle but simpler in practice.
Another important point concerns data. Firms are often told that their data are too messy to support automation. That excuse survives because it is useful to vendors whose systems fail. But any company still in business at scale already possesses data good enough to operate its supply chain, otherwise it would have gone bankrupt long ago. The issue is not whether the data are tidy. Real business systems never are. The issue is whether the people building the solution are competent enough to deal with reality rather than demanding an imaginary dataset.
The role of the supply chain scientist, as described here, is therefore not narrow. It is not merely data preparation, nor modeling, nor optimization in isolation. It is the ownership of the full numerical recipe, from raw data to final decision. Splitting that responsibility across specialists may sound efficient, but it usually creates failure at the seams. What is needed is one mind that understands the whole chain well enough to make it cohere and to explain it.
Explainability itself is treated here in a practical rather than theatrical way. You do not explain abstractions for their own sake. You explain decisions. And the explanation must finally cash out in economics: why this order, why this price, why now, why not later? If the answer cannot be stated in terms of gains, losses, risks, and trade-offs, then the explanation is probably ornamental.
The broader lesson is that deployment should be judged by ambition and speed. Aim first at the hardest real problem, not an easy toy problem. Demand useful results in weeks, not vague promises in years. If a vendor cannot demonstrate decision-making capability quickly, delay will not cure incompetence.
Full Transcript
Conor Doherty: Welcome back. This is episode 10 of a very special series where Joannes and I take his new book, Introduction to Supply Chain, and we discuss the ideas chapter by chapter. Now, for this specific series, I assume a very specific posture. As you know, I pretend not to be someone who works at Lokad. I’ve never heard of quantitative supply chain. I certainly don’t know Joannes and haven’t worked with him for almost four years.
I pretend to be one of the 10 million or so practitioners in the world who might see this book, be curious, start reading, and then have questions. Now, today is chapter 10. That means, of course, there were nine before this. I strongly recommend you watch those first because most certainly the things we discussed today will be built upon material covered in previous episodes.
And with that, Joannes, so let’s get started. Chapter 10, deployment. Now I’m immediately going to violate the posture I just promised everyone, and I will say that, you know, Conor, who works here, chapters four, that’s economics, and chapter eight, that’s decisions, they’re probably my personal favorites. Eight is probably the one that I get the most feedback about, excuse me, from people who know Lokad.
But if I genuinely think about it from the perspective of a practitioner, like someone who reads the book and they read the first few chapters and they think, “I really like this approach. I really like the idea of quantitative financial ranking of decisions. I’m really thinking about what’s the half-life of a decision. What I do now, does it open or close decisions later?” Like, I’m all on board for that. They will have a very simple question, which is, “What the hell does that look like?” Like, what if my boss says to me, “That’s a great idea, but what will it look like? What are the roles? What’s required of us? What’s the data? How long is it going to take? What are the possible failure points?”
Chapter 10 is where you actually go into that. So, we’re going to talk about the ins and outs of that, but at a high level, to get started, in your opinion, what makes a deployment actually work, and what makes one just fail catastrophically?
Joannes Vermorel: For as far as Lokad is concerned, the companies where we succeed are essentially the ones that let us proceed with the effort. And it may sound silly, but fundamentally it has nothing to do with maturity. So, you see some discussing with many supply chain directors and saying, “Oh, we need some degree of maturity,” and here I disagree, because what maturity are we talking about?
If by maturity you mean adherence to broken supply chain theories, then going further along this path will not help you to actually succeed with Lokad, but also just to succeed supply chain-wise. You see, the stance that I adopt in this book, I mean, this book is presented as a fresh introduction to supply chain. So I don’t discuss at length all the stuff that does not work, but you can read it as essentially the stuff that works, as opposed to the mainstream supply chain theory that is essentially a long list or collection of stuff that does not work in practice.
And so there are all those things, like point forecasts, service level micromanagement, having an approach where you will manage your supply chain through alerts and exceptions, rule-based everything, manual overrides for everything, etc., etc. So the bottom line is, when Lokad succeeds, it is essentially places that simply give us a solid chance at trying something that is typically an order of magnitude simpler than what the classic supply chain entails.
Because the problem is that, because the mainstream supply chain theory is utterly broken, it ends up being a nightmare of complications in practice. You see, so as soon as you actually have a correct theory, then everything is simpler. The software is simpler, the math is simpler, the logic is simpler, and the sort of deliverable lands much more cleanly, which is like decisions, optimized, risk-adjusted decisions, lands much more cleanly at the end of the initiative.
So that’s, I would say, maybe if there was one takeaway, it is don’t pursue a theory that will ultimately fail, no matter who is in charge of implementing it. At Lokad, we try to steer our prospects and clients to really stay on the stuff that will work. But ultimately, if they give us direct orders, it becomes very difficult to succeed against the will of the client.
Conor Doherty: You know, to follow up on that, just to clarify, excuse me, when you say “an order of magnitude,” you’re just giving numbers, but let’s say an order of magnitude simpler, do you mean in terms of deployment it is an order of magnitude simpler? Or do you mean in terms of the deliverable it is an order of magnitude simpler to handle?
Simpler in terms of timeline, how many days does it take to get a system up and running? How many man-hours do you need to invest? How much disruption is required? I mean, for example, an example please.
Joannes Vermorel: If you start with, let’s say, something like ABC analysis, which you love, or any kind of made-up segmentation, then you see you didn’t need that. It’s like a pseudo-obvious solution to a non-existent problem. So people think, “Oh yes, we need to approach that through varying quality of service or something like that, through a segmentation.” The short answer is no, you don’t need this segmentation.
And if we are forced into a segmentation, then we end up having so many lines of code that are going to be: if category A, then this and this and this; if category B, then this and this and this. If we have a product that went from B to A recently, we need to have this and this and this. If it went from A to B recently, then we need something. So you see, it’s just an idea that seems that the mainstream theory would absolutely embrace and like, a segmentation.
And this thing, code-wise, will cascade into a maze of edge cases, which means more lines of code, more bugs, more, I would say, insane decisions that will come out of the data pipeline at the end of the day. And so you need more time for people to actually review the numbers. You need more reports to even make sense of the numbers, etc., etc. You see, those things cascade on top of each other.
And the sort of things that Lokad does, it may sound complicated, like probabilistic forecasting, but it is not, because it’s a way to eliminate literally entire classes of problems and express, in just a few lines of code, things that would otherwise require thousands of lines of code. That’s the gist. I would say we need to pursue what is actually simple, not what looks simple, which is in fact simplistic and thus cascades into tons of rules and edge cases and, I would say, downstream complications.
Conor Doherty: So, to follow on that, and I want to be very mindful of not merging too many ideas together, so just to frame it a little bit more concretely, one of the things that you argue in chapter 10, again I’m paraphrasing, but this is very faithful, you argue that in the context of a deployment, concretely in terms of the deliverable, you’re not pursuing better visibility. You’re not pursuing better dashboards. You’re not pursuing better forecasts.
The point of a deployment, certainly in a supply chain optimization perspective, is to produce unattended, auditable decisions, those being, for example, purchase orders, transfers, schedules, or price changes that are then written back into your operational systems. Yes. That is simpler. That’s the point you’re making.
Joannes Vermorel: Again, and the important thing is unattended. So, for example, if you decide that, if you would say, “Oh, the bar is so high, unattended. You really want to be able to get it right like that, no intermediate step, straight to the good stuff.” And I say yes, because what is the alternative?
The alternative is to engineer a very complicated workflow where people can step in, do all sorts of overrides, and in the end we generate the resource allocations, the actual decisions. How much do I buy? How much do I produce? Where do I put the stock? Do I move the price up or down? So if you decide we go straight for unattended decisions, obviously what you want is to say, “Okay, I would not accept unattended decisions that are anything but excellent.” They need to be, like, typically much better than what people could manually produce.
I say, fine, no problem. That is absolutely a fair criterion. And what I’m saying is that this is what we should target from day one. And you see, if you try, you say, “Okay, we want to do it the attended way, with a multi-step workflow,” and etc., then your process, which was supposed to be supply chain optimization, devolves into the design of a workflow, and then it becomes, as you see, it is just not the same object.
And fundamentally, instead of spending time on, “Am I designing a system that really maximizes the rate of return of every allocated resource that I allocate through my supply chain?” which is the game that we’re playing, it dissolves into something where you have to survey the opinions of every single person, and then you have to do productivity optimization because the workflow is “let people step in,” so it consumes time.
So there are all sorts of trade-offs at play. If you give more flexibility, people can say, “Oh, then I have more levers,” but then it creates complications because then your employees might spend too much time on the workflow. And then if the endgame decisions end up bogus, whose fault is it? It completely blurs the responsibility.
Especially if the workflow involves half a dozen people doing little twists, incrementally, then it becomes extremely difficult to point out who is to blame. So you need to do causality analysis on all those departments. And you see, that’s how we started with something which was, “Let’s go straight to the decisions that are maximally profitable,” to something where we have been completely sidetracked, where we start engineering a workflow and user interfaces and monitoring of what people are doing and productivity optimization, etc.
You see, that’s how you can end up with something that is an order of magnitude slower, more complicated, just because you actually did a few things that looked, seemed simpler initially. No, no, it is not. So again, that’s, for us, a real criterion for success, is to be able to go straight with profitability maximization, no detour into workflows, no detour into made-up numerical artifacts like segmentations and whatnot.
Ultimately, you don’t care about ABC. What you care is, am I actually maximizing the return on investment? Whether I slice and dice my SKUs through classes, through this, through that, or through whatever, doesn’t matter. I mean, if what you want is to maximize, again, the rate of return with a long-term perspective, which means that you are not embracing a short-term, I would say, destructive perspective, you want to value the quality of service as it matters while protecting your long-term interests, and all of that will be in the rate of return. If not, it’s just that you have a simplistic criterion that needs to be adjusted.
Conor Doherty: Yes. And something you said there in particular, again, the idea of speaking to practitioners, be it just in a conference, doing podcasts like this, be it a business call, whatever, one of the things that comes up is change management. And something you said there, I asked you, like, what separates a successful one from a failure, and you said, you know, companies allowing you to just sort of do your thing.
And I would add to that, which is accepting that in change management, that means in the title there will be at least some change. And the change will be you’re navigating away from what you just described, the segmentation, the manual override, the supervision. You have to accept you’re going in the direction of automation, unattended decisions.
Joannes Vermorel: And again, I think also part of the problem is that the change that Lokad brings is extremely limited and mostly substractive. You see, that’s the thing where people are very, sometimes very, very confused. Lokad does not require to re-engineer the companies of our clients. The change that we bring is almost all of it substractive, removing things, and that’s it.
So you don’t need to re-engineer the job descriptions of a lot of people, retraining. It’s essentially, because again we are shooting for unattended decision-making processes, yes, they are conceptually simpler at all levels. It’s simpler for IT. It is simpler for the supply chain practitioners. It is simpler for the top management. It is in fact simpler for everybody.
So it is not as much as, “Oh, we have so much change, we will need to learn so much,” as opposed to unlearn all the stuff that is just not relevant anymore. You see, just think of it as those old typewriters, the mechanical ones. You needed to oil them. You needed to be able to change the ink ribbon. Sometimes you needed to take…
I had one when I was young. I mean, if you wanted to use a mechanical typewriter on a professional basis, this thing was requiring a lot of small maintenance. It’s literally a little bit of clockwork stuff. And if you go on a computer, suddenly it’s gone. Your keyboard works, and if your keyboard is dead, you just buy a new keyboard and that’s it.
The amount of knowledge that you need to use a modern keyboard, compared to an old-school typewriter, is so much less. So you see, the change management is very substractive. It’s tons of things just disappeared. And that’s really maybe the part that might be the most confusing for prospects when we’re discussing with them. They expect, in fact, a lot of change in the sense, “Oh, we’ll need to retrain people, we need to add this and add that,” and there is very little of that. It’s very, very little.
For IT, Lokad is just, I would say, a tiny fraction of the effort of what a classic system requires. So for IT, it’s a lot less. Certainly for a pilot, it’s typically very low friction. It’s just about essentially sending raw files, row flat files extracted from the system, no pre-processing whatsoever, copy and paste, just dump and transfer.
Conor Doherty: Which is a key point. Sorry, that’s actually quite a key point that we just glossed over, which is how low lift that is compared to, “We need a two-year implementation process just to get it ready.” Don’t speed past that point again.
Joannes Vermorel: Yes. The reason is, again, by design, the way Lokad operates is that we want this decision-making engine to run without a workflow. So, I mean, the workflow is super minimalistic: data in, decision out, and we’re done.
And so there are so many things that are just not needed. We don’t need to resynchronize with the ERP, tons of complicated stuff, you see, because at the end what we produce are just finalized decisions that are very straightforward to then reimport into ERP. If you want to generate, let’s say, a purchase order, it’s just product, quantity, and the supplier that is impacted, and that’s it. The data structure, purchase order finalized, is very, very simple.
As opposed to if we want, let’s say, to manage plenty of segmentations, resynchronize them with the ERP, give people the possibility to do all sorts of things in Lokad and then have it resynchronize into ERP, that’s the sort of thing that most of my peers would be offering. And that’s why the implementation takes forever, because again there are so many layers of numerical artifacts, stuff that is just, I would say, things that are not real, that are just like instruments to get to the final product, which is a decision.
And sometimes even the classic supply chain software, it doesn’t even go up to the finalized decision, the one that really takes all the constraints such as minimum order quantity checked, maximum container capacity checked, full truckload checked, etc. So very frequently you end up with also a lot of complexity that emerges from the fact that, instead of shooting for the completely finalized decision, what you get out of the typical advanced planning software, the classical APS, is something that is, again, a non-final result, and thus you need plenty of plumbing afterward to actually finalize the decisions.
Conor Doherty: This is very fertile ground to continue to walk on, I think, because when we talk about IT involvement, and this is something again we both know from having discussed with many, many practitioners at this point, one of the things that they’ll be concerned about is, “Well, my master data isn’t good enough. My data health is terrible. Joannes, you should see my data. It’s a mess. It’s indecent. Unworkable. You can’t even use it.”
You, in chapter 10, are very clear that that is total bunk.
Joannes Vermorel: Oh yes. Oh yes. The interesting thing is that, again, the market of supply chain enterprise software vendors, I mean, this market is absolutely terrible, and most vendors have failure rates that are way above 90%. No, it literally sounds insane. They are large. They are, on paper, supposedly having hundreds of successful implementations. In practice, they are all varying degrees of failure.
And whenever it fails, and it almost always fails, they will blame the data because it’s such a perfect scapegoat. Such a perfect scapegoat, you know. It’s like blaming the god of weather or something. You just blame an external force as if data was a thing of the universe and we have to live with it. No, no, no.
So my take is: data is almost invariably excellent for any company above, let’s say, $50 million. Almost invariably excellent. Why? Because the companies who didn’t have excellent data went bankrupt a long time ago. It’s just corporate Darwinism. If you don’t know what you’re buying, then you don’t know how to pay your suppliers, and you will pay some suppliers twice or not at all, and then they will stop being suppliers, or something like that.
So, can you not know what you’re buying? No. Can you not know what you’re selling? No. Because if you don’t know what you’re selling, then again you will not chase clients who forgot to pay, and those sorts of things. So the only companies who survived are the ones who know essentially what they buy, what they produce, and what they sell, basically.
Conor Doherty: Yes. Yes. Basic rule.
Joannes Vermorel: Yes. And again, Darwinism in action. Companies who cannot do that went bankrupt a long time ago, more probably like two decades ago. So the companies that survived are the ones where those basic data are correct. Correct in the sense meaning that they reflect reality and are usable.
Conor Doherty: So you reject the messiness argument?
Joannes Vermorel: No. Oh yeah, exactly. I mean, then there is what happens when incompetent vendors, yes, will face this data, and what they expect is data that is perfectly organized in a way, let’s say, a Kaggle competition is organized. You have super tidy data with just the right tables, with just the right fields, and everything is super nicely documented. But again, a Kaggle competition.
Yes, well, if you expect that as a vendor, you’re going to be disappointed. Yes. The reality is, yes, the applicative landscape is messy. What you will face is a landscape with half a dozen complex business systems, each business system having from 1,000 tables to 10,000 tables, each table having from 10 to 500 fields. And every single piece of data, like sales, is at least triplicated. So it’s presented in three different ways in different tables for different reasons, and that’s just the way it is.
So now, as far as Lokad is concerned, it is our job, and I would say I consider that the responsibility of Lokad, to just sort it out. This is just a basic expectation. And so for us, we don’t expect anything else but an extremely messy applicative landscape with decades of stuff that have sedimented. So you have, like, four different ERPs, one that was… because ERPs never really die, they just go into the background, and you still have the thing that is running on some mainframe, on an AS/400 or something, that is still running, and it was never really shut down.
And yes, you have to deal with that as well as the rest, and that’s just perfectly normal. So you see, when people blame data, for me it is really the vendors who are blaming. It is, for me, almost invariably a demonstration of incompetency from the vendors. If a vendor tells you, “Oh yes, we failed because the data is bad,” I mean, just run away. This vendor is completely incompetent. They don’t even know they are incompetent, and they are blaming the weather gods or something. It just… blaming data feels much more 21st century than saying, “Yes, the gods were not with us on this, and so we lost this battle,” but it’s really the same thing.
Conor Doherty: This is a key point, and I do want to really drill down on it, because there I need to separate two points that you have made, but I just want to echo them because they are important. One, the statement, “My data is messy,” that’s over here. And the other is, “My data is too messy to do anything industrious with.” Those are two separate claims you’re making.
And actually, directly over your shoulder, I don’t know if it’s visible on camera, is your first book, the manifesto, the red one. And in that you give the example of, I genuinely think it’s in the 90s, maybe page 98 or something like that, you give the example of, what does sale date mean? And you list about six to ten different examples. Like, if you open up your transactional data, it could mean the day it entered the basket, the day it was sold, the day the return period ended, the day the warranty ended, whatever. There are many different interpretations of what that means. That makes it messy.
But as you said just now, it is the responsibility of the vendor to take that messiness off your hands and do something industrious and productive with it.
Joannes Vermorel: Yes. Yes. And the key, and that’s fitting for the chapter deployment, is that you want to end up with the deliverable of an initiative, of something that delivers very grounded, risk-adjusted, very profitable decisions based on whatever data you have. Because the reality is that your people inside your company, they don’t have access to more data.
The production manager or the inventory manager or the purchase manager, they don’t go physically into the warehouse to acquire more information before entering the purchase orders or the production order or whatever. They do everything from their desk, and they don’t have any kind of privileged access to any kind of privileged information, for the most part, except what is actually in the business systems.
So the claim that I’m making is that Lokad… because your people, your employees, are already able to operate your supply chain, otherwise, again, Darwinism in action, you would be bankrupt. So if you’re not bankrupt, some people do manage to make your business run, which proves that the data somehow is sufficient. The very fact that your company is not bankrupt yet proves by itself that the data is good enough.
Now it’s a question: is the vendor competent enough to use the data as it is, as opposed to wishful thinking? If the vendor comes and says, “Yes, we will succeed if your data is up to my standard,” the standard of the vendor, you as a company who runs a supply chain have no control on the standard of the vendor. Obviously, this is nonsense.
Just imagine you want a repair in your house for plumbing, and the guy who shows up says, “Oh no, you know, I don’t really like the style of the way your plumbing was arranged. It feels a little bit complicated. The tubes are not completely straight. No, I think I will wait for your plumbing to be really up to my standard before I start actually having a look.” And people would say, “No, you’re the plumber. Just deal with the way the plumbing was done. And yes, if there are some pipes that are not completely straight, I mean, deal with it. That’s what we expect from you.”
You see, this sort of blaming the data is very much insane. And for me, what that speaks to a lot about the insanity of this market is that some vendors routinely manage to get away with blaming the client for the failure with the excuse that it was just the data. And the craziest thing is that they will very frequently manage to convince the clients themselves that it was their fault.
Conor Doherty: You know, it’s, for me, it’s like, whoa. Not only the vendor did fail, but they managed to convince… they gaslighted me to think it was me.
Joannes Vermorel: Okay. They managed to convince their client that it was their fault. I would say, yeah, it’s a talent. It’s an art in a way, but not exactly what you would expect from people who would claim to be supply chain specialists instead of being manipulation specialists.
Conor Doherty: Well, this actually sets up the next point, which is, again, when we say Lokad will take the data, or whoever you select, but in our case obviously we are Lokad, we’ll take your data and work with that, what we actually mean is the supply chain scientist. And that actually brings us to a core point here, which is the supply chain scientist’s role in a deployment and in the continuous improvement.
But certainly in the deployment stage, is the supply chain scientist’s role limited just to parsing and tidying the data, like you just said, or is it more all-encompassing?
Joannes Vermorel: No, because the thing is that you cannot know if the way you process the data is correct or not without the lens of the final decisions. Ultimately, the only criterion to know if what you’re doing with the data is correct or not is: are your decisions profitable or not? That’s the…
Conor Doherty: In a sense, if you misunderstand the data, but the decisions come out all right…
Joannes Vermorel: Then your misunderstanding is inconsequential.
Conor Doherty: Yeah.
Joannes Vermorel: And so people would maybe be surprised, say, how can you make a mistake and it doesn’t matter? Again, it’s a game of scale. You have thousands of tables. You have, in total, tens of thousands of fields. Yes, there will be misunderstandings. There will be glitches. There will be plenty of things. But what matters is, at the end of the day, people make mistakes too. You can have people who read a field; they should be reading another field.
It’s really: do you generate decisions that have zero percent insanity? So there is not a single decision that is immediately bogus.
Conor Doherty: Mhm.
Joannes Vermorel: And then they are all at least decently good, you know. And then when you measure the economic performance on average, do they really outperform what was the previous status quo? That’s the criterion.
Then the fact that you can have a never-ending, I would say, work to keep improving the numerical recipe to make it very, very great over time is nice, and that’s a continuation of the effort of the supply chain scientist. But ultimately, you see, the contribution of the supply chain scientist should be read as: do we manage to get those highly profitable decisions generated daily, unattended? And that is a deployment. That is an initiative that gets to this point where every day you get your decisions.
That’s the contribution of the supply chain scientist. And mechanically, or sorry, not mechanically, mechanistically speaking, the supply chain scientist is essentially the expert.
Conor Doherty: I think it’s the analogy you gave before. It’s like the pit crew all in one. It’s the engineer, the data scientist, the supply chain expert who is going to manage your specific account. Like, you’re interacting with that person, the person who runs your account.
Joannes Vermorel: Yeah. And it goes a little bit further. What I’m saying is that it doesn’t even depend on Lokad. If you fragment the responsibility of the numerical recipe… So someone has to engineer the piece of software that takes your raw data and generates decisions. This is what, when I use the term numerical recipe, it’s a piece of software starting from data as it can be found in the business systems, what exists raw, and generates at the end of the day the actual finalized decisions.
And when I say finalized, it means that nobody has to open a spreadsheet to tweak the numbers up or down just because there is an MOQ that was not managed or anything. So it’s really, really final. Good. The purchase order is exactly ready to be sent to, for example, the supplier. Okay.
So, what I’m saying is, and that’s how supply chain scientist should be understood, it must be one mind that covers all of that. One human mind. And this one human mind is the thing that is very important, because ultimately you want to have something that is completely consistent from start to finish.
And you see, if you fragment the responsibility, that’s what Lokad learned 15 years ago. If you fragment this task among, “Oh, there will be a person in charge of, let’s say, preparing the data, and then another will be in charge of doing, let’s say, the probabilistic modeling, and then another will be in charge of doing the optimization for the final decision-making process,” these sorts of things, you will end up with tons of bugs at the boundaries within your system.
You see, by having several people, they will naturally establish boundaries inside this numerical recipe, and nearly all the bugs will be concentrated at those boundaries. So you need to just have a way to remove all those boundaries so that it’s not fragmented.
And another way to understand that is just think of it as a process where you would split playing chess into several stages. Such as, for example, the first person decides a short list of pieces that are eligible for movement, and then another one decides something else. If you stage the process, will you come out with a better chess move at the end of the day? No. I mean, it’s almost guaranteed that if you try to fragment the way you play chess, you will end up with chess moves that are bad, where, if you’re playing against someone who is really good, this person will just have a massive advantage over you just because it’s one mind that can have a look at the whole board instead of trying to fragment the analysis.
Conor Doherty: Of course. Just to underline a point, or clarify and hopefully underline the point, when you say it’s one human mind, you’re talking about Lokad’s side. It is one human mind because obviously you still have to interact with the client.
Joannes Vermorel: This relationship is not about Lokad. You know, this Introduction to Supply Chain is not about Lokad. It’s about what works and what does not work in supply chain. Lokad is barely mentioned in footnotes a couple of times in the other book.
What I’m saying, and that’s the important lesson, is that if you want any supply chain initiative to actually work, it doesn’t matter if Lokad is even involved. I’m saying there must be a piece of software to generate your decisions. We went through that. If you don’t have a piece of software, then your efforts, your investments, are not accretive. You cannot make it better because it becomes very fuzzy. If someone leaves, again, it’s just extremely difficult to improve systematically something that is done completely manually.
So that’s why I say, okay, we need to approach that as a software artifact, this numerical recipe. Okay. Now what I’m saying is that there will be someone involved in the design and maintenance of this numerical artifact. If Lokad is involved, that might be someone from Lokad. If Lokad is not involved, it will be somebody else. It doesn’t matter where.
And as long as we don’t have, you know, Skynet levels of AI that are as autonomous and capable as humans, it will be a human mind. Because even if those agentic agents are incredible, they are not yet capable of doing such a complex undertaking on their own. So for now that means that there will be a person.
And what I’m saying is that, and that’s a criterion, no matter the scale of your company, it needs to be one person. It doesn’t mean that you can’t have three persons, but you see, it’s very different. Just think of it: you want to play chess with three persons, and potentially have like three experts. All the experts are equivalently capable, they are all able to play the game on their own, and they can see the whole problem. It’s not fragmented. It’s not staged.
So in a sense, if you have like three experts to decide the move, they are completely redundant. And that’s fine. So you see, what I’m saying is that it should be one mind. In practice, for a large company, you want redundancy because you don’t want, if this person is sick, to have no fallback. I understand that. What I’m saying is that if you have multiple people, they will be essentially introducing redundancies. It is not about a division of labor where you slice and dice the problem with people being ignorant of certain aspects of the process.
Fundamentally, to make it work, the numerical recipe needs to be produced by someone who understands completely the process from start to finish. That’s what I’m saying. And if you don’t have that, you will run into extremely predictable problems that almost systematically cause the undoing of this sort of initiative.
Conor Doherty: Well, in terms of predictable problems that undo the very initiative you’re trying to accomplish, one of the biggest ones is explainability. And again, we have both heard personally many, many, many times, “That sounds great. How do I explain that to my team, who have to interact with this system of intelligence that is now engineering unattended automated decisions? How do I build trust? How do I build explainability for that? What does that look like?”
Joannes Vermorel: So first, we go back to this one person, one mind. You see, who is in charge of explainability? The answer is the person who crafted the numerical recipe. It’s not an AI. It’s not a system. It’s a person. So there is a person who can explain what he did. So if this person is not available for an explanation, then again you have a problem.
So what I’m saying is that we go back to having a successful deployment. You need to have someone who takes ownership of the numerical recipe. That’s the first step. So explainability starts by having someone to do the explaining. You see, that’s the role.
And then, is this person capable of doing the explaining? Well, if this person has a comprehensive understanding from start to finish, even if in practice it can be a team, so some parts of the work might have been done by other people, if this person owns the whole numerical recipe, then yes, this person can do the explaining.
Now what you want is this person to also create the instrumentation. That’s part of what we call the white-boxing. So the person who crafts the numerical recipe will also craft all the white-boxing instrumentation. It is essentially all the sorts of dashboards…
Conor Doherty: Yeah, yeah, yeah.
Joannes Vermorel: …that instrument the numerical recipe. The intent behind this instrumentation is first to let the person crafting the numerical recipe convince himself that the recipe is working. You see, I mean, I write a numerical recipe that generates, let’s say, purchase orders. How do I convince myself that what I just did is correct? You see, I just put formulae.
Conor Doherty: That’s literally the question I’m asking you.
Joannes Vermorel: Yes. And the first answer is: I need to craft a series of indicators, yes, in euros or dollars, that decompose what I’m going to do and just tell me if what I am getting… And there will be, again, plenty of heuristics in what I want to look at.
So I will be looking… probably again, white-boxing is a little bit of an art. You don’t want to only look at the averages. You will want to maybe zoom in on products that are highly erratic, some that are highly stable, some that are growing, some that had extensive periods of stockouts, etc. I mean, all of that are the sorts of instrumentation that you are layering on top of the numerical recipe to convince yourself, as a supply chain scientist, that it’s actually working as intended.
And then this instrumentation is typically a little bit overwhelming because it’s literally thousands of numbers. And you will typically want, as a supply chain scientist, to produce a digest that is much more concise, that will be presented to colleagues, or again the clients, or to other people, to convey the convincing, but in a much more concise manner. And that’s again the responsibility of the same person, again, the person in charge of crafting the numerical recipe.
Conor Doherty: Well, in that answer, you covered the who, the what, and the how. So, who explains, what they explain, how they explain. What was not covered is when that explaining starts. And if I’ve understood correctly in chapter 10, that’s during the dual-run phase. That’s where you start to see for the first time, here’s what the new system of intelligence looks like compared to your current system. So, please expand.
Joannes Vermorel: So the thing is that in the numerical recipe, you have potentially hundreds of intermediate steps of calculation, but all the numerical artifacts, those things, they are just means to an end. The only thing that matters is the end, because that’s what you’re there for. It is, again, just like when, if you’re playing chess, the only thing that matters is the move that you make. All the sorts of intermediate steps that you had in your mind to come up with this decision are, like, yeah, okay. Ultimately they are inconsequential for observers. The only thing that really matters is what you’re actually playing. That will determine the outcome of the game.
Yes. So here what I’m saying is, and we are saying a little the same for the numerical recipe, we say explainability starts once you have decisions to explain. Because before that, everything is kind of moot. You can explain why you did all those sorts of preprocessing, why you are applying this heuristic here and there, why you’re picking this probabilistic model for the lead time rather than another one. All of that are just endless technicalities.
Fundamentally, the only thing that really deserves an explanation is the endgame, the decisions that you are suggesting. And that’s why the explaining, the white-boxing, will only start at typically the end of the second month, beginning of the third month. Once, in a supply chain initiative, the supply chain scientist starts actually delivering daily decisions.
Until then, it is just work that is mostly internal to what the supply chain scientist is doing just to come up with those decisions. I mean, the timeline is basically two months to get a data pipeline running and have the supply chain scientist dealing with this mess of data, making sense of it, and then very quickly writing the first numerical recipe.
The next two months are about rapid iterations to get rid of all the insane decisions and really tune, with feedback from practitioners, all the economic drivers. Because a lot of things require fine-tuning, and that’s because what you want is to make sure that your economic drivers reflect the strategic intent for the supply chain, for the company.
So, for example, what does quality of service actually mean? Again, a supply chain scientist can have put some guesswork and made assumptions here, but ultimately it will require discussion with actual practitioners to make sure that the economic framing is really capturing the long-term interests of the company. And those are very mundane decisions about what quality of service actually means, how exactly are structures, because the pressure on the working capital, etc., etc.
So plenty of things, rapid iterations for two months, and then by the end of month four you are ready to just let the numerical recipe run unattended for two months doing a dual run.
Conor Doherty: Yeah.
Joannes Vermorel: So that people can really… so that the numerical recipe can earn the necessary trust so that people can then decide that they will actually rely in production on this piece of software to steer the flow.
Conor Doherty: Well, you mentioned insane, and you had previously mentioned that what you’re looking for is zero insanity decisions. Now during that dual-run phase, and during the, let’s say, the first six months of a deployment, of an implementation, there presumably will be moments, whether it’s with Lokad, whether whoever it’s with, when you’re deploying a system of intelligence, there will presumably be moments where people who are observing, trying to build trust in this system, might observe a decision and it might be indistinguishable to them from a defect or, “Oh no, that’s just a new way of doing things.”
How exactly do you, if it’s so radically different to the previous system, how do you expect people to differentiate between, “That’s an insane decision,” or, “No, that just looks insane, it’s actually the best financial decision you can make”?
Joannes Vermorel: No, I mean, first, the first batch of things that you need to fix are really truly insane stuff. Okay? It’s almost invariably because there is a field that is misinterpreted, because, again, we are talking of thousands of tables. There is something where you think you have units, but in fact it is not units, it is kilograms, or whatever. You have things, it’s completely off.
And very frequently, for example, the first batch will be just to check with a CFO that we are seeing the same gross margin, the same stock value. And it’s not unusual that on first try you end up having a discrepancy of a factor two for whatever reasons. So those are, this is like the first layer of insanity.
And then you also discover all the shadow IT. For example, you suggest a quantity of 110, and then there is someone who tells you, “Oh no, no, no. I didn’t tell you, but it only comes in pallets of 100 units.” Okay, so there is a lot multiplier. It was not documented. Yes. Okay, we need to take that into account. And then etc. And then you have people who raise their hand, they say, “Oh, but no, we had these price breaks from this supplier.”
Conor Doherty: Yes.
Joannes Vermorel: It’s not recorded in the system. Usually I was just manually adjusting in a spreadsheet. Okay, we need to fix that, etc., etc. So there is, for me, the bulk of the first rounds of iterations are really all these things that are, I would say, the easy insanity. It’s something where there is a misunderstanding on the data, there is a constraint that is not properly modeled, etc., etc.
And because you set a goal for yourself that is we want to have unattended decision-making, it is more demanding. Because usually, historically, practitioners would say, “Oh, this number, yeah, it’s good, 110, we’ll just manually round it up to 100. For me it’s good.” And Lokad takes it a lot further and says, “No, no, no. If there is a lot multiplier involved, then the numerical recipe must, it’s not optional, must do everything so that we don’t need to have a manual corrective step at the end.” It is not satisfying.
So getting rid of the insanity is to remove all this stuff. And then, yes, later on we will have decisions that don’t reflect the historical practice. And here we will have the economic forces reflected. And usually, if there is a disagreement, it will be, “Do you agree on the dollars that we’re seeing?” Lokad suggests that because when we look at the dollars that are involved in terms of cost of stockout versus cost of overstock, this is the equilibrium that we see.
And here we will have iteration on those economic drivers to have a shared agreement. And that will be the second round of stuff where we have to fix the insane decisions, is that in fact economic drivers that are a lot of guesswork initially come out incorrect, and we need to iterate rapidly to get them in the ballpark of what feels right for the company.
And then finally, yes, at the end we will have decisions that sometimes surprise practitioners, but it arrives fairly late because at this point here, what we see, and that’s typically what happens with a well-functioning system, is that it will break the old patterns. For example, let’s say orders for a given supplier were always made on Mondays, but it’s not an actual constraint.
Conor Doherty: Yeah.
Joannes Vermorel: The supplier can take orders whenever we want. And sometimes it makes sense to pass an order on Thursday and not wait to the next Monday, just because, well, the sooner the better if we see that there was an unexpected spike of demand. Why should you start by waiting a couple of days while you already know that you need to pass an order? So that will break some habits.
But here the question will be, again, is it the right move from a rate-of-return perspective? Is this move more profitable or not? And here that will be the extent of the conduct of change, is to say, well, if this is obviously something more profitable, even if it doesn’t match the old manual pattern, then this should be the decision, and that’s it, and not try to add fictitious constraints to make it fit.
By the way, that is something that was happening quite a lot, I would say more than a decade ago, at Lokad, is that we had less experience than we have now. And the sort of problems that we had is that frequently some of our prospects did end up saying, “Oh, we want… those decisions change a little bit too much compared to what we had before. So we are going to introduce soft constraints, constraints that are not real.”
For example, a team might just be used to have soft MOQs as opposed to hard MOQ, so minimal order quantities that are unreal. The supplier doesn’t have them. The warehouse doesn’t care. There is no economic benefit associated with them. But for the purchasing team, it was just a way to pass less purchase orders, to make them less frequent because they had very low productivity, and thus that was a way for them to save time.
But again, once you enter the territory of unattended decision-making processes, unless there is an economic gain attached to batching your purchase orders, in which case it must be reflected in the numerical recipe, then there is no point in trying to model those soft MOQs that are completely made up and come out of thin air.
Conor Doherty: Listening to that, it reminded me of an anecdote. It was you, many years ago, I think it was during a live event a couple of years ago, you mentioned, and again I’m not going to say who, again it was a client, and in aerospace, that’s what we’ll say, but it demonstrates the idea that once you install a system of intelligence and you start adapting, you have to build trust, there will be opportunistic and sort of capitalistic decisions that arise that are outside the bounds of what you previously thought were possible.
And from that lens it might be insane, but once you actually investigate the economics, it makes sense. And the example I believe you gave was, I’m going to butcher it, but very, very simply, an MRO company had a recommended PO and it included, like, buy a full engine. Let’s just say, buy an engine. Buy the engine of an A380. And that was flagged like, “That’s mental. Why are you telling me to buy a full engine?”
And the justification was the system of intelligence had discovered, well actually, these planes in the area had just been scrapped. This engine is now being sold at a 50% discount. Buy it, sit on it, you can sell it for a profit in six months. So the recommendation was not to buy to use, it was to buy to sell, which is again very, very different to what the previous method was of, like, “I buy what I need in order to satisfy this purpose.” Whereas this is a much more all-encompassing economic perspective. So it’s not just, “Oh, I used to tick this box to do this purpose.” There are multiple ways to skin a cat and make more money.
Joannes Vermorel: Yes, exactly. And it still happens in aviation, for example. Airplanes get dismantled.
Conor Doherty: Exactly.
Joannes Vermorel: And so you have buying opportunities, yes, a part is… again, it depends on your situation, but if you know you are a company that is not tight on cash, cash-rich, and that’s something, and you’re not short on storage space, and this thing will be needed maybe one year from now, and most likely when you will need it you will pay a price that will be almost guaranteed much higher than now, yes, you should see that.
Or it can be a retailer where you have a promotion from a supplier and the product will not lose its value too fast, and you will just have the opportunity to sell it with a much nicer gross margin. So yes, that’s the sort of thing where… but again, that’s why the economic justification and explainability, the way we ground the explainability is in the economics.
You know, it’s “Why do you do that?” The answer is, well, look at the finance. And if the modeling says it’s very profitable and it makes sense from an economic perspective, then that is the right decision, even if it was not the habit historically in the company.
Conor Doherty: All right. Well, the only thing we haven’t covered yet is what happens post-deployment. So let’s say you’re a company, you’ve heard all of this, it’s great, you want to go out and buy yourself a system of intelligence. Post-deployment, what remains under the control of a vendor, and what do I keep as a client internally? Like, what parts of this process are totally under my control, and what is external to you?
Joannes Vermorel: I think, first, the big lesson of deployment is what should be the endgame. You know, if you want to have success, you should shoot for unattended decision-making.
Conor Doherty: Mhm.
Joannes Vermorel: If you don’t do that, it will cost you 10 times more. It will be 10 times as slow, and it will not be accretive, not capitalistic. You will not have something that really brings your company to the next stage of profitability as far as your supply chain is concerned. So this is really the concise lesson.
And it doesn’t matter if a vendor is involved or not, if you want to do it internally or not, etc. Again, this book is really not about Lokad. This is: what does it mean to deploy? Because you see, the sort of anti-pattern that I see in this industry is that a lot of people would say, “Oh, we have done this supply chain initiative, and this one, and this one, and this one,” and none of them have actually reached this unattended decision-making sort of stage.
So you end up with dashboards there that are ignored, a gadget here that is ignored, a piece of software over there that is just a productivity pit. It’s not literally bringing much considering the amount of time that you have to spend on it, etc., etc. So I think the key insight of deployment is that you need to have a clear goal independently of who is in charge of what. It should be to end up with something that you can trust, which generates daily those unattended decisions.
And then what I’m saying is that it’s a piece of software, and it needs to be maintained. Again, nobody avoids drift.
Conor Doherty: Yeah, exactly.
Joannes Vermorel: Just because we don’t have Skynet AI, so do not expect that a piece of software, no matter how much genius you put into that, etc., will kind of self-adapt to structural changes in your market.
Conor Doherty: Which is all the time, to be perfectly honest.
Joannes Vermorel: Yeah, not all the time. But you see, because there are classes of changes that are not structural. If it’s just about the market going up or down, then the forecasting model, the machine learning models, will just deal with that. The problem is what happens where your business becomes different, not just more of the same or less of the same because you have growth or you’re shrinking, but when you become a different beast altogether.
Just think, for example, an MRO that was selling parts and now they are selling uptime for flight hours.
Conor Doherty: Yes. It’s completely different business model.
Joannes Vermorel: You’re not even selling the same thing.
Conor Doherty: Yes. There will be aircraft parts. There’ll be overlapping mechanisms.
Joannes Vermorel: But your business model is completely different, and your incentives are completely different. The economic modeling of your business is completely different. And the same thing happened, for example, one decade ago, when a lot of traditional retailers became dominantly e-commerce. So obviously, if you were dominantly brick-and-mortar and now you’re dominantly e-commerce, again all the incentives, the sort of strategy, everything is shifting. And that’s not just more sales or less sales. It’s a transformation. The very nature of your business is changing.
So again, what I’m saying is that for all the mundane variations, a supplier having a problem and the lead times becoming slower, all of the mundane variability should be handled without any change by your numerical recipe. What I’m saying is that your numerical recipe will not be able on its own to accommodate the fact that, for example, you are introducing a new ERP.
Conor Doherty: Yes. Or that you are changing, or you’re closing distribution centers, or all these things.
Joannes Vermorel: Yes, exactly. I mean, things that are very much structural. So that’s why it needs to be maintained. It’s because you need someone who is paying attention and making sure that this piece of software is aligned with the reality of your market, the reality of your company, and the reality of its applicative landscape.
And that’s why whoever is in charge, at Lokad we call it supply chain scientist, but whoever is in charge of crafting the numerical recipe must afterward be in charge of maintaining the numerical recipe. And the reality is that you can also have this person in charge of continuous improvement of the numerical recipe, because usually when you go into production, the job has barely started.
You have achieved a certain degree of economic performance that is usually a massive step up compared to the former status quo, which was a manual process, but it doesn’t mean that you are anywhere near to something that would qualify as optimum. It just means that you’re much better, but you can keep investing into this asset to make it better over time.
Conor Doherty: Well, that’s, again, I don’t want to go, this is not in chapter 10, but it is worth stitching this together, because that is the core point of treating supply chain, in this case your supply chain software, the difference between capex and opex. Because when you invest in a system of intelligence, there is no, as you just said, there’s no upper limit to how much better, how much more performant, how much more financially rewarding a decision can actually become. I mean, I’m sure there’s only a certain amount of money in the world, but realistically, there’s no ceiling to how good that could be. So if you invest properly in that, you are at least oriented in the direction where you really financially ought to be going.
Joannes Vermorel: Yes. Yes. And again, it becomes, to some extent, an entrepreneurial undertaking. You have to decide if you want to expand the range of options. Should you, for example, have your decisions where you can start saying the MOQs are a given, but the next stage would be: the MOQs should maybe be renegotiated? Is there a case? Is there money to be made in renegotiating the MOQs with the suppliers?
What should be the negotiation about? What should it look like? Are we okay to go for a slightly higher unit price if we can substantially lower the MOQ, or should we go the other way around, etc., etc.? So you see that we start with… a supply chain initiative starts with a specific scope in terms of decisions, but then over time it can expand to have more and more decisions.
Usually you start with, I would say, the basic fundamental decisions governing the flow, but then you can layer that with decisions that are also shaping the flow, although they are typically taken as a given initially, just to keep the initiative grounded and end up with delivering, again, unattended decision-making quickly before expanding into more and more scopes.
Conor Doherty: Well, this is actually my closing thought, but it does follow with what you just said. Obviously, the end goal is unattended, automated decision-making oriented towards financial betterment of the company. Great. That is the end product of a deployment, and again it’s continuously improved, etc. Brilliant.
That you can judge the ROI of, or that you can at least observe. Does that therefore mean that in the first couple of months, where you’re just in the data validation and the data sorting stages, there’s no real financial value to that? So basically, without the end product, there’s no value to the first steps? Or there’s value throughout that entire chain?
Joannes Vermorel: No. I mean, again, as long as you don’t generate the endgame decisions, you have no idea, not the faintest, on whether you’re on the right track or not. You see, that’s why I say if you start chasing numerical artifacts, you don’t know. It may look very good, but the reality is you haven’t the faintest clue.
You see, again, think of it as if I tell you about chess. Without suggesting the final move. If I say… imagine you have a game of chess and I make a hundred statements about what it looks like, the sort of things that are strong position, weak position, and whatnot, and at the end I don’t say what sort of move we should be doing next. I mean, what is the value of all this guidance? You see, it’s…
And there is the problem, is that for me, a lot of enterprise software vendors have been using this ambiguity to sell stuff for decades. They will have all sorts of numerical artifacts. “I will give you a scorecard for your suppliers, a scorecard for the products, indicators for this, for that, a digital twin that simulates this and that and that and that,” endless stuff. And then not a single commitment to a final decision where we can agree on, “Will this thing generate profits or losses?”
And what I’m saying is that this is not… and that’s a difference of appreciation. This is not a distant goal. This is something that you can reach within, again, Lokad’s experience, eight to ten weeks. And again, eight to ten weeks with a team that is typically quite limited. This is not a massive undertaking. This is…
And for me, that is a start to everything. The deployment is not… for us, we say the closure of the deployment is when the company really genuinely trusts the unattended decision-making process, which is like the last two months of the process. And I think the mistake, and that’s why I say a lot of companies end up distracted, is that instead of going straight to unattended decisions, which they think to be like a super mature, super remote goal, they will start chasing other goals.
And they say, “Oh no, we cannot go into having a completely robotized system in 10 weeks. I think we need to establish a workflow first, and that will take 20 weeks.” You see, so you establish an intermediate step that is already twice as large and twice as complex as your endgame. And that’s why I say those numerical artifacts, those ideas coming from the mainstream supply chain theory, end up creating so much complexity.
That’s how you end up with projects that take multiple years. And after multiple years, you still don’t have something that is anywhere close to an unattended process, or anywhere close to something that would be capex, with an asset that is productive, and where your investments become accretive. That’s why I say it needs to be put on the agenda like this is the number one goal. This is what we should start with, and then improve on that.
Conor Doherty: I agree. And well, the only thing I want to add to that is I actually want to use the analogy, the simile, that you’ve used multiple times, so that being chess. And then I’m just going to say something, you give me your closing thoughts.
But if the end result of a deployment is making the best moves with the pieces of the chessboard so that you can win the game, that’s the end goal, that’s the system of intelligence, the automated decisions. The first couple of months, the data sorting and validation, where you’re building the schema, you’re parsing, you’re understanding the connections, that is effectively building the chessboard, or showing you, at the very least, “Here is your chessboard, here’s the color of the squares, here’s what the pieces look like. Here are the moves that you can actually do. Here’s how a horsey moves. Here’s what a rook does.”
I’m not giving you the decisions because I’m not there yet. But there’s, to me, manifest value in knowing, “Oh, that’s what a chessboard looks like. That’s what these pieces do.”
Joannes Vermorel: Yes. Yes. Obviously. So if we are talking about de-risking the initiative, yes, you can have a sense of the progression. Yeah. But let’s be real, most supply chain software initiatives are typically rolled out in multiple years. Most software vendors would sell licenses where you have to have minimum one-year commitment, and very frequently four-year commitment. Again, this is completely bogus.
What I’m saying is that you should be shooting for something that is much, much shorter. Yes. And 10 weeks is not that much, you know. And again, if you want to get a sense of, is this entity, even if it’s an internal solution, progressing toward the solution, at week four you can just ask the person in charge, again, I say one mind, yes, what are you doing? What are you building? Does it make sense to you? Is the explanation that is given toward, “Will this thing get me into the complete recipe just six weeks from now?”
I don’t think there is a lot of work that is for preparations, but in the grand scheme of enterprise software, to be able to reach a point where you deliver the endgame product in like 10 weeks, in terms of tunnel effect, it’s really not that much. It’s really, really not that much. Let’s maybe, in the future, with coding agents, we will bring that down to half the time, but it is still, I think, very fast.
Yes, the problem, you see, I do not see a lot of potential… we can have a potential to bring this, let’s say, 10 weeks of tunnel effect to five with a lot of coding agents, to really accelerate this part, but this is not really where the challenge is. The challenge is, compared to the status quo, go for something where you will get a result normally in 10 weeks, as opposed to literally shooting for a process where by design you go for something that will take 100 weeks.
You see, very frequently when it comes to deployment, for example, one thing that I hear very frequently is people say, “Oh yes, oh no, we cannot afford to do that, have results in 10 weeks. We need to start by doing an RFP,” and bam, 18 months. Okay, so you transformed… you had something where you could have results in 10 weeks, and now you have one year and a half of just vendor selection, and this vendor selection costs you a lot more than actually doing the stuff.
And then you end up with a vendor that literally asks, they want a commitment for one year, if it’s not like four years. Okay, this is bogus. That’s also the lesson of deployment, is what are the scales of the relevant timelines.
What I’m saying is that you can get to an unattended decision-making process in 10 weeks. It will take about six months for you to completely trust this thing, because most of it is really the time it takes for humans to trust a piece of software. It doesn’t have much to do with the technology. So that’s why even if tomorrow we have coding agents that can bring this delay of, let’s say, 10 weeks to really get to a numerical recipe that works and that is not completely insane, we can probably tomorrow have this compressed in five, let’s be crazy, three weeks.
It will still take a couple of months for practitioners, for the top management, to trust this piece of software and let it take control of a major piece of the company. So you see, in the end, I would say this is not the real battle. The real battle is… I mean, you can squeeze a few weeks here. Lokad is working on it, but it requires a lot of fancy technologies, a lot of very refined practices, because every day counts. You want to be really, really fast.
But very frequently, you see, Lokad, we work on developing the technologies so that we can squeeze a few days here and there. But what I see is that I see many, many companies where we are in discussion, and they start by losing entire years into going for things like, yeah, by design, where they go for an RFI, boom, eight months, then 12 months, and then they pick a first vendor that said that they will deliver something in eight months, but actually one year and a half later they still have almost nothing to show, and it’s certainly not automated, etc.
I mean, you see, imagine this sort of super frustrating situation where Lokad… we are in discussion with a company, and then they go through a process, and it takes us five years to finally start the pilot, which is then done in 10 weeks.
Conor Doherty: Yeah.
Joannes Vermorel: You see, that’s very frequently the sort of… and so that would be maybe a lesson for deployment. What I’m describing is that to deploy a supply chain initiative, companies need to have ambitions that need to be much higher, in a sense. Again, unattended decision-making.
And you want to not start with a small thing. You want to start with the hardest problem. Again, why? Because you want to weed out the incompetent people, whether it is an internal solution or an external vendor. You want to really start with something that is truly hard as a way to assess the actual competency of whoever you expect to solve the problem.
Do not start with an easy problem, because then you can end up with an incompetent entity, whether again in-house solution or external vendor, that just does a passable job, but you don’t realize that it’s a dead end because you picked something that is easy, French, dealing with a small data set, etc. No, no. Once you go into a modern path of supply chain, you pick the hardest problem, the largest data set that you have, and you want, in 10 weeks, to make really sure that the entity that you think is going to be your long-term solution is vetted on this thing, that you know that it works.
If you start by vetting this entity on something that is easy, you don’t know if this person or entity will be capable of doing the hard stuff afterward. Again, if the hard problem was taking like three years, you would say no, we need to do something small. But what I’m saying here, and that’s also part of the deployment, is that there is, to my knowledge, no problem in supply chains where, in 10 weeks, you can’t have an unattended decision-making process that demonstrates either the fact that you are able to do it, or that will demonstrate the fact that you’re incompetent. That’s it.
And the thing is that if the vendor can’t do it in 10 weeks, they won’t be able to do it in 100 weeks. So it’s pointless to keep investing. You have to admit that it didn’t work out. You need to change vendor, change the method, change something more fundamental. To just give it time is just not going to cut it.
Conor Doherty: All right. Well, Joannes, I don’t have any further questions. We’ve been going for, I think, about an hour and a half, but I do think covering a lot of very practical information, which again, I highly recommend people go back, read chapter 10. There’s a lot of very useful stuff. But thank you very much for your time, and thank you very much for watching.
And yep, if you have any questions or you want to talk to Joannes and me personally, you can reach out to us on LinkedIn or send us an email at contact@lokad.com. You know the drill. And with that, we’ll see you next week. Get back to work.
