...

ROLLEN_DESC mit den Texten aus "Die-17-Rollen-des-Service-Lifecycle.pdf" gefuellt
- je Rolle nur "Was macht die Rolle?" + "Warum brauchen wir sie?" (Beispiel und
  SLC-Beteiligung bewusst weggelassen, wie gewuenscht).
- 15 angezeigte Rollen mit Beschreibung; operations_manager aus AL B&C + AL App
  zusammengefuehrt (Einzelrollen sind im Glossar nicht mehr enthalten).
- dpm bleibt ohne Text (kein Eintrag im PDF) -> Rolle bleibt schlichte Zeile.
- sw.js Cache hochgezaehlt.

Verifiziert: Rollen klappen mit korrekter Beschreibung auf (Umlaute/Quotes ok),
DPM ohne Aufklapp-Marker, keine Konsolenfehler.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

04_Tablet-Quiz/app/index.html

@@ -497,10 +497,23 @@ const ROLLEN = {
    Leerer String = keine Beschreibung -> Rolle bleibt eine normale Zeile. Sobald Text
    eingetragen ist, wird die Rolle in der Übersicht aufklappbar (Übersicht + linkes Panel). */
 const ROLLEN_DESC = {
-  spm:"", sor:"", service_owner:"", support_manager:"", problem_manager:"",
+  spm:"Steuert das gesamte Service-Portfolio: entscheidet über Aufnahme, Änderung und Stilllegung, sichert Strategie, Priorisierung und Wirtschaftlichkeit, aggregiert alle Review-Berichte. Hält das Gesamtportfolio konsistent und wirtschaftlich — verhindert Wildwuchs und Doppelungen einzelner Services.",
-  projektleitung:"", betriebsteam:"", service_support_team:"", projektteam:"",
+  sor:"Gremium, das Service-Aktivierungen, Betriebsfreigaben und wesentliche Anpassungen bewertet und entscheidet. Ständige Mitglieder: SPM + SO + AL B&C + AL App. Bündelt alle relevanten Perspektiven für tragfähige Go/No-Go-Entscheidungen — keine Aktivierung im Alleingang.",
-  queue_koordinator:"", first_level_agent:"", second_level_agent:"",
+  service_owner:"Trägt die fachliche End-to-End-Verantwortung für einen Service über den ganzen Lifecycle: Anforderungen, Qualität, Weiterentwicklung; primärer Entscheider für Inhalt und Wert. Eine klar verantwortliche Person, die den Service „besitzt“ — sonst zerfasert die Verantwortung über viele Stellen.",
-  testmanagement:"", architektur:"", lieferant:"", operations_manager:"", dpm:""
+  support_manager:"Verantwortet Organisation und Qualität des Service-Supports (1st & 2nd Level): Prozesse, Leitlinien, Wissensmanagement und effizientes Incident/Request-Handling. Sorgt für funktionierenden, konsistenten Support — sonst wird die Ticketbearbeitung uneinheitlich und langsam.",
+  problem_manager:"Identifiziert wiederkehrende oder strukturelle Störungen, führt Root-Cause-Analysen durch, steuert Problemlösungen und stellt Workarounds bereit. Bekämpft Ursachen statt Symptome — verhindert, dass dieselben Störungen immer wieder auftreten.",
+  projektleitung:"Plant und steuert Service-Entwicklungsprojekte, koordiniert Ressourcen und Lieferanten, sichert Termine und Qualität, liefert die Projektartefakte. Bringt Bau und Beschaffung termin- und budgetgerecht ans Ziel.",
+  betriebsteam:"Führt alle laufenden Betriebsaufgaben aus — von Routine bis Infrastruktur: Monitoring, Standard-Changes, Deployment, Systempflege, tiefe Diagnosen. Hält den Service täglich am Laufen und sichert Stabilität und Verfügbarkeit.",
+  service_support_team:"Bearbeitet Nutzeranfragen und Incidents im 1st/2nd Level, sorgt für schnelle Wiederherstellung; Bindeglied zwischen Anwendern, Betrieb und Problemmanagement. Erste Hilfe für Nutzer; hält Störungen klein und Anwender handlungsfähig.",
+  projektteam:"Fachlich-technisches Team für Entwicklung, Konfiguration, Tests und Dokumentation; unterstützt Übergabe und Betriebsbefähigung. Die „Hände“, die im Projekt bauen und konfigurieren.",
+  queue_koordinator:"Überwacht das Ticketaufkommen, verteilt und routet Tickets an die richtigen Gruppen und sichert Priorisierung und SLA-Einhaltung. Sorgt für sauberen, schnellen Ticketfluss zur richtigen Stelle.",
+  first_level_agent:"Erste Anlaufstelle für Nutzer: nimmt Incidents/Requests auf, löst Standardfälle, dokumentiert sauber und eskaliert fachgerecht an den 2nd Level. Löst den Großteil der Fälle schnell und entlastet die höheren Support-Level.",
+  second_level_agent:"Bearbeitet komplexe Störungen und fachtechnische Anfragen, führt tiefere Analysen durch und stellt Lösungen bereit; kooperiert mit Betrieb, Herstellern und Problemmanagement. Knackt die Fälle, die der 1st Level nicht lösen kann.",
+  testmanagement:"Plant, organisiert und verantwortet Tests (Integration, Abnahme, Regression) während Entwicklung und Transition; sichert Qualität und Betriebsreife. Stellt sicher, dass nur Funktionierendes live geht.",
+  architektur:"Definiert technische Standards, Zielarchitekturen und Integrationsanforderungen, bewertet Designvarianten und Risiken, sichert technische Konsistenz und Zukunftsfähigkeit. Hält Lösungen technisch konsistent und zukunftsfähig statt zu Insellösungen.",
+  lieferant:"Stellt externe System-, Software- oder Infrastrukturkomponenten bereit oder entwickelt spezifische Anpassungen; wird bei Build, Fehleranalyse und Komponentensupport eingebunden. Bringt externe Leistung und Know-how, wo intern nicht vorhanden.",
+  operations_manager:"Verantwortet den stabilen, sicheren Betrieb der Infrastruktur- und Anwendungs-Services (Netze, Server, Cloud, Fachverfahren, Software), koordiniert die Betriebsteams und sichert SLA-/Policy-Einhaltung (AL B&C + AL App, ständige SOR-Mitglieder). Stellt sicher, dass technische Basis und Anwendungen tragfähig sind, und bringt die Betriebsperspektive in die SOR-Entscheidungen.",
+  dpm:""
 };
 // Rollen-Glossar fuer das Overlay: gruppiert/eingefaerbt nach den 6 Figuren-Kategorien
 // (Farbe = Filamentfarbe der Figuren). Deckt alle ROLLEN-Eintraege ab.
@@ -1292,10 +1305,7 @@ const ARTEFAKTE = {
     warum:"Es beschleunigt den Support, sichert konsistente Antworten und entlastet die höheren Support-Level."},
   A14:{name:"Service-Review-Dokument", phase:"review",
     was:"Verantwortlich: Service-Owner. Bewertung über 4 Dimensionen mit Leitfrage — Leistungserbringung (liefert der Service den erwarteten Nutzen?), Betriebsstabilität (läuft er störungsarm und beherrschbar?), Nutzerzufriedenheit (wie bewerten die Nutzer den Service?) und Zukunftsfähigkeit (ist er mittelfristig tragfähig?). Daraus eine Handlungsempfehlung: Weiterbetrieb (ggf. mit Monitoring-Fokus) · Änderung als Normal-Change · Änderung als Major-Change.",
-    warum:"Es ermöglicht eine fundierte Entscheidung, ob der Service unverändert weiterbetrieben werden kann oder ob Änderungen erforderlich sind — die Grundlage für die SOR-Bewertung."},
+    warum:"Es ermöglicht eine fundierte Entscheidung, ob der Service unverändert weiterbetrieben werden kann oder ob Änderungen erforderlich sind — die Grundlage für die SOR-Bewertung."}
-  A15:{name:"DPM-Rücklauf", phase:"review",
-    was:"Die Übergabe an den Demand-Lifecycle — Variante A: Neuer Demand (Redesign/Erweiterung) oder Variante B: Retirement-Plan / Decommissioning-Auftrag (Stilllegung).",
-    warum:"Es schließt den Lebenszyklus: größere Änderungen oder das Ende eines Service laufen kontrolliert über den Demand-Lifecycle, nicht „nebenbei“."}
 };
 // Welche Station erzeugt welches A-Artefakt (Choice-Schritt -> Aufnahme in die Akte).
 const STATION_ARTEFAKT = {
@@ -1303,7 +1313,7 @@ const STATION_ARTEFAKT = {
   tr_06:"A6", tr_07:"A7", tr_08:"A5",
   op_06:"A9",
   sp_02:"A13", sp_07:"A10", sp_09:"A11", sp_11:"A12",
-  rv_02:"A14", rv_05:"A15"
+  rv_01:"A14"
 };
 // Gate erzeugt Artefakt (beim Vorwaerts-Durchschreiten).
 const GATE_PRODUCES = { tr_12:"A8" };

04_Tablet-Quiz/app/sw.js

@@ -1,5 +1,5 @@
 /* Service Worker — SLC-Workshop Companion (App-Shell, offline-first) */
-const CACHE = "slc-companion-v38";
+const CACHE = "slc-companion-v39";
 const SHELL = ["./", "index.html", "manifest.webmanifest", "icon.svg"];
 // Action-Card-Grafiken (cards/s<service>-c<change>.png) fuer Offline vorab cachen (alle 24).
 const CARDS = [];