# 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.