Everyone has AI, few have redesigned the work

What is business process transformation?

Business process transformation is the structured redesign of how work flows through an organization: the sequence of steps, who owns them, where decisions get made, and what the process is measured on. It differs from process improvement in scope. Improvement makes an existing path faster or cheaper. Transformation changes the path itself, and usually deletes steps that only exist because an older system demanded them.

That distinction sets the size of the return. Teams that automate an existing workflow capture task-level savings. Teams that redesign the workflow first, then automate what survives, capture structural savings. Most organizations are still doing the first thing and reporting the results of the first thing.

The gap shows up plainly in current data. Almost every large company now uses AI somewhere. Very few can point to a profit line that moved because of it. The cause is rarely the model, the vendor or the budget. It is that the process the technology landed on was never redesigned.

How do digitization, digitalization and transformation differ?

These three terms describe three depths of change. Using them loosely is how programmes get scoped wrongly and funded for the wrong outcome.

Digital transformation is the enterprise programme these sit inside, moving strategy, operating model, technology estate and skills together. A quick test: if the handoffs, the approval rights and the definition of done are unchanged after go-live, you digitalized a process. You did not transform it.

How is AI changing business process transformation?

AI has moved the constraint from capability to design. Adoption is close to universal: 88% of organizations now use AI in at least one business function, up from 78% a year earlier.¹ Financial impact is not. Only about 6% report significant enterprise-wide EBIT impact from AI.¹ The distance between those two figures is the subject of this article.

The variable that separates the two groups is workflow design. Only 21% of companies have redesigned workflows end to end around AI, and doing so is one of the clearest markers of high performers.¹ The scarce input was never the tooling. It was the willingness to change the sequence of work and the approval rights attached to it.

Agentic AI raises the stakes again. 23% of organizations are scaling an agentic AI system and a further 39% are experimenting with agents.¹ That shifts the design question from automating a task to delegating a decision, which is a governance problem before it is a technical one. Someone has to define what an agent may approve alone, what it must escalate, and who answers for it when it is wrong. Most process management programmes have not written those rules, which is why agent pilots stay stuck in sandboxes. It is the first question worth settling in any AI transformation programme.

The macro estimate behind the enthusiasm is real but easy to misread. Generative AI could create $2.6 trillion to $4.4 trillion in annual economic value across 63 use cases.² That is a ceiling for an entire economy, not a forecast for any single company, and it is reachable only by organizations that change how work is sequenced rather than bolting a model onto an unchanged process.

What do process automation examples look like in practice?

The examples that pay are unglamorous and high volume. Finance and accounts payable are the standard proof-of-value pilot because the work is rule-based, repeated thousands of times a month, and already measured, so the before and after comparison is not a debate.

Structured automation is becoming the default rather than an initiative. Gartner projects structured automation reaching 70% of organizations by 2025, up from 20% in 2021.³ The tooling has spread past specialist teams as well: 89% of developers used low-code, no-code or digital process automation tools in the past 12 months.⁴ The digital process automation market is projected to grow from $13 billion to $23.9 billion between 2024 and 2029, an 11.6% compound annual growth rate.⁵ Availability is no longer the differentiator. Sequencing is, and it is the same lesson that shows up in business automation across a SaaS estate.

What is the ROI of business process automation?

Returns are strong where the process was selected well and absent where it was not. A Forrester Total Economic Impact study found a 248% three-year ROI for a composite enterprise deploying workflow automation.⁶ Buyer expectations are compressed to match: 78% expect ROI from process automation software within six months of implementation.⁷

Cost reduction scales with maturity rather than spend. Basic automation, meaning rules-based execution of the steps that already exist, cuts operational costs by 20% to 30%. Intelligent automation, which pairs redesign with AI-driven decisioning, reaches 50% to 70%.⁸

The distance between those two bands is the redesign, not the licence fee. Basic automation removes keystrokes. Intelligent automation removes steps, queues and handoffs, which is why its ceiling is so much higher. Budgets that fund tools without funding the redesign land in the lower band and stay there.

Why do digital business process programmes stall?

Because a large minority get nothing back. One 2025 industry survey reports that 31% of organizations saw no cost change at all despite investing in AI and automation, with poor process selection and legacy integration gaps given as the reasons.⁸ Both are decisions made before any software was configured.

Automating a broken process does not fix the process. It makes the mess move faster, and it makes the mess harder to see.

Three failure patterns account for most of it. The first is process selection by seniority: the loudest executive nominates a workflow, not the one with the largest measured queue. The second is integration debt, where a legacy core cannot expose the data an automated step needs, so humans are quietly reinserted to bridge the gap and the savings evaporate. The third is change management, where the redesigned process is delivered but the incentives, targets and job descriptions around it are not, so people keep running the old path in parallel.

None of these are tooling failures. All three are diagnosable before a build starts, which is the entire argument for spending the first weeks on evidence rather than on vendor selection.

Which business processes should you transform first?

Sequence beats ambition. A defensible order of work looks like this.

1. Mine before you map. Process mining reads event logs from the systems that already run the work and shows where cases actually wait, loop and get reworked. It replaces workshop opinion with evidence, and it usually contradicts the workshop. Run it first, on real logs, before anyone draws a target-state diagram.
2. Pick rule-based, high-volume, already-measured work. Accounts payable, invoice matching, onboarding and standard service requests qualify. The point of a first process is not the saving. It is producing an undisputed number that funds the next three.
3. Redesign, then automate. Delete the steps that exist only because a previous system required them. Collapse approval layers that no policy actually mandates. Automate what remains. Doing this in the other order is what produces the lower cost band.
4. Write the delegation rules before the first agent ships. Define the decisions an agent may take alone, the value or risk thresholds that force escalation, the audit trail it must leave, and the named owner accountable for its outputs.
5. Fix the integration path early. If a legacy core cannot supply clean data at the moment a step needs it, that is the project, and pretending otherwise is how humans get reinserted into an automated flow. Integration readiness, not model choice, is where AI consulting effort pays back first.

Customer-facing processes usually come later, once the internal ones have proved the operating discipline. When they do, the same rules apply to the interface layer, a point covered in more depth in digital transformation through applications.

How do you measure a business process transformation?

Baseline first, and baseline from system logs rather than from estimates. The metrics that survive scrutiny are cycle time from request to completion, straight-through processing rate, cost per transaction, exception rate, rework rate, and for anything agentic, the share of decisions delegated at an accepted accuracy level. Each of those is a number the finance function can audit.

Two guardrails matter. Measure the whole process, not the automated step, or you will report a faster task inside a slower end-to-end journey. And keep the exception rate visible next to the savings, because automation that pushes volume into a manual exception queue looks efficient in the dashboard and is not.

On timing, the useful frame is one process per quarter rather than one enterprise programme per year. That matches how buyers already think, given the 78% who expect returns within six months of implementation.⁷ Enterprise-wide impact takes considerably longer, but it is built out of proved single processes, not announced in advance of them.

Written by the group's editorial team with the practice leads who run these builds. Reviewed before publish. Spotted an error? Tell us and we will fix it.