Summary
A session on why enterprise IT spending is often misdirected and how to fix it. We will explore why most budgets go to records and reporting software instead of decision software, whether AI can improve your ERP, and how to measure the real impact of your software choices.
Full transcript
Conor Doherty: This is Supply Chain Breakdown, and today we will be breaking down where you are—in fact, despite what you might think—paying way too much for your ERP. My name is Conor. I’m Communications Director here at Lokad, and to my left, as always, Lokad’s founder, Joannes Vermorel.
Now, before we get started, please comment down below: how much are you paying for your ERP? We won’t tell anyone. Manning the chat as always, our producer Alexey—Alex, say hello—get your questions in, and he will filter them to us.
Now, Joannes, before we get to the main event, you alluded earlier today on LinkedIn to some seismic news. I’m not going to spoil it for the world, but what do you need to tell people?
Joannes Vermorel: The Introduction to Supply Chain is out. This is 18 months of work. When I was not actually running Lokad, I was using the spare time to write this book, and now, absolutely, it’s 51 pages of… not romance. It’s a little bit more dry, I’m afraid; it’s a little bit more dry. Nevertheless, it is, in writing, the descendant of the lectures, and it’s more up-to-date than the lectures.
It’s the up-to-date vision of how Lokad sees, views, and practices supply chain. Yeah.
Conor Doherty: So it expands on what you’d written in the Quantitative Supply Chain book previously—a much more crystallized, all-encompassing explication of your philosophy.
Joannes Vermorel: Yes. And by the way, it doesn’t talk about Lokad. It’s really focused on the domain, the field of studies and practice, independently of the fine print of what Lokad is doing.
Conor Doherty: Oh, well, for anyone who is interested in learning more about that, we’ve already created the event for next week’s episode, which will be entirely about Introduction to Supply Chain—a discussion on the theories and the main practices that you are now espousing in a little bit more detail. And we’ll get to some of the more spicy takes, because, you know, I’ve read the section on consultants. It’s worth covering.
But again, that is next week. Alexey, please drop the link to that in the live chat, and you can register for that now. If there’s nothing else to say, Joannes, let us—without further ado—get to the main event.
In another of your writings—this is, I think, 18-ish months ago—you wrote an article, The Three Main Classes of Enterprise Software, in which you outlined your view of how IT budgets should be spent on three given categories of software. Could you expand on that for anyone who has not read it?
Joannes Vermorel: The short gist is three categories, which are enterprise systems of record, systems of report, and systems of intelligence.
System of records: it’s your electronic ledger—glorified ledger. It creates the electronic counterpart of the information that characterizes your enterprise: what do you have in stock, what is your list of products, what is your list of stores, have you paid your suppliers, have you received money from your clients—all the super-transactional stuff. System of records.
Reports: it’s a system that lets end users—corporate end users—in a self-servicing mode generate descriptive statistics based on those very same records.
And systems of intelligence are about generating decisions. Again, the archetype of the system of intelligence is the anti-spam filter—quite an important decision: mail that you will never read because a piece of intelligence decided it was not worth your attention.
BI tools—business intelligence tools—are systems of reports. Systems of records, that’s really the bulk of the class: everything with management—WMS, YMS, CRM, etc. And ERP—which should be named ERM—are part of that as well.
The first point is spending. Nowadays, systems of records—anything “management”—are like three-quarters of the spending. Literally, almost all the money that large companies (or not so large) are spending is on systems of records. The ERP is typically the one thing that is more than half of the budget. It varies a little, but let’s say ERP plus CRM are definitively the elephants of the room.
Conor Doherty: The immediate follow-up is: what’s the problem with that? What’s wrong with allocating 50%, 75%, 95%? What’s the problem?
Joannes Vermorel: The problem is that since the late ’90s, prices have been growing for those products, despite the technology being increasingly commoditized—to the point where it’s completely commoditized nowadays. You would expect that something that is not fundamentally delivering more—a technology not superior to what it was 30 years ago—should be dirt cheap.
Technology to produce software costs orders of magnitude less than it did 30 years ago. Computing hardware is orders of magnitude cheaper. The quality of open-source tooling—databases, web servers, application frameworks to create apps swiftly and reliably—has skyrocketed. Open source alone has completely commoditized tons of problems.
Why, in this situation, do many companies—putting aside inflation—still pay twice or three times what they were paying 30 years ago for something where they should be paying ten times less? Considering the progress observed, this is extremely strange to me. Obviously, there are reasons—I understand them—but it’s a massive mistake done on a grand scale.
Conor Doherty: In that same article, you gave rough numbers: let’s say 75% of an IT budget goes to systems of record, 20% to BI tools like reports, and maybe 5% to what is effectively decision software. Whatever one thinks about the division, what actually moves the needle in terms of financial bottom line? I’m paraphrasing, but you said it’s not your records, it’s not your reports—it’s the decisions that you make. Expand a little on that: how does decision software move that needle?
Joannes Vermorel: Let’s look at inventory. You have an inventory management system. This system is counting—counting how many units come in, how many go out—and gives you the delta, which is your stock on hand, electronically. This was already working in the late ’70s. Electronic inventory management is super ancient, and you can have similar situations for production and everything. Those are your systems of records.
Now, what happens is that all those systems of records are branded and marketed with the idea that you will have less stock and fewer stockouts. For me, this is where things get very strange. An inventory management system manages, but in the sense of an accountant—like an accountant manages your accounts. It doesn’t take any kind of intelligent, profitable decision. That would be the realm of systems of intelligence.
Yet vendors have, since the late ’70s, fostered a massive ambient confusion: even if you are selling essentially record-keeping, you would say “less inventory, fewer stockouts,” which doesn’t make sense.
By the way, this charade with systems of records happened again with systems of reports: I give you statistics on your average stock levels, your average sales, average this, average that, and then I say you’re going to have fewer stockouts and less stock. No. It’s not because I give you descriptive statistics that you have better outcomes. Somebody must ultimately make the decision, and then it generates the return on investment.
What you’ve effectively done—for systems of report—is increase a little bit the productivity of the person chasing the numbers. It’s useful, but does it justify such an amount of money?
My criticism is that these commoditized technologies are not fundamentally generating substantial return on investment. Yes, they are necessary, but electricity is necessary for your business; there is no reason to spend multiple percent of your annual turnover on electricity unless you’re doing something extremely power-intensive.
Conor Doherty: If you say that something’s too expensive for what it does, that implies you know what it is for—the goal of a thing. Underlying this philosophy, what do you see as the goal of ERP—whatever way it’s used now? What is the goal of that system of record?
Joannes Vermorel: The goal should be the digital counterpart of the transactions—and nothing more. Obviously, vendors are going to present that as more. My counter is: if you try to make it anything more, you’re heading into trouble. Do not elevate your accountant as a company strategist. It’s bad.
If you look at CEOs of large companies, they are not former accountants—and there are very good reasons for that. The thinking that goes into accounting and strategic decision-making is water and oil. They do not mix.
The distinction bleeds into software. If you are doing software that is about records, you’re not in the sort of thinking of decisions. It is very different. People who are very decision-oriented typically make extremely poor accountants, precisely because imagination is not a quality in an accountant. As a business owner, if I were to see an accountant tell me, “I’m a very creative guy,” I’d pass; I’m going to take the one who is not creative.
The nature of the work is clerical. You want to be a faithful, extremely mechanical representation of your business. This is your mission: don’t be creative; don’t do anything fancy. This is only going to be counterproductive.
Conor Doherty: In the article you gave an imagining for what you think would be an appropriate budget allocation—back-of-the-napkin maths. Essentially an inversion: if current spending is 75%, you think it should basically be 20% on systems of records, 5% on systems of reports, and then the bulk on decisions. Before we get into that, how do you propose measuring the ROI on a tool like a system of records that you describe as being very… “there’s one cup on the table; if I move it off, there’s no cup on the table.” That’s what I want: total accuracy from a system of records. How do you measure ROI on any volume of investment in a system of record?
Joannes Vermorel: That’s very difficult. It enters the category of the cost of doing business—like electricity. If you don’t have it, this is a massive problem; thus, you need it. But then you assess: it’s a pure cost center; you need to minimize this cost.
Why am I saying it should be like 20%? Because so far, those management systems were easily, in most companies, 75% of IT spending—often higher. My take, with commoditization, is that the cost of producing software has been divided by at least a factor 10. Even with “vibe coding”—coding with ChatGPT or an LLM—the cost might be divided by two orders of magnitude, a factor of 100.
So if we go from 75% to 20%, I’m saying divide by three or four. It’s not even the full extent of commoditization, but it’s a start. As a start, if you do not shrink this software to a fraction—divide by three or four—you’ve not started to capture the benefits of this commoditization. And this commoditization is real and strong.
All the major pieces of your ERP: the database—PostgreSQL, open source, excellent. You don’t need an expensive Oracle database or IBM Db2. Web servers—same thing, many open-source options. It’s true for many components.
Bottom line: even if you want to produce it in-house, it is actually very cheap. And by the way, Lokad—which is not a very large company, about 60 people—we have just reimplemented a very complex B2B CRM, AI-augmented, web-based. The total cost is below something like €200,000. With tons of bells and whistles. It’s cheap.
I see clients—billion-plus companies—spending tens of millions of dollars or euros, plus time frames that are insane: five-year upgrades for an ERP. Absolute insanity, especially for technologies that are completely commoditized. We’re not talking rocket science. No. We’re talking CRUD—create, read, update, delete—pretty much the default for systems of records for the last 40 years. The technology is stagnant. Yes, you have web and mobile interfaces, but just a little on the UI; the rest is stagnant.
Conor Doherty: A lot of what we say at Lokad is framed in the context of ROI—very financially driven. I want to frame this very crisply through a metaphor you’ve used. Previously you said there’s theoretically—and actually—no upper limit to how financially rewarding decisions can become as more data becomes available. The financial reward to getting better and better decisions: there’s no ceiling, theoretically only the resources in the world.
Do you see that applying here in terms of the ROI you can extract from a system of record versus a system of reports versus decision software?
Joannes Vermorel: Systems of records are the electronic counterpart of a glorified accountant. There will be no sky-high return on investment. It is the cost of business to operate in a digital world. If you don’t do that, you have massive inefficiencies. But again, that doesn’t mean you should be spending millions on “electricity” unless you’re power-intensive.
For systems of reports, you’re getting descriptive statistics. This is nice, but you’re paying twice: first to generate the statistics, then to have people looking at the numbers. Costs skyrocket very fast. At some point, people should stop looking at the numbers and actually make decisions.
Take stores: if the store manager spends the entire day looking at spreadsheets, the store is not going to be properly attended to. Maybe look ten minutes a day at sales figures to get some insight; then go back to putting things on shelves, making sure everything is neat and tidy. For large corporations with BI tools, diminishing returns arrive quickly. Having more numbers, spending more on that—you should be moving into action territory: decisions.
Conor Doherty: If I were to summarize that—previously you said a dashboard can only look so good before you’re just making the colors slightly snappier, but fundamentally the information is already there.
Joannes Vermorel: You can tweak the definition of a KPI endlessly, but ultimately, you have to act for the business to improve. Contemplating numbers by itself is just a means to an end, and it comes with very severe diminishing returns.
Conor Doherty: You’ve multiple times used the term “cost center” to describe systems of record and systems of reports—ongoing expense. Previously we talked about supply chain: is it capex, is it opex? Would you apply that filter here more granularly to say decision software would be capex, and the other two categories opex?
Joannes Vermorel: The idea is: can you do something of real strategic value with a system of record that will skyrocket the value of your company? Maybe for some businesses, but for the vast majority, no. There is not enough leeway. Famous brands selling sports shoes—think Nike—already have an excellent electronic counterpart of their physical activity.
Could they extend systems of records to record things that would really transform the business? I doubt it. Ultimately, you have a good capture of what’s happening through transactional lenses, and there is not that much value in extending it further. You need it, but it becomes part of the background noise. You cannot differentiate yourself.
Cost center versus strategic component: can you really get a competitive edge versus the competition? What I’m saying is systems of records—not having them is a massive problem. But any company past €10 million of annual revenue has them. Once you have them and they are decent, the competitive edge to be gained by making them better is super small compared to having better decisions.
History is filled with successful entrepreneurs who took subtle ideas seriously, pushed them strongly, and made their company’s fortune. Better decisions are a very smart—or as smart as you can make it—profitable allocation of scarce resources: money, people, everything is limited.
Because there is no limit to what you want to allocate, you can restrict the problem—allocating inventory to stores—or expand it: open new stores, partner with existing stores to place your products, etc. In decisions, when I say it’s unlimited, there is no formal limit—if you’re willing to revisit scope. Boundaries and limits become fuzzy on what is an acceptable decision. It’s an open problem.
Conor Doherty: Listening to you differentiating between ERP (systems of record) and systems of intelligence (decision-making software), I’m reminded of a friend of the channel, Eric Kimberling. He covers a lot of enterprise software Hindenburgs—lots of failures.
Something I’ve never seen him report—and I’ve never seen on LinkedIn in general; it may exist, feel free to send me examples—but I’ve never seen anything approximating the headline: “Multi-billion-dollar company wastes $500 million on better decision-making software.” What I have seen many, many times is: “Multi-billion-dollar company squanders vast sums upgrading their ERP.”
Joannes Vermorel: Absolutely true. Several angles. ERPs are considered must-haves. Fundamentally, there is no clear upper limit to the price you should be spending on them. We say it’s necessary. If it’s necessary, you need to invest whatever it takes—yes—but this price must be low; otherwise you’re doing it wrong.
When you say “cost of doing business” like electricity, you will spend whatever it takes to have electricity—true—but it’s only valid because electricity is, in most places, dirt cheap. Vendors play on that to bill clients extravagant fees spread over many years.
Eric pointed out, for companies with an ERP working just fine—stable, reliable—you do not need to upgrade “to the cloud.” If you have something that works, a cost center with modest cost, and functionally it does what you want—accounting-style: the books are kept correctly—there is very little upside to modernizing your ERP.
It’s like: I have a very diligent accountant—reliable and cheap—and now I want an accountant who just graduated from Princeton or Harvard—great ring to it—but five times more expensive than the old one who was already perfectly reliable. If it’s not broken, don’t fix it.
For systems of intelligence, the reason you don’t get those half-a-billion catastrophes is that from the start you want payback. You’re in decision-making; you’re thinking of ROI. If after a few months it’s clear this vendor is never going to generate those decisions, the company says, “Okay, we stop,” and we keep people doing it manually. The BATNA—best alternative to a negotiated agreement—is to keep people taking those decisions manually.
Very quickly, if the cost of your decision-making software starts to come close to the cost of people doing it manually, you’re out. That’s why you don’t see five-year, hundreds-of-millions projects in systems of intelligence. The premise is: we will make you more profitable by better decisions and with more automation.
Think of an anti-spam filter: if the cost is more than having a secretary manually filter your mail, you’d say, “Hold on, I’m not going to spend millions when I could pay a secretary.” It puts a hard limit. This is not like ERP where you say “I need it, otherwise I’m screwed.” Here, there is the very real possibility of people with spreadsheets; it kind of works. So companies won’t keep burning money for years.
Conor Doherty: To frame this as a thought experiment—and I’m not dog-piling on Lidl; I like Lidl—but if you took the decision-makers at Lidl and said: “Is there an upper limit to how good your ERP can be? To how good your BI tools can be? Any financial upper limit to how good your decisions could be?” I’m pretty sure they’d agree with you. Yet the decision-making at the end doesn’t align with that reality. Why the asymmetry?
Joannes Vermorel: With Lidl, in their catastrophe, they were essentially buying a system-of-intelligence module from SAP. The problem is they had a vendor—a pure system-of-records vendor—that completely framed the decision problem in the paradigm of a system of records. That’s a dead giveaway. From the start, it was a very badly framed project.
They should have said: demonstrate you can have this up and running in three to four months for 100 stores, then we expand if it works. But they went for a crazy, complex project, following the philosophy of a system-of-records vendor. Oil and water: do not mix. Do not try to have a person who is both Steve Jobs and an accountant.
Conor Doherty: There are several questions and comments coming through from Alexey, so we’ll transition to that in a moment. One closing question: earlier you described the perception associated with an ERP—it’s a must-have. There’s a growing movement around “decision-first” practice—some of the people even in the chat today: Hey, Warren Pal; we’ve done interviews with Adam Dejans Jr., Cristina Radu, and Oscar Schneider. Lots of people post about decision-making as the primary driver.
What would have to happen, in your opinion, for that perspective to break through the ceiling and elevate the discussion to: “I must have a system of intelligence—decision-making software”?
Joannes Vermorel: I don’t think “must have.” Records are necessary first—not in the sense of most important, but antecedent: you need electronic records before clever automation on top of them. Yes, records come first. The important thing is to acknowledge it’s a problem with fully commoditized solutions, and you need to embrace it that way.
If you buy an internet access at home and somebody tells you, “I can give you a $50,000 internet access,” you’d think, “This is nuts.” You’re thinking $50 per month. Because it is commoditized. You know these things can be done at this price, so you won’t entertain discussions that are orders of magnitude higher. That’s the right attitude: completely commoditized; approach with aggressive cost-cutting.
For decisions that come afterward: software is expensive—especially decision-making software; it is more subtle than dumb, crude apps. You need scale for decisions. If it’s a decision made once a week, most likely a person is cheaper. You need decisions taken dozens, hundreds, thousands of times a day—many companies have that.
For high-frequency decisions, systems of intelligence are obvious. For very infrequent, not quite. Keep in mind the cost of having a smart person deal with it. If it occupies very few people and it’s a subtle decision made infrequently, it’s probably not a good candidate for a system of intelligence. If it’s something like repairs of airplanes—something very detailed where the decisions are extremely granular, and just entering the decision takes time—then yes, the upside is obvious.
Conor Doherty: Thank you. I’ll switch to questions/comments. This one is from Mel: the problem is not the unavailability of more cost-efficient ERP alternatives; it is lock-in. Joannes, how do you view the role of the MCP for unshackling companies from their extraordinary ERP vendor? MCP is “system of decisions” essentially.
Joannes Vermorel: I think companies overestimate the amount of lock-in. Usually, it’s more in their mind than in reality. They have access to the underlying databases—the raw materials. The vendor doesn’t give you the code, but they are not doing incredibly fancy things either. Basic rules.
If you want to piecewise reimplement in-house with open-source components, you roll out your own PostgreSQL database plus the Django framework in Python, and you roll out, piecewise, functional areas of your ERP to gradually phase out a system. I have seen very few companies truly suffering vendor lock-in. True lock-in is when you cannot access the raw database. It happens sometimes, but it’s rare.
If you define vendor lock-in as “the vendor who sold you your ERP is not cooperative,” that’s essentially 100% of the time. Do not expect the vendor to cooperate in their own phase-out. Most of the time, you can access the raw database. You might not have the documentation, but those things can be reverse engineered. Not the end of the world.
Conor Doherty: Before I read the next one, a reminder that legal said: careful now. From Manuel: “What about the supposedly intelligent modules sold by ERP software companies like SAP at high prices? What is your take?” Careful now.
Joannes Vermorel: Since the late ’70s, enterprise software vendors were not fools. They realized the value lies in decisions. But they also realized very early that decisions are tough. It’s so much easier to digitalize records—having an inventory management system that counts stock levels is a piece of cake compared to getting good inventory decisions.
Vendors went all-in on systems of records and created value, but when selling inventory systems, they would not say “you will have accurate records”; they would say “fewer stockouts, less stock”—the decision wheel. In the ’90s, “planning” was introduced into ERP—Enterprise Resource Planning—to rebrand management systems as more decision-oriented. Vendors perceived the end of value-add from mere digital coverage and needed to move to decisions.
Technology-wise and culture-wise, decision-making is not compatible with record-keeping. Maybe to defend vendors of the time: in the ’90s it wasn’t completely clear. The dominant machine learning was expert systems; people thought rule-based design—the core of systems of records—could scale into meaningful intelligence. It doesn’t.
I can give them slack for not realizing that in the ’90s. Past 2000, it was very clear.
Conor Doherty: Comment from David Rollingson: you have to know where you are, where you want to go, and work collaboratively to make good decisions. It’s not just a matter of software. Your thoughts?
Joannes Vermorel: I agree. A decision needs to be informed; it needs to be faithful to the strategic intent of the company. This is nuanced, of course. The subtle discussion on faithful capture of something elusive—the strategic intent—which captures a specific way to look at quality of service through the lenses of this company: that’s precisely the culture difference between systems of records and systems of intelligence.
When you’re doing systems of records, you don’t have to deal with extremely subtle, nuanced things. “Is this unit on the shelf? Yes or no.” “Is this the correct tax rate? Yes or no.” In systems of records, questions have binary answers. There is very little room for subtlety. It’s like an accountant: the books are correct or incorrect; you’re tax-compliant or not.
If your accountant tells you, “In terms of tax compliance, we are in the gray,” as a business owner you’d think, “No, I want to be absolutely compliant.” But in terms of strategic intent, you deal with shades of gray—only shades of gray. You need tools that embrace ambiguity and uncertainty. Dealing with ambiguity is very much something that exists in systems of intelligence.
Think of anti-spam filters: maybe an email from an e-commerce website telling you your product will arrive in two days is not spam, but a promotional email from the same sender is spam. You need nuance. Same sender, depending on content, is spam or not. Systems of intelligence handle this. Systems of records do not deal in those subtleties.
Conor Doherty: Question from Oscar Schneider: what have been the main factors for failure in the Lidl project we alluded to earlier? Cliff notes.
Joannes Vermorel: Ultimately, the main factor was broken supply chain theory. The mainstream supply chain theory does tons of crazy things: time series analysis as done in the mainstream is completely bogus; the point-forecast perspective is completely bogus; the lack of economic framing is completely bogus. The technological stack used by SAP in this specific case—SAP ERP—was completely bogus for this purpose, etc.
They probably had dozens of problems—each one would guarantee failure. Put together, they created so much confusion it took them seven years to call it a day after wasting half a billion. People say “death of a thousand cuts,” assuming each problem is not definitive. Here, the cuts were guillotine-deep. The body was sliced into thin layers; each cut was lethal, and there were many.
Conor Doherty: If anyone from Lidl is watching, reach out. We will provide a free copy of Joannes’s book, and you can sidestep all those landmines and guillotines. Let us push on.
Question—I’m paraphrasing slightly—from Maha: do you think supply chain leaders have not challenged enough their IT counterparts on allocation, etc.?
Joannes Vermorel: I would not blame supply chain leaders. Usually, the decision is made for them without them having a vote. For systems of records, it’s typically a deal closed by seducing the CEO, CFO, and the board. The supply chain director, in many companies, would not even get a vote. I would not put the blame on them.
They could be better advocates of alternatives, but the trio that bears responsibility—for extravagant spendings—is CEO, CFO, and CIO/CTO, potentially with a board giving blanket approval for very big spending.
Conor Doherty: Question from Pra Prevari—excuse me if I mispronounce. For the system of intelligence, can we not just use the current ERP as it stands, take necessary data extracts for the AI solution to process, and then deliver results back to the ERP system? You’re already shaking your head.
Joannes Vermorel: Yes. That’s exactly what Lokad does. We extract all the data from the ERP because we do not want to operate within the ERP. If you do anything computationally intensive, you slow down the ERP, which is super bad. An ERP needs to be snappy—stock level queries should answer in 50 milliseconds.
If you want to be fast, you should not starve the system in compute resources with a full network analysis. That needs to happen in a completely segregated system.
Also, uptime: if your ERP stops for a minute, transactions are blocked; big pain. A system of intelligence: if you cannot pass orders to your Chinese suppliers for a day, it’s a problem but not such a big problem. Uptime views are different.
So the proper way is clean, lightweight extraction—not even data preparation or joins—just raw table dumps, which are very cheap in resources. You put that in a different system. Once you’re done with the finished products—the endgame decisions—you re-inject them. The good news is those decisions are very light: if it’s a purchase order, it’s product plus quantity, a small envelope to re-inject into the ERP. In terms of IT interface friction, it’s limited.
Conor Doherty: Last question from Manuel: in my experience, implementation of decision systems in companies is limited by the ERPs in use because IT always needs to do some of the work, and they are typically overloaded with tasks. Thoughts?
Joannes Vermorel: I have seen this very frequently, but this is a deep cultural mistake. The mistake is to treat systems of decision—because it is software—as something that belongs to IT. This is not the case.
The core infrastructure of your company—systems of records—does belong to IT. Not the decisions. Decisions are completely domain-specific. They require deep domain insights.
Example: spending money on Google AdWords is not an IT problem. You need to know the ROI when you bid this much for this click on this keyword and how much it converts. Very domain-specific. It should not be expected of IT to solve it.
There are systems of intelligence in every division: marketing, sales, finance, supply chain. It’s segmented because the type of decision requires domain expertise that mirrors those divisions. The mistake is to put something that requires massive domain-specific expertise—supply chain, for example—in the hands of IT. It fails, because the core competency of IT is not decision-making.
You need to bring it back to the division, which means people may deal with software projects not part of IT but in their own projects. Guess what? This happened in marketing more than 10 years ago. Marketing departments spending on Google AdWords have used programmatic tools for more than a decade. They had to embrace this competency to succeed at games like AdWords with tens of thousands of keyword combinations, hundreds of messages, constant A/B testing, powerful tools.
Divisions embraced a programmatic approach a decade ago. You can do it internally or use specialists—Lokad would be a specialist for supply chain—supplementing your teams. The technicality cannot be avoided. You end up with a system of decision, which is a complex, usually bespoke software project for the company. Sometimes the complexity is too high and it’s not worth it—humans still win in cost-effectiveness—but when you have to take decisions at scale—Google AdWords, or allocation for the flow of physical goods in supply chain—software is a very promising candidate because of the granularity of the decisions.
Conor Doherty: Joannes, I don’t have any further questions. As always, thank you very much for your time and your insights. And to everybody else, thank you for attending, for your comments, for your questions. The interest in the book—there is quite a bit. As I said, next week’s episode is already live. The registration link is in the live chat here; we’ll post it again later.
Be sure to attend to learn more about Joannes’s magnum opus and how it can help your supply chain—and you can avoid becoming the next Lidl. On that note, I have nothing else to say. See you next week. Have a good evening, and get back to work. It’s a good one.
