Before you digitize a process, draw it

"We want to digitize our process" is one of the most common requests we receive. It is also one of the easiest to get wrong, because the process people describe in a meeting is rarely the process that actually happens.

The official process and the real one

Ask a manager how a purchase request is approved and you will hear a clean sequence of steps. Ask the people who do it every day and you will hear about the exceptions: the supplier who always needs a phone call, the approval that happens by WhatsApp when the manager is travelling, the spreadsheet that tracks what the system cannot.

Those exceptions are not noise. They are where the real work — and the real cost — lives. A digital tool that ignores them will be bypassed within a month.

Draw it on one page

Our first deliverable in almost every project is a process map that fits on a single page. We keep it deliberately simple:

Swimlanes for each role involved, so hand-offs are visible.
Steps written as verbs: validate order, not order validation module.
Decisions as explicit questions with every possible answer.
Pain points marked directly on the map, in the words of the people who feel them.

If a process cannot be drawn on one page, it is either too big to digitize in one go or not yet understood.

Decide what not to automate

A map makes trade-offs visible. Some steps should be automated entirely. Some should be simplified before anything is built. And some should stay human, because they involve judgement that is cheaper to keep than to encode.

This is also where scope is won or lost. A clear map lets everyone agree on the first version — the smallest slice that removes the biggest pain — and leave the rest for later iterations.

Questions we ask while drawing

A good process map comes from good questions. These are the ones we come back to in almost every workshop:

What starts this process? An email, a phone call, a date in the calendar, a threshold being crossed?
Who is waiting on whom? Every hand-off is a place where work can stall unnoticed.
What happens when something is missing? The answer usually reveals a workaround — and a requirement.
Where is information typed twice? Double entry is the most reliable sign that systems are not connected.
How do you know it is finished? If nobody can say, the process has no clear end state, and the software will not either.
What would you remove if you could? People doing the work usually know exactly which steps add nothing.

We write the answers directly onto the map, in the words people used. Weeks later, when a developer wonders why a rule exists, the map still explains it.

From map to software

Once the map is agreed, it becomes the backbone of the build: roles become permissions, decisions become business rules, hand-offs become notifications and statuses. The data model follows from the objects that move through the process.

The result is software that feels familiar to the people who use it, because it was drawn from their work — not from a feature list.