Types of process maps. Six formats, and which one actually fits your process.

The short answer. Different questions need a different type of map.

I'm Lauren Pearson, and the most common mistake I see with process mapping is not a badly drawn map, it is the wrong type of map for the question being asked. A team wants to know who keeps dropping the ball on a handoff, and someone hands them a basic flowchart with no roles on it at all. A founder wants a five-minute overview to decide where to focus a quarter's effort, and gets a forty-step detailed map instead. The type of process map matters as much as the accuracy of what is drawn on it.

There are five formats worth knowing, plus the high-level versus detailed distinction that applies across all of them. None is inherently better than the others, and a business does not need to master all five to get value from process mapping. Each answers a different question, and picking the wrong one wastes the time spent mapping in the first place, either because the finished map does not show what the team actually needed to see, or because it is more formal and time-consuming than the process warranted, which is its own way of putting people off documentation altogether.

How it works in practice. The five formats, and the question each one answers.

The basic flowchart. Boxes and arrows showing the sequence of steps and decisions from trigger to outcome. It answers "what happens, and in what order", and it is the right starting point for most simple, single-owner processes. Our companion guide to how to create a process map covers the method for building one from scratch.

The swimlane or cross-functional diagram. The same sequence as a flowchart, split into horizontal or vertical lanes, one per role or department. It answers "who is responsible for each step", which makes it the right choice the moment a process regularly stalls at a handoff between people rather than inside any one person's part of the work.

The SIPOC diagram. Short for suppliers, inputs, process, outputs and customers, a SIPOC sits above the detailed map, listing the five to seven major process steps alongside what feeds in and what comes out. It answers "where does this process actually start and end, and who is involved", which is exactly the alignment question a team needs to settle before a detailed map, so nobody spends a workshop mapping the wrong boundaries.

The value stream map. Built on Lean manufacturing method from the Toyota Production System, a value stream map tracks the flow of materials, information and time from order to delivery, marking which steps add value for the customer and which do not. It answers "where is time and effort being wasted", and it earns its complexity on higher-volume, repeatable processes where shaving days off a cycle time has a real, measurable payoff.

BPMN. Business Process Model and Notation, a standardised symbol set maintained by the Object Management Group, built so a process map can be read directly by workflow and automation software, not just by people. It answers "can this process be handed to a system", and it is worth the learning curve only once a process is genuinely heading towards automation or system integration, not for a process a person will keep running by hand for the foreseeable future.

High-level versus detailed. A second dimension that cuts across every format above.

Alongside the five formats, every process map also sits somewhere on a second scale, from high-level to detailed, and this choice matters as much as the format itself. A high-level map, whatever format it uses, shows five to ten major steps and is built for someone deciding where to focus attention, a founder, an investor, a new department head trying to understand how the business runs. A detailed map breaks each of those major steps into every sub-step, decision, exception and handoff, and is built for the person actually doing the work day to day.

The two are not competing versions of the same map, they serve different readers, and the most usable process documentation I build with clients keeps both: a one-page high-level SIPOC or flowchart that anyone in the business can glance at and understand, sitting above a set of detailed maps for the handful of steps that genuinely need that depth. Detailing every step equally is rarely worth the effort it takes, since most processes have two or three steps where the real risk and complexity sit, and the rest is straightforward enough that a single summary line covers it.

What good looks like. Matching the type to the actual decision you need to make.

The decision rule I use with clients is to name the question first, then pick the format. If the question is "does everyone agree what this process even covers", start with a SIPOC. If it is "who keeps dropping this", go straight to a swimlane. If it is "where is this process slow", a value stream map, even a rough one, will show it faster than a conversation will. A basic flowchart is the right default when none of those specific questions apply and the goal is simply to get an accurate record of the steps on paper for the first time.

As a quick reference, five questions and their matching format: "does everyone even agree what this process covers" points to a SIPOC; "who keeps dropping this between teams" points to a swimlane; "where is time actually being lost" points to a value stream map; "can this be handed to a workflow tool" points to BPMN; and "I just need an accurate record of what happens" points to a basic flowchart. Most processes only ever need one or two of these, not all five, and building more formats than the process actually calls for is its own kind of waste.

A twenty-person logistics client of mine had already built a detailed forty-step flowchart of their order fulfilment process before bringing me in, and it was accurate, but it did not answer the question they actually had, which was why orders were taking eleven days when the industry standard was five. Redrawing the same process as a value stream map, with time stamps at each step, showed the answer in a single session: orders spent six of the eleven days sitting in an unassigned queue between two systems that did not talk to each other, a wait time invisible on a standard flowchart because a flowchart shows sequence, not duration. The detailed flowchart was not wrong. It was simply the wrong type of map for a question about time.

Pitfalls to avoid. Where teams get the type wrong, or mix types badly.

PRIME BPM's 2024 Global BPM Trends survey, based on responses from over 4,500 business professionals, found that 40 percent rate a lack of clear rules and standards as the single biggest barrier to effective process mapping, ahead of any tooling or software complaint. In practice, that usually means a business has mapped some processes as flowcharts, others as swimlanes, with no agreed rule for which format applies when, so nobody outside the person who drew each one can read it confidently.

The second pitfall is reaching for BPMN or a full value stream map by default, on the assumption that more formal always means more rigorous. A five-step internal approval process rarely needs BPMN's full symbol set, and building it that way just adds a barrier to the team actually using the map, since most people were never trained to read it.

The third is skipping the high-level map entirely and going straight to a forty-step detailed version. A detailed map without a high-level SIPOC or overview sitting above it is hard for anyone outside the immediate team to navigate, and it is usually the reason a beautifully accurate process map ends up used once, in the workshop where it was built, and never referred to again. Build the high-level version first, get agreement on where the process starts and ends, and only then invest the time in full detail, ideally for the two or three steps that actually need it rather than every step equally. For the shapes and symbols used inside any of these formats once you have picked one, our guide to process map symbols covers the dozen worth knowing.

The fourth pitfall, and the one that costs the most rework, is choosing the format before naming the audience. A value stream map built for the operations team, full of cycle times and inventory queues, means very little to a board deciding whether to fund a new hire, and a simple flowchart built for a board deck leaves the operations team with nothing concrete to act on. Decide who will actually use the finished map before choosing how to build it, and if the honest answer is "several different audiences", that is usually a sign the business needs the high-level and detailed pair described above rather than a single map trying to serve everyone at once.