The Odometer Problem

In the summer of 2005, when I joined Danone, I was struck by something a senior executive said to me at the time. He compared businesses to cars. Different sizes, different brands, different engines, different designs — and it was precisely from that variety that a company could stay agile and adjust to whatever the market threw at it.

I have thought about that image for many years. Mostly because of what was happening at the time.

The hype of the moment was standardisation. Without a serious degree of it, the modern ERP journey was known to be long and costly. So companies did the sensible thing: they defined standards, imposed them across the organisation, and enforced adherence.

That effort created the basis of what GBS and Shared Services are today. It was ERP standardisation that unlocked scalable operations, with Processes designed to handle high transaction volumes. Nobody was worried about labour cost — the shiny new operating model was mind-blowing enough on its own. And let us not forget that until that moment most accounting sat in standalone systems, or on paper. Manual work did not mean copy and paste. It meant physically printing and signing documents.

Fast forward twenty years. We are still running the operating model built back then, and we have spent two decades squeezing every last drop of productivity and cost out of it. Let us be honest with ourselves: most companies have done a superb job of optimising that equation.

We built one very good car. Then we spent twenty years servicing it.

The car in question

A few years ago my parents sold me their Renault Espace. My mother drives it through the winter; whenever I am home it becomes the family car for the summer. If you do not know the story of the Espace, it is worth reading — but let us just say it is the best European family car ever built. Engines designed for long distance. Remarkable interior space. Real comfort. The ultimate family car.

This summer, the more I drove it, the more I wrestled with the idea of replacing it. A newer model, perhaps an electric one. And the more I ran the numbers, the more it looked like I already had a reliable, cost-effective vehicle that meets every need I have and has another 200,000 km in it if I look after it properly.

So I ran the scenarios through a well-known LLM.

To my surprise, it told me categorically to keep the sixteen-year-old family car.

The answer I asked for, not the answer I needed

I sat with that for a while, because it felt contradictory. Here was the most advanced technology I have access to, recommending I hold on to a manual, analogue, classical machine rather than replace it with something newer and considerably more technology-enabled.

Then I looked at the question I had actually asked.

I had asked about cost per kilometre. Depreciation. Maintenance schedules. Residual value. Given those inputs, the model was not wrong — it was flawlessly, rigorously right. It optimised the vehicle I already owned, because that was the only vehicle in the question.

What I had not asked was what I actually wanted the car to do for the next fifteen years.

This is the Broken Sequence, in a driveway. Most organisations run Business Problem → Technology → Data → Process. I had gone straight from problem to technology and skipped the step that matters most: Desired Outcome. And because I skipped it, I received a beautifully reasoned case for keeping exactly what I had.

I suspect a great many GBS leaders are currently receiving the same answer, for exactly the same reason — and mistaking it for validation.

Ask AI to optimise your existing operating model, and it will optimise your existing operating model. It will find efficiencies you had not spotted. It will build you a defensible business case. It will tell you the machine has plenty of life left. And every number in it will be correct.

That is not a strategy. That is a very expensive second opinion on a decision you had already made.

The mileage left to run

The more I drove the car, the more I appreciated it — and the more I researched how to keep it running. Which parts to buy in advance. How to modernise it. How to make it feel current.

Somewhere in the middle of all that, the aha moment arrived.

Every kilometre I drive brings this vehicle closer to its end of life. I intend to enjoy that final phase to the maximum. But I cannot hold on to it forever, and no amount of retrofitting will turn it into something designed after 2009. It was built for another time and another context. Adapting it until it matches a newly designed vehicle is simply not possible — unless I remain stubborn enough to keep trying to prove myself wrong.

I wrote about this a year ago and I was too generous. I said GBS 3.0 was like designing an electric vehicle from scratch rather than converting a combustion engine. I framed conversion as the harder path. It is not the harder path. It is not a path at all. You cannot retrofit your way to a different architecture — you can only make the old one more comfortable while it runs out of road.

So what does the new one look like?

This is where the White Canvas matters, and where the 2005 conversation finally closes.

That executive valued variety because variety created agility. Standardisation gave us scale and took the variety away — a trade we were right to make at the time, because scale was the constraint. It is not the constraint any more.

The new vehicle is not a better-optimised version of the old one. It is designed backwards from the outcome. Data as the cipher key, because without a common language across systems the machine cannot read its own instruments. Processes designed for what we want them to produce, not inherited from what the ERP could accommodate in 2005. Agentic capability wherever integration is not possible. And an orchestration layer that is unambiguously human — Process Owners and Data Stewards carrying the accountability, the intent, and the authority to cross boundaries.

That is the Perfect Process. Designed, deployed, run. And once you have one, you can share it — which is where GBS Condominiums stop being a thought experiment and start being a business model.

What this asks of us

We can keep things for pleasure. We can let them become heritage pieces. What we cannot do is change their design or their purpose.

The same applies to the GBS operating model. It is time to move — and the faster we accept that, the more responsibly we can manage the transition, preserving the solid base we spent decades building rather than being forced to abandon it in a hurry. The technology available to us today is not here to support marginal adjustment and continuous improvement at the pace we were accustomed to.

GBS is no longer a cost-cutting, productivity-generating machine. GBS is the Enterprise engine. The future operating models are ours to build — respecting our past, respecting what we inherited, and recognising honestly how difficult it is to let go of something that has worked well and stayed reliable for so long.

I am genuinely excited about that engine: powered by AI, orchestrated by Humans, designed to run Data-driven, digitally enabled Perfect Processes.

But first, we have to ask the right question.

What about you? Are you asking the right questions to challenge your established ways of working?

The content of this article is based on the author's own independent reflections and thoughts and is not in any way associated with any company or organisation and has no commercial intent.