The secret for success in RPA projects

There is one thing you need to know before starting an RPA project that is key to your project success.

Manu Cohen-Yashar
Towards Data Science

--

RPA is everywhere, it feels like anyone with a digital transformation program must have an RPA strategy. The promise of RPA is huge, but the reality is much less glamorous. It turns out that RPA is confusing. It's hard to implement and fulfill the promise and so numerous RPA projects fail with millions of dollars that are thrown down the drain. Why? What can you do better? By the end of this paper, you will know and understand a simple rule that will lead you to success.

Automation is the future. The financial and psychological gains are obvious. “Let machines do the repetitive and boring work and let humans concentrate on intelligent creative tasks”. It makes so much sense as humans perform so badly when the task is repetitive and machines are the exact opposite. From truck drivers to doctors, everyone hates repetitive boring tasks. All human beings have creativity and insight no matter how educated they are, and we all love using it. Automation is not a threat to the workforce, on the contrary, it is the promise that will make us happier and more productive.

RPA is pitched as the technology that can automate anything. Is it? Let's dig in and see how RPA fits in the story.
Automation has to major pillars: Integration and Orchestration. (Let’s keep the cost to the end). In modern business, almost every use case involves many different subsystems that need to work together in harmony. To automate, machines must be able to communicate and control each of those subsystems. This is not new of course. Integration technologies are available since the early days of computing. Enterprise Service Bus, Message Queues, RPC services, RESTful APIs are just a short list of examples. But what happens when the subsystem of interest has only a UI at its frontend? UI is designed for humans only. It’s not for machines! UI only systems break automation! From business or historical reasons many systems choose not to expose an API. If it is your legacy accounting system or the HR product that was integrated years back, there are many subsystems that only humans can interact with. Of course, it’s far from optimal but that is the reality, so what do we do?

RPA technologies to the rescue. Modern RPA solutions have powerful “recording” engines that can learn how humans interact with the UI and then automate that same behavior. At first sight, it looks perfect, because now we can automate procedures that were available only to humans, but a litter deeper investigation shows one fundamental difference. Machines don’t “understand” the nature of the process that is being automated. Humans do. That simple fact is critical when it comes to dealing with change. Even if a system changes completely its look and feel, humans will be able eventually to figure out what to do because they understand the context. It might take some time, and some experimentation but at the end of the day people will “get it”. Modern web sites change their UI on a daily basis and nothing breaks. On the contrary with AB testing related specifically to the design and functionality of the application presentation, companies collect valuable feedback that helps them improve. With machines its a different story. Fortunately not every simple change breaks RPA recordings. Typical modern RPA solutions use sophisticated methods to identify the components that make up the UI, for that very reason. Therefore hopefully if the order or the field layout changes in a typical UI web-form the recording should not break as it identifies the fields by tag or name or even input type, and not only by order or position. Still, it is impressive to see how little needs to change to break the RPA solution. As we’ll discuss later no matter how much machine learning you will throw at your RPA solution it will never have something even close to human understanding, and thus it will never be able to mimic the logic that humans use when they need to cope with change.

RPA systems bridge the gap between automation processes and systems that were designed for humans only, but it does it in a way that is far from perfect. Thus RPA should be considered as a temporary bandaid, never as a permanent solution. Only the introduction of APIs or other machines friendly interfaces can be considered as a true remedy. It might be expensive and complex, maybe even conceived as impossible, but even legacy systems eventually change (or replaced). At that time you need to make sure that the next version will include APIs. Until then you can live with an RPA automation solution but at the same time, you need to consider all the limitations and the brittleness you introduce.

The next (and more important) pillar of automation is orchestration. Here we describe the logic and flow of the automated process. Again there is nothing new under the sun. Every computer program has a control flow. There are numerous methods to program orchestrations from classic programming languages to graphical flow representations and low-code. It does not matter how you decide to code your orchestration flow, machines can execute it as long as it's well defined. Humans understand the context, that is why we can adapt to situations that were not considered on design time. We identity the entities, map them to existing knowledge, then we use deliberation, and finally, we apply a wealth of cognitive process to find the best set of operations to take.

