As-Is Before To-Be: Modelling the Process That Actually Runs
Two models of the same returns process side by side, and the table of differences between them, with the column most people skip: what each change breaks.
Most as-is models I am handed run in a straight line. Request, check, decide, done. Five boxes, one lane, not a single branch that goes anywhere unpleasant. Underneath it sits the to-be, with a form at the front and an automated step in the middle, and the document claims a saving.
An as-is model is a picture of a process as it actually runs, including the paths where it stalls, loops back or quietly hands the work to the customer, drawn before anybody proposes changing it. That last clause is the entire discipline.
A straight-line as-is has one consequence that survives every review. If nothing in the current state ever fails, then every benefit claimed for the future state is being measured against a process that already worked, and no reader can tell whether you improved anything or added a form.
The worked example below is returns and refunds at a mid-size online retailer. It is built only from sources I am free to publish: the retailer's published returns policy, its help centre articles, and ten public complaint threads I selected myself. There was no engagement and no client. Nobody at the company was asked about anything, at any point. No interviews, no workshops, no exports, no internal data. Where a branch comes from my reading of how the process has to work rather than from a source, the model says so on the branch.
In short
- An as-is with no failure branch in it makes the to-be look like an improvement to a process that was already fine.
- Draw the branch where the case stops before you draw anything you intend to change; here it is the point where evidence is incomplete, the case is parked, and nobody's name is on it.
- Four of the ten complaint threads I read ended in that branch, which is a count of threads I chose myself rather than a rate across cases, so the model carries the frequency as unknown and flagged for measurement.
- The artifact worth publishing is the table of differences between the two models, and its third column says what each change breaks.
Why bother with the as-is if you are going to change it anyway?
Because the to-be is an argument, and the as-is is the evidence it rests on. Remove the failure branches and the argument has nothing under it.
There is a second reason, more useful in a room. People who will not read a requirements register will look at seven boxes and tell you the third one is wrong, which is exactly what you wanted. A to-be never gets that reaction, because nobody has lived in it yet.
I do not have that room here. This case has no stakeholders to correct me, and everything below is limited by that. The compensation is labelling, not confidence.
The as-is, step by step
Damaged delivery, web store order. The customer has the parcel and the item is broken.
- The customer notices the damage and goes looking for the route. The published policy treats change-of-mind returns and damaged deliveries as separate cases with separate rules, and the help centre has articles for both. Where the case can leave the process: the process has two doors and the customer picks one before knowing which one they need.
- First contact. Phone or a contact form, depending on which help centre article the customer landed on.
- Evidence is requested. Photographs of the item and the packaging, plus the order reference.
- The customer supplies the evidence, or supplies part of it. Where the case can leave the process: this is the branch that matters. Evidence arrives incomplete, the case is parked pending more information, and from that point the only person who moves it forward is the customer. Four of my ten threads end here, with the customer chasing and no named person answering. That is a count of ten threads I selected, not a rate, and no public source will give me the real frequency.
- An agent assesses the case. Some decisions cannot be made without the returned item being received and confirmed. Where the case can leave the process: that wait is my inference from how the process has to work, not something any source states, and the model says so on the branch. Nothing public tells me whether the wait has an owner or a limit.
- A decision is recorded. The published policy is explicit that a case should not stay open beyond a stated number of working days.
- The item is collected or returned, and the refund is posted.
Steps 4 and 5 are the shape of the problem: a process with a clear start, a clear end, and two places in the middle where work stops without anybody being accountable for restarting it. Neither appears in a straight-line model, and both are where the customer experience actually happens.
The to-be, step by step
- One entry point that asks what happened before it asks what the customer wants. Damage and change of mind are separated by the answer, not by which article the customer found.
- The form states what evidence is required and refuses an incomplete submission while the customer is still there and can fix it.
- A case reaches an agent complete, or it does not reach an agent at all.
- The agent assesses it. Same authority, same rules, same published windows.
- The parked branch still exists. A case that cannot be completed goes to a named person with a deadline attached, rather than to a queue. The escalation window itself belongs in the requirements register, not in this model.
- The dependency on the warehouse confirmation is drawn explicitly, with a state the case sits in and a person it belongs to while it waits.
- Decision, collection and refund posting are unchanged.
This draft to-be changes five things and leaves the rest alone. That ratio is deliberate. Redraw every box and the first competent reader will ask which of the twelve changes produced the benefit you claimed, and you will not be able to answer. The version I actually recommend in the published case is narrower still, two changes out of these five: evidence collected before a human sees the case, and a named owner with a clock on the parked branch. The other three are drawn here and parked there, because a proposal you can only defend as a set is a proposal nobody can approve in parts.
The table of differences
This is the artifact. Two models are input; the table is what somebody can actually review.
| What changed | What I deliberately left alone | What this change breaks |
|---|---|---|
| One entry point, routed by what happened | The two policies stay separate, with their own rules and windows | The customer classifies their own case at the door, and a miscategorised case looks well-formed, so it is harder to spot than the visible false start it replaces. Somebody has to own the routing logic, and no public source tells me who. |
| Evidence collected by the form before a human sees the case | The phone line stays open and unchanged | The failure moves earlier and out of sight. A customer who cannot satisfy the form never becomes a case, so the parked-case count improves while the same people stay stuck. A parcel that never arrived has nothing to photograph, and that group is now out of scope with a reason rather than quietly worse off. |
| Parked cases get a named owner and a deadline | The parked branch itself stays in the model, because it will still happen | One person carries a queue of the worst cases. A deadline also rewards closing cases by refusing them, which would show up as a falling refund rate and read like success. Any measurement here has to watch refusals next to refunds. |
| Waiting states made explicit, including the dependency on the returned item | The agent's decision authority is untouched | Two states somebody has to keep accurate by hand. A state field nobody updates is worse than no state field, because within a month there is a report built on it. |
| A measurement point on cases with nobody's name against them | The published thresholds, including the partial refund rule, stay exactly as published | People manage to a number as soon as it exists, usually before anyone understands what it counts. The first readings will be bad and mean nothing, and somebody has to say so in advance. |
The third column separates this from a list of improvements. Anyone can name what changed. Naming the cost, and naming who pays it, is the part a reviewer cannot fake having thought about. It also protects you: a change with its cost written beside it is a proposal, and a change with only a benefit beside it is a pitch, and readers who take requirements documents apart for a living tell the two apart inside a page.
Row two is the one I got wrong first. My initial to-be moved the evidence check to the front and recorded the benefit, which is real. What it did not record is that the failure had not disappeared, it had relocated to a place where no queue metric can see it.
The blank version
Copy this into your own case. The bracketed prompts are what each cell has to answer.
| What changed | What I deliberately left alone | What this change breaks |
|---|---|---|
| [the change, in one clause, naming the step] | [the neighbouring thing you did not touch, and why] | [who is worse off, which metric goes quiet, what new work appears, what perverse incentive it creates] |
| [change 2] | [kept 2] | [cost 2] |
| [change 3] | [kept 3] | [cost 3] |
| [change 4] | [kept 4] | [cost 4] |
Unknowns carried forward:
[branch] - frequency unknown, measurable at [where], owner [name or open]
An empty third column means either the change is trivial or you have not finished thinking about it. It is almost always the second, and the missing entry is usually a person whose work increases so that somebody else's decreases.
How do you model a process you can only see from outside?
By putting the source on the branch instead of in a footnote. Every path in the as-is above carries one of three labels, visible in the model rather than in an appendix nobody opens.
Observed. A source states it or a thread demonstrates it. The parked branch is here.
Inferred. The process cannot work without it, but nothing public says so. The wait on the returned item is here, and calling it observed would be the cheapest way to lose a reviewer.
Unknown. Frequency, volume, cost. Almost every number about this process falls here, and writing unknown on a branch beats writing a plausible figure, because unknown converts into a measurement task with an owner.
A number appears in the model only if I can name where it came from. Four of ten threads keeps its denominator and its selection method every time it is written, and never becomes a percentage, because the moment it does it is describing cases I have never seen.
Notation matters less than any of this. BPMN if you know it, labelled boxes if you do not. What a reader checks is whether your gateways have both outputs drawn, and whether the unpleasant one leads anywhere other than off the edge of the page.
Where to start
Take a process you went through as a customer in the last month and draw only the branch where it stopped. One branch, with the point where you had to chase somebody marked on it, and a note saying what you know and what you are guessing.
Then write the three-column row for the one change you would make. If the third column stays empty for more than a few minutes, the change is not ready.
The full returns case, with both models and the review notes left in, is in the Proof Pack. The scorecard has the process checks in it, so you can go after your own model before anybody else does. How these two models sit alongside the other four documents is in the six artifacts piece.
A to-be is easy to make look good. It is only worth reading next to an as-is honest enough to make it look necessary.
Read next
The Context Diagram That Settles the Scope Argument
The scope argument runs on what stays outside and who inherits it. One box, a ring of entities, one line per exchange, a
Five Whys Stops Working at Why Number Two
When five whys does not work, and what to do instead: one incident from a published returns case, three honest why chain
Get the Proof Pack
Six blank templates and one worked case. Free, one email. The scorecard is a separate file and needs none.
Send it to meAll field notes · The portfolio guide · More in The Case File