The automation still runs every Monday, and nobody left knows what it does

Every Monday morning a spreadsheet in a shared folder gains a new row. Nobody in the building can tell you what puts it there. The person who set it up left in March, the row has been right every week since, and so the question has never come up.

That is the comfortable version.

The uncomfortable one is the same arrangement eighteen months on, where the figure in that row has been wrong since July and the report built on top of it has gone out to a customer eleven times.

Nothing has gone wrong, which is why nobody has looked

An automation that breaks loudly gets fixed the same day. The ones that cost money fail quietly, and there are a few different ways to do that.

It can simply stop. A password expires, a supplier redesigns a form, a folder gets renamed in a tidy-up, and the thing that ran every Monday does not run. Because it has never needed attention, nobody is watching for its absence, and the gap gets noticed by whoever was relying on the output, usually several weeks later.

Or it keeps running while the world around it moves. The spreadsheet gains a column, so the figure it copies is now the one next door. Nothing errors. The output is confidently wrong, which is considerably worse than missing, because missing gets investigated.

The third kind is the one people find hardest to credit. It is still doing exactly what it was built to do, faultlessly, and the reason for doing it ended two years ago.

Where the unowned ones actually live

They are rarely in the places a technical audit looks first. In a ten-person firm they are mostly these:

• A rule in somebody's mailbox that files, forwards or replies
• A scheduled task on a desktop under a desk that has to stay switched on
• A flow or script running as one person's account rather than the business's
• A macro inside a workbook that somebody opens on the first of the month
• A form posting somewhere, set up by a supplier whose engagement finished
• A report subscription emailing a list of addresses, two of which have left

There is an awkward collision here with advice every firm already follows. Offboarding says disable the leaver's account promptly, and that advice is right. But anything running as that account stops when you do it, and nothing tells you in advance which things those were. The dependency turns up a fortnight later, when something nobody had on a list stops arriving and no one can connect the two events.

Both halves of the advice are correct. They have to be done in the right order, and the order is to find out what runs as that person before the account is closed.

The dependency turns up a fortnight after the account was closed, when something nobody had on a list stops arriving.

The inventory is a morning's work, not a project

The reason it is a morning rather than a project is that you are not mapping systems. You are collecting a list of things that happen without a person, and in a small firm almost all of them are known to somebody. Just not to the same somebody.

1. 01Ask everyone what arrives on its own, and what they would miss on a Monday
2. 02Work backwards from each output to whatever produces it
3. 03Check what accounts things run as, not just what the things are
4. 04Write five lines on each one
5. 05Put a date against it

Five lines is the whole specification: what sets it off, what it reads, what it changes or sends, who outside the business receives anything from it, and whose name is against it now. That last one is the only field that matters more than the others, and it is the one usually left blank.

Not a diagram. A diagram is a project, it is out of date within a month, and the thing anybody actually needs at half past four on a Friday is a name.

Switching one off is the cheapest test you will run

For anything on that list that nobody can account for, there is a test better than archaeology. Turn it off on a Tuesday morning, with everyone in, having told people you are doing it. Then wait a fortnight, or a month if it ran monthly, and see what complains.

An hour of attention, and you learn what depended on it. The alternative is finding out by accident, at whatever moment it chooses.

Not everything qualifies, and this is where the test earns its caution. Anything touching a payment, a filing deadline, a regulator or a promise made to a customer gets written down rather than experimented on. Those you leave running, document properly, and give an owner. The experiment is for the long tail of things whose purpose has genuinely been forgotten, which in most firms is the majority of the list.

Then leave it alone for a year

Once each one has five lines and a name against it, the review is annual for nearly everything, plus whenever something adjacent changes: a supplier, a system, a person leaving.

The few that cannot survive that treatment, because they break every time anything moves, are telling you something useful. Those are the candidates for rebuilding as something the business owns rather than something it inherited. That tends to be a shorter piece of work than people fear, because the hard part was never the building.

What we actually do about this

One of the more useful things we have done for a client had no software in it. We mapped every recurring process as a workflow and wrote each one up as a standard operating procedure, so that every handoff had an owner. The automations were the straightforward half of that exercise. Working out who owned the ones already running was the work.

We have argued before that most of what people want automated is not worth automating, and the reason sits in this post. The cost of an automation is not building it. It is owning it for as long as it runs, and an automation nobody owns is not free, it is unpriced. If the thing doing the work is a spreadsheet that has quietly acquired users, that is its own question and worth taking first.

If you have found something running that nobody can explain and would rather not switch it off to find out, that is a sensible conversation to have before the fortnight is up.