From RPA to Python Automation
Overview and history
We started with a heavy focus on RPA automation and, over the past 2,5 years, implemented different versions of conversion tooling from Gen1 RPA tools to Python and Robocorp Control Room. While we got pretty good at it and still do have a tool out there, we always ran into the same case:
👉 Migrating bad automation just results in another bad automation.
The hype and tooling around RPA have generated a lot of bots that are just bad in many ways, but what does a "bad bot" mean?
- Automating a process that provides no value
- Brittle bots: if the success rate is less than 80%, then someone is constantly maintaining the bot, eating away the ROI.
- Inefficient bots: When bots are bound to licenses, it forces a single bot to do things that would be much more efficient done in parallel or smaller batches.
- The licensing also causes bots to be built for a given infrastructure instead of building the automation so that infrastructure can be ramped to match the needs.
- A lot of unnecessarily complex code and flows where the tooling has forces conventions that just obfuscate things instead of solving problems.
Building modern, stable and fast automation is relatively easy. If you know the process and the problem, then the choice of tools should be a minor decision.
🚀 With the emergence of AI and a lot of new tooling around Python especially, we'd like you to take another look at the green field of automation.
The Big Picture
👉 The key is knowing the problem and who you are solving it for.
If you know the process and the problem it is solving and know what the end-users expect, you are more than 80% there.
Mindlessly running migration or conversion on existing automation easily misses many things, even if the converted code does exactly what the old bot did.
With AI/LLM developments over the last year, the critical thing to understand is that the value of the actual code lines is getting closer to zero; the value comes from the automation's output, quality and speed.
The citizen-developer aspect of RPA is also eroding from two sides.
Using LLM tools like ReMark or ChatGPT, you can describe your problem statement and ask for the LLM to produce a base Python implementation. It may not be 100% there, but it is much closer than the bot built 2-4 years ago.
On the other hand, automations that actually have a valid ROI are developed and maintained professionally by dedicated developers who just want capable tools and ways of using them. For big automations, the cost savings come from infrastructure and parallel executions that raise the utilization rates of your hardware as close to 100% as possible.
Examples
It's common to have doubts about entering a conversion project. You will need to justify the investment of rethinking existing automation and how to free your developers from maintaining it to rewriting it in a new tool. Is it worth the risk and the investment?
The case study below shows the numbers you can get out when implementing the automation as code. When your devs are free to implement against API, websites, applications, or directly to a database, it is easy to find significant shortcuts like avoiding the usage of UI automation altogether.
There are also many more case studies on our site.
If you are constrained with developer resourcing to migrate, Robocorp's Certified Partners are always willing to help.
Playbook
Instead of endless estimations and evaluations, we recommend the following:
👉 Prepare:
- Select your Top 5 use cases
- Collect/know the process
- Documentations, Current inputs/outputs, Who or what is the end-user?, ...
- Have some developers undergoing Robocorp Certification Courses
👉 Analyze:
- Identify commonalities
- Identify systems/apps involved
- Are there updates / APIs / new data sources?
- Identify end-user needs (have they changed)
- Identify existing implementations
- Robocorp docs & libraries
- Our Portal bots
- ..just shy of 500k packages available in PyPI for Python
- Select one to do
👉 Do:
- Implement the selected automation using new tools and options available.
- Use common libraries from Robocorp and Python eco-systems
- Make your own reusable components
- Use up-to-date practices and leave behind old habits
- "Sleeping on the job is never good."
- "Don't repeat yourself."
- You can run a lot on a simple Linux.
The developer tools are free, and the Control Room free tier will get you quite far. Contact us for extended PoCs.
For the first target, you can pick small or big automation, but after the first one, you can think differently, and if you still want/need to estimate the next ones, you can, with the knowledge that you probably already made some common components you can use.
For the path above, we can help you and know that the whole thing can be done in one calendar month.
Tooling
While we still have our conversion tooling, we have seen that providing it usually only fuels the "estimation paralysis". "What % does the tool convert? How many days of work would you estimate? ...".
We've also achieved some good conversions, but there are still so many domain-level differences that we have seen the tooling confusing the process of getting started.
We can use our tooling and help with the analysis part from the Playbook above, but other than that, we strongly recommend just following the Playbook.