After doing a handful of robotic process automation (RPA) projects, I wanted to share some lessons that I learned with people who are passionate about the future of RPA and to those who are considering to build their very first RPA bot!
In a typical RPA project, we prioritize processes that are rule-based and repetitive in nature for an RPA robot to execute. Most of the time, data entry and validation work are on top of this RPA prioritization list.
Imagine yourself or your colleagues spending 8 hours a day looking at an Excel file, and your job is to eyeball the Excel file to find if there are any incorrect information not accepted by your system. After you finished eyeballing the Excel file, you take a break and now it’s time for you to enter the data into the system. What makes you feel terrible is that you have to enter the data row by row, and there are more than thousands of transactions staring at you from the Excel file. After typing on your keyboard for a few hours, you become exhausted and starts to make mistakes. You began to think if you are meant for this job for the rest of your life.
RPA bots can help people do repetitive and demotivating tasks faster. Most importantly, RPA bots make fewer or zero mistakes. RPA bots are also gaining popularity among the C-suites because it helps organizations to improve cost efficiency and productivity levels. Before you get excited to build your own RPA bot, there are four things to take note of before you start your project.
Four main steps in a typical RPA project:
Extract — Clean — Update — Result.
Extracting the data
In an RPA project, data sources are usually text or Excel files attached in emails or located in shared folders within an organization. When the bot is retrieving the files, it will need to save the data source in a local machine or environment before extracting data into variables that are readable and changeable by the bot itself.
It is also a best practice to save a backup of the working file. Keeping a separate backup file is most useful when you need to refer to the original data source for debugging purpose or when you need to investigate where the robot got stuck when executing a task.
Like any data analytic projects, cleaning data is also an essential step in an RPA project. For the bot to execute a task smoothly, the data used by the bot must be clean and ‘acceptable’ by the system or application. If the bot did not pre-process the data source thoroughly, the bot would throw an exception rather than process the transaction as configured. If the bot has not been ‘taught’ to handle a particular scenario or exception, then most likely the bot will get stuck at a specific screen or in the middle of the executed tasks.
In terms of how strong you should build your data validation rules for your bot to follow, it should depend on the system requirements that the bot will be working on. A rule of thumb when building data validation rules for an RPA bot is to make sure that the bot will not input ‘wrong but acceptable’ data into the system, yet it should be ‘smart’ enough not to throw exceptions for all of the records.
A simple data validation sample would be: Bot expected to input names from Excel file into the system. If the length of the name is more than 200 characters, the bot should throw an exception, and a business user should handle the case.
When data has been cleaned and ready to be used by the bot, it is time for the bot to do the magic.
Since RPA bots anchor on application screens most of the time to do its job, it is at the utmost importance that the system screens used by the bots are stable and will not change anytime soon. It can be a hassle if you found out that IT or your system provider decided to remove two fields from the screen after you completed configuring the bot.
Some scenarios that you might face when automating data entry in an RPA project:
- Automating data entry in an emulator or legend system: Scrapping the screen and building flexible keystroke shortcuts are essential to moving the cursor around in all kind of scenarios.
One rule of thumb when configuring the bot to do data update/entry: spy — scrap — enter.
Regardless of the system type that the bot will be automating on, the bot must be able to spy on the screen to see the elements. If the bot is not able to ‘see’ the screen, it will not be able to scrap the screen data to do data massaging. For example, if the bot is not able to locate the name field in SalesForce, then it would be impossible for the bot to enter any names retrieved from the Excel file into the system.
A typical RPA task usually ends by the bot providing the user reports.
There are three types of reports that a bot can provide — a transaction report, an audit report, and a statistics report.
A transaction report is usually printed by the bot back in the data source file or any other file types as long as it is easy for users to refer the printed results back to the original transactions. The bot will print results right after it finishes processing one transaction and before going to the next. A transaction report typically includes task status and remarks for failed executions. Using the name example again, if the bot failed to input Mark’s name because Mark provided more than 200 characters for his name, the bot will reject Mark’s input as it does not meet the system requirement and print the result in a designated Excel/text file as:
Customer name: Mark XXXXXXX(*200)
Status: Not processed
Remarks: Name provided has more than 200 characters. Please contact the customer for verification.
After the bot has executed all transactions, it can be configured to print an audit report. An RPA audit report typically includes task performed time, task status, selected transaction data such as customer number and changes made in the system. This report is especially useful if the bot is doing multiple tasks in a day. Nonetheless, this report is also essential for audit purposes.
It is also a best practice that the bot provides users a statistics report whenever it finished executing a task. The statistics report can be in the form of an Excel file in shared folders/local machine, or an email automatically sent to users. Typically, users will receive two types of statistics report.
A ‘success’ statistics report typically includes task end time, the number of transactions successfully processed, the number of transactions failed, and the number of transactions not processed.
A ‘failed’ statistics report usually serves as a reminder to the user that the bot has faced an issue that requires the user’s attention. For example, the bot can be configured to send a termination email when the system is down or too slow, and for login failure which requires the user to resolve before the bot can continue to execute tasks again.
RPA bots work the best when the task to be automated is rule-based and requires minimal decision-making. By using RPA bots to do these redundant tasks, human are sparred from having a ‘robotic’ lifestyle and can spend more time on analytical tasks. Most importantly, RPA bots are available 24/7 to work, and… no complaints!