Neue Software im Unternehmen einführen: Wie deine Mitarbeitenden sie wirklich nutzen

Mit der Abnahme ist die Software fertig, aber noch nicht eingeführt. Ob deine Mitarbeitenden sie nutzen, entscheidet sich danach: ob sie wissen, wie sie funktioniert, ob ihre alten Daten drin sind und ob der Umstieg ihren Arbeitstag nicht lahmlegt. Diese Phase gehört in die Projektplanung, bevor der Vertrag unterschrieben wird, und nicht erst auf den Tag nach dem Launch. Der Artikel zeigt einen Ablauf, den du an deine Größe anpassen kannst.

Einführung ist eine eigene Aufgabe

Ein Entwicklungsvertrag endet üblicherweise mit der Abnahme. Was danach kommt, liegt bei dir: Schulung der Beteiligten, Übernahme der Daten, Umstieg vom alten Verfahren, Betreuung in den ersten Wochen. Wenn du hier nichts plant, bleibt der Aufwand an einzelnen Mitarbeitenden hängen, die nebenbei eine neue Anwendung verstehen sollen. Frag deshalb schon im Angebot, welche Einführungsleistungen enthalten sind, und lege fest, was du selbst übernimmst.

Schritt 1: Beteilige die späteren Nutzer früh

Software, die ohne Beteiligung der Anwender entsteht, trifft deren Arbeitsweise nur zufällig. Binde deshalb schon beim Anforderungsdokument mindestens eine Person aus jeder Nutzergruppe ein. Sie kennen die Sonderfälle, die in keinem Prozesshandbuch stehen, und sie sind später deine Multiplikatoren. Wie du ihre Anforderungen sammelst, steht im Artikel Lastenheft erstellen ohne IT-Hintergrund.

Benenne außerdem pro Abteilung einen Key User: eine Person, die die Anwendung früh kennenlernt, Kolleginnen und Kollegen bei Fragen hilft und Rückmeldungen gesammelt an das Projektteam gibt. Plane dafür Arbeitszeit ein, sonst wird die Aufgabe zum Nebenbei-Job.

Schritt 2: Teste mit einer Pilotgruppe

Statt alle gleichzeitig umzustellen, lässt du eine kleine Gruppe die Software zuerst im echten Arbeitsalltag nutzen. Das deckt Probleme auf, die kein Abnahmetest findet, weil echte Arbeit andere Wege geht als Testfälle. Lege vorab fest:

Wer gehört zur Pilotgruppe (bevorzugt die Key User plus einige weitere)?
Wie lange läuft der Pilot, zum Beispiel zwei Wochen?
Welche Rückmeldungen werden wie erfasst (gemeinsame Liste, wöchentliches Kurztreffen)?
Wer entscheidet am Ende, ob der Rollout starten kann, und anhand welcher Kriterien?

Plane Zeit für Korrekturen nach dem Pilot ein und stimme mit dem Dienstleister ab, ob diese Anpassungen im Festpreis enthalten sind oder als Weiterentwicklung gelten. Der Abgrenzung zwischen Mangel und Änderungswunsch widmet sich der Artikel Wie die Abnahme eines Softwareprojekts funktioniert.

Schritt 3: Übernimm die Daten sauber

Neue Software ohne Altdaten ist für die Nutzer wertlos. Kläre früh:

Welche Daten werden übernommen (alle, nur aktive Vorgänge, nur eine bestimmte Zeitspanne)?
In welchem Zustand sind die Altdaten? Dubletten, uneinheitliche Schreibweisen und fehlende Pflichtfelder fallen bei der Übernahme auf, und das Bereinigen ist Fachaufgabe, die bei dir liegt.
Wer prüft nach der Übernahme stichprobenartig, ob Datensätze vollständig und richtig angekommen sind?

Der Aufwand für die Datenübernahme wird in Angeboten gern unterschätzt. Lass ihn als eigene Position ausweisen.

Schritt 4: Plane den Umstieg

