Nach der Einführung: Warum Fachsoftware im Alltag zermürbt

Was eine Schulung zeigt — und was sie nicht zeigen kann

Die Einführungsschulung läuft oft gut. Der Trainer kennt den Weg durch die Software, die Beispieldaten sind aufgeräumt, und alle Anwesenden haben an diesem Tag nichts anderes vor. Was gezeigt wird, funktioniert. Was erklärt wird, leuchtet ein. Am Ende verlässt das Team den Raum mit einem handschriftlichen Spickzettel und dem Gefühl, das zu schaffen.

Drei Wochen später sieht es anders aus. Nicht weil die Schulung schlecht war, sondern weil sie zwangsläufig den besten Fall gezeigt hat.

Der Unterschied zwischen dem Vorführ-Datensatz und dem eigenen

In der Schulung sind alle Felder befüllt, die Nummern stimmen, und jede Suche liefert genau das, was gesucht wird. Im Arbeitsalltag gibt es den Kunden, dessen Name im System dreifach angelegt ist — einmal mit Bindestrich, einmal ohne, einmal mit einem Tippfehler aus 2019. Welcher ist der richtige? Die Schulung hat das nicht gezeigt, weil der Vorführdatensatz sauber war.

Was man unter Zeitdruck vergisst

Manche Schritte merkt man sich nur, wenn man sie selbst ausgeführt hat — nicht wenn man zugeschaut hat. Eine Abfolge von fünf Klicks lässt sich beobachten und trotzdem beim ersten Mal allein nicht reproduzieren. Das ist keine Frage der Aufmerksamkeit. Es ist die Differenz zwischen Zuschauen und Tun, die jede motorische Tätigkeit kennt.

In der Schulung gab es Zeit für Korrekturen. Im Tagesgeschäft gibt es Telefonate, die dazwischenkommen, und Fristen, die nicht warten.

Was mit Sonderfällen passiert

Eine Schulung kann nicht alle Sonderfälle abdecken — das ist weder möglich noch sinnvoll. Aber im Arbeitsalltag tauchen genau diese Fälle auf: der Auftrag, der nicht ins Standardschema passt. Das Dokument, das in zwei Kategorien gleichzeitig gehört. Die Buchung, die storniert und neu angelegt werden muss, aber nicht darf, weil sie schon eine Folgebuchung hat.

Was dann zählt, ist nicht mehr, was in der Schulung erklärt wurde, sondern was die Software in diesem Moment sichtbar macht — oder eben nicht.

Zeigt sie, welche Felder für diesen Sonderfall relevant sind?
Erklärt sie, warum ein Schritt nicht möglich ist?
Führt sie zurück zur letzten gesicherten Version, wenn jemand etwas falsch abgespeichert hat?

Wenn die Antwort dreimal Nein lautet, ist das kein Schulungsproblem. Es ist ein Hinweis darauf, dass die Software für den gezeigten Standardfall entworfen wurde — und nicht für den Alltag derjenigen, die sie täglich benutzen müssen.

Die Aufgaben, für die keine Demo-Folie existiert

Jede Softwarevorführung zeigt denselben Ablauf: Ein neuer Datensatz wird angelegt, sauber ausgefüllt, gespeichert. Das System reagiert, wie es soll. Die Präsentation endet, bevor jemand fragt, was passiert, wenn man dreihundert bestehende Einträge gleichzeitig anpassen muss — oder wenn ein Datensatz aus dem Vorjahr korrigiert werden soll, der von jemandem angelegt wurde, der längst nicht mehr im Unternehmen ist.

Diese Aufgaben sind keine Ausnahmen. Sie sind ein großer Teil der tatsächlichen Arbeit. Aber sie tauchen in keiner Demo auf, weil sie sich schlecht zeigen lassen. Sie sind langsam, unordentlich und setzen voraus, dass das System Zustände kennt, die im Idealfall gar nicht vorkommen sollten.

