LMS und HR-System verbinden: Welche Daten wirklich synchronisiert werden sollten

Eine API kann fehlerfrei laufen und trotzdem die falschen Daten an die falsche Stelle schreiben. Genau das macht Integrationen zwischen HR-System und LMS tückischer, als es im Architekturdiagramm aussieht.

Technisch ist vieles lösbar: Benutzer anlegen, Attribute aktualisieren, Gruppen übertragen, Konten deaktivieren. Die schwierigere Frage kommt davor. Welches System darf eigentlich entscheiden, was für einen Mitarbeiter gerade gilt?

Wer diese Frage erst im Feldmapping beantwortet, baut die Fachlogik nebenbei. Besser ist die umgekehrte Reihenfolge: zuerst Datenhoheit und Prozessgrenzen klären, dann die passende technische Verbindung wählen.

Eine Schnittstelle kann technisch funktionieren und fachlich trotzdem falsch sein

Nehmen wir einen Mitarbeiter, der die Abteilung wechselt. Im HR-System ändert sich seine organisatorische Zuordnung. Das LMS kennt weiterhin die alte Abteilung. Ein Connector kann diesen Wert sofort überschreiben. Er kann ihn einmal täglich importieren. Oder er kann ihn gar nicht benötigen.

Alle drei Varianten können technisch funktionieren. Fachlich sind sie nicht gleich.

Denn hinter einem einzelnen Feld hängen oft weitere Entscheidungen: Wird die Abteilung nur für Reporting angezeigt? Steuert sie automatische Schulungszuweisungen? Darf ein Administrator sie im LMS manuell korrigieren? Was passiert beim nächsten Import mit dieser Korrektur?

Die Schnittstelle beantwortet keine dieser Fragen. Sie transportiert nur den Zustand, den wir ihr als richtig vorgeben.

Darum sollte die erste Integrationsentscheidung nicht „API, SCIM oder CSV?“ lauten. Sie sollte lauten: Welche Daten braucht der nachgelagerte Prozess wirklich, und wer besitzt für jedes dieser Daten die Wahrheit?

Zuerst klären: Wer besitzt welches Datum?

Bei einer LMS/HR-Integration lohnt es sich, drei Datenarten auseinanderzuhalten.

Identitäts- und Lifecycle-Daten beschreiben zunächst die Person und ihren Beschäftigungsstatus: etwa eine stabile Personalnummer, Name, geschäftliche E-Mail-Adresse oder aktiv/inaktiv. In einem HR-getriebenen Provisioning-Modell kann das HR-System dafür die Autoritätsquelle sein. Microsoft beschreibt genau dieses Muster für Einstellungen, Profiländerungen und Austritte.

Organisationsdaten liefern Kontext: Abteilung, Kostenstelle, Organisationseinheit oder Vorgesetzter. RFC 7643 kennt mehrere solcher Attribute in der SCIM Enterprise User Extension. Daraus folgt aber nicht, dass jedes LMS jedes Feld braucht. Ein Datum sollte nur fließen, wenn ein konkreter Lern-, Administrations- oder Reportingprozess davon abhängt.

Lernprozessdaten entstehen dagegen häufig erst im Lernsystem. Wenn ein LMS beispielsweise eine Zuweisung erzeugt, einen Abschluss berechnet oder ein Zertifikat verwaltet, muss separat entschieden werden, ob irgendein nachgelagertes System diese Information benötigt. Ein Rückkanal ist kein natürlicher Gegenpol zum HR-Import. Er braucht einen eigenen Zweck.

Das klingt nach Semantik. Ist es auch. Und genau diese Semantik entscheidet später, ob zwei Systeme denselben Mitarbeiter konsistent oder widersprüchlich abbilden.

SCIM löst Identitäten, nicht Ihre Trainingslogik

SCIM ist für diesen Zusammenhang nützlich, gerade weil der Standard seine Grenze relativ klar zieht.

