Der erste Produktivlauf ist der teuerste Ort, um zu lernen, wo ein Agent danebenliegt. Und etwas liegt daneben. Ein Lieferant schreibt das Datum andersherum. Eine Regel bildet eine Richtlinie ab, die im März geändert wurde. Ein Anhang entpuppt sich als Foto eines Dokuments. Im Protokoll ist nichts davon interessant. Im Hauptbuch kostet jedes davon Geld.
Der Schattenbetrieb, oft Schattenbetrieb genannt, ist der billige Weg, diese Dinge vorher zu finden. Die meisten Teams lassen ihn weg oder fahren ihn so, dass er nichts beweist. Deshalb lohnt es sich, genau zu sagen, was er ist und was er Ihnen nicht sagen kann.
Was Schattenbetrieb heißt
Der Agent liest echte Eingaben aus den echten Systemen. Er macht die ganze Arbeit. Er holt die Daten, wendet die Regeln an, kommt zu einer Entscheidung und formuliert aus, was er gesendet hätte. Dann schreibt er seine Antwort in ein Protokoll und hört auf. Nichts erreicht das führende System. Keine Mail verlässt das Haus. Keine Zeile wird gebucht.
Wo Sie ihn anhalten, ist wichtiger, als die meisten annehmen. Halten Sie ihn nicht im Prompt an. Einem Modell zu sagen, es solle die Mail nicht wirklich senden, ist eine Bitte, und eine Bitte wird irgendwann überhört, meist in dem Lauf mit der seltsamen Eingabe. Blockieren Sie stattdessen die Schreibzugriffe an der Verbindung. Geben Sie dem Schattenlauf Zugangsdaten mit reinem Leserecht, oder ersetzen Sie jede schreibende Funktion durch einen Rekorder, der die übergebene Nutzlast ablegt und eine plausible Erfolgsmeldung zurückgibt. Dann spielt die Entscheidung des Modells keine Rolle mehr, weil die Fähigkeit fehlt.
Die Eingaben müssen echt sein, aktuell, und in der Reihenfolge, in der sie ankommen. Ein Schattenlauf gegen einen bereinigten Export beweist, dass der Agent bereinigte Exporte beherrscht. Produktivdaten bringen die halb ausgefüllten Datensätze mit, den Vorgang, der innerhalb von vier Minuten zweimal eingereicht wurde, und den Lieferantennamen, der in drei Systemen drei Schreibweisen hat.
Die Bestehensschwelle gehört vor den Lauf
Eine Schwelle, die Sie nach den Ergebnissen festlegen, ist keine Schwelle. Sie ist eine Verhandlung, und die Seite, die live gehen will, gewinnt sie. Schreiben Sie die Zahl vorher auf, und machen Sie sie konkret genug, dass man an ihr scheitern kann.
Sortieren Sie die Ergebnisse in vier Gruppen, statt eine einzige Trefferquote zu zählen. Agent und Mensch waren einig. Der Agent hat eskaliert, statt zu entscheiden. Der Agent hat entschieden und lag falsch. Der Agent hat entschieden, der menschliche Datensatz widerspricht, und der Agent hatte recht. Die vierte Gruppe gibt es wirklich, und Teams vergessen sie regelmäßig. Das heißt, jemand muss die Widersprüche entscheiden, statt die historische Handarbeit als Wahrheit zu setzen. Planen Sie das ein. Eine Person, ungefähr eine Stunde am Tag, über die ganze Laufzeit.
Die Schwelle selbst braucht drei Zahlen. Eine Übereinstimmungsquote für die Entscheidungen, die identisch sein müssen. Eine Obergrenze für stille Fehler. Eine Eskalationsquote, die Ihr Team wegarbeiten kann.
Die stillen Fehler sind die Zahl, auf die es ankommt. Damit meine ich den Agenten, der falsch liegt und nichts davon sagt. Ein Agent, der zu oft eskaliert, nervt, und das können Sie nachjustieren. Ein Agent, der zweimal die Woche leise falsch liegt, bringt dem Team bei, alles nachzuprüfen. Sobald das Team alles nachprüft, haben Sie einen langsameren Prozess mit zusätzlicher Software darin gekauft. Ein stiller Fehler in einem Zahlungslauf wiegt schwerer als fünfzig Eskalationen.
Die Eskalationsgrenze leiten Sie aus der Prüfkapazität ab, nicht aus dem Wunsch. Laufen durch den Workflow 500 Vorgänge in der Woche und schafft die prüfende Person davon 60, dann liegt die Grenze bei zwölf Prozent. Schreiben Sie zwölf Prozent in das Dokument. Kommt der Lauf mit neunzehn Prozent zurück, haben Sie eine Entscheidung vor sich statt einer Diskussion.
Was Sie vergleichen
Vergleichen Sie Entscheidungen, keine Prosa. Bei einer Einordnung die Kategorien. Bei einer Abstimmung das Paar aus zwei Datensatznummern, denn zwei verschiedene Zuordnungen können dieselbe Summe ergeben und trotzdem auf unterschiedlichen Rechnungen landen. Bei einer vorformulierten Antwort taugt kein Textvergleich gegen das, was der Mensch geschrieben hat. Bewerten Sie sie mit drei Fragen, die nur ja oder nein zulassen. Hat sie beantwortet, was gefragt war. Steht etwas Falsches darin. Verpflichtet sie das Unternehmen zu etwas, wozu sie nicht befugt war. Drei Häkchen schlagen jeden Ähnlichkeitswert, und zwei Prüfer werden sich über sie einig.
Vergleichen Sie auch den Weg dorthin. Braucht der Agent vierzehn API-Aufrufe für eine Entscheidung, die ein Mensch von einem Bildschirm aus trifft, bleibt er zwar richtig, wird aber in der Menge langsam und teuer. Das sollten Sie wissen, bevor Sie es mit einem Jahr multiplizieren.
Jetzt die Grenze. Der Schattenbetrieb prüft die Entscheidung und nicht den Schreibvorgang. Schreibzugriffe haben eigene Fehlerbilder, und keines davon zeigt sich hier. Ratenbegrenzungen an einem Tag mit Massenlast. Doppelte Datensätze, weil ein Wiederholungsversuch nach einem Zeitüberlauf feuert. Ein Statuswechsel, der zweihundert Leute benachrichtigt. Ein Webhook, der sich selbst wieder auslöst. Diese Fälle testen Sie getrennt in einer Sandbox, oder mit einem einzigen echten Vorgang und jemandem, der auf den Bildschirm schaut.
Wie lange Sie laufen lassen
Zählen Sie Entscheidungen, nicht Tage. Prüfen Sie danach, ob Sie den Kalender gesehen haben.
Ein Workflow, der vierzig Mal am Tag läuft, liefert in zwei Wochen etwa 400 Entscheidungen. Das reicht, um die Form der Fehler zu erkennen. Ein Monatsabschluss liefert einen Lauf und eine einzige Stichprobe, und das ist kein Test. Für solche Fälle spielen Sie die Vergangenheit nach. Setzen Sie den Agenten auf die letzten drei oder vier Abschlüsse an und vergleichen Sie sein Ergebnis mit dem, was tatsächlich gebucht wurde. Der Nachlauf ist schwächer als ein echter Schattenlauf, weil er die Eingaben nicht zeigen kann, die niemand aufgehoben hat. Eine einzige Stichprobe ist trotzdem schlechter.
Egal wie hoch die Menge ist, decken Sie einen vollen Zyklus dessen ab, was die Schwankung erzeugt. Monatsende. Quartalsende. Die Woche, in der ein Feiertag jedes Fälligkeitsdatum verschiebt. Den Tag, an dem Ihr größter Kunde gesammelt einreicht. Ein Lauf, der vor der harten Woche endet, hat die leichten Wochen getestet.
Fehler nach Ursache gruppieren
Eine Trefferquote sagt Ihnen nichts darüber, was zu reparieren ist. Gruppieren Sie die Fehlschläge nach Ursache, und die Liste wird meist kurz und konkret. Ein Lieferant dreht das Datum um. Ein Eingangskanal wirft Anhänge weg. Eine Regel enthält einen Schwellenwert, den die Finanzabteilung im März geändert hat.
Beheben Sie eine einzelne Ursache, und die Quote springt oft um mehrere Punkte. Das umgekehrte Ergebnis hilft genauso. Hat ein Fünftel der Fehlschläge kein Muster, braucht die Entscheidung vermutlich Wissen, an das der Agent nicht herankommt, und dieser Teil des Workflows bleibt dauerhaft bei einem Menschen. Das in Woche zwei zu erfahren ist besser, als einen Monat lang dagegen zu justieren.
Ändern Sie den Agenten möglichst nicht während des Laufs. Wenn es sein muss, markieren Sie den Schnitt und zählen Sie die beiden Hälften getrennt. Jede Änderung setzt die Stichprobe zurück, und eine gemischte Zahl verdeckt, welche Version Sie eigentlich freigeben.
Wann Sie scharf schalten
In Stufen, nicht in einem Schritt.
Die erste Stufe behält eine menschliche Freigabe für jede Aktion. Der Agent macht die Arbeit, ein Mensch klickt auf Senden. Auf dem Papier ist das langsamer als der alte Prozess, in der Praxis meist nicht, weil das Lesen eines fertigen Entwurfs schneller geht als das Schreiben. Zwei Wochen davon zeigen Ihnen etwas, das Sie sonst nirgends erfahren, nämlich ob die freigebende Person liest oder nur klickt.
Die zweite Stufe verschiebt die Freigabe auf den Eskalationspfad. Sichere Entscheidungen gehen durch. Markierte Vorgänge warten auf einen Menschen, mit der Begründung des Agenten daneben, damit dieser Mensch nicht bei null anfängt.
Ziehen Sie auch nach dem Go-live Stichproben. Zwanzig Vorgänge in der Woche, von Hand geprüft, in den ersten ein bis zwei Monaten. Und halten Sie einen dokumentierten Rückweg bereit, also den Schalter, der den Workflow wieder an Menschen gibt, und den Namen der Person, die ihn umlegen darf. Schreiben Sie den Namen auf. Ein Rückfallplan ohne Verantwortliche ist ein Absatz Text.
Der Schattenbetrieb kostet ein paar Wochen und einen guten Teil der Aufmerksamkeit einer Person. Die Alternative ist, dieselben Fehler mit einem echten Hauptbuch und einem Kunden am Telefon zu finden. Ich zahle die zwei Wochen jedes Mal.