Wenn die Software stimmt, aber niemand sie benutzt

Warum Einführungstage trügen

Der Einführungstag läuft in der Regel gut. Der Trainer erklärt, die Teilnehmenden schauen zu, jemand stellt eine Frage, die Antwort macht Sinn. Am Ende nicken alle, und die Rückmeldungen fallen positiv aus.

Drei Wochen später sitzt dieselbe Person allein vor dem Bildschirm. Die Aufgabe ist dringend. Der Trainer ist nicht erreichbar. Und das Formular sieht irgendwie anders aus als damals — oder genau gleich, aber die Situation dahinter ist eine andere.

Das ist kein Einzelfall. Das ist der Normalfall.

Was die Schulungssituation verbirgt

Ein Schulungstermin ist eine Ausnahmesituation. Die Bedingungen unterscheiden sich in fast jeder Hinsicht vom echten Arbeitstag:

Jemand erklärt — die echte Arbeit passiert allein.
Die Aufgabe ist eine Übung — keine echten Konsequenzen, keine Ungeduld des Kunden.
Die Daten sind bereinigt oder erfunden — kein halbfertiger Eintrag aus dem Vortag, kein Sonderfall, den niemand im Schulungsraum kennt.
Fragen werden sofort beantwortet — der Trainer sitzt daneben.
Es gibt keine Unterbrechungen — kein Telefon, keine parallele Aufgabe, keine Deadline in zwanzig Minuten.

Unter diesen Bedingungen lernt man, einer Demonstration zu folgen. Man lernt nicht, eine Aufgabe selbständig zu lösen. Der Unterschied ist erheblich — und er wird am Einführungstag selten sichtbar.

Was Menschen in der Schulung verstanden haben, trägt sie oft bis zum zweiten oder dritten Schritt des echten Prozesses. Dann endet das Erinnerte, und der Rest fühlt sich neu an.

Ein konkretes Beispiel: Eine Mitarbeiterin im Maklerbüro lernt im Schulungsraum, wie sie ein neues Objekt anlegt. Sie klickt mit, nickt, stellt eine Frage zur Bildergröße. Zwei Tage später sitzt sie mit einem echten Exposé und einem wartenden Eigentümer vor der Eingabemaske. Sie weiß nicht mehr, ob sie zuerst den Grundriss hochlädt oder zuerst die Adresse einträgt. Kein Fehler, kein Missverständnis — nur die Lücke zwischen dem gezeigten Weg und der eigenen Situation.

Hinzu kommt: Wer an einem Schulungstag zehn neue Funktionen erklärt bekommt, erinnert am nächsten Morgen vielleicht drei. Nicht weil er unaufmerksam war, sondern weil Zuschauen und selbständiges Handeln zwei verschiedene Dinge sind. Das Gehirn speichert, was es geübt hat — nicht was es beobachtet hat.

Der Einführungstag gibt den Verantwortlichen das Gefühl, dass die Einführung erledigt ist. Genau das ist sein eigentliches Risiko: Er schließt eine Phase ab, die noch nicht begonnen hat.

Was Mitarbeiter tun, wenn die Software nicht passt

Sie benutzen sie trotzdem. Das ist der entscheidende Punkt. Wer keine Wahl hat, findet Wege — und diese Wege bleiben meistens unsichtbar für alle, die nicht täglich daran sitzen.

Der häufigste Weg ist die parallele Liste. Eine Tabellenkalkulation auf dem Desktop, die nicht im System steht. Ein geteiltes Dokument in einem Messenger, in dem die Kolleginnen und Kollegen vermerken, was das System nicht abbildet: welcher Auftrag noch offen ist, welcher Kunde auf einen Rückruf wartet, welche Unterlagen noch fehlen. Diese Listen entstehen nicht aus Nachlässigkeit. Sie entstehen, weil das System eine Frage nicht beantwortet, die jeden Tag gestellt werden muss.

Die stille Abkürzung

Daneben gibt es die stummen Umgehungen, die niemand benennt, weil sie sich nach einer Weile wie normales Arbeiten anfühlen. Ein Feld wird leer gelassen, weil der Pflichtschritt dahinter zu lang dauert. Ein Status bleibt auf „in Bearbeitung", weil das Setzen auf „abgeschlossen" fünf weitere Klicks erzwingt, von denen keiner etwas verändert, was der Mitarbeiter sehen kann. Eine Funktion wird schlicht nicht benutzt, weil sie beim letzten Mal nicht das getan hat, was sie sollte — und niemand nachgefragt hat, ob das ein Fehler war oder so gedacht.

Was bei der Einarbeitung weitergegeben wird

Das Folgenreichste passiert, wenn neue Mitarbeiterinnen und Mitarbeiter eingearbeitet werden. Was sie lernen, ist nicht, wie das System funktioniert. Was sie lernen, ist, wie das Team das System benutzt — also die Abkürzungen, die offenen Tabs, die parallelen Listen. Der offizielle Prozess und der gelebte Prozess wachsen auseinander, und das Wachstum ist still, weil es niemanden gibt, dem es gemeldet werden müsste.

