Automation centre of excellence: governing what already works

An automation centre of excellence is the team that decides what gets automated, to what standard it is built, and who answers when something fails. It is not a project office: it exists so that a set of automations stays governable once it stops being a handful and becomes a portfolio.

Below: when it is justified, which decisions it concentrates, how to size it without inflating it, what to measure, the federated model, and where to start.

An organisation's first automations almost never have governance, and it is right that they do not: there are few of them, whoever built them knows them, and the cost of coordinating would exceed the benefit.

The problem arrives later, and always the same way. Nobody knows how many are running, two teams built the same thing separately, and the person who understood the most critical one has changed role.

When it is justified

There is no magic number, but there are three signals that tend to appear together. The first is that nobody can list from memory which automations are running. The second is that a change in one system breaks several at once and finding out takes days. The third is that teams have started building on their own, each with its own criteria.

Before those signals, a centre of excellence is anticipated bureaucracy. After them, its absence is already costing money — just on a budget line nobody looks at.

Which decisions it concentrates

What enters the portfolio. A single criterion for evaluating candidates, so that priority is not set by who asked first. Volume, measured manual effort, process stability and technical feasibility.

To what standard it is built. How credentials are handled, where errors are logged, how it is documented and what must exist before production. That is the difference between a maintainable portfolio and forty artisanal pieces.

Who answers when it fails. Every automation with a functional owner and a technical one. Without that, the one that breaks in December waits for January.

When it is retired. The least frequent decision and the most forgotten: a process that changed leaves automations that no longer apply, and keeping them costs.

How to size it without inflating it

The most common version of this mistake is building a large structure before there is a portfolio to govern. In most mid-sized organisations the centre of excellence starts as a part-time role and a written standard, not a department.

What cannot be missing from day one is the inventory: what exists, what it does, which systems it depends on and who answers for it. A well-maintained spreadsheet governs better than a committee without data.

The failure mode at the other extreme is worth naming too. A centre that reviews everything and builds nothing becomes a queue, and a queue is what teams route around. If approval takes longer than building, the standard will be ignored regardless of policy.

What is measured to know it is working

A centre of excellence that reports nothing ends up perceived as a formality, and that perception dismantles it at the next budget review. It pays to define three or four figures from the outset that get published and are not negotiated.

The ones that hold up are simple: how many automations are in production and how many were retired, what share failed this month and why, how many hours of manual work were released, and how long it takes between a team proposing a candidate and getting an answer.

That last one protects the centre from itself. If the answer takes months, teams will build outside it whatever the policy says, and governance will exist only in the document describing it.

The federated model, and why it usually wins

Centralising all construction produces a bottleneck: the centre becomes the constraint and teams go back to building outside it, now discreetly. Fully decentralising reproduces the original problem.

The middle ground that holds is federated: the centre defines the standard, reviews and supports; the teams build within that frame. The authority sits in the criteria rather than in the execution.

That governance rests on the same discipline that orders the rest of the technology operation, which is why it is worth looking at alongside managed services and the automation capability as a whole.

What it owns and what it must not

The clearest way to keep one of these bodies useful is to be explicit about what it does not decide. It owns the standard, the intake criterion, the inventory and the retirement call.

It does not own whether a given business process should change. That belongs to the area running it, and a centre that starts ruling on process design acquires enemies faster than authority. The distinction sounds fine and is very practical: "we will not automate this until the process is agreed" is a legitimate position; "the process should work this way" is not its call to make.

Nor does it own the budget of the areas it serves. A centre that also controls funding stops receiving honest requests, because teams learn to phrase proposals for approval rather than describe problems accurately.

The people question nobody schedules

A centre of excellence needs somebody who can say no to a senior stakeholder and make it stick. That is not a technical requirement and it is the one most often left unfilled, which is why so many of these bodies become advisory within a year.

It also needs somebody who understands the processes rather than only the tooling. The most expensive automation decisions are about which process deserves attention, and that judgement does not come from knowing a platform.

Both roles can be part-time. Neither can be absent.

There is a third that is easier to fill and easy to overlook: somebody who maintains the inventory as a habit rather than a project. It is unglamorous work and it is what every other decision depends on, because a governance body reasoning from a stale list is guessing with more ceremony.

Where to start if it does not exist yet

With the inventory, and with one decision: what criterion will be used to accept the next candidate. Those two things can be done in weeks and already change everybody else's behaviour.

A process automation assessment serves as the baseline, because it surfaces the candidate processes and their real effort, which is the raw material the centre will decide with. The teams coordinate from Bogotá and Mexico City, in the time zone of the operation they are governing.

One thing worth agreeing in that first month: what happens to the automations that already exist. Bringing every legacy piece up to a new standard is usually not worth it, and declaring that openly — new work meets the standard, existing work is brought up only when it is touched anyway — prevents the centre from opening with a backlog it cannot clear.

Frequently asked questions

What is an automation centre of excellence?

The team that decides what gets automated, to what standard it is built, who answers when it fails, and when an automation that no longer applies is retired. Its function is keeping a portfolio governable, not executing every project.

How many automations before one is needed?

It does not depend on the number but on three signals: nobody can list from memory what is running, one system change breaks several at once, and teams have started building each with their own criteria.

Should it centralise all construction?

Rarely. Centralising turns the centre into a bottleneck and teams end up building outside it. The federated model — the centre sets the standard and reviews, teams build within it — is the one that tends to hold.

What has to exist first?

The inventory: what automations exist, what they do, which systems they depend on and who answers for each. Without that, any committee decides blind.

What should it report?

Automations in production and retired, failure rate and causes, hours of manual work released, and time from a team proposing a candidate to receiving an answer. The last protects the centre from becoming a queue.

What roles are essential?

Somebody who can say no to a senior stakeholder and make it stick, and somebody who understands the processes rather than only the tooling. Both can be part-time; neither can be missing.