Map it before you automate it: a guide to process mapping

Most businesses have a few jobs that everyone knows take too long. An order is typed into one system, then another. An invoice waits for a piece of paper to come back from the warehouse. Process mapping is how you see those jobs clearly enough to fix them, and it is worth doing before you buy or build anything to automate them.

If you automate a process you don't fully understand, you build its problems into the software. A good map shows what actually happens, awkward cases included, and becomes the brief for any business process automation that follows.

What process mapping is

A process map is a picture of how a piece of work gets done: the steps, who does each one, which systems they use and in what order. It starts with a trigger, such as a customer placing an order, and ends with an outcome, such as the invoice going out.

The most useful format for most businesses is the swimlane map. Each person, team or system gets its own lane, and each step sits in the lane of whoever does it. When work moves between lanes, that is a handoff, and handoffs are where work tends to wait, get lost or get typed in again. Geary Rummler and Alan Brache's book Improving Performance has a subtitle about managing the white space on the organisation chart, and that white space between the boxes is where handoffs live.

The standard formal notation is BPMN (Business Process Model and Notation), published by the Object Management Group. It is worth learning if the map will go to developers or into workflow software. For a first map, sticky notes on a wall or an online whiteboard are enough.

How to map a process

Pick one process and fix its ends

Choose a process that runs often and that people complain about, then write down where it starts and ends. "Order received to invoice sent" is a process. "Sales" is not.

Get the right people in the room

You need someone from every lane, and that means the people who do each step, not only their managers. Managers know how the process is meant to work. The people doing it know how it really works, workarounds and all. Add the person who owns the outcome and can make decisions, and a facilitator who owns none of the steps and so can ask the obvious questions. Make it clear you are looking at the process, not judging anyone in it, or you will get the official version.

Walk real cases, not the theory

Don't ask people to describe the process in general. Take three or four recent real examples, including one that went wrong, and follow each from start to finish. At every step ask: what arrives, where from, what do you do with it, where does it go next, and what happens when it's wrong? A well known Harvard Business Review article by Benson Shapiro, V. Kasturi Rangan and John Sviokla, Staple Yourself to an Order, has a title that sums up the method.

Draw the swimlanes

Give each role a lane, and give the main systems lanes too: the shared inbox, the order system, the accounts package, the spreadsheet. That shows where data lives and how it moves, which is what anyone automating the process needs to know. Map what happens now, not what should happen.

Mark the four things that cost time

• Handoffs. Every time work crosses from one lane to another, it can sit in a queue or be misread.
• Rekeying. Every time the same information is typed again somewhere else, such as copying an address from an email into a courier's website.
• Waiting. Where work sits: in an inbox, until the end of the day, until someone is back from holiday, until an approval comes through.
• Exceptions. The "unless" branches: out of stock, wrong price, missing purchase order number, customer on credit hold. Note how often each happens and who sorts it out.

Look for private workarounds too: the personal spreadsheet, the notebook, the email someone sends themselves as a reminder. They usually mark a gap the official system doesn't cover.

Measure a few things

You don't need a stopwatch study. For each step, get rough answers to how often it happens, how long it takes when someone is working on it, how long the work waits around it, and how often it has to be redone. Multiply frequency by time and you have the hours a step costs. Compare total working time with the time from trigger to outcome, and the gap is waiting.

A worked example: order to invoice

This is a hypothetical example, not one of our clients. A wholesaler takes orders from trade customers, picks them in its own warehouse and invoices on dispatch. Mapped as it really runs:

1. A customer emails an order to the shared inbox, sometimes as a PDF, sometimes typed into the email.
2. The sales office checks prices against a spreadsheet price list and types the order into the order system.
3. If something is out of stock, they email the customer and the order waits for a reply.
4. The warehouse prints a pick list, picks and packs, and writes any shortages on the paper.
5. The warehouse books the courier on the courier's website, typing the address in again.
6. At the end of the day, the signed pick lists go to accounts.
7. Accounts type the shipped quantities into the accounts package, then raise and email the invoice.

Drawn in swimlanes, the problems are plain:

• The order is typed three times: into the order system, the courier's site and the accounts package.
• The work crosses lanes at least four times, and one handoff is a piece of paper.
• Every invoice waits for that paper to reach accounts.
• Shortages are handwritten, so an invoice can charge for goods never sent, which means a credit note and an awkward phone call.
• Prices live in two places, and nothing keeps them in step.

Reading the map: simplify, automate or leave alone

Sort each problem into one of three piles, and deal with them in this order.

Simplify first

Some steps should simply stop: a check nobody acts on, an approval that is always given, a second spreadsheet that copies the first. Automating a step you didn't need still leaves you with that step, now harder to change. In the example, the price list spreadsheet goes, and prices live only in the order system.

Then automate the repetitive, rule-based work

Good candidates happen often, follow clear rules, use information that is already digital, and have few exceptions, or exceptions that are easy to spot. Rekeying between systems is the clearest case: if someone copies data from one screen to another, software can usually do it instead, and it won't mistype a postcode. We built and run Add to CRM, a Chrome extension that adds people from LinkedIn, Gmail and Outlook to a CRM in one click, for exactly this reason: it removes a copy-and-paste job.

In the example, the order system books the courier using the address it already holds. The warehouse confirms what was picked on a screen or scanner instead of paper, and those quantities raise the invoice as soon as the order ships. Three typing jobs and the paper handoff disappear, and the invoice matches what was sent.

Orders that arrive as free text or PDFs are harder, because the input has no fixed structure. Here AI automation can read the email and draft the order lines for a person to check and approve. Keep that check: the map tells you what a wrong order costs, and so how much review it needs.

Leave judgement to people

Ringing a customer about a shortage, deciding whether to release an order for a customer on credit hold, settling a pricing dispute: these depend on relationships and judgement, and are often too rare or too varied to be worth automating. Software can still make sure the right person hears about the exception quickly, with the facts in front of them.

Common mistakes

• Mapping the process as it should be. A map drawn from the procedures manual misses the workarounds.
• Leaving out the people who do the work. Without them, the map is a guess.
• Only mapping the happy path. If nobody knows how often an order ships short, nobody can design for it.
• Going too deep too early. Map steps a person would recognise, such as "types order into system", not every click.
• Getting stuck on notation. Start rough, and formalise later if you need to.
• Automating before simplifying. Automate a muddled process and you get the same muddle, faster and harder to change.
• Making a map and filing it. Give the process an owner, date the map, and redraw it when the process changes.

If you want a hand

You can do all of this yourself with a wall, some sticky notes and the right people. If you would like help running the session, or building the automation the map points to, that is work we do. Start a project and tell us which process you have in mind.