LMS-Ausschreibung: Warum ein gutes Lastenheft keine Featureliste ist

Viele LMS-Lastenhefte sehen auf den ersten Blick gründlich aus. Es gibt Tabellen mit Funktionen, Muss-/Soll-Spalten, Integrationen, Rollen, Reports und technischen Stichworten. Je länger die Liste, desto belastbarer wirkt die Auswahl.

Genau das kann täuschen. Eine Anforderung wie „Das LMS unterstützt automatische Zuweisungen“ lässt sich fast immer mit Ja beantworten. Offen bleibt, wer zuweist, welches Ereignis auslöst, welche Daten benötigt werden, was bei einem Rollenwechsel passiert und woran der Auftraggeber später erkennt, dass der Prozess wirklich funktioniert.

Ein gutes Lastenheft ist deshalb keine möglichst vollständige Feature-Sammlung. Es ist ein prüfbares Modell der Arbeitsprozesse, Qualitätsanforderungen und Grenzen, die das künftige LMS beherrschen muss. Erst wenn Anforderungen so formuliert sind, werden Anbieter tatsächlich vergleichbar – und aus einer Auswahl wird später eine abnehmbare Umsetzung.

Eine Anforderung muss mehr können als plausibel klingen

Requirements Engineering liefert dafür einen nützlichen Maßstab. Das IREB nennt für einzelne Anforderungen unter anderem Angemessenheit, Notwendigkeit, Eindeutigkeit, Vollständigkeit, Verständlichkeit und Verifizierbarkeit. Gerade bei einer formalen Abnahme ist der letzte Punkt entscheidend: Die Erfüllung einer Anforderung muss so prüfbar sein, dass nicht zwei Parteien zu unterschiedlichen Ergebnissen kommen.

Für ein LMS heißt das: „Mandantenfähigkeit vorhanden“ ist noch keine belastbare Anforderung. „Ein Administrator des Mandanten A darf weder Nutzer noch Lernstände des Mandanten B sehen; dies wird mit zwei getrennten Testmandanten geprüft“ ist wesentlich näher an einer späteren Abnahme.

Dasselbe gilt für Reporting, Reminder, Zertifikate, Rollen, SSO oder Schnittstellen. Sobald eine Anforderung nur beschreibt, dass etwas vorhanden sein soll, aber nicht, was im konkreten Prozess passieren muss, bleibt ein großer Interpretationsraum. Dieser Interpretationsraum verschwindet nicht nach dem Zuschlag. Er wird nur teurer.

Der Arbeitsprozess kommt vor dem Modulnamen

Der einfachste Schutz vor einer Featureliste ist, nicht mit dem Produktmenü zu beginnen. Starten Sie mit den Vorgängen, die im Betrieb funktionieren müssen.

Ein Beispiel: Ein neuer Mitarbeiter tritt ein, wird aus dem HR-System übernommen, erhält wegen Standort und Rolle zwei Pflichttrainings, muss eines davon innerhalb von 14 Tagen abschließen, bekommt bei Verzug eine Erinnerung und verliert nach einem Rollenwechsel eine nicht mehr relevante Zuweisung. Die Führungskraft braucht einen Status, die Administration einen belastbaren Nachweis.

Aus diesem einen Prozess entstehen mehrere Anforderungen. Identitätsdaten müssen ankommen. Regeln müssen Rollen und Organisationseinheiten auswerten. Fristen und Reminder benötigen eine definierte Logik. Statusänderungen müssen nachvollziehbar sein. Reporting und Nachweise brauchen eine fachliche Bedeutung.

Wer stattdessen fünf getrennte Zeilen zu „Benutzerimport“, „automatischer Zuweisung“, „Reminder“, „Reporting“ und „Zertifikaten“ schreibt, kann fünfmal ein Ja bekommen und trotzdem nicht wissen, ob der Gesamtprozess funktioniert.

Genau deshalb lohnt es sich, Integrationsanforderungen nicht nur als „API vorhanden“ zu formulieren. Bei der Verbindung von LMS und HR-System entscheidet zum Beispiel nicht die Existenz einer Schnittstelle, sondern Datenhoheit, Richtung, Trigger, Lifecycle und Fehlerbehandlung.

Eine belastbare Anforderung hat vier Teile

