Business processes: writing them, mapping them, keeping them alive

A process that only exists in one person's head is not a process, it is a dependency. This page describes how we write, map and control processes before automating anything.

Why start by writing

Writing a process almost always reveals two things. First, that the task contains implicit decisions nobody formalised, which explain why only one person knows how to do it. Second, that part of the work is useless and can simply disappear. Removing a step costs nothing and pays immediately: it is always the best automation available.

What a useful procedure looks like

A useful procedure fits on one page, reads in three minutes and lets someone who starts on Monday do the job right. It contains five elements and nothing else.

1. The trigger. What starts the process, stated without ambiguity.
2. The steps, in order, in the imperative, one action per line.
3. The special cases, kept apart from the normal path, or they drown it.
4. The expected result. How you know it is done, and done well.
5. Who to call when the situation falls outside the frame.

A twelve-page procedure will never be read. If it runs over a page, several processes are usually mixed in it.

Mapping without spending six months on it

Exhaustive mapping is a classic trap: six months of work, a beautiful document, and nothing changes in the company. The version that works maps only the flows that carry money or risk, and stops there.

List the five to seven main flows, for example: an incoming request becomes a customer, a service is delivered, an invoice is issued and paid. For each, note who is involved, which tools are used and where information is re-entered. The re-entry points are exactly where the system leaks.

Control without surveillance

Chasing people all day to know what is done is not a management problem, it is a system problem. When progress is visible without anyone having to ask, the chasing disappears on its own.

The principle fits in one sentence: make work visible at its source. A finished task is declared where it happens, once, and the information flows up by itself to those who need it. Control becomes a consequence of the system, not a full-time activity.

Keeping documentation alive

Documentation that is not updated becomes dangerous: it describes a reality that no longer exists and wastes more time than it saves. Three rules keep it alive: each process has a named owner, documentation lives where the work happens, and any change to the process ends with the document being updated straight away, not later.

Frequently asked questions

How do you document a business process?

On one page at most, with five elements: the trigger, the steps in order in the imperative, special cases kept apart from the normal path, the expected result and who to contact when things fall outside the frame. A longer procedure usually mixes several processes.

Should you map all your processes?

No. Exhaustive mapping takes months and changes nothing. Map the five to seven flows that carry money or risk, focusing on the points where information is re-entered by hand.

What is the difference between a process and a procedure?

The process is the sequence of steps that turns an input into a result. The procedure is the document explaining how to run it. The first exists even unwritten; the second is what makes it transferable.

How do you know a process is ready to automate?

If it can be written clearly, if its rules have not changed for six months, and if every step survives the three-question test: can it be removed, merged, or does it need human judgement. An unstable process produces an automation that needs constant repair.

How do you track team work without micromanaging?

Make work visible at its source: a task is declared finished where it happens, once, and the information flows up automatically. Tracking becomes a consequence of the system instead of a chasing activity.