Digital transformation without replacing everything

There is a pattern that repeats. The company decides to modernise, buys an integrated system, spends nine months implementing it, and at the end the team is still using spreadsheets — now in parallel with an expensive system nobody adopted.

The mistake is not the technology. It is the order of the questions.

Start with cost, not with the tool

Before looking at software, measure. Pick the five processes that consume the most time and answer, for each: how many hours a week, from how many people, and what happens when it goes wrong.

This exercise always produces two surprises. The first is that the most irritating process is rarely the most expensive. The second is that two or three of the five need no software at all — they need a decision nobody has taken about who does what.

Fix the non-technological part first

Automating a badly designed process gives you a badly designed process, faster and harder to correct. If approvals take time because three people must agree and none has the final word, no system fixes that. Name the owner and the problem disappears at no licensing cost.

This phase usually removes half the original list.

One change at a time, with a way back

For what remains, the rule is sequential. One change goes in, stabilises, and only then does the next. Each with three things defined before starting:

• A measurable success criterion. "Cut weekly invoicing close from four hours to one." Not "improve efficiency".
• A short deadline. Six weeks per phase is a good limit. Anything that cannot be broken into six weeks is probably not yet properly understood.
• A path back. If it fails, how do you return to what existed? If there is no answer, the scope is too large.

Choose boring technology

The temptation is to choose what is new. The right test is different: how many companies use this, how long has it existed, how many people on the market know how to work with it, and what happens if the vendor shuts down.

Mature, common technology is cheaper to hire for, easier to replace and far easier to hand to whoever comes next. Originality belongs in the product you sell, not in internal infrastructure.

Treat adoption as part of the project

A system nobody uses is an expense, not an investment. Reserve a real share of the budget for training and support — not the two days at the end, when neither time nor money is left.

And identify, within the team, who owns the system after handover. Without that person, any implementation degrades within six months.

The sign that it worked

It is not the feature list. It is the parallel spreadsheet having disappeared — and nobody noticing.