What is digital transformation?

Digital transformation is one of the least precise terms in business software, and the imprecision is expensive: three quite different undertakings get the same name, get budgeted the same way, and fail for different reasons.

A working definition worth using: digital transformation is changing what the business does or how it makes money because technology made something newly possible. If the business model is unchanged at the end, you did something else, which may well have been the right thing.

Three things that get the same name

Digitisation converts something analogue into data: scanning documents, putting a paper form online. The process is unchanged; the medium is not. Digitalisation changes how a process runs using that data: the order no longer needs retyping, the approval happens in a system, the report generates itself. Transformation changes what the business sells or how it earns: a manufacturer selling uptime instead of machines, a wholesaler opening a self-service channel that changes who the customer is.

Most programmes labelled transformation are digitalisation, and that is fine. The problem is that they are then governed like transformation (multi-year, board-sponsored, with a change narrative) when they are really a sequence of process improvements that would go faster with less ceremony.

Why transformation programmes fail

The dominant cause is structural rather than technical. Large transformation programmes are designed around economics that no longer hold: they assume building software is expensive and slow, so they front-load certainty: long analysis, a full specification, a single large commitment.

Building a first working version is now dramatically less expensive. Which means the rational shape has inverted: several small experiments beat one large plan, because the expensive thing is no longer the build, it is knowing what to build. A three-year programme fixed at the outset spends its most confident decisions at the moment it knows least.

The constraint is almost always data, not systems

Ask where a transformation programme actually stalls and the answer is rarely the new system. It is that the data needed to run the new process lives in an old system nobody can export from cleanly, in formats that disagree, with no owner willing to declare which version is correct.

This is why replacing a legacy system rarely delivers what was promised on its own: the new system inherits the same ambiguous master data, and the ambiguity was the constraint. Deduplicating customers, agreeing article identifiers and deciding who owns each field are unglamorous and are usually the highest-leverage work available.

Maturity models, and a more useful question

Digital maturity models (five stages, a radar chart, a score) are mostly a sales instrument. They produce a number that feels diagnostic and rarely tells you what to do on Monday.

A sharper question: which decisions in this business are currently made without the information that already exists somewhere in it? That points at a specific gap between data and decision, which is actionable, rather than at a stage on a scale, which is not.

What to do instead of a programme

Pick three processes rather than one strategy. Give each a named owner, a measured baseline, a written pass mark and a stop date, the structure described in our guide to running an AI pilot. Expect to stop most of them, because a portfolio where everything succeeds was chosen too safely to be informative.

Then, and only then, consider whether the pattern that emerges justifies something structural. Transformation, if it happens at all, is usually recognised afterwards rather than planned in advance.