Für die Praxis hilft eine einfache Struktur. Sie ist kein Normschema, sondern eine redaktionelle Synthese aus Requirements Engineering und Abnahmelogik: Bedarf, Kontext, erwartetes Verhalten und Prüfnachweis.

Der Bedarf beantwortet, welches Problem oder Ziel hinter der Anforderung steht. Der Kontext beschreibt Rollen, Daten, Auslöser und relevante Bedingungen. Das erwartete Verhalten sagt, was das System in dieser Situation leisten soll. Der Prüfnachweis legt fest, wie Anbieter und Auftraggeber später zeigen, dass die Aussage stimmt.

Damit wird aus „Das LMS kann Erinnerungen versenden“ beispielsweise: „Wenn ein verpflichtender Kurs sieben Tage vor Fälligkeit noch offen ist, erhält der Teilnehmer automatisiert eine konfigurierbare Erinnerung; die Regel wird an einem definierten Testfall mit Fälligkeit, Versand und dokumentiertem Status geprüft.“

Die Formulierung ist länger. Dafür erzeugt sie deutlich weniger Diskussion darüber, was mit „kann“ ursprünglich gemeint war.

Was das System tut, ist nur die halbe Spezifikation

Ein LMS kann fachlich alle gewünschten Funktionen besitzen und trotzdem für den vorgesehenen Einsatz ungeeignet sein. Anforderungen an Qualität, Betrieb und technische Randbedingungen gehören deshalb genauso in die Spezifikation wie Lernfunktionen.

ISO/IEC 25010:2023 beschreibt ein Produktqualitätsmodell für Software und ICT-Produkte und nennt ausdrücklich die Nutzung für Anforderungsdefinition, Vollständigkeitsprüfung, Testziele und Abnahmekriterien. Der wichtige Gedanke für eine LMS-Auswahl ist nicht, jede Normkategorie mechanisch in ein Lastenheft zu kopieren. Er lautet: Produktqualität muss ebenso spezifiziert und bewertet werden wie Funktionalität.

Dazu gehören je nach Einsatzkontext beispielsweise Reaktionsverhalten, Zuverlässigkeit, Schutzbedarf, Bedienbarkeit, technische Kompatibilität oder Wartbarkeit. Welche davon relevant sind und wie streng sie ausfallen müssen, hängt vom konkreten Betrieb ab.

Eine Anforderung „System ist performant“ hilft dabei nicht. Eine definierte Nutzerlast, ein konkreter Prozess und ein akzeptables Antwortverhalten sind prüfbarer. Gleiches gilt für Verfügbarkeit, Backup, Recovery oder Support: Ein Schlagwort ersetzt keinen Erwartungswert.

Standards müssen präzise genug sein, um etwas zu entscheiden

Standards sind im Lastenheft besonders anfällig für Scheingenauigkeit. „SCORM-kompatibel“, „LTI-fähig“ oder „barrierefrei“ klingt technisch konkret, kann aber sehr unterschiedliche Implementierungen bedeuten.

1EdTech geht in seiner eigenen RFP-Guidance für LTI genau auf dieses Problem ein. Die Organisation schlägt je nach Beschaffungsziel Formulierungen vor, die nicht nur allgemein nach LTI fragen, sondern Versionen, unterstützte Services und aktuelle Zertifizierung konkretisieren. Anbieter sollen außerdem offenlegen, welche Bestandteile nicht unterstützt werden und welche optionalen Dienste oder Parameter benötigt werden.

Der Punkt lässt sich über LTI hinaus übertragen: Wenn ein Standard für die Entscheidung wichtig ist, sollte klar sein, welche Version, welcher Teil und welcher Nachweis erwartet werden.

Bei Learning Standards hilft deshalb zuerst die Frage, welches Interoperabilitätsproblem überhaupt gelöst werden soll. SCORM, xAPI und cmi5 sind keine drei unterschiedlich modernen Häkchen für dieselbe Anforderung.

Barrierefreiheit zeigt dasselbe Muster. WCAG 2.2 formuliert seine Erfolgskriterien bewusst als testbare Aussagen. Für ein Lastenheft ist „barrierefrei“ daher weniger hilfreich als ein klar benannter Zielstandard, ein benötigtes Konformitätsniveau und ein vereinbartes Prüfverfahren für die betroffenen webbasierten Oberflächen. Welche rechtliche Verpflichtung im konkreten Projekt gilt, ist davon getrennt zu klären.

