RPA Bot – Robotic Process Automation

Die Abkürzung RPA steht für Robotic Process Automation (auf Deutsch: robotergestützte Prozessautomatisierung).

Der Software-Roboter arbeitet ein Skript ab, das die menschliche Bedienung einer Anwendung mit Maus und Tastatur nachbildet. So übernimmt er wiederkehrende Schritte über mehrere Systeme hinweg, ohne dass diese Systeme angepasst werden müssen.

In der Praxis ist der Bot zugleich die Betriebs- und Abrechnungseinheit: Er wird in einer Entwicklungsumgebung gebaut, über eine zentrale Steuerung verteilt und pro Instanz lizenziert.

Anschaulich gesprochen bedient ein RPA-Bot den Bildschirm, statt in die Datenbank zu greifen. Er meldet sich in einer Anwendung an, klickt Felder an, kopiert Werte und trägt sie an anderer Stelle wieder ein. Diese Arbeitsweise auf der Präsentationsschicht erklärt beides: Der Bot funktioniert auch dort, wo keine Schnittstelle existiert, und er bleibt stehen, sobald sich die Oberfläche ändert.

Ein RPA-Bot hat keine physische Form wie ein Industrieroboter, er arbeitet ausschließlich in einer digitalen Umgebung. Vom allgemeinen Bot-Begriff der Informatik, etwa dem Suchmaschinen-Crawler, unterscheidet ihn der Einsatz in Geschäftsprozessen.

Herstellerbegriffe wie „Digital Worker“ oder „Digital Assistant“ meinen dieselbe Sache: SAP verwendet „Digital Assistant“ synonym zum Attended Bot.

Typische Anwendungsfälle für RPA-Bots

Typische Anwendungsfälle für RPA-Bots sind stark strukturierte, sich wiederholende und regelbasierte Routineaufgaben. Insbesondere dann, wenn API-Schnittstellen fehlen.

Beispiele:

• Ein Portal gibt Daten nur am Bildschirm heraus, nicht als Datei. Kundenportale großer Auftraggeber, Lieferanten- und Vergabeplattformen, Behördenportale. Der Bot holt Bestellungen, Ausschreibungen oder Bescheide dort ab und legt sie im eigenen System an.
• Zwischen zwei Anwendungen fehlt die Verbindung, also tippt jemand dieselbe Information zweimal. Adress-, Preis- und Artikeländerungen, die parallel in CRM, ERP und Shop ankommen müssen, sind der Standardfall.
• Ein Vorgang startet im Posteingang. Aus E-Mail, Webformular oder eingescanntem Papier entsteht ein Datensatz im Fachsystem, etwa eine Schadenmeldung beim Versicherer oder eine Reklamation im Qualitätswesen.
• Ein Massenlauf wiederholt sich nach Zeitplan. Bestände abgleichen, Zählerstände verarbeiten, Fristen prüfen, Berichte zum Monatsende erzeugen. Solche Läufe passen zu unbeaufsichtigtem Betrieb nachts, während Bots am Arbeitsplatz eher Einzelvorgänge begleiten.
• Eine Aufgabe ist befristet und zu groß für Handarbeit. Datenübernahme bei einem Systemwechsel, Massenpflege nach einer Preisrunde, Nachdokumentation nach einer Prüfung.

Typische Anwendungsfälle haben folgendes gemeinsam: fester Ablauf, strukturierte Eingangsdaten, genug Wiederholungen pro Woche, um Entwicklung und Wartung zu tragen.

Nach Branchen sammeln sich die Fälle dort, wo Belegmengen und Regulierung zusammenkommen, also im Banken- und Versicherungsumfeld, bei Energieversorgern und in der Verwaltung. Welche fünf Merkmale ein Kandidatenprozess erfüllen muss, steht weiter unten unter „Welche Prozesse einem Bot standhalten“.

Im Marketing ist der Bot dagegen selten die erste Wahl. Werbe- und Analyseplattformen bieten meist dokumentierte Schnittstellen an, und wer Kampagnendaten darüber zieht, bekommt sie stabiler als über eine nachgebaute Klickstrecke im Anzeigenkonto. Interessant wird RPA erst bei Werkzeugen ohne API, etwa einem älteren PIM oder einem Lieferantenportal ohne Datenexport.

So arbeitet ein Bot auf der Benutzeroberfläche

