SLC_Game/00_Konzept/README_konzept.md

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

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, flacher Standfuß ohne Pin), farb- und formcodiert. Figuren werden gestellt, nicht gesteckt; markierte Standfelder gibt es an zwei Orten:

• Aktiv-Feld (RACI pro Schritt): Eine mobile Leiste 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 gestellt — 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 auf die Tor-Standfelder gestellt werden, sonst „öffnet" das Gate nicht.

Die Tiles bleiben dadurch clean; die Figuren sind bewusst klein (Standfläche Ø ~7,5 mm), damit mehrere in einer Zonen-Reihe stehen. 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 dem Action-Stein); „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 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/.

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

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.