The process runs on paper, a WhatsApp group and one spreadsheet. Digitised without making the fast path slower.

Five ways a process tells you it has left the system

Nobody books a call about digitisation. They book a call about one of these, after it has already cost them something.

1. EvidenceThe record exists, in a photo in a WhatsApp group

   Somebody photographed the signed docket and posted it to the group, so the work is proved. Finding it again months later means scrolling back through a chat full of other photographs, and the person who posted it has left.

2. OwnershipThe spreadsheet has one owner and no history

   It is the real system of record and everybody knows it. There is no version history worth the name and no record of who changed a cell, so when the owner is on leave the process runs on guesswork.

3. AuditA compliance request means a week of reconstructing what happened

   The answer gets assembled from email, a chat thread and somebody's memory of a phone call. It is usually correct. It is never quick, and it is never assembled the same way twice.

4. RejectionThe last system was slower than paper, so the floor went back to paper

   Now you have both. The system is updated from the paper at the end of the shift, which means the screen is always behind the yard, and the people who have to reconcile them trust neither.

5. BlindnessNobody can say how long a step takes

   Not because it is hard to measure, but because it was never recorded. Every conversation about capacity is a conversation about opinions, and the most senior opinion wins.

From the sentence on the first call to the part of the work it becomes

The complaint arrives as an operations problem with a date attached. Each one belongs to a different part of this job, and they need doing in a particular order.

Left is how the problem gets described. Right is the part of the work it turns into. The last row is the one that gets cut from scope first and missed hardest afterwards.

The process in the SOP, and the process people follow

Digitising the documented process gets you a system nobody uses. The rows worth arguing about are the ones where the two sides do not match.

An illustration of the shape, not a real client process. The step names change every time, the pattern does not: a signature that happens in a batch after the fact, an exception that lives in a phone call, and one report in the SOP that nobody has produced in a year and nobody has missed.

Three honest destinations for a step

Not every step belongs on the system, and saying which ones do not is part of this work rather than a caveat at the end of it.

1. On the systemThe step that is a written rule with a record attached

   Fixed thresholds, allocations by a stated rule, the same check made the same way every time. These belong on the system because software follows a written rule exactly, on every job, and leaves a record without being asked to.

2. AssistedThe step where a person decides and the system remembers

   The system shows what is known, the person makes the call, and the reason is captured in the same action rather than in a separate form afterwards. Judgement on the floor belongs here, and forcing it up a tier is what makes people distrust the whole thing.

3. Left aloneThe step that is a conversation and should stay one

   The handover at shift change, the walk along the line, the call to a supplier who is also a neighbour. Putting a form in front of these does not record them, it adds a form and loses the conversation.

Every step in your process gets one of these three, written down with the name of the person who agreed to it. The third column is the one that stops a digitisation project from quietly making the operation worse.

The work, in the order it has to happen

The sequence matters more than the tooling. Skipping the first box is how a project ends up faithfully automating a process nobody follows.

1. 01Watch the process being done

   Not a workshop with a whiteboard. Somebody stands where the work happens and follows a real job from the first form to the record it ends up in, including the parts the SOP does not mention because they were invented to get around it.

2. 02Write down both processes

   The one in the document and the one people follow. The gap between them is the project. Some of that gap is drift worth removing and some of it is the reason the operation works at all, and telling those apart is the whole skill.

3. 03Decide what should not be digitised

   Every step gets one of three decisions: onto the system, assisted by it, or deliberately left alone. The steps that stay manual are named and written down, so nobody adds them back in month four believing it was an oversight.

4. 04Put capture where the work happens

   On a phone, in a hand, offline, with the fewest taps we can get the common case down to. If recording the job takes longer than doing the job, the record will be invented at the end of the shift and you will have paid for worse data.

5. 05Move the process across in front of people

   The new path runs alongside the old one on real work, with the supervisor watching. The old path is retired when the people using it agree it can be, not on the date in the plan.

Capture designed for an aisle, not a desk

The person recording the work is standing up, holding something, and possibly wearing gloves. Every decision below follows from that rather than from what looks good in a demo.

1. Offline firstThe signal drops, the work does not stop

   The record is written on the device and syncs when there is coverage. No signal is ordinary in a cold store, a basement or a site with one bar, and designing for it as the exception is how a shift of jobs goes missing.

2. ConflictsTwo devices, one job, no silent overwrite

   When the same job is edited in two places the system says so and shows both versions, rather than quietly keeping whichever synced last. Silent last-write-wins is how offline capture loses a day of counts without anyone noticing.

3. Tap countCounted, because it decides adoption

   The number of taps to record the common case is a design target we set at the start and hold ourselves to, not something discovered after launch. The rare case is allowed to be slower, and usually should be.