RPA automatisiert „outside-in“: Die Werkzeuge arbeiten auf der Oberfläche anderer Computersysteme so, wie es ein Mensch täte. Das Informationssystem selbst bleibt dabei unverändert. Das unterscheidet den Ansatz von klassischer Workflow-Technologie, die „inside-out“ in die Anwendung eingreift.

Der praktische Vorteil: Bots lassen sich auch dort einsetzen, wo keine API existiert oder die Ressourcen für eine tiefe Integration fehlen.

Von Trigger bis Rückmeldung

Ein Bot-Lauf beginnt mit einem Trigger, also einem Ereignis oder einer Bedingung, die die Aufgabe startet. Das kann ein Zeitplan sein, eine Logik im Prozessablauf oder bei Attended Bots eine Aktion des Mitarbeiters.

Anschließend sammelt der Bot die benötigten Daten, typischerweise aus E-Mails, Tabellen, CRM- oder ERP-Systemen und Datenbanken. Erst danach folgen die eigentlichen Aktionen auf der Oberfläche: anmelden, navigieren, Felder ausfüllen, Werte übertragen, Dokumente ablegen.

Am Ende steht die Ergebnisübergabe, und genau hier entscheidet sich die Betriebstauglichkeit. Tritt eine Ausnahme auf, etwa durch widersprüchliche Daten, geht der Vorgang zur manuellen Weiterbearbeitung, statt den Lauf zu blockieren. Wer diesen Ausschleusepfad nicht mitplant, baut einen Bot, der beim ersten unerwarteten Datensatz den gesamten Stapel anhält.

Studio, Orchestrator, Robot

Eine RPA-Plattform besteht üblicherweise aus drei Komponenten.

1. Im Studio entsteht die Automatisierung visuell, bei UiPath etwa als Sequenz-, Fluss- oder Zustandsdiagramm mit Aktivitäten für jede Tastatur- und Mauseingabe
2. Der Orchestrator übernimmt Deployment, Konfiguration, Zeitplanung, Queue-Management und Logging
3. Der Robot ist die Instanz, die den Ablauf tatsächlich ausführt und die Benutzeraktionen am Bildschirm nachbildet

Das Skript wird in der Entwicklungsumgebung erstellt und getestet, zentral im Repository abgelegt und in einer ausgewählten Laufzeitumgebung ausgeführt.

Wer nur „einen Bot“ beschafft und die Orchestrierung ausspart, verliert damit die Steuerung über Warteschlangen, Zeitpläne und Protokolle. Genau diese Ebene macht aus einzelnen Automatisierungen einen skalierbaren Betrieb, weil sich Läufe verteilen, priorisieren und nachvollziehen lassen.

Warum Selektoren über Erfolg entscheiden

Klassische RPA-Werkzeuge wie UiPath, Automation Anywhere, Blue Prism und Power Automate binden ihre Schritte an konkrete Oberflächenelemente: Selektoren, XPaths und Objekt-IDs.

Ändert sich ein Bildschirm, erscheint eine neue Anwendungsversion oder benennt ein Anbieter einen Klassennamen um, dann kann diese Bindung brechen und der Bot hält an.

SAP formuliert denselben Sachverhalt herstellerneutral: Bots sind auf Elemente der Benutzeroberfläche angewiesen. Deshalb können schon kleinste Änderungen an der Anwendung die Automatisierung stören.

Daraus folgt eine Anforderung an den Kandidatenprozess. Je häufiger sich das Zielsystem ändert, desto teurer wird der Bot im Unterhalt, unabhängig davon, wie sauber er gebaut ist. Regelmäßige Updates, laufende Überwachung und eine belastbare Governance sind deshalb Voraussetzung für zuverlässigen Betrieb.

Attended oder unattended?

Die Typwahl ist die erste Entscheidung. Sie legt fest, unter wessen Rechten der Bot läuft, wo er ausgeführt wird und wer die Prozessverantwortung trägt. Sie wirkt direkt auf die Lizenzkosten, weil unbeaufsichtigte Ausführung anders abgerechnet wird als der Betrieb am Arbeitsplatz.

Attended: Bot am Arbeitsplatz

Attended Bots warten darauf, von Mitarbeitern aktiviert zu werden. Im Attended Mode arbeitet der Bot als virtueller Assistent auf dem Rechner eines Fachbereichsmitarbeiters. Er läuft unter dessen Aufsicht und mit dessen Benutzerrechten. Die Prozessverantwortung bleibt damit beim Menschen, der Bot läuft auf dessen Desktop oder auf einem virtuellen zweiten Desktop.

