Every automation programme that grows past a dozen bots arrives at the same fork. Either a centre of excellence is set up, or the estate becomes a collection of unrelated bots with different standards, no shared components and no one who can say what is running. The CoE is the right answer. The trouble is that it is often set up in a way that slows everything down, and the business routes around it. A CoE that scales is one that makes delivery faster, not slower.
Choose the operating model deliberately.
Three models are common. The centralised CoE builds everything itself. It gives the highest consistency and the longest queue. The federated model lets business units build, with the CoE setting standards and reviewing. It scales but needs real discipline to avoid drift. The hybrid model, which most mature programmes settle on, has the CoE own the platform, the standards, the reusable components and the hard builds, while trained delivery teams in the business handle the rest under review.
Pick the model by the organisation's size and skill, write it down, and revisit it yearly. Most programmes start centralised and should plan the move to hybrid from the beginning.
The five things a CoE must own.
1. Intake and prioritisation.
One front door for automation requests, with a short form that captures volume, systems, pain and sponsor. A scoring method that is applied the same way to every request, published so the business understands why one idea went ahead and another waited. A monthly prioritisation meeting with the decision-makers in the room. The queue should be visible to everyone who has submitted to it.
2. Standards that fit on two pages.
Naming conventions, project structure, logging format, exception classification, credential handling, config management, and the definition of done. Keep them short enough that people read them. Enforce them through templates and a workflow analyser rather than through review comments, so the standard is applied before a human sees the code.
3. Design review at the right moment.
The costly mistakes are in the design, not the code. Review the process definition document and the solution design before build starts: is the process stable, are the exceptions understood, is the access available, is the right pattern chosen. A thirty-minute review at this point saves weeks later. Code review before release is a lighter check that the standards were followed.
4. Reusable components.
A library of tested components for the things every bot needs: logging into the ERP, sending a standard notification, reading a configuration, handling a known exception type. Each one built once, versioned, documented and owned. The library is the single biggest lever on delivery speed and on consistency, and it needs a maintainer or it rots.
5. Operations and reporting.
The CoE owns the platform, the environments, the release process and the monitoring. It reports monthly on a small set of numbers: bots in production, straight-through rate, hours released against the business case, incidents by severity, and backlog age. The report goes to the sponsor and to the business units, so the programme's value is visible beyond the team.
Avoiding the bottleneck.
- Separate governance from delivery. The people who review should not be the only people who build.
- Give delivery teams self-service: environments, test data, a component library and templates, so they do not wait on the CoE for the basics.
- Make the standards checkable by tooling. A reviewer should be confirming design decisions, not counting naming violations.
- Set service levels for the CoE itself: design review within five working days, release review within three. Publish the actuals.
- Fund a platform engineer. Environments, upgrades, licensing and monitoring are a job, not a side task for the lead developer.
The people side.
A CoE is a small team with a wide remit: a lead who can talk to sponsors, one or two architects, a platform engineer, a business analyst who owns intake, and developers for the hard builds. Around it, trained developers in the business units. Training is part of the CoE's job, and so is the career path: people stay in automation teams when they can see the next role.
Set up this way, the CoE becomes the thing that makes automation easy to do properly, rather than the committee that has to be convinced. That is when the estate grows and stays healthy at the same time.
The measure of a CoE is not how many bots it approved. It is how fast a good idea becomes a bot that runs.