Lessons from RPA implementations after the hype
In a complex landscape of business applications, the flow of data between systems is crucial for today's enterprise. Sometimes, particularly with older systems, the interfaces necessary to facilitate data exchange do not exist. Traditional integration projects can take months or years to implement, and come with a price tag to suit. The workaround that emerged to address this problem some time ago became to be called Robotic Process Automation.
Looking back at the last 5 years, the rate of adoption for RPA in large enterprises has been quite staggering. In a typical organization, a team could easily automate dozens of paper processes in their first year. For some, the rapid scaling up came at the expense of quality.
The first projects were usually spent learning how to actually use the relatively novel tools effectively. In addition, (if the business analysts had done a good job in ROI estimation) those same initial use cases were typically the ones with the highest transaction volumes. If the performance of the initial version was bad enough, the projects have sometimes needed to be redone entirely.
As the total number of automations running in production increases, having formal incident management procedures in placeis important. But it is even better, if your team can produce solutions that don’t break in the first place. In this article I will discuss how teams can increase the maintainability and extensibility of their code.
At the end of the day, RPA is about code
Having the right tools for the job is a defining factor in enterprise RPA, regardless of whether they are used by in-house resources, an outsourcing partner, or a joint team. Even more important than the choice of technology, is using it effectively. Like with any software project, modularity and separation of concern are key in creating high-quality, maintainable automations.
The first principle to follow in any kind of programming is that of not repeating yourself. In the context of RPA, this means implementing each discrete, repetitive action as its own function. Opening an application or inputting a data record to a system are examples of tasks that warrant their own function. If functionality is not applied, similar sets of actions become duplicated in different parts of the solution. As a consequence, when there is a need to change the behaviour of a particular component, the change has to be implemented in all of the places where it has been defined (if you can find them first). A well-designed modular structure also allows individual procedures to be tested in isolation, providing an immediate feedback when iterating.
Take a step back before rushing into implementation
In a typical RPA project, the responsibilities of defining a process and the actual coding are fully segregated, to a “business analyst” and an RPA developer, respectively. The analyst might have a cursory understanding of the RPA tool being used, but typically is not experienced in programming. The analyst performs a process walkthrough with the subject matter expert and documents the work steps as shown. The developer then takes the document and starts to reproduce the process verbatim in code.
This workflow often results in solutions where business logic (i.e. the objectives of the process) has been closely intertwined with the user actions (how the work is done). Not separating business logic from application logic has implications on maintenance, such as when fixing a bug or modifying the behaviour. If the process consists of one long block of code mixing business rules and low-level tasks, it can be very hard for the maintainer to find the offending piece of code.
Separating business and system-related activities also enables extensibility. For example, applying a new validation rule is much easier when the rules have been defined in a dedicated module, away from system interactions.
Even allowing for separation of concerns, implementing a process exactly as it has been performed by a human rarely leads to the best possible automation. An RPA project should always be treated as an opportunity to take a step back and reassess the process itself and how it relates to other, similar processes.
Good practices will pay dividends
The quality of the code deployed to production has major implications on robot performance and the amount of unplanned maintenance work required to keep business processes running. The bigger the share of developers' time consumed by putting out fires in production, the less capacity a team has for implementing new use cases and for improving their daily practices, as promoted by the DevOps movement.
Besides maintenance implications, the performance of individual robots is also adversely affected by bad programming habits. When a robot is implemented suboptimally, it takes longer to complete one transaction, with differences typically measured in seconds. This starts to have an impact on costs when tasks are repeated hundreds of times a day. In order to support production operations, the need for a new robot runtime (and license, if using proprietary tools) arises sooner than would otherwise be necessary.
About the writer:
Otto Ahonen
Consultant who thinks in code. A recent convert to the open source RPA movement.
SKALER - Asiantuntijat ja yhteyshenkilöt
SKALER - Muita referenssejä
SKALER - Muita bloggauksia
It- ja ohjelmistoalan työpaikat
- Laura - Tietoturva-asiantuntija
- Nordea - Senior Full Stack Developer with IAM knowledge
- Tecinspire Oy - Dev Team Lead - Kehityksen tiimipäällikkö
- Laura - IT Manager
- Laura - Network Specialist
- Laura - Tiedonhallinnan erityisasiantuntija
- Laura - Junior Cyber Security Specialist
Premium-asiakkaiden viimeisimmät referenssit
- Ampersand Design Oy - Asiantuntijuuden vahvistaminen referenssitarinoilla
- Verkkovaraani Oy - Lentorata.fi-sivuston saavutettavuusauditointi
- Innofactor Oyj - Apotek 1 tarjoaa innovatiivisia palveluja Azure Kubernetes -ratkaisun avulla
- Innofactor Oyj - Business Centralin lisäarvoratkaisut tehostavat Domicetin liiketoimintaa
- Efima Oyj - Case Martela: Luottamus ERP-kumppaniin rakentui tehtaan lattialla
- Valve - Korsisaari uudistunut verkkopalvelu
- Valve - Musiikkituottajat – IFPI Finland ry verkkopalvelun uudistus
Tapahtumat & webinaarit
- 21.05.2024 - The path to productization
- 21.05.2024 - Ilmainen ERP-webinaari: NAV:stä Business Centraliin | Business Centralin mahdollisuudet versionvaihdon jälkeen
- 23.05.2024 - Ilmainen BI ja ERP-webinaari: Paradigman muutos
- 28.05.2024 - SprintIT webinaari ti 28.5. klo 10: Odoo Raportointi - Sitä saat mitä mittaat!
- 29.05.2024 - Efistream-webinaari: Näin rakennat modernin taloushallinnon, joka tukee tiedolla johtamista
- 29.05.2024 - Ilmainen ERP-webinaari: Forbesin maailman parhaaksi valitseman liiketoimintaohjelmiston, Business Centralin, esittely ja demo
- 30.05.2024 - Palvelumuotoilu osana DevOpsia
Premium-asiakkaiden viimeisimmät bloggaukset
- Ready Solutions Oy - Tietomallit osana informaatioarkkitehtuuria
- Timeless Technology - Milesight UR32L Lite Series teollisuusreititin hintaan 115,00€!
- Innofactor Oyj - Dynasty Asiointipalvelun 3 tärkeintä hyötyä
- Efima Oyj - Microsoft Fabric -sanakirja: esittelyssä Fabricin analytiikkatyökalut
- Staria Oyj - Citycon ulkoistaa pohjoismaiseen talous- ja vuokrahallintoon liittyvät toiminnot Starialle
- Timeless Technology - Perlen 4G ja 5G reitittimet: Virtaviivaista verkonhallintaasi Docker OCI-säilöillä.
- Ready Solutions Oy - Lakehouse – alusta vai tietovarasto moderniin analytiikkakehitykseen?
Digitalisaatio & innovaatiot blogimediaBlogimediamme käsittelee tulevaisuuden liiketoimintaa, digitaalisia innovaatioita ja internet-ajan ilmiöitä |