So, your organization needs to elevate automation of its business processes to keep pace with a changing digital landscape and has embarked on a robotic process automation (RPA) implementation. Once your business analysts have identified manual processes that are ripe for automation—perhaps with the help of a tool like the NICE Automation Finder how do you accelerate the process of building your automations?
Broadly speaking, there are two ways to go about it. The first is to use an RPA process recorder function, while the other option is to build the automation from scratch. By utilizing a process recorder, you can record manual processes as a basis for the optimized automated processes. Although this can slightly speed up your time to market with a new automation, for organizations who wish to create a more stable solution from the onset, additional effort will be required to stabilize the recording.
The other option is design-based automation, which involves a team analyzing the process, designing the automation and then building and deploying it. This approach is more time-consuming, but can often deliver better results for complex, enterprise-class RPA deployments. Let’s take a closer look at the process recorder function in RPA.
Recorder function in RPA: pluses and minuses
There’s nothing new about the idea of recording a series of tasks on your computer screen. If you are a power user of Word or Excel, the concept of an RPA recorder function will not be strange to you. You will probably have set up a bunch of macros to provide some simple automations for your desktop work – and you will have noted how with the power of macros to build in productivity tools is improving all the time
The process recorder function in RPA is conceptually similar – it’s one way to speed up the process of capturing the steps in a process and then automating them. It can be a useful tool for a range of simple automations. Nonetheless, it has its drawbacks, and it will take a while for software vendors to overcome some of these disadvantages.
In short, what a process recorder in RPA does is to follow the steps that a user performs and translates them into an automation-ready workflow designed to replicate those actions. If the user clicks on a specific location, the recorder will capture the specific coordinates that that point (and the time between clicks). Since the recorder does not the functionality to analyst the process, a business analyst will usually need to look at the workflow to ensure that it is as efficient and accurate as it can be.
Bear in mind that many tasks and processes are done in a particular way to make them easy for a human worker to follow—in some cases, a robot will not need some of the steps a human worker would, to accomplish a task, and vice versa. Without a business analyst optimizing a recorded process, it might be as inefficient as the old manual process. With this is mind, some organizations do not use the recorder function at all and rather have the business analyst assess the process, after which it is developed from scratch.
Plus, as it watches someone at work, an RPA process recorder cannot necessarily tell whether a user has paused for a specific reason—or whether it’s just a typical human delay. It may not be able to pick up exceptions that will break down the process and might struggle to capture automations with different path options (such as approving or rejecting a claim based on customer details and requirements). Since the recorder is a simplistic tool that cannot assess and evaluate process decisions, it is particularly not recommended for attended automation development.
It also cannot understand the business reasons why the automation took a specific path and not another. Also, process recording isn’t as configurable as the layered design process and doesn’t lend itself to best practices of reusing modules and subprocesses. So, for now, design-based automation will still have an important role to play.
The strengths of design-based automation
Admittedly, design-based automation creation is not as easy as turning on a recorder and jumping in. It is much more detailed, requires more planning, and may involve more people collaborating. However, it is often the correct approach for building more complex automations. With today’s no-code tools, it can be surprisingly easy to map processes and build automations as a business user with no knowledge of coding. More intuitive automation design tools, such as the NICE Automation Studio (link to web page), are specifically designed to bridge the gap between business users and more technical developers.
A good RPA solution will today offer developer tools with drag-and-drop functionality and other powerful, yet easy-to-use, features. Business users are often surprised by what they can accomplish and how quickly they can do so. The design-based approach that many organizations favor today is called a layered approach.
Different parts of the process automation are divided into different layers, each with its own logic and functionalities. Certain aspects need the attention of skilled process architects, while other aspects can be handed off to more focused configurers. This approach to automation design helps ease the process of development and can also make the automation easier to understand.
Where does the recorder function in RPA come into its own?
The points above do not mean that there is no value in process recording in RPA. Process recorders can be helpful for business analysts as they design and build their automations—they can, for example, record manual processes and then tweak them to create truly optimized automated processes.
Ultimately, whatever class of automation you are building—robotic or desktop, attended or unattended—the point is to take a workflow and hand at least part of it over to a software robot. Process recorder functions in RPA can support that goal, but for now, most enterprises will also need human oversight to get the most of the RPA automations they build.
