Wie gute Systeme das Vertrauen ihrer Nutzer gewinnen

Drei Wochen nach dem Go-live eines Systems für Wareneingänge 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. Jeden Wareneingang, den das System bestätigte, prüfte sie von Hand noch einmal gegen die Lieferung: 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 der richtigen Dosierung von Vertrauen, denn Vertrauen lässt sich messen und gezielt gestalten. Es ist auch ein Kontrollproblem. Die Kontrolle in der Prozessdokumentation war nicht die Kontrolle, die tatsächlich wirkte: 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 in der richtigen Dosis

Ziel ist, dass Menschen dem System so weit vertrauen, wie es das verdient, Fall für Fall. Zu viel Vertrauen führt dazu, dass Vorschläge durchgewinkt werden. Das ist eine Frage der Gestaltung des Freigabebildschirms. Zu wenig Vertrauen führt zur ausgedruckten Liste und zu einem Team, das jede Arbeit doppelt macht. Das ist eine Frage der Organisation rund um das System, und um die geht es hier. 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 Arbeitssegment und je Team, nie je Person. In jenem Projekt hatten wir nur die eigenen Kennzahlen des Systems beobachtet, und deshalb brauchte es drei Wochen und einen Vormittag vor Ort, um die ausgedruckte Liste zu finden. Jede dieser beiden Kennzahlen hätte sie in den ersten Tagen gezeigt.

Die Nachprüfquote. Wie oft Mitarbeitende den Lieferschein, den Datensatz im ERP oder eine eigene Liste öffnen, bevor sie einen Vorschlag bestätigen, den sie auch direkt hätten übernehmen können. Das meiste davon ergibt sich aus Daten, die das System bereits hat: geöffnete Belegansichten, erstellte Exporte, die Zeit zwischen dem Erscheinen eines Vorschlags und seiner Bestätigung und Änderungen, die direkt im ERP statt über den Workflow vorgenommen werden. Eine hohe Nachprüfquote in einem Segment, in dem das System zuverlässig richtig liegt, bedeutet: Das Vertrauen hinkt den Belegen hinterher. Das ist eine wertvolle Information, kein Verhalten, das man abstellen muss.

Die Korrekturlatenz. 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 anpasst. Von den beiden ist es die, auf die wir am genauesten achten. Korrigiert eine Fachkraft denselben Fehler dreimal und nichts passiert, zieht sie zu Recht den Schluss, dass ihre Korrekturen nichts bewirken, und prüft alles. Wird die Regel innerhalb weniger Tage angepasst und sieht sie den Fehler verschwinden, wächst das Vertrauen schneller als durch eine Präsentation.

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.

Das Korrekturprotokoll hält beide Daten fest, und jede Korrektur, die länger als eine Woche offen ist, kommt in die wöchentliche Besprechung, mit dem Namen der Person, die für die Lösung zuständig ist.

Der Shadow-Betrieb endet nach Kriterien, die das Team mitbestimmt hat

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

Shadow-Betrieb ist verbreitet. Ob er wirkt, hängt davon ab, wie er endet. Die Ausstiegskriterien vereinbaren wir vor dem Start mit dem Team und dem Prozessverantwortlichen: wie viele Fälle jedes Segment durchlaufen muss, welche Abweichungen ein Segment ausschließen, und eine Besprechung jeder Abweichung. Die Segmente verlassen den Shadow-Betrieb einzeln, sobald sie die Kriterien erfüllen, und die alte Arbeitsweise wird genauso abgelöst. Zuerst gehen die Segmente live, in denen das System am stärksten ist, und die schwierigen folgen, wenn das Team eine Weile gesehen hat, dass es richtig liegt. So sieht das Team, wie sich die Nachweise 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 dokumentierten Ergebnis ab.

• Das System lag falsch. Eine Regel oder ein Mapping 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. In diesen Fällen stecken 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 Stammdatensatz war die Ursache. Das geht an die Quelle zurück und wird dort behoben.

Die Verteilung der vier Ergebnisse zeigt, wie weit das System ist. Anfangs sind die meisten Abweichungen in der Regel Systemfehler, später geht es überwiegend um Auslegungsfragen der Richtlinie. Sind Abweichungen selten und betreffen sie fast nur noch die Richtlinie, hat sich das System in diesem Segment 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 bucht. 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, wie auch immer der Projektplan es nennt.

Deshalb ändern wir die Rollen ausdrücklich. Die erfahrensten Mitarbeitenden werden verantwortlich für die Regeln und Ausnahmeursachen in ihrem Bereich. Sie geben Änderungen an Toleranzen frei, entscheiden, wie neue Etikettenformate von Lieferanten behandelt werden, und ihre Namen stehen an den Regeln. Die Genauigkeit des Systems wird zu ihrer Verantwortung und zu ihrem Erfolg, und Wissen, das bisher in einem einzelnen Kopf steckte, wird zu Regeln, die das ganze Team nachlesen kann.

Der Sponsor legt den Zweck schriftlich fest

Die meisten Teams im operativen Geschäft fragen sich, ob ein neues System es ersetzen soll. Beantwortet niemand die Frage, beantwortet das Team sie selbst. Vor dem Shadow-Betrieb 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, Durchsatzziele während der Umstellung auszusetzen. Wer an Wareneingängen 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 etwas zu bewirken. Sobald eine Korrektur das System innerhalb weniger Tage veränderte, druckte sie die Liste nicht mehr aus. Messen Sie die Korrekturlatenz ab der ersten Woche nach dem Go-live, und halten Sie sie unter einer Woche.