„Muss“ ist keine Qualitätsstufe

Viele Kriterienkataloge wirken präzise, weil jede Zeile als Muss, Soll oder Kann markiert ist. Diese Priorisierung ist nützlich – aber sie verbessert keine unklare Anforderung.

Ein unscharfes Muss bleibt unscharf. Noch problematischer wird es, wenn sehr viele Anforderungen vorsorglich zu Muss-Kriterien werden. Dann entscheidet nicht mehr der tatsächliche Bedarf über den Ausschluss, sondern möglicherweise eine historisch gewachsene Wunschliste.

Bei öffentlichen Vergaben kommt eine zusätzliche formale Ebene hinzu. Artikel 42 der EU-Richtlinie 2014/24/EU verlangt für technische Spezifikationen unter anderem gleichen Zugang und untersagt ungerechtfertigte Wettbewerbshindernisse. Leistungs- oder Funktionsanforderungen sind ausdrücklich möglich, müssen aber hinreichend präzise sein. Das ist eine vergaberechtliche Regel für öffentliche Auftraggeber, keine allgemeine Vertragsvorgabe für jedes private LMS-Projekt.

Als Denkprinzip ist sie trotzdem nützlich: Ein Muss sollte sich aus dem Gegenstand und dem tatsächlichen Bedarf begründen lassen. Je härter die Konsequenz einer Anforderung, desto klarer sollte sein, warum sie notwendig ist und wie ihre Erfüllung geprüft wird.

Anforderung und Bewertung sind zwei verschiedene Ebenen

Ein weiterer häufiger Fehler entsteht, wenn die Anforderung schon die komplette Bewertungslogik enthalten soll. Dann wird aus einem fachlichen Bedarf schnell eine komplizierte Punktelogik, obwohl noch nicht einmal geklärt ist, was als erfüllt gilt.

Sauberer ist die Trennung. Zuerst wird beschrieben, was gebraucht wird und welche Mindestgrenze gilt. Danach folgt die Frage, ob oberhalb dieser Grenze Unterschiede zwischen Angeboten überhaupt entscheidungsrelevant sind.

Ein Beispiel: Wenn 99,9 Prozent Verfügbarkeit die fachlich notwendige Mindestgrenze sind, ist das zunächst eine Anforderung. Ob 99,95 Prozent gegenüber 99,9 Prozent zusätzliche Punkte wert sind, ist eine Bewertungsentscheidung. Dasselbe gilt für Supportzeiten, Konfigurierbarkeit, Administrationskomfort oder zusätzliche Integrationen.

Diese Trennung schützt vor zwei Verzerrungen. Zum einen werden Mindestanforderungen nicht künstlich zu Punktesammlern. Zum anderen bekommt nicht jede zusätzliche Funktion automatisch Gewicht, nur weil sie messbar ist.

Die Bewertungsmatrix sollte also nicht fragen, wer am meisten liefern kann. Sie sollte unterscheiden, welche Grenzen zwingend sind und bei welchen Kriterien ein besseres Ergebnis tatsächlich einen höheren Nutzen erzeugt.

Fordern Sie mehr als ein Ja vom Anbieter

Auch ein gut formulierter Kriterienkatalog verliert viel Wert, wenn die Antwort nur „erfüllt / nicht erfüllt“ zulässt.

Für die spätere Vergleichbarkeit sollte sichtbar werden, wie eine Anforderung erfüllt wird. Ist die Funktion im Standard vorhanden? Muss sie konfiguriert werden? Ist eine Integration nötig? Erfordert sie kundenspezifische Entwicklung? Gehört sie nur zur Roadmap? Welche Voraussetzung oder Lizenz ist damit verbunden?

Diese Antwortlogik verändert die Qualität der Auswahl erheblich. Zwei Anbieter können dieselbe Anforderung mit „Ja“ beantworten und trotzdem völlig unterschiedliche Einführungsrisiken verursachen.

