From ffc66f1f58c63a7000de0485447d7ef58afc6f40 Mon Sep 17 00:00:00 2001 From: breitenbach76 Date: Wed, 10 Jun 2026 11:34:56 +0200 Subject: [PATCH 1/2] Rollenbeschreibungen aus PDF-Steckbriefen eingetragen (15 Rollen) 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 --- 04_Tablet-Quiz/app/index.html | 21 +++++++++++++++++---- 04_Tablet-Quiz/app/sw.js | 2 +- 2 files changed, 18 insertions(+), 5 deletions(-) diff --git a/04_Tablet-Quiz/app/index.html b/04_Tablet-Quiz/app/index.html index ca8d844..5673afa 100644 --- a/04_Tablet-Quiz/app/index.html +++ b/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:"", - projektleitung:"", betriebsteam:"", service_support_team:"", projektteam:"", - queue_koordinator:"", first_level_agent:"", second_level_agent:"", - testmanagement:"", architektur:"", lieferant:"", operations_manager:"", dpm:"" + 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.", + 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.", + 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.", + 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. diff --git a/04_Tablet-Quiz/app/sw.js b/04_Tablet-Quiz/app/sw.js index 4fa46e1..bc2ea17 100644 --- a/04_Tablet-Quiz/app/sw.js +++ b/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-c.png) fuer Offline vorab cachen (alle 24). const CARDS = []; From 895dbce0722571c092dffa9b7aedb30b68e0458b Mon Sep 17 00:00:00 2001 From: breitenbach76 Date: Wed, 10 Jun 2026 13:31:56 +0200 Subject: [PATCH 2/2] ... --- 04_Tablet-Quiz/app/index.html | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/04_Tablet-Quiz/app/index.html b/04_Tablet-Quiz/app/index.html index 5673afa..b134627 100644 --- a/04_Tablet-Quiz/app/index.html +++ b/04_Tablet-Quiz/app/index.html @@ -1305,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."}, - 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“."} + 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."} }; // Welche Station erzeugt welches A-Artefakt (Choice-Schritt -> Aufnahme in die Akte). const STATION_ARTEFAKT = { @@ -1316,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" };