Process Mapping Before Automation: Draw It as It Runs

Before you automate a process, map it as it really happens, not as the manual describes it, because automating a messy process only makes the mess faster. In part 1 of the series you picked the first process with the highest score out of 12. This second part of 7 gives you 6 elements to map the process with the people who run it: the trigger, the steps, who does each one, the data, the waits and the exceptions. It then shows how to separate the rule from the habit, how to delete steps before automating anything, and an exercise in which you time each step yourself.

Why automating an unmapped process fails

Most businesses have two versions of every process: the one written in the policy manual or in the manager's head, and the one that actually happens on the ground. The second is the real one. It contains handoffs nobody wrote down, reviews added after an old mistake, and waits that appear on no document.

When you automate the written version, the system collides with reality in its first week: a case it did not expect, an approval staff usually skip, data that arrives incomplete. The team goes back to WhatsApp and Excel alongside the new system, and you end up with two ways of working instead of one. So the first step is not a screen or a tool. It is a large sheet of paper and a session with the people who work in the process every day.

Map the process with six elements

Sit with the employees who run the process, not only with their managers, and follow one real request from start to finish. For every step, record 6 elements:

• The trigger: what exactly starts the process? A customer message, a form being filled, a date arriving, goods being delivered.
• The step: what happens, as a clear verb: enters, checks, approves, sends, prints.
• Who does it: by role, not by name: storekeeper, accountant, branch manager.
• The data: what information the step needs, where it comes from, and in which program or file it is written. This is where the places that record the same information more than once show up.
• The wait: where the request stops and who it is waiting for. The wait is often longer than the work itself, and nobody sees it because it leaves no trace.
• The exceptions: what happens when data arrives incomplete, the approver is away or the amount exceeds the limit. Ask: when was the last time a request did not follow the normal path?

You need no software for this. A sheet on the wall and sticky notes are enough; what matters is that everyone sees the whole process in front of them. If part of the process lives in Excel files, go back to the file inventory method in Inventory Your Files: Which Sheet Is the System? to find which file is the real source of the data.

Separate the rule from the habit

Once the map is drawn, go through every step and ask one question: why do we do this? The answers fall into three kinds:

• A rule: a legal, contractual or regulatory requirement, or a policy management has approved. It stays, and it is written as a clear if-then sentence the system can follow later.
• A safeguard: a review added because a mistake once happened. Ask whether the risk still exists, and whether the system could prevent it with an automatic check instead of a human review.
• A habit: a step that survived because the old program required it, or because a former employee used to do it. Printing then scanning, signing a paper then photographing it, a copy in a file nobody reads.

The people who run the process are the best judges of which is which, because they know which step nobody has asked about in years. Nobody is at fault here; habits build up in any business that works and grows.

Delete before you automate

The simple rule: every step you delete needs no automation, no maintenance and no testing. So before moving any step into a system, put 3 questions to it, in order:

• Can it be deleted? Habits that protect nothing go straight away.
• Can it be merged? Two reviews of the same data by two different people may become one.
• Can it be simplified? A form with 20 fields may need only 8, with the system filling the rest from data it already holds.

What remains after these questions is the process worth automating. The same logic applies to data: do not move unclean data into a new system, as we explained in Cleaning Data Before the Move. And if the map shows the process handles data about people, such as customers or employees, mark it on the map. The Personal Data Protection Law published by SDAIA requires the controller, in Article 19, to take the organizational, administrative and technical measures necessary to protect personal data, including when it is transferred, and in Article 31 to keep records of its personal data processing activities with minimum contents that include the purpose of processing, the categories of data subjects, the recipients and the expected retention period. The map you draw now is the first input to that record. This is not legal advice; confirm the details with SDAIA or a lawyer.

The Origami view

We are a Saudi technology company that builds systems, apps, integrations between systems and AI solutions. In any automation project we start by mapping the process with the people who run it before writing a line of code, because the map is the real specification of the system, and every exception found on paper costs far less than one found after go-live.

A mapping session often ends with steps deleted before we build anything, so what gets automated is smaller and clearer. That order, map, then delete, then build, is how we approach everything we build, and the details are on our services page.

Exercise: map your first process and time it

Take the process that scored highest in the part 1 exercise and do this over 5 working days:

• Sit for one hour with 2 or 3 of the people who run the process daily, and map it with the six elements on a single sheet.
• Follow 10 real requests from start to finish, and record for each step the actual working time and the waiting time before it, separately.
• Classify every step: rule, safeguard or habit, and write beside it delete, merge, simplify or keep.
• Collect the exceptions: how many of the 10 requests left the normal path, and why.
• Write the target process on one page: what remains after deletion, who owns each step, and where each exception goes.

The numbers you collect here are the baseline you will compare against after automation. We will not give you a general figure instead, because it does not know your business.

In the next part

What will most likely stand out on your map is the waiting at approvals. Part 3 of the series, Automating Internal Approvals: A Path and a Deadline, turns an approval from a message chased on WhatsApp into a path with an authority matrix by type and amount, a delegate when the approver is away, a deadline and escalation, and a record of who approved what and when.