News

RPA: Wann Software-Roboter im KMU taugen

· DigifyNow

RPA (Robotic Process Automation) ist Software, die eine Anwendung über die Bedienoberfläche steuert, so wie es ein Mensch tun würde. Sie findet Felder über Selektoren oder Bilderkennung, liest Werte aus, tippt und klickt nach festen Regeln. Das lohnt sich bei stabilen, regelbasierten Abläufen in Altsystemen ohne Schnittstelle. Ändert sich die Maske, greift eine Mehr-Faktor-Anmeldung oder tauchen Ausnahmen auf, bricht der Bot ab. Hat das System eine API, ist sie die robustere Wahl.

Was ist RPA und wie arbeitet ein Software-Roboter?

RPA steht für Robotic Process Automation. Gemeint ist kein Roboterarm, sondern ein Programm, das eine Anwendung über ihre Bedienoberfläche steuert, also genau dort, wo sonst jemand aus dem Team klickt. Der Bot öffnet zum Beispiel die Warenwirtschaft, sucht das Feld „Kundennummer“, trägt einen Wert ein und liest das Ergebnis ab. Das richtige Feld findet er über Selektoren. In Webanwendungen sind das CSS- oder XPath-Ausdrücke, die auf den HTML-Aufbau der Seite zeigen. In Windows-Programmen ist es der Baum der Bedienelemente, den Microsoft über die Barrierefreiheits-Schnittstelle UI Automation bereitstellt. Läuft die Anwendung nur über Citrix oder Remote Desktop, sieht der Bot bloß ein Bild. Dann muss er mit Bildvergleich und Texterkennung (OCR) arbeiten, und das ist die anfälligste Variante. Es gibt zwei Betriebsarten: Attended-Bots laufen auf dem Rechner eines Mitarbeiters und werden von ihm gestartet. Unattended-Bots laufen ohne Aufsicht auf einem eigenen Server oder einer virtuellen Maschine, meist nach Zeitplan. Für Entscheider ist eines wichtig: RPA verändert die beteiligten Systeme nicht. Der Bot ist eine Schicht obendrauf. Deshalb kommt man schnell rein. Es heißt aber auch, dass jede Änderung an der Oberfläche den Bot treffen kann.

Illustration zur Frage „Was ist RPA und wie arbeitet ein Software-Roboter?“
KI-generiertes Bild

Was gehört zu einer RPA-Software dazu?

Eine RPA-Software besteht fast immer aus mehr als dem eigentlichen Bot. Wer Angebote vergleicht oder eine eigene Lösung plant, sollte nach diesen fünf Bausteinen fragen:

  • Designer oder Recorder: Hier wird der Ablauf aufgezeichnet oder als Flussdiagramm gebaut. Aufzeichnungen erzeugen oft starre Selektoren, die man von Hand robuster machen muss.
  • Laufzeitumgebung: Sie führt den Bot aus. Bei Desktop-Anwendungen braucht sie eine angemeldete, nicht gesperrte Windows-Sitzung. Ist der Bildschirm gesperrt, gibt es keine Oberfläche, die der Bot bedienen kann.
  • Orchestrierung: Zeitpläne, Warteschlangen für Vorgänge und Wiederholungsregeln, falls ein Schritt fehlschlägt.
  • Verwaltung der Zugangsdaten: Die Passwörter des Bot-Kontos liegen verschlüsselt in einem Tresor und nicht im Klartext im Ablauf.
  • Protokollierung: Jeder Schritt wird mit Zeitstempel festgehalten, im Fehlerfall zusätzlich mit einem Bildschirmfoto.

Ein Punkt geht bei der Einführung gern unter: Der Bot braucht im Zielsystem ein eigenes technisches Benutzerkonto. Läuft er unter dem Konto eines Mitarbeiters, kann später niemand mehr sagen, ob eine Buchung von einem Menschen oder vom Bot stammt. Bei buchungsrelevanten Vorgängen verlangen die GoBD aber genau diese Nachvollziehbarkeit. Außerdem lizenzieren viele Softwarehersteller pro benanntem Benutzer, sodass ein Bot-Konto eine zusätzliche Lizenz im Zielsystem kosten kann.

