In our offices, just like in life itself, we find all kinds of people: some are friendlier, others better prepared, some communicate more effectively, others work long hours, some have more experience, and so on. We can all agree that diversity enriches companies, and it makes sense to assign each position to the profile best suited for it.
On the other hand, I’ve noticed that the expansion of RPA (Robotic Process Automation) technology in large companies is leading to the creation of robotics departments—sometimes called RPA factories or automation centers—which typically create between 30 and 50 virtual workers (software robots) per year. Some even more.
Following the traditional corporate software purchasing model, these companies have selected a single RPA tool, just as one might choose a single ERP, a single CRM, or a single ECM (Enterprise Content Management) application. As a result, it can—and often does—happen that if this RPA tool isn’t flexible enough, all virtual workers end up being the same and performing very similar tasks, leaving other potentially more profitable processes unautomated.
Some companies already have virtual workers with a good reputation who efficiently automate basic processes, but find themselves stuck when they want to go further. I understand that these companies need to add tools capable of creating virtual workers with more advanced abilities.
For example, virtual workers that can access applications without the need to connect to a PC or desktop. This is the case with Web Automation, where virtual workers can access web pages, web interface applications, Excel files, XML files, or Terminal Server sessions directly in memory, without having to open browsers or connect to other machines. This means huge savings on infrastructure. For instance, using 20 virtual workers for these kinds of tasks translates to saving the infrastructure required for 20 machines or desktops. In fact, I know of two cases with more than 5,000 virtual workers of this kind. I believe this type of robot is essential in any RPA factory.
Another highly valuable feature is the ability to classify documents and extract data from them to make decisions and continue a specific process based on those decisions. This is known as Intelligent Process Automation. It’s true that you can always purchase an external application that your robot can call, but it’s much more advantageous to use a tool that already has this feature integrated. This enables faster and more cost-effective growth by avoiding disparate maintenance, independent updates, and lacking a unified roadmap and architecture. These kinds of robots will be the foundation of the second wave of RPA, which will arrive once the basic processes have been automated. I would also recommend including this type of robot in any RPA factory.
Another point to consider is the way we can invoke our virtual workers. Ideally, they should be callable directly from any application—as a web service, as a scheduled process at regular intervals, or as a batch process (what’s known as “Unattended Automation”)—and they should also be callable manually by selecting them from a list, even with a keyboard shortcut or when an event occurs on our desktop (“Attended Automation”). Most RPA tools offer one or the other way to be invoked, but it’s important that they support as many as possible. Personally, I believe that being able to deploy a robot as a web service has many advantages. Tools that deploy their virtual workers on a server and can be called from any workstation without local installation will always have a competitive edge.
In summary, I think we should ask ourselves whether, with RPA technology, we’re simply buying software or actually hiring workers (virtual ones). In the latter case, I would recommend looking for virtual workers who are capable of taking on multiple job profiles. And if you’re missing a specific profile, the best approach is to “hire” it and add it to your workforce, just as you would with any other employee.