Mapping Processes and Manual Workarounds

Mapping processes means writing down, in order, the steps a service follows to deliver its outcome, and mapping manual workarounds means writing down what people do by hand when a system in that chain is unavailable. Both matter because a service rarely fails cleanly. More often, one step stalls and staff improvise. If the improvisation is planned, authorised, and recorded, it can keep customers served while recovery proceeds. If it is invented on the spot, it may create errors, lose records, or breach a control that the automated step was quietly enforcing. The map should therefore show the normal process and the workaround side by side, with the limits of each made explicit.

A process map follows the service from the moment a customer request arrives to the moment the outcome is confirmed, noting each handoff between teams and systems. It should show where a decision is made, where a check happens, and where the process waits for something outside the firm, such as a supplier confirmation or a settlement cycle. It should also show what happens when a step fails: does the process stop, retry, queue, or pass to a person? Vague boxes labelled with team names are not enough. Each step needs enough detail that a responder can tell whether it has completed, what its output should be, and what to do if it has not.

Workarounds start as sensible responses to failure. Staff may take details by phone, record transactions on a spreadsheet, or process requests in a different order to keep a queue moving. The risk grows when a workaround is used repeatedly without review, because the checks built into the automated process may not survive the manual version. Duplicate entries, missed validations, and incomplete audit trails are common consequences. A workaround can also become the de facto process, with new staff taught the manual method as if it were normal, while the map still describes the automated route. At that point the map and reality have diverged, and the next incident will follow the wrong route.

A recorded workaround needs several facts: the failure it addresses, the steps staff should follow, the person who can authorise it, the checks that replace the automated controls, and the point at which it must stop and the normal process must resume. It also needs a way to reconcile afterwards, so that anything processed by hand can be matched back to the system of record once recovery is complete. That reconciliation step is easy to forget in the pressure of an incident and costly to reconstruct later. The map should therefore treat reconciliation as part of the workaround itself, not as an optional tidy-up task for quieter times.

A process step is only as resilient as the system and the people behind it. If a step depends on a single application, the map should show that application and its own dependencies alongside the step. If a step depends on a person with rare knowledge, the map should show that person and their cover. This cross-linking prevents a common blind spot: a process that looks robust on paper because it has many steps, but collapses in practice because several steps lean on the same system, the same team, or the same supplier. Tracing those shared supports is where process mapping earns its keep, because it reveals concentration that a simple flowchart would hide.

Walk the process with a failure inserted at a different step each time. Ask the team to follow the workaround exactly as written, including its checks and its reconciliation, and note where they hesitate or improvise. Hesitation usually points to a missing detail, an unclear authorisation, or a step that assumes access to a system that is also down. After the walk, update the map, not just the training notes, so the next team inherits the corrected version. Under DORA in the EU and under FCA and PRA policy in the UK, the ability to show that a service can continue or recover matters more than the elegance of the flowchart, and a tested workaround is stronger evidence than an untested one.