Bildschirmroboter (RPA) oder echte Schnittstelle: Wann sinnvoll?

Ein Bildschirmroboter beantwortet eine Frage, die im Zielsystem entsteht: Fehlt dort ein dokumentierter Zugang, bleibt als Verbindung die Oberfläche. Ob diese Brücke trägt, hängt an drei Größen: dem Zugangsweg, der Änderungsrate des Zielsystems und der Folge eines falschen Laufs. Prüfen Sie die drei in dieser Reihenfolge.

Worum es bei der Auswahl geht

Ein Bildschirmroboter (Robotic Process Automation, RPA) bedient eine fremde Anwendung über deren Benutzeroberfläche: Er öffnet Masken, liest Felder, trägt Werte ein und löst Schaltflächen aus; das Zielsystem verarbeitet eine Bediensitzung, keinen programmatischen Aufruf. Eine Schnittstelle ist der Weg ohne Oberfläche: Das Zielsystem veröffentlicht einen Aufruf, Ihr Programm übergibt Daten und erhält eine Antwort; Umfang, Felder und Fehlermeldungen stehen dokumentiert.

Die Wahl fällt je Vorgang: Dasselbe Unternehmen kann Bestellungen über eine Schnittstelle in das ERP übernehmen und ein Lieferantenportal ohne Zugang von Hand bedienen. Eine Brücke lässt sich später ablösen, wenn der Vorgang mit Feldern, Regeln und Fehlerfällen beschrieben wurde. Für die Auswahl der Vorgänge siehe Prozessautomatisierung im ERP: Welche Abläufe zuerst?.

Vor der Technik steht eine Frage an den Betreiber: Ob ein Programm die Oberfläche eines fremden Systems bedienen darf, klären Sie vorab mit ihm. Seine Nutzungsbedingungen sind ein erster Anlaufpunkt, keine abschließende Rechtsprüfung. Holen Sie die schriftliche Erlaubnis ein, bevor ein Lauf produktiv wird.

Diese Kriterien zählen

Die Tabelle nennt je Kriterium die Bedeutung, den Test und die Frage an den Anbieter.

Kriterium	Warum es den Weg entscheidet	Wie Sie es prüfen	Frage an den Anbieter
Zugangsweg	Ohne dokumentierten Schreibzugang entfällt die Schnittstelle, ohne Oberfläche der Roboter	Dokumentation anfordern, dann je Objekt Lese- und Schreibaufruf testen	Welche Objekte sind schreibbar, seit welcher Version?
Änderungsrate der Oberfläche	Eine Änderung an Maske, Feldbezeichnung oder Reihenfolge trifft den Roboter; ob eine Schnittstelle betroffen ist, hängt von den genutzten Feldern und den Zugangsbedingungen ab	Versionshinweise der letzten 12 Monate und die Ankündigungsfrist je Änderung	Mit welcher Frist kündigen Sie Änderungen an?
Risiko des Vorgangs	Bei Geld, Bestand und Steuer zählt die Folge eines falschen Laufs	Einen Doppellauf herbeiführen und im Zielsystem nachsehen	Welche Buchung entsteht bei doppelter Übertragung?
Takt und Menge	Ein Lauf je Woche verkraftet Handarbeit, ein Massenlauf nicht	Läufe je Woche, Datensätze je Lauf, Dauer eines manuellen Durchgangs	Welche Mengengrenzen gelten je Zeitfenster?
Nachvollziehbarkeit	Ohne Nachweis je Datensatz lässt sich eine Fehlbuchung nicht zuordnen	Protokoll eines Testlaufs anfordern und einen Datensatz verfolgen	Welche Protokolle entstehen je Datensatz?

Der Entscheidungsbaum

Prüfen Sie in drei Stufen; erst wenn alle drei bestanden sind, ist der Roboter vertretbar.

1. Gibt es einen dokumentierten Zugang mit Schreibrecht? Ja: Bauen Sie die Schnittstelle und prüfen Sie vorher ihre Eigenschaften nach Offene ERP-Schnittstelle prüfen. Nein: weiter mit Stufe 2; Zwischenwege sind Dateiübergabe (CSV-Austausch mit dem ERP), Integrationsplattform (Integrationsplattform oder Einzelschnittstellen) oder eine schriftliche Forderung an den Betreiber.
2. Ändert sich die Oberfläche ohne Ankündigung? Liegen Versionshinweise mit Frist vor und bleiben die Suchmuster gleich, folgt Stufe 3. Ohne Ankündigung trägt die Brücke nicht: Ein Umbau kann den Lauf abbrechen; ob Sie davon erfahren, hängt an Ihrer eigenen Überwachung.
3. Was folgt aus einem falschen Lauf? Bleibt die Folge lesend oder korrigierbar, ist der Roboter mit Prüfung und Erlaubnis vertretbar; führt er zu Buchungen in Geld, Bestand oder Steuer, bleiben Schnittstelle oder Freigabe je Lauf.

Die Zuordnung für fünf typische Lagen ist unsere Empfehlung.

