25-11-21 02:21 PM
I am looking to get some general input around the 'releasing' the Process Control Role into a centralised business unit that is not part of the RPA CoE.
We are discussing for a central team who specialise in "risk & controls", to look after the day to day management of all Control Room activity as part of the their normal BAU responsibilities. Whereas this would be an efficiency 'gain' back into the RPA CoE team, we are also debating what risks this could present us with.
The high level plan thus far is for all day to day activity, ie checking availability of resources, ensuring processes run within SLA, reviewing scheduling requirements, RCA of process terminations, logging tickets through IT teams where required, stakeholder management etc. is all done through the new team. If there are then any problems with the day to day that they cannot resolve ie resolving a process terminations etc. they would then get in touch with CoE for support.
Duties that would remain with the CoE are the releases of new code/processes, all 'Go live' activity (for at least the first few days after release…for extra checking), the initial creation of schedules to release into RUN mode and all monthly dashboard reporting.
Segregation of duties is also something we will need to consider, with multiple teams across multiple depts. having access to Production, but this can be picked up separately with Security for relevant approvals.
The idea of tools which can support the PC function is also something we have considered, however for where we are in our journey, as we expand our portfolio and add more processes into our Production environment. We are still keen however to understand if anyone has sampled any tools that look to support this activity, and of course any "lessons learnt" from doing so.
Anyhow, just interested to gather some thoughts around this topic in general, and if anyone else has adopted a similar model (or perhaps even considered but did not implement for any reason!) – thanks for the time.
Kevin
29-11-21 12:28 PM
A central controller team proviing ops services for multiple federated teams or delivery COE is something I have seen often and would recommend if your RPA capability has grown to a size where it makes sense to make that jump. It would be a fairly usual ops model.
Benefirts include enforcement of the Logical Access Model for security (stop developers jumping into production without governance), efficiencies (stop dev team getting distracted with running and consentrate on build). Your ops team will have targets related to robot utilisation, up time. They must have a very close relationship with the business process owners providing them with MI and dashboards to show what the resources you are providing to them are doing.
There are some gotchas to watch out to with this model (as with any model) - I recommend the ops team include people that can investigate problems in automations without constantly bringing in COE leads but you still need an 'emergency hit fix' process that can quickly bring in the developer for business critical processes with a short SLA.
Also, your ops team should have some governance of the production environment - ensuring quality gates are passed and peer reviews completed before allowing new solutions into the production environment the own.
For some customers the ops team also have a role in change control and requests for solutions they are managing. Keeping a close relationship with system owners to understand system changes that could impact solutions in production and raising change requests with the dev team for them. Also the close relationship with business owners to understand changes to the business needs of the process.
There have been some webcasts done by Blue Prism on control room ops and operating models if you hunt around (I think one of them may be on the webcasts in the main website).
29-11-21 02:19 PM
01-12-21 09:18 AM
01-12-21 09:25 AM