Two for One: Every New Tool Inherits the Old Bottleneck

Every year brings a new system. A workflow tool to replace the shared mailbox, a ticketing platform to replace the workflow tool, a platform to consolidate the platforms. Budgets are approved, migrations are managed, training is delivered — and eighteen months later the same complaints come back in slightly different words. The software changed. The bottleneck did not.

Why More Software Rarely Means Fewer Problems

The logic behind a tool purchase is almost always sound in isolation. A team is drowning in manual work, the current system is genuinely bad, and a better one exists. What makes the outcome disappointing is not the tool — most modern software does what it claims. It is that a tool changes where work happens, and only rarely changes how work flows.

Consider what a typical implementation actually does. It maps the existing steps into new screens, migrates the existing fields, replicates the existing approval chain because that is what the business signed off on, and adds reporting on top. If the process contained a three-day wait for a second signature, the new system contains a three-day wait for a second signature — now with a nicer notification. If work moved between four departments with an unclear definition of "complete", it still does, and the handoff is now an API call that fails silently instead of an email someone could chase.

The uncomfortable pattern is that organisations buy tools precisely when they cannot describe their process well enough to fix it. The purchase feels like progress because it is concrete, funded, and scheduled, while process work is abstract, political, and never quite urgent. So the tool becomes the plan. And because the tool inherits the undescribed process, it inherits the bottleneck along with it.

This is not an argument against buying software. It is an argument about sequence — and there are two levers that change the outcome without changing the budget.

When Tool Rollouts Become the Actual Process

There is a stage past which the implementations themselves become the organisation's dominant workflow. You can recognise it easily. The roadmap is a list of systems rather than outcomes. Teams describe their year by the migrations they survived. A recurring meeting exists to coordinate integrations between tools that were each bought to simplify things. New hires are onboarded into four systems for one end-to-end process, and the informal knowledge that matters most is which system is authoritative for what.

In that state, effort flows steadily into the layer above the work rather than into the work. Every new tool needs interfaces, permissions, data cleanup, reference tables, admin ownership, and a small internal community of people who know its quirks. None of that moves a single case through the process faster. It is the cost of having tools, not the benefit of using them.

The tell-tale sign is that the number of tools grows while the number of measured process improvements stays flat. Ask a team how many systems touch their core process and they can name them instantly. Ask what the end-to-end cycle time was two years ago and what it is now, and the answer is usually a guess. When the tooling landscape is described more precisely than the process it serves, the rollouts have become the process.

The Hidden Costs of Tool-Led Change

The obvious costs of this pattern are licences and projects. The expensive ones are structural, and they compound quietly.

First, the bottleneck gets encoded. A process weakness that lived in habit was at least negotiable — you could change a rule in a meeting. Once it is configured into a system, changing it requires a ticket, a release window, and a business case. Tool-led change takes the least examined part of the process and makes it harder to alter.

Second, measurement fragments. Each system reports its own slice competently, and nobody owns the sum. The elapsed time between systems — which is where the waiting lives — appears in none of the dashboards, so the very data needed to find the bottleneck is what the tool landscape destroys. This is the same failure we described in the edition on why automation fails when the process is unclear: automating an unmeasured flow scales whatever it already does, including the waiting.

Third, and most consequential: the organisation learns that change means procurement. If every improvement arrives as a system, the internal capability to redesign a process — to change a rule, remove an approval, redefine a handoff — never develops. Teams stop asking "what should this process look like?" and start asking "what does the tool support?" That is a slow loss, and no vendor will flag it.

It is worth being precise about the diagnosis, because it determines the fix. This is a structural problem, not a behavioural one. Nobody in the chain acts unreasonably: the team wants relief, IT wants consolidation, the vendor wants a signature, the sponsor wants a visible deliverable. The pattern persists because the decision sequence rewards buying before describing. Change the sequence and the same people produce a different result.

Two Practical Levers

Two levers are enough here, and they work in order. The first ensures you know what you are buying against. The second ensures the purchase is judged by whether it fixed that, rather than by whether it went live.

Lever 1: Measure the Process Before You Write the Requirements

Requirements documents are usually written from interviews. People describe what they believe happens, which is a version of the process cleaned up by memory and shaped by what they are responsible for. Build a shortlist on that basis and you are selecting a tool to support a process nobody has actually observed.

The alternative is to start from the recorded facts. The timestamps that describe your real process already exist across the systems in use today — when a case was created, when it changed hands, when it was approved, when it closed. Process mining reconstructs the actual path from those records: which variants dominate, where cases wait and for how long, how often work loops back, and which steps carry almost no volume yet consume most of the configuration effort. Platforms such as noreja extend this with causal analysis, which matters here because the question is not only where the delay appears but what produces it.

