Fachsoftware, die funktioniert – und trotzdem kostet

Der Unterschied zwischen dem Schulungstag und dem dreißigsten Arbeitstag

Am Schulungstag funktioniert fast jede Software. Jemand sitzt daneben, zeigt die Abfolge, erklärt, warum dieser Schritt vor jenem kommt. Die Oberfläche wirkt logisch, weil jemand den Weg kennt und führt. Wer zuhört, versteht. Wer nachfragt, bekommt eine Antwort. Am Ende des Tages denken viele: Das kriegen wir hin.

Dreißig Arbeitstage später sieht derselbe Bildschirm anders aus.

Nicht weil sich etwas verändert hätte. Sondern weil jetzt kein Trainer daneben sitzt, weil der konkrete Fall, der gerade ansteht, nicht der Standardfall aus der Schulung ist, und weil die Funktion, die man damals nur einmal gesehen hat, irgendwo in einem Untermenü liegt, das man seitdem nicht geöffnet hat.

Das Verstehen und das Können sind zwei verschiedene Dinge

Wer an einem Schulungstag zuschaut, wie ein Kollege einen Auftrag anlegt, versteht den Vorgang. Wer ihn drei Wochen später selbst anlegen muss — mit einem Sonderfall, den der Kollege damals übersprungen hat — merkt, dass Verstehen und Können nicht dasselbe ist.

Das ist kein Versagen der Person. Es ist eine Eigenschaft des Lernens: Was man einmal gesehen hat, muss man noch nicht können. Und was man unter Anleitung einmal gemacht hat, kann man unter Druck und Zeitnot noch lange nicht sicher wiederholen.

Fachsoftware, die das nicht berücksichtigt, verlässt sich auf die Schulung als einmaligen Akt. Als ob danach alles sitzt. Als ob niemand vier Wochen Urlaub macht und zurückkommt. Als ob keine neue Mitarbeiterin einfach anfängt, weil die bisherige gegangen ist, und in der ersten Woche allein vor dem System sitzt.

Was am dreißigsten Tag zählt

Am dreißigsten Arbeitstag zeigt sich, ob eine Software auf den Moment vorbereitet ist, in dem jemand allein ist und nicht weiterkommt. Ob die Oberfläche in diesem Moment etwas zurückgibt — einen Hinweis, eine Beschriftung, einen erkennbaren nächsten Schritt — oder ob sie schweigt.

Viele Teams lernen das auf die harte Tour: durch Anrufe bei Kollegen mitten in einer Besichtigung, durch selbst angelegte Notizzettel neben dem Bildschirm, durch Fehlbuchungen, die erst auffallen, wenn die Monatsauswertung nicht stimmt. Nicht weil die Mitarbeitenden unaufmerksam waren. Sondern weil die Software davon ausging, dass der Schulungstag ausreicht.

Was die Software jeden Morgen vergessen hat

Wer täglich mit derselben Anwendung arbeitet, kennt das Ritual: Anmelden, und dann erst einmal wiederherstellen, was gestern noch eingestellt war. Die Spaltenreihenfolge in der Übersicht. Der Filter, der die Datensätze auf den eigenen Bestand einschränkt. Die Sortierung nach dem letzten Änderungsdatum. Alles, was am Vortag mühsam eingestellt wurde, ist am nächsten Morgen wieder weg.

Das kostet keine zehn Minuten am Tag — meistens. Manchmal kostet es mehr, weil man vergessen hat, welchen Filter man gestern gesetzt hatte, und deshalb zuerst mit falschen Ergebnissen arbeitet. Manchmal kostet es gar nichts, weil die Person inzwischen so routiniert ist, dass sie die Klicks nicht mehr bewusst wahrnimmt. Genau das ist das Problem: Was zur Routine geworden ist, wird nicht mehr als Aufwand gezählt.

Die Einstellungen, die niemand als Einstellungen denkt

