# Gesamtkonzept — SLC-Workshop Tabletop

**Version:** 0.5 (Konzept · lineare Puck-Bahn · Phasen-Ring · quadratisches RACI-Aktiv-Feld · App-gekoppelte Lernschleife)
**Stand:** 2026-06-05
**Quelle:** Service-Lifecycle-Blueprint v3.2 (`#02_service-portfolio-management/.../02_spm_service-lifecycle-blueprint/`)

> **Änderung ggü. v0.4 (Hardware-Redesign):**
> - Eckige Steck-Tiles + separate Plättchen/Scheiben **ersetzt durch runde Ø100-Pucks**
>   (ein Bauteil je Station; 7 Figurenmulden + Mittenetikett). Pucks liegen **lose**
>   (keine Steckverbindung, keine Magnete, keine Verankerung).
> - **Action-Stein entfällt** — die Action Card liegt flach an der aktuellen Station;
>   die App führt die Reihenfolge, die gestellten Figuren markieren „wir sind hier".
> - **Gate-Tore + Gate-Karten entfallen** — ein Gate ist ein **roter Puck**; Keeper,
>   Artefakte und Auflösung laufen über die App (die entscheidende Rolle bleibt als
>   Marker am Gate-Puck stehen).
> - **Aktiv-Feld** ist jetzt **quadratisch (2×2: R|A / C|I)**.
> - Neu: **Phasen-Ring** — zusammengesteckt die SLC-Übersicht, auseinandergenommen
>   die farbigen Phasen-Köpfe der Bahn (Design-Segment = Start).

---

## 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 Puck-Bahn

Der Service-Lifecycle ist eine **durchgehende Bahn** von Design bis Review. Die
Gruppe wandert mit dem Szenario 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 runden Pucks
Die Bahn ist eine Reihe **runder Pucks** (Ø 100 mm): **eine je Aktivität** (37) plus
**3 Gate-Pucks** (gleiche Form, rote Farbe) = 40 Positionen. Die Pucks werden
**lose** aneinandergelegt (keine Steck-/Magnetverbindung); bei Platzmangel
mäandrierend. Als optische Linie dient eine flache Unterlage/Matte. Jeder Puck
trägt seine Phasenfarbe (Filament) und in der Mitte ein **Rundetikett** mit
ID + Kurzbezeichnung. Maße & Modelle: [`../01_3D-Druck/`](../01_3D-Druck/).

### Phasen-Ring (Übersicht ↔ Bahn-Köpfe)
Fünf farbige 72°-Segmente bilden **zusammengesteckt** den SLC-Übersichts-Donut
(Gesamtbild des Lifecycles) und **auseinandergenommen** die **Phasen-Köpfe** der
Bahn — das **Design-Segment ist der Start** vor dem ersten Puck. Jedes Segment
trägt Icon + Phasenname in der Phasenfarbe.

## 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 **Etikett-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 Gate-Puck |
|------|----|----------|-------------|------------------------------|
| 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 |

