Workflow Redesign: The Step Everyone Skips
Organisations reporting the strongest bottom-line impact from AI were 2.8 times more likely to have redesigned their workflows than those reporting weaker impact. Almost every transformation budget still goes to the tool rather than to this step.
This is a companion piece to our guide on digital transformation. Here we focus narrowly on the single finding that best explains why some technology investments pay off and others don't.
The finding
McKinsey's State of AI research found that among organisations reporting the strongest bottom-line impact from AI, 55% had redesigned their workflows to take advantage of the new capability. Among organisations reporting weaker impact, only 20% had done so — a gap of roughly 2.8 times. (McKinsey)
This is a specific, checkable finding, in contrast to the frequently repeated but untraceable claim that "70% of digital transformations fail" — a statistic we address directly in our main digital transformation guide. The workflow-redesign finding tells you something the vaguer folklore never does: what the successful minority actually did differently.
Why redesign is the differentiator, mechanically
A new tool dropped into an unchanged process automates the existing steps faster. It does not remove steps that only existed because of the old process's limitations, it does not change who makes which decision, and it does not eliminate handoffs that were only necessary because the old system required them.
Redesign means asking, before implementation: given this new capability, what should the process actually look like, starting from a blank page rather than from the current process with a tool inserted? That is a fundamentally different exercise from "how do we fit this tool into how we currently work," and it is the exercise most transformation projects skip.
Why it gets skipped
It is genuinely harder than buying and configuring software. Redesigning a workflow requires deep understanding of why the current process exists in its current form — including the informal workarounds and edge cases that never made it into any documentation — and organisational authority to change roles and decision rights, which is a different skill set than technical implementation.
It threatens people's roles more directly than a new interface does. A new tool feels like an upgrade. A redesigned process that eliminates a role, merges two teams' responsibilities, or changes who approves what, feels like a threat — and threatened people resist, sometimes actively, sometimes just by quietly not adopting the new way of working.
It is the first thing cut when budget or timeline is tight. Redesign work does not produce a visible deliverable the way a new system does. It is comparatively easy to defer, describe as "phase two," and then never actually schedule once the technology is live and the project is declared complete.
What redesign actually involves
Map the current process as it actually happens, not as it is documented. The gap between the documented process and the real one, including the workarounds, is usually where the redesign opportunity lives.
Identify which steps exist only because of a limitation the new technology removes. A manual approval step that exists because the old system could not automatically verify something is a candidate for elimination once the new system can verify it directly — but only if someone deliberately asks the question rather than preserving the step out of habit.
Redesign roles and decision rights explicitly, not implicitly. If the new process changes who decides what, name that change directly rather than letting it emerge ambiguously and get contested after launch.
Pilot the redesigned process, not just the tool. Testing whether the software works is a different question from testing whether the redesigned process, with the software embedded in it, actually produces better outcomes. Our piece on AI pilots that survive contact with production covers this distinction in more depth.
What we do
We scope workflow redesign as an explicit, resourced phase of any transformation project, separate from and alongside the technical implementation, because the McKinsey data is specific about what differentiates the outcomes and it is not the technology alone. If you are planning a project and want the redesign work built into the plan rather than assumed to happen informally, that is a conversation we are glad to have.
Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions.