How to map a business process before you automate it

Most automation projects start with a description of the process that's tidier than the process itself. The procedure document says invoices are received, checked, approved and paid. Then you sit next to the person who does it and find a shared inbox, a spreadsheet of supplier quirks, two kinds of approval depending on the amount, and a weekly batch of invoices that arrive on paper.

Automate the tidy version and the bot handles the easy cases while people quietly keep doing the rest by hand. Mapping the process properly first is how you avoid that. It doesn't need special software or a consultant. It needs a few hours, the right people in the room and some discipline about writing down what actually happens.

Draw the edges first#

Before you draw a single box, agree where the process starts and stops. "Accounts payable" is not a process. "From a supplier invoice arriving to the supplier being paid" is.

A SIPOC diagram is a quick way to pin this down. The US Agency for Healthcare Research and Quality describes SIPOC as a high-level flowchart that records the suppliers, inputs, process, outputs and customers, and suggests it for exactly the situations automation projects tend to be in: the start of a project, or when the inputs, suppliers, outputs or end users are unclear. Its method is to gather people who know the process, sketch the main steps, then list the outputs, the people who use them, the inputs the process needs and where those inputs come from, before reviewing the lot for gaps and duplicates.

For the invoice example, the outputs might be a payment, a ledger entry and a remittance email. The inputs are the invoice, the purchase order and the supplier's bank details. The suppliers of those inputs include the vendor, your purchasing team and whoever maintains the supplier master list. That last one matters. If bank details come from an email that someone forwards, that's an input your automation will have to deal with, and a fraud risk you'll want to design around.

Keep the SIPOC to one page. Its job is to stop the mapping session from drifting into neighbouring processes.

Map what actually happens, with the people who do it#

Now map the steps. A swim lane flowchart works well because automation problems usually live in the handoffs. AHRQ's flowchart guide lists examining handoffs between people or groups and identifying who's responsible for each task among its main uses. The method is simple: name the "players" involved, brainstorm the steps without worrying about order, give each player a row or column, place each step in the lane of whoever does it, then draw the arrows. The last step is the one people skip. Review the chart with the people who actually do the work and confirm it's accurate.

A few habits make the session far more useful:

• Map a handful of real, recent cases rather than the process in general. Pull up last Tuesday's invoices and walk through each one.
• Talk to the people doing the work, not only their manager. Managers know the intended process. The people in the lanes know the workarounds.
• Write down where every piece of information comes from at each step: which system, which email, which spreadsheet, whose memory.
• When someone says "and then I just check it", ask what they check, against what, and what they do if it's wrong.

That last question is where most of the useful detail hides. "Check it" might mean comparing three fields against a purchase order, which is easy to automate. Or it might mean recognising that this supplier always invoices in the wrong currency, which is knowledge you'll need to capture as a rule or leave with a person.

Record the numbers automation decisions depend on#

A map with no numbers tells you what happens, but not what's worth changing. Value-stream mapping, the Toyota-originated practice described by the Lean Enterprise Institute, attaches a data box to each step with measures such as processing time and "percent complete and accurate", and adds a timeline showing lead time, the time one item takes to get from start to finish. You don't need the full lean toolkit, but borrowing that idea pays off.

For each step, try to capture:

Rough numbers are fine. "About 40 a week, five minutes each, and maybe one in ten has the wrong PO number" is enough to make decisions. These figures are also your baseline. Without them you'll have no honest way to say later whether the automation saved anything.

Hunt for the exceptions#

The main path through most processes is short. The exceptions are where the work is. Once the happy path is on the wall, go back through it step by step and ask what happens when the input is missing, when it's wrong, when it's late, when the amount is over a threshold, and when the usual person is on leave.

Draw each exception as a branch, and note how often it happens. Some will be rare enough to leave as "send to a person". Others turn out to be a third of the volume, which changes the whole design. An automation that only handles the happy path is still useful, but you want to know that before you build it, not after.

Check the map against the data, if you have it#

People describe processes from memory, and memory smooths things over. If the process runs through software that keeps an audit trail, such as an ERP, a ticketing system or a CRM, you may be able to check the map against what the system recorded.

That's the idea behind process mining. The Process Mining Manifesto, written by the IEEE Task Force on Process Mining, describes techniques to "discover, monitor and improve real processes (i.e., not assumed processes)" by extracting knowledge from event logs. Each event in such a log refers to a case (one invoice, say) and an activity, often with a timestamp and the person or system involved. The manifesto describes three uses: discovery, which builds a process model from the log alone; conformance checking, which compares an existing model with the log to find where they differ; and enhancement, which adds information such as bottlenecks and waiting times to a model.

You don't need a commercial tool to get value from this. Exporting a month of status changes for 200 invoices and sorting them by case and time will often show paths nobody mentioned in the workshop. Treat the log with some care, though. It only shows what passed through the system, so anything that happens in email or on paper will be missing.

Pick a notation your audience can read#

Sticky notes on a wall are a perfectly good way to build the first map. When you need something more formal, for example to hand the process to developers or load it into a workflow engine, BPMN is the common standard. The Object Management Group's BPMN specification, currently version 2.0.2 from January 2014, aims to give a flowchart-like notation that business stakeholders can follow while being precise enough to translate into software process components.

You don't have to learn all of BPMN. Tasks, decision gateways, start and end events, and lanes cover most business processes. The point is that the same diagram should make sense to the person who does the work and the person who builds the automation.

Turn the map into an automation decision#

With a current-state map, numbers and exceptions in hand, the lean practice of drawing a future-state map is a useful next step. The Lean Enterprise Institute describes the current-state map as capturing the actual flow, and the future state as a roadmap showing how work should flow once improvements are made.

Often the future state removes steps rather than automating them. A check that exists because an upstream form allows free text might disappear once the form uses a dropdown. Two approvals might collapse into one. Only after that do you mark which of the remaining steps are good automation candidates: high volume, structured inputs, a clear written rule and a system you can actually connect to. Steps that need judgement, or whose rules nobody can articulate, are usually better left with a person and supported by the automation rather than replaced by it. When we scope automation work at TheAILAB, this is the stage where most of the real design decisions get made.

Keep the map and its numbers after you build. They're the reference you'll test the automation against, the first thing to update when the process changes, and the only reliable way to show what the change was worth.

Sources

1. Supplier, Inputs, Process, Outputs, Customer — Agency for Healthcare Research and Quality (AHRQ), Workflow Assessment for Health IT Toolkit (checked 2026-10-20)
2. Flowchart — Agency for Healthcare Research and Quality (AHRQ), Workflow Assessment for Health IT Toolkit (checked 2026-10-20)
3. Understanding the Fundamentals of Value-Stream Mapping — Lean Enterprise Institute, The Lean Post (25 August 2022) (checked 2026-10-20)
4. Process Mining Manifesto — Wil van der Aalst et al., IEEE Task Force on Process Mining (checked 2026-10-20)
5. About the Business Process Model and Notation Specification Version 2.0.2 — Object Management Group (OMG) (checked 2026-10-20)