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 10fe33fba6 Review-Phase: Arbeitsstand (Frank, Change-Enablement) in die App 
- App-Review rv_01..rv_06 -> 5 Aktivitaeten (Service-Reviews durchfuehren,
  Bewertung, Aenderungen definieren/starten/implementieren). Rolle DPM ergaenzt;
  Routing-Pfade RUN/DPM/MB an rv_04; Tour-Narrative angepasst.
- RACI + Quiz abgeleitet (Frank nennt nur Aktivitaeten) und als Arbeitsstand
  markiert. App jetzt 39 Stationen.
- NICHT geaendert: Blueprint-YAML, kanonisches Konzept, materialliste, board-layout
  (zeigen weiter 6 Review-Pucks) — vor Uebernahme mit Michael abstimmen.
- Notiz: 00_Konzept/review-phase_arbeitsstand-frank.md (Vorschlag + offene Punkte:
  MB undefiniert, Retirement fehlt, Vokabular-/RACI-Abgleich).

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

2.9 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: in der Companion-App (04_Tablet-Quiz/app/) als Review-Phase (rv_01–rv_05) — das ist das Workshop-Tool. Bewusst NICHT geändert: service-lifecycle_*.yaml (Single Source of Truth), das kanonische Konzept (README_konzept.md, Phasen-Tabelle), 01_3D-Druck/materialliste.md und board-layout (zeigen weiter 6 Review-Pucks). → bei Michael-Freigabe nachziehen.

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/Konzept: App hat jetzt 5 Review-Stationen → Bahn wäre 39 statt 40 Positionen. Board (Pucks) + Konzept erst nach Freigabe anpassen.