Part IV: Pitfalls in implementing process automation
You bought your shiny new RPA tool, and now you’re ready to build your software robots. Do you have an automation strategy? If not, see Part II. If you do, then you already have your top five to 10 automation opportunities defined, along with the expected ROI of each. You probably already have your requirements document for the first opportunity. You have your team in place and ready to go. But how do you really go about implementing process automation?
Before you hand over your RPA tool to a programmer, make sure you have applications — preferably test versions — and test data ready to go. After all, you don’t want your programmer using production applications and data! Make sure you have enough test data that the programmer can go through each scenario at least a dozen times.
Perhaps you have the type of data that either disappears or is moved to another state after processing. If so, make sure your programmer understands this and, therefore, waits until the end of the programming process before actually submitting the data.
Keep in mind that the programmer will run into issues, and must run the scenario multiple times with multiple pieces of data. That’s why you need enough records with the same issue — so the programmer can thoroughly test each scenario and each business rule.
Types of testing
Testing is obviously a crucial part of implementing process automation.
When programming is complete, the programmer should run unit tests on each scenario and document the results. Some tools can self-document the unit tests.
The business should examine these results before moving to the next stage, system integration testing. All this really means is that you configure the new process into the server and then run the tests again, to make sure everything works from end to end. If your automation solution is a standalone desktop RPA tool, you probably won’t need to do system integration testing; but, with a more powerful, server-based automation solution, you will have that need.
The last step before moving to production is user acceptance testing (UAT). To do proper and thorough UAT, you need several records for each scenario. You also need records that fit multiple scenarios, so you can make sure the robots can handle multiple scenarios for a single record. A typical volume for each scenario is 100 records but, depending on your situation, you may need more, or fewer.
The importance of audit logs
After running UAT, the business will evaluate the results, using the standard tools it has available. However, if your automation solution provides audit logs — and it should — that can be a great way to validate that the robots followed the correct rules. What often occurs is that the business tells you the robots didn’t work an item correctly. If you don’t have auditing capabilities, you’re looking at a long day of trying to figure out the problem.
I have worked with customers who said the robots did the work incorrectly. Yet, the audit logs showed the robots did exactly what they were programmed to do, based on the requirements document. It turned out that the requirements themselves were wrong. That’s a simple fix, with little time spent troubleshooting.
Trust me: make sure you have a product that provides audit logs!
When it’s “go” time
Now, finally, it’s time to deploy to the production environment. Here’s a typical scenario: everything works in unit testing, system integration testing, and UAT, but fails in production. What happened? There are two common causes for this:
The data used in all of the testing phases didn’t properly represent production data. You can fix this only by having good data. It’s critical that the data used in testing matches the production data.
Moving the code from test to production changed something. This may be due to the tool you’re using. Some products provide a deployment function that ensures the code you tested is exactly the same code you tested. This is a great feature! You should make sure it’s part of any product you choose.
Implementing process automation is a major, and wise, step for your company. Here’s hoping this post will help make it go a little more smoothly.
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.