Felder, die nie ausgefüllt werden, obwohl sie Pflichtfelder sein sollten
Vorgänge, die im System als offen gelten, aber längst abgeschlossen sind
Daten, die doppelt gepflegt werden — einmal im System, einmal anderswo
Funktionen, die nur eine Person im Team kennt und nutzt, weil sie Zeit hatte, sie auszuprobieren

Keines davon ist ein Zeichen schlechten Willens. Es sind Zeichen einer Software, die an bestimmten Stellen mehr kostet als sie gibt — und von Menschen, die trotzdem ihre Arbeit erledigen wollen.

Wo Bedienprobleme unsichtbar bleiben

Wer eine Fachsoftware einführt, bekommt selten zu hören, dass sie sich schlecht bedienen lässt. Nicht weil die Probleme fehlen — sondern weil niemand sie meldet.

Das hat einen einfachen Grund: Wer täglich mit einem System arbeiten muss, gewöhnt sich an seine Eigenheiten. Nicht im Sinne von Akzeptanz, sondern im Sinne von Anpassung. Die Kollegin, die einen bestimmten Schritt immer zweimal ausführt, weil er beim ersten Mal nicht zuverlässig übernommen wird, hat aufgehört, das als Problem wahrzunehmen. Es ist ihr Arbeitsablauf geworden.

Workarounds sind stille Aussagen

In fast jedem Team mit einer eingeführten Fachsoftware gibt es eine inoffizielle Anleitung, die nirgendwo steht. Neue Mitarbeiter lernen sie von alten. „Mach das lieber über diesen Weg, der andere hat manchmal Probleme." Oder: „Trag das erst in die Tabelle ein, dann übertrag es am Ende des Tages." Diese Sätze sind keine Tipps — sie sind dokumentierte Bedienprobleme, die sich in mündliche Überlieferung verwandelt haben.

Solange Workarounds funktionieren, werden sie nicht eskaliert. Die Arbeit kommt trotzdem raus. Das System gilt als stabil.

Wer meldet, muss beweisen

Selbst wer ein Problem benennen möchte, scheitert oft an der Beschreibung. „Es fühlt sich umständlich an" ist kein Ticket, das jemand aufnimmt. Der Hinweis, dass man für eine bestimmte Aufgabe dreimal durch verschiedene Ansichten navigieren muss, klingt kleinteilig, solange nicht jemand nachzählt, wie oft das pro Tag passiert.

Bedienprobleme sind selten dramatisch genug für eine Meldung — und zu kleinteilig für eine Eskalation. Sie leben in der Summe: zehn Sekunden hier, eine Fehlentscheidung dort, ein verlorenes Ergebnis, das neu eingegeben werden muss. Einzeln sind sie unsichtbar. In der Woche summieren sie sich auf Stunden.

Das Feedback, das nie ankommt

Rückmeldungen über die Bedienbarkeit einer Pflichtanwendung folgen einem anderen Muster als bei Software, die man freiwillig nutzt. Wer eine App als Verbraucher unbequem findet, hört auf, sie zu benutzen. Wer eine Fachanwendung unbequem findet, benutzt sie trotzdem — und spricht mit der Person neben sich, nicht mit der Stelle, die das System verantwortet.

Das bedeutet: Die Stelle, die entscheidet, ob und was sich ändert, hört von den Problemen als letzte. Nicht aus Böswilligkeit, sondern weil die Rückmeldewege für diesen Typ von Rückmeldung nicht vorgesehen sind. Eine Jahresbefragung erfasst keine Reibung, die sich in zwei Klicks versteckt.

Welche Stellen im Tagesablauf besonders viel Reibung erzeugen

Nicht jeder Moment im Arbeitstag ist gleich empfindlich. Es gibt Situationen, in denen eine Sekunde Verzögerung kaum auffällt — und Situationen, in denen eine unerwartete Abfrage ausreicht, um aus dem Rhythmus zu kommen. Reibung in Software entsteht fast immer an denselben fünf Stellen.

Der Moment direkt nach einem Gespräch

Ein Anruf endet. Eine Besichtigung ist vorbei. Eine Kundin hat gerade zugesagt. Jetzt müsste jemand das Besprochene festhalten — und zwar sofort, solange die Details noch präsent sind. Aber das Programm erwartet zuerst eine Zuordnung, dann eine Kategorie, dann ein Pflichtfeld, das für diesen Fall eigentlich nicht passt. Bis alles eingetragen ist, sind drei Minuten vergangen. Das passiert dreißigmal pro Woche. Was in dieser Zeit verloren geht, sind keine Datenpunkte — es ist die Konzentration, die danach fehlt.

Aufgaben, die sich täglich wiederholen

Wiederkehrende Schritte müssten mit der Zeit schneller werden. In vielen Systemen werden sie es nicht, weil jeder Durchlauf denselben Weg verlangt: denselben Klick, dieselbe Bestätigung, dieselbe Rückfrage. Wer täglich zwanzig Vorgänge gleicher Art bearbeitet, weiß nach einer Woche auswendig, welche Felder er überspringen will — und kann es trotzdem nicht.

Der Griff zur Software während eines Gesprächs

