diff --git a/00_Konzept/review-phase_arbeitsstand-frank.md b/00_Konzept/review-phase_arbeitsstand-frank.md deleted file mode 100644 index 3b70fd0..0000000 --- a/00_Konzept/review-phase_arbeitsstand-frank.md +++ /dev/null @@ -1,59 +0,0 @@ -# Review-Phase — Arbeitsstand (Vorschlag Frank) - -**Status:** Arbeitsstand **für den Workshop** · **nicht** im Blueprint-YAML · **nicht** -kanonisch ins Konzept übernommen (vor Übernahme mit **Michael** rückkoppeln). -**Quelle:** E-Mail Frank · **Logik:** Change-Enablement (analog YASM). - -> **Wo schon übernommen (Workshop-Material):** Companion-App (`04_Tablet-Quiz/app/`, -> Review = rv_01–rv_05), `01_3D-Druck/materialliste.md` (**36** Station-Pucks / **39** -> Positionen) und die **`board-layout`-Skizze**. **Bewusst NICHT geändert:** -> `service-lifecycle_*.yaml` (Single Source of Truth) und das **kanonische Konzept** -> (`README_konzept.md`, Phasen-Tabelle zeigt weiter 6/40) — vor Übernahme mit -> **Michael** abstimmen. - -## Die 5 vorgeschlagenen Aktivitäten - -1. **Durchführen von Service-Reviews** - - KPIs & Monitoring auswerten, Problems & Incidents auswerten, Kundenfeedback sammeln/einholen - - Bewerten der zugrunde liegenden Infrastruktur - - Service-Review-Dokument ausfüllen -2. **Bewertung der Review-Ergebnisse** - - RFC erstellen (Normal- bzw. Major-Change) - - Berichte (wenn nötig) an die SOR weiterleiten - - Ergebnisse in der SOR ganzheitlich bewerten -3. **Definieren von Service-Änderungen** - - passende Änderungsvorschläge formulieren - - Vorschläge bewerten & konsolidieren - - ausgewählte Änderung beschreiben -4. **Starten von Service-Änderungen** - - Normal Change: Planung der Umsetzung - - Major Change: Routing klären (RUN / DPM / MB?) - - Major Change: „Change-Steckbrief" ausfüllen & weiterleiten -5. **Implementieren von Service-Änderungen** - - Normal & Major (Weg RUN): durchführen, dokumentieren, abschließen durch SO - - Major (Weg DPM): Change geht durch Demand- & Projektprozess - - Major (Weg MB): direkt in den Projektprozess oder Durchführung im RUN - -## Abbildung gegenüber dem bisherigen Stand (rv_01–rv_06) - -| bisher | neu (Frank) | -|--------|-------------| -| rv_01 KPIs/RCA · rv_02 Performance-Review | 1. Service-Reviews durchführen | -| rv_03 SOR-Review | 2. Bewertung (RFC, SOR) | -| rv_04 Service Improvement | 3. Änderungen definieren | -| rv_05 Redesign → DPM | 4./5. Starten/Implementieren (Routing) | -| rv_06 Außerbetriebnahme | *— nicht explizit abgedeckt* | - -## Offene Punkte (vor Konzept-/YAML-Übernahme klären) - -- **„MB"** als dritter Routing-Weg ist **nicht definiert** (RUN und DPM sind klar). -- **Retirement / Außerbetriebnahme** (bisher rv_06) fehlt — bewusst entfallen oder - unter „Service-Änderung" subsumiert? -- **RACI + Quizfragen** wurden für die App **abgeleitet** (Franks Entwurf nennt nur - die Aktivitäten) — fachlich gegenprüfen. -- **Vokabular** („RFC", „Change-Steckbrief", Routing RUN/DPM/MB) mit den anderen - Phasen und der Rollen-/Gate-YAML abgleichen. -- **Konsequenz Board:** Bahn = **39 statt 40** Positionen (36 Station-Pucks + 3 Gate). - In Workshop-Material (App, materialliste, board-layout) bereits nachgezogen; alle - Pucks sind identische Blanks → faktisch nur **1 Puck weniger / als Reserve**. Das - **kanonische Konzept (`README_konzept.md`) zeigt noch 40** — nach Michael-Freigabe nachziehen. diff --git a/01_3D-Druck/board-layout.svg b/01_3D-Druck/board-layout.svg index 0186c96..5e565d3 100644 --- a/01_3D-Druck/board-layout.svg +++ b/01_3D-Druck/board-layout.svg @@ -1,8 +1,8 @@ -Service-Lifecycle — Board-Layout (39 Pucks) -36 Aktivitaeten + 3 Gate-Pucks · 1 Puck = Ø100 mm · lose Bahn, Sequenz links nach rechts +Service-Lifecycle — Board-Layout (40 Pucks) +37 Aktivitaeten + 3 Gate-Pucks · 1 Puck = Ø100 mm · lose Bahn, Sequenz links nach rechts DESIGN 4 Pucks @@ -428,7 +428,7 @@ REVIEW -5 Pucks +6 Pucks @@ -439,7 +439,7 @@ rv_01 -Service-Reviews durchf. +Taktische RCA + KPIs @@ -451,7 +451,7 @@ rv_02 -Bewertung d. Ergebnisse +Performance & Improvement @@ -463,7 +463,7 @@ rv_03 -Aenderungen definieren +SOR Periodischer Review @@ -475,7 +475,7 @@ rv_04 -Aenderungen starten +Service Improvement @@ -487,12 +487,24 @@ rv_05 -Aenderungen umsetzen +Redesign / Erweiterung + + + + + + + + + + +rv_06 +Ausserbetriebnahme Betriebs-Loop - -zurueck in DPM -rv_05 Redesign / rv_06 Retirement + +zurueck in DPM +rv_05 Redesign / rv_06 Retirement Gate-Puck (rot, Etikett G1/G2/G3 + Icon) diff --git a/01_3D-Druck/gen_board_layout.py b/01_3D-Druck/gen_board_layout.py index ed7e9b0..eb0d422 100644 --- a/01_3D-Druck/gen_board_layout.py +++ b/01_3D-Druck/gen_board_layout.py @@ -52,12 +52,13 @@ PHASES = [ ("sp_11", "RCA & Workaround", False), ]), ("REVIEW", "#8E63B5", [ - ("rv_01", "Service-Reviews durchf.", False), - ("rv_02", "Bewertung d. Ergebnisse", False), - ("rv_03", "Aenderungen definieren", False), - ("rv_04", "Aenderungen starten", False), - ("rv_05", "Aenderungen umsetzen", False), - ]), # Arbeitsstand Frank (Change-Enablement); nicht im YAML/Konzept + ("rv_01", "Taktische RCA + KPIs", False), + ("rv_02", "Performance & Improvement", False), + ("rv_03", "SOR Periodischer Review", False), + ("rv_04", "Service Improvement", False), + ("rv_05", "Redesign / Erweiterung", False), + ("rv_06", "Ausserbetriebnahme", False), + ]), ] # Layout-Parameter @@ -131,9 +132,9 @@ svg.append('') # Titel svg.append(f'' - f'Service-Lifecycle — Board-Layout (39 Pucks)') + f'Service-Lifecycle — Board-Layout (40 Pucks)') svg.append(f'' - f'36 Aktivitaeten + 3 Gate-Pucks · 1 Puck = Ø{TILE_MM} mm · ' + f'37 Aktivitaeten + 3 Gate-Pucks · 1 Puck = Ø{TILE_MM} mm · ' f'lose Bahn, Sequenz links nach rechts') row_y = {} diff --git a/01_3D-Druck/materialliste.md b/01_3D-Druck/materialliste.md index ea43d7e..ebea60e 100644 --- a/01_3D-Druck/materialliste.md +++ b/01_3D-Druck/materialliste.md @@ -32,7 +32,7 @@ Stand: 2026-06-04 · Maße in mm · Mengen für **ein** Workshop-Set. | Figurenplätze | **7 Mulden** Ø 22 × 1,5 mm (Einführ-Fase), auf Kreis r 33 (Ø 66) | | Etikettenmulde | mittig Ø 37,5 × 0,3 mm (Rundetikett Ø37; Puck-Rand bleibt sichtbar) | | Farbe | je Phase (blau/orange/grün/teal/lila) | -| Menge | **36** (eine je Aktivität) — Druck von 37 empfohlen: 1 Blank als Reserve | +| Menge | **37** (eine je Aktivität) | | Material | PLA, Infill 15 % | | Druckzeit | ~1,3 h/Puck | | Datei | `openscad/puck.scad` | @@ -45,16 +45,11 @@ Stand: 2026-06-04 · Maße in mm · Mengen für **ein** Workshop-Set. | Transition | orange | tr_02–tr_08, tr_10, tr_11 | 9 | | Operation | grün | op_01–op_07 | 7 | | Support | teal | sp_01–sp_11 | 11 | -| Review | lila | rv_01–rv_05 | 5 | -| | | **Σ Station-Pucks** | **36** | +| Review | lila | rv_01–rv_06 | 6 | +| | | **Σ Station-Pucks** | **37** | Die 3 Gates (tr_01, tr_09, tr_12) sind **Gate-Pucks** (gleiches Teil, rot, §2) → 3 Stück. -**Bahn gesamt = 36 + 3 = 39 Positionen.** - -> **Arbeitsstand Review (Workshop):** Die Review-Phase nutzt **5 Aktivitäten** nach -> Frank (Change-Enablement) statt bisher 6 — daher 36 statt 37 Station-Pucks. Details -> + offene Punkte: [`../00_Konzept/review-phase_arbeitsstand-frank.md`](../00_Konzept/review-phase_arbeitsstand-frank.md). -> Noch **nicht** im Blueprint-YAML / kanonischen Konzept (Michael-Freigabe ausstehend). +**Bahn gesamt = 37 + 3 = 40 Positionen.** Die Pucks werden zu einer **linearen Bahn** ausgelegt (kein Ring), bei Platzmangel mäandrierend. Als optische Linie + Halt empfiehlt sich eine **flache Unterlage/Matte** @@ -156,19 +151,19 @@ linearen Puck-Bahn — das **Design-Segment ist der Start** vor dem ersten Puck. | Teil | Menge | Datei | |------|------:|-------| -| Station-Puck | 36 (+1 Reserve) | `openscad/puck.scad` (Phasenfarbe) | +| Station-Puck | 37 | `openscad/puck.scad` (Phasenfarbe) | | Gate-Puck | 3 | `openscad/puck.scad` (rot) | | Phasen-Ring-Segment | 5 | `openscad/phasen-ring-.scad` (je Phasenfarbe) | | Aktiv-Feld (RACI-Fläche) | 1 | `openscad/aktiv-feld.scad` | | Rollen-Figuren (Einzel) | 32 | 16 Rollen × 2 | | Team-Sonderfiguren | 6 | 3 Teams × 2 | | Entscheidungs-Chips | 12 | (einfache Münze + Gravur) | -| Rundetiketten Ø37 | 39 | via Generator aus YAML (ID + Phasenfarbe); ablösbar bevorzugt | +| Rundetiketten Ø37 | 40 | via Generator aus YAML (ID + Phasenfarbe); ablösbar bevorzugt | ## Kritische Maße & Passungen (bitte prüfen) - **Puck = einziges Bahn-Teil** (Ø 100 × 6). Station vs. Gate nur über Filamentfarbe - + Etikett — **ein STL, 39× drucken** (36 Phasen + 3 rot; +1 Blank als Reserve). + + Etikett — **ein STL, 40× drucken** (37 Phasen + 3 rot). - **Figuren-Mulde Ø 22, Tiefe 1,5** für Sockel **Ø 20** (reinstellbar, Fase als Einführhilfe). 7 Mulden auf Kreis r 33. - **Etikettenmulde Ø 37,5 × 0,3** — Rundetikett Ø37 (Puck-Rand bleibt sichtbar, diff --git a/04_Tablet-Quiz/README.md b/04_Tablet-Quiz/README.md index f9cbbdf..4a7170d 100644 --- a/04_Tablet-Quiz/README.md +++ b/04_Tablet-Quiz/README.md @@ -6,9 +6,7 @@ > (offline-/kioskfähig). Sie führt den kompletten Flow durch (Action Card → > Startpunkt → optionale Tour → Station: Diskussion/Quiz/Auflösung → Debrief mit > **Markdown-/JSON-Export**). Inhalte (40 Stationen, 45 Quizfragen, 6 Use-Cases) -> sind derzeit in `app/index.html` eingebettet. Die **finalen Action-Card-Grafiken** -> (Freiburg-digital-Layout) liegen in `app/cards/` (`s-c.png`, 29/30 — -> `s0-c0` „Open Source von oben!" fehlt noch → Text-Fallback). **Deployment:** statisch, siehe +> sind derzeit in `app/index.html` eingebettet. **Deployment:** statisch, siehe > [`app/DEPLOY.md`](app/DEPLOY.md). **Lokal testen:** `python -m http.server 8099 > --directory 04_Tablet-Quiz/app` (oder Preview-Config `.claude/launch.json`). diff --git a/04_Tablet-Quiz/app/cards/s0-c1.png b/04_Tablet-Quiz/app/cards/s0-c1.png deleted file mode 100644 index ac25b8f..0000000 Binary files a/04_Tablet-Quiz/app/cards/s0-c1.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s0-c2.png b/04_Tablet-Quiz/app/cards/s0-c2.png deleted file mode 100644 index 255d426..0000000 Binary files a/04_Tablet-Quiz/app/cards/s0-c2.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s0-c3.png b/04_Tablet-Quiz/app/cards/s0-c3.png deleted file mode 100644 index d7a7587..0000000 Binary files a/04_Tablet-Quiz/app/cards/s0-c3.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s0-c4.png b/04_Tablet-Quiz/app/cards/s0-c4.png deleted file mode 100644 index 031930c..0000000 Binary files a/04_Tablet-Quiz/app/cards/s0-c4.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s1-c0.png b/04_Tablet-Quiz/app/cards/s1-c0.png deleted file mode 100644 index 0aa579e..0000000 Binary files a/04_Tablet-Quiz/app/cards/s1-c0.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s1-c1.png b/04_Tablet-Quiz/app/cards/s1-c1.png deleted file mode 100644 index 270c925..0000000 Binary files a/04_Tablet-Quiz/app/cards/s1-c1.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s1-c2.png b/04_Tablet-Quiz/app/cards/s1-c2.png deleted file mode 100644 index 692f60c..0000000 Binary files a/04_Tablet-Quiz/app/cards/s1-c2.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s1-c3.png b/04_Tablet-Quiz/app/cards/s1-c3.png deleted file mode 100644 index b212aca..0000000 Binary files a/04_Tablet-Quiz/app/cards/s1-c3.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s1-c4.png b/04_Tablet-Quiz/app/cards/s1-c4.png deleted file mode 100644 index a7bfce7..0000000 Binary files a/04_Tablet-Quiz/app/cards/s1-c4.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s2-c0.png b/04_Tablet-Quiz/app/cards/s2-c0.png deleted file mode 100644 index ff004e9..0000000 Binary files a/04_Tablet-Quiz/app/cards/s2-c0.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s2-c1.png b/04_Tablet-Quiz/app/cards/s2-c1.png deleted file mode 100644 index afa79a4..0000000 Binary files a/04_Tablet-Quiz/app/cards/s2-c1.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s2-c2.png b/04_Tablet-Quiz/app/cards/s2-c2.png deleted file mode 100644 index cc77016..0000000 Binary files a/04_Tablet-Quiz/app/cards/s2-c2.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s2-c3.png b/04_Tablet-Quiz/app/cards/s2-c3.png deleted file mode 100644 index 3a7fe04..0000000 Binary files a/04_Tablet-Quiz/app/cards/s2-c3.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s2-c4.png b/04_Tablet-Quiz/app/cards/s2-c4.png deleted file mode 100644 index c7c44bd..0000000 Binary files a/04_Tablet-Quiz/app/cards/s2-c4.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s3-c0.png b/04_Tablet-Quiz/app/cards/s3-c0.png deleted file mode 100644 index ef74d4f..0000000 Binary files a/04_Tablet-Quiz/app/cards/s3-c0.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s3-c1.png b/04_Tablet-Quiz/app/cards/s3-c1.png deleted file mode 100644 index 868ee1b..0000000 Binary files a/04_Tablet-Quiz/app/cards/s3-c1.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s3-c2.png b/04_Tablet-Quiz/app/cards/s3-c2.png deleted file mode 100644 index e5c04d3..0000000 Binary files a/04_Tablet-Quiz/app/cards/s3-c2.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s3-c3.png b/04_Tablet-Quiz/app/cards/s3-c3.png deleted file mode 100644 index 1e92d29..0000000 Binary files a/04_Tablet-Quiz/app/cards/s3-c3.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s3-c4.png b/04_Tablet-Quiz/app/cards/s3-c4.png deleted file mode 100644 index 2b55f60..0000000 Binary files a/04_Tablet-Quiz/app/cards/s3-c4.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s4-c0.png b/04_Tablet-Quiz/app/cards/s4-c0.png deleted file mode 100644 index e7f9924..0000000 Binary files a/04_Tablet-Quiz/app/cards/s4-c0.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s4-c1.png b/04_Tablet-Quiz/app/cards/s4-c1.png deleted file mode 100644 index 92c49c8..0000000 Binary files a/04_Tablet-Quiz/app/cards/s4-c1.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s4-c2.png b/04_Tablet-Quiz/app/cards/s4-c2.png deleted file mode 100644 index bde7e0c..0000000 Binary files a/04_Tablet-Quiz/app/cards/s4-c2.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s4-c3.png b/04_Tablet-Quiz/app/cards/s4-c3.png deleted file mode 100644 index 3d21db2..0000000 Binary files a/04_Tablet-Quiz/app/cards/s4-c3.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s4-c4.png b/04_Tablet-Quiz/app/cards/s4-c4.png deleted file mode 100644 index 5e924cb..0000000 Binary files a/04_Tablet-Quiz/app/cards/s4-c4.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s5-c0.png b/04_Tablet-Quiz/app/cards/s5-c0.png deleted file mode 100644 index 0535b9e..0000000 Binary files a/04_Tablet-Quiz/app/cards/s5-c0.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s5-c1.png b/04_Tablet-Quiz/app/cards/s5-c1.png deleted file mode 100644 index b4e46ea..0000000 Binary files a/04_Tablet-Quiz/app/cards/s5-c1.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s5-c2.png b/04_Tablet-Quiz/app/cards/s5-c2.png deleted file mode 100644 index 1df396b..0000000 Binary files a/04_Tablet-Quiz/app/cards/s5-c2.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s5-c3.png b/04_Tablet-Quiz/app/cards/s5-c3.png deleted file mode 100644 index b7319d8..0000000 Binary files a/04_Tablet-Quiz/app/cards/s5-c3.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/cards/s5-c4.png b/04_Tablet-Quiz/app/cards/s5-c4.png deleted file mode 100644 index ab3bb6a..0000000 Binary files a/04_Tablet-Quiz/app/cards/s5-c4.png and /dev/null differ diff --git a/04_Tablet-Quiz/app/index.html b/04_Tablet-Quiz/app/index.html index 09dbfb5..94058c5 100644 --- a/04_Tablet-Quiz/app/index.html +++ b/04_Tablet-Quiz/app/index.html @@ -245,11 +245,12 @@ const TOUR = { sp_09: "Ein Incident bleibt ungelöst – eine strukturelle Ursache wird vermutet. Der Problem Manager legt einen Problem Record an.", sp_10: "Mehrere ähnliche Speicher-Fehler häufen sich → sie werden geclustert und gebündelt als Problem Record erfasst.", sp_11: "Ursachensuche: Das Speicherproblem entsteht durch einen Timeout unter Last. Es gibt einen Workaround (Eintrag in die Wissensdatenbank) und die Entscheidung, dass ein Change nötig ist.", - rv_01: "Im Service-Review werden die Betriebsdaten des Beteiligungs-Moduls ausgewertet: KPIs, die gehäuften Speicher-Incidents, Kundenfeedback und die Infrastruktur — alles fließt ins Service-Review-Dokument.", - rv_02: "Die Ergebnisse werden bewertet: Der wiederkehrende Speicher-Fehler rechtfertigt einen RFC. Der Bericht geht an die SOR, die ganzheitlich bewertet.", - rv_03: "Auf Basis der Bewertung werden Änderungsvorschläge formuliert (z. B. Last-/Timeout-Optimierung), konsolidiert und die ausgewählte Änderung beschrieben.", - rv_04: "Die Änderung wird gestartet. Es ist eine überschaubare Anpassung → Normal-Change-Logik: Umsetzung planen. (Wäre sie grundlegend, würde hier das Routing RUN/DPM/MB geklärt und ein Change-Steckbrief erstellt.)", - rv_05: "Die Änderung wird umgesetzt: Im Weg RUN führt der Service Owner sie durch, dokumentiert und schließt sie ab. Der Service läuft verbessert weiter — der Kreis schließt sich." + rv_01: "Im Review werden Support-KPIs und wiederkehrende Fälle ausgewertet – die Speicher-Probleme tauchen klar als Muster auf.", + rv_02: "Der Service wird über vier Dimensionen per Ampel bewertet (Leistung, Stabilität, Nutzerzufriedenheit, Zukunftsfähigkeit). Empfehlung in unserem Fall: IMPROVEMENT.", + rv_03: "Die SOR sichtet das Review und entscheidet. In unserem Beispiel: VERBESSERUNG NÖTIG (klein) → rv_04. (Alternativen wären: weiter wie bisher, Redesign rv_05 oder Außerbetriebnahme rv_06.)", + rv_04: "Die kleine Verbesserung wird geplant und umgesetzt – z. B. die Last- und Timeout-Optimierung beim Speichern. Sie fließt zurück in den laufenden Betrieb (Operation). Damit schließt sich der Kreis.", + rv_05: "In unserem Beispiel NICHT gewählt. Wäre die Änderung grundlegend (z. B. eine komplett neue Beteiligungsplattform), würde sie hier als neuer Demand an den Demand-Lifecycle übergeben – der Service liefe quasi neu durch Design und Transition.", + rv_06: "Ebenfalls NICHT gewählt. Würde das Modul z. B. wegen eines Nachfolgesystems abgeschaltet, plant die SOR hier die kontrollierte Stilllegung (Retirement-Plan)." } }; @@ -269,7 +270,7 @@ const ROLLEN = { projektteam:"Projektteam", queue_koordinator:"Queue Koordinator", first_level_agent:"1st Level Agent", second_level_agent:"2nd Level Agent", testmanagement:"Testmanagement", architektur:"Architektur", - lieferant:"Lieferant", operations_manager:"Betrieb (AL B&C / AL App)", dpm:"Demand Portfolio Manager" + lieferant:"Lieferant", operations_manager:"Betrieb (AL B&C / AL App)" }; const PHASEN = { design:{label:"Design", color:"var(--design)"}, @@ -290,56 +291,56 @@ const USE_CASES = [ { service:"Zentrale VDI (Virtual-Desktop-Infrastructure)", desc:"Bereitstellung von virtuellen Windows-Desktops über das interne Rechenzentrum.", changes:[ - {titel:"Open Source von oben!", text:"Der OB gibt die Richtung vor: Die proprietäre VDI-Lösung soll auf eine Open-Source-Alternative (OpenStack + Thin-Client) umgestellt werden."}, - {titel:"Bauamt will mehr!", text:"Das Bauamt fordert ein neues GIS-Fachverfahren, das künftig direkt auf dem virtuellen Desktop laufen soll."}, - {titel:"Tapetenwechsel", text:"Die Stadt bekommt ein neues Logo — der Desktop-Hintergrund aller virtuellen Arbeitsplätze muss angepasst werden."}, - {titel:"Quartalspflege", text:"Das turnusmäßige Firmware-Update der VDI-Host-Hypervisoren steht an — im Standard-Change-Katalog längst hinterlegt."}, - {titel:"Blackout!", text:"Ein Stromausfall reißt ein ganzes VDI-Host-Cluster aus dem Betrieb — die Sitzungen müssen sofort auf ein Backup-Cluster migriert werden."} + "Strategische IT-Richtlinie auf Geheiß des OB, die den Umstieg von einer proprietären VDI-Lösung auf eine Open-Source-Alternative (z. B. OpenStack + Thin-Client) vorschreibt.", + "Das Bauamt fordert die Einführung einer neuen Fachsoftware (z. B. ein GIS-Tool), die auf dem virtuellen Desktop zugänglich sein soll.", + "Rebranding des Logos der Stadt Freiburg: Anpassung der Desktop-Hintergrundgrafik erforderlich.", + "Quartalsweises Update der VDI-Host-Hypervisor-Firmware – im Standard-Change-Katalog verankert.", + "Stromausfall: Ausfall eines VDI-Host-Clusters, der die sofortige Migration der Sitzungen auf ein Backup-Cluster erfordert." ]}, { service:"Managed VPN-Access Service", desc:"Zentral verwalteter VPN-Dienst, der Mitarbeitenden der Fachämter sicheren Remote-Zugriff auf interne Systeme (Intranet, Fachanwendungen, Datenbanken) ermöglicht.", changes:[ - {titel:"Brüssel ruft!", text:"Eine neue EU-weite IT-Sicherheitsverordnung zwingt dazu, die gesamte VPN-Architektur neu aufzustellen."}, - {titel:"Schlüsselpflicht", text:"Das Hauptpersonalamt verlangt eine neue Authentifizierung: FIDO2-Security-Keys werden für alle verpflichtend."}, - {titel:"Heimvorteil", text:"Ein neues Intranet-Portal soll in die Split-Tunnel-Liste, damit Mitarbeitende auch aus dem Homeoffice darauf zugreifen."}, - {titel:"Monatsroutine", text:"Das monatliche Firmware-Update der VPN-Appliance steht an — als Standard-Change bereits freigegeben."}, - {titel:"Gephisht!", text:"Ein erfolgreicher Phishing-Angriff hat eine VPN-Zertifikatskette kompromittiert — sofort sperren und neu ausstellen."} + "EU-weite neue Datenschutz- oder IT-Sicherheitsverordnung, die die gesamte VPN-Architektur neu gestaltet.", + "HPA fordert die Einführung einer neuen Authentifizierungsmethode (z. B. verpflichtende Nutzung von FIDO2-Security-Keys).", + "HPA möchte eine interne Anwendung (z. B. ein neues Intranet-Portal) in die Split-Tunnel-Liste ergänzen, weil Nutzer nun von zu Hause darauf zugreifen müssen.", + "Regelmäßige (monatliche) Firmware-Updates der VPN-Appliance, bereits im Change-Katalog als Standard-Change definiert.", + "Erfolgreicher Phishing-Angriff: Eine VPN-Benutzerzertifikatskette ist kompromittiert – sofortige Sperrung und Neu-Ausstellung der Zertifikate erforderlich." ]}, { service:"Online-Bürgerportal für Meldungen & Anträge", desc:"Zentrales Web-Portal, über das Bürger*innen Meldungen (z. B. Straßenreparatur, Lärm) und Anträge (z. B. Baugenehmigung, Personalausweis) digital einreichen und den Status verfolgen.", changes:[ - {titel:"Mitreden, Pflicht!", text:"Ein neues Landesgesetz schreibt digitale Bürgerbeteiligung vor — das Portal muss um komplette Beteiligungs-Module erweitert werden."}, - {titel:"Ratsbeschluss!", text:"Der Gemeinderat will einen neuen Meldetyp „Klimaschutz“ — das Umweltamt braucht dafür eigene Formulare und Workflows."}, - {titel:"Rotstift gefragt", text:"Der Bürgerservice meldet einen Rechtschreibfehler in einem statischen Hinweistext, der korrigiert werden muss."}, - {titel:"Patchday", text:"Das monatliche Sicherheits-Patch des Webservers (Apache/Nginx) steht an — im Change-Katalog definiert."}, - {titel:"Lücke im Formular!", text:"In einem Eingabe-Formular wird eine kritische XSS-Schwachstelle entdeckt — ein Hotfix muss sofort raus."} + "Neues Landesgesetz zur digitalen Bürgerbeteiligung (z. B. verpflichtende Online-Beteiligungs-Tools für größere Baumaßnahmen) → komplette Erweiterung des Portals um Beteiligungs-Module.", + "Neuer Gemeinderat fordert Einführung eines neuen Meldetyps (z. B. „Klimaschutz-Meldungen“) durch das Umweltamt – neue Formulare und Workflows erforderlich.", + "Bürgerservice meldet Rechtschreibfehler in einem statischen Hinweis-Text, der geändert werden muss.", + "Monatliches Sicherheits-Patch-Update des Web-Servers (Apache/Nginx) – bereits im Change-Katalog definiert.", + "Entdeckung einer kritischen XSS-Lücke in einem Eingabe-Formular, die eine sofortige Hot-Fix-Implementierung nötig macht." ]}, { service:"Zentrales Dokumenten-Management-System (DMS)", desc:"Elektronisches Archiv, das alle ein- und ausgehenden Dokumente (PDF, Scans, E-Mails) zentral speichert, versioniert und revisionssicher archiviert.", changes:[ - {titel:"Datendiät", text:"Eine DSGVO-Ergänzung zur Datenminimierung erzwingt die komplette Neugestaltung von Metadaten-Modell und Archivierungs-Policies."}, - {titel:"Akten-Zuwachs", text:"Ein neues Fachverfahren zieht ein und braucht eigene Dokumentenklassen und Workflows im DMS."}, - {titel:"Dropdown-Wunsch", text:"Das Finanzamt bittet um ein neues Metadaten-Feld „Kostenstelle“ als Auswahlliste."}, - {titel:"Versionspflege", text:"Das quartalsweise Update der DMS-Software (Sicherheits- und Funktions-Patches) steht an."}, - {titel:"Ransomware!", text:"Alarm: Dokumente werden verdächtig verschlüsselt — Storage sofort isolieren und aus den letzten Snapshots wiederherstellen."} + "EU-DSGVO-Ergänzung (z. B. neue Vorgaben zur Daten-Minimierung) → komplette Neugestaltung des Metadaten-Modells und der Archivierungs-Policies.", + "Einführung eines neuen Fachverfahrens (z. B. „Bürgerbeteiligungs-Verfahren“), das eigene Dokumenten-Klassen und Workflows erfordert.", + "Rückmeldung aus dem Finanzamt: Ein Metadaten-Feld (z. B. neues Dropdown-Feld „Kostenstelle“) muss angepasst werden.", + "Quartalsweises Update der DMS-Software-Version (Sicherheits- und Funktions-Patches) – im Standard-Change-Katalog.", + "Ransomware-Alarm: Verdächtige Verschlüsselung von Dokumenten – sofortige Isolation des Storage-Systems und Wiederherstellung aus letzten Snapshots." ]}, { service:"Kommunales GIS-Portal (Geoinformations-System)", desc:"Web-basiertes Karten- und Analyse-Portal, das Fachämtern (Bau, Umwelt, Verkehr) räumliche Daten (Flurstücke, Infrastruktur, Umweltzonen) und bearbeitbare Layer bereitstellt.", changes:[ - {titel:"Norm-Zwang", text:"Eine bundesweite Vorgabe zu EU-Standards erzwingt die komplette Migration des GIS-Stacks auf konforme Services und Datenmodelle."}, - {titel:"Klimarisiko im Blick", text:"Das Umweltamt will ein neues Analyse-Modul „Klimarisiko“ — mit neuen Daten-Layern und Rechen-Ressourcen."}, - {titel:"Falsch beschriftet", text:"Das Bauamt meldet eine falsche Beschriftung eines Karten-Layers, die korrigiert werden muss."}, - {titel:"GeoServer-Update", text:"Das monatliche Update der GIS-Software (GeoServer 2.23 → 2.24) steht an — im Standard-Change-Katalog."}, - {titel:"Schnittstelle offen!", text:"An einer Schnittstelle wird eine kritische Schwachstelle entdeckt, die unautorisierten Datenzugriff erlaubt — Dienst sofort abschalten und patchen."} + "Bundesweite Vorgabe zur Nutzung von EU-Standards → komplette Migration des GIS-Stacks zu konformen Services und Datenmodellen.", + "Das Umweltamt möchte ein neues Analyse-Modul (z. B. „Klimarisiko-Analyse“) einführen, das neue Daten-Layer und Rechen-Ressourcen erfordert.", + "Rückmeldung aus dem Bauamt: Korrektur einer falschen Beschriftung eines Karten-Layers.", + "Monatliches Update der GIS-Software (z. B. GeoServer 2.23 → 2.24) – im Standard-Change-Katalog definiert.", + "Entdeckung einer kritischen Schwachstelle an einer Schnittstelle, die unautorisierten Datenzugriff ermöglicht → sofortige Deaktivierung des Dienstes und Patch-Roll-out." ]}, { service:"Beschaffungs- und Vertrags-System für Fachämter", desc:"Web-Applikation, über die Fachämter interne Beschaffungen (Material, Dienstleistungen) anlegen, prüfen und Verträge digital verwalten.", changes:[ - {titel:"Vergabe neu!", text:"Eine neue EU-Vergaberichtlinie zwingt zur Einführung von E-Invoicing und erweiterten Transparenz-Reports."}, - {titel:"Portal für Partner", text:"Ein neues Lieferanten-Portal (z. B. für Badenova) soll andocken — mit neuen API-Schnittstellen und Authentifizierungs-Flows."}, - {titel:"Vierstellig, bitte", text:"Das Finanzamt wünscht eine kleine Anpassung: aus dem Label „Kostenstelle“ wird „Kostenstelle (4-stellig)“."}, - {titel:"Patch-Quartal", text:"Das quartalsweise Sicherheits-Patch des Anwendungsservers steht an — bereits im Change-Katalog."}, - {titel:"Upload-Falle!", text:"Im Vertrags-Upload wird eine kritische Lücke entdeckt, über die sich Schadcode hochladen lässt — Endpoint sofort sperren, Hotfix einspielen."} + "Neue EU-Vergaberichtlinie zwingt zur Einführung von e-Invoicing und erweiterten Transparenz-Reports.", + "Einführung eines neuen Lieferanten-Portals (z. B. für Badenova), das neue API-Schnittstellen und Authentifizierungs-Flows erfordert.", + "Rückmeldung aus dem Finanzamt: Anpassung eines Formular-Labels (z. B. „Kostenstelle“ → „Kostenstelle (4-stellig)“).", + "Quartalsweises Sicherheits-Patch-Update des Anwendungs-Servers – bereits im Change-Katalog.", + "Entdeckung einer kritischen Schwachstelle im Vertrags-Upload-Modul, die das Hochladen von Schadcode ermöglicht → sofortige Deaktivierung des Upload-Endpoints und Hot-Fix." ]} ]; @@ -758,67 +759,80 @@ const STATIONEN = [ optionen:["Ein Workaround","Ein Betriebshandbuch","Eine Gate-Vorlage","Ein Review-Bericht"], richtig:0, expl:"sp_11 ermittelt die Ursache, erstellt einen Workaround und entscheidet über Change-Bedarf (aktualisiert den Problem Record)."} ]}, - /* Review-Phase = ARBEITSSTAND (Vorschlag Frank, Change-Enablement) — noch NICHT - im Blueprint-YAML; vor Konzept-Uebernahme mit Michael abstimmen. - RACI + Quiz hier abgeleitet (Franks Entwurf nennt nur die Aktivitaeten). */ { id:"rv_01", phase:"review", typ:"aktivitaet", - name:"Durchführen von Service-Reviews", - beschreibung:"Den Service systematisch auswerten und die Ergebnisse im Service-Review-Dokument festhalten.", - umfasst:["KPIs & Monitoring auswerten","Problems & Incidents auswerten","Kundenfeedback sammeln/einholen","zugrunde liegende Infrastruktur bewerten","Service-Review-Dokument ausfüllen"], - artefakt:"Service-Review-Dokument", - raci:[["service_owner","A"],["betriebsteam","R"],["service_support_team","C"],["problem_manager","C"]], + name:"Taktische Root-Cause-Analyse + Auswertung Support-KPIs", + beschreibung:"Strukturelle Analyse wiederkehrender Supportfälle und KPIs, um mittelfristige Verbesserungen anzustoßen.", + umfasst:["KPI-Auswertung (Supportqualität, Trends)","Wiederkehrende Tickets und systemische Ursachen","Abgleich mit Problem Records","Ableitung taktischer Verbesserungsmaßnahmen"], + artefakt:"Taktische Verbesserungsmaßnahmen", + raci:[["service_owner","A"],["problem_manager","R"]], quiz:[ - {frage:"Welches Dokument entsteht beim Service-Review?", - optionen:["RFC","Service-Review-Dokument","Change-Steckbrief","Incident Record"], richtig:1, - expl:"KPIs, Incidents, Feedback und Infrastrukturbewertung werden im Service-Review-Dokument zusammengeführt."} + {frage:"Wer führt die taktische Root-Cause-Analyse durch (R)?", + optionen:["Problem Manager","Service Owner","SOR","1st Level Agent"], richtig:0, + expl:"Der Problem Manager führt die taktische Analyse durch; der Service Owner priorisiert und bestätigt Maßnahmen (A)."} ]}, { id:"rv_02", phase:"review", typ:"aktivitaet", - name:"Bewertung der Review-Ergebnisse", - beschreibung:"Die Review-Ergebnisse bewerten und bei Änderungsbedarf einen RFC erstellen; relevante Berichte gehen an die SOR.", - umfasst:["RFC für Normal- bzw. Major-Change erstellen","Berichte bei Bedarf an die SOR weiterleiten","Ergebnisse in der SOR ganzheitlich bewerten"], - artefakt:"RFC (Request for Change)", - raci:[["sor","A"],["service_owner","R"],["spm","C"]], + name:"Service Performance & Improvement Review", + beschreibung:"Operativer Review des Servicezustands anhand Qualitätsberichten, Supportdaten und Problem-Analysen. Methodik: 4-Dimensionen-Modell mit Ampelbewertung.", + umfasst:["Leistung gegen Ziele und SLAs abgleichen","Gesamterfüllungsgrad bewerten","Operative Risiken, Störungen, Engpässe diskutieren","Optimierungsmaßnahmen identifizieren","Vorbereitung für SOR-Review","Handlungsempfehlung: CONTINUE / IMPROVEMENT / REDESIGN / RETIRE"], + artefakt:"Service Performance & Improvement Review (Ampelbewertung)", + raci:[["service_owner","A/R"],["spm","I"]], quiz:[ - {frage:"Was wird erstellt, wenn die Bewertung Änderungsbedarf zeigt?", - optionen:["Ein RFC (Request for Change)","Ein Incident Record","Ein Test-Report","Eine Service-Definition"], richtig:0, - expl:"Bei Normal- oder Major-Change entsteht ein RFC; Berichte gehen an die SOR."}, - {frage:"Wer bewertet die Review-Ergebnisse ganzheitlich?", - optionen:["Der 1st Level","Die SOR","Das Testmanagement","Der Lieferant"], richtig:1, - expl:"Die SOR bewertet die Ergebnisse als Gremium ganzheitlich."} + {frage:"Welche Bewertungsskala nutzt das Service Performance & Improvement Review?", + optionen:["1–10 Punkte","Grün / Gelb / Rot","Pass / Fail","A / B / C"], richtig:1, + expl:"Das 4-Dimensionen-Modell (Leistung, Stabilität, Zufriedenheit, Zukunftsfähigkeit) wird per Ampel (Grün/Gelb/Rot) bewertet."} ]}, { id:"rv_03", phase:"review", typ:"aktivitaet", - name:"Definieren von Service-Änderungen", - beschreibung:"Auf Basis der Bewertung konkrete Änderungsvorschläge formulieren, konsolidieren und die ausgewählte Änderung beschreiben.", - umfasst:["passende Änderungsvorschläge formulieren","Vorschläge bewerten & konsolidieren","ausgewählte Änderung beschreiben"], - artefakt:"Beschriebene Service-Änderung", - raci:[["service_owner","A"],["sor","C"],["architektur","C"]], + name:"SOR: Periodischer Service Review", + beschreibung:"Die SOR bewertet regelmäßig die Serviceleistung und trifft operative Entscheidungen. Verzweigt in vier Wege.", + umfasst:["Sichtung des Service Performance & Improvement Reviews","Bewertung von Stabilität & Betriebsreife","Priorisierung operativer Verbesserungen","Freigabe kleinerer Maßnahmen","Schnittstelle zur Demand-/Portfolio-Steuerung"], + artefakt:"SOR-Entscheidung (Review)", + pfade:[ + ["Weiter wie bisher","Service stabil, keine Maßnahmen → Operation"], + ["Verbesserung nötig (klein)","→ rv_04 Service Improvement"], + ["Strukturelle Überarbeitung","→ rv_05 Redesign / Erweiterung"], + ["Service End-of-Life","→ rv_06 Außerbetriebnahme"] + ], + raci:[["sor","A"],["service_owner","R"]], quiz:[ - {frage:"Was ist das Ziel dieser Aktivität?", - optionen:["Incidents schließen","Änderungsvorschläge formulieren, konsolidieren und beschreiben","Den Service abschalten","Das Budget planen"], richtig:1, - expl:"Aus der Bewertung werden konkrete, beschriebene Service-Änderungen abgeleitet."} + {frage:"Wer trifft im periodischen Service Review die Entscheidung (A)?", + optionen:["Service Owner","SOR","SPM","Problem Manager"], richtig:1, + expl:"Die SOR entscheidet; der Service Owner berichtet und präsentiert (R)."}, + {frage:"Welche Wege kann rv_03 eröffnen?", + optionen:["Nur Weiter oder Stop","Weiter / Improvement / Redesign / Retirement","Go / No-Go","Intern / Extern"], richtig:1, + expl:"Weiter wie bisher, kleine Verbesserung (rv_04), Redesign (rv_05) oder Außerbetriebnahme (rv_06)."} ]}, { id:"rv_04", phase:"review", typ:"aktivitaet", - name:"Starten von Service-Änderungen", - beschreibung:"Die Änderung anstoßen: bei Normal Change die Umsetzung planen; bei Major Change das Routing klären und den Change-Steckbrief ausfüllen.", - umfasst:["Normal Change: Umsetzung planen","Major Change: Routing klären (RUN / DPM / MB)","Major Change: Change-Steckbrief ausfüllen & weiterleiten"], - artefakt:"Change-Steckbrief (bei Major Change)", - raci:[["service_owner","A"],["sor","C"],["spm","C"],["dpm","I"]], - pfade:[["RUN","Durchführung im laufenden Betrieb (Service Owner)"],["DPM","über den Demand- & Projektprozess"],["MB","direkt in den Projektprozess oder RUN"]], + name:"Service Improvement", + beschreibung:"SOR-Entscheidung: Planung und Steuerung kleinerer Verbesserungsmaßnahmen innerhalb des Service.", + umfasst:["Probleme in Verbesserungs-Initiativen umwandeln","Aufwandsschätzung und Priorisierung","Zielmetriken festlegen","Verantwortlichkeiten zuweisen","Sichtbarkeit im Service-Portfolio"], + artefakt:"Verbesserungs-Initiative (zurück in Operation)", + raci:[["service_owner","A/R"],["spm","C"],["problem_manager","C"]], quiz:[ - {frage:"Was muss beim Major Change vor der Umsetzung geklärt werden?", - optionen:["Das Routing: RUN, DPM oder MB","Die Ticket-Queue","Der Eskalationsweg","Die Lizenzkosten"], richtig:0, - expl:"Beim Major Change wird das Routing (RUN/DPM/MB) geklärt und ein Change-Steckbrief erstellt; beim Normal Change wird direkt die Umsetzung geplant."} + {frage:"Wohin fließen die Verbesserungsmaßnahmen aus rv_04 zurück?", + optionen:["In die Operation (laufender Betrieb)","In die Design-Phase","In den Demand-Lifecycle","An Gate 1"], richtig:0, + expl:"Service Improvement setzt kleinere Maßnahmen im laufenden Betrieb (Operation) um."} ]}, { id:"rv_05", phase:"review", typ:"aktivitaet", - name:"Implementieren von Service-Änderungen", - beschreibung:"Die Änderung gemäß gewähltem Weg umsetzen, dokumentieren und abschließen.", - umfasst:["Normal & Major (Weg RUN): SO führt durch, dokumentiert, schließt ab","Major (Weg DPM): Demand- & Projektprozess","Major (Weg MB): Projektprozess oder RUN"], - artefakt:"Umgesetzte & dokumentierte Service-Änderung", - raci:[["service_owner","A"],["projektteam","R"],["dpm","C"]], + name:"Service Redesign / Erweiterung", + beschreibung:"SOR-Entscheidung: strukturelle Weiterentwicklung des Service. Übergabe an den Demand-Lifecycle.", + umfasst:["Überarbeitung der Service-Definitionen","Anpassung von Komponenten, Prozessen, Rollen","Anforderungen für Entwicklungsprozess identifizieren","Übergabe an Demand-Lifecycle-Prozess"], + artefakt:"Neuer Demand (Redesign) → DPM", + raci:[["service_owner","A"],["spm","C"]], quiz:[ - {frage:"Wer führt eine Änderung auf dem Weg „RUN“ durch?", - optionen:["Der Service Owner","Der Demand Portfolio Manager","Ein externes Projektteam","Die SOR"], richtig:0, - expl:"Im Weg RUN führt der Service Owner die Änderung durch, dokumentiert und schließt sie ab."} + {frage:"Wohin übergibt rv_05 (Redesign/Erweiterung)?", + optionen:["An die Operation","An den Demand-Lifecycle (DPM) als neuer Demand","An den Support","An Gate 2"], richtig:1, + expl:"Strukturelle Änderungen werden als neuer Demand erfasst und durchlaufen den Demand-Lifecycle."} + ]}, + { id:"rv_06", phase:"review", typ:"aktivitaet", + name:"Service außer Betrieb nehmen", + beschreibung:"Strukturierte Entscheidung und kontrollierte Abschaltung eines Services.", + umfasst:["Auslöser definieren (Nutzung, Kosten, Überalterung)","Bewertung durch SOR","Retirement-Plan erstellen (Kommunikation, Migration, Abschaltung)","Koordination mit Portfolio (SPM)","Übergabe an Projekt-/Transitionsthemen"], + artefakt:"Retirement-Plan / Decommissioning-Auftrag → DPM", + raci:[["sor","A"],["service_owner","R"],["spm","C"]], + quiz:[ + {frage:"Wer entscheidet über die Außerbetriebnahme eines Services (A)?", + optionen:["Service Owner","SOR","SPM","Support Manager"], richtig:1, + expl:"Die SOR entscheidet über die Stilllegung; der Service Owner führt den Retirement-Plan aus (R)."} ]} ]; @@ -838,18 +852,6 @@ const $ = s => document.querySelector(s); const cur = () => STATIONEN[S.index]; function pkey(sid, qi){ return sid+"#"+qi; } function roleLabel(id){ return ROLLEN[id] || id; } -function acard(si, ci){ return USE_CASES[si].changes[ci]; } // {titel, text} -function cardHtml(si, ci){ const c = acard(si, ci); - return `
${c.titel}
` - + `
${c.text}
` - + `
Was passiert an welchen Stellen?
`; } -// Finale Action-Card-Grafik (cards/s-c.png). Eine fehlt noch -// (s0-c0 "Open Source von oben!") -> Text-Fallback. -function cardImg(si, ci){ return (si===0 && ci===0) ? null : `cards/s${si}-c${ci}.png`; } -function cardMedia(si, ci){ const f = cardImg(si, ci); - return f ? `Action Card: ${acard(si,ci).titel}` - : cardHtml(si, ci); } /* ====================== RENDER: SIDEBAR ====================== */ function renderList(){ @@ -904,7 +906,7 @@ function renderCardScreen(){ -
${cardMedia(S.service,S.change)}
+
${USE_CASES[S.service].changes[S.change]}
@@ -916,7 +918,7 @@ function renderCardScreen(){ svc.innerHTML = USE_CASES.map((u,i)=>``).join(""); ch.innerHTML = CHANGE_TYPES.map((c,i)=>``).join(""); svc.value=S.service; ch.value=S.change; - const refresh=()=>{ $("#cardTrigger").innerHTML=cardMedia(S.service,S.change); }; + const refresh=()=>{ $("#cardTrigger").textContent=USE_CASES[S.service].changes[S.change]; }; svc.onchange=()=>{ S.service=+svc.value; save(); refresh(); }; ch.onchange=()=>{ S.change=+ch.value; save(); refresh(); }; $("#randomCard").onclick=()=>{ S.service=Math.floor(Math.random()*USE_CASES.length); S.change=Math.floor(Math.random()*CHANGE_TYPES.length); save(); draw(); }; @@ -941,7 +943,7 @@ function renderTour(){ const last = S.tourIndex === STATIONEN.length-1; $("#panel").innerHTML = `
📘 Geführtes Beispiel · ${USE_CASES[TOUR.service].service} — ${CHANGE_TYPES[TOUR.change]}
- ${acard(TOUR.service,TOUR.change).titel} — ${acard(TOUR.service,TOUR.change).text}
+ ${USE_CASES[TOUR.service].changes[TOUR.change]}
Station ${S.tourIndex+1} von ${STATIONEN.length}
${chip}
${st.name}
@@ -1044,7 +1046,7 @@ function renderRun(){
${st.id}
Action Card: ${USE_CASES[S.service].service} ${CHANGE_TYPES[S.change]} -
${acard(S.service,S.change).titel} — ${acard(S.service,S.change).text}
+
${USE_CASES[S.service].changes[S.change]}
`; @@ -1181,7 +1183,7 @@ function openDebrief(){ let md = `# SLC-Workshop — Debrief\n\n`; md += `**Service:** ${USE_CASES[S.service].service}\n`; md += `**Change-Typ:** ${CHANGE_TYPES[S.change]}\n`; - md += `**Action Card:** „${acard(S.service,S.change).titel}“ — ${acard(S.service,S.change).text}\n`; + md += `**Auslöser:** ${USE_CASES[S.service].changes[S.change]}\n`; md += `**Stationen bearbeitet:** ${doneN}/${STATIONEN.length}\n`; md += `**Quiz:** ${correct}/${total} richtig\n\n`; md += `## Als unklar markiert\n`; @@ -1197,8 +1199,7 @@ function openDebrief(){ erzeugt: stamp, service: USE_CASES[S.service].service, changeTyp: CHANGE_TYPES[S.change], - actionCard: acard(S.service,S.change).titel, - ausloeser: acard(S.service,S.change).text, + ausloeser: USE_CASES[S.service].changes[S.change], stationenBearbeitet: doneN, stationenGesamt: STATIONEN.length, quiz: { richtig: correct, gesamt: total }, diff --git a/04_Tablet-Quiz/app/sw.js b/04_Tablet-Quiz/app/sw.js index 04d4be8..d86914d 100644 --- a/04_Tablet-Quiz/app/sw.js +++ b/04_Tablet-Quiz/app/sw.js @@ -1,13 +1,6 @@ /* Service Worker — SLC-Workshop Companion (App-Shell, offline-first) */ -const CACHE = "slc-companion-v2"; -const SHELL = ["./", "index.html", "manifest.webmanifest", "icon.svg"]; -// Action-Card-Grafiken (cards/s-c.png) fuer Offline vorab cachen. -const CARDS = []; -for (let s = 0; s <= 5; s++) for (let c = 0; c <= 4; c++) { - if (s === 0 && c === 0) continue; // s0-c0 fehlt (Text-Fallback) - CARDS.push(`cards/s${s}-c${c}.png`); -} -const ASSETS = SHELL.concat(CARDS); +const CACHE = "slc-companion-v1"; +const ASSETS = ["./", "index.html", "manifest.webmanifest", "icon.svg"]; self.addEventListener("install", (e) => { e.waitUntil(