As of today, Machines cannot do any of this. Machines do not really “understand” concepts like humans do and are not capable of developing a sequence of steps to solve complex problems based on such understanding. Obviously, that will change in the future, but there is a long way to go. Classifications, Regressions and many other Machine Learning methods are important and useful but we should be careful not to confuse them with human-style understanding. Speaking of computation of an optimal flow of actions for solving a complex problem… The purpose of Reinforcement Learning is to teach machines to do exactly that, put it simply, how to find an optimal policy (i.e. series of actions) for solving complex problems (i.e. earn the maximum reward), yet the math shows that the complexity of such algorithmics (e.g. Markov Decision Process) grows exponentially with the number of states the make the “world” of the problem. There are impressive implementations of Reinforcement Learning in robotics such as a robot that learns how to walk or fly a helicopter, but if we want to solve everyday problems that we all face at work on a daily basis in the “real” world we will need computers that we do not have today. Research in Cognitive and symbolic AI might give us in the future methods to teach computers world knowledge that humans use so naturally, but the research did not even scratch the surface of what needs to be done. Probably it's going to be many years before we get there.

To demonstrate my point I would like to mention GPT-3 which was released by OpenAI on June 11, 2020. This is by far the biggest neural network ever created. At the core its a language model that generates text by finding the most probable next word. It was trained on most of the internet and a corpus of books that includes most of the text that was ever written throughout history. It's just impossible to imagine a bigger training set. The results are more than exciting, but is there true intelligence in that network?
At first sight, it might look like there is. You can ask GPT-3 almost anything and get pretty good results. It can compute arithmetics, compose code snippets, and tell you about historical facts. It can even author original short stories that look totally human-created. To figure out if OpenAI created the first true human-like intelligence lets do the following simple test. Arithmetics is simple enough so let's play there. First, let’s ask GPT-3 to solve simple arithmetic problems with numbers on the scale of hundreds. GPT-3 will respond with the right answer with impressive precision. Great, now let's repeat the same set of problems but now with numbers on a much larger scale. As numbers grow GPT-3 will struggle. This is not what we expect from a machine that truly understands what numbers are and what is the meaning of an arithmetic operator. The simplest 1$ calculator from the dollar store solves arithmetic problems with numbers both in the hundreds and millions in the exact same computation quality. The scale does not matter (as long as it's reasonable). Calculators are not intelligent, we programmed them exactly what to do, but GPT-3 was not designed to solve arithmetics. It just read all the books in the world and so we now try to figure out if it did learn arithmetics from reading all this text? Unfortunately, I believe it didn’t. It turns out that arithmetic problems with small numbers are very common in common text. It could be explicit arithmetic expressions or tables of data with a “sum” column that implicitly tells GPT-3 how much is A+B. Arithmetics with large numbers is just too rare so GPT-3 fails to learn it. More importantly, it proves that GPT did not apply true arithmetics to solve the exercises we submitted. It simply computed text probabilities. It does not “understand” the world as we do, and so it cannot draw conclusions or apply cognitive processes.

Today a machine that can design a good orchestration that defines the flow of effective integrations with other subsystems to deal with ambiguous situations is science fiction, but remember: The hoverboard was also science fiction in “back to the future”. Human intelligence and Artificial intelligence are profoundly different. Don’t confuse them.

The last point I want to discuss is cost. As we have learned RPA solutions are brittle. They will need your close attention and maintenance. The people that can execute such operations are expensive. You want to compute that cost before you start your RPA journey. Another hidden cost factor is about accountability and explainability. In a fully automatic process, you might be asked to explain why your system behaved as it did, especially if a stakeholder was negatively impacted. That has a cost as well. Unfortunately, these types of costs do not appear in the RPA solution product brochure.

That brings me to the simple rule that will improve your chances of success with RPA. Know the technology limitations and true purpose before you use it. RPA was designed to bridge the gap between your well-defined orchestration process and legacy systems that expose only a user interface. Use it as a temporary solution and integrate your systems through API as much as possible. Don’t listen to the marketing pitch — base your architecture on facts, especially when it comes to cost.

--

--