Why Technology Spend Does Not Automatically Create Business Value

Technology investment is easy to count. Business value is harder. Licence cost, implementation spend and go-live dates are visible; fewer organisations can trace those investments to shorter cycle times, fewer errors, lower operating effort, better customer outcomes or stronger management visibility.

PwC's 2026 Digital Trends in Operations survey makes the gap unusually clear: 89% of operations leaders said technology investments had not fully delivered expected results. Integration complexity, data issues and user adoption were among the leading reasons. The survey covered 767 operations and supply chain leaders at US companies, and the same group was notably confident in other respects — 85% said they were ahead of most competitors in digital transformation. Confidence in transformation and confidence in results are evidently not the same thing.

The pattern is not confined to operations. PwC's 2026 Global CEO Survey reported that 56% of CEOs said they had seen no significant financial benefit from AI to date, and only 12% said AI had delivered both cost and revenue benefits.

A system going live is an implementation event. Value appears only when the operating system of the business improves.

Why the value disappears

The common failure is to treat technology as the intervention rather than one component of it. A CRM cannot create disciplined handoffs if nobody has defined ownership. A dashboard cannot create trusted reporting if source data is inconsistent. Automation cannot remove waste if the underlying process is poorly designed. AI cannot reliably execute work if the systems it depends on are fragmented.

This creates a familiar pattern: the new platform arrives, old workarounds remain, staff add spreadsheets around the new platform, manual reconciliation continues and management concludes that adoption is the problem. Sometimes it is. Often the implementation simply reproduced the old operating model in newer software.

The mechanisms that leak value

Value usually leaks through a small number of identifiable routes:

Parallel running that never ends: the old spreadsheet, report or system is kept “just in case” and remains the place people trust, so the cost of both persists.
Integration gaps: the new system is not connected to the systems either side of it, so people re-key data at the boundary. PwC's respondents ranked integration complexity first among reasons for under-delivery.
Data that arrives unfit: poor data quality means outputs are checked by hand before anyone acts on them, quietly cancelling the time saved.
Configuration to match old habits: the platform is customised to mirror an existing process, including its unnecessary steps.
Nobody owns it after go-live: the project team disbands, small problems accumulate and users drift back to workarounds.

An illustrative example

This is a hypothetical scenario, not a client case. A business replaces a spreadsheet-based quoting process with a configure-price-quote tool. The tool works, and quotes look more professional. But approved quotes still have to be re-entered into the finance system because the two were never connected, pricing exceptions are still agreed by email, and sales managers still keep a spreadsheet to forecast because the tool's stages do not match how deals actually progress. The organisation now pays for the tool and the workarounds. The investment did not fail technically; the value mechanism was never designed.

Start with the value mechanism

Before approving a technology project, define the operational change that is supposed to create value. Is the investment expected to remove repeated data entry? Reduce customer onboarding time? Improve conversion visibility? Eliminate a reconciliation step? Reduce dependency on one employee? Make exceptions visible sooner?

If the answer is only “modernise the system” or “use AI”, the value mechanism is not yet defined.

A useful discipline is to write the mechanism as a single chain: this change removes this activity or prevents this failure, which affects this measure, which is owned by this person. If any link in the chain cannot be named, the business case is relying on hope.

Measure the process around the tool

Software utilisation is not the same as business performance. A better measurement set follows the work: cycle time, rework, error rate, handoff delay, exception volume, manual touches, time-to-resolution, data completeness and the cost of maintaining workarounds.

This also changes ROI discussions. The relevant comparison is not merely licence A versus licence B. It is the cost and performance of the operating process before and after the intervention, including integration, maintenance, training and ongoing ownership. That requires a baseline captured before the change, which many projects skip because it feels like delay. Without it, value can neither be proven nor disproven. Our guide to calculating the real cost of a repetitive task is one practical way to build that baseline.

Technology value is architectural

PwC also reports that poor data quality continues to impair digital value: 87% of its operations respondents said poor data quality had hampered their progress in achieving value from digital initiatives, and only about half said their companies establish a clean, structured data foundation before scaling. That matters because applications do not operate in isolation. Their value depends on surrounding systems, data, interfaces, workflow rules and people. A technically capable product inserted into a weak architecture can create another silo — a pattern explored further in piling on more software is not digital maturity.

The practical implication is to assess investments at system level: what does this replace, what does it connect to, which data does it own, which process does it change, who operates it, what happens when it fails, and how will the business know whether it is working?

Warning signs of a technology-value problem

Business cases describe features and licence savings but not process changes.
Success is reported as “went live on time” with no later review of outcomes.
Spreadsheets and manual reconciliation grow up around a recently implemented platform.
Several tools in the estate overlap, and nobody can say which one is authoritative.
The same problem appears in successive investment requests under different names.

A practical diagnostic

List the last few significant technology investments and the problem each was meant to solve.
For each, identify the process measure that should have moved and check whether it did.
Find the workarounds that still surround each system and estimate the effort they consume.
Check which systems each investment connects to, and where data is still re-keyed.
Confirm who owns each system's performance today, not just its licence.

Trade-offs

Insisting on a defined value mechanism slows approval, and not every investment can be measured precisely; some are foundational and pay back through later projects. That is acceptable if it is said explicitly. The risk is not that some investments are foundational, but that every investment is described that way so none is ever held to an outcome.

What better looks like

High-value technology programmes begin with a business outcome, redesign the necessary workflow, define data and ownership, choose technology that fits that design, integrate it into the operating environment and measure the resulting performance. They also keep improving after go-live.

Sometimes that leads to buying new software. Sometimes the higher-return decision is to configure an existing platform properly, connect two systems, remove a redundant tool or redesign a workflow without buying anything. Deciding which software to remove can be as valuable as deciding what to buy.

When to act

If technology spend is rising while manual work, reconciliation, reporting disputes and operational delays remain unchanged, the organisation does not primarily have a procurement problem. It has a technology-value problem. That deserves diagnosis before the next purchase.

A Digital Systems Audit can identify where current technology is creating value, friction or duplication. Digital Systems Architecture & Roadmap connects future investment to an explicit operating model.

Why technology spend does not automatically create business value.