diff --git a/00_Konzept/README_konzept.md b/00_Konzept/README_konzept.md index c74bba6..d07369d 100644 --- a/00_Konzept/README_konzept.md +++ b/00_Konzept/README_konzept.md @@ -135,7 +135,7 @@ Alle Standfelder sind Ø 22 (gleich wie die Puck-Mulden — dieselben Ø-20-Figu Details & Designvarianten: [`../02_Spielfiguren/`](../02_Spielfiguren/). ### 5.4 Weitere Karten -- **Artefaktkarten + Service-Akte:** Was an einer Aktivität entsteht (15 konsolidierte Artefakte A1–A15). Erzeugte Artefakte kommen als Karte in die **Service-Akte** (Tableau neben der aktuellen Station); „lebende" Artefakte (Service-Definition, Problem Record, Wissensdatenbank) werden über einen **Status-Marker** mehrfach befüllt. **Gate-Kopplung:** Ein Gate öffnet nur, wenn die geforderten Artefakte in der Akte liegen (Gate 1: SDD + Implementation Blueprint usw.). Details: [`../03_Karten/`](../03_Karten/). +- **Artefakte A1–A15 + Service-Akte (App):** Was an einer Aktivität entsteht (15 konsolidierte Artefakte). Erzeugte Artefakte werden **in der App** bestimmt (Choice) und in der digitalen **Service-Akte** gesammelt; „lebende" Artefakte (Service-Definition, Problem Record, Wissensdatenbank) werden mehrfach befüllt. **Harte Gate-Kopplung:** Ein Gate gibt die Entscheidung erst frei, wenn die geforderten Artefakte gesammelt sind (Gate 1: A2·A3·A4 usw.). Details: [`../03_Karten/`](../03_Karten/). - **Störungskarten:** Gegenstück zu Action Cards (Incident-Welle, Sicherheitsvorfall, Budgetkürzung, Eskalation) — zwingen in die Operation↔Support-Schleife oder über ein Gate zurück. - **DPM-Rücklauf-Karte:** markiert am Review-Ende, wenn der Service als Redesign/Retirement zurück in den Demand-Lifecycle geht. - **„Unklar"-Marker:** rote Punkte für Verständnislücken (→ Dokumentation). @@ -168,13 +168,13 @@ Schwach beantwortete Stationen werden protokolliert (→ Abschnitt 8). MVP-Scope 1. Was passiert hier konkret für dieses Szenario? 2. Wer macht es (Rolle, RACI)? → die genannten **Figuren an den Puck stellen** und zusätzlich ins **Aktiv-Feld** in die passende R/A/C/I-Zone. - 3. Welches Artefakt entsteht? → erzeugte **Artefaktkarte in die Service-Akte** - legen (bzw. Status-Marker eines bestehenden Artefakts weiterschieben). + 3. Welches Artefakt entsteht? → in der **App auswählen** (Artefakt-Schritt); es + wandert in die digitale **Service-Akte**. Dann **App-Quiz** zur Station → **Auflösung in der App** → Gruppe reflektiert / gleicht ab. Danach Aktiv-Feld leeren und zur **nächsten Station** weiterziehen (App schaltet weiter, Action Card mitnehmen). -5. **Gates:** Diskussion, Pflicht-Figuren an den Gate-Puck stellen, **geforderte - Artefakte in der Service-Akte prüfen** (sonst öffnet das Gate nicht), +5. **Gates:** Diskussion, Pflicht-Figuren an den Gate-Puck stellen; die **App prüft die + geforderten Artefakte** (fehlen sie, bleibt die Entscheidung gesperrt), Entscheidung in der App treffen, weiterziehen. 6. **Schleife:** Störungskarten und Support-Phase durchspielen, bis Review erreicht ist. 7. **Review-Entscheidung:** Improvement / Redesign (rv_05) / Retirement (rv_06) — Redesign & Retirement geben den Service über die DPM-Rücklauf-Karte ab. diff --git a/01_3D-Druck/openscad/artefakt-token.scad b/01_3D-Druck/openscad/artefakt-token.scad deleted file mode 100644 index cc75290..0000000 --- a/01_3D-Druck/openscad/artefakt-token.scad +++ /dev/null @@ -1,56 +0,0 @@ -// Artefakt-Token (Service-Akte) — gedruckte "Karte" statt Pappkarte -// SLC-Workshop Tabletop · Einheiten: mm -// Kleine Tile mit gravierter A-Nummer; wird in einen Slot des Artefakt-Trays -// (artefakt-tray.scad) gelegt. Eingefaerbt in der PHASENFARBE der erzeugenden -// Phase (Design/Transition/Operation/Support/Review) -> Farbe via Filament. -// -// "Lebende" Artefakte (A2 Service-Definition, A11 Problem Record, -// A13 Wissensdatenbank) wachsen sichtbar: Basis-Token + je Aktualisierung -// eine duenne Status-Platte oben drauf (Entwurf -> Final -> Aktualisiert). -// -// part = "token" -> ein Artefakt-Token (Nummer via tok_label) -// "plate" -> eine Status-Platte zum Aufstapeln (lebende Artefakte) - -part = "token"; // "token" | "plate" - -/* [Token] */ -tok_w = 30; // Breite -tok_d = 20; // Tiefe -tok_h = 4; // Hoehe (Basis-Token) -tok_r = 2.5; // Eckenradius -tok_label = "A2"; // gravierte A-Nummer -lab_size = 11; // Schriftgroesse A-Nummer -lab_depth = 0.8; // Gravurtiefe - -/* [Status-Platte] (lebende Artefakte) */ -plate_h = 2.5; // Hoehe je Aktualisierungs-Platte - -$fn = 48; - -module rrect(l, w, h, r) { - linear_extrude(h) offset(r) offset(-r) square([l, w], center = true); -} - -module token(label) { - difference() { - rrect(tok_w, tok_d, tok_h, tok_r); - translate([0, 0, tok_h - lab_depth]) - linear_extrude(lab_depth + 0.1) - text(label, size = lab_size, halign = "center", valign = "center"); - } -} - -// duenne Platte zum Aufstapeln; kleine Mittenrille als Status-Markierung -module status_plate() { - difference() { - rrect(tok_w, tok_d, plate_h, tok_r); - translate([0, 0, plate_h - 0.5]) - linear_extrude(0.6) - square([tok_w - 10, 1.2], center = true); - } -} - -if (part == "plate") status_plate(); -else token(tok_label); - -echo(part = part, tok = [tok_w, tok_d, tok_h], plate_h = plate_h); diff --git a/01_3D-Druck/openscad/artefakt-tray.scad b/01_3D-Druck/openscad/artefakt-tray.scad deleted file mode 100644 index 741013d..0000000 --- a/01_3D-Druck/openscad/artefakt-tray.scad +++ /dev/null @@ -1,107 +0,0 @@ -// Artefakt-Tray (Service-Akte) — 3D-Aufnahme fuer die 15 Artefakt-Token -// SLC-Workshop Tabletop · Einheiten: mm -// Flaches Tableau mit 15 beschrifteten Steck-Slots (A1-A15), in 5 PHASEN-Reihen -// gruppiert (Design -> Transition -> Operation -> Support -> Review). Liegt neben -// der aktuellen Station und wandert mit. Die Token (artefakt-token.scad) tragen -// die Phasenfarbe; der Tray selbst ist EINFARBIG (Beschriftung via Gravur). -// -// Mechanik: -// - Artefakt erzeugt -> Token in seinen Slot legen. -// - "Lebende" Artefakte (A2/A11/A13, hier mit eingraviertem Zusatz-Rahmen -// markiert): Status-Platten oben aufstapeln -> Stapel waechst sichtbar. -// - Gate-Kopplung bleibt REGEL: ein Gate "oeffnet" nur, wenn die geforderten -// Token im Tray liegen (keine Mechanik am Gate-Puck). - -/* [Platte] */ -plate_thick = 6; // Dicke -margin = 8; // Aussenrand -corner_r = 5; - -/* [Slots] (Token Ø 30x20 wird REINGELEGT) */ -slot_w = 31; // Slot-Innenbreite (Token 30 + Spiel) -slot_d = 21; // Slot-Innentiefe (Token 20 + Spiel) -pocket_dep = 3.0; // Vertiefung (Token 4 hoch -> steht ~1 mm vor = greifbar) -pocket_r = 2.5; -gap_x = 7; // Abstand zwischen Slots in einer Reihe -row_gap = 8; // Abstand zwischen den Phasen-Reihen -header_h = 9; // Hoehe der Phasen-Kopfzeile ueber den Slots -finger_r = 6; // Greifkerbe an der Slot-Unterkante - -/* [Gravur] */ -num_size = 7; // A-Nummer im Slot-Boden -num_depth = 0.8; -hdr_size = 6; // Phasen-Name -hdr_depth = 0.8; -lf_inset = 3; // "lebend"-Rahmen: Abstand zum Slot-Rand -lf_w = 1.2; // Strichstaerke -lf_depth = 0.6; - -$fn = 48; - -// [Phasen-Reihe, [[A-Nummer, lebend?], ...]] — Reihenfolge = Lebenszyklus -ROWS = [ - ["DESIGN", [["A1", false], ["A2", true], ["A3", false], ["A4", false]]], - ["TRANSITION", [["A5", false], ["A6", false], ["A7", false], ["A8", false]]], - ["OPERATION", [["A9", false]]], - ["SUPPORT", [["A10", false], ["A11", true], ["A12", false], ["A13", true]]], - ["REVIEW", [["A14", false], ["A15", false]]] -]; -cols_max = 4; -n_rows = len(ROWS); - -// abgeleitete Maße -content_w = cols_max * slot_w + (cols_max - 1) * gap_x; // 145 -plate_w = content_w + 2 * margin; // 161 -block_h = header_h + slot_d; // 30 -content_h = n_rows * block_h + (n_rows - 1) * row_gap; // 182 -plate_h = content_h + 2 * margin; // 198 - -// Platz von Ecke (0,0) aus; y oben = plate_h -function blockTopY(r) = plate_h - margin - r * (block_h + row_gap); -function slotCenterY(r) = blockTopY(r) - header_h - slot_d/2; -function slotCenterX(c) = margin + slot_w/2 + c * (slot_w + gap_x); - -module rrect(l, w, h, r) { - linear_extrude(h) offset(r) offset(-r) square([l, w], center = true); -} - -module pocket(cx, cy, label, live) { - // Vertiefung - translate([cx, cy, plate_thick - pocket_dep]) - rrect(slot_w, slot_d, pocket_dep + 0.1, pocket_r); - // Greifkerbe an der Unterkante - translate([cx, cy - slot_d/2, plate_thick - pocket_dep]) - cylinder(r = finger_r, h = pocket_dep + 0.1); - // A-Nummer im Boden (sichtbar bei leerem Slot) - translate([cx, cy, plate_thick - pocket_dep - num_depth]) - linear_extrude(num_depth + 0.1) - text(label, size = num_size, halign = "center", valign = "center"); - // "lebendes" Artefakt: zusaetzlicher Rahmen als Hinweis (stapeln/aktualisieren) - if (live) - translate([cx, cy, plate_thick - pocket_dep - lf_depth]) - linear_extrude(lf_depth + 0.1) - difference() { - square([slot_w - 2*lf_inset, slot_d - 2*lf_inset], center = true); - square([slot_w - 2*lf_inset - 2*lf_w, slot_d - 2*lf_inset - 2*lf_w], center = true); - } -} - -module tray() { - difference() { - translate([plate_w/2, plate_h/2, 0]) rrect(plate_w, plate_h, plate_thick, corner_r); - for (r = [0 : n_rows - 1]) { - hdr = ROWS[r][0]; - slots = ROWS[r][1]; - // Phasen-Kopfzeile (links ueber der Reihe) - translate([margin + 1, blockTopY(r) - header_h/2, plate_thick - hdr_depth]) - linear_extrude(hdr_depth + 0.1) - text(hdr, size = hdr_size, halign = "left", valign = "center"); - for (c = [0 : len(slots) - 1]) - pocket(slotCenterX(c), slotCenterY(r), slots[c][0], slots[c][1]); - } - } -} - -tray(); - -echo(plate_w = plate_w, plate_h = plate_h, plate_thick = plate_thick, slots = 15); diff --git a/03_Karten/README_karten.md b/03_Karten/README_karten.md index 90df850..1111afc 100644 --- a/03_Karten/README_karten.md +++ b/03_Karten/README_karten.md @@ -9,8 +9,6 @@ Freiburg-digital-Look (rot/weiß, Wappen-Logo) analog zur bestehenden Action Car |-----------|--------|---------| | Action Cards | 60 × 90 mm | liegen flach an der aktuellen Station; werden separat selbst produziert | | Störungskarten | 60 × 90 mm | gleiches Format, anderer Akzent | -| Artefaktkarten | 63 × 88 mm (Bridge) | werden in der Service-Akte gesammelt | -| Service-Akte (Tableau) | A4 quer / A5 | 15 Slots (A1–A15), Artefakt-Sammler (§3a) | > **Keine Gate-Beschreibungskarten mehr:** Gate-Nr/Keeper/Pfade/Artefakte führen > **App + Gate-Puck-Etikett** (`G1/G2/G3`), siehe §4. Auch der frühere Action-Stein @@ -43,15 +41,16 @@ oder über ein Gate zurück. Beispiele: - **Budgetkürzung** → Review-Entscheidung erzwungen. - **Lieferant fällt aus** → Build/Support verzögert. -## 3. Artefaktkarten (Ergebnisse) +## 3. Artefakte A1–A15 (in der App gesammelt) -Wird an einer Aktivität ein Artefakt erzeugt, kommt die Karte ins Spiel und wird -mitgeführt. Im Blueprint tauchen ~20 Artefakt-Bezeichnungen auf (Schnittstellen, -`umfasst`-Listen); für das Spiel sind sie hier zu **15 Kern-Artefaktkarten** -konsolidiert. Mehrere Dokument-Varianten werden bewusst auf eine Karte gelegt -(Spalte „fasst zusammen"). +Erzeugt eine Aktivität ein Artefakt, wird es **in der App** bestimmt (Auswahl im +Artefakt-Schritt, „nochmal" bis richtig) und in die digitale **Service-Akte** +aufgenommen — **keine physischen Artefaktkarten** mehr. Im Blueprint tauchen ~20 +Artefakt-Bezeichnungen auf; für das Spiel sind sie zu **15 Kern-Artefakten (A1–A15)** +konsolidiert (Spalte „fasst zusammen"). Diese Tabelle ist die Referenz/Datengrundlage +der App; ausführliche Inhalte je Artefakt in `artefaktkarten_gamma.md`. -| # | Artefaktkarte | Phase | entsteht bei | fasst zusammen / Notiz | +| # | Artefakt | Phase | entsteht bei | fasst zusammen / Notiz | |----|---------------|-------|--------------|------------------------| | A1 | **Projektauftrag** | Eingang (DPM) | → ds_01 | „Freigegebener Demand" aus dem Demand-Lifecycle | | A2 | **Service-Definition** | Design | ds_01 | zentrales Artefakt; im Review fortgeschrieben (`service_review`) | @@ -70,67 +69,50 @@ konsolidiert. Mehrere Dokument-Varianten werden bewusst auf eine Karte gelegt | A15 | **DPM-Rücklauf** | Review → DPM | rv_05 / rv_06 | Variante A: Neuer Demand (Redesign) · Variante B: Retirement-Plan / Decommissioning-Auftrag | **Ergebnis-Hinweis:** Die Review-Entscheidung erzeugt entweder eine -**Verbesserungsmaßnahme** (rv_04, fließt zurück in die Operation — kein eigenes -Kartendeck nötig) oder den **DPM-Rücklauf** (A15). +**Verbesserungsmaßnahme** (rv_04, fließt zurück in die Operation — kein eigener +Akte-Eintrag nötig) oder den **DPM-Rücklauf** (A15). -**Konsolidierungs-Logik (für die Druckvorlage):** +**Konsolidierungs-Logik (für die A1–A15-Datengrundlage):** - A6 bündelt die ganze „Betriebs-/Support-Doku"-Familie (Manual, Handbuch, - Richtlinien, Standard Changes, Known Errors) auf **eine** Karte. + Richtlinien, Standard Changes, Known Errors) auf **einen** Eintrag. - A9 deckt die laufenden Betriebsdaten (Monitoring/Alerts) mit ab — Live-Daten - sind keine eigene physische Karte. + sind kein eigener Eintrag. - A10 trägt Incident **und** Request Record (gleicher Abschluss-Workflow). -- A15 ist **eine** Karte mit zwei Rückseiten/Varianten statt zwei Decks. +- A15 ist **ein** Eintrag mit zwei Varianten (Redesign / Retirement). > Hinweis Datenqualität: Nur der **Problem Record** ist in den YAMLs als -> `artefakte:`-Objekt mit Inhalten/Verantwortung spezifiziert. Für saubere, -> generierbare Karten sollten A1–A15 analog als `artefakte:`-Block in den +> `artefakte:`-Objekt mit Inhalten/Verantwortung spezifiziert. Für eine saubere, +> generierbare App-Datengrundlage sollten A1–A15 analog als `artefakte:`-Block in den > `service-lifecycle_*.yaml` definiert werden (Single Source of Truth). -## 3a. Service-Akte (Artefakt-Tableau) — Spielelement +## 3a. Service-Akte (App-Element) -Ein **gedrucktes Tableau (A4/A5)**, das **neben der aktuellen Station** liegt und -mitwandert. Es hat **15 beschriftete Slots** (A1–A15, nach Phase gruppiert) und -macht die wachsende Service-Dokumentation sichtbar. Layout: `service-akte.svg`. +Die Service-Akte ist **vollständig digital in der Companion-App** abgebildet — +**kein gedrucktes Tableau, keine Pappkarten**. **Mechanik** -- **Erstellen:** Erzeugt eine Station ein Artefakt → die zugehörige **Artefaktkarte - (63×88)** kommt in ihren Slot der Service-Akte. -- **Befüllen / Aktualisieren:** Wird ein bestehendes Artefakt erneut angefasst → - **Status-Marker weiterschieben** (`Entwurf → Final → Aktualisiert`). So „wächst" - ein Artefakt sichtbar über mehrere Stationen. +- **Erzeugen:** Im Artefakt-Schritt einer Aktivität wählen die Teilnehmenden, welches + Artefakt entsteht (Choice, „nochmal" bis richtig) → es wandert in die Akte. +- **Vorbefüllt:** Beim Einstieg mitten im Lebenszyklus (z. B. Normal Change an Gate 1) + liegen die zuvor entstandenen Artefakte bereits in der Akte. +- **Sichtbar:** Das Panel **„📁 Akte"** zeigt A1–A15 nach Phase, gesammelt vs. offen. +- **Lebende Artefakte** (A2 Service-Definition, A11 Problem Record, A13 Wissensdatenbank) + werden mehrfach befüllt/aktualisiert. -**„Lebende" Artefakte (werden mehrfach befüllt):** +**Harte Gate-Kopplung:** Ein Gate gibt die Entscheidung erst frei, wenn die geforderten +Artefakte in der Akte liegen (siehe §4) — sonst Hinweis „🔒 Es fehlt: …". Das macht +Artefakte zum echten Spielelement (analog zu den Pflicht-Figuren am Gate-Puck). -| Artefakt | erstellt | aktualisiert/befüllt | -|----------|----------|----------------------| -| **A2** Service-Definition | ds_01 | im Review (rv_02 / rv_04, Improvement-Tracking) | -| **A11** Problem Record | sp_09 / sp_10 | sp_11 (Root-Cause + Workaround) | -| **A13** Wissensdatenbank | sp_02 (Pflege) | sp_11 (neue Workarounds) | - -Alle übrigen Artefakte werden **einmal erstellt** (Status `Final`). - -**Funktional an die Gates gekoppelt:** Ein Gate „öffnet" nur, wenn die geforderten -Artefaktkarten in der Akte liegen (siehe §4). Das macht Artefakte zum echten -Spielelement — analog zu den Pflicht-Figuren am Gate — und bildet die -Prüf-Dimensionen des Blueprints physisch ab. - -**Debrief:** Am Ende ist die gefüllte Service-Akte das sichtbare Ergebnis: „Das hat -der Service über seinen Lebenszyklus an Dokumentation/Artefakten produziert." - -| Merkmal | Wert | -|---------|------| -| Form | Bedrucktes Tableau A4 (quer) oder A5, laminierbar | -| Slots | 15 (A1–A15), nach Phase gruppiert, je mit Mini-Status-Track | -| Karten | Artefaktkarten 63 × 88 mm (Bridge) | -| Menge | 1 (ggf. 2 bei parallelen Tischen) | +**Debrief:** Am Ende ist die gefüllte Akte das sichtbare Ergebnis: „Das hat der Service +über seinen Lebenszyklus an Dokumentation/Artefakten produziert." ## 4. Gate-Anforderungen (App-geführt, keine physische Karte) Es gibt **keine Gate-Beschreibungskarte** mehr. Gate-Nummer, Gate-Keeper, Pflicht-Rollen, Entscheidungspfade — **und die erforderlichen Artefakte** — führt die **App**; am Tisch markiert der **rote Gate-Puck** (Etikett `G1/G2/G3` + Icon) die -Position. Das Gate „öffnet" nur, wenn die erforderlichen Artefaktkarten in der -Service-Akte liegen (vgl. §3a) und die Pflicht-Figuren am Gate-Puck stehen. +Position. Das Gate „öffnet" nur, wenn die erforderlichen Artefakte in der digitalen +Akte gesammelt sind (App-Prüfung, vgl. §3a) und die Pflicht-Figuren am Gate-Puck stehen. | Gate | Keeper | Erforderliche Artefakte | Pfade | |------|--------|-------------------------|-------| diff --git a/03_Karten/service-akte.svg b/03_Karten/service-akte.svg deleted file mode 100644 index 7e89cb7..0000000 --- a/03_Karten/service-akte.svg +++ /dev/null @@ -1,70 +0,0 @@ - - - - Service-Akte — Artefakte A1–A15 - Erzeugte Artefaktkarten in den Slot legen · „lebende" Artefakte per Status-Marker weiterschieben (E→F→A) · Gxx = von Gate gefordert - - - Eingang (DPM) - Design - Transition - Operation - Support - Review - - - A1ProjektauftragFinal - - - A2 Service-Definition - lebt (Review aktualisiert) - E - F - A - G1·G3 - A3 Service Design DocArchitektur / WIEFinalG1 - A4 Impl. BlueprintEinführungsplanFinalG1 - - - A5 Gate-/SOR-VorlageGate-AnträgeFinal - A6 BetriebsdokuManual/HandbuchFinalG2·G3 - A7 Test-ReportTestprotokolleFinalG2·G3 - A8 Aktivierter ServiceErgebnis Gate 3Final - - - A9 QualitätsberichtSLA/KPIs (+Monitoring)Final - - - A10 Incident Recordinkl. Request RecordFinal - A11 Problem Recordlebt (sp_09→sp_11) - E - F - A - A12 Workaround→ WissensdatenbankFinal - A13 Wissensdatenbanklebt (sp_02 ← sp_11) - E - F - A - - - A14 Review-Bericht4-Dim.-AmpelFinal - A15 DPM-RücklaufDemand / RetirementFinal - - - - Legende - Status-Marker: E Entwurf → F Final → A Aktualisiert (nur „lebende" Artefakte: A2, A11, A13) - G1 - = Gate fordert dieses Artefakt (Gate öffnet nur, wenn es in der Akte liegt). G1: A2·A3·A4 · G2: A6·A7 · G3: A6·A7·A2 → A8 - - diff --git a/04_Tablet-Quiz/README.md b/04_Tablet-Quiz/README.md index d6739c4..228dd27 100644 --- a/04_Tablet-Quiz/README.md +++ b/04_Tablet-Quiz/README.md @@ -63,19 +63,19 @@ steht, sondern in der App liegt. ``` [1] Action Card ziehen → Raster aller Karten-Grafiken, eine antippen -[2] Change-Art bestimmen → 5 Change-Arten + Legende; falsch = "nochmal", richtig = weiter +[2] Change-Art bestimmen → 4 Change-Arten + Legende; falsch = "nochmal", richtig = weiter [3] Erfolgreiche Kategorisierung → kurze Bestätigung + Warum [4] Einstieg finden → Lebenszyklus groß: Phase anklicken (falsch = "nochmal") [5] Los geht's → App nennt Start-Station + Begründung → App führt ab Start-Station durch die Stationen (Fortschritt sichtbar) - → Aktivitäts-Station (2 Takte): - → Handeln am Brett: Figuren ins RACI-Feld, Artefaktkarte in die Service-Akte - (App fragt; "Zeig mir" als Hilfe, wenn die Gruppe nicht weiterkommt) - → Auflösung & Abgleich: App zeigt RACI/Artefakt → Brett korrigieren, "unklar" markieren - → "Nächste Station" - → Gate-Station: Kriterien prüfen (Artefakte in der Akte? Pflicht-Figuren?) + → Aktivitäts-Station (schrittweiser Mikro-Ablauf, 4 Fragen je einzeln + Auflösung): + → (1) Was steckt hinter der Überschrift? (2) Beteiligte Rollen → Figuren auf die Puck-Mulden + → (3) RACI → Figuren ins Aktiv-Feld (R/A/C/I), mit RACI-Legende + → (4) Artefakt als Choice → kommt in die digitale Service-Akte (Panel "📁 Akte") + → Abschluss-Screen ("✓ Aktivität abgeschlossen"; an Phasengrenzen 🎉-Feedback) → "Nächste Station" + → Gate-Station: App prüft die geforderten Artefakte (fehlen sie → Entscheidung gesperrt) + Pflicht-Figuren → Entscheidung wählen (Go/Auflagen/Zurück/Ablehnung bzw. Entwicklung/Konfiguration) - → Konsequenz + Verzweigung (z.B. Konfiguration überspringt den Build; + → Konsequenz + Verzweigung (Konfiguration überspringt den Build; echte Rückschleifen; reicht die SOR-Hoheit nicht → Demand via DPM ans Mission Board) → [Ende] → Debrief-Export (bearbeitete Stationen, unklare, Pfad) ``` diff --git a/04_Tablet-Quiz/app/index.html b/04_Tablet-Quiz/app/index.html index 3ba0b80..9a401dc 100644 --- a/04_Tablet-Quiz/app/index.html +++ b/04_Tablet-Quiz/app/index.html @@ -912,21 +912,51 @@ const STATIONEN = [ Die Akte ist rein digital: erzeugte Artefakte werden per Choice bestimmt und gesammelt; Gates sind hart gekoppelt (oeffnen nur mit den geforderten Artefakten). */ const ARTEFAKTE = { - A1:{name:"Projektauftrag", phase:"design"}, - A2:{name:"Service-Definition", phase:"design", live:true}, - A3:{name:"Service Design Document", phase:"design"}, - A4:{name:"Implementation Blueprint", phase:"design"}, - A5:{name:"Gate-/SOR-Vorlage", phase:"transition"}, - A6:{name:"Betriebsdokumentation", phase:"transition"}, - A7:{name:"Test-Report", phase:"transition"}, - A8:{name:"Aktivierter Service", phase:"transition"}, - A9:{name:"Service-Qualitätsbericht", phase:"operation"}, - A10:{name:"Incident Record", phase:"support"}, - A11:{name:"Problem Record", phase:"support", live:true}, - A12:{name:"Workaround", phase:"support"}, - A13:{name:"Wissensdatenbank-Eintrag", phase:"support", live:true}, - A14:{name:"Service-Review-Bericht", phase:"review"}, - A15:{name:"DPM-Rücklauf", phase:"review"} + A1:{name:"Projektauftrag", phase:"design", + was:"Der freigegebene Auftrag aus dem Demand-Lifecycle: Ziel, Rahmen, benannte Projektleitung sowie zugesagtes Budget und Ressourcen (nach DSR/MB-Freigabe).", + warum:"Er ist das Startsignal und Mandat für die Design-Phase — ohne ihn gibt es weder einen legitimierten Start noch zugewiesene Ressourcen."}, + A2:{name:"Service-Definition", phase:"design", live:true, + was:"Zweck, Nutzen und Zielgruppen des Services, Utility & Warranty, die SLA-/SLO-Anforderungen sowie Abhängigkeiten zu anderen Services.", + warum:"Sie legt fachlich fest, WAS der Service leisten soll — der Bezugspunkt für Design, Betrieb und das spätere Review."}, + A3:{name:"Service Design Document", phase:"design", + was:"Servicearchitektur (Komponenten, Schnittstellen), Design der Betriebs- und Supportprozesse, Security/Datenschutz/Compliance, Monitoring/Reporting und das Rollenmodell.", + warum:"Es übersetzt das „Was“ der Service-Definition in das WIE — der technische und organisatorische Bauplan und Voraussetzung für Gate 1."}, + A4:{name:"Implementation Blueprint", phase:"design", + was:"Plan zur organisatorischen Einführung: Integration, Rollenübergaben, Anpassung von Prozessen/Tools, Trainings & Kommunikation, Bewertung der Time-to-Operate.", + warum:"Er stellt sicher, dass der Service nicht nur gebaut, sondern auch wirklich in die Organisation eingeführt und übernommen werden kann."}, + A5:{name:"Gate-/SOR-Vorlage", phase:"transition", + was:"Die Entscheidungsvorlage für ein Gate: Aufwand/Risiken/Budget, Empfehlung und die zu prüfenden Dimensionen. An Gate 2 als „Transition-Steckbrief“.", + warum:"Sie macht Gate-Entscheidungen nachvollziehbar und legitimiert — ohne Vorlage keine SOR-/SO-Freigabe."}, + A6:{name:"Betriebsdokumentation", phase:"transition", + was:"Service Operation Manual, Betriebshandbuch, Arbeitsanweisungen, Eskalationswege, Standard Changes, Known Errors und Konfigurations-/Betriebsrichtlinien.", + warum:"Sie macht den Service betreib- und supportbar — ohne sie kein stabiler Regelbetrieb und keine schnelle, einheitliche Störungsbehebung."}, + A7:{name:"Test-Report", phase:"transition", + was:"Ergebnisse von Funktions-, Integrations- und Abnahmetests, der Nachweis der Betriebsreife sowie Testprotokolle und Freigaben.", + warum:"Er belegt, dass der Service funktioniert, BEVOR er live geht — Grundlage für die Freigabe an Gate 2."}, + A8:{name:"Aktivierter Service", phase:"transition", + was:"Der freigegebene, produktive Service inklusive Aufnahme ins Portfolio und aktiviertem Katalog-Eintrag (ggf. mit Support-Dokumentation).", + warum:"Es markiert den offiziellen Go-Live — ab hier ist der Service in Betrieb und im Portfolio sichtbar und steuerbar."}, + A9:{name:"Service-Qualitätsbericht", phase:"operation", + was:"SLA-/SLO-Auswertung, technische KPIs (Verfügbarkeit, Response Time), Abgleich gegen Qualitätsziele und Verbesserungspotenziale — inkl. Monitoring-/Betriebsdaten.", + warum:"Er zeigt objektiv, ob der Service seine Versprechen hält, und ist die Zuarbeit fürs Review."}, + A10:{name:"Incident Record", phase:"support", + was:"Aufnahme, Bearbeitung, Lösung und Abschluss einer Störung oder eines Service Requests — inklusive Klassifizierung für Auswertungen. (Trägt auch den Request Record.)", + warum:"Es dokumentiert Störungen/Anfragen nachvollziehbar, sichert SLA-Konformität und liefert Daten für Trendanalysen."}, + A11:{name:"Problem Record", phase:"support", live:true, + was:"Beschreibung, Symptome und Diagnosewege, bekannte Workarounds, die Ursache (Root Cause, wenn gefunden), Change-Bedarf sowie Status und Priorität.", + warum:"Es bündelt die strukturelle Ursachenarbeit hinter wiederkehrenden oder ungelösten Incidents — das einzige im Blueprint formal definierte Artefakt."}, + A12:{name:"Workaround", phase:"support", + was:"Eine vorläufige Umgehungslösung, die den Betrieb stabil hält, bis die eigentliche Ursache behoben ist — mit Eintrag in die Wissensdatenbank.", + warum:"Es hält den Service nutzbar, obwohl die Ursache noch offen ist, und reduziert den Druck auf den Support."}, + A13:{name:"Wissensdatenbank-Eintrag", phase:"support", live:true, + was:"Standardlösungen, Known Errors, Workarounds, FAQ und Anleitungen — das zentrale Arbeitsmittel für 1st und 2nd Level Support.", + warum:"Es beschleunigt den Support, sichert konsistente Antworten und entlastet die höheren Support-Level."}, + A14:{name:"Service-Review-Bericht", phase:"review", + was:"Das „Service Performance & Improvement Review“: Bewertung über 4 Dimensionen (Leistung, Stabilität, Nutzerzufriedenheit, Zukunftsfähigkeit) per Ampel und eine Handlungsempfehlung (CONTINUE / IMPROVEMENT / REDESIGN / RETIRE).", + warum:"Es liefert die strukturierte Grundlage für die SOR-Entscheidung über die Zukunft des Service."}, + A15:{name:"DPM-Rücklauf", phase:"review", + was:"Die Übergabe an den Demand-Lifecycle — Variante A: Neuer Demand (Redesign/Erweiterung) oder Variante B: Retirement-Plan / Decommissioning-Auftrag (Stilllegung).", + warum:"Es schließt den Lebenszyklus: größere Änderungen oder das Ende eines Service laufen kontrolliert über den Demand-Lifecycle, nicht „nebenbei“."} }; // Welche Station erzeugt welches A-Artefakt (Choice-Schritt -> Aufnahme in die Akte). const STATION_ARTEFAKT = { @@ -1291,7 +1321,7 @@ function activitySteps(st){ legend: raciLegendHtml(), auf:`

RACI

${raciTable(st)}` }, { label:"Artefakt", artefakt:true, - frage:`Welche Artefaktkarte entsteht hier und gehört in die Service-Akte?`, + frage:`Welches Artefakt entsteht hier und kommt in die Service-Akte?`, auf:`

Artefakt

${st.artefakt}

` } ]; } @@ -1353,10 +1383,16 @@ function renderActivity(st){ html += `
${opts}
`; if(S.arteWrong) html += `
Nicht ganz — überlegt nochmal, welches Ergebnis diese Station liefert.
`; } else if(S.actReveal){ - if(isArteChoice) - html += `

Artefakt

✓ ${arteId} — ${ARTEFAKTE[arteId].name} in die Service-Akte gelegt.

`; - else + if(isArteChoice){ + const A = ARTEFAKTE[arteId]; + html += `
+

✓ ${arteId} — ${A.name} in die Service-Akte gelegt.

+

Was umfasst es?

${A.was}

+

Warum brauchen wir es?

${A.warum}

+
`; + } else { html += `
${step.auf}
`; + } } let actions = `
`; @@ -1395,7 +1431,7 @@ function renderGate(st){

${st.beschreibung}

-

Artefaktkarten in der Akte? Pflicht-Figuren am Gate-Puck?

+

Geforderte Artefakte in der Akte (siehe oben)? Pflicht-Figuren am Gate-Puck?

`; } diff --git a/04_Tablet-Quiz/app/sw.js b/04_Tablet-Quiz/app/sw.js index a62b9de..36d13a1 100644 --- a/04_Tablet-Quiz/app/sw.js +++ b/04_Tablet-Quiz/app/sw.js @@ -1,5 +1,5 @@ /* Service Worker — SLC-Workshop Companion (App-Shell, offline-first) */ -const CACHE = "slc-companion-v9"; +const CACHE = "slc-companion-v11"; const SHELL = ["./", "index.html", "manifest.webmanifest", "icon.svg"]; // Action-Card-Grafiken (cards/s-c.png) fuer Offline vorab cachen (alle 30). const CARDS = []; diff --git a/PROJEKTSTAND.md b/PROJEKTSTAND.md index 77bdc63..5eedd15 100644 --- a/PROJEKTSTAND.md +++ b/PROJEKTSTAND.md @@ -21,7 +21,7 @@ Operations/Service-Owner/Support. Mix aus **Vermittlung** (Lifecycle + Stationen | `00_Konzept/` | Gesamtkonzept (`README_konzept.md`, v0.5) + Arbeitsstand-Notizen | | `01_3D-Druck/` | Materialliste, OpenSCAD-Modelle, Board-Layout-Generator, Visual-Prompts | | `02_Spielfiguren/` | Rollen-Figuren (38), Farbcodierung, Gate-Besetzung | -| `03_Karten/` | Action/Störungs/Artefaktkarten, Service-Akte | +| `03_Karten/` | Action/Störungskarten + Artefakt-Katalog A1–A15 (Service-Akte = App-Element) | | `04_Tablet-Quiz/` | **Companion-App** (`app/` = deploybare PWA) + Konzept | | `05_Workshop-Dokumentation/` | Logbuch, Reflexion, Debrief | @@ -43,7 +43,9 @@ Operations/Service-Owner/Support. Mix aus **Vermittlung** (Lifecycle + Stationen ### Karten (`03_Karten/`) - **Action Cards:** 24 finale Grafiken (Freiburg-digital-Layout) liegen in `04_Tablet-Quiz/app/cards/s-c.png` (6 Services × 4 Change-Arten). -- **Artefaktkarten A1–A15 + Service-Akte** (Tableau, liegt **neben der aktuellen Station**). +- **Service-Akte = App-Element:** Artefakte **A1–A15** werden in der App per **Choice** + gesammelt; **harte Gate-Kopplung** (Gate öffnet nur mit den geforderten Artefakten, + Akte beim Einstieg vorbefüllt). Keine physischen Artefaktkarten / kein Tableau / kein 3D-Teil. - **Gate-Entscheidung** (Go / Auflagen / Zurück / Ablehnung) trifft die zuständige Rolle **in der App**; die entscheidende Rolle bleibt als Marker am Gate-Puck. **Keine Chips, keine Gate-Karte mehr**. @@ -52,10 +54,12 @@ Operations/Service-Owner/Support. Mix aus **Vermittlung** (Lifecycle + Stationen **Flow:** Karten-Raster (Action Card ziehen) → **Change-Art klassifizieren** (Legende, „nochmal" bis richtig) → **Phasen-Einstieg** (Lebenszyklus-Phase anklicken, retry) → **Stationen** → **Abschluss-Screen** („abgeschlossen" oder „abgelehnt"). -- **Aktivitäts-Station, 2 Takte:** „Handeln am Brett" → „Auflösung & Abgleich". - **Figuren-Regel (zweistufig):** (1) beteiligte Rollen auf die **Mulden des - Station-Pucks** stellen, (2) dieselben Figuren ins **Aktiv-Feld (R·A·C·I)** - einsortieren = RACI-Antwort. Artefaktkarte in die Akte; „Zeig mir"-Hilfe. +- **Aktivitäts-Station, schrittweiser Mikro-Ablauf** (4 Fragen, je einzeln + Auflösung): + (1) Was steckt hinter der Überschrift? (2) Beteiligte Rollen → Figuren auf die + **Puck-Mulden**; (3) **RACI** → Figuren ins **Aktiv-Feld (R·A·C·I)** (mit RACI-Legende); + (4) **Artefakt als Choice** → in die App-Akte. Danach eigener **Abschluss-Screen** + („✓ Aktivität abgeschlossen", an Phasengrenzen zusätzlich 🎉-Phasen-Feedback). + Aufgaben jeweils im farbigen Aufgaben-Kasten. - **Gate-Station interaktiv:** Kriterien prüfen → Entscheidung → Konsequenz + **Verzweigung**. **Echte Rückschleifen:** „Zurück an Build/Transition" springt zurück, blendet einen Nacharbeits-Banner ein und legt das Gate danach **erneut** diff --git a/README.md b/README.md index 59b5c9d..29b175f 100644 --- a/README.md +++ b/README.md @@ -25,7 +25,7 @@ richtigen Rollen-Figuren physisch zusammenkommen müssen. 2. **Szenario / Action Card** — die gezogene Karte liegt flach an der aktuellen Station und wandert mit; die App führt die Reihenfolge, gestellte Figuren markieren „wir sind hier" (kein Spielstein). 3. **RACI-Aktiv-Feld** — quadratisches Board (2×2: R|A / C|I) neben der aktuellen Station; beteiligte Rollen werden je Aktivität in die Zonen R/A/C/I gestellt. Gates sind rote Pucks mit Pflicht-Versammlung. 4. **Phasen-Ring** — 5 farbige Segmente: zusammengesteckt die SLC-Übersicht, auseinandergenommen die Phasen-Köpfe der Bahn (Design = Start). -5. **Artefakt- & Störungskarten** — machen Ergebnisse (Service-Akte) und die Operation↔Support-Schleife greifbar. +5. **Störungskarten** — machen die Operation↔Support-Schleife greifbar. Die **Service-Akte** (Artefakte A1–A15) läuft in der App: Artefakte werden per Choice gesammelt, Gates sind hart gekoppelt. 6. **Companion-App (Lernschleife)** — führt die Stationsreihenfolge, stellt pro Station ein vermittelndes Quiz, liefert die Auflösung und protokolliert Verständnislücken. ## Ordnerübersicht @@ -35,7 +35,7 @@ richtigen Rollen-Figuren physisch zusammenkommen müssen. | [`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 | +| [`03_Karten/`](03_Karten/) | Action Cards, Störungskarten + Artefakt-Katalog A1–A15 (Service-Akte = App) | | [`04_Tablet-Quiz/`](04_Tablet-Quiz/) | Eigenständiges Teilprojekt: Begleit-App (Konzept & Architektur) | | [`05_Workshop-Dokumentation/`](05_Workshop-Dokumentation/) | Logbuch-Vorlage, Reflexionskarten, Debrief | @@ -50,6 +50,5 @@ richtigen Rollen-Figuren physisch zusammenkommen müssen. | Rollen-Figuren | ✅ | — | — | | Rundetiketten Ø37 (Station-/Gate-ID) | — | ✅ | — | | Action Cards / Störungskarten | — | ✅ | — | -| Artefaktkarten / Service-Akte | — | ✅ | — | | Logbuch / Reflexionskarten | — | ✅ | — | -| Companion-App (Quiz + Auflösung) | — | — | ✅ | +| Companion-App (Quiz, Auflösung, Service-Akte A1–A15) | — | — | ✅ | diff --git a/visual-prompts_nano-banana.md b/visual-prompts_nano-banana.md index 57c5374..55e72c9 100644 --- a/visual-prompts_nano-banana.md +++ b/visual-prompts_nano-banana.md @@ -33,8 +33,7 @@ board with four outlined fields in a 2x2 grid labelled R, A (top) and C, I (bott with several chunky 50mm miniature figures standing in the fields and in the puck wells. A flat "Action Card" lies next to the current puck. At the start of the track, five colour segments form a "phase ring" header (DESIGN/TRANSITION/OPERATION/SUPPORT/ -REVIEW). A small printed dossier sheet ("Service-Akte") with little artefact cards lies -to the side, plus a few round decision coins. Miniatures colour-coded by role category +REVIEW). Miniatures colour-coded by role category (gold, deep bordeaux, blue, grey, white, and green team figures). Wide composition, cohesive matte PLA set, soft studio light, premium look. ``` @@ -99,18 +98,7 @@ background, soft light, emphasis on the red colour and the "committee gathers to decide" idea. ``` -## 7. Service-Akte (Artefakt-Tableau) - -``` -Top-down render of a printed A4 landscape dossier sheet labelled "Service-Akte", -organised into columns by phase colour, with 15 labelled card slots. Several small -playing cards (bridge size) are placed into slots, each showing an artefact name; a -few slots show a small status track (Entwurf - Final - Aktualisiert) with a marker. -Some slots carry a small "Gate required" badge. Clean infographic-meets-board-game -look, neutral background, soft even light, crisp legible layout. -``` - -## 8. Phasen-Ring (Übersicht ↔ Köpfe) +## 7. Phasen-Ring (Übersicht ↔ Köpfe) ``` Product render of a colour-coded "phase ring": a flat donut (about 180mm outer, 84mm