A practical guide: map the client's real process before letting AI automate it

On a logistics project, the consultancy Edana mapped a client’s data integration process and found four email exchanges that appeared nowhere in the documentation. Alongside them were shared files that staff opened to correct data by hand before it was loaded into the system.

Had the engineering team automated from the official diagram, those steps would have vanished from the new flow and bad data would have gone straight into the system.

At every client, assume this will happen. Edana observes that employees adapt to constraints: they work around tools or invent shortcuts to get things done faster.

The real process therefore drifts away from the one on paper, and in Edana’s view, digitising without seeing those gaps merely turns the mess into a digital one.

This guide walks through drawing an as-is process map in the order the work should be done. No specialist software is needed. A text editor, a spreadsheet and permission to sit beside the people doing the work are enough.

What will you end up with?

The output has three parts: a list of every step (manual ones included), a swimlane diagram organised by role, and a labelled list of friction points. Of the three, the friction list is the most valuable.

Edana writes that mapping exposes friction points and suggests ways to simplify or eliminate them before anything is automated.

To keep things concrete, the examples below use a hypothetical scenario: a distributor takes orders from resellers, accounting checks credit, and the warehouse ships the goods. The client wants an agent that reads orders and creates dispatch notes automatically.

Step 1: Gather evidence before asking anyone

Visual Paradigm’s guide to as-is modelling recommends starting by collecting all available evidence: forms, emails, system logs, policy manuals. In the hypothetical scenario, you would ask for an order template, a few email threads between sales and accounting, a log export from the accounting software and any process documentation that exists.

Check after this step: you have at least one real record for each department involved. If a department has documentation but no actual trace of work, flag it, because that is usually where the real process diverges most.

Step 2: Interview with “walk me through it”

Do not ask “Do you follow the process?” That question only gets you the answer people think you want to hear. Visual Paradigm suggests an open prompt along the lines of: “Tell me what happens when a customer places an order.”

When the interviewee says “then I enter it into the system”, keep going: entered from where, what happens if information is missing, does anyone have to be asked? Every “and then…” is a potential step. Interview each role separately, because sales and accounting often tell two different versions of the same order.

Step 3: List every step, however rough

MockFlow advises listing all the steps first rather than trying to produce a perfect map straight away. The template below is a simple text table created for illustration, not any notation standard. The first three rows:

# | Role       | Action                          | Note
1 | Sales      | Takes order by phone/chat       | not documented
2 | Sales      | Retypes order into Excel        | entry #1
3 | Sales      | Emails accounting for credit    | hidden step

The next three rows:

4 | Accounting | Checks credit, replies by email | accounting software
5 | Sales      | Enters order into sales system  | entry #2
6 | Warehouse  | Ships goods per dispatch note   | warehouse software

Visual Paradigm is explicit: any work done manually over email must appear on the model. Row 3 is the kind of step people tend to leave out because “it isn’t part of the process”. In fact, it is the process.

Check: every hand-off between two people has its own row in the table.

Step 4: Add exceptions, rework and waits

The happy path is only part of the story. MockFlow reminds practitioners to capture rework loops, exceptions, waiting states and bottlenecks. Go back through each row and ask: what happens when this step goes wrong?

In the hypothetical scenario, you might discover that when a reseller exceeds its credit limit, accounting forwards the email to the department head for approval, and the order sits until a reply arrives. The agent you plan to build will hit exactly this case. If the map lacks that branch, the agent will not know what to do.

Step 5: Arrange swimlanes, then validate

When a process crosses several roles, departments or systems, MockFlow recommends swimlanes. ManageEngine describes a workflow as a series of stages connected by intermediate actions that move work from one stage to the next. Seen that way, laying out the lanes becomes easier.

A text sketch (simplified; numbers in brackets match the table in Step 3):

[Sales]        (1) Take order → (2) Type into Excel → (3) Email credit check
                                                    ↓
[Accounting]                       (4) Check credit → within limit? ── yes ──┐
                                                    └ no                      │
                                                         ↓                    │
[Dept head]                                      Approve (WAIT) ──────────────┤
                                                                              ↓
[Sales]        (5) Enter into sales system ←──────────────────────────────────┘
                        ↓
[Warehouse]    (6) Ship goods

Both branches, with or without approval, return to Sales for entry into the sales system before moving on to the Warehouse. The swimlane shows at a glance how many times an order bounces between lanes. Every lane change is a place where work can slow down, lose information or need re-entering.

But a map you drew yourself is still only a hypothesis. Visual Paradigm recommends taking the as-is draft to a workshop with the people who actually run the process. Print it large or put it on a screen and let them correct it directly, pen in hand.

The most effective question in that session is “What’s wrong here?”, not “Is this right?” Check: each role on the swimlane has at least one person who has confirmed their lane.

Step 6: Flag friction before choosing where AI goes

Edana warns that modernising an undiagnosed process carries every workaround along with it: duplicate data entry, multi-layer approvals, detours. So before writing a single line of agent code, mark each friction point:

Steps 2 + 5    [DUP-ENTRY]     order typed twice into two systems
Step 3         [HIDDEN-EMAIL]  credit checked by email, no trace in any system
Approval path  [WAIT]          order sits idle until the department head replies

This list changes the brief. The client may not need an order-reading agent at all; it may first need to drop the Excel retyping step, and only then let an agent handle the rest.

Common mistakes

The most common mistake is drawing from the documentation and calling it as-is. The second is interviewing only managers: they describe the process as it should run, while front-line staff know how it actually runs. The third is leaving out exceptions because they “rarely happen”.

Yet exceptions are precisely where agents are most likely to break in production.

Where does this skill show up in FDE work?

The six steps draw on business analysts’ elicitation skills: interviewing, modelling and scenario analysis. Microsoft’s Requirements Gathering in Business Analysis course on Coursera teaches exactly these topics and includes a project on writing requirements for a manual process.

It is a good place to practise if you have never done this before.

When reading job descriptions, look for passages about working directly with a client’s operations teams, or understanding and redrawing business processes. If you see requirements like these, put your process-mapping experience near the top of your CV. Do not write a generic “business analysis”.

State how many manual steps you uncovered and which ones you removed before automating.

However capable an agent is, it only follows the process you give it. Give it the process on paper, and it will go wrong at the first undocumented email.