RFC 7644 beschreibt SCIM als HTTP-basiertes Protokoll zum Provisionieren und Verwalten von Identitätsdaten. Zu den Kernressourcen gehören Benutzer und Gruppen. RFC 7643 ergänzt die zugehörigen Schemas und eine Enterprise-Erweiterung für typische Organisationsattribute.

Damit lässt sich viel Infrastruktur vereinheitlichen.

Was SCIM nicht definiert, ist die fachliche Bedeutung einer LMS-Gruppe. RFC 7643 sagt bei Group-Ressourcen ausdrücklich, dass die konkrete Semantik einer Gruppenmitgliedschaft und das daraus folgende Verhalten beim Service Provider liegen.

Für ein LMS ist das entscheidend. Eine Gruppe kann eine Organisationseinheit abbilden. Sie kann aber auch eine Schulungskohorte, eine Rolle oder irgendeinen technischen Auswahlmechanismus darstellen. Der Standard transportiert Identitäts- und Gruppendaten. Er entscheidet nicht, ob daraus eine Pflichtschulung entsteht.

Deshalb ist „wir machen das mit SCIM“ noch kein vollständiges Integrationskonzept.

SSO, Provisioning und Fachlogik sind drei verschiedene Probleme

In Projekten verschwimmen diese Ebenen schnell.

SSO beantwortet, wie sich ein Nutzer anmeldet. Provisioning beantwortet, wie ein Konto und seine Identitätsattribute entstehen, geändert oder deaktiviert werden. Die Fachlogik beantwortet schließlich, was das Lernsystem mit diesen Informationen tut.

Ein Mitarbeiter kann sich also erfolgreich per SSO anmelden, obwohl seine Abteilung im LMS veraltet ist. Ein SCIM-Prozess kann das Konto sauber deaktivieren, ohne irgendeine Aussage dazu zu treffen, wie lange historische Lernnachweise erhalten bleiben. Und eine korrekt synchronisierte Abteilung garantiert noch nicht, dass eine automatische Kurszuweisung fachlich richtig definiert ist.

Das ist keine Wortklauberei. Wer alle drei Ebenen unter „HR-Schnittstelle“ zusammenfasst, kann später kaum sagen, wo ein Fehler tatsächlich entstanden ist.

Die Abgrenzung zu Beginn spart deshalb nicht Dokumentation. Sie macht Dokumentation überhaupt erst brauchbar.

Joiner, Mover, Leaver ist erst der Anfang

Der klassische Joiner-Mover-Leaver-Lifecycle ist ein guter Test für die Integrationslogik.

Beim Eintritt ist meist leicht zu erkennen, was passieren soll: Ein neuer Datensatz entsteht und ein Konto wird angelegt. Interessanter wird es beim Wechsel. Welche Attribute dürfen sich ändern? Welche Zuordnungen müssen neu berechnet werden? Was bleibt bewusst bestehen?

Beim Austritt wird die Trennung noch wichtiger. „Benutzer deaktivieren“ ist eine Identity-Entscheidung. „Lernhistorie löschen“ wäre eine völlig andere fachliche Entscheidung. Das eine darf nicht versehentlich aus dem anderen abgeleitet werden.

Ähnlich beim Wiedereintritt. Wird dieselbe Person über einen stabilen Schlüssel wiedererkannt oder entsteht ein zweites Konto? Welche historischen Daten sollen wieder sichtbar sein? Solche Fälle werden nicht durch einen zusätzlichen API-Endpunkt gelöst. Sie brauchen vorher eine eindeutige fachliche Regel.

Microsoft zeigt in seiner HR-getriebenen Provisioning-Dokumentation, wie Quelle, Ziel und Lifecycle-Aktionen getrennt modelliert werden können. Für eine LMS-Integration lässt sich daraus ein nützliches Prinzip ableiten: Jeder Zustandswechsel braucht einen definierten Owner und eine definierte Folge. Nicht mehr und nicht weniger.

