Business operations considerations for new finance systems

A new finance system gets planned and owned by finance, and that makes sense. The chart of accounts, the reporting structure, the compliance requirements and the sign-off all sit with the finance team, usually the FD or financial controller, because they are the people who understand what the system needs to do.

What it does not sit with, at least not by default, is everyone else who touches the system without being part of the project: the salesperson who raises an invoice, the ops manager who submits a purchase order, the person in another department who pulls a number out of finance every month for their own reporting. None of that is anyone's fault. It is simply a different job to the one the finance team is doing, and unless someone is explicitly holding it, it tends not to get held at all.

Why the risk sits outside the finance function

Finance teams are, rightly, expert in the accounting requirements: what the new system needs to record, report and reconcile correctly. They are not always positioned to see every place the old system was quietly relied on by people outside finance, because that reliance was never part of their brief to map.

That gap does not show up in the project plan. It shows up later, when someone outside finance finds that a report they used to pull no longer exists in the same form, or a workaround they built around the old system's limitations has nowhere to go in the new one.

The finance team can specify what the new system needs to do. They cannot always see everywhere the old one was quietly relied on.

Watch-outs from a business operations perspective

Who outside finance touches the system daily. Sales raising invoices, ops raising purchase orders, whoever approves expenses. Each of these is a workflow that changes on cutover, and each has an owner who is not in the finance project meetings.

Manual workarounds and shadow spreadsheets. These usually exist because the old system did not do something a team needed. It is worth asking why before assuming the new system automatically covers it. If nobody asks, the spreadsheet often just gets rebuilt around the new system instead of retired.

Approvals and handovers that cross departmental lines. Who signs off what, at what point, and does that sequence still make sense once the system changes. A sign-off step designed around the old system's quirks can easily get carried over unchanged simply because nobody owns the question of whether it should be.

Training and adoption for occasional users. The finance team will be trained properly, because that is what the project budget is for. People who touch the system lightly, a few times a month rather than every day, are the ones most likely to be missed, and the ones most likely to revert to the old way of doing things under pressure.

Reporting dependencies outside finance. Anyone who currently pulls a number out of the finance system for their own purposes, a board pack, an operational dashboard, a customer-facing report, needs to know whether that still works on day one, not find out when the report is due.

An illustrative example

Consider a business (illustrative, not a specific client) partway through a finance system change, timed to land alongside the new financial year. The finance project was well run: requirements gathered, data migrated, the finance team trained and ready. What nobody had mapped was that the operations team relied on a monthly export from the old system to build its own delivery performance report, a report finance did not use and had never been asked about. The export format did not exist in the new system. It took three weeks to notice, because the report was not due until month end, and by then the old system had already been switched off.

Nothing about the finance implementation was done badly. The gap was simply that nobody's job was to look at the system from outside finance, so nobody did, until a report went missing.

What this means in practice

None of this is a criticism of how finance teams run these projects. Specifying and implementing the accounting side well is a real skill, and it is reasonable that it takes most of the project's attention. The point is that the wider view, everyone else who touches the system, the workarounds that need a home, the approvals that cross departmental lines, is a different job, and it is easy for that job to go unowned in exactly the period when budget cycles, year end and other changes are already competing for everyone's time.

The useful habit is not a bigger project plan. It is making sure someone, formally or informally, is asking who else this touches, before go-live rather than after.