Welche RPA-Tools gibt es und welches passt zu einem KMU?

RPA-Tools lassen sich grob in drei Gruppen einteilen. Sie unterscheiden sich weniger im Funktionsumfang als darin, wie sie im Alltag betrieben werden. Die erste Gruppe sind Desktop-Werkzeuge, die oft schon in Büropaketen stecken und mit denen Mitarbeiter ihre eigenen Abläufe aufzeichnen. Der Einstieg ist leicht. Dafür liegen die Bots dann verstreut auf einzelnen Rechnern, und wenn der Kollege das Unternehmen verlässt, weiß niemand mehr, was sein Ablauf eigentlich macht. Die zweite Gruppe sind Enterprise-Plattformen mit zentralem Orchestrator, eigenen Bot-Servern und Rollenmodell. Sie sind für Dutzende Prozesse gebaut. Bei zwei oder drei Abläufen in einem KMU ist der Aufwand für den Betrieb meist größer als die Arbeit, die der Bot abnimmt. Die dritte Gruppe ist Automatisierung im Code: Browser-Steuerung mit Open-Source-Bibliotheken wie Playwright oder Selenium, kombiniert mit direkten API-Aufrufen. So arbeitet DigifyNow. Wir prüfen zuerst, ob das Zielsystem eine Schnittstelle hat, etwa eine REST-API, einen Datenbankzugriff, einen CSV-Import oder Webhooks. Nur den Teil, für den es keine Schnittstelle gibt, steuern wir über die Oberfläche. Der Code liegt versioniert in Git, die Selektoren sind an einer Stelle gebündelt, und wenn etwas fehlschlägt, geht eine Meldung raus, statt dass der Vorgang still liegen bleibt. Bei der Auswahl zählt deshalb eine Frage mehr als jede Funktionsliste: Wer kümmert sich in zwei Jahren um den Bot, wenn sich die Oberfläche geändert hat?

Illustration zur Frage „Welche RPA-Tools gibt es und welches passt zu einem KMU?“
KI-generiertes Bild

Welche RPA-Beispiele funktionieren im Mittelstand?

Die RPA-Beispiele, die im Alltag halten, folgen festen Regeln, haben wenige Ausnahmen und laufen auf einer Oberfläche, die sich selten ändert. Typische Fälle aus der Projektpraxis:

  • Aufträge aus einem Kundenportal abholen: Der Bot meldet sich an, lädt die Exportdatei herunter und spielt sie ins ERP ein. Das geht nur, wenn das Portal keine Push-Bestätigung auf dem Handy verlangt.
  • Stammdaten zwischen zwei Altsystemen abgleichen, zum Beispiel Artikelpreise aus der Warenwirtschaft in ein Branchenprogramm übertragen, das keine Importfunktion hat.
  • Status bei Lieferanten- oder Behördenportalen abfragen, etwa Sendungsverfolgung oder Bearbeitungsstand, einmal pro Nacht und mit einer Liste der Abweichungen am Morgen.
  • Monatsberichte zusammenstellen: Werte aus mehreren Masken in eine Excel-Vorlage übertragen und als PDF im richtigen Ordner ablegen.
  • Rechnungseingang: Früher ein Paradebeispiel für Texterkennung auf PDFs. Seit dem 1. Januar 2025 müssen Unternehmen in Deutschland aber E-Rechnungen im Format XRechnung oder ZUGFeRD ab Version 2.0.1 empfangen können. Diese Rechnungen enthalten strukturierte XML-Daten nach EN 16931, die man direkt auslesen kann. Ein Bot mit OCR ist dafür nur noch ein Umweg.

Wenn ein Vorgang mit Freitext arbeitet, etwa Kundenanfragen per E-Mail, stößt klassische RPA an ihre Grenzen. Solche Fälle sind eher Aufgaben für Sprachmodelle. Wie das aussieht, zeigen die KI-Agenten Beispiele aus dem KMU.

