Das Wichtigste in Kürze
- Unzufriedenheit mit dem LMS zuerst an gescheiterten Prozessen und ihren Ursachen prüfen.
- Zwischen behebbarer Konfiguration, Daten-/Prozessfehlern und strukturellen Produktgrenzen unterscheiden.
- Behalten, Ergänzen und Ablösen mit gleichem Zeithorizont sowie klaren Test- und Abbruchkriterien vergleichen.
- Portabilität von Kursinhalten nicht mit der Übertragbarkeit historischer Nachweise verwechseln.
Das Lernmanagementsystem nervt. Führungskräfte fordern bessere Berichte, Administratoren pflegen Excel-Listen nebenher und die Belegschaft klickt sich durch ein Menü, das niemand freiwillig gebaut hätte. Beim nächsten Budgetgespräch fällt der Satz: „Wir brauchen ein neues LMS.“
Vielleicht stimmt das. Vielleicht wird aber gerade ein Problem mit Prozessen, Daten oder Zuständigkeiten zum Softwareproblem erklärt. Dann kann eine neue Plattform teuer werden, ohne die Ursache zu beseitigen. Umgekehrt bindet ein System, das zentrale Anforderungen dauerhaft nicht erfüllt, Jahr für Jahr Geld und Arbeitszeit. Ein weiterer Workaround ist dann auch keine Lösung.
Vor einer Ausschreibung steht deshalb eine andere Entscheidung: Ist das bestehende LMS verbesserbar, oder ist die Grenze der Plattform tatsächlich erreicht? Wer diese Frage sauber beantwortet, spart nicht zwangsläufig einen Wechsel. Er kann ihn aber fachlich begründen und anschließend gezielter durchführen.
Unzufriedenheit ist ein Signal, noch keine Diagnose
„Das Reporting funktioniert nicht“ kann mindestens vier verschiedene Dinge bedeuten. Vielleicht fehlen dem System notwendige Filter. Vielleicht wurden Organisationsdaten falsch importiert. Vielleicht nutzen Fachbereiche unterschiedliche Definitionen von „abgeschlossen“. Oder der Bericht existiert bereits, wurde aber nie so eingerichtet, dass die Führungskräfte ihn verwenden können.
Nur der erste Befund deutet unmittelbar auf eine Produktgrenze. Bei den anderen könnte dieselbe Software nach einer Datenbereinigung, einer Prozessentscheidung oder einer besseren Konfiguration erheblich mehr leisten. Die Unterscheidung ist banal genug, um im Alltag regelmäßig übersprungen zu werden.
Eine tragfähige Bestandsaufnahme beginnt daher nicht mit einer Liste gewünschter Funktionen. Sie beginnt mit misslungenen Arbeitsvorgängen: Welche Rolle will was erledigen, wie sollte der Vorgang laufen, was passiert tatsächlich und welche Folge hat die Abweichung? Erst dann lässt sich prüfen, ob das Problem technisch, organisatorisch oder gemischt ist.
Diese Sicht passt zum Gedanken der ISO/IEC 25010:2023: Softwarequalität ist mehrdimensional und lässt sich anhand definierter Eigenschaften beurteilen. Die Norm ist kein fertiger LMS-Fragebogen. Sie bietet jedoch einen besseren Ausgangspunkt als die pauschale Bewertung „alt“ oder „modern“.
Der entscheidende Test: Ist die Lücke behebbar?
Ein Praxisfall: Ein Unternehmen verwaltet Pflichttrainings für Beschäftigte an mehreren Standorten. Nach einem Rollenwechsel bekommen manche Personen noch alte Zuweisungen, andere neue Schulungen erst verspätet. Die Fachabteilung will das LMS austauschen.
Bevor sie Anbieter einlädt, muss sie den Weg der Daten verfolgen. Ist das HR-System für Stellen und Organisationseinheiten führend? Wer entscheidet über Trainingspflichten? Wann werden Änderungen übertragen? Und was macht das LMS mit vorhandenen Zuweisungen und historischen Nachweisen?
Wenn eine falsche Gruppenzuordnung die Ursache ist, kann ein neuer Anbieter dieselben fehlerhaften Stammdaten erhalten. Falls das aktuelle LMS die benötigte Änderungslogik trotz sauberer Daten nicht unterstützt und auch keine wirtschaftlich vertretbare Erweiterung zulässt, sieht die Lage anders aus. Dann ist eine strukturelle Grenze belegt.
Für jede relevante Lücke sollte ein kleines Dossier vorliegen: reproduzierbarer Fehler oder fehlender Ablauf, betroffene Nutzer, Häufigkeit, Auswirkung, bisherige Versuche, mögliche Abhilfe und der Nachweis, warum diese ausreicht oder eben nicht. Besonders kritisch sind Sicherheits- und Datenschutzdefizite, fehlende belastbare Nachweise sowie fachlich unverzichtbare Prozesse. Ein hässliches Dashboard hat eine andere Dringlichkeit.
Behalten oder ersetzen ist kein Vergleich von zwei Preisschildern
Die Entscheidung ist asymmetrisch. Beim Behalten bleiben viele bekannte Aufwände sichtbar: Lizenz, Administration, Support, individuelle Anpassungen. Beim Wechsel ist der künftige Betrieb zunächst eine Schätzung. Die einmalige Migration kommt hinzu, ebenso die Zeit von IT, Fachbereichen, Testern und Nutzern.
Ein Vergleich sollte denselben Betrachtungszeitraum nutzen und in beiden Fällen alle wesentlichen Kosten abbilden. Darum geht es ausführlich im Praxiswissen-Beitrag zu den tatsächlichen LMS-Gesamtkosten. Für die Ablöseentscheidung ist zusätzlich wichtig, welchen Schaden das Nichtstun verursacht: wiederkehrende manuelle Arbeit, unzuverlässige Daten, verspätete Qualifizierung oder Risiken, die nicht mehr angemessen kontrolliert werden können.
Die Kosten des Wechsels lassen sich vorab ebenfalls nicht einfach aus einer Anbieterpräsentation ablesen. In einem älteren EDUCAUSE-Erfahrungsbericht zum Wechsel von Course-Management-Systemen wurden erhebliche Nacharbeiten an übertragenen Kursen beschrieben. Das war ein konkreter Hochschulfall und ist keine heutige durchschnittliche Migrationsquote. Er erinnert aber an eine weiterhin gültige Unterscheidung: Erfolgreicher Datentransport ist nicht gleich fachlich korrekte Übernahme.
Ebenso wenig darf ein vorhandener Integrationsstandard mit vollständiger Portabilität verwechselt werden. 1EdTech beschreibt Common Cartridge für den Austausch bestimmter Lernmaterialien und Assessments. Daraus folgt gerade nicht, dass Berechtigungen, Lernhistorien, Zuweisungsregeln und alle individuellen Workflows einer Organisation automatisch zwischen zwei LMS mitwandern.
Was verbessert werden kann – und was einen Wechsel rechtfertigt
Eine Gegenüberstellung hilft, solange sie nicht zu einer simplen Punktetabelle verkommt. Dieselbe Schwäche kann je nach betroffener Rolle und Risiko unterschiedliche Konsequenzen haben.
Was die Ursachenprüfung nahelegt
Eher optimieren
- Die geforderten Prozesse sind im System grundsätzlich abbildbar.
- Fehler entstehen überwiegend durch Datenqualität, Konfiguration oder ungeklärte Verantwortlichkeiten.
- Ein überprüfbarer Verbesserungsplan hat einen klaren Owner, Aufwand und Termin.
- Support und Weiterentwicklung sind verlässlich genug für die nächsten Jahre.
Eher ablösen
- Ein kritischer Prozess lässt sich im Standard und mit vertretbarer Anpassung nicht zuverlässig erfüllen.
- Wesentliche Sicherheits-, Nachweis- oder Integrationsanforderungen bleiben offen.
- Der Anbieter kann notwendige Änderungen nicht verbindlich und wirtschaftlich tragfähig lösen.
- Die fortgesetzte Nutzung verursacht eine belegte, wiederkehrende Belastung oder ein nicht akzeptables Risiko.
Das sind Diagnosehinweise, keine automatischen Kaufregeln. Manchmal reicht ein Prozessumbau. Manchmal kann ein ergänzendes Werkzeug ein eng umrissenes Problem günstiger lösen als ein Plattformwechsel. Diese Erweiterung muss allerdings selbst betrieben, abgesichert und integriert werden. Mit jeder neuen Insellösung wächst die Frage, welches System künftig welche Daten und Aufgaben besitzt.
Den Verbesserungsversuch begrenzen, statt ewig weiterzubasteln
Wer sein LMS behalten möchte, braucht einen Test, der scheitern darf. Sonst wird „Wir optimieren erst einmal“ zur Dauerformel, während die eigentlichen Probleme bestehen bleiben.
Ein sinnvoller Test betrifft wenige priorisierte Vorgänge. Beispiel: Für den Rollenwechsel sollen neue Trainingspflichten spätestens mit dem vereinbarten Datenlauf entstehen; entfallene Zuweisungen müssen korrekt behandelt werden; bestehende Abschlüsse dürfen ihre Bedeutung nicht verlieren. Das Team definiert die erwarteten Ergebnisse, führt Testfälle mit realitätsnahen Daten aus und dokumentiert Abweichungen.
Die Bedingungen gehören vor Beginn auf den Tisch: Wer liefert Stammdaten? Welche Änderungen kann der Anbieter tatsächlich umsetzen? Welche Nacharbeiten sind im vereinbarten Aufwand enthalten? Woran erkennen Fachbereich und IT gemeinsam den Erfolg? Ein Verbesserungsversuch ohne Abbruchkriterium produziert häufig nur neue Schleifen.
Die Grenze lässt sich pragmatisch ziehen: Scheitern wiederholt genau jene Vorgänge, wegen derer das System überhaupt gebraucht wird, und existiert keine glaubhafte Abhilfe, ist die Ablöseentscheidung belastbarer. Sind die Vorgänge nach überschaubarem Aufwand stabil, wäre ein kompletter Plattformwechsel schwerer zu begründen.
Eine Ablösung muss vor dem Einkauf rückwärts gedacht werden
Wenn ein neues System notwendig erscheint, lohnt sich ein unangenehmer Test: Können wir heute erklären, wie die bisherige Lernhistorie später noch belegt werden soll? Nicht jede Datei muss migriert werden. Manche Daten müssen im neuen LMS weiterverwendet werden, andere können revisionsgerecht im Altsystem oder in einem geeigneten Archiv verbleiben. Entscheidend ist, dass die fachliche Aussage erhalten bleibt.
Dieser Punkt ist eine eigene Disziplin. Der Beitrag zur LMS-Migration und Lernhistorie beschreibt die Unterscheidung zwischen Übernehmen, Transformieren, Archivieren und Neuaufbauen. Für die Entscheidung vor der Ausschreibung reicht zunächst ein belastbares Dateninventar: Welche Nachweise gibt es, welche werden benötigt, wem gehören sie, welche Exportwege funktionieren und was bleibt nach Vertragsende verfügbar?
Auch die zukünftige Systemlandschaft gehört auf den Prüfstand. Ein neues LMS ersetzt möglicherweise keine HR-Datenhoheit, kein Identity Management und keinen Prozess für fachliche Schulungspflichten. Wird all das im Beschaffungstext nicht sauber getrennt, wirkt eine Demo beeindruckend, während der spätere Betrieb wieder von Sonderregeln abhängt.
Die EDUCAUSE-Fachliteratur zur LMS-Auswahl plädiert schon seit Jahren dafür, unterschiedliche Nutzergruppen und IT gemeinsam einzubeziehen. Ihr Untersuchungsfeld sind Bildungseinrichtungen, nicht der deutsche Unternehmensmarkt. Der Grundgedanke bleibt plausibel: Ein System muss für diejenigen funktionieren, die lernen, Inhalte verantworten, administrieren und die Daten später prüfen.
Der stärkste Einwand gegen den Wechsel: Die neue Software wird nicht automatisch besser genutzt
Ein Austausch kann technische Grenzen beseitigen. Er beseitigt nicht automatisch unklare Rollen, schlechte Inhalte, mangelnde Lernzeit oder fehlende Prozessverantwortung. Wer die alte Plattform wegen geringer Nutzung ersetzen will, muss deshalb zeigen, welcher Teil der geringen Nutzung tatsächlich durch die Software verursacht wird.
Manchmal ist der ernsthafte Gegenentwurf zum Wechsel eine organisatorische Reparatur: eindeutige Zuständigkeiten, reduzierte Pflichtkataloge, saubere Daten, ein verständlicher Zugang und Unterstützung für Führungskräfte. Dafür spricht auch die Erfahrung aus LMS-Einführungen: Akzeptanz und Arbeitsprozesse sind eigenständige Erfolgsbedingungen.
Das Gegenargument hat allerdings eine Grenze. Wenn Administration und Nutzer trotz sinnvoller Abläufe an zentralen Produktbeschränkungen scheitern, kann gutes Change Management fehlende Fähigkeiten nicht herbeizaubern. Die Organisation muss nicht unbegrenzt um eine Plattform herumarbeiten, nur weil sie bereits investiert hat.
So wird aus einer Unzufriedenheit eine Entscheidungsvorlage
Ein knapper Entscheidungsvermerk muss kein Mammutprojekt sein. Er sollte die gravierendsten gescheiterten Prozesse mit ihren Auswirkungen nennen, die Ursachenprüfung dokumentieren und die verbleibenden Optionen vergleichbar machen. Dazu gehören „behalten und optimieren“, „gezielt ergänzen“ und „ablösen“ – jeweils mit Nutzen, Risiken, zeitlichem Horizont, internem Aufwand und Abhängigkeiten.
Für einen geplanten Wechsel sollte das Team außerdem die Mindestbedingungen vor einer Vertragsunterschrift festhalten: nachgewiesene End-to-End-Prozesse, belastbare Export- und Migrationsmöglichkeiten, klare Verantwortlichkeiten bei Integrationen, nachvollziehbare Kosten und ein realistisches Abnahmekonzept. Wo Anbieter etwas nicht live zeigen können, braucht es einen späteren prüfbaren Nachweis statt eines Häkchens in einer Funktionsliste.
Eine große Scorecard mit hundert Kriterien vermittelt Präzision. Ein reproduzierbarer Test der wenigen geschäftskritischen Vorgänge liefert meist die bessere Entscheidung. Die Gewichtung der Kriterien bleibt Sache der Organisation; ein allgemeingültiger Grenzwert, ab dem jedes LMS ersetzt werden müsste, existiert nicht.
Ein System ist nicht allein deshalb austauschreif, weil es alt oder unbeliebt ist. Es ist austauschreif, wenn relevante Anforderungen nachweislich nicht mehr angemessen erfüllt werden können und ein Wechsel unter Berücksichtigung seiner eigenen Risiken die vernünftigere Option darstellt. Diese Beweislast schützt vor zwei teuren Fehlern: vorschnellem Austausch und endlosem Festhalten.
Quellen
- ISO/IEC 25010:2023 — Product quality model — IEC / ISO · 2023
- ISO/IEC 25012:2008 — Data quality model — ISO · 2008
- Common Cartridge — Interoperability of learning resources — 1EdTech Consortium
- Selecting a Learning Management System: Advice from an Academic Perspective — EDUCAUSE Review · 2014
- Changing Course Management Systems: Lessons Learned — EDUCAUSE Review · 2005