During my career, I have participated in many Proofs of Concept (POCs) using various software solutions. POCs are a resource sometimes used during the sales phase to demonstrate a series of specific, pre-agreed functionalities.

Since a POC can require significant effort without any guarantee it will result in a sale, we (software vendors) only undertake them when we see a clear commitment to purchase from a client who wants to confirm that the solution will work with their particular business requirements. As a general rule, we do not charge for this work, as our goal is to sell the solution.

A clear alternative to POCs are references, which can be used to verify that the solution works for other clients. We also often do personalized demos or even technical workshops. There are also what we call Pilot Tests, which are real installations on a small scale and in the client’s environment. These tend to last longer and incur associated costs. One could write a whole article just about these presales tools.

The fact is, the emergence of RPA technology has truly revolutionized digital transformation projects, and it’s something many companies are interested in, as it is a quick and simple way to start automating tasks. For example, in 2019 we averaged two to three new inquiries per week specifically about this technology. If we assume a similar or greater trend among our competitors, and add to this the fact that some RPA vendors now have more and more distributors (some solutions offer free online training or open-source versions), a market is being created in which almost anyone can sell you an RPA solution. Moreover, it’s becoming customary to do a POC for every interested client. That’s why today, the words “RPA” and “POC” are more closely linked than ever. And I wonder why.

Personally, I think it’s all related to the new distributors popping up everywhere. Since they don’t have good references yet, the POC is a good way to earn the client’s trust. In theory, it’s an easy technology to implement. Also, almost all of them charge for their services, so they have little to lose and, at the same time, get training on the tool by implementing a project. Naturally, this means that some POCs don’t turn out well, but it doesn’t matter much since there’s another one waiting the next week. I get the impression that more POCs are being sold than actual final products.

This way of doing business means that if a potential client likes your solution, they’ll end up requesting a POC, because others have offered them one.

Let’s be honest: any of the best-known RPA solutions are capable of automating a specific task. It may take more or less work, but it can be implemented. So, are RPA POCs really useful?

Considering that the AIIM Emerging Technologies Report (2019) indicates that only 3% of companies have managed to scale RPA technology with 50 or more robots, it’s clear that focusing solely on doing a POC for a specific task doesn’t provide the full picture.

In fact, most of the time, only that same task or perhaps one more ends up being automated. This is because the chosen solution doesn’t allow work at a corporate level, or the vendor doesn’t have the experience to help set up a center of excellence or expand the solution.

Therefore, my conclusion would be that a Proof of Concept on a specific task does not always indicate the suitability of a solution. One must also consider how far the product can go at a corporate level and who is implementing it.

There is a trend in many RPA-related communications to add the words “Artificial Intelligence” (AI) to their messaging, in such a way that one might think a certain RPA technology provider includes Artificial Intelligence in their products.

It’s true that both technologies complement each other well, and from any RPA product, it’s easy to call an external AI service. For example, there are already multiple robots that call Google Cloud Natural Language, IBM Watson, or Microsoft Azure Text Analytics services, among others.

However, what really piqued my curiosity was whether RPA products include any form of artificial intelligence natively (without calling external tools). So, after reading numerous articles and watching many demo videos, I’ve tried to separate the wheat from the chaff and identify what the main RPA providers actually include in their products.

But before anything else, it’s necessary to properly understand some basic terms that are used in this context.

Artificial Intelligence

The Oxford dictionary defines it as: A computer program designed to perform certain operations that are considered to require human intelligence.

One of the most important tools AI uses to solve these problems is Machine Learning, a technique by which systems learn something automatically as they are given information.

Different methods are used for learning: probabilistic, classifiers (support vector machines, nearest neighbor, decision trees…), clustering, regression, etc.

Another term that often appears is Computer Vision, a discipline of AI aimed at enabling a system to understand and classify images as a human would. Machine Learning or other techniques are used for this purpose.

Similarly, Natural Language Processing (NLP) is another AI discipline focused on enabling a system to understand and process human language. Machine Learning techniques are also used to identify structure, language, or specific data. It’s worth noting that only about 10% of a company’s documents contain natural language; most use more constrained language depending on the business type.

Since I can’t analyze all the RPA solutions on the market, I’ve focused on the most prominent ones, starting with Kofax, which I know best.

Kofax

Kofax specializes in automating processes that involve managing information contained in documents. Their solutions include RPA, BPM, multichannel information capture, e-signature, CCM, and BI (Business Intelligence). Their RPA solution includes functionality to classify all types of documents and extract data from them. This allows robots to make decisions based on the content of the documents they handle. Kofax has been using AI in its products for over 15 years but has never advertised it.

Classification uses Machine Learning so that the product is given samples of a document type and automatically generates a knowledge base based on similarities among samples. The same is done for each document type. For example, this function can be used to classify all incoming emails and automatically route them to the appropriate department (accounting, customer service, support, etc.).

Data extraction also uses Machine Learning to determine where the data to be extracted is located in each document and learns over time. Most of the documentation that Kofax handles is business-related, but its most advanced function includes NLP technology to handle natural language, extracting information based on its context. In simpler projects, information is extracted from structured documents like invoices, orders, IDs, contracts, etc., and in more complex ones, from unstructured documents such as mortgages, deeds, meeting minutes, etc.

In addition to Machine Learning, Kofax has a powerful rules engine to complement classification and data extraction.

