breitenbach76
b12bed892a
- 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>
59 lines
3.1 KiB
Markdown
59 lines
3.1 KiB
Markdown
# 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.
|