Mapping the Work Before You Change It

Every organisation has a process document, and the work does not follow it.

This is not a failure of discipline. Documents describe the intended path, and real work contains exceptions, informal shortcuts, undocumented handoffs, and steps that exist because of something that happened three years ago. The gap is largest in exactly the processes people most want to automate, because complexity is what made them slow.

So the first work is observation rather than design. Sit with the people doing the task. Follow individual items through end to end. Ask why at each step and record the answers, because a step whose reason nobody remembers is either removable or load-bearing in a way you need to discover before removing it.

Two specific things to look for.

The unofficial steps. The spreadsheet someone maintains, the message they send to check something, the second system they cross-reference. These rarely appear in documentation and frequently carry the process.

And the exception paths. The documented flow describes the common case; the time is often spent elsewhere. If thirty percent of items take a different route, a redesign optimising the other seventy percent will disappoint.

Mapping badly is the most common reason a redesign fails to deliver, and it is entirely preventable.

The unit of analysis is the task, not the role and not the process. This follows from the same reasoning as the managing-teams cursus: AI reaches tasks unevenly, so any analysis at a coarser grain averages away the thing you need to see.

A usable decomposition names, for each step: what is produced, what input it requires, who does it, roughly how long it takes, and what happens if it is done wrong.

Three distinctions matter more than the rest.

Judgement versus production. Producing a document, extracting figures and formatting a report are production. Deciding whether to approve, choosing between options and handling an unhappy customer are judgement. AI reaches the first far more than the second.

Deterministic versus contextual. Steps following a rule differ from steps requiring knowledge of this customer, this history, this exception. Contextual steps resist automation and are where institutional knowledge lives.

And value-adding versus compensating. Some steps produce the outcome. Others exist to compensate for a limitation elsewhere: a check that exists because an upstream system is unreliable, a reconciliation that exists because two systems disagree. Compensating steps are the richest target, because removing the limitation removes the step entirely rather than merely speeding it up.

That third distinction is the one people skip, and it is where the largest gains sit.

The most common measurement error is recording how long each step takes and adding them up.

Touch time is the time someone is actively working on an item. Elapsed time is how long the item takes to get through the process. In most office processes the second is many times the first, and the difference is waiting.

Items wait in queues for someone available. They wait for a batch to fill. They wait for approval from a person with other priorities. They wait because a handoff crossed a team boundary and nobody owns the item in between.

This matters enormously for AI, because AI reduces touch time and does nothing about waiting. Automating a step that takes twenty minutes of touch time inside a process with a five-day elapsed time improves the elapsed time by almost nothing, and the improvement is invisible to a customer.

So measure both. For a sample of real items, record when each step started and finished, not just its duration. The gaps are the finding.

A useful ratio: touch time divided by elapsed time. Where it is very low, the process is dominated by waiting and the redesign should attack queues, handoffs and batching before it attacks any individual step. Teams that skip this measurement automate the wrong thing with real conviction.

A process has one step that governs its throughput. Improving anything else changes nothing measurable, which is the single most useful idea in operations and the one most often ignored when a new tool arrives.

The constraint is identifiable by observation. Work piles up in front of it. The people at it are always busy while others have slack. Expediting means going and asking them personally.

The sequence that follows is well established. Identify the constraint. Get everything possible out of it, by removing work from it that does not need to be there. Subordinate the rest of the process to it, so upstream steps do not flood it. Then invest in expanding it. And when it moves, start again, because relieving one constraint always creates another somewhere.

The application to AI is direct and frequently missed. Applying AI upstream of the constraint increases the queue in front of it and improves nothing. That is precisely the review-bottleneck pattern from the managing-teams cursus, arriving here as a general law rather than a special case.

For each step, the question is not can this be automated but why does this exist. The answers sort into categories with different treatments.

It produces the outcome. Genuine value-adding work. Automate or improve it, but it stays.

