Automate the report, not the judgement

A weekly report usually has two halves that get discussed as one thing. There is the assembly — exports, joins, formatting, the same remembered corrections every week. And there is the reading: the paragraph at the top that says what happened and what to do about it. Automation should take the whole of the first half and none of the second.

The corrections are the project

Reproducing the exports is an afternoon’s work. What takes weeks is the set of manual fixes the analyst applies without thinking about them — the branch that reports in different units, the customer whose code changed in March, the row that always has to be moved. Each one has to be traced to a cause and then either fixed upstream or written down as an explicit rule.

If you skip this, you have not automated the report. You have automated a draft that still needs an hour of hand-finishing, which is the worst of both arrangements.

Run both versions until they agree

Never cut over on the strength of one matching week. Run automated and manual side by side for three or four cycles and compare. In my experience the discrepancies that surface are about as likely to be in the old manual version as in the new one — which is itself worth knowing, and much easier to say out loud while both still exist.

What “ready in the morning” changes

The obvious gain is the four hours. The quieter one is availability: a report that assembles itself can run on a Wednesday, so people start asking questions between cycles instead of saving them up. And it appears while its owner is on holiday, which the manual version never did.

Keep the commentary human. A report that arrives finished but unread is not an improvement — it is the same work, moved.