- SCORM verbindet paketierte E-Learning-Inhalte mit einem LMS.
- xAPI standardisiert Experience-Daten und deren Austausch mit einem Learning Record Store.
- cmi5 nutzt xAPI und ergänzt Regeln für LMS-Launch und sessionbasiertes Lernen.
- Die Auswahl sollte vom benötigten Prozess ausgehen, nicht vom Alter des Standards.
Wer ein LMS auswählt, Lerninhalte einkauft oder eine bestehende Akademie migriert, trifft schnell auf drei Kürzel: SCORM, xAPI und cmi5. Oft werden sie wie drei Generationen derselben Technik dargestellt. Genau das führt zu falschen Anforderungen.
Die kurze Antwort: SCORM standardisiert vor allem das Zusammenspiel eines paketierten E-Learning-Kurses mit einem LMS. xAPI standardisiert die Übertragung von Lernerfahrungsdaten an einen Learning Record Store. cmi5 nutzt xAPI, ergänzt aber Regeln für LMS-gestützte, sessionbasierte Lerninhalte.
Die wichtigste Korrektur zuerst: xAPI ist nicht einfach SCORM 2.0
SCORM beantwortet eine sehr konkrete Frage: Wie kann ein E-Learning-Paket in unterschiedlichen kompatiblen Lernmanagementsystemen gestartet werden und mit dem LMS über typische Laufzeitdaten kommunizieren?
xAPI setzt an einer anderen Stelle an. Der aktive IEEE-Standard 9274.1.1-2023 beschreibt ein JSON-Datenmodell und eine REST-Schnittstelle, über die Aktivitäten Experience-Daten an einen Learning Record Store, kurz LRS, senden und daraus abrufen können. Seit Oktober 2025 existiert dieser Standard zusätzlich als ISO/IEC/IEEE 39274-1-1.
Damit wird der Problemraum größer. Eine Lernerfahrung muss nicht mehr zwingend ein klassischer Kurs sein, der innerhalb eines LMS im Browser läuft. Das ist leistungsfähig, löst aber nicht automatisch alle Dinge, die SCORM für einen klassischen Kurs festlegt.
| Ansatz | Kernproblem | Typischer Fit |
|---|---|---|
| SCORM | Kurs und LMS interoperabel verbinden | Portable Standard-E-Learnings |
| xAPI | Experience-Daten interoperabel erfassen | Verteilte Lern- und Performance-Daten |
| cmi5 | xAPI-basierten Kurs mit LMS-Regeln verbinden | Sessionbasierte LMS-Kurse auf xAPI-Basis |
Was SCORM gut kann
SCORM wurde für eine Welt gebaut, in der ein Autorentool einen Kurs erzeugt, dieser Kurs als Paket in ein LMS importiert wird und das LMS Dinge wie Start, Status, Ergebnis oder Bearbeitungsstand verwaltet.
Gerade dafür ist die Begrenzung auch eine Stärke. Inhaltsersteller und LMS-Anbieter haben einen relativ klar umrissenen Vertrag. Wer Standard-E-Learnings von verschiedenen Anbietern einkauft und in einem LMS betreiben will, benötigt nicht automatisch eine komplexere Experience-Architektur.
Die Grenzen werden sichtbar, wenn Lernen den klassischen Kurscontainer verlässt. ADL beschreibt unter anderem das feste Datenmodell sowie die starke Bindung an browser- und LMS-zentrierte Inhalte als Einschränkungen von SCORM. Aktivitäten in anderen Anwendungen, Simulationen oder verteilte Lern- und Performance-Erfahrungen passen schlechter in dieses Modell.
Das macht SCORM nicht wertlos. Es macht seinen Anwendungsbereich klarer.
Was xAPI anders macht
xAPI denkt nicht zuerst in Kursen, sondern in Erfahrungen und deren Daten.
Eine Anwendung kann eine Aktivität als strukturiertes Statement an ein LRS melden. Dadurch lassen sich Daten aus unterschiedlichen Quellen in einem gemeinsamen technischen Modell erfassen. Der IEEE-Standard definiert dafür Datenformat und RESTful Web Service.
Das ist interessant, wenn Lern- und Performance-Daten aus mehreren Systemen zusammenlaufen sollen oder wenn relevante Aktivitäten außerhalb eines klassischen LMS-Kurses stattfinden.
Diese Flexibilität hat eine Kehrseite: xAPI allein sagt noch nicht, wie ein traditioneller LMS-Kurs paketiert, gestartet und innerhalb einer Session gesteuert werden soll. Genau deshalb ist „Wir unterstützen xAPI“ als Anforderung häufig zu unscharf. Man muss wissen, welchen Prozess die Schnittstelle tatsächlich interoperabel machen soll.
Und wofür gibt es dann cmi5?
cmi5 schließt einen Teil dieser Lücke. Das offizielle Projekt beschreibt cmi5 als Profil für die Nutzung von xAPI mit traditionellen Lernmanagementsystemen.
Vereinfacht gesagt: xAPI liefert die Sprache für Experience-Daten; cmi5 legt zusätzliche Regeln fest, damit ein LMS und ein xAPI-basierter Kurs in einem definierten Launch- und Sessionmodell zusammenarbeiten können.
Die aktuell veröffentlichte cmi5-Spezifikation ist Quartz, 1st Edition aus dem Jahr 2016. Gleichzeitig läuft die formale Weiterentwicklung im IEEE-Projekt P9274.3.1. Dessen Scope umfasst ausdrücklich Packaging, Launch und Runtime von xAPI in sessionbasiertem Lernen. Am 7. September 2026 führt IEEE das Vorhaben als Active PAR, noch nicht als veröffentlichten IEEE-Standard.
Diese Unterscheidung ist bei Ausschreibungen wichtig. xAPI selbst besitzt bereits einen aktiven IEEE- und internationalen ISO/IEC/IEEE-Standardstatus. cmi5 befindet sich für seine nächste formale Standardisierung noch im Prozess.
Welchen Ansatz braucht man nun?
Wenn vor allem fertige E-Learning-Pakete zwischen LMS austauschbar sein müssen, ist SCORM weiterhin ein naheliegender Ausgangspunkt.
Wenn Aktivitäten aus mehreren Systemen zusammengeführt werden sollen, wird xAPI relevant. Dann gehören LRS, Profile und Datenverwendung in die Architektur.
Wenn ein definierter LMS-Launch und Sessionregeln benötigt werden, sollte cmi5 geprüft werden.
Warum „Wir migrieren alles auf xAPI“ keine Strategie ist
Technische Modernisierung klingt oft nach Ablösung: SCORM raus, xAPI rein. Diese Logik ist zu grob.
Ein Unternehmen mit hunderten funktionierenden Standardkursen gewinnt wenig, wenn es diese ohne neuen fachlichen Bedarf in eine komplexere Architektur überführt. Umgekehrt wird ein Unternehmen, das Lernaktivitäten aus Simulationen, Arbeitsanwendungen und mehreren Plattformen zusammenführen möchte, mit einem reinen SCORM-Modell schnell an Grenzen stoßen.
Der Standard sollte deshalb aus dem gewünschten Prozess folgen, nicht umgekehrt.
Was in ein LMS-Lastenheft gehört
Statt „SCORM, xAPI und cmi5 müssen unterstützt werden“ lohnt sich eine präzisere Beschreibung:
- Welche vorhandenen Content-Pakete müssen importiert und abgespielt werden?
- Welche Laufzeit- und Abschlussdaten müssen dabei zuverlässig erhalten bleiben?
- Entstehen relevante Lernaktivitäten außerhalb des LMS?
- Gibt es bereits ein LRS oder soll eines Teil der Architektur werden?
- Müssen xAPI-basierte Inhalte als klar definierte LMS-Kurse gestartet und verwaltet werden?
- Welche bestehenden Inhalte müssen bei einer Migration unverändert weiterlaufen?
Aus diesen Antworten entsteht eine technische Anforderung. Eine Liste mit drei Häkchen entsteht dagegen sehr schnell und sagt erstaunlich wenig.
Fazit: Erst das Interoperabilitätsproblem, dann das Kürzel
SCORM, xAPI und cmi5 sind nicht einfach alt, neu und neuer. Sie überlappen, aber sie setzen an unterschiedlichen Stellen an.
SCORM ist stark, wenn ein klassischer E-Learning-Kurs zuverlässig mit einem LMS zusammenspielen soll. xAPI erweitert die Perspektive auf Experience-Daten aus unterschiedlichen Quellen. cmi5 bringt xAPI wiederum in einen stärker definierten LMS-Kurskontext.
Wer diese Ebenen trennt, kann bei LMS-Auswahl, Content-Einkauf und Migration viel präziser fragen. Und genau das ist am Ende wichtiger als die längste Liste unterstützter Standards.