Full transcript
Conor Doherty: This is Supply Chain Breakdown, and today we’ll be breaking down why your supply chain is CapEx, not OpEx.
My name’s Conor. I’m the Communications Director here at Lokad, and joining me in studio to my left, as always, the very well-dressed Joannes Vermorel.
Now, before we get started, please comment down below: first of all, where you’re watching from, and secondly, do you agree—Is your supply chain CapEx or OpEx?
It’s a very simple question—or is it? Let’s get straight into it.
So, Joannes, I came back from my vacation. During my vacation, like all good employees, I rewatched all of your lectures.
As longtime followers of Lokad will know, Joannes has a long-running series. That’s a very terrible way to spend your vacations, but I digress.
But I learned, you know, monetizing my time, and in all seriousness, I did actually rewatch some.
And one of them was Product-Oriented Delivery for Supply Chain, and that goes way back.
That’s, I think, 2017, something like that, and in that there’s a really nice gem of an insight.
There’s many, but one in particular struck me, where you argued—and that’s what brought this about—that you should reconsider your supply chain: not OpEx, not an expense, not a liability, but more as a productive asset, one that can generate value again like machinery, the cars, whatever.
So my first question: have I broadly summarized the thesis correctly?
Joannes Vermorel: Yes. And by supply chain I really mean the decision-making part of the process, not the supply chain infrastructure. Yes, a warehouse is obviously an asset, but here we’re talking about the machine, or the organization, or the process, or whatever that generates all the mundane supply chain decisions that need to happen on a daily basis. What do I purchase? Where do I produce? Where do I put the inventory? Should I move the prices up or down?
The machinery—this organization that generates all those decisions—Is it treated as an asset? And yes, my point is that in the mainstream practice right now, absolutely not. Supply chain—the management part, the decision-making part—is pure OpEx. It is a cost center. It is whatever it takes, you know, as many planners as it takes to just get the jobs done, and this is again.
Conor Doherty: So, let’s be really clear and as concrete as possible for this. What are the behaviors specifically that would separate what you’re advancing right now from the current state of the art? So, in concrete terms?
Joannes Vermorel: Concretely, the only part that is perceived as CapEx would be the software licenses by some enterprise software vendor supporting the decision-making processes. But that’s, I would say, as CapEx goes and as productive assets go, very, very weak in the supply chain world, because those pieces of enterprise software are extremely demanding in terms of manpower. It’s literally—you can even think of those pieces of enterprise software as things that need human co-processors. So you have your systems; your systems require tons of manpower every day to deliver the decisions that concern the floor.
And the reason why I say it’s not CapEx is because it’s not accretive. You invest mandates today, every day, to get the flow moving, and this is not something capitalistic. You spend it, and you have to spend it again and again and again, and fast-forward twenty years, you still have to do the exact same thing. So you see, it endlessly consumes this manpower. There is nothing really capitalistically accretive about it. It is just like you need to put fuel in a truck; you need to put manpower in those pieces of enterprise software. And that’s why I say that, by and large, companies are treating their supply chain as pure OpEx—if we put aside the small line about the license of enterprise software that is maybe considered, at least normally in terms of accounting, as an asset—but it’s still a very, very weak asset.
Conor Doherty: Is this across the board, this perspective? So is it limited to just supply chain people, or are you saying that even at COO or CFO levels and accounting levels they would still see it in those terms?
Joannes Vermorel: Plenty of cost centers inside the company would have the exact same approach. They would think of, for example, accounting—same thing. It’s just pure OpEx. That’s just the cost of being in business. You need to have this amount of resources in terms of accounting workforce. Maybe your accounting software is a small asset, but that means it’s certainly not really a productive asset. It’s not something that is going to, on its own, generate extra profit, extra revenue. It’s not a money-making machine of any kind.
You know, that’s the difference between asset and liability: Is this thing you’ve purchased—will it generate money on its own? And if we look at accounting, clearly no. It’s necessary, yes, but will it generate money? No. It’s a pure cost center. And that’s the problem here. The point that I’m making is that the classical way to look at supply chain—so, decision-making, the decision-making part—is to treat it as a pure cost center with essentially expenditure in terms of mandates every day: a company this large needs this many mandates to keep the flow running, and that’s it.
Conor Doherty: We’ll get into the implications of this and, again, specifically how supply chain as an asset will work. We’ll get to that. But right off the top, you mentioned decisions generating money. You were saying that that is antithetical—that is the opposite, excuse me—of the current mindset. Are there any examples, right at the start, of decisions—You mentioned decisions—any examples of decisions on a day-to-day basis that change in a company once you start thinking about your supply chain as CapEx versus OpEx?
Joannes Vermorel: The idea is that if you start thinking about CapEx, you have to step back. Instead of thinking, “I am paying people to take those decisions,” you think, “I am paying those people to engineer the system that generates the decisions on its own.” And that’s very different, because it means that if those people that you’ve paid—you stop paying them—the system keeps generating those profitable decisions.
And that can be something as mundane as an inventory replenishment. If it’s done correctly, this is obviously a profitable operation: you convert your dollars into physical inventory, and this physical inventory will be converted back into dollars. If those decisions are made automatically, this is like a money-printing machine. You have those decisions being made profitably for the benefit of the company, irrespective of whether people invest more time or not. In practice, you have to pay for electricity and a few things to keep the software running, but as a principle, whenever you can mechanize a whole thing, the cost of running the ongoing thing is just a tiny fraction compared to having people doing the same work.
If you look at a conveyor belt, moving things through a conveyor belt has a cost—electricity, maintenance, etc.—but it’s such a small fraction compared to having people manually carry the items.
Conor Doherty: I think we’ll get straight into, again, the discussion of it as an asset, because I think for a lot of people, when they hear assets, they’re still stuck on the concept of physical assets. And something that we’ve talked about many times is—and this is my own phrasing, you may tweak it—but supply chain is a geographically distributed network of actors. You have behaviors, you have prices. Again, that’s a noun, but it’s an abstract noun. So, supply chain is constituted of both physical and abstract concepts. And so, how do you explain the asset nature of supply chain given that it is both physical and abstract?
Joannes Vermorel: Think of it as a decision-making machine. You have these big machines that involve literally computers and people, and they generate those decisions. What I’m saying is that if you think about it as an asset, you think, “Okay, I am investing time to make the machine better,” and, again, because it’s a machine, if you stop investing—so, spending people’s time—the machine will just stay the same, but it is supposed to be staying the same.
Just compare the two outlooks: they are very, very different from the CapEx perspective. When we mechanize supply chain decisions—thus we treat supply chain as CapEx—actually, the reality is that when supply chain scientists go on vacations, things are just fine. The decisions are still generated. We have people supervising; we have people in case of emergency that are there to supplement, but the reality is that if we stop investing for a week, all the decisions are still being generated, and if we put the person back, it is to improve further. That’s literally the time being spent: it is there for continuous improvement, and this improvement is something that is lasting. That’s why I say it’s CapEx—because it’s accretive. You spend this amount of days to make the machine better, and then if you let the machine run, it will run on its own. A little bit like a conveyor belt: yes, it needs maintenance; yes, it’s not fully autonomous—that is true—but we are talking about orders of magnitude of difference.
Just like if you stop the maintenance of your conveyor belt for a day, it should be running fine. You don’t have people tweaking the thing all the time. If, to operate your conveyor belt, you need to have someone always behind this machine, then it’s a bad machine. It doesn’t fulfill its role as a productive asset; it should be largely unattended.
Conor Doherty: You’ve touched on ideas of better and worse—making the machine better or worse. You used a conveyor belt, which works functionally; it’s a function, it’s quite mundane, and I think there’s probably a ceiling to how high you can make that better or appreciate the asset. I just want to dig down a bit on that. What is the limit to the appreciation and/or depreciation of this supply chain asset, because, again, if it is an asset, it is subject to the forces of appreciation and depreciation; otherwise, it’s not an asset.
Joannes Vermorel: Yes. And here there is fundamentally no upper limit, because when you enter the realm of decision-making, there is no ceiling usually. If you define the problem as just narrow inventory replenishment of the things that you’ve already sold, then yes, there is a ceiling: the optimal replenishment, whatever it is, will only increase the profitability of your company so much. That can be a lot, but there is only so much.
But then, if you extend this very notion of decisions—such as when do you decide to introduce a new product; when do you decide how much you invest in promoting a given product, etc.—then it becomes very fuzzy, and I would say there is no clear limit. Yes, there might be limits, but the reality is that when you’re in this realm of decision-making processes, the limits are really sky-high in the sense that there is no obvious limitation.
Again, if we compare that to, let’s say, accounting: if you have a great accountant, it’s going to be very good; if you go for the very best accountant in the world, it’s not going to make that much of a difference compared to a great accountant, just because you’re in the realm of compliance, not in the realm of making decisions. So now, if you arbitrarily restrict the scope of those decisions—let’s say we are very narrowly approaching supply chain as it can only do this short list of decisions within this frame—then yes, there is a ceiling. But if you just extend that, then there is no clear ceiling anymore, and the fact that there are companies that keep entering the market, outperforming their former dominant companies, proves that obviously there is a way to make better decisions so that you out-compete. Every single company that has recently turned into a giant just proved that there was a better way somehow.
Conor Doherty: In even simpler terms—and correct me where I’m wrong—but what makes the decisions is available data, whatever that information is. So, the more people who enter the market, the more suppliers who enter the market, the price actions of your competitors—All of this changes the limits: what is possible to be done tomorrow versus what was possible to be done yesterday and what is possible today, because that shifts. From that perspective, if you have the tooling to pull all this information into your supply chain—into your asset—there’s no upper limit to how good, and by good I think you mean financially rewarding, a decision can become, because today you made a dollar profit; tomorrow, because of a slight tweak in the circumstances of the global supply chain, that’s worth a dollar ten; you can do it even better.
Joannes Vermorel: The thing is that if you look at other domains—let’s say marketing—it becomes very obvious. There is no upper limit on how good a marketing tagline can be. The “Just Do It” of Nike is very famous; they made billions with this tagline. There is kind of no upper limit on how good you can be in marketing. Obviously, in practice, it is very difficult to outperform, and the people who are able to be absolutely brilliant are extremely rare. But fundamentally, what I’m saying is that it is the sort of problem that does not have any kind of obvious limits, and if you look at outliers—and again, we are in the realm of decision-making, creativity, invention—you can revisit the very frame of your decisions. It gives you enormous freedom, and that’s why I say no clear limit. But that doesn’t mean that you don’t have practical limits. Yes, you have practical limits that are your own capacity to even think or engineer this system that will generate those super decisions.
Conor Doherty: In terms of the engineering of the system, there’s two ways to think about the engineering of the system. You have the, let’s say, data scientists or the supply chain scientists or the decision scientists who do the literal coding. But there’s also the engineering of circumstances at a company that allows for that to happen. To focus more on the latter—from COOs and CFOs—what are actions that they can do that engineer a more copacetic or more productive environment for this kind of thinking?
Joannes Vermorel: I think the starting point is really to have a core assessment of the money that you’re spending on decision-making—supply chain broadly—which will cover planning, forecasting, S&OP, all the mundane management that could be production management, inventory management, distribution management, etc. Essentially, all those people who are handling spreadsheets.
You have to ask yourself: Am I spending money CapEx-style? So, am I spending this money because I need it, otherwise the flow stops, and tomorrow the situation will be exactly the same—I will have to repay again because fundamentally nothing has truly changed? Or am I spending money to automate further, to improve the automation, or to even start automating? Just the starting point, before thinking of the fine print of the engineering—how you do that, etc.—is to think: Is this money spent to make my decision-making machine better, whatever the ratio of computers versus people you have in this mix? Or am I just spending money as fuel for a truck, just to keep it running, and that will not change anything about the truck once I have exhausted this fuel?
My core take is: If you do this core assessment, I think in most companies you would realize that the quasi-totality of the funds are just OpEx. It’s like 99% is literally spent to just keep the engine running. There is very, very little about improving the engine. Improving the engine will only happen every five years when they suddenly pay a large enterprise software vendor for an upgrade or something. But that’s a really wrong way to think about it, because it is very weak. It means that you are essentially treating your supply chain as pure OpEx every single day, except once in a blue moon where you do the opposite. What I would advocate is that CapEx should be every single day. Every single day, whatever you spend should be to improve this asset, not once in a blue moon, like twice a decade when you decide to pick a vendor versus another.
Conor Doherty: On that note, it’s a perfect segue. You describe “every day”—adopt this CapEx mindset, then every day treat your spending as if it is CapEx. Okay. To take an example of an asset: if I buy a house, it’s not that you can, with absolute exactness, know what the value of my house is, but there are ways to gauge—“I paid half a million a year ago; here’s what a similar sized house with a similar energy rating sold for in the area; it looks like my asset has appreciated 10% or depreciated 5%,” whatever. From the perspective of supply chain as CapEx or as an asset, how exactly do you propose measuring the appreciation and/or depreciation of that asset class?
Joannes Vermorel: It is extremely difficult because fundamentally you are dealing with counterfactuals. “If my supply chain was run by a different machine, how profitable or unprofitable would it be?” So it makes the investigation quite difficult. Nevertheless, in practice, it’s not that difficult, because you can look at all your basic performance indicators: inventory turns, profitability, inventory write-off, overall quality of service, etc. If your machine is well-oiled and improving, those things should improve.
Again, you have to look at counterfactuals because, for example, your improvement might be undermined by the fact that suddenly your suppliers are having tons of trouble and your lead times have increased enormously since you started working. You need to factor all those elements. It’s difficult to have a metric, but fundamentally, while this is difficult, it is the same sort of problem that every software vendor has to face. By the way, there is a reason for this similarity: if you treat your supply chain as a machine that generates decisions, then you are dealing with essentially a software asset.
Just think of how Microsoft judges that, when they spend this amount improving Microsoft Word, they have actually improved Microsoft Word. It becomes a very diffuse problem; it is difficult to grasp exactly why you’re spending resources to improve the engineering—what are you exactly improving? Nevertheless, even if it’s difficult, the progress is very tangible and very real. When you go back to any software, just try the version they released two decades ago, and you would say, “Oh, this version twenty years ago was such a piece of crap, and the one I have now is so much better.” Unless the software vendor is stalling in its progress, it is a typical path you would observe.
That’s the same sort of thing that should be happening for your supply chain, meaning that this machine should be taking you to a state where there are fewer and fewer areas where you need those human co-processors. That’s one thing you can measure in a very straightforward way. You can also assess how deep your decisions go. For example, are you able to deal with multi-sourcing, or are you still sticking to very crude sourcing heuristics where you cannot handle multi-sourcing? Is your reordering really smart with full truckloads, full containers, or not? Are you able to truly leverage price breaks that your suppliers offer, etc.?
There are plenty of things where—even if you don’t ever have actual counterfactuals for what would have happened without this improvement—you can still have back-of-the-envelope calculations: “Okay, last quarter we managed to really improve our heuristics for full-container shipments; we didn’t do that in the past; this is now done quite carefully, and I can assess that the extra payback is roughly that.” It’s approximate, but when the improvement is real, it doesn’t take that much work to convince yourself that you have tangible results. If it’s almost impossible to identify any kind of tangible outcome, then probably your improvement was not real; it was just an idea you had, not something that really mattered for your company.
Conor Doherty: When we talk about heuristics, one of the things that people often strive for with any kind of digital transformation is a greater sense of resilience, and people often see assets as resilient to shocks. For example, anytime the market crashes, gold spikes. Do you see this supply chain-as-CapEx perspective providing any concrete resilience boost in the face of things like, let’s say, COVID or Suez Canal incidents or anything like that? If you can compare A/B—the OpEx perspective in those situations and the CapEx perspective in those situations.
Joannes Vermorel: Yes. If you’re OpEx, that means you are essentially trying to optimize your resources. What does that mean? That would mean 100% utilization of your resources, which are people. So your people are working at 100% to keep the flow running. If they’re only working at 70%, then you’re wasting 30% of their time where they are doing nothing. That’s the problem of approaching with OpEx: you want this 100% utilization.
Now, what about a disruption? With a disruption, because of the disruption, obviously you will need to deal with things that are unusual, and that will require—because we don’t have general AI yet—people by default. You’ve built a machine, but the machine is not sentient; it’s not able to deal with extraordinary circumstances on its own; it’s going to fall back on people for those events. Question: are those people even available to cope with that?
My answer is: If you’re in this OpEx mode, the reality is that everybody is at 100% utilization. One symptom of that is: in the company, everybody’s firefighting, and the supply chain director is juggling with five emergencies per day. That’s a sign of very high utilization—constant firefighting, where people are being a little bit overwhelmed by the amount of stuff, and routinely it bubbles up to the higher layers.
In contrast, if you’re in CapEx mode, people are spending their time to improve the machine. If there is a disruption, they just stop their work—which is improvement—and they can go into damage control, because they are not fully utilized just to keep the mundane operation running. That’s where, in terms of resilience, this CapEx that I advocate gives you a lot of leeway to deal with the exceptional, because people are not 100% utilized just to cope with the mundane. Literally, they can—if you are in this CapEx mode where you have this machine that generates decisions—everybody can go on vacation for a week, and unless this is a precise time where there is a complete new set of tariff policies, it will be just fine. If you’re not at the specific time where chaos unfolds, it will be fine, which means that if chaos unfolds, those people can readily jump into tackling, in terms of damage control, this disruption instead of being completely drowned already under the daily humdrum.
Conor Doherty: To build on that, I think it might be from the same lecture—or maybe it’s 1.4—talking about the agility and responsibility of a decision-making engine. When those events strike, you don’t want to have to convene a hundred people all in the same room or on a Teams call. You want the engine—the asset—to be able to quickly adapt to these shocks.
Joannes Vermorel: That’s also the second part to the answer. If you have this machine, then if you have a large-scale disruption, the amount of stuff that you will need to tweak is enormous. If you have dozens of people that you have to retrain, adapt their policies, etc., that will take time. Even if you’re super diligent, it will take weeks. If your decisions are under the control of essentially a piece of software, you can duct-tape in a matter of hours—maybe a day or two at most—something crude that at least does damage control at scale.
That’s something that, look, we have done numerous ways during the last decade. Those people who have bandwidth available to deal with the damage control—when they want to act—they will not go through workflows that don’t even fit the emergency, because the workflows are optimized for productivity for daily tasks as you usually do them. You can directly go in the code and inject your heuristics to deal with the problem at scale, and as soon as you restart the engine, you will generate revised decisions that embrace this new reality.
Just to give you an example, they would say, “What if, for example, the company lost suddenly access because a large bank that was servicing the company just canceled a big line of credit?” So overnight, the amount of liquidity accessible to the company has been, let’s say, divided by two. Suddenly, you have a liquidity crunch. You have a problem. You don’t have enough money to buy all the stuff that you would need to buy.
Question: how do you revise, end-to-end, all your purchasing policies so that it fits this new reality—at least for the time being—until somebody in finance manages to find another source of liquidity? If you have people, it’s going to be very complicated; that will take weeks. If you have a machine and you have a numerical recipe with economic drivers, you would just say, “Okay, cost of cash—bam—I inflate this factor by maybe 10× just because I have this liquidity crunch,” and that will automatically eliminate any kind of decision that is not very shortly cash-positive to cope with this problem of lack of liquidity.
Conor Doherty: Thank you. Before we push on to some of the public comments and a couple of DMs, just one last thought. We’ve talked about the asset; we’ve talked about the perspective of the CapEx mindset, but, as I’ve written here, you haven’t commented specifically on what are the tools or techniques or methodologies that mark the kind of perspective that you’re saying—technologically—what makes that asset appreciate?
Joannes Vermorel: We are literally talking about software improvement. In practice, when I was saying “machine”—with computers and people in the mix—this is essentially a big software project. I believe that supply chain, when approached in a modern way—this decision-making game—is fundamentally a software game.
Now you have to think of: How do I make this piece of software that is completely specific to my company? That’s the catch: it cannot be a generic piece of software, because it has to completely embrace the exact data sources that you have, the exact strategy that you have. At scale—if we’re looking at companies that are, let’s say, a hundred million dollars and above—there are no two companies that are exactly alike. There is always differentiation. Every large company occupies some kind of economic niche of its own.
So this machine is going to be specific to you. It doesn’t mean there can’t be similarities or components reused, etc., but fundamentally, because you are bringing together all the data sources and the strategy of the company, this piece of software is going to be, very dominantly, something that is completely specific to this one company. At Lokad, we are serving dozens and dozens of companies, and each one has numerical recipes that are completely their own, because even if companies are similar, we find out that there are profound differences.
Conor Doherty: When you drop the term “numerical recipes,” you’re essentially referring to the asset itself—the algorithm that generates the decisions.
Joannes Vermorel: Exactly. The numerical recipe is a loose term. It can involve plenty of algorithms, plenty of heuristics, plenty of stuff—some very smart, some not so smart. It’s literally all the plumbing that goes from all the inputs there till the decisions that you need to generate, and that’s the way to visualize the asset.
Conor Doherty: All right, Joannes, I will push on because we’ve been talking for about thirty-five minutes. This is—I’m just going to read this as a comment; I don’t see a question mark, so I’ll read it, and you give me your take. This is from—forgive my pronunciation—Gav. I hope I’ve said that correctly: “From what I understand, positioning supply chain investments as CapEx highlights that building resilient networks, automation, and digital platforms are long-term assets that strengthen competitiveness and not just day-to-day costs.” I presume you’re in agreement with that.
Joannes Vermorel: Absolutely. And you have to really think of means to an end. Don’t think, “I’m investing in some kind of data platform.” You are investing into a machine that will make more profitable decisions. Keep in mind: is this investment aligned with this vision of generating more profitable decisions?
Because that’s also another trick you have, where you have many pieces of enterprise software that are absolutely not capitalistically accretive. An example would be: you have a supply chain digital twin—fancy—but if it does not derive decisions on a daily basis, then what you have is a gadget, and possibly an expensive one. The only way to think of this as a productive asset is that it generates decisions on a daily basis, at scale, and those decisions generate the profit that makes the asset productive and profitable.
Conor Doherty: I do think—and again, as always, correct me where I’m wrong—but a key detail there, and there’s a reason I always jump in whenever that topic comes up, is “at scale,” because at scale is critical.
Any one person might outperform or perform as well as an algorithm on any one decision, but if you need to take 50,000 every single day, that’s way beyond the back of—
Joannes Vermorel: And also you have the problem that, again, that’s OpEx. Okay, this person is very good, but this person is fundamentally not going to get better that much over time. The good supply chain practices have been known since the 1970s. APICS, the Association for Supply Chain Management in the US, has been teaching those principles for decades after decades. We have to be realistic on how much improvement we can expect. It’s not a domain where someone is going to be more productive tomorrow: it’s essentially the same numerical recipes, the same practice.
You should not be expecting, when people do it manually, that there will be that much improvement. So, yes, at scale—but it’s what you get by default with software. If the software is correctly engineered, you can generate decisions at any scale.
Conor Doherty: Okay, thank you. I’ll push on. If the numerical recipe—the decision-making plumbing—is the asset, who owns the versioning, rollback, and guardrails, and how do you handle model depreciation when market dynamics shift?
Joannes Vermorel: Yes, the numerical recipe is not the only asset. At Lokad, we have another thing that is equally important: what we call the joint process manual, which is the grand manual of the initiative. The numerical recipe tells you the what—literally, how do I generate my decisions every day—and it gives you what is happening at every stage. That’s the code: the code tells you what calculations are being done. The joint process manual—which is intended for humans—gives you the why: why did we choose to prepare the DR that way? Why do we choose to have this modeling rather than another? Why do we decide to express an economic driver this way or that way?
The combination of the two—the what and the why—are really the assets. The numerical recipe is very important, but it’s only half of the picture. The document that describes the why is also critically important, because that’s your entry point to know what you want to improve. If you see, “Why did I do that? Oh, it’s a crude approximation just because I didn’t have the time to do anything better; let it be,” that’s in the why—it’s the documentation that will tell you, also, the supply chain scientist “if and then.”
Absolutely, you need code versioning, auditing; there should be a process for the release. Ideally, you need plenty of processes to check that what goes in is correct, what goes out is correct, etc. Who should control that? The answer is: supply chain. It should be under the umbrella of supply chain management. Ultimately, it is the supply chain director or head of supply chain who is responsible for that. It cannot be IT, because fundamentally you are generating supply chain decisions. Ultimately, the responsibility is in the hands of the person who is in charge of this, just like it would be the responsibility of marketing to spend wisely their Google AdWords budget.
Yes, spending money on Google AdWords may require tons of tooling, but ultimately it is up to marketing to decide if they want to bank on some keyword and how much, etc. They have to take their own responsibility. Same applies here.
Conor Doherty: This is a bit more technical. From a CFO’s perspective, what hard evidence would you show an auditor to justify capitalizing your decision engine versus expensing ongoing operations? Or is this primarily a philosophical position and not a strict accounting one?
Joannes Vermorel: From an accounting perspective, you don’t necessarily have to do that. Some companies do that—for example, among software companies, some decide to capitalize funds when they have software engineers that spend time on that. Some do not. It is more a matter of accounting clarity. For the CFO, I would say: don’t get too carried away about the fact that you can capitalize immediately the money invested, because if you do that—that is, by the way, a problem that software companies are facing—it gives a vision way too positive on spending money on this thing.
If, in accounting terms, whenever you spend a million dollars on a piece of software you say, “Don’t worry; the value of the asset increases by one million dollars automatically,” then you end up with a very strange problem that is not driven by reality. My take would be to take that with a grain of salt. From an accounting perspective, look at how accounting is done in software companies and stick to those general principles, which vary from country to country.
It is really a philosophical principle: Am I investing money on something that will have leverage in terms of impact? Am I spending money so that I can survive the day, or am I investing to make tomorrow better? When I say CapEx, you need to think, “I spend money and time and effort only on things that will make tomorrow, the day after tomorrow—indefinite future—better.”
And indeed, it does depreciate—that’s absolutely correct. As a rule of thumb at Lokad, it does depreciate relatively rapidly. At Lokad, I would say every two or three years, we end up completely rewriting our numerical recipes. So it’s not an incredibly long-lived asset, but still, that makes an enormous difference when you say that you have an asset that will depreciate within three years, as opposed to something where, if you stop spending, then tomorrow the flow stops just because decisions are unmade. Even if we’re not yet having an asset that will live for decades, it can live, and it does live, a few years—sometimes a little bit more in companies that are not too extensively disrupted. Obviously, the amount of disruption really accelerates depreciation.
Conor Doherty: I have no further questions or comments. But before we close, we’ve covered a lot of ground here today. Sixty-second call to action for everyone who’s been listening and everyone who will listen to this later.
Joannes Vermorel: Do make sure that every single investment for your supply chain is accretive in improving this decision-making machine. That’s your key takeaway. Think of your supply chain organization as a decision-making machine. Forget about having correct forecasts, correct planning, correct bureaucratic tasks. Those things are just artifacts; they are not generating any profits. The only things that are generating profits are the decisions that you are taking and executing.
You should be thinking of your organization as a machine to generate that, and you should be thinking: Is the money that I invest just to keep the machine running—like electricity or fuel—or is it engineering efforts, integral efforts, to make it better? My take is that, yes, there is a mix of both. For most companies, it’s literally almost 100% on just keeping the machine running—pure OpEx—and once a decade a big dose of CapEx with a vendor. I would say it’s wrong. You should really think of it as doing it much more incrementally, because, when it comes to those intellectual undertakings, this drop of investment every day has a much higher return as opposed to doing it once a decade and pouring millions, and then nothing for a decade. These on-off techniques work very poorly, and that’s a good way to make enterprise software vendors rich but not your company very profitable.
Conor Doherty: All right, Joannes, we’re out of questions, and I think we’re out of time. As always, thank you very much for your answers, and to everyone else, thank you for attending.
Thank you for your questions and thank you for the private messages. I know with some of these topics they’re a little bit internally sensitive, so sometimes people are a bit shy about publicly commenting what they really feel. But I speak for both of us: we do appreciate when we receive those messages, and the people who asked private questions will recognize that some that I asked were ones that were privately sent.
So, in other words, don’t be afraid to get in touch. And on that note, get back to work.
