A process map is a set of decisions, not a set of boxes
Most process diagrams describe a sequence of activities with arrows between them, and agents built from those diagrams fail for the same reason. The diagram shows what is done, not what is decided, by whom, on what basis, or what happens when the basis does not apply. Those missing elements are the parts of the work the organisation has never formalised, and an agent will fill them with plausible guesses. Mapping makes them explicit enough that a business decision can be taken about each.
Name the roles that actually touch the work
A map that lists job titles misses the people who keep the process alive. The interesting roles are not in the organogram: the planner who keeps a spreadsheet of exceptions, the coordinator who interprets a customer request, the controller who cannot let a discount stand without a second signature. Map by role in the work, not by hierarchy.
Fix the inputs and the authority behind them
Every input needs three things recorded: what it is, where it comes from, and which source is authoritative when sources disagree. The third is the one that gets skipped and causes most downstream error, because in a fragmented business two systems routinely disagree and a person resolves the conflict using history that no record contains. Where the authority is genuinely undecided, write it down as an open decision with a named owner. It is a business choice, not a data project. The broader treatment of these shared definitions is in business ontology explained.
Isolate the decisions and their criteria
For each decision, write down the criteria a competent person would apply, and separate them into two piles. The first is decidable from data: a threshold, a rule, a match against a stated condition. The second requires context, relationship or experience: whether a customer is credible, whether an exception is reasonable, whether a claim is genuine. The first pile is what software and models can execute reliably. The second should stay with a person accountable for the outcome, at least until the organisation has evidence it can be specified. Where the second pile is larger, the answer is not a model but a rule set or a reallocation of the work. Both piles should be visible in the map, because the ratio between them tells you what kind of system the process can support.
Follow the handoffs and count the exceptions
A handoff is where information is transformed, and informal transformations are where errors are born. For each handoff, record what changes, what is dropped, and what the receiving person has to re-derive. Then count the exceptions: the cases that do not follow the routine path, who handles them, how long they take, and how they are recorded. Exception handling is where experienced people spend their time, and the least visible cost in the process.
Record the systems, the controls and the outputs
- Systems. Where each step runs, including the spreadsheets, shared drives and personal inboxes that are not on the architecture diagram but hold real records.
- Controls. What is checked, by whom or by what, and what happens when the check fails. A control that is really a person's memory should be labelled as one.
- Authority. Who may approve, on what threshold, and where the approval is recorded.
- Outputs. What the process produces for someone else, and what the next process assumes about it. Most integration defects are disagreements between what a process produces and what the next one expects.
The order in which the map gets built
Mapping is easier when the elements are gathered in the order the work moves, because each raises the questions that make the next meaningful.
- Name the role that performs the step and the role that approves it.
- Record the input, its origin and which source wins when two disagree.
- Write the decision criteria, and mark each as rule-based or judgement-based.
- Describe what changes at the handoff, and what the receiving role has to reconstruct.
- List the exception path, who handles it and where it is recorded.
- Note the system, the control and the authority threshold for each step.
- State the output and what the receiving process assumes about it.
- Have the process owner correct the result, and record the corrections.
The map is a deliverable, and it is bounded
The map has to be written down in a form the business can correct, and attached to the owner's name. A diagram left in the consultant's file is a record of a meeting. A map the process owner has edited is a shared description of the work, and the only document in which the organisation's real operating rules appear in writing.
A workable format is a structured document rather than a picture: a table of steps, and for each step the role, the input and its authority, the decision and whether it is rule-based or judgement, the system, the control, the exception path, the output, and the baseline measure the step will be judged against. It is dull, it is reviewable, and it later becomes the specification for the system.
For a single process handled by one team, mapping should take days rather than weeks, and the sign that it has gone wrong is a diagram with more than about fifteen boxes. For a chief operating officer who owns the outcome, the map is also the only artefact that shows which decisions the business has made, and which are still open. If the process turns out to be twenty steps, it is probably several processes described as one. A useful constraint is that the map must be complete enough for a new joiner to follow the routine path without asking a question. The map is a discovery activity, and the discipline it belongs to is described in the first thirty days of a forward-deployed engagement. The engineering that follows is described in our agent engineering practice.