Turning a Folder of Files Into a Map You Can Look At

To turn documents into a process map you extract four things from each file and discard the rest: the steps in order, the role that owns each one, the systems each one touches, and the point where the work leaves one person and arrives with another. Everything else in a procedure document is context, justification or formatting, and none of it survives the translation into a map.

That reduction is the whole technique. Most of the difficulty is being willing to throw away ninety per cent of a document somebody spent a week writing.

Why a folder was never the right shape

A folder holds documents in isolation. Each one describes its own process from its own starting point, which means the thing you most want to see, how they connect, is exactly what the format cannot show.

Read fifteen procedures one after another and you will finish knowing fifteen processes and nothing about the business. The handoffs are invisible, because each document ends where its author's responsibility ended. The duplication is invisible, because two teams describing the same activity in different vocabulary look like two different activities. And the gaps are invisible, because a gap between two documents does not appear in either of them.

A map has one property a folder does not: everything is on it at the same time, so adjacency becomes visible. That is the entire reason to do the conversion.

The four things to pull out

Steps, as verbs. "Finance approves the invoice", not "invoice approval process". Verbs force you to name who does what, and the moment you cannot name the actor you have found a step that needs a question rather than a box.

Roles, never names. The document may say Priya. The map should say the operations lead. Roles survive resignations and names do not, and a map keyed to individuals has to be rebuilt every time someone leaves.

Systems, as they are actually called. If the document says CRM and everyone in the building says HubSpot, write HubSpot. The value of the systems layer is that duplicates become obvious, and duplicates only become obvious when the labels match reality.

Handoffs, marked explicitly. Any point where the work changes hands. These are worth marking differently from steps, because almost all delay and nearly all dropped work happens at a handoff rather than inside one.

What to throw away

The purpose section. Every SOP opens with why the process exists, and it never helps. It is policy, and policy belongs somewhere else.

Screenshots. They date within a release, and a map carrying three obsolete screenshots gets distrusted entirely.

Anything conditional on approval thresholds, at first pass. "Over five hundred pounds requires director sign-off" is real and important and it will double the size of your map if you branch on it early. Get the main line drawn, then add the branches that fire often.

The revision history. It tells you when the document changed, which is not the same as when the process changed, and it invites false confidence about currency.

What you will not find, and have to ask for

Three things are absent from every document, and if you do not go and get them the map will look complete and be hollow.

Duration. Documents record actions, not the gaps between them. A six-step procedure can take nine days and the nine days are the thing worth fixing.

Frequency. A document describes a process once, and never says whether it runs four hundred times a month or twice a year. Without frequency you cannot rank anything, and an unranked map is a picture rather than a plan.

The exception path. Procedures describe the run where nothing goes wrong, because that is the easy version to write. In plenty of processes the failure branches carry a third of the volume.

So the document gets you a skeleton and the questions get you the flesh. Reading your SOPs into the same model that the interviews build is what abi. Clone is for, so the documented version and the real one sit on one picture instead of in two places you have to compare from memory. Building the map by hand is free on any account, with no card, and a first pass takes minutes.

Do them in the right order

Not alphabetically, and not by which file you found first.

Start with the process that generates revenue, end to end, across every department it touches. That single chain usually crosses four or five documents and it is the one where a missing handoff costs money weekly.

Then the process that generates the most support load. Then anything with a single point of failure attached, meaning a step only one person can perform.

Everything else can wait, possibly forever. A map does not need to be complete to be useful, and the attempt to make it complete is the most common way these projects stall.

The concession worth making

If your folder is small, this is not worth systematising. Fifteen documents can be read and drawn on a whiteboard in an afternoon by one person who knows the business, and the whiteboard photo, kept current, will beat any map you abandon.

The conversion is worth doing when the volume is past what one person can hold, which in practice means somewhere upward of forty documents or twenty-five people. Below that you are building infrastructure for a problem you do not have.

And there is a harder concession. A map built purely from documents is a map of the official business. It will be tidy, coherent and wrong in the specific way that all official accounts are wrong: no waiting, no workarounds, no rework. If you stop at the conversion you have made the folder easier to read without making it truer.

What to do the day after

Print the map and take it to four people who do the work on it.

Ask them to mark what is missing rather than what is incorrect. People are much better at spotting an absent step than at auditing a diagram, and absence is the dominant error.

You will get marks on the handoffs first, which is the expected result and a sign the exercise is working. The seams between departments are where documents stop and where the business actually lives.