Modelling the Target Process — Without Romanticising the Current One

The symptom

The usual sequence sounds reasonable: capture the current process, mark the weak points, derive the target process from it. In a presentation the result looks clean — chaos on the left, order on the right.

What regularly emerges, however, isn't a new process but the old one with less friction. The same steps, the same responsibilities, the same underlying logic, only faster. That's better than before, and far short of what was available.

The reason is simple: deriving from the current state inherits all of its assumptions without ever testing them. And the most expensive assumptions are the ones nobody recognises as assumptions any more.

The mechanism

Every process that has grown over time contains steps that once had a good reason. A double check, because six years ago an error got expensive. A management sign-off, because back then an employee costed too generously. An interim notification, because a customer once asked.

Those steps outlive their cause. The old error is now guarded against some other way, the employee has left, the customer no longer asks — the step remains. It continues to cost time and is felt by everyone to be necessary, because everyone has always done it.

During current-state capture, such steps don't get flagged as weaknesses. They run perfectly smoothly. What gets flagged is what sticks. So the conventional method systematically removes the loud problems and leaves the quiet ones standing.

The second mechanism is loyalty to existing responsibilities. A current-state map depicts who does what today. Anyone deriving from it usually holds that distribution constant, because shifting it means conflict. Yet many of the most valuable improvements consist of exactly that — moving a step somewhere else: closer to the information, closer to the decision, closer to the customer.

The cost

An anonymised example, altered in detail, real in pattern. A supplier wanted to accelerate its quotation process. The current process had eleven steps across four departments. A first attempt had already been made: the two most obvious waiting times had been removed and lead time had fallen from twelve days to nine. After that it stalled.

Looking more closely, three of the eleven steps proved entirely dispensable — not because they were badly executed, but because their purpose no longer existed. A technical feasibility check ran on every quotation, although 80 per cent of enquiries concerned repeat parts of known feasibility. A commercial second check existed for a costing template that was by now hard-coded anyway. An approval tier applied above an order value that had been large ten years earlier and now described the average order.

Those three steps together cost an average of 3.8 days per quotation. At around 400 quotations a year, with a measurable correlation between response time and win probability, that was the largest single item in the entire process — and the first optimisation had left it untouched, because not one of those steps was sticking.

The fix

A target process comes from three explicit decisions, not from a derivation.

First: what is the result, and what is the triggering need? Not "quotation preparation", but: a customer has an enquiry and needs a dependable statement on price and date. Everything in the process must be measurable against that. The formulation sounds banal and is the sharpest filter available.

Second: which step contributes to that result — and what specifically happens if it's removed? This question has to be answered for each step individually, with a concrete consequence rather than "then we lose the safety net". If nobody can name a concrete consequence, that itself is a finding.

Third: where does the decision have to be made? As a rule, where the information is first complete. Approvals sitting higher up than the information reaches generate queries — and queries are queue time.

One practical rule sits alongside these: the exception is modelled into the target process, not added afterwards. A process that knows only the normal case becomes the old process again through the exception.

In the example, eleven steps became six, plus a described special route for new parts. Lead time fell from nine days to three — well beyond what optimising the current state could have reached.

That sequence — measure, then clarify purpose, then model — is the core of our process analysis. Fixed scope, fixed duration, fixed price.

The next step

Take a process step you consider self-evident and ask: what exactly happens if we drop it tomorrow? If the answer stays vague, you've just found an assumption that has been passing as a necessity for years.