Process mapping: understand how the work really happens

Start with the work people really do

A procedure may say that an employee records every order in one system. In practice, the employee may keep another list because a required detail has no field. Or a question may be answered by telephone even though the official instructions specify email. These workarounds do not automatically mean that the people involved are doing something wrong. They can reveal where the prescribed path fails to support the work. Write down the official version and the observed version separately. If you quietly replace what happened with what ought to have happened, you will be mapping a future wish rather than the current process. Ask the people performing the work what they need at each handover, and watch an actual case where it is appropriate and permitted.

A fictional manufacturer's order

Imagine a manufacturing business with twenty employees that wants to digitise order handling. Before selecting software, the team examines a few suitable orders. Who first enters the request? Which details are missing when production receives it? When does somebody have to call back, and which version of a drawing is approved? In a hypothetical example, an approval may take place over the phone while the production team later has no reliable record of the agreed version. Looking closely might also reveal individual steps that can be removed or organised differently, whatever system is eventually chosen. This is an invented case, not a claim about a real customer or a guaranteed saving. Its point is to show why a choice of software should follow a clearer account of the actual work.

Choose a boundary before drawing the map

Pick one repeatable situation instead of attempting to capture the entire company. The order process might start when a confirmed request arrives and end when production receives an accepted specification. If important corrections occur immediately after that point, you may need a wider boundary. Record what is outside your map and who needs to use its result. Sales, production and the customer may regard a completed handover differently. A workflow for complaints may form part of the same process or deserve a separate map; choose according to the decision you are trying to make. APQC recommends clarifying purpose, participants, inputs, outputs and boundaries before developing a detailed representation. A map that covers everything is often too unwieldy to answer one practical question.

Follow information and responsibility through handovers

At each important step, note the input, the action, the decision and the output that the next person actually receives. Which document is the agreed version? Where is it stored, and how does the next person know it is ready? A document may exist but still be impossible to identify as authoritative. Ask who can decide when information conflicts, rather than assuming that the person passing on the file owns that decision. If you have observed waiting time, record the duration and the case; if somebody estimates it from memory, label it as an estimate. Include returns and exceptions without forcing them into a tidy line. An initial sketch on paper or in a table is often enough to make these points visible. The format is less important than a description the participants recognise.

Keep observations separate from explanations

“The approved drawing was absent at two handovers” can be an observation if those events were checked. “The team is careless” is an interpretation; “we need a new platform” is a possible solution. Those statements should not occupy the same box on a map without a clear distinction. Perhaps the file was in the wrong folder, perhaps it changed after approval, or perhaps nobody knew who was authorised to release it. Look at actual orders before deciding which explanation fits. A single exceptional order is not proof that every handover fails. Compare a smooth handover with the troublesome ones: what was different about the input and who was involved? Keep contradictory evidence beside the initial theory. ROTER FADEN's broader method is useful here because it allows a thought to remain unresolved.

A small mapping card you can use immediately

Write one question at the top, such as “Why does production sometimes lack the approved specification?” Use the same short card for two or three appropriate orders. Mark whether an entry was observed, copied from a record or inferred from someone's recollection. If two people describe a step differently, keep both descriptions until you understand the difference. This is a working aid, not an industry standard or a substitute for formal requirements in a regulated process. The card should be easy to discuss with someone involved, without telling them in advance which answer you would prefer. If a field does not help your question, leave it out rather than creating paperwork for its own sake.

• Trigger and end: what starts this case, and when is its result usable by the next person?
• Step and owner: what actually happens, who performs it, and who decides on exceptions?
• Input and output: what information is needed, what is passed along and which version counts?
• Evidence and question: what did you check, what is only an assumption, and what should another case clarify?

Use the map without rushing into a solution

Compare the cards. Did questions recur at the same handover? Did a particular detail arrive too late, or was it available under a different name? One small trial might be to mark the approved drawing in an agreed location for a limited number of new orders and then check the next handover together. This could be process improvement, but it is not a universal prescription. Watch whether the change moves work elsewhere in the company. If the cause is still uncertain, continuing to observe can be a good result. When the need becomes clearer, turn it into requirements analysis and compare the benefits, cost and operational risks of digitisation. Avoid calling a software feature the requirement before you know which information people need to exchange.

Validate the picture and know when to update it

A process map is a snapshot. Different shifts, order types or seasonal peaks may follow different paths. State the period and kinds of cases you examined. Invite the people who do the work to correct the map, particularly across team boundaries. Agreement in a meeting is not the same as checking a further real case; do both when the decision matters. If roles or needs change, update the document or mark it as historical so it cannot be mistaken for current guidance. Process management may turn that review into ongoing work. For a one-off decision, a short map with openly stated limits may be more useful than a huge model. The outcome is a clearer question and a traceable account of what you saw, not an obligation to change anything immediately.