Robotic Process Automation as we know it today is a framework through which large scale processes can be automated. The biggest advantage of current RPA systems is that they can be easily integrated with current IT and Software systems.
RPA can be used to automate repetitive process-driven work with well-defined outcomes. However, there is a catch. If this is Process Automation, then why don’t we just call it Process Automation? Apart from the marketing angle of using the word Robotic in Process Automation, whoever coined the term had something beyond just process automation in mind.
The intent and endeavor to automate workflows are not new. In traditional systems, automation was achieved by software developers building a comprehensive list of APIs or Scripts to cover all pre-conceived and possible tasks. However, there was a serious drawback in this approach, it was not scalable.
In modern RPA systems, instead of writing a finite number of scripts, the software systems trained to understand any number of steps as executed by recording the actual process and then replicating the same as it was recorded with the RPA platform. The 90’s generation that used excel extensively to write macros to record a set of standard activities and then store it so that every time those set of processes are run, it executes a complex but well-defined set of processes in a certain sequence. This was also called an excel macro. The current RPA platforms execute on similar principles, although at a much larger scale of complexity and size with advanced technology.
While this overcomes the problem of scale, there was still one last challenge. The significance of the word Robotic comes from the fact that there is an element of intelligence expected from the process of automation undertaken by an RPA platform. This intelligence allows the platform to take autonomous decisions based on trigger. While the trigger can be programmed, the same is not the case with the decision tree that activates the trigger.
Most RPA software’s like UIPath, Blue Prism and Automation Anywhere have so far come out with platforms that are very good at process automation by being programmed to follow a certain set of standard processes. However, they fall short miserably when it comes to making the whole process intelligent. They fail to transcend from their platforms being Automatic to Autonomous.
Let’s illustrate this with an example. Let’s assume there is a complex senior management report that gets generated by collating some specific lines of data from various enterprise databases like Oracle, SAP, and others. After the report generation, an automated mail is sent out to 500 users with specific content to each user.
The process is repetitive because multiple reports need to be generated from multiple sources of data. This is a complex process with ginormous scales of data having a multiplier effect on each of the customized reports generated for more than 500 stakeholders which are then emailed to intended recipients.
Sounds like quite a complex process but today’s RPA platforms are equipped to handle this easily and repeat process automation with minimum errors. This does not require a lot of development on existing RPA platforms. As mentioned, it can also be easily integrated into multiple platforms mentioned earlier.
However, current implementations still fall short of one critical feature required to certify it as a true autonomous implementation.
Taking one particular use case as an example, if the RPA platform had to decide on whom to send the reports based on some critical random content of the reports which could be either a picture, text or numeric and it could appear in a random pattern, the platform would fail to do so. It will fail for the simple reason that it does not know how to detect and tackle unknown situations and the decisions thereof because it is not a part of the standard process.
Similarly, many other use cases are missing from current RPA platforms. While they claim that some of them are AI-enabled, most of them are not there yet.
The main reason for such a shortcoming is that AI is not the core of process automation developers. Naturally, it is an area they are skeptical in investing and rightfully so. It is going to be difficult for them to develop such a specialized competency. The RPA platforms should, therefore, drop the word Robotic unless their platforms are truly autonomous.
The RPA enterprise customers who see a real and large-scale implementation of their process automation platforms should work with AI service providers like Affine, to be able to add the element of intelligence and true autonomous Capabilities to the process automation already implemented.
One should not have the apprehensions of integration here because just like RPA platforms can be easily integrated into existing systems, AI modules can also be integrated into either RPA modules or to the end systems directly.
That is when RPA implementations will truly become Robotic in nature.