first

00_Konzept/README_konzept.md

@@ -0,0 +1,190 @@
+# Gesamtkonzept — SLC-Workshop Tabletop
+
+**Version:** 0.4 (Konzept · lineares Board · RACI-Aktiv-Feld · App-gekoppelte Lernschleife)
+**Stand:** 2026-05-27
+**Quelle:** Service-Lifecycle-Blueprint v3.2 (`#02_service-portfolio-management/.../02_spm_service-lifecycle-blueprint/`)
+
+> Änderung ggü. v0.1: Board ist **linear** (durchgehende Bahn), kein geschlossener
+> Ring. Der DPM-Rücklauf wird als Ausgang am Review-Ende dargestellt, nicht als
+> Brückensegment.
+>
+> Änderung ggü. v0.3: Die **Erklärung** wandert von der Plättchen-Rückseite in die
+> **Companion-App**. Plättchen tragen nur noch die **Kurzbezeichnung** (einseitig).
+> Pro Station gilt die Schleife **Diskussion → App-Quiz → Auflösung → Reflexion**;
+> die App führt die Stationsreihenfolge automatisch.
+
+---
+
+## 1. Zweck & Zielgruppe
+
+Ein haptisches Workshop-Format, mit dem Teams der Stadt Freiburg / DIGIT den
+Service-Lifecycle **erleben statt nur lesen**. Eingesetzt wird es zur Schulung
+neuer Beteiligter, zur gemeinsamen Validierung des Blueprints und als
+Feedback-Instrument: Wo das Spiel hakt, ist meist auch das Konzept unklar.
+
+Lernziele:
+- Phasenfolge und Aktivitäten des Lifecycles verstehen.
+- Begreifen, **wer** an **welchem Gate** entscheidet (Governance / RACI).
+- Die Operation↔Support-Schleife und die Rückkopplung in den Demand-Lifecycle nachvollziehen.
+
+## 2. Das Spielbrett — lineare Bahn
+
+Der Service-Lifecycle ist eine **durchgehende Bahn** von Design bis Review. Ein
+Service-Token wandert von links nach rechts; Operation und Support bilden eine
+sichtbare Hin-und-zurück-Schleife. Am Review-Ende führen zwei Ausgänge zurück in
+den Demand-Lifecycle (Redesign / Retirement) — bewusst **kein** kurzgeschlossener
+Pfeil zu Design.
+
+```
+                               Gate 1            Gate 2 / Gate 3
+                                 │                    │
+ [ DESIGN ]──▶[   TRANSITION   ]──▶[ OPERATION ]⇄[ SUPPORT ]──▶[ REVIEW ]
+  ds_01–04     tr_01 … tr_12        op_01–07      sp_01–11      rv_01–06
+                                                                    │
+            rv_05 (Redesign) / rv_06 (Retirement) ──▶ zurück in DPM (Demand-Lifecycle)
+```
+
+Loop-Ebene: **Operation ⇄ Support** ist der innere Sub-Loop (laufender Betrieb,
+dreht sich häufig); der DPM-Rücklauf ist die langlebige „Wiedergeburt" eines
+Services und verlässt das Board am Review-Ende.
+
+### Aufbau aus modularen Tiles
+Das Board ist ein **Tile-System**: kleine, untereinander steckbare Basistiles
+(je eine Aktivität/Gate pro Tile), die zu einer Bahn aneinandergereiht werden.
+Bei Platzmangel kann die Bahn **mäandrierend** (Zeilen-Umbruch) gelegt werden.
+Das hält die 3D-Druckteile klein genug für übliche Druckbetten. Maße & Mechanik:
+[`../01_3D-Druck/`](../01_3D-Druck/).
+
+## 3. Phasen & Aktivitäten
+
+Präfixe: `ds_` Design · `tr_` Transition · `op_` Operation · `sp_` Support · `rv_` Review.
+
+| Phase | Farbe | Aktivitäten |
+|-------|-------|-------------|
+| **Design** | blau | ds_01–ds_04 (4) |
+| **Transition** | orange | tr_01–tr_12 (9 Aktivitäten + 3 Gates) |
+| **Operation** | grün | op_01–op_07 (7) |
+| **Support** | teal | sp_01–sp_11 (11) |
+| **Review** | lila | rv_01–rv_06 (6) |
+
+Vollständige Aktivitätsliste mit Namen: siehe Blueprint-README (Quelle oben).
+Die **Plättchen-Kurzbezeichnung** (ID + Name) und die **App-Auflösung** werden
+beide 1:1 aus den `service-lifecycle_*.yaml` gezogen — keine Doppelpflege.
+
+## 4. Die Gates
+
+| Gate | ID | Position | Gate-Keeper | Pflicht-Figuren am Tor |
+|------|----|----------|-------------|------------------------|
+| Gate 1 | tr_01 | Entry Transition | **SOR** | SPM + SO + AL B&C + AL App |
+| Gate 2 | tr_09 | nach Build | **SO** (allein) | SO |
+| Gate 3 | tr_12 | Exit Transition → Operation | **SOR** | SPM + SO + AL B&C + AL App |
+
+Entscheidungspfade als Chips: **Go / Go mit Auflagen / Zurück / Ablehnung**
+(exakt die im Blueprint dokumentierten Pfade). Gate 1 verzweigt zusätzlich
+**Entwicklung (tr_02)** vs. **Konfiguration (tr_05)**.
+
+> Hinweis Governance: Laut Rollen-YAML v1.1 wurde „Operations Manager" durch
+> **AL Basis & Cloud** und **AL Applikationen** ersetzt (GOV-SOR-005). Beide sind
+> ständige, stimmberechtigte SOR-Mitglieder.
+
+## 5. Spielelemente (Mechaniken)
+
+### 5.1 Action-Stein (Szenario-Träger)
+Ein Spielstein mit aufrechtem Kartenschlitz. Die gezogene **Action Card** (z.B.
+„Strategiewechsel") steckt sichtbar im Stein und wandert mit ihm durch die
+Phasen. Footprint des Steins = Footprint der Aktivitäts-Verankerung.
+
+### 5.2 Aktivitätsplättchen + App-Auflösung (Kern-Mechanik)
+- **Plättchen ist einseitig:** nur **ID + Kurzbezeichnung** (`op_05 — Überwachen
+  der Services`). **Keine Erklärung auf der Rückseite** — die liegt in der App.
+- Sitzt in der **Verankerung** (Vertiefung) des Tiles und ist **entnehmbar**.
+- **Spielzug:** Action-Stein erreicht das Plättchen → Gruppe **diskutiert anhand der
+  Kurzbezeichnung**, was hier passiert (noch **nichts** aufdecken) → Plättchen
+  herausnehmen, Action-Stein in die freie Verankerung stellen (markiert „wir sind
+  hier") → **App-Quiz** zur Station → **Auflösung in der App** → kurze Reflexion.
+- Die Erklärung wird also **erarbeitet, nicht vorgelesen**: erst Diskussion, dann
+  Quiz (vermittelnd), dann die ausführliche App-Auflösung.
+
+### 5.3 Rollen-Figuren & Platzierung
+Schlanke Pöppel je Rolle (Höhe ~22 mm, Pin Ø 4 mm), farb- und formcodiert.
+Es gibt **einheitliche Steckplätze (Ø 4,2 mm)** an zwei Orten:
+- **Aktiv-Feld (RACI pro Schritt):** Eine mobile Stecklochleiste steht **neben dem
+  Action-Stein** und wandert mit ihm. Sie hat vier beschriftete Zonen
+  **R · A · C · I**. Beim Bearbeiten einer Aktivität werden die beteiligten Rollen
+  in die passende RACI-Zone gesteckt — sichtbar wird nicht nur *wer*, sondern *in
+  welcher Verantwortung*. **A** hat genau einen Platz (genau eine Rolle accountable).
+- **Gate-Versammlung:** An den Gates müssen die **Pflicht-Figuren** in die
+  Tor-Steckplätze, sonst „öffnet" das Gate nicht.
+
+Die Tiles bleiben dadurch clean; die Figuren sind bewusst klein (Standfläche ≤ 8 mm),
+damit mehrere in einer Zonen-Reihe stehen. Details & Designvarianten:
+[`../02_Spielfiguren/`](../02_Spielfiguren/).
+
+### 5.4 Weitere Karten & Chips
+- **Artefaktkarten:** Was an einer Aktivität entsteht (Projektauftrag, Betriebsdoku, Test-Report, Service-Qualitätsbericht, Incident/Problem Record, Workaround, Review-Bericht).
+- **Störungskarten:** Gegenstück zu Action Cards (Incident-Welle, Sicherheitsvorfall, Budgetkürzung, Eskalation) — zwingen in die Operation↔Support-Schleife oder über ein Gate zurück.
+- **Entscheidungs-Chips:** Go / Go mit Auflagen / Zurück / Ablehnung.
+- **DPM-Rücklauf-Karte:** markiert am Review-Ende, wenn der Service als Redesign/Retirement zurück in den Demand-Lifecycle geht.
+- **„Unklar"-Marker:** rote Punkte für Verständnislücken (→ Dokumentation).
+
+Details: [`../03_Karten/`](../03_Karten/).
+
+### 5.5 Companion-App (Lernschleife & Auflösung)
+Die App ist der **erklärende Gegenpart** zum Board und ersetzt die frühere
+Plättchen-Rückseite. Sie **führt die Stationsreihenfolge automatisch** (linearer
+Lifecycle, „Nächste Station") — die Plättchen brauchen daher keinen Code.
+
+Pro Station liefert die App die Schrittigkeit:
+1. **Diskussion zuerst (am Board):** Gruppe deutet die Kurzbezeichnung; App noch zu.
+2. **Quiz (vermittelnd):** kurze Fragen, die *durch* den Stoff führen (parate
+   Active-Recall-Mechanik), nicht nur abprüfen.
+3. **Auflösung:** ausführliche Erklärung, was hinter der Aktivität steckt
+   (gespeist aus den `service-lifecycle_*.yaml` + Rollen/RACI).
+4. **Reflexion:** Gruppe gleicht ihren Tipp mit der Auflösung ab; „Unklar"-Marker
+   bei Lücken.
+
+Schwach beantwortete Stationen werden protokolliert (→ Abschnitt 8). MVP-Scope:
+[`../04_Tablet-Quiz/`](../04_Tablet-Quiz/).
+
+## 6. Spielablauf
+
+1. **Setup:** Bahn legen, Plättchen in Verankerungen, Rollen-Figuren am Spielfeldrand, Action/Störungs-Decks bereit, Tablet aktiviert.
+2. **Rollen verteilen:** Jede Person hält 1–2 Rollen-Figuren und spricht, wenn ihre Rolle dran ist.
+3. **Szenario ziehen:** Action Card in den Stein, Stein auf `ds_01` (erste Station).
+4. **Station bearbeiten (Lernschleife, App noch zu):** Pro Aktivität die drei Leitfragen diskutieren —
+   1. Was passiert hier konkret für dieses Szenario?
+   2. Wer macht es (Rolle, RACI)? → die genannten **Rollen-Figuren ins Aktiv-Feld
+      in die passende R/A/C/I-Zone stecken**
+   3. Welches Artefakt entsteht?
+   Plättchen herausnehmen, **Action-Stein in die Verankerung** („wir sind hier").
+   Dann **App-Quiz** zur Station → **Auflösung in der App** → Gruppe reflektiert /
+   gleicht ab. Danach Aktiv-Feld leeren und mit dem Action-Stein zur **nächsten
+   Station** weiterziehen (App schaltet weiter).
+5. **Gates:** Diskussion, Pflicht-Figuren setzen, Entscheidungs-Chip wählen, Token durch das Tor schieben.
+6. **Schleife:** Störungskarten und Support-Phase durchspielen, bis Review erreicht ist.
+7. **Review-Entscheidung:** Improvement / Redesign (rv_05) / Retirement (rv_06) — Redesign & Retirement geben den Service über die DPM-Rücklauf-Karte ab.
+8. **Debrief:** Logbuch & Reflexion (→ [`../05_Workshop-Dokumentation/`](../05_Workshop-Dokumentation/)).
+
+## 7. Didaktische Hebel
+
+- **Active Recall:** erst diskutieren/raten anhand der Kurzbezeichnung, dann App-Quiz, dann Auflösung — statt passivem Vorlesen.
+- **Embodiment:** Rollen-Figuren in der Hand erzwingen Beteiligung und vermitteln Verantwortlichkeiten körperlich (RACI im Aktiv-Feld).
+- **Forcierte Konsens-Entscheidung an Gates:** trainiert Governance statt reiner Stoffvermittlung.
+- **Produktives Ringen:** Die App löst erst *nach* dem Gruppentipp auf.
+- **Low-stakes:** Punkte optional, Diskussion vor Wettbewerb.
+
+## 8. Dokumentation & Feedback-Schleife
+
+Verständnislücken im Spiel = oft Lücken im Konzept. Deshalb wird dokumentiert:
+- „Unklar"-Marker direkt auf dem Board → sichtbare **Heatmap**, abfotografieren.
+- Logbuch-Bogen pro Runde (Pfad, Gate-Entscheidungen, unklare Aktivitäten, Stimmung).
+- Tablet-Export der schwach beantworteten Aktivitäten.
+
+Diese Daten fließen zurück in die Weiterentwicklung des Blueprints.
+
+## 9. Offene Punkte / nächste Schritte
+
+- [ ] Print-Test der 3D-Maße (Stein-Stabilität mit aufrechter Karte validieren).
+- [ ] Plättchen-Texte aus den YAMLs final generieren (Layout).
+- [ ] Tablet-Quiz: MVP-Scope festlegen (siehe `04_Tablet-Quiz/`).
+- [ ] Pilot-Workshop terminieren und Logbuch testen.