Digital Reengineering: A Practical Guide for Enterprise Leaders

Digital Reengineering is not another name for Digital Transformation. It is a distinct discipline built on a different first move.

Rather than starting with technology selection and asking the operating model to catch up, Digital Reengineering starts with the operating model — decision rights, incentives, ownership, workflows — and treats the technology as a consequence of that operating decision.

This guide is written for enterprise leaders — CEO, CIO, CTO, COO — who have watched technology-first programs stall repeatedly and want a different way to approach the problem. It explains what Digital Reengineering is, why the current moment makes it practical in a way it was not thirty years ago, what its underlying principles are, when to use it, how to start, and where it fits alongside the discipline of Digital Transformation.

If you are time-poor, skip to How to start.

What is Digital Reengineering?

Digital Reengineering is the discipline of redesigning an enterprise's operating model — decision rights, incentives, ownership, workflows, and the decision architecture that sits above them — before choosing the technology that will serve it.

It is a specific answer to a specific problem: the repeated failure of technology-first programs to deliver the business outcomes they were commissioned to produce.

Three things Digital Reengineering is not.

It is not software modernisation. Software modernisation replaces old technology with newer technology while leaving the operating model in place. Digital Reengineering starts with the operating model.

It is not the business process reengineering of the early 1990s. The intellectual lineage runs back to Michael Hammer and James Champy's Reengineering the Corporation, which laid out the case for radical redesign of business processes rather than automation of existing ones. What has changed since 1993 is that the toolset now available to reengineer with — cloud infrastructure, integrated data platforms, AI-assisted workflows, real-time analytics — produces operating models that were literally not possible thirty years ago.

It is not Digital Transformation as commonly practised. Many Digital Transformation programmes become technology-led in execution, with operating-model redesign following implementation rather than shaping it from the outset. Digital Reengineering deliberately reverses that sequence.

The distinction sounds subtle. In practice it is the difference between a program that changes what platforms an enterprise uses and a program that changes how the enterprise actually operates.

Why Digital Reengineering matters now

Two conditions define the current moment.

The first is the accumulated failure pattern of Digital Transformation programs run over the last two decades. The Harvard Business Review, in a 2019 article by Behnam Tabrizi and colleagues, reported that roughly seventy percent of digital transformation initiatives do not reach their intended goals. McKinsey's long-running research on organisational transformations arrives at a similar order of magnitude. Different framings, different measurement bars, but the direction is consistent: the majority of transformation programs do not deliver their stated business objectives. If the failure pattern were about technology choice, it would have converged over twenty years toward the platforms that worked. It has not. Different tools each cycle, and the same essential outcome each time — an argument developed in detail in Why Most Digital Transformations Fail at the Org Chart, Not the Tech Stack.

The second condition is capability. The modern enterprise toolset makes it possible to design operating models that could not exist in 1993 and to deploy them on a schedule enterprises can actually absorb.

Together these two conditions create the reengineering moment. The failure pattern demonstrates that the discipline is needed. The capability upgrade demonstrates that the discipline is now feasible.

Digital Reengineering is neither a new label for Digital Transformation nor a revival of 1993-era business process reengineering. It is the discipline that becomes possible when a proven failure pattern meets a modern toolset.

The Enterprise Shift

The 1993 reengineering literature captured a real insight — process redesign matters more than tool selection — but was constrained by the tools of its era. Enterprise architectures thirty years ago were monolithic, on-premises, batch-oriented, and slow to change. Rebuilding an operating model with those tools was a multi-year, capital-heavy commitment few enterprises could sustain to completion.

Six changes to the enterprise technology substrate have made Digital Reengineering practical today in a way it was not then.

• Cloud maturity. Compute and storage that would have required months of procurement and hardware deployment are now available on demand. Operating-model redesigns no longer need a matching capital plan.
• API ecosystems. Modern SaaS platforms expose the interfaces necessary to compose an operating model across best-of-breed components rather than force it into a single vendor's monolith.
• AI. Language models and machine learning have absorbed classes of work — drafting, routing, categorisation, summarisation, code generation — that previously required human throughput. Operating models designed with AI-capable workflows have qualitatively different structures than those designed without them.
• Modern data platforms. Real-time data integration and observability let an operating model be measured, iterated, and corrected while it is running. Reengineering programs no longer have to complete before their effects become visible.
• Workflow automation. Low-code and event-driven orchestration make operating-model prototypes deployable in weeks rather than quarters, so trade-offs can be tested empirically rather than argued in slideware.
• Dramatically faster implementation cycles. Modern delivery practices allow redesigned operating models to be implemented and iterated far more rapidly than was practical a generation ago.

