[August 2026 edition]

The Art of Not Building, Part 1 — Distorted Requests and Trimming Work with ECRS

Published: Aug 11, 2026
Reading time: ~10 min

Japan’s Digital Agency publishes a briefing on its counter-service BPR advisory programme that states, under the heading “the precondition for counter-service digitalisation is business process reengineering (BPR),” that introducing tools without BPR achieves nothing. The process it lays out runs in three phases: groundwork, BPR starting from the analogue process, and only then BPR that makes use of systems. Deployment comes last.

Speeding up unnecessary work leaves it unnecessary. Digitise a convoluted procedure as it stands and you get a convoluted procedure that runs quickly. What has to happen first upstream is a reengineering of the work itself: survey it exhaustively, merge and shrink and simplify it, restructure it down to what genuinely warrants a system, and discard or revisit the rest. That is the art of not building.

Part 1 covers the distortions that arrive with the request, what happens when you digitise while leaving them in place, and the ECRS procedure for trimming work.

1. Three distortions in the request

A request to build a system is not neutral information. Three distortions are already present before requirements gathering begins.

#	Distortion	What happens	Consequence
1	The solution is fixed in advance	The request arrives as a means, not a problem	Nobody checks whether the means is sound
2	Requests preserve the status quo	Interviews surface demands premised on today’s process	Unnecessary work is ported to the new system
3	Purpose and means are conflated	A means such as “an approval feature” is treated as a requirement	Alternative ways to meet the purpose go unexamined

1.1 The solution is fixed in advance

Move the ledger we keep in Excel to a web system. Turn the applications we handle by email into a workflow. Put the paper checklist on tablets. Requests arrive in this shape. The conclusion — build a system — is already in place, and the developer who receives it starts organising requirements for screens, features, data, permissions, notifications, reports, and APIs. Whether that ledger, that application, that check is still needed at all has already dropped out of the conversation.

“Move Excel to the web” is not a problem; it is a solution somebody already selected. The UK government’s Service Manual says you must not start building a service during discovery, and asks teams to take any pre-supplied solution and reframe it as a problem to be solved before research begins. Its own example rewrites “we need an interactive map showing where our offices are” into “how might we make it easier for people to find their nearest office?” Deciding not to proceed to the next phase is not a failure either — the guidance notes that the time and money can go somewhere else.

1.2 Requests preserve the status quo

This distortion appears during interviews. Most of what a user department describes is a demand to keep the current process alive. Let me review it in a list. Let me export CSV. Let me configure three approval levels. Keep an operation history. Each looks reasonable if you accept today’s work as given, and nothing guarantees today’s work is reasonable.

Processes accrete over years in response to legal changes, incidents, audit findings, reorganisations, staff turnover, and customer requests. Each addition had a reason at the time, and that reason has not necessarily survived. The work persists anyway: I inherited it from my predecessor, there was trouble once, I think the auditors asked for it, another department receives it, the rules mention it, the system has a field for it.

1.3 Purpose and means are conflated

Take approval. Say the current means for “a manager approves the application” is that the applicant fills in a form, a notification reaches the manager, the manager checks and clicks approve, it moves to the next approver, and the result is stored. Before designing a workflow system, establish why that approval exists. There is rarely one purpose, and each purpose has its own alternatives.

Purpose of the approval	Alternative
Catching input errors	Input constraints, master data lookup
Preventing budget overruns	Automatic reconciliation against remaining budget
Keeping managers informed	Notification alone
Preventing fraud	Separation of duties, limits by amount or risk
Establishing accountability	An operation log instead
A legal or contractual requirement	Check the actual clause (covered in Part 2)

The same conversation can establish what approvers actually verify, and whether they are simply clicking through. “We need an approval feature” then becomes a definition: which risk, reduced to what degree, by whom, through what means. Sometimes the approval feature disappears as a result.

2. Five ways digitalisation leaves the work unchanged

Digitise while those distortions remain and only the means changes; the structure of the work stays put.

Work is made of a medium that records information, a place that holds it, a route that passes it between people, an actor that performs the steps, and an actor that makes the decisions. Digitalisation replaces one of those layers. Organised by layer, the patterns look like this.

#	Layer replaced	Typical initiative	What remains
1	Medium	Paper becomes PDF	Fields, attachments, seal-equivalent checks, transcription, storage, reconciliation
2	Storage	Excel becomes a web screen	The same fields entered by the same people at the same time, then exported to another spreadsheet
3	Route	Email becomes a workflow	Requests, chasing, approval, returns. Operating steps increase
4	Executing actor	Manual work becomes RPA	The structure that duplicates the same data across systems
5	Deciding actor	AI handles complex cases	Convoluted rules, scattered information, exceptions

Layers 1 to 3 swap the container for information and never touch the steps. Layers 4 and 5 swap who performs the steps, and the steps survive intact. In pattern 4, a robot transcribing between systems on a human’s behalf leaves the duplication in place; the waste becomes harder to see, so it takes longer to find. In pattern 5, connecting AI to a mess of convoluted rules, scattered information, and exceptions does not resolve the complexity — it adds a layer that processes it.

Initiatives often span layers. Moving a counter service online replaces both the medium and the route.

Whichever of the five you replace, the structure of the work remains: the number of fields, the depth of the approval chain, the count of exceptions. Changing that structure is the job of ECRS, in section 3.

Automating a process without restructuring it rarely delivers the reduction anyone expected. McKinsey identifies going straight to technical development — precisely because the value looks large — as an execution pitfall that derails automation programmes, and notes the result is automating processes that are inefficient or obsolete.

