Massenpflege in Fachsoftware: Warum Korrekturen Tage dauern

Der Arbeitstag, der mit einer Liste beginnt

Manchmal liegt sie schon auf dem Schreibtisch, wenn man den Rechner hochfährt. Manchmal steht sie in einer E-Mail, manchmal hat man sie sich selbst am Vorabend notiert. Zwanzig Datensätze, dreißig, manchmal mehr. Alle betreffen dasselbe Feld — eine Adresse, ein Datum, eine Kategorie, die sich geändert hat. Die Aufgabe klingt nach einer Stunde. Sie wird den halben Tag dauern.

Das ist keine Übertreibung. Es ist eine Beschreibung, wie Massenpflege in vielen Systemen tatsächlich abläuft. Wer in einer Hausverwaltungssoftware fünfzig Einheiten auf eine neue Betriebskostengruppe umstellen will, öffnet die erste Einheit, sucht das richtige Feld, trägt den Wert ein, speichert, geht zurück zur Liste, öffnet die zweite. Und so weiter. Für zwanzig Datensätze ist das lästig. Für hundert ist es ein Arbeitstag.

Die Liste, die nicht kleiner wird

Was den Arbeitstag besonders zermürbt, ist nicht das einzelne Klicken. Es ist das Gefühl, dass die Liste nicht kürzer wird — oder zumindest nicht sichtbar kürzer. Man ist eine Stunde drin und hat dreißig von zweihundert erledigt. Der Rest wartet.

Solche Situationen entstehen häufig nach einem externen Ereignis:

• Ein Lieferant ändert seine Artikel- oder Preisstruktur und alle bestehenden Einträge müssen angepasst werden.
• Eine Behörde stellt auf neue Schlüssel um — Nutzungsarten, Zustandsklassen, Energieetiketten — und die alten Bezeichnungen gelten nicht mehr.
• Ein Kunde hat drei Niederlassungen, die bisher einzeln geführt wurden, und sie sollen jetzt einer gemeinsamen Gruppe zugeordnet werden.
• Der Steuerberater hat mitgeteilt, dass alle Belege eines Quartals einem anderen Konto zuzuordnen sind.

Keiner dieser Fälle ist ungewöhnlich. Alle zusammen erklären, warum manche Menschen montags mit einer Liste anfangen und freitags noch daran sitzen.

Wie sich der Tag anfühlt

Wer solche Arbeit kennt, beschreibt sie selten als schwierig. Sie ist nicht schwierig. Sie ist erschöpfend auf eine bestimmte Weise: Die einzelne Handlung fordert keine Konzentration. Aber die Summe der Handlungen fordert Zeit, die für anderes nicht zur Verfügung steht.

Und während man klickt und speichert und zurückgeht und wieder öffnet, läuft das Tagesgeschäft daneben. Anfragen kommen herein. Das Telefon klingelt. Irgendjemand braucht eine Auskunft. Die Liste wartet. Sie ist geduldig. Das ist das Problem.

Was auffällt, wenn man Menschen dabei zuschaut: Sie entwickeln Strategien. Sie markieren erledigte Zeilen in einer Tabelle, die sie parallel offen halten. Sie arbeiten in Blöcken, um den Fortschritt sichtbar zu machen. Sie notieren, wo sie aufgehört haben, weil eine Unterbrechung den Platz verloren gehen lässt. Das sind keine Arbeitstechniken. Das sind Behelfe für eine Situation, die das System ihnen nicht abnimmt.

Was aus einem Klick fünfzig Klicks macht

In vielen Fachsystemen gibt es eine Funktion, die auf dem Papier existiert und in der Praxis so gut wie unbenutzbar ist: die Sammelbearbeitung. Nicht weil sie nicht vorhanden wäre — sie ist da, irgendwo im Menü —, sondern weil sie nur für den Idealfall gebaut wurde.

Der Idealfall sieht so aus: Alle betroffenen Datensätze haben dasselbe Problem. Sie lassen sich mit einem einzigen Filter finden. Die Korrektur ist für jeden identisch. Dann funktioniert die Massenbearbeitung tadellos.

Der Alltag sieht anders aus.

