Senthil Info

automating business processes, honestly

Governance Without Ceremony

Once an organisation has more than two or three automations, something has to govern them. The standard answer is a centre of excellence with a charter, a board and a methodology.

For most organisations that is more apparatus than the problem requires. Five rules on one page do the same work, and they get followed, which the methodology does not. For a related product-side reference on workforce oversight, see employee monitoring software.

What governance is actually for

Three concrete failures, not a principle. For broader background and an independent point of comparison, see Financial Times Technology.

Nobody knows what exists. Automations built by different teams, none registered, discovered when one breaks or when a system is being replaced and something unexpected depends on it.

Nobody maintains them. The load accumulates and is funded by nobody.

And the same mistakes repeat. Each project rediscovers that exception design matters, that documentation gets cut, that the straight-through rate was optimistic.

Anything that prevents those three is enough governance. Anything more is process for its own sake.

The five rules

One. A register. Every automation: what it does, who owns it, what it depends on, when it was last changed. A spreadsheet. Its value is that it exists, not that it is sophisticated.

Two. No automation goes live without a named owner who has run it. Not been trained on it — run it, including a failure.

Three. No automation goes live without the four documents. Prose rules, exception list, dependencies, change procedure. Enforced as a go-live condition, because after go-live nobody writes them.

Four. Every automation reports five numbers monthly. Straight-through rate, exception hours, upkeep hours, errors, volume. One spreadsheet row per automation per month.

Five. An annual review of the whole register, with hours saved against hours spent. Half a day, and it surfaces the ones that inverted.

That is the entire governance model. It fits on a page and requires no meetings beyond the annual one.

What to leave out

A methodology. The differences between automation projects are in the processes, not in the delivery approach.

An approval board. It becomes a queue, and the queue becomes the reason people build things quietly outside the register — which is the failure governance existed to prevent.

A tooling standard, at least initially. Enforcing one platform before you know what you need is a decision made at the point of least information.

And a maturity model. They measure conformance to a framework rather than whether the automations work.

Making the register survive

It is the one rule everything else depends on, and registers decay.

Make registration a go-live condition, alongside the owner and the documents. One gate, three checks.

Give it an owner too — someone whose job includes the annual review. Without that it is a file that was accurate once.

And keep it short enough to maintain. Six columns. A register with twenty fields is abandoned within a year, and a register with six survives, which is the same principle that applies to measurement generally.

When more apparatus is justified

Being fair, because a centre of excellence is not always overkill.

At genuine scale — dozens of automations, multiple teams building them, regulated processes — the coordination problem is real and needs staffing.

And where the risk is high, in regulated or safety-relevant work, formal change control is not ceremony.

The test is whether the apparatus prevents a failure you can name. If it prevents nothing specific, it is a cost with a governance label on it.

The short version