How workarounds become processes

Processes are rarely designed from scratch. They accumulate over time as understanding deepens and the business changes, and they end up looking very different from how they were first conceived.

Some of that happens for good reason. Often it's a workaround, or an extra step to catch an edge case. One system doesn't talk to another, so someone exports a spreadsheet. The 2021 data needs handling differently. A new accounting process spits out a different format. It all adds up, and the three step report now has fifteen steps and takes a day to produce.

Give it a few years and everyone calls that the process. It isn't really. It's a pile of workarounds that became permanent. So when a business looks at AI, usually to drive efficiency and free people up, the first instinct is to take that fifteen step process and automate it. And it works. Fifteen steps automated. Job done.

But I think that's a missed opportunity. Strip the thing back to its bare bones and ask what we're actually trying to achieve, and why we're doing it at all. With a modern approach you can often pull in data that didn't exist before, or that sat in systems which were never properly joined up, and end up with something far more useful than the original report. It might even act on what it finds instead of waiting for someone to read it on Monday morning.

What has actually changed

Software has always been good at following instructions. Give it structured information, a predictable set of rules and a defined outcome, and it can do the job consistently. The things that stayed manual were often the things that required someone to read something, understand it, interpret it, make a judgement or deal with information that didn't fit neatly into a predefined structure. Not because businesses didn't want to automate those things, there just wasn't a particularly sensible way to. That's one of the more important changes AI has brought about.

AI can work with information that isn't neatly structured. It can read documents, understand language, identify patterns, summarise information and make useful recommendations. Combined with the systems and data a business already has, that opens up possibilities that simply weren't practical before.

A report might have existed because someone needed to manually pull information from three different systems every Friday. If those systems can now be connected and the information interpreted automatically, perhaps the answer isn't a faster Friday report. Perhaps there shouldn't be a Friday report at all.

Efficiency is the first benefit. Capability is the bigger one

Most of the AI projects are about doing the same work faster. That's genuinely useful and it usually pays for itself. But it's the smaller half of what's on offer.

You can normally tell which one a business is going for from the question it asks:

  • Can AI answer these emails? Or: can AI show us what customers keep struggling with, across every interaction?

  • Can AI write our monthly report? Or: could we monitor performance live, with recommendations as things happen?

  • Can AI search our documents? Or: could anyone get the right answer, with the relevant context, at the moment they need it?

The first version saves time on work you already do. The second gives you something you've never had, which is a different order of value entirely.

A useful test

Before automating anything, these are the questions I'd want to work through:

  • Why does this step exist?

  • What constraint created it?

  • Does that constraint still exist?

  • If it doesn't, what would this look like designed today?

  • Does AI actually help us build that?

Often it does. Sometimes it doesn't, and I think that's just as useful an answer. Not every process needs AI. Some of them just need deleting.

Don't automate the past

There's a natural tendency in technology projects to look at what a business does today and try to make it better. That's understandable. It's concrete, measurable and relatively easy to explain. AI, however, gives us a reason to be a little more ambitious.

If the technology can now handle things that previously required manual interpretation, and if systems can share information that used to be trapped in separate places, then we don't necessarily have to preserve the processes those limitations created. We can rethink them.

That doesn't mean every business needs to throw everything away and start again. Most don't. There is plenty of value in improving what already works. But before spending time and money automating a fifteen-step process, it's worth understanding why there are fifteen steps in the first place.

The interesting question isn't how quickly we can automate the business we already have. It's what we'd build if we weren't constrained by the way we've always done things.

By Josh Gosselin, Founder, DEXM