The greatest strength behind robotic process automation (RPA) is its accessibility and usability. Unfortunately, these factors can also contribute to its failure in large, scalable implementations. RPA opens the door to technology without requiring a degree or years of experience — putting coding into the hands of end users. However, most executives today expect much larger successes (and therefore cost savings) from RPA. For these instances, an organization needs more than just an end user recording automations on their desktop. The entire solution includes software running on servers, robots running on desktops, security credentials, network connectivity, methodologies to write, test and deploy the programs, and a team of people to support the process. All of these components are critical to success, yet they are often ignored during the initial purchase and implementation of RPA solutions.

RPA should not be looked at as roughly replicating the steps of an end-user. It should be looked at as exactly replicating the steps an end-user would take. This level of precision requires that RPA implementations — to be successful at scale — adopt the life cycle of software development, including major components such as requirements, testing and the underlying infrastructure the robots run on.

Requirements

Like traditional development, this involves clearly understanding and documenting all the inputs (the data a user might receive or see) and all the steps they might take to accomplish their tasks in the system(s) they use. The requirements-gathering process can be as detailed and as difficult as those used in any other traditional IT exercise. RPA that avoids this level of process inherent in many IT organizations runs the risk of only automating what is known as the “happy path”, leading to the often dreaded “missed requirements” fallout that plagues unsuccessful initiatives.

Testing

The testing of RPA automations suffers from the same challenge that IT development has faced for decades: the ability to (a) know all the possible process paths and data types and then (b) actually test them to see what happens. To do this effectively for large, complex automations, the RPA team needs to:

1. Have a deep understanding of the application(s) that are being used in the automation. This includes how the applications work, what the screen flows are, and what messages can and do appear with different (potentially erroneous) inputs. These are all invaluable to know as you start to record the robot actions through several scenarios.
2. Employ a broad, multi-person team for testing. Having team members who are different than the developers conduct the testing of the automations will help to identify and expose scenarios and issues well before stumbling upon them in production. This level of discipline leads to higher quality outcomes and avoids the potential loss of confidence that can occur if too many exceptions are seen after deployment.

Infrastructure

One item that is simultaneously almost never discussed prior to implementing robotic process automation and that is also the driver of significant challenges is the underlying infrastructure that the robots run on. Corporate networks and system setup can easily be decades old and, more importantly, taken for granted. Failing to invite the teams that understand these to the table for RPA discussions often leads to issues down the line with the underlying servers, networks and applications that RPA uses. To succeed, companies need to think about the following:

1. Is your RPA robot going to run on a physical computer sitting on a desk or on a virtual computer in the cloud? Wherever it runs, who maintains it from a technical standpoint? Who downloads updates and keeps it running? Who sets up the user account for the robot and resets the passwords if required? If running somewhere different than regular employee desktops (a VM in the cloud for example), can it even connect securely to all the applications that users normally have access to? Due to the variety of its jobs, a robot often needs access to more corporate applications than any other single user might need.
2. Are your network and infrastructure teams prepared to setup and maintain the VM server farms for the robots? Who deals with an outage? What if the outage is unique to the robots? Who maintains the RPA servers? Who analyzes the network communications to ensure it is operating appropriately?
3. Who sets up, owns and maintains the security access and credentials for the robots to all the corporate applications it has access to? Who ensures that the robots only have the minimal required access as providing full access is easy…but insecure?

One of RPA’s major strengths is its low barrier to entry. It can be easy to understand, allowing an initial automation to be created by end users with relative ease. But the phrase, “the devil is in the details” rings true. If your organization wants effective, scalable and maintainable automations, don’t miss the need to create support structures and teams surrounding RPA. It is often more work than initially anticipated, but if done properly, it can lead to large-scale automation savings. For more information about robotic process automation, click here.