Wenn die Software läuft und niemand sie benutzt

Der erste Arbeitstag ist nicht das Problem

Die Einführungsschulung dauert drei Stunden. Der Trainer klickt sich durch die Menüs, zeigt, wo neue Einträge angelegt werden, erklärt die wichtigsten Felder. Alle nicken. Die Fragen sind überschaubar. Am Ende des Tages gilt das System als eingeführt.

Was danach passiert, sieht niemand, der an diesem Tag dabei war.

Am dritten Arbeitstag öffnet jemand die Oberfläche alleine zum ersten Mal — ohne Trainer, ohne jemanden neben sich, der zeigt, wo man klickt. Die Aufgabe ist dieselbe wie in der Schulung. Aber der Weg dorthin ist plötzlich unklar. Welches Untermenü war das? Muss zuerst gespeichert werden oder erst danach? Warum erscheint die Fehlermeldung, die in der Schulung nicht aufgetaucht ist?

Das ist kein Wissensproblem. Die Person war dabei. Sie hat aufgepasst. Der Trainer hat es richtig erklärt. Das Problem ist, dass der erste Tag für eine andere Situation gebaut war: für jemanden, der erklärt — nicht für jemanden, der alleine arbeitet.

Der Unterschied zwischen „verstanden" und „selbstständig nutzbar"

In der Schulung gibt es immer einen nächsten Schritt, der gezeigt wird. Beim täglichen Einsatz nicht. Wer alleine vor dem System sitzt, muss selbst herausfinden, was als nächstes kommt — und wohin er klickt, wenn etwas schiefgeht.

Viele Systeme sind darauf ausgelegt, in einer Vorführung gut auszusehen. Die Hauptwege — ein neues Objekt anlegen, einen Auftrag erfassen, einen Bericht ausgeben — sind klar strukturiert. Was fehlt, sind die Situationen, die in keiner Vorführung vorkommen: das Feld, das ausgefüllt sein muss, ohne dass jemand erklärt warum. Die Maske, die bei bestimmten Eingaben einen anderen Ablauf verlangt. Die Funktion, die in der Schulung übersprungen wurde, weil sie „seltener gebraucht wird" — und die am zweiten Arbeitstag genau gebraucht wird.

Was die ersten Wochen zeigen

Die ersten vier Wochen nach einer Systemeinführung sind der einzige Zeitraum, in dem Probleme noch als Einführungsprobleme gelten. Wer in Woche zwei nicht weiterkommt, fragt noch nach. In Woche sechs fragt niemand mehr — man hat sich einen Weg gesucht, der funktioniert, auch wenn er nicht der vorgesehene ist.

Das sind keine außergewöhnlichen Nutzerinnen und Nutzer. Das ist der normale Verlauf. In jedem Team, das ein neues System übernimmt, gibt es eine kurze Phase, in der noch gefragt wird. Danach nicht mehr. Was danach entsteht, sind Gewohnheiten — manchmal gute, manchmal solche, die das System dort umgehen, wo es unbequem wird.

Ob eine Einführung gelungen ist, zeigt sich nicht am ersten Tag. Es zeigt sich daran, was die Mitarbeitenden in Woche vier noch selbstständig im System erledigen — und was sie inzwischen anders regeln. Wer das nicht beobachtet, hält den Schulungstag für den Maßstab. Der ist es nicht.

Was passiert, wenn niemand zurückfragt

In den meisten Häusern gibt es irgendwann diesen Moment: Die Einführung ist abgeschlossen, die Schulungen sind gelaufen, der Dienstleister hat das Projekt offiziell übergeben. Und dann — Stille. Keine Rückmeldungen, keine Supportanfragen, keine Beschwerden. Wer dafür zuständig ist, liest das gerne als Zeichen, dass alles funktioniert.

Meistens ist es kein Zeichen dafür.

