How to Map Business Processes Before Automating Them

Why map a process before automating it

Automate chaos and you get faster chaos. A process map shows what actually happens, where time is lost and which parts are worth handing to a system. For developers it is the best possible input: it answers questions that would otherwise surface in the middle of the project.

The work has two steps:

1. As-is — the process as it runs today, workarounds included.
2. To-be — the target process after changes and automation.

Step 1. Pick one process and set its boundaries

Do not try to map the whole company. Take one process and record:

• start — the event that triggers it (a lead arrives, a customer calls);
• finish — how it ends (order delivered, payment received);
• participants — roles or departments, not specific people;
• goal — what should improve: speed, errors, visibility.

Step 2. Map the as-is process

The best source is the people who do the work. Walk through the process with them using real examples and write down what happens, not what "the policy says should happen".

A handful of BPMN elements is enough for the diagram:

A simple example as text:

[Customer]   (start) -> Submits a request on the website
[Manager]    Copies it to a spreadsheet -> Calls the customer -> <Customer agrees?>
               yes -> Writes an invoice by hand -> Sends it to accounting in a messenger
               no  -> (end)
[Accountant] Checks payment in the bank -> Tells the manager -> (end)

You can draw on a whiteboard, in any diagram editor or even in a spreadsheet. What matters is that the people in the process understand the diagram.

Step 3. Find bottlenecks and handoffs

Go through the diagram and mark:

• handoffs between roles — every arrow from one lane to another. This is where tasks get lost and wait;
• manual data transfer — copying from one system to another;
• waiting — steps where the process stalls until someone replies;
• rework and loops — when work is redone because of errors;
• branches without rules — decisions made "from experience".

For each problem, note how often it happens and what it causes. Use real data if you have it, or label the figure honestly as an estimate.

Step 4. Draw the to-be process

The target diagram removes unnecessary steps and handoffs and splits the remaining ones into:

• automatic — the system does it (create a deal, send an invoice, remind);
• manual with system support — a person decides, the system suggests and records;
• fully manual — things not worth automating.

Do not automate everything. Sometimes it is enough to remove a step or agree on a rule.

Step 5. Turn the map into input for developers

For each step of the target diagram, describe:

• who performs it (role) or what triggers it;
• what data comes in and what comes out;
• rules — branch conditions, deadlines, constraints;
• exceptions — what to do when something goes wrong;
• notifications — whom to notify and when;
• integrations — which systems need to exchange data.

Attach the as-is and to-be diagrams, a list of roles and samples of real documents. Developers can estimate this package and turn it into a technical specification.

Common mistakes

• Mapping the process from the policy rather than from reality.
• Drawing in too much detail — the diagram becomes unreadable.
• Skipping exceptions: they often take a large share of development time.
• Not agreeing on the target diagram with the people who will work in it.