What the five patterns share is that technology does not necessarily remove the problem in the existing work. More often it speeds the problem up, spreads it wider, and makes it harder to spot.

3. Trimming work with ECRS

Industrial engineering has a set of four improvement principles known as ECRS. The glossary from the Japan Management Association Consultants explains that applying Eliminate, Combine, Rearrange, and Simplify in that order produces larger gains, avoids both excessive and insufficient improvement, and minimises unnecessary trouble.

The order matters because each stage shrinks the target for the next. Work you eliminate needs neither combining nor simplifying. Start from simplification and you will later eliminate procedures you just spent effort refining.

Stage	Principle	Main question	What remains afterwards
1	Eliminate	Can we stop doing this at all?	Work that cannot be stopped
2	Combine	Can scattered instances of the same processing be merged?	Consolidated procedures
3	Rearrange	Can the order, place, or owner change?	Relocated procedures
4	Simplify	Can branches, exceptions, and approval steps be reduced?	Candidates for a system

3.1 Eliminate

Elimination comes first. Check the following.

Who uses the output of this task
What happens if it is not produced
When it was last used in a decision
Whether law or contract genuinely requires it
Whether the value justifies the cost of collecting the information
Whether anyone would notice its absence

Count concretely: whether a human being reads the report you produce, where the data you key in is used, whether any field is never referenced at all.

Reports, status updates, ledgers, standing meetings, and approvals attract this scrutiny most. The producing side carries an unmistakable burden while the receiving side may not use the output. Submitting something monthly and it being used monthly are different facts.

Lean’s Value Stream Mapping charts the flow of material and information required to bring a product from order to delivery, laying out value-creating and non-value-creating activity together so that waste can be identified and removed. Its distinguishing feature is treating the entire flow to the point of delivered value as one object, rather than speeding up individual tasks.

3.2 Combine

Processing with the same purpose is often scattered across departments, products, regions, and channels. Separate application forms per department, the same customer details keyed in by several teams. Phone, counter, and web running distinct procedures; each person keeping a private tracking sheet; similar meetings reporting the same progress. Systematise this as it stands and you produce screens, permissions, data, and notifications for every fragment.

Examine five things: whether the point of entry can be made singular, whether decision criteria can be shared, whether the same information can be reused, whether department-specific exceptions can go, and whether it can become one procedure from the customer’s point of view. The answer is not necessarily one enormous integrated system. Point 2 of the GOV.UK Service Standard is “solve a whole problem for users” and point 3 is “provide a joined-up experience across all channels.”

Separation applies too. Count the ratio of routine cases to exceptions and you may find the exceptions are what force complexity onto everything. Split the exceptions into their own path and the routine flow stays simple. Confirm as well whether those exceptions still occur.

3.3 Rearrange

After combining and separating, consider changes of order, place, and owner. Put approval before the work starts rather than after it finishes. Complete in the originating department what used to pass through several. Move an inspection from a later stage to an earlier one.

Substitution belongs here as well: reusing information the organisation already holds instead of asking the customer to supply it, or moving from reviewing every case to rule-based automatic approval with review of exceptions only. The total volume of processing does not change — only where and by whom it happens.

3.4 Simplify

For the work that remains, cut frequency, scope, precision, and retention.

Axis	Before	After
Scope	Check every case	Check exceptions only
Frequency	Daily	Weekly
Fields	20 entries	5
Approval	All cases	High-risk cases only
Retention	Indefinite	Only as long as required
Collection	Detailed data	Only the indicators a decision needs

Decide how much precision is actually needed, when the data can be deleted, and what damage an error would cause, and the scope of collection narrows on its own.

Systematisation makes bulk processing easy, which invites the inversion of collecting data because you can process it. More stored data means more responsibility for entry, validation, access control, backup, migration, auditing, deletion, and breach prevention. Adding one input field is not adding one screen element; it is adding a commitment to manage that data as an organisation indefinitely.

Branches, exceptions, input fields, approval steps, handoffs, and statuses fall under the same treatment. Consolidate duplicated master data and write the decision criteria down.

What drives development cost up is not the screen count of the happy path but the combination of exceptions, branches, department-specific rules, transitional measures, manual corrections, and special permissions. The benefit of simplification goes beyond fewer screens. Reduce approvals from three stages to one and you no longer need route configuration, delegated approval, out-of-office handling, or return destinations; notifications, deadline escalation, permission changes, audit logs, test cases, and user documentation go with them. Removing one branch in the business process removes a great deal of functionality, data, testing, and operational load at once.

4. Comparing against non-system measures

For whatever survives ECRS, compare against non-system measures before systematising. Deciding not to build is not the same as leaving things alone.

What changes	How
Rules	Revise approval authority, retention periods, reporting frequency, scope
Responsibility boundaries	Complete in one department what passed through several
The service	Reuse information the organisation holds instead of asking the customer
Decision criteria	Move from reviewing everything to rule-based approval plus exception review
Contracts	Standardise formats and delivery methods that differ per supplier
Organisation	Retire relay departments and meetings that only forward information
Existing products	Settle it with configuration in forms, shared storage, calendars, or existing SaaS
Timing	For low-volume, high-change work, keep it manual and wait until it can be standardised

A system is one instrument of improvement among several, and an improvement does not have to arrive at software.

ECRS reduces the structure of the work, but applying it requires an accurate picture of the work in the first place. Part 2 covers the whole of a process that a per-person task list never reveals, how to verify the claim that the law requires something, and how to carry the results of this cleanup into a decision about what to systematise.