The difference between a process and a workaround
Ask an analyst to walk you through a returned payment, from the return file arriving to the customer getting their money back. Listen for the words "and then I just". Whatever follows them is rarely in the documented process.
A process, as we use the word, has an owner, sits somewhere people can find it, and is known to the teams on either side of it. A workaround is a step somebody added to get past a gap, such as a missing field or a report that does not exist. The person doing it knows about it, and possibly their team lead. Workarounds are often clever and almost always well intended, and plenty of operations would stop inside a day without them.
They are also invisible to everyone above the person doing them, which is where the trouble starts.
Why reporting does not show them
Operational reporting counts events the system records: cases opened, cases closed, time to close, breaches of the service level. A workaround happens in the space between those events. Say an analyst closes a refund case in twelve minutes, comfortably inside target. The report shows twelve minutes. It does not show the five of them spent copying a reference from the processor portal into the case notes, because the case system has no field for it, or the check against a personal list of merchants whose refunds have to be held.
That gap matters most when volume grows or people leave. The hidden time scales with volume while the reporting does not, so the first sign of trouble is usually a service level slipping for no visible reason. The dependency on individuals shows up the week the one person who knows the trick goes on leave. Workarounds also sit outside controls by definition. A manual step that nobody documented is a step nobody reviews, which is how a four-eyes check ends up being performed by one pair of eyes looking at an export.
A workaround becomes the process on the day somebody new is trained on it.
Where to look
Workarounds leave traces, and most of them turn up in a morning of looking.
Start with people. Sit with an analyst for half a day and write down every step they take that is not in the procedure, without reacting to any of them. The phrases worth listening for are "I just", "we usually" and "unless it is one of those". Ask what happens when they are off sick, and who covers.
Then look at artifacts. Personal spreadsheets, saved searches, email folders with rules attached, bookmarks pointing at a report in the old system, a shared inbox somebody works through by hand at four o'clock. The free-text notes field is a good place to look: if analysts type the same short code into notes on hundreds of cases, they are storing structured data the system gave them no home for. We wrote last year about the most common artifact of all, the spreadsheet that runs your operation.
Then look at the data. Gaps between system timestamps show where work happens off-system, so if a case is opened at 09:02 and the next recorded event is at 09:31, something occupied twenty-nine minutes. Reopened cases, adjustments posted by the same two people every month and exports downloaded on a schedule are all worth a question.
Putting a price on one
Estimate the time per occurrence and the frequency, then add what it risks. Say a step takes four minutes and happens 150 times a day. That is ten hours a day, more than one full-time person. None of it appears in the headcount plan. The figures are illustrative, but the arithmetic is the part people skip.
Then ask whether the step bypasses a control, whether it depends on one person, and what happens if it is done wrong. A two-minute step that skips an approval on outgoing payments deserves more attention than a twenty-minute step that only irritates the team doing it.
Four ways to resolve one
Once a workaround is visible and priced, there are four sensible outcomes, and the cost tells you which.
Formalize it when it is better than the documented path and cheap to control. Some workarounds are simply the right way to do the work, invented by the people closest to it. Write it into the procedure, give it an owner, add the check it needs, and make it reportable, ideally by giving the system the field the analysts were faking in the notes.
Fix it when the volume is high or the error rate is real. That usually means a configuration change or a small integration, and it belongs on the change backlog with its hours-per-week figure attached, so it can compete with feature work on the numbers, which is the only argument that reliably wins.
Remove it when the reason has gone. Some workarounds compensate for a problem fixed two releases ago, and nobody told the team. These are the cheapest wins available to you.
Tolerate it with an expiry date when the fix is already scheduled. This category grows fastest after a large project, and we covered how to track it in implementation debt. The date is the part that does the work. Without one, the temporary arrangement is what the next joiner learns on their first morning.
Pick one queue this month and spend a morning watching it. Expect a longer list than the procedure suggests, and expect to be impressed by two or three items on it.
Discuss your operations
