The challenge in automation scale-up

Typically scalability and efficiency aim to have higher and better output with less resources, but traditional RPA implementations often have strange scale-up models that rely on citizen developers. The target is to scale up the resources used, not the output and value created. The target is to have more and more people, citizen developers, to build robots.

In a traditional RPA model, a company first uses its resources to educate citizen developers to use RPA tools. Then, these individuals try to build their first robots, which takes time away from their actual work. Sometimes they are able to get an automation set up, but it is often for personal use and typically it is not efficiently implemented. The robot is often broken and only built to handle normal situations, making it an unreliable solution for all kinds of special situations.

This model encourages people without the proper training and tools to create bots that ultimately only hinder efficiency and scalability. For example, a company pays for RPA software licenses for 100 employees. Maybe half of them are able to even make a robot and even fewer are able to make a robot that adds scalable value. Several employees likely develop similar robots parallel to their personal needs. Then the company must spend time and resources fixing the bots when something eventually breaks or goes wrong. This model scales up resources, but not the output and hinders efficiency. This model is not sustainable for scaling.

An alternative is available - a model where a few professional developers make robots for many employees. These professional developers are able to implement robust robots for each need and then all employees who have that need can use it. This is the scalable model to implement automation.

Robots and robot modules for scaling

It’s important to consider how the whole development model is linked to business models. With the citizen development model, several people can develop a solution for the same need inside a company, but none of them are professionally implemented in a way that other parties could also use it. In the professional tools model, companies can better utilize each implemented robot internally and utilize robots that other parties have already developed. 

These are not very new ideas. Most software development has included this methodology for decades. There are modules, libraries and GitHub repositories to build software. There are SaaS models to offer software for specific needs. This all is relevant for automation and RPA cases too, but the market has been focused on proprietary tools to implement robots. Unfortunately, these tools don’t typically support these very basic principles of software building, maintenance and business.

No one encourages employees to code their own word processing or spreadsheet tools, but in automation we see this type of thinking. During the early days of PCs in the 1980’s, many people tried to make their own word processing tools, but when the market started to become more professional and effective, it didn’t make any sense. Maybe with automation we are still in that early phase.

Use the best components available

When an individual employee has a routine task she or he wants to automate, typically they are not the only one in the company, or in the world, to have that need. It would be much more effective to get a ready solution than to encourage this individual to make their own robot. In many cases the prebuilt robot might need some tailoring, but one properly done robot should include options to solve typical tailoring needs. That is not rocket science, and it is the case with most software products and services.

Another typical use case is larger processes that consist of many tasks and are linked to many systems. Those implementations must read and enter data to several other IT systems and process data between them. In these cases, the whole implementation can be based on many existing modules. Some of these needs are so typical, like SAP, NetSuite and Salesforce interfaces, that the proprietary robotic solutions can offer tools for them. But often there are much more needs for less typical systems. It doesn’t make any sense for big RPA vendors to make components for all of these needs. The only solution is an open ecosystem where different parties, open source developers or commercial providers can offer those implementations.

When automation starts to include more intelligence and AI, scalability becomes even more relevant. There is a need to combine the best modules of the automation, AI and other relevant software solutions. It is not possible for one tool or a proprietary system to offer all of the needed and best components. This leads to a situation where individual developers spend time implementing something that is not in their core competence area and that others have already implemented well in other systems.

Robocorp’s approach

Robocorp’s solutions are based on open source and commonly used programming tools. The principle is that it is easy to use existing software modules and robots in implementations. The whole ecosystem is based on openness and offers tools to make robust, scalable implementations. The business model is based on the real use of robots. So, there is no incentive to try to sell development tool licenses to all possible employees.

The software industry has learned many best practices over decades. Software is built on modules, and developers try to find the best possible modules for their software. There is a large community of developers that make modules and publish them as open source or commercially. Why should RPA and automation be something different? It is not going to be different. The same principles will prevail in automation implementations too. That’s why we want to offer tools and models to build automation with those principles.

Jouko Ahvenainen is Co-Founder and COO of Robocorp, a serial entrepreneur, and a tech and business pioneer.