Wenn die Software mehr Zeit kostet als die Aufgabe

Was Ihre Mitarbeitenden in der Software wirklich tun — und wie lange

Wenn man einer Mitarbeiterin bei der Arbeit zuschaut — nicht bei einer Vorführung, sondern an einem normalen Dienstagnachmittag — sieht man Dinge, die in keiner Prozessbeschreibung auftauchen.

Sie öffnet ein Kundenkonto. Findet nicht, was sie sucht. Öffnet ein zweites Fenster. Kopiert eine Nummer. Wechselt zurück. Gibt dieselbe Nummer noch einmal ein, weil das Feld beim Wechsel geleert wurde.

Das dauert vierzig Sekunden. Niemand hat es erfasst.

Was die Uhr zeigt, wenn man sie anlässt

Für eine Sachbearbeiterin in der Hausverwaltung bedeutet „Betriebskostenabrechnung erstellen" auf dem Papier: Belege prüfen, Umlage berechnen, Schreiben versenden. In der Praxis bedeutet es außerdem: zwischen vier Masken navigieren, weil die benötigten Felder auf keine zusammenpassen. Eine Heizkostenposition drei Mal eingeben, weil das Programm nach jedem Pflichtfeld neu aufbaut. Einen Fehler vermuten, den man nicht überprüfen kann, weil die Ansicht keinen Verlauf zeigt.

Der eigentliche Rechenaufwand: zehn Minuten. Der Gesamtaufwand: fünfzig.

Der Unterschied liegt nicht in der Aufgabe, sondern im Weg durch das Programm.

Wege, die niemand bewusst geplant hat

Viele dieser Wege sind entstanden, nicht entworfen. Jemand hat herausgefunden, dass ein Vorgang funktioniert, wenn man ihn in dieser Reihenfolge durchführt. Diese Reihenfolge wurde an die Kollegin weitergegeben. Die Kollegin hat sie an die neue Mitarbeiterin weitergegeben. Keine dieser Personen weiß noch, warum die Reihenfolge genau so ist — sie wissen nur, dass es anders nicht geht.

Das ist kein Wissensverlust. Das ist Anpassung an ein Werkzeug, das sich selbst nicht angepasst hat.

Die Tätigkeiten, die in der Zeiterfassung unsichtbar bleiben

Suchen nach einem Vorgang, der unter einem anderen Begriff abgelegt wurde
Warten, bis eine Maske vollständig aufgebaut hat, bevor man weitermachen kann
Doppelte Eingaben, weil Felder beim Seitenwechsel nicht gespeichert werden
Notizen auf Papier, weil das Programm eine Zwischenstufe nicht kennt
Rückfragen an Kolleginnen — nicht weil die Aufgabe unklar ist, sondern weil das Programm den nötigen Stand nicht zeigt

Diese Tätigkeiten tauchen in keiner Auswertung auf. Niemand bucht Zeit auf „Maske neu aufgebaut" oder „Feld leer nach Navigation". Sie verschwinden im Block „Abrechnung", „Anfrage bearbeitet", „Pflege erledigt".

Wenn jemand fragt, wie lange eine Aufgabe dauert, nennt die Mitarbeiterin die Zeit, die sie dauern sollte — nicht die Zeit, die sie tatsächlich braucht. Den Unterschied hat sie längst aufgehört zu bemerken.

Warum Pflichtprogramme eine andere Reibung erzeugen als freiwillige Apps

Wer eine App auf dem Smartphone nicht mag, löscht sie. Wer eine Buchungsplattform umständlich findet, sucht eine andere. Das ist der stille Druck, der Hersteller von Konsumersoftware zur Verbesserung zwingt: Jede Nutzerin kann gehen, ohne Erklärung, ohne Termin, ohne Genehmigung.

