If you digitise a broken process, you don't get a digital transformation. You get a broken process with a login screen. The single most reliable way to scale organisational chaos is to take your dysfunctional analogue workflows and automate them before anyone has asked whether they should exist at all. I've watched organisations spend seven-figure budgets doing exactly this, and the results are almost always the same: faster failure, delivered at greater expense, with a dashboard.
This article is for the people who've been handed a digital transformation mandate and are quietly wondering whether the emperor is wearing any clothes. Spoiler: often, he isn't. But there is a sensible path through — it just doesn't start where most organisations think it does.
What Does "Digitising Analogue Workflows" Actually Mean?
Digitising analogue workflows means converting processes that currently run on paper, spreadsheets, phone calls, or institutional memory into digital systems — software platforms, automated pipelines, digital forms, or integrated data flows. In principle, this reduces manual effort, improves accuracy, and creates an auditable record.
In practice, it often means taking the process nobody has reviewed since 2009, the one that requires three people to initial a form in a specific order for reasons nobody can remember, and building it faithfully into a new £400,000 platform. The inefficiency is now immutable. Congratulations.
The distinction between digitisation (converting analogue to digital) and digitalisation (using digital technology to change how work gets done) matters enormously here. Most organisations say they're doing the latter when they're actually doing the former. According to McKinsey's 2023 digital transformation research, fewer than 30% of digital transformations achieve their stated goals — and process fidelity to broken originals is one of the most cited reasons why.
Why Do Organisations Keep Scaling Chaos Instead of Fixing It?
Is the problem the technology, or is it the process underneath?
Almost always, it's the process. Technology is a very efficient amplifier — it amplifies what's already there, good or bad. If your analogue workflow involves duplicate data entry, unclear ownership, and approval gates that exist because someone once made a mistake in 2014, the digital version will have all of those things, plus the ability to do them simultaneously across twelve departments.
I worked with a public sector organisation that had a paper-based referral process taking an average of 11 days. They digitised it. It now takes 11 days. The forms are prettier, and you can track exactly where in the 11-day journey your referral is sitting, which is a bit like getting real-time updates on a delayed train. Technically impressive. Fundamentally unchanged.
Why don't organisations redesign the process before digitising it?
Because it's uncomfortable, slow, and politically difficult. Redesigning a process means asking why things are done the way they are, which means asking who decided that, which means having conversations about power, accountability, and institutional inertia that most leadership teams would rather avoid.
It's far easier to buy a platform. The vendor has a roadmap, a case study from a vaguely similar organisation, and a very confident sales team. Process redesign has none of those things. It has workshops, post-it notes, and the phrase "it's complicated" said by someone who has been in the organisation for 23 years.
According to Gartner's research on digital transformation failure modes, 70% of digital initiatives fail to meet their objectives, with organisational resistance and poor process design cited as the top contributing factors — not technology limitations.
What's the Actual Cost of Digitising a Broken Workflow?
How does technical debt compound when you build on a broken foundation?
Technical debt is the accumulated cost of taking shortcuts in technology decisions — the equivalent of paying minimum balance on a credit card and wondering why the balance keeps growing. When you digitise a broken process, you bake the brokenness into the architecture.
Every workaround, every exception, every "we'll fix that later" becomes a configuration, a custom field, or a manual override in the new system. Later, when someone finally redesigns the process properly, they find the system won't support it without significant rework. The platform that was supposed to enable change has become the thing preventing it.
What does this cost in real terms?
The numbers are genuinely eye-watering. A 2022 report by the Standish Group found that 31.1% of IT projects are cancelled before completion, and of those that finish, 52.7% cost nearly double their original estimates. A significant proportion of that overrun is attributable to undiscovered process complexity — i.e., the chaos that was already there, now expressed in JIRA tickets.
Beyond budget, there's the human cost. Staff who were already frustrated with a broken process are now frustrated with a broken digital process, plus the overhead of having been trained on it, plus the expectation that they should be grateful because the organisation has "invested in their tools".
How Do You Actually Fix This? A Practical Framework
Step 1: Map the process as it actually exists, not as it should exist
This is more radical than it sounds. Most process documentation describes the intended workflow. The actual workflow — the one that involves Sarah forwarding the email to Dave because the system doesn't have the right permissions, and Dave printing it out to sign it because he doesn't trust the e-signature — lives in people's heads and inboxes.
Techniques like process mining (using software to analyse event logs from existing systems to reconstruct actual process flows) and value stream mapping (a lean methodology for visualising the steps and delays in a process) are useful here. So is simply sitting with the people who do the work and watching them do it without interrupting.
Step 2: Identify what's genuinely broken versus what just looks odd
Not every workaround is a problem. Some of them are elegant solutions to real constraints that the official process hasn't caught up with. The goal isn't to eliminate all deviation from the documented process — it's to distinguish between necessary complexity (the real world is complicated) and accumulated dysfunction (nobody ever questioned this).
A useful question: "If we were designing this from scratch today, would we include this step?" If the answer is no, and the reason it exists is historical rather than functional, that's a candidate for removal before digitisation.
Step 3: Redesign before you digitise
This is the step most organisations skip because it doesn't feel like progress. There's no new software to demo, no implementation partner to invoice, no announcement to make. It's just people in a room arguing about whether the three-step approval process could be one step, and whether the weekly report that goes to the Director is actually read by the Director.
The organisations that do this well typically use a minimum viable process approach — designing the simplest version of the workflow that meets the genuine business need, then testing it before building a digital system around it. It borrows from agile product development and applies it to process design.
Step 4: Choose technology that fits the redesigned process, not the other way around
This sounds obvious. It is not common. The typical sequence in most organisations is: select a platform based on a market overview and a vendor shortlist, then map the business processes into the platform's capabilities, then wonder why the system doesn't quite fit the way people work.
The correct sequence is: understand the process you need to support, define the functional requirements that flow from it, then evaluate platforms against those requirements. The technology should be the last decision, not the first.
Step 5: Implement with the people, not at them
Change management is not a communications plan. It's not a training session two weeks before go-live. It's the ongoing, iterative work of involving the people who do the work in the design of the system they'll use to do it. According to Prosci's 2023 benchmarking report, projects with excellent change management are six times more likely to meet their objectives than those with poor change management.
I've seen this principle violated so many times it has become almost ceremonial. The system gets built. The training gets delivered. The go-live happens. The staff go back to their spreadsheets. The implementation partner has left the building.
Analogue vs. Digital Workflows: What's Actually Different?
| Dimension | Analogue Workflow | Poorly Digitised Workflow | Well-Designed Digital Workflow |
|---|---|---|---|
| Speed | Slow, constrained by physical handoffs | Fast, but errors and rework still occur | Fast, with built-in validation reducing rework |
| Visibility | Low — status lives in someone's in-tray | Medium — you can see where it's stuck | High — real-time, actionable data |
| Scalability | Requires more people to handle more volume | Scales volume, also scales dysfunction | Scales volume without proportional cost increase |
| Flexibility | Informal workarounds are easy to adopt | Workarounds become shadow processes outside the system | Designed to accommodate legitimate variation |
| Audit trail | Patchy — paper records, if they exist | Exists, but records broken steps accurately | Comprehensive and meaningful |
| User experience | Familiar, even if slow | Unfamiliar and still slow | Intuitive and meaningfully faster |
| Cost of failure | Low unit cost, high aggregate cost | High implementation cost plus ongoing dysfunction | High upfront, lower long-term cost of ownership |
What Role Does AI Play in All of This?
Can AI fix a broken workflow?
No. But it can break it faster and more expensively than any technology that came before it. Artificial intelligence — particularly generative AI and machine learning-based automation — is extraordinarily good at optimising for the patterns it's trained on. If those patterns encode a broken process, the AI will encode the brokenness with remarkable efficiency.
There is, however, a legitimate and genuinely useful role for AI in workflow improvement when applied in the right order. AI-powered process mining tools can identify bottlenecks, exceptions, and deviations at a scale and speed that human analysis cannot match. Used before redesign, not instead of it, this is genuinely valuable.
What about large language models and workflow automation?
Large language models (LLMs) — the technology behind tools like ChatGPT and Microsoft Copilot — can assist with document processing, drafting, summarisation, and decision support within workflows. The organisations getting real value from these tools are those who have already done the process redesign work. The ones who haven't are discovering that an AI that helps you fill in a form more quickly doesn't help if the form shouldn't exist.
According to MIT Sloan Management Review's 2024 AI and business transformation research, the highest-performing AI adopters shared one characteristic: they redesigned work around AI capabilities rather than bolting AI onto existing work. The sequence matters.
What Does Good Look Like? Signs You're Doing This Right
- The people who do the work were involved in designing the system — not just consulted after the decisions were made.
- You can articulate what problem the digitisation solves in a single sentence that doesn't contain the words "efficiency", "synergy", or "transformation".
- The process was simplified before it was digitised — the new digital version has fewer steps than the old analogue one, not more.
- There are clear metrics that will tell you whether it's working, agreed before go-live, not invented after.
- The workarounds people are using six months in are being captured and fed back into the next iteration, not ignored.
- The technology vendor does not have a seat at the table when you're deciding whether the process is fit for purpose. That's your call.
The Public Sector and Charity Angle: Less Budget, Higher Stakes
A significant portion of my work has been in public sector and third sector organisations, where the pressure to digitise is real, the budgets are constrained, and the consequences of getting it wrong are felt by the people the organisation exists to serve — not just by a P&L.
The dynamics are slightly different here. Analogue workflows in these settings often exist because of regulatory requirements, legacy IT infrastructure that predates most of the staff, or the sheer complexity of serving populations with highly variable needs. The temptation to buy a platform and call it transformation is just as strong — arguably stronger, because there's political pressure to be seen to be modernising.
The principle is the same, though. A digital system that faithfully replicates a process that doesn't serve people well just serves them badly at greater speed. The question "does this process actually work for the people it's meant to serve?" is not a technical question. It has to be asked and answered before the technology conversation starts.
Frequently Asked Questions
What's the difference between digitisation and digital transformation?
Digitisation is converting analogue information or processes into a digital format — scanning paper forms, moving from a filing cabinet to a shared drive. Digital transformation is the broader change in how an organisation operates, delivers value, and makes decisions, enabled by digital technology. Digitisation is often a component of digital transformation, but it is not transformation by itself. Scanning your paper forms is not a transformation. It's scanning.
How do you know if a workflow is broken before you digitise it?
Look for: excessive handoffs between people or teams; steps that exist "just in case" or "because we've always done it"; data being re-entered more than once; decisions being made without access to the information needed to make them well; and staff who have developed parallel informal processes to get around the official one. Any of these is a signal to stop and redesign before you build.
How long should process redesign take before digitisation begins?
It depends on the complexity of the process, but a reasonable rule of thumb for a single end-to-end workflow is four to eight weeks of structured discovery and redesign work before technology selection begins. Organisations that skip this or compress it to two days of workshops almost always pay for it later in scope creep, rework, and low adoption.
What's the biggest mistake organisations make when digitising workflows?
Selecting the technology platform before understanding the process. It happens constantly, usually because procurement timelines, budget cycles, or executive enthusiasm for a particular vendor create pressure to make the technology decision first. The process then gets reverse-engineered to fit the platform, which is a bit like buying a car and then deciding where you want to go.
Is it ever right to digitise a process without redesigning it first?
Yes, occasionally. If a process is genuinely well-designed, delivers good outcomes, and the only problem is that it's slow because it's analogue, then digitising it as-is is reasonable. These cases are rarer than most organisations assume. The honest test is: can you articulate why each step exists in functional terms? If the answer to any step is "I'm not sure" or "historical reasons", that's your cue.
How do you get leadership buy-in for process redesign before digitisation?
Frame it as risk management, not delay. The cost of redesigning a process before digitisation is a fraction of the cost of redesigning it after you've built a platform around the broken version. Show examples — there are plenty — of organisations that skipped this step and paid for it. Then propose a time-boxed discovery phase with a clear deliverable, rather than an open-ended review. Leaders are much more comfortable with "four weeks, then we'll have a recommendation" than "we need to think about this properly".
What tools are useful for mapping analogue workflows before digitisation?
Value stream mapping (from lean methodology) is useful for identifying waste and delay. Process mining tools such as Celonis or UiPath Process Mining can extract actual process flows from existing system logs if digital traces exist. For genuinely analogue processes, structured observation and swim lane diagrams — which map who does what across different teams — are practical starting points. The tool matters less than the discipline of mapping what actually happens, not what the documentation says happens.
Nicholas Hodder is a digital transformation and technology leader with over 20 years of experience working across public sector, charity, and commercial organisations. He is also a professional speaker and stand-up comedian — which, he will tell you, is excellent preparation for delivering bad news to executive teams. You can find him at nickhodder.com.