Governance, CoE Practices, and Scaling Automation
What you must know
Scaling is a governance problem as much as a technical one. Candidates must understand the CoE operating models (centralised, federated, hybrid), the automation lifecycle from intake and prioritisation through build, run, and retirement, and the artefacts that gate each stage: idea backlog, PDD, SDD, test evidence, change request, and decommission record.
Know the control environment: role-based access, segregation of duties, audit trails, change management, and alignment to frameworks such as SOX, GDPR, and model-risk guidance for AI components. Understand risk tiering - a bot touching payments or PII needs more controls than an internal reporting bot. Know the metrics that matter: pipeline conversion, STP, bot utilisation, exception rate, cost per transaction, and benefit realisation versus business case.
Traps
- Confusing centralised (CoE builds everything) with federated (business units build, CoE sets standards) - questions often describe one and ask you to name it.
- Treating governance as a one-time gate rather than continuous control.
- Measuring only bots deployed, not value delivered or exception rates.
- Forgetting bot retirement; stale bots are audit and security risk.
- Assuming AI components need no model documentation or monitoring - they need more.
Rule of thumb
Risk tier drives control depth. Classify each automation by data sensitivity and financial/regulatory impact; apply proportionate review, testing, and monitoring. Never apply the same lightweight gate to a payments bot as to a report generator.
Worked example
A pipeline of 120 ideas: intake triage removes 40 as unsuitable; prioritisation scores the rest on value, feasibility, and risk; the top 30 enter build. Track conversion at each stage and report realised benefit against business case quarterly. A high-risk payments bot gets dual approval, full audit logging, and monthly control testing; a low-risk reporting bot gets standard review and annual testing.