Der eigentliche Integrationsvertrag passt auf eine Seite

Bevor Entwickler das erste Mapping bauen, sollte für jedes relevante Datum oder Ereignis ein kleiner Vertrag stehen.

• Owner: Welches System darf den fachlich gültigen Wert setzen?
• Schlüssel: Woran wird dieselbe Person oder Organisationseinheit systemübergreifend erkannt?
• Richtung: Fließt der Wert nur zum LMS, nur zurück oder tatsächlich in beide Richtungen?
• Trigger: Wird bei einem Ereignis synchronisiert, zyklisch abgeglichen oder manuell angestoßen?
• Schreibregel: Was passiert bei Create, Update, Deaktivierung und Wiedereintritt?
• Leere Werte: Bedeutet leer „löschen“, „unbekannt“ oder „nicht ändern“?
• Konflikt: Welcher Wert gewinnt, wenn Quelle und Ziel auseinanderlaufen?
• Betrieb: Wie werden Fehler, Wiederholungen und dauerhaft nicht verarbeitbare Datensätze sichtbar?

Microsoft empfiehlt bei der Planung eines SCIM-Endpunkts einen ähnlichen Startpunkt: zuerst die Objekte und Attribute auflisten, die eine Anwendung tatsächlich benötigt, und dann unterscheiden, welche davon für Authentifizierung, Lifecycle oder die eigentliche Anwendungsfunktion nötig sind.

Das ist unspektakulär. Aber genau daraus wird eine Integration, die man testen und betreiben kann.

Ein Mapping-Dokument sagt nur, dass department nach department geschrieben wird. Ein Datenvertrag erklärt zusätzlich, warum das geschieht, wer den Wert besitzt und was bei einer Änderung passieren muss.

Weniger Sync kann die bessere Lösung sein

Es gibt einen wichtigen Gegenfall: Vielleicht braucht das LMS gar keine tiefe HR-Integration.

Wenn der eigentliche Zweck nur darin besteht, Benutzer automatisch anzulegen, Stammdaten zu aktualisieren und ausgeschiedene Personen zu deaktivieren, kann ein sauberer Provisioning-Prozess ausreichen. Dann wäre es unnötig, Lernstände, Zertifikate oder weitere Prozessdaten zurück in ein HR-System zu drücken, nur weil technisch ein Rückkanal möglich ist.

Auch organisatorische Attribute verdienen diesen Test. Eine Kostenstelle, die im LMS keinen Prozess steuert und in keinem sinnvollen Report gebraucht wird, muss dort nicht allein aus Vollständigkeitsgefühl gepflegt werden.

Integration ist kein Wettbewerb um die Zahl synchronisierter Felder.

Je weniger Systeme denselben Wert verändern dürfen, desto klarer bleibt die Zuständigkeit. Und je weniger Datenflüsse ein Prozess wirklich braucht, desto weniger Sonderfälle müssen später erklärt werden.

Gute Integrationen haben klare Zuständigkeiten

Die wichtigste Designentscheidung bei einer LMS/HR-System-Verbindung fällt vor der Technik.

SCIM, APIs oder Dateiimporte können Daten zuverlässig transportieren. Sie können aber nicht entscheiden, welches System einen Wert fachlich besitzt, wann ein Wechsel eine Lernzuweisung verändert oder ob ein Lernergebnis überhaupt zurückgeschrieben werden sollte.

Deshalb beginnt eine belastbare Integration mit einer kleinen Menge präziser Fragen: Welche Daten braucht der LMS-Prozess? Wo entsteht der gültige Wert? In welche Richtung darf er fließen? Was passiert bei Änderungen und Fehlern?

Erst wenn das feststeht, wird die Wahl der Schnittstelle interessant.

Und manchmal lautet die beste Integrationsarchitektur nicht „mehr synchronisieren“, sondern ganz bewusst: genau genug.