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