Warum gute Systeme still umgangen werden

Drei Wochen nach dem Go-live eines Abgleichssystems 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. Eine der erfahrensten Sachbearbeiterinnen hatte neben dem System eine Tabelle geöffnet. Jeden Abgleich, den das System vorschlug, übertrug sie dorthin und prüfte ihn von Hand, bevor sie ihn bestätigte.

Sie sträubte sich nicht gegen Veränderung. Sie machte diese Arbeit seit Jahren, sie war für die Richtigkeit verantwortlich, 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 sprechen deshalb nicht mehr von einem Akzeptanzproblem. Es geht um die richtige Dosierung von Vertrauen, und anders als Akzeptanz lässt sich die messen und gezielt beeinflussen.

Ziel ist Vertrauen in der richtigen Dosis

Es geht nicht darum, dass Menschen dem System vertrauen. Sie sollen ihm genau 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 Tabelle neben dem Bildschirm 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 weder das eine noch das andere. 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.

Die Nachprüfquote. Wie oft Mitarbeitende den Originalbeleg, den Datensatz im ERP oder eine eigene Datei öffnen, bevor sie einen Vorschlag bestätigen, den sie auch direkt hätten übernehmen können. 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. Sie zeigt genau die Segmente, in denen sich das System in den Augen des Teams noch nicht bewährt hat.

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. Das ist die wichtigste Kennzahl, und kaum ein Projekt misst sie. 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 jede Präsentation.

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: eine Mindestzahl an Fällen je Segment, keine Abweichung in einem zahlungsrelevanten Feld, bei der das System falsch lag, und jede Abweichung besprochen. Die Segmente verlassen den Shadow-Betrieb einzeln, sobald sie die Kriterien erfüllen, und die alte Arbeitsweise wird genauso abgelöst, Segment für Segment, nie zu einem festen Stichtag. 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. Jeder Fall wird mit einem dokumentierten Ergebnis abgeschlossen.

• Das System lag falsch. Eine Regel oder ein Mapping wird angepasst, innerhalb von Tagen, nicht Wochen. Hier entscheidet sich die Korrekturlatenz.
• 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 sind wertvoller als alle anderen.
• 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 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 das Vertrauen des Teams verdient.

Die Fachleute übernehmen die Regeln

Die eigentliche Ursache dafür, dass Systeme umgangen werden, ist ein Rollenwechsel, den niemand ausgesprochen hat. Vor dem System war die erfahrene Sachbearbeiterin diejenige, die wusste, wie man eine schwierige Zahlung zuordnet. Danach war sie Anwenderin eines Werkzeugs, das ihre bisherige Arbeit erledigte, mit der vagen Pflicht, es zu kontrollieren. Das ist eine Herabstufung, 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 Belegformate 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

Jedes Team im operativen Geschäft fragt 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. Ein System, das auf die Korrekturen von Menschen angewiesen ist, die sich von ihm bedroht fühlen, wird diese Korrekturen nicht bekommen.

Außerdem bitten wir darum, Durchsatzziele während der Umstellung auszusetzen. Wer an Fällen pro Stunde gemessen wird, ignoriert verständlicherweise ein System, das ihn während der Einarbeitung bremst.

Vertrauen wächst mit der Korrekturgeschwindigkeit

Die Tabelle neben dem Bildschirm war das Aufschlussreichste, was wir in diesem Projekt gesehen haben. Sie markierte die Fälle, in denen sich das System noch nicht bewährt hatte, und sie zeigte uns, dass die Korrekturen der Sachbearbeiterin zu lange brauchten, um etwas zu bewirken. Sobald eine Korrektur das System innerhalb weniger Tage veränderte, öffnete sie die Tabelle nicht mehr. Niemand musste sie darum bitten.