commit c87b0b1775b51e97663bf0bc38f356dc8adc2913 Author: breitenbach76 Date: Thu May 28 15:50:08 2026 +0200 first diff --git a/00_Konzept/README_konzept.md b/00_Konzept/README_konzept.md new file mode 100644 index 0000000..f44917f --- /dev/null +++ b/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. diff --git a/01_3D-Druck/README_3d-druck.md b/01_3D-Druck/README_3d-druck.md new file mode 100644 index 0000000..d20ff20 --- /dev/null +++ b/01_3D-Druck/README_3d-druck.md @@ -0,0 +1,35 @@ +# 3D-Druck — Übersicht + +Alles, was der 3D-Druck-Producer braucht, um die haptischen Spielelemente zu +fertigen. Großflächige Grafik (Aufdrucke, Beschriftungen) wird **nicht** gedruckt, +sondern als Aufkleber/Print-Layout aufgebracht — die 3D-Teile liefern Form, +Verankerung und Steckmechanik. + +## Inhalt dieses Ordners + +| Datei | Zweck | +|-------|-------| +| [`materialliste.md`](materialliste.md) | Alle Bauteile mit Maßen, Mengen, Material- und Druckempfehlung | +| [`visual-prompts_3d-producer.md`](visual-prompts_3d-producer.md) | Bild-Prompts als Orientierungs-Renderings für den Producer | +| [`board-layout.svg`](board-layout.svg) | Maßstäbliche Layout-Skizze des gesamten Boards (exakt 40 Tiles, Sequenz, Loop) | +| `board-layout.png` | PNG-Vorschau der Layout-Skizze | +| [`gen_board_layout.py`](gen_board_layout.py) | Generator-Skript für die Layout-Skizze (bei Änderungen erneut ausführen) | +| [`openscad/`](openscad/) | Parametrische Modelle (OpenSCAD) der Schlüsselteile zum direkten Slicen | + +## Grundsätzliche Design-Entscheidungen + +- **Modulares Tile-System** statt eines großen Boards — jedes Teil passt auf ein übliches Druckbett (≥ 200 × 200 mm). +- **Lineare Bahn** (kein Ring) — Tiles werden zu einer durchgehenden Linie aneinandergereiht, bei Platzmangel mäandrierend. +- **Eine standardisierte Verankerung** (Ø 50 mm Rundsockel) für *alle* Plättchen und für den Action-Stein → Teile sind austauschbar. +- **Steckverbindungen** (Puzzle-Tabs) zwischen Tiles, damit die Bahn stabil zusammenhält und flexibel gelegt werden kann. +- **Materialempfehlung:** PLA für Tiles/Plättchen/Gates (formstabil, günstig), PLA + Gewichtseinlage (M8-Mutter) für den Action-Stein (Standfestigkeit mit aufrechter Karte). + +## Drucker-Annahmen + +- Bauraum mind. 220 × 220 × 220 mm. +- Düse 0,4 mm, Schichthöhe 0,2 mm. +- Beschriftungen werden als **vertiefte Gravur** (negativ, 0,6–1,0 mm tief) modelliert, alternativ als aufgeklebtes Label. + +> Alle Maße sind ein **Start-Spec** und vor der Serienfertigung an einem +> Funktionsmuster zu prüfen (insb. Passung Sockel↔Plättchen↔Stein und +> Kippstabilität des Steins mit Karte). diff --git a/01_3D-Druck/board-layout.png b/01_3D-Druck/board-layout.png new file mode 100644 index 0000000..639d011 Binary files /dev/null and b/01_3D-Druck/board-layout.png differ diff --git a/01_3D-Druck/board-layout.svg b/01_3D-Druck/board-layout.svg new file mode 100644 index 0000000..f26877f --- /dev/null +++ b/01_3D-Druck/board-layout.svg @@ -0,0 +1,310 @@ + + + +Service-Lifecycle — Board-Layout (40 Tiles) +37 Aktivitaeten + 3 Gates · 1 Tile = 100x100 mm · lineare Bahn, Sequenz links nach rechts + +DESIGN +4 Tiles + + + + +ds_01 +Eigenschaften definieren + + + + + +ds_02 +Komponenten designen + + + + + +ds_03 +Vorgehen beschreiben + + + + + +ds_04 +Implementierung vorbereiten + + +TRANSITION +12 Tiles + + + + +tr_01 +Entw. / Konfig.? + + + + + +tr_02 +Entwicklung koordinieren + + + + + +tr_03 +Anwendungen entwickeln + + + + + +tr_04 +Komponenten annehmen + + + + + +tr_05 +Komponenten konfigurieren + + + + + +tr_06 +Betriebsdoku erstellen + + + + + +tr_07 +Komponenten testen + + + + + +tr_08 +Formale Uebergabe + + + + + +tr_09 +Entry-Pruefung + + + + + +tr_10 +Ausrollen + + + + + +tr_11 +Aktivierung vorbereiten + + + + + +tr_12 +Go-Live-Freigabe + + +OPERATION +7 Tiles + + + + +op_01 +Early Life Support + + + + + +op_02 +Betriebs-Leitlinien + + + + + +op_03 +Laufender Betrieb + + + + + +op_04 +Ressourcen & Budget + + + + + +op_05 +Services ueberwachen + + + + + +op_06 +Qualitaetsbericht + + + + + +op_07 +Proaktive Problemerkennung + + +SUPPORT +11 Tiles + + + + +sp_01 +Support-Leitlinien + + + + + +sp_02 +Wissensdatenbank + + + + + +sp_03 +Incidents/Requests verteilen + + + + + +sp_04 +Requests bearbeiten + + + + + +sp_05 +Incident 1st Level + + + + + +sp_06 +Incident 2nd Level + + + + + +sp_07 +Record geloest + + + + + +sp_08 +Schliessen + + + + + +sp_09 +Problem Record anlegen + + + + + +sp_10 +Wiederk. Incidents -> Problem + + + + + +sp_11 +RCA & Workaround + + +REVIEW +6 Tiles + + + + +rv_01 +Taktische RCA + KPIs + + + + + +rv_02 +Performance & Improvement + + + + + +rv_03 +SOR Periodischer Review + + + + + +rv_04 +Service Improvement + + + + + +rv_05 +Redesign / Erweiterung + + + + + +rv_06 +Ausserbetriebnahme + +Betriebs-Loop + +zurueck in DPM +rv_05 Redesign / rv_06 Retirement + +Gate-Tile (Tor mit Rollen-Steckplaetzen) + +Aktivitaets-Tile (mit Verankerung fuer einseitiges Plaettchen) +Breiteste Phase: 12 Tiles ~ 134 cm (bei 100 mm Tiles + 12 mm Verbinder). Bahn bei Platzmangel maeandrierend faltbar. + \ No newline at end of file diff --git a/01_3D-Druck/gen_board_layout.py b/01_3D-Druck/gen_board_layout.py new file mode 100644 index 0000000..1a91b69 --- /dev/null +++ b/01_3D-Druck/gen_board_layout.py @@ -0,0 +1,202 @@ +#!/usr/bin/env python3 +"""Generiert die Board-Layout-Skizze (SVG) fuer den SLC-Workshop. +Lineares Phasen-Swimlane-Layout: jede Phase eine Zeile, Tiles links->rechts. +Exakt 40 Tiles (37 Aktivitaeten + 3 Gates). Reproduzierbar: bei Aenderungen +einfach erneut ausfuehren -> board-layout.svg. +""" + +# (id, kurzname, is_gate) +PHASES = [ + ("DESIGN", "#2F80C9", [ + ("ds_01", "Eigenschaften definieren", False), + ("ds_02", "Komponenten designen", False), + ("ds_03", "Vorgehen beschreiben", False), + ("ds_04", "Implementierung vorbereiten", False), + ]), + ("TRANSITION", "#E8893B", [ + ("tr_01", "Entw. / Konfig.?", True), + ("tr_02", "Entwicklung koordinieren", False), + ("tr_03", "Anwendungen entwickeln", False), + ("tr_04", "Komponenten annehmen", False), + ("tr_05", "Komponenten konfigurieren", False), + ("tr_06", "Betriebsdoku erstellen", False), + ("tr_07", "Komponenten testen", False), + ("tr_08", "Formale Uebergabe", False), + ("tr_09", "Entry-Pruefung", True), + ("tr_10", "Ausrollen", False), + ("tr_11", "Aktivierung vorbereiten", False), + ("tr_12", "Go-Live-Freigabe", True), + ]), + ("OPERATION", "#5BAE5B", [ + ("op_01", "Early Life Support", False), + ("op_02", "Betriebs-Leitlinien", False), + ("op_03", "Laufender Betrieb", False), + ("op_04", "Ressourcen & Budget", False), + ("op_05", "Services ueberwachen", False), + ("op_06", "Qualitaetsbericht", False), + ("op_07", "Proaktive Problemerkennung", False), + ]), + ("SUPPORT", "#3FB5B5", [ + ("sp_01", "Support-Leitlinien", False), + ("sp_02", "Wissensdatenbank", False), + ("sp_03", "Incidents/Requests verteilen", False), + ("sp_04", "Requests bearbeiten", False), + ("sp_05", "Incident 1st Level", False), + ("sp_06", "Incident 2nd Level", False), + ("sp_07", "Record geloest", False), + ("sp_08", "Schliessen", False), + ("sp_09", "Problem Record anlegen", False), + ("sp_10", "Wiederk. Incidents -> Problem", False), + ("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), + ]), +] + +# Layout-Parameter +TILE_W, TILE_H = 112, 74 +GAP_X, GAP_Y = 16, 46 +LABEL_W = 150 +X0 = 30 + LABEL_W + 20 +Y0 = 96 +MAX_TILES = max(len(t) for _, _, t in PHASES) +WIDTH = X0 + MAX_TILES * (TILE_W + GAP_X) + 200 +HEIGHT = Y0 + len(PHASES) * (TILE_H + GAP_Y) + 120 +TILE_MM = 100 # ein Tile = 100x100 mm + + +def esc(s): + return s.replace("&", "&").replace("<", "<").replace(">", ">") + + +def lighten(hexcol, f=0.85): + h = hexcol.lstrip("#") + r, g, b = int(h[0:2], 16), int(h[2:4], 16), int(h[4:6], 16) + r = int(r + (255 - r) * f) + g = int(g + (255 - g) * f) + b = int(b + (255 - b) * f) + return f"#{r:02x}{g:02x}{b:02x}" + + +def tile_svg(x, y, tid, name, color, is_gate): + fill = color if is_gate else lighten(color, 0.88) + stroke = color + sw = 3 if is_gate else 2 + txtcol = "#ffffff" if is_gate else "#1a1a1a" + parts = [] + # Puzzle-Notch links (Hintergrundfarbe), Bump rechts (Randfarbe) + parts.append(f'') + parts.append(f'') + parts.append(f'') + if is_gate: + # kleiner Torbogen + GATE-Label + ax, ay = x + TILE_W/2, y + 14 + parts.append(f'') + parts.append(f'{esc(tid)}') + parts.append(f'{esc(name)}') + else: + parts.append(f'') # Verankerung + parts.append(f'{esc(tid)}') + parts.append(f'{esc(name)}') + return "\n".join(parts) + + +def arrow(x1, y1, x2, y2, color="#666", w=2.2): + return (f'') + + +svg = [] +svg.append(f'') +svg.append(f'') +svg.append('' + '') +# Titel +svg.append(f'' + f'Service-Lifecycle — Board-Layout (40 Tiles)') +svg.append(f'' + f'37 Aktivitaeten + 3 Gates · 1 Tile = {TILE_MM}x{TILE_MM} mm · ' + f'lineare Bahn, Sequenz links nach rechts') + +row_y = {} +for ri, (pname, color, tiles) in enumerate(PHASES): + y = Y0 + ri * (TILE_H + GAP_Y) + row_y[pname] = y + # Phasen-Label + svg.append(f'') + svg.append(f'{esc(pname)}') + svg.append(f'{len(tiles)} Tiles') + # Tiles + prev = None + for ti, (tid, name, is_gate) in enumerate(tiles): + x = X0 + ti * (TILE_W + GAP_X) + if prev is not None: + svg.append(arrow(prev + 8, y + TILE_H/2, x - 2, y + TILE_H/2)) + svg.append(tile_svg(x, y, tid, name, color, is_gate)) + prev = x + TILE_W + # Connector zur naechsten Phase (von letztem Tile runter zur naechsten Zeile Start) + if ri < len(PHASES) - 1: + lastx = X0 + (len(tiles) - 1) * (TILE_W + GAP_X) + TILE_W/2 + ny = y + TILE_H + GAP_Y + svg.append(f'') + +# Operation <-> Support Loop (links neben den Labels) +oy = row_y["OPERATION"] + TILE_H/2 +sy = row_y["SUPPORT"] + TILE_H/2 +svg.append(f'') +svg.append(f'Betriebs-Loop') + +# Exit nach Review (DPM-Ruecklauf) +ry = row_y["REVIEW"] + TILE_H/2 +rx = X0 + (len(PHASES[-1][2]) - 1) * (TILE_W + GAP_X) + TILE_W +svg.append(arrow(rx + 6, ry, rx + 70, ry, color="#8E63B5", w=2.6)) +svg.append(f'zurueck in DPM') +svg.append(f'' + f'rv_05 Redesign / rv_06 Retirement') + +# Legende / Massstab +ly = HEIGHT - 64 +svg.append(f'') +svg.append(f'Gate-Tile (Tor mit Rollen-Steckplaetzen)') +svg.append(f'') +svg.append(f'Aktivitaets-Tile (mit Verankerung fuer einseitiges Plaettchen)') + +# Gesamtbreite-Hinweis +total_mm = MAX_TILES * (TILE_MM + 12) +svg.append(f'' + f'Breiteste Phase: {MAX_TILES} Tiles ~ {total_mm/10:.0f} cm ' + f'(bei {TILE_MM} mm Tiles + 12 mm Verbinder). Bahn bei Platzmangel maeandrierend faltbar.') + +svg.append('') + +out = "board-layout.svg" +with open(out, "w", encoding="utf-8") as f: + f.write("\n".join(svg)) + +total = sum(len(t) for _, _, t in PHASES) +gates = sum(1 for _, _, t in PHASES for _, _, g in t if g) +print(f"geschrieben: {out}") +print(f"Tiles gesamt: {total} (Aktivitaeten: {total-gates}, Gates: {gates})") diff --git a/01_3D-Druck/materialliste.md b/01_3D-Druck/materialliste.md new file mode 100644 index 0000000..a125583 --- /dev/null +++ b/01_3D-Druck/materialliste.md @@ -0,0 +1,131 @@ +# Materialliste — zu druckende Elemente + +Stand: 2026-05-27 · Maße in mm · Mengen für **ein** Workshop-Set. + +## Standard-Schnittstelle (für alle Teile gültig) + +- **Verankerung (Sockel):** zylindrische Vertiefung **Ø 50 mm, Tiefe 4 mm**, mit + 0,4 mm Spielpassung. Sowohl Aktivitätsplättchen als auch der Action-Stein-Fuß + passen hinein. +- **Tile-Steckverbindung:** Puzzle-Tab **12 mm breit, 6 mm tief**, mittig je Kante. +- **Figuren-Steckplatz:** Pin-Loch **Ø 4,2 mm, Tiefe 4 mm** (für Figuren-Pin Ø 4,0 mm). + Einheitlich am **Aktiv-Feld** und an den **Gate-Toren** — jede Figur passt überall. + +--- + +## 1. Phasen-Basistiles (lineare Bahn) + +| Merkmal | Wert | +|---------|------| +| Grundfläche | 100 × 100 × 6 mm | +| Verankerung | zentriert, Ø 50 × 4 mm | +| Kanten | Puzzle-Tabs (Tab/Slot abwechselnd) | +| Farbe | je Phase (blau/orange/grün/teal/lila) | +| Menge | **40** (eine je Lifecycle-ID: 37 Aktivitäten + 3 Gate-Positionen) | +| Material | PLA, Infill 15 % | +| Druckzeit | ~1,5 h/Tile | + +> Tiles bleiben bewusst **clean** (nur Verankerung + Tabs). Die Rollen-Platzierung +> übernimmt das mobile **Aktiv-Feld** (Abschnitt 4a), das neben dem Action-Stein steht. + +Alle Tiles sind **gerade** und werden zu einer **linearen Bahn** aneinandergereiht +(kein Ring). Bei Platzmangel kann die Bahn mäandrierend (Zeilenumbruch) gelegt +werden — die Puzzle-Tabs erlauben auch 90°-Ecken. + +## 2. Aktivitätsplättchen (einseitig) + +| Merkmal | Wert | +|---------|------| +| Form | Rundscheibe Ø 49 × 4 mm (passt in Verankerung) | +| Gravur | **einseitig: ID + Kurzbezeichnung** (z. B. `op_05 — Überwachen der Services`). Rückseite leer/Phasenfarbe — Erklärung liegt in der App | +| Griff | umlaufende Fase 1 mm zum leichten Herausnehmen | +| Menge | **37** (eine je Aktivität; an den 3 Gate-Positionen steht stattdessen ein Gate-Tor) | +| Material | PLA, je Phase eingefärbt (matcht Tile) | + +> Plättchen bleibt entnehmbar: beim Bearbeiten herausnehmen und den Action-Stein +> in die Verankerung stellen („wir sind hier"). Die ausführliche Auflösung kommt +> über die Companion-App, nicht über eine Rückseiten-Gravur. +> Bei zu kleiner Schrift für Gravur: glatte Scheibe drucken + bedrucktes Label aufkleben. + +## 3. Action-Stein (Szenario-Träger) + +| Merkmal | Wert | +|---------|------| +| Fuß | Ø 49 × 5 mm (sitzt in Verankerung) | +| Körper | Zylinder Ø 35, Höhe 30 mm | +| Kartenschlitz | Breite 74 mm, Tiefe 4 mm, Höhe 25 mm (für Karte 70 mm breit) | +| Gewichtseinlage | Aussparung für M8-Mutter im Fuß (Kippschutz) | +| Stabilitäts-Option | zusätzlicher Standring Ø 70 mm, falls Karte zu kopflastig | +| Menge | **1–2** | +| Material | PLA, Infill ≥ 40 % + Metalleinlage | + +## 4. Gate-Tore + +| Merkmal | Wert | +|---------|------| +| Form | Bogen/Tor, lichte Weite 90 mm, Höhe 100 mm, Materialstärke 8 mm | +| Standfüße | 2 × Grundplatte 30 × 60 mm, überspannt 2 Tiles | +| Rollen-Steckplätze | Lochreihe **Ø 4,2 mm** an der Basis (für Figuren-Pin), 4 Plätze, Pitch 8 mm | +| Kartenschlitz | oben quer, Breite 65 mm, Tiefe 3 mm (Gate-Beschreibungskarte) | +| Gravur | „Gate 1/2/3" + Gate-Keeper | +| Menge | **3** | +| Material | PLA, Infill 20 % | + +## 4a. Aktiv-Feld (RACI-Stecklochleiste) + +Mobile Leiste, die **neben dem Action-Stein** steht und mit ihm weiterwandert. +Hier werden die je Aktivität beteiligten Rollen-Figuren nach **RACI** gesteckt — +RACI wird so **pro Schritt** sichtbar, ohne die Tiles zu verändern. + +| Merkmal | Wert | +|---------|------| +| Grundkörper | ~86 × 26 × 6 mm (Länge ergibt sich aus den Zonen), Ecken r3 | +| Zonen | **R** (2 Plätze) · **A** (1 Platz) · **C** (3 Plätze) · **I** (3 Plätze) | +| Steckplätze | Ø 4,2 mm, Tiefe 4 mm, Pitch 8 mm (für Figuren-Pin Ø 4,0) | +| Gravur | Zonen-Buchstaben R / A / C / I vorne, Tiefe 0,8 mm | +| Menge | **1** (ggf. 2 bei parallelen Tischen) | +| Material | PLA, Infill 20 % | + +> **A = genau 1 Platz** — bildet ab, dass je Aktivität genau eine Rolle +> *Accountable* ist (RACI-Regel aus `spm_rollen.yaml`). Nicht jeder Platz muss +> belegt sein; die Leiste ist großzügig ausgelegt. +> Optional: Rastnase, damit die Leiste an den Action-Stein-Fuß andockt. + +## 5. Rollen-Figuren + +| Merkmal | Wert | +|---------|------| +| Form | Schlanker Pöppel, Höhe ~22 mm, **Standfuß-Pin Ø 4,0 mm × 4 mm** (passt in Aktiv-Feld & Gate-Loch Ø 4,2) | +| Standfläche | schmal (~8 mm), damit mehrere Figuren in einer Zonen-Reihe nebeneinander stehen | +| Codierung | Farbe + Formvariante je Rollenkategorie | +| Menge | siehe `../02_Spielfiguren/` (Governance, Management, Teams) | +| Material | PLA, eingefärbt | + +## 6. Entscheidungs-Chips (optional 3D statt Karte) + +| Merkmal | Wert | +|---------|------| +| Form | Münze Ø 30 × 4 mm, Symbolgravur | +| Varianten | Go / Go mit Auflagen / Zurück / Ablehnung | +| Menge | je 3 | +| Material | PLA | + +--- + +## Stückliste (Kurzfassung) + +| Teil | Menge | Datei | +|------|------:|-------| +| Phasen-Basistile | 40 | `openscad/aktivitaets-tile.scad` | +| Aktivitätsplättchen | 37 | `openscad/aktivitaets-plaque.scad` | +| Action-Stein | 2 | `openscad/action-stein.scad` | +| Aktiv-Feld (RACI-Leiste) | 1 | `openscad/aktiv-feld.scad` | +| Gate-Tor | 3 | `openscad/gate-tor.scad` | +| Rollen-Figuren | ~20 | (Standard-Meeple-Modell + Einfärbung) | +| Entscheidungs-Chips | 12 | (einfache Münze + Gravur) | + +## Hinweise für den Producer + +- Toleranzen Sockel/Plättchen an **einem Probedruck** kalibrieren (Drucker-spezifisch). +- Gravurtiefe 0,6–1,0 mm; bei sehr kleiner Schrift Label-Variante wählen. +- Farbtrennung über Filamentwechsel je Phase, nicht über Lackierung (abriebfest). diff --git a/01_3D-Druck/openscad/README_openscad.md b/01_3D-Druck/openscad/README_openscad.md new file mode 100644 index 0000000..51b40f0 --- /dev/null +++ b/01_3D-Druck/openscad/README_openscad.md @@ -0,0 +1,33 @@ +# OpenSCAD-Modelle + +Parametrische Quellmodelle der Schlüsselteile. In [OpenSCAD](https://openscad.org) +öffnen, Parameter im Customizer anpassen, mit **F6** rendern und über +*Datei → Export → STL* slicebereit exportieren. + +| Datei | Bauteil | +|-------|---------| +| `aktivitaets-tile.scad` | Phasen-Basistile (100×100, Verankerung Ø50, Puzzle-Tabs) | +| `aktivitaets-plaque.scad` | Beidseitiges Aktivitätsplättchen (Ø49) — Text per Variable | +| `action-stein.scad` | Szenario-Träger mit Kartenschlitz + M8-Gewichtsaussparung | +| `gate-tor.scad` | Gate-Tor mit 4 Rollen-Steckplätzen + Kartenschlitz | + +## Serienfertigung der Plättchen + +`aktivitaets-plaque.scad` enthält den Text als Variablen (`front_id`, +`front_name`, `back_text`). Für alle 38 Aktivitäten empfiehlt sich ein kleines +Skript, das die Werte aus den `service-lifecycle_*.yaml` liest und je Aktivität +ein STL erzeugt (z.B. via OpenSCAD-Kommandozeile `-D` Parameter-Override): + +```bash +openscad -o op_05.stl \ + -D 'front_id="op_05"' \ + -D 'front_name="Ueberwachen der Services"' \ + -D 'back_text="..."' \ + aktivitaets-plaque.scad +``` + +## Hinweise + +- Gravur-Text bewusst kurz halten; lange Kurzbeschreibungen ggf. auf Label auslagern. +- Umlaute in Gravuren je nach Font kritisch — im Zweifel `ae/oe/ue` verwenden (so in den Vorlagen). +- Vor Serienstart **ein** Tile + Plättchen + Stein als Passungs-Funktionsmuster drucken. diff --git a/01_3D-Druck/openscad/action-stein.scad b/01_3D-Druck/openscad/action-stein.scad new file mode 100644 index 0000000..55142de --- /dev/null +++ b/01_3D-Druck/openscad/action-stein.scad @@ -0,0 +1,42 @@ +// Action-Stein: Szenario-Traeger mit aufrechtem Kartenschlitz +// SLC-Workshop Tabletop · Einheiten: mm + +/* [Fuss] */ +foot_d = 49; // sitzt in Verankerung (Ø50) +foot_h = 5; +stand_ring = 70; // optionaler Standring fuer Kippstabilitaet +use_ring = true; + +/* [Koerper] */ +body_d = 35; +body_h = 30; + +/* [Kartenschlitz] */ +card_w = 74; // fuer Karte 70 mm breit +card_t = 4; // Schlitzdicke +card_h = 25; // Einstecktiefe + +/* [Gewichtseinlage M8] */ +nut_af = 13; // Schluesselweite M8-Mutter +nut_h = 6.5; +$fn = 96; + +module base() { + if (use_ring) + cylinder(d = stand_ring, h = 2); + translate([0,0,0]) cylinder(d = foot_d, h = foot_h); +} + +module body() { + translate([0,0,foot_h]) cylinder(d = body_d, h = body_h); +} + +difference() { + union() { base(); body(); } + // Kartenschlitz (zentriert in X, durch den Koerperkopf) + translate([-card_w/2, -card_t/2, foot_h + body_h - card_h]) + cube([card_w, card_t, card_h + 1]); + // Gewichtsaussparung im Fuss (Sechskant fuer M8-Mutter) + translate([0, 0, -0.1]) + cylinder(d = nut_af / cos(30), h = nut_h, $fn = 6); +} diff --git a/01_3D-Druck/openscad/aktiv-feld.scad b/01_3D-Druck/openscad/aktiv-feld.scad new file mode 100644 index 0000000..7e5886f --- /dev/null +++ b/01_3D-Druck/openscad/aktiv-feld.scad @@ -0,0 +1,77 @@ +// Aktiv-Feld — RACI-Stecklochleiste +// SLC-Workshop Tabletop · Einheiten: mm +// Steht NEBEN dem Action-Stein. Bei jeder Aktivitaet werden die beteiligten +// Rollen-Figuren nach RACI in die passende Zone gesteckt: +// R = Responsible · A = Accountable (genau 1) · C = Consulted · I = Informed +// Anpassen und mit OpenSCAD nach STL exportieren (F6 -> Export). + +/* [Leiste] */ +strip_w = 26; // Tiefe (zum Spieler) +strip_h = 6; // Dicke +corner_r = 3; + +/* [Steckplaetze] */ +pin_hole_d = 4.2; // Loch fuer Figuren-Pin (Pin Oe 4,0 + Spiel) +pin_hole_depth = 4; +pin_pitch = 8; // Mitte-zu-Mitte innerhalb einer Zone +zone_gap = 10; // Luecke zwischen den Zonen +end_margin = 8; // Rand links/rechts +socket_y = 5; // Lochreihe nach hinten versetzt (weg von der Beschriftung) + +/* [Beschriftung] */ +label_size = 7; // Buchstabengroesse +label_depth = 0.8; // Gravurtiefe +label_y = -8; // Position der Buchstaben (vorne, zum Spieler) + +/* [Zonen] */ +// [Label, Anzahl Steckplaetze] — A bewusst nur 1 (genau eine Rolle accountable) +zones = [ ["R", 2], ["A", 1], ["C", 3], ["I", 3] ]; + +$fn = 48; + +// --- Hilfsfunktionen ------------------------------------------------------- +function zone_span(c) = (c - 1) * pin_pitch; + +function sumspan(i = 0) = + i >= len(zones) ? 0 : zone_span(zones[i][1]) + sumspan(i + 1); + +function total_len() = + end_margin * 2 + zone_gap * (len(zones) - 1) + sumspan(); + +// linker Startversatz der Zone idx (Summe vorheriger Zonen + Luecken) +function zone_offset(idx, i = 0, acc = 0) = + i >= idx ? acc + : zone_offset(idx, i + 1, acc + zone_span(zones[i][1]) + zone_gap); + +// --- Geometrie ------------------------------------------------------------- +module rounded_rect(l, w, h, r) { + linear_extrude(h) + offset(r) offset(-r) + square([l, w], center = true); +} + +module raci_strip() { + L = total_len(); + difference() { + rounded_rect(L, strip_w, strip_h, corner_r); + + for (idx = [0 : len(zones) - 1]) { + cnt = zones[idx][1]; + sx = -L/2 + end_margin + zone_offset(idx); + + // Steckplaetze der Zone + for (i = [0 : cnt - 1]) + translate([sx + i * pin_pitch, socket_y, strip_h - pin_hole_depth]) + cylinder(d = pin_hole_d, h = pin_hole_depth + 0.1); + + // Zonen-Beschriftung (mittig unter den Loechern) + cx = sx + zone_span(cnt) / 2; + translate([cx, label_y, strip_h - label_depth]) + linear_extrude(label_depth + 0.1) + text(zones[idx][0], size = label_size, + halign = "center", valign = "center"); + } + } +} + +raci_strip(); diff --git a/01_3D-Druck/openscad/aktivitaets-plaque.scad b/01_3D-Druck/openscad/aktivitaets-plaque.scad new file mode 100644 index 0000000..584d63e --- /dev/null +++ b/01_3D-Druck/openscad/aktivitaets-plaque.scad @@ -0,0 +1,48 @@ +// Beidseitiges Aktivitaetsplaettchen (Rundscheibe fuer Verankerung) +// SLC-Workshop Tabletop · Einheiten: mm +// Text per Variable setzen; fuer Serie ueber Skript je Aktivitaet generieren. + +/* [Scheibe] */ +disc_d = 49; // Durchmesser (Verankerung 50 - Passung) +disc_h = 4; // Dicke +chamfer = 1; // Fase als Griffhilfe + +/* [Gravur] */ +engrave_depth = 0.8; +front_id = "op_05"; +front_name = "Ueberwachen der Services"; +back_text = "Laufende Ueberwachung von Verfuegbarkeit, Leistung und Qualitaet des Service."; +font = "Liberation Sans:style=Bold"; +$fn = 96; + +module disc_body() { + // Scheibe mit beidseitiger Fase + hull() { + cylinder(d = disc_d - 2*chamfer, h = 0.01); + translate([0,0,chamfer]) cylinder(d = disc_d, h = disc_h - 2*chamfer); + translate([0,0,disc_h-0.01]) cylinder(d = disc_d - 2*chamfer, h = 0.01); + } +} + +module front_engraving() { + translate([0, 6, disc_h - engrave_depth]) + linear_extrude(engrave_depth + 0.1) + text(front_id, size=7, halign="center", font=font); + translate([0, -6, disc_h - engrave_depth]) + linear_extrude(engrave_depth + 0.1) + text(front_name, size=3.2, halign="center", font=font); +} + +module back_engraving() { + // gespiegelt, weil Rueckseite + mirror([1,0,0]) + translate([0, 0, -0.1]) + linear_extrude(engrave_depth + 0.1) + text(back_text, size=2.6, halign="center", font=font); +} + +difference() { + disc_body(); + front_engraving(); + back_engraving(); +} diff --git a/01_3D-Druck/openscad/aktivitaets-tile.scad b/01_3D-Druck/openscad/aktivitaets-tile.scad new file mode 100644 index 0000000..f69fbc9 --- /dev/null +++ b/01_3D-Druck/openscad/aktivitaets-tile.scad @@ -0,0 +1,52 @@ +// Phasen-Basistile mit zentraler Verankerung und Puzzle-Tabs +// SLC-Workshop Tabletop · Einheiten: mm +// Anpassen und mit OpenSCAD nach STL exportieren (F6 -> Export). + +/* [Tile] */ +tile_size = 100; // Kantenlaenge +tile_height = 6; // Dicke +corner_r = 3; // Eckenradius + +/* [Verankerung / Sockel] */ +socket_d = 50; // Durchmesser Vertiefung +socket_depth = 4; // Tiefe +fit_clear = 0.4; // Spielpassung + +/* [Puzzle-Tabs] */ +tab_w = 12; // Breite +tab_d = 6; // Tiefe (Ueberstand / Aussparung) +tab_h = tile_height; +$fn = 64; + +module rounded_square(s, r, h) { + linear_extrude(h) + offset(r) offset(-r) + square([s, s], center=true); +} + +module tab(positive=true) { + // Tab ragt heraus (positive) oder wird ausgespart (negative) + d = positive ? tab_d : tab_d + fit_clear; + w = positive ? tab_w : tab_w + fit_clear; + translate([0, 0, tab_h/2]) + cube([w, d*2, tab_h], center=true); +} + +module tile() { + difference() { + union() { + rounded_square(tile_size, corner_r, tile_height); + // Tabs an Nord- und Ost-Kante (positive) + translate([0, tile_size/2, 0]) tab(true); + translate([ tile_size/2, 0, 0]) rotate([0,0,90]) tab(true); + } + // Verankerung + translate([0, 0, tile_height - socket_depth]) + cylinder(d = socket_d + fit_clear, h = socket_depth + 0.1); + // Slots an Sued- und West-Kante (negative) + translate([0, -tile_size/2, 0]) tab(false); + translate([-tile_size/2, 0, 0]) rotate([0,0,90]) tab(false); + } +} + +tile(); diff --git a/01_3D-Druck/openscad/gate-tor.scad b/01_3D-Druck/openscad/gate-tor.scad new file mode 100644 index 0000000..f635976 --- /dev/null +++ b/01_3D-Druck/openscad/gate-tor.scad @@ -0,0 +1,70 @@ +// Gate-Tor mit Rollen-Steckplaetzen und Kartenschlitz +// SLC-Workshop Tabletop · Einheiten: mm + +/* [Tor] */ +opening_w = 90; // lichte Weite +opening_h = 100; // lichte Hoehe +thick = 8; // Materialstaerke (Tiefe) +post_w = 12; // Pfostenbreite +top_h = 14; // Hoehe des Querbalkens + +/* [Fuesse] */ +foot_w = 60; +foot_d = 30; +foot_h = 4; + +/* [Rollen-Steckplaetze] */ +peg_d = 8.2; // Loch fuer Figuren-Pin (Ø7,5 + Passung) +peg_count = 4; +peg_depth = 6; + +/* [Kartenschlitz oben] */ +card_w = 65; +card_t = 3; +card_depth = 10; +$fn = 48; + +total_w = opening_w + 2*post_w; +total_h = opening_h + top_h + foot_h; + +module arch() { + difference() { + // Aussenkontur + translate([-total_w/2, 0, 0]) + cube([total_w, thick, opening_h + top_h]); + // Oeffnung + translate([-opening_w/2, -0.1, 0]) + cube([opening_w, thick + 0.2, opening_h]); + } +} + +module feet() { + for (x = [-1, 1]) + translate([x*(opening_w/2 + post_w/2) - foot_w/2, -(foot_d-thick)/2, 0]) + cube([foot_w, foot_d, foot_h]); +} + +module peg_holes() { + // Lochreihe entlang der Vorderkante der Fuesse + spacing = (opening_w + post_w) / (peg_count - 1); + for (i = [0 : peg_count - 1]) + translate([-(opening_w + post_w)/2 + i*spacing, foot_d/2 - peg_d, foot_h]) + rotate([180,0,0]) + cylinder(d = peg_d, h = peg_depth); +} + +module card_slot() { + translate([-card_w/2, thick/2 - card_t/2, opening_h + top_h - card_depth]) + cube([card_w, card_t, card_depth + 0.1]); +} + +// Tor inkl. Kartenschlitz +difference() { + translate([0,0,foot_h]) arch(); + translate([0,0,foot_h]) card_slot(); +} +// Fuesse inkl. Rollen-Steckplaetze +difference() { + feet(); + peg_holes(); +} diff --git a/01_3D-Druck/visual-prompts_3d-producer.md b/01_3D-Druck/visual-prompts_3d-producer.md new file mode 100644 index 0000000..411a2e4 --- /dev/null +++ b/01_3D-Druck/visual-prompts_3d-producer.md @@ -0,0 +1,125 @@ +# Visual-Prompts für den 3D-Druck-Producer + +Diese Prompts erzeugen **Orientierungs-Renderings** (kein Marketing-Bild), +die dem Producer Form, Proportion und Steckmechanik der Bauteile zeigen. +Empfohlen für Bildmodelle wie Nano Banana / Imagen. Englisch erzielt meist die +sauberste Geometrie; Beschriftungen bewusst sparsam halten. + +> **Board-Layout:** linear (durchgehende Bahn), **kein Kreis**. +> **Wichtig:** die **einseitigen, entnehmbaren Aktivitätsplättchen** müssen +> sichtbar sein — einige liegen flach in der Verankerung (Code-Seite oben), +> einige sind herausgenommen und liegen daneben (Rückseite leer), sodass die +> **freie Verankerung** erkennbar ist (dort steht dann der Action-Stein). +> *(Stand v0.2-Renderings — Erklärung liegt inzwischen in der App, nicht auf der +> Rückseite; RACI-Aktiv-Feld + verschlankte Figuren sind hier noch nicht abgebildet.)* + +--- + +## Prompt A — Bauteil-Übersicht (Exploded-Style) + +``` +Clean technical product render, neutral light-grey studio background, exploded +view of a set of 3D-printed tabletop game components in matte PLA. Show: a square +modular base tile (100x100mm) with puzzle-tab edges and a round centered recess; +a round single-sided insert disc that fits the recess (top face with a short +engraved code, plain back); a cylindrical game token +with a wide weighted base and a vertical card slot on top; a small upright +arch-shaped "gate" with peg holes at its base; a meeple figure with a round pin +foot. Parts floating slightly apart to show how they connect. Soft shadows, +isometric angle, high detail, dimension-focused, minimal text. +``` + +## Prompt B — Aktivitätsplättchen: einseitig & entnehmbar + +``` +Close-up technical render of round single-sided game discs in matte colored PLA, +each about 49mm diameter and 4mm thick with a chamfered edge for easy gripping. +Three discs shown: one sitting flush inside a square tile's round recess (top face +showing a short engraved activity code), one lifted out by fingers, and one lying +beside the tile with a plain blank back. The empty recess of one tile is clearly +visible (this is where the upright action token will stand). Emphasis on the +removable fit and the freed socket. Neutral grey background, soft studio light, +shallow depth of field, premium board-game component photography. +``` + +## Prompt C — Action-Stein im Detail + +``` +Close-up technical render of a single 3D-printed game token, matte white PLA. +Cylindrical body on a wide round base, with a vertical slot on top holding an +upright rectangular card. The base diameter is clearly wider than the body for +stability. The token stands inside a square tile's round recess (the same recess +that normally holds an activity disc). Quarter-section cutaway shows a hexagonal +cavity in the base for a metal weight. Neutral grey background, soft studio +lighting, isometric, emphasis on proportions and the card slot fit, no decorative +text. +``` + +## Prompt D — Gate-Tor mit Rollen-Steckplätzen + +``` +Technical product render of a small upright arch-shaped game piece in matte PLA, +like a doorway about 100mm tall with 90mm clear opening, 8mm thick. Two flat feet +at the base spanning two tiles of a straight track. A row of four small round holes +along the front base edge for inserting pin-footed figures. A thin horizontal slot +across the top of the arch holding a small reference card. A round-pin meeple figure +is inserted in one of the base holes. Neutral background, isometric, soft shadows, +focus on the peg-hole mechanism, minimal text. +``` + +## Prompt E — Tile-Steckmechanik (gerade Bahn) + +``` +Top-down and slight-angle technical render of four square modular game tiles +(matte PLA, different solid colors: blue, orange, green, teal) connected via +puzzle-tab edges into a STRAIGHT row / track. Each tile has a round recessed socket +in its center: two sockets hold flat round single-sided discs (engraved code on +top), one socket is empty showing the recess, one holds a small upright arch gate. Clean grey background, soft light, isometric, emphasis on how +tiles interlock into a straight line, minimal text. +``` + +## Prompt F — Komplettaufbau (Referenz für Proportionen) + +``` +Wide isometric technical render of a fully assembled LINEAR tabletop game on a +neutral surface: square color-coded tiles connected into a long straight track +left to right through five color zones (blue, orange, green, teal, purple); two of +the zones (green and teal) sit side by side with two curved arrows forming a small +loop between them; three upright arch gates stand on the track; small meeple figures +placed at the gates; round single-sided activity discs sit in the tile sockets with +a couple lifted out leaving empty sockets; one cylindrical token with an +upright card stands in a socket; at the right end two exit arrows lead off the board. +Matte PLA materials, soft studio lighting, clean and diagrammatic, +proportion-accurate, minimal text. +``` + +## Prompt G — Gesamtaufbau, 40 Einzeltiles (Tisch-Optik) + +> Hinweis: Bild-KIs zählen nicht zuverlässig — die exakte Tile-Zahl ist über +> [`board-layout.svg`](board-layout.svg) garantiert. Dieser Prompt liefert die +> **Optik/Stimmung**, nicht die exakte Anzahl. Raster explizit vorgeben erhöht +> die Trefferquote. + +``` +Isometric high-angle photograph of a complete modular tabletop board on a large +wooden meeting table, spanning about 1.2 meters. The board is assembled from many +small individual square puzzle tiles interlocking via tab-and-slot edges; each tile +is one lifecycle step. Tiles are color-grouped into five phases laid out as fixed +grids: DESIGN (blue) 4 tiles, TRANSITION (orange) 12 tiles with three of them marked +by a small upright arch gate, OPERATION (green) 7 tiles, SUPPORT (teal) 11 tiles, +REVIEW (purple) 6 tiles. Each tile has a round recessed socket holding a flat +single-sided disc; a few discs are lifted out leaving empty sockets. Between the green and teal phases two curved arrows form a +small loop; two exit arrows leave the purple phase at the right. A cylindrical token +with an upright card stands in a socket at the start. A coffee mug and notebook give +scale. Soft daylight, matte PLA surfaces, clean modern design, large phase labels +only, minimal small text. +``` + +--- + +### Hinweise zum Einsatz + +- Prompts A–D sind **Bauteil-Referenzen** (für Fertigung), Prompt E zeigt die **Steckmechanik**, Prompt F den **Gesamtaufbau** (lineare Bahn). +- **Prompt B** zeigt die einseitigen, entnehmbaren Plättchen und die freigelegte Verankerung (dort steht der Action-Stein). +- Verbindliche Maße stehen in [`materialliste.md`](materialliste.md) und in den OpenSCAD-Modellen — die Bilder dienen nur der Orientierung, nicht als Maßvorlage. +- Bei unsauberer Geometrie: Anzahl beschriebener Teile pro Prompt reduzieren. diff --git a/02_Spielfiguren/README_spielfiguren.md b/02_Spielfiguren/README_spielfiguren.md new file mode 100644 index 0000000..1026d94 --- /dev/null +++ b/02_Spielfiguren/README_spielfiguren.md @@ -0,0 +1,82 @@ +# Spielfiguren — Rollen + +Die Figuren bilden die Rollen aus dem Service-Lifecycle ab. Quelle: +[`spm_rollen.yaml`](../../../%2302_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/spm_rollen.yaml) (v1.1). + +Jede Figur ist ein schlanker Pöppel mit **Pin-Fuß Ø 4,0 mm**, der in die +einheitlichen Steckplätze (Ø 4,2 mm) von **Aktiv-Feld und Gate-Toren** passt. +Codierung über **Farbe** (Kategorie) und optional **Formvariante**. + +> **Platzierung (v0.3):** Figuren werden nicht nur an Gates gesteckt, sondern bei +> **jeder Aktivität** in das mobile **Aktiv-Feld** neben dem Action-Stein — in die +> passende **RACI-Zone (R/A/C/I)**. So wird pro Schritt sichtbar, *wer* in *welcher +> Verantwortung* agiert. Deshalb: schlanke Figuren (Standfläche ≤ 8 mm), damit +> mehrere in einer Zonen-Reihe (Pitch 8 mm) nebeneinander passen. +> Aktiv-Feld-Maße: [`../01_3D-Druck/openscad/aktiv-feld.scad`](../01_3D-Druck/openscad/aktiv-feld.scad). + +> **Design-Varianten je Rolle:** konkrete Figuren-Entwürfe (3 Stil-Tracks + +> Bild-KI-Prompts) für alle 16 Rollen in [`figuren-varianten.md`](figuren-varianten.md). +> **Ausgearbeitetes Set B** (stilisierte Minifiguren, einheitlicher runder Sockel): +> [`figuren-set-b_minifiguren.md`](figuren-set-b_minifiguren.md). + +## Rollen & Codierung + +### Governance (Entscheider) — Gold/Gelb +| Figur | Kürzel | Rolle | +|-------|--------|-------| +| Service-Portfolio-Manager | SPM | strategische Portfolio-Steuerung | +| Service Owner | SO | End-to-End-Verantwortung je Service | +| Service Operations Runde | SOR | Gremium (Freigaben, Betriebsreife) | + +> **SOR ist ein Gremium**, kein Einzelner. Praktisch wird die SOR durch ihre +> ständigen Mitglieder am Tor repräsentiert: **SPM + SO + AL B&C + AL App**. +> Optional eine eigene „SOR"-Sammelfigur als Marker. + +### Management (operative Führung) — Blau +| Figur | Kürzel | +|-------|--------| +| Abteilungsleitung Basis & Cloud | AL B&C | +| Abteilungsleitung Applikationen | AL App | +| Support Manager | Sup Mgr | +| Problem Manager | Prob Mgr | +| Projektleitung | PL | + +### Teams (Sammelfiguren) — Grün +| Figur | Kürzel | +|-------|--------| +| Betriebsteam | Betrieb | +| Service-Support Team | Support | +| Projektteam | Projekt | + +### Operative Einzelrollen — Grau (optional, für Detailtiefe) +Queue Koordinator, 1st Level Agent, 2nd Level Agent, Testmanagement, Architektur. + +### Externe — Weiß +Lieferant / Hersteller / Entwickler. + +## Gate-Zuordnung (wer muss zusammenkommen) + +| Gate | ID | Gate-Keeper | Pflicht-Figuren am Tor | +|------|----|-------------|------------------------| +| Gate 1 | tr_01 | SOR | SPM + SO + AL B&C + AL App | +| Gate 2 | tr_09 | SO | SO | +| Gate 3 | tr_12 | SOR | SPM + SO + AL B&C + AL App | + +**Regel:** Ein Gate „öffnet" erst, wenn alle Pflicht-Figuren in seinen +Steckplätzen stehen. Fehlt eine Rolle, kann nicht entschieden werden — das macht +die Governance-Anforderung körperlich erfahrbar. + +## Phasen-Beteiligung (für Embodiment-Modus) + +Aus `lifecycle_relevanz` der Rollen-YAML — wer in welcher Phase „sprechen" muss: + +- **Design:** SPM, SO, PL, Projektteam, Architektur, Testmanagement, Lieferant +- **Transition:** SPM, SOR, SO, AL B&C, AL App, Sup Mgr, PL, Projekt-/Betriebsteam, Lieferant +- **Operation:** SO, AL B&C, AL App, Betriebsteam +- **Support:** SO, Sup Mgr, Prob Mgr, Support-Team, Queue Koord, L1, L2, Lieferant +- **Review:** SPM, SOR, SO, Prob Mgr + +## Mengen (ein Set) + +Je Pflicht-/Hauptrolle 1 Figur; Teams je 1; operative Rollen optional. Richtwert +**~20 Figuren**. Für größere Gruppen Governance-/SOR-Figuren ggf. doppeln. diff --git a/02_Spielfiguren/figuren-set-b_minifiguren.md b/02_Spielfiguren/figuren-set-b_minifiguren.md new file mode 100644 index 0000000..1987326 --- /dev/null +++ b/02_Spielfiguren/figuren-set-b_minifiguren.md @@ -0,0 +1,176 @@ +# Figuren-Set B — Stilisierte Minifiguren (runder Sockel) + +Track-B-Umsetzung für **alle 16 Rollen**: charaktervolle, brettspieltypische +Minifiguren — alle auf dem **gleichen schlanken runden Sockel**, damit sie in +dieselben Steckplätze (Tile-Reihe **und** Gate, Ø 4,2 mm) passen und als +geschlossenes Set wirken. + +> **Wichtig (v0.3):** Da bei jeder Aktivität mehrere Figuren in einer Zonen-Reihe +> des **Aktiv-Felds** (neben dem Action-Stein) stehen (Pitch **8 mm**), muss der +> Sockel **schlank** sein (Ø ≤ 8 mm) und der Pin **Ø 4,0 mm**. Kein breiter +> Diorama-Sockel — sonst kollidieren Nachbarfiguren. + +Rollenquelle: [`spm_rollen.yaml`](../../../%2302_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/spm_rollen.yaml) (v1.1). + +--- + +## Style-Bible (gilt für ALLE 16 Figuren — vor jeden Prompt setzen) + +> `Stylized board-game miniature character in matte PLA, chunky friendly proportions +> (large head, simplified body, no thin fragile parts), standing on an identical +> small ROUND disc base ~8mm diameter with a centered round pin foot Ø4mm +> underneath. Figure height ~22mm including base. Clean technical product render, +> neutral light-grey studio background, soft studio light, isometric, high detail, +> tiny role abbreviation engraved on the back of the base.` + +**Damit das Set zusammenpasst:** +- **Identischer schlanker Rundsockel** für jede Figur (Ø ~8 mm, gleiche Höhe, Pin Ø 4 mm) — passt in Tile-Reihe und Gate. +- Gleiche **Proportionen** (großer Kopf, gedrungener Körper) — variiert wird nur Pose + Attribut. +- **Farbe = Kategorie:** Governance Gold/Gelb · Management Blau · Teams Grün · Operative Grau · Externe Weiß. +- Attribut/Requisit darf in Kontrastton abgesetzt sein. +- Keine dünnen, bruchgefährdeten Teile (druck- & spielfest). + +> **Ausnahme Sammelfiguren (SOR, Teams):** Diese dürfen einen breiteren Sockel +> haben (Diorama/Trio). Sie stehen dann **neben** dem Aktiv-Feld bzw. überspannen +> 2 Steckplätze einer Zone — nicht einzeln in der schmalen 8-mm-Reihe. +> Einzelrollen bleiben beim schlanken Ø-8-mm-Sockel. + +--- + +# GOVERNANCE — Gold/Gelb + +### SPM — Service-Portfolio-Manager +Strategischer Steuermann des ganzen Portfolios. +``` +gold matte miniature character, confident standing pose, wearing a small pointed crown, holding up a fanned spread of three tiny service tiles in one hand, the other hand resting on a small ship's-wheel/compass, "SPM" engraved on the round base rim. +``` + +### SO — Service Owner +Hütet einen einzelnen Service end-to-end. +``` +gold matte miniature character, protective stance cradling a single glowing round service orb with a tiny name-plate against its chest, a key pendant hanging at the neck, "SO" engraved on the round base rim. +``` + +### SOR — Service Operations Runde *(Gremium)* +Marker-Figur: das Entscheider-Gremium. +``` +gold matte miniature marker on the same round disc base: a miniature round council table with four tiny stylized seats around it and a small judge's gavel standing upright in the center, "SOR" engraved on the round base rim. +``` + +--- + +# MANAGEMENT — Blau + +### AL B&C — Abteilungsleitung Basis & Cloud +Infrastruktur: Netze, Server, Cloud. +``` +blue matte miniature character, sturdy pose, torso stylized as a small ribbed server rack, a little cloud floating just above the head, holding a server module under one arm, "AL B&C" engraved on the round base rim. +``` + +### AL App — Abteilungsleitung Applikationen +Anwendungen, Fachverfahren. +``` +blue matte miniature character, holding an upright glowing application window panel with a title bar and three dots, a small "" badge on the chest, "AL App" engraved on the round base rim. +``` + +### Sup Mgr — Support Manager +Organisiert & sichert den Support. +``` +blue matte miniature character wearing a headset with a boom mic, holding a clipboard with a checkmark, organizing/directing pose, "Sup Mgr" engraved on the round base rim. +``` + +### Prob Mgr — Problem Manager +Root-Cause-Jäger. +``` +blue matte miniature character in a detective pose holding an oversized magnifying glass up near its face, a small root/branch pattern at its feet, "Prob Mgr" engraved on the round base rim. +``` + +### PL — Projektleitung +Taktgeber des Projekts. +``` +blue matte miniature character wearing a hard hat, holding a clipboard with a Gantt-bar chart, raising a small pennant baton in the other hand, "PL" engraved on the round base rim. +``` + +--- + +# TEAMS (Sammelfiguren) — Grün +*Als „mehrere Personen" lesbar — Trio auf einem gemeinsamen runden Sockel.* + +### Betrieb — Betriebsteam +Laufender Betrieb, Monitoring, Deployment. +``` +green matte miniature: three chunky figures grouped together on one shared round disc base, a gear and a heartbeat monitor line motif between them, busy working pose, "Betrieb" engraved on the round base rim. +``` + +### Support — Service-Support Team +1st/2nd-Level, Nutzeranfragen. +``` +green matte miniature: three chunky figures grouped on one shared round disc base, each wearing a small headset, a speech bubble above the group, "Support" engraved on the round base rim. +``` + +### Projekt — Projektteam +Entwicklung, Test, Doku, Übergabe. +``` +green matte miniature: three chunky figures grouped on one shared round disc base, leaning over a rolled-out blueprint with a wrench beside them, "Projekt" engraved on the round base rim. +``` + +--- + +# OPERATIVE EINZELROLLEN — Grau + +### Queue Koord — Queue Koordinator +Ticket-Lotse. +``` +grey matte miniature character in a traffic-controller pose holding a signal paddle, branching routing arrows on the round base surface, "Queue" engraved on the round base rim. +``` + +### L1 — 1st Level Agent +Erste Anlaufstelle. +``` +grey matte miniature character, slim friendly pose wearing a headset, a large number "1" on its chest, "L1" engraved on the round base rim. +``` + +### L2 — 2nd Level Agent +Tiefe Analyse. +``` +grey matte miniature character wearing a headset, holding a screwdriver, a large number "2" on its chest, leaning over an opened device, "L2" engraved on the round base rim. +``` + +### Test Mgmt — Testmanagement +Prüft Betriebsreife. +``` +grey matte miniature character holding a shield with a large checkmark, a small test tube at the belt, inspecting pose, "Test" engraved on the round base rim. +``` + +### Arch — Architektur +Standards & Zielarchitektur. +``` +grey matte miniature character holding an open drafting compass over a small blueprint, a ruler in the other hand, "Arch" engraved on the round base rim. +``` + +--- + +# EXTERNE — Weiß + +### Lieferant — Lieferant / Hersteller / Entwickler +Liefert externe Komponenten. +``` +white matte miniature character carrying a shipping crate on one shoulder, a small delivery label, friendly delivering pose, "Lieferant" engraved on the round base rim. +``` + +--- + +## Set-Render (alle Figuren zusammen) +Für ein Übersichtsbild des kompletten Sets: +``` +Group product render of a complete set of stylized matte PLA board-game miniatures, +all standing on identical round disc bases, arranged in rows by color category: +gold (governance) front row, blue (management), green (team trios), grey (operatives), +white (external) — consistent chunky proportions and base, neutral grey background, +soft studio light, isometric, cohesive collectible set look, minimal engraved labels. +``` + +## Hinweise +- Attribute (Krone, Lupe, Headset, Kiste) ggf. als separate Aufsteck-/Anbauteile drucken → weniger Stützstruktur, mischbar. +- Identischer Sockel ist hier das verbindende Element — bei der Modellierung als **gemeinsames Basis-Modul** anlegen und die Figuren darauf setzen. +- Verbindliche Maße: [`materialliste.md`](../01_3D-Druck/materialliste.md) und die OpenSCAD-Modelle. Diese Prompts sind Konzept-/Orientierungsbilder, keine Maßvorlage. diff --git a/02_Spielfiguren/figuren-varianten.md b/02_Spielfiguren/figuren-varianten.md new file mode 100644 index 0000000..8bff1bb --- /dev/null +++ b/02_Spielfiguren/figuren-varianten.md @@ -0,0 +1,225 @@ +# Figuren-Varianten — alle 16 Rollen + +Designvorschläge für die Rollen-Figuren des SLC-Workshops. Für **jede Rolle** drei +Stil-Varianten plus ein fertiger Bild-KI-Prompt (Englisch, für Nano Banana / Imagen). +Rollenquelle: [`spm_rollen.yaml`](../../../%2302_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/spm_rollen.yaml) (v1.1). + +## Die drei Stil-Tracks (gelten für jede Rolle) + +| Track | Idee | Druck/Aufwand | +|-------|------|---------------| +| **A — Meeple + Attribut** | Klassische Meeple-Grundform, oben ein rollentypisches Attribut aufgesetzt. Konsistent zur bestehenden Mechanik. | einfach | +| **B — Charakter-Mini** | Stilisierte Spielfigur mit Pose & Requisit, Brettspiel-Optik. | mittel/aufwendig | +| **C — Totem / Symbol** | Abstrakter geometrischer Turm mit graviertem Rollen-Symbol. Edel, robust, gut steckbar. | einfach | + +**Gemeinsame Constraints (in jedem Track):** +- Pin-Fuß **Ø 4,0 mm** (passt in einheitliche Steckplätze Ø 4,2 mm — Tile-Reihe & Gate) +- Schlanker Sockel **Ø ≤ 8 mm**, damit mehrere Figuren in einer Aktiv-Feld-Zone (Pitch 8 mm) nebeneinander stehen +- Höhe ~22 mm, matte PLA +- **Farbe = Kategorie** (siehe unten), Attribut/Gravur in Kontrastton möglich +- Kürzel klein an Sockel oder Brust graviert + +**Farbcodierung (Kategorie):** Governance = Gold/Gelb · Management = Blau · Teams = Grün · Operative Einzelrollen = Grau · Externe = Weiß + +**Gemeinsamer Bild-KI-Stil-Vorspann (vor jeden Prompt setzbar):** +> `Clean technical product render, matte PLA tabletop game figure, single piece on neutral light-grey studio background, soft studio light, isometric, round pin foot at base, height ~40mm, minimal engraved label, high detail.` + +--- + +# GOVERNANCE — Gold/Gelb + +## SPM — Service-Portfolio-Manager +Steuert das gesamte Portfolio, strategisch. **Signatur: Krone + aufgefächerte Service-Plättchen** (das ganze Portfolio in der Hand). +- **A:** Meeple mit kleiner Zacken-Krone, vor der Brust ein Fächer aus 3 Mini-Tiles. +- **B:** Stehende Figur, ein Arm hält einen Fächer aus Service-Karten, anderer auf einem Steuerrad/Kompass. +- **C:** Goldener Turm, Spitze als Krone, Schaft mit graviertem Fächer-Symbol „SPM". + +``` +matte gold PLA game figure: a regal meeple wearing a small pointed crown, holding a fanned-out spread of three tiny service tiles against its chest, a small steering-compass at its side, "SPM" engraved on the base, round pin foot. +``` + +## SO — Service Owner +End-to-End-Verantwortung für **einen** Service. **Signatur: schützend gehaltener Service-Orb + Schlüssel** (Ownership). +- **A:** Meeple, beide Arme umschließen eine Kugel mit Namensschild; Schlüssel am Hals. +- **B:** Figur, die eine leuchtende Service-Kugel wie einen Schatz hält, Schlüssel-Anhänger. +- **C:** Goldturm mit zentraler Kugel-Einfassung und graviertem Schlüssel „SO". + +``` +matte gold PLA game figure: a meeple cradling a single round service orb with a tiny name-plate against its body, a key pendant on its chest, protective stance, "SO" engraved on base, round pin foot. +``` + +## SOR — Service Operations Runde *(Gremium, kein Einzelner)* +Bewertet & entscheidet im Gremium. **Signatur: runder Tisch / Ring mit 4 Sitzen + Richterhammer.** +- **A:** Sammel-Marker: runde Scheibe mit 4 kleinen Steck-Pins (für SPM+SO+AL B&C+AL App), Hammer-Aufsatz mittig. +- **B:** Mini-Diorama: vier winzige Köpfe um einen Ring-Tisch, Gavel in der Mitte. +- **C:** Breiter Goldturm mit Ring-Krone und 4 Kerben, graviertes „SOR" + Hammer. + +``` +matte gold PLA game marker: a round table disc with four small empty peg sockets evenly spaced around its rim and a small judge's gavel standing in the center, "SOR" engraved on the rim, broad stable round base with pin foot. +``` + +--- + +# MANAGEMENT — Blau + +## AL B&C — Abteilungsleitung Basis & Cloud +Infrastruktur-Betrieb (Netze, Server, Cloud). **Signatur: Server-Rack-Körper + Wolke obenauf.** +- **A:** Meeple, dessen Rumpf als kleines Server-Rack gerillt ist, kleine Wolke als „Hut". +- **B:** Figur mit Helm, hält ein Server-Modul, Cloud-Symbol auf der Schulter. +- **C:** Blauer Turm aus gestapelten Rack-Einschüben, Spitze als Wolke, „AL B&C". + +``` +matte blue PLA game figure: a manager meeple whose torso is shaped like a small ribbed server rack, a little cloud sitting on top like a hat, holding a server module, "AL B&C" engraved on base, round pin foot. +``` + +## AL App — Abteilungsleitung Applikationen +Anwendungs-Betrieb (Fachverfahren, SAP). **Signatur: App-Fenster-Panel + Code-Brackets ``.** +- **A:** Meeple, vor der Brust ein App-Fenster-Tile mit Titelleisten-Punkten. +- **B:** Figur mit Helm, hält ein schwebendes Anwendungsfenster, `` graviert. +- **C:** Blauer Turm, Front als App-Fenster mit Titelbalken, „AL App". + +``` +matte blue PLA game figure: a manager meeple holding an upright application-window panel with a title-bar and three dots, small "" engraved on its chest, "AL App" on base, round pin foot. +``` + +## Sup Mgr — Support Manager +Organisiert & sichert Qualität des Supports. **Signatur: Headset + Klemmbrett/Checkliste.** +- **A:** Meeple mit Headset, hält ein Klemmbrett mit Häkchen. +- **B:** Figur mit Headset und Mikrofon-Arm, Klemmbrett in der Hand, dirigierende Pose. +- **C:** Blauer Turm mit Headset-Bügel als Krone, graviertes Häkchen, „Sup Mgr". + +``` +matte blue PLA game figure: a meeple wearing a headset with a boom mic, holding a clipboard with a checkmark, organizing pose, "Sup Mgr" engraved on base, round pin foot. +``` + +## Prob Mgr — Problem Manager +Root-Cause-Analyse, strukturelle Störungen. **Signatur: überdimensionierte Lupe + Wurzel-Symbol.** +- **A:** Meeple, hält eine große Lupe; an der Basis ein eingraviertes Wurzelgeflecht. +- **B:** Detektiv-Pose mit Lupe vor dem „Auge", kleines Wurzel/Baum-Symbol am Sockel. +- **C:** Blauer Turm mit Lupen-Kopf, Schaft mit gravierten Verzweigungen (Root-Cause), „Prob Mgr". + +``` +matte blue PLA game figure: a detective-like meeple holding an oversized magnifying glass up to its face, a small root/branch pattern engraved at the base, "Prob Mgr" engraved, round pin foot. +``` + +## PL — Projektleitung +Plant & steuert Entwicklungsprojekte. **Signatur: Klemmbrett mit Gantt + Dirigentenstab/Wimpel.** +- **A:** Meeple mit Bauhelm, hält Klemmbrett mit Balkenplan; kleiner Stab. +- **B:** Figur mit Helm, eine Hand am Klemmbrett, andere hebt einen Wimpel/Stab (Taktgeber). +- **C:** Blauer Turm, Spitze als Wimpel, Front mit graviertem Balkenplan, „PL". + +``` +matte blue PLA game figure: a meeple wearing a hard hat, holding a clipboard with a Gantt-bar chart, raising a small pennant baton in the other hand, "PL" engraved on base, round pin foot. +``` + +--- + +# TEAMS (Sammelfiguren) — Grün +*Sollen als „mehrere Personen" lesbar sein — breitere Basis, Trio-Anmutung.* + +## Betrieb — Betriebsteam +Laufender Betrieb, Monitoring, Deployment. **Signatur: Trio-Block + Zahnrad & Herzschlag-Linie.** +- **A:** Drei verschmolzene Meeple-Köpfe auf breiter Basis, Zahnrad-Aufsatz. +- **B:** Drei kleine Figuren um einen Monitor mit Herzschlag-Kurve. +- **C:** Grüner Breitturm mit 3 Kerben oben, graviertes Zahnrad + EKG-Linie, „Betrieb". + +``` +matte green PLA team figure: three meeple heads merged on one wide base, a gear and a heartbeat monitor line engraved across the front, "Betrieb" engraved, broad stable base with round pin foot. +``` + +## Support — Service-Support Team +1st/2nd-Level, Nutzeranfragen. **Signatur: Trio mit Headsets + Sprechblase.** +- **A:** Drei verbundene Köpfe, jeder mit Mini-Headset; Sprechblase als Aufsatz. +- **B:** Drei Figuren an einer Theke, Sprechblasen darüber. +- **C:** Grüner Breitturm, Sprechblasen-Krone, gravierte Headsets, „Support". + +``` +matte green PLA team figure: three connected meeple heads each wearing a tiny headset, a speech bubble on top, "Support" engraved on the wide base, round pin foot. +``` + +## Projekt — Projektteam +Entwicklung, Test, Doku, Übergabe. **Signatur: Trio + Blaupause-Rolle & Schraubenschlüssel.** +- **A:** Drei Köpfe auf Basis, eine Blaupausen-Rolle und ein Schraubenschlüssel gekreuzt. +- **B:** Drei Figuren über einem ausgerollten Bauplan gebeugt. +- **C:** Grüner Breitturm mit gravierten gekreuzten Werkzeugen + Plan, „Projekt". + +``` +matte green PLA team figure: three merged meeple heads on a wide base, a rolled blueprint and a wrench crossed in front, "Projekt" engraved, round pin foot. +``` + +--- + +# OPERATIVE EINZELROLLEN — Grau *(optional, für Detailtiefe)* + +## Queue Koord — Queue Koordinator +Ticket-Routing, Priorisierung, SLA. **Signatur: Signal-Paddel + verzweigende Pfeile.** +- **A:** Meeple mit Lotsen-Paddel, an der Basis abzweigende Pfeile. +- **B:** Verkehrslotsen-Pose mit zwei Paddeln, Routing-Pfeile am Boden. +- **C:** Grauer Turm mit Pfeil-Verzweigung graviert, „Queue". + +``` +matte grey PLA game figure: a meeple holding a traffic-control paddle, branching routing arrows engraved at the base, "Queue" engraved, round pin foot. +``` + +## L1 — 1st Level Agent +Erste Anlaufstelle, Standardfälle. **Signatur: Headset + großes „1".** +- **A:** Schlanker Meeple mit Headset, „1"-Badge an der Brust. +- **B:** Figur am Empfangstresen mit Headset, „1" über dem Kopf. +- **C:** Grauer Turm, Headset-Bügel, große gravierte „1". + +``` +matte grey PLA game figure: a slim meeple wearing a headset, a large number "1" engraved on its chest, "L1" on base, round pin foot. +``` + +## L2 — 2nd Level Agent +Komplexe Störungen, tiefe Analyse. **Signatur: Headset + Werkzeug + großes „2".** +- **A:** Meeple mit Headset, hält Schraubendreher, „2"-Badge. +- **B:** Figur mit Headset über aufgeklapptem Gerät gebeugt, „2". +- **C:** Grauer Turm, Headset + graviertes Werkzeug, große „2". + +``` +matte grey PLA game figure: a meeple wearing a headset and holding a screwdriver, a large number "2" engraved on its chest, "L2" on base, round pin foot. +``` + +## Test Mgmt — Testmanagement +Plant & verantwortet Tests, Betriebsreife. **Signatur: Häkchen-Schild + Reagenzglas.** +- **A:** Meeple, hält ein Schild mit großem Häkchen, Reagenzglas am Gürtel. +- **B:** Figur mit Prüf-Klemmbrett, hebt ein Reagenzglas prüfend. +- **C:** Grauer Turm mit graviertem Häkchen-im-Kreis + Glaskolben, „Test". + +``` +matte grey PLA game figure: a meeple holding a shield with a large checkmark and a small test tube at its belt, "Test" engraved on base, round pin foot. +``` + +## Arch — Architektur +Standards, Zielarchitektur, Risiken. **Signatur: Zirkel + Blaupause.** +- **A:** Meeple, hält einen geöffneten Zirkel über einer Mini-Blaupause. +- **B:** Figur am Stehpult mit Bauplan, Zirkel und Lineal in der Hand. +- **C:** Grauer Turm, Spitze als Zirkel, Front mit graviertem Grundriss-Raster, „Arch". + +``` +matte grey PLA game figure: a meeple holding an open drafting compass over a small blueprint, a ruler in the other hand, "Arch" engraved on base, round pin foot. +``` + +--- + +# EXTERNE — Weiß + +## Lieferant — Lieferant / Hersteller / Entwickler +Liefert externe Komponenten/Anpassungen. **Signatur: Paket/Kiste auf der Schulter.** +- **A:** Meeple, trägt eine Versandkiste auf der Schulter; Klebeband-Gravur. +- **B:** Lieferanten-Pose mit Kiste vor dem Bauch, kleines Etikett. +- **C:** Weißer Turm in Kisten-Optik (Versand-Markierungen graviert), „Lieferant". + +``` +matte white PLA game figure: a meeple carrying a shipping crate on its shoulder, packaging tape lines engraved, a small label, "Lieferant" engraved on base, round pin foot. +``` + +--- + +## Hinweise zum Einsatz + +- **Konsistenz-Tipp:** Für ein stimmiges Set einen Track durchziehen (z. B. alles Track A) und nur Governance optional als Track B aufwerten, damit die Entscheider-Figuren hervorstechen. +- **Gate-Lesbarkeit:** Die vier SOR-Pflichtrollen (SPM, SO, AL B&C, AL App) sollten am auffälligsten sein — sie müssen an den Gates zwingend zusammenkommen. +- **Druck:** Attribute (Krone, Lupe, Headset) als separate Aufsteck-Teile drucken senkt die Stützstruktur-Last und erlaubt Mischen. +- Verbindliche Maße über [`materialliste.md`](../01_3D-Druck/materialliste.md) und die OpenSCAD-Modelle; diese Prompts sind Konzept-/Orientierungsbilder, keine Maßvorlage. diff --git a/03_Karten/README_karten.md b/03_Karten/README_karten.md new file mode 100644 index 0000000..d5cd79c --- /dev/null +++ b/03_Karten/README_karten.md @@ -0,0 +1,83 @@ +# Karten & Chips + +Alle bedruckten Spielkarten und die Entscheidungs-Chips. Layout im +Freiburg-digital-Look (rot/weiß, Wappen-Logo) analog zur bestehenden Action Card. + +## Kartenformate + +| Kartentyp | Format | Hinweis | +|-----------|--------|---------| +| Action Cards | 70 × 120 mm (Tarot) | passt in Action-Stein-Schlitz (74 mm) | +| Störungskarten | 70 × 120 mm | gleiches Format, anderer Akzent | +| Artefaktkarten | 63 × 88 mm (Bridge) | werden bei Aktivitäten mitgeführt | +| Gate-Beschreibungskarten | 60 × 90 mm | stecken im Gate-Tor-Schlitz (65 mm) | +| Entscheidungs-Chips | Ø 30 mm | Karte oder 3D-Münze | + +--- + +## 1. Action Cards (Szenario-Deck) + +Triggern eine Lifecycle-Runde. Aufbau: **Banner „ACTION CARD" · Icon · Titel · +Szenariotext · Leitfrage · Logo**. Beispiel (vorhanden): + +> **Strategiewechsel** — „Das Ticketsystem muss kurzfristig an die neue +> Servicestrategie der Stadt angepasst werden. Was passiert an welchen Stellen?" + +Weitere Szenario-Vorschläge: +- **Neues Fachverfahren** — ein neuer Service soll von Grund auf entstehen (voller Build-Pfad). +- **Standardsoftware-Rollout** — Konfiguration statt Entwicklung (Gate-1-Pfad „Konfiguration"). +- **Major Incident** — wiederkehrende Störung eskaliert (Support→Problem→Review). +- **Außerbetriebnahme** — ein Altservice soll abgelöst werden (Pfad Richtung rv_06). +- **Sicherheits-Update** — kurzfristige Änderung im Betrieb mit Re-Transition. + +## 2. Störungskarten (Ereignis-Deck) + +Gegenstück zu Action Cards: werfen den Service in die **Operation↔Support-Schleife** +oder über ein Gate zurück. Beispiele: +- **Incident-Welle** → Support-Schleife sp_03–sp_08. +- **Strukturelles Problem** → sp_09/sp_10 + Problem Manager. +- **Sicherheitsvorfall** → Re-Transition (zurück über Gate). +- **Budgetkürzung** → Review-Entscheidung erzwungen. +- **Lieferant fällt aus** → Build/Support verzögert. + +## 3. Artefaktkarten (Ergebnisse) + +Wird an einer Aktivität ein Artefakt erzeugt, kommt die Karte ins Spiel und wird +mitgeführt. Mapping: + +| Artefakt | entsteht bei | +|----------|--------------| +| Projektauftrag | Eingang aus DPM → ds_01 | +| Service-Definition / Steckbrief | ds_01 | +| Betriebsdokumentation | tr_06 | +| Test-Report | tr_07 | +| Service-Qualitätsbericht | op_06 | +| Incident Record | sp_05–sp_07 | +| Problem Record | sp_09 / sp_10 | +| Workaround | sp_11 | +| Service-Review-Bericht | rv_02 / rv_03 | + +## 4. Gate-Beschreibungskarten + +Eine Karte je Gate, steckt im Tor-Schlitz: Gate-Nummer, Gate-Keeper, +Pflicht-Rollen, Entscheidungspfade. + +| Gate | Keeper | Pfade | +|------|--------|-------| +| Gate 1 (tr_01) | SOR | Entwicklung (tr_02) / Konfiguration (tr_05) | +| Gate 2 (tr_09) | SO | Go / Go mit Auflagen / Zurück / Ablehnung | +| Gate 3 (tr_12) | SOR | Go-Live / mit Auflagen / Zurück / Ablehnung | + +## 5. Entscheidungs-Chips + +Vier Typen, an Gates gelegt: **Go · Go mit Auflagen · Zurück · Ablehnung**. +Als Karte (Ø 30 mm Stanzung) oder als 3D-Münze (siehe Materialliste). + +--- + +## Druck-Pipeline (Hinweis) + +Karteninhalte lassen sich aus den `service-lifecycle_*.yaml` und `spm_rollen.yaml` +generieren (eine Quelle, kein Doppeln). Empfehlung: ein Template (HTML→PDF im +Freiburg-Layout), das die YAML-Felder einsetzt — analog zur bestehenden +Action-Card-Gestaltung. Umsetzung offen / späterer Schritt. diff --git a/04_Tablet-Quiz/README.md b/04_Tablet-Quiz/README.md new file mode 100644 index 0000000..cc9f491 --- /dev/null +++ b/04_Tablet-Quiz/README.md @@ -0,0 +1,101 @@ +# Tablet-Quiz — Begleit-App (Teilprojekt) + +**Status:** Konzept · **Typ:** eigenständiges Software-Teilprojekt des SLC-Workshops + +Das Tablet-Quiz ist der **digitale Begleiter** des Tabletops — kein Ersatz fürs +Brett. Es ist der **erklärende Gegenpart** zu den Plättchen und **ersetzt deren +Rückseite**: Die Plättchen tragen nur noch die Kurzbezeichnung, die ausführliche +Erklärung liefert die App. Sie **führt die Stationsreihenfolge** (linearer +Lifecycle), stellt pro Station ein **vermittelndes Quiz**, gibt danach die +**ausführliche Auflösung** und protokolliert Verständnislücken fürs Debrief. + +--- + +## 1. Ziel & Rolle im Spiel + +- **Stationsführung:** schaltet Station für Station automatisch weiter („Nächste Station") — die Plättchen brauchen keinen Code. +- **Active Recall verstärken:** erst Diskussion am Board, dann vermittelndes Quiz, dann Auflösung — Gruppe rät, App bestätigt/korrigiert. +- **Vollständige Erklärung:** liefert nach dem Quiz die ausführliche Auflösung (ersetzt die Plättchenrückseite) aus dem Blueprint (Single Source of Truth). +- **Dokumentation:** erfasst automatisch, welche Aktivitäten unklar waren (→ `../05_Workshop-Dokumentation/`). + +Bewusst **nicht** das Ziel: das Spiel digital ersetzen, Echtzeit-Multiplayer, +Accounts/Login, Cloud-Pflicht. + +## 2. Datengrundlage (keine Doppelpflege) + +Die App liest ausschließlich die bestehenden Blueprint-Dateien und leitet +Fragen daraus ab: + +| Quelle | liefert | +|--------|---------| +| `service-lifecycle_*.yaml` | Aktivitäten, Beschreibungen, Reihenfolge, Gates | +| `spm_rollen.yaml` | Rollen, RACI, Gate-Keeper | + +Ein Build-Schritt konvertiert die YAMLs in ein statisches `questions.json`. +Damit bleibt der Blueprint die einzige Wahrheit; Inhalte werden nie im App-Code +dupliziert. + +## 3. Fragetypen + +1. **Reihenfolge:** „Was kommt nach `tr_08`?" +2. **Rolle / RACI:** „Wer ist *Accountable* für `op_06`?" +3. **Artefakt:** „Welches Artefakt entsteht bei `tr_07`?" +4. **Gate-Logik:** „Wer muss an Gate 1 zustimmen?" / „Welche Pfade gibt es?" +5. **Zuordnung:** „In welcher Phase liegt `sp_09`?" + +Jede Frage: Gruppentipp → *Auflösen*-Button → Modellantwort. Im Anschluss an das +Quiz folgt die **ausführliche Auflösung** der Station (vollständige Beschreibung + +Rollen/RACI + Artefakt aus der YAML) — das ist der Inhalt, der früher auf der +Plättchenrückseite stand. + +## 4. Ablauf (UI-Flow) + +``` +[Start] → Szenario wählen (= Action Card) + → App führt zur aktuellen Station (linearer Lifecycle, Fortschritt sichtbar) + → Station: + → Gruppe diskutiert am Board anhand der Kurzbezeichnung (App noch zu) + → Quiz (vermittelnd): Frage(n) → Gruppentipp → "Auflösen" → richtig/falsch + → ausführliche Auflösung der Station (Erklärung + RACI + Artefakt) + → Gruppe reflektiert; optional "war unklar" markieren + → "Nächste Station" + → an Gates: Gate-Frage + Rollen-Check + → [Ende] → Debrief-Export (unklare Aktivitäten, Quote, Pfad) +``` + +## 5. Funktionsumfang (MVP) + +- [ ] `questions.json` + Stations-Inhalte aus YAMLs generieren (Build-Skript). +- [ ] Stationsführung: linearer Durchlauf mit „Nächste Station" + Fortschritt/Phasen-Farben. +- [ ] Fragetypen 1–3 (vermittelndes Quiz). +- [ ] „Auflösen"-Mechanik (Antwort erst auf Klick) **+ ausführliche Stationsauflösung** (Erklärung/RACI/Artefakt) nach dem Quiz. +- [ ] „Unklar"-Markierung je Aktivität. +- [ ] Debrief-Export (Markdown/JSON, lokal). + +### Später (Ausbau) +- Gate-Fragen mit Rollen-Check (Typ 4–5). +- Mehrere Szenarien mit unterschiedlichen Fragesets. +- Punktestand / Team-Modus. +- Mehrsprachigkeit. + +## 6. Technik-Empfehlung + +- **Single-Page-Web-App**, offline lauffähig (PWA), passt zum bestehenden + HTML-first-Stil im Repo (vgl. MB-Retro-HTMLs). +- Kein Backend nötig: statisches `questions.json` + LocalStorage für das Logbuch. +- Tablet im Kiosk-/Vollbildmodus; keine Konten, keine Cloud. +- Stack-Vorschlag: Vanilla JS oder leichtes Framework, ein Build-Skript (Node/Python) + für die YAML→JSON-Konvertierung. + +## 7. Schnittstellen zum restlichen Spiel + +- **Eingang:** Szenarioauswahl = gezogene Action Card (`../03_Karten/`). +- **Inhalt:** Aktivitäten/Gates/Rollen = Brett-Elemente (`../00_Konzept/`). +- **Ausgang:** Debrief-Daten → Workshop-Dokumentation (`../05_Workshop-Dokumentation/`). + +## 8. Offene Punkte + +- [ ] Format `questions.json` spezifizieren. +- [ ] Entscheidung Framework vs. Vanilla. +- [ ] Wer pflegt/baut? (intern DIGIT vs. extern) +- [ ] Datenschutz: rein lokal, keine personenbezogenen Daten — bestätigen. diff --git a/04_Tablet-Quiz/prototype/index.html b/04_Tablet-Quiz/prototype/index.html new file mode 100644 index 0000000..7257b3a --- /dev/null +++ b/04_Tablet-Quiz/prototype/index.html @@ -0,0 +1,491 @@ + + + + + +SLC-Workshop — Companion-App (Prototyp) + + + +
+
SLC Companion
+ Prototyp · v0.4 +
+ +
+
+ + +
+
+ +
+ +
+
+ + +
+

