Besoldung in der Feuerwehr

Die Applikation LODUR stellt Feuerwehren Funktionen zur Administration zur Verfügung. Diese umfassen hauptsächlich folgende Bereiche: Verwaltung Angehörige der Feuerwehr, Besoldung, Einsatzrapportierung, Materialverwaltung, Kursanmeldung und Übersicht über den Ausbildungsstand.
Das Modul «Besoldung» verursacht bei unserem Auftraggeber, der B. Wahlstroem Engineering GmbH, einen hohen Supportaufwand. In diesem Modul erfolgen die Konfigurationen der Besoldungsregeln, eine Aufgabe für die zur Zeit fast jede Feuerwehr den Support in Anspruch nimmt. Der Auftraggeber ist deshalb daran interessiert, die Anzahl Supportfälle mit einem Redesign des Moduls «Besoldung» zu reduzieren oder bestenfalls ganz zu eliminieren. Die Ursachen für die vielen Supportfälle sind einerseits die starke Verteilung von einzelnen Einstellungen auf verschiedene Fenster und andererseits die fachliche Komplexität der Besoldungsregeln. Denn jede Feuerwehr hat ihre eigenen, teilweise völlig unterschiedlichen Besoldungsregeln. Vereinfacht ausgedrückt definieren die Besoldungsregeln verschiedene Soldansätze sowie die Abrechnungsart für unterschiedliche Tätigkeiten. Die Abrechnungsart bestimmt, ob eine Tätigkeit pro Stunde, pauschal oder in einer Mischform vergütet wird. Besoldungsregeln werden normalerweise einmalig eingerichtet. Anpassungen erfolgen anschliessend höchstens einmal pro Jahr, wenn zum Beispiel eine Feuerwehr ihre Soldansätze an die Teuerung anpasst.
Thema dieser Masterarbeit ist eine Fallstudie für das Redesign der Benutzeroberfläche des Moduls «Besoldung» mit benutzerzentrierten Analyse- und Designmethoden. Für die Erhebung der Rohdaten haben wir vorwiegend ethnografische Interviews und ein Fragebogen eingesetzt. Mittels Sketching und Prototyping ist das Design des Lösungsvorschlages entstanden. Benutzer haben uns bei der Prototypen-Evaluation mittels Walkthroughs unterstützt.
Als methodische Vertiefung haben wir uns mit dem Schritt von den Analyse-Resultaten zum Design
befasst, also dem Überwinden des Gaps zwischen dem Problem- und Lösungsraum. Zur Zeit existiert kein gesamtheitliches Mapping zwischen den Aspekten des Problemraums und dem fertigen Design einer Benutzeroberfläche. Hübscher et al. (2012) erarbeiten für diesen Gap ein Mapping. Dieses Mapping-Modell hat zum Ziel, eine Landkarte als Orientierung zwischen dem Problem- und Lösungsraum zu bieten. In der Praxis basiert die Ableitung des Designs aus den Analyse-Resultaten hauptsächlich auf der Erfahrung der Interaction Designer und ist somit eine Art «Magic». Ein Mapping-Modell ist ein möglicher Ansatz, um dieses «Magic» zu konkretisieren.
Für diese Vertiefung haben wir zwei Vorgehensweisen für die Überwindung des Gaps verglichen: Zuerst haben wir das Design des Prototypen V 1.0 gemäss den Prinzipien der Struktur- und Rasterebene nach Garrett (2012) erarbeitet, einer Vorgehensweise mit konkreten Modellen. Vor dem Walkthrough haben wir den Prototypen mit dem Mapping-Modell nach Hübscher et al. (2012) evaluiert, der zweiten Vorgehensweise mit einem Mapping-Modell. Daraus haben sich sieben Erkenntnisse ergeben, wovon eine besagt, dass der Prototyp nicht den Bedürfnissen der primären Persona entspricht. Dies hätte eigentlich die Verschiebung des Walkthroughs mit einem Prototypen V 2.0 bedeutet. Nachdem wir aber für einen Vergleich trotzdem V 1.0 evaluiert hatten, bestätigte sich die zentrale Erkenntnis aus dem Mapping-Modell. Hätte man die Ergebnisse des Mapping-Modells bereits in V 1.0 einfliessen lassen, wäre man nun bereits für den ersten Walkthrough auf dem Stand von V 2.0 gewesen. Dies gibt einen Hinweis darauf, dass der Einsatz des Mapping-Modells Iterationen einsparen kann. Dies ist eine der noch offenen Fragestellungen, die sich aus dem Vergleich ergeben haben.
Für unseren Lösungsvorschlag stehen die Ebenen «Struktur» und «Verhalten» nach Baxley (2003) im Fokus. Die Ausarbeitung der Ebene «Präsentation» wird vom Auftraggeber nicht erwartet. Der Auftrag- geber hat als Hauptergebnis einen Wireframe HTML Prototypen erhalten. Die zuvor auf viele verschiedene Fenster verteilten Besoldungsregeln sind nun in vier Register nach den Sold-Kategorien «Soldart», «Entschädigung», «Funktionsentschädigung» und «Grundeinstellungen» aufgeteilt. Als primäre Persona haben wir einen Benutzer definiert, der gute Anwenderkenntnisse, jedoch wenig Erfahrung in der Einstellung von PC-Applikationen mitbringt. Die vier Register stellen für diesen Benutzer einen Prozess dar: Der Benut- zer beginnt mit den Einstellungen im ersten Register und führt die Eingaben in den weiteren Registern fort. Im Register «Soldarten», welches die meisten Einstellungsmöglichkeiten anbietet, führt ein Assistent für jede neu erstellte Soldart durch die Optionen. Die beiden sekundären Personas sind versierte PC-Anwender, die es gewohnt sind, Einstellungen an PC-Applikationen vorzunehmen. Die beiden Personas haben ähnliche Eigenschaften, unterscheiden sich aber wesentlich in Bezug auf ihren Verantwortungsbereich. Ihnen bieten die Register einen raschen Zugriff auf alle Einstellungsmöglichkeiten.