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.

04_Tablet-Quiz/app/index.html

@@ -245,12 +245,11 @@ const TOUR = {
     sp_09: "Ein Incident bleibt ungelöst – eine strukturelle Ursache wird vermutet. Der Problem Manager legt einen Problem Record an.",
     sp_10: "Mehrere ähnliche Speicher-Fehler häufen sich → sie werden geclustert und gebündelt als Problem Record erfasst.",
     sp_11: "Ursachensuche: Das Speicherproblem entsteht durch einen Timeout unter Last. Es gibt einen Workaround (Eintrag in die Wissensdatenbank) und die Entscheidung, dass ein Change nötig ist.",
-    rv_01: "Im Review werden Support-KPIs und wiederkehrende Fälle ausgewertet – die Speicher-Probleme tauchen klar als Muster auf.",
+    rv_01: "Im Service-Review werden die Betriebsdaten des Beteiligungs-Moduls ausgewertet: KPIs, die gehäuften Speicher-Incidents, Kundenfeedback und die Infrastruktur — alles fließt ins Service-Review-Dokument.",
-    rv_02: "Der Service wird über vier Dimensionen per Ampel bewertet (Leistung, Stabilität, Nutzerzufriedenheit, Zukunftsfähigkeit). Empfehlung in unserem Fall: IMPROVEMENT.",
+    rv_02: "Die Ergebnisse werden bewertet: Der wiederkehrende Speicher-Fehler rechtfertigt einen RFC. Der Bericht geht an die SOR, die ganzheitlich bewertet.",
-    rv_03: "Die SOR sichtet das Review und entscheidet. In unserem Beispiel: VERBESSERUNG NÖTIG (klein) → rv_04. (Alternativen wären: weiter wie bisher, Redesign rv_05 oder Außerbetriebnahme rv_06.)",
+    rv_03: "Auf Basis der Bewertung werden Änderungsvorschläge formuliert (z. B. Last-/Timeout-Optimierung), konsolidiert und die ausgewählte Änderung beschrieben.",
-    rv_04: "Die kleine Verbesserung wird geplant und umgesetzt – z. B. die Last- und Timeout-Optimierung beim Speichern. Sie fließt zurück in den laufenden Betrieb (Operation). Damit schließt sich der Kreis.",
+    rv_04: "Die Änderung wird gestartet. Es ist eine überschaubare Anpassung → Normal-Change-Logik: Umsetzung planen. (Wäre sie grundlegend, würde hier das Routing RUN/DPM/MB geklärt und ein Change-Steckbrief erstellt.)",
-    rv_05: "In unserem Beispiel NICHT gewählt. Wäre die Änderung grundlegend (z. B. eine komplett neue Beteiligungsplattform), würde sie hier als neuer Demand an den Demand-Lifecycle übergeben – der Service liefe quasi neu durch Design und Transition.",
+    rv_05: "Die Änderung wird umgesetzt: Im Weg RUN führt der Service Owner sie durch, dokumentiert und schließt sie ab. Der Service läuft verbessert weiter — der Kreis schließt sich."
-    rv_06: "Ebenfalls NICHT gewählt. Würde das Modul z. B. wegen eines Nachfolgesystems abgeschaltet, plant die SOR hier die kontrollierte Stilllegung (Retirement-Plan)."
   }
 };
 
@@ -270,7 +269,7 @@ const ROLLEN = {
   projektteam:"Projektteam", queue_koordinator:"Queue Koordinator",
   first_level_agent:"1st Level Agent", second_level_agent:"2nd Level Agent",
   testmanagement:"Testmanagement", architektur:"Architektur",
-  lieferant:"Lieferant", operations_manager:"Betrieb (AL B&C / AL App)"
+  lieferant:"Lieferant", operations_manager:"Betrieb (AL B&C / AL App)", dpm:"Demand Portfolio Manager"
 };
 const PHASEN = {
   design:{label:"Design", color:"var(--design)"},
@@ -759,80 +758,67 @@ const STATIONEN = [
        optionen:["Ein Workaround","Ein Betriebshandbuch","Eine Gate-Vorlage","Ein Review-Bericht"], richtig:0,
        expl:"sp_11 ermittelt die Ursache, erstellt einen Workaround und entscheidet über Change-Bedarf (aktualisiert den Problem Record)."}
     ]},