Konkrete Situation: Eine Verwalterin hat dreißig Objekte, bei denen ein bestimmter Nebenkostenanteil falsch eingetragen ist — nicht bei allen gleich hoch, sondern je nach Einheit unterschiedlich. Der Filter zeigt ihr alle dreißig. Aber die Korrektur muss sie für jede Einheit separat eingeben, weil das Feld nicht in der Sammelansicht editierbar ist. Also: dreißig Mal öffnen, dreißig Mal scrollen, dreißig Mal eingeben, dreißig Mal speichern. Dann nochmal prüfen, ob sich der Wert auch wirklich geändert hat — denn bei fünf Einträgen hat das System die Änderung kommentarlos verworfen.

Oder der Makler, der nach einer Preisverhandlung zwölf Exposés aktualisieren muss. Nicht wegen zwölf verschiedener Objekte, sondern weil das System pro Bild, pro Variante und pro Vertriebskanal einen eigenen Eintrag führt. Was wie ein Objekt aussieht, ist im System vier verschiedene Datensätze. Ein Klick ist jetzt achtundvierzig.

Das ist kein Randfall und kein Anwenderfehler. Es ist das Ergebnis einer Softwarearchitektur, die Daten in Einheiten speichert, die für die Maschine sinnvoll sind — nicht für den Menschen, der am Nachmittag fünfzig Korrekturen durchführen muss.

Wenn die Sammelansicht nicht trägt

Viele Systeme bieten eine Listenansicht an, in der Datensätze nebeneinander sichtbar sind. Aber sichtbar ist nicht editierbar. Man kann lesen, nicht schreiben. Wer korrigieren will, muss trotzdem in den Einzeldatensatz wechseln — und danach zurück in die Liste, Seite neu laden, nächsten Datensatz öffnen.

Das Muster ist überall dasselbe:

• Datensatz öffnen
• Feld suchen
• Wert ändern
• Speichern
• Bestätigungsmeldung wegklicken
• Zurück zur Liste
• Nächsten Datensatz öffnen

Sieben Schritte pro Datensatz. Bei fünfzig Datensätzen sind das dreihundertfünfzig einzelne Handlungen — für eine Korrektur, die inhaltlich in dreißig Sekunden erledigt wäre.

Das lässt sich durch Übung nicht verkürzen. Es ist der Aufwand, den das System erzeugt, unabhängig davon, wie erfahren die Person ist, die damit arbeitet. Eine schnellere Maus ändert daran nichts. Und wer die Arbeit nach dem dritten Nachmittag an eine Kollegin weitergibt, gibt auch den Fehlerstand weiter — denn es gibt keinen verlässlichen Weg zu markieren, bis wohin man bereits war.

Wo Fehler entstehen, die niemand als Fehler zählt

Wer dieselbe Aktion vierzig Mal hintereinander ausführt — Datensatz öffnen, Feld suchen, Wert eintragen, speichern, weiter — der denkt irgendwann nicht mehr über die Aktion nach. Er führt sie aus. Genau dort entstehen die Fehler, die kein Protokoll erfasst: der falsche Datensatz geändert, der Wert ins falsche Feld eingetragen, weil der Cursor eine Zeile versetzt stand, die Änderung auf einen Eintrag angewendet, der gar nicht gemeint war.

Das System hat dabei nichts beanstandet. Der Wert war formal korrekt. Der Speichervorgang verlief ohne Meldung. Der Datensatz sieht aus wie alle anderen — und das ist das eigentliche Problem. Kein Ausrufezeichen, keine rote Markierung, kein Hinweis, dass hier etwas nicht stimmt.

Drei Situationen, die häufiger vorkommen als zugegeben

• Ein Status wird auf „abgeschlossen" gesetzt, obwohl der Vorgang noch offen ist — weil die Auswahloptionen im Dropdown ähnlich beschriftet sind und der Blick schon beim nächsten Eintrag ist.
• Ein Betrag wird korrekt eingetragen, aber in der falschen Zeile, weil die Tabulatorreihenfolge des Formulars nicht der Leserichtung der Liste entspricht.
• Ein Datum wird richtig erfasst, aber für den falschen Monat — weil das Datumsfeld den Vormonat vorgeblendet hat und niemand mehr nachschaut, wenn man es schon hundert Mal gemacht hat.

Die Software bestätigt jeden dieser Schritte einzeln. Sie weiß nicht, dass der achtunddreißigste Eintrag der erste Fehler des Tages war — und dass der neununddreißigste und vierzigste ihn stillschweigend fortgesetzt haben.

Was nach dem Speichern folgt