Wann funktioniert RPA nicht?

Ein Bot scheitert selten am Ablauf selbst, sondern meist an seiner Umgebung. Diese Fehlerbilder sehen wir am häufigsten, jeweils mit Ursache:

  • Oberflächen-Update: Der Hersteller verschiebt ein Feld oder ändert dessen Kennung, und der Selektor findet nichts mehr. Besonders betroffen sind Webanwendungen, die ihre Element-IDs bei jedem Laden neu erzeugen.
  • Mehr-Faktor-Anmeldung: Eine Push-Bestätigung auf dem Handy kann ein Bot nicht geben. Einmal-Codes nach RFC 6238, die alle 30 Sekunden wechseln, lassen sich technisch erzeugen. Dann liegt aber auch das zweite Geheimnis beim Bot, und der zweite Faktor schützt faktisch nichts mehr.
  • Captchas: Sie sind genau dafür gebaut, Automatisierung zu erkennen. Wer sie umgeht, verstößt oft gegen die Nutzungsbedingungen des Portals.
  • Bildschirmskalierung: Bei Bilderkennung über Citrix reicht es schon, wenn die Windows-Skalierung von 100 auf 125 Prozent umgestellt wird, und die Vorlagen passen nicht mehr.
  • Unerwartete Dialoge: Ein Update-Hinweis, ein Cookie-Banner oder eine Meldung, dass das Passwort abläuft, blockiert den Ablauf.
  • Viele Ausnahmen: Wenn häufig ein Mensch entscheiden muss, landet am Ende ein großer Teil der Fälle doch wieder auf dem Schreibtisch.

Dazu kommt ein Punkt, der nichts mit der Technik zu tun hat: Wer einen umständlichen Ablauf automatisiert, hat danach einen schnellen umständlichen Ablauf. Eine saubere Prozessanalyse vor dem ersten Bot zeigt, welche Schritte man streichen kann, statt sie zu automatisieren.

Illustration zur Frage „Wann funktioniert RPA nicht?“
KI-generiertes Bild

RPA, Schnittstelle oder KI: Was passt zu welchem Ablauf?

RPA ist ein Werkzeug unter mehreren. Welches passt, hängt vor allem davon ab, ob die Daten strukturiert sind und ob das System eine Schnittstelle anbietet.

Vier Wege, einen Ablauf zu automatisieren, und wo sie jeweils an ihre Grenzen stoßen
AnsatzWie er arbeitetPasst, wennSchwachstelle
API-IntegrationSysteme tauschen Daten direkt über REST-Schnittstellen oder Webhooks aus, ohne OberflächeBeide Systeme haben eine dokumentierte SchnittstelleAbhängig von der API-Version und von Nutzungslimits des Anbieters
RPABot bedient die Bedienoberfläche über Selektoren oder BilderkennungAltsystem ohne Schnittstelle, feste Regeln, stabile MaskenBricht bei Oberflächenänderungen, Mehr-Faktor-Anmeldung und Pop-ups
KI-Assistent oder AgentSprachmodell liest Freitext, klassifiziert und ruft definierte Werkzeuge aufUnstrukturierte Eingaben wie E-Mails oder DokumenteErgebnisse können falsch sein, deshalb sind Freigaben nötig
Individuelle SoftwareNeues System ersetzt den Medienbruch komplettDer Ablauf ist Kerngeschäft und soll langfristig laufenHöherer Aufwand am Anfang, Wartung über Jahre

In der Praxis kombiniert DigifyNow die Ansätze oft. Eine KI liest zum Beispiel eine Bestellung aus einer E-Mail, ein Mensch gibt sie frei, und der Eintrag ins System läuft über die API. Nur wenn keine API existiert, übernimmt ein Bot diesen letzten Schritt. Mehr zur Auswahl steht im Beitrag darüber, welche Prozesse sich im KMU automatisieren lassen.

