Robotic Process Automation oder Schnittstelle: was länger hält

Robotic Process Automation hat einen schlechten Ruf bei Entwicklern und einen guten bei denen, die Abläufe verantworten. Beide haben recht, nur reden sie über verschiedene Situationen. Wer ohne eigene Entwicklungsabteilung über einen Ablauf entscheiden muss, braucht deshalb keine Glaubensfrage, sondern eine nachvollziehbare Reihenfolge, die sich auch später noch begründen lässt.

Der Unterschied in einem Satz

Eine Schnittstelle spricht ein Programm direkt an: Sie übergibt Daten an die dafür vorgesehene Stelle und bekommt eine Antwort, unabhängig davon, wie der Bildschirm gerade aussieht. Robotic Process Automation bedient stattdessen die Oberfläche nach – sie klickt, tippt und liest an denselben Stellen, an denen sonst ein Mensch arbeitet.

Daraus folgt alles Weitere. Die Schnittstelle ist an die Logik des Programms gebunden, der Roboter an sein Aussehen. Logik ändert sich selten und angekündigt, Aussehen oft und beiläufig.

Wo Robotic Process Automation bricht

Die häufigste Bruchstelle ist das Update. Eine Schaltfläche wandert um zwanzig Pixel, ein Feld bekommt eine zusätzliche Bestätigung, eine Tabellenspalte wechselt die Position – der Roboter greift ins Leere. Im besten Fall bleibt er stehen, im schlechteren trägt er Werte in das falsche Feld ein.

Die zweite Bruchstelle ist das Konto. Roboter laufen oft unter den Zugangsdaten eines Mitarbeiters, weil es schneller ging. Scheidet die Person aus oder läuft ihr Kennwort ab, steht der Ablauf – und in den Protokollen des Zielsystems steht der Name eines Menschen, der nichts getan hat.

Die dritte Bruchstelle ist das Tempo. Ein Roboter arbeitet in der Geschwindigkeit der Oberfläche: Er wartet auf jede Maske, jede Bestätigung, jeden Seitenwechsel. Was eine Schnittstelle in einem Aufruf erledigt, dauert am Bildschirm ein Vielfaches, und der Abstand wächst mit der Menge der Vorgänge. Bei ein paar Dutzend Vorgängen am Tag fällt das nicht auf, bei ein paar tausend bestimmt es, ob der Lauf über Nacht fertig wird.

Die vierte Bruchstelle ist die Menge. Ein Roboter, der eine Maske bedient, arbeitet streng nacheinander: Zwei Vorgänge gleichzeitig gibt es nicht, und ein Fehler in der Mitte lässt den Rest des Stapels liegen. Wächst das Aufkommen, wächst die Laufzeit mit — bis der nächtliche Lauf in den Vormittag reicht und jemand morgens entscheiden muss, ob er ihn abbricht.

Wann der Roboter trotzdem die richtige Wahl ist

Wenn es keine Schnittstelle gibt und auch keinen Datenzugang – bei älteren Branchenprogrammen ist das der Normalfall. Wenn der Hersteller eine Schnittstelle nur in einer teureren Ausbaustufe anbietet und der Ablauf diesen Aufwand nicht trägt. Oder wenn ein Programm in absehbarer Zeit ohnehin abgelöst wird und sich eine saubere Anbindung nicht mehr lohnt.

In diesen Fällen ist der Roboter keine schlechte Entscheidung, sondern eine bewusste Zwischenlösung. Wichtig ist, dass sie als solche im Protokoll steht und nicht als Dauerzustand vergessen wird. Was beim Nachbedienen einer Oberfläche technisch passiert und woran es typischerweise scheitert, steht ausführlich unter Oberflächenautomatisierung.

Die Prüfung, die Robotic Process Automation braucht

Ein Roboter ohne Kontrolle ist der eigentliche Fehler, nicht der Roboter selbst. Was dazugehört: ein Abgleich jedes übertragenen Datensatzes gegen die Quelle, eine Meldung an eine benannte Rolle bei jeder Abweichung, ein technisches Konto auf den Namen des Unternehmens und ein Protokoll, das festhält, welcher Vorgang wann bearbeitet wurde.

Damit verliert der Ausfall seinen Schrecken: Er wird bemerkt, bevor falsche Daten weiterwandern, und er lässt sich von Hand überbrücken.

Dazu gehört auch die unbequeme Prüfung, die am Anfang steht: Läuft der Roboter unter den Zugangsdaten eines Menschen, gehört das Konto vor allem anderen in Ordnung gebracht. Solange im Zielsystem der Name eines Mitarbeiters unter Buchungen steht, die eine Maschine erzeugt hat, ist weder die Protokollierung brauchbar noch die Frage zu beantworten, wer etwas veranlasst hat.

Eine Reihenfolge statt einer Glaubensfrage

In der Praxis hat sich diese Reihenfolge bewährt: Zuerst prüfen, ob eine Regel im Zielsystem den Schritt ganz erübrigt. Dann prüfen, ob es eine Schnittstelle oder einen Datenzugang gibt. Erst danach der Roboter, mit Abgleich. Und für alles, was selten vorkommt oder Urteil verlangt, bleibt der Mensch zuständig – das ist keine Niederlage der Automatisierung, sondern ihre Voraussetzung.

Diese Reihenfolge lässt sich auch ohne eigene Entwickler anwenden. Sie verlangt nur, dass jemand für jeden Schritt aufschreibt, was ihn trägt und warum. Wenn dafür im Haus niemand frei ist, übernehmen wir den vorhandenen Bestand als Auftrag: RPA-Software und Makros übernehmen heißt bei uns aufnehmen, entscheiden, im Schattenlauf prüfen und mit Beschreibung übergeben.