Warum wir nicht über Bildschirme klicken lassen
Ein Kunde zeigte uns eine Aufzeichnung, in der ein Agent sein ERP über den Bildschirm bediente, Felder füllte und Schaltflächen klickte, und fragte, wie schnell wir das in den Betrieb bringen könnten. Die ehrliche Antwort begann mit der Frage, was mit der API nicht stimmt.
Was die Vorführung zeigte
Sie funktionierte tatsächlich. Der Agent las den Bildschirm, fand die Auftragssuche, tippte eine Auftragsnummer, wartete auf die Trefferliste und klickte in die richtige Zeile. Das zuzusehen überzeugt mehr als jedes Integrationsdiagramm — und genau darin liegt das Problem als Entscheidungsgrundlage.
Die Vorführung beweist, dass die Aufgabe möglich ist. Sie sagt nichts über die Fehlerquote auf zehntausend Läufen, darüber, was passiert, wenn ein Dialog auftaucht, der in der Aufzeichnung nicht vorkam, oder wer verantwortlich ist, wenn ein Klick in der falschen Zeile landet.
Ein Bildschirm ist nicht das System
Die Oberfläche ist eine Darstellung des Systems für einen Menschen. Sie ändert sich, wenn der Hersteller findet, eine Schaltfläche gehöre woandershin, sie variiert mit Bildschirmgröße und Sprache, und nichts daran ist ein Vertrag. Eine API, wie schlecht dokumentiert auch immer, impliziert wenigstens ein Versprechen über Namen und Formen.
Diese Unterscheidung ist das ganze Argument. Gegen einen Bildschirm zu automatisieren heißt, dass unser System von einer Oberfläche abhängt, deren Stabilität niemand zugesagt hat — und die Abhängigkeit bleibt unsichtbar, bis ein Routine-Update ein Feld verschiebt und ein nächtlicher Lauf still etwas anderes tut.
Die Forschung und was sie belegt
Wu und Kollegen veröffentlichten in jenem Oktober OS-ATLAS, ein Aktionsmodell für Agenten, die grafische Oberflächen bedienen, mit besonderem Augenmerk auf Grounding — also die Zuordnung von einem beschriebenen Element zu der Stelle, an der es auf dem Bildschirm tatsächlich ist.
Dass Grounding der schwierige Teil ist, ist der Grund für unsere Zurückhaltung. Oberflächenautomatisierung hängt daran, das richtige Element verlässlich zu finden, und dass die Forschung das als substanzielles offenes Problem behandelt, ist ein besserer Wegweiser zum Betriebsrisiko als eine gelungene Aufzeichnung.
| Frage | Wenn die Antwort nichts hergibt |
|---|---|
| Gibt es eine API oder eine Datenbank? | Nutzen. Das ist der Regelfall |
| Sichert der Hersteller das Layout zu? | Bildschirme wandern. Bruch einplanen |
| Ist die Aktion umkehrbar? | Kein unbeaufsichtigter Betrieb |
| Rechtfertigt die Menge die Zerbrechlichkeit? | Unter einigen hundert am Tag: ein Mensch |
Das Projekt, bei dem wir zugestimmt haben
Ein Lieferantenportal ohne API, ohne Export und mit einer rechtlichen Pflicht, Dokumente abzurufen, die es nur dort gibt. Zweimal täglich, rund vierzig Dokumente, und die Alternative war eine Person, die das jedes Mal eine Stunde von Hand tat.
Wir haben es gebaut, und die Abnahmekriterien waren ungewöhnlich: Es muss laut scheitern statt weiterzumachen, jeder Lauf erzeugt ein Bildschirmprotokoll, und ein Mensch prüft die Anzahl gegen einen erwarteten Bereich. In achtzehn Monaten ist es zweimal gebrochen, beide Male nach einem Portal-Redesign, und beide Male hat es angehalten statt geraten.
Worauf wir bestanden haben
Nur lesend, wo immer möglich. Ein Dokument herunterzuladen ist wiederherstellbar, ein Formular abzuschicken nicht — und der absendende Agent ist eine ganz andere Sache als der abholende. Unser Portal-Agent liest und lädt herunter, sonst nichts.
Wo ein Schreibvorgang unvermeidlich ist, erzeugt er einen Entwurf, den ein Mensch bestätigt. Das halbiert den Nutzenversprechen und ist die einzige Anordnung, die wir zu betreiben bereit waren — denn ein fehlgeleiteter Klick in einem führenden System ist ein Fehler, den niemand im Protokoll sieht, bevor er zählt.
Die Kosten, die niemand einplant
Die Pflege. Oberflächenautomatisierung baut nicht sanft ab; sie funktioniert, bis sie es nicht mehr tut, und die Reparatur ist keine Codekorrektur, sondern eine Neuherleitung des heutigen Bildschirmaufbaus. Wir kalkulieren einen Tag je Quartal und Portal und lagen damit ungefähr richtig.
Dazu kommt das Testumgebungsproblem. Einen Bildschirmagenten zu testen heißt, eine Testinstanz des fremden Portals zu haben, die es häufig nicht gibt — also findet die Prüfung gegen die Produktion statt, mit aller Sorgfalt, die das erfordert.
Was wir stattdessen empfehlen
Der Reihe nach: die API nutzen. Gibt es keine, nach einem geplanten Export fragen, den Hersteller oft anbieten und Kunden oft nicht kennen. Scheitert auch das, den Hersteller direkt fragen — denn ein Kunde, der eine Integration verlangt, ist für ihn ein stärkeres Signal als ein Behelf, von dem er nie erfährt.
Bildschirmautomatisierung ist Vierter, und ein vernünftiger Vierter. Unser Einwand gilt nicht der Technik, sondern dem Griff danach, bevor die ersten drei versucht wurden — was geschieht, weil die Vorführung überzeugender ist als ein Gespräch über Exportformate.
Was wir nicht behaupten
Wir behaupten nicht, Oberflächenagenten funktionierten nicht. Unserer funktioniert, spart täglich eine Stunde, und die Technik hat sich deutlich verbessert. Die Behauptung betrifft die Reihenfolge: Es ist die Option, zu der man greift, wenn die anderen fehlen, nicht die, zu der man greift, weil sie sich gut vorführen lässt.
Wir behaupten auch nicht, unsere Schwellen seien prinzipiell begründet. Bei einigen hundert Vorgängen am Tag hörte die Zerbrechlichkeit für uns auf, sich zu lohnen — wer ein stabileres Portal oder mehr Bruchtoleranz hat, zöge die Linie mit gutem Grund anderswo.