Jedes Unternehmen kennt die Geschichte vom Tool, das niemand nutzt. Es wurde sorgfältig ausgewählt, hat sich in der Evaluierung gegen drei Wettbewerber durchgesetzt, die Integration funktioniert, die Lizenzen verlängern sich jedes Jahr, und die eigentliche Arbeit findet trotzdem in einer Tabelle statt, die jemand von Hand pflegt. Nichts ist kaputtgegangen. Der Rollout ist einfach leise gescheitert, und weil er leise gescheitert ist, musste es niemand erklären.
Genau das sollten Sie an einem Software-Rollout verstehen: Das Risiko ist fast nie technisch. Das Deployment ist ein gelöstes Problem: Provisionierung, SSO, Berechtigungen und Datenmigration sind anspruchsvoll, aber sie sind Engineering, und Engineering wird irgendwann fertig. Was nicht von allein fertig wird, ist der Teil, in dem ein paar hundert Menschen, die letzten Dienstag noch völlig produktiv waren, sich dafür entscheiden, vorübergehend langsamer und schlechter in ihrem Job zu sein, im Tausch gegen einen Nutzen, den ihnen jemand anderes in einem Kick-off-Meeting beschrieben hat. Ein Software-Rollout-Plan existiert, damit dieser Tausch gelingt.
Dieser Leitfaden ist die praktische Version jeder Software-Einführung. Was ein Rollout-Plan wirklich enthalten muss, warum Rollouts in den Wochen nach dem Go-live scheitern und nicht währenddessen, wie Sie zwischen einer Big-Bang- und einer phasenweisen Rollout-Strategie wählen, ein Prozess in acht Schritten, den Sie komplett übernehmen können, wie Sie Ihre Wellen dimensionieren und mit Gates absichern, welche Adoption-Kennzahlen etwas aussagen und wie Sie die Anleitung direkt in der Software bereitstellen. Genau das unterscheidet einen Rollout, der hält, von einem, der zerfällt, sobald die Schulung vorbei ist.
Das Wichtigste in Kürze
- Das Deployment endet, wenn die Software funktioniert; ein Rollout endet, wenn Menschen sie nutzen. Die meisten Pläne sind Deployment-Zeitpläne mit einem Go-live-Termin und ohne Adoption-Plan dahinter.
- Phasenweise schlägt Big Bang, solange keine harte Abhängigkeit einen einzigen Termin erzwingt. In Wellen lassen sich die Probleme jeder Gruppe beheben, bevor die nächste Gruppe darauf stößt, und die Support-Last bleibt in dem Rahmen, den Ihr Helpdesk bewältigen kann.
- Jede Welle braucht ein Go/No-Go-Gate mit echten Zahlen. „Welle 2 startet am 14.“ ist ein Kalendereintrag. „Welle 2 startet, wenn 70 % von Welle 1 die Kernaufgabe erledigt haben“ ist ein Plan.
- Schulungswissen verblasst, In-App-Anleitungen nicht. Was zwei Wochen vor dem Go-live gelernt wurde, ist größtenteils vergessen, wenn es gebraucht wird; eine Anleitung, die im Moment der Aufgabe erscheint, funktioniert weiter, auch für den neuen Kollegen, der im sechsten Monat dazukommt.
- Zugewiesene Lizenzen sind keine Adoption-Kennzahl. Messen Sie Reichweite, Aktivierung, Tiefe und Dauerhaftigkeit, und achten Sie auf die stille Rückkehr zum alten Tool.
- Legen Sie das Abschaltdatum früh fest. Ein Rollout ohne Enddatum für den alten Weg wird zum dauerhaften Parallelbetrieb, und das ist das teuerste mögliche Ergebnis.
Was ist ein Software-Rollout? (Und was gehört in einen Rollout-Plan?)
Ein Software-Rollout ist der geplante Prozess, ein neues Tool in die Hände der Menschen zu geben, die es nutzen sollen, und sie dazu zu bringen, ihre echte Arbeit darin zu erledigen. Die Unterscheidung, auf die es ankommt und die die meisten Pläne verwischen, ist die zwischen Deployment und Rollout.
Software-Rollout, definiert. Das Deployment ist ein technisches Ereignis: Es endet, wenn die Software installiert, erreichbar und funktionsfähig ist. Ein Rollout ist ein Ereignis des Verhaltens: Er endet, wenn die vorgesehenen Nutzer die vorgesehene Arbeit im neuen Tool erledigen, ohne dafür Hilfe zu brauchen. Ein makelloses Deployment und ein gescheiterter Rollout schließen sich nicht aus; genau das ist sogar der typische Fall des Scheiterns.
Ein Rollout-Plan ist also kein Projektzeitplan mit einem Go-live-Termin. Ein brauchbarer Plan beantwortet schriftlich acht Fragen, und wenn er das nicht kann, ist er ein Deployment-Zeitplan, der sich nur Rollout-Plan nennt:
| Die Frage | Was ein schwacher Plan sagt | Was ein brauchbarer Plan sagt |
|---|---|---|
| Wofür ist das? | „Unseren Tech-Stack modernisieren“ | „Angebotsdurchlaufzeit von 3 Tagen auf denselben Tag senken, für die 60 Personen im Sales Ops“ |
| Wer ist betroffen, in welcher Reihenfolge? | „Alle, zum 1.“ | Benannte Wellen, dimensioniert und in Reihenfolge gebracht, mit einem Verantwortlichen pro Welle |
| Was muss jede Gruppe am ersten Tag können? | „Einloggen und umschauen“ | Die zwei oder drei Aufgaben, die den aktuellen Workflow ersetzen, aufgelistet pro Rolle |
| Wie lernen sie es? | „90-minütige Schulung“ | Anleitung im Tool im Moment der Aufgabe, plus eine kurze Session für den Kontext |
| Wen fragen sie, wenn etwas nicht funktioniert? | „Ticket aufmachen“ | Ein benannter Champion pro Team, ein Hilfeweg in der App und eine Reaktionszeit, an die man glaubt |
| Was messen wir? | „Zugewiesene Lizenzen“ | Reichweite, Aktivierung, Tiefe, Dauerhaftigkeit, mit Schwellenwerten pro Welle |
| Was, wenn eine Welle scheitert? | (unbeantwortet) | Ein ausdrückliches Go/No-Go-Gate und was vor der nächsten Welle behoben wird |
| Wann endet der alte Weg? | (unbeantwortet) | Ein festes Abschaltdatum, vorab angekündigt und durchgesetzt |
Rollouts gibt es in einigen Varianten, und die Form des Plans ändert sich mit jeder leicht: der interne Rollout eines neuen Tools an Mitarbeiter, der Migrations-Rollout, der etwas ersetzt, auf das sich die Menschen bereits verlassen (der schwierigste Fall: Sie konkurrieren mit einer funktionierenden Gewohnheit), und der Feature-Rollout innerhalb eines Produkts, das Ihre Nutzer schon haben, was eher dem Ankündigen einer neuen Funktion gleicht als einem vollständigen Deployment. Der Prozess in acht Schritten unten ist für die ersten beiden geschrieben; das meiste davon lässt sich im kleineren Maßstab auf den dritten übertragen.
Warum Software-Rollouts scheitern (es liegt fast nie an der Software)
Post-Mortems gescheiterter Rollouts geben meist dem Tool die Schuld, weil das Tool nicht widersprechen kann. Die wahren Ursachen sind langweilig beständig, und jede davon lässt sich schon in der Planung verhindern:
-
Das „Warum“ wurde für den Käufer geschrieben, nicht für den Nutzer
Der Business Case, der den Kauf gerechtfertigt hat (Konsolidierung, Lizenzeinsparungen, besseres Reporting für die Geschäftsführung), interessiert die Person, die sich umstellen soll, oft überhaupt nicht. Wenn die Antwort auf „Was habe ich davon?“ lautet „Das Management bekommt ein schöneres Dashboard“, werden die Leute auf die minimale Art mitmachen, die Ärger vermeidet. Im Lizenzbericht sieht das genau wie Adoption aus, in der Praxis kein bisschen.
-
Die Schulung fand Wochen vor dem Bedarf statt
Der übliche Ablauf (eine Schulung, dann eine Lücke, dann das Go-live) richtet sich nach der Verfügbarkeit der Trainer, nicht nach dem menschlichen Gedächtnis. Wenn die Aufgabe dann tatsächlich ansteht, ist das meiste vergessen, und übrig bleibt das vage Gefühl, dass es einmal erklärt wurde und erneutes Nachfragen peinlich wäre. Eine Anleitung, die im Moment der Aufgabe erscheint, hat dieses Problem nicht, und genau das ist das ganze Argument dafür, sie ins Tool zu verlagern.
-
Der alte Weg funktionierte noch
Jeder Rollout konkurriert mit einer funktionierenden Alternative: der Tabelle, dem geteilten Postfach, der persönlichen Vorlage, die seit vier Jahren gute Dienste leistet. Solange der Rückweg möglich und schneller ist, kehrt ein spürbarer Teil der Leute zurück, nicht aus Widerstand, sondern weil am Nachmittag eine Deadline ansteht. Rollouts, die nie ein Abschaltdatum für den alten Weg nennen, entscheiden sich stillschweigend für dauerhaften Parallelbetrieb.
-
Hilfe zu holen war mühsamer als aufzugeben
Der Moment der Wahrheit ist ein Mitarbeiter, der um 16 Uhr nicht weiterkommt. Wenn Hilfe bedeutet, ein PDF zu suchen, das Intranet zu durchforsten oder ein Ticket mit zwei Tagen Reaktionszeit aufzumachen, ist das alte Tool die rationale Wahl. Das ist ganz gewöhnliche User Friction, und sie summiert sich: Jeder ungelöste Stillstand macht den nächsten Versuch unwahrscheinlicher.
-
Niemand hat das Verhalten gemessen, nur den Aufwand
Zugewiesene Lizenzen, durchgeführte Schulungen, Teilnahmequoten: All das misst, was das Rollout-Team getan hat, nichts davon misst, was die Mitarbeiter tun. Ein Rollout kann bei jeder dieser Zahlen 100 % melden, während sich die eigentliche Arbeit keinen Millimeter bewegt hat. Ohne Verhaltenskennzahlen bleibt das Scheitern unsichtbar, bis die Verlängerung ansteht.
-
Es gab einen Launch, aber keinen zweiten Monat
Aufmerksamkeit, Budget und die Zeit der Champions konzentrieren sich alle auf den Go-live-Tag. Doch die Fragen, die darüber entscheiden, ob ein Rollout hält, kommen in den Wochen drei bis acht: die Sonderfälle, der Quartalsprozess, den niemand geprobt hat, die neue Kollegin im sechsten Monat, die jede Schulung verpasst hat. Pläne, die beim Go-live enden, planen nur die leichte Hälfte.
Achten Sie auf das Muster: Fünf der sechs Ursachen betreffen das, was passiert, nachdem die Software funktioniert. Deshalb wird die Adoption-Lücke am Verhalten gemessen, nicht an der Installation, und deshalb öffnet sie sich an vier vorhersehbaren Stellen.
Big Bang oder phasenweiser Rollout: die richtige Rollout-Strategie wählen
Es gibt eigentlich nur zwei Strategien für einen Software-Rollout, plus eine Mischform, die man kennen sollte. Die Wahl bestimmt alles andere im Plan: Zeitplan, Support-Besetzung, wie viel Parallelbetrieb Sie tolerieren und wie viel Sie lernen können, bevor Sie festgelegt sind.
Bei einem Big-Bang-Rollout wechseln alle am selben Tag. Bei einem phasenweisen Rollout wechseln die Menschen in Wellen, jede hinter einem Entscheidungspunkt. Das verlockende Denkmodell lautet „Big Bang ist riskant, phasenweise ist sicher“, aber das trifft es nicht ganz: Der eigentliche Unterschied ist, wann Sie es herausfinden. Big Bang ballt alle Erkenntnisse in einer Woche bei voller Größenordnung. Phasenweise verteilt sie und verschafft Ihnen die Chance, zwischen den Gruppen nachzubessern.
| Strategie | So funktioniert sie | Wählen Sie sie, wenn | Der Preis |
|---|---|---|---|
| Big Bang | Alle stellen an einem Tag um; das alte System wird schreibgeschützt oder abgeschaltet | Das System hat einen gemeinsamen Datenbestand, der sich nicht aufteilen lässt (Lohnabrechnung, ERP, ein einziges Hauptbuch), oder eine vertragliche bzw. regulatorische Frist gibt den Termin vor | Alle Probleme kommen gleichzeitig und in voller Größenordnung, ohne Generalprobe und mit einer Support-Warteschlange, die Sie nicht besetzen können |
| Phasenweise (nach Wellen) | Ein Pilot, dann schrittweise größere Gruppen, jede hinter einem Go/No-Go-Gate | Der Standardfall. Überall dort, wo sich die Arbeit nach Team, Region oder Kunde aufteilen lässt, ohne einen gemeinsamen Prozess zu zerreißen | Wochenlanger Parallelbetrieb; zwei Sätze an Anleitungen; erfordert die Disziplin, ein Gate auch wirklich zu halten |
| Phasenweise (nach Funktion) | Alle bekommen das neue Tool, aber jeweils nur für einen Workflow | Das Tool ersetzt mehrere Workflows, und einer davon ist eindeutig der einfachste Gewinn | Die Menschen arbeiten in zwei Tools gleichzeitig, was auf andere Weise verwirrt; takten Sie die Abfolge eng |
| Parallelbetrieb | Beide Systeme werden bewusst für dieselbe Arbeit genutzt, für ein festes Zeitfenster | Die Ergebnisse müssen abgeglichen und als identisch nachgewiesen werden (Finanzen, Regulierung) | Doppelte Arbeit: nur mit einem harten Enddatum vertretbar, sonst wird er zum Dauerzustand |
Die Mischform-Falle. „Wir machen einen phasenweisen Rollout, aber alle bekommen am ersten Tag Zugriff, damit Motivierte früh anfangen können“ klingt großzügig und wird still und leise zum Big Bang. Der Zugriff ist der Rollout. Wenn sich Welle 3 schon während Welle 1 einloggen kann, haben Sie nichts gestaffelt außer den E-Mails.
Der Software-Rollout-Plan in 8 Schritten
Der folgende Prozess geht von einem phasenweisen Rollout eines Tools aus, das eine bestehende Arbeitsweise ersetzt, dem häufigsten und schwierigsten Fall. Die Schritte 1 bis 4 finden statt, bevor irgendjemand außerhalb des Projekts die Software sieht; die Schritte 5 bis 8 sind der eigentliche Rollout.
- Das Ergebnis in der Sprache der Nutzer definieren, nicht in der des Käufers
- Zielgruppen und Aufgaben für den ersten Tag erfassen, pro Rolle
- Strategie wählen und Wellen gestalten
- Umgebung, Daten und Anleitungen vorbereiten
- Den Pilot durchführen und die Skeptiker gewinnen
- Jede Welle hinter einem Gate starten
- Die mittleren Wochen begleiten, in denen Rollouts tatsächlich sterben
- Den alten Weg abschaffen und in den Regelbetrieb übergeben
1. Das Ergebnis in der Sprache der Nutzer definieren
Schreiben Sie einen Satz, der die Gruppe, die Arbeit und die Veränderung benennt: „Sales Ops erstellt ein individuelles Angebot noch am selben Tag statt in drei Tagen.“ Dieser Satz muss den Kontakt mit der Person überstehen, die die Arbeit macht. Wenn eine Angebotsspezialistin ihn liest und denkt „das würde meine Dienstage wirklich besser machen“, haben Sie einen Rollout. Wenn sie denkt „das ist eine Management-Kennzahl“, haben Sie eine Pflichtübung, und Sie sollten die Version des Nutzens finden, die für sie zutrifft, bevor Sie weitermachen. Meist gibt es eine; sie ist nur nicht die aus dem Business Case.
Schreiben Sie auch das Gegenargument ehrlich auf: was in den ersten Wochen schlechter wird. Irgendetwas wird es immer. Es vorab zu benennen kostet Sie nichts und verschafft Ihnen die Glaubwürdigkeit, die Sie in Woche drei brauchen, wenn es eintritt.
2. Zielgruppen und Aufgaben für den ersten Tag erfassen
Listen Sie jede betroffene Gruppe auf und für jede die zwei oder drei Aufgaben, die sie an ihrem ersten Tag im Tool erledigen können muss, formuliert als Arbeit, nicht als Funktion („eine Gutschrift ausstellen“, nicht „das Abrechnungsmodul nutzen“). Diese Liste ist das Rückgrat von allem, was folgt: Sie bestimmt, was der Pilot testet, was die Anleitung abdeckt, was „Aktivierung“ in Ihren Kennzahlen bedeutet und was das Gate einer Welle misst.
Halten Sie sie radikal kurz. Zehn Aufgaben für den ersten Tag sind ein Lehrplan, und ein Lehrplan wird nicht gelernt. Drei sind ein Rollout. Alles andere gehört in den zweiten Monat und kann später im Tool vermittelt werden, wenn es gebraucht wird: dieselbe Logik wie beim progressiven Onboarding, das ein Produkt nach und nach erklärt statt alles auf einmal.
Dann segmentieren Sie. Eine Controllerin, ein Servicetechniker und eine Teamleiterin brauchen nicht denselben Rollout, und allen dreien denselben generischen Walkthrough zu geben, ist der sicherste Weg, Anleitungen für alle lästig zu machen. Menschen danach zu gruppieren, was sie tatsächlich tun müssen, ist dieselbe Disziplin wie die Nutzersegmentierung in der Produktarbeit, und sie macht gezielte In-App-Anleitungen später überhaupt erst möglich.
3. Strategie wählen und Wellen gestalten
Wählen Sie anhand der Tabelle oben zwischen Big Bang und phasenweise, und wenn phasenweise, legen Sie die Größe der Wellen fest. Ein praktikabler Standard: ein Pilot mit etwa 5–10 % der Nutzer, dann Wellen, die sich jeweils ungefähr verdoppeln, sodass jede Gruppe größer ist als die vorherige, aber nie so groß, dass eine schlechte Woche zum unternehmensweiten Ereignis wird. Zwei Wochen zwischen den Wellen sind ein guter Ausgangsabstand: lang genug, damit verzögerte Probleme sichtbar werden, kurz genug, um den Schwung zu halten.
Definieren Sie dann das Gate jeder Welle vor ihrem Start, in Zahlen. Nicht „Welle 2 startet am 14.“, sondern „Welle 2 startet, wenn 70 % von Welle 1 die Kernaufgabe mindestens zweimal erledigt haben und die offenen Tickets unter X liegen“. Ein Gate, das Sie vorab festlegen, ist eine Entscheidung; ein Gate, das Sie hinterher bewerten, ist eine Rechtfertigung.
5–10 % der Nutzer
~25 % der Nutzer
Alle übrigen
4. Umgebung, Daten und Anleitungen vorbereiten
Die Liste der technischen Bereitschaft ist bekannt: Zugänge und SSO, Berechtigungen pro Rolle, Integrationen und (der Punkt, der mehr Rollouts versenkt als jeder andere) die Daten und gespeicherten Konfigurationen, auf die die Menschen angewiesen sind. Wenn die zwölf gespeicherten Filter, die Vorlagen oder drei Jahre Historie einer Person nicht mitkommen, lässt sie das alte Tool offen, egal was im Plan steht. Die fünf wichtigsten Artefakte pro Rolle zu migrieren ist mehr wert als eine Woche Schulung.
Bereiten Sie die Anleitung gleichzeitig vor, nicht danach, und entscheiden Sie, wo sie zu finden ist. Eine Präsentation und ein PDF sind eine vertretbare Basis, aber die einzige Anleitung mit einer ordentlichen Halbwertszeit ist die, die im Tool im Moment der Aufgabe erscheint: eine kurze Produkttour beim ersten Login, eine Checkliste der Aufgaben für den ersten Tag, die ihren Fortschritt selbst verfolgt, Tooltips an den vier Feldern, die alle falsch ausfüllen, und ein Hilfeweg in der App, damit Feststecken nie bedeutet, den Bildschirm verlassen zu müssen.
5. Den Pilot durchführen und die Skeptiker gewinnen
Ein Pilot, der ausschließlich mit Freiwilligen besetzt ist, zeigt Ihnen, wie der Rollout für Menschen aussieht, die ihn wollten. Das ist die am wenigsten nützliche Gruppe, die Sie befragen können. Nehmen Sie bewusst zwei oder drei Personen auf, die das Ganze für Zeitverschwendung halten; sie finden den Workflow, den das Tool schlecht abbildet, und davon erfahren Sie lieber von fünf Leuten in Woche zwei als von dreihundert in Woche sechs.
Führen Sie den Pilot anhand der echten Aufgabenliste für den ersten Tag durch, beobachten Sie, wo die Leute hängen bleiben, und korrigieren Sie die Anleitung vor Welle 2, statt es in ein Backlog zu schreiben. Das Ergebnis des Pilots ist kein Daumen hoch, sondern eine Liste konkreter Reparaturen (drei Tooltips, ein umformulierter Schritt, eine migrierte Vorlage, ein Workflow, den der Anbieter bestätigen muss) und Belege für das Gate.
6. Jede Welle hinter einem Gate starten
Jede Welle bekommt dasselbe Paket: eine kurze Nachricht von jemandem, an den die Gruppe tatsächlich berichtet (nicht vom Projektteam), die erklärt, was sich ändert und wann der alte Weg endet, Zugriff am Starttag, die auf diese Welle ausgerichtete In-App-Anleitung, ein benannter Champion vor Ort und ein sichtbarer Support-Weg. Dann beobachten Sie die Zahlen im Vergleich zu dem Gate, das Sie in Schritt 3 festgelegt haben.
Ein Gate zu halten, wenn die Zahlen schlecht sind, ist die schwierigste und wertvollste Disziplin in einem Rollout. Sie ist auch die günstigste: Welle 3 um eine Woche zu verschieben kostet eine Woche, Welle 3 in ein bekanntes, ungelöstes Problem laufen zu lassen kostet Sie die Glaubwürdigkeit, die Sie für jeden weiteren Rollout brauchen.
7. Die mittleren Wochen begleiten, in denen Rollouts tatsächlich sterben
Die Support-Kapazität wird fast immer rund um den Go-live-Tag geplant, und das ist der falsche Tag. Die Fragen, die zählen, kommen in den Wochen zwei bis sechs: der Monatsprozess, den niemand geprobt hat, der Quartalsabschluss, der Sonderfall beim Kunden, die Person, die während des gesamten Launchs im Urlaub war. Planen Sie die Besetzung dafür, und halten Sie die Champions auch nach dem Applaus aktiv.
Hier zahlt sich die In-App-Anleitung doppelt aus. Jede wiederkehrende Frage ist ein Tooltip oder ein Schritt, den Sie noch in derselben Woche ergänzen können (kein Release, keine Nachschulung), und jeder neue Mitarbeiter danach bekommt automatisch die korrigierte Version. Das ist der Mechanismus, der aus einem Rollout dauerhafte Digital Adoption macht statt eines Launchs, der wieder zerfällt.
8. Den alten Weg abschaffen und in den Regelbetrieb übergeben
Kündigen Sie das Abschaltdatum zu Beginn des Rollouts an, nicht am Ende, und setzen Sie es dann tatsächlich durch: erst schreibgeschützt, dann aus. Jede Woche, in der das alte Tool voll verfügbar bleibt, ist eine Woche, in der der Rollout optional ist, und optionale Rollouts pendeln sich auf dem Adoption-Niveau ein, das das am wenigsten überzeugte Team festlegt.
Übergeben Sie dann sauber: Jemand ist ab sofort für die In-App-Anleitung verantwortlich, die Aufgaben für den ersten Tag werden Teil des Mitarbeiter-Onboardings für neue Kollegen, und das Adoption-Dashboard hat einen benannten Leser mit einem festen monatlichen Termin. Ein Rollout ohne Verantwortlichen nach dem Go-live ist ein Rollout, der in achtzehn Monaten wiederholt werden muss.
Der Rollout-Zeitplan: was in jeder Phase passiert
Für den Rollout-Zeitplan wünschen sich die meisten eine Vorlage, und gerade hier führt eine Vorlage am stärksten in die Irre: Ein Tool für 40 Personen und ein ERP für 4.000 teilen sich keinen Kalender. Was sich übertragen lässt, ist die Form: eine Vorbereitungsphase, die länger dauert, als irgendjemand einplant, Wellen, deren Abstand sich nach dem Lernen richtet statt nach der Bequemlichkeit, und ein Support-Nachlauf, der den Launch überdauert.
Zwei Dinge an dieser Form werden regelmäßig unterschätzt. Das erste ist die Vorbereitung: Die Datenmigration und die Anleitungen dauern beide länger als das Deployment, und beide liegen auf dem kritischen Pfad dafür, ob Welle 1 gelingt. Das zweite ist das Support-Band; beachten Sie, dass es auf keinen Launch-Tag zentriert ist. Es überspannt die Mitte, weil dann die unangenehmen Fragen kommen.
Ein nützlicher Test für Ihren Rollout-Plan. Fragen Sie sich, was konkret passieren müsste, damit Sie Welle 3 um eine Woche verschieben. Gibt es darauf keine Antwort, sind die Wellen nicht durch Gates abgesichert; sie sind nur Termine, und der Rollout läuft im selben Tempo weiter, ob er funktioniert oder nicht.
Was Sie während und nach einem Software-Rollout messen sollten
Das Messproblem der meisten Rollouts ist nicht, dass nichts erfasst wird, sondern dass das Erfasste die Aktivität des Rollout-Teams misst statt des Verhaltens der Mitarbeiter. Zugewiesene Lizenzen, durchgeführte Schulungen, Teilnahme, versendete E-Mails: All das kann bei einem Rollout, der nichts verändert hat, 100 % erreichen. Vier Ebenen, in dieser Reihenfolge, beheben das.
| Ebene | Die Frage | Was Sie messen | Wann sie sich bewegen sollte |
|---|---|---|---|
| Reichweite | Sind sie überhaupt aufgetaucht? | % der Welle, die sich mindestens einmal angemeldet haben | Tage 1–5 der Welle |
| Aktivierung | Haben sie das Eigentliche erledigt? | % derjenigen, die die Aufgabe des ersten Tages erledigt haben: die Arbeit, nicht die Tour | Woche 1–2 der Welle |
| Tiefe | Nutzen sie das, worauf der Business Case beruht? | Wöchentliche Nutzung der zwei oder drei Workflows, die das Tool rechtfertigen | Wochen 2–6 |
| Dauerhaftigkeit | Hat die Gewohnheit gehalten? | Noch aktiv in Woche 4 und 8; Rückkehr zum alten Tool | Wochen 4–12 |
Daneben liefern zwei operative Signale die früheste Warnung vor Problemen. Die Zeit bis zur ersten erfolgreichen Aufgabe, also die Spanne zwischen erstem Login und dem ersten echten erledigten Arbeitsschritt, ist das interne Gegenstück zur Time to Value, und wenn sie sich verlängert, sackt alles Nachgelagerte mit ab. Und die Support-Tickets pro hundert Nutzer und Welle sollten von Welle zu Welle sinken; erzeugt Welle 3 dieselbe Ticketrate wie der Pilot, wurde nichts von dem, was Sie dazwischen gelernt haben, tatsächlich behoben.
Achten Sie auf die Verteilung, nicht nur auf den Durchschnitt. Ein Rollout mit 68 % Aktivierung ist entweder insgesamt gesund oder besteht aus zwei Abteilungen mit 95 % und einer mit 12 %, und das erfordert völlig unterschiedliche Reaktionen. Das Team mit 12 % hat meist einen konkreten Grund: einen Workflow, den das Tool schlecht abbildet, eine Führungskraft, die nie überzeugt war, oder eine Migration, bei der etwas Wichtiges verloren ging. Durchschnitte verbergen genau das, was Sie beheben können.
Software-Rollout: Do's und Don'ts
✓ Do
- Den Nutzen in den Worten der Person formulieren, die die Arbeit macht, und benennen, was zuerst schlechter wird
- Die Aufgabenliste für den ersten Tag auf drei Punkte pro Rolle kürzen
- Die Skeptiker bewusst in den Pilot holen
- Das Gate jeder Welle in Zahlen festlegen, bevor die Welle startet
- Die gespeicherten Filter, Vorlagen und die Historie migrieren, auf die sich die Leute wirklich verlassen
- Anleitungen im Tool bereitstellen, im Moment der Aufgabe
- Den Support für die Wochen 2–8 besetzen, nicht für den Launch-Tag
- Das Abschaltdatum des alten Systems zu Beginn ankündigen und durchsetzen
- Anleitungen und Adoption-Dashboard nach dem Go-live einem benannten Verantwortlichen übergeben
✗ Don't
- Zugewiesene Lizenzen als Adoption-Kennzahl berichten
- Die Schulung drei Wochen bevor jemand das Tool nutzen kann durchführen
- Welle 3 schon während Welle 1 Zugriff geben; das ist ein Big Bang mit zusätzlichen E-Mails
- Den Pilot ausschließlich mit Freiwilligen und Begeisterten besetzen
- Das Gate als Formalie behandeln, sobald der Termin im Kalender steht
- Das alte Tool „sicherheitshalber“ unbegrenzt voll verfügbar lassen
- Einen generischen Walkthrough an jede Rolle ausspielen
- Den Rollout am unternehmensweiten Durchschnitt messen und die Abteilung mit 12 % übersehen
- Den Plan beim Go-live enden lassen
Einen Software-Rollout ohne Entwicklungsaufwand umsetzen
Der schwierigste Posten in einem Rollout-Plan ist meist die Anleitung, weil alle naheliegenden Wege, sie zu erstellen, schlecht sind. Dokumentation, die niemand liest, ist billig und nutzlos. Live-Schulungen sind teuer, verblassen innerhalb weniger Tage und müssen für jeden neuen Mitarbeiter wiederholt werden. Und Hilfe in die Software selbst einzubauen, steht Ihnen selten überhaupt offen: Ist es das Produkt eines Anbieters, können Sie es nicht ändern, und ist es intern, konkurrieren Sie mit der Roadmap um Entwicklerzeit.
Kompassify wurde genau für diese Lücke gebaut: Es legt Anleitungen über Software, die Sie bereits betreiben, ohne deren Code anzufassen.
- Anleitungen in jeder Web-App, ohne Release-Zyklus. Fügen Sie Produkttouren, Tooltips und Hotspots zu dem Tool hinzu, das Ihre Mitarbeiter nutzen, erstellt in einem visuellen Editor direkt auf Ihrer Live-Anwendung. Kein Entwickler, kein Deployment-Fenster.
- Aufgaben für den ersten Tag als selbst mitzählende Checkliste. Eine Onboarding-Checkliste macht aus Ihren drei Aufgaben für den ersten Tag sichtbaren Fortschritt, der pro Person gespeichert bleibt: Wer mitten in der Einrichtung unterbrochen wird, macht dort weiter, wo er aufgehört hat, und nicht wieder am Anfang.
- Targeting, das zu Ihren Wellen passt. Zeigen Sie jeder Welle, Abteilung oder Rolle nur die Anleitung, die für sie gedacht ist, und schalten Sie eine Welle frei, indem Sie die Zielgruppe ändern, statt eine Schulung zu wiederholen.
- Ankündigungen für die Meilensteine. Wellentermine, neue Workflows und die Abschaltung des alten Systems lassen sich direkt im Tool ankündigen, wo die Menschen ohnehin sind, statt in einem E-Mail-Verlauf, den sie stummgeschaltet haben.
- Analysen pro Schritt. Das integrierte Reporting zeigt Abschluss- und Abbruchraten für jeden Schritt jedes Flows, sodass die Anleitung für Welle 2 eine reparierte Version der von Welle 1 ist und kein hoffnungsvoller Neuentwurf.
- Anleitungen, die nach dem Rollout weiter funktionieren. Die neue Kollegin, die im sechsten Monat dazukommt, erlebt denselben angeleiteten ersten Tag wie Welle 1, ohne dass jemand etwas planen muss.
Kompassify ist DSGVO-konform und in der EU gehostet, kostenlos für unter 100 monatlich aktive Nutzer, kostenpflichtige Pläne gibt es ab $129/Monat. So können Sie eine Pilotwelle komplett durchführen, bevor der Rollout überhaupt ein eigenes Budget hat.
Machen Sie das neue Tool zur einfachen Wahl
Kompassify ergänzt die Software, die Ihre Teams bereits nutzen, um Produkttouren, Checklisten, Tooltips und Ankündigungen: ohne Code, ohne Release-Zyklus, gezielt Welle für Welle ausgespielt und Schritt für Schritt gemessen. Geben Sie jedem Mitarbeiter einen angeleiteten ersten Tag, auch denen, die sechs Monate nach dem Go-live dazukommen. DSGVO-konform, in der EU gehostet und kostenlos für unter 100 monatlich aktive Nutzer.
Kostenlos starten →Häufig gestellte Fragen
Was ist ein Software-Rollout?
Ein Software-Rollout ist der geplante Prozess, ein neues Tool in die Hände der Menschen zu geben, die es nutzen sollen, und dafür zu sorgen, dass sie es tatsächlich in ihrer täglichen Arbeit verwenden. Er geht über das Deployment hinaus: Das Deployment ist ein technisches Ereignis, das endet, sobald die Software installiert und erreichbar ist, während ein Rollout erst endet, wenn die vorgesehenen Nutzer die vorgesehene Arbeit ohne Hilfe im neuen Tool erledigen. Ein Rollout-Plan umfasst deshalb Zielgruppen und Reihenfolge, die Migration von Daten und Workflows, die Anleitung und Schulung der Mitarbeiter, den Support-Weg, wenn jemand nicht weiterkommt, die beobachteten Adoption-Kennzahlen und das Datum, an dem das alte Tool abgeschaltet wird.
Was gehört in einen Software-Rollout-Plan?
Ein brauchbarer Software-Rollout-Plan beantwortet schriftlich acht Fragen: Welchem Ergebnis dient der Rollout (in der Sprache des Geschäfts, nicht des Tools), wer ist betroffen und in welcher Reihenfolge, was muss jede Gruppe am ersten Tag können, wie lernt sie es, wen fragt sie, wenn etwas nicht funktioniert, was wird mit welchen Schwellenwerten gemessen, was passiert, wenn eine Welle ihr Gate nicht besteht, und wann wird der alte Weg abgeschafft. Alles andere (Zeitpläne des Anbieters, Lizenzzahlen, Integrationsdiagramme) ist Begleitmaterial. Fehlen diese acht Antworten, ist der Plan ein Deployment-Zeitplan, der sich nur Rollout-Plan nennt.
Was ist der Unterschied zwischen einem Big-Bang- und einem phasenweisen Rollout?
Bei einem Big-Bang-Rollout wechseln alle am selben Tag auf die neue Software; bei einem phasenweisen Rollout wechseln die Mitarbeiter in Wellen: zuerst eine Pilotgruppe, dann schrittweise größere Gruppen, jeweils hinter einer Go/No-Go-Entscheidung. Big Bang ist schneller, vermeidet den Parallelbetrieb zweier Systeme und ist die ehrliche Wahl, wenn das Tool wirklich nur ganz oder gar nicht funktioniert (eine Umstellung der Lohnabrechnung, ein System mit einem einzigen gemeinsamen Datenbestand). Der Preis: Jedes Problem tritt gleichzeitig auf, in voller Größenordnung und ohne Generalprobe. Ein phasenweiser Rollout dauert länger und erfordert eine Phase des Parallelbetriebs, aber jede Welle lehrt Sie etwas, das Sie vor der nächsten beheben können, und die Support-Last bleibt in dem Rahmen, den Ihr Helpdesk bewältigen kann. Solange keine harte Abhängigkeit einen einzigen Umstellungstermin erzwingt, ist der phasenweise Rollout die risikoärmere Standardwahl.
Wie führt man neue Software bei Mitarbeitern ein?
Definieren Sie das gewünschte Ergebnis in geschäftlichen Begriffen, erfassen Sie, wer betroffen ist und was jede Gruppe können muss, wählen Sie eine Rollout-Strategie (meist phasenweise), stellen Sie eine Pilotgruppe zusammen, zu der neben den Begeisterten auch die Skeptiker gehören, bereiten Sie die Umgebung vor und migrieren Sie die Daten und Workflows, auf die die Mitarbeiter angewiesen sind, verankern Sie die Anleitung im Tool selbst statt nur in einer Präsentation oder einem PDF, führen Sie jede Welle hinter einem Go/No-Go-Gate mit echten Adoption-Kennzahlen ein und schaffen Sie erst dann den alten Weg ab. Der wichtigste Erfolgsfaktor ist der Ort, an dem die Hilfe zu finden ist: Was in einer Schulung gelernt wird, verblasst innerhalb weniger Tage, während eine Anleitung, die im Tool genau im Moment der Aufgabe erscheint, für jeden neuen Mitarbeiter weiter funktioniert.
Warum scheitern Software-Rollouts?
Fast nie, weil die Software nicht funktioniert. Rollouts scheitern, weil die Mitarbeiter nie einen Grund für die Umstellung bekommen haben, der aus ihrer Sicht Sinn ergibt, weil die Schulung Wochen vor dem tatsächlichen Bedarf stattfand, weil das neue Tool die eine Sache noch nicht konnte, die ihr alter Workaround gut erledigte, weil Hilfe zu holen langsamer war als zum alten Weg zurückzukehren, oder weil niemand etwas anderes gemessen hat als zugewiesene Lizenzen. Das Scheitern verläuft leise: Die Software bleibt installiert, die Lizenzen werden weiter bezahlt, und die Arbeit läuft still in Tabellen und E-Mails weiter. Deshalb brauchen Rollout-Pläne Adoption-Kennzahlen und ein ausdrückliches Abschaltdatum für den alten Weg, nicht nur einen Go-live-Termin.
Welche Kennzahlen sollten Sie während eines Software-Rollouts verfolgen?
Verfolgen Sie vier Ebenen, in dieser Reihenfolge. Reichweite: wie viele der vorgesehenen Nutzer sich überhaupt angemeldet haben. Aktivierung: wie viele die erste echte Aufgabe erledigt haben, für die es den Rollout gibt, keine Tour, sondern die eigentliche Arbeit. Tiefe: wie viele die zwei oder drei Workflows, auf denen der Business Case beruht, wöchentlich nutzen. Dauerhaftigkeit: wie viele das vier und acht Wochen später noch tun und wie viele still zum alten Tool zurückgekehrt sind. Die Support-Last pro Welle und die Zeit bis zur ersten erfolgreichen Aufgabe gehören als Frühwarnsignale dazu. Zugewiesene Lizenzen und Schulungsteilnahme sind keine Adoption-Kennzahlen; sie messen Ihren Aufwand, nicht das Verhalten der Mitarbeiter.
Wie lange sollte ein Software-Rollout dauern?
Lang genug, um zwischen den Wellen zu lernen, und kurz genug, damit die Veränderung nicht an Schwung verliert. Für ein Abteilungstool ist ein gängiges Muster ein bis zwei Wochen Pilotphase, danach zwei bis vier Wellen im Abstand von etwa zwei Wochen, und das alte System wird vier bis acht Wochen nach der letzten Welle abgeschaltet. Der Abstand ist wichtiger als die Gesamtdauer: Jede Pause muss lang genug sein, damit die Probleme einer Welle sichtbar werden (die meisten Support-Tickets kommen einige Tage nach dem Go-live, nicht am Tag selbst) und Sie die Anleitung korrigieren können, bevor die nächste Gruppe gegen dieselbe Wand läuft. Rollouts, die länger als ein Quartal dauern, geraten oft ins Stocken, weil der Parallelbetrieb zur neuen Normalität wird und sich niemand mehr verpflichtet fühlt umzusteigen.
Wie schulen Sie Mitarbeiter in neuer Software, ohne etwas zu entwickeln?
Verlagern Sie die Schulung in das Tool, statt sie daneben zu stellen. Mit einer No-Code-Digital-Adoption-Plattform wie Kompassify fügen Sie Produkttouren, Tooltips, Checklisten und Ankündigungen zu der Software hinzu, die Ihre Mitarbeiter bereits nutzen, erstellt in einem visuellen Editor direkt auf Ihrer Live-Anwendung, gezielt ausgespielt an die Welle oder Abteilung, die gerade umgestellt wird, und veröffentlicht ohne Release-Zyklus und ohne Entwickler. Neue Mitarbeiter erhalten Monate später dieselbe Anleitung, ohne dass jemand eine Schulung wiederholen muss, und integrierte Analysen zeigen genau, an welchem Schritt Nutzer abbrechen. Kompassify ist DSGVO-konform und in der EU gehostet, kostenlos für unter 100 monatlich aktive Nutzer, kostenpflichtige Pläne gibt es ab $129/Monat.