Digital Reengineering is not a rebranding of an older discipline. It is what becomes possible when that older insight meets a substrate that can actually carry it.

Digital Reengineering vs Digital Transformation

The two disciplines are not competing labels. They differ on sequencing, primary artefact, success measure, failure mode, and timeline shape.

Starting point. Digital Transformation typically starts with technology selection — which cloud, which platform, which vendor. Digital Reengineering starts with the operating model — decision rights, incentives, ownership, workflows.

Primary artefact. Digital Transformation's primary deliverable is the deployment of a chosen platform, integrated to the existing environment. Digital Reengineering's primary deliverable is a redesigned operating model, expressed clearly enough that any subsequent technology decision is a consequence of it.

Success measure. Digital Transformation is often measured by adoption and integration completeness — the tool is deployed, the users are trained, the integrations are stable. Digital Reengineering is measured by operating-model outcomes at the P&L level — the enterprise runs differently, and the difference is visible in the business's actual results.

Failure mode. Digital Transformation programs commonly succeed technically and stall at the operating-model layer: the tool is present, but the underlying way of working has not changed. Digital Reengineering programs are more likely to stall earlier — during the operating-model design phase, which is politically expensive — but when they do land, the technology-layer decisions that follow are already serving a model the business is committed to.

Timeline shape. Digital Transformation typically has a compressed front-end and a long back-end. Digital Reengineering inverts that shape: a longer front-end on operating-model design and a much shorter back-end on the technology rollout, because the technology decisions are then serving a model that already knows what it needs to do.

The point of the distinction is not to argue that one discipline is universally right. Digital Transformation as a term will continue to capture the search demand and the vendor-facing language of the enterprise technology market. Digital Reengineering is the discipline that becomes necessary when the technology-first sequence has repeatedly failed to produce the business outcome. Michael E. Porter's distinction between operational effectiveness and strategic positioning is a useful analogue: both matter, but they are not interchangeable, and enterprises that confuse them tend to over-invest in the easier one.

The five Principles

Jettifi operates as a Digital Reengineering firm on the basis of five principles. They are not universal laws — they are the concise articulation of how we think about the discipline. Each is nameable in a phrase, defensible in a paragraph, and usable as a shared reference across engagements, articles, and the way an enterprise talks about its own operating-model decisions. Where a specific engagement decision does not obviously match one of the five, that is a signal to slow down and re-examine the operating question.

Principle 1 — Operating Models Before Platforms

Decide how the enterprise should work before choosing the technology that will serve it. The reverse sequence — buy platform, run change program, hope the operating model catches up — is the single most reliable failure mode in enterprise transformation.

Salespeople log into the new CRM to update fields the old process required. Analysts use the new data platform to build reports the old cadence needed. Customer service uses the new AI capability to draft responses that a supervisor edits back into the old tone. The technology is present. The operating model is unchanged. The detailed argument for why this pattern is structural, not incidental, is developed in Why Most Digital Transformations Fail at the Org Chart, Not the Tech Stack.

Principle 2 — Protect Differentiating Logic

Business logic that constitutes competitive differentiation should live in your operating model — and, where appropriate, in your own code — not in a vendor product available to your competitors on the same terms.

Protection does not mean preservation of every implementation. The implementation can and often should evolve, sometimes radically. What matters is that the underlying differentiating capability continues to live inside the enterprise and continues to serve as a source of position. When differentiating logic drifts into a vendor's product, that source erodes silently, and the enterprise finds itself competing on terms its competitors can also buy. The differentiation-vs-operational-effectiveness distinction Michael Porter articulated in "What Is Strategy?" is directly load-bearing here.

Principle 3 — Design for Reversibility

In unpredictable-half-life environments — AI-adjacent, regulation-in-flux, competitive-dynamics-in-flux — reversible decisions dominate irreversible ones. The current era qualifies. Assume the half-life of any current assumption is shorter than the enterprise wants it to be, and bias every operating-model choice toward configurations that can be revisited without a new transformation program.

Reversibility is not the same as reversibility-of-technology. A reversible technology decision inside an irreversible operating-model decision is often the worst configuration — the flexibility is at the wrong layer. The reengineering discipline puts reversibility into the operating model, not just the tooling.

Principle 4 — Technology Should Follow Process

Rebuild the process first, then choose the technology to serve it. This is the central inheritance from Hammer and Champy: the failure mode of prior generations was automating existing broken processes; the reengineering answer was to redesign the process before layering technology on top.

The modern toolset changes what a redesigned process can achieve, but the sequencing principle is unchanged. A technology-first decision produces processes warped to fit the tool. A process-first decision produces tools chosen to serve the operating model the business is committed to. The reverse sequence occasionally produces something workable. It rarely produces something durable.

