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.
Match your bot deployment strategy to your RPA mode
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.
Unattended RPA
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,
- Scheduled based execution to run an automation at a fixed point of time on specified machine/s
- Queue based execution to line up automation transactions in pre-built queue/s when a condition is met. For instance, so they can be executed on specified machine/s, e.g. when a file is dropped with transactional data in a folder at the end of the day to then queue up all the transactions for automated execution overnight
- API based execution to trigger the execution programmatically by making an API call to the RPA platform in order to execute an automation which can either result in a schedule based or a queue-based execution
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.
Attended RPA
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.
- Event-based execution to trigger an automation based on certain actions performed by a user when interacting with an application UI, such as mouse clicks or keyboards presses or populating/updating display values of UI objects, etc.
- Interaction based execution to trigger an attended automation on-demand based on real-time interactions between a user and the RPA platform via a chat or voice interface (this is something on the horizon to be offered as out of the box in most widely used RPA platforms)
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.
Hybrid RPA
The idea here is to have a common RPA platform that supports the needs for both attended and unattended executions in order to achieve,
- Robot orchestration for both unattended and attended RPA and this is a difficult task to achieve as the technical requirements for the two are very different and you have many vendors offering “Watched unattended RPA” for attended automation as Francis Carden explains in What RPA mode are you in?
- Conversion from one form of automation to another, more so when going from attended automations to unattended as one creates more granular task-based automations in a bottom-up fashion that can be joined up to achieve an end-to-end unattended process. Conversion from unattended to attended automation is only possible if the former has been developed taking a modular approach to reuse individual components for attended task automation requirements
- Data Security to cater for both attended and unattended RPA executions minimising the risks that may arise when moving sensitive data across different applications via their User interface, especially in the case of attended automations where both user and bot are performing actions at the same time on desktop applications where there might be multiple instances of an application running with both the user and the bot logged in on individual instances as an example
- Access Management to assign the right level of roles, permissions and credentials for the needs of both attended and unattended automations
- Lifecycle Management right from crowdsourcing of automation ideas to all the way to the monitoring of automations running in production, but more importantly from a deployment perspective to include environment, version and change management (reviews, approvals, rolling out updates)
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.
