What happens to your processes when the person who runs them leaves?

Most finance teams have a person whose holiday is planned around month end. They built the reconciliation workbook years ago, they wrote the macros only they understand, and they carry a mental list of which supplier always invoices in the wrong currency. The process works because they run it. When they're off sick for a week, the report is late. When they hand in their notice, someone spends their last month trying to write down what they do, and finds out how much of it was never written anywhere.

This risk rarely makes the risk register, because nothing has gone wrong yet. It shows up later, as a late close, a missed rebate or a customer invoiced twice, months after the person has gone. We think it's also one of the cheaper risks to reduce, if you start while the person is still there.

Why these processes end up with one person

Nobody designs a process to depend on one person. It happens because the business grows faster than its systems. The ERP doesn't produce the report the board wants, so someone builds it in a spreadsheet. A customer needs a pricing exception, so someone adds a column. Each fix is sensible on the day. Five years later the month-end pack depends on a workbook with forty tabs, three linked files and a macro that breaks if a column moves, and one person knows the order to run it in. It's one of the reasons the back office grows faster than revenue: every workaround needs someone to keep it going.

That person is usually good at their job and often proud of the workbook, with reason. The rules of the process, such as which accounts to exclude, which customers get which discount and what to do when a figure doesn't match, live in their head and in formulas nobody else reads.

How to find the processes that depend on one person

Ask your managers three questions about every recurring process in their area:

• What happens when this person is on holiday? If the work waits until they're back, or they log in from the beach to do it, you've found one.
• Could someone else run it next week using only what's written down? Having watched it once doesn't count.
• Where do the rules live? If the answer is a spreadsheet on one person's drive, a set of macros, or "she just knows", the rules are at risk.

Start with finance and operations, where the reporting cycle makes the dependency easy to see: month-end close, management accounts, commission, rebate and pricing checks, payroll inputs and stock reconciliations. Customer service and sales ops have them too, often as the one person who knows how to fix the CRM when an import goes wrong. Rank what you find by two things: how much it would cost if the process stopped for a month, and how likely the person is to leave, retire or burn out. Ask about the last one directly. People usually tell you.

Write the steps down while they're still here

The first fix costs nothing but time. Sit with the person through one full run of the process and write down every step as they do it: which file they open, what they check, what they do when something doesn't match. Record the screen if it helps. Then have someone else run the next cycle from the notes while the owner watches and corrects.

The second run is where the gaps appear. The notes say "adjust for the timing difference" and the stand-in has no idea what that means, which tells you there's a rule that has never been written down. A gap found while the owner is there takes minutes to close. The same gap found after they've gone can take days.

Writing it down buys you time. It doesn't fix the process, because the rules still live in a workbook that one person maintains, and the notes will be out of date by the next year end.

Move the rules into a system with a log

The lasting fix is to take the rules out of the spreadsheet and put them in a system that runs them the same way every time and records what it did. For a month-end bank reconciliation, the system pulls the bank and ledger data, applies the matching rules, lists what it matched and why, and sends the items it couldn't match to a named person with both sides attached.

Three things change. The rules become visible: anyone with access can see that invoices from a particular supplier are converted at the invoice-date rate, and a manager approves a change to that rule instead of discovering it. The work is logged, so when the auditor or a new finance controller asks why a figure is what it is, the answer is in the record. And the process belongs to a team, because running it now takes someone to review the exceptions, and anyone trained can do that.

This is where we think automation earns its keep. It saves hours, and it also turns a process into something the company owns, can see and can hand to the next person. The same applies to the figures someone re-types from one system into another every week, which we cover in stop re-keying between systems.

A worked example from month end

Take a hypothetical manufacturer with 400 staff. Its management accounts depend on a commission and rebate workbook kept by one finance analyst, who is going on parental leave in three months. The finance controller asks her to walk a colleague through a full month's run, and between them they write down twenty-three steps and eleven rules, four of which surprise the controller. Over the following months the rules move into a system that reads the sales data from the ERP, calculates commission and rebates, and sends anything outside the rules to the controller with the order and the customer's terms attached. By the time the analyst leaves, her colleague runs month end by reviewing a short list of exceptions. When she comes back, she's the one who suggests the next process to move.

Who owns the process after the move

A system only reduces the risk if someone owns it. Give each automated process a named owner in the team that uses it, a deputy, and a short routine: review the exceptions, check a sample of what ran without any, and approve changes to the rules. Keep a note of what changed and why alongside the log.

Systems drift as well. A new product line, a changed price list or a new bank account means a rule needs updating, and someone has to notice. That's the part of operating a system that gets forgotten when nobody is named to do it, and it's how a process slides back into one person's hands.

What to do this week

1. Ask each manager which recurring process stops when one person is away.
2. List what you find, with two notes against each: what it would cost if it stopped for a month, and who runs it.
3. For the top one, book a session to sit through a full run with the owner and write down every step.
4. Name a second person to run the next cycle from those notes.
5. Decide whether the rules should move into a system, and who would own it.

Get the next article when it's published.