Womit man anfängt, und warum nicht mit der lautesten Beschwerde

Fragen Sie eine Abteilung, welche Arbeit zuerst automatisiert werden soll, und Sie bekommen die Liste der Dinge, die alle hassen. Die Liste ist nützlich, aber sie misst Ärger, und Ärger und Kosten hängen nur lose zusammen. Die drei Stunden pro Woche, die in Scheiben zu zwölf Minuten verschwinden, tauchen in keiner Beschwerde auf. Der unangenehme Quartalsbericht, den im ersten Interview jeder erwähnt, kostet vielleicht zwanzig Stunden im Jahr.

Der erste Build ist also ein Sortierproblem, und es lohnt sich, offen zu sagen, nach welcher Zahl sortiert wird. Sonst trifft die Entscheidung derjenige, der im Workshop am lautesten gesprochen hat.

Die Zahl, nach der sortiert wird

Zurückgewonnene Stunden pro Monat, geteilt durch Wochen Bauzeit. Das ist alles. Alles andere ist ein Filter, den Sie nach dem Sortieren anlegen.

Die zurückgewonnenen Stunden setzen sich aus drei Größen zusammen, die man zählen statt schätzen kann. Wie oft der Workflow läuft, abgelesen im Quellsystem und nicht aus dem Gedächtnis. Wie lange ein Durchlauf dauert, gemessen, indem man jemandem zusieht und die Uhr mitlaufen lässt. Und der Anteil dieser Zeit, den ein Agent tatsächlich übernimmt, was fast nie alles ist, weil eine Zeit lang noch jemand die Ergebnisse liest.

Nehmen wir einen Workflow, der vierzig Mal pro Woche läuft und pro Durchlauf zwölf Minuten kostet. Das sind acht Stunden pro Woche, also rund fünfunddreißig Stunden im Monat. Wenn ein Agent achtzig Prozent der Menge von Anfang bis Ende erledigt und der Rest in die Prüfung geht, rechnen Sie mit fünfundzwanzig Stunden zurück. Bei sechs Wochen Bauzeit ist die Sortierzahl etwa vier.

Jetzt der Quartalsbericht, über den sich drei Leute beschweren. Drei Tage Arbeit, vier Mal im Jahr, also vierundzwanzig Stunden im Quartal oder acht im Monat. Ein einzelner Durchlauf enthält mehr verschiedene Entscheidungen als der häufige Workflow in einem ganzen Monat, deshalb dauert der Bau länger, sagen wir acht Wochen. Die Sortierzahl ist eins. Das ist ein Fünftel des Werts, und es ist der Workflow, den alle genannt haben. Beide Rechnungen sind Annahmen, die Methode ist es nicht.

Schreiben Sie die Schätzungen vor dem Sortieren auf, auch die unsicheren, und vermerken Sie, wie sicher Sie sind. Eine Bauschätzung ist geraten, und was Sie aufgeschrieben haben, können Sie später nachprüfen. Was Sie im Kopf behalten, wird einfach zum Termin.

Häufigkeit schlägt Dauer

Zwei Workflows können dieselben Stunden pro Monat zurückholen, der eine mit zweihundert Durchläufen, der andere mit zwei. Nehmen Sie den häufigen, und zwar aus Gründen, die über die Rechnung hinausgehen.

Sie bekommen früher ein Urteil. Ein Workflow mit zweihundert Durchläufen im Monat liefert in zwei Wochen genug Vergleiche im Schattenbetrieb, um zu wissen, ob der Agent richtig liegt. Bei zwei Durchläufen im Monat brauchen Sie für dieselbe Sicherheit ein Jahr, und bis dahin kann niemand sagen, ob der Build funktioniert hat.

Korrekturen kommen an, solange Sie noch etwas damit anfangen können. Die erste Fassung jedes Agenten liegt bei irgendetwas Bestimmtem daneben. Bei einem häufigen Workflow finden Sie es in Woche eins, beheben es und sehen die Wirkung. Bei einem seltenen taucht der Fehler einmal auf, wird anhand eines einzigen Beispiels geflickt, und die nächste Gelegenheit, den Flicken zu prüfen, kommt Monate später.

Seltene Workflows bieten weniger Wiederholung, die man ausnutzen kann. Ein Dreitagesprozess besteht meist aus dreißig verschiedenen Schritten, die je einmal vorkommen, und jeder Schritt braucht eigene Regeln. Ein häufiger Workflow besteht aus wenigen Schritten, die hundertfach vorkommen. Die Kosten pro zurückgewonnener Stunde liegen bei der zweiten Sorte weit niedriger.

Und Häufigkeit bringt Kosten mit, die in keiner Zeitaufnahme stehen. Eine Aufgabe, die jemanden acht Mal am Tag unterbricht, zerlegt den Tag drumherum. Zwölf Minuten Arbeit kosten mehr als zwölf Minuten Aufmerksamkeit.

Die Falle mit der Ausnahmequote

Das ist die Schätzung, die am häufigsten danebengeht. Ein Workflow sieht einheitlich aus, der Agent wird für den Standardweg gebaut, und die zurückgewonnenen Stunden liegen weit unter der Zahl in der Map. Die Ursache ist fast immer die Ausnahmequote, genauer gesagt das, was auf dem Ausnahmeweg passiert.

