Where Should You Start When Digitizing Manual Operations?

The operations team has a spreadsheet. It has forty columns; some rows are yellow, some are grey. One person knows what yellow means. When that person is on leave, the team isn't waiting on the spreadsheet — they are waiting on them.

Digitisation projects look at that spreadsheet and assume the work is straightforward: turn the fields into a form, move the data into a database, build the screens. That work can be done, and usually finishes on schedule. The problem is that what finishes doesn't work.

Because that spreadsheet isn't a data store. It is an unwritten specification.

Paper and spreadsheets are where the rules are kept

If a manual operation has run for any length of time, many rules nobody wrote down have accumulated inside it. Not being in a document, they end up embedded in the tools being used.

Colour is a state machine: yellow means "on hold", grey means "cancelled", red means "urgent" — and that definition is written nowhere. A column nobody fills in is the residue of a rule no longer applied. A cell where the formula has been overwritten by hand shows how exceptions are handled. The date in the filename explains how versioning works.

So the first task in digitising isn't design, it's reading. Going through the existing tools — what each column is for, when it was last used, which cells were edited by hand — is a few days of work, and usually yields more rules than the interviews.

Look for the decisions, not the steps

The most common mistake in process discovery is writing the work down as steps: the request arrives, it is checked, it is approved, it is recorded. That list is accurate and teaches almost nothing.

What teaches is the decisions. Every point where somebody acts "depending on the situation" is an unwritten rule. Why was this request expedited? Why did this discount go through without being questioned? Why was this customer exempted from the check?

Collected together, the answers to those questions are the system's real requirement list. The undefined rules described in the automation piece live exactly here: most behaviour taken for an exception turns into a rule the moment it is asked about.

The critical knowledge usually sits with one person

Every manual operation has one person who genuinely knows how the work runs. They apply the rules, handle the exceptions, and mostly don't regard it as expertise — to them it is just their job.

That is where digitisation's biggest risk sits. If that knowledge doesn't make it into the system, the work still falls to them after go-live, only now in spite of the system. The team quickly reverts to the old method for anything the system can't accommodate.

The practical way to extract it isn't asking them to describe the process but walking through several real cases end to end. Asking "what did you look at here?" at the moment a decision is made yields far more than the summary they would give in a meeting.

A rule you don't recover comes back as "the system can't do this"

Missed rules don't disappear. After go-live they return as a familiar sentence: the system doesn't handle this case.

That sentence is usually mistaken for a missing-feature request. Most of the time it isn't — it is a rule that already existed in the process and never reached the system because nobody discovered it. If there are few, they get added later. If there are many, the team stops waiting and carries on in the spreadsheet; the system becomes the place the result is recorded, and nothing more.

Which is why the measure of success in a digitisation project isn't the scope being completed but how few rules were missed.

Where the work happens decides what the screen can be

When the digital counterpart of a manual operation is designed, the assumed user sits at a desk. These jobs are frequently done under quite different conditions.

Standing in a warehouse, wearing gloves, operating a terminal one-handed. Out in the field, somewhere the connection drops. At a shift change, on a shared screen three people use in turn. On a production floor, in noise, at speed.

Those conditions decide what the interface can be, and are hard to correct afterwards. A forty-field form is tedious at a desk and unusable in a warehouse. A system requiring a separate login per transaction ends with everyone sharing one account, or with nobody using it.

So part of the discovery work belongs where the work is done, not in the office. An hour of observation shows more than ten questions would — because people don't think their own working environment is worth describing; to them it is the already-known part of the job.

Why the spreadsheet still wins

The most common reason a digitised process drifts back to a spreadsheet isn't that the system is missing something. It is that the system is rigid.

In a spreadsheet a new column takes five seconds. When something unexpected comes up, the user invents their own solution: they add a note, colour a cell, open a temporary column. When the process changes, the spreadsheet changes the same day.

The same need becomes a development request and waits in a queue. As the wait grows the user steps outside the system to do their job — not a discipline problem, but the consequence of work having to continue.

The design principle that follows: a system must be flexible where the process changes. A free-text note, a user-added tag, or the ability to mark a case non-standard and carry on is often worth more than the next development cycle — and those marked cases produce the next list of rules.

Where to start: where pain meets clarity

Two criteria are used to choose a starting point, and neither is sufficient alone.

The first is friction: which process loses the most time and produces the most errors? As described in the transformation piece, this shows where the value is.

The second is clarity: how recoverable are the rules? A process that hurts a great deal but whose rules sit entirely in people's instincts is a poor candidate for a first project — it will take a long time and its result will be arguable.

The right place for the first piece of work is where those two intersect: a process producing visible pain whose rules are defined enough to be written down in a few days. There is a strategic benefit too — whether the first project delivers determines the budget for the ones after it.

Don't drop the paper immediately, but set an end date

Running the old method alongside the new system for a while is necessary for verification in digitisation: comparing records entered into both the spreadsheet and the system in the same week makes the missed rules visible straight away.

But that period needs an end date. Any parallel period without one becomes permanent; two records are kept, which one is authoritative becomes unclear, and eventually the easier one wins. Once verification is done, the old route has to be actually closed — the observation from the transformation side holds here too: while two paths are open, habit wins on a busy day.

In closing

Digitising a manual operation isn't moving existing work onto a screen. It is writing that work down for the first time — because until now it was never written down anywhere.

So the most valuable output of the project is often not the software but the list of rules that emerges. That list determines what the system does, and it also takes the process out of one person's memory.

The answer to where to start follows from that: not from the most impressive process, but from a real source of pain whose rules you can actually recover. In our enterprise software and automation work, the first delivery is usually not a screen but the list of rules nobody had written down before.