Your AI Strategy Is Digital Transformation With Better Branding

In the last three years, the volume of corporate communications announcing AI transformation strategies has reached a level that makes it difficult to identify a large organisation that is not, by its own account, in the process of transforming itself through AI. The language is consistent across industries, geographies, and organisational types: productivity, scale, efficiency, insight, augmentation. The strategies vary, but they share a framing. The company is changing. AI is the agent of change.

I want to make an argument that is uncomfortable for organisations that have invested significantly in AI strategies of the kind currently being announced. Most of what is being called AI transformation is not transformation. It is digital transformation — the process of making existing processes faster and cheaper through technology — with updated marketing language. And the reason this matters is that digital transformation, done without asking the process-elimination question, has a consistent track record of producing expensive infrastructure in the service of unchanged institutional structures.

Plot them on the same axes and the only difference left is the label.

1. The acceleration-versus-elimination claim, and what grounds it

What this paper argues from. A 1990 management-theory text, read directly, that made this paper's exact argument about automation versus redesign three and a half decades before the current AI wave, with two named companies' real before-and-after figures. The founders' own 2007 account of M-Pesa's design process. A 2025 applied-research report on generative-AI pilot outcomes, read directly and treated explicitly as preliminary and non-peer-reviewed. The documented 1990s history of what happened when "eliminate the process" rhetoric was applied badly at scale. And one worked comparison between two procurement-process designs, reasoned through rather than measured in a live deployment.

What this paper does not argue from. It does not argue from a controlled, matched comparison of organisations pursuing AI-as-acceleration versus AI-as-elimination strategies; no such study is cited because none was found. It does not argue from an audit of Flux's own customers' outcomes; this paper does not claim organisations that bought Flux's automation products outperformed comparable organisations that did not.

What this paper does not claim. It does not claim every AI copilot or productivity tool is worthless — §3 states plainly these are real, if narrower, gains. It does not claim process elimination is costless or guaranteed to succeed; §8 takes the 1990s reengineering failure rate and its human cost seriously as a direct precedent for what can go wrong with this paper's own prescription, not as ancient history safely left behind.

What would refute it. Given in full, in decreasing order of damage, in §9. The sharpest version: if organisations pursuing AI-as-acceleration strategies are found, at scale, to achieve outcomes — cost, speed, institutional capability — comparable to or exceeding those pursuing AI-as-elimination strategies, the distinction this paper is built on would not be doing the work this paper claims it does, and the right response would be to withdraw the argument, not merely soften its framing.

2. What Digital Transformation Actually Delivered

The digital transformation wave of the 2000s and 2010s produced genuine improvements. Processes that had been executed on paper became faster and more accurate when executed on software. Customer service that had required phone calls became accessible through web portals. Financial transactions that had required physical presence at a bank branch became executable from a phone.

These were real gains. But they were, in most cases, gains in the efficiency of existing processes rather than the elimination of processes. The bank that built mobile banking did not become a different kind of institution. It became a faster version of the same institution. The call centre that deployed IVR and self-service portals reduced call volume. It did not eliminate the problem that generated the calls.

This distinction is not new, and it is worth being precise about how old it actually is, because the current AI-strategy conversation mostly proceeds as if it were discovering it. In 1990, Michael Hammer argued in the Harvard Business Review that "speeding up those processes cannot address their fundamental performance deficiencies," because "heavy investments in information technology have delivered disappointing results — largely because companies tend to use technology to mechanize old ways of doing business."¹ He was not speaking abstractly. Ford Motor Company's accounts payable department, in the early 1980s, set out to cut its 500-person headcount by around 20% through process rationalisation and new computer systems — a conventional automation program. When Ford instead redesigned the underlying process itself (moving to "invoiceless processing," matching three data items between a purchase order and a receipt record instead of fourteen across three separate documents), it achieved a 75% headcount reduction — not the 20% the automation-only plan would have delivered.¹ Mutual Benefit Life Insurance Company faced a similar choice: its president demanded a 60% productivity improvement in processing insurance applications, which had taken 5 to 25 days through a 30-step process spanning five departments. Tinkering with the existing process could not plausibly reach that target. MBL instead replaced the handoff chain with a single "case manager" role holding full responsibility for an application start to finish, supported by expert systems and specialist consultation rather than a sequential approval chain. The result: turnaround of two to five days, average as little as four hours in straightforward cases, 100 field-office positions eliminated, and more than double the application volume handled with the new structure.¹ The gap between Ford's 20% and 75%, and between MBL's old 5-25 day range and its new 2-5 day range, is the gap this paper is about — delivered, in both cases, with 1980s technology, by asking a different question before deploying it.

