Robotic Process Automation (RPA) technology can be applied in a range of industries. Demand is growing for robots to reduce costs and create efficiencies, especially in labor intensive processes. While many CFOs are now aware of RPA as an option, most are unfamiliar with the ‘How?’ How exactly does a robot perform tasks that have, until now, been performed by human employees? A fundamental understanding of how the technology works will help you see through the eyes of a robot when assessing the process landscape for automation opportunities.

RPA is a mature technology with many levels of sophistication. Software processing robots that take repetitive processes and perform them efficiently at high velocity are becoming an affordable solution for companies in the finance and consumer industries where, currently, people are performing the high-volume, highly transactional components of processes.

How Robots Are Deployed

Describing this software as a ’robot‘ may not sound intuitive, and most think of a robot as a physical machine or hardware. RPA uses the term ‘robots’ as they are each separate identifiable processing entities operating under the software.

Many vendors offer a package that includes the software license and a standard number of robots with additional robot units available at an incremental cost. Each robot deployed operates within the software but are individually identifiable with the same unique IDs and credentials as their human counterparts.

Any robot joining your team will need its own computer, email account, and credentials to access each software application. Each robot’s body of work is fully distinguishable and auditable, also each robot can be assigned to unique or overlapping tasks/functions depending on the resource and processing needs at a given time.

How Robots Work

To a human observer, the way in which the software robots perform tasks will look familiar. Has someone from IT ever taken control of your computer by using the cursor to open system folders that you didn’t know existed as they troubleshoot? That’s what a robot looks like in action, but run by software and probably much faster. Not only can you observe a robot at work, almost all robotics software includes the functionality to retain a log of activities for improved end-to-end process visibility and auditability.

There are significant differences between robots from different vendors. Under the surface, there are two ways that robots learn what to do and two ways that they can execute processes:

How Robots Learn

The robots’ tasks are assigned, prioritized and scheduled from a command center managed by a human team member. The key difference is in how the robot learns how to perform the process

  • Approach 1: Human Observation – The robot software observes a human performing the process and records the key strokes. The robot then replays the recording to execute the process. If there are any changes to the process or systems used, the software may require a new recording.
  • Approach 2: Defined Process Maps – Process maps are defined in the RPA software. Each step and decision is documented and the robot follows these flows when executing the processes. This takes longer to establish and requires more detailed knowledge of the processes, especially when deviating from the most common path, but is also easier to update when there are changes and allows the robot to handle more process scenarios.

How Robots Execute

In the RPA landscape, there are two distinct approaches to the solution once the robot has access to the necessary hardware and software. The key differences are in the way a robot sees and interacts with the software applications your company uses

  • Approach 1: Screen Scraping – the software relies on location or visual appearance of buttons and objects within each application. The robot repetitively performs the same task based on set rules including button and object locations. One downside is that the robot is not receptive to changes in the application interfaces – any physical changes to buttons/fields might require a manual update to the recording/process/decision flow to recalibrate to new-look interfaces or screen layout.
  • Approach 2: Code Reading – the robotic software reads the underlying code of each application – known as Application Program Interface (API), which allows for more efficient task processing. When the robot is interfacing with applications at a lower level, data input or transfer can occur while screens are still loading – before it becomes visible to the human eye or the screen scraping robot. One downside to this approach is that some applications require a fee to access the object repository that would allow interaction at the code level. However, once available to the robot, the underlying code changes less frequently than the visual interfaces in many applications. This option is more efficient but also more expensive and takes longer to initially set up

Generally, the more similar approaches are paired together, but this doesn’t have to be the case. Many combinations of these approaches exist and one may fit your organization better than another. Either way, keeping these in mind will help you figure out what’s going on under the hood of the RPA software and help you find the software tool that is the most compatible long term solution to your process automation.