How to map a process

This guide helps an SME produce, in one or two weeks of light work, a shared picture of how a work flow really happens — not how it is supposed to happen. It is a lean version of process mapping and value stream mapping, reduced to what matters for decision-making: triggers, activities, handoffs, waiting time, rework and the next intervention.

What this guide is for

The goal is not to create a beautiful diagram. The goal is to make a real flow legible enough that people can agree where the friction is and decide one useful intervention.

A process map is valuable when it represents work as it actually happens. In SMEs this often differs from the official description. The map should therefore be built from real cases, not from memory, hierarchy or aspiration.

When to use it

Use this guide when a problem repeats: delays, rework, errors, duplicated entry, unclear ownership or decisions that always wait in the same place.

Use it when different people give different versions of the same flow.

Use it before a decision that will harden the current way of working: buying an ERP or CRM, hiring “to fix the bottleneck”, reorganising roles, or changing incentives.

It is also useful before due diligence. A company that arrives with mapped flows shifts the conversation from “trust us” to “verify this”.

Before starting

Choose a narrow perimeter and a concrete problem. Do not start with “the sales process”. Start with “from customer request to quote sent” or “from confirmed order to release to production”.

Identify the three to five people who touch the flow. Collect recent, completed real cases: orders, quotes, tickets, files, complaints. The map is built on instances, not opinions.

Keep one methodological warning visible: you are mapping the real process. Everyone, including the founder, will be tempted to map the nominal process. The steps below exist to prevent that.

Operational sequence

Step 1 — Reconstruct 10 to 15 real cases.

Take recent completed instances of the flow. For each one, record dates, steps, people involved, returns, waiting points and versions. Use existing traces: emails, timestamps, file versions, order status, CRM notes, calendar entries.

This is the domestic version of execution-trace reconstruction. It follows the same principle as process mining, but without the software.

Step 2 — Interview the people who execute, separately.

Spend around 30 minutes with each person. Use one guiding question: “Tell me the last case you handled, step by step.”

Do not ask “how does the process work?” That question activates the official version. A specific recent case activates episodic memory, which is much closer to the real flow.

Step 3 — Draw the flow as it is.

Use one lane per actor or role, with activities in sequence and arrows for handoffs. This is the basic swimlane format. Its strength is that it exposes handoffs, where much of the time is usually lost.

Paper, whiteboard or a shared digital board are enough. Include exceptions that appeared in the interviews. Exceptions are often not marginal; in SMEs they may represent a large share of real work.

Step 4 — Mark waits, returns and duplicate work.

On the map, mark where work waits, where it goes backward and where it is done twice. In lean language these correspond to waiting, rework and overprocessing.

Quantify when possible using the cases from Step 1. “Average 2.3 loops between technical office and sales” is more useful than “too many steps”. The number makes the friction discussable.

Step 5 — Separate working time from lead time.

For each case, distinguish the actual time spent working from the calendar time elapsed. The first is cycle time. The second is lead time.

In SMEs this distinction often changes the diagnosis. People may spend four hours of actual work on a quote that takes nine days to reach the customer. The problem is rarely personal speed. It is where the work lies still.

Step 6 — Validate the map in a one-hour group session.

Put the map in front of the people interviewed. The question is not “do you like it?” but “is this how it happens?”

Corrections in this session are valuable. If two roles describe the same step differently, that is not a meeting problem. It is data. It may indicate a role gap, unclear handoff or unspoken decision rule.

Step 7 — Decide one intervention.

From the validated map, select one friction point with the best ratio between impact and effort. Define who does what by when.

Resist the temptation to redesign everything. Constraint logic is brutal but useful: a flow is limited by one point at a time. Improving elsewhere may waste effort. The map exists to choose the point, not to refound the company.

Expected output

The exercise should produce three outputs.

First, a one-page map that the people doing the work recognise as true.

Second, a list of friction points with at least one observable number for each: waiting days, loops, duplicate entries, missing inputs, unresolved approvals.

Third, one intervention decision with an owner and a deadline.

If one of these three is missing, the exercise is not complete. A map without a decision is decoration.

Mistakes to avoid

Do not map the official version instead of the real version.

Do not widen the scope halfway through the work.

Do not turn the map into an aesthetic deliverable that nobody uses.

Do not skip group validation by trusting one person’s synthesis.

Do not stop at the map. Diagnosis is not treatment. The map must lead to a decision.

Example

A 12-person technical studio complained about slow quotes and was considering quotation software. Mapping 12 real quotes showed that cycle time was around four hours, but lead time was nine days.

The waiting time concentrated in one step: founder approval. Approval happened “when there was a moment”. Moving approval into two fixed weekly slots cut response time to the customer by half.

The cost of the intervention was zero. The software decision was reconsidered six months later, on a process that was now legible. The system was chosen better and configured faster because the company knew what the flow actually required.

MARTRO connection

In the MARTRO sequence, process mapping is the first diagnostic act. It creates the legibility on which later interventions rest: RACI, bottleneck analysis, decision rights, stop rules, WIP limits and digital tools.

It also produces a benefit that founders often underestimate and investors do not: a company that can show its flows has already demonstrated that it can observe itself. That capability is the basis for many others.

Next step

If the map shows one point limiting the whole flow, continue with the guide on how to identify a bottleneck.

If the problem is who decides what, continue with RACI and decision rights.

If the map reveals disagreement between roles, continue with role gap and triangulation.

Frequently asked questions

How detailed should the map be? Detailed enough to identify handoffs, waits, rework and decisions. If the map cannot support a decision, it is too vague. If it includes every micro-action, it is too detailed.

Do we need BPMN or a formal notation? Not at the beginning. A swimlane map is usually enough for an SME diagnostic pass. Formal notation becomes useful when the process must be automated, audited or scaled.

Who should facilitate the mapping? Someone who can stay neutral and follow evidence. If the founder facilitates, people may describe the version the founder expects. For sensitive flows, an external facilitator or independent analyst improves the quality of the evidence.

How many cases should we analyse? Ten to fifteen recent completed cases are often enough to reveal patterns. If the flow is highly variable, increase the sample, but do not turn the first mapping into a research project.

What should happen after the map? One decision. The map is successful only if it changes what the company does next.