01 — Theory
Getting the real process, and agreeing on it
Five questions decide whether the As-Is is a description of the work or a second copy of the handbook.
How do you run an interview that gets past the happy path?
Open with a case, not with the process: "walk me through the last complaint you handled". Follow the case through every hand-over and ask, at each one, what happens when the next person is not there, when the information is missing, when the customer does not answer. Every "it depends" is a gateway; ask for the rule behind it and, when there is none, write that down as a finding. Every "normally" hides an exception; ask for the last time it was not normal. Listen for the spreadsheet beside the system and the phone call that replaces a form; those are workarounds, and workarounds are the most honest description of where the designed process does not fit. Close by asking what the handbook says that nobody does, and what everybody does that the handbook does not say.
How do you facilitate a workshop where people disagree on how the work runs?
Put the diagram on the wall and make the disagreement visible as two branches, not as an argument. Usually both sides are right: one unit describes the standard case and the other describes the exception they see most, or the process really does run two ways depending on who takes the call. Ask for the last case each side handled and draw both. If the branches merge later, the disagreement was about a decision rule, and the workshop's job is to name the rule. If they do not merge, there are two processes, and that is the finding. End the workshop with the diagram everyone has seen, not with a promise to model it later; the workshop as the deliverable explains why.
How much BPMN do you need, and which symbols carry a business process?
A dozen symbols carry nearly every business process: start and end events, tasks, the exclusive and parallel gateways, pools and lanes, sequence and message flows, data objects, and the message and timer events that show where a case waits for someone else. Use those, and leave the rest of the notation to the people who build executable models. The one addition worth making is the control step: a task marked as a check with a named owner and a piece of evidence, because that is what an auditor will ask about and what the designed process usually leaves implicit. The BPMN guide walks through the symbols; the examples show them in use.
What do you do with exceptions and workarounds?
Draw them. An exception that happens to one case in four is not an exception; it is a branch, with a gateway, a rule and a path that has to end somewhere. A workaround is drawn where it happens, with a note on what it replaces, because the To-Be in step 8 will either make it official or make it unnecessary, and both need the As-Is to show it. What you do not draw is the once-a-year case that one person remembers; record it as an open question with a name and move on. The test is whether the people who run the process recognise the diagram, and they recognise their exceptions before they recognise the happy path.
When is a model good enough to sign off?
When three things are true. Every lane owner has read their lane and corrected it at least once, because a diagram nobody corrected has not been read. Every gateway has a question and every outgoing path has a rule or an explicit "no rule, decided by the person". And every open question has a name and a date, so that sign-off does not mean "complete" but "agreed as the basis for the analysis". A model is signed off by the people who run the process, not by the analyst, and the signature is a version, not a document: later changes make a new version and leave this one as it was.
02 — Better with patchley
Capture is where patchley takes on the most work
The diagram forms while people talk, so the correction happens in the room and not in the week after it.
One person talks, one takes notes, and the model is built afterwards from memory and notes.
With patchleyThe diagram builds while people talk, visible to everyone, and they correct it on the spot: wrong lane, missing decision, forgotten exception.
Recorded calls get rewatched to find what was said.
With patchleypatchley joins Teams, Zoom, Webex or Google Meet as a visible participant and records only between Start and Stop. What was said lands as notes, and one step turns them into a diagram draft.
Corrections go round by email, and nobody knows which version is current.
With patchleySay what is wrong, by voice or in writing; see the proposed change; apply or reject it. Each change makes a new version, and your own hand edits are never overwritten.
Running the room and signing off the model. patchley draws what was said and points out what is unclear or missing when you ask about the diagram; who is right when two units disagree is decided by the people, in the room.
03 — The running case
Two interviews change the handbook draft
Tannhof Armaturen GmbH is fictional and every figure is invented. Step 5 ended with a draft read from procedure QM-14. Two interviews followed: the team lead of Customer Service and the lead of the Complaints Team in Quality.
What Customer Service said that the handbook did not
The handbook routes every complaint to Quality. The team lead of Customer Service described a first question that is in no document: is this a small complaint, a credit below a threshold from a regular customer? About a third are. For those, the agent calls the Sales Office, a colleague settles the matter with the customer by phone, Accounts Receivable issues the credit note, and the complaint is closed. Nobody tells Quality, nothing is recorded in the CAQ system, and the same fault can come back without anyone noticing. In the diagram this is a new gateway, a new lane for the Sales Office and a second end event, "Complaint settled", that Quality never sees.
How the two versions were reconciled
The Complaints Team's description matched the handbook from the moment the email arrives, with more detail: the completeness check that fails for roughly every fourth complaint, the returned part that takes about a week to arrive and then waits at the Returns Desk, the head of Quality's approval of every 8D report as a mandatory control, and a decision the handbook merges into one step: credit note or replacement, which became a gateway with two paths. The two versions did not contradict each other; they described different stretches of the same process. Reconciling them meant placing the Customer Service branch in front of the Quality path, and agreeing that "Forward complaint to Quality" is where one view hands over to the other.
What the first draft got wrong, and who noticed
Three things. The draft had no small-complaint branch, because the handbook has none; the team lead of Customer Service noticed as soon as she saw the opening of the diagram. The draft had the Returns Desk passing the part straight to the Lab; the Complaints Team lead added the wait, as a timer event, and that one element carries most of step 7. And the draft merged credit note and replacement into one step; the Complaints Team lead split it, and Assembly and Logistics gained their steps. In every case the person who noticed was the one whose lane it was.
The diagram above holds what the two interviews added to the handbook draft. In patchley such corrections are given in plain words, by voice or in writing, while people talk or afterwards: describe what is wrong, see the proposed change in the diagram, and apply or reject it. Each applied change is a new version; the handbook draft stays as version one.
04 — Helper tool
BPMN checker
Three questions this tool answers: is the model formally correct, what would a reviewer flag first, and which fixes matter and which are cosmetic. Choose or drop a BPMN 2.0 file, or paste its XML; it is parsed in your browser and never leaves it. The checker reports missing end events, gateways without a question or without labelled paths, empty lanes, orphaned elements and tasks without an incoming or outgoing flow.
Works with BPMN 2.0 XML from patchley, Camunda Modeler, Signavio, ADONIS and most other tools. The file stays in this page; reloading the page forgets it.
05 — Best-practice outcome
A signed-off As-Is diagram
One diagram, one version number, agreed by the people who run the process. Three checks tell you whether it is that.
Capture ends with sign-off by the people who run the process, and the signed version stays as it was, whatever changes later.
06 — Common traps
Where capture goes wrong
Three mistakes that produce a tidy diagram of a process nobody runs.
People describe the ideal instead of the real work
Asked in general terms, people describe what should happen, partly from politeness and partly because that is the version they were trained on. The remedy is specific: the last case, the one before, the one that went wrong. Specific cases cannot be idealised.
Too much detail
A diagram with every click and every field is read by nobody and signed off by everybody. Stop at the level where a step changes hands, changes a system or changes a decision; what happens inside one person's screen belongs in a work instruction, not in the process.
A model built only from the handbook
The handbook describes the process as designed, years ago, by someone who no longer runs it. At Tannhof a third of the cases would have been invisible. A draft from the handbook is a good start and a bad end; the interviews are what make it an As-Is.
07 — Ready to move on?
Two questions before step 7
The analysis in the next step rests on this diagram. If it is not agreed, the findings will be argued instead of ranked.
Who signed it off?
Named people, one per lane, and the process owner for the whole. "The team" is not a signature. If a lane owner has not read their lane, the diagram is a draft for that lane, whatever the rest of it says.
Which open questions remain?
Listed, with a name and a date each. An open question is not a defect in the As-Is; an unlisted one is. At Tannhof the list had one entry: whether small complaints should reach the CAQ system, to be decided in the To-Be.