As-is and to-be process template: boundaries, exception paths and the delta

Boundaries, as-is steps, exception paths, to-be steps and what changes between them, written before anything is drawn. Blank, and filled from the worked case.

Fill this in before you draw anything. A diagram drawn first becomes a picture of what you assumed, and it is hard to argue with a picture, which is exactly the problem. Written steps can be checked line by line by someone who does the work, and every line below converts into one shape on a canvas when you are ready.

Nothing enters this document without a tag. The seven-tag provenance legend is at the top of template 1 and it governs the four templates that hold claims about the business (the stakeholder map, this one, the requirements register and the rule register): [POLICY], [HELP], [THREADS n=10], [WALKTHROUGH], [LAW], [MINE], [OPEN]. A process model is where untagged facts do the most damage, because a timing typed into a table stops looking like an estimate within about a week. Every step, every time and every exception below carries where it came from, and the example rows show it.

1. Boundaries

Three lines, and the second one is where people go wrong.

• Trigger event (the process starts when):
• End events (the process ends when), all of them: list the successful ending first, then every unsuccessful one. A process with a single happy ending on paper has unsuccessful endings in real life that nobody owns.
• Out of scope, and why:

Example, from the worked case in this pack:

• Trigger: the customer reports that a delivery arrived damaged.
• Ends: refund paid in full; refund refused with a reason given; case parked with no decision and no owner. The third one is not a failure of my modelling, it is what happens.
• Out of scope: change-of-mind returns (separate policy, different owner), marketplace orders (different contract).

2. As-is: the steps

Write what happens, not what the policy says happens, and mark the difference when you find one. One row per handover, because every handover is a place where a case can stop moving. Use the verb first in the step column so that the row reads as an action rather than as a topic.

On the time column. Write both numbers. Touch time is how long the work takes when someone is doing it; elapsed time is how long the case sits there. Ten minutes of work spread over four days is the finding, and one number on its own hides it. Every number gets its own tag, because the two halves of the cell rarely come from the same place: an elapsed time can sit in a complaint thread while the touch time next to it is your estimate.

The italic rows are an example from the worked case in this pack, built from public sources. Not one time in them was measured inside the company. Nobody put a fake damage claim through a real shop's process to collect timings, so [WALKTHROUGH] means the published journey was followed to the point where a genuine order would have been needed, and every estimate says [MINE] instead of sitting in the table looking like a measurement. Delete the rows before you send yours.

3. Exception paths

This is the section the document exists for. The happy path is the part everyone can already describe, and it takes twenty minutes to write. The exceptions are where cases stop, where money leaks and where your reader finds out whether you have understood the process or read about it. One block per exception, copied as many times as you need.

EX-1 - Evidence incomplete, case parked

EX-2 -

If you have written one exception, you have not finished. Ask the person who does the work what happened last week that was not normal, and then ask what happened the week before.

4. To-be: the steps

Same table, one extra column. Keep the step numbers aligned with the as-is where the step survives, so a reader can put the two side by side without a decoder ring.

Every target time in a to-be is [MINE] unless it comes from a rule, and it stays tagged. The 48 h in the example row is a number I chose, tighter than the published window on purpose; the design does not fall over if its owner makes it 72. Tagging targets is what stops a proposal being read back to you six months later as though it had been measured.

The exception branch still exists in the to-be. It has an owner and a deadline attached to it, which is the change. A to-be with no exception paths at all is a sales pitch, and the first reviewer who has run the process will say so within a minute.

5. What changes between as-is and to-be

The fourth column is the one that gets read. Everyone can propose a bigger change; the analyst is the person who can say why the smaller one is enough, and what evidence would make them reconsider.

6. Turning this into a diagram

Five rules, and the model draws itself.

1. Every numbered step becomes one task box. The verb-first wording is already the label.
2. Every actor becomes a lane. If a step has two actors, it is two steps and you have found a handover you had not written down.
3. Every exception block becomes a gateway with its condition on the outgoing path, drawn at the step it branches from.
4. Every ending in your boundaries section becomes an end event, including the ones nobody wants. The parked branch on a diagram is worth more than the whole happy path.
5. Times go under the boxes as annotations, both numbers, and the tags travel with them onto the canvas. Nobody argues with the shapes. People argue with the elapsed times, which is the conversation you want.

Before you call this done

1. Does the as-is show where work stops? If every path on the page ends in success, you have modelled the policy, not the process, and your to-be will look better than it is.
2. Can the person who does this work read the step table and disagree with a specific line? Show it to them before the diagram exists. Their corrections are the document.
3. Is every claim on the page tagged, and is every "how often" either counted or openly marked as unknown? Turning ten complaint threads into "40% of cases" is the easiest thing in any document for a reviewer to catch, and the most expensive to have caught. Keep the count as a count, keep the n in the tag.
4. Does the to-be change as little as possible? Count the changed rows. If more than a third of the steps are new, you have designed a system and skipped the analysis.

How long this takes. Three to four hours for a process this size, including one full redraw. There is always one full redraw.

The one mistake. Modelling what should happen instead of what does.

Scorecard checks that apply to this artifact: 03 The as-is model shows the exception path, not the happy one 09 Every task in both models has one actor against it: a lane, a role or a named system 10 Every claim about frequency or volume carries its source, or is marked as not measured 11 The to-be states what changed against the as-is, and what deliberately stayed the same 12 Every branch in the to-be where a case waits ends with a named owner and a time limit

Template 2 of the Proof Pack, from analify.com. Use it in your own applications and at work, including commercially. Do not resell it as your own product.

In the worked case

Section 3 of the worked case shows this artifact filled to the standard the template asks for: returns and refunds at a mid-size online retailer, built from public sources only, with every number tagged. Read it there, then come back to the blank.

The scorecard checks for this artifact

Two models of the same process: how it runs today, and how you propose it should run.

All twenty-five checks, with the scoring scale: the scorecard.

Notes that work on this artifact

Next template

All six templates · The worked case · The scorecard