Modelling the to-be process without romanticising the current one

A to-be process, also called the target or future-state process, is the agreed description of how a piece of work will run once a change is made. It names the trigger and the result, every step in between, who owns each decision, and which data each step reads and writes. The as-is process records how the same work runs today, detours and workarounds included.

Trouble starts when a project treats the current map as a first draft. The team sands off the visible friction and launches what is, underneath, the old process. This article sets out the three decisions that separate a real to-be design from an edited map: what the process delivers, what each step contributes and where authority sits.

What is a to-be process?

Treat it as the specification the business signs off before anyone reconfigures the ERP or moves a desk. A useful one fits on two pages, and the hardest part to write is usually the case that doesn't fit, because that case decides whether the design survives its first month in daily use. Around it sits the ordinary route: what sets the work off and what counts as finished, then for each step an owner, a deputy for when that owner is away, and the data the step reads and writes, with whoever keeps that data correct.

Why the as-is map misleads

Mapping workshops lean toward the org chart. Everyone in the room speaks for a department, and a design that moves work from one department to another needs somebody to argue for the loss. Usually nobody does, so the future map inherits today's split of responsibilities by default. That default gets expensive whenever a step sits two desks away from the person who first holds the full information, since every handover between them adds a round of questions.

The other trap is quieter. Mature processes carry steps whose reason has expired. A second credit check went in after one bad debt, and every customer return needs a supervisor's signature because of a single disputed refund. Both rules answered a real incident, and both incidents were covered years ago by other means. The steps outlived them. Workshops collect complaints, and a step that runs smoothly while serving nobody produces none, which is exactly why it stays on the map.

As-is and to-be process compared

The current-state map still has a job, only a narrower one than most workshops give it. Read it for counts: how many cases arrive in a week, how many take the awkward route, and where work sits overnight. Those counts tell you which exceptions deserve a route of their own in the new design and which can stay a phone call. The sequence of boxes is the part to leave behind.

The to-be process and the data model

Behind each box on a process map sits a question the business answers from its data. Can we ship this today? Is this customer good for the money? A to-be process runs only as fast as the slowest of those answers arrives, and it is only as dependable as the person who keeps each answer current.

In practice that means one extra column on the map, filled in step by step with the fields the step reads, the fields it writes and the role that owns each one. "The system" doesn't count as an owner, and neither does "everyone in sales". Ownership means a named role whose job includes fixing the value when it's wrong and reviewing it on a schedule, the rule the piece on master data as a quiet error source applies to every critical field. In the example below, the owner column is where the real problem turns up.

One caution on order. Opening the ERP's table structure first is tempting, because the fields are already there, but then you end up modelling the process the software suggests. Write the steps first and bring the ERP in when you check whether it can supply each field.

The three decisions, worked through an example

This is an illustrative example with invented figures and an invented company. A distributor of hydraulic hoses and fittings receives around 60 orders a day by email, about half of them as PDF attachments. Each order passes through six hands before the customer hears anything, and a confirmation takes two working days on average.

Decision one: name the result and the trigger. The distributor settles on this: the customer knows, on the day they order, whether they'll get what they asked for and when. The trigger is an order arriving through any channel, PDF attachments included. Written down like that, the sentence works as a test, and any step that doesn't move the order toward that answer has to justify itself.

Decision two: make every step earn its place. Go through the steps one at a time and ask what exactly would go wrong without each. At the distributor two steps have no good answer. Sales staff key every order into the ERP, and then a colleague compares the printout line by line with the original email, a check introduced when the previous system dropped lines. That system was replaced years ago. Separately, every order above €2,000 waits for accounts to run a credit check, although the ERP already holds a credit limit for every customer that nobody looks at. What the retyping itself costs is worked out in what retyping a PDF really costs.

Decision three: put each decision where the information is. The credit limit sits in the customer record from the moment the order is entered, so the order desk can release anything within the limit. Accounts only sees the orders that exceed it.

Then the awkward case. At the distributor it's the order line that can't be filled from stock, which today ends up as a sticky note on a monitor. In the to-be process it gets its own route: a partial confirmation with a promised date, owned by the order desk. Without that route, the first unfillable line of the morning lands on a sticky note again, and staff conclude the new process is for easy orders only. Gaps of this kind are how old processes creep back after a project.

Now the data column. To confirm on the same day, the order desk needs four fields it can trust when the order arrives. Available stock belongs to the warehouse. Credit limit and open balance belong to accounts. Replenishment lead time for items that must be back-ordered belongs to purchasing. That last field is where the example finds its real problem. Nobody has reviewed the lead times in the item master since the ERP went live, so any date promised on a back-ordered line is a guess until purchasing takes ownership of it.

In the example, six steps become four, and the distributor expects same-day confirmation for orders within the credit limit. That expectation has to be checked against a measured lead time once the new process has run for a few weeks, not against the figure people quote from memory.

If you'd rather not run this alone, our process analysis works in the same sequence and measures the current state before anyone draws the new one. Fixed scope, fixed duration, fixed price.

The next step

Pick one process you know well and write the table for it: step, data read, data written, owner. Any row with an empty owner column marks the place where your to-be process will break first.