RPA explained: what fits small and mid-sized businesses

RPA stands for robotic process automation and describes software robots that carry out recurring computer tasks by operating programs through the user interface: clicking, typing and copying data from one application into the next. RPA is used above all where several systems have to work together but offer no direct technical connection. For small and mid-sized businesses it is therefore often a fast bridge, but rarely a stable foundation: where systems can be connected directly, a tailored automation is usually more reliable and cheaper in the long run.

What is RPA (robotic process automation)?

RPA stands for robotic process automation. Behind it sits a software robot that operates a program just like a human: it clicks fields, types values and copies data from one application into the next, only automatically and around the clock. So the robot imitates the operation of the user interface, instead of working inside a system.

That is exactly the decisive difference from a real interface. An interface connects two systems on the technical level, so data flows directly and reliably. RPA, by contrast, sits one level above, on the screen, and mimics what a human would otherwise do with a mouse and keyboard. That makes RPA flexible to deploy, even with old programs that have no modern connection, but also dependent on the interface staying exactly as the robot knows it.

A simple picture: RPA is the digital temp worker who doggedly works through a rehearsed click path. It never tires and makes no careless mistakes, but it does not understand what it is doing. If a button moves, it stands there helpless. Anyone who keeps that in mind assesses RPA realistically, instead of treating it as a miracle solution.

Where does RPA make sense, where are the limits?

RPA is useful above all when systems offer no interface and still have to work together. The classic case is legacy software that cannot be connected but has to be fed daily with data from another system.

The biggest limit is its fragility to changes: if a program’s interface changes, for example after an update, the robot often breaks and has to be reworked. What began as a time saving then turns into an ongoing maintenance case. That is why RPA is often a good bridge, but rarely the stable foundation on which to permanently build a critical core process.

A second limit is a matter of content: RPA does not understand what it reads, it only follows fixed rules. As soon as a step needs understanding, such as grasping the content of an email or a receipt, classic RPA ends. This is where AI automation comes in, adding the understanding of unstructured content. The two do not exclude each other, but they solve different problems.

What fits small and mid-sized businesses better?

For many mid-sized workflows the answer is not an RPA tool, but a direct, tailored automation via real interfaces. Where systems offer an interface or can be connected, it is usually the more stable and, in the long run, cheaper choice: data then flows for real between the systems, instead of via imitated clicks, and an update does not immediately bring the whole flow down. How programs are cleanly connected to each other is shown on our page on connecting systems.

The more honest view is on the whole workflow anyway, not on a single tool. Often it pays to simplify the process first and then automate it deliberately, instead of having a robot replay a clunky click sequence one-to-one. We describe this path in the overview on digitising and automating processes and concretely under automating business processes.

Start2x recommends Richard Roth Strategie & Automatisierung

RPA sounds like big automation, but it is often a plaster for missing interfaces. We first look at whether systems can be connected directly, because that is more stable and needs less maintenance. We use RPA deliberately where there is no other way, such as legacy software without a connection, not as the standard answer to every automation.

What does RPA cost in a mid-sized business?

The visible costs of RPA are usually the licence fees for the robot software plus the one-off setup of a flow. Both can be calculated well. The catch lies in the invisible follow-up costs from maintenance: every change to one of the operated programs can break the robot and trigger maintenance. An RPA flow is therefore rarely “built once and done”, but causes ongoing upkeep that is easily overlooked in the first calculation.

For an honest cost calculation you should therefore look not just at the build, but at the operating costs over several years. Often it then turns out that a direct connection costs a little more to implement but runs with far less maintenance and is cheaper overall. Where RPA is only meant to build a short bridge until a system is replaced anyway, it can be the pragmatically right and cheap choice. Whether an automation step pays off at all is covered in the article When is automation worth it?.

How do you find the right path?

The pragmatic path starts not with the tool, but with the workflow.

• Understand the workflow. Which systems are involved, where is data copied by hand today and how often?
• Simplify. Can steps be removed or merged before anything is automated at all?
• Check the interfaces. Can the systems be connected directly? Then that is usually the better path.
• Use RPA deliberately. Only where no clean connection is possible, as a conscious bridge with maintenance factored in.