patrick/SLC_Game
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
SLC_Game/00_Konzept/review-phase_arbeitsstand-frank.md
breitenbach76 9ecb3d3dfc Change-Arten auf 4 zusammengefuehrt (Frank/ITIL/YASM) + MB = Mission Board 
- 5 -> 4 Change-Arten: Major (Top-Level-Beispiel) / Normal / Standard / Emergency.
  Top/Low ist Routing/Freigabe-Ebene, kein Typ (ITIL: Major = Normal m. hoeherer
  Authority; YASM: lean). Klarere Klassifizierung in der App.
- App: CHANGE_TYPES/CHANGE_LEGEND/START_EMPFEHLUNG/USE_CASES auf 4; Action Cards
  24 (Major-Low entfernt, Rest auf c0-c3 umbenannt); sw.js cacht 24 (v4).
  Browser-getestet: 24 Karten, 4 Klassifizier-Optionen, Bilder laden.
- review-phase_arbeitsstand-frank.md: MB = Mission Board geklaert; SOR-Routing
  RUN/DPM/MB + Eskalations-Kriterium (Ressourcenhoheit -> Demand -> Mission Board);
  Change-Arten-Begruendung. README (24 Karten) nachgezogen.
- Workshop-Arbeitsstand; NICHT im YAML / kanonischen Konzept.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-06 15:31:03 +02:00

3.9 KiB
Raw Permalink Blame History

Review-Phase — Arbeitsstand (Vorschlag Frank)

Status: Arbeitsstand für den Workshop · nicht im Blueprint-YAML · nicht kanonisch ins Konzept übernommen (vor Übernahme mit Michael rückkoppeln). Quelle: E-Mail Frank · Logik: Change-Enablement (analog YASM).

Wo schon übernommen (Workshop-Material): Companion-App (04_Tablet-Quiz/app/, Review = rv_01–rv_05), 01_3D-Druck/materialliste.md (36 Station-Pucks / 39 Positionen) und die board-layout-Skizze. Bewusst NICHT geändert: service-lifecycle_*.yaml (Single Source of Truth) und das kanonische Konzept (README_konzept.md, Phasen-Tabelle zeigt weiter 6/40) — vor Übernahme mit Michael abstimmen.

Die 5 vorgeschlagenen Aktivitäten

  1. Durchführen von Service-Reviews
    • KPIs & Monitoring auswerten, Problems & Incidents auswerten, Kundenfeedback sammeln/einholen
    • Bewerten der zugrunde liegenden Infrastruktur
    • Service-Review-Dokument ausfüllen
  2. Bewertung der Review-Ergebnisse
    • RFC erstellen (Normal- bzw. Major-Change)
    • Berichte (wenn nötig) an die SOR weiterleiten
    • Ergebnisse in der SOR ganzheitlich bewerten
  3. Definieren von Service-Änderungen
    • passende Änderungsvorschläge formulieren
    • Vorschläge bewerten & konsolidieren
    • ausgewählte Änderung beschreiben
  4. Starten von Service-Änderungen
    • Normal Change: Planung der Umsetzung
    • Major Change: Routing klären (RUN / DPM / MB?)
    • Major Change: „Change-Steckbrief" ausfüllen & weiterleiten
  5. Implementieren von Service-Änderungen
    • Normal & Major (Weg RUN): durchführen, dokumentieren, abschließen durch SO
    • Major (Weg DPM): Change geht durch Demand- & Projektprozess
    • Major (Weg MB): direkt in den Projektprozess oder Durchführung im RUN

Abbildung gegenüber dem bisherigen Stand (rv_01–rv_06)

bisher neu (Frank)
rv_01 KPIs/RCA · rv_02 Performance-Review 1. Service-Reviews durchführen
rv_03 SOR-Review 2. Bewertung (RFC, SOR)
rv_04 Service Improvement 3. Änderungen definieren
rv_05 Redesign → DPM 4./5. Starten/Implementieren (Routing)
rv_06 Außerbetriebnahme — nicht explizit abgedeckt

Routing & Change-Arten (geklärt)

  • MB = Mission Board (offener Punkt gelöst). Das SOR-Routing am Change ist: RUN (im Betrieb durch den SO) · DPM (über den Demand-Prozess) · MB (Mission Board). Eskalations-Kriterium: Reicht die Ressourcen-/ Entscheidungshoheit der SOR nicht (z. B. zusätzliches Budget/Mittel), wird der Change zum Demand → über DPM ans Mission Board (= der DPM-Rücklauf).
  • Change-Arten auf 4 zusammengeführt (Major · Normal · Standard · Emergency). Franks frühere Top-Level/Low-Level-Unterscheidung ist Routing/Freigabe-Ebene, kein Change-Typ (ITIL 4: „Major" = Normal-Change mit höherer Authority; YASM: bewusst schlank). In der App umgesetzt: 4 Change-Arten, 24 Action Cards (6 Services × 4), klarere Klassifizierung. „Major" nutzt das Top-Level-Beispiel. → Workshop-Arbeitsstand (App), nicht YAML/kanonisches Konzept.

Offene Punkte (vor Konzept-/YAML-Übernahme klären)

  • Retirement / Außerbetriebnahme (bisher rv_06) fehlt — bewusst entfallen oder unter „Service-Änderung" subsumiert?
  • RACI + Quizfragen wurden für die App abgeleitet (Franks Entwurf nennt nur die Aktivitäten) — fachlich gegenprüfen.
  • Vokabular („RFC", „Change-Steckbrief", Routing RUN/DPM/MB) mit den anderen Phasen und der Rollen-/Gate-YAML abgleichen.
  • Konsequenz Board: Bahn = 39 statt 40 Positionen (36 Station-Pucks + 3 Gate). In Workshop-Material (App, materialliste, board-layout) bereits nachgezogen; alle Pucks sind identische Blanks → faktisch nur 1 Puck weniger / als Reserve. Das kanonische Konzept (README_konzept.md) zeigt noch 40 — nach Michael-Freigabe nachziehen.