The problem
Why most process documentation is out of date
Three ways organisations document processes, and what happens to each one the day a step moves. The last column is the approach this page describes.
| The handbook | The wiki | Analyses that follow the diagram | |
|---|---|---|---|
| Where it lives | A document per process, often a Word file converted to PDF at the last audit. | Pages per topic, written by whoever had time, linked by hand. | On the diagram. Every step carries its own analysis; the diagram is the table of contents. |
| Relationship to the diagram | Separate. The diagram is a picture pasted into chapter two. | Separate. If there is a diagram, it is an attachment. | One source. The text is written from the step it belongs to and from the conversation that produced it. |
| When a step changes | Someone has to remember the handbook exists, find the chapter and rewrite it. | The page stays as it was until a reader complains. | The analyses update with the diagram. What you wrote or corrected by hand stays as it is. |
| The audit question | "Is this the current version?" Usually answered with a date, not with confidence. | "Which page is authoritative?" Often several. | Which version was signed off, and by whom. Every version stays. |
| Getting it into a deck | Copy and paste, then reformat, then repeat after every change. | The same, with screenshots. | The deck is filled from the diagram and the analyses, and refilled after a change; what you changed in patchley's deck editor is kept. |
Documentation goes stale when it is a second artefact next to the process model. It stays current when it is the process model, read step by step.
Per step
What a step-by-step analysis contains
Every step in the diagram can carry an analysis. patchley writes it per step, from what was said in the interview and what the diagram shows, and you choose the lens. The lenses can be combined; a compliance analysis and a pain-point analysis of the same process are two readings of the same steps.
SOP: who does what, with which system, and what comes out
The standard operating procedure per step: the role that performs it, the inputs it needs, the system or document it works in, and what it hands to the next step. Written in the order of the diagram, so it reads as a procedure, not as a list of fragments.
Pain points: where the process waits, breaks or is done twice
What the people who run the process said about each step: where cases wait for a signature, where data is typed a second time, where a workaround replaces the designed path. Pain points are attached to the step they belong to, so an improvement discussion can start from the diagram.
Compliance: objective, standard reference and evidence per control step
For every step marked as a control, three things: what the control is meant to prevent or ensure, which internal policy or public framework it refers to, and which evidence the step leaves behind. That is the structure an auditor asks for, and it is far easier to fill in while the process is being captured than months later.
Quantitative: the figures you provide, laid out per step
Volumes, durations, costs or error counts, where your organisation has them. patchley does not invent figures; it lays out the ones you provide or estimate per step in a consistent structure, so that the numbers from three departments finally sit next to each other on the same diagram.
The questions your organisation asks about every process. Many organisations already have a documentation standard: the fields a process description must contain, the headings in the quality manual, the questions internal audit asks. Give patchley that template and it is answered per step, in your wording and your structure.
In sync
Keeping documentation and diagram in step
The analyses are written from the diagram, so they follow it. Insert a step, and the step appears in the analyses with its own entry. Move a step into a different lane, and the SOP names the new role. Split a gateway into two decisions, and the compliance analysis asks about both. You do not keep a second document in step; there is no second document.
What changes automatically, what never does
What patchley wrote, it may rewrite when the diagram changes, and it shows the proposed change before it lands. What you wrote or corrected by hand is kept. A sentence you added to a pain point, a standard reference you corrected, a figure you entered: all of that stays through every later change to the diagram, and every version remains available, so you can see what the analysis said before.
The diagram is the source. Analyses follow it; hand-written text stays; every change is shown before it is applied; every version stays.
The deck
From documentation to a deck for the steering committee
The last stage usually eats the evenings before a steering committee: the process map on one slide, the findings per step on the next ten, the control steps in a table, all retyped from the document. patchley builds the deck from the diagram and the analyses.
In your organisation's look
The deck uses your organisation's layout, so the process map and the findings arrive in the slides your steering committee already knows.
A real PowerPoint file
Text, tables and the diagram are editable in PowerPoint. What you see in the slide is what you can change, in the tool your organisation already uses.
Edits in the deck editor are kept
Change the diagram or an analysis, refill the deck, and the slides update. What you changed in patchley's deck editor is kept; in PowerPoint, text, tables, chart and diagram stay editable.
One diagram, several decks
A compliance deck for internal audit and an improvement deck for the department can come from the same diagram, with different analyses selected for each.
The landscape
From several diagrams to a process landscape
Landscape
Several diagrams as one picture: which processes exist and how they connect.
Process
One BPMN 2.0 diagram: lanes, steps, gateways, systems, documents, control steps.
Step
The analyses: SOP, pain points, compliance, figures or your template.
One diagram is one process. Once you have captured several, patchley puts them into a process landscape: the claims process, its subprocesses and the processes next to it as one picture rather than a folder of files. For documentation that means the landscape is the entry page, each process is a chapter and each step is a paragraph, and all three levels come from the same source.
That structure also answers the question that stalls many documentation projects: where to start. Capture the process that hurts most, document it per step, and let the landscape grow around it as the next processes are captured. The documentation never has to be complete to be useful; it only has to be current for the processes it covers.
FAQ
Frequently asked questions
What people ask when they compare this with the documentation they have today.
Can I use my own documentation template?
Yes. Give patchley the fields and headings your organisation uses for process descriptions, and the analysis is written per step in that structure, alongside or instead of the built-in lenses.
What happens to my edits when the diagram changes?
They stay. patchley may propose to rewrite what it wrote itself, and shows the proposal before it lands; what you wrote or corrected by hand is never overwritten. Every version remains available.
Which export formats are available?
The diagram as BPMN 2.0 XML, which opens in standard BPMN tools such as Camunda Modeler, Signavio or ADONIS, or as SVG and PNG; the analyses as XLSX; the deck as PowerPoint.
How does the process get into patchley in the first place?
Through an interview, a workshop, a meeting that patchley joins, or a document. The process capture page describes the four sources and the path from the first draft to sign-off.