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>

00_Konzept/review-phase_arbeitsstand-frank.md

@@ -0,0 +1,56 @@
+# 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.