Wie gute Systeme das Vertrauen ihrer Nutzer gewinnen

Drei Wochen nach dem Go-live eines Systems zur Prüfung eingehender Lieferungen im Lager eines Medizinprodukteherstellers sahen seine Kennzahlen gut aus, aber das Team hatte nicht weniger zu tun. Wir verbrachten einen Vormittag mit dem Team, um den Grund zu finden. Die erfahrenste Lagerleiterin hatte neben dem System eine ausgedruckte Liste auf dem Tisch liegen. Jede Lieferung, die das System bestätigte, prüfte sie von Hand noch einmal: Chargennummern, Verfallsdaten, Mengen.

Sie sträubte sich nicht gegen Veränderung. Sie machte diese Arbeit seit Jahren, sie war für das verantwortlich, was ins Lager ging, und nichts im System zeigte ihr, wann sie sich darauf verlassen konnte. Also verließ sie sich nie darauf und prüfte alles. Das System funktionierte. Im Alltag wurde es trotzdem umgangen.

Wir behandeln das heute als Frage, wie gut Vertrauen zu den Belegen passt, denn Vertrauen lässt sich messen und gezielt gestalten. Es ist auch ein Kontrollproblem: Der Wirtschaftsprüfer testet die Bestätigungen des Systems, und die Prüfung, die zählte, fand auf einer ausgedruckten Liste statt, die niemand ablegt.

Ziel ist Vertrauen, das zu den Belegen passt

Ziel ist, dass Menschen dem System so weit vertrauen, wie es das verdient, Fall für Fall. Zu viel Vertrauen führt dazu, dass ohne Hinsehen freigegeben wird. Zu wenig führt zur ausgedruckten Liste und zu doppelter Arbeit. Schulungen lösen das selten. Menschen bilden ihr Vertrauen an Belegen aus ihren eigenen Fällen, nicht an Erklärungen, wie das System funktioniert.

Zwei Kennzahlen zeigen, wo Vertrauen fehlt

Vom ersten Tag nach dem Go-live an verfolgen wir zwei Kennzahlen, je Art von Arbeit und je Team, nie je Person. In jenem Lager hatten wir nur die eigene Genauigkeit des Systems beobachtet, und deshalb brauchte es drei Wochen und einen Vormittag vor Ort, um die Liste zu finden. Jede der beiden Kennzahlen hätte sie in den ersten Tagen gezeigt.

Wie oft nachgeprüft wird. Wie oft jemand den Lieferschein, den Datensatz im zentralen Geschäftssystem oder eine eigene Liste öffnet, bevor er einen Vorschlag bestätigt, den er auch direkt hätte übernehmen können. Das meiste ergibt sich aus Daten, die das System schon hat: geöffnete Belege, erstellte Exporte, die Zeit bis zur Bestätigung, Änderungen am Ablauf vorbei. Eine hohe Quote dort, wo das System zuverlässig richtig liegt, heißt: Das Vertrauen hinkt den Belegen hinterher. Das ist Information, kein Fehlverhalten.

Wie schnell eine Korrektur zählt. Die Zeit zwischen dem Moment, in dem ein Mensch das System korrigiert, und dem Moment, in dem das System sein Verhalten für diese Art von Fall ändert. Auf diese Zahl achten wir am genauesten. Korrigiert eine Fachkraft denselben Fehler dreimal und nichts passiert, zieht sie zu Recht den Schluss, dass ihre Korrekturen nicht zählen, und prüft alles. Wird die Regel innerhalb weniger Tage angepasst und sieht sie den Fehler verschwinden, wächst das Vertrauen schneller als durch jede Vorführung.

Die Forschung weist in dieselbe Richtung. Dietvorst, Simmons und Massey zeigten 2015, dass Menschen das Vertrauen in einen Algorithmus schneller verlieren als in einen Menschen, wenn sie beide denselben Fehler machen sehen, und ihn selbst dann meiden, wenn sie gesehen haben, dass er besser abschneidet als ein Mensch. Ihre Folgestudie in Management Science (2018) ergab, dass Menschen einen unvollkommenen Algorithmus deutlich eher nutzen, wenn sie sein Ergebnis anpassen können, und sei es nur ein wenig. Im Labor ist das ein Schieberegler. Im Betrieb ist es eine Korrektur, die bleibt.

Jede Korrektur, die länger als eine Woche offen ist, kommt in die wöchentliche Besprechung, mit dem Namen der zuständigen Person.

Der Probebetrieb endet nach Kriterien, die das Team mitbestimmt hat

Bevor das System irgendetwas selbst ausführt, läuft es in einem Probebetrieb neben dem Team mit, oft Shadow-Betrieb genannt: Es bearbeitet dieselben Fälle, seine Vorschläge werden protokolliert, und das Team arbeitet wie gewohnt weiter. Täglich werden die Vorschläge mit dem verglichen, was die Menschen tatsächlich getan haben.