Was wirklich auf dem Tisch liegt

Eine Verwalterin, die am Monatsanfang Betriebskostendaten für achtzig Einheiten einpflegt, arbeitet nicht mit dem Formular, das die Demo gezeigt hat. Sie arbeitet mit einer Liste, die aus einer anderen Quelle stammt, in einem Format, das das System nicht direkt versteht. Sie überträgt, prüft, korrigiert — Zeile für Zeile, weil das System keine Möglichkeit bietet, viele Felder gleichzeitig zu bearbeiten.

Ein Makler, der eine fehlerhafte Provision aus dem letzten Quartal richtigstellen will, findet sich in einem Ablauf wieder, der offensichtlich für das Neuanlegen gedacht wurde — nicht für das Korrigieren. Er muss einen Umweg nehmen, der funktioniert, aber nicht dokumentiert ist. Beim nächsten Mal erinnert er sich vielleicht nicht daran.

Datensätze zusammenführen, weil ein Kontakt doppelt angelegt wurde
Felder leeren, die beim Import falsch befüllt wurden
Einen Auftrag stornieren, der bereits teilweise abgerechnet ist
Etwas suchen, das vor vier Monaten unter einem anderen Namen eingetragen wurde

Keine dieser Aufgaben ist kompliziert. Aber keine von ihnen wurde bei der Auswahl des Systems ausprobiert. Die Frage, die dabei zählt, ist nicht, ob das System sie theoretisch beherrscht — sondern wie viele Schritte sie tatsächlich kosten und ob der Weg dabei einigermaßen erkennbar ist.

Software, die für den zweiten Arbeitstag gebaut ist, behandelt Korrekturen und Massenänderungen nicht als Sonderfälle. Sie sind Teil der Arbeit — und das System sollte das wissen.

Wo sich Klicks summieren und Arbeitszeit verschwindet

Die meisten Verluste in einer Arbeitswoche sind nicht laut. Sie bestehen aus Momenten, die jeder für sich genommen harmlos wirken: ein Feld, das man jedes Mal neu ausfüllt, obwohl die Information schon irgendwo im System steht. Eine Liste, durch die man scrollen muss, um den richtigen Eintrag zu finden. Ein Vorgang, der drei Bildschirme braucht, obwohl er eine Entscheidung ist.

Wer diese Momente zum ersten Mal erlebt, denkt: Das lerne ich noch. Nach drei Monaten denkt niemand mehr darüber nach. Die Bewegung ist zur Gewohnheit geworden — und die Zeit, die sie kostet, ist unsichtbar, weil sie nie in einer Zeile auftaucht.

Das Öffnen, das niemand zählt

Nehmen Sie eine Mitarbeiterin, die täglich fünfzig Vorgänge bearbeitet. Für jeden öffnet sie die Akte, prüft eine Information, schließt die Akte, wechselt in eine andere Maske, trägt die Information dort ein. Vier Klicks, vielleicht fünf. Multipliziert mit fünfzig ergibt das zweihundert bis zweihundertfünfzig Klicks allein für diese eine Tätigkeit — täglich, an jedem Arbeitstag des Jahres.

Kein Projekt, das diese Stelle analysiert hat, hat je jemanden klagen hören. Nicht weil es kein Problem ist, sondern weil es zu klein ist, um es auszusprechen, und zu groß, um es zu ignorieren. Es ist einfach da.

Die Felder, die immer wieder leer sind

Ein anderes Muster: Software, die eine Information nicht von einem Schritt in den nächsten mitträgt. Die Adresse, die man beim Anlegen eines Vorgangs eingegeben hat, steht im Dokument, das man am Ende druckt, nicht drin — weil das Dokumentenmodul und das Vorgangsmodul nicht miteinander sprechen. Also wird die Adresse noch einmal getippt. Immer. Von jedem, der das weiß. Von niemandem, der es nicht weiß — die tippen es auch, aber mit Fehlern.