Es sind selten die großen Konfigurationen, die jeden Morgen verloren gehen. Es sind die kleinen: die Ansicht, die man bevorzugt. Die Breite einer Spalte, die man auf das Nötigste reduziert hat, weil der Rest ohnehin nie relevant ist. Das Eingabefeld, das der Cursor beim Öffnen des Formulars anspringen soll — und stattdessen irgendwo landet, wo man nie anfängt.

• Eine Maklerin stellt jeden Morgen denselben Ortsfilter ein, weil die Software beim Start immer alle Regionen anzeigt.
• Ein Verwalter scrollt bei jeder Sitzung durch dieselben ersten dreißig Einträge, weil die Standardsortierung alphabetisch ist — und seine offenen Vorgänge nie mit A beginnen.
• Ein Gutachter öffnet bei jedem Auftrag manuell dasselbe Drucklayout, weil das System kein bevorzugtes Format kennt.

Diese Handgriffe sind so klein, dass niemand sie in einer Problembeschreibung erwähnen würde. Und doch sind sie jeden Tag da. Vor der ersten inhaltlichen Entscheidung. Bevor die eigentliche Arbeit beginnt.

Wenn das System nicht weiß, wo man gestern aufgehört hat

Manche Anwendungen öffnen beim Start immer dieselbe Startseite — unabhängig davon, was beim letzten Schließen geöffnet war. Wer mitten in einem Vorgang unterbrochen wird und am nächsten Morgen weitermachen will, beginnt damit, den Weg zurück zu finden. Den Datensatz suchen. Den richtigen Bereich aufklappen. Den Stand von gestern rekonstruieren.

Das ist kein Bedienungsfehler. Es ist eine Entscheidung, die das System still für alle getroffen hat: Kontext gehört nicht gespeichert. Für jemanden, der täglich dieselben zehn Vorgänge bearbeitet, bedeutet das zehn Mal täglich orientieren, bevor irgendetwas inhaltliches passiert.

Besonders spürbar wird es bei Unterbrechungen. Ein Anruf, ein Termin, ein Kollege mit einer Frage — und danach ist die Arbeitssituation weg. Nicht die Daten, die sind noch da. Aber der Kontext, in dem man gerade gearbeitet hat: welcher Datensatz war offen, welche Ansicht war gewählt, was war der nächste Schritt. Das System weiß es nicht. Also fängt man neu an.

Was die Software jeden Morgen vergessen hat, merkt man meistens erst dann, wenn man anfängt zu zählen.

Wenn eine Aufgabe fünfzig Schritte braucht, weil das System sie so sieht

Ein Makler will den Preis eines Objekts anpassen. Im System bedeutet das: Objekt aufrufen, in den richtigen Tab wechseln, den Bearbeitungsmodus aktivieren, das Feld suchen, den Wert ändern, speichern, zurück zur Übersicht. Sieben Schritte für eine Zahl. Multipliziert mit fünfzehn Objekten an einem Dienstagvormittag.

Das ist kein Einzelfall. Es ist ein Muster. Fachsoftware ist häufig so gebaut, wie eine Datenbank denkt — nicht wie ein Arbeitstag verläuft. Die Software unterscheidet zwischen Stammdaten und Bewegungsdaten, zwischen Hauptmaske und Untermaske, zwischen Speichern und Veröffentlichen. Der Nutzer unterscheidet zwischen: erledigt und nicht erledigt.

Die unsichtbaren Zwischenschritte

Viele dieser Schritte sind nicht als Aufwand sichtbar, weil sie einzeln betrachtet klein sind. Ein Klick. Eine Bestätigungsmeldung, die man wegklickt. Ein Ladebalken, der kurz erscheint. Eine Filtereingabe, die man jedes Mal neu setzen muss, weil das System sie nicht behält. In der Summe sind das Minuten. An jedem Tag. Für jede Person im Team.

