How do you map a process when nothing is documented?

The usual answer, and why it does not scale

The standard method is to interview people and draw what they describe. It works, and for one important process it is hard to beat.

It stops working at volume. Each process costs several hours of a subject matter expert's time plus the analyst's, the output is only as good as what someone remembered in a meeting, and by the time the twentieth process is drawn the first is out of date. Organisations that try to interview their way through a few hundred processes usually stop somewhere around thirty, and what they produced is stale before it is used.

The other failure is subtler. People describe the process as it is supposed to work, not as they actually do it, and they do so honestly. The workarounds are so routine that they no longer register as departures.

Start from what already exists

Before interviewing anyone, gather the material that describes the work. In most organisations this is more than people expect, because it was written for other reasons.

• Onboarding and training material, which describes the job as someone was last taught to do it.
• Runbooks, checklists and desk instructions, including the ones that live in a personal folder rather than the official library.
• Wiki and intranet pages, which often carry the reason a step exists even when they are wrong about the step.
• Meeting recordings and transcripts, where the exceptions get discussed because they are what people talk about.
• Policies, contracts and standards, which connect a step to the obligation behind it.
• Tickets and email threads about the process going wrong, which show you the paths nobody documents.

Then record one run

Reading the material gets you a draft that is confident in the wrong places. The cheapest correction is to watch the job done once.

One consented recording of a person performing the task settles most of what the documents leave ambiguous: the order of steps, the systems actually touched, the field that always has to be corrected, the spreadsheet between two systems that nobody mentioned because it is not officially part of the process.

Consent matters here and is not a formality. The version that works is session based: the person doing the work chooses to start the recording, knows what is captured, and sees the result. Continuous background monitoring of staff is a different practice with different obligations, and treating them as the same thing is how these programmes lose the goodwill they depend on.

Reconcile, and treat the gaps as findings

Now compare the two. The document says a check happens; the recording shows it skipped. The document lists four approvers; the recording shows one. The recording shows a step the document never mentions.

The instinct is to correct the map to match the recording and move on. That throws away the most valuable output of the exercise. Each gap is a question with a real answer behind it: the check is skipped because it duplicates a later one, the approvers were reduced after an incident and nobody updated the page, the undocumented step exists to work around a system that cannot do something it should.

Record the gaps as findings alongside the map. They are what makes the map worth having, and they are the shortlist for the work that follows.

Show it back before you trust it

A map nobody has challenged is a draft. Put it in front of the people who do the work and ask a specific question rather than whether it looks right, because everything looks right at a glance.

Better questions: where does this go wrong most often? What happens when the input is incomplete? Who do you go to when it is stuck? What did you have to do last week that this does not show? Each of these surfaces a path the map is missing.

Then decide what the map is for. A map kept for its own sake decays quietly. One attached to a decision, a control, or a change being designed gets corrected because someone depends on it.

Doing this at the scale of an organisation

The method above works with a document folder, a screen recording and a text editor, and for a handful of processes that is a reasonable way to run it.

The reason it is rarely done at scale is arithmetic rather than disagreement. Reading everything relevant to four hundred processes, reconciling each against a recording, and keeping the result current is more reading than a team can do, so the ambition shrinks to the thirty processes someone can interview their way through.

That arithmetic is what Omni is for: the model is generated from the documents, transcripts and wiki pages, then checked against the recorded run, so the reading is not the constraint. The method does not change. What changes is how many processes you can afford to apply it to.