Ein Gate ist ein **roter Puck** (Etikett `G1`/`G2`/`G3` + Entscheidungs-Icon). Die
Pflicht-Figuren werden in seine Figurenmulden gestellt; sonst „öffnet" das Gate
nicht. Entscheidungspfade (in der App): **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 Szenario / Action Card (kein Spielstein)
Eine gezogene **Action Card** (z. B. „Strategiewechsel") gibt das Szenario vor. Sie
liegt **flach an der aktuellen Station** und wandert mit der Gruppe die Bahn entlang.
Einen aufrechten Träger-Stein gibt es nicht mehr; die **App führt** die
Stationsreihenfolge, die aktuelle Station ist zusätzlich daran erkennbar, dass dort
die **Rollen-Figuren** stehen.

### 5.2 Station-Puck + App-Auflösung (Kern-Mechanik)
- **Ein Puck je Station** (Ø 100 mm): außen ein Ring aus **7 Figurenmulden**, in der
  Mitte ein **Rundetikett** mit **ID + Kurzbezeichnung** (`op_05 — Überwachen der
  Services`). **Keine Erklärung am Puck** — die liegt in der App.
- **Spielzug:** Die Gruppe erreicht den nächsten Puck → **diskutiert anhand der
  Kurzbezeichnung**, was hier passiert (noch **nichts** aufdecken) → beteiligte
  **Figuren an den Puck stellen** → **App-Quiz** zur Station → **Auflösung in der
  App** → kurze Reflexion → weiter zur nächsten Station.
- Die Erklärung wird **erarbeitet, nicht vorgelesen**: erst Diskussion, dann Quiz
  (vermittelnd), dann die ausführliche App-Auflösung.

### 5.3 Rollen-Figuren & Platzierung
Pöppel je Rolle (Höhe ~50 mm, flacher Standfuß Ø 20 mm ohne Pin), farb- und
formcodiert. Figuren werden **gestellt, nicht gesteckt**; es gibt **zwei** Orte:
- **Am Station-Puck (wer ist beteiligt):** die **7 Figurenmulden** (Ø 22) nehmen die
  je Aktivität beteiligten Rollen auf — sichtbar wird, *wer* an dieser Station mitwirkt.
- **Aktiv-Feld (RACI pro Schritt):** ein **quadratisches** Board (130 × 130 mm), das
  neben der aktuellen Station liegt und mitwandert. Es hat vier Zonen im 2×2-Raster
  **R | A** (oben) und **C | I** (unten). Die beteiligten Rollen werden zusätzlich in
  die passende RACI-Zone gestellt — sichtbar wird nicht nur *wer*, sondern *in welcher
  Verantwortung*. **A** hat genau einen Platz (genau eine Rolle accountable).
  Didaktische Gewichtung (Frank): **R und A** sind die Pflicht und unbedingt zu
  durchdenken (obere Zeile R | A), **C und I** sind ergänzend / nice-to-have.

Alle Standfelder sind Ø 22 (gleich wie die Puck-Mulden — dieselben Ø-20-Figuren).
Details & Designvarianten: [`../02_Spielfiguren/`](../02_Spielfiguren/).

### 5.4 Weitere Karten
- **Artefakte A1–A15 + Service-Akte (App):** Was an einer Aktivität entsteht (15 konsolidierte Artefakte). Erzeugte Artefakte werden **in der App** bestimmt (Choice) und in der digitalen **Service-Akte** gesammelt; „lebende" Artefakte (Service-Definition, Problem Record, Wissensdatenbank) werden mehrfach befüllt. **Harte Gate-Kopplung:** Ein Gate gibt die Entscheidung erst frei, wenn die geforderten Artefakte gesammelt sind (Gate 1: A2·A3·A4 usw.). Details: [`../03_Karten/`](../03_Karten/).
- **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.
- **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. Sie **führt die
Stationsreihenfolge automatisch** (linearer Lifecycle, „Nächste Station") — die Pucks
brauchen daher keinen Code; ihre ID steht nur auf dem Etikett.

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:** Puck-Bahn auslegen (Phasen-Ring auseinandernehmen, Design-Segment als Start, dann die Station-Pucks je Phase, Gate-Pucks an Gate 1/2/3), Rollen-Figuren am Spielfeldrand, Aktiv-Feld bereit, 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 ziehen, an die erste Station (`ds_01`) legen.
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 **Figuren an den Puck stellen** und
      zusätzlich ins **Aktiv-Feld** in die passende R/A/C/I-Zone.
   3. Welches Artefakt entsteht? → in der **App auswählen** (Artefakt-Schritt); es
      wandert in die digitale **Service-Akte**.
   Dann **App-Quiz** zur Station → **Auflösung in der App** → Gruppe reflektiert /
   gleicht ab. Danach Aktiv-Feld leeren und zur **nächsten Station** weiterziehen
   (App schaltet weiter, Action Card mitnehmen).
5. **Gates:** Diskussion, Pflicht-Figuren an den Gate-Puck stellen; die **App prüft die
   geforderten Artefakte** (fehlen sie, bleibt die Entscheidung gesperrt),
   Entscheidung in der App treffen, weiterziehen.
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 (am Puck *wer*, im Aktiv-Feld *welche RACI-Rolle*).
- **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 (Passung Figur ↔ Puck-Mulde, Etikett ↔ Mulde, Stabilität Phasen-Ring-Segmente).
- [ ] Etiketten-Bogen (Ø 37) aus den YAMLs generieren (Layout).
- [ ] Tablet-Quiz: MVP-Scope festlegen (siehe `04_Tablet-Quiz/`).
- [ ] Pilot-Workshop terminieren und Logbuch testen.