Besonders auffällig wird es bei Aufgaben, die eigentlich zusammenhängen, im System aber getrennt abgebildet sind. Eine Hausverwalterin, die eine neue Mieterin anlegen will, trägt die Adresse in einem Bereich ein, den Kontoinhaber in einem anderen, den Mietbeginn in einem dritten — und merkt am Ende, dass der Vertrag in einem separaten Modul liegt, das sie noch gar nicht geöffnet hat. Die Arbeit ist eine. Die Wege durch das System sind vier.

Wenn der Umweg zum Standard wird

Teams, die mit solchen Systemen arbeiten, entwickeln über Wochen ihre eigenen Wege. Sie wissen, welche Felder man nicht anfassen darf, weil sonst etwas springt. Sie kennen die Reihenfolge, in der man speichern muss. Sie haben gelernt, manche Dinge in einer eigenen Tabelle zu führen, weil das System sie nicht zuverlässig festhält.

Das ist kein Versagen des Teams. Es ist eine vernünftige Reaktion auf ein System, das ihnen Hindernisse in den Weg stellt. Aber es bedeutet, dass ein Teil der Arbeitszeit jeden Tag damit verbracht wird, das System zu managen — und nicht die eigentliche Arbeit.

Ein Gutachter, der fünfzehn Minuten damit verbringt, ein Gutachten in die richtige Mappe zu verschieben, weil die Software zwischen Entwurf, Intern und Veröffentlicht unterscheidet und er jedes Mal vergisst, welcher Status was bedeutet, erledigt in dieser Zeit keine Besichtigung, keine Kalkulation und keine Rückfrage beim Auftraggeber. Die Software hat entschieden, dass das drei verschiedene Zustände sind. Für ihn ist es ein Dokument.

Oft liegt das Problem nicht darin, dass ein Schritt fehlt. Es liegt darin, dass Schritte dort sitzen, wo man sie nicht vermutet — und das merkt man nicht am ersten Tag, sondern erst dann, wenn man sie hundertmal gemacht hat und immer noch nachdenken muss.

Die Zeit, die in keiner Auswertung auftaucht

Wenn ein Unternehmen seine Software bewertet, fragt es meistens: Wie viele Datensätze wurden heute angelegt? Wie lange dauert der Abschluss eines Vorgangs im Schnitt? Beides sind Zahlen, die sich erheben lassen. Beides sind auch die falschen Zahlen, um zu verstehen, was die Software die Belegschaft wirklich kostet.

Was keine Auswertung erfasst, ist die Zeit dazwischen. Die Minute, in der jemand vor einem Bildschirm sitzt und überlegt, in welchem Bereich des Menüs eine Funktion hinterlegt sein könnte. Die Sekunden, in denen eine Kollegin wartet, bis sich eine Liste aufgebaut hat, und dabei den Faden verliert. Das Öffnen einer zweiten Anwendung, weil die erste die benötigte Information nicht auf derselben Seite anzeigt.

Diese Zeiten sind real. Sie summieren sich. Aber sie erscheinen nirgendwo.

Was gezählt wird — und was nicht

Systeme protokollieren Aktionen: gespeichert, geändert, gedruckt. Was sie nicht protokollieren, sind die Bewegungen davor. Ein Mitarbeiter, der einen Vorgang öffnet, ihn falsch zugeordnet findet, schließt, neu sucht und neu öffnet — das System zählt zwei Aufrufe. Die dazwischenliegenden vier Minuten sind unsichtbar.

In der internen Zeiterfassung läuft das unter „Büroarbeit" oder gar nicht. In Gesprächen über Produktivität kommt es als vages Gefühl auf: Das zieht sich immer so. Niemand kann benennen, wie viel Zeit es kostet, weil niemand nachgeschaut hat — und die Software liefert keine Basis dafür.

Das ist kein Randproblem. In Betrieben, in denen dieselben Vorgänge täglich in großer Zahl bearbeitet werden, multiplizieren sich diese Minuten über Teams und Monate. Sie werden nie als Kostenfaktor verbucht, weil sie keinen Namen tragen.

Der stille Puffer, den niemand angesetzt hat

