How to create a process documentation system
How to build a process documentation system that is still true in two years: a process inventory with named owners, review intervals set from the rate of change, and a dated defect for every lagging map.
A worked example, stage by stage
An owner before an analysis
The trigger is a calendar date or an event, and the row after it confirms the accountable owner before anything is read. "Change to the policy required?" then treats "No change" as a real ending: "Review recorded, new date set" is what keeps a register honest about a document's age.
Consultation is not a courtesy
Drafting in tracked changes, then the affected business areas, then legal and regulatory fit. "Employee consultation required?" routes to the representatives, and "Not agreed" ends at "Referred to formal negotiation" — an ending outside the library's control, drawn rather than assumed.
Tiering keeps the board free
"Which approval tier applies?" splits three ways into the board, the executive committee and the policy committee, and all three converge on "Approval decision?". Its "Redraft" exit points back at the drafting row; "Rejected" shelves the revision and leaves the previous version in force.
Publication writes back to the register
The register is written from two rows: "Publish the new version and announce it" and "Supersede and archive the old version". The new revision, the publication date and the next review date all come from them. A publishing step that writes back to nothing leaves a register ageing on its own.
The obligations after publishing
A materiality decision routes training, attestation is recorded against the affected staff, and "Refresh the exception and waiver register" catches waivers granted against clauses that no longer exist. The system ends at "Revised policy in force" rather than at publication.
How it works
Write the process inventory before any map
List every process the organisation runs, one line each, with a named person accountable for its description, the level it should be documented at, and how critical it is. Expect the list to be shorter than feared and the ownership column to be the argument. Nothing else can be built while that column has gaps.
Set each review interval from the rate of change
Take the interval from how often the process actually moved over the last two years rather than from a policy default: three changes earns six months, no change in five years earns two. Record the interval, the next due date and the documented level in the inventory, so none of the three is re-argued at every revision.
Build the meta-process as a chart first
Before documenting any real process, put your own documentation route into rows: what triggers a review, who confirms the owner, who is consulted, who approves, how it is published and trained. Type the stages into the Box text column and join them by row number in the Line to column. Every later document inherits from it.
Put the approval tier on the chart as a decision
The routing row takes Decision in the Shape column, with the tiers written into Line text against the numbers in Line to, so a revision's route is known before drafting starts. Use the Horizontal lane column for the phase and the Vertical lane column for the owner, so the diagram shows that a policy office and an approval body differ.
Draw the redraft loop as a backward number
An approval that sends work back is a row number pointing at an earlier row, not an arrow somebody adds to the drawing afterwards. Because the Line to column holds data, that loop survives inserting a step above it. A diagram showing only forward motion describes an approval body that has never once disagreed.
Audit the library against its own dates
Each quarter count four figures: documents past their review date, documents with no named owner, documents whose process changed before its map did, and reviews recorded with no change. The last is health. Book the next count in the inventory before closing this one, because a count with no next date lapses and the library resumes decaying.
Frequently asked questions
What is a process documentation system?
It is the set of rules and roles that keeps a body of process documentation true, as distinct from the documents themselves: an inventory with one named owner per process, the level each is documented at, a review interval whose due dates reach those owners, a measured rate at which the library falls behind the work, and a route for creating, approving, publishing and retiring a document. The template matters least. The test is what the register says about a document nobody has touched for three years.
What should a process inventory contain?
One line per process: the process name, the owner as a person rather than a team, the level it is documented at, its criticality, the location of the current version, and the dates it was last reviewed and is next due. Two further columns earn their keep quickly — the systems the process runs in, which tells you what a migration will invalidate, and the clause it exists to satisfy, which tells you what an auditor will ask to see. The inventory comes first because every later decision is a query against it.
Who should own a process documentation system?
One person, and not the person who owns the most documents. The system owner holds the inventory, the meta-process and the register of review dates; each document owner holds content. Merging the two produces the familiar failure where every revision queues behind the one individual who understands the system, and the queue gets reported as a resourcing problem rather than a design one. Half a day a week carries a library of fifty processes, provided the reminders are automatic and every owner is a name.
Where should process documentation live?
Wherever the inventory says, which is why location is a column in it, not a decision taken once for the whole library. A quality management system, a wiki and a shared drive can each hold a current version; none of them can tell you which processes have no current version at all. So the test is not which platform but whether every row in the register names the place its readers are sent, and whether arriving there produces the revision the register claims. A process with no row is invisible to any platform choice.