Recently, I was tasked to research about Robotic Process Automation (RPA). In my entire career in the software industry, I vaguely heard about RPA ideas, whether it's from a conference, meetups, or technology groups. It was just never thought of as a solution to a problem. However, as I research more about RPA, I started to understand more as to why this has been an alternative approach to typical Custom Software Development.
Robotic process automation (or RPA) is an emerging form of business process automation technology based on the notion of software robots or artificial intelligence (AI) workers. - Wikipedia
As a software developer, you would have thought how is it different from what we are already used to doing? Isn't it script automation? macros? writing my own simple software? Well, this post tries to clarify the misconceptions about what RPA really is.
Different approaches when it comes to automating
- Macros, screen scraping, and scripting
- Custom Software Development
- Robotic Process Automation
The vision for enterprise with RPA
Create digital service workers in the enterprise by automating tasks that are mundane to the employees with cognitive intelligence, thus freeing up their time and focusing on more important tasks that are matters the most. Organizations want to increase efficiency and collaborations by having business users and technical people collaborate when it comes to automating their workflow processes. Include it with enterprise features such as scalability, auditing, security, and orchestration from most of the leading vendors in the RPA market and you have a new approach when it comes to solving a problem.
Common problems that we encounter when we are dealing with stakeholders are the following:
- High costs
- Extensive time to complete
- No proper documentation and APIs exposed to integrate with a legacy system
- They want it as soon as possible
Sure, you would say that in a wonderful world, we could have addressed the problems through proper planning, implementation, and a rock star team, but we know that doesn't happen all the time.
How would you solve this problem?
There are an immediate business needs that require to be implemented as soon as possible, and an enterprise has legacy systems such as COBOL that runs on its emulator and is still a critical operation through their entire business that stores all the customers information and requires to interface with an ERP or CRM systems.
There are not much COBOL developers in the world that can just write interfaces that can deliver it in production right away without further testing and making sure nothing breaks.
One solution that pleases most stakeholders' ears is the RPA approach because it mimics the entire workflow that an existing human already does. When it comes to the OSI Model, RPA only touches the Application layer, the user interface of an application.
Since the robots are only touching the user interfaces, the RPA robot can act as a broker between different systems that can transform, aggregate, or anything a person can do in a typical desktop environment.
Why introduce another approach and not fix the root of the problem?
Well because some of the business organizations are scarred for making any changes to a system that just works and they are just too expensive to fix. Why would you try to rewrite everything or try to integrate another system if I can hire someone to do the work through its user interfaces? RPA allows enterprises to implement technology quickly and efficiently, without changing processes.
RPA Solutions Team consists of what a typical software development team is. They mostly replaced the word software with RPA.
- Back Office - No customer facing, mostly internal processes
- Front Office - Customer facing, mostly external processes
- Shared Services - Consolidation of support functions such as human resources, finance, information technology, and procurement from several departments into a standalone organizational entity
- Swivel Chair - Processes where humans took input from one set of system, processed and move it to another system such as ERP or CRM
- RDA - Robotic Desktop Automation. Some enterprise products mention different types of RDA. Attended and Unattended Robotic Desktop Automation
Application life cycle
There are two approaches that are possible when it comes to implementing RPA solutions. They are not that different from what a software development life cycle uses.
You might be wondering why we are trying to implement a Waterfall model that we no longer try to use. Well, because some organizations do not know where to start implementing an RPA. A good way of introducing RPA is to create RPA solutions that the organization already implements. With the Waterfall model, we already know what the requirements are, and we do not want to change the underlying process. Introducing a process change can be intimidating for an organization.
An agile model is a modern way of implementing software solutions. However, I think this is a high risk for organizations that are just starting to implement RPA solutions with minimal cost and time that will be spent. This approach is much effective with a combination of using a business process re-engineering strategy that identifies what are the potential processes that can be optimized, reduced, and be more efficient.
Today, we have seen the practical usages of Machine Learning algorithms and how they affect our day to day jobs that used to just be research papers a few decades ago. Thanks to the computing power that is innovated every year, these dreams are now becoming reality in making the computer smarter every day.
There are different machine learning solutions that can now replace what a human person is doing. For example, a service worker's daily job is to go to the 10th floor, scans all the documents, goes to the 5th floor, classifies and sorts the documents, goes to his desktop and logins to different systems to aggregate and transform data, then he must create a daily summary report on his OneNote application.
With Machine Learning and RPA, we can easily replace all the employee tasks:
- Scan - Use Optical Character Recognition (OCR) to extract texts out of a scanned document
- Classifies - Use machine learning classification algorithms to build a model that can classify the documents
- Aggregate and Transform- Use RPA robots to log in to different systems using his desktop to aggregate and merge data
- Summary - Use machine learning information extraction algorithms to build a model that can summarize the data
- Final - Use RPA robot to input the summarized data by a machine learning model to OneNote without having to know OneNote APIs
With the RPA approach, the use cases are limitless on what you want to delegate to a robot instead. Common RPA use cases are the following:
- Human Resources - Recruitment, Onboarding, Payroll, Off-boarding, QnA Knowledge-Based
- Information and Technology - Data Archiving, Backup Automation, Use Management, Support Ticket Handling
- Finance and Accounting - Expense Management, Asset Accounting, Cost Accounting, Rules-Based Control
- Supply Chain - Sales and Operations Planning, Procurement, Order Management, and Delivery
Key Characteristics to determine if a process can be automated with RPA
- Performed by humans
- Highly Repetitive
- High Frequency
- High volume
- Actions are consistent
- Business Critical Operation
First Impressions and Findings
Sure, the benefits make sense, and everything said was so magical and the benefits outweigh the risks of implementing an RPA solution. Depending on an organization, an RPA approach might be a viable solution to them in the short term. It is a patch to a problem. It's not really solving the root cause of the problem. In my opinion, after reading all different articles, white papers and blogs about RPA and without going through the actual implementations, it sounded so easy to deploy an RPA solution right away.
RPA is like a combination of automated UI tests like Selenium for browsers, and TestStack.White for desktop. Most enterprise vendors only support Windows platform.
As of this writing, only UIPath offers a community edition compared to other market vendors. Others only offer trial licenses that expire. I came up with a simple use case that I can automate using UIPath. I would want to automate my time sheet every day. And since my company wouldn't allow me to get an API for our timesheet system I thought it would be a good use case in showing the power of RPA solution.
Everything was going well until I got stuck on determining which input control do I have to input my number of work hours. Since the HTML output by our system does not really have a relationship between different HTML tags, I had to hack around the solution instead of solving the problem. And as a software developer, I prefer to create solutions that are clean and getting to the root of the problem. With RPA, it reminds me of working in a SharePoint environment given the technology constraints and how it behaves. I must modify the pseudo code that I came up with just to work around the issue.
- RPA solutions are extremely dependent on the user interface. If the user interface changes, then expect your RPA solution to break
- I have no idea how they create automated tests with RPA. I'm sure they have a way.
- Handling processes that have a lot of edge cases are hard to develop and time-consuming
- Automating user interactions in the user interface that has a dynamic view port are not a simple task to solve. (e.g., A table that has infinite scroll - How would you know when to stop scrolling if the constraints that you're looking for are limited to identify that specific row?)
In my next blog post, I will be sharing how I prototype an RPA solution with Cognitive Intelligence.