Process: as-is and to-be

Show how requests are handled today, how they will be handled, and which rule makes each new step necessary.

After the brief and the first pass of rules. Inputs: the brief, the stakeholder register and the source register. Feeds: the requirements, the user stories, the RACI and the tests.

• Draw the as-is in lanes, one lane per role.
• For each as-is step, write what goes wrong and which rule it breaks.
• Draw the to-be, and label every decision point with its decision table.
• Tag each to-be step with the rules it applies.
• Show every way out of the process.
• List what changes, step by step, and why.

1. Where does the clock start, stop and restart? Answered in TB-01, where it has already started on the date of receipt, whoever holds the request. TB-05 records day 1 and the deadline, TB-06 restarts the count and TB-12 stops it; document 07 shows every move.
2. Which rule makes each to-be step necessary? Answered in To-be table, column "Rules and tables".
3. What changes between the as-is and the to-be, and why? Answered in Table "What changes".
4. Where does a request leave the process? Answered in Column "Exit?": TB-03, TB-06, TB-08, TB-12, TB-13, TB-14 and TB-15.
5. Is the as-is observed or assumed? Answered in As-is section, first paragraph: assumed, not observed (DEC-05).

• A to-be that is the as-is with a system name added. You can spot it when every to-be step has an as-is twin and no rule explains the difference.
• No exits: every path ends in "reply sent", although some requests are never answered.
• Lanes for systems instead of roles: a lane that cannot be held to account for anything.
• Decision points without labelled outcomes: a diamond whose arrows say nothing, so two readers follow different paths.
• An as-is written as fact when nobody observed it: the as-is carries no tag, and no one can say who watched the work.

• The as-is is a starting point chosen by the author, not an observation (DEC-05). Rejected: a council that already has a case system, which would leave less to analyse and hide the rules in someone else's configuration.
• Lanes are roles, never systems, and the to-be names no product (DEC-14). Rejected: a lane for "the case system", which would make the to-be the as-is with a system name added.
• Every decision point carries its decision table's ID, or its rule where no table applies, and each outcome carries its rule numbers. The diagram and document 10 then cannot drift apart unnoticed. Rejected: decisions written as free text on the diagram.
• The approver's lane is labelled with OQ-08, because nobody has agreed which role approves. Until then the information governance lead approves (DEC-10). Rejected: naming a role on the diagram that nobody has agreed to.