Principle 5 — Reengineer Before You Replace

The reengineer column of the four-option enterprise-technology decision framework is often the highest-value option — and the option that receives least attention.

Rebuild-from-scratch is exciting and sponsors well. Bolt-on is easy to procure and closes the vendor conversation quickly. Walk-away is politically difficult and rarely gets a fair hearing. Reengineering — knowing the current system honestly, preserving what still earns its keep, rewriting what has gone stale, retiring what no longer serves — is the harder discipline and, in our observation, the one that most reliably compounds. The Reengineering Playbook develops the full four-option decision framework.

The four strategic choices

Any enterprise system decision reduces to one of four choices. The distinction between them determines the ceiling of what the subsequent program can achieve.

Build. Commit engineering capacity to constructing a system from first principles, owning the codebase, the operating model, the roadmap, and the long-term maintenance. Sensible when the system encodes competitive differentiation and the vendor market for it does not exist on defensible terms.

Bolt on. License a commercial product, configure it to context, integrate it with the existing environment. Sensible when the capability is undifferentiated and the five-year total cost of ownership is provably lower than building.

Reengineer. Take the current system — a mix of custom code, vendor products, legacy databases, and manual processes — and redesign the operating model it serves, then refactor the technology to serve the redesigned model. Sensible when the current system contains real business logic worth preserving and the operational context has drifted from the assumptions the system was built on.

Walk away. Retire the system, absorb the loss, change the business's expectation. Sensible when the system was solving a problem the business no longer has, or when the cost of any of the first three options is provably higher than the continuing value.

Real decisions rarely have a single dominant signal. The choice depends on five signals — where the business logic lives, the system's relationship to differentiation, the organisational memory sunk into current workflows, the realistic cost of switching, and the half-life of the surrounding market. The full decision framework — five signals for choosing among the four options — is developed in The Reengineering Playbook.

When organisations should reengineer

Reengineering is not the answer for every enterprise situation. Two lists.

Signals that reengineering is the right response:

• The current system contains real business logic worth preserving — logic that, if lost, would materially change how the enterprise operates.
• The operational context has drifted significantly from the assumptions the system was originally built on.
• The cost of ripping everything out is measurably higher than the cost of surgery.
• Previous transformation programs have technically succeeded (deployed platforms, integrated systems, trained users) but have not delivered the business outcome that was commissioned.
• AI is being layered onto an operating model that was not designed for it, and the productivity return is not materialising.
• The enterprise is running a heavily-customised, half-broken deployment that outlived the conditions that made the original vendor decision correct.

Signals that reengineering is not the right response:

• The system is genuinely commodity — payroll, expense management, video conferencing — and a modern vendor will match or exceed it. Bolt on.
• The system was solving a problem the business no longer has, or a problem the market has moved past. Walk away.
• The system encodes deep differentiation but is too corrupted to salvage, and rebuilding is defensible on both capability and time-horizon grounds. Build.

Realistic estimation of the switching cost — including data migration, integration rework, retraining, temporary productivity loss, and the risk-adjusted cost of things breaking during the change window — is often where the analysis goes wrong. The Reengineering Playbook's Signal 4 develops the discipline of who inside the enterprise should be trusted to produce that estimate.

Why Reengineering Programmes Fail

Reengineering programs fail in identifiable ways. Recognising the pattern early is the difference between a program that lands and one that repeats the transformation cycle.

Politics overrides analysis. The system's original sponsor is still senior. The vendor has an existing commercial relationship the CFO does not want to disturb. The IT leader has staked reputation on the previous build. The framework does not remove any of these forces. It only makes their operation visible. A leader who insists on running the analysis before the political conversation still has to have the political conversation — but has a coherent case to bring to it.

Sunk cost drives the wrong option. Enterprises that have spent significant money on the current system tend to resist any option that implies the money was wasted. Reengineering is often chosen for this reason when bolt-on or walk-away would be correct. Or build is chosen when reengineer would be correct, on the argument that "if we're going to invest anyway, we might as well go all-in". Neither is a framework decision.

Operating-model change treated as downstream. The program has a technology sponsor and a technology scorecard. The operating-model implications are treated as change-management side-effects. When the technology deploys and the operating model does not change to receive it, the program is still called a success because the technology criteria were met. The commissioned business outcome is quietly dropped from the reporting.

Technology-first reflex reasserts itself mid-program. The program starts with the operating-model discipline and then, at the first political friction, quietly reverts to platform selection as the safer conversation. The reversion is often invisible to the program itself. Six months later it is the same transformation program with a different name.

The role of AI

AI does not replace the reengineering discipline. AI is a tool that becomes dramatically more useful in a reengineered operating model than in an unchanged one.