Diese Lücken entstehen nicht durch Nachlässigkeit. Sie entstehen, weil die Software in Phasen gebaut wurde, und jede Phase für sich funktioniert. Was fehlt, ist der Blick auf die Strecke dazwischen — auf die Arbeit, die in den Übergängen liegt.

Wenn der Bildschirmwechsel die eigentliche Aufgabe ist

Es gibt Vorgänge, bei denen die eigentliche Arbeit zehn Minuten dauert und das Zusammensuchen der dafür nötigen Informationen dreißig. Nicht weil die Informationen fehlen — sie sind im System, verteilt auf vier verschiedene Bereiche, die nie zusammen auf einem Bildschirm zu sehen sind.

Wer das täglich tut, entwickelt eigene Wege: ein offenes Browser-Tab hier, eine Notiz dort, ein Kollege, den man schnell fragt. Das System wird umgangen, nicht genutzt. Die Nutzenden sind dabei nicht unzufrieden — sie haben aufgehört, Erwartungen an die Software zu haben, die über das Notwendigste hinausgehen.

Informationen, die mehrfach eingetragen werden, weil sie nicht weitergereicht werden
Listen ohne Suchfunktion, die mit der Zeit zu lang zum Durchscrollen sind
Pflichtfelder, die bei jedem Vorgang gleich gefüllt werden — mit demselben Wert
Druckvorlagen, die jedes Mal manuell nachgebessert werden müssen
Statusfelder, die niemand pflegt, weil die Pflege länger dauert als der Vorgang selbst

Jeder dieser Punkte für sich ist klein. Zusammen formen sie den Teil des Arbeitstags, der am Ende übrig bleibt, wenn man fragt: Wo ist die Zeit geblieben?

Was passiert, wenn Nutzende aufhören, Probleme zu melden

Am Anfang werden Fehler gemeldet. Jemand schickt eine E-Mail an die Teamleitung, ruft beim Support an, dokumentiert, was nicht funktioniert hat. Das ist ein gutes Zeichen — es bedeutet, dass die Person noch glaubt, dass sich etwas ändern lässt.

Irgendwann hört das auf. Nicht weil keine Probleme mehr da wären. Sondern weil niemand mehr die Energie aufbringt, sie zu beschreiben. Jede Meldung kostet Zeit: das Problem in Worte fassen, den richtigen Kanal finden, warten, nachfassen, erklären, was man eigentlich gemeint hatte. Und wenn aus früheren Meldungen nichts Sichtbares geworden ist, rechnet man eben nicht damit, dass es diesmal anders wird.

Was dann passiert, ist schwer zu sehen, weil es nicht laut ist. Die Mitarbeiterin, die jeden Auftrag zuerst in eine eigene Tabelle trägt und ihn erst danach ins System einpflegt, erklärt das nicht mehr. Sie tut es einfach. Der Kollege, der bestimmte Felder konsequent leer lässt, weil er gelernt hat, dass sie sowieso falsch aufsummiert werden, meldet das nicht mehr. Er lässt sie leer.

Stille ist kein gutes Zeichen

Eine Software, über die niemand mehr klagt, wirkt stabil. Manchmal ist sie das auch. Aber oft bedeutet Stille nur, dass die Menschen, die mit ihr arbeiten müssen, ihre eigenen Umgehungen gefunden haben — und dass diese Umgehungen längst so selbstverständlich geworden sind wie der Rest der Arbeit.

Das hat Folgen, die man nicht sofort sieht:

Daten werden parallel an zwei Orten gepflegt, weil das System nicht liefert, was gebraucht wird.
Fehler in Auswertungen bleiben unkorrigiert, weil niemand mehr erwartet, dass sie korrigiert werden.
Neue Mitarbeitende lernen nicht nur die offizielle Bedienung, sondern auch die inoffiziellen Wege — mündlich, von Kollegin zu Kollegin.
Entscheidungen werden auf Basis von Zahlen getroffen, die niemand mehr für verlässlich hält, aber auch niemand mehr anzweifelt.

