What processes can't be automated just yet? What improvements to those limitations can we expect in the next 5-10 years?
Most importantly - what are some things that RPA cannot do?
The top RPA tools in the industry strive to reduce limitations by expanding RPA capabilities and engineer their products to more greatly integrate with complementary products, like AI and ML, but limitations still remain. Although there are some disadvantages, the benefits of RPA certainly outweigh them and can contribute to a positive ROI for RPA when considered and implemented thoughtfully.
We've summarized our members' experiences and insights to surface the most important points. One limitation not mentioned is RPA security, which is not necessarily related to task completion and our members have recommended approaches to mitigate any security risks.
Before we get into the specific drawbacks of RPA, we should first define what RPA is not in comparison to other related technologies. Defining it in this way clearly shows this technology's limitations and when not to use RPA.
Our members have looked at RPA vs AI and they have also looked at RPA vs BPM, and clearly stated that RPA is neither. RPA is a more simplified technology meant for repetitive, rules-based activities and not the "automation of entire processes or workflows, which learn and adapt as they go", says Vivek Mishra, AVP of Technology & Solutions at Cygnet.
All of the limitations of RPA are addressable in fairly straightforward ways if you're familiar with the other tools that are important for building Intelligent Automation solutions.
1. If unstructured data is a concern, machine learning techniques in combination with image processing yield impressive results for entity extraction in addition to straight image-to-text. These solutions are increasingly offered in tandem with RPA software but can be purchased best of breed, separately.
2. Different incoming formats for data fed in. this is an issue, but relates to the first item. different ML trained algorithms can be run on each input form type, with reinforced training by your team members. It's more work, but it can be done.
3. While RPA bots don't learn, they can be written to leverage decision frameworks for choices, and those decision frameworks *can* learn (machine learning), and adapt over time.
4. While a lack of context is an issue, leveraging a process orchestration layer alongside RPA bots can resolve this difference. As said, automating a broken process won't fix it, but while automating, look for the context, the total picture of that process and see if you can, indeed, fix it with a combination of RPA and process.
5. For processes that require human judgment, don't rely solely on RPA, leverage process orchestration to assist - it is a pattern that has worked really well for us.
Currently the RPA is still limited to Human for designing the workflow, its not build smart enough to build and self heal itself.
Processes related to Live Monitoring of Command Center ( Command and Control) example view real time Camera and taking actions.
Taking actions based on real time Sentimental Analysis derived from Natural Language processing.
Pre-build AI and ML Packs for RPA Processes for Smart Exception Handling and providing Analysis - Recommendations.
Improvements:
- Smart AI and ML integrations that understands Exceptions and Provide recommendations ( Supervised Learning Logic & Self Healing)
From Saibal response I would challenge question #1 bulletpoint #2: i think that you can find intelligent solutions to deal with unstructured data. Do not limit to just structured data.
I would also challenge question #2 bullet point #1: Why seasonal? I would say any manual and repetitive process regardless if it is seasonal or not.
And question #2 bullet point #2; why just limited volume? actually the more volume the more ROI. because once the automation is implemented the costs are fixed.
The processes having following characteristics are not suitable for RPA:
1. Any process that need human judgement to process
2. Any process which has data which is unstructured
3. Any process which has non-digital input source
The processes having the below characteristics can be automated, however the ROI may not be encouraging:
1. Processes which are seasonal
2. Processes which has limited volume
3. Processes which are broken
It is these benefits that are generating the boom in RPA interest – and a good measure of hype. However, every technology has its limitations, and RPA is best viewed as an additional cost reduction lever and a foundational technology rather than an operational panacea.
Limitations of RPA include:
First, RPA cannot read any data that is non-electronic with unstructured inputs. An example would be inbound correspondence such as paper customer letters. When a customer sends their energy company or bank a letter is it generally paper-based and unstructured. A company would then receive, scan and reallocate this letter to the correct department for processing. In this case, RPA will only work with a collection of other implemented technologies (such as OCR) required to make it digital and structured. This can become a costly hurdle before RPA can be applied, and companies may want to consider other solutions such as straight-through processing, digital capture, process optimization or other intelligent automation technologies.
Second, companies need to be aware of diverse inputs coming from multiple sources. For example, in a procurement function, supplier invoices may be received in different formats, with fields placed in different areas. For a ‘Bot’ to be able to read an invoice, all supplier invoices must be received in the same format with the same fields. Although robots can be trained by exception to read different fields, they cannot read multiple different formats – unless these are all digital and configured separately. In practical terms, there will always be a volume and cost threshold below which RPA is not an economic solution, and companies should focus first on high volume/high-cost processes for maximum benefit.
Third, RPA is not a cognitive computing solution. It cannot learn from experience and therefore has a ‘shelf life’. As processes evolve – for example, through the introduction and use of other technologies — they may become redundant and require changes. It is therefore wise for a company to examine the process prior to building a ‘Bot’. Typically, at our clients, we see a Bot shelf life to be anywhere from three to five years after implementation. Applied to a process that is inefficient and/or on the way out, that shelf life may be reduced to just a year. The business case may then not stack up.
Finally, applying RPA to a broken and inefficient process will not fix it. RPA is not a Business Process Management solution and does not bring an end-to-end process view from approaches such as Lean Six Sigma. The same goes for out of date infrastructure – RPA will only mask the underlying issues. This can counteract any sustainable long-term savings by adding complexity which must be addressed down the line. Companies should focus first on addressing the root causes of their process or technology inefficiencies and then apply RPA to maximize the benefits
RPA is best suited for rules based vs. judgement based processes. Some examples of rules based processes are invoice processing, month end closing, ...
The main limitation to traditional RPA (not ML or AI or OCR Intelligent capture) is nondigital work, unstructured data, voice and call back processes and processes that require human subjectivity.
I agree with Reddy Subramanyam's assessment. RPA is a necessary but not sufficient technology to achieve intelligent automation. The industry is evolving, so you should look for tools that include cognitive capabilities, fully integrated rather than bolted on to an RPA ecosystem. The AI must be baked into the platform's DNA, not 3rd party AI added via APIs. This intelligent automation solution should start with data's first mile, identifying, enhancing, curating and extracting actionable meaning from unstructured data. Once this data has been made actionable, it can be handed to the digital workforce or other downstream systems for processing.
The RPA conundrum is simple: RPA requires structured data but 80% of enterprise data is buried in unstructured documents: emails, letters of credit, invoices, passports, sanction lists, et al. You must find the tools that can deal with that document variance, as well as delivering self-healing capabilities do deal with UI changes in downstream systems that will break the automations of RPA 1.0 bots.
This question cannot be answered without first answering the question of how do you qualify which processes can be automated.This is normally determined by subjecting the proposed candidate processes to an RPA assessment criteria which will check among other things (1) Basic checks-Process/Tasks must be currently manual, repetitive,rule-based and with high volumes of data generated. (2) Level of complexity of the process,the lower the complexity the higher the automation success,the higher the process complexity the more difficult it would be to automate.Process complexity can further be broken down to look at a number of things eg Is the number of exceptions high in the current manual process, are majority of the documents handwritten?, is there a planned or on going underlying business system change or upgrade etc.
One of the limitations to do with hand written documents recognition is slowly being addressed and hopefully in the ext few years we are likely to see more intelligent 'handwritten notes' recognition engines being incorporated by major RPA Vendors as a key capability in their tools.
At my current company we have identified more than 53 opportunities to implement RPA. A simple list is described below where these opportunities are:
* Invoicing
* Bank reconciliation
* Hiring / Resignation/Vacation (the bureaucratic part).
* Document entries: fiscal, accounting, finance
* User Profile maintenance.
In general todays RPA platform has come a long way to enable the interaction of software robos (BOTS) with any type of application though the accuracy and stability of solution vary based on type of application and access channels. Still there some of the areas which are still challenging for RPA and i believe as technology matures we expect great improvement in these are -
1- Reading and interpreting Image/Graphic data - For documents OCR is helpful but if i have to read a network topology or some machine drawing to get some details it is not possible with RPA. Computer vision technology need to mature to give better accuracy to be adopted for industry usage
2-reading captcha- i think this is still genuine since purpose of this is only to stop automated/robo access
3-taking decisions based on knowledge base/historical data to perform activities - it is not out of the box from RPA platform but integrating RPA with AI components can help in achieving this. industry is calling intelligent automation. A lot of work is happening in this area and will continue for coming years
Theoretically anything can be automated but the real question is what should be automated with RPA solutions based on the current state of these technologies. Typically activities that are not rule-based and repetitive should not be automated because you will not generate the benefits you are looking for. Further, there should be sufficient volumes in the activity or process to justify RPA investment. One should also look at alternatives to RPA including ERP and packaged software solutions which can provide you with a more holistic automated solution but may be much more expensive. There are advancements in RPA technologies with the most recent being the integration of AI with RPA that will improve in the coming years as AI solutions mature.
- User cannot launch RPA-robot. It is suitable for scheduled back-office processes. Some vendors offer tools for immediate scheduling also but it is quite expensive (license per user). RDA tools are of course suitable for this kind of processes. Maybe RPA and RDA will get closer in the future and license models will be more attractive.
- RPA is quite vulnerable to UI-changes, for example. It is possible that someone will in the future develop some kind of ai-component for automatic change management but I think this is still something that we just have to accept.
Hello Menachem,
Today RPA is primarily focused on automating business processes that involve structured data (think spreadsheets and databases), rules-based decisions and basic reporting/analytics. Today 60-65% of the automation effort is spent piecing together the various steps in a business process. In five years, RPA will be able to automatically discover and prioritize processes that need to automate and, automatically create intelligent digital workers needed to automate that business process. The intelligent digital workers will be able to process unstructured data (documents, emails, images, video, etc.), make human-like judgments (flag potential fraud, make customer service exceptions, etc.) and, continuously learn and improve from human-in-the-loop feedback and advanced analytics.
Using Kryon RPA, there are very few limitations we have run into that can't be worked around especially if you have a .net developer and some modern functions such as API systems. As long as you structure your team with test, UAT, and the ability to test upgrades/updates to your platform to ensure alignment with your RPA projects that are running; you should not experience any major surprises. Kryon specifically ensures that with updates to there functionality that it is backward compatible so that growth and maintenance are a huge factor in moving forward.
There are a number of tasks that require thinking and if you cannot come up with all the different scenarios then it takes a human to make a decision. I think with additional AI tools the number of options can be sorted out but this will take time to learn this The other major challenge is with complex tasks to take all the stakeholders and systems into account which is very burdensome