Oberflächenautomatisierung: wann ein Roboter die Maske bedient und wann ein Datenweg trägt

Oberflächenautomatisierung bezeichnet Software, die ein Programm so bedient wie ein Mensch: Sie öffnet Masken, füllt Felder, klickt Schaltflächen und liest Werte vom Bildschirm ab. Der Weg über die Bedienoberfläche steht immer offen, weil jedes Programm eine hat — auch dann, wenn es keinen dokumentierten Datenweg nach außen anbietet.

Oberflächenautomatisierung: was der Roboter tatsächlich tut

Ein solcher Roboter merkt sich Positionen, Beschriftungen und Reihenfolgen. Er startet die Warenwirtschaft, wartet auf das Anmeldefenster, trägt Kennung und Kennwort ein, wechselt in die Belegerfassung und tippt Zeile für Zeile ein, was in einer Tabelle steht. Für das bediente Programm ist er von einer Person am Arbeitsplatz nicht zu unterscheiden: Es empfängt Tastatureingaben und Mausklicks, keine Datenübergabe.

Darin liegt die Stärke dieser Bauweise. Sie braucht keine Freigabe des Herstellers, keine zusätzliche Lizenz für einen Datenweg und keinen Eingriff in die Datenbank. In einem Unternehmen ohne eigene Entwicklung entsteht sie deshalb häufig zuerst: Ein Dienstleister richtet sie ein, ohne die gewachsene Systemlandschaft anzufassen, der Ablauf läuft, und der Hersteller der Fachanwendung muss nicht einbezogen werden.

Der andere Weg: Schnittstelle, Export, Datenbank

Die zweite Bauweise geht nicht über den Bildschirm, sondern über einen dafür vorgesehenen Zugang: eine Programmierschnittstelle des Herstellers, einen geplanten Datei-Export, einen überwachten Importordner, eine Datenbanksicht mit Leserecht. Ausgetauscht wird in einem vereinbarten Format, mit Feldnamen statt Bildschirmpositionen, und der Hersteller sagt zu, dass diese Namen bestehen bleiben.

Der Unterschied zeigt sich nicht am ersten Tag, sondern bei der ersten Änderung. Ein Feld, das in der Maske eine Zeile tiefer rutscht, ist für den Datenweg kein Ereignis; für den Klickweg ist es der Ausfall. Umgekehrt gibt es Fachanwendungen, die keinen Zugang anbieten oder ihn nur in einer höheren Produktstufe führen — dann bleibt die Bedienoberfläche der einzige Weg.

Woran Oberflächenautomatisierung bricht

Die Auslöser sind wenige, und sie wiederholen sich in jedem Haus:

• eine neue Programmversion ändert Feldreihenfolge, Beschriftung oder Tastenkürzel;
• ein Hinweisfenster erscheint einmalig und liegt über der erwarteten Maske;
• Bildschirmauflösung, Zoomstufe oder Schriftgröße am ausführenden Rechner ändern sich;
• das Programm antwortet langsamer als sonst, und der Roboter schreibt in ein Feld, das noch nicht bereit ist;
• ein Kennwort läuft ab, und die Anmeldung bleibt an einer Rückfrage stehen.

Schwerer als der Ausfall wiegt, wie er bemerkt wird. Ein selbst gebauter Roboter führt selten ein Protokoll. Er meldet keinen Fehler, er hört auf — oder er arbeitet weiter und schreibt Werte in die falschen Felder. Auffällig wird das dann nicht am Tag des Ausfalls, sondern später an der Folge: Mahnungen ohne Beleg, doppelte Buchungen, eine Liste, die niemand mehr abgleicht. Was ein Releasewechsel an bestehenden Automatisierungen verändert, gehört deshalb vor jede Aktualisierung auf den Tisch.

Kriterien für die Wahl des Weges

Vier Fragen entscheiden in der Praxis, und zwar in dieser Reihenfolge.

1. Gibt es einen offiziellen Zugang? Bietet der Hersteller Schnittstelle, Export oder Importstrecke an, ist das der erste Kandidat — auch wenn die Einrichtung zunächst aufwendiger aussieht.
2. Welche Menge, welche Häufigkeit? Ein Dutzend Belege am Tag verträgt der Klickweg. Ein nächtlicher Lauf über mehrere tausend Zeilen wird über die Maske langsam und bricht bei einer Störung mitten im Bestand ab.
3. Was kostet ein Fehler? Bei einer internen Liste ist eine falsche Zeile ärgerlich. Bei Zahlungen, Preisen oder Bestellmengen ist sie ein Vorgang mit Außenwirkung.
4. Wer führt den Ablauf weiter? Jede Bauweise braucht einen benannten Verantwortlichen und ein technisches Benutzerkonto mit eigenen Rechten, unter dem sie arbeitet.

Es gibt gute Gründe für den Weg über den Bildschirm: eine Fachanwendung ohne jeden Zugang, eine Lizenz, die den direkten Datenzugriff untersagt, ein Ablauf, der ohnehin abgelöst wird. Dann ist die Entscheidung vertretbar — unter einer Bedingung: Sie wird als befristete Lösung festgehalten, mit Anlass, Grenzen und dem Ereignis, bei dem sie ersetzt wird.

Typische Fehler bei geerbten Robotern

Der häufigste Fehler ist die Frage nach dem Werkzeug statt nach dem Ablauf. Ob ein Roboter mit einem gekauften Produkt, einem Skript oder einer Tabelle gebaut wurde, sagt wenig darüber aus, was er entscheidet. Die Auskunft steckt in den Regeln, die jemand einmal hinterlegt hat — und die nach dem Weggang des Erbauers niemand mehr kennt.

Zwei weitere Muster wiederholen sich. Der Roboter läuft auf einem einzelnen Arbeitsplatzrechner, der eingeschaltet bleiben muss, und im Haus weiß niemand, welcher das ist. Und er arbeitet unter dem persönlichen Zugang eines Mitarbeiters: Verlässt die Person das Unternehmen, wird ihre Kennung gesperrt, und der Ablauf endet ohne erkennbaren Zusammenhang.

Wie wir einen geerbten Roboter übernehmen

Wir lesen zuerst aus, was tatsächlich geschieht: Auslöser, Eingangsdaten, Entscheidungsregeln, Ausgabe, benutzte Zugänge. Danach entscheiden wir je Schritt, ob er am Bildschirm bleibt oder auf einen vorhandenen Datenweg wechselt, und schreiben die Regeln so auf, dass eine andere Person sie anwenden kann. Wo sich eine Regel nicht formulieren lässt, weil der Eingang aus freiem Text besteht, kommt eine KI-Implementierung neben der Standardsoftware in Betracht, mit Prüffällen und einer Übergabe an einen Menschen. Übergeben wird ein Stand erst nach der Abnahme; die Weisung an die Umsetzenden liegt bei unserer Projektleitung. Den Rahmen dafür beschreibt die Prozessautomatisierung für Unternehmen ohne eigene Entwicklung.