In vielen Systemen für die Stapelbearbeitung gibt es keine nachvollziehbare Änderungshistorie auf Feldebene. Oder es gibt sie, aber sie liegt drei Navigationsschritte entfernt, ohne direkten Weg vom betroffenen Datensatz dorthin. Wenn am Ende des Tages jemand bemerkt, dass eine Gruppe von Einträgen falsche Werte trägt, lautet die erste Frage nicht: Was ist schiefgelaufen? Sie lautet: Welche Einträge sind betroffen?

Bei größeren Mengen kann die Antwort darauf länger dauern als die ursprüngliche Aufgabe. Und anders als die ursprüngliche Aufgabe folgt sie keinem System — man vergleicht, schätzt, rekonstruiert. Das ist die Stelle, an der aus einer Stunde Pflegearbeit ein halber Arbeitstag Fehlersuche wird. Nicht weil jemand unaufmerksam war, sondern weil das Werkzeug keine andere Möglichkeit lässt.

Diese Fehler tauchen in keiner Statistik auf. Sie werden nicht als Systemfehler gemeldet, weil das System keinen gemacht hat. Sie werden selten angesprochen, weil die Person, die sie gemacht hat, weiß, dass die Aufgabe eigentlich machbar sein sollte. Und sie häufen sich — leise, über Wochen.

Warum es niemand anzusprechen weiß

Das Merkwürdige an diesem Problem ist nicht, dass es existiert. Es ist, dass es so selten ausgesprochen wird — nicht in Meetings, nicht in Feedback-Runden, nicht in Gesprächen mit dem Anbieter.

Wer die Software täglich benutzt, hat sich längst arrangiert. Die Handgriffe sitzen. Man weiß, welche Felder man weglassen kann, wo ein Klick nichts bewirkt und wo man besser zweimal nachschaut. Dieses Wissen ist real — es kostet nur niemandem etwas auf dem Papier.

Was nicht gezählt wird, existiert nicht

Wenn eine Mitarbeiterin neunzig Datensätze einzeln öffnet, weil es kein Auswahlfeld für alle gibt, schreibt sie das nirgendwo auf. Sie macht es. Es dauert, wie es dauert. Am Ende des Tages sind die Einträge aktualisiert, und das Ergebnis sieht genauso aus wie eines, das in zehn Minuten entstanden wäre.

Führungskräfte sehen Ergebnisse. Was dazwischen lag — die wiederholten Klicks, die Unterbrechungen, die Konzentration, die das kostet — liegt unterhalb der Sichtlinie. Es gibt keine Spalte in der Auswertung, die zeigt, wie lange jemand gebraucht hat, um ein Ergebnis herzustellen, das auch anders hätte entstehen können.

Der falsche Adressat

Selbst wer die Reibung benennen möchte, weiß oft nicht, an wen. Die Kollegen kennen das Problem bereits. Der Vorgesetzte hat andere Prioritäten. Beim Anbieter hört man: „Das ist so vorgesehen." Oder: „Das lässt sich anpassen" — ohne dass klar wäre, was das bedeutet, was es kostet und ob es je kommt.

So bleibt das Gespräch aus. Nicht weil niemand unzufrieden wäre. Sondern weil die Unzufriedenheit keine Sprache gefunden hat, die über die eigene Schreibtischkante reicht. Eine Beschwerde braucht einen Namen für das, worüber man sich beschwert — und „die Software ist langsam bei vielen Einträgen" trifft es nicht genau genug, um gehört zu werden.

Wenn Gewöhnung als Können gilt

Hinzu kommt eine seltsame Umkehrung: Wer lange mit einer schwerfälligen Software arbeitet, gilt als erfahren. Die Umwege, die sie kennt, werden zur Qualifikation. Wer neu anfängt, braucht Wochen, um dieselben Umwege zu lernen — und die Einarbeitung wird als normal verbucht, nicht als Zeichen, dass das System etwas verlangt, das es nicht verlangen müsste.

In dieser Logik ist die Beschwerde über fehlende Möglichkeiten zur Sammelbearbeitung keine sachliche Rückmeldung, sondern ein Zeichen von Unerfahrenheit. Wer das weiß, hält den Mund. Die Erfahrene hilft der Neuen still und trägt weiter, was sie selbst nie als Problem benennen würde.

Das Problem bleibt, wo es ist. Es wächst still, mit jedem neuen Datensatz, der einzeln bearbeitet wird, und mit jeder neuen Kollegin, die lernt, dass das eben so ist.