SLC_Game/00_Konzept/README_konzept.md

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 App + Entscheidungs-Chips.
• 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/.

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 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 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).

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

5.4 Weitere Karten & Chips

• Artefaktkarten + Service-Akte: Was an einer Aktivität entsteht (15 konsolidierte Artefakte A1–A15). Erzeugte Artefakte kommen als Karte in die Service-Akte (Tableau neben der aktuellen Station); „lebende" Artefakte (Service-Definition, Problem Record, Wissensdatenbank) werden über einen Status-Marker mehrfach befüllt. Gate-Kopplung: Ein Gate öffnet nur, wenn die geforderten Artefakte in der Akte liegen (Gate 1: SDD + Implementation Blueprint usw.). Details: ../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.
• 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/.

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/.

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? → erzeugte Artefaktkarte in die Service-Akte legen (bzw. Status-Marker eines bestehenden Artefakts weiterschieben). 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, geforderte Artefakte in der Service-Akte prüfen (sonst öffnet das Gate nicht), Entscheidungs-Chip wählen, 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/).

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.