Robotergesteuerte Prozessautomatisierung (RPA): was sie leistet und wo sie an ihre Grenze kommt

Die kurze Antwort: Robotergesteuerte Prozessautomatisierung (RPA) ist Software, die feste Klickabfolgen auf den Oberflächen bestehender Programme nachbildet — Daten kopieren, Felder ausfüllen, Buttons klicken —, genau so, wie es vorher ein Mensch getan hat. Sie eignet sich gut für stabile Abläufe mit immer gleichem Ablaufmuster und wenigen Ausnahmen, etwa das Übertragen von Daten zwischen zwei Systemen ohne eigene Schnittstelle. Ihre Grenze liegt bei allem, was Inhalte verstehen muss statt sie nur zu kopieren: ein Freitext, ein Foto, eine E-Mail mit wechselnder Formulierung. Dort übernimmt eine KI-gestützte Automatisierung, die Inhalte liest und interpretiert, statt nur eine Oberfläche zu bedienen — und die beiden Ansätze lassen sich im selben Ablauf auch kombinieren. Wann klassisches RPA reicht und wann mehr nötig ist, steht in den Abschnitten darunter.

„Robotergesteuerte Prozessautomatisierung" klingt nach mehr, als der Begriff meint: Kein physischer Roboter ist beteiligt, sondern eine Software, die auf dem Bildschirm das tut, was vorher eine Person mit Maus und Tastatur gemacht hat. Für viele Betriebe ist RPA der erste Kontakt mit dem Thema Automatisierung überhaupt — meist über einen Anbieter, der eine einzelne Lizenz für einen einzelnen Ablauf verkauft.

Dieser Beitrag ordnet ein, was RPA technisch tatsächlich macht, wo sie sich von der KI-gestützten Automatisierung unterscheidet, die wir überwiegend bauen, und an welcher Stelle beide Ansätze kombiniert werden.

Was RPA technisch macht

Ein RPA-Roboter arbeitet auf derselben Oberfläche, auf der auch ein Mensch arbeiten würde: Er öffnet ein Programm, klickt in ein Feld, liest einen Wert aus, trägt ihn an anderer Stelle ein. Das funktioniert zuverlässig, solange sich drei Dinge nicht ändern: die Position der Elemente auf dem Bildschirm, das Format der Eingabedaten und die Reihenfolge der Schritte. Ändert sich eines davon — ein Software-Update verschiebt einen Button, ein Lieferant ändert das Format seiner Rechnung —, bricht der Roboter ab und muss nachjustiert werden.

Das macht RPA gut geeignet für sehr repetitive, stabile Abläufe zwischen Systemen, die keine eigene Schnittstelle zueinander haben — etwa das Übertragen von Bestelldaten aus einem älteren Warenwirtschaftsprogramm in ein neueres. Für alles, was Inhalte deuten muss statt sie nur zu übertragen, ist RPA allein nicht die passende Technik.

RPA und KI-gestützte Automatisierung im Vergleich

| | RPA | KI-gestützte Automatisierung | |---|---|---| | Arbeitet mit | fester Klickabfolge auf der Oberfläche | Inhalten: Text, Bild, Sprache | | Reagiert auf Abweichungen | schlecht — bricht meist ab | gut — erkennt Bedeutung auch bei Abweichung | | Typischer Einsatz | Daten zwischen zwei starren Systemen übertragen | Rechnungen lesen, Anfragen beantworten, Dokumente einordnen | | Pflegeaufwand bei Oberflächen-Updates | hoch | gering, da meist über Schnittstellen statt Oberfläche | | Einstieg | oft eine einzelne Lizenz pro Ablauf | meist ein Baustein, der an mehrere Systeme andockt |

In der Praxis schließen sich beide nicht aus: Ein Ablauf kann mit RPA an ein altes System andocken, das keine Schnittstelle anbietet, und gleichzeitig eine KI-Komponente nutzen, um den Inhalt eines eingehenden Dokuments zu verstehen, bevor die Daten weiterverarbeitet werden. Welches Werkzeug im Einzelfall den Ausschlag gibt — ein Baukasten wie Make oder n8n, eine Individuallösung oder ein RPA-Baustein —, hängt von denselben Kriterien ab wie in Make, n8n oder Eigenbau: Zahl der Systeme, Zahl der Ausnahmen, und wer den Ablauf später pflegen soll.

