How automation costs changed as usage grew
The commercial RPA platform helped the client get started without first building its own technical foundation. As processes, users and licences were added, operating costs and dependence on the original platform grew as well.
The client chose an open-source solution that it could control more directly and develop with its own team. We selected Robot Framework as the new foundation. It is also used for robotic process automation (RPA).
An open-source solution still requires infrastructure, maintenance, updates and expert support. Future development no longer had to remain tied to the original licensing model. Our comparison of open-source and commercial RPA solutions examines the same decision criteria in more detail.
The automations had to be rebuilt
The existing automations could not simply be exported and moved to the new tool. We therefore rebuilt the solution almost from scratch. During the design, we removed ties to the previous platform and set shared rules before the number of robots began to grow again.
We designed the Robot Framework architecture, project structure and principles for subsequent processes. Process definitions stayed readable in Robot Framework. Python covered the helper libraries and custom technical logic that the available keywords could not handle on their own.
From the start, we separated process logic, technical communication with applications, input data, configuration and reusable components. Authors did not have to decide where each part belonged or how it should work every time they started a new robot.
The first robots showed the team how to continue
In the initial phase, we built the first working robotic processes and used them as reference implementations. The internal team could see both Robot Framework syntax and how to design another process within the shared architecture.
One design repeatedly ran the same automation logic with different input data. Instead of creating a separate robot for each item, every run processed the next prepared input while the procedure stayed the same.
Separating data from logic made the solution easier to reuse. Changing an input did not require a change to the robot procedure. When the process changed, one implementation could be updated instead of several nearly identical copies.
Best practices were built into the project
Choosing an open-source tool does not make the code maintainable by itself. Without shared rules, Robot Framework can still turn into a collection of scripts understood only by their original author. We therefore defined development standards alongside the architecture:
- a layered structure based on the Page Object Model, separating technical interaction with applications from process and business logic
- shared resource files, keywords and components so that the same functionality was not implemented again in every robot
- a consistent structure for tasks, configuration, input data, variables and helper libraries
- central management of environments and configuration instead of values embedded directly in automations
- consistent handling of expected errors, process termination and diagnostic information
- standardised logging that made it possible to trace a run and identify the cause of a failure
- naming rules, appropriately sized keywords and clear responsibilities between layers
- extension rules that directed new robots to reuse existing components before creating another implementation of the same task
Handover prepared the team for independent development
Knowing Robot Framework syntax was not enough to take ownership of the solution. The internal team also needed to understand the architecture, project organisation, shared components, development standards, naming rules, configuration, data, logging and error handling.
Handover included training, documentation and practical examples based on the first robots. We also provided technical guidance as the team created more automations, allowing the new approach to be learned on a working solution.
We transferred the knowledge needed to avoid replacing dependence on the platform vendor with dependence on an external supplier. The internal team could then develop and support subsequent robots independently.
What changed for the client
- A solution built on open-source Robot Framework replaced the commercial RPA platform.
- The client gained a shared architecture, project structure and rules for future automation development.
- The internal team also used the first production-ready robots as reference implementations for new work.
- Configuration, data, logging and error handling followed one consistent approach.
- Reusable components reduced the need to implement the same steps in multiple robots.
- The internal team received documentation, practical training and experience extending the solution.
- After handover, the internal team could continue developing and supporting robotic processes with its own people.
- The client had greater control of the solution, and future development was no longer tied to the original licensing model.