The organisations that changed structurally were the ones that used technology not to accelerate their existing operations but to ask what their operations should be. M-Pesa is the most instructive example in the Kenyan context, and it is worth grounding in its own founders' account rather than its now-familiar legend. The project began as a UK Department for International Development challenge-fund pilot aimed specifically at helping microfinance customers repay loans more cheaply and securely — not at digitising an existing bank branch.² Nick Hughes, the Vodafone executive who led the deal, wrote plainly about why a telecom company rather than a bank built it: "telecom companies are young and fast moving; banks are old, traditional, conservative, and slow moving," and the actual constraint on reaching the unbanked was never a shortage of funds but "the ability to move money from the sender to the receiver."² M-Pesa did not build a faster version of the bank branch. It asked what a payment infrastructure should look like for a population that had never had a bank account, and designed an answer from that premise. A later peer-reviewed study found the resulting access to mobile-money agents lifted an estimated 194,000 Kenyan households — roughly 2% of the country — out of extreme poverty over the following years, concentrated among female-headed households.³ That is a measured outcome of the design choice Hughes and Lonie describe, not merely a founders' retrospective claim about their own intentions.

The distinction in both cases is not the sophistication of the technology. Ford and MBL used 1980s mainframes and expert systems; Safaricom used 2007-era feature phones and SMS menus. It is the willingness to ask the right question: not "how can we do what we do faster?" but "what should we be doing, and how should we build a system to do it?"

3. The Pattern in Current AI Deployment

The current AI deployment wave is replicating the digital transformation pattern in most organisations. The evidence is visible in the products being purchased, the use cases being announced, and the metrics being used to evaluate success — and, now, in applied research that has gone looking for this pattern specifically in AI deployments and found it.

The products being purchased are overwhelmingly interface improvements: AI tools that make knowledge workers faster at the tasks they were already doing. Copilot tools that autocomplete emails and documents. Search tools that surface relevant information faster. Summarisation tools that condense documents. Meeting transcription and action item generation. These are genuine productivity improvements. They are not process redesigns. The processes they operate on — writing emails, reviewing documents, searching for information — are unchanged. The human is still doing the work. The AI is making the human faster.

The use cases being announced are predominantly augmentation narratives: AI helping the human do the same job better. The contract reviewer who uses AI to flag relevant clauses faster. The compliance officer who uses AI to search regulatory databases more efficiently. The financial analyst who uses AI to generate first-draft models. These are real improvements in individual productivity. They are improvements in the efficiency of processes that should, in many cases, be examined more fundamentally.

The metrics being used to evaluate success are telling. The dominant metrics are tasks completed per hour (faster is better), error rates in existing processes (lower is better), employee satisfaction with tools (higher is better). These metrics measure the efficiency of existing processes. They do not measure whether the right processes are being done.

This is no longer only an inference from the kinds of products on the market. A 2025 applied-research report from MIT's Project NANDA — explicitly a preliminary, non-peer-reviewed study, based on a review of more than 300 disclosed AI deployments, structured interviews with 52 organisations, and survey responses from 153 senior leaders — reported that roughly 95% of generative-AI pilots in its sample showed no measurable business return, and named the mechanism directly: tools that function as "a productivity enhancer, not a workflow transformer," lacking the memory, feedback loops, and deep integration that separate the minority of successful deployments from the rest.⁴ I am treating that 95% figure as press-reported, order-of-magnitude evidence of a pattern, not as a precise, generalisable failure rate — it is one preliminary study's sample, not a census — but the mechanism it names, independently, is this paper's own distinction, restated for the current technology rather than inferred from the digital-transformation era by analogy.

4. The Question That Is Not Being Asked

The question that most AI strategies do not ask is: which of our processes should not exist?