Zwei Workflows können beide fünfundzwanzig Prozent Ausnahmen haben und trotzdem völlig verschiedene Investitionen sein. Im guten Fall ist eine Ausnahme in sich abgeschlossen. Der Agent legt sie mit Begründung ab, jemand bearbeitet diesen einen Fall, ohne etwas über die anderen fünfundsiebzig Prozent wissen zu müssen, und die Ersparnis fällt ungefähr proportional aus. Im schlechten Fall bedeutet eine Ausnahme, dass der Prüfer sich ohnehin den ganzen Zusammenhang laden muss. Er muss den Stapel verstehen, nachsehen, was der Agent schon getan hat, und dann entscheiden. Dort fressen fünfundzwanzig Prozent den größten Teil des Nutzens, weil der teure Anteil nie das Tippen war.

Messen Sie die Quote, bevor Sie sich festlegen, aus Daten und nicht aus Meinungen. Ziehen Sie zweihundert aktuelle Vorgänge, lassen Sie die Person, die die Arbeit macht, jeden davon als Standard oder Ausnahme markieren, und fragen Sie bei jeder Ausnahme, was sie erfordert hat. Das dauert einen Nachmittag und sagt besser als alles andere voraus, ob sich der Build rechnet. Meine Faustregel ist einfach. Liegt der Anteil über etwa zwanzig Prozent und braucht jede Ausnahme den vollen Zusammenhang, rutscht der Workflow in der Liste nach unten, bis sich der Standardweg sauberer herauslösen lässt.

Bei Gleichstand entscheidet die Umkehrbarkeit. Zwei Kandidaten mit ähnlichen Zahlen sind nicht gleich, wenn der eine internen Text vorformuliert und der andere Rechnungen an Kunden schickt. Der erste Build sollte einer sein, bei dem ein Fehler in Woche zwei eine Korrektur und eine Entschuldigung im eigenen Haus kostet. Das ist keine Vorsicht um ihrer selbst willen. Der erste Build entscheidet, ob jemand dem zweiten traut, und ein früher Fehler nach außen kostet mehr als der Zeitplan, den er gespart hat.

Warum die lauteste Beschwerde selten zuerst kommt

Der Workflow, über den am lautesten geklagt wird, ist meist aus Gründen laut, die ihn als ersten Build disqualifizieren.

Er ist unangenehm, nicht häufig. Mühsal und Menge sind zwei verschiedene Dinge, und die Aufgaben, über die am meisten geschimpft wird, sind oft die seltenen und sperrigen.

Oder niemand ist sich einig, was das richtige Ergebnis wäre. Das ist der eigentliche Ausschlussgrund. Wenn zwei erfahrene Leute denselben Fall unterschiedlich behandeln und beide ihre Antwort gut begründen, können Sie keine Bestehensschwelle formulieren. Ohne Bestehensschwelle hat der Schattenbetrieb nichts, wogegen er vergleichen könnte, und der Agent geht nie in den Produktivbetrieb, weil es kein Kriterium gibt, das er erfüllen kann. Diese Uneinigkeit gehört geklärt, und das ist eine Führungsaufgabe und kein Agenten-Build. Einen umstrittenen Prozess zu automatisieren lässt den Streit nur schneller laufen.

Oder er ist laut, weil er für jemanden weit oben sichtbar ist. Das sagt Ihnen etwas über Berichtswege und nichts über Stunden.

Nichts davon heißt, ignorieren Sie ihn. Der laute Workflow gehört meist als Build zwei oder drei in die Reihe, und bis dahin schulden Sie ihm eine ausdrückliche, schriftliche Begründung, warum er nicht zuerst kommt. Menschen akzeptieren den zweiten Platz, wenn die Rechnung auf dem Papier steht. Sie akzeptieren keine Entscheidung, die so aussieht, als hätte der Berater sich das Bequemere ausgesucht.

Was der erste Build außer einer guten Zahl braucht

Drei Filter nach dem Sortieren, und jeder darf den Sieger kippen.

Ein System, höchstens zwei. Jedes weitere System bringt Zugangsdaten, Anfragelimits, ein Berechtigungsmodell und eine eigene Art zu scheitern. Ein hoch bewerteter Workflow, der fünf Tools berührt, ist Build zwei oder drei.

Eine benannte verantwortliche Person, die entscheiden darf. Jemand muss Fragen innerhalb eines Tages beantworten und die Regeln abnehmen. Kein Gremium.

Eine Zahl, die der Auftraggeber schon verfolgt. Zeigt sich die Verbesserung nur in einer Kennzahl, die Sie für das Projekt erfunden haben, wird der Build sechs Monate später nach Gefühl beurteilt. Nehmen Sie den Workflow, dessen Ergebnis auf einer Zahl landet, die vor Ihrer Ankunft schon auf einem Bericht stand, und einigen Sie sich darauf, wie hoch sie heute ist.

Das Sortieren ist nicht der schwere Teil. Schwer ist, dabei zu bleiben, wenn die lauteste Beschwerde nicht oben steht.