Wer an einer Hochschule Lehrevaluationen mit LimeSurvey umsetzt, kennt das Muster: Es funktioniert – bis die Struktur komplexer wird. Eine Vorlesung mit drei Übungsgruppen und drei unterschiedlichen Lehrpersonen ist mit LimeSurvey allein kein Survey-Problem mehr, sondern ein Datenmodell-Problem, das man LimeSurvey nicht ansieht.
Das eigentliche Problem liegt vor der Umfrage
LimeSurvey ist eine ausgezeichnete Survey Engine: Gruppen, Fragen, Logik, Aktivierung, Teilnehmerverwaltung – das alles beherrscht es zuverlässig. Was LimeSurvey nicht mitbringt, ist ein Modell für die akademische Realität, die vor der Umfrage steht:
Eine Lehrveranstaltung wie „Software Engineering" beschreibt zunächst nur den Gegenstand als solchen. Erst die konkrete Durchführung in einem akademischen Zeitraum – etwa „Software Engineering, WS 2026/27" – ist eine eigenständige Größe: dieselbe Veranstaltung kann in unterschiedlichen Semestern unterschiedlich besetzt und organisiert sein.
Diese konkrete Durchführung zerfällt wiederum in Lehreinheiten – Vorlesung, mehrere Übungsgruppen, ein Seminar. Lehrpersonen werden dabei nicht einfach der gesamten Veranstaltung zugeordnet, sondern ihrer konkreten Lehreinheit. Dieselbe Person kann dadurch in unterschiedlichen Rollen oder Einheiten beteiligt sein – etwa als Vorlesungsleitung und gleichzeitig als Betreuung einer Übungsgruppe.
Eine einzelne Evaluation soll diese Struktur gemeinsam erfassen: die Veranstaltung als Ganzes und die Lehrpersonen jeweils in ihrer konkreten Lehreinheit.
Wer das direkt in LimeSurvey abbildet, landet fast zwangsläufig bei einer von zwei unbefriedigenden Lösungen: entweder einer Umfrage pro Lehrperson (organisatorischer Mehraufwand, fragmentierte Auswertung) oder einer einzigen, von Hand zusammengeklickten Umfrage, die bei jeder neuen Konstellation – andere Anzahl Übungsgruppen, andere Lehrpersonen – wieder von Hand angepasst werden muss.
Copy-Paste ist keine Architektur
Der naheliegende Ausweg – eine bestehende Umfrage duplizieren und die Namen austauschen – funktioniert genau einmal gut. Danach beginnt das eigentliche Problem: Jede Kopie lebt für sich. Eine Korrektur an der Frageformulierung, ein zusätzliches Item, eine geänderte Skala – all das muss in jeder Kopie einzeln nachgezogen werden, oder es driftet auseinander, ohne dass das jemandem auffällt, bis die Auswertung nicht mehr vergleichbar ist.
Das ist kein LimeSurvey-Defizit. Es ist die Konsequenz daraus, dass eine Survey Engine keine Vorstellung davon hat, was “dieselbe Frage, mehrfach angewendet” bedeutet. Diese Bedeutung gehört in eine fachliche Schicht oberhalb der Survey Engine.
Der entscheidende Zwischenschritt: Was wird eigentlich evaluiert?
Bevor man über Fragen spricht, lohnt sich ein Schritt zurück. Eine Evaluation besteht nicht einfach aus Fragen. Sie besteht zunächst aus den Dingen, die bewertet werden sollen: die Lehrveranstaltungsdurchführung als Ganzes, und daneben jede konkrete Zuordnung einer Lehrperson zu einer Lehreinheit.
Diese Evaluationsgegenstände sind fachlich eigenständig – unabhängig davon, welche Fragen später darauf angewendet werden. Erst wenn feststeht, was evaluiert wird, lässt sich sinnvoll entscheiden, welche Fragenbausteine dafür passen.
Wo die Trennung ansetzen muss
Die tragfähige Lösung trennt zwei Dinge, die in der Praxis ständig vermischt werden:
Das Fachmodell – Lehrveranstaltung, Durchführung, Lehreinheiten, Lehrpersonen, Evaluationsgegenstände – gehört einer eigenen Anwendung, nicht LimeSurvey. LimeSurvey bekommt niemals eine eigene Vorstellung davon, wer wann was unterrichtet hat.
Die Frageninhalte – “Wie verständlich erklärt die Lehrperson?”, “Wie ist die Betreuung in der Übung?” – werden als wiederverwendbare Bausteine behandelt. Ein Baustein für die Lehrpersonen-Bewertung wird zentral gepflegt und versioniert. Er wird nicht für jede Lehrperson kopiert, sondern in der jeweils vorgesehenen Version auf die konkreten Evaluationsgegenstände angewendet.
Technisch lassen sich solche Bausteine beispielsweise als Survey-as-Code-Beschreibungen einer LimeSurvey-Fragengruppe ablegen. Die Fachanwendung muss dann keine LimeSurvey-Fragen einzeln zusammenklicken, sondern kann aus versionierten Gruppendefinitionen eine konkrete Umfrage kompilieren.
Aus der Kombination – was evaluiert wird und welche Bausteine darauf angewendet werden – lässt sich die konkrete Umfrage dann jedes Mal neu und automatisch zusammensetzen: für die aktuelle Konstellation aus Lehreinheiten und Lehrpersonen, mit konsistenten Frageninhalten über alle vergleichbaren Evaluationsgegenstände hinweg. LimeSurvey bleibt dabei genau das, was es gut kann: die Engine, die die fertig komponierte Umfrage ausführt.
Warum das mehr ist als Komfort
Diese Trennung zahlt sich an der Stelle aus, die bei Lehrevaluationen am meisten zählt: Vergleichbarkeit. Wenn jede Lehrperson dieselbe, versionsgesicherte Frage in derselben Formulierung bekommt, ist zumindest die instrumentelle Grundlage für vergleichbare Auswertungen über Lehreinheiten und Semester hinweg gesichert – statt nur Fragebögen zu haben, die der Optik nach ähnlich sind. Das ist derselbe Gedanke, der auch hinter Report-Driven Survey Design steht: Nicht die einzelne Frage ist der Ausgangspunkt, sondern das, was am Ende verglichen und entschieden werden soll.
Der zweite Effekt betrifft die Wartungslast. Eine Änderung an einer Frage – eine Skala, ein zusätzliches Item, eine präzisere Formulierung – wird an einer Stelle vorgenommen und wirkt für alle künftigen Evaluationen, die diesen Baustein verwenden. Historische Auswertungen bleiben davon unberührt, weil vergangene Durchführungen an die damalige Version des Bausteins gebunden bleiben.
Für wen das relevant wird
Diese Problematik taucht typischerweise dann auf, wenn eine Hochschule oder ein Fachbereich von einer einmaligen, manuell gepflegten Lehrevaluation zu einem wiederkehrenden, semesterweisen Prozess übergeht – oft ausgelöst durch wachsende Studierendenzahlen, mehr parallele Lehreinheiten, oder den Wunsch nach semesterübergreifend vergleichbaren Kennzahlen.
Für genau diesen Übergang habe ich ein Architekturkonzept ausgearbeitet, das LimeSurvey konsequent als Survey Engine behandelt und das Lehr-/Evaluationsmodell als eigenständige, führende Fachanwendung davor stellt. Das Konzept ist bewusst noch keine fertige Software: Ob und wie daraus eine konkrete Anwendung entsteht, hängt vom tatsächlichen Bedarf einer Hochschule oder eines Fachbereichs ab. Bei konkretem Bedarf lässt sich auf dieser Grundlage sehr gezielt über Anforderungen und Umsetzung sprechen.