We have seen an evolution and widespread adoption of RPA (Robotic Process Automation) technologies as accelerators of the Digital Transformation that is underway. This technology for automating repetitive and manual tasks has enabled unprecedented increases in efficiency and productivity by creating a hybrid workforce with people and virtual collaborators (robots) working side-by-side in the end-to-end automation of highly complex business processes.

Some of the benefits of RPA are related to freeing people for more value-added and strategic tasks, more flexibility in responding to volume spikes, eliminating human error and improving customer and employee experience. Not least important, RPA has driven reskilling programs in Developer, Business Analyst or Bot Controller roles with remarkable success rates.

The RPA market has been growing rapidly and is expected to reach $20.1 billion by 2030. This rapid growth coupled with some lack of awareness of the technology needs and little follow-through from vendors has created several challenges in managing and scaling automation programs. Companies typically select a vendor and a partner and perform a successful proof of concept, however the real challenges come later. Difficulties in integrating RPA with other technologies, lack of support and documentation, poorly robust and scalable developments, difficulties in defining and monitoring reliable KPIs, infrastructure problems and lack of self-recovery and advanced orchestration capabilities may explain why the vast majority of organizations have less than ten robots in production and only 40% of RPA licenses are actually used.

To address some of the challenges I listed above, one of the unanimous recommendations in the market is to create a center of excellence (CoE). Although RPA is Business Driven and not IT Driven, this team must have a high technological expertise that allows it to integrate different technologies and define and monitor best practices. In addition, this team provides high quality automation services aligned with the strategic objectives of the organization and ensures the necessary communication, resources, and security standards.

Typically, an RPA process has four phases after the opportunity has been identified and prioritized (ideally automatically): Design, Development, Go-Live, and Monitoring/Maintenance. RPA projects do not end when the solution goes into production. In fact, it is from this phase on that the real challenge begins, and often the monitoring and maintenance effort is directly related to the quality of the Design and Development. Moreover, there is a whole component of continuous improvement in terms of orchestration, Change Management, and Reporting that is essential for the sustained growth of an RPA program and future transition to Intelligent Automation, becoming technology agnostic and process oriented.

Here are some best practices and lessons learned in the last seven years working in Process Automation with RPA and other technologies:

1. Design:

a. About 80% of an efficient and scalable RPA solution starts with mapping the ASIS model (manual process without automation) and TOBE model. One of the great difficulties for organizations using RPA is functional analysis, in which opportunities for process improvement and simplification are typically missed prior to automation. When at this stage the ASIS process is not challenged, the automation teams don't discover the root cause of their problems, ending up solving symptoms instead of the real problems, and as a consequence a poorly designed process is automated, with many problems that will not be solved with its automation.

b. A very common mistake in automation teams is when the ASIS and TOBE model is linear and almost the same, or in some cases there is not even a TOBE model in the PDD(Process Definition Document). Often the process flow has no variations or exceptions and just has the "Happy path". Only about 30-40% of the transactions in a process follow the "Happy Path", so this usually indicates that the functional analysis is incomplete and as a consequence a solution will be developed that will not be prepared to handle the variations and exceptions that exist in every business process, which of course will impact the success rate.

c. The TOBE model should mirror the solution and is rarely a replica of the ASIS model, since it should incorporate changes and improvements to the process that will increase its success rate and reduce execution times, such as integration with BPM, APIs, BDs, etc. It is important to keep in mind that in the vast majority of cases automations will not be 100% successful (nor is the effort justified) and that it is necessary to clearly ensure who will be responsible for exception handling.

d. The functional document (PDD) should clearly describe the contingency plan in the face of disaster situations (e.g., application servers down) or unavailability of any of the applications used by the RPA.

2. Development:

a. Work Queues that allow the process to run on more than one machine simultaneously should always be used.

b. Distinction between Dispatcher (process that feeds a work queue) and Executor/Worker (process that executes transactions from a work queue). This distinction can be ensured through arguments in the RPA process, and it is not necessary to create two separate processes.

c. Situations that justify an abrupt termination of an RPA process are rare, even when encountering unanticipated situations. Robust logging and exception management mechanisms should be included to handle variations and exceptions to the process, restoring the initial state of the applications if necessary.

d. Exception types should be distinguished between System Exception (RPA and application errors) and Business Exception (business rules, out-of-scope situations, etc.). Typically an RPA process should not have more than 10% system exceptions.

e. All developments should be based on a single, standard template, thus ensuring that all developers follow the defined best practices and program in the same way, facilitating maintenance.

f. Development should be modular with a view to reusing blocks in other processes using the same applications, speeding up development time and reducing maintenance effort.

g. Whenever possible, development should favor the use of APIs or DBs over front-end application actions that are naturally more prone to changes and errors.

3. Go-Live

a. Upon completion of development, thorough testing should be conducted with the business team, not only with success cases, but also by forcing errors throughout the process to ensure that the automation behaves as expected.

b. The entry into production of the process must be approved by the business and a QA that ensures the solution is reviewed and published into production, and the RPA process will then run automatically at the agreed schedule and frequency and responsibility of the maintenance team.

4. Monitoring/Maintenance

a. Segregate development from maintenance. Typically in the maintenance team are the more experienced developers with greater knowledge of the procedures in place.

b. The maintenance team must ensure all the component of continuous improvement of RPA operations, namely the monitoring of process executions, the reduction of execution times, the correction of exceptions with higher volume and the incorporation of evolutions that increase the scope of automatisms and their success rates.

c. Reporting should be based on the actual volume of cases handled by the automations and preferably through a BI dashboard based on structured data that is generated by the RPA processes.

d. Advanced orchestration mechanisms should be implemented to maximize machine occupancy rate and compliance with defined schedules, such as dynamic scheduling based on pending case volume, SLAs, and free machines.

e. RPA processes must have automatic mechanisms for reprocessing System Exceptions and automatically stopping them if any of their applications are unavailable.

f. Alarms must be configured that allow support to be proactive and avoid downtime.

There is no magic formula for the adoption of RPA in an organization, because even companies in the same industry have their specificities and it is always necessary to adapt the technology to the organization's needs and not the other way around. RPA when used alone has many limitations, so it has been complemented with BPM, IDP, NLP, Process Mining, Chatbot and Machine Learning technologies, becoming a much more powerful technology in simplifying, improving and automating business processes.

Today, organizations operate in a highly challenging and unpredictable business landscape, with phenomena such as Great Resignation, Quiet Quitting and the lack of qualified talent in process automation. In 2023, organizations are expected to prioritize strategies for improving employee experience and automating increasingly complex and customer-impacting processes using RPA and other complementary technologies. "Inefficient processes and systems are causing employee frustration and burnout," Qualtrics wrote recently. The focus of automation will shift from just hours saved/avoided to improving the overall employee experience with the goal of providing better conditions for your people and improving talent retention rates.


Note: The opinions expressed above are mine alone and do not represent my employer.

This article is part of Nova SBE Digital Experience Lab's annual cycle of reflection on technology, business, and sustainability. To receive more news about the events and articles that the Digital Experience Lab is organizing, subscribe to our monthly newsletter.

Do you know our program:
Cyber Conflict Prevention and Resolution?
Published in 
 in the area of 
Digital & Technology

More articles from

Digital & Technology


Join Our Newsletter and Get the Latest
Posts to Your Inbox

No spam ever. Read our Privacy Policy
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.