Process mapping

Process mapping is the discipline of making the path of work visible from trigger to output. It shows activities, roles, handoffs, decision points, queues, rework loops and exceptions. In an SME, its value is not the diagram itself. Its value is the shared evidence it creates before people decide what to change.

In brief

A process map turns a vague operating problem into a visible flow. Instead of saying “quotes are slow” or “production is disorganised”, the company can see where work starts, where it waits, who touches it, where it returns and which decision controls the next step.

A useful map is not a decorative deliverable. It is a working object. It lets different roles discuss the same sequence and identify the point where intervention is most likely to matter.

Operational definition

A process map describes a flow with a defined trigger, sequence, roles, decision points and output.

A good SME process map usually includes five layers.

The first layer is the activity sequence: what happens first, next and last.

The second is role ownership: who performs each activity and who answers for it.

The third is handoffs: where work moves from one role, team or system to another.

The fourth is timing: where work is active, where it waits and where it returns.

The fifth is exception logic: what happens when the standard path does not fit the case.

The format does not need to be complex. A swimlane map is often enough: one lane per role, activities in order, arrows for handoffs, markers for waits and loops.

Why it matters for SMEs

SMEs often coordinate through direct contact, memory and informal correction. That works at small scale. As the company grows, the same informality hides friction.

A process map makes the flow transferable. It reduces dependence on the founder or on a few experienced people. It helps new hires understand not only what they do but where their work enters and exits the system.

It also changes the quality of internal discussion. Without a map, each role argues from its local experience. With a map, disagreement becomes visible: two roles may see the same handoff differently, or one role may assume a decision exists while another never receives it.

For investors or buyers, process maps are evidence of operating maturity. They show whether the company can explain how results are produced without relying entirely on tacit knowledge.

Observable signals

Process mapping is needed when people describe the same flow differently.

It is needed when work repeatedly waits at the same handoff.

It is needed when a private spreadsheet or chat thread is used to track work outside the official system.

It is needed when rework occurs but nobody can say where the error was created.

It is needed before software implementation, because software will encode a process whether the company has chosen it or not.

Common mistakes

The first mistake is mapping the process in a meeting from memory. This usually produces the nominal process, not the real one.

The second mistake is making the perimeter too wide. “The commercial process” is often too large. “From customer request to quote sent” is a better first map.

The third mistake is mapping only activities and ignoring waits. In SMEs, lead time is often dominated by waiting, not working.

The fourth mistake is hiding exceptions. Exceptions are not noise when they recur. They are part of the real process.

The fifth mistake is stopping at the map. A map without a decision is documentation, not diagnosis.

Operational example

A technical services company complains that quotes are slow. Management believes the issue is lack of sales discipline.

A process map of 12 recent quotes shows a different pattern. Sales collects the request quickly. The quote waits for technical validation. Technical validation often returns the request because one site datum is missing. The file then waits again for the founder’s price approval.

The map shows that sales speed is not the main constraint. The real issues are input quality, technical handoff and founder approval.

The first intervention is not a CRM. It is a required intake field, a technical validation owner and two fixed approval slots per week. Lead time falls before any tool is changed.

Diagnostic questions

What event triggers the flow?

What is the output, and who uses it?

Which roles touch the work, and in what order?

Where does work wait?

Where does it return to a previous step?

Which decisions change the route?

Which exceptions occur often enough to be drawn on the map?

Practical implications

Start with one narrow flow and 10 to 20 real cases. Use operational traces: emails, timestamps, file versions, forms, order status. Interview people separately before validating together.

Mark waits, returns and handoffs visibly. Distinguish cycle time from lead time. Then choose one intervention with an owner and a date.

The map should become the basis for RACI, bottleneck analysis, rework reduction, ERP readiness and SOP writing. It is the common evidence layer.

MARTRO reading

In MARTRO’s reading, process mapping is the first act of operational legibility. It converts a hidden flow into a diagnostic surface.

The map does not only show sequence. It reveals organisational conditions: role gaps, decision latency, hidden dependency, fragile handoffs and premature digitisation. This is why MARTRO treats mapping as an entry point into structure, not as a drawing exercise.

When to go deeper

Go deeper when the same problem repeats, when roles disagree on how the flow works, when software is being considered, or when an investor or buyer will need to verify how the company produces results.

Natural next steps are nominal process vs real process, bottleneck, rework and RACI.

Frequently asked questions

Do we need BPMN to map processes? Not for a first diagnostic pass. A swimlane map is usually enough. Formal notation can come later if the process must be automated or audited.

How many cases should we map? Ten to twenty recent completed cases often reveal the pattern. More may be needed for highly variable flows.

Should the founder lead the mapping? The founder can sponsor it, but should not be the only source. Separate interviews with people who perform the work improve accuracy.

What is the difference between process mapping and SOP writing? Mapping shows the flow. An SOP standardises a recurring activity inside that flow.

When is the map finished? When it is recognised as true by the people doing the work and has led to at least one decision.