Jemand ruft an und fragt nach dem Stand eines Auftrags, einer Einheit, eines Termins. Die Antwort liegt im System. Die Person am Telefon wartet. Wer jetzt suchen muss — weil die Übersicht unübersichtlich ist, weil der Name nicht als Suchbegriff funktioniert, weil die letzte Notiz drei Ebenen tief liegt — spricht währenddessen mit halbem Ohr. Das Gespräch leidet. Die Auskunft auch.

Massenpflege nach einer Änderung

Ein Stichtag verschiebt sich. Eine Kategorie wird umbenannt. Ein Zuständiger wechselt. Was in der Besprechung nach einer Kleinigkeit klingt, bedeutet im System: vierzig Datensätze öffnen, ändern, speichern, weiter. Wer das einmal erlebt hat, zieht die nächste Änderung so lange hinaus, bis sie wirklich nicht mehr aufzuschieben ist. Das sind keine Faulheit und keine Nachlässigkeit — das ist eine rationale Reaktion auf unverhältnismäßigen Aufwand.

Der Montag nach einem langen Wochenende

Wer drei Tage nicht im System war, muss sich neu orientieren. Was war offen? Was wurde inzwischen erledigt? Was wartet noch auf eine Rückmeldung? Systeme, die diesen Wiedereinstieg nicht unterstützen, zwingen dazu, sich diese Übersicht selbst zu bauen — aus Erinnerung, aus Notizen, aus einem Blick in den E-Mail-Verlauf. Das dauert. Und wer sich nicht sicher ist, ob er etwas übersehen hat, arbeitet den Rest des Vormittags mit einem leichten Vorbehalt im Hinterkopf.

Diese fünf Stellen sind keine Ausnahmen. Sie gehören zum normalen Arbeitstag. Und sie sind die Orte, an denen eine Software zeigt, ob sie für die Arbeit gebaut wurde — oder nur für den Tag, an dem jemand sie vorgeführt hat.

Was eine zweite Einführung nicht heilt

Wenn eine Software nach sechs Monaten noch nicht genutzt wird, ist der erste Reflex oft derselbe: noch eine Schulung. Ein Nachmittag, alle zusammen, diesmal mit mehr Zeit für Fragen. Der Gedanke dahinter ist verständlich — wenn jemand etwas nicht benutzt, hat er es vielleicht nicht richtig verstanden.

Aber Bedienprobleme in Fachsoftware entstehen selten aus mangelndem Verständnis. Sie entstehen aus mangelnder Passung. Wer nach dem ersten Einführungstag aufgehört hat, die Software zu öffnen, hat in den meisten Fällen nicht vergessen, wie es geht. Er hat festgestellt, dass es so, wie es geht, für seinen Alltag nicht taugt.

Was in der Schulung nicht vorkommt

Eine Einführung zeigt, wie die Software funktioniert — an einem aufgeräumten Beispieldatensatz, ohne Zeitdruck, ohne das Telefon, das gleichzeitig klingelt. Sie zeigt den Idealfall. Der Idealfall ist der seltenste Fall im Arbeitsalltag.

Was nicht gezeigt wird: Wie man mit der Software umgeht, wenn dreißig Datensätze gleichzeitig geändert werden müssen. Was passiert, wenn eine Eingabe gespeichert wurde, die so nicht stimmt. Wie man einen halbfertigen Vorgang unterbricht, weil ein Kunde in der Leitung ist, und wie man danach wieder weiß, wo man war. Genau dort entstehen die Reibungsstellen, die dazu führen, dass jemand wieder zur Tabelle greift.

Die Schulung zeigt Einzelfälle. Der Arbeitsalltag besteht aus Ausnahmen.
Die Schulung setzt voraus, dass man die Aufgabe kennt. Das eigentliche Problem ist oft, dass die Software die Aufgabe anders schneidet als der Mensch, der sie erledigt.
Die Schulung endet. Die Gewohnheit, die sich in den sechs Monaten davor gebildet hat, bleibt.

Wenn der Umweg schneller ist als der richtige Weg

Es gibt in fast jedem Unternehmen jemanden, der weiß, wie man mit einer bestimmten Exportfunktion eine Aufgabe in drei Minuten erledigt, für die die Software eigentlich zehn Schritte vorsieht. Dieser Umweg ist kein Zeichen von Unwissen. Er ist das Ergebnis von Erfahrung. Und er wird durch eine zweite Schulung nicht aufgegeben — weil er funktioniert.

Eine zweite Einführung kann erklären, wie der vorgesehene Weg aussieht. Sie kann nicht erklären, warum der vorgesehene Weg besser sein soll als der, der seit Monaten zuverlässig klappt. Wer das nicht beantworten kann, macht aus der Schulung eine Übung in Überzeugungsarbeit — und verliert sie.

Das ist keine Kritik an Schulungen. Es ist eine Beschreibung dessen, was sie leisten können und was nicht. Eine Einführung vermittelt Wissen. Sie verändert keine Abläufe, die sich bereits bewährt haben — auch dann nicht, wenn diese Abläufe aus Sicht der Software falsch sind.