Having spent a few months researching software from some key RPA suppliers, I thought I’d share my findings.
Firstly, the RPA market is rapidly evolving into a set of software solutions which on the face of it appear to deliver the same capabilities and promise the same business outcomes.
The promises made by vendors and resellers of RPA software are mostly aligned around Business Process Automation that results in improved productivity. The justification for the investment is predicated on ROI and improved customer service.
I’d like to caveat these findings with the usual “it depends” on the scenario and requirements of specific projects. I’ve tried to frame the findings accordingly. Similarly, the scope of this report is to consider “execution” robots rather than robots that address cognitive parts of a process.
I’ve presented my key findings and observations under the following headings:
- Many RPA systems need developers to design, develop and configure. The reason for this is the underlying complexity of applications (typically MS Windows), the limitations of the host OS and the “framework” style of RPA solutions. While some RPA systems include automated or “wizard” setup capabilities, they invariably reach a point in the development and deployment where scripting or access to APIs are definitely needed. At the other end of the extreme, some RPA vendors use a 100% configurable approach that provides a set of APIs for integration, data exchange and management. Personally, I believe that Business Analysts should be able to use an RPA solution build and prototype robots in an agile way. Depending on the complexity and sophistication of the project, IT can and should be stakeholders to ensure governance and application resilience for any production roll out.
- Most RPA vendors have solutions that permit development and staging of “execution robots” to run on MS Windows desktop environments. This is a critical point for me as MS Windows wouldn’t necessarily be my first choice of platform for processing large volumes of data. I accept that if an MS Windows environment is needed to run Windows applications then there are few other options. However, if the process simply needs to run processes without any MS Windows dependency then best to use an RPA that can run natively on a server. This approach significantly reduces the complexity and cost of deployment as no MS Windows environments are needed; the inherent performance benefits of server architecture can be fully realised.
- RPA systems generally offer two “core” methods of running; attended and unattended mode. These refer to robots that essentially “serve” or respond to requests from interactive users and those that run processes behind the scenes and are not so reliant on user’s direct input. The way different RPA solutions approach these requirements is quite varied. Some RPA system are entirely attended and even “unattended” processes are initiated from the user’s desktop. Some sophisticated desktop RPA solutions effectively embed themselves into MS Windows processes and can assume control of the desktop application; this is to MS Windows applications what assisted parking or adaptive cruise control is a contemporary motor vehicle. Some desktop RPA software allow the user to issue hot keys or are configured to trigger on a pre-defined event. Unattended processes run behind the scenes and typically on physical or virtualised MS Workstation environments that are dedicated to the processes in mind.
- What constitutes a robot? It’s important to note that different vendors use the term “robot” in different ways and this can introduce some initial confusion. Many vendors refer to the complete MS Windows “desktop” (physical or virtual) running a set of robot processes assigned to it. To others, the term robot refers to an individual robot process that then run on various environments. I personally believe this is a great marker as to the background of the market and how the particular vendor initially developed their system; RPA vendors that started as MS Windows programs to automate simple desktop functions such as screen scraping and keyboard macros tend to refer to the licensed desktop as a “robots”. Whereas RPA systems that started as BPM and incorporated applications integration tend to license on a process-oriented “robot” approach.
- Overall Business Process Improvement and Automation. Naturally, any discussion about robots must gravitate towards process improvement and automation as well as setting goals regarding targets for user productivity gains. For this reason, larger scale RPA projects often include Consulting and Systems Integration companies. An example a recent project on which our company was engaged had stalled because where current “as is” processes included the manual processing of inbound documents and messages. Had the automation of these tasks had been considered in the context of the end to end business process then it probably would have been tackled initially and before involving RPA consultants.
So, what are the questions you should ask when considering Robot Process Automation? Here are some typical questions that I ask during the initial meetings.
- Have you identified target applications and processes? What are the expectations for improvement and what are the core dependencies?
- Has the data-set that needs to be managed to ensure smooth and automated execution of individual applications and tasks that drive these processes been identified?
- What proportion of these target processes include applications that will need to run natively under MS Windows or can these processes run on alternative environments?
- What is the style of processes, i.e. using RPA terminology, are these “attended” or “unattended”?
- What is the acceptable latency, i.e. what level of responsiveness to an RPA process trigger do these automated processes need to run?
- Do your end users need to be able to trigger any RPA processes on an immediate and ad hoc way?
- What are the aggregate volumes of data that are likely to be involved in these automated processes?
In summary, RPA is multi-faceted and specific use cases by product and implementation are very much determined by the requirements of the process and the overall objectives. Without question however, the spectrum across which RPA can be utilised is vast and flexible, giving organisations the scope to realise benefits, not just through cost savings, but with non-tangible results too such as staff re-deployment, less human error and more efficient customer services.
For queries or comments, please contact Andy Johnson:
