Robotic Operating Model (ROM) and Governance
What the ROM is
The Robotic Operating Model (ROM) is Blue Prism's delivery framework describing the roles, artefacts, and lifecycle needed to run an automation programme. It covers the Automation Lifecycle (identification, assessment, design, build, test, deploy, run, and retire), the operating model (centralised, federated, or hybrid), and the governance structures that keep delivery controlled.
Roles
Key roles include the Programme Sponsor, Head of RPA / Centre of Excellence lead, Business Analyst, Process Designer/Developer, Technical Architect, Controller/Operations, and Support. Questions often present a scenario and ask who owns a decision. Traps include confusing the Process Designer (builds the process) with the Technical Architect (sets standards and infrastructure) and confusing the Controller (runs the live operation) with the Developer (changes the process).
Governance artefacts
Expect questions on the Process Definition Document (PDD), Solution Design Document (SDD), Operational Impact Assessment, and the change control process. The PDD captures business requirements; the SDD captures technical design. A common trap swaps the two.
Operating models
Centralised models put all capability in a single CoE; federated models distribute delivery to business units with central standards; hybrid blends both. The answer often depends on scale and governance maturity, not on a single 'correct' model.
Rule of thumb
Separate build from run: developers should not have production release rights, and controllers should not modify processes. This segregation of duties is a frequent exam point.
Worked example
A bank wants business units to design their own automations but keep central standards. The hybrid model fits: central CoE owns standards, infrastructure, and release approval; business units own process discovery and first-line support.