Two things change immediately when requirements start from measurement. The first is scope: teams routinely discover that sixty to eighty percent of volume runs through a handful of variants, so a tool that supports those well and handles the rest as exceptions beats one configured for every case anyone can imagine. The second is honesty about the bottleneck. When the measurement shows that most elapsed time is waiting for a decision from a single overloaded role, the requirements list stops being about features and starts being about that role — a conversation no software selection will produce on its own.

There is a useful side effect. Sometimes the measurement shows the bottleneck is a rule, a threshold, or an unclear responsibility, and the correct response is to change it — for free, this quarter, without a project. A process you have measured is a process you can improve without buying anything, which is precisely the option the tool-led sequence never puts on the table. We wrote about the version of this problem where documentation and reality drift apart in the edition on processes that exist only on paper.

Lever 2: Make the Bottleneck the Acceptance Criterion

Most implementations are judged on delivery: is it live, migrated, trained, adopted. Those are project milestones, not process outcomes, and a rollout can achieve all of them while the flow is unchanged. The second lever is to define, before signing, the single process number the tool is expected to move — and to hold the project to it.

Make it concrete and narrow. Not "improve efficiency" but "reduce the median waiting time at the credit-check handoff from four days to one", measured the same way before and after, with a named owner and a date at which the comparison happens. One number, chosen because the measurement in Lever 1 identified it as the constraint. If several numbers matter, the tool is probably being asked to solve several unexamined problems at once.

This changes behaviour on both sides of the contract. Internally, it forces the sponsor to state what the constraint actually is, which is often where a project quietly dies — for the right reasons. With the vendor, it turns the conversation from feature comparison to mechanism: how, specifically, does this system reduce that waiting time? If the honest answer is "it makes the step visible so people react faster", that may still be worth buying, but it is a different claim from "it removes the step", and it should be priced accordingly.

Then run the comparison, and report it. Very few organisations look back at a tool decision with the same metric they justified it with, which is why the pattern repeats: without a measured verdict, every implementation is remembered as a success and the next purchase starts from the same assumptions. A short, honest post-review — the number moved, or it did not, and here is why — is the only mechanism that turns tooling decisions into organisational learning.

The principle to test both levers against: if you cannot describe the bottleneck in one sentence with a number attached, you are not ready to buy a tool for it — and if you can, you may not need one.

Food for Thought

How many systems touch your core process today, and how many measured improvements to that process happened in the same period?

For the last tool you introduced: what single process number was it supposed to move, and did anyone check?

If your next improvement had to be delivered without buying anything, what would you change first — and what stops you from doing that now?

Which of your bottlenecks is now configured into a system, so that changing it requires a release rather than a decision?

Who in your organisation can state the end-to-end cycle time of your most important process without looking it up?

When your teams discuss improvement, do they ask what the process should look like, or what the tool supports?

Conclusion: Describe the Bottleneck Before You Buy Around It

New software does not inherit a process's intentions; it inherits its structure. Buy before you have measured, and you pay to encode the current bottleneck more firmly, with fresh integration work on top and a fragmented view that makes the next diagnosis harder. The fix is not restraint for its own sake — sometimes the tool is exactly right. The fix is sequence: measure the real process first, write requirements against what the measurement shows, name the one number the purchase must move, and check that number afterwards with the same method you used before. Do that twice, and the pattern breaks: not because you buy less software, but because you finally know which problem each system was supposed to solve.

FAQ

Why do new tools often fail to fix process problems?

Because an implementation usually maps the existing steps, fields and approvals into new screens. It changes where work happens, not how it flows. If the process contained a multi-day wait or an unclear handoff, the new system reproduces it — often less visibly, because the delay is now inside an integration rather than in an inbox someone could chase.

What is the tooling trap?

The pattern in which each unresolved process problem triggers a new system purchase, so that implementations become the organisation's dominant workflow. Effort flows into interfaces, permissions and admin ownership rather than into the flow of work, and the number of tools grows while measured process improvements stay flat.

How do you know whether you need a tool or a process change?

Measure the process first. If the constraint turns out to be a rule, a threshold, or an unclear responsibility, changing it costs nothing and no software is required. If the constraint is genuinely volume, traceability or manual data entry, a tool can help — and the measurement tells you which capability actually matters.

What should the acceptance criterion for a tool implementation be?

One process number, defined before signing, that the tool is expected to move — for example the median waiting time at a specific handoff — measured identically before and after, with a named owner and a date for the comparison. Go-live, migration and training are project milestones, not evidence that the flow improved.

How does process mining help before a software selection?

It reconstructs the real process from timestamps that already exist in current systems, showing which variants dominate, where cases wait, and how often work loops back. That replaces interview-based requirements with observed facts, usually narrowing scope considerably and identifying the actual constraint the purchase should address.