Ob ein Probebetrieb wirkt, hängt davon ab, wie er endet. Die Kriterien für das Ende vereinbaren wir vor dem Start mit dem Team und dem Prozessverantwortlichen: wie viele Fälle jede Art von Arbeit durchlaufen muss, welche Abweichungen eine Art ausschließen, und eine Besprechung jeder Abweichung. Die Arten von Arbeit verlassen den Probebetrieb einzeln, sobald sie die Kriterien erfüllen, beginnend dort, wo das System am stärksten ist; die schwierigen folgen, wenn das Team eine Weile gesehen hat, dass es richtig liegt. So sieht das Team, wie sich Belege gegen einen Maßstab aufbauen, den es selbst mitbestimmt hat, statt dass ihm ein Go-live-Datum verkündet wird.

Jede Abweichung endet mit einem von vier Ergebnissen

In den ersten Monaten geht das Team einmal pro Woche mit einem Engineer jeden Fall durch, in dem System und Mensch zu unterschiedlichen Ergebnissen kamen, und schließt jeden mit einem festgehaltenen Ergebnis ab.

• Das System lag falsch. Eine Regel wird angepasst, innerhalb von Tagen, nicht Wochen.
• Der Mensch lag falsch. Meist eine Gewohnheit, die sich von der Richtlinie entfernt hat. Der Prozessverantwortliche entscheidet, ob sich die Gewohnheit oder die Richtlinie ändert, und informiert das Team.
• Beides war vertretbar. Der Prozessverantwortliche entscheidet, und die Entscheidung wird als Regel festgeschrieben. Das sind die ungeschriebenen Regeln, die bisher nur in den Köpfen existierten, und sie festzuhalten lohnt sich oft am meisten.
• Die Eingangsdaten waren das Problem. Ein Lieferantenbeleg oder ein falscher Eintrag in den Stammdaten des Unternehmens war die Ursache, und das wird an der Quelle behoben.

Anfangs sind die meisten Abweichungen in der Regel Systemfehler, später überwiegend Fragen der Richtlinie. Sind Abweichungen selten und betreffen sie fast nur noch die Richtlinie, hat sich das System für diese Art von Arbeit das Vertrauen des Teams verdient.

Die Fachleute übernehmen die Regeln

Eine tiefere Ursache dafür, dass Systeme umgangen werden, ist oft ein Rollenwechsel, den niemand ausgesprochen hat. Vor dem System war die erfahrenste Lagerleiterin diejenige, die wusste, wie man eine schwierige Lieferung einbucht. Danach war sie Anwenderin eines Werkzeugs, das ihre bisherige Arbeit erledigte, mit der vagen Pflicht, es zu kontrollieren. Das fühlt sich wie eine Herabstufung an.

Deshalb ändern wir die Rollen ausdrücklich. Die erfahrensten Mitarbeitenden werden verantwortlich für die Regeln und die häufigsten Ursachen von Ausnahmen in ihrem Bereich. Sie geben Änderungen daran frei, was als nah genug gilt, entscheiden, wie neue Etikettenformate von Lieferanten behandelt werden, und ihre Namen stehen an den Regeln. Die Genauigkeit des Systems wird zu ihrem Erfolg, und Wissen, das in einem einzelnen Kopf steckte, wird zu Regeln, die das ganze Team nachlesen kann.

Der Sponsor legt den Zweck schriftlich fest

Die meisten Teams fragen sich, ob ein neues System sie ersetzen soll, und beantwortet niemand die Frage, beantworten sie sie selbst. Vor dem Probebetrieb bitten wir den Sponsor, drei Dinge aufzuschreiben und mit dem Team zu teilen: was das Team künftig mehr tun wird, was weniger, und was das Unternehmen mit der gewonnenen Kapazität vorhat. Bei den Aufträgen, die wir annehmen, ist dieser Zweck Kapazität für Wachstum.

Außerdem bitten wir darum, Leistungsziele während der Umstellung auszusetzen. Wer an geprüften Lieferungen pro Stunde gemessen wird, hat gute Gründe, ein System zu meiden, das ihn während der Einarbeitung bremst.

Vertrauen wächst mit der Korrekturgeschwindigkeit

Am Ende gehörte die ausgedruckte Liste zum Aufschlussreichsten in diesem Lager. Sie markierte die Fälle, in denen sich das System noch nicht bewährt hatte, und sie zeigte, dass die Korrekturen der Lagerleiterin zu lange brauchten, um zu zählen. Sobald eine Korrektur das System innerhalb weniger Tage veränderte, druckte sie die Liste nicht mehr aus. Messen Sie ab der ersten Woche nach dem Go-live, wie schnell Korrekturen zählen, und halten Sie es unter einer Woche.