Fachsoftware in Unternehmen funktioniert anders. Die Verwalterin, die täglich Betriebskostenabrechnungen eingibt, hat keine Wahl. Der Makler, der Objekte in das Verwaltungssystem pflegt, weil das Unternehmen es so verlangt, verlässt das System nicht. Er umgeht es — oder er gewöhnt sich an den Umweg, bis er ihn nicht mehr als Umweg wahrnimmt.

Das ist der entscheidende Unterschied: Bei freiwilliger Software signalisiert Abwanderung, dass etwas nicht stimmt. Bei Pflichtprogrammen bleibt diese Rückmeldung aus. Die Nutzerin bleibt, aber sie verliert täglich Zeit. Manchmal Minuten, manchmal eine halbe Stunde — verteilt über Eingabefelder, die in der falschen Reihenfolge kommen, Bestätigungen, die niemand braucht, Listen, die sich nicht filtern lassen.

Der Unterschied liegt nicht in der Qualität, sondern im Marktmechanismus

Es wäre falsch zu sagen, Fachsoftware sei schlechter gebaut als Konsumerprodukte. Oft ist sie technisch robuster, weil die Anforderungen präziser sind. Aber sie unterliegt einem anderen Ausleseprinzip: Gekauft wird sie von Entscheidern, benutzt wird sie von anderen. Die Person, die am Ende täglich auf „Speichern" klickt, war selten im Auswahlgespräch dabei.

Was folgt daraus, ist keine Bösartigkeit, sondern ein strukturelles Problem: Die Erfahrung derer, die das System täglich benutzen, fließt nicht automatisch in Entscheidungen zurück. Ob ein Formular drei Klicks zu viel hat, ob ein Pflichtfeld abgefragt wird, das niemand kennt, ob eine Fehlermeldung erscheint, die niemand versteht — das spüren die Nutzenden, aber es landet nicht dort, wo es etwas ändern könnte.

Konsumersoftware verliert Nutzerinnen sofort, wenn sie Reibung erzeugt — und gewinnt sie nur zurück, wenn sie sich verbessert.
Pflichtsoftware behält ihre Nutzerinnen unabhängig davon, ob sie gut ist oder nicht.
Der Aufwand, der durch schlechte Bedienung entsteht, wird deshalb selten gemessen — er wird gelebt.

Das bedeutet nicht, dass niemand klagt. Aber Klagen, die nichts verändern, verstummen irgendwann. Was bleibt, ist eine stille Anpassung: Die Sachbearbeiterin entwickelt eine Reihenfolge, in der sie Eingaben macht, die das System eigentlich anders vorsieht. Der Verwalter führt eine eigene Liste, weil der Bericht aus dem Programm die Frage, die sein Geschäftsführer stellt, nie vollständig beantwortet. Diese Anpassungen sind keine Lösung — sie sind der Beweis, dass das Problem noch da ist.

Gewöhnung als Messfehler: Wenn niemand mehr klagt, obwohl sich nichts verbessert hat

Es gibt einen Moment in jedem Softwareprojekt, an dem die Beschwerden aufhören. Nicht weil das Problem gelöst wurde, sondern weil sich niemand mehr vorstellen kann, dass es anders sein könnte. Diese Stille wird regelmäßig als Erfolg gelesen. Sie ist keiner.

Wer täglich mit einer Software arbeitet, die fünf Klicks braucht, wo zwei reichen würden, hört nach einigen Wochen auf, das zu benennen. Nicht weil es nicht mehr stört — sondern weil es zum Hintergrund geworden ist, wie das Rauschen einer Lüftung, das man beim Betreten des Raumes hört und nach zehn Minuten nicht mehr. Die Reibung ist noch da. Nur die Sprache dafür ist verschwunden.

Was aus Klagen wird, wenn niemand zuhört

In den ersten Wochen nach einer Einführung gibt es Rückmeldungen. Das Feld sitzt falsch. Die Liste lässt sich nicht sortieren. Der Speichern-Button ist nicht dort, wo man ihn erwartet. Dann, irgendwann, verstummt das. Wer fragt, bekommt zu hören: "Haben wir uns dran gewöhnt." Das klingt wie eine Aussage über Akzeptanz. Es ist eine Aussage über Resignation.

