Digital Transformation with Robots

Automating systems together is tough. People often skip thinking about how their systems will work with other systems. The business is stuck with Human Automation (people transferring data between systems) as the only solution to make systems work together. With the focus on digital transformation and improved efficiency, the need to make systems work together without people is even more important. But to make systems work together, you have to find a way to do it.

In the past, you would hire developers to build out system automation solution. System automation uses APIs within the systems and require an orchestration service to be built for the systems to work together. It requires the building of API if they are not there. Often, APIS are not there because the need for them was not a priority when the system was built or purchased. But with demands of a modern business, APIs are now critical. Another developer needs to make them work together by orchestrating the APIs calls to complete the task.

Robotic Process Automation (RPA) offers an alternative option to programmatically integrating systems together. RPA allows building an automation by simulating a user (robot) using the system. The robot performs a set of actions on a computer just like any user. Unlike a person, the task can run 24/7 and repeats the process without getting tired or making any errors. A robot is the perfect replacement of a person for high volume repetitive tasks. Some great use cases of RPA are:

* Moving data from one application to another application

* Comparing values from multiple screens and generating a report

* Typing in a set of values from a list or spreadsheet into an application

* Navigating an application to a screen based on a trigger

RPAs are built by creating a script of actions on the system. An RPA developer/analyst makes a recording of the task and then modifies the script to connect all the data points togethers. Once the script is done, the script is tested looking for correct behaviors and to identify additional logic to deal with errors that might occur. Writing an error free RPA script is difficult so the first few weeks will be bumpy with script updates to address errors that never occurred in test. But the solution is developed in weeks compared to months or year associated with system automation.

RPA can be used in two different ways. The most common use case is Process Automation where multiple systems are connected together to complete a human task. This involves the robot talking to multiple systems to perform a task. An alternative use case is where RPA is used an API End Point to a system. RPA as an API End Point allows a robot to perform a task that would normally be done by an API. This is a quick way to solve an integration without all the work of building an API. We will dive into both use cases.

---

Process Automation

Process Automation is the most common entry point for introducing Robotic Process Automation into a company. The business case is very simple. Find a highly repetitive task done by a person and replace it with a robot. Add up the savings and use it to pay for the next automation. The business case becomes pretty simple after the initial investment. When I led the creation of the RPA Center of Excellence, we achieved 100% ROI on the licensing costs on our first project. By the second project, we had covered all the labor. And each additional project just led to greater savings for the company.

Process Automation creates tactical wins for the business. It doesn’t fix the underlying problems of a closed system. But it alleviates the restrictions and allows the business to automate and save labor. The system still does not have APIs, data feeds for analytics, or cross system work management. To solve those problems, it potentially requires refactoring the application or replacing the application.

---

API End Point

The other option is an API End Point. Some of the RPA platforms allow automations to be triggered by an external call from another system or integration platform. The RPA scripts the logic within the UI that would have been executed by the API call. The call executes slower than a typical API but can be used with the enterprise. This is way faster than building out an application. However, it will never scale for high transaction volumes and runs the risk of timeouts and timing issues.

The alternative to RPA as an API End Point is to build an APIs for the system. The time and cost associated with building an API into a system is significant but offers options that make it a more scalable and consistent solution. Several options that you can consider:

• Refactoring the code to create an API used both by the user interface and other systems.

• Build an API layer that directly updates the datastore

• Upgrading or replacing the system with a new package that has API capabilities

If you choose to build APIs for a system, you may still want to build an API end point using RPA as a tactical solution. The low cost of building RPA may give the business a quick boost while waiting for the more permanent solution. Also, orchestration service and other systems can start using the API while the build is going on.

---

RPA is a game changer for most enterprises. It allows people to quickly build automations without touching the code of the system. RPA is quick to build and can often be done by analysts or testers without the need of a tester. As a result, most projects have return on investments in months after the initial software purchase. As companies look to improve efficiency, RPA is one of the best solutions to reduce cost and improve quality.

---

Pro Tips

• RPA still requires good architecture and security awareness. A robot should follow the same security controls as a person. A robot should never have an account with more rights than any other user in the system.

• Testers are often good candidates for writing RPA scripts. They have experience with test automation tools and RPA scripting is very similar. Being part of the test team, they are aware of upcoming deployments and can double check the automation.

• Build a prioritization spreadsheet to manage demand. The spreadsheet should use quantitative metrics helps identify the most beneficial RPA initiatives. Common factors should include frequency, user error frequency, and time to complete the task. Perceived priorities did not yield the expected efficiency gains.

• Different vendors sell different types of robots. Back Office robots execute on a server and are typically scheduled to run at specific times. Front Office robots run on users desktop and assist them with a task. Companies may need both types of robots to address all their needs.