Ein neues Softwaresystem ist fertig. Die Entwicklung ist abgeschlossen, die Tests sind durchgeführt, und der Einführungstermin rückt näher. An diesem Punkt atmen viele Unternehmer erleichtert auf — das Schwierigste liegt hinter ihnen.
Das tut es nicht.
In der Praxis entstehen einige der kostspieligsten und folgenreichsten Probleme bei Softwareprojekten nicht während der Entwicklung, sondern beim Rollout. Mitarbeiter, die sich der Veränderung widersetzen, Workarounds, die parallel zum neuen System weitergenutzt werden, Daten, die nie an der richtigen Stelle ankommen, und am Ende ein Werkzeug, das viel Geld gekostet hat, aber nur halb genutzt wird. Das sind keine Ausnahmen. Das ist die Regel.
Ihr Team dazu zu bringen, neue Software wirklich anzunehmen — und nicht nur zu tolerieren — erfordert gezielten Aufwand. Die gute Nachricht: Der Aufwand ist nicht übermäßig groß, und die Prinzipien sind überschaubar.
Warum Software-Rollouts scheitern
Bevor wir uns anschauen, was funktioniert, lohnt es sich zu verstehen, warum Dinge schiefgehen.
Der häufigste Grund für mangelnde Akzeptanz ist nicht die Technologie. Die meiste moderne Individualsoftware ist zuverlässig und gut gestaltet, wenn sie Ihr Team erreicht. Die Probleme sind fast immer menschlicher Natur:
Die Mitarbeiter verstehen nicht, warum die Veränderung stattfindet. Wenn Mitarbeiter aufgefordert werden, ein neues System zu nutzen, ohne den Grund zu kennen, ist die natürliche Reaktion Misstrauen. Was war falsch am alten Weg? Geht es darum, uns zu überwachen? Wird unsere Arbeit dadurch schwerer?
Die Mitarbeiter waren nicht am Prozess beteiligt. Teams, die keine Möglichkeit hatten, das neue System mitzugestalten, haben oft das Gefühl, dass es nach der Vorstellung von jemandem anderen gebaut wurde — nicht so, wie die Arbeit tatsächlich abläuft.
Die Schulungen waren unzureichend oder schlecht terminiert. Eine einzige Schulungssitzung eine Woche vor dem Launch ohne Nachbereitung lässt die Menschen unvorbereitet zurück. Der Druck, die eigentliche Arbeit zu erledigen und gleichzeitig ein neues Werkzeug zu erlernen, führt zuverlässig zur Frustration.
Das alte System wurde nicht vollständig abgelöst. Wenn Mitarbeiter weiterhin auf Tabellen, E-Mail-Ketten oder die alte Software zurückgreifen können, tun viele das. Parallelsysteme teilen die Aufmerksamkeit, erzeugen Dateninkonsistenzen und verlangsamen die Akzeptanz erheblich.
Widerstand wurde als Obstruktion und nicht als Feedback behandelt. Mitarbeiter, die sich einem neuen System widersetzen, weisen oft auf echte Probleme hin — Funktionen, die nicht zu tatsächlichen Arbeitsabläufen passen, Begriffe, die nicht der Denkweise des Teams entsprechen, oder fehlende Funktionalität. Dieses Feedback abzuweisen, macht die Situation schlimmer.
Beginnen Sie, bevor die Software fertig ist
Das effektivste Change Management beginnt nicht beim Launch. Es beginnt während des Projekts selbst.
Auch wenn ein System auf der Grundlage Ihrer Vision als Eigentümer oder Führungskraft entwickelt wird, haben die Menschen, die es täglich nutzen werden, Wissen, das Sie möglicherweise nicht haben. Sie wissen, welche Sonderfälle wichtig sind, welche Prozesse komplizierter sind als sie auf dem Papier aussehen, und welche Informationen sie tatsächlich griffbereit brauchen.
Mindestens einige Schlüsselbenutzer bereits in der Designphase einzubeziehen — ihnen frühe Entwürfe zu zeigen, sie durch den beabsichtigten Arbeitsablauf zu führen, sie zu fragen, was sie anders machen würden — dient zwei Zwecken. Erstens entsteht bessere Software. Zweitens entstehen interne Fürsprecher, die das System verstehen, daran glauben und ihren Kollegen helfen können, wenn die Zeit kommt.
Diese internen Fürsprecher — manchmal auch Change Champions genannt — sind eines der wertvollsten Mittel, die Sie bei einem Rollout haben.
Kommunizieren Sie das Warum vor dem Was
Wenn Sie bereit sind, die bevorstehende Veränderung Ihrem breiteren Team anzukündigen, widerstehen Sie der Versuchung, mit Funktionen zu beginnen. Niemanden interessiert, dass das neue System ein besseres Reporting-Dashboard hat. Die Menschen interessiert, ob ihre Arbeit dadurch schwerer wird.
Kommunikation, die funktioniert, ist ehrlich über den Kontext:
- Welches Problem löst die neue Software?
- Wie wurde die Entscheidung getroffen, sie zu entwickeln?
- Was ändert sich für jedes Team?
- Was bleibt gleich?
- Was passiert mit dem alten System?
- Wann geschieht das, und wie sieht der Zeitplan aus?
Klare Antworten auf diese Fragen, die gegeben werden, bevor die Menschen danach fragen, reduzieren die Angst erheblich. Unsicherheit ist der Treibstoff für Widerstand. Information ist das Gegenmittel.
Gestalten Sie Schulungen um echte Arbeit, nicht um Funktionen
Der Instinkt vieler Unternehmen ist es, eine Demonstration der Software zu arrangieren — einen Durchgang durch jeden Bildschirm und jede Funktion, geleitet von demjenigen, der das System implementiert hat. Das ist selten wirksam. Menschen erinnern sich sehr wenig an eine Demonstration, die sie passiv beobachten — besonders wenn sie wegen der Veränderung ängstlich sind.
Schulungen, die funktionieren, sehen anders aus:
Sie sind praktisch. Menschen lernen Software, indem sie sie benutzen, nicht indem sie jemand anderem dabei zusehen. Wo immer möglich, sollten Schulungen echte Aufgaben in einer Testumgebung beinhalten.
Sie sind rollenspezifisch. Ein Lagerleiter und ein Buchhalter müssen nicht die gleichen Teile des Systems verstehen. Die Aufteilung der Schulungen nach Rolle bedeutet, dass jeder das lernt, was er tatsächlich braucht.
Sie finden nahe am Launch-Datum statt. Schulungen, die zwei Monate vor dem Launch stattfinden, werden weitgehend vergessen sein. Schulungen, die ein oder zwei Wochen vorher stattfinden, mit dem echten System kurz danach verfügbar, führen viel besser zu dauerhaft erlernten Fähigkeiten.
Sie werden durch Referenzmaterialien unterstützt. Nicht umfangreiche Handbücher, sondern kurze, aufgabenspezifische Leitfäden — „wie man eine Rückgabe bearbeitet", „wie man einen Monatsbericht erstellt" — die die Mitarbeiter in den ersten Wochen nachschlagen können, wenn sie nicht weiterkommen.
Sie beinhalten einen klaren Support-Pfad. Die Mitarbeiter müssen wissen, wen sie fragen können, wenn sie etwas nicht herausfinden. Das kann Ihr interner Champion sein, ein designierter Hilfe-Kontakt oder direkter Support von Ihrem Entwicklungspartner.
Gestalten Sie die Übergangsphase aktiv
Die ersten vier bis sechs Wochen nach dem Launch sind die kritischsten. In dieser Zeit bilden sich Gewohnheiten, Menschen stoßen auf die Schwachstellen, und die Versuchung, zu alten Wegen zurückzukehren, ist am höchsten.
Einige Praktiken machen diese Phase reibungsloser:
Legen Sie ein klares Datum fest, an dem das alte System endet. Wenn Sie intern vereinbart haben, dass das alte System an einem bestimmten Datum abgeschaltet wird, kommunizieren Sie dies klar und halten Sie daran fest. Unbefristeter Parallelbetrieb ist schädlich.
Halten Sie regelmäßige kurze Check-ins ab. Kurze wöchentliche oder zweiwöchentliche Gespräche mit Teamleitern im ersten Monat geben Ihnen frühzeitige Warnsignale bei Problemen, bevor sie sich festsetzen. Was funktioniert? Wo hakt es? Welche Fragen tauchen immer wieder auf?
Unterscheiden Sie zwischen „ich brauche Hilfe" und „das ist wirklich kaputt". Eine gewisse Reibung ist bei jedem neuen System normal. Manche Reibungspunkte weisen auf echte Lücken in der Software hin. Ihr Entwicklungspartner sollte in dieser Phase eingebunden sein, um beides zu unterscheiden und echte Probleme schnell zu beheben.
Feiern Sie frühe Erfolge. Wenn ein Team seinen ersten Monatsabschluss mit dem neuen System abschließt, wenn der erste Auftrag reibungslos durchläuft, wenn ein Bericht, der früher vier Stunden dauerte, jetzt zwanzig Minuten dauert — erkennen Sie das an. Kleine Anerkennungen stärken die Überzeugung, dass die Veränderung es wert war.
Wie echte Softwareakzeptanz aussieht
Nach einem erfolgreichen Rollout wird die Software auf die richtige Weise unsichtbar. Die Menschen denken nicht an das Werkzeug — sie erledigen einfach ihre Arbeit. Die alten Workarounds wurden aufgegeben. Die Daten befinden sich am richtigen Ort. Die Prozesse, die das System unterstützen sollte, laufen tatsächlich durch es.
Das passiert nicht automatisch. Es ist das Ergebnis davon, die menschliche Seite der Veränderung mit derselben Ernsthaftigkeit zu behandeln wie die technische Seite.
Die Unternehmen, die das richtig hinbekommen, teilen ein gemeinsames Verständnis: Die Software ist nicht die Lösung. Die Software ist der Enabler. Die Lösung ist ein Team, das sie gut nutzt.
Planen Sie einen Software-Rollout, oder sind Sie noch in der Designphase und fragen sich, wie Sie Ihr Team optimal aufstellen? Sprechen Sie mit uns. Wir begleiten Kunden durch den gesamten Bogen eines Softwareprojekts — nicht nur durch die Entwicklung.