Before You Automate, Question the Process

Something I keep coming back to in discussions about AI: we look at existing processes and ask which parts we can automate. But how often do we question the process itself?

A process was designed to address a need, within certain constraints. Some of those constraints are human: how much information we can process, how quickly we can work, what we can remember. Others come from the systems, information and organizational structures available at the time.

With AI, those constraints change. So why would we assume the process should remain? I think the starting point needs to be the need it addresses. Is that need still relevant? What would a process addressing it look like if we designed it today, with AI available?

This also matters for the people who remain involved. Take a hypothetical process handling 100 cases a day, of which 20% require human intervention. That is 20 cases. Increase capacity to 1,000 cases through AI, and even if you reduce the intervention rate to 5%, you now have 50 cases requiring attention. You have improved the process by several measures, while more than doubling the workload for the people handling the exceptions. And that calculation assumes the effort per case stays the same.

What if you have also reduced the team because of the work automated? What if the remaining work consists mainly of complex cases, without the routine work through which people previously built their understanding and experience?

Calling this “human in the loop” does not resolve it. People still need the capacity, context, competence and authority to intervene. Otherwise, human oversight risks becoming a formal responsibility that cannot be exercised properly.

There is nothing entirely new about this. Michael Hammer questioned the automation of existing processes in “Reengineering Work: Don’t Automate, Obliterate” already in 1990. Lisanne Bainbridge described in “Ironies of Automation” in 1983 how people could be left with an “arbitrary collection of tasks”. AI gives these questions a different scale and urgency.

For me, this is where architecture, governance and organizational design come together. Changing what a system can do has consequences for how work flows, where decisions are made, who carries responsibility, and what people’s jobs become. We need to assess those consequences across the whole process. Time saved in one activity tells us very little about the outcome if we have moved the work, complexity or risk somewhere else.

When you discuss AI initiatives in your organization, how much room is there to question the process itself?

Related reading: Delegation in the Age of Agentic AI on who may decide and who may act, Why Enterprises Need an AI Capability Map, and AI Strategy Is Not Missing. It Is Expiring..