Cross-functional CoE Governance
Establishing a cross-functional governance structure for a Blue Prism CoE in UK financial services — aligning IT infrastructure, operations, and the wider business through a working group built from scratch.
A mature Blue Prism CoE doesn't operate in isolation. It runs processes that touch business systems maintained by other teams, on infrastructure owned and changed by IT, in an environment shaped by regulatory requirements driven from outside the programme entirely. Without structured alignment with each of those groups, the CoE is always one unannounced change away from a production problem.
The risk compounds as the programme grows. More processes means more system dependencies, more runtime resource exposure, more surface area for IT changes to land on. What's manageable as an informal arrangement at ten processes becomes a liability at a hundred.
Infrastructure migrations, system upgrades, and business system changes are among the most disruptive events for an RPA operation — and they're typically planned and decided without automation in the room. A database migration changes connectivity. A business system upgrade changes process UI. An infrastructure change affects runtime resource availability. Without early input at the planning stage, the CoE finds out when a process fails in production.
The challenge wasn't just getting information — it was getting a seat at the table early enough for that information to be useful.
Effective cross-functional governance for a CoE requires alignment across three distinct areas. Each one informs the others — gaps in any one of them erode the value of the other two.
IT infrastructure and platform
The most operationally critical relationships were with the IT infrastructure, DBA, and information security teams. Upcoming server migrations, database changes, infrastructure upgrades, and platform moves all carried direct exposure for the automation estate. Representation from these teams meant RPA impact could be assessed before decisions were made, resource could be allocated ahead of change windows, and the CoE wasn't presenting a reactive problem to a delivery team already in execution.
Business operations and digital transformation
Operational heads from across the business brought their own horizon of change — regulatory deadlines, process transformation initiatives, system replacements, and operational restructures. Each had automation implications. Knowing about them early allowed the CoE to assess whether existing processes would be affected, whether new automation opportunity existed, and whether the programme roadmap needed adjusting to account for dependencies or competing demands on resource.
Governance and accountability
The working group had structure that made it accountable, not just informational. A regular cadence, cross-functional representation, and a clear output: anything agreed in the room was written up and signed off by the relevant representative. The CoE's planning was based on documented, committed information — not informal conversations that could be walked back — and the wider organisation had an auditable record of what had been agreed.
The working group was established from scratch — there was no existing forum for this kind of cross-functional alignment at the CoE level. Representatives from IT infrastructure, the DBA team, information security, and operational heads from the business areas the CoE served were brought together on a regular cadence.
The format was straightforward: each representative surfaced upcoming projects, changes, and deadlines relevant to their area. The group discussed implications, agreed on actions or sequencing where needed, and those agreements were written up and signed off by the relevant reps before the next session.
The most consistently valuable input came from the IT side — infrastructure migrations and business system upgrades in particular. These were the changes most likely to have direct production impact without early warning. Having them on the horizon weeks out, rather than announced as an imminent event, was the difference between managed change and reactive scramble.
The CoE operated as a programme-level stakeholder — not a downstream consumer of decisions made elsewhere.
By the time a change reached execution, the automation impact had already been assessed, resource had been allocated, and any necessary process adjustments were in progress. The working group turned foresight from a matter of luck into a structural feature of how the CoE operated.
Strategy & Governance in ROM2 asks whether automation is strategically positioned and supported at the right level. A governance structure with real cross-functional authority, documented outputs, and a seat at the table during IT and business planning isn't just good practice — it's the infrastructure that makes everything else in the CoE sustainable.
Assess your CoE's governance maturity →