A professor from the Faculty of Computer Engineering once mentioned: “What is the main difference between a Computer Engineer and a Civil Engineer? All projects involving a Civil Engineer will result in a physical realization, with all project hours translating into something visible and tangible. In contrast, the hours invested by you (Computer Engineers) will largely produce intangible assets, making the perception of effort and its valuation relative.” In other words, this means that maintaining a building, bridge, or dam will periodically require maintenance. Similarly, computer systems and software, regardless of their nature, will also require maintenance.
Assuming that digitization and computerization of businesses are a one-time cost is incorrect, but it is difficult for the human perspective to accept this truth because it is not something visible. Let’s think about the number of programmers needed just to ensure the smooth operation of, for example, banking systems, payment terminals, and ATMs. Now, let’s add the constantly changing rules and regulations, and the impact these factors have on system maintenance. To further complicate matters, new business needs emerge, in the form of developments on top of architectures, often complex, trying not to regress the more mature parts of the system. As the icing on the cake, let’s consider constant technological advancements, which often require some form of software adaptation to avoid becoming outdated. The art and science of Software Engineering are complex because businesses and processes are also complex, especially during a period of talent and resource scarcity, with a growing demand for qualified professionals who take a significant amount of time to mature.
Considering a real-life situation in a podcast with Farfetch’s CTO, he was once asked if 500 computer engineers were really necessary to create an online store. Today, Farfetch has more than 5000 registered employees on LinkedIn, with a large percentage of them being computer engineers.
In the case of RPA – Robotic Process Automation, they have emerged recently as an alternative to “traditional” software programming for certain scenarios, allowing tailored automations in business processes instead of resorting to custom system development, which is more complex to implement. However, RPA is a technology and practice that falls under the domain of programming, which means it involves maintenance stages, as mentioned earlier. Process automations, especially RPAs, depend on two additional factors that affect their stability – they often interact with constantly evolving third-party platforms, and they depend on business processes, which are shaped by the organization’s maturity, influenced by employee turnover, changes in the business, or its growth.
Drawing a parallel with industrial robots, visible entities in business units, it is common sense that these robots will periodically need maintenance or, sometimes, stop due to errors or breakdowns. However, despite the investments in solutions or maintenance, the adoption of robots, both in physical and digital environments, continues to rise, freeing humans from robotic processes and driving technology and society forward. Currently, the benefits of digitalization and automation are evident for society, providing more personal and professional conditions, options, knowledge, and information, primarily because technology enables us to do so. For example, a vaccine for the COVID pandemic was created in such a short time with a high success rate, mainly because technology allowed it, not only in the pharmaceutical industry but also due to the hardware, models, and software that enable simulation of countless healing scenarios.
Regarding the case of RPA – Robotic Process Automation, there are indeed negative experiences with this technology, especially concerning the maintenance of robots in production. However, its adoption continues to grow, along with successful cases. Based on our experience, we will attempt to list some scenarios that can contribute to excessive maintenance costs:
Mismanagement of expectations
Selling RPA or automation as the savior of all organizational problems is a wrong approach. It requires a proper awareness of the technology, its potential, applicability, and limitations. Defining and setting an automation strategy based on clear and measurable objectives for the client is crucial.
Misidentification and prioritization of processes
This seems to be one of the most valid reasons. There are robots that stop frequently because the platforms they interact with are constantly changing and have unpredictable errors. Scenarios may arise in processes that were not identified during the initial analysis, and the automations may not be prepared to handle those cases.
Wrong choice of technology
We often debate this topic when recommending the adoption of a platform to a client. RPA is not a “one size fits all” solution. The correct choice may be Power Automate, UiPath, Robocorp… depending on various factors, such as strategy, use cases, maturity, and technological ecosystem. Many variables need to be considered, and the chosen technology will influence the automations that will be implemented, requiring the proper design and maintenance tailored to that reality.
Project and maintenance team
Automations, as pieces of software, must be well thought out, planned, and designed with appropriate solutions and architectures, going through a process of conception and quality validation following best practices. We cannot expect that a single junior developer will deliver quality RPAs because that won’t be possible. This problem only becomes apparent when the robots are in production and start stopping too often. An experienced and knowledgeable team, suited to the size and complexity of the projects and maintenance operations, is essential. Another important point is dealing with regressions caused by a lack of knowledge, resulting from an incorrect handover from the project team or a lack of maturity in the support team to apply the appropriate fixes.
Inadequate licensing
Different RPA vendors have different types of licenses and advantages, with two main types, bot-based licenses or pay-per-use. The bot-based license should be based on a strategy of developing multiple processes to minimize the fixed cost of the license, while pay-per-use licenses require scrutiny to optimize the robots’ work time. Evaluating the type of licensing and the technology together with the client is of utmost importance for the predictability of automation programs. Of course, platforms with more substantial licenses will have advantages in terms of development time, stability, and integrations compared to others with limited or no licensing.
Having said that, the correct implementation of automation and RPAs is a clear advantage for organizations, leading to multiple success stories with various technologies, regardless of their size or industry. This technology has proven to be advantageous for companies that adopt it, making them more efficient and resilient in their businesses. Optimizing and caring for employees, who are essential to companies, should be one of the driving forces guiding organizations’ strategies. The technology exists and is mature, and the emergence of AI increases automation’s capacity as never seen before. Therefore, it is necessary to teach companies how to take advantage of this tool and adopt new ways of working. This is precisely the purpose of Engibots: democratizing access to this capacity and technology for any organization whose quantity and morphology of processes allow it.
In conclusion, RPA maintenance exists and must be considered; however, with a proper automation program, it can be minimized and, in some cases, performed predictively. When there is a business scenario that justifies the application of automation, RPAs are a benefit, with direct advantages, but also impacting an organization’s way of working, translating into greater quality and competitiveness.
