„Läuft gut" ist keine Messung (und die Ersparnis aus dem Angebot auch nicht)
Es gibt ein Gespräch, das sich in jedem Unternehmen wiederholt, das vor mehr als einem halben Jahr etwas automatisiert hat. Jemand fragt, ob das Ding eigentlich etwas bringt. Kurze Stille. Und dann antwortet der, der es gebaut hat: „Läuft, macht keine Probleme." Das ist eine Auskunft über den Zustand des Systems, nicht über seine Leistung. Ein Flow kann sechs Monate lang nicht ausgefallen sein, dabei halb so viele Fälle verarbeiten wie früher, zwei Leute beschäftigen, die vorsichtshalber jede Ausgabe prüfen — und auf die einzige Frage, die je gestellt wird, weiterhin „läuft gut" antworten.
Der zweite Joker ist schlimmer, weil er wie eine Zahl aussieht: die „geschätzte Ersparnis" aus dem Angebot. Zwanzig Stunden im Monat, stand auf der Folie. Diese Zahl entstand aus einem angenommenen Volumen mal einer angenommenen Bearbeitungszeit, bevor es einen einzigen echten Messwert gab, und ohne die neue Arbeit abzuziehen, die die Automatisierung schaffen würde — Ausnahmen prüfen, dienstags die Integration reparieren, dem System den seltenen Fall erklären. Das ist eine Kaufhypothese, und ihr Platz ist die Investitionsentscheidung, nicht die Bewertung des Investierten. Eine Prognose wird nicht dadurch zur Messung, dass acht Monate vergehen.
Die Baseline: die einzige Zahl, die du nicht nachträglich erheben kannst
Hier ist der Fehler, der die Messung der meisten Automatisierungen ruiniert, und er passiert, bevor die erste Zeile des Flows geschrieben ist: Niemand hat notiert, wie der Prozess vorher lief. Ohne dieses „vorher" ist alles, was du später misst, eine verwaiste Absolutzahl. Ihr verarbeitet achthundert Fälle im Monat: Ist das gut? Weiß keiner. Ihr braucht vier Stunden pro Fall: besser oder schlechter als im Januar? Niemand erinnert sich genau, und das Gedächtnis eines Teams rundet immer zugunsten des Neuen — weil das Neue jemand gebaut hat, der mit im Raum sitzt.
Die Baseline nimmt man auf, solange der Prozess noch von Hand läuft, über zwei oder drei Wochen, und sie braucht keinerlei Instrumentierung: eine Tabelle und die Disziplin, sie auszufüllen. Fünf Spalten:
- Volumen. Wie viele Fälle pro Woche hereinkommen. Mit notierter Saisonalität, falls es sie gibt: August zählt nicht wie Oktober.
- Durchlaufzeit von Anfang bis Ende. Von der Ankunft des Falls bis zu seinem Abschluss, nicht die Zeit, die jemand tippt. Die Differenz zwischen beiden Zahlen — die Zeit, die der Fall im Postfach von irgendwem wartet — ist meist die Hälfte des Ganzen, und genau dort wird wirklich gewonnen.
- Hände, die ihn anfassen. Wie viele verschiedene Personen beteiligt sind. Jede Übergabe ist eine Stelle, an der der Fall stehen bleibt.
- Fehler und Nacharbeit. Wie viele Fälle noch einmal gemacht werden müssen. Das ist die Kennzahl, die fast niemand notiert, und die später am meisten täuscht: Wenn du einen Prozess automatisierst, der in 15 % der Fälle nachgearbeitet wurde, und er wird weiterhin in 15 % nachgearbeitet, hast du nicht die Qualität verbessert, nur das Tempo.
- Sonderfälle. Wie viele vom normalen Weg abweichen und warum. Diese Spalte sagt dir Monate später, ob die Ausnahmen deiner Automatisierung die alten sind oder neue, die du selbst geschaffen hast.
Wenn du bereits ohne Baseline ausgerollt hast — was das Wahrscheinlichste ist, weil sie fast niemand aufnimmt —, dann erfinde das „vorher" nicht. Es aus dem Gedächtnis zu rekonstruieren ist schlimmer, als es gar nicht zu haben, denn es erzeugt eine Zahl, die aussieht wie ein Messwert und die danach nie wieder jemand hinterfragt. Ehrlich ist: „keine Baseline vorhanden" in den Bericht schreiben, ab heute messen und den laufenden Monat als Startpunkt nehmen — in einem Quartal hast du einen Vergleich. Und wenn du noch rechtzeitig bist, ist die richtige Reihenfolge genau umgekehrt zu der, die alle einhalten: Erst wird der Prozess gemessen, dann wird entschieden, welche Prozesse automatisiert werden, und erst dann wird gebaut.
Die vier Kennzahlen, auf die es ankommt
Vier reichen. Das ist keine ästhetische Askese: Ein Dashboard mit zwölf Indikatoren schaut sich niemand an, und was niemand anschaut, existiert nicht. Diese vier decken die vier verschiedenen Fragen ab, die man einem System im Betrieb stellen kann — wie viel es allein erledigt, wie oft es hängen bleibt, wie viel es wirklich freisetzt und was es kostet — und jede stopft ein Loch, das die anderen drei offen lassen.
| Kennzahl | Was sie beantwortet | Wie oft angeschaut |
|---|---|---|
| Anteil, der allein durchläuft | Von hundert eingehenden Fällen: Wie viele werden abgeschlossen, ohne dass jemand sie anfasst. Die einzige Kennzahl, die misst, wie viel vom Prozess wirklich automatisiert ist. | Wöchentlich |
| Ausnahmen pro Woche | Wie viele Fälle aus dem Flow fallen und vor allem welcher Art. Unterscheidet das System, das lernt, von dem, das nur durchhält. | Wöchentlich |
| Real gesparte Zeit vs. versprochene | Stunden, die wegfallen, minus neue Stunden für Prüfung und Wartung, gegen das, was im Angebot stand. Die einzige Stelle, an der das Versprechen auf die Daten trifft. | Monatlich |
| Kosten pro Fall | Alles, was das System kostet — Lizenzen, Tokens, Wartung, verbleibende Menschenzeit —, geteilt durch die verarbeiteten Fälle. | Monatlich |
Die Reihenfolge ist kein Zufall: Die ersten beiden sind Betriebskennzahlen und werden im wöchentlichen Jour fixe gelesen; die letzten beiden sind Geschäftskennzahlen und gehören ins Steuerungsgremium. Vermischt man sie, passiert das Übliche — das Gremium diskutiert Einzelausnahmen, und das technische Team streitet sich mit einer Kostenzahl, an der es nichts ändern kann.
Wie du den Anteil „läuft allein durch" zählst, ohne dich selbst zu täuschen
Die Kennzahl der Fälle, die von Anfang bis Ende ohne Eingriff durchlaufen, haben nicht wir erfunden: Sie kommt aus der Finanzwelt, wo seit Jahrzehnten Straight-Through Processing gemessen wird — die Transaktion, die ohne manuellen Eingriff abgewickelt wird — und wo das keine Eitelkeitszahl ist, sondern etwas, das abgerechnet wird: Banken berechnen Gebühren für Zahlungen, die nicht allein durchlaufen, oder legen die Kosten der manuellen Nachbearbeitung auf die um, die ihnen Anweisungen in schlechter Qualität schicken. Die Ausnahme hat einen Preis, und deshalb versteckt sie dort niemand.
Die Falle dieser Kennzahl ist der Zähler, und fast alle tappen hinein: Als „läuft allein durch" zählt nur der Fall, der komplett und ohne jeden menschlichen Eingriff abgeschlossen wird. Ein Prozess mit automatisierter Erfassung und manueller Freigabe läuft nicht allein durch: Er läuft halb. Wenn der Flow die Daten aus der Rechnung extrahiert, aber jemand auf Freigeben klicken muss, ist das ein assistierter Fall, kein automatischer. Und wenn du den Anteil misst, indem du den automatisierten Teil der Strecke zählst statt der abgeschlossenen Fälle, bekommst du wunderschöne 90 %, die mit dem Gefühl von niemandem übereinstimmen, der dort arbeitet — und genau diese Dissonanz zwischen Kennzahl und Alltag zerstört die Glaubwürdigkeit der gesamten Messung.
Die Ausnahmen: die Kennzahl, die sagt, ob das System besser wird oder nur durchhält
Wenn du jede Woche nur auf eine Zahl schauen dürftest: auf diese. Der Anteil, der allein durchläuft, sagt dir, wo du stehst; die Ausnahmen sagen dir, wohin du gehst. Und der Trick ist, nicht bei der Summe stehen zu bleiben: zwanzig Ausnahmen diese Woche und zwanzig in der letzten können zwei gegensätzliche Lagen sein, je nachdem, welcher Art sie sind.
Sortiere sie in drei Körbe — die zugleich die drei Gründe sind, warum ein Fall den automatischen Weg verlässt: Es fehlt Information, die Information kommt in einem Format an, das die Maschine nicht versteht, oder der Fall fällt aus den Regeln, die automatisiert werden sollten:
- Unvollständige oder schmutzige Daten. Der Fall kommt ohne das an, was gebraucht wird. Das repariert man fast nie in der Automatisierung: Man repariert es flussaufwärts, im Formular, in der Vorlage oder beim Lieferanten, der die Datei falsch schickt. Wenn dieser Korb wächst, hast du ein Eingangsproblem im KI-Kostüm.
- Legitimer Fall außerhalb der Regeln. Das System tut gut daran, ihn nicht anzufassen: eine Retoure nach Frist, ein Betrag über dem Limit, ein Kunde mit Sonderkonditionen. Diese Ausnahmen sollten nicht auf null sinken. Sie sind das Design bei der Arbeit.
- Systemfehler. Die Integration ist ausgefallen, das Modell hat etwas Unbrauchbares zurückgegeben, der Flow blieb auf halber Strecke stehen. Nur diese zählen als Schuld: Jeder braucht Namen, Ursache und Fix, und derselbe sollte nicht zweimal auftauchen. Sie rechtzeitig zu bemerken ist eine andere Sache mit eigener Mechanik: Fehler in KI-Automatisierungen erkennen.
Die Lesart ist eindeutig. Sinkt Korb drei, während zwei stabil bleibt, reift das System: Du hast Fehler geschlossen, und was bleibt, ist die Grenze, die du bewusst nicht überschreiten wolltest. Bleibt Korb drei Monat für Monat flach, wird das System nicht besser — es hält durch, und jemand bezahlt dieses Durchhalten mit seiner Zeit. Und wächst Korb eins, liegt das Problem nicht in deiner Automatisierung: Es liegt bei dem, der dir die Daten schickt.
Hier taucht die Ausgabe auf, die nie budgetiert wird: die Zeit für das Bearbeiten von Ausnahmen. Das ist neue Arbeit, von der Automatisierung geschaffen, erledigt von jemandem, der sie vorher nicht hatte. Zählst du sie nicht, ist deine Ersparnis Fiktion; zählst du sie, entdeckst du oft, dass die Hälfte der versprochenen Ersparnis von der Schlange der Sonderfälle aufgefressen wird. Genau dieses Mitzählen macht aus einer Messung eine Messung.
Nachschärfen, neu bauen oder abschalten: das Entscheidungskriterium
Messen ohne vorher festgelegtes Entscheidungskriterium ist Zahlensammeln. Das Kriterium muss aufgeschrieben sein, bevor du auf die Zahlen schaust — sonst wird die Zahl zugunsten dessen ausgelegt, was ohnehin schon beschlossen war — und es hat genau drei Ausgänge.
| Was du siehst | Was es bedeutet | Was du tust |
|---|---|---|
| Der Anteil, der allein durchläuft, ist vernünftig, und die Ausnahmen stammen fast alle aus Korb 2 (außerhalb der Regeln). | Das System macht seine Arbeit, und die Grenze sitzt richtig. | Nachschärfen. Regeln nur dann Fall für Fall erweitern, wenn das Volumen dieser Art den Aufwand rechtfertigt. Kleine, getestete Änderungen. |
| Korb 3 (Fehler) sinkt seit drei Monaten nicht, und immer an derselben Stelle. | Das ist kein Bug: Das ist ein Designproblem des Flows. Weiterflicken hält noch ein Quartal. | Diesen Teil neu bauen. Ein eng gefasstes Redesign kommt billiger als zwölf Patches, und es passiert mit Netz: siehe Änderungen testen, ohne die Automatisierung zu zerlegen. |
| Das Volumen des Prozesses ist eingebrochen, oder die Wartung kostet mehr Stunden, als sie spart, oder die Ausnahmen übersteigen mehrere Wochen in Folge die automatischen Fälle. | Was du hast, ist ein manueller Prozess mit einem automatischen Schritt, der im Weg steht und weiter Lizenzen, Meldungen und Aufmerksamkeit frisst. | Abschalten. Ausschalten und dokumentieren, warum. Der am seltensten genutzte Ausgang und der, der am meisten Geld zurückholt. |
Die dritte Zeile ist die unangenehme. Eine Automatisierung abzuschalten fühlt sich an wie das Eingeständnis, dass sie nichts taugte — also bleibt der Flow „für alle Fälle" an und wandert in die Zählung der Zombie-Automatisierungen: die, die laufen, kosten und niemandem mehr nützen. Rechtzeitig abzuschalten ist kein Scheitern des Projekts — es ist der einzige Beweis, dass die Messung überhaupt etwas bewirkt, denn eine Messung, die nur frühere Entscheidungen bestätigen kann, ist keine Messung, sondern eine Zeremonie.
Wie du die Messung noch diese Woche aufsetzt
Nichts davon braucht ein neues Werkzeug. An einem Nachmittag, in dieser Reihenfolge: Definiere, was als „ohne Eingriff abgeschlossener Fall" zählt, und schreib es auf, denn diese Definition ist 80 % der Verlässlichkeit von allem Weiteren; zieh aus der Ausführungshistorie die Fälle der letzten vier Wochen und sortiere sie in allein durchgelaufen / Ausnahme, die Ausnahme mit einem der drei Körbe etikettiert; notiere einen Monat lang die Zeit, die das Team für Ausnahmen und Wartung aufwendet, auch grob geschätzt, denn das ist die Seite, die niemand hat; und bau die Kosten pro Fall mit der echten Rechnung, nicht mit der geschätzten. Vier Zahlen, ein Tabellenblatt, fünfzehn Minuten jeden Montag.
Und eine Warnung zum Takt: Die wöchentliche Messung dient dem Betreiben, nicht dem Urteilen. Eine schlechte Woche bedeutet gar nichts — es kam ein seltsamer Stapel herein, es gab einen Ausfall, die Person, die sonst alles löst, war im Urlaub. Die Entscheidung über Nachschärfen, Neubauen oder Abschalten fällt mit drei Monaten Daten vor sich, nie mit einer Kurve über sieben Tage. Diese Disziplin — oft hinschauen, langsam entscheiden — ist tatsächlich die Hälfte der Wartung einer Automatisierung: Die andere Hälfte ist, etwas mit dem zu tun, was die Messung dir sagt.
Die ehrliche Grenze: Das hier ist für alle geschrieben, die ein paar Flows und ein Tabellenblatt haben. Wenn darunter Agenten live entscheiden, mit Token-Kosten, die ohne Vorwarnung explodieren, und Qualität, die im Stillen abrutscht, ist die Messung kein Wochenblatt mehr, sondern Instrumentierung mit Traces und Alarmen: Das ist KI im Produktivbetrieb überwachen. Und wenn du willst, dass Baseline, die vier Kennzahlen und der Quartalsreview auf deinen aktuellen Flows aufgesetzt werden und von jemandem betrieben, der nicht du ist, dann ist das Automatisierung von Operations: die Zahl, jeden Monat, ohne dass du daran denken musst, sie einzufordern.