153 lines
8.5 KiB
Markdown
153 lines
8.5 KiB
Markdown
# 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 | 60 × 90 mm | zum Draufstecken auf den Action-Stein (Schlitz 64 mm); 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) |
|
||
| Gate-Beschreibungskarten | 60 × 90 mm | stecken im Gate-Tor-Schlitz (65 mm); Layout selbst produziert |
|
||
| 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. 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 dem Action-Stein** 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-Beschreibungskarten
|
||
|
||
Eine Karte je Gate, steckt im Tor-Schlitz: Gate-Nummer, Gate-Keeper,
|
||
Pflicht-Rollen, Entscheidungspfade — **und die erforderlichen Artefakte**
|
||
(das Gate „öffnet" nur, wenn diese Karten in der Service-Akte liegen, vgl. §3a).
|
||
|
||
| 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.
|
||
|
||
## 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.
|