Wie startet man ein RPA-Projekt im KMU?

Am Anfang steht nicht das Werkzeug, sondern ein einzelner, klar abgegrenzter Ablauf. So gehen wir bei DigifyNow vor:

  1. Ablauf aufnehmen: jeden Klick, jede Maske, jede Ausnahme, dazu wie oft der Vorgang pro Woche vorkommt und wie lange er von Hand dauert.
  2. Schnittstellen prüfen: API-Dokumentation, Importfunktionen und Datenbankzugriff beim Hersteller erfragen. Erst was übrig bleibt, ist ein Fall für RPA.
  3. Einen Proof of Concept mit fester Timebox bauen: ein Ablauf, echte Testdaten und vorher festgelegte Kriterien, wann man abbricht.
  4. Bot-Konto einrichten: eigener technischer Benutzer, nur die Rechte, die der Ablauf braucht, Passwort im Tresor.
  5. Betrieb regeln: einen Verantwortlichen benennen, Fehlermeldungen an eine feste Adresse schicken und Software-Updates der Zielsysteme vorher ankündigen lassen.

Wie der Testlauf aufgebaut ist und woran man erkennt, dass er gescheitert ist, erklärt der Beitrag zu Ablauf und Kriterien eines Proof of Concept. Und noch ein Hinweis: Wenn ein Attended-Bot auf Arbeitsplatzrechnern läuft und dabei protokolliert, was Mitarbeiter tun, hat ein vorhandener Betriebsrat nach § 87 Abs. 1 Nr. 6 BetrVG ein Mitbestimmungsrecht. Den Betriebsrat sollte man deshalb früh einbinden und nicht erst kurz vor dem Start.

Illustration zur Frage „Wie startet man ein RPA-Projekt im KMU?“
KI-generiertes Bild

Häufige Fragen

Was ist der Unterschied zwischen RPA und KI?

RPA führt feste Regeln aus: Klicke hier, kopiere dieses Feld, trage es dort ein. Ein KI-Modell dagegen interpretiert Eingaben wie Freitext oder Bilder und liefert Ergebnisse, die mit einer gewissen Wahrscheinlichkeit stimmen. RPA ist dadurch vorhersehbar, kann aber mit unstrukturierten Daten nichts anfangen. KI kann das, braucht aber Freigaben, weil sie sich irren kann.

Was ist ein Attended- und ein Unattended-Bot?

Ein Attended-Bot läuft auf dem Rechner eines Mitarbeiters und wird von ihm gestartet, zum Beispiel per Knopfdruck während eines Kundentelefonats. Ein Unattended-Bot läuft ohne Aufsicht auf einem Server oder einer virtuellen Maschine, meist nach Zeitplan, etwa nachts. Für Unattended-Betrieb braucht man eine dauerhaft angemeldete Windows-Sitzung und ein eigenes Bot-Konto.

Braucht ein RPA-Bot einen eigenen Rechner?

Für Desktop-Anwendungen braucht er eine eigene Windows-Sitzung, die nicht gesperrt ist. Das ist in der Regel eine virtuelle Maschine. Teilt er sich die Sitzung mit einem Menschen, kommen sich beide bei Maus und Tastatur in die Quere. Reine Browser-Automatisierung kann dagegen ohne sichtbaren Bildschirm laufen, im sogenannten Headless-Modus auf einem Server.

Ist RPA dasselbe wie ein Excel-Makro?

Nein. Ein VBA-Makro automatisiert Schritte innerhalb einer Office-Anwendung und nutzt deren interne Befehle. RPA arbeitet anwendungsübergreifend über die Bedienoberfläche, also zum Beispiel vom Webportal ins ERP und dann in Excel. Makros sind für Aufgaben innerhalb einer Datei robuster. RPA ist das Werkzeug, wenn mehrere Programme ohne gemeinsame Schnittstelle beteiligt sind.

Kostenlose Einschätzung für Ihr Projekt anfragen