The order of operations in a digital transformation

Sequence is the decision, not scope

Ask a business what its transformation programme involves and you usually get a reasonable list: fix the data, replace the ageing system, automate the manual processes, improve the customer-facing experience, get some analytics in place. The list is rarely the problem.

What determines whether the programme succeeds is the order, and specifically whether early phases produce something that funds and justifies later ones. Programmes structured as a long build with value at the end are structurally fragile: they depend on eighteen months of continuous sponsorship, and sponsorship in most organisations does not survive a change of priorities, a budget round or a departure.

The alternative is not to do less. It is to sequence so that each phase delivers something usable, measurable and defensible on its own — which incidentally means that if the programme is stopped halfway, what was built is still worth having.

The dependencies that are real

Some ordering constraints are genuine and ignoring them wastes money. Measurement comes before optimisation: you cannot demonstrate improvement without a baseline, and a programme that does not capture one before it starts will spend its second year arguing about whether it worked.

Data quality comes before automation. Automating a process that operates on inconsistent identifiers produces faster errors and a system that people route around. Integration comes before analytics that span systems, because a dashboard assembled from manual exports will be abandoned the first time somebody is too busy to produce the export.

And process definition comes before software selection, not after. Choosing a platform first and then discovering the process means the process gets reshaped by an implementation decision made before anyone understood it, which is how organisations end up with expensive software that nobody defends.

Baseline before change

Without measurement taken first, the second phase is an argument rather than a calculation.

Data before automation

Automating over inconsistent identifiers produces faster errors and quiet workarounds.

Integration before cross-system analytics

A dashboard fed by manual exports has a predictable lifespan.

Process before platform

Selecting software before understanding the process lets the vendor define your operating model.

The dependencies that are imaginary

Equally, several ordering rules are asserted routinely and are not true. "We need the new ERP in before we can improve anything" is the most expensive of them, because it converts every small improvement into a reason to wait, and the wait is usually years.

Similarly, "we cannot start until the data is clean" is a recipe for never starting, since data quality is not a state you reach but a discipline you maintain. The workable version is that the data supporting the specific process being automated has to be clean enough for that process, which is a bounded and achievable piece of work.

And "we need a strategy first" is frequently a delay dressed as diligence. A programme benefits enormously from knowing which two or three outcomes it exists to produce; it rarely benefits from a document that takes a quarter to produce and describes an operating model in the abstract.

Start where the evidence is cheapest

The first phase should be chosen for the quality and speed of the evidence it produces, not for its strategic weight. That usually means a process with a countable volume, a measurable handling time, a clear owner and a boundary that does not require three departments to agree.

This annoys people who want to start with the most important thing, and the reason to resist is practical rather than timid. An organisation with no track record of delivering this kind of change has no internal credibility to spend, and the first phase is where that credibility is either created or destroyed. Starting with the hardest, most political, most cross-functional problem is starting with the one most likely to produce an ambiguous result.

A first phase that finishes, demonstrably works, and produces a number that someone in finance accepts changes what is possible afterwards. It is worth choosing on that basis alone.

The baseline is the artefact that matters most

The single highest-return activity in the first weeks is capturing what things currently cost — volumes, handling times, error rates, cycle times, cost per transaction. It takes days and it is skipped constantly, because it produces nothing visible and everyone is impatient to start building.

Without it, every subsequent claim about the programme is unfalsifiable in both directions. Advocates cannot prove it worked; sceptics cannot be answered; and the finance function, reasonably, discounts the whole thing. Programmes die from this more often than from technical failure.

With it, phase two becomes arithmetic. "We measured this at four hours per week per person before, it is now twenty minutes, here is the same measurement applied to the next process" is a fundamentally different conversation from "the first phase went well and we would like more budget".

People are the constraint, and the plan should say so

The technical portion of a transformation is usually the predictable part. The unpredictable part is that the people whose processes are changing are also the people whose knowledge is required to change them, and they already have a full-time job.

A plan that assumes subject matter experts are available on demand is a plan that will slip, and it will slip in a way that gets blamed on the supplier or on the software. The honest version names who is needed, for roughly how many hours a week, and what they will stop doing to make that possible.

The second people-shaped risk is that improvement is threatening when it is not spoken about. If a process is being automated and nobody has said what happens to the person who currently runs it, they will reasonably assume the worst, and the cooperation the project needs will not be there. Saying it plainly at the start — including if the answer is uncomfortable — costs less than discovering it through resistance.

What "done" should mean at the end of each phase

A phase is finished when the new way of working is the only way of working, the old process has been switched off, someone internal owns the result, and the measurement has been retaken. Not when the software is delivered.

The distinction matters because parallel running is where value quietly disappears. A process that is automated but where the spreadsheet is still maintained "just in case" has added work rather than removed it, and the just-in-case version tends to become permanent. Switching the old path off is a decision that needs a date and an owner, and it belongs in the plan rather than in an implicit assumption.

Internal ownership is the other half. A phase that depends on the supplier to operate has not transferred anything, and the second phase then has to carry the operating cost of the first. Handover, documentation and a named owner are deliverables, not courtesies.

A shape that tends to hold

The sequence we would generally propose: measure the current state; fix the data supporting the first process only; automate or rebuild that one process end to end with the old path switched off; retake the measurement; then use that evidence to select the next.

Integration and analytics come once two or three processes are running properly, because a cross-system view is only worth building when the systems hold something worth viewing. Customer-facing work can run in parallel where it does not depend on the internal changes, and frequently should, because it produces visible progress while the internal work is still unglamorous.

Replacement of a core system, if it is genuinely needed, should come as late as the situation allows. It is the highest-risk item in the programme, it consumes the most attention, and doing it after several successful phases means the organisation attempts it with a track record, a baseline and an understanding of its own processes that it did not have at the start.

Where this sits in what we do

This article covers one decision inside a wider engagement. The solution page sets out how that engagement runs, what it includes and what it costs to find out.

• Complete Digital Transformation — The whole stack, sequenced — brand, web, marketing, CRM, automation, reporting and infrastructure — with benefits measured afterwards rather than projected and forgotten.
• AI for custom customer care: what it can answer and what it must not
• When to build software instead of buying it
• Why more traffic rarely fixes a pipeline problem
• Lead scoring that sales will actually use
• All insight articles