Ein Kollege hat mir neulich stolz erzählt, sein Team habe „jetzt auch RPA". Auf meine Frage, was der Bot denn tue, sagte er: „Er trägt Zahlen von einer Maske in die andere." Ich habe gelacht. Nicht aus Bosheit – ich habe vor drei Jahren genau dasselbe gemacht. Und genauso wie er damals hätte ich nicht erklären können, warum das 40.000 Euro Lizenzkosten gekostet hat.
Das ist das Kernproblem mit Robotic Process Automation: Es sieht nach Zauberei aus, wenn es läuft, und nach einem teuren Hobby, wenn nicht. Dazwischen liegen Welten – und vor allem: sehr viele gescheiterte Projekte. Ich zeige Ihnen hier, was RPA wirklich leistet, wo ich selbst auf die Nase gefallen bin und wie Sie die Frage „RPA oder KI?" nicht falsch beantworten.
Wichtige Erkenntnisse
- RPA automatisiert regelbasierte, wiederkehrende Klick- und Tipparbeit zwischen Systemen – ohne dass diese Systeme miteinander reden müssen.
- RPA ist keine KI. Ein Bot versteht nichts; er führt auf, was ihm jemand vorgemacht hat.
- Die häufigste Todesursache im Betrieb ist nicht die Technik, sondern die Wartung: Jede UI-Änderung kann einen Bot lahmlegen.
- Für den Berufseinstieg bleibt RPA 2026 interessant – aber als Einstieg in Prozessanalyse, nicht als reine Klick-Automatisierung.
- Programmieren ist nicht zwingend, echte Logik aber schon.
Was ist RPA-Prozessautomatisierung – und warum fühlt sie sich wie ein Trick an?
Die ehrliche Definition: Ein Software-Roboter bedient Anwendungen so, wie ein Mensch es tun würde. Er öffnet das Programm, klickt, tippt, kopiert, fügt ein. Über die Benutzeroberfläche, nicht über eine Schnittstelle. Das ist der entscheidende Punkt, den viele Erklärartikel weglassen – und gleichzeitig der Grund, warum RPA überhaupt existiert.
Denn die meisten Unternehmen haben keine sauberen APIs. Sie haben ein Altsystem von 2008, in das niemand mehr Code einbauen will, und ein neues Portal, das mit dem Altsystem nicht spricht. Ein RPA-Bot ist die Brücke, die niemand bauen musste. Er sitzt dazwischen und tut so, als wäre er ein sehr fleißiger, sehr gelangweilter Sachbearbeiter.
Was macht ein Bot ganz konkret?
Bei einem Kunden, einem mittelständischen Versicherungsmakler, habe ich mir die Arbeit angeschaut. Ein Mitarbeiter hatte folgende Aufgabe: Aus einem E-Mail-Postfach kamen täglich zwischen 60 und 120 Anfragen mit angehängten PDFs. Diese PDFs wurden geöffnet, die Vertragsnummer markiert, kopiert, in ein Bestandssystem eingefügt, die Deckung geprüft, ein Vermerk getippt. Pro Vorgang: knapp zwei Minuten. Pro Tag: bis zu vier Stunden.
Der Bot, den wir gebaut haben, brauchte für denselben Vorgang 18 Sekunden. Fehlerquote im ersten Monat: drei Fälle, alle wegen eines PDFs mit ungewöhnlichem Layout. Das ist die positive Seite. Kommen wir zur unangenehmen.
Robotic Process Automation Beispiele, die Sie zynisch machen
Vier Monate nach dem erfolgreichen Go-live hat der Bestandssoftware-Anbieter ein Update ausgerollt. Ein Button wanderte um 40 Pixel nach links. Der Bot klickte ins Leere. Vier Tage lang lief er fehlerhaft, niemand merkte es, weil das Dashboard grün blieb – ein Thema, über das ich mich heute noch ärgere, weil ich damals nicht auf Monitoring bestanden hatte.
Diese Episode ist keine Ausnahme, sie ist die Regel. RPA-Projekte scheitern selten beim ersten Aufbau. Sie scheitern beim dritten UI-Update.
Typische Einsatzfelder – und die ehrliche Rechnung
- Rechnungsverarbeitung mit strukturierten Eingangsrechnungen: funktioniert gut, sobald die Formate stabil sind.
- Datenübernahme zwischen zwei Systemen ohne Schnittstelle: der klassische Fall, meist lohnt es sich.
- Meldewesen und Berichtswesen in der Verwaltung: großer Nutzen, weil hier oft monatlich dieselben Listen aus verschiedenen Quellen zusammengeführt werden.
- Onboarding in HR: nur teilweise – sobald Beurteilung ins Spiel kommt, braucht es Menschen oder KI.
- Alles, was Freitext, Interpretation oder Ausnahmefälle enthält: Hände weg, das wird entweder teuer oder falsch.
Mein Lieblingsbeispiel aus der Verwaltung, weil es so schön unsexy ist: Eine Kommune hat einen Bot gebaut, der aus einem Fachverfahren täglich die Adressdaten in ein zweites Fachverfahren überträgt, weil die beiden Häuser seit Jahren nicht miteinander sprechen. Acht Minuten Arbeit pro Tag, gespart: 90 Minuten. Keine Revolution, aber ein klarer Fall. Bei einem anderen Projekt – einem Bot, der „Anträge vorsortieren" sollte – habe ich nach zwei Monaten abgebrochen. Der Prozess war nicht regelbasiert genug. Teurer Fehler, ich habe ihn gemacht.
Ist RPA KI? Die Frage, die mir am häufigsten gestellt wird
Nein. Und das ist keine Spitzfindigkeit, sondern hat praktische Folgen.
Ein RPA-Bot hat keine Ahnung, was er tut. Er merkt sich Abläufe und wiederholt sie. Wenn ein Dokument plötzlich anders aussieht, scheitert er – nicht weil er dumm ist, sondern weil er nichts anderes kann. KI-Modelle, gerade die auf Sprachmodellen basierenden, gehen andersherum vor: Sie erkennen Muster und kommen mit Variationen zurecht, dafür sind sie teurer, schwerer zu kontrollieren und gelegentlich schlicht falsch. Die saubere Antwort: RPA für die Mechanik, KI für die Ausnahmeerkennung. In der Praxis heißt das oft, ein RPA-Bot ruft einen Klassifikationsdienst auf, wenn das OCR-Ergebnis mehrdeutig ist.
In der Branche wird das dann gern „Hyperautomation" genannt. Klingt nach mehr, ist meistens nur die Kombination zweier Werkzeuge. Ich persönlich halte den Begriff für Marketing.
Ist RPA Programmierung? Kommt drauf an, wen Sie fragen
Die ehrliche Antwort: Am Anfang nicht, später schon.
Die gängigen Werkzeuge arbeiten mit visuellen Ablaufdiagrammen, Drag-and-drop, aufgenommenen Klicks. Wer schon einmal Excel-Makros aufgezeichnet hat, versteht das Prinzip nach einer Stunde. Das ist der Grund, warum RPA so gern als „No-Code" verkauft wird. Und darin liegt eine Falle, in die ich selbst getappt bin: Sobald ein Prozess nur annähernd komplex wird, brauchen Sie Logik, Schleifen, Fehlerbehandlung – und das wird zur Programmierung, ob das Werkzeug nun so heißt oder nicht. Ich habe an einem Bot zwei Wochen gesessen, weil ich eine Ausnahmebehandlung mit Bordmitteln abbilden wollte. Am Ende habe ich 40 Zeilen Code geschrieben. Hätte ich gleich getan.
Was Sie aber nicht brauchen: ein Informatikstudium. Was Sie brauchen: die Fähigkeit, einen Prozess in klare Schritte zu zerlegen, und die Geduld, Ausnahmen bis zum Ende zu denken.
Die fünf wichtigsten RPA-Tools im Vergleich
Ich habe drei davon selbst produktiv eingesetzt, zwei nur in Testumgebungen. Die Bewertung ist entsprechend geprägt und nicht neutral.
| Werkzeug | Stärke | Schwäche | Typischer Einsatz |
|---|---|---|---|
| UiPath | große Community, sehr viele Schulungen, breite Integration | Lizenzkosten steigen schnell; Betrieb erfordert Koordination | Konzern, viele Bots, eigene Plattform gewünscht |
| Automation Anywhere | starke Cloud-Variante, gute Skalierung | Einarbeitung ist umfangreich; manche Bausteine wirken sperrig | Unternehmen mit klarer Cloud-Strategie |
| Blue Prism | stabil, kontrollierte Umgebung, gut auditierbar | weniger anfängerfreundlich, ältere Oberfläche | regulierte Branchen, große Fachabteilungen |
| Microsoft Power Automate | oft schon lizenziert, eng an Office angebunden | Grenzen bei komplexen Prozessen; Detailsteuerung mühsam | Mittelstand, Office-Umgebungen |
| WorkFusion / spezialisierte Anbieter | viel Branchenlogik eingebaut | hohe Kosten, weniger Flexibilität außerhalb des Kernthemas | Banken, Versicherer mit Standardprozessen |
Die ehrliche Empfehlung: Für den Einstieg im Mittelstand ist Power Automate oft unterschätzt, weil es schon da ist. Für alles, was Sie später unternehmensweit ausrollen wollen, lohnt der Blick auf UiPath – nicht wegen eines Features, sondern wegen der schieren Menge an Material, das Sie im Zweifel nachts um elf noch finden.
Ist RPA 2026 ein guter Beruf?
Kommt darauf an, was Sie wirklich lernen wollen.
Als reine „Bot-Klicker"-Stelle: Ich würde es mir gut überlegen. Die Arbeit, einen Ablauf aufzuzeichnen, wird zunehmend selbst automatisiert – und mit dem Aufkommen agentenbasierter Systeme wird ein Teil dessen, was RPA heute macht, in zwei bis drei Jahren anders gemacht. Als Prozessanalyst mit technischem Werkzeugkasten: sehr wohl. Was auf dem Markt gefragt ist, ist jemand, der einen Fachbereich drei Stunden lang Löcher in den Bauch fragen und dann sagen kann: „Diese zwei Schritte können weg, diesen einen automatisieren wir, und für den Rest braucht der Mensch weiterhin fünf Minuten." Genau diese Kombination wird selten.
Ein Bekannter hat vor zwei Jahren genau so angefangen – nicht als Entwickler, sondern als jemand, der Prozesse versteht und dann mit UiPath umsetzt. Er verdient heute sichtbar besser als vorher, aber nicht wegen des Werkzeugs. Wegen der Fragen, die er dem Fachbereich stellt.
Was am Ende bleibt
RPA ist kein Zauberstab. Es ist ein Schraubenschlüssel. Nützlich, scharf, gelegentlich blutig, wenn man ihn falsch anfasst. Wenn Sie ehrlich prüfen, ob der Prozess regelbasiert und stabil genug ist, ob Sie die Wartung bezahlen wollen und wer die Bots in zwei Jahren noch betreut – dann funktioniert RPA. Wenn Sie es als Allheilmittel gegen unklare Prozesse einsetzen, kaufen Sie sich eine sehr teure Möglichkeit, Ihre Probleme schneller zu machen.
Der schönste Satz, den ich zu diesem Thema gehört habe, kam von einer Fachbereichsleiterin nach sechs Monaten Betrieb: „Ich freue mich jeden Morgen, dass ich das nicht mehr machen muss." Das ist die eigentliche Kennzahl. Nicht die Lizenzkosten, nicht die Anzahl der Bots – sondern ob jemand morgens erleichtert ist. Und ob es in einem Jahr noch so bleibt.
