Wenn die Software da ist, aber niemand sie nutzt

Der zweite Arbeitstag: Wenn die Schulung vorbei ist

Der erste Tag mit der neuen Software ist meistens in Ordnung. Jemand erklärt, jemand zeigt, man stellt Fragen. Die Schritte folgen aufeinander, es gibt eine Reihenfolge. Wer nicht mitkommt, kann nachfragen.

Am zweiten Tag ist die Trainerin weg. Die Kolleginnen und Kollegen haben ihre eigene Arbeit. Und der erste richtige Vorgang wartet.

Für viele ist das der Moment, in dem sich entscheidet, ob sie die Software nutzen oder umgehen. Nicht weil sie keine Lust haben. Sondern weil sie nicht mehr wissen, wo sie anfangen sollen — und weil sie es sich gerade nicht leisten können, zehn Minuten zu suchen.

Was in dieser Woche passiert

Ein Makler, der eine neue Verwaltungssoftware eingeführt hat, erinnert sich: „Ich wusste noch, wie man ein Objekt anlegt. Aber dann kam die erste Anfrage, und ich wollte eine Notiz dazu machen. Ich habe fünf Minuten gesucht und dann einfach aufgeschrieben."

Das ist kein Einzelfall. Die ersten Tage nach einer Software-Einführung sind selten die schwierigsten, weil die Software zu komplex wäre. Sie sind schwierig, weil echte Arbeit wartet und keine Zeit ist, sich zu orientieren.

Der Schritt, der in der Schulung erklärt wurde, ist da — aber unter einem anderen Menüpunkt als erwartet.
Der Vorgang, der geübt wurde, war vereinfacht. Der echte Vorgang hat drei Felder mehr.
Niemand hat erklärt, was passiert, wenn man etwas falsch macht — ob man es rückgängig machen kann, oder ob es weg ist.

Das Vertrauen in eine Software entsteht nicht in der Schulung. Es entsteht — oder entsteht nicht — in der dritten Stunde des zweiten Tages, wenn zum ersten Mal etwas nicht so klappt wie gezeigt.

Der Moment, in dem die Liste wiederkommt

Viele Mitarbeiterinnen und Mitarbeiter haben nach der Einführung nicht aufgehört, ihre alten Methoden zu benutzen. Sie haben sie nur kurz beiseitegelegt. Wenn die Software am zweiten Tag ins Stocken gerät, kommt das Vertraute zurück — das Notizbuch, die Tabelle, die Notiz im Kalender.

Das ist keine Verweigerung. Es ist ein Urteil über das, was in diesem Moment funktioniert. Und dieses Urteil fällt schnell, oft ohne dass irgendjemand es ausspricht.

Wer die Einführung einer Software begleitet hat, kennt diesen Moment oft nicht. Die Schulung verlief gut, die Rückmeldungen waren freundlich. Was danach passiert — wie die ersten echten Vorgänge laufen, wo jemand abbricht und zurückgreift auf das Vertraute —, das zeigt sich selten in einer Abschlusspräsentation.

Was die Schulung nicht abbilden kann

Schulungen zeigen, wie etwas gemeint ist. Sie können nicht zeigen, wie es sich anfühlt, wenn drei Telefonate nacheinander kommen und man zwischendurch einen Datensatz abschließen muss. Wenn die Kollegin fragt, ob der Auftrag schon drin ist. Wenn man nicht sicher ist, ob man auf „Speichern" oder auf „Abschließen" drücken soll — und ob der Unterschied später noch eine Rolle spielt.

Unter diesen Bedingungen zählt nicht, was jemand in Ruhe gelernt hat. Es zählt, was schnell genug abrufbar ist, damit die Arbeit weiterläuft. Eine Software, die das nicht berücksichtigt, verliert ihre Nutzerinnen und Nutzer nicht bei der Einführung. Sie verliert sie in der Woche danach — leise, ohne großes Aufheben, und meistens ohne dass jemand Bescheid gibt.

Die stille Umgehung: Wie Teams neben der Software arbeiten

Irgendwann entsteht eine zweite Schicht. Sie ist nicht geplant, nicht abgestimmt, nicht dokumentiert. Sie wächst einfach — weil jemand gemerkt hat, dass es schneller geht, wenn man es so macht.

