Digitisation Is Not Automation: Why a Project Clears Acceptance and Delivers No Effect

There's a reliable tell for a project that will clear acceptance and deliver no effect. The results report doesn't mention a single rule that changed: it lists the modules deployed, the users trained, the data migrated, and the share of processes "covered by the system." Not one line about what's now done differently.

A project like this isn't deceiving anyone on purpose. It's reporting exactly what happened: the work moved from paper and spreadsheets into an interface. The trouble is that the move, on its own, changes neither the effort required nor the error rate — it only changes where they show up.

Four Signs Digitisation Is Passing Itself Off as Automation

All four signs are visible at the acceptance stage, and none of them require special expertise. It's enough to read the project report and put four questions to it — a finance director or an operations lead can do this in twenty minutes, without opening a single system screen.

The report is written entirely in nouns. Deployed, configured, trained, migrated. Automation, by contrast, gets described in verbs of disappearance: "the calculation is no longer done by hand," "approval is no longer required," "the field no longer needs to be filled in." If wording like that is missing from the report, the underlying work hasn't gone anywhere — it has only changed its address.

The number of process steps hasn't changed. There were nine steps before the project; there are still nine after it, just carried out inside the new system instead of on paper. This is the single most reliable sign, because real automation always cuts the number of steps — a step disappears when its output starts being computed by a rule rather than performed by a person.

New mandatory actions have appeared. Mark a status, tick a flag, duplicate an entry into an adjacent system. Every one of these actions is new work that didn't exist before the project, and in practice it usually lands on the very person whose workload the project was supposed to reduce — the case handler, the account manager, the clerk closing out the file.

The effect is measured by coverage. "Eighty percent of requests are now processed in the system" is a rollout metric, not a results metric. It climbs under every scenario, including the one where handling time for a single request has doubled and nobody noticed, because nobody was tracking handling time to begin with.

It's usually the last question that exposes the problem. There was no time measurement taken before the rollout, so there's nothing to answer with, and the conversation quietly retreats back to coverage numbers.

A Distinction Defined Thirty-Five Years Ago

The topic isn't new, and its sharpest formulation predates today's enterprise software by decades — long before anyone was pitching a platform, a portal, or an AI copilot.

The limitation is real, and I'll state it myself: this is a management article built on case studies, not a peer-reviewed study, and the figures were never independently audited. The value lies elsewhere — in the precision of the distinction it draws. The gap between a 20% reduction and a 75% reduction didn't come from a better computer system. It came from a decision to check three line items instead of fourteen. That's a process decision, and a company could have made it with a pencil and a policy memo, no software required.

What Healthcare Data Actually Shows

Healthcare is one of the rare fields where the shift to electronic systems has been measured not through surveys but through event logs and direct time-and-motion tracking, across large samples and over multiple years. The conclusions travel well to any industry where a written record is mandatory — insurance, banking, logistics, professional services.

One specialty, one academic health system, one software vendor — generalizing straight across to other industries calls for caution. But the method here is strong: not self-report, but event logs cross-checked against direct timing. This is precisely the kind of measurement that's missing from corporate implementation projects, where the effect is evaluated by coverage instead.

An even more convincing result comes from a study that directly compared the paper and electronic version of the same job.

Time allocation here was captured through participants' own reports rather than system logs — a real limitation — and the sample is confined to junior medical staff in one country. Even so, the direction of the finding runs directly opposite to what digitization is supposed to deliver: administrative time is higher for electronic-record users, not lower. The electronic form didn't remove a single requirement. It simply made meeting all of them more labor-intensive.

Why It Gets Worse Over Time, Not Better

The second counterintuitive fact: the workload inside a digital system running on unchanged rules keeps climbing over time, and it doesn't level off on its own.

The period partly overlaps with post-pandemic workload recovery, which could inflate the trend somewhat — that caveat has to be stated plainly. But the underlying mechanism is easy to follow and reproduces itself everywhere: in a system that never eliminates a requirement, every new requirement simply stacks on top of the ones already there. Rules accumulate for a mundane reason — adding a field to a form is cheaper, and far less politically fraught, than removing one.

How to Tell the Difference Before You Start

The second step needs someone with the authority to eliminate a step, and that's the real organizational obstacle, not a technical one. A vendor doesn't hold that authority. IT usually doesn't hold it either. Until the process owner has made the call to eliminate a step, any project defaults to a move by design — the same point I make in a companion piece on why you fix the process before you implement the system.

Four Questions for Every Implementation Report

Frequently Asked Questions