Was in dieser Zeit passiert: Die Mitarbeitenden entwickeln Umgehungswege. Sie exportieren Daten in eine Tabelle, um sie dort zu sortieren, bevor sie sie zurückschreiben. Sie merken sich, welche Felder man in welcher Reihenfolge ausfüllen muss, damit das System nicht abbricht. Sie rufen eine Kollegin an, weil der Vorgang sonst zwei Tage hängt. Diese Wege werden nirgendwo aufgeschrieben. Sie werden mündlich weitergegeben, beim Einarbeiten neuer Personen, wie ein lokales Wissen, das keiner aufgezeichnet hat, weil es selbstverständlich wirkt.

Die Metrik, die fehlt

Helpdesk-Tickets gehen zurück. Das wird in Berichten als Stabilisierung vermerkt. Was nicht vermerkt wird: wie viele Vorgänge täglich über eine Tabellenkalkulation laufen, die ursprünglich nur als Brücke gedacht war. Wie viele Felder routinemäßig doppelt gepflegt werden, weil die Synchronisation nicht zuverlässig ist. Wie lange der zweite und der dreißigste Arbeitstag in Wirklichkeit dauern — nicht der erste, an dem noch jemand zuschaut.

Gewöhnung lässt sich nicht aus Zufriedenheitsbefragungen ablesen. Wer fragt "Kommen Sie gut zurecht?", bekommt fast immer Ja — weil die Alternative bedeuten würde, das eigene Können infrage zu stellen. Die eigentliche Frage wäre eine andere: Was tun Sie, wenn etwas nicht so funktioniert, wie Sie es brauchen? Die Antworten darauf sind selten bequem.

Der unsichtbare Aufwand: Was in keinem Bericht auftaucht

Es gibt Arbeit, die in keiner Zeiterfassung erscheint, weil sie niemand als Arbeit wahrnimmt. Sie passiert in den Lücken: in dem Moment, in dem jemand eine Maske ein zweites Mal öffnet, weil unklar ist, ob die erste Eingabe gespeichert wurde. In dem Moment, in dem ein Kollege eine Exceldatei parallel offen hält, weil der Bericht in der Software die falsche Sortierung zeigt. In dem Moment, in dem jemand dreimal klickt und dann abbricht, weil er sich nicht sicher ist, ob das die richtige Schaltfläche ist.

Kein einzelner dieser Momente ist groß genug, um ihn zu melden. Zusammengenommen formen sie einen Teil des Arbeitstags, der nirgendwo auftaucht — weder in der Auslastungsstatistik noch im Supportlog noch im Jahresgespräch.

Was typischerweise dazugehört

Umwege, die irgendwann einmal eingeführt wurden, weil der direkte Weg nicht funktionierte, und die seitdem als "so macht man das" gelten — obwohl das ursprüngliche Problem längst behoben sein könnte.
Doppelprüfungen: Wer nicht sicher ist, ob eine Aktion tatsächlich ausgeführt wurde, prüft nach. Das kostet Zeit, die nirgendwo erfasst wird, weil sie kein eigener Schritt ist, sondern Teil eines anderen.
Das Einarbeiten neuer Kolleginnen und Kollegen in Workarounds, die offiziell nicht existieren. Wer einem neuen Teammitglied erklärt, dass man Feld X nie direkt befüllen darf, sondern immer zuerst Feld Y, gibt Wissen weiter, das keine Dokumentation festhält — und das eigentlich gar nicht existieren sollte.
Exportieren, um nachzusehen. Wenn jemand eine Liste aus der Software in ein Tabellenkalkulationsprogramm exportiert, nur um sie dort nach einem einzigen Wert zu durchsuchen, den die Software nicht direkt zeigt, ist das kein Nutzungsfehler. Es ist eine Anpassungsleistung, die täglich erbracht wird.