Dieser Einsatz zielt meist auf Front-Office-Aktivitäten und läuft am Arbeitsplatz sichtbar ab. Deshalb ist auch von Robotic Desktop Automation (RDA) oder von einem Digital Assistant die Rede. Wenn ein Sachbearbeiter pro Vorgang entscheidet und der Bot nur die Tipparbeit übernimmt, ist das der passende Typ. Die Rechte über das Mitarbeiterkonto vereinfachen den Start, koppeln den Bot aber an Anwesenheit und Anmeldung dieses Nutzers.

Unattended: Bot auf der virtuellen Maschine

Unattended Bots arbeiten unabhängig und führen einen regelbasierten Prozess bis zum Abschluss durch. Ausgelöst werden sie nach Zeitplan oder durch Logik im Prozessablauf, nicht durch einen Menschen. Ausgeführt werden sie auf freien beziehungsweise virtuellen Maschinen, damit die Arbeitslast überhaupt zu bewältigen ist.

Dieser Typ ist für hohe Mengen ausgelegt und bearbeitet Vorgänge vollständig ohne Aufsicht. Der Preis dafür ist doppelt: Jede unbeaufsichtigte Automatisierung braucht eine eigene Lizenz. Dazu kommt eine Ausführungsumgebung, die auch nachts und am Wochenende bereitsteht. Wer nachts 4.000 Rechnungspositionen übertragen lassen will, kommt an unattended Betrieb nicht vorbei, muss aber Lizenz und Infrastruktur zusammen kalkulieren.

Wann sich ein hybrider Aufbau lohnt

Ein hybrider Aufbau teilt den Prozess an der Stelle, an der die menschliche Entscheidung endet. Der Mitarbeiter prüft und löst den Vorgang aus, den mengenintensiven Rest übernimmt eine unbeaufsichtigte Instanz nach Zeitplan oder Warteschlange. Sinnvoll ist diese Teilung dort, wo nur der erste Schritt Ermessen erfordert, der nachgelagerte Teil aber vollständig regelbasiert ist. Belastbare Kennzahlen zur Verbreitung und zum Nutzen hybrider Aufbauten liefert die Recherche nicht. [Recherchelücke, menschliche Prüfung]

Aufgezeichnet, geklickt oder programmiert

Bot-Skripte entstehen laut Gartner-Marktdefinition entweder (1) per Programmierung oder (2) über eine Low-Code- beziehungsweise No-Code-Oberfläche.

Der dritte Weg ist die Aufzeichnung: Citizen Developer schneiden eine Abfolge von Schritten während der Ausführung mit. Das System wandelt diese Aktionen dann in wiederholbare Abläufe um, die der Bot später ausführt. Alle drei Wege münden in dasselbe Ergebnis, ein Skript, das im Repository liegt und in einer Laufzeitumgebung deployt wird.

Die Wege tragen unterschiedlich weit. Die Aufzeichnung eignet sich für kurze, lineare Klickstrecken ohne Verzweigungen und ist der schnellste Einstieg für Fachbereiche.

Sobald Bedingungen, Schleifen, Ausnahmebehandlung und Übergaben zwischen mehreren Anwendungen dazukommen, führt der Weg über das Studio. Dort werden die Aktivitäten als Sequenz-, Fluss- oder Zustandsdiagramm strukturiert.

Der typische Fehlgriff ist, eine aufgezeichnete Klickstrecke direkt produktiv zu setzen: Sie enthält keine Prüfungen, keinen Ausschleusepfad für fehlerhafte Datensätze und bricht bei der ersten Oberflächenänderung. Da jedes Skript vor dem Deployment getestet und freigegeben wird, gehört der Aufwand für Test und Governance in jede Schätzung, unabhängig vom gewählten Weg.

Welche Prozesse einem Bot standhalten

Ein Kandidatenprozess lässt sich an fünf Merkmalen prüfen. Er muss regelbasiert sein, weil der Bot einem vordefinierten Ablauf folgt und keine eigenen Entscheidungen trifft. Die Eingangsdaten sollten strukturiert vorliegen, denn RPA-Bots folgen nur den vom Endnutzer definierten Prozessen.

