5.9 KiB
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 | 70 × 120 mm (Tarot) | passt in Action-Stein-Schlitz (74 mm) |
| Störungskarten | 70 × 120 mm | gleiches Format, anderer Akzent |
| Artefaktkarten | 63 × 88 mm (Bridge) | werden bei Aktivitäten mitgeführt |
| Gate-Beschreibungskarten | 60 × 90 mm | stecken im Gate-Tor-Schlitz (65 mm) |
| 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 alsartefakte:-Block in denservice-lifecycle_*.yamldefiniert werden (Single Source of Truth).
4. Gate-Beschreibungskarten
Eine Karte je Gate, steckt im Tor-Schlitz: Gate-Nummer, Gate-Keeper, Pflicht-Rollen, Entscheidungspfade.
| Gate | Keeper | Pfade |
|---|---|---|
| Gate 1 (tr_01) | SOR | Entwicklung (tr_02) / Konfiguration (tr_05) |
| Gate 2 (tr_09) | SO | Go / Go mit Auflagen / Zurück / Ablehnung |
| Gate 3 (tr_12) | SOR | Go-Live / mit Auflagen / Zurück / Ablehnung |
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.