The hidden cost of a system nobody owns

Every automated workflow in a business is quietly owned by somebody, whether or not anyone has said so. Someone notices when it stops. Someone knows why it does the odd thing it does on the last Friday of the month. Someone gets asked.

When that person is named, resourced and expecting the responsibility, the system is maintained. When they are not — when ownership defaults to whoever happens to be closest — the system decays in a specific and predictable way.

How unowned systems fail

They rarely fail loudly. A loud failure gets fixed. What actually happens is slower.

The business changes — a new supplier, a renamed field, a different document format — and the automation keeps running against assumptions that are no longer true. Its output degrades slightly. Someone notices, works around it manually, and does not report it because it is easier to fix their own case than to raise a ticket.

Six months later the workaround is the process, the automation is a step people route around, and the business is paying for both.

Software you cannot see failing is more expensive than software that crashes. A crash gets fixed on Tuesday.

What ownership actually requires

It is less than people fear, but it is not nothing, and it needs to be explicit.

• A named person, not a team. Teams do not notice things; people do.

• Time in their week for it. An owner with no allocated time is a nominee.

• A way to see what the system is doing — volumes, failures, cost — without asking a supplier.

• A standing sample check. Someone looks at a handful of real outputs on a fixed rhythm and asks whether they are still good.

• A route for reporting oddness that is faster than working around it. If the workaround is cheaper than the report, you will get workarounds.

The supplier question

It is entirely reasonable for a supplier to run and maintain a system. What is not reasonable is a situation where nobody inside the business understands it well enough to judge whether it is still working.

The test is simple. If the supplier disappeared tomorrow, could you say what the system does, see whether it is running, and get someone else to take it on? If the answer is no, the dependency is not a commercial arrangement — it is a single point of failure with an invoice attached.

Budget it at the start

The practical fix is unglamorous: decide who owns it before it is built, and treat that as part of the project rather than something to sort out at handover.

Projects that cannot name an owner are worth pausing. Not because the idea is bad, but because a system nobody is accountable for will produce a year of value and then quietly stop, and the business will conclude that the technology was the problem.