Map the Process Before You Fix It
Scroll down to see an interactive process mapping demo in this post, and map one yourself!
There is a methodology that large consulting firms and manufacturing companies have used for decades to diagnose operational problems, and it is one of the most underused tools in small business. It is called process mapping, and the specific version I use most often is the very accessible swim lane diagram. I want to explain what it is, why it matters at any scale, and how to do it.
What a swim lane map is
A swim lane diagram is a type of flowchart that adds one critical dimension most flowcharts leave out: who is responsible for each step. The name comes from its visual structure. Horizontal or vertical lanes divide the diagram into sections, each representing a different person, role, or department. Process steps sit inside the lane of whoever owns that step, and arrows show how the work moves between them.
The format was popularized by Geary Rummler and Alan Brache in their 1990 book "Improving Performance: How to Manage the White Space on the Organization Chart," which is still considered one of the foundational texts in process improvement. Their core insight was that most organizational breakdowns do not happen inside a department. They happen in the white space between departments, the handoff points where responsibility transfers from one person or team to another. That idea turned out to be one of the most useful concepts in operational improvement, and it applies to a 12-person company just as well as it does to a 12,000-person enterprise.
The standard symbols are simple. Rectangles represent process steps. Diamonds represent decision points, where the process branches depending on a yes-or-no condition. Ovals or rounded rectangles mark the start and end of the process. Arrows show direction and sequence. You do not need specialized software or a Six Sigma certification to build one.
Why small businesses should care
The reason swim lane mapping matters for smaller operations is that the problems it reveals are the same problems small businesses deal with every day, even if they describe them differently.
When an owner says "things keep falling through the cracks," that is usually a handoff problem. Work moves from one person to another, and the transition point has no defined trigger, no confirmation, and no clear ownership of what happens next. When someone says "we keep duplicating effort," that is usually a visibility problem; two people are doing the same work because neither can see that the other is already handling it. When the complaint is "this takes way too long," the delay is almost always sitting at a handoff, not inside any individual step.
Miro, Atlassian, Lucidchart, and several other platforms have all published extensively on swim lane methodology, and the consensus across the literature is consistent: the highest-value finding in most process maps is not a bad step. It is a bad handoff. The Lean Six Sigma community, which formalized much of this methodology, tracks a concept called "touch time versus wait time," and in most processes, the time work spends waiting between steps dwarfs the time anyone spends actually working on it.
For a small business, you do not need to adopt an entire improvement framework to benefit from this. You just need to see your process on paper, with the lanes drawn, and look at where work crosses from one lane to another. That is where almost every fixable problem lives.
How to build one
The process is straightforward, and I walk clients through it regularly as part of how I scope work. Here is the sequence:
Start by naming the process and defining its boundaries. Pick something specific: "customer places an order through fulfillment," not "how the business works." You need a clear start point and a clear end point.
Next, identify the lanes. Who touches this process? In a small business, this might be the owner, a salesperson, a warehouse or production person, and a customer. Each one gets a lane. Keep it to four or five lanes at most; more than that and the diagram becomes hard to read without breaking the process into sub-processes.
Then place the steps. Walk through what actually happens, not what should happen or what the employee handbook says happens. Start at the beginning and move left to right, placing each step in the lane of whoever performs it. Use rectangles for tasks and diamonds for decision points.
Connect the steps with arrows. This is where the handoffs become visible. Every time an arrow crosses from one lane into another, that is a transfer of responsibility, and each one is a potential failure point worth examining.
Once the map is complete, look at it as a whole. Count the handoffs. Notice where a step bounces back and forth between the same two lanes, which often signals rework or an unclear approval process. Look for steps that have no clear owner, or decision points where the criteria for "yes" and "no" are undefined.
I built a free interactive tool that walks through this entire process in about five minutes. It covers six steps: naming the process, setting up lanes, placing shapes, connecting steps, adding a decision point, and exporting a finished map. You can open it and build a real swim lane diagram without signing up for anything: https://ona-process-map-demo.netlify.app/
What the map tells you
The value of the map is not the map itself. It is the conversation the map forces you to have about how work actually moves through your business.
In my experience, the most common finding is that the owner is in too many lanes. They appear in every handoff, not because they need to, but because the process was never formalized enough for anyone else to make the call. That is not a staffing problem. It is a process design problem, and it is fixable without hiring anyone.
The second most common finding is that decision points are undefined. There is a diamond on the map, meaning the process branches depending on a condition, but nobody has written down what the condition actually is. In practice, this means someone makes a judgment call every time, and the outcome varies depending on who is working that day. Defining those criteria takes 10 minutes and eliminates hours of inconsistency over time.
The third is redundant steps. Two people in two different lanes performing the same quality check, or a piece of information getting entered into two systems manually when one could feed the other. These are invisible when you are inside the process, but obvious the moment you see them on a map.
Map first, fix second
The instinct when something is not working is to jump to a solution. Hire someone, buy a tool, add a step. But without a map of the current process, you do not actually know where the breakdown is, which means the fix is a guess. Sometimes it is a good guess. Often it is not, and you end up adding complexity to a process that needed simplification.
Rummler and Brache built their entire methodology around a two-map approach: the "is" map, showing how the process works today, and the "should" map, showing how it should work after improvements. The gap between the two maps becomes the implementation plan. That structure works at any scale, and the first map, the "is" map, is the one that most businesses have never drawn.
If you have a process that feels slow, inconsistent, or dependent on one person's knowledge, draw the swim lanes before you try to fix anything. The map will show you where the real problems are, and they are almost always in the handoffs.