Zugangsweg	Oberfläche	Fehlerfolge	Weg
Schreibender Zugang dokumentiert	beliebig	beliebig	Schnittstelle
Kein Zugang	Änderungen mit Frist	lesend oder korrigierbar	Roboter mit Prüfsumme und Freigabe
Kein Zugang	ohne Ankündigung	beliebig	nicht automatisieren; Zugang verlangen oder Handarbeit
Kein Zugang	beliebig	Buchungswirkung	Schnittstelle oder Freigabe je Lauf
Kein Zugang, Datei verfügbar	beliebig	wie oben	Dateiübergabe mit Prüfsummen

Typische Ausfallarten von Bildschirmrobotern

Die Liste nennt Mechanik, Symptom und Gegenmaßnahme; die Fehlerbeschreibungen sind im Standard als nicht normativ gekennzeichnet.

Ausfallart	Mechanik und Belegstelle	Symptom	Gegenmaßnahme
Suchmuster trifft nicht mehr	Der Roboter sucht Elemente unter anderem über CSS-Selektor oder XPath (WebDriver, Abschnitt 12.1); die Suche nach einem einzelnen Element meldet ohne Treffer no such element (Abschnitt 12.2), die Suche nach mehreren Elementen liefert eine leere Liste (Abschnitt 12.3), ein abgehängtes Element stale element reference (Abschnitt 6.6)	Der Aufruf liefert einen Fehler; der Lauf endet oder überspringt den Schritt, je nach Fehlerbehandlung des Roboters	Muster breit wählen, Version vor jedem Update prüfen
Element nicht bedienbar	WebDriver verlangt ein bedienbares Element (Abschnitt 11.1); ist der Klickpunkt verdeckt, antwortet es mit element click intercepted. Für einen Klick schiebt der Standard den Elementcontainer zuerst in den Sichtbereich (Abschnitt 14.1, Schritt 4); liegt der Container danach weiterhin außerhalb, folgt element not interactable (Abschnitt 14.1, Schritt 5; Abschnitt 6.6)	Der Klick wird als Fehlerantwort zurückgegeben und nicht ausgeführt; der Lauf endet oder setzt fort, je nach Fehlerbehandlung	Klickpunkt prüfen, auf das Laden warten, Fehlerantwort auswerten
Zeitüberschreitung	Je Sitzung einstellbare Standardwerte: 300.000 ms Seitenaufbau, 30.000 ms Skript, 0 ms implizite Wartezeit (Abschnitt 8). Die drei Fristen melden unterschiedlich: Bleibt der Seitenaufbau aus, antwortet der Standard mit timeout (Abschnitt 9.1), ein nicht beendetes Skript mit script timeout (Abschnitt 15.2.1), eine Suche nach einem einzelnen Element, die bis zum Ablauf der impliziten Wartezeit keinen Treffer findet, mit no such element (Abschnitte 12 und 12.2)	Lauf endet im Fehler bei langsamem Zielsystem	Limits je Maske messen und anpassen, Wiederholung begrenzen
Dialog blockiert	Ein modales Hinweisfenster blockiert die laufende Anweisung; der Standard behandelt Dialoge nicht automatisch, und die Fähigkeit unhandled prompt behavior steuert, was geschieht: dismiss und accept schließen beziehungsweise bestätigen den Dialog und lassen die Anweisung ohne Fehler weiterlaufen, dismiss and notify und accept and notify tun dasselbe und geben zusätzlich einen Fehler zurück, ignore lässt ihn offen. Für einen offenen Dialog, den die laufende Anweisung nicht selbst behandelt, ist unexpected alert open der Fehlercode (Abschnitte 6.6 und 18)	Ob der Aufruf mit unexpected alert open endet, hängt an der Eingabe für unhandled prompt behavior: bei dismiss oder accept läuft die Anweisung ohne Fehler weiter, bei dismiss and notify und accept and notify meldet der Standard den Fehler, bei ignore und ohne Angabe ebenfalls; eine fehlende Angabe schließt den Dialog und meldet den Fehler (Abschnitt 18)	Dialogbehandlung einbauen, Lauf überwachen
WebDriver-Sitzung	Lässt sich keine WebDriver-Sitzung erstellen, meldet der Standard session not created (Abschnitt 6.6); gemeint ist die Browser-Sitzung, nicht die Anmeldung an der Fachanwendung	Lauf beginnt nicht	Treiber-, Browser- und Sitzungskonfiguration prüfen
Anmeldung an der Fachanwendung	Der Roboter meldet sich wie eine Person an; Mehrfaktor-Anmeldung, Gerätewechsel oder Sitzungsablauf können den Lauf blockieren (Prüffrage, nicht Teil des WebDriver-Protokolls)	Lauf bricht bei der Anmeldung ab	eigenes Konto verlangen, Mehrfaktor und Sitzungsende klären
Doppelte oder fehlende Buchung	RFC 9110 definiert in Abschnitt 9.2.2 idempotent: gleiche Aufrufe wirken wie einer (PUT, DELETE); ohne diese Eigenschaft soll ein Aufruf nicht automatisch wiederholt werden. Für einen Klick auf eine Maske fehlt eine solche Festlegung	Ein zweiter Lauf erzeugt eine zweite Buchung oder keine	Doppellauf testen, Sendeschlüssel vereinbaren, abgleichen
Stiller Datenfehler	Ob ausgelesene Werte stimmen, ist nicht Teil des WebDriver-Protokolls; die Prüflogik legen Sie selbst fest	Buchung vorhanden, aber falsch zugeordnet	Prüfsumme und Mengenabgleich je Lauf

