„Geben wir dem Ganzen noch zwei Wochen Übergangszeit.“ Wer diesen Satz bei einer Software-Einführung schon einmal gesagt hat, kennt das Ende: Aus den zwei Wochen werden zwei Monate, und das neue Tool kommt nie richtig in Gang. Ich habe rund zehn Jahre als IT-Leiter interne Tools gebaut, und dieser Satz — immer gut gemeint — steckte hinter den meisten meiner gescheiterten Einführungen.
Die kurze Antwort
Wie bringen Sie Ihr Team dazu, neue Software zu nutzen? Beziehen Sie die Leute früh ein, wählen Sie ein Tool, das sich von selbst erklärt, schulen Sie an echten Arbeitsabläufen und feiern Sie die ersten Erfolge. So steht es im Lehrbuch, und das ist nicht falsch. Einführung ist genauso ein Change-Thema wie ein Software-Thema.
Nur hat das Lehrbuch für sich allein nie gereicht. Was wirklich funktioniert hat, war einfacher — und deutlich unbequemer:
Wir haben das alte System abgeschaltet.
Jedes Mal, wenn wir neue Software eingeführt oder einen Prozess geändert haben, nahmen wir den alten Weg vom Tisch. Tabelle gesperrt, altes Formular offline. Die Leute murrten zwei Wochen lang und stiegen dann um. Und sobald jeder Prozess über das neue Tool lief, konnten wir endlich enorm viel Handarbeit automatisieren — weil der einzige Weg durch den Prozess durch Software führte, die wir selbst kontrollierten.
Ich gehe zuerst das Standard-Vorgehen durch, denn das brauchen Sie weiterhin. Danach kommt die Umstellungstechnik, samt der Frage, wie Sie sie durchziehen, ohne dass Ihr Team Sie hasst.
Warum Teams sich gegen neue Software wehren
Es liegt fast nie an der Software.
Das Anzeichen. In zehn Jahren interner Tool-Einführungen habe ich kaum je einen Nutzer erlebt, der ein neues Tool aus fachlichen Gründen ablehnte. Was mir immer wieder begegnete, war schlichte Angst vor Veränderung.
Die Ursache. Die alte Tabelle mag langsam und mit Copy-Paste zusammengehalten sein — aber sie gehört ihnen. Sie wissen, wo alles steht, sie sind schnell darin. Ein neues Tool, selbst ein offensichtlich besseres, lässt sie zwei Wochen lang langsam und unfähig wirken, und dafür meldet sich niemand freiwillig. Die viel zitierte Schätzung von McKinsey lautet, dass rund 70 % der Veränderungsprogramme ihre Ziele verfehlen, und der übliche Grund ist der Widerstand derjenigen, die mit der Veränderung leben müssen. Jede Arbeitsplatz-Umfrage, die mir zuletzt untergekommen ist, sagt eine Variante desselben Satzes: Mitarbeitende fühlen sich ohnehin von Tools überschüttet und gehen davon aus, dass jedes neue Tool ihnen mehr Arbeit bringt.
Die Lösung steckt nicht in der Software — sie besteht darin, die Einführung als das zu behandeln, was sie tatsächlich ist: ein Change-Projekt, an dem zufällig Technik beteiligt ist. Alles Weitere folgt daraus.
Das Standard-Vorgehen (machen Sie das zuerst)
Der Standardrat ist Standard, weil er funktioniert. Wer ihn überspringt, den rettet auch kein Umstellungstrick.
1. Beziehen Sie das Team früh ein
Die Menschen, die täglich in dem Tool arbeiten werden, sollten es mitformen. Holen Sie zwei oder drei Ihrer künftigen Vielnutzer in den Bauprozess, zeigen Sie ihnen Prototypen, lassen Sie sie Dinge kaputt machen. Wer ein Tool mitgestaltet hat, verteidigt es später — und bringt es am Ende allen anderen im Umfeld bei.
Genau hier schlägt der Eigenbau interner Tools den Kauf von der Stange. Wenn jemand eine Änderung wünscht und sie noch in derselben Woche live sieht, fängt er an, das Tool als sein eigenes zu betrachten. Ein Anbieter, der „steht auf der Roadmap“ antwortet, bewirkt das genaue Gegenteil.
2. Wählen Sie ein Tool, das sich von selbst erklärt
Jeder zusätzliche Klick kostet Sie Akzeptanz. Wenn das Tool für die einfachste Tagesaufgabe ein Handbuch braucht, steckt die Einführung schon in Schwierigkeiten. Meine Messlatte war immer dieselbe: Ein neuer Nutzer schafft den Kernablauf beim ersten Versuch, ohne Hilfe. Wenn nicht, reparieren Sie das Tool, bevor Sie die Schulung reparieren.
3. Schulen Sie an echten Abläufen, nicht an Funktionen
Eine Führung durch die Einstellungsseite interessiert niemanden. Schulen Sie jedes Team an seiner konkreten Arbeit: „So erfassen Sie eine Kundenreklamation“, „So geben Sie eine Bestellung frei“. Mit echten Daten und echten Sonderfällen. Eine halbe Stunde rund um den realen Dienstag einer Kollegin bringt mehr als zwei Stunden Funktionsdurchlauf.
4. Feiern Sie die ersten Erfolge
Suchen Sie den ersten Moment, in dem das neue Tool den alten Weg klar geschlagen hat — der Report, der früher vier Stunden brauchte und jetzt zehn Minuten dauert, so etwas. Erzählen Sie es allen und nennen Sie die Beteiligten beim Namen. Frühe Erfolge liefern den Unentschlossenen den Beweis, dass der Wechsel sicher ist, und der Führungsebene einen Grund, das Projekt weiter zu tragen.
Die Technik, die wirklich gewirkt hat: das alte System abschalten
Zehn Jahre Einführungen haben mich etwas Unbequemes gelehrt: Sie können alle vier Schritte oben richtig machen und trotzdem zusehen, wie die Einführung stirbt. Aus einem einzigen Grund.
Das Anzeichen. Jedes Mal, wenn wir ein neues Tool „für eine Übergangsphase“ neben dem alten laufen ließen, passierte dasselbe: In Woche eins schoss die Nutzung hoch, danach sickerte sie zurück in die alte Tabelle.
Die Ursache. Solange der alte Weg existiert, nehmen die Leute den alten Weg. Die Übergangsphase endet nie von selbst. Freiwillige Einführung ist in Wahrheit nur ein langsames Nein.
Die Lösung war, parallele Systeme zu beenden. Am Umstellungstag ging die alte Tabelle auf schreibgeschützt und das alte Formular vom Netz. Die neue Software war der einzige Weg, die Arbeit zu erledigen.
Und jedes Mal passierte dasselbe: Die Debatte darüber, ob man wechseln solle, war schlicht vorbei, und diese Energie floss direkt ins Lernen des neuen Tools. Die unangenehmen zwei Wochen gingen tatsächlich zu Ende, weil das ganze Team sie gemeinsam durchlief, statt sie endlos aufzuschieben. Echte Probleme kamen binnen Tagen ans Licht, weil alle gleichzeitig darauf stießen, und wir behoben sie, solange die Aufmerksamkeit noch hoch war. Und alle Daten lagen endlich an einem Ort.
Es ist das Prinzip „Schiffe verbrennen“, angewendet auf Bürosoftware. Cortés soll seine Schiffe versenkt haben, damit der Rückzug keine Option mehr war. So dramatisch muss es nicht sein — eine Tabelle auf schreibgeschützt zu setzen erfüllt denselben Zweck.
Die Automatisierungsdividende
Diesen Teil überspringen die meisten Artikel über Software-Einführung, und für uns war er mit Abstand der größte Gewinn.
Sobald ein Prozess nur noch über die neue Software lief, wurde jeder Schritt dieses Prozesses für ein System sichtbar — und damit endlich automatisierbar. Freigaben leiteten sich selbst weiter. Wochenberichte waren nicht länger jemandes Freitagnachmittag. Nichts davon war vorher möglich gewesen, weil die Hälfte jedes Prozesses verstreut in Postfächern und persönlichen Tabellen lag, die kein System sehen konnte.
Die Einführung war für uns nie das Ziel. Sie war die Voraussetzung. Der eigentliche Ertrag zeigt sich danach, wenn der ganze Prozess in einem System sitzt, das Sie tatsächlich kontrollieren.
Wie Sie eine erzwungene Umstellung durchziehen, ohne Ihr Team zu zermürben
Zur Klarstellung: Das alte System abzuschalten ist keine Ausrede, die Change-Arbeit zu überspringen. Im Gegenteil, es erhöht den Einsatz, also muss die Vorbereitung besser werden, nicht schlechter. Das ist das Vorgehen, auf das wir uns nach einigen Fehlversuchen geeinigt haben.
- Nehmen Sie nichts weg, bevor das neue Tool wirklich fertig ist. Eine erzwungene Umstellung auf etwas Halbfertiges verbrennt Vertrauen, das Sie so schnell nicht zurückbekommen. Der Kernablauf muss stabil und mit echten Nutzern getestet sein, bevor irgendetwas gesperrt wird.
- Kündigen Sie den Termin Wochen vorher an — und wiederholen Sie ihn. „Am 15. geht die alte Liste auf schreibgeschützt.“ Keine Überraschungen. Was Menschen fürchten, ist die Überraschung; auf ein Datum können sie sich vorbereiten.
- Migrieren Sie die Daten selbst. Bitten Sie Nutzer nie, ihre eigenen Datensätze umzuziehen. Wenn ihre Historie am ersten Tag schon im neuen System liegt, haben Sie den größten sachlichen Einwand entfernt.
- Sperren Sie das alte System, löschen Sie es nicht. Die Leute entspannen sich, wenn nichts verloren geht, und Sie behalten nebenbei eine lückenlose Nachvollziehbarkeit.
- Überbesetzen Sie den Support in Woche eins. Sprechstunden, ein eigener Chat-Kanal, jemand, der durchs Büro geht. Der meiste Widerstand löst sich auf, wenn Hilfe in unter fünf Minuten da ist.
- Bleiben Sie standhaft. Irgendjemand wird „nur diese eine Ausnahme“ erbitten. Diese erste Ausnahme wird zum neuen alten System. Die Antwort muss ein freundliches, festes Nein sein — plus eine echte Lösung für die tatsächliche Lücke hinter der Bitte.
- Beheben Sie Gemeldetes schnell und sichtbar. Woche eins einer Umstellung bringt eine Flut ehrlicher Rückmeldungen. Korrekturen binnen Tagen auszuliefern ist das, was die Skeptiker überzeugt.
Wo AgentUI hineinpasst
Eine erzwungene Umstellung funktioniert nur, wenn das neue Tool wirklich besser ist und Sie es so schnell verbessern können, wie Rückmeldungen eintreffen. Das ist der schwierige Teil — und genau da kommt AgentUI ins Spiel.
Mit AgentUI bauen Fachteams maßgeschneiderte interne Tools mit KI: rund 30 Minuten bis zur ersten funktionierenden Version, danach laufend verfeinert, während die Nutzer reagieren. Dieses Tempo verändert die ganze Rechnung: Wenn jemand am Montag eine Lücke meldet und sie am Mittwoch behoben sieht, gewinnt das Tool schneller Vertrauen als jede Schulung. AgentUI bringt außerdem ab Tag eins persönliches Onboarding mit — ein echtes Team aus Menschen, das die Einführung mit Ihnen plant und Ihre Daten migriert, damit Sie die Veränderung nicht allein stemmen.
Ihre Prozesse auf einer Plattform zusammenzuführen ist auch das, was die Automatisierungsdividende freilegt. Sobald die Arbeit durch ein einziges, geregeltes System läuft statt durch verstreute Tabellen, lassen sich die wiederkehrenden Teile endlich automatisieren.
Häufige Fragen
Schadet es nicht der Stimmung, Nutzer zum Wechsel zu zwingen?
Nach meiner Erfahrung schadet unbefristete Unklarheit der Stimmung mehr als ein sauberer Schnitt mit klarem Datum. Was die Stimmung wirklich beschädigt, ist der Zwang auf ein Tool, das nicht funktioniert, ohne Unterstützung und ohne Mitsprache. Wenn das Tool fertig ist, Hilfe bereitsteht und Rückmeldungen sichtbar zu Korrekturen führen, empfinden die meisten Teams Erleichterung: Die Entscheidung ist gefallen, und alle sind gemeinsam umgezogen.
Was, wenn mein Team seine Arbeit im neuen Tool wirklich nicht erledigen kann?
Dann haben Sie zu früh umgestellt. Stellen Sie den Zugang wieder her, schließen Sie die Lücken mit Ihren Pilotnutzern und setzen Sie einen neuen Termin. Die Technik heißt „das alte System abschalten, sobald das neue fertig ist“ — nicht „abschalten und das Beste hoffen“.
Wie lange sollten altes und neues System parallel laufen?
Tage, wenn Sie es einrichten können. Nutzen Sie ein kurzes Parallelfenster nur zur Datenprüfung, geben Sie ihm ein öffentlich angekündigtes Enddatum und halten Sie sich daran. Eine Parallelphase, die bequem wird, wird meistens dauerhaft.
Woran messe ich, ob die Einführung wirklich geklappt hat?
Achten Sie auf drei Dinge: aktive Nutzung (sind alle vorgesehenen Nutzer wöchentlich im Tool?), Prozessabschluss (läuft die Arbeit von Anfang bis Ende darüber?) und Schattensysteme (tauchen leise neue Tabellen auf?). Das dritte ist das Frühwarnsignal, das die meisten Teams vergessen zu prüfen.
Wie schnell lässt sich ein internes Tool bauen, für das sich der Wechsel lohnt?
Mit AgentUI dauert eine erste funktionierende Version typischerweise rund 30 Minuten und ein produktionsreifes internes Tool etwa eine Woche. Darin enthalten sind die Iterationsrunden mit Ihren Pilotnutzern, die eine selbstbewusste Umstellung überhaupt erst möglich machen.
Bereit, ein internes Tool zu bauen, das Ihr Team tatsächlich nutzt, und die Tabelle endgültig in Rente zu schicken?
AgentUI kostenlos testen — bauen Sie Ihr erstes internes Tool in Minuten.