+  /* Review-Phase = ARBEITSSTAND (Vorschlag Frank, Change-Enablement) — noch NICHT
+     im Blueprint-YAML; vor Konzept-Uebernahme mit Michael abstimmen.
+     RACI + Quiz hier abgeleitet (Franks Entwurf nennt nur die Aktivitaeten). */
   { id:"rv_01", phase:"review", typ:"aktivitaet",
-    name:"Taktische Root-Cause-Analyse + Auswertung Support-KPIs",
+    name:"Durchführen von Service-Reviews",
-    beschreibung:"Strukturelle Analyse wiederkehrender Supportfälle und KPIs, um mittelfristige Verbesserungen anzustoßen.",
+    beschreibung:"Den Service systematisch auswerten und die Ergebnisse im Service-Review-Dokument festhalten.",
-    umfasst:["KPI-Auswertung (Supportqualität, Trends)","Wiederkehrende Tickets und systemische Ursachen","Abgleich mit Problem Records","Ableitung taktischer Verbesserungsmaßnahmen"],
+    umfasst:["KPIs & Monitoring auswerten","Problems & Incidents auswerten","Kundenfeedback sammeln/einholen","zugrunde liegende Infrastruktur bewerten","Service-Review-Dokument ausfüllen"],
-    artefakt:"Taktische Verbesserungsmaßnahmen",
+    artefakt:"Service-Review-Dokument",
-    raci:[["service_owner","A"],["problem_manager","R"]],
+    raci:[["service_owner","A"],["betriebsteam","R"],["service_support_team","C"],["problem_manager","C"]],
     quiz:[
-      {frage:"Wer führt die taktische Root-Cause-Analyse durch (R)?",
+      {frage:"Welches Dokument entsteht beim Service-Review?",
-       optionen:["Problem Manager","Service Owner","SOR","1st Level Agent"], richtig:0,
+       optionen:["RFC","Service-Review-Dokument","Change-Steckbrief","Incident Record"], richtig:1,
-       expl:"Der Problem Manager führt die taktische Analyse durch; der Service Owner priorisiert und bestätigt Maßnahmen (A)."}
+       expl:"KPIs, Incidents, Feedback und Infrastrukturbewertung werden im Service-Review-Dokument zusammengeführt."}
     ]},
   { id:"rv_02", phase:"review", typ:"aktivitaet",
-    name:"Service Performance & Improvement Review",
+    name:"Bewertung der Review-Ergebnisse",
-    beschreibung:"Operativer Review des Servicezustands anhand Qualitätsberichten, Supportdaten und Problem-Analysen. Methodik: 4-Dimensionen-Modell mit Ampelbewertung.",
+    beschreibung:"Die Review-Ergebnisse bewerten und bei Änderungsbedarf einen RFC erstellen; relevante Berichte gehen an die SOR.",
-    umfasst:["Leistung gegen Ziele und SLAs abgleichen","Gesamterfüllungsgrad bewerten","Operative Risiken, Störungen, Engpässe diskutieren","Optimierungsmaßnahmen identifizieren","Vorbereitung für SOR-Review","Handlungsempfehlung: CONTINUE / IMPROVEMENT / REDESIGN / RETIRE"],
+    umfasst:["RFC für Normal- bzw. Major-Change erstellen","Berichte bei Bedarf an die SOR weiterleiten","Ergebnisse in der SOR ganzheitlich bewerten"],
-    artefakt:"Service Performance & Improvement Review (Ampelbewertung)",
+    artefakt:"RFC (Request for Change)",
-    raci:[["service_owner","A/R"],["spm","I"]],
-    quiz:[
-      {frage:"Welche Bewertungsskala nutzt das Service Performance & Improvement Review?",
-       optionen:["1–10 Punkte","Grün / Gelb / Rot","Pass / Fail","A / B / C"], richtig:1,
-       expl:"Das 4-Dimensionen-Modell (Leistung, Stabilität, Zufriedenheit, Zukunftsfähigkeit) wird per Ampel (Grün/Gelb/Rot) bewertet."}
-    ]},
-  { id:"rv_03", phase:"review", typ:"aktivitaet",
-    name:"SOR: Periodischer Service Review",
-    beschreibung:"Die SOR bewertet regelmäßig die Serviceleistung und trifft operative Entscheidungen. Verzweigt in vier Wege.",
-    umfasst:["Sichtung des Service Performance & Improvement Reviews","Bewertung von Stabilität & Betriebsreife","Priorisierung operativer Verbesserungen","Freigabe kleinerer Maßnahmen","Schnittstelle zur Demand-/Portfolio-Steuerung"],
-    artefakt:"SOR-Entscheidung (Review)",
-    pfade:[
-      ["Weiter wie bisher","Service stabil, keine Maßnahmen → Operation"],
-      ["Verbesserung nötig (klein)","→ rv_04 Service Improvement"],
-      ["Strukturelle Überarbeitung","→ rv_05 Redesign / Erweiterung"],
-      ["Service End-of-Life","→ rv_06 Außerbetriebnahme"]
-    ],
-    raci:[["sor","A"],["service_owner","R"]],
-    quiz:[
-      {frage:"Wer trifft im periodischen Service Review die Entscheidung (A)?",
-       optionen:["Service Owner","SOR","SPM","Problem Manager"], richtig:1,
-       expl:"Die SOR entscheidet; der Service Owner berichtet und präsentiert (R)."},
-      {frage:"Welche Wege kann rv_03 eröffnen?",
-       optionen:["Nur Weiter oder Stop","Weiter / Improvement / Redesign / Retirement","Go / No-Go","Intern / Extern"], richtig:1,
-       expl:"Weiter wie bisher, kleine Verbesserung (rv_04), Redesign (rv_05) oder Außerbetriebnahme (rv_06)."}
-    ]},
-  { id:"rv_04", phase:"review", typ:"aktivitaet",
-    name:"Service Improvement",
-    beschreibung:"SOR-Entscheidung: Planung und Steuerung kleinerer Verbesserungsmaßnahmen innerhalb des Service.",
-    umfasst:["Probleme in Verbesserungs-Initiativen umwandeln","Aufwandsschätzung und Priorisierung","Zielmetriken festlegen","Verantwortlichkeiten zuweisen","Sichtbarkeit im Service-Portfolio"],
-    artefakt:"Verbesserungs-Initiative (zurück in Operation)",
-    raci:[["service_owner","A/R"],["spm","C"],["problem_manager","C"]],
-    quiz:[
-      {frage:"Wohin fließen die Verbesserungsmaßnahmen aus rv_04 zurück?",
-       optionen:["In die Operation (laufender Betrieb)","In die Design-Phase","In den Demand-Lifecycle","An Gate 1"], richtig:0,
-       expl:"Service Improvement setzt kleinere Maßnahmen im laufenden Betrieb (Operation) um."}
-    ]},
-  { id:"rv_05", phase:"review", typ:"aktivitaet",
-    name:"Service Redesign / Erweiterung",
-    beschreibung:"SOR-Entscheidung: strukturelle Weiterentwicklung des Service. Übergabe an den Demand-Lifecycle.",
-    umfasst:["Überarbeitung der Service-Definitionen","Anpassung von Komponenten, Prozessen, Rollen","Anforderungen für Entwicklungsprozess identifizieren","Übergabe an Demand-Lifecycle-Prozess"],
-    artefakt:"Neuer Demand (Redesign) → DPM",
-    raci:[["service_owner","A"],["spm","C"]],
-    quiz:[
-      {frage:"Wohin übergibt rv_05 (Redesign/Erweiterung)?",
-       optionen:["An die Operation","An den Demand-Lifecycle (DPM) als neuer Demand","An den Support","An Gate 2"], richtig:1,
-       expl:"Strukturelle Änderungen werden als neuer Demand erfasst und durchlaufen den Demand-Lifecycle."}
-    ]},
-  { id:"rv_06", phase:"review", typ:"aktivitaet",
-    name:"Service außer Betrieb nehmen",
-    beschreibung:"Strukturierte Entscheidung und kontrollierte Abschaltung eines Services.",
-    umfasst:["Auslöser definieren (Nutzung, Kosten, Überalterung)","Bewertung durch SOR","Retirement-Plan erstellen (Kommunikation, Migration, Abschaltung)","Koordination mit Portfolio (SPM)","Übergabe an Projekt-/Transitionsthemen"],
-    artefakt:"Retirement-Plan / Decommissioning-Auftrag → DPM",
     raci:[["sor","A"],["service_owner","R"],["spm","C"]],
     quiz:[
-      {frage:"Wer entscheidet über die Außerbetriebnahme eines Services (A)?",
+      {frage:"Was wird erstellt, wenn die Bewertung Änderungsbedarf zeigt?",
-       optionen:["Service Owner","SOR","SPM","Support Manager"], richtig:1,
+       optionen:["Ein RFC (Request for Change)","Ein Incident Record","Ein Test-Report","Eine Service-Definition"], richtig:0,
-       expl:"Die SOR entscheidet über die Stilllegung; der Service Owner führt den Retirement-Plan aus (R)."}
+       expl:"Bei Normal- oder Major-Change entsteht ein RFC; Berichte gehen an die SOR."},
+      {frage:"Wer bewertet die Review-Ergebnisse ganzheitlich?",
+       optionen:["Der 1st Level","Die SOR","Das Testmanagement","Der Lieferant"], richtig:1,
+       expl:"Die SOR bewertet die Ergebnisse als Gremium ganzheitlich."}
+    ]},
+  { id:"rv_03", phase:"review", typ:"aktivitaet",
+    name:"Definieren von Service-Änderungen",
+    beschreibung:"Auf Basis der Bewertung konkrete Änderungsvorschläge formulieren, konsolidieren und die ausgewählte Änderung beschreiben.",
+    umfasst:["passende Änderungsvorschläge formulieren","Vorschläge bewerten & konsolidieren","ausgewählte Änderung beschreiben"],
+    artefakt:"Beschriebene Service-Änderung",
+    raci:[["service_owner","A"],["sor","C"],["architektur","C"]],
+    quiz:[
+      {frage:"Was ist das Ziel dieser Aktivität?",
+       optionen:["Incidents schließen","Änderungsvorschläge formulieren, konsolidieren und beschreiben","Den Service abschalten","Das Budget planen"], richtig:1,
+       expl:"Aus der Bewertung werden konkrete, beschriebene Service-Änderungen abgeleitet."}
+    ]},
+  { id:"rv_04", phase:"review", typ:"aktivitaet",
+    name:"Starten von Service-Änderungen",
+    beschreibung:"Die Änderung anstoßen: bei Normal Change die Umsetzung planen; bei Major Change das Routing klären und den Change-Steckbrief ausfüllen.",
+    umfasst:["Normal Change: Umsetzung planen","Major Change: Routing klären (RUN / DPM / MB)","Major Change: Change-Steckbrief ausfüllen & weiterleiten"],
+    artefakt:"Change-Steckbrief (bei Major Change)",
+    raci:[["service_owner","A"],["sor","C"],["spm","C"],["dpm","I"]],
+    pfade:[["RUN","Durchführung im laufenden Betrieb (Service Owner)"],["DPM","über den Demand- & Projektprozess"],["MB","direkt in den Projektprozess oder RUN"]],
+    quiz:[
+      {frage:"Was muss beim Major Change vor der Umsetzung geklärt werden?",
+       optionen:["Das Routing: RUN, DPM oder MB","Die Ticket-Queue","Der Eskalationsweg","Die Lizenzkosten"], richtig:0,
+       expl:"Beim Major Change wird das Routing (RUN/DPM/MB) geklärt und ein Change-Steckbrief erstellt; beim Normal Change wird direkt die Umsetzung geplant."}
+    ]},
+  { id:"rv_05", phase:"review", typ:"aktivitaet",
+    name:"Implementieren von Service-Änderungen",
+    beschreibung:"Die Änderung gemäß gewähltem Weg umsetzen, dokumentieren und abschließen.",
+    umfasst:["Normal & Major (Weg RUN): SO führt durch, dokumentiert, schließt ab","Major (Weg DPM): Demand- & Projektprozess","Major (Weg MB): Projektprozess oder RUN"],
+    artefakt:"Umgesetzte & dokumentierte Service-Änderung",
+    raci:[["service_owner","A"],["projektteam","R"],["dpm","C"]],
+    quiz:[
+      {frage:"Wer führt eine Änderung auf dem Weg „RUN“ durch?",
+       optionen:["Der Service Owner","Der Demand Portfolio Manager","Ein externes Projektteam","Die SOR"], richtig:0,
+       expl:"Im Weg RUN führt der Service Owner die Änderung durch, dokumentiert und schließt sie ab."}
     ]}
 ];