Der Login klappt. Die Benutzer sind importiert. Kurse lassen sich zuweisen, E-Mails gehen raus, die Schnittstelle liefert Daten. Technisch kann ein LMS an diesem Punkt ziemlich fertig aussehen.
Und trotzdem beginnt jetzt oft der schwierigere Teil: Menschen müssen ihre Arbeit mit dem neuen System erledigen.
Das ist mehr als Bedienung. Administratoren bauen Zuweisungen und Regeln. Fachbereiche liefern Inhalte oder Zielgruppen. Führungskräfte reagieren auf Status und Überfälligkeiten. Beschäftigte müssen verstehen, was von ihnen erwartet wird. Wenn diese Arbeitsabläufe nicht funktionieren, hilft ein grüner technischer Abnahmetest nur begrenzt.
Die Forschung zu Enterprise-Systemen kennt diese Trennung seit Langem. Sie unterscheidet Probleme der technischen Konfiguration von Problemen der organisatorischen Assimilation. Für LMS-Projekte ist genau diese Unterscheidung nützlich: Ein funktionierendes System ist eine Voraussetzung. Es ist noch kein Beleg für eine funktionierende Einführung.
- Technische Konfiguration und organisatorische Assimilation sind unterschiedliche Implementierungsprobleme.
- Feature-Schulung und das How-to des eigenen Arbeitsprozesses sind nicht dasselbe Lernziel.
- Ein LMS hat mehrere Rollen; belastbare Tests sollten reale Rollenszenarien statt nur Funktionen prüfen.
- Training wirkt nicht allein: Unterstützung und Lernmöglichkeiten im tatsächlichen Nutzungskontext bleiben nach dem Go-live wichtig.
Der Go-live ist nur ein technischer Zustand
Bei einer Softwareeinführung lässt sich technische Bereitschaft vergleichsweise sauber prüfen. Sind Benutzer angelegt? Funktioniert Single Sign-on? Werden Daten übertragen? Läuft der Kurs? Kommt eine Benachrichtigung an?
Organisatorische Bereitschaft ist sperriger. Sie zeigt sich erst, wenn reale Fälle auftreten. Ein neuer Mitarbeiter beginnt. Eine Person wechselt die Rolle. Eine Schulung wird überfällig. Eine Führungskraft braucht einen Status. Ein Administrator muss eine falsche Zuordnung korrigieren.
Daniel Robey, Jeanne Ross und Marie-Claude Boudreau haben bei der Einführung von ERP-Systemen in 13 Industrieunternehmen zwei unterschiedliche Wissensbarrieren beschrieben: Wissen über die Konfiguration des Systems und Wissen darüber, wie neue Arbeitsprozesse tatsächlich aufgenommen werden. Gerade die zweite Barriere blieb in den untersuchten Unternehmen ein laufendes Thema.
Das lässt sich nicht eins zu eins auf jedes LMS übertragen. ERP und Lernmanagement sind unterschiedliche Systeme. Der Mechanismus ist trotzdem relevant: Software verändert nicht nur Oberflächen. Sie verändert Zuständigkeiten, Reihenfolgen und Entscheidungen.
Zwei Arten von Implementierungswissen
Eine typische Produktschulung beantwortet Fragen wie: Wo lege ich einen Kurs an? Wie weise ich eine Gruppe zu? Wo finde ich einen Bericht?
Das ist wichtig. Es beantwortet aber noch nicht die Prozessfrage: Wer entscheidet, welche Gruppe welche Schulung erhält? Was passiert bei einem Rollenwechsel? Wer bearbeitet Ausnahmen? Ab wann wird eine Überfälligkeit eskaliert? Welcher Status gilt im Audit oder im Monatsreport?
Funktionen finden, Einstellungen verstehen, Aktionen korrekt ausführen.
Auslöser, Zuständigkeiten, Ausnahmen und Entscheidungen im eigenen Arbeitsablauf zuverlässig abbilden.
Robey und Kollegen beobachteten, dass Schulungen hilfreicher für die Assimilation waren, wenn sie technische Nutzung und Geschäftsprozesse zusammenbrachten. Eine Untersuchung von Technologieeinführungen in zwölf englischen NHS-Organisationen kommt aus einer anderen Richtung zu einem ähnlichen Punkt. Dort unterschieden die Forscher zwischen Wissen darüber, dass eine Innovation existiert, Wissen über ihre Prinzipien und praktischem „How-to“-Wissen. Wurde diesem How-to-Wissen früh zu wenig Aufmerksamkeit gegeben, trug das in zwölf der untersuchten Fälle zu unvollständiger Implementierung oder Abbruch nach der Einführung bei.
Für ein LMS heißt das: „So funktioniert die Funktion“ und „So funktioniert unser Prozess mit dieser Funktion“ sind zwei verschiedene Lernziele.
Ein LMS hat mehrere Arbeitsrollen
Hinzu kommt ein Problem, das in Projektplänen leicht verschwindet: Es gibt nicht den einen LMS-Nutzer.
Ein Lerner braucht meist wenige, klare Abläufe. Ein Administrator arbeitet dagegen mit Zielgruppen, Regeln, Inhalten, Berichten und Ausnahmen. Führungskräfte brauchen womöglich nur bestimmte Statusinformationen. HR oder Compliance interessieren sich für andere Nachweise als ein Content-Verantwortlicher.
Eine einzige Einführungsschulung kann diese Unterschiede kaum sinnvoll abbilden. Nicht weil sie zu kurz wäre, sondern weil die Jobs verschieden sind.
Die bessere Frage lautet deshalb nicht: „Sind alle geschult?“ Sie lautet: „Kann jede relevante Rolle ihre kritischen Fälle im neuen Prozess erledigen?“
Das verändert auch den Test vor dem Rollout. Statt nur Funktionen abzuhaken, lassen sich echte Szenarien durchspielen: Eintritt, Rollenwechsel, Fristüberschreitung, Ausnahme, Reporting, Korrektur. Dabei werden nicht nur Softwarefehler sichtbar. Man entdeckt auch unklare Zuständigkeiten und Prozesslücken.
Unterstützung muss dort auftauchen, wo Arbeit passiert
Selbst eine gute Einführungsschulung löst nicht jedes Problem vorab. Vieles wird erst verständlich, wenn jemand den Vorgang zum ersten Mal wirklich erledigen muss.
Eine longitudinale Untersuchung mit 94 Beschäftigten während der Einführung eines unternehmensweiten Systems zeigte, dass Training mit der Nutzungsabsicht auch über die wahrgenommenen Unterstützungsressourcen zusammenhing. Vereinfacht: Es zählt nicht nur, was jemand in der Schulung gesehen hat. Es zählt auch, ob die Person erwartet, bei der tatsächlichen Nutzung handlungsfähig und unterstützt zu sein.
Aktuellere Forschung zu Digital-Adoption-Plattformen untersucht genau diesen Punkt. In einem Experiment mit 152 Beschäftigten führte interaktive Unterstützung bei einem neuen Unternehmenssystem zu höher wahrgenommener Nützlichkeit und höherer Nutzungsabsicht als ein klassisches Benutzerhandbuch.
Das beweist nicht, dass jedes Unternehmen eine Digital-Adoption-Plattform braucht. Gemessen wurden unter anderem Wahrnehmung und Nutzungsabsicht, nicht der langfristige Erfolg realer LMS-Projekte. Der Befund stützt aber eine praktische Idee: Hilfe ist besonders wertvoll, wenn sie nah an der konkreten Aufgabe verfügbar ist.
Das kann technisch aufwendig sein. Oft reicht zunächst weniger: kurze rollenbezogene Anleitungen, ein klarer Supportweg, benannte Ansprechpartner und eine Sammlung der Fälle, die nach dem Go-live tatsächlich Probleme verursachen.
Was ein belastbarer Rollout vor dem Go-live prüft
Aus den Studien lässt sich kein universelles Fünf-Punkte-Rezept für LMS-Projekte ableiten. Dafür sind Systeme, Organisationen und Einsatzfälle zu unterschiedlich. Es lassen sich aber fünf getrennte Fragen stellen, die unterschiedliche Risiken sichtbar machen.
Authentifizierung, Daten, Inhalte, Benachrichtigungen und relevante Integrationen müssen zuverlässig laufen.
Ein realer Vorgang sollte vom Auslöser bis zum Ergebnis durchgespielt werden, einschließlich einer typischen Ausnahme.
Für kritische Schritte muss feststehen, wer entscheidet, ausführt und bei Problemen reagiert.
Administratoren, Lerner und Führungskräfte brauchen unterschiedliche Praxis.
Probleme müssen gesammelt, priorisiert und in Prozess, Konfiguration oder Unterstützung zurückgeführt werden.
Diese Fragen ersetzen keinen technischen Abnahmekatalog. Sie ergänzen ihn um die Ebene, die ein technischer Test kaum erfassen kann.
Software kann trotzdem das Problem sein
Bei all dem wäre es bequem, jedes misslungene Projekt zum Change-Management-Problem zu erklären. Das wäre falsch.
Wenn zentrale Funktionen fehlen, Schnittstellen instabil sind oder das System den erforderlichen Prozess nicht abbilden kann, hilft auch die beste Schulung nicht. Menschen können keinen schlechten Systemfit wegtrainieren.
Deshalb gehört die Reihenfolge dazu: Erst muss die Software für den vorgesehenen Zweck technisch und funktional geeignet sein. Dann muss die Organisation lernen, mit ihr zuverlässig zu arbeiten. Beides kann scheitern. Und beides braucht andere Gegenmaßnahmen.
Gerade deshalb ist die Diagnose wichtig. Wer ein Prozessproblem mit einer neuen Funktion lösen will, kauft womöglich Komplexität. Wer einen Produktmangel mit mehr Training beantworten will, verlagert das Problem auf die Nutzer.
Erfolg beginnt nach dem technischen Test
Ein LMS ist erfolgreich eingeführt, wenn es nicht nur erreichbar ist, sondern die vorgesehenen Lern- und Verwaltungsprozesse im Alltag trägt.
Dafür müssen Menschen mehr lernen als Klickwege. Sie brauchen Klarheit darüber, wie ihr eigener Arbeitsprozess mit dem System funktioniert, welche Verantwortung sie haben und wo sie Unterstützung bekommen. Das lässt sich vor dem Go-live teilweise testen. Der Rest zeigt sich erst in echten Fällen.
Der technische Go-live bleibt ein wichtiger Meilenstein. Nur sollte man ihn nicht mit dem Ende der Einführung verwechseln.
Quellen
- Robey, Ross & Boudreau: Learning to Implement Enterprise Systems.
- Marler, Liang & Dulebohn: Training and Effective Employee Information Technology Use.
- Technology adoption and implementation in organisations: comparative case studies of 12 English NHS Trusts.
- Digital Employee Training With Digital Adoption Platforms.