Why process must come before technology

---

A while back I sat in on a demo for a shiny new system. The vendor was good. The screens were clean, the reporting looked sharp, and by the end of the hour half the room was already imagining the launch. Somebody asked what the current process actually looked like. The real one, the one staff used on a busy Tuesday when the phones were ringing and someone was off sick. There was a pause. Nobody in the room could describe it. And nobody seemed to think that was a problem.

That struck me as exactly backwards.

We had a detailed picture of the tool and almost no picture of the work the tool was meant to improve. We knew what we were buying. We didn't know what we were fixing.

I've watched this pattern play out for thirty years now, in big national programmes and in single-site clinics, and it nearly always ends the same way. The system goes live. Adoption is patchy. Within a few weeks the workarounds are back; the side spreadsheet, the shared inbox, the one person who "just knows" how to make it behave. The improvements everyone was promised never quite arrive, and no one is entirely sure why.

Usually the reason is dull and uncomfortable: the process was never understood in the first place. The technology didn't create the mess. It just switched the lights on.

Technology amplifies what already exists

Here is the idea this whole thing turns on, and it isn't complicated.

A digital tool makes work move faster. It does not make work clearer. Those are two different things, and we constantly confuse them.

Think of it like a megaphone. Hand a megaphone to someone with something clear and useful to say, and more people hear something worth hearing. Hand the same megaphone to someone who is confused, contradicting themselves, and talking over the top of three other people — and now everyone gets the confusion, faster and louder, with a dashboard to prove it happened.

That's what a new system does to a shaky process. A digital referral pathway laid over a slow, unclear referral pathway doesn't produce a fast, clear one. It produces confusion at speed, delivered to more people, with much better reporting on exactly how badly it's going.

The tool inherits the process. If the process is good, the tool is a gift. If the process is a workaround held together by one person's memory, the tool faithfully scales the workaround - and the fragility with it.

None of this is an argument against technology. I’ve said it before: digital technology, on its own, has no value whatsoever. Its only job is to improve the outcome of whatever it's bolted onto. That's not scepticism about tools. It's a refusal to treat the tool as the point.

Why we buy the megaphone anyway

If this is so obvious, why do capable, careful leaders keep doing it?

Because tools are easy and processes are hard. A tool demos well. It has a name, a price, a vendor who will present to your board, and a tidy line in next year's budget. You can point at it. You can approve it.

A process has none of that. It lives in handoffs, in local habits, in the quiet things people do to keep the service running that never appear on any map. It doesn't demo. It doesn't sit neatly in a budget line. It only becomes visible when it breaks, and by then you've usually already bought the tool that was supposed to fix it.

So the bias isn't laziness. It's gravity. The easy thing to see, fund and approve is the thing that gets seen, funded and approved. And that quiet preference, repeated across enough decisions, is where a surprising amount of wasted money and lost clinician goodwill actually comes from.

A better first question

The instinct, when the pressure to modernise builds, is to ask: what should we buy?

It's the wrong question, or at least the wrong first one. The better question is less exciting and far more useful: how does the work actually happen right now, and is it ready for what we're about to introduce?

Not the policy version of the work. Not the process map drawn three years ago and never touched since. The real version — what happens when the phones are busy, the system is slow, two staff are away, and a patient needs an answer. That's the process your new tool is going to amplify, whether you've looked at it or not.

You don't need a consultant to take the first look. You need ninety minutes, your practice manager, one frontline person, and the honesty to trace a single patient journey end to end, describing what people actually do, not what they're supposed to do. You'll almost certainly find something that surprises you. That surprise is the whole point. That's the thing the demo was never going to tell you.

Where this leaves us

There's a discipline for looking at work this way. It comes from manufacturing, it's called lean thinking, and clinical teams are right to bristle at industrial language turning up in care: patients aren't cars, and a health service isn't a production line. Fair enough. But strip the jargon away and lean is just a stubborn habit of seeing the work clearly before you change it. Referrals, triage, enrolments, follow-up, recalls: these are processes, and they behave like processes, whatever we'd prefer to call them.

Do that seeing first, and technology becomes something you can aim at it. Skip it, and you've bought a megaphone and pointed it at a room where nobody agrees on what's being said.

So, before the next demo, before the next procurement paper, before the next confident promise about what the system will deliver, it's worth sitting with the plainer question. Not what tool solves this?

But do we actually understand the work we're about to make faster?

---

This is the argument at the heart of our guide, Before You Invest in Digital and AI - a practical read for health and community leaders on how to know whether your process is ready, before you spend a dollar on the tool. It includes the readiness self-diagnostic we use with clients, and the questions worth asking before you commit.