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
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 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. Artefaktkarten (Ergebnisse)

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

#	Artefaktkarte	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 eigenes Kartendeck nötig) oder den DPM-Rücklauf (A15).

Konsolidierungs-Logik (für die Druckvorlage):

A6 bündelt die ganze „Betriebs-/Support-Doku"-Familie (Manual, Handbuch, Richtlinien, Standard Changes, Known Errors) auf eine Karte.
A9 deckt die laufenden Betriebsdaten (Monitoring/Alerts) mit ab — Live-Daten sind keine eigene physische Karte.
A10 trägt Incident und Request Record (gleicher Abschluss-Workflow).
A15 ist eine Karte mit zwei Rückseiten/Varianten statt zwei Decks.

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 service-lifecycle_*.yaml definiert werden (Single Source of Truth).

3a. Service-Akte (Artefakt-Tableau) — Spielelement

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.

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.

„Lebende" Artefakte (werden mehrfach befüllt):

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)

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.

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.

8.5 KiB Raw Blame History Unescape Escape