Your RPA Strategy Is Out of Control

Many companies decided to start their RPA journey by experimenting with one RPA product and one process just to get a feel for it. One thing led to another and soon they had multiple processes automated and were planning even more. However, department A wasn’t talking to departments B or C, and each department started on their journey independently. When someone in the organization finally decided it was time to put some structure around RPA, they ended up with multiple RPA products with no real strategy to manage the environments.

The main reason for creating a structure, or center of excellence, around RPA is to ensure the business departments are able to effectively manage their automation strategy without negatively impacting the company as a whole, including the IT department. RPA works by interacting with application screens. It’s important for the business to understand if/when those screens could change, so the robot navigation can be updated to accommodate those changes. It’s also important for IT to know that robots are working against the user interface of the applications so they can appropriately manage the application resources to ensure there is no negative impact on performance. After all, robots are faster than humans and could have an impact on the applications.

When putting structure around an RPA strategy, there are two very common but different approaches. The first is a federated approach. This approach allows each business department to use an RPA tool of their choice as long as they follow the guidelines set by the governing body. The other approach is unfederated, or centrally controlled. This approach would only allow the business departments to use an RPA product that is sanctioned by the governing body. This puts a great deal of responsibility on the governing body, but also prevents mayhem by insuring the RPA products have been fully tested and the management structure is in place to deal with any issues. Regardless of your approach (federated or centrally-controlled), you still have an issue any time you have multiple RPA products to manage.

So, how do you monitor, manage, and control all of your RPA products? One solution is to use an orchestration platform that supports third-party RPA tools. One such solution is AutoiQ from OpenConnect. AutoiQ utilizes a small software agent that runs on each desktop and interacts with the desktop robot. This allows an organization to solve multiple problems by:

  • Providing a solution that manages multiple vendor robots
  • Utilizing the best products for each department with governance
  • Integrating multiple vendor products into a single solution

AutoiQ provides a single interface to manage the desktop connections, credentials, and third-party robots. You can even create process definitions from a simple-to-use interface and call third-party robots to execute tasks. Since AutoiQ is task-oriented, you can create tasks to perform small units of work, such as “Get Customer Information,” and each task can utilize the RPA product chosen by the department that owns that task. AutoiQ will then orchestrate the various tasks, including tasks within AutoiQ, to execute an end-to-end process. By utilizing the advanced features of AutoiQ, and the existing RPA products, you can automate more processes, and more complex processes — all with a centrally managed enterprise-level automation solution. And, with the most advanced mainframe connectivity available, AutoiQ can reduce the amount of time per work item, which reduces the number of robots and desktops required to do the same amount of work. It’s one of the most effective tools to help take your RPA strategy from out-of-control to under control.

Is RPA Really Designed for Business People?

According to all of the marketing from RPA companies, any business person can use RPA and quickly automate their business processes. Unfortunately, most don’t get the expected return on investment and many can’t even automate more than a single, simple process. The main reason is that RPA is really programming. Yes, the RPA vendors try to make their tools easy to use. But if you have any business rules that are more than if-then statements, then you really should know some basic programming. For most business processes with an average amount of complexity, you will need someone with programming experience. But programmers aren’t subject matter experts on your business processes. So how do you educate them on the processes so they can create the automation logic?

One method is to use a task-oriented architecture. This will allow you to separate the business logic from the screen navigation so that the business analyst can focus on defining the process and a task programmer can focus on small simple tasks. A task-oriented architecture provides a section containing only business logic. The business logic calls tasks to perform work. For example, if you need to retrieve customer information the business logic would call a task called getCustomer, and it would pass in a customer ID. The task simply navigates screens and returns customer information based on the customer ID passed into the task. However, if you’re using a standard desktop-based RPA tool, there really is no way to separate the business logic and task logic. It still requires a programmer to create the business logic and the task.

The AutoiQ way

OpenConnect’s AutoiQ provides a better way. Since it’s server-based, not desktop-based, business analysts can create the business logic and programmers can create the tasks. The business logic is created through a standard Web interface and is fully versioned. This allows a business analyst to add logic then increment the version number before testing. If errors are found, a few mouse clicks gets you back to the previous version. You can add logic and change versions as often as you like without impacting the production version. The tasks can be created using standard RPA tools, the OpenConnect mainframe tool, standard Web services, or direct database access. Any of the most common RPA tools will work with AutoiQ. If you already invested in RPA but are having a difficult time actually automating your more complex processes, then use AutoiQ to handle the logic and your existing RPA tool to create the tasks.

In addition to providing version control for the process definition, AutoiQ also allows you to have different environments such as Dev, Test, and Production. A process that is marked as Dev will only access resources, credentials, and tasks that are also in the Dev environment. When promoted to another environment, it will then use the resources in that environment, allowing you to take advantage of standard environments without the need to move multiple pieces to different servers. Other RPA products require you to use a third-party version control system designed for programmers.

All of the AutoiQ features result in lower development costs, faster return on automation investments, and the necessary governance controls to deliver enterprise automation at scale. The flexibility and control built into AutoiQ give business people the power to master their RPA.