Die Kollegin führt ihre eigene Liste in einer Tabellenkalkulation, weil sie dort in Sekunden suchen kann, was im System drei Klicks braucht. Der Außendienstmitarbeiter fotografiert seine Notizen und schickt sie per Messenger weiter, weil das Formular zu umständlich ist, um es vom Parkplatz aus auszufüllen. Die Verwalterin schreibt die wichtigsten Fristen in ihren persönlichen Kalender, weil sie dem System nicht ganz traut. Niemand hat das so entschieden. Es hat sich ergeben.

Was parallel läuft, läuft irgendwann auseinander

Das Nebenher-Arbeiten beginnt meist mit kleinen Ausnahmen. Ein Termin wird hier vermerkt, ein Kontakt dort gepflegt. Solange die Zahlen stimmen, fällt es niemandem auf. Schwierig wird es, wenn zwei Menschen auf dieselbe Information zugreifen wollen — und jeder in seiner eigenen Quelle nachschaut.

Typische Konstellationen, die im Alltag entstehen:

Objektdaten im System, aktuelle Absprachen per E-Mail — wer neu ins Gespräch eintritt, kennt nur den offiziellen Stand.
Termine in der Software, Änderungen im Messenger — die Synchronisation hängt davon ab, dass jemand beides im Blick behält.
Dokumente hochgeladen, aber der aktuelle Entwurf liegt noch auf dem Desktop — eingereicht wird am Ende die falsche Version.

Das ist kein Versagen einzelner Personen. Es ist das Ergebnis von Software, die an bestimmten Stellen mehr Aufwand erzeugt, als sie abnimmt.

Was Teams dabei still lernen

Wenn eine Umgehung lange genug funktioniert, wird sie zur Gewohnheit. Neue Kolleginnen und Kollegen werden eingearbeitet — nicht nur in die Software, sondern auch in die Schichten darum herum. „Das machen wir immer noch so" ist kein Zeichen von Nachlässigkeit. Es ist ein Hinweis darauf, dass das System an dieser Stelle nie wirklich passte.

Was dabei verloren geht, ist nicht immer sichtbar. Manchmal ist es die Verlässlichkeit einer Aussage — weil niemand mit Sicherheit sagen kann, welche Quelle gerade stimmt. Manchmal ist es die Zeit, die damit verbracht wird, zwei Aufzeichnungen abzugleichen, die eigentlich dasselbe abbilden sollten. Und manchmal ist es die Bereitschaft, der Software beim nächsten Projekt überhaupt noch zu vertrauen.

Besonders in kleinen und mittleren Unternehmen, wo Zuständigkeiten selten scharf gezogen sind, verbreiten sich solche Gewohnheiten schnell. Eine Person entwickelt eine Abkürzung. Eine zweite übernimmt sie. Die dritte kennt den Ursprung nicht mehr — und fragt auch nicht danach, weil es funktioniert. Bis es das nicht mehr tut.

Formulare, die niemand zu Ende ausfüllt

Irgendwann öffnet jemand im Team ein Formular, schaut es an und schließt es wieder. Nicht weil die Aufgabe erledigt ist. Sondern weil der Aufwand in diesem Moment größer erscheint als der Nutzen.

Das passiert nicht nur einmal. Es passiert jeden Tag, in vielen Unternehmen, mit Software, die eigentlich genau dafür gebaut wurde.

Was den Abbruch auslöst

Selten ist es ein einzelnes Feld, das den Ausschlag gibt. Meistens ist es die Summe:

Ein Formular, das zwölf Felder zeigt, von denen drei tatsächlich gebraucht werden.
Pflichtfelder, die im Arbeitsablauf an dieser Stelle noch keine Antwort haben.
Ein Auswahlfeld mit vierzig Einträgen, von denen keiner genau passt.
Ein Abschnitt, der sich nur öffnet, wenn vorher eine bestimmte Option gewählt wurde — aber das merkt man erst, wenn man schon weitergeblättert hat.

