00:00:00 Lokad’s founding story and early years
00:02:31 Misconceptions about Supply Chain optimization
00:04:31 Existing supply chain theories did not work
00:06:32 The paradox of forecasting failures
00:08:33 How “forecasting nothing” beat competitors
00:10:25 The challenge of rejecting established ideas
00:12:00 Pivoting to probabilistic forecasting
00:14:07 The importance of extreme demand scenarios
00:16:32 The complexity of enterprise data integration
00:20:55 Why supply chain models on paper fail
00:27:30 Engineering problems in enterprise AI adoption
00:35:00 The impact of COVID-19 on supply chains
00:42:49 LLMs are text-based, not mathematical
00:50:25 The financial industry’s parallel evolution
01:09:00 Q&A and final remarks
Summary
Joannes Vermorel, CEO and Founder of Lokad, delivered a lecture in French, sharing his journey in Supply Chain management. Vermorel recounted founding Lokad after graduating from École Normale Supérieure and shifting focus from bioinformatics to Supply Chain challenges. He discussed the development of Envision, Lokad’s programming language, and the company’s evolution since 2007. Vermorel criticized traditional Supply Chain theories, likening them to astrology, and emphasized the importance of challenging consensus. He highlighted Lokad’s success with probabilistic methods and the impact of COVID-19 on Supply Chain robotization. Vermorel predicted the obsolescence of traditional roles and encouraged students to drive the industry’s revolution.
Extended Summary
In a lecture delivered to students in French, Joannes Vermorel, CEO and Founder of Lokad, shared his journey and insights into the world of Supply Chain management and the evolution of his company. Vermorel began by introducing himself and recounting the origins of Lokad, a company he founded right after graduating from École Normale Supérieure. Initially, Vermorel attempted to pursue a thesis in bioinformatics but soon realized that the field was already saturated with talented individuals. By chance, he stumbled upon the challenges of Supply Chain management, which became his new focus.
Vermorel expressed his surprise and delight at seeing students from Centrale using Envision, a programming language he created for Supply Chain optimization. He recounted the development of Envision, noting that the first compiler he wrote was quickly replaced by a superior version created by Victor Nicolet, Lokad’s CTO. Envision has since evolved significantly, with the company now on the verge of releasing version 6.
Lokad’s journey began in 2007, with the company officially founded in 2008. However, Envision was not introduced until 2013, five years into Lokad’s existence. Vermorel explained that the decision to create a new programming language came after exhausting all other alternatives. Initially, he believed that the Supply Chain was a well-established field with decades of literature and numerous competitors like SAP, Oracle, IBM, and Microsoft. He thought the key to success would be repackaging existing Supply Chain theories into web applications, leveraging the shift from client-server applications to cloud-based solutions.
Despite his initial confidence, Vermorel soon discovered that the established theories and models did not work as expected. He recounted a particularly absurd experience in 2011, where Lokad won a benchmark by submitting zero forecasts, which outperformed competitors by 20% in accuracy. This experience led Vermorel to question the validity of traditional Supply Chain theories, likening them to astrology rather than astronomy.
Vermorel emphasized the importance of challenging consensus in science, noting that history is filled with examples of widely accepted but ultimately incorrect beliefs. He concluded that while the Supply Chain itself is a legitimate field, the classical theories underpinning it were flawed. This realization prompted him to explore alternative approaches, such as biased forecasts and quantile predictions, which proved to be more effective.
Lokad’s approach evolved to embrace probabilistic and programmatic methods, moving away from traditional models that failed to address the complexities of real-world Supply Chain problems. Vermorel highlighted the importance of having a robust programming language tailored to these challenges, criticizing the use of general-purpose languages like Python, which often led to failed initiatives due to various technical issues.
The lecture also touched on the impact of the COVID-19 pandemic, which accelerated the robotization of Supply Chains. Vermorel noted that Lokad’s solutions proved effective at large scales, managing stocks worth billions of euros with minimal human intervention. This shift mirrors the transition in the finance industry, where trading has become predominantly algorithmic.
Vermorel discussed the future of Supply Chain management, predicting that the traditional roles of inventory managers and demand planners would become obsolete as more companies adopt automated decision-making processes. He encouraged students to be proactive in driving this revolution rather than merely observing it.
In response to student questions, Vermorel explained that companies with a strong technological focus might internalize Lokad’s solutions, while others would likely continue to outsource these services. He also addressed the limitations of large language models (LLMs) like ChatGPT, noting their lack of learning and memory capabilities.
Vermorel concluded by reflecting on the irrationality of markets and the persistence of failed projects in the Supply Chain industry. He shared anecdotes of competitors who repeatedly raised substantial funds despite past failures, highlighting the chaotic nature of the market. Despite these challenges, Vermorel expressed pride in Lokad’s achievements and the unexpected success of Envision among students from prestigious institutions like Centrale. He invited students to consider joining Lokad, emphasizing the company’s ongoing recruitment efforts.
Full Transcript
The original speech in French was translated to English.
Joannes Vermorel: Let me introduce myself: I’m Joannes Vermorel, founder of Lokad. I created the company when I finished school. I was at École Normale Supérieure, started a PhD in bioinformatics, but in the end, so many people were doing interesting things in bioinformatics that they probably didn’t need me. And by chance, I came across these supply chain issues. I’m very happy to see that you’ve been using Envision today. It’s quite something for me to find myself in front of Central students talking about this language. It’s something I would never have imagined back when I created Envision, which was about twelve years ago.
I wrote the first Envision compiler, then Victor Nicolet—Lokad’s CTO—threw it out and quickly wrote the second compiler, which was much better. And now you’re basically using version 5, while version 6 is about to be released. The language has evolved a lot. But what you worked on—the piece you’ve seen—wasn’t at all where Lokad started. It came quite late in fact. Lokad is a project that began in 2007 and was incorporated in 2008, whereas Envision is from around 2013. So when Envision arrived, the company was already about five years old.
The idea of creating a language came after we had exhausted all other alternatives; it was not the visionary founder’s plan from the start—simply that everything else we tried had failed.
To give you an idea of what’s so surprising about supply chain: when I launched Lokad in 2008, my view was that supply chain was a well-established field. After all, there are 60 or 70 years of literature about it, literally millions of papers. If you type “supply chain management” on Amazon, you get—I checked—around 10,000 books currently available on the topic. Over the decades, many more have been published, but those 10,000 are the ones still for sale now. It’s a hugely documented field.
When I started, I saw big competitors with big names: SAP, Oracle, IBM, even Microsoft—major players in supply chain. If you sum the total revenue of your competitors, it’s half a trillion dollars. That’s significant. My original intuition—completely wrong as it turns out—was that I could take the established supply chain theories and simply repackage them into a web app. It was 2008, and all enterprise software was shifting from so-called “thick client” apps, which you install on your PC, to “thin client,” i.e., web apps. So there was this opportunity to rebuild supply chain software as a web app, possibly with cloud hosting. Lokad moved to the cloud very early. That might give us a lead over large companies still on older, heavier client-based systems. And since there are literally entire books explaining how to optimize supply chains—like the MIT manual, the Stanford manual, the Caltech manual—I read them, all these 1,000-page volumes written by two or three professors with all the equations.
I then coded those approaches—and nothing worked. Interestingly, that didn’t prevent Lokad from growing or having customers. You’d think that to make money as a startup you need a product that actually works, but in enterprise software, you can sell something that doesn’t work at all, and still find clients. It might sound strange, but that’s how it is. The reality is, if there’s a big problem a company wants to solve, there’s a budget to try and solve it. This budget might not be huge—especially if your product doesn’t actually work—but for a startup, those sums can seem very large. If a giant like Carrefour puts 100,000 euros on the table “just to see,” that’s nothing for Carrefour, but it’s a lot for a small company.
So, leveraging that asymmetry, I started and attempted to implement these standard supply chain theories: time-series forecasting, safety stock, service-level optimization, etc. None of it worked; none of it at all. We had these rather schizophrenic discussions with clients: they’d say, “You must have coded the safety-stock formula incorrectly,” so we’d go back, literally take the values from the tables in the textbooks, re-check the parameters—and it was exactly as stated. So the theory was implemented correctly, but the outcome was total nonsense.
I think the height of nonsense came in summer 2011. We participated in a big RFP with half a dozen software vendors, half of them European, the other half American. Lokad was among the Europeans. The case, as I recall, was about ten supermarkets, 5,000 SKUs per supermarket, with the need to forecast a few days ahead because these supermarkets were replenished maybe two or three times a week. The client used a backtesting error criterion on daily product-level forecasts for each store—basically absolute error between forecast and actual. Lokad ended up winning that benchmark—by 20% better accuracy, absolutely crushing the competition. My secret method? I sent back zeros. Zero for everything. Thanks to my “zero forecast,” I also beat everyone else in calculation speed: returning zeros is extremely fast. And I got 20% better forecasting accuracy than the others. Even better, if you forecast zero demand, you won’t replenish the store, so in two weeks, the store is empty, which matches your forecast 100%. I was the king of statistics.
Obviously, that was complete nonsense. But if you consider the approach recommended by all the supply chain textbooks and the client’s standard process, it resulted in total absurdity. The conclusion I drew from that was quite unsettling. We had a profitable, growing company, but I was forced to realize I might just have stumbled onto some scheme. You can start something, it earns money, but it’s pure nonsense. Maybe at first you’re just too inexperienced to realize it. But once you do realize, do you keep going? When you graduate and discover what you’re doing is nonsense, do you continue? That triggered profound questioning. Could supply chain just be astrology—like the fortune-telling kind, not astronomy?
Eventually, I concluded that supply chain as a field is real, but that standard supply chain theory is basically astrology. That was the bug. It’s very hard to accept that 70 years of research, a million+ papers, thousands of professors, could all be wrong. Imagine the intellectual arrogance needed. If you see four different doctors, each telling you you’ve got the same diagnosis, at what point do you say they’re all wrong and you’re right? But science doesn’t work on consensus. A thousand people can agree on something and still be wrong. History of science is full of examples: extremely broad consensus on ideas that turned out to be crazy. Some who study the history of science even say that half of what any society believes at a given time is wrong; the tricky part is knowing which half.
So Lokad ended up with that conclusion from the benchmark: the mainstream way was nonsense. We had to look for something else. Our big breakthrough came in early 2012, going after biased forecasts with what is known as quantile forecasts. At the time, I had clients employing 50 people full-time just to remove bias. So they asked me, “Why on earth would you want a biased forecast, given we pay folks to un-bias them?” They were quite alarmed because the new method added so much bias they’d never be able to remove it manually. But if I call it “quantile forecasting,” it sounds more scientific than “biased forecasting.” In reality, though, a quantile forecast is just a biased forecast.
We tried this approach with our first e-commerce client. Overnight, we switched from absurd results—like forecasting zero for everything—to something mediocre but at least somewhat sensible. That might not sound amazing, but going from total absurdity to mere mediocrity was a big step up.
That then led us to revisit all supply chain assumptions found in textbooks—challenging every foundation, which turned out to be very shaky, basically wrong. Quantile forecasting is just the simple version of that. It’s a statistical tool that specifically looks at extremes. Economically, in supply chain, the extremes are where the money is lost: unexpectedly high demand that creates a stockout, unexpectedly low demand that creates overstock, unexpectedly long lead times that ruin your plans, etc. It’s never the middle of the distribution that really hurts you; it’s the tails. A quantile forecast is a tool that focuses on those extremes. An improved version is probabilistic forecasting—which is what you’ve been working on—where you get a full probability distribution. Back in 2012, we started with quantile forecasts because it was simpler in terms of math, statistics, and computing. Handling a probability distribution across millions of SKUs is much heavier than generating a single forecast number per SKU.
Meanwhile, Envision—which was originally developed for something else entirely, an internal project codenamed “Priceforge” for pricing—turned out to be perfect for addressing the new approach. Before that, Lokad’s idea was to build standard supply chain software with menus, buttons, and options, as is typical in enterprise software. But it was chaos from the software publisher’s standpoint: as you add more functionality, data-mapping from the client’s environment to your data structures becomes an engineering nightmare.
Why? Because clients’ data architectures are always unique. One client’s ERP might have 10,000 tables, each with 50 fields, many undocumented, used in unusual ways. Actually, they might have two or three ERPs, plus a WMS, plus an e-commerce platform… The ecosystem is complicated. No two companies have the same data definitions. Even something seemingly simple like “order date” can have 20 different definitions: date the record was created, date the customer confirmed the order, date you confirmed it, date the payment provider authorized it, date the order was shipped, and so on. Multiply that by a thousand other potential data fields.
If you create a “classic” piece of software with set definitions for product, SKU, variants, supplier, location, and so forth, those definitions rarely match the client’s reality. Even within apparel, for example, one company might define variants purely as color and size, while another might include fabric composition as well. Or in grocery, you might have “expiration date” meaning the day it absolutely can’t be sold, or the day it can’t be displayed in-store. There are endless subtleties.
Hence the standard supply chain theories turned out to be inadequate. We needed something new: a programmatic approach. This is something supply chain textbooks never address. Off-the-shelf models don’t help because the real world never fits those models perfectly. There’s always something—minimum order quantity, expiration constraints, shipping schedule constraints. Each company’s constraints are unique. So we realized the solution is programmatic, not a static formula. The question then became: what is the right programming paradigm for supply chain?
In 2012, people might say, “Why not just use Python?” Indeed, back then, that’s exactly what all my American e-commerce clients were doing. Nearly every data science initiative I saw at that time failed due to Python (or could’ve been Java, C#, or later Julia—it’s the same problem). The pattern was: in three weeks, a data science team builds an impressive prototype for some supply chain problem. Then they want to put it in production, and one year later it’s still not in production; management loses patience, cancels the project, that’s it.
Why did it fail? Death by a thousand cuts: NullReferenceException, OutOfQuotaException, concurrency issues, incompatible packages, security breaches, ransomware on your environment, and so on. None of that is directly related to the supply chain problem itself. The fundamental issue is that if you use a general-purpose language in a large production environment, your attack surface for problems is huge. For instance, if you can write to the file system from your code, you can accidentally corrupt the environment hosting your code—easy to do if you’re handling gigabytes of data in parallel. Maybe a file is locked by one process, or a disk is out of space, and so forth. These things inevitably happen in the middle of the night, with nobody there to fix it on the spot. Then, come morning, the client is furious because they expected the system to finish at 2 a.m. but it crashed at midnight.
In data science demos, you usually have a babysitter launching the script, so if it crashes, they fix it. But real-world supply chain automation must run unsupervised every day. Even run times can fluctuate from 20 minutes to two hours, which breaks production. That was the problem in 2012: these data science initiatives would fail in production due to the broad complexity of general-purpose languages, not the supply chain logic itself.
All that led Lokad to realize we needed a programmatic environment that was safe and specialized enough to handle large-scale daily operations without fragile babysitting. Plus, once we recognized we also needed to do advanced forecasting (probabilistic, quantile, etc.), Envision was set up to handle those workflows as first-class citizens. For example, if you want differentiable programming for machine learning, in a general-purpose language you embed another “mini-language” like PyTorch for that. Then you have Python plus a chunk of PyTorch code, and it’s easy to make mistakes, because your PyTorch code is essentially an uncompiled string. The same goes for mixing SQL queries inside your Python code. It’s all strings, so you only discover your typos at runtime. Envision, on the other hand, can treat these functionalities as built-in features with compilation checks.
Lokad’s approach evolved in parallel with advances like deep learning—where you no longer just have a library of pre-packaged models, but you compose your own model programmatically. TensorFlow is essentially a language for constructing computational graphs. You’re not stuck with a “catalog” of models; you build structures. Envision can incorporate these ideas natively as well. For example, we’ve recently worked on stochastic optimization. Anyone here know what that is? It’s the math optimization of a function whose outcome is uncertain—like deciding how many units to purchase when future demand is unknown. That’s a classic supply chain challenge. You’ve seen simpler versions with minimal constraints, but real businesses have a pile of constraints: order minimums, container fill rates, category constraints, or complicated calendars. On top of that, your cost/benefit function is uncertain. So these are advanced programmatic concepts.
All in all, Envision kept adding features. As of today, we’re also on the threshold of another revolution: large language models (LLMs). You’re probably familiar with ChatGPT. Maybe some of you are using it to do your homework. (I’m not grading you, so you can admit it!) Or even paying for the pro version. The interesting part for us is that Lokad has a writing culture, which is quite unusual for a supply chain company. We rely on text at two levels. First, we have the Envision code itself, which literally encodes “what” we’re doing. We don’t want a process that generates recommended orders in Excel, then someone modifies them by hand. Our aim is that the final numbers are generated automatically with no manual changes. And if changes are needed—sometimes they are, initially—those changes are captured in a workflow so we can discuss with the client: “Why did you modify what was generated? What might we change so manual edits are no longer needed?” Or sometimes we see the edits weren’t actually helpful, so we can incorporate that knowledge too.
Then we have a second text artifact, the JPM or Joint Process Manual, which explains the “why.” It’s our reference document for handovers and for giving the client a big-picture view of the initiative in plain language—without them having to read the Envision code directly. So we have a code layer that describes “what” and a separate document layer explaining “why.”
That fits quite well with LLMs, because LLMs process text. They’re not so good with raw numeric data. If you dump a huge table into ChatGPT, you won’t get a sensible regression. ChatGPT can only generate a piece of Python code that would do the regression. LLMs themselves are just giant next-token prediction models; they’re not built for arithmetic. Hence the jokes about ChatGPT failing basic math. But if you feed them code or text-based instructions, they do quite well at manipulation and generation.
So that’s where Lokad stands: we have advanced supply chain automations that can run for months with zero human intervention—something proven during the 2020–2021 lockdowns, when many of our clients sent their white-collar workers home. Meanwhile, the supply chain still had to run because the blue-collar workforce in warehouses and trucks was still active. Lokad already functioned largely remotely, so our supply chain scientists could keep working from home. That was the real stress-test: to see how our recipes would run without any day-to-day supervision. In some cases, large clients had literally hundreds of planners, managers, or analysts who suddenly were not there, but their supply chain still had to operate.
And for us, it worked surprisingly well. None of our clients died from it—nobody disappeared. That begs the question: if you can run your supply chain for 12 or 14 months without 500 white-collar staff, do you really need them back at all? This was an experiment we never could have done otherwise, as companies are usually afraid to fully trust an automated system. But lockdowns effectively forced them to rely on automation, proving we could run massive supply chains with minimal or even no manual intervention. Of course, we keep discussing ways to improve the numeric recipes; it’s not zero collaboration. But you no longer see large teams making daily Excel modifications to each SKU in each store.
So if I try to see where the supply chain world is headed: to me, it resembles the shift that happened in finance 20 years ago, when trading went electronic. Human traders who once read the morning paper, decided to buy or sell a stock by hand—that was replaced by quants with large automated portfolios. I see the same transformation happening in supply chain. We solved that old dream—mechanizing supply chain decisions. That was the original ambition of operations research (the “ancestor” of supply chain) in the 1940s, 50s, and 60s. Over time, “operations research” became its own sub-discipline, focusing on solvers, but if you look at the early vision, it’s exactly what supply chain wants: math, numeric optimization, resource allocation. We achieved a version of that at Lokad nearly ten years ago. The lockdowns were our real proof that it works at scale, even for more than a year without direct supervision.
A number of our clients today let the system run entirely by itself. For example, we can cite Cdiscount, a big French e-commerce retailer: we handle store inventory for them fully automatically, with no manual intervention. That doesn’t stop ongoing discussions on how to improve the recipes, but the daily “plus or minus units” approach has ended. That ended in 2020, and it’s still working now.
As a result, I think we’re at the end of an era, the one in which there are something like five million people worldwide whose job is to go through a thousand SKUs per day in Excel to decide if they need to order more, produce more, shift inventory, change prices, and so on. All sorts of job titles—inventory manager, demand planner, supply planner, category manager, S&OP analyst—boil down to the same daily routine: going through a chunk of SKUs. With large budgets, that might be 100 SKUs per person; with smaller budgets, maybe 5,000 SKUs per person. Either way, I believe that’s coming to an end.
Why now? Because for decades, no one could automate all those decisions. But once a certain number of companies demonstrate it can be done, others will follow. It’s extremely costly to maintain big manual-planning teams, plus it’s hard to pivot strategically when you need to retrain hundreds of planners across multiple countries, each used to doing the same daily spreadsheet routine for 20 years. Changing that is very slow. But once you can go purely programmatic, you can redirect quickly.
That’s what’s coming: the same shift we saw in banking. You used to have people manually trading all day; now it’s mostly automated. I see the same mechanization on the way for supply chain, and I believe it will become standard practice long before you retire—if you retire after 61 years of working, or however the laws change. You’ll still encounter many companies stuck in older methods, but that revolution is underway.
So my message is that you can either be an active driver of this change or just a passenger. Given that you’re Central students, you probably have the potential to be active drivers rather than just observers.
Alright, maybe we can move on to questions. I’ve inflicted a 50-minute monologue on you, so if you have any questions about all this, please go ahead.
Student: Yes, so does that mean these companies will become dependent on solutions like Lokad, or can they develop similar technologies internally?
Joannes Vermorel: Both are possible. If it’s a tech-savvy company—like a very large e-commerce player—sometimes they send teams to be trained by us, with the idea of internalizing the kind of practices Lokad employs. If a company has a strong tech culture and already develops a lot in-house, they can certainly do it. But if their culture is “We outsource anything too tricky,” then they’ll probably outsource. Overall, I think most will go with specialized providers, whether that’s Lokad or others. Of course, I’m biased—I’d like to believe Lokad will be among those solutions—but in any case, I’m convinced the revolution is happening, one way or another.
Student: You said LLMs wouldn’t replace engineers, only those who don’t use LLMs. What factor limits AI so that it cannot replace those engineers who do use LLMs? In other words, what prevents AI from surpassing engineers who themselves use AI?
Joannes Vermorel: If I knew the definitive answer, it would be worth a thousand billion dollars. Over the decades, there have been many breakthroughs in artificial intelligence, each time revealing a facet of what intelligence is—which we hadn’t fully understood. Again and again, we realize we were mistaken about what constitutes “real” intelligence.
For instance, if you asked in 1940 what shows superior intelligence, they might say: “Someone who can diagonalize a matrix.” École Polytechnique even had a department for diagonalizing matrices, considered the pinnacle of intellectual achievement. Now a simple computer algorithm can diagonalize a matrix; we don’t see that as intelligent at all.
We’ve had twenty such episodes in AI history, each time discovering that something we thought was “intelligence” isn’t. Large Language Models have some glaring flaws right now—like not actually learning anything during use. They’re static models. You can give them a prompt, they give you a continuation, and that’s it. If you do the same prompt again, you get the same continuation. They don’t learn from the conversation. You can do fine-tuning, yes, but that’s an external process. Day to day, there’s no memory or persistent improvement. A human who does an exercise learns something; an LLM does not. You can re-run the same scenario 200 times, and it doesn’t accumulate knowledge.
Another strange aspect is the massive amount of data LLMs require. A child learns to speak in about three years, with maybe 1,000 hours of listening at most. An LLM apparently needs to read the entire internet—billions of tokens. Or consider self-driving cars: they drive millions of virtual or real miles to learn to do what a human masters in 20 hours of lessons. Why so much data for “intelligence”?
So we sense there’s something fundamental missing, but we don’t know precisely what. Maybe the next iteration of LLMs or a new approach altogether will fix these shortcomings, but we’re not sure if that’s tomorrow or 20 or 50 years from now. Some people, like Yann LeCun, say we should throw out the entire LLM approach and do something else. I’m not so sure; maybe we can tweak LLMs to address the issues. Since no one has a solution yet, we simply don’t know.
Anyway, these are deep limitations that stop an LLM from fully replacing a human, even in relatively simple jobs. So yes, LLMs will replace engineers who choose not to use them; but they won’t necessarily replace the engineers who do use them—those individuals will remain indispensable.
Student: Earlier, you mentioned Lokad stayed profitable even though the product didn’t work at first. How is that possible? Did you get funding or subsidies? Or were you providing other services?
Joannes Vermorel: No, no subsidies or outside funding. Let me explain: the supply chain market is somewhat crazy. Typical business plans from competitors since the 1980s go like this: Step 1, raise loads of money—tens of millions. Step 2, capture market share by focusing on some vertical, like aviation, for two or three years. Step 3, hire 200 salespeople, grab 20% of the market, then eventually implode. Rinse and repeat.
We see it constantly. Even giants like Nike almost went bankrupt in 2004 due to a well-known supply chain software fiasco with one of our competitors. The “Nike disaster” is documented on their Wikipedia page. They basically messed up nine months of Nike’s production. Meanwhile, the same vendor messed up lots of customers, was acquired, and the acquirer ended up paying $250 million in damages. My experience is that in enterprise software, even if you’re mediocre, you don’t usually get sued, so these guys must have been truly awful. But despite that track record, they simply started a new company—same people—and raised another half a billion dollars. The market never learns.
Many of our clients actually come to us after half a dozen disastrous attempts at supply chain projects with different vendors. Supply chain automation is an old dream; the underlying data has been digitized since the ’80s or ’90s, so they’ve been trying for decades. It’s normal that big companies have a stack of failed projects in their closet.
That’s the environment we operate in. There’s huge inertia. People forget. The need remains, so they try again and again. The market might look rational from a distance, but it’s slow to fix these issues—especially in an opaque area like enterprise software. You can even have a catastrophic implementation, yet the client might give you a glowing case study anyway, because the manager who chose your product doesn’t want to be blamed. So, ironically, a fiasco can be spun as a success in the marketing narrative. That’s how messy it can get.
Joannes Vermorel: Any other questions? Does everything I’ve described seem normal, rational—what you expected from the business world?
Alright. Well, in any case, thank you all very much for the time you spent coding Envision scripts. I’m quite proud to see Central students rolling up their sleeves and using Envision. I truly never imagined, when I wrote the first compiler over a decade ago, that I’d one day see Central students working with it. It was a risky gamble back then; it wasn’t in our business plan to get you folks in front of Envision, but I’m delighted it happened. And if Rémi or Basil haven’t told you yet: Lokad is hiring, just so you know!