Es ist ein Zeichen dafür, dass die Menschen aufgehört haben zu fragen. Nicht weil sie zufrieden sind, sondern weil sie gelernt haben, dass Fragen nichts bringen. Weil der erste Anruf beim Support eine halbe Stunde kostete und das Problem trotzdem noch da war. Weil die Rückmeldung, die jemand in der Einführungsphase gegeben hat, sechs Wochen später unverändert im System stand. Weil es schneller geht, das Feld manuell nachzukorrigieren, als zu erklären, warum es falsch befüllt wird.

Das Problem verschwindet nicht — es wird unsichtbar

Eine Maklerin, die jeden Morgen denselben Export aus dem Verwaltungssystem zieht und ihn manuell in eine Tabelle überträgt, wird das irgendwann nicht mehr melden. Sie tut es einfach. Es kostet sie zwanzig Minuten täglich, und sie hat längst aufgehört, sich darüber zu ärgern. Es ist Teil des Arbeitsalltags geworden.

Wer das System von außen betrachtet, sieht: keine offenen Tickets, keine Beschwerden, keine Rückfragen. Was er nicht sieht: mehr als hundert Stunden im Jahr, die in eine Umgehung fließen, die niemand bemerkt, weil niemand mehr fragt.

• Das Feld, das alle wissen falsch zu befüllen — aber jeder macht es trotzdem so, weil das System es verlangt.
• Die Suchfunktion, die niemand mehr benutzt, weil die Ergebnisse unzuverlässig sind — stattdessen scrollt man durch die Liste.
• Der Statuswechsel, den drei Kolleginnen doppelt pflegen, weil das System ihn nicht automatisch weitergibt.

Das sind keine Ausnahmen. Das ist die Regel in Systemen, deren Nutzende aufgehört haben zurückzufragen.

Die Rückmeldung, die nie ankommt

Wenn jemand im ersten Monat ein Problem meldet und dafür Aufwand investiert — ein Formular ausfüllt, einen Termin wahrnimmt, eine E-Mail schreibt — und dann nichts passiert: Er wird es nicht zweimal tun. Das ist keine Gleichgültigkeit. Das ist eine rationale Entscheidung.

Was folgt, ist ein Zustand, den viele Systemverantwortliche als Stabilität lesen: kein Lärm, keine Eskalationen, keine Anforderungen. Was es tatsächlich ist: eine Rückmeldungsschleife, die abgebrochen ist. Das System entwickelt sich nicht mehr weiter, weil der Kanal, über den Verbesserungen eingehen würden, still geworden ist.

Die Fragen, die sich die Nutzenden stellen, landen nicht mehr beim Ansprechpartner. Sie landen im Flur, in der Mittagspause, beim nächsten Teammeeting: „Macht ihr das auch so?" Und meistens ist die Antwort: „Ja, anders geht's nicht." Ob das stimmt, weiß niemand mehr — weil niemand mehr fragt.

Die Kosten der Umgehung

Wenn ein System nicht benutzt wird, bedeutet das selten, dass die Arbeit nicht erledigt wird. Es bedeutet meistens, dass die Arbeit woanders erledigt wird. In einer Excel-Datei, die auf dem Desktop liegt. In einem WhatsApp-Chat, den nur zwei Personen lesen können. In einem Notizbuch, das mit dem nächsten Urlaub verschwindet.

Diese Umgehungen sind kein Zeichen von Disziplinlosigkeit. Sie entstehen, weil das System langsamer ist als die Alternative. Wer täglich zwanzig Vorgänge bearbeitet, rechnet intuitiv nach: Wenn jeder Vorgang im System drei Minuten mehr kostet als im alten Weg, kostet das in der Woche eine Stunde. Eingespart wird sie woanders — und das ist eine rationale Entscheidung, keine Verweigerung.

Was dabei verloren geht

Das Problem liegt nicht im einzelnen Vorgang. Es liegt darin, was diese verteilten Daten bedeuten, wenn jemand eine Entscheidung treffen muss. Die Verhandlungsvorbereitung stützt sich auf Zahlen aus dem System — aber die aktuellen Konditionen stehen im Chat. Der Bericht an die Geschäftsführung zieht die Auftragszahlen aus der offiziellen Oberfläche — aber wer im Haus welches Objekt betreut, steht in der Tabelle einer Kollegin, die gerade krank ist.

