Der Begriff führt manchmal in die Irre. Bei RPA gibt es keine physischen Roboter und keine künstliche Intelligenz im eigentlichen Sinne. Ein „Roboter“ ist hier nichts anderes als ein Stück Software, das einen zuvor definierten Ablauf auf einem Computer ausführt – Maus und Tastatur werden simuliert, Bildschirminhalte werden ausgelesen, Entscheidungen werden anhand fest hinterlegter Regeln getroffen. Wer schon einmal ein Excel-Makro aufgenommen hat, kennt das Grundprinzip in einer einfachen Form. RPA hebt dieses Prinzip auf Unternehmensniveau: Ein Bot kann nicht nur eine Anwendung steuern, sondern mehrere Programme nacheinander bedienen, sich anmelden, Daten aus einer E-Mail in ein ERP-System übertragen, dort eine Buchung anlegen und anschließend eine Bestätigung verschicken.
Genau diese Arbeitsweise ist Stärke und Schwäche zugleich. RPA lässt sich auch über Altsysteme legen, die keine moderne Schnittstelle besitzen: ERP-Masken aus den frühen 2000ern, Terminal-Anwendungen, Web-Portale von Behörden oder Lieferanten, branchenspezifische Speziallösungen ohne offene API. Der Bot bedient diese Systeme von außen, ohne sie zu verändern – das macht RPA schnell einführbar und risikoarm in der Anbindung. Zugleich ist die Bedienung der Oberfläche von Natur aus fragil: Ändert sich eine Maske, verschiebt sich ein Button oder wird ein Feld umbenannt, findet der Bot seine Anhaltspunkte nicht mehr und der Ablauf bricht ab.
Drei Merkmale grenzen RPA klar von anderen Automatisierungsformen ab und erklären, warum die Technologie im Mittelstand so beliebt geworden ist:
Trotz des KI-Hypes ist RPA keineswegs veraltet – im Gegenteil. Viele Unternehmen besitzen eine über Jahrzehnte gewachsene Systemlandschaft, in der zentrale Anwendungen schlicht keine moderne Schnittstelle anbieten. Solange diese Altsysteme im Einsatz bleiben, bleibt die UI-Automatisierung oft der einzige wirtschaftlich vertretbare Weg, um Medienbrüche zu überbrücken. Hinzu kommt, dass RPA inzwischen mit KI-Komponenten kombiniert wird: Dokumentenerkennung, Texteinordnung und intelligente Ausnahmebehandlung erweitern den klassischen Bot um Fähigkeiten, die regelbasierte Logik allein nicht abdecken kann. Damit ist RPA heute weniger eine isolierte Technologie als ein Baustein in einem größeren Automatisierungs-Gefüge.
Die wichtigsten Gründe für den anhaltenden Einsatz im DACH-Markt: RPA funktioniert ohne API auch über Altsysteme, erzielt schnelle erste Erfolge bei klaren Routineprozessen, erfordert keine Änderung der bestehenden Systeme, skaliert über beaufsichtigte und unbeaufsichtigte Bots, reduziert Fehler bei manueller Dateneingabe und liefert einen messbaren ROI bei hohem Mengenaufkommen.
Ein RPA-Ablauf entsteht typischerweise in drei Schritten. Zunächst wird der Prozess aufgenommen oder modelliert: Mit einem Recorder klickt eine Fachkraft den Ablauf einmal durch, oder ein Entwickler baut den Ablauf in einer visuellen Oberfläche per Drag-and-drop zusammen. Anschließend wird der Bot mit Regeln, Verzweigungen und Fehlerbehandlung verfeinert – etwa, was passieren soll, wenn ein Feld leer ist oder eine Anwendung nicht antwortet. Zuletzt wird der fertige Bot in Betrieb genommen und über eine zentrale Steuerung – die Orchestrierung – geplant, gestartet und überwacht.
Damit ein Bot ein Eingabefeld findet, braucht er Anhaltspunkte. Moderne RPA-Plattformen nutzen dafür mehrere Strategien. Im besten Fall liest der Bot die technischen Eigenschaften eines Bedienelements aus – etwa eine eindeutige Kennung im Hintergrund der Anwendung. Wo das nicht möglich ist, arbeitet er mit relativen Positionen, mit Texterkennung auf dem Bildschirm oder im Extremfall mit reiner Bilderkennung von Koordinaten. Je „weiter unten“ in dieser Kette ein Bot arbeiten muss, desto fragiler wird er: Eine Anwendung, die nur über Pixel-Koordinaten bedient werden kann, bricht bereits, wenn sich die Bildschirmauflösung ändert. Diese technische Realität ist der Kern fast aller späteren Wartungsthemen und sollte schon bei der Prozessauswahl mitgedacht werden.
Ein beaufsichtigter Bot (Attended) läuft auf dem Rechner eines Mitarbeitenden und wird von diesem ausgelöst. Er arbeitet quasi Schulter an Schulter mit dem Menschen: Die Fachkraft startet den Bot per Knopfdruck, wenn ein bestimmter Schritt ansteht – etwa das Anlegen eines Neukunden in fünf verschiedenen Systemen – und der Bot übernimmt die monotone Klickarbeit, während der Mensch die Kontrolle behält. Attended Automation eignet sich besonders im Front-Office, etwa im Kundenservice oder im Vertrieb, wo Prozesse menschliche Entscheidungen enthalten und der Bot punktuell entlastet. Der Nachteil: Der Rechner ist während des Bot-Laufs gebunden, und der Skalierungseffekt ist begrenzt, weil immer ein Mensch beteiligt ist.
Ein unbeaufsichtigter Bot (Unattended) läuft autonom im Hintergrund, typischerweise auf einem Server oder einer virtuellen Maschine, und wird zeit- oder ereignisgesteuert ausgelöst – etwa nachts um drei Uhr, wenn keine Mitarbeitenden im System sind, oder automatisch beim Eintreffen einer neuen Datei. Unattended Automation entfaltet den größten Skalierungseffekt: Mehrere Bots können parallel arbeiten, eine zentrale Orchestrierung verteilt die Aufgaben, und das Mengenvolumen lässt sich nahezu beliebig hochfahren, solange Lizenzen und Infrastruktur ausreichen. Dieser Modus eignet sich für das Back-Office – Massenverarbeitung von Belegen, nächtliche Datenabgleiche, regelmäßiges Reporting. Der Preis dafür ist ein höherer Anspruch an Betrieb, Berechtigungen und Monitoring, weil hier ohne menschliche Aufsicht gearbeitet wird.
Der wichtigste Vergleich überhaupt. Eine API-Integration verbindet zwei Systeme über deren offizielle Schnittstellen – Daten fließen direkt und strukturiert von einer Anwendung in die andere, ohne den Umweg über eine Bildschirmoberfläche. Das ist robuster, schneller und wartungsärmer, weil sich Schnittstellen seltener ändern als Oberflächen und Änderungen meist mit Vorlauf angekündigt werden. RPA dagegen bedient die Oberfläche und ist deshalb fragiler. Die Regel ist eindeutig: Wo eine stabile API existiert, ist die echte Integration der UI-Automatisierung vorzuziehen. RPA ist die richtige Wahl, wenn keine Schnittstelle verfügbar ist – typisch bei Altsystemen – oder wenn sehr schnell entlastet werden muss und die Integration erst später kommt.
Hier liegt der schärfste konzeptionelle Unterschied. Ein klassischer RPA-Bot ist deterministisch und regelbasiert: Er tut exakt, was ihm vorgegeben wurde, und scheitert an allem, was nicht vorab beschrieben ist. Ein KI-Agent dagegen arbeitet auf Basis großer Sprachmodelle, kann Aufgaben interpretieren, mit unstrukturierten Eingaben umgehen, Zwischenschritte selbst planen und auf unvorhergesehene Situationen reagieren. Damit deckt der KI-Agent genau die Lücke, die RPA strukturell offenlässt – nämlich Urteilsvermögen und Umgang mit Mehrdeutigkeit. Der Preis: KI-Agenten sind nicht deterministisch, ihre Ergebnisse müssen validiert werden, und sie sind schwerer auditierbar. In der Praxis verschmelzen beide Welten zunehmend: Der Bot übernimmt die zuverlässige, regelhafte Klickarbeit, die KI übernimmt das Lesen und Einordnen – etwa, um aus einer frei formulierten E-Mail die relevanten Bestelldaten zu extrahieren, die der Bot dann sauber in das ERP-System einträgt.
Process Mining ist keine Automatisierungs-, sondern eine Analyse-Technologie. Es rekonstruiert aus den digitalen Spuren in den IT-Systemen – den Ereignisprotokollen – wie ein Prozess tatsächlich abläuft: wo Schleifen entstehen, wo Wartezeiten anfallen, welche Varianten existieren und welche Schritte sich besonders oft wiederholen. Process Mining beantwortet damit die Frage, die vor jeder RPA-Initiative steht: Welche Prozesse lohnen sich überhaupt für eine Automatisierung? Die beiden Technologien ergänzen sich also perfekt – Mining identifiziert und priorisiert die Kandidaten, RPA setzt die Automatisierung der geeigneten Kandidaten um. Wer ohne diese Analyse automatisiert, läuft Gefahr, viel Aufwand in Prozesse zu stecken, die gar nicht den größten Hebel bieten.
Der Begriff Hyperautomation beschreibt das orchestrierte Zusammenspiel dieser Technologien zu einer durchgängigen End-to-End-Automatisierung. Process Mining liefert die Erkenntnis, welche Prozesse sich lohnen; RPA übernimmt die regelhafte Ausführung; KI ergänzt das Urteilsvermögen für unstrukturierte Daten; eine Prozessmanagement- bzw. Orchestrierungs-Ebene (BPM) hält alles zusammen und steuert die Übergänge zwischen Mensch, Bot und KI. RPA ist in diesem Bild ein wichtiger, aber einzelner Baustein – nicht das Gesamtkonzept. Diese Einordnung ist entscheidend, weil sie verhindert, dass RPA als vermeintliche Universallösung überdehnt wird.
Quer durch diese Beispiele zeigt sich ein klares Muster. Ideal sind Prozesse, die hochvolumig, stabil, regelbasiert und dokumentierbar sind: Sie fallen oft an, laufen auf Systemen mit unveränderlichen Oberflächen, folgen klaren Wenn-dann-Regeln und lassen sich vollständig in Worte fassen. Je strukturierter die Eingangsdaten und je seltener die Zielsysteme sich ändern, desto höher der Nutzen und desto geringer der Wartungsaufwand. Schlechte Kandidaten sind das genaue Gegenteil: seltene Einzelfälle, häufig wechselnde Oberflächen, viel menschliches Urteilsvermögen und unstrukturierte Eingaben ohne klare Regeln.
In der Praxis sehen wir RPA besonders in Finanzbuchhaltung und Rechnungswesen, in der Auftragsabwicklung von Handel und Produktion, im Personalwesen sowie in stark formularbasierten Bereichen wie Versicherung, Verwaltung und Gesundheitswesen. Allen gemeinsam ist eine heterogene Systemlandschaft, in der ein zentrales System ohne offene Schnittstelle den Takt vorgibt und drumherum manuell überbrückt wird. Genau dieser Medienbruch ist das natürliche Revier von RPA – und der Grund, warum die Technologie im Mittelstand so verlässlich ihren ROI findet.
Die Tool-Auswahl ist seltener eine Frage des „besten“ Produkts als eine Frage der Passung. Drei Kriterien sind in unseren Projekten ausschlaggebend. Erstens der vorhandene Stack: Wer ohnehin tief in einer Cloud-Suite steckt, fährt mit der integrierten Lösung oft günstiger und reibungsärmer. Zweitens das Lizenzmodell: Manche Plattformen rechnen pro Bot, andere pro Lauf oder pro Nutzer – je nach Mengenstruktur kann derselbe Anwendungsfall sehr unterschiedlich teuer werden. Drittens die Verfügbarkeit von Know-how: Eine Plattform mit großem Fachkräfte- und Partner-Ökosystem senkt das Betriebsrisiko erheblich, weil Wartung und Weiterentwicklung nicht an einzelnen Personen hängen.
Der Funktionsumfang der etablierten Anbieter ist weitgehend vergleichbar. Dazu zählen ein Recorder zur Aufnahme von Abläufen, eine visuelle Entwicklungsumgebung, eine zentrale Orchestrierung für Planung und Überwachung der Bots, eine sichere Verwaltung von Zugangsdaten, Protokollierung und Audit-Trails sowie zunehmend KI-Bausteine für Dokumentenerkennung und den Umgang mit unstrukturierten Daten. Unterschiede liegen weniger im „Ob“ als im „Wie gut“ und im Preis – weshalb ein sauberer Proof of Concept auf den eigenen Prozessen aussagekräftiger ist als jeder Funktionsvergleich auf dem Papier.
Der Nutzen von RPA setzt sich aus mehreren Komponenten zusammen, die weit über die reine Zeitersparnis hinausgehen. Am offensichtlichsten ist die Entlastung von monotoner Klickarbeit: Tätigkeiten, die einen Menschen Stunden kosten, erledigt ein Bot in Minuten und rund um die Uhr. Hinzu kommt die Fehlerreduktion – ein Bot vertippt sich nicht und überspringt keinen Schritt, was bei manueller Dateneingabe die häufigste Fehlerquelle ist. Weniger sichtbar, aber oft genauso wertvoll sind Geschwindigkeit und Verfügbarkeit: Prozesse laufen schneller durch, Durchlaufzeiten sinken, und Mitarbeitende werden für höherwertige Aufgaben frei.
Ein Rechenbeispiel aus der Praxis verdeutlicht die Größenordnung. Angenommen, ein Prozess der Rechnungserfassung bindet täglich zwei Vollzeitkräfte für jeweils vier Stunden reine Tipparbeit:
Liegen die Lizenz- und Betriebskosten für diesen Bot bei beispielsweise 15.000 bis 20.000 € pro Jahr und die einmalige Entwicklung bei einem ähnlichen Betrag, ist die Amortisation innerhalb des ersten Jahres realistisch – und in den Folgejahren verbessert sich das Verhältnis weiter, weil die Entwicklungskosten entfallen. Genau dieses Muster macht RPA bei den richtigen Prozessen so attraktiv.
So überzeugend die Zahlen klingen, so wichtig ist die nüchterne Einordnung. Der theoretische Nutzen realisiert sich nur, wenn drei Bedingungen erfüllt sind. Erstens muss das Volumen tatsächlich hoch sein – bei seltenen Einzelfällen kippt die Rechnung sofort, weil Entwicklung und Wartung den Nutzen übersteigen. Zweitens müssen die Zielsysteme stabil sein; jede Oberflächenänderung erzeugt Wartungsaufwand, der in der ersten Begeisterung gern vergessen wird. Drittens muss die gewonnene Zeit auch genutzt werden: Wird ein halber Mitarbeitender eingespart, der trotzdem weiterbeschäftigt bleibt, ohne die Zeit wertschöpfend einzusetzen, bleibt der ROI ein Buchwert ohne Kassenwirkung.
Wirtschaftlich am erfolgreichsten sind RPA-Programme, die mit einem einzigen, klar abgegrenzten und stabilen Hochvolumen-Prozess beginnen. Dieser erste Anwendungsfall liefert den Nachweis, schafft Vertrauen und finanziert über die Einsparung die nächsten Schritte. Erst danach lohnt sich der Aufbau einer breiteren Automatisierungs-Basis. Der umgekehrte Weg – große Plattform, viele parallele Initiativen, hohe Vorabinvestition – scheitert in der Praxis überdurchschnittlich oft, weil er Risiken und Kosten bündelt, bevor der Nutzen bewiesen ist.
Die fundamentalste Schwäche von RPA ist zugleich seine Daseinsberechtigung: Weil der Bot die Oberfläche bedient, ist er von dieser Oberfläche abhängig. Ändert sich eine Maske, verschiebt sich ein Button, wird ein Feld umbenannt oder ein Anmeldedialog umgestaltet, findet der Bot seine Anhaltspunkte nicht mehr und der Ablauf bricht ab. Diese Fragilität ist kein Mangel der einzelnen Lösung, sondern ein Wesensmerkmal der UI-Automatisierung. Besonders kritisch wird es bei Cloud-Anwendungen, die der Hersteller laufend und ohne Vorankündigung aktualisiert – hier kann ein Bot von einem Tag auf den anderen ausfallen. Stabile, selten geänderte Altsysteme sind aus genau diesem Grund die dankbarsten RPA-Ziele.
Aus der Brüchigkeit folgt der zweite große Risikofaktor: der laufende Wartungsaufwand. Ein RPA-Programm ist kein Projekt mit Enddatum, sondern ein Betrieb. Jeder produktive Bot muss überwacht, bei Störungen analysiert und nach Systemänderungen angepasst werden. Wächst die Zahl der Bots, wächst auch dieser Aufwand – ohne klare Verantwortlichkeiten und Monitoring entsteht schnell eine Situation, in der mehr Zeit in die Reparatur der Bots fließt als sie einsparen. Diese stille Kostenkurve ist der Hauptgrund, warum viele anfangs euphorische RPA-Initiativen nach zwei bis drei Jahren ins Stocken geraten.
Das vielleicht wichtigste strategische Risiko ist konzeptioneller Natur. RPA überbrückt einen Medienbruch, ohne ihn zu beheben – es legt sich wie ein Pflaster über die fehlende Integration zweier Systeme. Das ist kurzfristig pragmatisch und richtig. Problematisch wird es, wenn das Pflaster zur Dauerlösung wird und die eigentlich gebotene saubere Integration dadurch dauerhaft aufgeschoben wird. Wo eine API existiert oder mit vertretbarem Aufwand geschaffen werden könnte, ist die echte Integration der UI-Automatisierung fast immer überlegen – robuster, schneller, wartungsärmer. RPA sollte in diesen Fällen bewusst als Übergangslösung mit definiertem Ablaufdatum geplant werden, nicht als bequeme Vermeidung der eigentlichen Aufgabe.
Die Quintessenz: RPA ist weder Wundermittel noch Auslaufmodell. Es ist ein präzises Werkzeug für eine klar umrissene Klasse von Aufgaben. Wer diese Klasse trifft, erntet schnellen und messbaren Nutzen. Wer RPA überdehnt – auf instabile Systeme, seltene Fälle oder als Ersatz für eine ohnehin fällige Integration –, produziert Folgekosten, die den anfänglichen Vorteil aufzehren.
Ein Center of Excellence (CoE) ist die zentrale organisatorische Einheit, die das RPA-Programm steuert. Es muss nicht groß sein – im Mittelstand reichen oft wenige Personen oder sogar eine geteilte Rolle – aber es muss klare Verantwortlichkeiten bündeln. Das CoE entscheidet, welche Prozesse automatisiert werden, setzt technische und organisatorische Standards, betreibt und überwacht die produktiven Bots und sorgt dafür, dass Wissen nicht an Einzelpersonen hängt. Ohne diese Klammer entsteht in der Praxis fast zwangsläufig Wildwuchs: einzelne Abteilungen bauen eigene Bots, niemand kennt den Gesamtbestand, und bei Störungen weiß keiner, wer zuständig ist.
Die wichtigste Aufgabe des CoE ist die disziplinierte Auswahl und Priorisierung der Automatisierungskandidaten. Nicht jeder Prozess, der sich technisch automatisieren lässt, sollte auch automatisiert werden. Das CoE bewertet Kandidaten anhand klarer Kriterien: Volumen, Stabilität der Zielsysteme, Regelhaftigkeit, erwarteter Nutzen und Wartungsaufwand. Hier zahlt sich das Zusammenspiel mit Process Mining aus – die Analyse liefert die objektive Grundlage dafür, welche Prozesse den größten Hebel bieten. Ein entscheidender Grundsatz: Vor jeder Automatisierung steht die Standardisierung. Einen schlechten, umständlichen Prozess zu automatisieren, zementiert lediglich seine Ineffizienz. Erst vereinfachen, dann automatisieren.
Produktive Bots sind kein Selbstläufer. Das CoE verantwortet den laufenden Betrieb: Es überwacht, ob die Bots planmäßig laufen, reagiert auf Störungen, pflegt die zentrale Verwaltung der Zugangsdaten und hält den Bestand aktuell. Ein durchdachtes Monitoring ist dabei entscheidend – es muss frühzeitig erkennbar sein, wenn ein Bot bricht oder auffällig häufig in Ausnahmen läuft, idealerweise bevor ein Fachbereich den Ausfall bemerkt. Ebenso wichtig ist das Management des Lebenszyklus: Bots, die nicht mehr gebraucht werden, müssen geordnet stillgelegt und ihre Berechtigungen entzogen werden. Verwaiste Bots mit aktiven Zugriffsrechten sind ein erhebliches Sicherheits- und Compliance-Risiko.
Anders als ein KI-Dienst in der Cloud verarbeitet ein RPA-Bot in der Regel keine Daten an einen externen Anbieter, sondern bewegt sie innerhalb der bestehenden Systemlandschaft. Das ist datenschutzrechtlich grundsätzlich günstig – die Daten verlassen die gewohnte Umgebung nicht zwangsläufig. Die eigentlichen Risiken liegen woanders: bei den Zugriffsrechten der Bots, beim Verarbeitungsort der Plattform und bei der Nachvollziehbarkeit dessen, was ein Bot mit personenbezogenen Daten tut.
Ein Bot braucht ein eigenes Konto mit Zugriffsrechten auf die Systeme, die er bedient. Der häufigste und gefährlichste Fehler ist, diesem Konto aus Bequemlichkeit zu weitreichende Rechte zu geben – etwa ein Administrator-Konto, „damit der Bot sicher überall hinkommt“. Damit entsteht ein hochprivilegiertes, automatisiert agierendes Konto, das ein erhebliches Angriffs- und Missbrauchsrisiko darstellt. Der Grundsatz lautet: minimale Rechte, maximale Nachvollziehbarkeit. Jeder Bot erhält genau die Berechtigungen, die er für seine Aufgabe braucht – nicht mehr. Seine Aktivitäten werden protokolliert, und sein Konto wird bei Stilllegung des Bots ebenso konsequent deaktiviert wie ein menschliches Mitarbeiterkonto beim Austritt.
Ob und wo personenbezogene Daten die eigene Umgebung verlassen, hängt stark vom gewählten Betriebsmodell ab. Läuft die RPA-Plattform vollständig im eigenen Rechenzentrum, bleibt die Datenverarbeitung in eigener Hand. Wird eine Cloud-Variante genutzt, ist zu klären, in welcher Region die Daten verarbeitet werden und welche vertraglichen Grundlagen gelten – inklusive eines Auftragsverarbeitungsvertrags und gegebenenfalls einer Bewertung möglicher Drittlandtransfers. Diese Fragen sollten vor der Tool-Entscheidung beantwortet werden, weil sie je nach Datenschutzanforderung des Unternehmens die Auswahl bereits einschränken können.
Richtig aufgesetzt ist RPA aus Datenschutzsicht gut beherrschbar: minimale Bot-Rechte, lückenlose Protokollierung, geklärter Verarbeitungsort und ein sauberes Lebenszyklus-Management der Bot-Konten bilden einen soliden Rahmen. Die organisatorische Disziplin des Center of Excellence aus dem vorigen Kapitel ist dabei keine Bürokratie, sondern genau das Instrument, mit dem diese Sicherheits- und Datenschutzanforderungen dauerhaft eingehalten werden.
