The Transformation Was Delivered.
So Where Did the Value Go?

The case begins with two numbers: 31% and 25%.

According to McKinsey’s 2022 global survey, organizations captured a median of just 31% of the full revenue benefits and 25% of the maximum cost benefits that their recent digital transformations could have achieved.

Think about that for a moment.

Companies invest millions in new platforms, automation, enterprise systems, data and technology. They assemble transformation teams, engage consultants, redesign processes, train employees and celebrate go-live milestones.

Yet, when the financial results are examined, much of the value originally anticipated has not materialized.

Where did it go?

Was the technology inadequate? Was the implementation flawed? Did employees refuse to adopt the new way of working?

Or is there something else happening—something that the project dashboard never revealed?

Let’s investigate.

Clue 1: The project was successful. The business case was not.

Let’s begin with the familiar transformation dashboard.

This is where the first contradiction appears.

The project team has delivered what it was asked to deliver. But has the business received what it was promised?

McKinsey and the University of Oxford examined more than 5,400 IT projects. For large projects with initial budgets exceeding US$15 million, the research reported average outcomes of:

• 45% over budget
• 7% over schedule
• 56% less value than predicted

These findings suggest that the problem is not simply whether projects are delivered. It is whether they deliver the economic value used to justify the investment.

The research reveals an even more revealing case.

Source: McKinsey and University of Oxford, Delivering Large-Scale IT Projects on Time, on Budget, and on Value (2012).

Clue 2: Nearly US$10 million—and then the project was stopped

A bank set out to establish a central data warehouse to address inconsistencies in its finance and risk information.

The objective was understandable: improve the quality and consistency of information used by the business.

But as the project progressed, the technical architecture became increasingly elaborate. Additional data and complexity were introduced, and the solution moved further away from the original business problem.

After 18 months and nearly US$10 million in investment, the bank stopped the project.

Consider what happened.

The organisation had invested significant money and time. The team had been working on a sophisticated technical solution. Yet the original business problem remained unresolved.

Were they solving the business problem—or had they become occupied with building the solution?

This is an important distinction in transformation.

A technically impressive platform, data warehouse or ERP implementation is not necessarily a successful business transformation.

The technology must solve the right problem, support the right process and produce an outcome that the organisation can measure.

Source: McKinsey and University of Oxford, 2012.

Clue 3: The system is live. But how is work actually getting done?

Now let’s move away from project reports and into the business.

Imagine a procurement department after an ERP implementation.

The system is live. Purchase orders are being processed. Employees have completed their training.

But when we examine the actual process, we find:

• Approvals still being chased through email.
• Employees maintaining spreadsheets to track outstanding work.
• Material information being corrected manually.
• Hard-copy approvals still influencing the process.
• Different teams following different routes to complete similar transactions.

Is this employee resistance?

Not necessarily.

A 2017 academic study examined procurement after ERP implementation at an agricultural chemicals company. The researchers identified process variations associated with technical issues, data migration, material numbering and categorisation, and dependencies on hard-copy approvals.

Some deviations helped activities move faster. Other issues created bottlenecks.

The finding is important: the process that actually operates after implementation may be quite different from the process the organisation intended to establish.

The technology may be available, but the operating conditions surrounding it still matter.

This is where the investigation changes direction.

What is preventing the intended process from becoming the natural way of working?

Source: ERP Post Implementation Review with Process Mining: A Case of Procurement Process, Procedia Computer Science (2017).

Clue 4: The workarounds are telling us something

A spreadsheet outside the system is not automatically evidence of failure.

An email approval is not automatically a sign of resistance.

A manual intervention may be necessary because the system does not support a legitimate business scenario.

But repeated workarounds can reveal something important about the transformation.

• Perhaps the process design was incomplete.
• Perhaps the technology does not accommodate the reality of the business.
• Perhaps decision rights and responsibilities were never clarified.
• Perhaps employees have been asked to follow a new process without removing the constraints that made the old process difficult.

Research into technology adoption and workarounds identifies a range of causes, including technical limitations, incomplete process design, lack of knowledge, inadequate support and the perception that a system makes work more difficult.

Research on process mining also shows how actual process execution can differ from the formal process design—and why human context is needed to interpret those differences.

This is why simply measuring logins, training attendance or system usage can be misleading.

Adoption is not just about whether people enter the system. It is about whether the organisation can operate effectively through the new way of working.

This is what I call the False Adoption Illusion™.

The transformation appears complete because the system is live, training is complete and project measures are green.

But the organisation may still be relying on manual work, duplicate activities and informal processes to get the job done.

The illusion is that implementation has been mistaken for adoption—and adoption has been mistaken for value.

Sources: Stagewise Overview of Issues Influencing Organizational Technology Adoption and Use; Using Process Mining for Workarounds Analysis in Context (2023).

Clue 5: Sometimes the biggest opportunity is removing work—not automating it

Let’s look at a banking example.

In a published customer case, UiPath describes process-mining work at İşbank.

The analysis identified approval steps that could be removed or simplified.

According to the case study, the initiative:

• Mined 26 processes.
• Reported 116,000 hours saved.
• Optimised 61% of cases through the elimination of unnecessary approval steps.
• Optimised 65% of cases to meet service-level targets.

