In this instalment of our RPA Implementation lifecycle Series, we look to shift our focus onto the Deploy phase and examine some of the key aspects in this phase such as setting up triggers, access & security controls, and other important run configurations necessary for effective executions of RPA robots in production.
In one of our previous blogs in this series, I touched upon the two RPA implementation approaches. Top-down and bottom-up, emphasising the need to focus on both – operational efficiency as well as employee productivity, centralised as well as democratised automation initiatives, process as well as task automation. And also the two broad forms of RPA, – Unattended and attended, that align with the top-down and bottom-up approaches.
Given how these two forms of RPA are geared towards realising different value outcomes, and have got different design considerations and execution behaviours (most importantly whether the automation is to be executed on an employee’s desktop needing real-time inputs to assist in their day to day job or is it to be run on a server or a virtual machine without any human intervention), the setup and run configurations needs for these two RPA forms are considerably different.
When it comes to choosing which approach to adopt, often it is not a question of one vs. the other but a hybrid or ambidextrous approach is needed to pursue both of these approaches simultaneously as Francis Carden describes in What RPA mode are you in? which is a must-read for RPA professionals. Doing so would demand a common platform that supports both of these approaches in terms of the setup and configuration choices for a software robot. We discuss these in more details in the following sections.
With the intention is to run end to end process automations on a server/VM without any human intervention, it requires setting up triggers such as,
Another important run configuration aspect for unattended executions is to set up Handoffs between a robot and a human to implement the human in the loop concept to cater for situations where human intervention is required in order to fulfil an end-to-end process transaction. For instance, to seek approval or confirmation from a human before proceeding further. A robot can achieve this by sending a notification to a human, perhaps in the form of an email, or by creating a task for a human to fulfil in the RPA platform until which it pauses its execution. It is crucial that such hand-offs are orchestrated in a controlled way, by either using an RPA platform or with the help of a similar workflow orchestration platform.
Running RPA automations as attended to execute simpler individual tasks (and not end to end processes) on a user’s desktop workstation in real-time alongside the work they are continuing to do, requires setting up different trigger types.
The interaction-based execution is aligned to the idea of ‘Robot in the loop’ (the inverse of human in the loop concept in the case of unattended RPA) where the user is in the driver seat and the robot acts as a personal assistant to the user to be brought into action on-demand basis.
The idea here is to have a common RPA platform that supports the needs for both attended and unattended executions in order to achieve,
The below diagram pictorially joins up all the salient points discussed for the three RPA modes above from a deployment configuration perspective.
Read the other articles from this RPA Implementation Lifecycle series:
Robotic Process Automation Index
Contact us at SQA Consulting, to see how we may assist you in developing the necessary skills needed for implementing RPA projects.