This is not a radical question. Every organisation, on honest examination, runs processes that exist because they were designed for a world that has changed — for a compliance environment that was different, for a staffing model that no longer applies, for a technology constraint that no longer binds. The digital transformation wave created more of these processes, by digitising manual workflows without asking whether they should exist, and then building dependencies on them that made them harder to question.

An AI strategy built on this accumulated inheritance — one that asks "how can AI improve each of our processes?" rather than "which of our processes should AI eliminate?" — is not a transformation strategy. It is a maintenance strategy. It is the modernisation of an institutional structure that was never designed to be optimal and has never been interrogated at the level of design.

5. What the Gap Looks Like in Practice

Consider two organisations in the same industry, making different choices.

The first has deployed an AI copilot for its procurement team. With the copilot, team members process expense requests faster — they get AI-generated summaries of each request, flagged against relevant policy provisions, and can approve or reject with less manual review. Request processing time has fallen by thirty percent. The team is the same size. The process is the same process.

The second has redesigned its procurement process. Spending authority is encoded in a virtual card system. Employees spend within encoded limits without requiring approval. The procurement team's role has shifted: they manage vendor relationships, negotiate contracts, and oversee exceptions — the cases that fall outside the automated system's parameters. The routine approval workflow does not exist. The team is now doing work that genuinely requires human judgment.

Both organisations will report AI success metrics. The first will report faster processing times. The second will report process elimination. In five years, the first organisation will have a more efficient procurement team doing the same work. The second will have a fundamentally different cost structure and a procurement function that operates at a different level of complexity.

The difference between these two organisations is not the sophistication of the AI they deployed. It is the question they asked before they deployed it. This is, directly, Hammer's Ford-versus-conventional-automation gap from §2, restated for an AI copilot instead of a mainframe system.

6. The Honest Question

I am not arguing that AI-assisted improvements are worthless. They are not. I am arguing that they are not what most AI transformation strategies claim them to be, and that the gap between the claim and the reality matters because it determines the decisions organisations make about where to invest.

An organisation that believes it is transforming through AI copilots is unlikely to also invest in the process redesign work that genuine transformation requires. The belief that the transformation is already happening is the primary obstacle to the work that would make it happen.

The honest question for any organisation claiming an AI transformation strategy is this: for the processes you are most proud of having improved with AI, did the AI do the work, or did it help your people do the work faster? If the answer is the latter, you have a productivity improvement. That is worth having. It is not worth calling a transformation.

The essays that follow push this argument further. If human accountability is the stated reason for keeping humans in the process — and it often is — a companion essay examines whether that reason holds up under scrutiny.

7. Objections I take seriously