Entscheidungen werden auf Basis der Daten getroffen, die sichtbar sind. Was nicht im System steht, steht nirgends — jedenfalls nicht für die Person, die in diesem Moment entscheiden muss.

Die unsichtbare Doppelarbeit

Umgehungen erzeugen fast immer eine zweite Pflege. Wer Termine in einer eigenen Tabelle führt, weil das System zu umständlich ist, trägt denselben Termin irgendwann nach — oder er fehlt im System ganz. Beide Fälle kosten Zeit: die erste Variante doppelt, die zweite beim nächsten Mal, wenn jemand auf Vollständigkeit angewiesen ist.

• Eine Objektliste, die im System steht und parallel in einer Tabelle gepflegt wird: Wer hat beim letzten Update welche Version genommen?
• Eine Aufgabe, die per Zuruf vergeben wurde, weil das Anlegen im System zu viele Felder verlangt: Wer weiß in vier Wochen noch davon?
• Ein Kundengespräch, dessen Ergebnis im E-Mail-Entwurf gespeichert wurde, weil der Gesprächsbericht im System drei Klicks entfernt ist: Wer findet es, wenn die Person krank ist?

Die Kosten dieser Umgehungen zeigen sich selten sofort. Sie zeigen sich, wenn jemand neu in ein Projekt eintritt und nicht versteht, warum das System andere Zahlen trägt als die Excel-Datei. Sie zeigen sich beim Jahresgespräch, wenn die Auswertung nicht stimmt. Oder wenn die einzige Person, die weiß, welche Tabelle die aktuelle ist, das Unternehmen verlässt.

Es entsteht auch ein zweites Problem, das noch schwerer zu beziffern ist: Wer etwas außerhalb des Systems erledigt, meldet dem System nicht zurück, was er weiß. Das System lernt nicht. Es spiegelt nicht den tatsächlichen Stand — es spiegelt den Stand vom letzten Mal, als jemand Zeit hatte, es ordentlich zu befüllen. Und dieser Abstand zwischen Abbild und Wirklichkeit wächst mit jeder Umgehung ein Stück weiter.

Ein System, das umgangen wird, ist kein neutraler Zustand. Es ist ein System, dessen Datenbasis täglich ein Stück weniger verlässlich wird — ohne dass jemand eine Entscheidung dafür getroffen hätte.

Wenn der Schulungsaufwand wächst und die Nutzung sinkt

Irgendwann fällt auf, dass die Einführungszeit für neue Mitarbeiterinnen und Mitarbeiter länger geworden ist — nicht weil die Aufgaben komplizierter wurden, sondern weil das System mehr Erklärung braucht als zuvor. Wer das dokumentiert, findet meistens einen stillen Anstieg: drei Tage Einarbeitung wurden zu fünf, fünf zu sieben. Die Arbeit selbst hat sich nicht verändert.

Gleichzeitig sinkt die tatsächliche Nutzung. Nicht dramatisch, nicht auf einmal — sondern langsam. Ein Team trägt Kundentermine wieder in eine eigene Tabelle ein, weil das System „zu umständlich" ist, wenn man es eilig hat. Eine andere Gruppe schickt sich Ergebnisse per E-Mail, obwohl das System dafür einen eigenen Bereich hätte. Beides ist keine Sabotage. Beides ist ein Weg, den Menschen gehen, wenn ein anderer Weg täglich Reibung kostet.

Das FAQ-Dokument, das niemand mehr liest

In vielen Teams gibt es ein internes Dokument — manchmal eine E-Mail-Kette, manchmal eine geteilte Notiz — in dem die häufigsten Fragen zum System gesammelt wurden. Es wurde angelegt, weil dieselben Fragen immer wieder auftauchten. Es wird länger, je mehr Ausnahmen und Umwege sich einschleichen. Wer es liest, versteht die Antworten nur dann, wenn er die Fragen schon aus eigener Erfahrung kennt.

Das ist kein schlechtes Dokument. Es ist ein Abbild dessen, was das System nicht von sich aus erklärt.

