Visualising Workflows Before Building Systems
Every growing business has at least one process that exists entirely in someone's head. The warehouse manager who knows the workaround for returns. The office manager who remembers which supplier needs a purchase order and which takes a phone call. The developer who built the integration three years ago and never wrote it down.
When that person is on holiday, things slow down. When they leave, things break. And when you try to build software to support the process, you discover that nobody can describe it completely, because nobody has ever had to.
This is where most software projects go wrong. Not in the code. In the gap between how people think the business works and how it actually works. Business process mapping closes that gap: it is the practice of documenting how work actually flows through your organisation, so the software you build matches the reality it needs to support.
What undocumented processes cost
The problems with undocumented processes are not dramatic. They are slow, persistent, and expensive. They show up as inconsistency, delays, and software that does not fit the work it was built to support.
| Area | Undocumented | Mapped |
|---|---|---|
| New staff | Learn by shadowing for weeks, absorbing good habits and bad ones alike | See the full process on day one, ask informed questions |
| Consistency | Ten people handle the same work ten different ways | One agreed process with known variations |
| Bottlenecks | Felt but not identified. "Things are slow" but nobody knows where | Visible on the map. Measurable. Fixable |
| Software design | Built on assumptions. Developers guess at workflows. Rework after launch | Built on documented reality. Fewer surprises during development |
| Key-person risk | Critical knowledge leaves when people leave | Knowledge captured, shared, and maintained |
For businesses with 5 to 50 employees, the undocumented process problem is almost universal. Processes were never formally designed. They emerged. Someone started doing something a certain way, it worked, and it became "how we do things." That works until growth forces changes, staff turn over, or you need software to support the work.
What process mapping actually produces
Process mapping is the practice of making invisible work visible. Not how a policy document says work should flow, but how it actually flows through your organisation day to day: who does what, in what order, with what information, and what happens when things go wrong.
The output is a visual diagram that everyone involved can look at and either confirm ("yes, that is what we do") or correct ("no, that is wrong, here is what actually happens"). The corrections are where the real value lives. Every disagreement surfaces knowledge that was previously invisible.
Mapping vs documentation: Standard operating procedures (SOPs) describe processes in text. Process maps add a visual, structural layer that reveals relationships, dependencies, and bottlenecks that text alone cannot show. Both are valuable. Mapping is what you need before designing software.
To make this concrete, we will follow a single example through this guide: an order fulfilment process for a wholesale distributor with 30 staff. Orders arrive by email, phone, and an online portal. They pass through sales, warehouse, and accounts before reaching the customer. Three teams, dozens of handoffs, and a collection of spreadsheets holding it all together.
As-is mapping: capturing current reality
The first step is always the same: document what actually happens now. Not the improved version. Not the version in the staff handbook. The real one, with all its workarounds, exceptions, and "that is just how we have always done it" steps.
This is the as-is map. It captures current reality so everyone can see it, discuss it, and agree on it before anyone proposes changes.
Why the as-is map matters for software
Software that ignores the as-is process will fight the people using it. If your warehouse team has been processing urgent orders through a side channel for years, and your new system has no concept of urgency tiers, the team will work around the software. Shadow processes will persist alongside the system you paid to replace them. We wrote about what happens when tools and reality diverge in our guide to user experience design.
The as-is map prevents this. It makes the real process (including the messy parts) the starting point for design.
What as-is mapping reveals
In our order fulfilment example, the as-is map typically surfaces patterns like these.
Approval bottlenecks
Every order over a certain value requires the sales director's sign-off. The sales director is in meetings most of the day. Orders queue up. Delivery dates slip. The map shows the bottleneck clearly: one person constraining the entire flow.
Rework loops
Orders with incorrect addresses get picked, packed, and then returned to the warehouse when the courier rejects them. The error originates at order entry but is not caught until despatch. The map traces the loop and reveals where a validation step would eliminate it.
Information gaps
The warehouse team does not know whether an order is urgent until someone from sales walks over and tells them. There is no field for priority. No notification. Just a conversation that may or may not happen. The map shows the missing information flow.
Shadow processes
The official process says credit checks happen before order confirmation. In practice, the sales team skips them for repeat customers to avoid delays. The shadow process works most of the time, but when it does not, the cost is significant. The map captures both the official and shadow versions.
Swimlane diagrams: where the handoffs break
A basic flowchart shows steps in sequence. Useful, but limited. A swimlane diagram adds horizontal lanes (one per role or team) so you can see, instantly, where work crosses from one group to another. That crossing point is where most process problems live, which makes swimlanes the single most useful notation for software design.
Our order fulfilment diagram has three lanes: Sales, Warehouse, Accounts. Even the rough first draft made something obvious that the flowchart version missed entirely.
The handoff problem: Every time work crosses from one lane to another, information can be lost, delayed, or corrupted. An order confirmed by Sales but not communicated to Warehouse for two hours is a handoff failure. An invoice raised by Accounts using different line items than the delivery note is a handoff failure. The swimlane diagram makes every crossing visible and countable.
Most order fulfilment processes we have mapped contain between eight and fifteen handoffs. Reducing that number, or making each handoff explicit and reliable, is one of the highest-value outcomes of the mapping exercise. Each handoff that software can automate (a notification, a task assignment, a status change) removes a point where information can degrade.
Swimlanes also reveal role overlap. When two teams both update the same spreadsheet, or when the same data is entered twice because neither team trusts the other's version, the diagram shows it. These are not people problems. They are process design problems, and they become software requirements: a single source of truth, access controls, and an audit trail showing who changed what.
Exception mapping: the other 60%
The straightforward path through a process (order received, picked, packed, shipped, invoiced) is called the happy path. It is the version people describe first in interviews. It is also, in most businesses, only 40 to 60 percent of what actually happens.
The rest is exceptions: returns, partial shipments, back-orders, credit holds, address corrections, customer cancellations, supplier substitutions, damaged goods. Exceptions are where processes break, where staff spend disproportionate time, and where software most commonly fails.
Every exception you discover during mapping is one you can design for in software. Every exception you miss becomes a support ticket, a workaround, or a manual override after launch.
Signs of unmapped exceptions
In our order fulfilment example, exception mapping added fourteen additional paths to the diagram. Partial shipments alone introduced three: back-order the remainder, substitute a product, or cancel the outstanding items. Each path requires different logic in software (different notifications, different invoice calculations, different stock movements). Discovering these during mapping costs hours. Discovering them after launch costs weeks.
To-be design: the future state
With the as-is map validated and exceptions documented, the next step is designing the to-be process: how the work should flow once improvements are in place. The gap between the as-is and to-be maps is, in practical terms, the design brief for the software.
The to-be map is not a wish list. It is a deliberate redesign that addresses specific problems identified in the as-is map.
The to-be map gives the development team a clear target. It shows what the software needs to support, what it needs to enforce, and what it can safely ignore. It also gives the business team a shared picture of the future, which makes user acceptance testing far more productive. People can test against the agreed to-be process rather than their individual assumptions.
From map to code: translating process into requirements
This is the step that most process mapping guides skip entirely. The map is complete. The as-is and to-be states are agreed. The next challenge is turning a diagram into a software specification.
The translation is more direct than most people expect. Every element of a process map corresponds to a concrete software concept.
| Process map element | Software requirement | Order fulfilment example |
|---|---|---|
| States | Status fields and transitions | Order: Draft, Confirmed, Picking, Packed, Shipped, Invoiced, Complete |
| Decision points | Business rules and validation logic | If order value exceeds threshold, route to approval. If stock is insufficient, trigger back-order |
| Handoffs | Notifications, task assignments, and queue management | Order confirmed triggers a picking task assigned to the warehouse team with priority flag |
| Exceptions | Error handling, alternative flows, and escalation rules | Partial shipment creates a back-order record and adjusts the invoice automatically |
| Information needs | Data model: fields, relationships, and access controls | Order record needs: customer, items, quantities, urgency, delivery address, credit status |
| Swimlane crossings | Permissions, role-based views, and integration points | Sales sees order value and margin. Warehouse sees items and priority. Accounts sees payment terms |
In a typical order fulfilment mapping exercise, a validated to-be map produces dozens of discrete requirements: status transitions, business rules, notification triggers, exception handlers, and integration points with existing systems. The exact count varies by complexity, but the principle holds: every requirement traces back to a specific element on the map.
This traceability matters. When a developer asks "why does the system need to handle partial shipments?", the answer is on the map. When a business owner asks "why is this feature taking so long?", the complexity is visible in the exception paths. The map becomes the shared language between the people who understand the business and the people who write the code. We cover the technical implementation of these patterns in our guide to workflow engines.
The return on mapping: The order fulfilment project took fourteen weeks to build. The mapping phase took two weeks. Without mapping, based on our experience with similar projects, we estimate an additional four to six weeks of rework during and after development as undiscovered requirements surfaced one by one. Two weeks of mapping saved at least four weeks of development time.
Running a process mapping workshop
The quality of a process map depends almost entirely on how the information is gathered. Two techniques produce the best results, and the difference between them matters.
Interviews vs observation
Interviews capture what people think happens. Ask someone to describe their process and they will give you the clean version: the steps as they are supposed to occur, in the order they are supposed to occur. They will skip steps that have become automatic. They will omit workarounds they have normalised. They will describe the intended process, not the actual one.
Observation captures what actually happens. Watching someone process three orders reveals the sticky note they check before entering an address ("some postcodes need the depot code"), the spreadsheet they cross-reference for stock levels because they do not trust the system, and the phone call to the warehouse that is not in any procedure document.
Both are necessary. Interviews provide the structure. Observation provides the truth. Start with interviews to build the draft map, then observe the work to validate and correct it.
Workshop facilitation
When running a group workshop, three practices consistently produce better maps.
Start with sticky notes, not software
Give each participant a pad of sticky notes and ask them to write one step per note. Arrange them on a wall in sequence. This physical activity surfaces disagreements immediately. When two people put different steps in the same position, you have found a variation that needs resolving. Diagramming software comes later, once the content is agreed.
Separate what from who from when
Map the activities first (what happens). Then assign roles (who does it). Then add timing and triggers (when does it happen). Trying to capture everything simultaneously overwhelms participants and produces messy diagrams. Three passes produce a clean, accurate map.
Ask "and then what?" until you reach the end
The most effective facilitation technique is also the simplest. "Walk me through what happens when an order arrives." Then: "And then what?" Repeat until the process reaches its conclusion. Follow every branch. "What happens if the item is out of stock?" "And then what?" This forces participants to articulate the complete process, including the exception paths they would otherwise skip.
Expect the first draft to be wrong. Plan for at least two validation sessions where participants review the map, correct it, and add what was missed. The third version is usually accurate enough to design from.
Choosing the right notation
There is no shortage of process mapping notations. BPMN (Business Process Model and Notation) is the formal standard, maintained by the Object Management Group. It is precise, detailed, and thorough. It is also intimidating for non-technical participants, which makes it a poor choice for workshops with business owners and their teams.
Our position, after twenty years of running these workshops: simple flowcharts with swimlanes produce the best results for businesses with 5 to 50 employees. Rectangles for activities. Diamonds for decisions. Arrows for flow. Lanes for roles. That is enough to capture any business process at the level of detail needed for software design.
| Notation | Best for | Watch out for |
|---|---|---|
| Flowchart with swimlanes | Workshops with mixed audiences. Software design briefs. Most business processes | Can become unwieldy for very large processes. Split into sub-processes if the diagram exceeds a single wall |
| BPMN 2.0 | Enterprise process management. Workflow automation platforms (Camunda, Bizagi). Regulatory documentation | Participation barrier for non-technical staff. Over-specification for discovery-phase mapping |
| State diagram | Tracking the lifecycle of a work item (order, ticket, application). Status-driven workflows | Does not show who does the work. Use alongside swimlanes, not instead of them |
| Value stream map | Identifying where time is wasted. Prioritising automation. The typical finding in knowledge work: 90 to 95 percent of cycle time is waiting, not working | Requires time measurement data, which is rarely available before the first mapping exercise |
For tools, anything that gets out of the way works: Lucidchart, Miro, draw.io, or a whiteboard. The tool does not matter. The conversation it enables does. Pick whatever your team will actually use.
What mapped processes deliver
We have mapped processes for over 50 projects since 2005. The same results keep showing up.
-
Software that fits the work Systems built on documented reality, not assumptions. Fewer change requests during development. Faster user acceptance testing because people can test against the agreed process.
-
Visible bottlenecks Problems that were felt but not identified become explicit and fixable. Some are resolved by process changes that cost nothing. Others become clear priorities for automation.
-
Shared understanding The team agrees on how the process works. New staff learn faster. Handovers between people are cleaner. The "ask Sarah" dependency disappears because the knowledge is captured.
-
Reduced key-person risk Critical process knowledge is documented, not locked in one person's memory. The business becomes more resilient to staff changes and growth.
-
A foundation for continuous improvement Once you can see the process, you can measure it, improve it, and track whether changes are working. Project visibility starts with process visibility.
The order fulfilment project we followed through this guide went live on time. Not without friction: the warehouse supervisor hated the new priority flags for the first fortnight and kept a paper backup "just in case." By week three, she was the one showing new pickers how to use the system, because it matched how the team actually worked. Twelve months on, order processing time had halved and mis-ships were down to two or three a month. Not magic. Just the result of building software from a map of reality instead of a guess.
Map your processes before you build
We use process mapping as the first step in designing software that supports how your business actually works. A short mapping phase at the start saves weeks of rework during development. Process mapping workshops are available as a standalone consulting engagement or as part of a broader discovery project.
Book a process mapping session →