Process mapping fundamentals: start without BPMN

First "as-is", then "to-be"

The most common misconception about process mapping is this: you need to know "how it should be" before you draw a map. No. You need to know "what is happening right now" first.

The "as-is" map shows how the process actually works today — not what the documents say. In many SMEs, order intake, invoicing or customer onboarding processes have not changed for years but are written down nowhere. This gap is the biggest risk when moving to automation: if you automate an undocumented process, you automate its errors too.

A concrete example: you want to automate your e-invoice process. But if you have no written answer to "who creates the invoice, who approves it, how it gets sent to the customer, what happens when a dispute arrives" — map that flow first. Sticky notes on a wall, a strip in Miro, or a four-column table in Excel is enough. You do not need to learn BPMN or buy Visio.

Once the as-is map exists, designing the "to-be" state becomes much easier. You see not what will change, but what stays the same. That grounds optimisation decisions in real data — not intuition.

Map your process in 1 hour: the 4-column approach

To map a process without setting up a complex tool, a four-column Excel table or a Miro strip is enough. Each row represents one step; the columns are:

1. Step — What is done? Short verb form: "create invoice", "wait for approval", "enter into system". 2. Who does it? Role name, not person name: accounting, sales rep, customer. 3. What is the input? What is needed for this step to start: form, email, approval, system record. 4. What is the output? What is produced after this step: document, notification, database record.

These four columns resemble a simple swimlane diagram and require no software knowledge. In a one-hour working session with two or three people who know the process, using sticky notes, you can fill the whole table.

A practical tip: use this method to document your invoicing process, registration workflows or personal data handling flows. The four-column table serves as both an internal audit record and a ready technical specification for future automation.

After completing the map, ask this question about each step: "Can this step be automated? Removed? Merged?" These three questions eliminate unnecessary complexity.

When a mapped process is ready for automation

Not every mapped process is ready for automation. Four criteria must be met before moving to automation:

1. Repetition rate: if the process repeats at least two to three times per week, the cost of automation becomes justifiable. For an exceptional task done once a month, automation is usually unnecessary.

2. Standardised input: if the inputs that start the process are standardised — a specific email format, form response or system notification — automation runs far more reliably. If inputs vary each time, a data standardisation step is needed first.

3. Amount of human judgment: if many subjective decisions are made at critical steps in the process, those steps must first be simplified or rule-bound. Automation can automate rule-based steps; not ambiguous decisions.

4. Error tolerance: if an error in the process leads directly to customer loss, legal violation or financial damage, comprehensive testing before automation is mandatory.

Processes that meet all four criteria are the most automation-ready. Setviva's approach: once the qualifying process is identified, we run a pilot test on a small dataset first, then gradually expand to full volume. No map, no pilot; no pilot, no scale.

Process mapping is the first step: after mapping, explore where to start your digital transformation and our sector-specific automation approaches.

The step most teams skip: talk to the people who do the work

The biggest reason process maps end up wrong is not lack of effort — it's asking the wrong person. A manager will describe the process the way it is supposed to run, often the way it was designed years ago. The person who actually processes the order, enters the invoice or answers the support ticket knows the version with the workarounds: the extra check they do because the system once failed, the second approval they seek informally because the official one is too slow. If your map only reflects what management believes happens, you will automate a process that does not exist.

Workarounds are not noise to filter out — they are the most useful signal in the whole exercise. A side spreadsheet nobody officially approved, a WhatsApp group used instead of the ticketing system, a printed form that gets re-typed into three systems: each of these marks a point where the official process failed to meet a real need. Note them on the map explicitly, with who created them and why. They usually point straight at either a training gap or an automation opportunity, sometimes both.

Do not try to map every exception. A map that tries to capture every possible branch becomes unreadable and nobody will maintain it. Instead, capture the main path plus the two or three exceptions that come up often enough to matter — a missing document, a rejected payment, a customer who changes an order after submission. Anything rarer than that belongs in a short "known exceptions" note, not in the flow itself.

Finally, pay closest attention to handoffs between departments, not the steps inside a single team. Most processes run smoothly within a department and break down exactly at the point where sales passes something to operations, or operations to finance. Mark every handoff on your map with a clear owner and an explicit expectation of what "done" looks like on each side. These handoff points are where miscommunication costs the most time today, and where automation usually pays back fastest once you do move to build something.