How to Digitize Manual Business Processes

Most process digitisation projects fail in the same way. Someone recreates the existing paper form on a screen, deploys it, and discovers within a month that people have gone back to the paper — because the screen was slower and answered none of the questions the form was really being used for.

Digitising a process properly means deciding who owns each step, what must be true before it can move forward, and what the system should do on its own. The screen is where those decisions surface. It is not the work.

Step 1 — Map the process as it is actually run

Not the process as documented. The process as run, including the workarounds. Every operation has informal practices that exist because the official process could not handle a real situation, and those practices are the most important thing you will learn.

The way to find them is to sit with the person doing the work rather than their manager, and ask what happens when things go wrong. 'What do you do if the material has not arrived but the customer needs it tomorrow?' will teach you more than any process document.

Step 2 — Find where information is re-entered

Trace one piece of information through the whole process — an order quantity, say — and mark every place it is written down again. Each of those points is a cost: a chance to differ, a delay, and a reconciliation somebody has to do later.

In most manual processes there are between three and six re-entry points. They are usually where the largest and most immediate savings are, and they are also the easiest thing to explain to the people who have to change how they work.

Step 3 — Decide the rules before designing any screen

This is the step that is most often skipped and that most determines whether the result survives. For each step in the process, write down:

• What is mandatory, and what may legitimately be left blank.
• Who may override a rule, and whether the override is recorded.
• What must have happened before this step is permitted at all.
• What happens when the normal path cannot be followed — the exception route.
• Who is notified, and what happens if nobody acts.

Step 4 — Capture data once, where the work happens

The single most important design decision is where data enters the system. It should be entered by the person doing the work, at the moment they do it, and never typed again downstream.

This usually means the form has to work somewhere uncomfortable — a store on a shared tablet, a site on a phone with poor signal, a machine where the operator is wearing gloves. Design for that context specifically. A form that requires an office and five undisturbed minutes will be filled in later, from memory, in round numbers.

Step 5 — Automate what needs no judgement

Once data is captured once and the rules are written down, a set of things can happen without anyone deciding them: calculations, routing to the next owner, notifications, document generation, reminders and escalation.

Be deliberate about what stays human. Anything requiring genuine judgement — a commercial decision, a quality concession, a customer commitment — should remain a decision a person makes, with the system ensuring they have the context to make it and a record that they did.

Step 6 — Make the old way stop

At some agreed point, the new process has to become the only process for that piece of work. If the paper register and the system run in parallel indefinitely, the register wins, because it is familiar and it is faster for the person doing it.

That said, if a team keeps a parallel sheet after go-live, resist the urge to treat it as indiscipline. In our experience it almost always means the system is missing something real that the sheet provides. Go and find out what it is.

What good looks like after three months

• The process runs the same way whoever is on shift.
• Nobody is re-typing information that already exists in the system.
• You can say how many items are at each stage right now, without asking anyone.
• You can see the average and worst-case time per stage — which usually reveals that the bottleneck is not where everyone assumed.
• When something goes wrong, you can trace what happened rather than reconstruct it.