RPA: Robotic Process Automation an der Oberfläche

RPA (Robotic Process Automation) bezeichnet Software, die wiederkehrende Arbeit an der Bedienoberfläche anderer Programme erledigt: Sie liest Felder aus, trägt Werte ein, klickt Schaltflächen und speichert. Ein solcher Softwareroboter braucht keinen Zugang zum Innenleben der Systeme, sondern bedient sie wie ein Mensch am Bildschirm.

Was RPA technisch ist

Ein Bot besteht aus einer Abfolge von Anweisungen, die meist in einem grafischen Editor zusammengestellt oder mit einem Rekorder aufgezeichnet werden. Damit er ein Feld wiederfindet, orientiert er sich an Merkmalen des Bedienelements: an seiner internen Kennung, seiner Beschriftung oder seiner Lage im Fenster. Bei Webanwendungen liest er die Seitenstruktur, bei klassischen Windows-Programmen die Schnittstellen des Betriebssystems für Bedienhilfen. In Terminal- und Remote-Desktop-Sitzungen bleibt oft nur die Bilderkennung.

Man unterscheidet zwei Betriebsarten. Der begleitete Bot läuft auf dem Rechner eines Mitarbeiters und wird von ihm gestartet, etwa um einen neuen Kunden in drei Programmen gleichzeitig anzulegen. Der unbegleitete Bot läuft auf einem eigenen Rechner oder virtuellen Server nach Zeitplan oder Auslöser und arbeitet eine Warteschlange ab, zum Beispiel alle über Nacht eingegangenen Aufträge. Im Fachjargon heißen die beiden Varianten attended und unattended.

Wann RPA die richtige Wahl ist

Die Stärke der Oberflächenautomatisierung liegt dort, wo kein anderer Zugang existiert. Typische Ausgangslagen:

• Ein Altsystem hat keine Programmierschnittstelle, und der Hersteller liefert keine mehr nach.
• Das Portal eines Kunden, Lieferanten oder einer Behörde bietet nur eine Weboberfläche an.
• Ein System wird absehbar abgelöst, und eine Schnittstelle für die Übergangszeit lohnt den Aufwand nicht.
• Die Arbeit ist vollständig regelbasiert, die Eingaben liegen strukturiert vor, und die Oberfläche ändert sich selten.

Auf dem Weg von der Anfrage zur Zahlung betrifft das meist einzelne Übergaben: Auftragsdaten müssen in ein Branchenprogramm ohne Import, Lieferscheine in ein Kundenportal, Zahlungsinformationen aus einem Portal in die Buchhaltung. Welche Übergaben das in einem Unternehmen sind, zeigt eine Prozessanalyse. Für solche Stellen ist ein Bot eine brauchbare Brücke, solange allen klar ist, dass es eine Brücke ist. Vor dem Bau gehört außerdem geprüft, ob die Nutzungsbedingungen eines fremden Portals automatisierte Zugriffe überhaupt erlauben.

Wann eine Schnittstelle besser trägt

Bietet ein System eine dokumentierte Programmierschnittstelle oder einen Datenimport, ist diese Anbindung in fast allen Fällen stabiler als ein Bot. Sie arbeitet mit Datenfeldern statt mit Bildschirmelementen, liefert eindeutige Fehlermeldungen statt eines hängenden Fensters und verarbeitet große Mengen, ohne dass Maske für Maske aufgebaut werden muss. Auch Standardformate zählen dazu: Kontoauszüge im CAMT-Format, elektronische Rechnungen nach XRechnung oder ZUGFeRD, Bestellungen per EDI.

Die Gegenrechnung ist in der Regel einfach: Ein Bot ist schneller gebaut, eine Schnittstelle günstiger im Betrieb. Wer einen Ablauf viele Jahre betreiben will, sollte deshalb zuerst prüfen, ob der Hersteller eine Schnittstelle anbietet, ob ein Update sie nachliefert oder ob ein Exportformat reicht. Wie sich die Übergaben eines ganzen Auftragswegs auf diese Weise verbinden lassen, zeigt der Artikel Auftragsabwicklung automatisieren.

Warum Bots brechen und was sie stabiler macht

Die Abhängigkeit von der Oberfläche ist die Kehrseite des Ansatzes. Ein Bot scheitert, wenn ein Update eine Maske umbaut, ein unerwarteter Hinweisdialog erscheint, eine Sitzung abläuft, ein Kennwort gewechselt werden muss oder eine Zwei-Faktor-Anmeldung hinzukommt. Schon eine andere Bildschirmauflösung oder Spracheinstellung kann genügen. Tückisch ist, dass nicht jeder Bruch zum Abbruch führt: Trägt ein Bot einen Wert ins falsche Feld ein, läuft er weiter und hinterlässt einen Fehler, den erst die Buchhaltung bemerkt.

Stabil wird ein Bot durch dieselben Vorkehrungen, die für jede Automatisierung gelten:

• Bedienelemente über feste Kennungen ansprechen, nicht über Bildschirmkoordinaten.
• Nach jedem schreibenden Schritt prüfen, ob der Wert tatsächlich gespeichert wurde.
• Jeden Vorgang protokollieren und nach einem Abbruch an der richtigen Stelle wieder aufsetzen, ohne doppelt zu buchen.
• Fälle, die nicht in die Regel passen, auf eine Ausnahmeliste für einen Menschen setzen, statt sie zu überspringen.
• Eine verantwortliche Person benennen, die von Updates der bedienten Systeme vorab erfährt und den Bot anpasst.

Ohne diese Vorkehrungen entsteht Wildwuchs: einzelne Abläufe, die jemand aufgezeichnet hat, die niemand mehr versteht und deren Ausfall erst auffällt, wenn Aufträge fehlen. Wie viele Vorgänge ein Ablauf tatsächlich ohne Eingriff bewältigt, beschreibt der Begriff Dunkelverarbeitung.

Wie wir zwischen Bot und Schnittstelle entscheiden

Wir betrachten einen Bot nicht isoliert, sondern als eine Übergabe im gesamten Auftragsweg eines Auftraggebers. Zuerst klären wir, ob die beteiligten Systeme eine Schnittstelle, einen Import oder ein Standardformat anbieten. Nur wo das nicht der Fall ist, setzen wir auf die Oberfläche, mit Prüfschritten, Protokoll und Ausnahmeliste, und halten im Angebot fest, woran der Ablauf abgenommen wird und wer ihn nach der Abnahme betreibt. Wie ein solches Vorhaben als Ganzes aufgesetzt wird, beschreibt die Seite Workflow-Automatisierung.