Es gibt zwei grundlegende Strategien:

Stichtag-Umstellung: Ab einem festen Datum arbeitet das gesamte Team nur noch in der neuen Software. Das ist einfach zu kommunizieren, verlangt aber eine gute Vorbereitung und einen Plan für den Fall, dass am ersten Tag etwas nicht funktioniert.
Parallelbetrieb: Altes und neues Verfahren laufen für einen begrenzten Zeitraum nebeneinander. Das senkt das Risiko, verdoppelt aber die Arbeit und birgt die Gefahr, dass Daten in beiden Systemen auseinanderlaufen. Lege deshalb ein klares Enddatum fest.

Welche Variante passt, hängt von der Kritikalität der Abläufe ab. Bei Software, die Aufträge oder Zahlungen abwickelt, ist ein Rückfallplan unverzichtbar. Wie du beim Ablösen eines Altsystems Risiken begrenzt, beschreibt der Artikel Legacy-System ablösen, ohne den Betrieb zu gefährden.

Schritt 5: Schulen, was der Arbeitsalltag braucht

Schulungen wirken, wenn sie sich an konkreten Aufgaben orientieren. Statt jede Funktion zu erklären, übt die Gruppe die zehn Handlungen, die sie täglich ausführt. Hilfreich sind:

eine kurze Schnellstart-Anleitung pro Rolle,
Aufzeichnungen der Schulung für neue Kolleginnen und Kollegen,
ein fester Ansprechpartner für Fragen in den ersten Wochen,
eine Sprechstunde nach dem Start, in der Key User und Projektteam Fragen sammeln.

Vereinbare mit dem Entwicklungspartner, welche Dokumentation er liefert (Benutzerhandbuch, Administrationshandbuch) und ob er Schulungen hält. Das gehört in den Vertrag und nicht in eine mündliche Absprache.

Schritt 6: Miss nach dem Start, ob die Software genutzt wird

Lege vorab fest, woran du den Erfolg erkennst, und prüfe es nach vier bis sechs Wochen. Mögliche Messgrößen sind die Zahl aktiver Nutzer, die Bearbeitungsdauer eines Vorgangs im Vergleich zu vorher, die Anzahl von Supportanfragen und die Rückmeldungen der Key User. Fällt eine Kennzahl hinter dein Ziel zurück, siehst du, wo nachgebessert werden muss. Das kann eine Schulung sein, aber auch eine Funktion, die im Alltag anders gebraucht wird als geplant. Zur Nachbetreuung nach dem Launch gehört auch Wartung und Weiterentwicklung.

Fazit

Die Einführung entscheidet, ob die Investition ankommt. Beteilige Anwender früh, benenne Key User, teste mit einer Pilotgruppe, plane Datenübernahme und Umstieg mit Rückfallplan, schule entlang der täglichen Aufgaben und miss nach dem Start. Halte im Vertrag fest, welche dieser Leistungen der Dienstleister übernimmt.

Häufig gestellte Fragen

Wann sollte ich mit der Einführungsplanung beginnen?

Schon beim Erstellen des Lastenhefts. Die Auswahl der Key User, der Umfang der Datenübernahme und der Umstiegszeitpunkt beeinflussen Zeitplan und Kosten und lassen sich nach der Abnahme nur noch schwer in das Projekt einbauen.

Wie lange sollte ein Pilotbetrieb dauern?

Das hängt von der Häufigkeit der Arbeitsabläufe ab. Wenn die wichtigsten Abläufe täglich vorkommen, kann ein Pilot von ein bis zwei Wochen aussagekräftig sein. Bei Abläufen, die nur monatlich auftreten, brauchst du entsprechend mehr Zeit oder gezielt nachgestellte Fälle.

Muss der Entwicklungspartner die Schulung übernehmen?

Nicht zwingend, aber er kennt die Anwendung am besten. Alternativ schulst du die Key User, die ihr Wissen weitergeben. Entscheidend ist, dass im Vertrag steht, wer was liefert.