Ein Beispiel aus der Praxis

Ein Großhändler mit rund 30 Mitarbeitenden nutzte für die Übertragung von Bestelldaten zwischen einem älteren Warenwirtschaftssystem ohne Schnittstelle und der Buchhaltung zunächst einen reinen RPA-Baustein: Der Roboter öffnete beide Programme und übertrug Feld für Feld. Das funktionierte zuverlässig — bis ein Update der Warenwirtschaft die Maske veränderte und der Roboter drei Tage lang stillstand, ohne dass es sofort auffiel.

In der anschließenden Prozessanalyse zeigte sich: Rund 45 Bestellungen pro Woche, je 3 Minuten Übertragung von Hand während des Ausfalls, macht 45 × 3 × 46 ÷ 60 = 104 Stunden im Jahr, wenn der Ausfall zur Regel würde. Statt den RPA-Baustein nur zu reparieren, wurde die Übertragung auf eine Anbindung über die Datenbank des Warenwirtschaftssystems umgestellt — stabiler gegenüber Oberflächen-Updates, weil sie nicht mehr auf der sichtbaren Maske, sondern auf den dahinterliegenden Daten arbeitet. Diese Umstellung war möglich, weil das System eine solche Anbindung erlaubte; bei reinen Cloud-Programmen ohne Datenbankzugriff bleibt oft nur die Anbindung über eine offizielle Schnittstelle oder eben RPA auf der Oberfläche.

Wo RPA an eine klare Grenze stößt

RPA scheitert regelmäßig an drei Stellen: bei Oberflächen, die sich häufig ändern, weil jede Änderung eine manuelle Anpassung braucht; bei Eingaben, die nicht in einem festen Format vorliegen, etwa handschriftliche Notizen oder frei formulierte E-Mails; und bei Programmen, die aktive Bot-Zugriffe technisch blockieren, was bei manchen Cloud-Diensten inzwischen der Fall ist. In all diesen Fällen ist nicht mehr RPA die passende Antwort, sondern eine Anbindung über eine echte Schnittstelle oder eine KI-Komponente, die den Inhalt versteht statt ihn nur abzutippen.

Und unabhängig von der Technik gilt dieselbe Grenze wie bei jeder Automatisierung: Abläufe, die eine fachliche oder rechtliche Einzelfallbewertung brauchen, gehören nicht automatisiert, sondern bleiben bei der Fachperson — egal, ob mit RPA, Baukasten oder Individuallösung gebaut würde.

Was das für die Kosten bedeutet

Klassische RPA-Plattformen werden meist pro eingesetztem Roboter lizenziert — ein laufender Posten, der zusätzlich zur Einrichtung anfällt und mit jedem weiteren automatisierten Ablauf wächst. Bei den Automatisierungen, die wir bauen, liegt der einmalige Aufwand meist zwischen 2.500 und 10.000 Euro, dazu kommt eine Betreuung im niedrigen bis mittleren dreistelligen Bereich pro Monat — unabhängig davon, ob im Hintergrund eine Schnittstelle, ein RPA-Baustein oder eine KI-Komponente arbeitet. Die Betriebskosten der KI-Anteile selbst liegen bei üblichen Mengen im Cent-Bereich je Dokument oder Anfrage und fallen dabei kaum ins Gewicht. Eine ausführliche Rechnung mit mehreren Beispielen steht in Was KI-Automatisierung wirklich kostet.

Der nächste Schritt

Ob euer Ablauf tatsächlich einen RPA-Baustein braucht oder besser über eine Schnittstelle oder eine KI-gestützte Automatisierung läuft, lässt sich am zuverlässigsten in einer Prozessanalyse klären — kostenlos, 60 bis 90 Minuten. Eine Übersicht über die Abläufe, die sich in der Praxis am häufigsten automatisieren lassen, mit Beispielen und Kosten, steht auf der Seite KI-Automatisierung.