Die Person, die das Formular ausfüllen soll, kennt die Antworten oft. Was sie nicht hat, ist die Zeit, sie in dieser Reihenfolge, in diesem Format, mit diesen Pflichtfeldern einzugeben.

Was stattdessen passiert

Manche tragen Platzhalter ein. Ein Bindestrich im Pflichtfeld, eine Null in der Zahl, ein „tbd" im Textfeld. Die Software akzeptiert es, das Formular ist abgeschickt, der Datensatz ist unvollständig. Andere legen die Aufgabe beiseite. Sie notieren sich etwas auf Papier, schicken eine E-Mail, sprechen es kurz ab — und kehren zum Formular vielleicht später zurück, vielleicht nie.

Das Ergebnis sieht von außen gleich aus: Das Formular wurde ausgefüllt. Oder es wurde nicht ausgefüllt. Beides ist ein Befund, kein Versagen einzelner Mitarbeiterinnen oder Mitarbeiter.

Wenn die Daten fehlen, fehlen sie überall

Was in einem Formular nicht eingetragen wird, fehlt danach in der Auswertung. Im Bericht. In der Übersicht, die jemand anderes nutzt, um eine Entscheidung zu treffen. Fehlende Felder sind selten zufällig verteilt — sie betreffen oft genau die Angaben, die aufwendig zu beschaffen waren. Grundstücksgröße. Baujahr. Zustand zum Zeitpunkt der Erfassung. Die Angabe, die jemand aus einem alten Dokument hätte heraussuchen müssen.

Wer später nach diesen Daten sucht, merkt, dass sie fehlen. Wer sie anfordert, stört jemanden bei einer anderen Arbeit. Wer sie selbst nachträgt, weiß nicht mehr genau, welchen Stand sie widerspiegeln.

Formulare, die niemand zu Ende ausfüllt, hinterlassen keine Fehlermeldung. Sie hinterlassen eine Datenbank, in der man nicht weiß, was man weiß.

Wenn Fehlermeldungen das Vertrauen kosten

Es gibt einen Moment, den viele kennen: Man hat gerade zehn Minuten lang ein Formular ausgefüllt, trägt die letzte Zahl ein, klickt auf Speichern — und bekommt eine rote Meldung. Was dort steht, erklärt nicht, was falsch war. Es erklärt auch nicht, ob die vorherigen Eingaben noch vorhanden sind. Es steht einfach da.

In diesem Moment entscheidet sich etwas. Nicht bewusst, nicht dramatisch, aber dauerhaft: Das Vertrauen in die Software kippt ein Stück.

Fehlermeldungen in Fachsoftware haben eine eigentümliche Qualität. Sie erscheinen oft genau dann, wenn jemand konzentriert gearbeitet hat. Sie unterbrechen nicht eine Nebentätigkeit, sondern die Kernarbeit. Und sie sagen häufig das Falsche — oder zu wenig.

Was die Meldung sagt und was sie meint

„Ungültige Eingabe" ist eine Aussage, die aus Sicht der Software stimmt. Aus Sicht der Person am Bildschirm ist sie wertlos. Sie weiß nicht, welches Feld gemeint ist. Sie weiß nicht, was an ihrer Eingabe falsch war. Und sie weiß nicht, ob sie von vorne anfangen muss oder ob es genügt, einen Wert zu ändern.

Manchmal erscheint die Meldung auf einer anderen Seite als dem Formular selbst. Manchmal verschwindet sie, sobald man zurücknavigiert — und alle Eingaben sind weg. Manchmal bleibt sie stehen, egal was man ändert, weil der eigentliche Grund ein anderer ist, der nirgendwo angezeigt wird.

Das sind keine Extremfälle. Das ist Alltag in Software, die seit Jahren produktiv eingesetzt wird.

Die Konsequenz ist nicht Ärger — sie ist Vorsicht

Menschen, die regelmäßig mit solchen Meldungen umgehen, entwickeln Strategien. Sie kopieren wichtige Eingaben in ein Textdokument, bevor sie speichern. Sie führen bestimmte Aktionen nur zu bestimmten Uhrzeiten durch, weil sie gelernt haben, dass es dann „zuverlässiger" läuft. Sie fragen Kolleginnen, ob es einen richtigen Weg gibt, der nirgendwo dokumentiert ist.