Muster in unstrukturierten Daten erkennen dagegen lernende Verfahren. Das Zielsystem muss stabil sein, sonst frisst die Wartung den Nutzen auf. Das Volumen muss den Aufwand rechtfertigen, wobei unbeaufsichtigte Bots gerade für große Mengen ausgelegt sind. Und die Ausnahmefälle müssen benennbar sein, damit sich ein Ausschleusepfad definieren lässt.

Ausschlusskriterien

Ungeeignet sind Prozesse mit Ermessensentscheidungen, denn RPA folgt nur klar definierten Anweisungen. Ein eingebauter „gesunder Menschenverstand“, der bei Unklarheiten entscheidet, fehlt dem Bot. Ebenso problematisch sind Abläufe mit unstrukturierten Eingangsdaten, weil der Bot ohne zusätzliche Komponenten keine Muster erkennen und nicht dazulernen kann.

Der dritte Ausschlussgrund ist ein häufig wechselndes Zielsystem. Bots müssen ständig gewartet werden, teils häufiger als reguläre Anwendungen. Das gilt besonders, wenn sich die zugrundeliegenden Systeme ändern, etwa eine Website, von der Daten geholt werden. Auch regulatorische Änderungen im Geschäftsprozess ziehen jeweils Anpassungen am Bot nach sich. Ein Prozess, der in beiden Dimensionen instabil ist, verursacht dauerhaft Änderungsaufwand. Er sollte eher über eine Schnittstelle oder gar nicht automatisiert werden.

Was ein Bot pro Monat kostet

Abgerechnet wird bei unbeaufsichtigter Automatisierung nicht pro Nutzer, sondern pro gleichzeitig laufendem Bot. Microsoft Power Automate zeigt diese Logik mit öffentlichen Listenpreisen:

• Per-User-Modell: 15 US-Dollar pro Nutzer und Monat
• Process-Plan für unattended RPA: 150 US-Dollar pro Bot und Monat
• Hosted Process für cloud-gehostete Bots: 215 US-Dollar pro Bot und Monat

Ein Team mit vier parallel laufenden unbeaufsichtigten Prozessen kommt damit auf 600 US-Dollar monatlich, noch bevor die darunterliegenden Premium-Nutzerlizenzen gezählt sind. Die Werte stammen aus Drittanbieter-Preisübersichten. Vor einer Kalkulation sollte man sie gegen die offizielle Preisliste des Herstellers prüfen, besonders bei Preisen in Euro.

Die Kosten steigen also mit der Parallelität, nicht mit der Zahl der Automatisierungen. Prozesse, die nacheinander laufen können, teilen sich eine Instanz. Wer dagegen fünf Abläufe gleichzeitig um 6 Uhr startet, zahlt ohne fachlichen Grund das Vierfache, obwohl vier davon auch über den Tag verteilt laufen könnten.

Warum Lizenz nicht gleich Gesamtkosten ist

Neben der Lizenz fallen mindestens vier weitere Posten an. Die Entwicklung im Studio samt Test und Freigabe ist Projektaufwand, der bei komplexen Abläufen nicht mit einer Aufzeichnung erledigt ist. Die Orchestrierung mit Deployment, Queue-Management und Logging ist eine eigene Plattformkomponente. Unbeaufsichtigte Bots brauchen freie oder virtuelle Maschinen als Ausführungsumgebung. Und die laufende Wartung ist ein Dauerposten, weil Bots häufiger angepasst werden müssen als reguläre Anwendungen. Zusätzlich braucht es weiterhin Menschen, die Ausnahmen prüfen und beurteilen, wann Verbesserungen nötig sind.

Warum Bots stehenbleiben

Ausfälle haben in der Regel eine von drei Ursachen: Die Bindung an die Oberfläche bricht, ein Datensatz passt nicht ins Regelwerk, oder Zugangsdaten und Berechtigungen stimmen nicht mehr. Alle drei lassen sich vor dem Produktivstart durch klare Zuständigkeiten und Mechanismen entschärfen.

Updates am Zielsystem