The common failure mode is familiar. An enterprise deploys an AI capability — a copilot, an assistant, a workflow tool — into a business process that was designed years earlier for a different constraint set. The AI technically works. The users are trained. The integrations are stable. Six months later, the promised productivity has not materialised. The AI is either used sparingly for tasks the old process did not really need, or its outputs are edited back into the shape the old process expected.

The reengineering answer is the same sequencing claim the discipline rests on. Redesign the operating model around AI-capable workflows first. Establish where AI is doing load-bearing work, where it is augmenting human judgement, and where it should not be used at all. Then deploy the AI capability into that redesigned model.

Two of the five Principles are especially relevant to AI decisions specifically. Design for Reversibility applies because the AI capability landscape is changing on quarterly time-scales; irreversible operating-model commitments to a particular AI vendor or model are almost always mistakes. Protect Differentiating Logic applies because differentiating capability that gets absorbed into a general-purpose AI vendor's product becomes available to competitors on the same commercial terms.

The full argument on why AI adoption is fundamentally an operating-model problem, not a budget problem, is developed in AI Readiness Is a Culture Problem, Not a Budget Problem.

How to start

Digital Reengineering is not a single deliverable. It is a working sequence. Jettifi organises engagements around three phases and seven working steps.

Diagnose → Understand → Reengineer → Select Technology → Implement → Measure → Evolve

Diagnose. Establish the operating-model baseline honestly. Map decision rights, incentives, ownership, workflows, and the shadow curriculum operators have accumulated. Identify where business logic that matters actually lives.

Understand. Separate the operating-model constraints that are structural from those that are political, and the technology constraints that are real from those that are legacy assumption. Most transformation programs skip this step and pay for it later.

Reengineer. Redesign the operating model for the outcomes the business is trying to deliver. Not the outcomes the current operating model happens to produce. Not the outcomes the previous transformation program was commissioned for.

Select Technology. Only now does the technology conversation begin. Because the operating model is already committed, the technology decisions are constrained productively rather than politically. The build-vs-bolt-on-vs-reengineer-vs-walk-away decision framework becomes usable at this point.

Implement. Deploy the technology into the reengineered operating model. Because the model already knows what it needs to do, the implementation is measurably faster than a comparable Digital Transformation program.

Measure. Instrument the operating model, not just the technology deployment. The reengineering claim rests on P&L-visible outcomes; the measurement should too.

Evolve. Build the reversibility Principle 3 requires into the operating model itself. The environment will shift again. A reengineered operating model that cannot evolve becomes the next generation's legacy system.

The three phases — Diagnose, Reengineer, Evolve — are the shorthand. The seven working steps are the practical shape of an engagement. Learn more about how Jettifi approaches this.

Further reading

Three companion pieces develop specific parts of the argument in more depth.

• Why Most Digital Transformations Fail at the Org Chart, Not the Tech Stack — the detailed case for why Digital Transformation programs fail at the organisational layer rather than the technology layer. Read this to understand the failure pattern that makes the reengineering discipline necessary in the first place.
• The Reengineering Playbook — the full four-option decision framework and the five signals for choosing among Build, Bolt On, Reengineer, and Walk Away. Read this when the guide's When organisations should reengineer section leaves you wanting the working framework.
• AI Readiness Is a Culture Problem, Not a Budget Problem — how the reengineering discipline applies specifically to AI adoption. Read this if AI is where the current program's return on investment is not materialising.

In summary

Digital Reengineering is not intended to replace every existing management discipline. It is a way of sequencing enterprise change so that technology serves an operating model the business has deliberately designed, rather than asking the operating model to adapt after the fact. Organisations will continue to modernise systems, adopt new platforms, and invest in AI. The question this guide asks is simpler: are those investments reinforcing a consciously engineered operating model, or compensating for the absence of one?

Sources

• Michael Hammer & James Champy — Reengineering the Corporation: A Manifesto for Business Revolution, HarperBusiness, 1993. Anchors the intellectual lineage of the discipline (Section 2) and the sequencing claim behind Principle 4.
• Michael E. Porter — "What Is Strategy?", Harvard Business Review, November–December 1996. Anchors the operational-effectiveness-vs-strategic-positioning distinction that underlies the DR-vs-DT section and Principle 2.
• Behnam Tabrizi, Ed Lam, Kirk Girard, and Vernon Irvin — Digital Transformation Is Not About Technology, Harvard Business Review, March 2019. Anchors the transformation failure-pattern claim in Why Digital Reengineering matters now.
• McKinsey & Company — Losing from day one: Why even successful transformations fall short, December 2021. Anchors the transformation shortfall data in Why Digital Reengineering matters now.