diff --git a/00_Konzept/review-phase_arbeitsstand-frank.md b/00_Konzept/review-phase_arbeitsstand-frank.md new file mode 100644 index 0000000..3b70fd0 --- /dev/null +++ b/00_Konzept/review-phase_arbeitsstand-frank.md @@ -0,0 +1,59 @@ +# 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 5e565d3..0186c96 100644 --- a/01_3D-Druck/board-layout.svg +++ b/01_3D-Druck/board-layout.svg @@ -1,8 +1,8 @@ -Service-Lifecycle — Board-Layout (40 Pucks) -37 Aktivitaeten + 3 Gate-Pucks · 1 Puck = Ø100 mm · lose Bahn, Sequenz links nach rechts +Service-Lifecycle — Board-Layout (39 Pucks) +36 Aktivitaeten + 3 Gate-Pucks · 1 Puck = Ø100 mm · lose Bahn, Sequenz links nach rechts DESIGN 4 Pucks @@ -428,7 +428,7 @@ REVIEW -6 Pucks +5 Pucks @@ -439,7 +439,7 @@ rv_01 -Taktische RCA + KPIs +Service-Reviews durchf. @@ -451,7 +451,7 @@ rv_02 -Performance & Improvement +Bewertung d. Ergebnisse @@ -463,7 +463,7 @@ rv_03 -SOR Periodischer Review +Aenderungen definieren @@ -475,7 +475,7 @@ rv_04 -Service Improvement +Aenderungen starten @@ -487,24 +487,12 @@ rv_05 -Redesign / Erweiterung - - - - - - - - - - -rv_06 -Ausserbetriebnahme +Aenderungen umsetzen 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 eb0d422..ed7e9b0 100644 --- a/01_3D-Druck/gen_board_layout.py +++ b/01_3D-Druck/gen_board_layout.py @@ -52,13 +52,12 @@ PHASES = [ ("sp_11", "RCA & Workaround", False), ]), ("REVIEW", "#8E63B5", [ - ("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), - ]), + ("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 ] # Layout-Parameter @@ -132,9 +131,9 @@ svg.append('') # Titel svg.append(f'' - f'Service-Lifecycle — Board-Layout (40 Pucks)') + f'Service-Lifecycle — Board-Layout (39 Pucks)') svg.append(f'' - f'37 Aktivitaeten + 3 Gate-Pucks · 1 Puck = Ø{TILE_MM} mm · ' + f'36 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 ebea60e..ea43d7e 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 | **37** (eine je Aktivität) | +| Menge | **36** (eine je Aktivität) — Druck von 37 empfohlen: 1 Blank als Reserve | | Material | PLA, Infill 15 % | | Druckzeit | ~1,3 h/Puck | | Datei | `openscad/puck.scad` | @@ -45,11 +45,16 @@ 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_06 | 6 | -| | | **Σ Station-Pucks** | **37** | +| Review | lila | rv_01–rv_05 | 5 | +| | | **Σ Station-Pucks** | **36** | Die 3 Gates (tr_01, tr_09, tr_12) sind **Gate-Pucks** (gleiches Teil, rot, §2) → 3 Stück. -**Bahn gesamt = 37 + 3 = 40 Positionen.** +**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). Die Pucks werden zu einer **linearen Bahn** ausgelegt (kein Ring), bei Platzmangel mäandrierend. Als optische Linie + Halt empfiehlt sich eine **flache Unterlage/Matte** @@ -151,19 +156,19 @@ linearen Puck-Bahn — das **Design-Segment ist der Start** vor dem ersten Puck. | Teil | Menge | Datei | |------|------:|-------| -| Station-Puck | 37 | `openscad/puck.scad` (Phasenfarbe) | +| Station-Puck | 36 (+1 Reserve) | `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 | 40 | via Generator aus YAML (ID + Phasenfarbe); ablösbar bevorzugt | +| Rundetiketten Ø37 | 39 | 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, 40× drucken** (37 Phasen + 3 rot). + + Etikett — **ein STL, 39× drucken** (36 Phasen + 3 rot; +1 Blank als Reserve). - **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 4a7170d..f9cbbdf 100644 --- a/04_Tablet-Quiz/README.md +++ b/04_Tablet-Quiz/README.md @@ -6,7 +6,9 @@ > (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. **Deployment:** statisch, siehe +> 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 > [`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 new file mode 100644 index 0000000..ac25b8f Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s0-c1.png differ diff --git a/04_Tablet-Quiz/app/cards/s0-c2.png b/04_Tablet-Quiz/app/cards/s0-c2.png new file mode 100644 index 0000000..255d426 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s0-c2.png differ diff --git a/04_Tablet-Quiz/app/cards/s0-c3.png b/04_Tablet-Quiz/app/cards/s0-c3.png new file mode 100644 index 0000000..d7a7587 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s0-c3.png differ diff --git a/04_Tablet-Quiz/app/cards/s0-c4.png b/04_Tablet-Quiz/app/cards/s0-c4.png new file mode 100644 index 0000000..031930c Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s0-c4.png differ diff --git a/04_Tablet-Quiz/app/cards/s1-c0.png b/04_Tablet-Quiz/app/cards/s1-c0.png new file mode 100644 index 0000000..0aa579e Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s1-c0.png differ diff --git a/04_Tablet-Quiz/app/cards/s1-c1.png b/04_Tablet-Quiz/app/cards/s1-c1.png new file mode 100644 index 0000000..270c925 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s1-c1.png differ diff --git a/04_Tablet-Quiz/app/cards/s1-c2.png b/04_Tablet-Quiz/app/cards/s1-c2.png new file mode 100644 index 0000000..692f60c Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s1-c2.png differ diff --git a/04_Tablet-Quiz/app/cards/s1-c3.png b/04_Tablet-Quiz/app/cards/s1-c3.png new file mode 100644 index 0000000..b212aca Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s1-c3.png differ diff --git a/04_Tablet-Quiz/app/cards/s1-c4.png b/04_Tablet-Quiz/app/cards/s1-c4.png new file mode 100644 index 0000000..a7bfce7 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s1-c4.png differ diff --git a/04_Tablet-Quiz/app/cards/s2-c0.png b/04_Tablet-Quiz/app/cards/s2-c0.png new file mode 100644 index 0000000..ff004e9 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s2-c0.png differ diff --git a/04_Tablet-Quiz/app/cards/s2-c1.png b/04_Tablet-Quiz/app/cards/s2-c1.png new file mode 100644 index 0000000..afa79a4 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s2-c1.png differ diff --git a/04_Tablet-Quiz/app/cards/s2-c2.png b/04_Tablet-Quiz/app/cards/s2-c2.png new file mode 100644 index 0000000..cc77016 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s2-c2.png differ diff --git a/04_Tablet-Quiz/app/cards/s2-c3.png b/04_Tablet-Quiz/app/cards/s2-c3.png new file mode 100644 index 0000000..3a7fe04 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s2-c3.png differ diff --git a/04_Tablet-Quiz/app/cards/s2-c4.png b/04_Tablet-Quiz/app/cards/s2-c4.png new file mode 100644 index 0000000..c7c44bd Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s2-c4.png differ diff --git a/04_Tablet-Quiz/app/cards/s3-c0.png b/04_Tablet-Quiz/app/cards/s3-c0.png new file mode 100644 index 0000000..ef74d4f Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s3-c0.png differ diff --git a/04_Tablet-Quiz/app/cards/s3-c1.png b/04_Tablet-Quiz/app/cards/s3-c1.png new file mode 100644 index 0000000..868ee1b Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s3-c1.png differ diff --git a/04_Tablet-Quiz/app/cards/s3-c2.png b/04_Tablet-Quiz/app/cards/s3-c2.png new file mode 100644 index 0000000..e5c04d3 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s3-c2.png differ diff --git a/04_Tablet-Quiz/app/cards/s3-c3.png b/04_Tablet-Quiz/app/cards/s3-c3.png new file mode 100644 index 0000000..1e92d29 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s3-c3.png differ diff --git a/04_Tablet-Quiz/app/cards/s3-c4.png b/04_Tablet-Quiz/app/cards/s3-c4.png new file mode 100644 index 0000000..2b55f60 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s3-c4.png differ diff --git a/04_Tablet-Quiz/app/cards/s4-c0.png b/04_Tablet-Quiz/app/cards/s4-c0.png new file mode 100644 index 0000000..e7f9924 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s4-c0.png differ diff --git a/04_Tablet-Quiz/app/cards/s4-c1.png b/04_Tablet-Quiz/app/cards/s4-c1.png new file mode 100644 index 0000000..92c49c8 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s4-c1.png differ diff --git a/04_Tablet-Quiz/app/cards/s4-c2.png b/04_Tablet-Quiz/app/cards/s4-c2.png new file mode 100644 index 0000000..bde7e0c Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s4-c2.png differ diff --git a/04_Tablet-Quiz/app/cards/s4-c3.png b/04_Tablet-Quiz/app/cards/s4-c3.png new file mode 100644 index 0000000..3d21db2 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s4-c3.png differ diff --git a/04_Tablet-Quiz/app/cards/s4-c4.png b/04_Tablet-Quiz/app/cards/s4-c4.png new file mode 100644 index 0000000..5e924cb Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s4-c4.png differ diff --git a/04_Tablet-Quiz/app/cards/s5-c0.png b/04_Tablet-Quiz/app/cards/s5-c0.png new file mode 100644 index 0000000..0535b9e Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s5-c0.png differ diff --git a/04_Tablet-Quiz/app/cards/s5-c1.png b/04_Tablet-Quiz/app/cards/s5-c1.png new file mode 100644 index 0000000..b4e46ea Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s5-c1.png differ diff --git a/04_Tablet-Quiz/app/cards/s5-c2.png b/04_Tablet-Quiz/app/cards/s5-c2.png new file mode 100644 index 0000000..1df396b Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s5-c2.png differ diff --git a/04_Tablet-Quiz/app/cards/s5-c3.png b/04_Tablet-Quiz/app/cards/s5-c3.png new file mode 100644 index 0000000..b7319d8 Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s5-c3.png differ diff --git a/04_Tablet-Quiz/app/cards/s5-c4.png b/04_Tablet-Quiz/app/cards/s5-c4.png new file mode 100644 index 0000000..ab3bb6a Binary files /dev/null and b/04_Tablet-Quiz/app/cards/s5-c4.png differ diff --git a/04_Tablet-Quiz/app/index.html b/04_Tablet-Quiz/app/index.html index 94058c5..09dbfb5 100644 --- a/04_Tablet-Quiz/app/index.html +++ b/04_Tablet-Quiz/app/index.html @@ -245,12 +245,11 @@ 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 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)." + 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." } }; @@ -270,7 +269,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)" + lieferant:"Lieferant", operations_manager:"Betrieb (AL B&C / AL App)", dpm:"Demand Portfolio Manager" }; const PHASEN = { design:{label:"Design", color:"var(--design)"}, @@ -291,56 +290,56 @@ const USE_CASES = [ { service:"Zentrale VDI (Virtual-Desktop-Infrastructure)", desc:"Bereitstellung von virtuellen Windows-Desktops über das interne Rechenzentrum.", changes:[ - "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." + {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."} ]}, { 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:[ - "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." + {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."} ]}, { 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:[ - "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." + {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."} ]}, { 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:[ - "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." + {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."} ]}, { 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:[ - "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." + {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."} ]}, { 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:[ - "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." + {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."} ]} ]; @@ -759,80 +758,67 @@ 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:"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"]], + 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"]], quiz:[ - {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)."} + {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."} ]}, { id:"rv_02", phase:"review", typ:"aktivitaet", - 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:"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:"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:"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:"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:"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:"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:"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", + 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"]], 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)."} + {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."} + ]}, + { 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"]], + 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."} + ]}, + { 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"]], + 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."} + ]}, + { 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"]], + 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."} ]} ]; @@ -852,6 +838,18 @@ 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(){ @@ -906,7 +904,7 @@ function renderCardScreen(){ -
${USE_CASES[S.service].changes[S.change]}
+
${cardMedia(S.service,S.change)}
@@ -918,7 +916,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").textContent=USE_CASES[S.service].changes[S.change]; }; + const refresh=()=>{ $("#cardTrigger").innerHTML=cardMedia(S.service,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(); }; @@ -943,7 +941,7 @@ function renderTour(){ const last = S.tourIndex === STATIONEN.length-1; $("#panel").innerHTML = `
📘 Geführtes Beispiel · ${USE_CASES[TOUR.service].service} — ${CHANGE_TYPES[TOUR.change]}
- ${USE_CASES[TOUR.service].changes[TOUR.change]}
+ ${acard(TOUR.service,TOUR.change).titel} — ${acard(TOUR.service,TOUR.change).text}
Station ${S.tourIndex+1} von ${STATIONEN.length}
${chip}
${st.name}
@@ -1046,7 +1044,7 @@ function renderRun(){
${st.id}
Action Card: ${USE_CASES[S.service].service} ${CHANGE_TYPES[S.change]} -
${USE_CASES[S.service].changes[S.change]}
+
${acard(S.service,S.change).titel} — ${acard(S.service,S.change).text}
`; @@ -1183,7 +1181,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 += `**Auslöser:** ${USE_CASES[S.service].changes[S.change]}\n`; + md += `**Action Card:** „${acard(S.service,S.change).titel}“ — ${acard(S.service,S.change).text}\n`; md += `**Stationen bearbeitet:** ${doneN}/${STATIONEN.length}\n`; md += `**Quiz:** ${correct}/${total} richtig\n\n`; md += `## Als unklar markiert\n`; @@ -1199,7 +1197,8 @@ function openDebrief(){ erzeugt: stamp, service: USE_CASES[S.service].service, changeTyp: CHANGE_TYPES[S.change], - ausloeser: USE_CASES[S.service].changes[S.change], + actionCard: acard(S.service,S.change).titel, + ausloeser: acard(S.service,S.change).text, 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 d86914d..04d4be8 100644 --- a/04_Tablet-Quiz/app/sw.js +++ b/04_Tablet-Quiz/app/sw.js @@ -1,6 +1,13 @@ /* Service Worker — SLC-Workshop Companion (App-Shell, offline-first) */ -const CACHE = "slc-companion-v1"; -const ASSETS = ["./", "index.html", "manifest.webmanifest", "icon.svg"]; +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); self.addEventListener("install", (e) => { e.waitUntil(