In vielen Betrieben rechnen Mitarbeitende stillschweigend mit dieser Zeit ein. Sie planen mehr, weil sie wissen, dass das System langsam antwortet. Sie legen Zettel daneben, weil das Programm nicht behält, was sie gerade brauchen. Sie fragen Kolleginnen, weil das Handbuch keine Antwort gibt, die im Arbeitsalltag funktioniert.

Das ist keine schlechte Gewohnheit. Es ist eine stille Anpassung an ein Werkzeug, das mehr verlangt, als es zurückgibt. Die Zeit, die so vergeht, fehlt woanders — bei der Beratung, bei der Nachbereitung, bei der Arbeit, für die die Stelle eigentlich gedacht war.

Manche Betriebe spüren das erst, wenn jemand geht. Dann fällt auf, wie viel ungefragtes Wissen eine Person mitgetragen hat — Wissen darüber, welche Felder man in welcher Reihenfolge ausfüllen muss, damit das System nicht abbricht. Welcher Knopf tatsächlich das tut, was er beschriften sollte. Wo die Ausnahme sitzt, die das Handbuch nicht kennt. Dieses Wissen entstand nicht aus der Software heraus. Es entstand trotz ihr — als Reaktion auf das, was sie nicht konnte.

Was Teams meinen, wenn sie sagen: Das Programm ist umständlich

Das Wort fällt oft, aber selten mit einer Erklärung dahinter. Umständlich ist kein technischer Befund. Es ist eine Erschöpfung, die sich über Wochen angesammelt hat — und die erst dann einen Namen bekommt, wenn jemand fragt, wie die Arbeit so läuft.

Was damit gemeint ist, lässt sich besser in Situationen beschreiben als in Kategorien.

Die Aufgabe war einfach. Der Weg dorthin nicht.

Eine Mitarbeiterin möchte den Ansprechpartner in einem Vorgang ändern. Sie weiß, was sie will. Sie weiß, wo die Information stehen soll. Aber das System führt sie über drei Masken, verlangt eine Bestätigung, die keinen erkennbaren Zweck hat, und speichert am Ende — wenn sie nicht aufpasst — die alte Version, weil sie vergessen hat, einen zusätzlichen Haken zu setzen, der optisch nicht als Pflichtfeld erkennbar ist. Die Aufgabe hat vielleicht zwei Minuten gedauert. Das Gefühl danach ist kein gutes.

Der Umweg, den alle kennen und keiner meldet.

In vielen Teams gibt es Wege durch die Software, die nicht dokumentiert sind, aber trotzdem jeder kennt. Man speichert einen Datensatz nicht über die eigentliche Schaltfläche, sondern über einen Umweg, weil die direkte Variante manchmal hängt. Man öffnet eine Liste immer neu, weil der Filter sich beim Schließen zurücksetzt. Man tippt einen Namen nie vollständig ein, weil die Suche ab dem fünften Buchstaben langsamer wird. Niemand meldet das. Es ist kein Fehler. Es ist einfach so.

Diese inoffiziellen Wege sind nicht das Zeichen einer schlechten Einarbeitung. Sie sind das Zeichen, dass das System an diesen Stellen etwas verlangt, das die Arbeit nicht verlangt.

Was das Wort wirklich trägt.

Wenn ein Team sagt, das Programm sei umständlich, meinen sie meistens eines von vier Dingen:

• Es braucht mehr Schritte, als die Aufgabe inhaltlich rechtfertigt.
• Es fragt nach Informationen, die in dem Moment nicht relevant sind — oder die man schon einmal eingegeben hat.
• Es reagiert nicht so, wie man es nach drei Wochen Nutzung erwartet hätte.
• Es zwingt dazu, parallel woanders nachzuschauen, weil die Ansicht nicht zeigt, was man braucht.

Jedes einzelne davon ist in einem Fall keine große Sache. In zweihundert Fällen pro Monat ist es die Art, wie sich Arbeitstage anfühlen. Und weil es kein Absturz ist und keine Fehlermeldung, landet es nirgends — außer in dem einen Satz, den jemand beim Mittagessen sagt.