Robotic process automation: Part IV of a five-part series

implementing process automation

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?

implementing process automation

First considerations

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.

Robotic process automation: Part III of a five-part series

Choices

Part III: Choosing the right process automation solution

Do a search for process automation or robotic process automation (RPA). You’ll get hundreds of results for tools that let you build software robots. Does it really matter which one you choose? They’re all the same, right?

Wrong!

What’s right for one department may not be right for you. Your team IT might have a solution they’d like you to use, but it may be complex and too expensive for you. So how do you really choose an automation solution?

Choices

Understand the problem

First, you need to understand the problem you’re trying to solve.

  • Are you trying to reduce head count, or simplify a process so as to increase productivity?
  • How complex are your processes?
  • Do your processes contain a lot of complex logic, or are they fairly simple?
  • Do you have to access a lot of applications, or just one?
  • Will you need a high volume of robots, or just a few?

There are two types of automation solutions available.

Process automation, also called business process automation, is a server-based solution that uses application programming interfaces (API) and Web services to interact with applications.

The other is RPA. It runs on a desktop PC and interacts with applications the same way a human does — through the user interface.

Both have advantages and disadvantages. Multiple factors will influence your choice. Don’t choose an automation tool simply because of the hype surrounding it.

So, again, we come back to . . . how do you know which way to go?

Maybe you have very simple processes that anyone can learn to do in a short time. If a human can learn the process with less than a day of training and maybe a few days of experience, that’s a simple process. In that case, you probably need only a simple RPA product. However, if your process has many different scenarios, and each can take a week or more of training and several weeks of experience before a human can perform it, you have a complex process. If that’s your situation, you should be reluctant to purchase an RPA product until you do your due diligence.

Hybrid solutions

Let’s say you determine that you have a complex process and you therefore don’t believe an RPA tool is appropriate for your needs. What do you do?

You could contact your IT department and see if it has a process automation solution that can handle complex processes. But that will work only if your application has an available API with which the automation solution can interact.

However, there is an alternative.

There are some hybrid solutions that constitute the best of both worlds. They’re server-based solutions that can interact with applications using an API or Web services. They also have RPA components that can interact with applications through their user interfaces. These hybrid solutions usually aren’t considered to be RPA, so they’re a little more difficult to find in a Web search — but it’s worth your time to seek them out.

Hybrid process/RPA products allow you to handle complex processes while still utilizing applications’ existing user interfaces. This type of solution can be implemented and managed by your IT team, and it fits into their overall automation strategy. In addition, some business units have been successful implementing this type of solution without IT involvement, because it doesn’t require complex programming or special interfaces. One cautious reminder, though: if you’re going to implement this type of solution, it’s important that you have a good automation strategy (see Part II).

Part IV: Pitfalls in implementing process automation.