Process audit, mapping and optimisation in a company before automating office work

Process mapping: what it is and why it matters

A process map describes the steps from the starting event (e.g. an enquiry arrives) to the result (an invoice sent, an order closed). For each step you record who performs it, in which system, what data goes in and out and how long it takes.

The map does not need to be a pretty diagram. A spreadsheet table is enough. Its purpose is shared understanding between the people who do the work and whoever will automate it. Very often this stage alone reveals that two departments do the same thing or that a step that has “always been there” is not needed by anyone.

Step 1: choose one process and its boundaries

A process audit starts with one process, not the whole organisation. A good candidate is repetitive, runs at least a few times a week and has a clear start and end. Examples: taking an order from a B2B customer, the flow of cost invoices, preparing the monthly report.

Write down what triggers the process and what ends it. Without these boundaries the map grows forever.

Step 2: write down the steps with the people who do them

The best source is the person who does it every day, not the manager who knows how it “should” be. Ask them to walk through the process on a real example from last week and note every move: opening the email, copying a number, looking up the customer, typing in data.

• Step number and a short description of the activity.
• Who performs it (role, not name).
• System or tool: email, Excel, accounting program, CRM, paper.
• Input and output data.
• Estimated time per execution.
• What happens when something is missing (exception).

Step 3: count time, frequency and errors

For each step add how many times a month it repeats. Time per execution multiplied by frequency shows where the hours really go. The most expensive step often turns out to be a trivial one, such as re-typing data from a PDF into a program, because it repeats hundreds of times.

Record errors too: mistakes in re-typed data, lost emails, invoice corrections. The cost of an error can exceed the cost of the work itself, because it comes back as a complaint or a correction.

Step 4: mark exceptions and decisions

Automation handles rules well and gut-feel decisions badly. For each step, mark whether it needs human judgement. If so, describe what that judgement is based on. Sometimes it can become a rule; sometimes it is better to keep a person and automate only the preparation of data for the decision.

This is also where an AI-oriented process audit fits: language models are good at reading unstructured content, e.g. classifying emails or extracting data from documents, but a person should check the output, at least at first.

Step 5: optimise the process before automating anything

Process optimisation often needs no technology. Before automating a step, ask whether it is needed. Removing an unnecessary approval or standardising the enquiry form can deliver more than code.

• Remove steps that do not change the result.
• Merge steps done by different people on the same data.
• Standardise input: one form instead of free-form emails.
• Agree a single source of truth for customer, product and price.

Step 6: choose what to automate first

Finally, rank the steps by two criteria: how much time and how many errors they cost, and how hard they are to automate. Start with costly, simple steps, such as moving data between two systems that have APIs. Leave costly, hard steps for a second stage, once the first has delivered a measurable effect.

For a first estimate of whether automation pays off, you can use our free ROI calculator. The result is a guide, not a quote, but it shows the order of magnitude well.

Digitisation is not the same as automation

Digitisation means moving information from paper and people's heads into systems: a scan instead of a binder, a CRM instead of a notebook. Automation is the next step, where systems do part of the work themselves. Without digitisation there is nothing to automate, which is why a process map often ends with a list of data that must first be stored in one place.