Debrief-Export

+

Lokale Auswertung dieses Durchlaufs — nichts wird hochgeladen.

+
+ 

+    

+      
+      

+      
+    

+  

+
+
+
+
+
diff --git a/05_Workshop-Dokumentation/README_dokumentation.md b/05_Workshop-Dokumentation/README_dokumentation.md
new file mode 100644
index 0000000..f34e954
--- /dev/null
+++ b/05_Workshop-Dokumentation/README_dokumentation.md
@@ -0,0 +1,28 @@
+# Workshop-Dokumentation
+
+Was während und nach dem Spiel festgehalten wird — damit die Gruppe **danach
+darüber diskutieren** kann und Verständnislücken in den Blueprint zurückfließen.
+
+## Drei Erfassungsebenen
+
+1. **Auf dem Board (live):** „Unklar"-Marker (rote Punkte) direkt auf die
+   Aktivitäts-Verankerung legen, wo es hakte. Am Ende ergibt das eine **sichtbare
+   Heatmap** der Verständnislücken — einfach abfotografieren.
+2. **Logbuch-Bogen** (1 Seite/Runde): gewählter Pfad, Gate-Entscheidungen, unklare
+   Aktivitäten, Stimmungs-Check. Vorlage: [`logbuch-vorlage.md`](logbuch-vorlage.md).
+3. **Tablet-Export** (falls genutzt): schwach beantwortete Aktivitäten + Quote.
+
+## Abschluss-Reflexion
+
+Mit den [`reflexionskarten.md`](reflexionskarten.md) im Plenum, ~10 Minuten.
+
+## Auswertung / Feedback-Schleife
+
+Nach dem Workshop:
+- Heatmap-Foto + Logbuch + Tablet-Export zusammenführen.
+- Häufig markierte Aktivitäten = Kandidaten für Nachschärfung im
+  Service-Lifecycle-Blueprint (`#02_service-portfolio-management/...`).
+- Erkenntnisse als kurze Notiz an die Blueprint-Pflege geben.
+
+> Leitgedanke: Wo das Spiel hakt, ist meist auch das Konzept unklar. Die
+> Dokumentation ist damit zugleich **Schulungs-Feedback** und **Konzept-Review**.
diff --git a/05_Workshop-Dokumentation/logbuch-vorlage.md b/05_Workshop-Dokumentation/logbuch-vorlage.md
new file mode 100644
index 0000000..7a0b5b4
--- /dev/null
+++ b/05_Workshop-Dokumentation/logbuch-vorlage.md
@@ -0,0 +1,66 @@
+# Logbuch — SLC-Workshop (eine Runde)
+
+> Pro durchgespieltem Szenario ausfüllen. Druckvorlage; im Workshop handschriftlich.
+
+**Datum:** ________________  **Gruppe / Anzahl:** ________________
+**Moderation:** ________________
+
+---
+
+## Szenario (Action Card)
+
+**Titel:** ____________________________________________
+
+**Kurz:** ____________________________________________
+
+---
+
+## Gewählter Pfad
+
+Reihenfolge der durchlaufenen Aktivitäten (IDs):
+
+```
+ds_ ___ → tr_ ___ → ... → op_ ___ → sp_ ___ → rv_ ___
+```
+
+Gate-1-Pfad:  ☐ Entwicklung (tr_02)   ☐ Konfiguration (tr_05)
+
+## Gate-Entscheidungen
+
+| Gate | Anwesende Rollen vollständig? | Entscheidung (Go / Auflagen / Zurück / Ablehnung) | Diskussionspunkt |
+|------|:----------------------------:|---------------------------------------------------|------------------|
+| Gate 1 | ☐ ja ☐ nein | | |
+| Gate 2 | ☐ ja ☐ nein | | |
+| Gate 3 | ☐ ja ☐ nein | | |
+
+## Unklare Aktivitäten (Heatmap)
+
+Welche Aktivitäten waren unklar / strittig? (IDs + warum)
+
+| Aktivität | unklar weil … |
+|-----------|----------------|
+| | |
+| | |
+| | |
+
+## Stimmungs-Check je Phase
+
+(1 = zäh/verwirrend … 5 = klar/flüssig)
+
+| Phase | 1 | 2 | 3 | 4 | 5 |
+|-------|:-:|:-:|:-:|:-:|:-:|
+| Design | ☐ | ☐ | ☐ | ☐ | ☐ |
+| Transition | ☐ | ☐ | ☐ | ☐ | ☐ |
+| Operation | ☐ | ☐ | ☐ | ☐ | ☐ |
+| Support | ☐ | ☐ | ☐ | ☐ | ☐ |
+| Review | ☐ | ☐ | ☐ | ☐ | ☐ |
+
+## Offene Fragen / Aha-Momente
+
+____________________________________________________________
+
+____________________________________________________________
+
+## Tablet-Quiz (falls genutzt)
+
+Trefferquote: ______ %   ·   schwächste Aktivitäten: ____________________
diff --git a/05_Workshop-Dokumentation/reflexionskarten.md b/05_Workshop-Dokumentation/reflexionskarten.md
new file mode 100644
index 0000000..26f4d4c
--- /dev/null
+++ b/05_Workshop-Dokumentation/reflexionskarten.md
@@ -0,0 +1,38 @@
+# Reflexionskarten — Abschluss
+
+> Zum Ausdrucken/Ausschneiden. Im Plenum reihum, ~10 Minuten. Eine Karte pro
+> Frage; die Gruppe greift verdeckt und beantwortet.
+
+---
+
+**Karte 1 — Überraschung**
+Was hat dich heute am Lifecycle überrascht?
+
+**Karte 2 — Realitätscheck**
+Wo war das Modell anders als euer Arbeitsalltag?
+
+**Karte 3 — Fehlende Rolle**
+Hat an einer Stelle eine Rolle gefehlt oder war eine zu viel?
+
+**Karte 4 — Schwierigstes Gate**
+Welches Gate war am schwersten zu entscheiden — und warum?
+
+**Karte 5 — Die Schleife**
+Wie habt ihr die Operation↔Support-Schleife erlebt?
+
+**Karte 6 — Wiedergeburt**
+War die Review-Entscheidung (Improvement / Redesign / Retirement) eindeutig?
+
+**Karte 7 — Klarste Aktivität**
+Welche Aktivität war am verständlichsten — was hat sie klar gemacht?
+
+**Karte 8 — Eine Änderung**
+Wenn du eine Sache am Konzept ändern dürftest — welche?
+
+---
+
+## Moderationshinweis
+
+Die Antworten auf **Karte 2, 3 und 8** sind die wertvollsten für die
+Blueprint-Weiterentwicklung — kurz mitschreiben und an die Konzeptpflege geben
+(siehe [`README_dokumentation.md`](README_dokumentation.md)).
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..0f61bca
--- /dev/null
+++ b/README.md
@@ -0,0 +1,53 @@
+# SLC-Workshop — Tabletop zum Service-Lifecycle
+
+Ein physisches Tabletop-Workshop-Format, mit dem Teams den **Service-Lifecycle des
+SPM-Konzepts** (Design → Transition → Operation ↔ Support → Review) gemeinsam
+durchspielen. Ein Szenario („Action Prompt") wandert als Spielstein durch alle
+Phasen, Aktivitäten und Gates. An jeder Station wird diskutiert, wer was tut und
+welches Artefakt entsteht; ein optionales Tablet-Quiz vertieft und protokolliert.
+
+**Auftraggeber-Kontext:** Stadt Freiburg / DIGIT — DIGITOM
+**Inhaltliche Quelle:** [`#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/`](../../%2302_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/)
+**Status:** Konzept / Vorbereitung Prototyp
+
+---
+
+## Kernidee in einem Satz
+
+Der Service-Lifecycle wird zu einer **linearen Spielbahn**, auf der ein Service
+als Spielstein von Design bis Review wandert — Entscheidungen fallen an drei
+Gates, an denen die richtigen Rollen-Figuren physisch zusammenkommen müssen.
+
+## Zentrale Spielmechaniken
+
+1. **Action-Stein** — trägt die gezogene Szenario-Karte aufrecht und wandert durch die Phasen.
+2. **Aktivitätsplättchen (einseitig)** — nur ID + Kurzbezeichnung. Aus der Verankerung genommen → Stein nimmt den freien Platz ein (= „wir sind hier"). Die Erklärung liegt in der App, nicht auf der Rückseite.
+3. **RACI-Aktiv-Feld** — mobile Leiste neben dem Action-Stein; beteiligte Rollen werden je Aktivität in die Zonen R/A/C/I gesteckt. Gates bleiben zusätzliche Pflicht-Versammlung.
+4. **Artefakt- & Störungskarten** — machen Ergebnisse und die Operation↔Support-Schleife greifbar.
+5. **Companion-App (Lernschleife)** — führt die Stationsreihenfolge, stellt pro Station ein vermittelndes Quiz, liefert die Auflösung und protokolliert Verständnislücken.
+
+## Ordnerübersicht
+
+| Ordner | Inhalt |
+|--------|--------|
+| [`00_Konzept/`](00_Konzept/) | Gesamtkonzept: Board, Phasen, Gates, Mechaniken, Spielablauf, Didaktik |
+| [`01_3D-Druck/`](01_3D-Druck/) | Materialliste mit Maßen, OpenSCAD-Modelle, Visual-Prompts für den 3D-Druck-Producer |
+| [`02_Spielfiguren/`](02_Spielfiguren/) | Rollen-Figuren, Farbcodierung, Gate-Zuordnung |
+| [`03_Karten/`](03_Karten/) | Action Cards, Störungs-, Artefakt- und Entscheidungskarten + Druckmaße |
+| [`04_Tablet-Quiz/`](04_Tablet-Quiz/) | Eigenständiges Teilprojekt: Begleit-App (Konzept & Architektur) |
+| [`05_Workshop-Dokumentation/`](05_Workshop-Dokumentation/) | Logbuch-Vorlage, Reflexionskarten, Debrief |
+
+## Bauteile auf einen Blick
+
+| Komponente | 3D-Druck | Print/Karte | Software |
+|------------|:--------:|:-----------:|:--------:|
+| Phasen-Basistiles (Bahn) | ✅ | — | — |
+| Aktivitätsplättchen (einseitig, Kurzbezeichnung) | ✅ | — | — |
+| Action-Stein (Szenario-Träger) | ✅ | — | — |
+| RACI-Aktiv-Feld (Stecklochleiste) | ✅ | — | — |
+| Gate-Tore | ✅ | — | — |
+| Rollen-Figuren | ✅ | — | — |
+| Action Cards / Störungskarten | — | ✅ | — |
+| Artefaktkarten / Entscheidungs-Chips | (Chips ✅) | ✅ | — |
+| Logbuch / Reflexionskarten | — | ✅ | — |
+| Companion-App (Quiz + Auflösung) | — | — | ✅ |