Wer bedient das später? Software einführen, ohne das Team zu verlieren

Die Anwendung ist fertig, der Chef ist begeistert, und am Montag danach führt die Buchhaltung ihre Excel-Liste weiter. Nicht aus Bosheit. Die neue Software war in der Schulung ganz nett, aber jetzt ist Monatsabschluss, und da nimmt man das, was man kennt. Drei Monate später ist die Anwendung ein Programm, das „irgendwann mal" eingeführt werden soll.

Software scheitert im Mittelstand selten an der Technik. Sie scheitert an dem Moment, in dem ein Mensch unter Zeitdruck entscheidet, ob er den neuen oder den alten Weg nimmt.

Welchen Ablauf Sie zuerst angehen und wie ein Pilot aufgesetzt wird, steht im Beitrag Digitalisierung schrittweise. Hier geht es um das, was danach kommt: die Wochen, in denen sich entscheidet, ob das Team die Software annimmt. Und darum, wie Sie diese Wochen vorbereiten, ohne Schulungsmarathon, ohne Zwang und ohne dass Sie selbst wochenlang daneben sitzen müssen.

Warum Menschen neue Software nicht benutzen

Die Gründe sind fast immer dieselben, und keiner davon ist „die wollen nicht".

• Der alte Weg ist schneller, heute. Die Excel-Liste kennt man blind. Die neue Anwendung braucht am Anfang doppelt so lange. Dass sie in vier Wochen halb so lange braucht, hilft heute nicht.
• Niemand hat gefragt. Die Anwendung wurde für den Betrieb gebaut, aber ohne die Leute, die damit arbeiten. Dann fehlt genau das Feld, das man dreimal am Tag braucht.
• Die Einführung fiel in die falsche Woche. Jahresabschluss, Messe, Urlaubszeit. Es gibt gute und schlechte Wochen für Neues, und die meisten Einführungen landen aus Termingründen in einer schlechten.
• Die Angst, etwas kaputtzumachen. Wer nicht weiß, ob ein Klick etwas Unwiderrufliches auslöst, klickt lieber gar nicht.
• Es gibt keinen, den man fragen kann. Die Schulung war vor drei Wochen, der Entwickler ist nicht im Haus, und der Chef hat keine Zeit. Also zurück zur Liste.

Key-User: Die Person, die den Alltag kennt

Der wichtigste Schritt kostet nichts: Suchen Sie sich eine Person aus dem Team, die die neue Anwendung als Erste richtig kennt. Im Beitrag über die schrittweise Digitalisierung haben wir sie Kümmerer genannt, im Fachjargon heißt sie Key-User. Es muss keine Führungskraft sein, es darf eine sein. Entscheidend ist etwas anderes: Die Person arbeitet wirklich mit dem Ablauf, kennt die Sonderfälle, wird vom Team ernst genommen, hat Zeit dafür und kann sagen, was hakt, statt nur, dass es hakt.

Was sie tut:

• Sie testet die Anwendung vor allen anderen mit echten Fällen aus dem Alltag, nicht mit Beispieldaten.
• Sie sagt dem Entwickler, was im Alltag nicht funktioniert, bevor das Team es merkt.
• Sie ist ab dem ersten Tag die Anlaufstelle: „Frag die Sabine" wird zur Stärke statt zum Risiko.
• Sie bekommt dafür Zeit. Nicht „nebenbei", sondern feste Stunden in den ersten Wochen.

Nehmen Sie ruhig die Skeptikerin. Wer der neuen Software nicht traut, testet gründlicher als jeder Fan. Wer alle Einwände kennt, kann sie später im Team entkräften. Warum das funktioniert, zeigt unsere Case Study mit dem Sicherheitsdienst. Und wenn die Skeptikerin überzeugt ist, hat die Einführung einen Fürsprecher gewonnen, der mehr wiegt als jede Schulung. Ein Satz, den wir in Varianten schon öfter gehört haben, meist etwa in der dritten Woche: „Ich war ja dagegen. Aber die alte Liste will ich nicht zurück."

Klein anfangen, aber richtig

Warum alles auf einmal schiefgeht, haben wir im Beitrag über die schrittweise Digitalisierung beschrieben. Hier die Kurzfassung für die Einführung: ein Ablauf, ein Team. Zum Beispiel nur die Auftragserfassung, nur im Büro, nur für neue Aufträge. Alte Aufträge bleiben, wo sie sind. Nach zwei Wochen gibt es den ersten Termin zum Nachbessern, nach vier bis sechs Wochen ist der Pilot ausgewertet und das Team hat Vertrauen gefasst. Dann der nächste Ablauf.

Klein anfangen heißt nicht, beide Wege auf Dauer parallel zu betreiben. Für jeden Ablauf braucht es einen klaren Zeitpunkt, ab dem das neue System führend ist. Sonst gewinnt unter Stress immer der alte Weg, und drei Monate später steht die Anwendung wieder auf „irgendwann mal".

