The last few years have seen a huge growth in software robots (RPA), used to automate monotonous and repetitive jobs, thus freeing people from these types of tasks. As with all previous waves of IT (ERP, CRM or even Cloud), RPA is going through quite a hype phase, where it sometimes appears as the panacea for all organizations’ problems. This silver bullet image, despite favoring companies like ARPA (after all, we are a company whose core is the implementation of RPA services) does not correspond, in our opinion, to the reality of the hundreds of processes we have already implemented and put into production in our clients.
Whenever a new technology emerges, there is a temptation to portray it as very different from previous ones, when in practice we are only talking about a different terminology. That temptation also exists in RPA, but there is one real difference to other waves of the past: change is often led by businesspeople and not by IT departments. This is due to the combination of two characteristics of typical RPA tools:
- They allow interaction with legacy systems through the UI, without the need to use APIs, nor direct access to data and, therefore, without the need to include the teams that develop and maintain the applications. Moreover, and almost by definition, the use of UI as an integration method almost always makes available all the capabilities of the application, there is usually documentation (if only a User Manual), and current users are a good source of knowledge.
- The programming of the robots is based on Drag&Drop and Point&Click (or low code) interfaces that make it easy for non-programmers to develop. It is easy to reuse a non-specialist and have them do some automation experiments, right after a few training sessions on the tool. In addition, the development and business knowledge lie in the same people, speeding up the production of the first automation examples. It is common to hear that RPA enables the citizen-developer, i.e., any employee of the company can become a programmer.
Unfortunately, if this approach is good for proofs of concept, the truth is that it does not scale well. Process automation through RPA, which is a key contribution to the much-desired Digital Transformation, is still software development, potentially on a large scale, with all the complexity and risks we know. An RPA-developer, with little software experience, will find it difficult to create reusable robots, without errors, that survive deviations from the happy path and that are easy to maintain.
The use of the UI as an entry point to legacy systems, with all the advantages it has, is very dependent on small changes that can make a series of robots already in production fail catastrophically, just because someone decided to change the name of a field on the screen or change the logo on a list. Defensive programming, change management and controlled versioning are fundamental in the healthy evolution of RPA projects, perhaps even more than in other IT specialties. These concepts and tools are usually unknown to people who have never developed software.
Finally, when we talk about end-to-end processes, the need to reuse sub-processes is very natural, and they must be designed to be used that way. This involves notions and experience of abstraction and encapsulation, trivial for someone with a programming background, but probably not so familiar to someone without one.
For all these reasons, and despite being a technology where it is easy and quick to produce initial results, the large-scale introduction of RPA can be doomed to failure in the medium term if not properly planned, executed, monitored, and managed, using the right methodologies and tools for each phase of the process and involving people with IT training and experience. This is what happened to several of our clients: after an internal bootstrap effort, they asked us to help them move forward. A bit like someone who starts renovating a house and halfway through discovers they’re going to need professional help, when they realize that painting is easy, but fixing the stain on the wall means breaking the wall and changing the plumbing.
This does not mean that an RPA project has to be something very big, or that we have to trace the whole path and have a large team, before starting. On the contrary, a well-thought-out RPA project, especially by its natural division in Processes, fits very well with Agile methods. With the right framework, it is simple to decide what we can do with internal resources and what we need external help with, as well as to scale the project incrementally and supported by successes along the way. The low-code technology is powerful enough to be used by professionals, with the guarantee that its endogenization is simpler than more conventional technologies.
Another “myth” we come across at many clients is that RPA will replace people. The organizations that have advanced the furthest along this path have already realized that it is essential to combine robots with people, especially when we start addressing large and complex processes. Knowing how to break work into sub-processes, and coordinate them, is a fundamental skill for the success of a long-term, organization-wide initiative.
Part of these sub-processes will still have to be executed by people. In cooperation with robots, of course, combining the best of humans (use of unstructured information, a decision with incomplete data, etc.) with the capabilities of robots (simple and repetitive tasks without errors, higher speed, etc.). In fact, a successful APR project always has the right balance between People, Tools (technology), and Methodology, which depends on each Organization.
Automating should be seen as a way to increase human capabilities and the Digital Transformation process must be centered on People, in all phases of its life cycle, combining human capabilities with Tools that support a robust Methodology.
Discovery – Process and Task Mining tools must be combined with people’s sensibility and business know-how. Although AI is a very important tool, advances such as the extraction of tasks from recordings, still need a lot of human intervention. Otherwise, we will get robots that are not very optimized and very limited in managing exceptions.
Analysis – The criteria for valuing automation should be clearly defined and the scoring process should be managed in an automated way. The criteria should not only take into account FTE savings but also quality, service levels, accountability, and the ability to do things that were not done.
Design – The opportunity should be taken to rethink the processes, orienting them to the new “digital” capabilities, taking advantage of human capacities of reasoning and decision with little information, and perhaps combining other technologies beyond RPA.
Implementation – It is crucial to use a clear development methodology. We should not reinvent the wheel; RPA is software development. Using low-code interfaces can create a false sense of “ease” for the simplest processes, but it does not scale as well for more complex processes. With a well-defined methodology, it is easy to do the work completely in-door, outsource development, or work in a hybrid way.
Production – The right infrastructure must be dimensioned so that deploying processes to production is simple, and they can work robustly. Given that the the extensive use of the UI as an access route to legacy applications is usual in RPA, and also normal and frequent that changes happen in it, it’s very important to foresee the possibility of versioning the automation scripts of the processes, to ensure more consistent and faster deliveries.
Operation – Conditions must be created for better interaction with the human, while coordinating the hybrid workforce, which involves robots, artificial intelligence, and people. Digital workers often become critical points of failure. It is important to create safeguards and mitigate risks by creating redundancy or even alternative circuits that go through people. It is important to ensure security, a task complicated by increased complexity. From automation to autonomy.
Measure, Feedback, and Scale – It is very important to create intelligent cockpits with indicators and operation control and ensure their evolution, creating new metrics as the goals evolve. Only with reliable indicators can we manage, improve the work cycle in all its phases and ensure the quality of the people-centric digital transformation.
In all these phases, the balance between Methodology, Tools, and People is important and each organization is potentially a different case. All the more reason to seek support from experienced partners who can help you find the sweet spot.
This careful fusion will imply the reformulation of some concepts. In the past, we saw an approach to process “automation” that relied on BPM and Workflow tools, where people were at the center of the decision, and software was responsible for automatically routing data. RPA came from the opposite end of the map, with the original promise of replacing people entirely, by automating their tasks.
In practice, it will be the balanced combination of the two approaches that will lead to the path to success. In this path, the end-to-end macro-processes are analyzed, broken down into sub-processes, and some of these are chosen to be automated, probably with RPA. However, not all of these sub-processes can, or should, be automated and will still be done by humans, who will have to be involved in the “loop” of the robots and cooperate with them.
Our vision is that there will be a new generation of Workflow systems, focused on large processes, that combine and coordinate all types of workers, both robots and people. These systems are known as “Orchestrators”, which are fundamental in a global Automation process, and help to implement human-in-the-loop.
Just as many companies decide to move to RPA using only in-house resources, many do not consider using an orchestrator in the first place. However, the truth is that almost all organizations are faced with the need to use an Orchestrator once they have more than a dozen automated processes in production.
Besides enabling a hybrid workflow between people and robots, a good Orchestrator is a vital ally of people, when it comes to support the Operation, especially when we have many processes, in multi-technology systems, highly parallel and with a complex infrastructure. This is the normal landscape in a large company that decides to do a general roll-out of an RPA pilot that went well.
They also enable the automatic collection of statistics and their exploration in dashboards, helping to optimize the system and measure ROI. Information like this helps to manage the scaling of a solution in safe steps, reusing previous experience to choose the right paths.
Automation is important, but it is of little use if not managed well by people, ensuring absolute control of the digital workers, interacting with them whenever necessary, correcting problems, making and validating decisions, all in a simple and fully integrated way.
We mentioned the issue of multi-technology above, and it is very relevant in the context of orchestration. Sometimes we come across the false idea that RPA has to be mono-technology. The world is diverse and so we must also ensure that automation can be achieved through various tools and that orchestration can handle this diversity. Choosing a mono-technology orchestration product is very limiting to truly manage the ability to transform the organization with all the tools available to do so.
We also hear a lot from our clients about Artificial Intelligence (AI) and the questions they have about how this integrates with their internal Automation program. As with RPA, there is an expectation that AI can enable the automation of more tasks.
This expectation is legitimate and fueled by news of AI’s very advanced achievements. However, while the advancement of AI is huge and inexorable, especially in the area of Deep Learning, the truth is that the “packaging” of these advances and their incorporation into everyday workflows is anything but trivial. The solutions that reach the market tend to be of three types:
- modules provided by RPA vendors, which are not AI specialists. They are usually not very advanced compared to the best that is currently being done. The rapid evolution of R&D leads to many significant disruptions and that makes non-specialized solutions obsolete overnight;
- packages integrated into the widest range of the large software vendors’ offer, usually still very general and difficult to parameterize for a specific problem;
- verticalized end-to-end systems, often incorporating powerful AI solutions, but which imply replacing the entire workflow.
The alternative is the use of more modular and recent solutions, but they are often only supported in the form of open-source libraries, requiring the creation of some “glue” with existing systems and internal or third-party support capabilities. At least, this option allows the use of state-of-the-art AI at specific points, without major disruption to the current workflow, nor expensive bets on large integrated packages, of which we will only use one or two capabilities.
The thoughtful integration of AI into RPA systems is something that will ever more present and will allow more and more tasks to be automated. But again, we believe that people will continue to be indispensable, for a long time to come.
Despite the great advances of Deep Learning in areas such as image recognition, or natural language interpretation, the truth is that these advances focus on how machines can handle input data in loosely structured formats and internalize it into a powerful model (“understand” it).
The ability to make complex decisions about data, on the other hand, has not advanced that far. When, on top of that, many of those decisions need to be chained (i.e. where the next decisions depend on the impact of the previous ones on the outside world), AI is clearly in its early days, but humans do it without difficulty. We believe that advances in Reinforcement Learning will improve this picture, but much of what is being done today is still at the laboratory level and far from enterprise availability.
Although we know that models can be trained to decide within the scope of a certain application, there are still difficult questions to resolve, such as the following:
- problems where the decision is very complex and where it is simpler to have access to an expert than to learn by examples;
- application areas where liability is critical and a human has to assume responsibility;
- the need for explainability, i.e. why the machine took a certain decision and not another;
- decision bias due to less correct choice of training data;
- missing information, which can only be filled in by autonomous research (e.g. telephone call);
Just as RPA is not a universal panacea, neither is AI. The combination of both technologies is certainly powerful, but it will not avoid anytime soon (if ever) the involvement of people in processes and the need to think of Automation as the cooperation between robots and people.
Speaking of people, if we think they are fundamental for a pragmatic solution, we are sure that they are indispensable in programming and we think that there is an excellent opportunity in RPA for the qualification and requalification of people. We should not forget that RPA is a technology designed to be learned by people without much training in programming.
We believe that many valuable people could enter the labor market without difficulty if they received adequate RPA training. Such training need not be very extensive, especially in the context of well-thought-out projects with the right skills. It would be up to the Job Centres, for example, to suggest RPA development courses to people who are not employed, but who show affinity and interest in process automation, even if only in the (critical!) analysis phase.
Universities could and should also do recognize this, focusing part of their curricula on the skills that are important for good process analysis. We believe that there are several courses, even non-technical, where there is a lot of relevant material for this activity, such as Sociology, Management, and others. After all, organizations that want to automate their processes are made up of people, and it is by talking to them that we can understand which ones are simple to automate and which ones will continue to be done by humans. If a small part of that decision is technological, a large part is not. You don’t need to have an engineering degree, for example, to do good process analysis.
We could extend this short contribution to clarify some of the myths that surround RPA and its implementation, since the list does not end here. Like all emerging technologies, RPA is going through its hype cycle and is expected to go through the Valley of Disillusionment before reaching the Plateau of Productivity. ARPA was one of the first Portuguese companies to invest in this technology and is here to stay, helping our clients navigate this landscape, that changes every day. For this, we have a young team, but one with a lot of experience, resilience, and the will to provide the best service we know, even when things get complicated.
At the end of the day, and as we hope we have been clear in this article, we are working towards automation, but we believe that it is people that is what matters.
