Karten

Alle bedruckten Spielkarten. Layout im Freiburg-digital-Look (rot/weiß, Wappen-Logo) analog zur bestehenden Action Card.

Kartenformate

Kartentyp	Format	Hinweis
Action Cards	60 × 90 mm	liegen flach an der aktuellen Station; werden separat selbst produziert
Störungskarten	60 × 90 mm	gleiches Format, anderer Akzent

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 ist entfallen — die Action Card liegt einfach flach an der aktuellen Station.

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. Artefakte A1–A15 (in der App gesammelt)

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.

#	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`)
A3	Service Design Document	Design	ds_02	Architektur- & Lösungsdesign (das WIE)
A4	Implementation Blueprint	Design	ds_03	organisatorischer Einführungsplan
A5	Gate-/SOR-Vorlage	Transition	tr_01, tr_09, tr_11	Gate-Anträge inkl. Transition-Steckbrief (Gate 2)
A6	Betriebsdokumentation	Transition/Operation	tr_06, op_02	Service Operation Manual + Betriebshandbuch + Betriebsrichtlinien + Standard Changes + Known Errors
A7	Test-Report	Transition	tr_07	Testprotokolle & Freigaben
A8	Aktivierter Service	Transition → Operation	tr_12 (Go-Live)	Aufnahme ins Portfolio, Katalog-Eintrag aktiv
A9	Service-Qualitätsbericht	Operation	op_06	inkl. Monitoring-/Betriebsdaten & Alerts (op_05)
A10	Incident Record	Support	sp_05–sp_08	inkl. Request Record (sp_04/sp_07)
A11	Problem Record	Support	sp_09 / sp_10 (aktual. sp_11)	einziges im Blueprint formal definierte Artefakt
A12	Workaround	Support	sp_11	wird in die Wissensdatenbank eingetragen
A13	Wissensdatenbank-Eintrag	Support	sp_02	Known Errors / FAQ / Standardlösungen
A14	Service-Review-Bericht	Review	rv_02 / rv_03	„Service Performance & Improvement Review" (4-Dimensionen-Ampel)
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 eigener Akte-Eintrag nötig) oder den DPM-Rücklauf (A15).

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 einen Eintrag.
A9 deckt die laufenden Betriebsdaten (Monitoring/Alerts) mit ab — Live-Daten sind kein eigener Eintrag.
A10 trägt Incident und Request Record (gleicher Abschluss-Workflow).
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 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 (App-Element)

Die Service-Akte ist vollständig digital in der Companion-App abgebildet — kein gedrucktes Tableau, keine Pappkarten.

Mechanik

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.

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

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 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
Gate 1 (tr_01)	SOR	A2 Service-Definition · A3 SDD · A4 Implementation Blueprint	Entwicklung (tr_02) / Konfiguration (tr_05)
Gate 2 (tr_09)	SO	A6 Betriebsdokumentation · A7 Test-Report	Go / Go mit Auflagen / Zurück / Ablehnung
Gate 3 (tr_12)	SOR	A6 (final) · A7 · A2 mit SLA/SLO → erzeugt A8 Aktivierter Service	Go-Live / mit Auflagen / Zurück / Ablehnung

Bezug zum Blueprint: Gate 1 prüft „Design-Vollständigkeit" (SDD vorhanden), Gate 2 die „Übergabe-Vollständigkeit", Gate 3 die „Betriebsreife" — die Artefakt-Bedingung bildet genau diese Prüf-Dimensionen physisch ab.

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.

7.9 KiB Raw Blame History Unescape Escape