Diese Strategien kosten Zeit. Aber das ist nicht das Wesentliche. Das Wesentliche ist, dass diese Menschen der Software nicht mehr glauben, dass sie ihre Arbeit vollständig und korrekt aufgenommen hat. Sie überprüfen. Sie sichern. Sie zweifeln.

Ein Makler, der nach jedem Eintrag in die Objektverwaltung die Detailansicht öffnet, um zu kontrollieren, ob alles gespeichert wurde.
Eine Verwalterin, die Buchungsbelege ausdruckt und in einen Ordner legt, nur für den Fall.
Ein Mitarbeiter, der bestimmte Felder bewusst leer lässt, weil er einmal gelernt hat, dass ein bestimmtes Format eine Meldung auslöst — und sich nicht sicher ist, was das System eigentlich erwartet.

Keiner dieser Menschen hat sich gegen die Software entschieden. Sie haben sich für Sicherheit entschieden. Das ist ein Unterschied, der im Alltag kaum auffällt — bis man die Gesamtheit dieser kleinen Ausweichbewegungen betrachtet.

Was dabei verloren geht, ist schwerer zu messen als eine Fehlerzahl: Es ist die Überzeugung, dass die Software das hält, was sie verspricht. Wer einmal erlebt hat, dass eine Meldung erschien und die Daten trotzdem weg waren — oder dass keine Meldung erschien und die Daten trotzdem falsch waren — trägt dieses Wissen mit sich. Und handelt danach.

Was bleibt, wenn die Einführung abgeschlossen ist

Irgendwann schließt das Projektteam die Tickets. Die Dokumentation ist fertig, die Schulungen sind protokolliert, der Einführungstermin ist gehalten. Intern gilt das Projekt als abgeschlossen. Was danach kommt, hat keinen eigenen Namen mehr — und genau das ist das Problem.

In vielen Unternehmen entsteht in diesem Moment eine Lücke zwischen dem, was auf dem Papier gilt, und dem, was im Büro tatsächlich passiert. Die Software läuft. Sie ist lizenziert, gewartet, in den Systemplan eingetragen. Ob sie auch genutzt wird — und von wem, und wofür, und wie regelmäßig — fragt nach dem Go-live kaum noch jemand systematisch nach.

Was nach der Einführung unsichtbar wird

Nutzungsdaten liegen selten vor, und wenn, liest sie kaum jemand aus. Wer sich mit der Software arrangiert hat, fällt nicht auf. Wer sie meidet, auch nicht — zumindest nicht sofort. Erst Monate später, wenn Berichte lückenhaft sind oder Abläufe nicht mehr nachvollziehbar, wird sichtbar, dass ein Teil des Teams einen anderen Weg gegangen ist.

Die Projektverantwortlichen haben zu diesem Zeitpunkt längst weitergezogen. Die Fachabteilung hat sich eingerichtet. Die IT wartet auf eingehende Meldungen. Niemand ist mehr explizit zuständig für die Frage, ob die Einführung tatsächlich gelungen ist — oder ob sie nur rechtzeitig abgeschlossen wurde.

Die Fragen, die niemand mehr stellt

Welche Funktionen werden tatsächlich genutzt, welche nicht?
Wo bricht die Nutzung ab — nach dem Login, nach dem ersten Schritt, nach dem zweiten?
Welche Vorgänge laufen weiterhin außerhalb des Systems?
Wann hat jemand zuletzt gefragt, ob die Software im Alltag das leistet, wofür sie beschafft wurde?

Diese Fragen sind unbequem, weil die Antworten selten gut klingen. Und sie werden seltener gestellt, je weiter der Einführungstermin zurückliegt. Dabei verändert sich die Nutzung nicht schlagartig — sie driftet. Langsam, unauffällig, ohne Protokoll.

Was am Ende bleibt, ist oft ein stilles Missverhältnis: zwischen dem, was die Software können soll, und dem, was sie im Alltag tatsächlich trägt. Nicht weil sie schlecht gebaut ist. Sondern weil die Einführung geendet hat, bevor der Alltag richtig begonnen hatte. Und weil danach niemand mehr hingeschaut hat.