At the annual Camunda Community Summit, Markus Stahl from Arvato Systems lead a workshop about RPA. Participants exchanged experience and suspicion about Robotic Process Automation (RPA) and worked on recommendations for digital transformation. The island of "Arpiei" served as story frame where attendees came together in a group of explorers.
🍓 Sweet fruits: Benefits of RPA
The expedition crew landed on the island and discovered the "sweet fruits", meaning the benefits of RPA. For instance: natural involvement of the end user. Since you need to recreate the manual steps of a user, the user is immediately at the center of the implementation. Attendees also reported that for some cases, RPA projects had a shorter time-to-market span. One participant from a Swiss university reported that RPA helped them ensure proper execution of exams during the pandemic. A traditional software development project would have cost too much time which would have lead to chaotic consequences for the students, he reported.
🎇 Hidden treasures: Anticipated benefits of RPA
The crew went on and discussed anticipated treasures, meaning benefits that have not yet fully been uncovered, yet, or benefits that were unexpected. For instance, since processes are executed step by step, you usually get good overview about the execution from logs, which leads to convenient monitoring of the processes. Also RPA is naturally a good fit, where a task has to switch applications or contexts (Germans fancy the term "Medienbruch" here). Introducing RPA developers in your workforce reduces pressure on lack of software developer resources to some extend. As the recruiting market for "traditional" developers is empty, RPA developers can assist projects, when integrated properly.
🏴☠️ Pirates at the shore: Pitfalls of RPA
The crew reported some dangers along the way. Since RPA automates 3rd party tools, a process is very sensitive to changes, for instance when a button in user interface gets a new ID or when network latency leads to an unexpected loading time of webpages. However, despite having to refactor a piece of the process from time to time, attendees agreed that refactoring was still cheaper than the manual process that had been replaced by automation in first place. Also common agreement was the misuse of KPIs. Companies advertise their amount of hours a bot was working. Or the amount of bots. Those KPIs are meaningless as they cannot be set in context. The amount of working hours does not compare to hours of humans. The automated process is different. Also the amount of bots has no meaning as you could build 1 bot per task or 1 bot per process that contains tasks. Such numbers are ok for get an idea of magnitude, but do not work at all as KPI.
💡 Message in a bottle: Recommendations about RPA
After having discovered the island of Arpiei the crew put messages for future explorers in bottles:
- Consider RPA especially when:
- task does not need to run 24/7
- you need a quick solution for automated user tasks
- RPA is only 1 piece of your automation tool stack
- Bots need to be integrated in your IT infrastructure (logging, monitoring, operating in general)
- Onboard new developers. Don't let them alone with an RPA suite as it is not that easy as you're told
- Do not separate citizen developers from software developers
📰 TL;DR - most significant impulses
API-first ignores costs 💸
I used to argue that RPA is only useful as long as there is no API available. I use to calculate the costs for an RPA implementation and never question the superior benefit of an API. Yes, an API is great for inter-software communication. But when you do not need that, why investing in one? Or when priority for an API is too low, but your RPA developers have capacity to build a solution? I even had a case where an RPA solution run well for 2 years until it was finally replaced with an API. But the API was expensive and more complex, since because of security schemes that are different for APIs than for users. Now, it is faster and more secure - but the RPA task has been more than fast enough and secure enough already. I love APIs, but looking at the plain pro's and con's, I think, you really do not to integrate an API naturally. You need to reason as you do for any other software project.
RPA developers are just developers 👬
I used to distinguish RPA developers from software developers which does not seem right. An RPA developer has to understand requirements, work user centered, needs technical understanding, has to know how to build a process for good monitoring. The only difference is the tooling. A software developer uses a programming languages as his main tool. But also many platforms and user interfaces. And depending on project and context, each software developers use different tools. RPA developers are developers. That's it. Which means RPA teams need to be integrated with software development teams. Personally and tool wise. RPA developers need tools that easily accessible for software developers, too. At best, software developers and RPA developers use same IDEs with different views.
Integrated infrastructure is crucial 🔥
When RPA has its own parallel IT infrastructure, you increase costs significantly. You already have a software development department with well selected tools for monitoring and hosting. Crafting this selection took decades and it changes constantly. Modernization require new tools, thus your IT infrastructure is in constant evolution. If you separate RPA from that infrastructure, you create a second room for evolution and double the costs. Therefore it is critical to integrate RPA in to your existing infrastructure. For instance, use similar cloud hosting approach for RPA as for your APIs. Use the monitoring mechanism you have for your API.
It all boils down to a quote a attendee:
RPA is 1 tool in your automation stack.
❓ What's your take on RPA?