Ein neues Release der Zielanwendung, eine geänderte Bildschirmmaske oder ein umbenannter Klassenname reichen aus, damit ein Selektor ins Leere greift und der Bot anhält. Entscheidend ist die Frage, wer diese Anpassung verantwortet. In der Praxis liegt diese Verantwortung beim anwendenden Unternehmen, nicht beim Anbieter der Zielsoftware. Es muss die Lauffähigkeit sichern und den Bot bei Updates und Releases anpassen. Wer den Bot einführt, braucht deshalb einen Prozess, der die Release-Termine der Zielsysteme kennt. Testläufe gehören davor, sonst zeigen sich Ausfälle erst im Produktivbetrieb.

Was bei Fehlern passiert

Ausnahmen wie fehlende Daten, Regelverstöße oder Systemfehler erfordern häufig menschliches Eingreifen. Eine tragfähige Ausnahmesteuerung leitet den betroffenen Vorgang zur manuellen Weiterbearbeitung aus und lässt den Bot mit dem nächsten Datensatz weiterarbeiten. Fehlt dieser Pfad, verlangsamt jede Abweichung den gesamten Prozess, und der Zeitgewinn kehrt sich um. Diese Ausschleusung gehört bereits in die Entwicklung, nicht in eine spätere Ausbaustufe.

Zugangsdaten und Berechtigungen

Bots benötigen Zugriff auf mehrere Systeme, üblicherweise mit denselben hartcodierten Anmeldeinformationen. Das öffnet ein Einfallstor für Angreifer, die Bots manipulieren können. Weil Software-Roboter auch automatisch erzeugt werden können, wächst das Risiko mit ihrer Anzahl. Die Berechtigungsnachweise für privilegierte Konten, die Roboterskripte nutzen, sind eine Bedrohung, wenn sie unsicher vergeben und gespeichert werden. Ein zentrales Credential-Management und eigene, minimal berechtigte Bot-Konten gehören daher spätestens ab dem zweiten produktiven Bot in die Planung, nicht erst in die Skalierung.

Bot, API oder KI-Agent?

RPA und API senken beide den manuellen Aufwand, sind aber grundlegend verschiedene Werkzeuge. Die falsche Wahl kostet Nacharbeit und Budget. Der Unterschied liegt in der Ebene: Der Bot bedient die Präsentationsschicht, die Schnittstelle spricht das System direkt an. Ein Makro deckt dagegen nur Abläufe innerhalb einer einzelnen Anwendung ab, während der Bot mehrere Systeme über deren Oberflächen verbindet.

Wann die API die bessere Wahl ist

Existiert eine dokumentierte Schnittstelle und soll der Prozess dauerhaft laufen, ist die Anbindung über die API die stabilere Lösung. Sie funktioniert unabhängig von Bildschirmmasken und Selektoren. Der Bot ist dort im Vorteil, wo keine API vorhanden ist oder wo die Ressourcen für eine tiefe Integration fehlen.

Sein zweiter Vorteil: Die zugrundeliegenden Systeme bleiben unverändert. Das macht ihn für Altanwendungen und für Umgebungen mit strengen Änderungsauflagen geeignet. Als Faustregel gilt: API bei stabilem Dauerbetrieb und vorhandener Schnittstelle, Bot als Überbrückung dort, wo kein Zugang unterhalb der Oberfläche zur Verfügung steht.

Eine vorhandene Schnittstelle schließt den Bot nicht automatisch aus. Läuft der Prozess nur befristet oder fehlt das Budget für die Integration, bleibt der Bot die pragmatische Wahl, muss aber dieselben Anforderungen an Stabilität und Datenqualität erfüllen.

Wo RPA aufhört und KI anfängt

RPA ist nicht mit künstlicher Intelligenz zu verwechseln, denn die Technologie folgt einem vordefinierten Ablauf. Der Bot kann nur die vom Endnutzer definierten Prozesse abarbeiten. KI-gestützte Verfahren erkennen dagegen mit maschinellem Lernen Muster, besonders in unstrukturierten Daten, und verbessern sich über die Zeit. Ein Chatbot wiederum führt einen Dialog mit Nutzern und ist damit eine eigene Kategorie, kein Prozessausführer.

Sinnvoll ist die Kombination genau an der Bruchstelle: Ein lernendes Verfahren strukturiert die Eingangsdaten, etwa aus Dokumenten, und der Bot übernimmt danach die regelbasierte Weiterverarbeitung über die Systemoberflächen. Wer dagegen erwartet, dass ein reiner RPA-Bot bei unklaren Fällen sinnvoll entscheidet, unterschätzt seine Grenze, denn er bringt keinen „gesunden Menschenverstand“ mit.

FAQ