“Digital transformation” has become a phrase people say when they mean “we bought software.” That is why so many transformation programmes produce a new system, a training day, and a workforce that quietly keeps using the spreadsheet.
The pattern under the successful ones is not technological. It is that somebody changed how a decision gets made, and the software was downstream of that.
The spreadsheet test
Six months after any new system goes live, ask one question: is anyone still keeping a private spreadsheet?
If yes — and it usually is yes — the system failed to do something the spreadsheet does. Not something trivial. People do not maintain shadow records out of stubbornness; they do it because the official system is slower, refuses a legitimate case, or cannot answer a question they get asked weekly.
Find those spreadsheets and you have a precise list of what the transformation missed. It is the cheapest audit available and almost nobody runs it.
Where the money actually goes
| Line | Typical share of budget | Typical share of attention |
|---|---|---|
| Software licences | 20–30% | Most of it |
| Implementation and integration | 30–40% | Some |
| Data cleanup and migration | 15–25% | Almost none |
| Training and change management | 10–20% | Almost none |
| Running it after year one | Ongoing | None, until it hurts |
Data cleanup deserves particular mention. Moving messy data into a new system produces a new system full of messy data, and then everybody blames the software.
Start where the pain is measurable
Transformation programmes that begin with a strategy document tend to end with a strategy document. The ones that stick begin with something specific and irritating that somebody can name:
- Someone retypes numbers from PDFs into a spreadsheet every week
- Two teams keep separate customer lists and they disagree
- A monthly report takes three days to assemble
- Approvals sit in an inbox for a week because nobody knows whose turn it is
Each of those has a number attached — hours a week, error rate, days of delay. Fix one, measure it, and you have both a result and the credibility to do the next one. That sequence is what makes a programme survive its first setback.
The four questions before buying anything
- What decision will be made differently after this? If the answer is “none — we will just do the same thing in a nicer interface”, the return will be small.
- Who loses something? Every change removes someone’s control, visibility or convenience. Naming it early lets you address it; not naming it does not make it go away, it makes it quiet.
- What is the manual fallback? Systems fail. If there is no answer, the business stops when it does.
- What does year three cost? Licences per seat, integration maintenance, the specialist you now depend on.
Why adoption fails even when the software is good
Almost always one of three reasons, and none of them is fixed by more training:
- It is slower for the person entering the data than for the person reading it. Classic CRM failure — sales enter, managers benefit, so entry quality collapses. Someone has to make it worth the enterer’s time.
- It refuses a real case. The system cannot represent something that happens in reality, so people route around it, and the exception becomes the habit.
- The old way still works. If the spreadsheet is still there, it will still be used. At some point the old path has to be closed, deliberately and with warning.
The same principle applies to tools generally — the ones that get abandoned are the ones where the cost lands on a different person than the benefit. We looked at that from the individual side in fix the leak, not the app.
Common questions
Where does AI fit into this?
Best at the specific, boring tasks with cheap verification — document extraction, transcription, categorisation. Worst as a strategy. We put numbers on which categories pay back in AI tools for business.
Should we hire a consultancy?
Useful for a specific implementation with a defined end. Less useful for deciding what to change, because the people who know where the friction is already work for you and can usually name it in ten minutes.
How long should a programme take?
Each step should show a result within a quarter. Anything longer than that loses its sponsor to a reorganisation or a budget cycle, which is how most multi-year programmes actually die.
What is the most common mistake?
Buying the system before agreeing what decision it changes. Everything else follows from that one.
Leave a Reply