diff --git a/00_Konzept/review-phase_arbeitsstand-frank.md b/00_Konzept/review-phase_arbeitsstand-frank.md new file mode 100644 index 0000000..e0ae404 --- /dev/null +++ b/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. diff --git a/04_Tablet-Quiz/app/index.html b/04_Tablet-Quiz/app/index.html index 7c87540..9185785 100644 --- a/04_Tablet-Quiz/app/index.html +++ b/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_02: "Der Service wird über vier Dimensionen per Ampel bewertet (Leistung, Stabilität, Nutzerzufriedenheit, Zukunftsfähigkeit). Empfehlung in unserem Fall: IMPROVEMENT.", - 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_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_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_06: "Ebenfalls NICHT gewählt. Würde das Modul z. B. wegen eines Nachfolgesystems abgeschaltet, plant die SOR hier die kontrollierte Stilllegung (Retirement-Plan)." + 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: "Die Ergebnisse werden bewertet: Der wiederkehrende Speicher-Fehler rechtfertigt einen RFC. Der Bericht geht an die SOR, die ganzheitlich bewertet.", + 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 Ä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: "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." } }; @@ -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", - beschreibung:"Strukturelle Analyse wiederkehrender Supportfälle und KPIs, um mittelfristige Verbesserungen anzustoßen.", - umfasst:["KPI-Auswertung (Supportqualität, Trends)","Wiederkehrende Tickets und systemische Ursachen","Abgleich mit Problem Records","Ableitung taktischer Verbesserungsmaßnahmen"], - artefakt:"Taktische Verbesserungsmaßnahmen", - raci:[["service_owner","A"],["problem_manager","R"]], + name:"Durchführen von Service-Reviews", + beschreibung:"Den Service systematisch auswerten und die Ergebnisse im Service-Review-Dokument festhalten.", + umfasst:["KPIs & Monitoring auswerten","Problems & Incidents auswerten","Kundenfeedback sammeln/einholen","zugrunde liegende Infrastruktur bewerten","Service-Review-Dokument ausfüllen"], + artefakt:"Service-Review-Dokument", + 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)?", - optionen:["Problem Manager","Service Owner","SOR","1st Level Agent"], richtig:0, - expl:"Der Problem Manager führt die taktische Analyse durch; der Service Owner priorisiert und bestätigt Maßnahmen (A)."} + {frage:"Welches Dokument entsteht beim Service-Review?", + optionen:["RFC","Service-Review-Dokument","Change-Steckbrief","Incident Record"], richtig:1, + 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", - beschreibung:"Operativer Review des Servicezustands anhand Qualitätsberichten, Supportdaten und Problem-Analysen. Methodik: 4-Dimensionen-Modell mit Ampelbewertung.", - 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"], - artefakt:"Service Performance & Improvement Review (Ampelbewertung)", - 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", + name:"Bewertung der Review-Ergebnisse", + beschreibung:"Die Review-Ergebnisse bewerten und bei Änderungsbedarf einen RFC erstellen; relevante Berichte gehen an die SOR.", + umfasst:["RFC für Normal- bzw. Major-Change erstellen","Berichte bei Bedarf an die SOR weiterleiten","Ergebnisse in der SOR ganzheitlich bewerten"], + artefakt:"RFC (Request for Change)", raci:[["sor","A"],["service_owner","R"],["spm","C"]], quiz:[ - {frage:"Wer entscheidet über die Außerbetriebnahme eines Services (A)?", - optionen:["Service Owner","SOR","SPM","Support Manager"], richtig:1, - expl:"Die SOR entscheidet über die Stilllegung; der Service Owner führt den Retirement-Plan aus (R)."} + {frage:"Was wird erstellt, wenn die Bewertung Änderungsbedarf zeigt?", + optionen:["Ein RFC (Request for Change)","Ein Incident Record","Ein Test-Report","Eine Service-Definition"], richtig:0, + 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."} ]} ];