Das Tückische an diesem Aufwand ist nicht sein Umfang — es ist seine Verteilung. Drei Minuten hier, neunzig Sekunden dort, ein kurzes Zögern, ein zweiter Versuch. Kein Moment davon überschreitet die Schwelle, die jemanden dazu bringt, ihn anzusprechen. Genau deshalb taucht er in keiner Aufwandsschätzung auf, wenn über eine Systemanpassung nachgedacht wird.

Was auffällt, wenn man diesen Aufwand einmal sichtbar macht, ist oft weniger die Summe als die Frage, wie lange er schon anfällt. Nicht seit letzter Woche. Meistens seit dem Tag, an dem das System in Betrieb gegangen ist.

Was sich zeigt, wenn man einen Arbeitstag mitgeht statt ihn zu beschreiben

Wer wissen will, wie eine Software im Alltag wirklich läuft, sollte nicht fragen. Er sollte zusehen.

Das ist keine Kritik an den Mitarbeitenden. Es ist eine Eigenschaft jeder Gewohnheit: Was man täglich tut, beschreibt man nicht mehr — man tut es. Wer seit zwei Jahren denselben Bildschirm aufruft, um eine Zahl dort abzulesen und sie drei Felder weiter rechts einzutippen, hält das nicht für erwähnenswert. Es ist Arbeitsalltag.

Erst wenn jemand danebensitzt, wird es sichtbar. Nicht weil die Person etwas falsch macht. Sondern weil ein frischer Blick keine Gewöhnung mitbringt.

Was man typischerweise sieht

Fenster, die parallel geöffnet bleiben, weil keine einzelne Ansicht alle nötigen Informationen enthält
Notizzettel, handgeschriebene Listen oder offene Tabellen neben dem eigentlichen System
Wege durch die Software, die niemand so geplant hat — aber alle so gehen
Momente des Innehaltens: die Person wartet, bis eine Seite aufgebaut ist, oder klickt eine Meldung weg, ohne sie zu lesen

Diese Beobachtungen sind kein Vorwurf. Sie sind eine Beschreibung dessen, was in keinem Gespräch auftaucht — weil niemand erzählt, was er nicht mehr bemerkt.

Besonders auffällig ist der stille Umgang mit Fehlern. Nicht die Meldungen, die das System zeigt — sondern die kleinen Korrekturen, die die Person vornimmt, bevor es so weit kommt. Ein bestimmtes Feld wird in einer bestimmten Reihenfolge ausgefüllt. Ein Speichervorgang geschieht zweimal, weil einmal manchmal nicht reicht. Eine Kollegin wird kurz gefragt, bevor man auf „Bestätigen" drückt — nicht weil man unsicher ist, sondern weil man gelernt hat, dass dieser Schritt Konsequenzen hat, die sich schlecht rückgängig machen lassen.

Die Lücke zwischen Erleben und Benennen

Das Gespräch danach bringt andere Antworten als das Gespräch zuvor. „Hatten Sie den Eindruck, das hat gut funktioniert?" — „Ja, eigentlich schon." Und trotzdem hat man zwanzig Minuten lang zugesehen, wie jemand etwas auf Umwegen erledigt, das direkt hätte gehen können.

Das ist keine Unaufmerksamkeit. Es ist das Ergebnis von Anpassung. Der Mensch hat sich an die Software angepasst, nicht umgekehrt — und irgendwann hört er auf, das als Problem zu bezeichnen. Es ist einfach so.

Wer nur fragt, bekommt den angepassten Bericht. Wer zusieht, bekommt den ursprünglichen Ablauf — mit allen Umwegen, Wartepausen und stillen Korrekturen, die dazugehören. Die Lücke zwischen beidem ist selten dramatisch. Sie ist meistens klein, wiederkehrend und unsichtbar für alle, die drin stecken.