Eine Schnittstelle kann eigene programmatische Zugangsdaten erhalten; RFC 6749 sieht dafür in Abschnitt 4.4 den Client-Credentials-Grant vor, der nur vertraulichen Clients erlaubt ist. Ein Bildschirmroboter meldet sich dagegen in der Oberfläche an, wie es eine Person täte; getrennte Konten und Rechte je Anbindung sind deshalb auch bei ihm die Prüffrage.

Woraus sich die Kosten zusammensetzen

Beide Wege haben dieselben Kostenfelder. Tragen Sie je Angebot Beträge ein oder die offene Frage.

Kostenfeld	Beim Bildschirmroboter	Bei der Schnittstelle
Erstaufbau	Aufzeichnung der Schritte, Testfälle, Prüflogik je Lauf	Entwicklung gegen die Dokumentation, Testumgebung, Fehlerbehandlung
Laufende Nutzung	Lizenz je Roboter, je Lauf oder je gleichzeitigem Zugriff	Freischaltung und Kontingente des Zugangs
Änderungsaufwand	Nacharbeit bei Änderungen der Oberfläche, die Suchmuster oder Ablauf treffen	Nacharbeit bei Änderungen der genutzten Felder oder der Zugangsbedingungen
Überwachung und Korrektur	Zeitüberwachung, Dialogeingriff, Nachbuchen falscher Buchungen von Hand	Fehlerprotokolle, Wiederholung, Abgleich (Schnittstellenfehler im Betrieb)
Vertragsseite	Nutzungsrechte, Haftung, Ankündigungsfristen des Betreibers	Laufzeit und Kündigung des Zugangsvertrags

Für den Vergleich setzen Sie den Änderungsaufwand gegen die Zahl erwarteter Änderungen. Beispiel: vier Änderungen je Jahr zu je zwei Tagen Nacharbeit tragen nur, wenn der Vorgang den Einsatz rechtfertigt.

Warnsignale in Angebot und Vertrag

• Automatisierte Zugriffe sind in den Nutzungsbedingungen nicht geregelt, und eine schriftliche Erlaubnis fehlt.
• Änderungen an der Oberfläche werden ohne Ankündigungsfrist ausgerollt.
• Der Roboter soll mit den persönlichen Zugangsdaten einer Person arbeiten; ein eigenes Konto wird verweigert.
• Ein Test auf einen doppelten Lauf fehlt, und je Datensatz gibt es kein Protokoll des geschriebenen Werts.
• Die benötigte Schnittstelle ist nur mündlich in Aussicht gestellt.
• Lizenz je Roboter und Jahr, unabhängig davon, ob der Vorgang noch automatisiert läuft.

Welche Kriterien für welchen Fall wiegen

Die Zuordnung ist unsere Empfehlung; Ihre Mengen können sie verschieben.

Fall	Größtes Gewicht	Weg
Belege aus einem Kundenportal ohne Schnittstelle abrufen	Erlaubnis, Änderungsrate	lesender Roboter mit Mengenabgleich, sonst Dateiübergabe
Bestellungen oder Rechnungen aus einem Shop in das ERP übertragen	Zugangsweg, Doppelbuchung	Schnittstelle mit Ereignismeldung
Stammdaten in einem Lieferantenportal pflegen	Änderungsrate, Fehlerfolge	Schreibvorgänge einzeln freigeben
Buchungen erzeugen	Fehlerfolge	Schnittstelle mit Prüfsumme, kein unbeaufsichtigter Lauf
Einmaliger Datenumzug bei einem Systemwechsel	Aufwand je Lauf	Roboter für den Umzug, Ergebnis abgleichen

So entscheiden Sie in fünf Schritten

1. Schneiden Sie den Vorgang in Eingabe, Prüfregeln, Ausgabe und Fehlerfall; notieren Sie die berührten Felder.
2. Prüfen Sie den Zugangsweg: Dokumentation, Schreibrechte, Testumgebung.
3. Messen Sie die Änderungsrate: Versionshinweise der letzten 12 Monate und die Frist je Änderung.
4. Erzeugen Sie absichtlich einen Fehlerlauf und halten Sie fest, was daraus entstand.
5. Legen Sie die Prüfung je Lauf fest (Prüfsumme, Mengenabgleich, Freigabe, Korrekturweg) und lassen Sie sich automatisierte Zugriffe schriftlich erlauben.