"Flux has a commercial interest in this conclusion." Flux builds and sells process-elimination automation — PBOMaster, ProcureBee, AnswerTab — and this essay's argument is a direct sales case for why organisations should buy process redesign rather than copilot tools layered on existing workflows. The honest mitigation is narrow: §§2-3's evidence (Hammer's 1990 case studies, Hughes and Lonie's own M-Pesa account, Suri and Jack's measured poverty results, the MIT NANDA report) all comes from sources independent of Flux and would be true whether or not Flux existed. Whether Flux's own products deliver the Ford-and-MBL-scale gains this paper describes is Flux's own claim, not independently audited here.

"This paper's own prescription has a documented history of going badly wrong." This is the objection I take most seriously, and I am not going to let the 1990 citation in §2 stand without its sequel. Business process reengineering, the movement Hammer's 1990 article launched, developed its own well-documented failure pattern within a few years: a series of early-1990s studies found that 70% or more of reengineering initiatives "made things worse" rather than better, and a 1994 industry survey found 73% of companies using reengineering to cut an average of 21% of jobs, with most of the largest corporate downsizings of the era occurring at companies actively pursuing reengineering programs.⁵ Thomas Davenport, one of the movement's own founders alongside Hammer, later wrote: "the last thing that I would have ever imagined was that people would start losing their jobs because of some ideas that I was offering."⁵ The exact rhetorical move this paper is making — stop merely accelerating the process, eliminate it — is the rhetorical move that, applied badly and used as cover for indiscriminate layoffs, became the reengineering movement's own undoing. I am naming this directly rather than treating 1990 as safely historical: a company selling process-elimination automation today is not exempt from the same risk, and §9's falsification conditions reflect that.

"Process elimination that removes a human task is not costless even when the business case is sound." Labour economics offers a more precise vocabulary for this than "job losses" alone. Acemoglu and Restrepo's displacement/reinstatement framework distinguishes automation that displaces a task previously done by labour from the separate question of whether new tasks emerge that create demand for labour elsewhere; they find recent decades of slower U.S. employment growth are explained by an accelerating displacement effect paired with a weakening reinstatement effect.⁶ This paper's procurement example in §5 treats "the team now does work that genuinely requires human judgment" as an unambiguous good. The honest version is narrower: whether that reallocation is net reinstatement (new, higher-value work genuinely created) or disguised net displacement (fewer people doing the same oversight work at lower cost) is an empirical question this paper has not measured for Flux's own customers, and should not be assumed in the automation's favour by default.

"The MIT NANDA figure is itself exactly the kind of secondhand, order-of-magnitude statistic this paper warns readers to be careful with elsewhere in the corpus." Fair, and stated plainly in §1 and §3: it is one preliminary, non-peer-reviewed study's sample, not a census, and its 95% figure is a self-assessed-ROI measure across the organisations it surveyed, not an audited outcome. What it adds to this paper is not statistical precision; it is an independent, contemporary restatement of the mechanism this paper argues for, which is a different and more modest contribution than a reliable population estimate would be.

8. Where the acceleration-versus-elimination claim stops

No controlled comparison of AI-as-acceleration versus AI-as-elimination strategies across organisations exists; this paper does not cite one because none was found.

It does not claim Flux's own products have been independently shown to deliver the magnitude of gains Hammer documented for Ford and MBL; §7's first objection states this directly.

It does not claim process elimination is risk-free; §7's second and third objections take the 1990s reengineering backlash and the displacement/reinstatement question seriously as live risks, not resolved history.

It does not claim the MIT NANDA report's 95% figure is a reliable, generalisable population estimate; §1, §3, and §7's fourth objection all state it is a preliminary sample, used for its mechanism rather than its precision.

And it does not claim every current AI deployment that looks like augmentation is secretly worthless; §6 states plainly that productivity improvements are real and worth having — only that they are not the same achievement as the transformation many strategies claim to be delivering.

9. What would falsify this

Stated as commitments, in decreasing order of how much damage each would do to this paper's claims.

Organisations pursuing AI-as-acceleration strategies are found, at scale, to achieve outcomes comparable to or exceeding those pursuing AI-as-elimination strategies. If this were established by a controlled or large-sample comparison, the distinction this paper is built on would not be doing the explanatory work claimed for it, and the right response would be withdrawal, not narrowing.

A large-sample study of current AI-driven process elimination finds a dominant pattern of disguised net job losses rather than the reinstatement this paper's procurement example assumes. This would not falsify §§2-6's historical and current-pattern evidence, but it would falsify this paper's implicit framing of process elimination as a straightforwardly positive outcome for the people whose roles change as a result.

Flux's own customers, independently audited, are shown to achieve gains no larger than the copilot-style improvements this paper characterises as the lesser achievement. This would not refute the general Ford/MBL/M-Pesa pattern, but it would falsify this paper's implicit claim that Flux's products specifically deliver the Hammer-style gap rather than sitting on the acceleration side of it.

The MIT NANDA report's finding fails to replicate in a larger, peer-reviewed, or independently repeated study. This would not falsify §2's historical argument, which does not depend on it, but it would remove this paper's only contemporary, AI-specific evidence for the pattern, leaving the AI-era claim resting on analogy to the digital-transformation era alone.

Appendix A — Evidence table

Appendix B — Citation register

CITATION-NEEDED — controlled acceleration-vs-elimination comparison. Appendix A row 8. No study directly comparing organisational outcomes between AI-as-acceleration and AI-as-elimination strategies was found; §9's first falsification condition names the study that would settle this paper's central claim.

CITATION-NEEDED — Flux's own customer outcomes, audited. Appendix A row 9. This paper does not cite, because Flux has not published, an independent audit of its customers' gains against the magnitude Hammer documented for Ford and MBL.

CITATION-NEEDED — displacement/reinstatement balance for Flux's own customers. Appendix A row 10. §7's third objection names this directly: whether process elimination at Flux's customers nets out as genuine reinstatement (higher-value work) or disguised displacement has not been measured.