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 b12bed892a Workshop-Arbeitsstand: Materialliste + Board-Layout auf 5 Review / 39 Pucks 
- materialliste: Review 6->5, Station-Pucks 36 (+1 Blank Reserve), Bahn 39
  Positionen, Etiketten 39; Arbeitsstand-Hinweis ergaenzt.
- gen_board_layout.py: Review-Aktivitaeten = Franks 5; Titel/Subtitle 39/36;
  board-layout.svg neu generiert (39 Pucks, well-formed).
- Notiz review-phase_arbeitsstand-frank.md aktualisiert (Material + Board jetzt
  auf Arbeitsstand; YAML + kanonisches Konzept bleiben bei 6/40 bis Michael).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-06 13:51:38 +02:00

3.1 KiB
Raw 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

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

  • „MB" als dritter Routing-Weg ist nicht definiert (RUN und DPM sind klar).
  • 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.