These are outcomes reported in the vendor’s customer case.

The interesting part is not just the number of hours saved.

It is what the investigation uncovered: some of the work being performed was not adding sufficient value to justify its existence.

If an organisation automates every existing approval, handoff and validation step without questioning its purpose, it may simply automate unnecessary complexity.

Before automating a process, understand which activities create value, which provide necessary control, and which introduce avoidable complexity.

Source: UiPath, İşbank: Journey of Operational Excellence with Process Mining. Outcomes as reported in the published customer case.

Clue 6: The value opportunity is hiding in the end-to-end process

Consider order-to-cash.

An organisation may have implemented a new ERP, standardised its finance processes and automated parts of order processing and invoicing.

But cash collection still takes longer than expected.

Where is the delay? Is it in order entry? Credit checks? Delivery confirmation? Invoice creation? Disputes? Payment allocation?

Looking at individual system transactions may not reveal the complete picture.

In its published customer case, SAP Signavio describes how Rio Tinto analysed large volumes of procurement and order-to-cash data.

The case reports analysis involving more than:

• 800,000 purchase orders
• 6,300 sales orders
• 17,500 invoices

The analysis identified process variations and opportunities to improve operational performance.

It also described a potential on-time collection value of approximately US$50 million to US$90 million.

Important: this was a potential value opportunity described in the case, not a claim that the full amount had already been realised.

Identifying a financial opportunity is not the same as capturing it. The process must be improved, the change must be implemented, and the resulting business benefit must be measured.

The real opportunity may not be visible within a single system or department. It may be hidden in the end-to-end process.

Source: SAP Signavio, Rio Tinto customer success story. Financial opportunity as reported in the published case.

Clue 7: The customer is experiencing the consequences

There is one more place to look: the customer.

SAP’s published Runs SAP case describes a support environment involving fragmented portals, processes and tools.

Process mining and customer feedback were used to understand how customers moved through support processes and where they experienced unnecessary redirection between teams.

The organisation worked on improving the support experience, reducing redirection and improving resolution and self-service.

This illustrates an important point.

A transformation may appear successful within individual departments while the customer continues to experience a fragmented journey.

The finance team may have a new system. Customer service may have a new portal. Support teams may have new workflows.

But if the handoffs between these areas remain complicated, the customer still experiences the old problem.

Internal process complexity eventually becomes an external customer experience problem.

Source: SAP Signavio, SAP Runs SAP customer success story.

So what have we uncovered?

We started with two numbers: 31% and 25%.

We then found a bank that stopped a nearly US$10 million project, procurement processes still shaped by technical and manual dependencies, unnecessary approvals consuming operational capacity, and large-scale processes where substantial value opportunities could be identified only by examining actual execution.

The evidence points towards a common pattern.

The problem is not always the technology.

It is often the gap between what the organisation designed, what people actually do, and what the customer or business ultimately experiences.

This is the Process Truth Gap™—SCA’s framing of the difference between three views of a process:

When these three views do not align, transformation value can leak.

A process may be compliant with the system configuration but inefficient. It may be efficient for one department but create delays for another. It may meet internal targets while frustrating customers. And it may appear successful in a project dashboard while employees continue to rely on manual activities.

The objective is not to eliminate every variation. Some variations are necessary because of customer needs, regulatory requirements or legitimate business conditions.

The objective is to identify which variations are necessary, which are avoidable, and what business consequences they create.

The final test: Five questions every transformation leader should ask

Are employees completing the process in the intended system?

Look for spreadsheets, email approvals, offline reporting, duplicate data entry and manual reconciliation. Understand why they exist before deciding what to remove.

Where is the process losing time and value?

Examine waiting time, handoffs, repeated approvals, rework and exceptions. A process can be automated and still be unnecessarily complicated.

Are we measuring business outcomes or just implementation milestones?

If the business case promised faster order processing, lower costs, better service or improved working capital, measure those outcomes directly.

Are workarounds exposing a system problem or an operating-model problem?

A missing system capability may require technical remediation. Unclear responsibilities may require process redesign. An unnecessary approval may require a business decision.

Who owns value realisation after go-live?

Benefits need owners, baselines, targets, measurement periods and follow-through. Otherwise, the project may close while the business case remains unfinished.

Closing the case: The technology worked. But did the business transform?

The investigation began with an uncomfortable finding: organisations often capture only a fraction of the value they expect from digital transformation.

We have seen why.

The technology can be delivered while the original business problem remains unresolved.

The system can be live while employees continue to rely on workarounds.

Activities can be automated without questioning whether they add value.

Individual departments can improve while the end-to-end customer experience remains fragmented.

And opportunities can be identified without ever being converted into realised benefits.

The answer is not necessarily another technology investment.

It is a better understanding of the business itself: its processes, its people, its customers, its data and the way work actually gets done.

At Sujata Chakravarty Advisory, the transformation perspective is built around a simple principle:

When these elements are not aligned, implementation can succeed without transformation succeeding.

So, the next time a programme dashboard turns green, ask one more question:

Can we prove that the business value has been realised?

Because a transformation is not complete when the technology is delivered.

It is complete when the business can demonstrate the value created by the change.