Bei kritischen Anforderungen sollte außerdem ein Beleg vereinbart werden: Dokumentation, Zertifikat, Teststellung, konkretes Demo-Szenario, Exportdatei oder ein anderer nachvollziehbarer Nachweis. Ein Kriterienkatalog wird damit nicht nur Bewertungsbogen, sondern Vorbereitung für Due Diligence und Abnahme.

Zu viel Spezifikation kann genauso schaden

Die Gegenposition ist wichtig: Nicht jede Anforderung muss bis zum letzten Feld und Klick vorgegeben werden.

Das IREB weist darauf hin, dass der notwendige Detailgrad von Informationsbedarf, Stakeholdern und Projektsituation abhängt. Eine leichtere Spezifikation kann unnötigen Aufwand vermeiden, wenn zusätzliche Details für das gemeinsame Verständnis nicht gebraucht werden.

Das ist gerade bei einem Standardprodukt relevant. Wer im Lastenheft den heutigen Prozess samt aller Masken, Feldnamen und manuellen Zwischenschritte nachbaut, kann ungewollt eine alte Lösung konservieren. Dann wird nicht mehr beschrieben, welches Ergebnis gebraucht wird, sondern wie der bisherige Anbieter es umgesetzt hat.

Auch hier ist die öffentliche Vergabe ein nützlicher Extremtest: Technische Spezifikationen sollen den Wettbewerb nicht ungerechtfertigt einschränken. Im privaten Einkauf gibt es dieselbe Vorschrift nicht, aber dieselbe wirtschaftliche Frage: Schließt eine Vorgabe wirklich ungeeignete Lösungen aus – oder nur Lösungen, die dasselbe Ziel anders und vielleicht besser erreichen?

Ein gutes Lastenheft ist deshalb präzise bei Bedarf, Grenzen und Abnahme. Bei der Lösungsarchitektur lässt es dort Spielraum, wo dieser Spielraum einen echten Wettbewerb der Ansätze ermöglicht.

Die Abnahme beginnt beim Schreiben der Anforderung

Der stärkste Test für eine Anforderung ist simpel: Wie würden Sie sie nach der Auswahl prüfen?

Wenn darauf keine klare Antwort existiert, ist die Anforderung wahrscheinlich noch nicht fertig. Das gilt nicht nur für eine formale Ausschreibung. Es hilft auch bei kleineren Auswahlverfahren, Workshops und strukturierten Anbieterabfragen.

Die spätere Demo sollte dann nicht neben dem Lastenheft stehen, sondern daraus entstehen. Kritische Anforderungen werden in konkrete Szenarien übersetzt. Integrationen werden mit den vorgesehenen Daten und Ereignissen geprüft. Qualitätsanforderungen erhalten Mess- oder Nachweisformen. Abweichungen bleiben sichtbar statt in einer Gesamtnote zu verschwinden.

So entsteht eine durchgehende Linie vom Bedarf über die Ausschreibung bis zur Implementierung: Warum brauchen wir das? Was genau erwarten wir? Wie weist der Anbieter es nach? Wie prüfen wir es später?

Ein Lastenheft wird dadurch nicht zwangsläufig kürzer. Aber jede Zeile bekommt eine Funktion.

Das bessere Lastenheft macht die Entscheidung kleiner

Eine LMS-Auswahl ist komplex, weil Prozesse, Daten, Integrationen, Qualität, Betrieb und Organisation zusammenkommen. Ein schlechter Kriterienkatalog vergrößert diese Komplexität noch, indem er hunderte Aussagen sammelt, die sich nur schwer gewichten und noch schwerer prüfen lassen.

Ein gutes Lastenheft tut das Gegenteil. Es trennt echte Muss-Grenzen von Präferenzen. Es beschreibt Prozesse statt Produktmenüs. Es benennt Standards präzise. Es macht Qualitätsanforderungen sichtbar. Und es verbindet entscheidende Kriterien mit einem Nachweis oder einer späteren Abnahme.

Damit wird aus der Frage „Welches LMS hat die meisten Häkchen?“ eine deutlich bessere Frage: Welches System erfüllt unsere kritischen Prozesse und Rahmenbedingungen nachweisbar – mit welchem Aufwand, welchen Abhängigkeiten und welchen verbleibenden Lücken?

Genau dafür sollte ein Lastenheft da sein.