Wenn erfahrene Mitarbeiterinnen und Mitarbeiter dieselben Fehler machen wie neue

Ein anderes Zeichen: Die Fehler, die in der ersten Arbeitswoche passieren, passieren auch nach zwei Jahren. Nicht bei denselben Personen — aber immer wieder, an denselben Stellen. Ein Pflichtfeld, das als optional aussieht. Ein Schritt, der nicht bestätigt werden muss, aber es sollte. Eine Funktion, die etwas anderes tut als ihr Name verspricht.

Solche Stellen werden in der Einarbeitung neuer Kollegen explizit erwähnt: „Da muss man aufpassen." Wer das sagt, hat sich längst daran gewöhnt. Wer es hört, notiert es — und vergisst es trotzdem, weil es kein System gibt, das ihn zur richtigen Zeit daran erinnert.

• Die Einarbeitungszeit wächst, aber die Aufgaben werden nicht komplexer.
• Interne Workarounds werden weitergegeben wie mündliches Überlieferungsgut.
• Erfahrung bedeutet vor allem: Wissen, was man im System besser nicht tut.
• Fragen, die nach drei Monaten gestellt werden, sind dieselben wie nach drei Jahren.

Der Schulungsaufwand ist ein Maß dafür, wie viel das System seinen Nutzern abverlangt, ohne es selbst zu tragen. Wenn dieser Aufwand wächst, liegt das selten an den Menschen. Es liegt meistens daran, dass das System nicht mitwächst — oder nie dafür gebaut wurde, im Alltag benutzt zu werden.

Was die Stille über das System aussagt

Wenn niemand Fehler meldet, kann das zwei Dinge bedeuten: Das System funktioniert. Oder die Leute haben aufgehört zu melden, weil es sich nicht lohnt.

Der zweite Fall ist schwieriger zu erkennen, weil er sich wie Ruhe anfühlt. Die Inbox bleibt leer. Der Helpdesk hat wenig zu tun. Niemand beschwert sich. Wer das als Zeichen nimmt, dass alles gut läuft, sieht nicht, was stattdessen passiert.

Was statt der Software benutzt wird

In Verwaltungsteams, die eine Softwareeinführung hinter sich haben, lässt sich oft beobachten, dass bestimmte Aufgaben auf Umwegen erledigt werden. Eine Kollegin schickt die Unterlagen per E-Mail, obwohl das System dafür vorgesehen wäre. Jemand pflegt eine eigene Tabelle, die er nicht zeigt. Die Kommunikation zu einem Vorgang läuft über Telefon — weil das schneller geht und weil das Ergebnis dann wenigstens sicher ist.

Das sind keine Regelbrüche. Das sind Anpassungen. Menschen, die täglich unter Zeitdruck arbeiten, lösen Probleme auf dem kürzesten Weg. Wenn der kürzeste Weg am System vorbeiführt, sagt das etwas über das System — nicht über die Menschen.

Was die Nutzungslücke verdeckt

Viele Systeme messen, ob jemand eingeloggt war. Sie messen nicht, ob die eigentliche Aufgabe danach im System erledigt wurde oder anderswo. Eine Maklerin, die sich morgens anmeldet, ihre Exposés aus einer anderen Anwendung zieht und sich mittags wieder ausloggt, erscheint in der Auswertung als aktive Nutzerin. Der Befund stimmt formal. Er beschreibt nicht, was wirklich passiert.

Die Stille ist keine Abwesenheit von Information. Sie ist Information — nur in einer Form, die kein Ticket erzeugt und keine Eskalation auslöst. Niemand sagt: „Ich benutze das nicht, weil es mich mehr Zeit kostet als der Weg davor." Sie tun es einfach nicht. Und das System läuft weiter, ungestört, unbenutzt und unangefochten.

Was ein Team wirklich benutzt und was es dazu gebracht hat, daran vorbeizugehen, lässt sich meist nicht aus dem System ablesen. Es lässt sich nur herausfinden, indem man fragt — an einem ganz normalen Arbeitstag, nicht beim Rollout.