It compensates for an upstream defect. A quality check catching errors from a bad form, a reconciliation because two systems disagree. Fix the upstream cause and the step vanishes. Automating it instead makes a permanent fixture of a workaround.

It exists for control. An approval, a second signature, a review. Ask what it actually catches. Where the answer is nothing in living memory, it is ritual. Where it catches real problems, it is a genuine control and its position matters.

It exists because of a system limitation. Rekeying between systems that do not integrate, exporting to a spreadsheet because a report is inflexible. These are integration problems that AI can paper over, which is sometimes the pragmatic answer and always worth naming as a workaround rather than a design.

And nobody knows. Common, and it needs care. Some are genuine vestiges; some encode a lesson from an incident nobody present remembers. Ask the longest-serving person before removing one.

The second and fourth categories together often account for a surprising share of the steps, and both dissolve rather than needing automation.

Whatever you change, someone will later ask whether it worked. That question is answerable only if you measured beforehand, and the measurement takes a fortnight rather than a quarter.

What to capture, for a sample of real items over a period long enough to include a normal range of variation.

Elapsed time end to end, with the distribution rather than the average. Averages hide the tail, and the tail is usually where customer complaints come from.

Touch time by step, so you know where the effort sits.

Volume and mix, including what proportion take the exception path.

Quality: rework rate, error rate, and defects found downstream. This is the counterweight, and omitting it is how a redesign reports success while degrading the outcome.

Cost per item, including labour and any system costs.

And queue lengths at each step, which is what reveals the constraint.

Two cautions. Measure the current process as it actually runs, not as it should run, or your comparison is against a fiction. And record the variation, not only the central value, because a redesign that improves the average while widening the spread has made the process harder to run even though the headline number moved the right way.

This baseline is the same artefact the AI QA cursus builds for a model, applied to a process.

An insurance claims intake process, mapped to the point where the redesign becomes obvious.

STEP                       TOUCH   ELAPSED  TYPE          WHY IT EXISTS

1 Claim arrives by email   -       -        -             -
2 Log into claims system   8 min   4 hrs    production    value-adding
3 Chase missing documents  5 min   3 days   production    upstream defect:
                                                          form is unclear
4 Verify policy coverage   12 min  6 hrs    judgement     value-adding
5 Reconcile with finance   20 min  1 day    production    system limitation:
                                                          two systems disagree
6 Senior approval          6 min   2 days   control       CONSTRAINT
7 Notify claimant          3 min   2 hrs    production    value-adding

TOTAL                      54 min  ~7 days

Read the ratio first. Fifty-four minutes of touch time inside seven days elapsed, so this process is roughly ninety-nine percent waiting. Any intervention aimed at the fifty-four minutes is aimed at one percent of the problem.

Then read the why column. Step 3 is three days of waiting caused by an unclear form. Step 5 is a day caused by two systems disagreeing. Neither needs AI; both need the upstream cause fixed.

And step 6 is the constraint, two days waiting on a senior. Applying AI to steps 2 and 4, the obvious candidates, sends work to that queue faster and changes the total by nothing.

A completed map answers four questions, and the answers determine whether AI is the right intervention at all.

Is this process dominated by touch time or by waiting? If waiting, the redesign is about queues, handoffs and batching, and AI is at best a secondary lever.

Where is the constraint, and is it a person, an approval, a system, or an external dependency? Everything else is subordinate to it.

What proportion of steps are compensating rather than value-adding? A high proportion means the largest gains come from fixing upstream causes, which is unglamorous and usually cheaper than automation.

And which steps are judgement rather than production? Those set the floor on how much can be automated at all.

The uncomfortable outcome, which happens often enough to expect: the map shows that AI is not the highest-value change available. A clearer form, a fixed integration, or a redistributed approval authority would do more.

That is a good result rather than a failed analysis, and reporting it honestly is what makes the next analysis trusted. A team that only ever concludes that AI is the answer is not analysing.

With the map done, the next lesson covers what to actually change.