Das Gefährliche daran: Nach außen läuft alles. Die Software läuft. Das Team arbeitet. Nur wenn man genau hinschaut — auf die Export-Tabellen, auf die E-Mails mit „zur Sicherheit noch mal separat", auf die kurzen Erklärungen beim Onboarding, die eigentlich keine Bedienhinweise sind, sondern Überlebenstipps — dann sieht man, wie viel Arbeit das Team aufwendet, um mit dem System zurechtzukommen, statt durch es hindurch.

Manche Unternehmen merken das erst, wenn jemand kündigt, der dieses Wissen mitgenommen hat. Dann fragen sich Verantwortliche, warum plötzlich Dinge nicht mehr funktionieren, die vorher reibungslos liefen. Die Antwort ist fast immer dieselbe: Sie liefen nicht reibungslos. Sie liefen, weil eine Person wusste, wie man sie zum Laufen bringt.

Woran man erkennt, ob Software für den zweiten Tag gebaut ist

Software, die für den zweiten Tag gebaut ist, fällt nicht durch ihren ersten Eindruck auf. Sie fällt dadurch auf, dass nach dem fünfzigsten Mal eine Aufgabe nicht schwerer geworden ist als nach dem ersten.

Es gibt ein paar Stellen, an denen das sichtbar wird — ohne Schulung, ohne Messung, einfach durch die Arbeit, die darin gemacht wird.

Die Suchfunktion

Wer täglich nach denselben Objekten, Vorgängen oder Personen sucht, sucht nicht sorgfältig. Er sucht schnell, mit unvollständigen Begriffen, manchmal mit dem falschen Wort. Software, die das kennt, findet trotzdem. Software, die nur auf exakte Eingaben reagiert, kostet jeden Tag ein paar Sekunden — die sich summieren.

Was nach einem Unterbruch passiert

Ein Telefonanruf, ein Kollege, eine Ablenkung — und man kehrt zur Maske zurück. Ob die Eingaben noch da sind, ob man die Liste wieder von vorn filtern muss, ob die Software weiß, wo man war: Das sind keine Komfortfragen. Das ist der Unterschied zwischen zehn Minuten und zwanzig Minuten für dieselbe Aufgabe.

Massenpflege

In der Verwaltungsarbeit gibt es Aufgaben, die zwanzig Datensätze betreffen, nicht einen. Wenn die Software nur Einzelbearbeitung kennt, kostet jede solche Aufgabe das Zwanzigfache. Wer täglich damit arbeitet, weiß das. Es steht nirgends auf einer Folie.

Was bei einem Fehler passiert

Nicht, ob ein Fehler angezeigt wird — das tut jede Software. Sondern was danach passiert. Ob man die Eingabe noch sieht. Ob man korrigieren kann, ohne von vorn zu beginnen. Ob die Meldung sagt, was falsch war, oder nur, dass etwas falsch war.

Software, die für den zweiten Tag gebaut ist, behandelt einen Fehler als Teil der normalen Arbeit — nicht als Ausnahme, für die kein Platz vorgesehen wurde.

Die Frage nach dem Weg zurück

Wenn jemand, der die Software seit sechs Monaten täglich benutzt, für eine ungewöhnliche Aufgabe trotzdem bei der IT anrufen muss — nicht wegen der Komplexität der Aufgabe, sondern wegen der Bedienung —, dann beantwortet das die Frage.

Die Software hat den zweiten Tag zwar überstanden. Aber sie hat ihn nicht eingeplant. Das ist der Unterschied, der sich in der Summe des Jahres zeigt: nicht in einer einzelnen langen Schulung, sondern in tausend kleinen Momenten, in denen eine Person innehält und überlegt, wie sie etwas tut — statt es einfach zu tun.