00:00:00 Eric Kimberling and Third Stage introduction
00:04:31 Focus on people over tech in projects
00:06:14 Correctly framing digital transformations
00:08:08 Overcoming incrementalism in transformations
00:10:53 Vendor biases risk misguiding efforts
00:12:40 Challenges in forced cloud migrations
00:14:46 Low value in upgrading systems or records
00:19:26 System sensitivities and transformation impacts
00:21:38 Big company vulnerabilities in transformation
00:23:39 Leadership issues increase risk aversion
00:26:22 Lack of strategic perspective in transformations
00:29:42 Importance of mechanical sympathy in leadership
00:32:42 Data latency hampers distributed computing
00:35:42 High costs of terabyte data processing
00:38:38 Tech transformation risk analysis
00:41:43 Visionary strategies for digital transformations
00:44:25 Balancing project budgets with returns
00:47:42 Realistic cost expectations in transformations
00:50:58 Software feature overload hinders productivity
00:53:29 Focus on business processes over tech
00:56:39 Internal management of tech transformations
00:59:45 Bureaucracy in strategic planning execution
01:02:48 Governance prevents chaos in supply chains
01:06:27 Comprehensive overhaul for ambitious transformations
01:09:34 Optimizing capex for supply chain value
01:12:20 Inefficiencies in current transformations
01:15:28 Vendor data usage for competitive advantage
01:18:11 Financial incentives affecting productivity
01:21:13 Pursuing promising software technology developments
01:23:19 Avoid costly failures by acknowledging sunk costs
Summary
In their discussion on supply chain digital transformations, Eric Kimberling and Joannes Vermorel highlight frequent failures due to vendor-driven pressures and misaligned priorities. Kimberling, guiding Third Stage Consulting Group, advocates for technology-agnostic strategies, emphasizing business needs over mere software upgrades. He warns against rushed decisions driven by vendors that often fail to deliver transformative outcomes. Vermorel underscores the importance of leveraging existing systems with innovative add-ons rather than disruptive replacements. Both leaders stress aligning transformation efforts with tangible business goals and underscore change management as vital for success. They advocate for gradual, mindful adoption of technology, ensuring objectives are defined and risk is managed.
Extended Summary
When examining why supply chain digital transformations often fail, it is vital to consider the insights shared by industry leaders like Eric Kimberling and Joannes Vermorel in their recent dialogue, hosted by Conor Doherty. Both Kimberling and Vermorel possess a wealth of experience in guiding businesses through the treacherous waters of technological upheaval, and their perspectives reveal crucial truths often overlooked by organizations embarking on such endeavors.
Eric Kimberling, a luminary in technology thought leadership, leads Third Stage Consulting Group—a firm dedicated to offering independent and technology-agnostic guidance to organizations aspiring for successful digital transformations. His firm operates under a clear mission: empowering clients through unbiased advice that foregrounds business needs over mere technological upgrades. Eric’s approach highlights the necessity for transformations to focus not simply on technological solutions but rather on holistic organizational change encompassing process and people over technology alone.
The conversation swiftly puts the spotlight on the notion of “tech agnosticism,” a principle Kimberling argues should be at the core of any successful transformation project. He warns against vendor-driven biases that prioritize software upgrades over genuine business needs, a sentiment echoed by Vermorel. Vendors often push rapid upgrade timelines—a strategy that can inadvertently trap companies into rushed decisions that yield incremental, rather than transformative, improvements. Eric warns that such pressured upgrades seldom align with long-term organizational goals and often detract from the value digital transformation is meant to deliver.
Joannes Vermorel, founder of Lokad, delineates the realms of enterprise software into “systems of records,” “systems of reports,” and “systems of intelligence,” arguing that transformations should not myopically focus on systems of records that offer minimal additional value. Both Vermorel and Kimberling recognize alternative strategies from companies like Palantir and Snowflake, which enhance existing systems without the disruptive need for replacement, emphasizing the strategic advantage in adapting current infrastructures with innovative add-ons.
A recurring theme in their dialogue surfaces, revealing large corporations as particularly vulnerable to costly failures during digital transformations. Kimberling notes these failures often stem from complex solutions coupled with high-risk aversion and a lack of decisive accountability, highlighting an intrinsic need for mechanical curiosity—a concept urging business leaders to be intimately familiar with their enterprise’s digital requirements. Without this curiosity, companies falter when they outsource too heavily, treating vendors as primary drivers rather than subcontractors of change.
The leaders stress the significance of aligning digital transformation strategies with tangible business objectives. They present the disturbing prospect of inflated budgets dedicated to ERP upgrades without clear ROI—or worse, projects that neglect ROI and benefit analysis entirely. The discussion underscores the critical importance of change management—the often-overlooked linchpin of transformation success. Transformations that overlook cultural assimilation and comprehensive training are destined for complications regardless of the technical prowess involved.
In identifying success cases, Kimberling and Vermorel delineate the importance of clarity and brevity in planning documents. Rather than cumbersome PowerPoints, concise textual plans foster a deeper understanding and facilitate clearer communication among stakeholders. They extol the virtues of treating technology investments akin to capital expenditures—valuing them as enduring assets rather than mere operational expenses.
As the dialogue concludes, the pair reiterates that while tech-driven transformations can be potent catalysts for business evolution, their success hinges on a careful balance between adopting software innovations and nurturing organizational change. Kimberling advises embarking on these transformations with gradual mindfulness, ensuring objectives are rigorously defined before accelerating implementations. Vermorel concurs, promoting incremental engagements and a “fail fast” approach that tempers risk while allowing room for adaptation.
Through their exchange, Kimberling and Vermorel illuminate the path for organizations contemplating digital transformations—prompting leaders to consider more than the allure of trendy technologies, focusing instead on aligning these projects with their overarching business goals and aspirations.
Full Transcript
Conor Doherty: Welcome back to Lokad. Today I’m happy to host a conversation between Eric Kimberling and Joannes Vermorel. Now, Eric is the CEO and founder at Third Stage Consulting Group, and today he joins us to share his unique perspective on why so many digital transformations fail in supply chain. Now, while you’re here, if you like what we do at Lokad, really consider subscribing to Lokad TV here on YouTube. I’ll wait.
All right, thank you. And also follow us on LinkedIn, and with that, I give you today’s conversation with Eric Kimberling. Well, first of all, Eric, thank you very much for joining us, and welcome to Lokad.
Eric Kimberling: Thanks for having me. It’s good to be here.
Conor Doherty: So Eric, before we get into the meat and potatoes of the conversation, I should say you’re a very popular voice online. In fact, I came across you first on LinkedIn. You’ve quite a following, and you’re prolific on YouTube as well. Now, we have a primarily European audience, so they might not be as familiar with you. So could you give a brief primer for any of our audience who is not in North America? What is it that Third Stage Consulting Group does, how did you get here, etc.?
Eric Kimberling: Yep, so Third Stage Consulting Group is a US-based digital transformation consulting firm. And the key to our business model is that we’re independent and tech agnostic. So we help clients through the entire life cycle from digital strategy and software evaluation and selection, through implementation planning, and through the actual implementation program management and change management as well.
We have close to 100 consultants. We actually have a small office in Europe based out of the UK that handles the EMEA region. So you are correct that we’re not as prevalent in Europe yet, but our goals are to have as much of a presence in the EMEA region as we do in North America. But really, I started the company back in 2018 just because I felt like there weren’t enough consultants out there that were truly tech agnostic, objective, and really representing clients’ interests.
So that’s really the premise for why I started the company. It was just to give clients an alternative to the typical consulting model.
Conor Doherty: When you talk about the typical consulting model, I presume tech agnosticism is a big part of that, but could you unpack what you mean by that? It’s a beautiful phrase, but what do you mean by tech agnosticism?
Eric Kimberling: Sure, tech atheism, I like that term too. It’s even better. No, so tech agnostic means that we’re not commissioned by the software vendors. In other words, we don’t make money when the vendors make money. We only make money directly from our clients. And that’s a really important nuance because most consulting firms are either directly incentivized by the software vendors to expand the software footprint as much as possible throughout a market or region.
They have a bench of resources focused on one technology, and their goal is to get those consultants staffed on projects focused on that one technology. That bias creates a technology-first mindset around transformation, whereas in my opinion, the most successful transformations, whether we’re talking about supply chain transformations or ERP implementations, whatever it might be, the more successful ones are driven by business needs and defining a strategy and roadmap that fits those business needs— not leading with technology and then trying to figure out how it could possibly fit your business. That may sound like a very minor detail, but it’s actually a pretty big deal, and it’s a big driver for what causes success or failure in the market.
Conor Doherty: Well, thank you and Joannes will come to you just in a moment, but I think it would be important to set the table a little bit so we understand technosticism, thank you! When you say digital transformation, you said it’s not just limited to ERPs. Could you give a brief primer there for the rest of the conversation? When we talk about digital transformation, is that end-to-end? How do you define the scope of that idea?
Eric Kimberling: Really, the way we define it is technology enablement across the enterprise. It’s not just technology; arguably even more important is the operational and organizational side of things, the process and people sides of things.
When we’re looking at specific technologies, most people lead with a decision that they need to replace their technology. That’s usually the problem statement: “We need to replace some sort of technology.” That technology might be a supply chain system, it could be an ERP system, it could be a CRM or a customer relationship management system; it could be an HR system, financial, even now with AI being such a big deal it could be AI, it could be business intelligence.
So there’s all these different types of technologies out there to choose from. In our minds, when you think digital transformation, it’s a pretty broad term and it’s pretty vague. It encompasses a lot of different things, a lot of different technologies, and what’s more important about it is I think the word digital transformation is a bit misleading because it leads one to think it’s about technology. Really, these projects typically become a lot more about processing people and less about technology.
Conor Doherty: Thank you Eric, and Joannes to come to you. Eric mentioned problem statements. I know that having a better understanding of a problem statement is basically the foundation of whatever it is you want to accomplish. So, your thoughts on what Eric has said and how that fits into your understanding of digital transformation.
Joannes Vermorel: I very much agree first on the importance of tech agnosticism if you want to provide good advice. It is absolutely fundamental; otherwise, the problem will literally be framed as whatever expands the footprint of whoever has already a foot in the door as a vendor. That would be, and then the project devolves into how do we upgrade the ERP from this vendor from version N to N+1. In the end, it’s like a recipe for massive investment and very little to show for.
The incentives do not underestimate the power of incentive to frame correctly the initial problem statement. It may sound like very little, but what I’ve observed is that those tiny few decisions that get made typically very early on in the process can then completely frame the millions of dollars that are going to be spent over multiple years afterwards. So, I very much agree this is absolutely fundamental to take the side of the business. What do we want to deliver, not yet asking the question of which vendor? And then there is the side question which is really, and I also very much agree with your vision that digital transformation is really about what sort of company will we become if we can do things better with those more fancy tools and whatnot.
As opposed to think of a linear progression on going from version N to version N+1, and that’s usually a very tricky question because, for example, you might think, “Okay, we have so many people who are doing this and this and this,” but it turned out that maybe if we were better organized we don’t even need to do those things in the first place. So, there is no point in trying to optimize what they’re doing because the best organization would not even need to do that in the first place again. So, I see that as a challenge to really think the business. What are you actually achieving?
And then you need to have a good sense of the technology, what it can do, what it cannot do. But I would say it’s a distant second compared to having a very clear understanding of the business and what you’re trying to achieve. This framing I like very much, and I believe that for me the biggest challenge of most companies, I think in Europe but maybe to some extent in the US too, in this digital transformation is that it’s the curse of incrementalism. They really think of the same thing plus a few bells and whistles, or we would like to have the same ERP but a web interface instead of having a desktop interface or whatever.
And that for me, yes, that would be kind of nice, but fundamentally the sort of returns on investment for those projects which are very expensive, I mean, it doesn’t justify it. You don’t upgrade an ERP because you’re tired of your ugly interface. If it works, it works, even if it’s not good-looking. If you want to upgrade and spend years doing that, you need to have something that your company will be much better afterward, not just having a nicer looking tool but the company itself has become something else. That would be my take for what genuine and correctly executed digital transformation actually means.
Eric Kimberling: Yeah, that’s a great point because you have a number of really good points in that. One is you talked about the planning and the early decisions that are made and how that sets the trajectory for the project. That’s very true, and a lot of organizations, I think, feel like we’ll just rush through these decisions, let’s just get into the project and then we’ll figure everything out during the project. And that’s where things get messy and there’s no clarity of direction.
But the other thing too that you’re alluding to is that sometimes it’s okay to say we’re not going to upgrade our technology. What if you don’t upgrade to the newest fanciest system out there? What if you instead optimize what you have? What if you focus on modifying your business processes to be more optimized? What if you train people how to use the software better? What if you did all these low-cost sorts of things that deliver an extremely high amount of value and low risk to the organization? Why not consider that as an option?
Now, software vendors would strongly disagree with me. If I were a software vendor, I would say that is a terrible idea; you need to upgrade all your technologies, you need to move to the cloud, you need AI, you need all this stuff because I’m trying to sell you technology. But if you step back and just take the emotion out of it and take the vendor bias out of it, a lot of times organizations will come to the conclusion that, “You know what? We don’t need to rush to upgrade to the cloud just because our vendor is telling us that we have a deadline to do it.”
And I think that’s really important that you take the transformation into your own hands and base it on your business needs, your priorities, your strategies, not the software vendors.
Conor Doherty: Eric, if I can just follow up on that, I mean, and I don’t want to put words in your mouth, but is the implication there that people are perhaps a bit misled by consultants or vendors and that leads to digital transformation failures? If not, then what do you see as some of the most common reasons why digital transformations fail?
Eric Kimberling: Yeah, that’s a great question. We could spend the entire interview discussing that one question. But to summarize, I’d say yes, the biases for sure are contributing factors to failure. If I’m a software consultant and I come in with a myopic view that this is the technology I need to fit within your organization, you’ve already created a mismatch because I’m not leading with your business; I’m leading with my technology.
My technology has best practices; my technology has built-in workflows; you need to adjust to my software because my software is great. It’s just a very disruptive process because of that. So, I think the bias is part of it; that’s a big contributing factor. But what I think is an even bigger contributing factor that a lot of people don’t recognize is that a lot of these big software vendors, like if you think of SAP or Microsoft, they’re essentially forcing their customers to upgrade to new technology by saying, “We’re going to take away maintenance and support for your old system; we’re going to take it away on this date, and you have until this date to get to the new system or else we cut off support.”
And I think that’s extremely reckless; it’s not a client-focused problem statement. It’s essentially taking a vendor problem and making it the customer’s problem. The vendor problem is we need to move to the cloud because it’s more profitable for us; our investors are demanding it. So, that problem becomes the customer’s problem because now they’re saying, “Hey, I know maybe you just implemented an on-premise solution say two years ago, but guess what? We’re cutting off support for that same system you just implemented; we’re going to cut off support in two or three years, and you have till then to get onto the new system.”
So, that creates a rushed panic in organizations, and that’s the worst place to be when you’re trying to go through this transformation because it leads to a lot of the things that you’re mentioning, which is now I’m just going to make these incremental improvements. I’m going to spend all this time and money and risk just to get maybe some minor improvements to my business, and it’s hard to justify the ROI when you go about that process.
Conor Doherty: Joannes, I know you’re a huge fan of vendors and you defend them to the hilt, but can I push you for a comment on that one?
Joannes Vermorel: Yeah, I mean, my take is that the software industry, I split, by the way, I see the world of enterprise software in three distinct kingdoms. We have systems of records, systems of reports, and systems of intelligence. Systems of records are really about data entries and workflows. This is everything that comes with management in a system of record that can be CRM, ERP (which should have been named ERM, enterprise resource management, because planning is like a secondary concern), TMS, transport management systems, etc. All those management systems, they are systems of records.
My take is that once you have a system of record that kind of fits, that kind of works, that is not super sluggish, then you’re kind of done as far as this layer is concerned. What I see as digital transformation is that people try to improve some stuff that can’t really be improved much. If you have, let’s say, you’re an accountant, you already have a ledger, it’s a good one, it’s not as shiny as anything, but does this ledger have everything you need? Yes, and that’s what those systems of records are.
Systems of records are and so I see that in those digital transformations, a lot of discussion are about upgrading systems of records that are already kind of capturing everything they need to capture. So for me, the added value of this sort of transformation, which typically absorbs like 80% plus of the budget, is almost zero because you have already your workflows. They already work. Your software might, I mean, the next interface is not going to change anything because it’s data entries and whatnot.
And if you have that and it works and it kind of functionally captures what you need to capture, you’re kind of done. And I think that the curse of those enterprise vendors is that they realize, especially companies like SAP, they realize that they had reached a point where the job was done. Mission accomplished for the system of record two decades ago.
And now, and by the way, you can explain all the movement of SAP HANA toward, “Oh, let’s transform this thing,” which was a system of records into a system of reports with all sorts of analytical layers. But my analysis is you should just stick to your guns. You are a system of records. And then you realize when businesses look at it like that, they would say then, “We should not be investing in that because the next version is only going to be bugs, regressions, new training unless the old systems were insufferable because it was way too slow, way too buggy, or it could not even capture those records that we needed. Then there is no added value.”
And for us in supply chain, it’s really important because I see many clients that have inventory management systems that are like 30 years old. They are black and white text console screens, but functionally they do 100% of what those companies need. And inventory management, you know, is not rocket science. I pick something plus minus one on the shelf. I put something on the shelf plus one.
So those software are ancient and functionally they do 100% of what they need. So here it’s the sort of things where spending a lot of money to just upgrade those sort of things for me doesn’t lead to the outcome that people think they will get when investing on this sort of journey.
Eric Kimberling: I agree. And I think that’s why companies such as Palantir and Snowflake, some of these bolt— I don’t want to say they’re bolt-on systems, but they’re systems that are designed to interoperate with other systems of record. So where you could say, “Well, my system of record might be outdated, but it works, and I don’t want to go through all the risk and cost and effort of replacing that system of record. But I do want better reporting. I want better intelligence. Maybe I want some AI capabilities. But I want that without… I don’t need to rip out the back office system of record.”
So that’s how companies like Palantir, Snowflake, and others have come about. They create a solution that says, “Keep your old system. We don’t care. We’re going to provide you a solution that doesn’t mess with that. Instead, it just builds on it and gives you better workflows, better AI, better reporting, better intelligence, all that stuff.”
So I think you’re right. Those are the options that a lot of times organizations and teams don’t realize. They have options because they’re hearing from other vendors that, “No, no, no, you do need to replace your system of record because it’s on an old technology. You’ve got technical debt. You’re going to fall behind.” You know, it’s a lot of fear-based selling. And it works.
Fortunately for the vendors, it works. Unfortunately for the customers, it works. So I think the key is just to educate yourself, be objective, get that outside objective opinion on what your real options are because it could be that you leave your system of record in place, but you add something that gives you more capabilities without all the risk.
Joannes Vermorel: Shameless plug, this is exactly the business model of Lokad. It is geared exactly like Palantir or Snowflake. We do just that for those reasons. But obviously, I didn’t want to force you to say that. But yes, that’s my point. The problem with those systems of records is when you touch them, the amount of disruption to the organization is immense.
You can switch a Snowflake on and off that does analytics on the side, you know, no big deal until you are really dependent on it for your day-to-day operation. But until then, you can switch this thing on and off as much as you want. Unlike the system of records where if you touch it and it breaks, then all hell break loose because suddenly you don’t know who you should pay, for your suppliers, who owe you money from your clients, etc.
So the systems of records, it’s a layer that is much more sensitive and much more delicate. And that’s why I would say the upside is not that great because you’re not going to— if you have something that is functionally satisfying already, the upgrade is not going to do much. But the downside, if you break it, can be absolutely immense.
Recently in France, we had a major company that just went bust, GiFi, just due to, I actually have that open in front of me, bad digital transformation manage. A multibillion company that just went bankrupt with a mismanaged digital transformation.
Eric Kimberling: Let’s say it’s a big well-known company in France too, right?
Joannes Vermorel: Yeah, it was let’s say one of the top ten nationwide retail networks.
Conor Doherty: That’s actually a perfect transition because I did actually want to get into something that you comment on a lot, Eric, which is taking examples of big companies that everyone knows. Actually, I have a list open in front of me. You’ve written and recorded on Lidl, for example. I have it in front of me: 600 million failure trying to transform their ERP system. Excuse me. But there are also across the world, not just Europe.
You have DHL losing hundreds of millions, Lidl in Germany, losing half a billion. Asda, GE, Spar. Actually, I remember I saw a video of yours on Spar as well. So again, these are huge companies, so it’s again not localized or just Europe or just France, for example, or just Washington or whatever. This is almost like a systemic occurrence.
Now, I don’t want to put words in your mouth, but if it is in fact somewhat systemic among huge companies, the question then becomes is there something uniquely vulnerable about huge companies that just leads to this? Do they lack agility or what? Why are these big companies losing so much money?
Eric Kimberling: That’s a great question. First of all, I don’t know. I couldn’t tell you either way. Yeah, I suspect there probably are slightly higher failure rates with big companies, although I will say there’s plenty of small and midsize companies that fail as well. The only difference is you don’t hear about them because no one cares.
No one’s heard of these companies before, but they’ve heard of Lidl. They’ve heard of Spar Group. They’ve heard of Asda, whoever the big name is. But I think to answer your question about why, you know, are big companies more susceptible to these failures, I’d say the dynamics that are at play with a big company do lend themselves to failure, partially because of organizational behavior. Part of it is because a big company, for example, is more likely to implement a big, complex solution because they are a big, complex company and they feel like they need a bigger, complex solution.
So they’re more likely to go buy an SAP or an Oracle or some other big system. So that right there is a risk factor. That’s increasing your risk right away because now you’ve got a big, complex system you’re trying to implement.
The other dynamic that happens with big companies more often than smaller companies is the sort of, I’ll call it the lack of accountability. There’s less visibility and accountability at the executive level. Oftentimes these executives have so much on their plate. They’re expanding. They’re into new markets and they’re going out and buying companies. They’re focused on these strategic things and they view digital transformation as a non-strategic thing, which is a mistake.
And they delegate that down the organization. And that lack of executive ownership and transparency and visibility and buy-in, that lack of executive involvement, leads to failure. That’s one of the big root causes. And then, I’d say a third thing, a third dimension that works against big companies is that big companies are more likely to be so risk-averse that they actually are increasing the risk, ironically.
And what I mean by that is they say, “Well, if I implement SAP, SAP is a well-known product. If I hire Accenture, Deloitte, or KPMG, that’s a very well-known firm. So I’m going to cover my bases and make sure I hire the blue-chip names that are going to lead me to feel comfortable that they are the experts, they can handle this.”
And then what happens is you have an open checkbook and the system integrator takes over your project because your executives aren’t super involved and they trust the big brand names. And those big companies will go down the path of implementing technology and they’ll overcomplicate things, even if it doesn’t necessarily make sense for your business, because that’s what they know. That’s what they do.
That’s what they do, and I don’t think it’s actually, I don’t think it’s a nefarious intentional thing. But I think it’s not having ownership and transparency leads to people pursuing their self-interest, which when you have the vendors and the system integrators pursuing their self-interest, they want to sell you more software. They want to bill you more hours, and the ROI doesn’t factor into this at all. It doesn’t matter whether it delivers value or not. They’re going to get paid.
So the incentives are misaligned. At a big company, a big complex company, those dimensions are magnified because it’s a bigger company and there’s more at stake. So, I think those three things are probably the three biggest things that come to mind as far as what works more against a big company than a smaller company. Though I will say a small and mid-size company is likely to fail as well if they don’t follow just sort of the basic fundamentals.
And the good news, there’s no rocket science or secret formula to how to make these successful. It’s actually pretty simple, but organizations don’t take that time to stop and think and make the right decisions early on. That leads to a lot of these problems we’re talking about.
Conor Doherty: Thank you Eric. Joannes you have commented once or twice about bureaucracy in big companies. Could you repeat those thoughts?
Joannes Vermorel: Yeah, I mean, my take is that small companies can fail because yes, they are lacking the resource to have the experts and whatnot. I believe that large companies, where they are frequently failing, they have all the experts, but the problem is that they come with an agenda. All those experts are hired, and they come with all sort of agendas.
Sometimes it is a little bit, I would say, dumb agendas, such as people just want to try a new technology because it will look good on their resume. So don’t underestimate also the fact that tech guys are going to do techy things just for the sake of having experimenting and tinkering.
But also, I think a problem is, as you were pointing out, it’s digital transformation is not seen as strategic. As a cascade effect of that is, they have no, I’ve frequently seen that top management in large companies have no mechanical sympathy.
So what do I mean by mechanical sympathy? They have zero curiosity to what goes under the hood, what how those things are plugged, what are we even talking about. I’m not talking about being like an expert software engineer, but are we talking of just something that is like a crude app, you know, create, read, update, delete on a database that happen to be many tables?
Or do we need real time? What do we mean by real time? Do we need microsconds, milliseconds, seconds or hours? Do we need etc., etc.? I mean, there are plenty of questions that are relatively basic, but if you have what I call no mechanical sympathy at all, then the objects or software objects that you manipulate are completely abstract.
And for you it is a series of code names that make no sense whatsoever. “Oh we need the widget ABC20, and but in order to get ABC20 working we also need Contoso12 to be upgraded.” And Contoso12, oh it also need up thingy number seven, etc., etc.
I mean that’s like a long list of code names that make no sense. Then, if you have this sort of environment that is, I would say, that lends itself very easily to some sort of technocratic capture. You know, the business perspective gets thrown out of the window just because in fact business people have surrendered completely their claims because they have no mechanical sympathy. So they can’t feel even in capacity to express an opinion on whether things are generally going into a direction that is kind of aligned with the business or not.
You, sorry it’s a long answer, but this mechanical sympathy ingredient I’ve seen it missing from many, many companies. And it doesn’t require that much expertise. You know, again like a guy who likes cars, he will just take a little bit of time to know what goes under the hood so that it’s not like pure magic if the car is moving forward. There is some understanding of the main building blocks that make the thing happen.
Eric Kimberling: Yeah, absolutely. That’s an interesting term. I had not heard mechanical curiosity, and I think it gets back to a point I do make often. I think they’re very much interconnected, and that is general ownership and curiosity about the product overall.
And so I think that encompasses what you’re saying, which is the mechanical curiosity. But I think you’re on to something here, which is that, if you don’t do what you just said about having that mechanical curiosity, there’s no way for you to have ownership and the right intelligence to make intelligent decisions around these projects.
And by not having that hands-on curiosity and experience, you don’t have to be as experienced as the experts, but at least be experienced enough to where you can manage those experts because it’s your job to manage them. They shouldn’t be managing you just because they’re the experts. It’s your company. You’re the one that has to live at the results, so manage them accordingly.
It’s amazing to me how many of these big organizations say, “That’s, I’m not a technology guy. I’m not responsible, I’m going to let the experts handle this.” But it’s a business transformation, and if you’re doing it right, it’s actually business transformation, and you need to be involved, very involved.
Even if you’re not involved in the technical mechanical curiosity, you should at the very least be involved in the operational curiosity. What is this going to mean to my organization? What are my operations going to look like? How are people’s jobs going to be affected? Do I want that, is that okay, or do I want something different?
And if you’re not involved in that, the system integrator will inevitably create what they think is right, and that just is not going to match your vision and your strategy.
Conor Doherty: If I may also, just because I agree with both of you, but I just want to drop in a little pin there because I’ve heard you talk about mechanical sympathy a few times. Recently, on a different podcast with the Supply Chain Connect, shout out, I talked about that exact concept.
There were two really good points, the direct benefits of mechanical sympathy. Obviously, when you understand a little bit about the software, you know how better to leverage it, so it increases the direct ROI of utilizing it. But it also protects you from bogus vendor claims.
And you’d said that before, again understanding a little bit or some about what is being designed, what the software is able to do, can insulate you from perhaps misleading claims from vendors.
Joannes Vermorel: Yeah, I mean just an example, let’s say for example LLMs. Okay, AI is great, fantastic, okay, so we have those large language models. What is the cost to ingest a megabyte of data into an LLM, just ballpark?
The ballpark is one megabyte, even if you take a cheap model, we are talking of basically $1, and that’s a cheap lower end. Every time you want to get a response, if you have to process one megabyte worth of data as input with your LLM, that’s going to cost you $1, even with the cheapest model.
If you just have this number in your head, you know that okay, there are plenty of things that are right out of the door and they will remain invisible for probably more than a decade. Because if you think, okay, I have terabytes of data, okay, I’m not going to process that through LLMs first.
And then if you, every single time somebody clicks, you would have to pay $1. I mean, you just do again, super basic math that would tell you, okay, this thing cannot work. It is not economy viable.
Even if the price drops by a factor of 100, we are still four zeros off to anything sensible. Just an example, and I’ve seen many situations where I was discussing with prospects say, just take a few basic orders of magnitude so that we know what we’re talking about.
Same thing, for example, for distributed computing. Distributed computing is very much limited by the speed of light. People say, “Why do I need to know the speed of light?” But the answer is if you have a system where you are going to have your warehouse that will be talking to your central system and information goes back and forth, you have 200 milliseconds of latency.
You just realize that you need a thousand roundtrips to do something. Then we are already talking of 200 seconds just of round trips to do that. Again, it’s not like super fancy math, but it is the sort of things where, okay, we have a design problem.
You don’t need to be an advanced engineer, we’re just talking of simple multiplication, just a few baselines. I’ve seen many projects that have failed on our clients that were just doomed because some basic rule of thumb calculations had not been done.
If so, people would realize that it would just not work considering the business objectives. Because the guy, the technologist might say, “Well, it’s going to take 200 seconds. A lot of calculation takes time, why not 200 seconds?”
But the guy would say, “No, this is something that an operator is waiting, so it’s not even possible.” Or, the LLM would say, “Oh, it costs one megabyte, $1.” The engineer would say, “Yeah, why not? You know it’s just a price point, I don’t care.”
Don’t care, and then the business says, “But do you realize that a person paid something like $20 an hour is going to click this thing 60 times an hour?” So your LLM cost is going to be like four times what we pay the guy who is operating it.
Again, that’s just, but again, that’s the only way to make sure that it kind of makes sense. Is to have this business with some mechanical sympathy involved, framing of the project, and its added value, intended added value, kind of makes sense. That’s, that would be my take.
Eric Kimberling: Yeah, and just understanding those hidden costs and those things that on the surface may look like they’re actually improving your business. It might be improving your business, but if it dramatically and materially increases your cost, then you probably aren’t going to be able to get the ROI you’re looking for.
Joannes Vermorel: Yes, and again, don’t underestimate how, that’s my experience with engineers: how engineers can give you five numbers of precision, but the comma is just a little bit off in the calculation.
So that’s, that’s why I say executives really need to be, to have this mechanical sympathy, to have this interest for the digital transformation and what goes in. Because otherwise, you’re in the hands of technologists who are enthusiastic about the technology—fine, perfect—but that can very easily be distracted and lose sight of those orders of magnitude that just condition whether you will have a positive ROI or not.
Conor Doherty: Just to make sure I understood this, the impact that you mentioned earlier: a terabyte is a million megabytes, right? So processing a dollar per megabyte would be just…
Joannes Vermorel: A terabyte is a thousand gigabytes. So yeah, it’s a million megabytes. So a terabyte at this price point I was mentioning would be a million dollars per terabyte to be processed.
Conor Doherty: Just make sure I understand.
Joannes Vermorel: So yeah, I mean, if you want to do that, you probably don’t want to do that in the first place. And if you absolutely have to do it, you would really make sure that you don’t have to do it more than once a year, because obviously, even for a large company, we are talking of fairly extravagant IT costs.
Conor Doherty: Well, yeah. Well, actually, Eric, if I can come back to that, because the general tenor of that, the overall framing was things that are missing. But I do want to circle back to something else that was missing. You know, we already discussed mechanical sympathy, but in that, you brought up both of you the idea of ROI financial return.
And something you said earlier, Eric, when you were talking about companies like big companies selecting what their software is going to be, “Oh, we’ll just, what’s the big name? We’ll get that. And who’s a big consulting firm? We’ll get that because, you know, box ticked.” And you said, because in that context, often ROI doesn’t matter. Now I know Joannes has talked before about financial KPIs and ROI in supply chain, but I was wondering, could you just unpack that a little bit, like why do you think the financial perspective might not be as present in supply chain as it perhaps it should be?
Eric Kimberling: Yeah, I think with technology changing so quickly and exponentially, there’s almost like a nuclear arms race where people feel they have FOMO, you know, they have the fear of missing out. And they want to make sure that they aren’t suffering from technical debt and all these fancy terms that analysts and software vendors come up with.
And so they lose sight. I think they’re, I think the industry is losing sight of why are we doing these technology projects. I mean, we’re not doing it because we want cloud capabilities. We’re not doing it because we want AI. We’re not even doing it because we want better intelligence or reporting or a better system of record.
We’ve lost sight of all that. We’ve just, we haven’t focused on why do we need that technology? Why do we need to, like for example, why do we need to go to the cloud? I mean, sometimes I’ll ask clients that, and I get blank looks like, uh, because we’re on prem right now. I’ll say, “Okay, you’re on premise. So what’s the worst that’ll happen if you just stay on prem for five more years?”
Well, you know, then we won’t be in the cloud, or the software vendor is going to cut off our maintenance. Okay, well, hold on. Let’s talk about that. Maybe they cut off your maintenance, what’s the worst that’s going to happen? Well, we have to maintain it ourselves, and we can’t contact the vendor for support. Okay, then you might have to hire someone.
Let’s look. But let’s look at that. Let’s look at that option, because that might actually be a much lower risk to you than going through a big massive $600 million transformation, in the case of Lidl, for example.
So companies don’t do that enough because they feel like they have to. They feel like they have to do an upgrade. They have to move to the cloud. They have to get AI, blah, blah, blah. So I think that just all the changes in technology and the speed of change is happening so quickly that companies get lost, and they get twisted around and forget why they’re doing these projects in the first place.
Joannes Vermorel: I think it’s, I mean, first financial KPIs are kind of misleading because I don’t think it’s the right approach. Your digital journey, let’s call it that, is like 10 years. You have to think kind of 10 years ahead—where do you want to be? Those things are long. That’s literally the companies that you’re engineering.
So my take is that looking at KPIs that are kind of short-termish is not really for me something that is really relevant to think whether it’s the right thing or not. It is typically the sort, if you were to follow those KPIs, that’s exactly the sort of things that would say Walmart, year 2002, “Oh, no, e-commerce, we don’t care.”
That’s the sort of thing that leads you to say, “Okay, e-commerce is relevant; it’s so small, we don’t care.” No, it is actually very relevant, and there will be a giant that will be just bigger than you in a few years if you don’t do anything. Which was a missed digital transformation. I mean, the big retail chain could have become the e-commerce giant; they did not because they missed the digital transformation in a sense.
But, so back to say, I would say, I’m not too, I’m more into thinking from a long-term business perspective. Do we have a back-of-the-envelope calculation that tells us this is the right thing to do? Risk-adjusted, saying there’s, you know, do you think it’s 90% risk or 50% risk or 10% risk, and try to have the simple assumption but just to justify that and to get to this direction.
And now I think what is typically lacking is that, again, I was mentioning incrementalism. People think of their digital transformation as the same but a little bit better. Again, if we go back to Walmart 2002, the future is e-commerce, so it’s definitely not the same as just Walmart with more better point of sale with LCD screen.
This is not, you see, that’s the catch. The future is fundamentally something different, and I think that’s usually the place where businesses do not precisely step in enough to challenge what the company will look like in 10 years. What are the sort of roles? I think there was a very interesting memo from the CEO of Shopify that was circulating around on LinkedIn recently.
He was literally saying to everybody, “We pause all hiring for now, and every department will have to justify that what they want to hire for cannot be already done with the AI technologies, LLMs and whatnot that we have already acquired, implemented, and plugged into our system.” Shopify is a fairly high-tech company, so they have already several years of experience in that.
And he was saying, “Okay, we have a problem in terms of transformation. Clearly, the memo, the essence of the memo was the broader management was just not sticking to very incremental perspectives instead of being a lot more ambitious on the end game.” And I think the message was very interesting. They were not saying, “We don’t invest, we don’t hire.” They were saying, “You need to have an end game that acknowledges that those technologies exist and you should not be trying to go on a trajectory that just pretends they don’t.”
That was the case of the memo, and that was very interesting. I see a lot of large companies where in terms of what is your 10-year vision for the company that is digitally transformed, whatever that means, it’s just the same but with a slightly better user interface. And for me, this is very underwhelming.
Think 10 years ahead, you need to think of something where half of the jobs, especially white-collar jobs, that exist today are no more. It doesn’t mean that you fire people; you can retrain them, repurpose them, and whatnot. But the jobs themselves, there should be at least half of them, 10 years ahead, that are just gone, and they will be.
Eric Kimberling: Yeah, and I think you’re hitting on a really important point, which is, for people listening that are leading technology or transformation initiatives in their supply chains or wherever they might be working, I think it’s important for them to ask themselves: What do we want this initiative to be? Is this initiative to replace old technology and just keep up to date, which maybe is more of an incremental, ideally lower cost, but potentially lower ROI proposition? Or are we looking to transform our business, truly transform it, and look at new business models and look at innovation? Those are two very different paths, and neither one’s right or wrong. You just have to make sure that you are aligned and you’re making decisions that fit which path you’re going down. It shouldn’t be a one-size-fits-all proposition either; it should be based on who you are. Shopify’s digital strategy should look a lot different than yours or mine or anyone else’s.
Joannes Vermorel: I very much agree, but the problem what I see is that the path number one, just incremental upgrade low ROI, is where you get the massive budgets.
Eric Kimberling: Yes.
Joannes Vermorel: Yes, and for me, that’s like, how can you have this project that if you do any reasonable back-of-the-envelope calculation, your ROI is going to be very modest? Why do you spend? I have seen companies, and I’m not going to disclose names, but I’ve had discussions with companies that have $100 million-plus ERP upgrades that apply for five-year-plus projects. When I discuss with the top management, I mean, it’s very hard to see if there will be any return—not just return on investment, but just return. Once you upgrade, will the business be actually better? It’s not even clear, especially if you have to go to the sort of hardware requirement of SAP HANA that is, I mean, I’m just piling on SAP; they’re not the only one.
Conor Doherty: Punch up, that’s okay.
Joannes Vermorel: Yeah, but if you freeze your IT for five years, just the opportunity cost is just immense. It cannot just be something incremental; it has to be much more than that.
Conor Doherty: So Eric, if I can just pin on that because literally, Joannes, what did I just write there—first order, second order opportunity cost—literally, I had just written those exact words to pitch back to you. Eric, again as a consultant, I was literally just about to ask you, how exactly do you explain the concept of first order and second order costs? Because obviously, the first order cost: you buy this software, it’s going to cost you 50, 100, 150 million; you’ll have to hire people to oversee that will cost another x amount of millions, whatever. That’s the first order cost.
The second order cost is, as Joannes just said, the opportunity cost. The money that you just spent on that you now can’t spend over there because a dollar here cannot also be simultaneously spent over there.
Joannes Vermorel: Your IT team is inundated, frozen in time on this thing for a given amount of time also.
Conor Doherty: This, again, talks to the financial perspective that I was getting at earlier. How do you personally, when you’re in a room as a tech agnostic, help people grasp—and I’m not being condescending there, I just mean literally—you take a dollar, you can’t buy two candy bars if one costs a dollar and the other one costs a dollar; you can’t buy both of them with a dollar. So first order, second order opportunity cost, how do you cover those topics in a way that really resonates with people who, as you’ve said, have FOMO—they don’t want to miss out, they want to catch the wave, etc.?
Eric Kimberling: You’re alluding to something that we haven’t really touched or gone into in much detail yet, and that is realistic expectations and having realistic expectations around those first and second order costs. I think the root cause or one of the root causes of the problem is that organizations don’t understand what the real cost is, so therefore they can’t assess those opportunity costs because they think it’s going to cost 100 million when in reality it was never going to cost 100 million; it was always going to be 300 million. But someone convinced you that it could be done for $100 million, and that someone was overselling you, underestimating the effort, knowing that there’s complexities and risks that are probably going to increase the cost. If you think about it, when a software vendor or solution provider is selling you a solution, it doesn’t do them any good, from a self-serving perspective, to overestimate the cost. What helps them is to underestimate and say, “No, no, it’s low risk, low cost.” So the problem starts there.
So, okay, if I say I’m going to assess opportunity costs, those second order costs, I’m assessing it with faulty information. Even if I do it, it doesn’t matter because I don’t have the accurate information to make that decision. But I think if more companies knew the actual cost it was really going to be, then they’d say, “Whoa, whoa, hold on, that’s a lot of money. That’s money we could be using to build another factory. We could be opening 10 more stores for that same cost. Is that what we want?” Most organizations don’t come to that decision point because they’re basing it on an underestimated cost that was never realistic.
The other thing, too, well there’s one other thing that sort of—and I thought maybe this is where you guys were going with the first and second order cost—but another cost that we haven’t touched on yet is the operational disruption. You know, what happens when you first adopt new technology, no matter how well the project is run? There’s going to be a dip in productivity of some sort. Now, hopefully, it’s not a complete fall off the cliff dip in productivity; too often it is. But even if you manage it really well, you are just going to have some disruption.
So what is that cost of disruption, and what would happen, for example, if you can’t ship product for two weeks, four weeks, three months? That happens to organizations; they go through these projects, something goes wrong, they go live, and then they can’t ship products. Customers get upset, they cancel orders. Those are the real costs. Those are the costs that you’ve got to factor into your ROI, too, so you can optimize your implementation and make sure you’re managing the implementation well and that you understand what the real risk is.
Conor Doherty: You brought up a really good point there, Eric, and Joannes I want to come back to you again to take the example that Eric just gave. Like if you took somebody—and I’m not picking on anyone in particular—but if you just took the average sea level from, let’s say, the automotive industry or aerospace or oil and gas, and you said, “How much does an hour’s downtime cost loss productivity?” They would be able to give you a rough order of magnitude, but the kinds of downtimes that Eric just described, they might not be able to quantify.
Joannes Vermorel: Yes, and also I think for the operational cost, it’s completely spot on. One thing that people don’t realize is that productivity decreases when the complexity of your environment increases. So you see, you have a piece of software; it’s ancient, it does very few things, but it does the things that you need. It means that in terms of my IT environment, my user interface doesn’t have that many buttons, it doesn’t have that many options, it doesn’t have that many bells and whistles and stuff that I can do with it. Now I upgrade to something that is vastly more powerful. Why? Because the vendor, there were so many boxes that needed to be ticked in the AFP. We asked the vendor, “Should be able to do this and that and that and that and that and that, okay, 100 boxes later.” Now we have the upgraded system that can do tons of things in addition.
But that means that for the person who operates the software, you have so many more menus. And I’ve seen that over and over in enterprise software, where people show me the software and I say, “This is horrible.” It’s like you have 30 menus, and then I click any of the menu, and every menu has like 30 submenus, and maybe every submenu has like five submenus. And then you have like a wall screen with 20 different options on the screen.
And so, what I very frequently witnessed was people upgrade a software, especially those systems of records, toward a new, better one. Yes, the UI is nicer, but it has so much more features that actually productivity is lower just because people are lost into a maze of features. And so, that’s the interesting thing is that in enterprise software, more is not necessarily better, especially more features. Especially more features that you don’t use.
Every single feature in a system that you don’t use is just dead weight. It means that it will confuse every new recruit that will come and start to use that. They will say, “Why doesn’t it work?” Ah, because there are like five different screens to do purchase orders, but we only use one of the five. The other four, no, they’re just dead ends. If you enter your stuff there, it will not be processed; it will just be lost and ignored. That’s the sort of things that you can have.
Eric Kimberling: Yes, absolutely. I mean, it’s such a good point, and it gets back to really defining what it is you need. I mean, do you need all that technology? A lot of times companies bite off more than they can chew, and they overcommit to the technology spend. And then it creates so much complexity just on the technical side that then you don’t have the time or resources.
Back to your point about opportunity cost, now you don’t have the time or resources to invest in the things that really matter. And the things that really matter are: let’s optimize our business processes, let’s make sure the people are trained well, let’s make sure we’re getting adoption, let’s make sure we’re redefining people’s roles and responsibilities to fit the new technology and the new operating model.
Those things are what make or break a system or a transformation. But yet, companies are overinvesting in technology. I’d much rather see a company that buys just a little bit of technology but implements it really well because that company’s going to be more successful. They’re going to decrease the risk, they’re going to probably get a better ROI.
And then, once you’ve done that too, by the way, once you take that small technology investment and do it really well, then you build confidence and capabilities and maturity in your organization to where now you can say, “Okay, I’m going to take on a bigger project now. Now I feel confident we’ve learned enough that now we could invest in a little bit more technology.”
And instead of just buying one big massive system, spending all this money, and then feeling the pressure to implement it all because we paid for it, and then it creates all this complexity, then we don’t invest in adoption and process improvement, all the stuff that’s important. And that’s where a lot of these projects spiral out of control.
Conor Doherty: Actually, and again, much like Joannes earlier, you’ve teed up exactly what I just wrote down as the next question or as a follow-up. We’ve discussed at some length the problems and the landmines to try and sidestep. But that really brings up the actual concept of implementation and managing change management, the process of change management.
So, Eric, first to you, I mean, on a brighter note, are there any things that you’ve observed in successful digital transformations, certainly in the context of handling change management, all the culture, the expectations, etc.? What are the things that actually help with that?
Eric Kimberling: Yeah, I mean, I’ll go back to the term you used—honesty—you said was it mechanical sympathy, sympathy? I was saying mechanical curiosity in my mind. Both kind of work, to be fair. It’s kind of the same. Mechanical sympathy—I knew I messed that up earlier on. But mechanical sympathy is a really important one.
Because the most successful projects we’ve seen are the ones where the business leaders in the organization are hands-on. They understand the technology; they may not be experts in configuring and coding, they don’t need to be, but they do understand how the technology works. And they definitely understand how their business works and how they want their business to work.
That mechanical empathy will lead to more ownership and more business-driven outcomes rather than technology-driven outcomes. So that’s one thing we see a lot of: that ownership of the project, the hands-on involvement from the business leaders in the organization.
The other thing is, I guess it’s somewhat related to this, is they don’t outsource the transformation. They don’t just say, “We’re going to bring in big vendors and let them handle it all.” They say, “We are going to bring in experts, but we’re going to manage them.” Just like you would manage a subcontractor or a general contractor if you hired someone to build a new factory.
They’re probably not just going to say, “We don’t care, just go build the factory, use best practices, do what you need to do to build the factory.” No, they’re going to be heavily involved, making sure that the factory meets the specifications and whatnot. But with technology projects, a lot of companies don’t do that. So the more successful companies treat technology investments and transformations just like any other capital investment.
They don’t treat it any differently; they expect an ROI, they’re going to limit the budget, they’re going to be heavily involved, they’re going to have a lot of say in how things go. So that stuff all happens upfront, and that’s an important success factor.
Another one is just back to a point that one of you made earlier on, which is the decisions that are made early on. I don’t want to say the execution doesn’t matter because it does matter, but what’s even more important are the things that lead up to the actual execution—the decisions that are made, the priorities that are set, the alignment.
Getting the alignment amongst the team, because a lot of times when we walk into a room with, say, seven executives and you’ve got our steering committee here, and if I ask them, “What does this transformation mean to the organization?” usually you’re going to get seven different answers. And none of them are right or wrong necessarily, but you’re all saying different things, and you can’t be successful.
You just aren’t going to be successful, no matter who you hire, no matter what technology you invest in, you aren’t going to be successful if you’re not all on the same page. It’s a messy process, and in theory, it might slow down the project in the short term because now you’re saying, “Hold on, let’s stop the technology, let’s not do that yet, let’s get aligned first.”
People think, “Well, but we need to start today.” You know, we’re behind schedule already, we need to go, and we’ll say, “Well, slow down, because if you rush into it, you’re just going to rush off a cliff. So let’s make sure you don’t go off the cliff; take the extra time to make sure you’ve got a clear path and then get on the same page.”
So that alignment and taking the time to set strategic goals, parameters, priorities, the business case, expectations, governance, defining our future state business processes—what do we want our processes to be going forward? What do we want the organization to be going forward? All that stuff has to be defined upfront before you start deploying technology, and that’s a really important success factor.
And then the last one I’ll mention is just the investment in change management. The companies that invest heavily, and when I say invest heavily, I don’t necessarily mean a lot of money. I mean they’re investing time and focus on organizational change, communication, adoption, clarity for the organization. All that stuff dramatically increases the success rate.
Joannes Vermorel: Agree with your anecdote. In fact, in software, you know, I’m also a software engineer. There is this saying that, “Oh, I spent three hours thinking about the problem I wanted to implement. I spent three hours, and it cost me three weeks of extra implementation.”
But back to the initial case, I see a lot of companies, you know, large companies take this idea, “Oh, yes, we need to plan carefully.” They have heard this advice; we’re not the first to say that. So they do that, but I see a perversion of this sort of thinking, which is I completely agree it is the right way. You need to be thinking very clearly and take a little bit of time, probably, on this phase that is super critical.
But what I’ve seen is that many large companies corrupt this idea through their organization into a box-ticking exercise or a bureaucratic exercise like, “Oh, we are in the planning phase, so I need this report and this report and this validation and this audit and this diagnosis mission and this and this and this.” And what you end up with is not clarity; what you end up with is a case that can be thousands of pages long that shed zero clarity. It’s what I say technocracy.
It’s this planning phase where you just end up gathering things from the organization, and everybody will kind of overcomply with the request. So imagine you’re the board, and now, in one month, your teams have gathered several thousand pages of assessment, diagnosis, etc. And nobody has any clue of the content. It’s a little bit like the omnibus spending bill of Congress in the US. It’s like a massive document, many thousand pages long, and nobody has any clue what goes in it.
My take is that there is also in this planning phase the realization that people should not do this as a technocratic exercise. You need to be able to maintain clarity in a document that is probably, I would say, between five and 20 pages long max. If you can’t have something that is clearly expressed in max 20 pages, ideally shorter than that, then probably you’re just lost in a technocratic maze.
Your path is going to be very misguided afterward. And I say pages written in text, not PowerPoints, because with PowerPoints, you can cheat with the bullet points—you have no logical connection, so you can have something that is super ambiguous. If you write in English with proper signaling and connection, then you can’t cheat; you need to have something that makes sense and a document that you can read aloud. That’s kind of my take on this sort of thinking.
Eric Kimberling: That’s a great point. And the team that’s executing the project needs to have that clarity too. You know, if you think about a supply chain transformation, let’s just say you’re an organization looking at deploying a complete supply chain technology. It’s easy to get lost in a lot of complexities and details.
If you treat it as a sort of democracy where everyone has an equal say and priorities and requests and things they want out of the system, the project’s going to spiral out of control. You need governance in place to say, “You know what? Yes, we’re doing the supply chain transformation, but procurement isn’t our top priority right now. Instead, what it is, it’s supplier management, it’s vendor management.”
Because guess what? The United States government is imposing all these tariffs now, or there are all these geopolitical things we’ve got to navigate, so we need better supplier management, and that’s our focus. You need to prioritize and say, “We’re doing this because we want to overhaul our supplier management processes” and manage it accordingly.
If you don’t have that clarity in that 5 to 20-page document and you can’t get everyone on the same page, then it’s going to turn into a free-for-all where everyone just asks for whatever they think they want.
Joannes Vermorel: By the way, for the record, I’ve seen many companies, and I’ve never seen high-quality documents except for leaked documents from American tech companies like Amazon, Shopify, Apple—leaked memos that are super clear, written in five pages, beautifully written. You can see that the management really has a very sharp understanding of where they are, where they want to go, etc., and they write very clearly and concisely.
When you go to non-tech companies, it’s exceedingly rare to see that. Exceedingly rare. I can maybe think of only a dozen of companies. Berkshire Hathaway, for example, their memos are absolutely brilliant; it is crystal clear what they’re doing, why, etc. But typically, for companies we were mentioning, like Lidl and whatnot, I am 100% sure that nobody had a simple memo of what are we even trying to achieve here? Why are we convinced that this thing has any kind of reasonable chance to succeed?
Most of those big projects that I’m witnessing—Lokad is sometimes part of them—you know, they upgrade their ERP, they upgrade their supply chain analytics with us. It is just so rare; that’s why I’m mentioning it. I almost never see any degree of clarity when it comes to digital transformation. It’s just layers upon layers of technocracies.
Again, you were mentioning outsourcing—also parties that are completely outside the company. So those decs, thousand pages, half of them would be provided by third-party vendors.
Eric Kimberling: I wonder if that’s really interesting, what you say about tech companies. I wasn’t aware of that, or I hadn’t made that connection before. You know, maybe tech companies are more capable and mature in their ability to provide that clarity.
But I wonder, sometimes I wonder if, you know, the executives now—you think about executives that have grown up in the tech space since maybe the ’90s, okay, maybe they’re around my age or a little bit older. I remember Windows 98 came out, and it was such a big deal when Windows 98 got rolled out.
It was sort of a disruption for a lot of companies because they had to go through these big Windows upgrades. But at the end of the day, it was a Windows update; it wasn’t a transformation. It was, “We need new operating systems for our PCs and our desktops and laptops.”
I wonder if the executives that grew up in the IT space during that time still think of tech projects as a Windows 98 upgrade, and they fail to recognize that this is not a Windows 98 upgrade. This is a massive overhaul of not just your back-office systems and databases but your processes, the way you’re organized, all that stuff.
That’s just a pure hypothesis. I don’t know if it’s true or not, but I’m trying to get to the root cause of what we’re talking about here to figure out why that is.
Joannes Vermorel: My take is that when I look at digital transformation plans for most non-tech companies, usually, as a technologist myself—Lokad is a software company that does essentially robotized decision-making for supply chain—what I see is that those digital transformations seem extremely tame to me.
When I think of digital transformation for my own company, because those technologies, as you mentioned, are evolving and a lot of things are changing for Lokad, I see a future 10 years ahead where maybe more than half of the jobs that we have will be gone in terms of tasks. The people will still be there, no problem, but they will be doing different things.
When I look at the classical non-tech companies—think of an aviation company, a manufacturing company, a retail company, a fashion company—you know, companies for whom technology is just something on the side, when I look at their digital transformation, it is very, very tame.
There is almost no job being removed, no task being eliminated out of the box. When you think of what tools like, for example, ChatGPT can do, you see there are entire classes of tasks that can obviously be automated.
So anyway, my take is that digital transformations are very frequently lacking ambition; they are extremely tame. The only thing that is not tame is the budget that they have to do the upgrade.
Conor Doherty: Just jump in and build on that because I think, in the background, it’s sort of like opening loops. If you go back to the actual very opening loop the fundamental thought actually in terms of mentality and how we even frame the problem to come back full circle, the problem that we’re trying to solve. Joannes, I’ll come to you first and then to Eric for a comment.
Joannes, I actually opened up in the background because something Eric said earlier about capex vs. opex reminded me of a lecture you did on product-oriented delivery for supply chain in which you made the argument that supply chain is not opex supply chain. It should be recategorized as capex treated as an asset, and it occurs to me that the simple framing of that problem, like not treating it as a supply chain and all of its associated costs as, well, it’s just like biscuits or pens. It’s just things I need to get through the day, treating it more like an asset that can scale and appreciate in value might be a more helpful way to start the discussion in the first place, be it hiring people or finding software. So, could you perhaps expand a bit on that distinction?
Joannes Vermorel: Yeah, I mean, it’s my own personal take. When I look at white-collar jobs, unless there is something really special about it, I think it’s just something that the company needs to pay to get a certain output in terms of information transformation. A white-collar worker is basically taking information in and producing information out that can take many forms. But a lot of people, especially in back office, that’s what they do in large companies. In supply chain, for example, you have people that will get the stock levels for their ERP and plus many indicators of the recent sales and whatnot, and what will they decide? They will decide for every single SKU, storage keeping unit: “Do I need to reorder, yes or no?” I have a thousand SKUs to manage. The organization is split with one supply and demand planner has, let’s say, 1,000 SKUs. We have 80,000 SKUs in total, so that’s 80 supply and demand planners, and each one of them every day goes through 1,000 SKUs and emits the replenishment order for the day. A lot of companies are organized exactly like that.
So, my take is that when you think of your supply chain practice like that, the people that you have are pure opex. You need to spend those salaries every day so that your company does not stop operating. If you stop paying those people, they don’t do it, the company halts, the flow of goods halts. If you think the way Lokad approaches it is to say, “No, we should think of the supply chain practice as something that is capex. We have people who are engineering software, one way or another. There are plenty of ways; low code, you don’t necessarily have to code, but you engineer software that generates those replenishment decisions automatically.”
And then, if you have to pay one person more, it is to improve the system. In this case, your investment is capex. You have this piece of software that runs automatically, and you have the opex, but it’s just for the software, so spending is very low. And when you spend money on people, it is to improve the system, and thus it is very capitalistic. It’s accretive; it’s like an asset should be. Yes, it becomes an asset. So, your investment in people becomes an asset; the output of those people is a tangible asset for your company, which happens to be this decision-making system.
What I see in terms of those modern digital transformations is that they seem to be extremely tame in the sense that there are tons of jobs that are pure opex white-collar jobs that should become capex. When people work one hour, they deliver something that is accretive, something that builds an asset of some kind, probably software, but it can be other things that have value for the company, independently, of the continued work of the people. It may sound a little bit strange, but it’s as if those people were engineering the machine, and then you can keep the machine running indefinitely. I am simplifying, obviously; those machines need maintenance and whatnot, but most of the digital transformations I see are extremely tame because what they are just looking at is those people who were used as opex, so pure consumable. I need to reuse to have the time of those people again and again and again.
I’m talking of purely informational tasks, not flipping burgers in a restaurant. For that, you need hands. We don’t have robots yet that are capable of flipping burgers. But I’m talking of anything that is like a white-collar back-office job. For me, the sort of most digital transformations are barely addressing the fact that those things should most of them be completely robotized again, back office, so we are not even in front of the clients. It is pure internal busy work, and yet, for many large companies, that can easily be two-thirds of the white-collar workforce is back office busy work inside the company. Very frequently, I see those digital transformations are not even scratching the surface when it comes to addressing this enormous amount of opex that should be transforming to capex, but that’s a very personal take.
Eric Kimberling: You’re really hitting a really interesting point and a bigger challenge, I think, in the tech industry, the enterprise technology space in general. You’ve talked a lot about capex and opex and treating IT as an asset, but if you look at where the technology vendors are headed, they’re headed towards a model where it is not an asset to their customers; it’s the asset to the vendor. And it’s always been that case, obviously; it’s their product, it’s their IP. But what’s happening is we’re moving from on-premise where you know you invest, you make that capital investment, you tailor the software to fit your processes and that sort of thing, and that becomes an asset that you depreciate, and it’s viewed differently than where we’re going now, which is we’re going to move everything to the cloud. All our data is in the cloud. Now it’s moving from a capex to an opex, and it’s not just an accounting decision of whether it’s capex or opex.
It’s a mindset change because now what’s happening is, like AI is another example. If we look at AI, what’s happening is these big technology vendors are saying, “Hey, we’ve got this AI technology that can deliver magnificent value to your organization.” And that may be true, but what’s happening in the process is we’re taking our data, our intellectual property within the company, and we’re using that to train these AI models that are being used in other competitors and other firms. Now the vendors, the center of power is moving from the customers to the vendors because now the vendors don’t own the data, but they own the AI and the technology that’s using your data to train it to make it a better AI tool to go sell to other companies.
So, that’s important. That’s a really important thing to think about, asking a bigger question of what is IT to us. Is it a commodity that we just want off the balance sheet, we want it out of our operations because we just don’t want to deal with it? Maybe. I mean, that might be okay for some organizations. But you mentioned Amazon and Spotify. I guarantee Amazon and Spotify do not view IT as just a commodity that someone else could manage. It’s a significant competitive advantage, and we don’t all have to aspire to be Amazon or Spotify, but we can aspire to say, “For example, if our competitive strength is we’ve got a really efficient supply chain, we can deliver products to customers faster than anyone, and we can customize our products fast and get them to our customers faster. Okay, that’s your competitive advantage. Now let’s build technology that’s unique to you so it makes that competitive advantage really hard to replicate. If I just go get a cloud solution that anyone else can buy, then I’ve lost my advantage.”
So, this whole movement towards cloud standardization of processes, using data to train AI models for other people’s benefit, is shifting. I think it’s a very dangerous trend that’s going to cause a lot of regret for organizations for years to come. So, I think it’s important to stop and think. If we want IT to be a strategic asset that’s a differentiator for us, then let’s treat the project as such. Then, that probably means we don’t go with a standard off-the-shelf technology that’s in the cloud. Maybe we do go with a more tailored custom solution, even though it’s a bad word and you’re not supposed to talk about customization, you’re not supposed to talk about custom dev. That might be the right answer for you if you’re viewing IT as a strategic advantage.
Joannes Vermorel: Advantage, yes, and I would also point out again, many vendors have absolutely terrible incentives. Again, the vast majority of enterprise software vendors are charging per seat. So when you are charging per seat, you are definitively not looking for productivity improvement. If you can make your software less efficient or less productive, then you will have more seats.
You see, it’s—I mean, obviously, enterprise software vendors are not, you know, they are not evil. Most employees are just good people, just like 90% of the population. They don’t try to make their product worse just to get more seats, but still, the power of incentives is just extremely important.
It means that, for example, if there is a venue for the software vendor that requires tons of people operating the software, those things will be in the… When the CEO of the software company looks at his own sales, they say, “Oh, look, there is so much traction there.” Yes, yes, because here, in this area, we need so many people interacting with the software, so that drives the revenue.
And suddenly, it becomes very complicated. Do you really want to challenge yourself as a software vendor if you are charging per seat into something where your next upgrade will maybe eliminate 90% of your seats? It’s—it’s a very, very tough question. It’s a very tough question. By the way, historically, that happened already to IBM. IBM was charging per MIPS, millions of instructions per second in—that’s what they were doing in the 80s and 90s. And guess what? When IBM was charging per MIPS, their software was slower and slower at every generation, obviously.
Eric Kimberling: Yeah, I mean, you’re raising a really—another topic that we could spend an entire episode talking about, and that is misaligned expectations or misaligned incentives. You know, if your software vendor and your system integrator, and, you know, there’s three parties, three primary parties, if all three of you have very different conflicting incentives, then it’s hard to overcome.
Conor Doherty: Sorry to interrupt, but I am mindful of Eric’s time. You’ve been very gracious in staying with us, so I will—at least we may return to this and talk about the ethics of everyone’s actions. But for today, I will transition to a closing thought. I’ll start with you, Joannes, on a bright note again. What advice would you give to organizations in spite of everything that we’ve said or taking into consideration everything we’ve said? What advice would you give to organizations that are about to start their digital transformation?
Joannes Vermorel: As a four decades-long software enthusiast—I was an enthusiast even, you know, a while ago on software, even if it was mostly video games when I was very young—as a lifelong software enthusiast, I would say I don’t think there has been a better time where the software technologies were promising so much. It is just amazing for me—the deep learning revolution, its descendant with LLMs and whatnot. It is almost magic, you know, the idea that you can have something that can process natural language to do a lot of things.
It’s absolutely incredible, and those technologies are easily accessible. They’re not necessarily cheap, but they’re easily accessible. So I would say there has never been a period where you could expect more from a digital transformation. I think right now, if you think of that digital transformation, hold the promise to really make your company a completely different beast that does so much more for your clients in so many ways. It can be better service for your clients, smarter operation. You name it; it has a potential that is absolutely massive.
So I would say, dream big and then spend carefully and incrementally on stuff that are not like mega projects because risk—that would be my message for digital transformation. You need to put yourself in a position of failing fast, because, as a software vendor, I can tell you that if you ask a client, “Can you give me a really bad estimate for what will happen during the next six months?” Six months, I can maybe do that. Yes, one year starts to be tricky; two years is tricky, tricky, because I can have people rotating in and out. It might be as disruption a two-year long project to process, it’s very difficult.
Five years—oh gosh, this is like we are trying to engineer the Death Star. So my take is that, yes, digital transformation has enormous potential. That’s excellent, it’s not that expensive, so you should try instead of thinking we need to make sure it works. I would say do the opposite: do things that are small and make them fast and fail fast, so that if it fails, you can very acknowledge that it’s sunken cost and move on instead of doubling down and doubling down and doubling down, which is the exact recipe for enterprise software vendors who end up getting their clients overspending 10 times compared to what was originally spent.
You need to be able to say, “No, we are stopping. We tried, we’ve seen, we are done. We are going to try something else because the world is vast. We have so much potential; we don’t absolutely need to stick to the original plan. It’s okay to have to fail an initiative after three months. It is just not okay to fail after three years.”
Eric Kimberling: After you’ve already spent billions or hundreds of millions of dollars.
Joannes Vermorel: Yes, yes.
Conor Doherty: Well, Eric, it’s customary here to give the last word to the guests, so again, same question: any advice to share for people or companies that are about to start their journey?
Eric Kimberling: Well, I mean, that was great advice you just gave. And I would maybe add to that that, you know, invest in—invest in change management. Make sure you’re investing your time in change management to make it less likely that you’ll even need to fail fast. But I do agree, you do want to fail fast, and that’s why I think starting small, starting slow, and then speeding up is a lot more effective than starting off too fast and too big and then having to slow down later. That just creates a lot of morale issues, a lot of uncertainty and doubt in the organization.
So, yeah, fail fast, but also invest in organizational change. And the other thing I’d say is just take your time up front because those first few months of a project, before you ever start implementing technology, that’s where the trajectory is set. I mean, you’re setting the vision, the parameters, the direction of the project. So be sure to get that part right. If you don’t, if you have doubt as to whether you have that clarity, then get it, you know, take your time to get that part right.
Because the more time you spend up front getting that part right, the faster it’s going to go overall. In fact, you’re going to implement a lot faster and save a lot of time and money if you just slow down early on. You can always speed up later, but start slow. That’d be my last closing advice.
Conor Doherty: I don’t have any further questions. Thank you very much for your time, Eric, greatly appreciated.
Eric Kimberling: Great conversation, a lot of fun too, I enjoyed it.
Conor Doherty: So, Joannes, I have nothing else to say but thank you very much for your time, Eric, again. Thank you very much for yours, and thank you all for watching. We’ll see you next time.
