Robotic Process Automation (RPA) projects follow the typical software development life-cycle (SDLC), like any IT project.
After the process prioritization and requirement gathering stages, a sufficient amount of time should be dedicated to solution design before any implementation/coding happens.
Each automated process should have a solution design document.
The RPA Solution Architect mentality: Think before you build!
A solution architect is a person who understands the technical aspect of the RPA tool, the business process to be automated, and the IT landscape within an organization. On a day-to-day basis, this person will take on a macro-view of the automated platforms, and making sure that all are integrated accordingly. Communication with various stakeholders, problem-solving along the way are also some essential responsibilities of the solution architect.
Below are a few points that the solution architect or any person taking the role of doing solution design for an RPA robot should take note of.
Robot design 101: Understanding how your robot functions avoid design issues in the future
Before any real coding happens, think about how the robot will be triggered in the future. It is important to understand the robots’ organizational structure when doing solution design to avoid performance issues. For example, if an organization decided that it will only trigger the robots once every day, then you will want to design the robot to process ALL files at one trigger rather than one file per trigger.
Process improvement: Don’t automate the bad process, fix it!
It is tempting to automate the process just as how it is at the moment in an RPA project. While it makes the project seems more straightforward, it doesn’t help an organization improves. The RPA robot will only make the already bad processes uglier. That is why you should always think about how to streamline the process better before diving into automation. A rule of thumb is to let the robot complete a transaction with minimal screen movements.
Read here for a helpful tool that can help make gathering requirements easier in an RPA project.
Data modeling: Standardize data input source for effortless data validation
After streamlining the process, understand how the data flows between systems and how you would like to structure them in a presentable format. If the robot is taking dynamic data from an Excel spreadsheet, think about how users should fill the template and how the robot can extract data from the source without too much trouble. A standardized input template will help make the data validation part easier.
Other than standardizing the data source, take some time to understand the validation rules in each system. A validated data will prevent error messages/pop-ups from showing up, which may cause the robot to go haywire.
Common components: Don’t repeat yourself (the DRY principle) for the same process
One of the reasons RPA robots are so popular is its ability to scale quickly. If an RPA robot is dedicated to automating a hundred processes in one application, why build the same login function every time you automate a new process?
When doing the solution design, keep the idea in mind that a particular step should be usable with minimal work for the next process. Most of the automated processes would share a similar structure, including data extraction, login, navigation, write output to an Excel file, etc. In a nutshell, these are the steps that can be copied and pasted in the future.
Scalability also means less hard codes and more dynamic variables in development.
Monitor & control: The four-eyes principle to maintain quality and improve transparency
Delegating tasks to the robots free up people’s time for meaningful work. Having that additional resource (robot in this case) is great, but how can you make sure that it’s doing the right thing? How can you make sure that it didn’t put Freddie’s address under Sam’s profile?
The four-eyes principle is a controlling mechanism that a decision/transaction has approvals from at least two parties. In an RPA project, the robot would be the maker (doing all the transactions) while the user should be the checker who ensures that all the automated work is done accordingly.
Therefore, each RPA robot must have a built-in step/function that generates a report/audit log for each transaction they do. This component will help to increase transparency and gain trust from people who are not familiar with RPA.
Designing a smart robot to handle exceptions: Sink or swim!
Let’s face the facts. RPA robots are not artificial intelligence robots who can learn and become smarter over time. If an RPA robot is not designed to handle an exception, it will not move beyond the screen and most likely be stuck indefinitely.
With this inherited nature, exception handling becomes an essential part of the solution design. Therefore, listing out as many exceptions as you can help to prevent the robot from going “out of control”. When doing workshops with stakeholders to understand their current process, take the opportunity to observe how the stakeholders overcome an obstacle (error message pop-up timing and their reaction to it). These exceptions will most likely happen when the robot is automating the process too, so the earlier you know about the hiccup, the easier it is to design the robot.