We re-engineer the processes that run your business — then automate them on a no-code workflow engine you can actually audit.
Working with enterprise workflow platforms since Kintana, 2002.
You have read that 70% of digital transformations fail. It appears in board papers, vendor decks and the Harvard Business Review. It has no evidentiary basis whatsoever. Here is the paper trail — click each step and check it yourself.
"70% of digital transformations fail."
Four sources deep. Roughly four minutes to verify.
The origin. Hammer and Champy state that 50–70% of reengineering efforts fail to achieve their intended results — and describe this themselves as an unscientific estimate. By 1995 Hammer was publicly walking it back, writing that there is no inherent failure rate for reengineering.
An honest guess by two authors becomes, three decades later, a statistic.
Mark Hughes traced the five most-cited sources for the 70% figure — Hammer & Champy, Beer & Nohria, Bain, McKinsey and Kotter. Every one either asserts the number without evidence, or cites another source that asserts it without evidence.
His conclusion: there is no valid and reliable empirical evidence for the claim.
Steven ZoBell, then Chief Product and Technology Officer of a work-management software company, writes: "research tells us that 70% of these initiatives will not reach their stated goals. That equates to over $900 billion."
No citation is given for the 70%. The $900 billion is not a research finding either — it is 70% of $1.3 trillion, multiplied by the author. The Forbes Technology Council is a paid membership programme for contributors, not editorial journalism.
HBR states that "70% of all DT initiatives do not reach their goals." The sentence carries a hyperlink. Follow it, and it goes directly to the Forbes post in step 3.
An uncited assertion by a software vendor's executive now carries the authority of the Harvard Business Review — and from there into every consulting deck that cites HBR.
The real figures are less dramatic, which is precisely why they are worth trusting.
Now read the causes. McKinsey's four failure categories are unclear objectives, shifting requirements, unaligned teams, and reactive planning. Birmingham's statutory auditor named governance and programme management. Not one of them is "the software lacked the capability."
That is the whole argument for doing the process work first. It is also why we put people and process ahead of tools — and have since 2004.
Flyvbjerg & Budzier, Why Your IT Project May Be Riskier Than You Think, HBR Sept 2011
(preprint) ·
Bloch, Blumberg & Laartz, Delivering large-scale IT projects on time, on budget, and on value,
McKinsey on Business Technology No. 27, 2012 · Hughes, Journal of Change Management 11(4), 2011 ·
Eveleens & Verhoef, The Rise and Fall of the Chaos Report Figures, IEEE Software 27(1), 2010 ·
Grant Thornton, Birmingham City Council Value for Money Report — Oracle Implementation, Feb 2025.
Where we are uncertain, we say so. We have not found a
defensible published figure for what share of a transformation budget the software licence represents —
every version of that statistic traces back to marketing material. So we do not quote one.
Our founder wrote this down in 2004, after two decades leading IT teams inside large software companies: an efficient organisation depends on three things, and technology is the last of them. Twenty-two years later it is still how we work.
Automation fails when nobody owns the process. We start with the humans who do the work today — what they actually do, not what the manual says — and we train the people who will run it tomorrow.
Then we re-engineer. Most processes have accumulated steps nobody can justify. Automating those just makes the waste faster. We map it, cut it, and design the flow you should have had.
Only then does technology enter. For twenty years we implemented other people's platforms. Now we implement one built for exactly this — a no-code workflow engine with the audit trail regulated work demands.
Every pre-built application encodes somebody else's idea of how your work ought to happen. When it doesn't match, you have two options, and both cost money forever: change how your organisation operates to suit the software, or pay to customise the software — then pay again at every upgrade to keep those customisations alive.
A no-code workflow engine inverts the relationship. You describe the process you actually run — the steps, the roles, the approvals, the exceptions — and the engine executes it. There is no gap to close, because nothing was assumed about your business in advance. And no customisation debt, because configuring it is not customising it.
The part that matters most: it was built for business users, not developers. The person who knows why step four exists is the person who can change step four — without raising a ticket, without a release cycle, without waiting a quarter. That is the difference between a process you own and a process you rent.
In the interest of being straight with you: our workflow engine is at alpha. It runs, we build on it, and we will show it to you honestly — including what it does not do yet. The re-engineering work below stands entirely on its own and does not depend on it.
"It quickly became evident that Abraham's knowledge of the platform far out-shined HP's own technical consultants."
Steve Bagley — Director, Portfolio Management & Delivery Centre of Excellence, Scholastic Inc. · September 2013
"Abraham was the key enabler in our transformation from a manual driven process to a unified Portfolio Management system."
"Quiksilvr has taken a verbal, paper based at best process and made it efficient and manageable. We average 250+ active deliverables on a daily basis."
"After working together for almost 10 years in different organizations, I still strongly recommend him over any other candidates."
Enterprise portfolio and workflow platforms, delivered end to end — implementation, re-engineering, training and long-run support.
Maintained and supported the enterprise project portfolio management platform. Upgrade and performance re-architecture, custom financial and timesheet reporting, production administration.
Requirements, workflow design and technical specification for a portfolio management programme spanning technology proposals, capital governance and financial system integration.
Four continuous years of portfolio platform support across six modules — day-to-day user support, role-based training, enhancement design, and the business-unit rollout.
Our principal's practice also spans:
Seventy-one percent of organisations are using AI agents. Eleven percent have got one into production. The gap is not model quality — it is that long chains of autonomous steps degrade, and nobody can prove to an auditor what happened.
Read this honestly: it is arithmetic, not a measurement — the probability of n independent steps each succeeding at rate p. Real agent chains are worse than this, because errors correlate: corrupted context propagates forward. It is illustrative of the shape of the problem, not a benchmark of any system.
Camunda / Coleman Parkes, 2026 State of Agentic Orchestration (n=1,150 senior
decision-makers, fieldwork Sept–Oct 2025 — commissioned by Camunda, who sell orchestration) ·
Forrester, The State of Agentic AI, 2026 · Thinking Machines Lab,
Defeating Nondeterminism in LLM Inference, 2025 · COSO, Internal Control Over Generative AI,
Feb 2026 · Anthropic, Building Effective Agents.
The counter-argument we take seriously: agent capability
is improving fast — the length of task a model can complete unaided has been doubling roughly every
four months. Any claim that agents are permanently unreliable will age badly. Our position is
architectural, not a bet against the models: irreversible, regulated and auditable steps belong
under deterministic control regardless of how capable the model becomes.
Digital Business Process was founded in 2004, when Abraham Delgado left Mercury Interactive to work directly with the organisations trying to make enterprise workflow platforms actually fit how they operate.
He had been working with the technology since it was called Kintana, in 2002 — before Mercury acquired it, and long before HP acquired Mercury. What became clear across two decades of implementations was that the platform was never the hard part. The hard part was the process underneath, and the people who had to live with it.
That is why we now build on a no-code workflow engine of our own design, as implementation partner to NeosArk Technologies — the same work we have always done, on tooling shaped by twenty years of watching what these systems can and cannot do.
Bring us a process that frustrates your organisation and we will spend an hour on it with you — mapping what actually happens, where the waste sits, and what could be automated versus what should be eliminated first.
No slide deck, no pricing conversation, no obligation. If the answer is that you do not need software, we will tell you that — it is usually the most valuable hour we spend.