You probably know by now that at least one company in our industry is offering a free RPA tool. You may be wondering: is that good or bad for the RPA industry? I guess that depends on whether you’re a provider or a buyer. I think the buyer perspective is obvious, so let’s look at it from the provider perspective.
If you’re a provider, and you have a desktop-based RPA tool, then you should be concerned. You should be looking for ways to add value to your product, so you can focus on the additional value you provide and not the RPA functionality. Of course, you could also try to compete strictly on features and functions, but it’s hard to compete with free. Or maybe you believe you already have a product that can compete with free. I guess you’ll soon find out.
But is it good or bad for the industry? I believe the answer is both.
On the one hand, it’s good because it will force vendors to look for ways to improve their tools beyond RPA. On the other hand, it’s bad because it makes it easier for companies to implement desktop RPA tools. Why is that bad? Because RPA is not necessarily the right solution for all situations. RPA has definite advantages and can be the right solution, but it can also cause a lot of problems if it’s not implemented correctly.
Best practices for implementing RPA
That consideration leads to the obvious question, “So just exactly how do you implement RPA correctly?” Here are some best practices I would suggest.
Access applications and data using the most efficient, accurate, scalable way available. — The desktop user interface isn’t the best, but may be the only option. I’ll soon talk about what you should do if it’s not.
Make sure the IT department is involved and that you’re on the change control list. — Caution: If you’re using RPA with an application that sees a lot of UI changes, this could hamper IT and delay application improvements requested by other departments; and that will not make you very popular with the folks in IT. Remember: RPA tools rely on a consistent user interface. If your IT department changes the user interface to improve usability, RPA robots may stop working.
Centralize the logic and runtime execution so that you have better control. — A free RPA tool could proliferate rogue departments’ automating applications without the knowledge of their IT department. This could cause major issues and cost the organization a lot of money. It gets back to having a good automation strategy and, possibly, a center of excellence. [Editor’s note: Kevin discusses these and other aspects in his five-part series on robotic process automation, which begins here.]
Provide full auditing and reporting capabilities.
To avoid issues with changing UIs, use APIs, Web services, and database calls as much as possible.
Use RPA when it’s the only option available, and avoid the desktop as much as possible. — I’ll explain that in more detail next.
You really can get around the desktop
Now you might be saying, “Okay, so just how do you ‘avoid the desktop as much as possible,’ and why is that important?”
First, by “the desktop,” I really mean Windows. We all know that Windows updates occur frequently, and Windows applications rely on the underlying operating system to function properly. I have seen updates in Windows and/or applications kill RPA robots.
That’s why you should avoid desktops if possible; but how?
Believe it or not, there are other ways to access many of the same applications without accessing a Windows desktop environment. OpenConnect has been providing automation solutions for over 10 years, and has always looked at automation from an enterprise level. That’s led us to stress the superiority of a server-based approach.
There are two common types of applications that can be accessed from a server: mainframe 3270 applications and Web applications. The OpenConnect automation platform, AutoiQ, has a proprietary data connector that allows it to connect directly to mainframes via the TN3270 protocol. With AutoiQ, you interact with the exact same screens that end users access on their desktop, except that there is no desktop. All sessions run in memory, and a single server supports thousands of concurrent sessions. There’s no desktop and no Windows, just pure, raw 3270 data, processed 15 times faster than desktop-based RPA tools can do it; and the process is 100% accurate.
Embrace Web services and a server-based environment
In a similar vein, there are two different ways to access Web applications other than through a desktop-based browser. The first is through Web services. They’re machine-to-machine communications and are typically available in modern Web applications. By accessing the application through Web services, you completely avoid the user interface altogether. No change control issues occur, because you’re not accessing the user interface.
The other way to access Web applications is using a server-based browser environment. Server-based browsers don’t run on Windows and don’t depend on specific browsers’ functionality. Note that this approach won’t work for all applications; but you should be able to minimize the desktop access.
A few other items that can be avoided include file access and file parsing (reading). Network access to files and the parsing of files can all take place on a server. It is common to have to read Excel, Word, and PDF files as part of an automated process. All of these file types, and more, can be accessed using server-based technology — again, avoiding the desktop as much as possible.
Here’s why you should minimize the desktop’s role
The goal isn’t to eliminate the desktop. That’s probably impossible for most environments. But you should be able to minimize the number of desktops required, thus minimizing the risk. Your approach should be to look for ways to do the work on the server, instead of a desktop. You may find that you can end up with 25% to 50% fewer desktops you originally thought you would need.
With this approach, the desktop becomes just another data source so, if there’s a free tool available, that’s good. The value is in the server and how it executes processes and manages robots — not in the tool used on the desktop.
Free RPA is a move in the right direction
In my opinion, a free RPA tool is good news. It will impel the industry to create tools that provide automation the right way. That means using the right tool for the job, or application, rather than doing everything on the desktop.
I believe the presence of free RPA tools will move our industry to act in ways that will benefit all of us, users and providers alike. I also believe that, regardless of the automation tool you select, you’ll have a better chance of filling your automation if you follow the guidelines I’ve described in this post and elsewhere.
Kevin Culliton is OpenConnect’s Vice President of Product Management and Services. He’s responsible for developing products and capabilities that solve targeted market problems for global enterprises. Culliton has over 30 years of experience in the technology sector and over 20 years of experience providing enterprise software solutions to Fortune 500 companies. He works with many of America’s largest health insurance companies (one of OpenConnect’s key markets), and is an expert in the areas of automation and process analysis for the purpose of automating. Culliton oversees both OpenConnect’s premier mainframe robotic process automation (RPA) solution — which complies with strict industry standards and is used to automate complex processes — and OpenConnect’s operational analytics solutions. He is currently working with current and future OpenConnect customers to provide the next generation of analytics and automation solutions for back-office operations.