Die erste Woche

Die erste Woche entscheidet. Nicht, weil danach alles läuft, sondern weil sich in dieser Woche die Gewohnheiten bilden. Ein paar Dinge, die den Unterschied machen:

• Jemand ist da. Der Key-User oder der Entwickler ist in den ersten Tagen erreichbar. Nicht irgendwann, sondern so, dass eine Frage in Minuten oder wenigen Stunden geklärt ist. Eine Frage, die schnell beantwortet wird, ist ein Problem weniger. Eine Frage, die bis zum nächsten Termin wartet, ist ein Zettel mehr.
• Fehler sind erlaubt, solange sie sichtbar sind. Sagen Sie es laut: Wer in den ersten zwei Wochen etwas falsch eingibt, sagt Bescheid, und wir korrigieren es zusammen. Niemand muss Angst haben, aber niemand darf einen Fehler stillschweigend stehen lassen, denn hinter einem Auftrag hängen Rechnung und Kunde. Das senkt die Hemmschwelle und hält die Daten sauber.
• Kleine Erfolge sichtbar machen. Das erste Angebot, das in fünf Minuten raus war. Der erste Auftrag, den der Monteur vom Handy aus abgeschlossen hat. Erzählen Sie das im Team, es wirkt mehr als jede Schulung.
• Die alte Liste bewusst liegen lassen. Nicht verbieten, aber auch nicht mehr pflegen. Wenn niemand mehr reinschreibt, stirbt sie von allein.

Schulung: weniger, dafür passend

Der klassische Schulungstag, an dem alle acht Stunden lang alle Funktionen sehen, ist eine erstaunlich teure Form der Einführung. Zwei Wochen später ist das meiste vergessen, weil es noch nicht gebraucht wurde.

Was besser funktioniert: kurze Einheiten, direkt vor dem Einsatz, mit den eigenen Fällen. Eine halbe Stunde „So legen wir ab Montag Aufträge an", am Freitag davor, mit drei echten Aufträgen von dieser Woche. Dazu eine Seite mit den fünf wichtigsten Schritten, die neben dem Monitor liegt. Ja, ein Zettel. Aber einer, der die Software erklärt, statt sie zu ersetzen.

Und nicht jeder muss alles lernen. Die Buchhaltung braucht andere Funktionen als der Monteur. Schulen Sie Rollen, nicht die komplette Software.

Die Rechnung dazu, mit Ihren eigenen Zahlen: Ein Schulungstag mit zwölf Leuten sind 96 Arbeitsstunden für Funktionen, von denen viele erst Wochen später zum ersten Mal gebraucht werden. Die halbe Stunde am Freitag mit denselben zwölf Leuten kostet sechs Stunden, und am Montag wird benutzt, was gezeigt wurde.

Was Sie als Chef tun sollten (und was nicht)

• Selbst benutzen. Wenn Sie Ihre Zahlen weiter aus der alten Liste ziehen, weiß das Team, was wirklich zählt. Ziehen Sie sie aus der Anwendung, auch wenn es am Anfang unbequem ist.
• Zeit geben, nicht nur Termine. Der Key-User braucht Stunden, das Team braucht die Erlaubnis, in der ersten Woche langsamer zu sein.
• Nicht drängeln. „Warum benutzt ihr das noch nicht?" bringt nichts. „Was fehlt euch noch?" bringt eine Liste, die man abarbeiten kann.
• Zuhören, wenn es hakt, und unterscheiden. Wenn das Team nach vier Wochen sagt, dass ein Ablauf nicht passt, hat es meistens recht. Meistens. Der Unterschied liegt in der Beschwerde: Ist sie konkret („das Feld fehlt", „das sind drei Klicks zu viel"), hat das Team recht, dann wird angepasst, nicht durchgesetzt. Ist sie pauschal („früher ging das schneller"), ist es die Gewohnheit, die sich wehrt, dann heißt es durchhalten und in zwei Wochen noch einmal fragen.

Fazit

Eine Einführung ist kein Termin, sondern ein paar Wochen, die man planen kann wie ein Projekt: eine Person aus dem Team, die vorangeht, ein Ablauf zum Anfangen, ein Stichtag, ab dem der neue Weg gilt, jemand, der erreichbar ist, und die Erlaubnis, am Anfang langsamer zu sein. Das kostet weniger als ein Schulungstag und wirkt länger. Wie diese Wochen bei Ihnen aussehen, mit welchem Ablauf und welchem Key-User, ist eine Frage für ein Erstgespräch, und wir planen sie mit, nicht nur die Software.

Die beste Anwendung ist die, die Ihr Team nach vier Wochen nicht mehr hergeben will. Das entscheidet sich nicht im Code, sondern in der ersten Woche.