Years ago, when I started CampTek Software, I was on a roundtable with a group of practitioners and business leaders who were in the Automation space. We were having an open discussion around RPA, and each person spoke about where they or their company was in their adoption and use of the platform. Most indicated they were just getting started, had a fairly well-developed COE, or were somewhere in the middle. As we went around the quorum, one person indicated that his company had decided to “go right to AI and will skip RPA altogether.” I was astonished by the answer and have tried to figure out the thought process around this decision.
In a previous blog, I spoke about how AI and RPA are often confused, and now with more awareness and excitement around Chat GPT, Microsoft CoPilot, and AI Large Language Models. Everything is now classified as AI, even though in some cases it may be RPA. The truth of the matter is that RPA, at its core is a representation of years of Machine Learning Models. Today’s platforms like UiPath have a lot of AI embedded into their activities to increase reliability as they interact with applications on a Windows desktop. Each activity represents thousands of hours of development, testing, and use. These activities need to work 100% of the time, so it makes sense that they are refined, very similar to ML.
That’s all well and good, but is RPA needed any longer? The short answer is yes and yes and YES! The longer explanation is focused on several key areas to consider, in relation to AI.
- The Data… AI needs ample data to provide its intelligence. RPA can help with this. To build a ML Model sufficient to accommodate the needs of a robust AI activity, there must be enough quality data the model can consume and begin making quality decisions from. So, one starts to think of where the real decisioning data lives, it’s in the applications that have been collecting it for years. In Healthcare particularly, there seem to be restrictions in both the modern EHR/EMRs and the older ones as well. The older applications have proprietary databases that are hard to pull from using typical query language, so the only way to get to the data is to pull it from the front end. To make matters worse, some of the leading “modern” vendors own or put restrictions on accessing the data which require a lot of hoops to go through. This makes the task of collecting historical and real-time data hard. There is only so much that can be pulled from the back end, and sometimes it doesn’t line up. This is clearly something that RPA can help resolve as a near and long-term solution.
- The Decisioning… RPA is fantastic at interacting with desktop applications that reside anywhere and in any form, (i.e. Citrix, Cloud, Windows, Character-based, Web, etc.). The use of any intelligent automation activity (i.e. GenAI, AI w/ LLM’s, Intelligent Document Processing) to be inherently useful will need to be orchestrated, activated, and used by an application. The application could be SAP, Epic, Salesforce, ServiceNow, some type of Low Code App, or any application on the desktop. How can you get the question asked by the user to the AI activity and its answer back to something that can act on this decision? RPA is how.
- The Day to Day… We are already seeing significant traction of Microsoft CoPilot, Python-based RPA applications, and even at some point, UiPath AutoPilot. These next-generation applications will simplify the Citizen Developer or the Power User Experience. They are all powered by RPA and AI in some form. While these will be considered 1st gen tools, at some point, they are getting us closer to a dynamic learn-as-you-go experience where the tool is getting smarter with limited user instruction versus the contrary.
As I wrote previously, we are getting closer to where technology will work for humans versus humans working for technology.
Written by: Peter Camp, CTO & Founder
