Artifact §02 · Process map

The process, drawn

The requirement in the previous piece came out of a walkthrough, not a meeting. This is what the walkthrough produced: the month end close as it runs today, with the waiting marked, and the same close once FIN-014 is live. Two drawings on the same six day grid, so the difference is visible before you read a word.

I draw before I write. Half the value is in the drawing and the other half is in what people say when they see their own week laid out as boxes. Nobody corrects a paragraph. Everybody corrects a box that is in the wrong lane, and those corrections are the most useful requirements input I get.

Like the requirement, this is illustrative. No employer's process is drawn here, which is what lets me show the whole thing.

How to read it

• A task, done by whoever owns the lane
• The system doing the work
• Work kept by hand, on purpose
• Someone waiting
• A decision
• The acceptance criterion in FIN-014 that the step satisfies

This is most of BPMN without the parts that need a course. When a team reads full BPMN, I draw full BPMN. When it does not, I draw this, because a notation the controller cannot read is a notation the controller cannot correct.

As is: the close today

What the drawing showed that the interview did not

1. The analyst's three days are not the longest bar. The controller's is.

   She waits from the morning of day one to the afternoon of day five, and everything downstream waits with her. The reconciliation is the bottleneck, but the cost lands on people who never touch it. That is why the request arrived as "better reporting": the report is the only part of this anyone outside finance ever sees.

2. The loop has no owner.

   Each difference goes back and forth by email. There is no list of open differences, no record of which ones took two days, and no one accountable for the loop as a whole. It is invisible work, and invisible work does not get fixed, it gets tolerated.

3. Nothing checks the spreadsheet.

   The reconciliation is never itself reconciled. If an account code exists in one export and not the other, the line simply does not appear, and the error stays hidden until someone downstream disputes a figure. That observation became AC-02: the listed differences have to add up to the whole variance, with no residual.

To be: the close with FIN-014 live

What changed, and what deliberately did not

1. The ledgers close the same way.

   I did not touch the upstream processes. The people who own them were not in the room, their steps were not the problem, and a requirement that quietly redesigns someone else's work is how you lose a department.

2. The matching moved to the system. The judgement stayed with people.

   The run lists the differences. The analyst decides what they mean. The controller decides when to publish. Automating the judgement would have been a larger build with a smaller chance of being trusted, and a reconciliation nobody trusts is a reconciliation that gets redone by hand in a spreadsheet.

3. The manual step is still manual, on purpose.

   Unexplained lines go to the production lead by hand. The controller asked for that, and she was right. Until the variance pattern is understood, an automated adjustment is a way of hiding the problem with more precision. It is the first item under "out of scope" in the requirement, and this is why.

4. Every system step carries its acceptance criterion.

   That is the traceability a tester needs three months later, and it is how I check myself now: that I have not drawn a process the requirement cannot deliver, or specified something the process does not need. Two of the criteria in FIN-014 were rewritten after I drew this.

5. Day five or six becomes day three.

   Roughly three working days a month come back to the analyst, and everything downstream moves two to three days earlier. I would not put those numbers in a business case until I had measured two real closes. They are the reason the work is worth doing, and the reason I wrote AC-05 as a hard date rather than a preference.

What I sent the controller the same afternoon

A walkthrough that does not produce a readback within a day is a walkthrough that will be remembered differently by everyone in it. This is the note, in her words where I caught them.

The two uncertainties at the bottom became OI-1 and OI-2 in the requirement. They were not discovered by a template. They were discovered because two people in the same room gave two different answers to a question I happened to ask both of them.

Where this goes wrong

A map like this can be too tidy. Real processes have the months that do not fit: the production ledger that closed late, the analyst on leave, the year end when everything is bigger. I draw the normal month first because people can agree on it, then I ask for the worst month and draw the differences on top in a second colour. The second drawing is usually where the open items come from.

The other failure is drawing the process I expect rather than the process they have. I have done it. The cure is cheap and slightly embarrassing: draw it live, in front of them, badly, and let them fix it. A clean diagram produced alone at a desk is a hypothesis. A messy one corrected by the people who do the work is evidence.

Written by Nasmaan Ibrahim for nasmaan.com. Illustrative, not drawn from any employer's systems or data. Maps drawn as inline SVG, so they follow your theme and print clean.
Back to the record · 01 One requirement, written out in full · 03 The UAT pack, in miniature · Resume, PDF