4. InputScan, photograph, pick from a list, and only then type

   A barcode beats a list and a list beats a keyboard, especially with gloves on. Free text stays where judgement genuinely belongs, because free text is where the reporting you wanted goes to die.

5. DevicesStart with the phone that is already in the building

   Ruggedised hardware is sometimes right and often a way of postponing the project. We start on what people already carry and specify hardware once the work has proved it is needed.

What the trail has to answer before we call it digitised

A record that cannot answer these will be reconstructed by hand the next time somebody asks, which is the situation you are paying to leave.

1. 01Who did it, and who approved it

   Named people, not a shared login on the terminal by the door. A shared login means the trail says the warehouse did it, which is not an answer an auditor can work with.

2. 02When, in the order it actually happened

   Timestamps taken at the point of capture, so a record made at the bench and a record typed up at the end of the shift can be told apart rather than both reading as six o'clock.

3. 03What it looked like before it was changed

   Amendments are kept as amendments, with the previous value and the reason. Overwriting a field destroys the only evidence that a decision was ever reconsidered.

4. 04The evidence attached to the record, not beside it

   The photograph, the signature and the scanned docket held against the job they belong to, rather than in a shared folder organised by date that somebody has to search.

5. 05What the person was allowed to do at the time

   Permissions change, people move roles. Being able to show what somebody was authorised to do on the day, not what their account can do today.

6. 06Exported by your team, without ringing us

   Your people produce the pack for an auditor from the system itself. If answering a compliance request still needs a developer, nothing has actually improved.

This list gets written for your process specifically during the Week 1 audit. Two calls, a fixed fee, and you keep the one-pager whether or not the rest of the work goes ahead.

Rolling it out so the floor does not quietly go back to paper

This is where these projects actually die, and they die quietly. Nobody announces that they have stopped using the system.

1. 01Start with the shift that hates the current process most

   Not the most compliant team, and not the most senior. The team carrying the worst workaround has the strongest reason to make the new path work, and they will tell you plainly and early when it does not.

2. 02Run both paths on the same real work

   For an agreed period the job is recorded both ways and the two records are compared. That comparison is what proves the new path is complete, and it convinces a supervisor in a way that no amount of training will.

3. 03Time the common case on the floor, with a stopwatch

   If the new path is slower than the paper it replaces, we fix that before rolling any further. A system that costs an operator time on every job gets worked around whatever the policy says, and nobody announces the workaround.

4. 04Train the person the others copy

   Every shift has one and it is rarely the supervisor. Once that person uses the system without complaining about it, the rest of the shift follows without being asked to.

5. 05Take the paper away on a date people agree to

   Leaving the paper path available as a fallback means the paper stays the real path. It gets removed deliberately, once both paths have been compared and the gaps closed, rather than on the go-live date in the plan.

6. 06Watch the fallbacks once the paper has gone

   Every workaround is a design note. Reverting to the sheet, the photograph or the phone call gets recorded, and the ones that keep recurring go back into the build instead of into a reminder about policy.

What the first six weeks look like on a process

Three phases, the same as every engagement here. What differs on this kind of work is what has to be true by week three.

1. Week 1The audit, fixed fee

   Two calls, and one real job followed from the first form to the record it ends up in. You get a one-pager naming the gap between the documented process and the one people follow, what that gap is costing you, and the order to close it in. Yours whether or not we go further.

2. Week 2The first slice is chosen

   A pod of three starts on one process end to end, usually the one carrying the worst workaround rather than the one that demonstrates best. The demo-friendly screen teaches you nothing about whether anybody will use it at six in the morning.

3. Week 3It is in somebody's hands

   Software a real user can open, on a real device, with real jobs in it. This is the week you discover that the step you were told is optional is not optional, which is exactly why it is not week eight.

4. Weeks 4 to 6Both paths run, then one is retired

   The new path runs alongside the paper on real work and the two are compared before anything is switched off. Across our engagements the median time to a first production-grade artefact is six weeks.

5. Week 7 onwardsOperate

   Quarterly reviews and on-call governance. On this kind of work the reviews are mostly about workarounds: what people have started doing around the system, and what each one says about a step we got wrong.

What we have actually delivered

We have not published a named process digitisation case yet, so these are firm-wide delivery figures. We will say on the call which of them came from work that looked like yours.

There is no client name on this page

Worth explaining rather than papering over, because you will notice it anyway.

The ones that come up on almost every first call about this work.

• The moment an app can change data, it owes you an audit trailThe first write-back button is the cheapest moment to get identity, permissions, an append-only log and a reversal path right. Every later moment costs more.
• Building around an ERP you are not allowed to changeThe customisation is refused, the upgrade path must stay clean, and the work still has to happen. What survives is a satellite, and a record of who owns each field.
• Some questions need a button, not another chartA report can tell you fourteen orders are stuck. It cannot let anyone unstick them, which is why the work quietly moves into a spreadsheet you never see.