For screen control, Kofax robots can use Intelligent Screen Automation (ISA), a Computer Vision technique that identifies all objects on the screen and recognizes all visible words (OCR). This allows the robot to navigate the screen based on objects (menus, buttons, text boxes, images, etc.) and the surrounding words, rather than relying on fixed positions. This adds a lot of flexibility in production, as screens don’t always have to be exactly the same, with the same resolution and appearance. The identification of different screen objects was done using Machine Learning, training the software with hundreds of example application screens.

Blue Prism

Blue Prism was one of the pioneers in RPA solutions and, though it’s losing market share, remains one of the sector’s references. You can find hundreds of articles about Blue Prism calling all kinds of external AI services, and the product is ready to communicate with the most well-known ones (Google, Microsoft, etc.).

However, I have not found any reference to actual AI functionality built into the product.

Recently, Blue Prism announced the creation of a new lab dedicated to embedding AI capabilities into its product. https://www.blueprism.com/news/blue-prism-expands-r-d-capabilities-adding-dedicated-ai-labs-and-outlines-roadmap-for-embedded-ai-capabilities

The article highlights that the key will be to include the ability to understand data from documents in any format and use Computer Vision to improve bot design when interacting with environments, following the ideas mentioned earlier.

UiPath

UiPath is one of the fastest-growing companies, to the point that many analysts (e.g., Forrester or Gartner) considered it a market leader in 2018. It’s worth remembering that analysts evaluate not only product functionality, which is what interests me most, but also business parameters like market coverage (industries and geographies), number of references, strategy, business model, etc.

Like other vendors, the product integrates with almost any external AI tool. In addition, a few weeks ago UiPath announced the ability to automate screens using Computer Vision: https://twitter.com/uipath/status/1086231426503106560.

This allows robots to avoid relying on fixed screen positions.Unfortunately, UiPath uses external tools to understand the information in documents, and there do not appear to be plans to change this. It’s the only major vendor for which I could not find any roadmap for adding document understanding features.

Automation Anywhere

Automation Anywhere is the third major player in the RPA sector and likely the leader in the American market. It offers IQ Bot, a technology that enables data extraction from documents using AI techniques: https://www.automationanywhere.com/images/products/IQBotBrochure.pdf

Their messaging is heavily marketing-driven, making it difficult to know exactly which techniques are used, but from the videos I’ve seen, I’d say they use Machine Learning to learn where information is located in documents.

However, the functionality seems rather basic. I haven’t seen examples with complex documents (most of the time, invoices are captured, which has been a solved problem for years), and it doesn’t seem to be able to capture data from unstructured documents (mortgages, contracts, etc.).

I also haven’t seen options to complement learning with design rules (keyword searches, formats, or data relationships) or even create fixed templates. And I’m not clear whether the learning must occur before deployment or if online learning is possible (ideally, both options should be available).

Workfusion

Workfusion’s offering is very similar to Kofax in the sense that, in addition to traditional RPA, the solution includes Machine Learning to capture information from unstructured documents, a workflow manager, and analytics and reporting tools.

Workfusion is a relatively new company, fundamentally rooted in the AI world.

Almost all their public news or videos have a strong marketing component. But these two articles give a good idea of how their main solution (Workfusion SPA) works: 

https://blog.workfusion.com/8-steps-to-supercharging-rpa-7b0982e4c7d3
https://blog.workfusion.com/5-top-questions-email-intake-processing-418ba7905e18

Workfusion’s idea is to use Machine Learning (with different algorithms) to extract information from documents (structured and unstructured) so the robot can perform actions depending on this information. The learning steps are standard (gathering significant samples, user support to show where the data is, and generating the knowledge base).

What the solution lacks, in my opinion, is complementing the AI part with a rules engine to implement the different use cases that commonly arise in these projects.

On the other hand, I’m surprised that, as AI specialists, all their public references talk about capturing very simple documents. For example, Workfusion holds a hackathon among its partners to push its technology to the highest level, and in the two editions held so far, the challenge has been to capture invoice information. As I’ve mentioned before, invoice data capture has been solved for over 15 years. I was hoping to find some more complex use cases.

Others

Most RPA vendors are working on systems that can analyze the work users do to build robots automatically (or more easily). Initially, the idea was fairly simple: record part of the user’s work, and the robot would be built by replaying the recorded tasks. This works well for demos, but it’s not very applicable in production because robots need to learn to handle exceptions, so manual configuration is eventually needed.

That’s why there are companies today trying to apply AI to this design phase, so that after observing a user for days, the software will automatically determine all the decisions the user makes based on the data on screen and implement the robot accordingly. It sounds a bit like science fiction, and currently, this solution works well for creating robots that execute the “happy path” (the task a user performs most frequently), but its designers admit it still has a long way to go before it can correctly recognize exceptions.

Conclusions

Let’s not fool ourselves—traditional RPA products, which only mimic a user’s movements on a PC, don’t require NASA-level technology or highly complex programming. If you want to choose the right one for your business, then you must consider its architecture and scalability, and above all, what gives them added value is the ability to understand the information they process, as this enables the automation of many more processes. AI helps in this area, which is why we’re seeing more and more marketing in this direction.

This is the path RPA vendors are following, although, as we’ve seen, there are significant differences between them today. While Kofax has been capturing document information for many years, others are just getting started, like Workfusion and Automation Anywhere; some haven’t even begun (Blue Prism), and others rely on third-party tools (UiPath), which has many drawbacks—different consultants, different maintenance, different licenses, etc.

The first to market are the ones who have dominated so far, but as we know, in technology, after the initial business development phase comes the competition phase (where we are now, with solutions popping up everywhere), and then comes the domination phase, with one or two solutions as undisputed leaders (which aren’t always the ones who started it all).

We still have some very interesting years ahead in the RPA world.

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.