governance_entscheidungen: - id: GOV-001 datum: 2025-11-26 quelle_modul: "P-02 Service Level Management" frage: "Wer verantwortet und entscheidet die Service-Kategorisierung (A/B/C)?" entscheidung: | - Responsible: Service-Portfolio-Manager - Accountable: Mission Board (Freigabe) begründung: | Die Kategorisierung hat strukturelle Implikationen für Governance (welches Gremium, welcher SLA-Typ). Das ist eine taktische Portfolio-Entscheidung, keine operative SLM-Frage. Das Mission Board als taktisches Entscheidungsgremium (AL + Abteilungsleiter) ist die richtige Ebene. auswirkung_auf: - dokument: "G-01 Portfolio Governance" abschnitt: "Entscheidungsmatrix" - dokument: "R-02 Service-Portfolio-Manager" abschnitt: "Verantwortlichkeiten" status: "final" # --------------------------------------------------------------------------- - id: GOV-002 datum: 2025-11-26 quelle_modul: "P-02 Service Level Management" frage: "Was ist der Eskalations- und Sanktionsmechanismus bei SLA-Verletzungen?" entscheidung: | 1. Service Owner identifiziert systematische SLA-Verletzung 2. Eskalation ins Mission Board 3. Mission Board definiert gemeinsam mit Service Owner verpflichtende Verbesserungsmaßnahmen 4. Kommunikation an Usergroup und via SLS-Update 5. Ultima Ratio: Sichtbarkeit auf OB-Ebene (Standing des Amtsleiters) begründung: | Kein vertraglicher Sanktionsmechanismus (unrealistisch im Verwaltungskontext), aber klare Governance-Konsequenz: Verpflichtende Verbesserung mit Accountability auf Amtsleitungsebene. auswirkung_auf: - dokument: "G-01 Portfolio Governance" abschnitt: "Eskalationswege" - dokument: "G-02 SOR Geschäftsordnung" abschnitt: "Schnittstelle zu Mission Board" status: "final" # --------------------------------------------------------------------------- - id: GOV-003 datum: 2025-11-26 quelle_modul: "P-02 Service Level Management" frage: "Wie verhält sich der interne Service Review zum externen SLA Review?" entscheidung: | Zwei-Stufen-Logik: 1. Interner Service Review (Blueprint sr_02): Service Owner → SOR → ggf. Mission Board = Vorbereitung und interne Abstimmung 2. Externer SLA Review (neu zu modellieren): Service Owner → Usergroup/Kunden-Gremium = Kommunikation, Validierung, SLA-Anpassung begründung: | Trennung von interner Steuerung (was können/wollen wir liefern?) und externer Abstimmung (was brauchen die Kunden?). Der interne Review ist Voraussetzung für den externen – nicht umgekehrt. auswirkung_auf: - dokument: "B-03 service_review.yaml" abschnitt: "Neue Aktivität: SLA Review mit Kunden" - dokument: "P-02 Service Level Management" abschnitt: "Review-Aktivitäten" status: "final" offene_fragen: - "Modellierung der neuen Aktivität im Blueprint" # --------------------------------------------------------------------------- - id: GOV-004 datum: 2025-11-26 quelle_modul: "P-02 Service Level Management" frage: "Wer ist der SLA-Partner für Kategorie-A-Services (Basisversorgung)?" entscheidung: | Konzeptionelle Anforderung an ein "Kundengremium Basisversorgung": 1. Repräsentiert die Kundenperspektive der Gesamtverwaltung 2. Ist SLA-fähig (Entscheidungskompetenz für Leistungsvereinbarungen) 3. Strukturvorschlag: - Pflichtvertreter: Querschnittsämter (z.B. HPA, ggf. weitere) - Wechselnde Vertreter: Rotation aus Fachämtern/Dezernaten 4. Folgt der Usergroup-Logik (analog Kategorie B) Finale Besetzung und Verankerung: Abstimmung mit Verwaltungsführung erforderlich. begründung: | Konsistente Governance-Logik über alle Service-Kategorien: Auch Kategorie A hat eine Usergroup – nur mit besonderer Zusammensetzung wegen des Querschnittscharakters. Pflichtvertreter sichern Kontinuität, wechselnde Vertreter sichern Repräsentativität. auswirkung_auf: - dokument: "G-01 Portfolio Governance" abschnitt: "SLA-Partnerstruktur" - dokument: "Konzept SLA/SLM" abschnitt: "Gremienstruktur Kategorie A" status: "draft" # Finale Abstimmung mit Verwaltung ausstehend offene_fragen: - "Welche Ämter sind 'Pflichtvertreter'?" - "Rotationslogik für wechselnde Vertreter?" - "Organisatorische Verankerung (wo angesiedelt)?" # --------------------------------------------------------------------------- - id: GOV-005 datum: 2025-11-26 quelle_modul: "P-02 Service Level Management" frage: "Wer darf als SLA-Partner für Kundenseite agieren?" entscheidung: | SLA-Partner auf Kundenseite müssen Entscheidungsbefugnis haben: 1. Grundsatz: Amtsleiter:in des nutzenden Amtes 2. Alternative: Explizit delegierte Person mit dokumentierter Entscheidungsbefugnis (z.B. Abteilungsleiter:in, Verwaltungsleiter:in des Amtes) Für Kategorie A und B gilt: - Mitglieder der Kundenvertretung sind Amtsleitungen oder deren delegierte Vertreter:innen - Die Delegation muss dokumentiert sein - Die Kundenvertretung ist kein "Anwenderforum", sondern ein Entscheidungsgremium Terminologie: - Kategorie A: "Kundenvertretung Basisservices" - Kategorie B: "Kundenvertretung [Servicename]" - Kategorie C: "Amtsleitung [Amt]" (bilateral) begründung: | SLAs sind Governance-Instrumente, keine Nutzerfeedback-Runden. Nur wer Entscheidungsbefugnis hat, kann verbindliche Leistungsvereinbarungen abschließen. Die Delegation ermöglicht Flexibilität, ohne die Legitimation zu untergraben. auswirkung_auf: - dokument: "P-02 Service Level Management" abschnitt: "Kernkonzepte, alle Aktivitäten mit SLA-Partner" - dokument: "G-01 Portfolio Governance" abschnitt: "SLA-Partnerstruktur" - dokument: "Konzept SLA/SLM (Ideenskizze)" abschnitt: "Abschnitte 4 und 6" status: "final" # --------------------------------------------------------------------------- - id: GOV-006 datum: 2025-11-27 quelle_modul: "P-01 Service Catalog Management" frage: "Wer ist Practice Owner für Service Catalog Management?" entscheidung: | Der Service-Portfolio-Manager (SPM) ist Practice Owner für SCM. Im MVP werden beide Rollen konsolidiert, um Rolleninflation zu vermeiden. begruendung: | SPM und SCM operieren beide auf Portfolio-Ebene und haben natürliche Nähe. Eine Trennung ist langfristig möglich, aber für die Einführungsphase nicht nötig. Die Konsolidierung reduziert Komplexität bei der Einführung rollenbasierten Arbeitens. auswirkung_auf: - dokument: "P-01 Service Catalog Management" abschnitt: "metadata.practice_owner" - dokument: "R-02 Service-Portfolio-Manager" abschnitt: "Verantwortlichkeiten" - dokument: "G-01 Portfolio Governance" abschnitt: "Rollenübersicht" status: "final" # --------------------------------------------------------------------------- - id: GOV-007 datum: 2025-11-27 quelle_modul: "P-01 Service Catalog Management" frage: "Wer erstellt die Service-Definition?" entscheidung: | Der Service Owner ist verantwortlich (Accountable) für die Erstellung der Service-Definition. SPM validiert und gibt frei. RACI: - Service-Definition erstellen: SO (A/R), SPM (C) - Service-Definition validieren: SPM (A/R), SO (C) - Katalogeintrag freigeben: SPM (A) oder SOR (A) je nach Änderungstyp begruendung: | ITIL4-konform: Der Service Owner trägt End-to-End-Verantwortung für den Service. Die Service-Definition ist Teil dieser Verantwortung. SCM stellt Methodik, Templates und Qualitätssicherung bereit, aber die inhaltliche Verantwortung liegt beim SO. auswirkung_auf: - dokument: "P-01 Service Catalog Management" abschnitt: "aktivitaeten_transition" - dokument: "R-01 Service Owner" abschnitt: "Verantwortlichkeiten" - dokument: "02.5_informationsmodell/spm_schema_service-definition.yaml" abschnitt: "schema.verantwortung" status: "final" # --------------------------------------------------------------------------- - id: GOV-008 datum: 2025-11-27 quelle_modul: "P-01 Service Catalog Management" frage: "Wie wird die Freigabe von Katalogeinträgen gesteuert?" entscheidung: | Dreistufige Governance nach Impact: 1. Redaktionelle Änderungen: - Beispiele: Tippfehler, Telefonnummer, Formatierung - Entscheidung: Service Owner (autonom) - Keine separate Freigabe nötig 2. Inhaltlich-minor: - Beispiele: FAQ-Link, Klarstellung ohne Änderung, neue Doku-Referenz - Entscheidung: Service Owner + SPM (bilateral) - Freigabe: SPM 3. Inhaltlich-major / Neuaufnahme: - Beispiele: Leistungsumfang, Service Levels, Zielgruppe - Entscheidung: SOR - Freigabe: SOR 4. Strukturell (Sonderfall): - Beispiele: Kategorie-Wechsel, Stilllegung - Entscheidung: Mission Board begruendung: | Vermeidet Überlastung des SOR/MB mit Kleinstthemen. Operative Themen werden operativ gelöst. Nur portfolio-relevante Entscheidungen eskalieren. Die Logik entspricht dem Subsidiaritätsprinzip und spiegelt die Änderungs-Governance in P-02 SLM. auswirkung_auf: - dokument: "P-01 Service Catalog Management" abschnitt: "aktivitaeten_betrieb.scm_05" - dokument: "G-01 Portfolio Governance" abschnitt: "Entscheidungsmatrix" - dokument: "G-02 SOR Geschäftsordnung" abschnitt: "Entscheidungsgegenstände" status: "final" # --------------------------------------------------------------------------- - id: GOV-009 datum: 2025-11-27 quelle_modul: "P-01 Service Catalog Management" frage: "Wie erfolgt die Qualitätssicherung für Kundenverständlichkeit?" entscheidung: | SHM wird eingebunden für die Prüfung der Kundenverständlichkeit von Service-Steckbriefen. Im MVP ist dies optional (Empfehlung), da das SHM-Modul noch in Entwicklung ist. Prozess: - SO erstellt Service-Steckbrief - SPM prüft Schema-Konformität und Konsistenz - SHM prüft Kundenverständlichkeit (optional im MVP) - SPM gibt frei begruendung: | SHM hat die Kompetenz für Kundenperspektive und -sprache. Die Einbindung vermeidet IT-zentrische Formulierungen und erhöht die Akzeptanz des Katalogs bei den Ämtern. Die Schnittstelle sollte etabliert werden, sobald SHM operativ ist. auswirkung_auf: - dokument: "P-01 Service Catalog Management" abschnitt: "aktivitaeten_transition.scm_02" - dokument: "SHM Funktionsbeschreibung" abschnitt: "3.2 Bedarfsaufbereitung und Routing" status: "draft" abhaengig_von: - "Finalisierung SHM-Modul" offene_fragen: - "Konkrete Qualitätskriterien für Verständlichkeit definieren" - "Prüfprozess in SHM-Workflow integrieren" # --------------------------------------------------------------------------- - id: GOV-010 datum: 2025-11-27 quelle_modul: "P-01 Service Catalog Management" frage: "Wer betreibt den Publikationskanal (Portal/Intranet)?" entscheidung: | Trennung von Inhalt und Betrieb: - SCM (SPM) verantwortet den INHALT des Katalogs (Was steht drin? Ist es aktuell? Ist es korrekt?) - Der BETRIEB des Publikationskanals ist eine separate Verantwortung (Webteam, IT-Betrieb, Kommunikation – je nach Kanal) Im MVP ist die konkrete Zuordnung noch zu klären. begruendung: | SCM ist ein Managementprozess, kein Portal-Betrieb. Die Vermischung würde SCM mit technischen Betriebsaufgaben überfrachten und von der eigentlichen Aufgabe (Informations-Governance) ablenken. Die Trennung ermöglicht auch verschiedene Publikationskanäle (Intranet, ITSM-Tool, PDF) ohne SCM-Prozessänderung. auswirkung_auf: - dokument: "P-01 Service Catalog Management" abschnitt: "kernkonzepte.service_katalog.publikationskanaele" - dokument: "G-01 Portfolio Governance" abschnitt: "Verantwortungsmatrix" status: "draft" offene_fragen: - "Wer ist konkret für Portal-Betrieb zuständig?" - "Welcher Kanal wird primär verwendet (Intranet, Self-Service-Portal)?" - "Wie erfolgt die Synchronisation mit ITSM-Tool?" # --------------------------------------------------------------------------- - id: GOV-011 datum: 2025-12-03 quelle_modul: "SPM / SHM Harmonisierung" frage: | Wie soll die Service-Kategorie B benannt werden, um terminologische Konsistenz zwischen SPM (Service-Perspektive) und SHM (Amt-Perspektive) herzustellen? entscheidung: | Umbenennung von "Modular-Services" zu "Erweiterte Services" (Kategorie B). Begründung der Begriffswahl: - "Modular" beschreibt die technische Architektur (zubuchbar, kombinierbar) - "Erweitert" beschreibt die Beziehung zum Basis-Level - "Erweitert" funktioniert für beide Perspektiven: * SPM: Service erweitert die Basis-Ausstattung * SHM: Amt hat erweiterte Anforderungen über Basis hinaus Die drei Kategorien heißen nun konsistent: - Kategorie A: Basis-Services / Basis-Profil - Kategorie B: Erweiterte Services / Erweitertes Profil - Kategorie C: Spezial-Services / Spezial-Profil begruendung: | Terminologische Konsistenz zwischen SPM und SHM reduziert Begriffsverwirrung und ermöglicht einheitliche Kommunikation über Funktionsgrenzen hinweg. auswirkung_auf: - dokument: "P-02 Service Level Management" abschnitt: "kernkonzepte.service_kategorien" - dokument: "P-01 Service Catalog Management" abschnitt: "kategorien_logik, katalog_views" - dokument: "spm_schema_service-definition.yaml" abschnitt: "identitaet.service_kategorie" - dokument: "readme_spm_vorgehen-entwicklung-spm-mvp-konzept.md" abschnitt: "Arbeitsmaterialien" status: final # --------------------------------------------------------------------------- - id: GOV-012 datum: 2025-12-09 quelle_modul: "P-02 Service Level Management + SHM Engagement-Framework" frage: | Wie werden die Kundenvertretungen (SLM) mit den Stakeholder-Management-Formaten (SHM) koordiniert? entscheidung: | Integration zu einem "Kundenforum"-Konzept: Die Kundenvertretungen nach P-02 werden mit den SHM-Formaten zusammengeführt. Das Kundenforum erfüllt beide Funktionen: - SLA-Abstimmung und Review (SLM-Verantwortung) - Beziehungspflege und Bedarfssammlung (SHM-Verantwortung) Die Governance-Kompetenz für SLA-Entscheidungen bleibt unverändert. begruendung: | Konsistenz der Kundeninteraktion: Ein Gremium statt paralleler Formate mit denselben Teilnehmern. Reduziert Aufwand für Ämter und DIGIT, stärkt gemeinsame Außenwirkung. auswirkung_auf: - dokument: "spm_practice_service-level-management.yaml" abschnitt: "kundenvertretung" - dokument: "shm_engagement-framework.yaml" abschnitt: "kollektive_formate" status: "final" verweis: "GOV-SHM-015 (SHM-Governance-Log)" # =========================================================================== # P-04/05/06 SERVICE-SUPPORT-MANAGEMENT (SSM) # =========================================================================== - id: SSM-G-01 datum: 2025-12-07 quelle_modul: "Service-Support-Management / Klassifikation" frage: "Wer bestimmt die Priorität eines Tickets?" entscheidung: | Service Desk (First Level) priorisiert nach verbindlicher Impact-Urgency-Matrix. Eskalation bei Widerspruch an Queue-Koordinator oder Teamleitung. Kunden können Dringlichkeit (Urgency) melden, aber nicht die Priorität festlegen. Die Matrix ist nicht verhandelbar. begruendung: | Aktuelle "4 low"-Monokultur verhindert sinnvolle Triage. Regelbasierte Priorisierung ersetzt informelle Verhandlungen und schafft Transparenz über Entscheidungsgrundlagen. auswirkung_auf: - dokument: "ssm_klassifikation-priorisierung.yaml" abschnitt: "grundprinzipien.autoritaet" - dokument: "sub-practice_incident-management.yaml" abschnitt: "Klassifikationsschritt (noch zu entwickeln)" status: "final" # --------------------------------------------------------------------------- - id: SSM-G-02 datum: 2025-12-07 quelle_modul: "Service-Support-Management / Klassifikation" frage: "Ist die Impact-Urgency-Matrix verbindlich?" entscheidung: | Die Impact-Urgency-Matrix ist verbindlich anzuwenden. Abweichungen nur durch Queue-Koordinator oder Teamleitung mit dokumentierter Begründung. begruendung: | Nur verbindliche Anwendung schafft Vergleichbarkeit für KPI-Auswertungen und verhindert subjektive Priorisierung. Die Eskalationsmöglichkeit wahrt Flexibilität für Ausnahmen. auswirkung_auf: - dokument: "ssm_klassifikation-priorisierung.yaml" abschnitt: "governance.entscheidungen.KLASS-G-01" status: "final" # --------------------------------------------------------------------------- - id: SSM-G-03 datum: 2025-12-07 quelle_modul: "Service-Support-Management / Klassifikation" frage: "Wie wird Explorative Diagnose legitimiert?" entscheidung: | Analyse-Tickets legitimieren 90-120 Minuten Explorative Diagnose. Voraussetzungen: - Ticket ist als Charakteristik "ANALYSE" klassifiziert - Dokumentation der Erkenntnisse ist verpflichtend - Erkenntnisse werden in Wissensdatenbank überführt begruendung: | Exploratives Arbeiten ist bei unbekannten Problemen notwendig und fördert systematisches Lernen. Ohne explizite Legitimation entsteht Rechtfertigungsdruck, der zu oberflächlichen Lösungen führt. Die Dokumentationspflicht verhindert Missbrauch. auswirkung_auf: - dokument: "ssm_klassifikation-priorisierung.yaml" abschnitt: "ticket_charakteristik.charakteristiken.ANALYSE.explorative_diagnose" - dokument: "ssm_design-zieldimensionen.yaml" abschnitt: "LS-02 (Rollenverständnis)" referenz: - dokument: "Lösungssäulen-Vision" abschnitt: "Säule 2: Rollenverständnis" status: "final" # --------------------------------------------------------------------------- - id: SSM-G-04 datum: 2025-12-07 quelle_modul: "Service-Support-Management / Klassifikation" frage: "Wie werden Langläufer-Tickets behandelt?" entscheidung: | Tickets mit Laufzeit >20 Arbeitstage werden als "Langläufer" gekennzeichnet und aus operativen KPIs (MTTR, FCR) exkludiert. Optionen nach Kennzeichnung: 1. Umklassifikation zu PROJEKT (Pool-Wechsel) 2. Verbleib mit separater Auswertung Die Kennzeichnung erfolgt automatisch durch das System. begruendung: | Langläufer verzerren operative Metriken massiv. Die aktuelle MTTR ist nicht aussagekräftig, weil Pseudo-Projekte mit Incidents vermischt werden. Die Exklusion schafft vergleichbare Kennzahlen für den Regelbetrieb. auswirkung_auf: - dokument: "ssm_klassifikation-priorisierung.yaml" abschnitt: "umklassifikation, pool_modell.pools.POOL-PROJEKT" - dokument: "ssm_kennzahlen.yaml" abschnitt: "(noch zu entwickeln)" status: "final" # --------------------------------------------------------------------------- - id: SSM-G-05 datum: 2025-12-07 quelle_modul: "Service-Support-Management / Klassifikation" frage: "Welche SLA-Ziele gelten für die Prioritätsstufen?" entscheidung: | Rahmenparameter für SLA-Ziele: | Prio | Reaktion | Lösung (Ziel) | Lösung (Max) | |------|----------|---------------|--------------| | P1 | 15 Min | 4h | 8h | | P2 | 1h | 8h | 16h (2 AT) | | P3 | 4h | 3 AT | 5 AT | | P4 | 1 AT | 5 AT | 10 AT | Service-spezifische SLAs können abweichen; bei Abweichung gilt die service-spezifische Vereinbarung. begruendung: | Die Rahmenparameter schaffen einen Standard für den Fall, dass kein service-spezifisches SLA existiert. Sie verhindern willkürliche Erwartungshaltungen und ermöglichen messbare Eskalationskriterien. auswirkung_auf: - dokument: "ssm_klassifikation-priorisierung.yaml" abschnitt: "prioritaetsstufen" - dokument: "spm_practice_service-level-management.yaml" abschnitt: "sla_typen (Referenz)" status: "draft" offene_fragen: - "Abstimmung mit Service Owner für kritische Services" - "Tool-Umsetzung der Eskalationstrigger" - id: "SSM-G-06" name: "L1/L2-Grenzziehung" entscheidung: | L1 bearbeitet Tickets, solange: 1. Dokumentation (KB) die Lösung ermöglicht UND 2. L1-Agent die erforderlichen Berechtigungen hat Zusätzlich: Bei Analyse-Tickets ist Explorative Diagnose (90-120 Min) erlaubt. Eskalation an L2 ist legitim, wenn: - Keine passende Dokumentation vorhanden - Lösung erfordert Berechtigungen außerhalb L1-Scope - Explorative Diagnose ausgeschöpft ohne Fortschritt - Komplexität übersteigt dokumentierten L1-Scope Eskalation erfordert "Definition of Handover" (DoH): - Was wurde versucht? - Welche KB-Artikel konsultiert? - Beobachtungen/Erkenntnisse - Eskalationsgrund status: "vorgeschlagen" - id: "SSM-G-07" name: "Ticket-Ownership-Prinzip" entscheidung: | Wer ein Ticket annimmt, ist verantwortlich bis: a) Ticket ist geschlossen, ODER b) Übergabe wurde vom Empfänger akzeptiert Regeln: - Tickets ohne Owner (Status NEU nach Annahme) sind verboten - "Zurücklegen" (Rückgabe an Queue ohne Empfänger) ist verboten - "Parken" (Status WARTEN_*) ist erlaubt mit Begründung Ausnahme: - L1 → L2 Domain Pool: Keine explizite Akzeptanz erforderlich (Pool-Verantwortung wird durch Queue-Koordinator gesteuert) - L2 → L1 Rückgabe: Akzeptanz + Begründung erforderlich Nicht-Akzeptanz innerhalb 4h: Auto-Eskalation an Queue-Koordinator status: "vorgeschlagen" # --------------------------------------------------------------------------- - id: "SSM-G-17" name: "(Reserviert)" datum: "2025-12-07" quelle_modul: "-" frage: "-" entscheidung: | Diese ID ist reserviert für zukünftige Governance-Entscheidungen im Request-Management-Kontext. begruendung: "Nummerierungskonsistenz" status: "reserviert" kategorie: "Request Management" # --------------------------------------------------------------------------- - id: "SSM-G-18" name: "Keine dedizierte Problem-Manager-Rolle" datum: "2025-12-07" quelle_modul: "sub-practice_problem-management.yaml" frage: "Brauchen wir eine dedizierte Problem-Manager-Rolle?" entscheidung: | Im MVP gibt es keine dedizierte Problem-Manager-Rolle. Der Service Owner ist Process Owner für Problem Management in seinem Service-Bereich. Operative Tätigkeiten können an Second Level Agents delegiert werden. begruendung: | Vermeidet Rollen-Inflation und nutzt bestehende Verantwortungs- strukturen. Der Service Owner hat ohnehin die Gesamtverantwortung für die Service-Qualität. ITIL4 warnt explizit davor, Problem Management als separate Funktion aufzubauen. auswirkung_auf: - dokument: "sub-practice_problem-management.yaml" abschnitt: "organisationsmodell" - dokument: "ssm_rollen.yaml" abschnitt: "service_owner, second_level_agent" status: "vorgeschlagen" kategorie: "Rollenmodell" # --------------------------------------------------------------------------- - id: "SSM-G-19" name: "Problem Management nur reaktiv im MVP" datum: "2025-12-07" quelle_modul: "sub-practice_problem-management.yaml" frage: "Welche Problem-Identifikationswege werden im MVP unterstützt?" entscheidung: | Problem-Identifikation erfolgt im MVP ausschließlich reaktiv aus dem Incident Management (nicht lösbare oder wiederkehrende Incidents). Proaktive Problem-Identifikation (YaSM LP4.7.1) ist nicht im Scope. begruendung: | MVP-Fokus auf Grundprozess. Für proaktive Identifikation fehlt die Datenbasis (Incident-Trends, Monitoring-Integration). Kann in späteren Ausbaustufen ergänzt werden. auswirkung_auf: - dokument: "sub-practice_problem-management.yaml" abschnitt: "aktivitaeten.PRB-01" status: "vorgeschlagen" kategorie: "Scope" offene_fragen: - "Ausbaustufe 2: Trend-Analyse und proaktive Identifikation?" # --------------------------------------------------------------------------- - id: "SSM-G-20" name: "Known Errors als KB-Artikel" datum: "2025-12-07" quelle_modul: "sub-practice_problem-management.yaml" frage: "Wie werden Known Errors dokumentiert?" entscheidung: | Known Errors werden als KB-Artikel mit speziellem Typ (KNOWN_ERROR) in der bestehenden Wissensdatenbank dokumentiert. Es wird keine separate Known Error Database (KEDB) geführt. begruendung: | Integration in bestehendes Wissensmanagement, vermeidet Tool-Redundanz und parallele Strukturen. L1/L2-Agents suchen ohnehin in der KB – Known Errors werden so automatisch gefunden. auswirkung_auf: - dokument: "sub-practice_problem-management.yaml" abschnitt: "kernkonzepte.known_error" - dokument: "ssm_wissensmanagement.yaml" abschnitt: "known_error_artikel" status: "vorgeschlagen" kategorie: "Wissensmanagement" # ============================================================================= # TMP-BAUSTEIN: Governance-Entscheidungen Service Transition (AP-01 + AP-02) # ============================================================================= # Zur Integration in: spm_governance-entscheidungen-log.yaml # Arbeitspakete: AP-01 Gate-Struktur, AP-02 Entscheidungskriterien # Datum: 2025-12-17 # ============================================================================= metadata: beschreibung: > Zusammenstellung aller Governance-Entscheidungen aus den Arbeitspaketen AP-01 (Gate-Struktur) und AP-02 (Entscheidungskriterien) für die Integration in das zentrale SPM Governance-Entscheidungs-Log. id_bereich: "GOV-TR-001 bis GOV-TR-012" referenzen: ap_01: "[tmp]_ap-01_gate-struktur.yaml" ap_02: "[tmp]_ap-02_entscheidungskriterien.yaml" ziel: "spm_governance-entscheidungen-log.yaml" # ============================================================================= # GOVERNANCE-ENTSCHEIDUNGEN AUS AP-01: GATE-STRUKTUR # ============================================================================= entscheidungen_ap_01: # --------------------------------------------------------------------------- - id: GOV-TR-001 datum: "2025-12-16" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" frage: "Was ist ein 'Gate' im DIGITOM-Kontext?" entscheidung: | Ein Gate ist ein formaler Entscheidungspunkt im Lifecycle, der kombiniert: - Prüfkriterien (Was muss erfüllt sein?) - Gate-Keeper (Wer entscheidet?) - Entscheidungsoptionen (Welche Ergebnisse sind möglich?) - Dokumentation (Wie wird die Entscheidung festgehalten?) begruendung: | Ein Gate nur als Checkliste hat keine Steuerungswirkung – es wird zum bürokratischen Durchwinken. Ein Gate nur als Entscheidung ohne Prüfkriterien wird beliebig. Die Kombination stellt sicher, dass es objektive Kriterien gibt UND jemand die Verantwortung für die Freigabe übernimmt. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Quality Gates" - dokument: "SPM Glossar" abschnitt: "Gate-Definition" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-002 datum: "2025-12-16" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" frage: "Wie viele Gates hat die Service Transition und wer ist Gate-Keeper?" entscheidung: | Zwei-Gate-Modell: - Gate 1 "Entry Transition": Gate-Keeper ist Service Owner - Gate 2 "Go-Live-Freigabe": Gate-Keeper ist Service Operations Runde (SOR) begruendung: | Gate 1 ist eine operative Entscheidung des SO (fachlich-inhaltlich). Gate 2 ist eine Governance-Entscheidung der SOR (Portfolio-Perspektive). Die Trennung spiegelt die Verantwortungslogik: SO verantwortet den Service, SOR verantwortet das Portfolio. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Quality Gates" - dokument: "G-SOR Geschäftsordnung" abschnitt: "Entscheidungsgegenstände" - dokument: "R-SO Rollenbeschreibung" abschnitt: "Entscheidungsbefugnisse" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-003 datum: "2025-12-16" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" frage: "Für welche Service-Änderungen gilt die Gate-Struktur?" entscheidung: | Major Changes erfordern eine einmalige SOR-Autorisierung. Die SOR entscheidet in einem Schritt, ob der Major Change durchgeführt werden darf, und legt dabei den Einstiegspunkt im Lifecycle fest. Nach der Autorisierung durchläuft der Major Change den regulären Service-Lifecycle einschließlich der üblichen Transition-Gates (inkl. Gate 3 für Go-Live). Die Gate-Struktur gilt für: - Neue Services (erstmalige Aktivierung) - Major Changes an bestehenden Services Minor Changes laufen über Change Enablement (Standard/Normal Change). Major-Kriterien: - Änderung der Service-Definition (Scope, Zielgruppe, Kernfunktionalität) - Änderung der SLA/SLO-Vereinbarungen - Signifikante Architektur-Änderung - DPM-Klassifizierung "komplex" oder "hochkomplex" begruendung: | Die Gate-Struktur ist Governance-Overhead, der sich nur bei signifikanten Veränderungen rechtfertigt. Für Minor Changes wäre das unverhältnismäßig. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Geltungsbereich" - dokument: "P-03 Change Enablement" abschnitt: "Major/Minor-Abgrenzung" status: "final" offene_punkte: - "Major/Minor-Abgrenzung muss mit P-03 Change Enablement synchronisiert werden" # --------------------------------------------------------------------------- - id: GOV-TR-004 datum: "2025-12-16" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" frage: "Wann muss ein Service Owner für einen neuen Service benannt sein?" entscheidung: | Zweistufige Regelung: 1. Empfehlung: Frühzeitige Benennung bei/kurz nach Projektfreigabe - SPM identifiziert und schlägt vor - SO wird als Consulted in Projektentscheidungen eingebunden 2. Harter Constraint: Spätestens bei Gate 1 - SO ist Gate-Keeper für Gate 1 - Ohne SO kann Gate 1 nicht durchgeführt werden Formale Bestätigung: SOR bestätigt SO bei Gate 2 (Go-Live-Freigabe) Fallback: Bei fehlendem SO-Kandidaten eskaliert SPM an Abteilungsleitung (spätestens 4 Wochen vor geplantem Gate 1) begruendung: | Ein harter Constraint bei Projektfreigabe kann zum Bottleneck werden. Die Empfehlung zur frühzeitigen Benennung bleibt, aber der unbedingte Zwang liegt erst bei Gate 1. auswirkung_auf: - dokument: "R-SO Rollenbeschreibung" abschnitt: "Benennung und Bestätigung" - dokument: "R-SPM Rollenbeschreibung" abschnitt: "Mandat SO-Identifikation" - dokument: "G-SOR Geschäftsordnung" abschnitt: "SO-Bestätigung" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-005 datum: "2025-12-16" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" frage: "Welche Entscheidungsergebnisse sind an den Gates möglich?" entscheidung: | Vierstufige Entscheidungsoptionen analog DSR-Verfahren: Gate 1 (SO): - Freigabe - Freigabe mit Auflagen - Zurückweisung - Eskalation an SOR Gate 2 (SOR): - Go-Live-Freigabe - Go-Live mit Auflagen - Zurück an Transition - Service-Ablehnung begruendung: | Das DSR-Entscheidungsverfahren kennt bereits differenzierte Optionen. Diese Logik auf die Gates zu übertragen schafft Konsistenz und reduziert Lernaufwand. Die Vierstufigkeit ermöglicht differenzierte Steuerung – besonders "Freigabe mit Auflagen" verhindert, dass kleine Mängel den gesamten Prozess blockieren. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Quality Gates / Entscheidungsoptionen" - dokument: "G-SOR Geschäftsordnung" abschnitt: "Entscheidungsverfahren" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-006 datum: "2025-12-16" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" frage: "Wie ist die Verantwortungsübergabe PL → SO geregelt?" entscheidung: | Modell "Überlappungszone mit differenzierter Accountability": - Projektphase (bis Gate 1): PL ist A/R, SO ist C (falls benannt) - Überlappungszone (Gate 1 bis Gate 2): - PL: A/R für Projekt-Deliverables - SO: A/R für Service-Scope - Betrieb (ab Gate 2): SO ist A/R, Projekt abgeschlossen Formaler Übergabepunkt: Mit positivem Gate 1 geht die Service-Accountability auf den SO über. PL bleibt für Projekt-Deliverables verantwortlich bis Projektabschluss (nach Gate 2, spätestens Ende ELS). begruendung: | In der Transition-Phase gibt es eine Überlappung – das Projekt läuft möglicherweise noch, aber der Service geht bereits Richtung Betrieb. Klare Abgrenzung ist erforderlich, um Verantwortungslücken zu vermeiden. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Verantwortungsübergang" - dokument: "R-SO Rollenbeschreibung" abschnitt: "Accountability-Übernahme" - dokument: "service-lifecycle_service-transition.yaml" abschnitt: "RACI" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-007 datum: "2025-12-16" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" frage: "Ist der Pilot ein eigenständiges Gate?" entscheidung: | Nein. Die Pilot-Entscheidung ist kein eigenständiges Gate, sondern ein Routing innerhalb von Gate 1. Der SO prüft im Entry-Gate, ob ein Pilot erforderlich ist, und legt ggf. die Pilot-Parameter fest. Der Pilot ist eine optionale Phase zwischen Gate 1 und Gate 2. begruendung: | Ein drittes Gate würde Overhead erzeugen. Die Pilot-Entscheidung ist Teil der Entry-Prüfung – der SO kennt seinen Service und kann einschätzen, ob ein Pilot nötig ist. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Pilot-Konzept" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-008 datum: "2025-12-16" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-01 Gate-Struktur definieren" frage: "Ist ELS-Exit ein formales Gate?" entscheidung: | Nein. Der Übergang von ELS in den Normalbetrieb ist kein formales Gate, sondern eine SO-Entscheidung mit Orientierungsprinzipien. Der SO entscheidet, wann ELS endet, und dokumentiert dies im Service-Steckbrief oder informiert die SOR. begruendung: | Ein drittes Gate würde Overhead erzeugen. ELS ist eine Stabilisierungsphase, deren Ende der SO am besten einschätzen kann. Formale Governance ist hier nicht erforderlich. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "ELS-Konzept" status: "final" # ============================================================================= # GOVERNANCE-ENTSCHEIDUNGEN AUS AP-02: ENTSCHEIDUNGSKRITERIEN # ============================================================================= entscheidungen_ap_02: # --------------------------------------------------------------------------- - id: GOV-TR-009 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-02 Entscheidungskriterien pro Gate" frage: "Wie werden die Gate-Kriterien gestaltet – prinzipienbasiert oder checklistenbasiert?" entscheidung: | Prinzipienbasierter Ansatz für beide Gates (MVP). Grundsatz: "Informed Judgment statt mechanische Prüfung" Der Gate-Keeper trifft eine Gesamtbewertung auf Basis definierter Prüfdimensionen. Die Dimensionen geben die Richtung vor, ohne jeden Einzelfall vorab zu regeln. begruendung: | Für den MVP ist ein prinzipienbasierter Ansatz angemessen. Detaillierte Checklisten erzeugen Governance-Overhead ohne nachgewiesenen Mehrwert. Die operative Erfahrung wird zeigen, wo Präzisierung nötig ist. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Quality Gates / Prüfdimensionen" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-010 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-02 Entscheidungskriterien pro Gate" frage: "Welche Prüfdimensionen gelten für Gate 1 (Entry Transition)?" entscheidung: | Drei Prüfdimensionen: 1. Übergabe-Vollständigkeit (Showstopper) Kernfrage: "Liegt alles vor, was ich für die Transition brauche?" 2. Betriebsvorbereitung (kein Showstopper) Kernfrage: "Sind Betrieb und Support informiert und vorbereitet?" 3. Pilot-Erfordernis (Routing-Entscheidung) Kernfrage: "Braucht dieser Service einen Pilot vor Go-Live?" Nachweisform: Formlos, aber dokumentiert (kurze Notiz, E-Mail, Protokolleintrag) begruendung: | Minimale Prüfdimensionen für den MVP. Nur Übergabe-Vollständigkeit ist Showstopper, da ohne Artefakte keine sinnvolle Transition möglich ist. Betriebsvorbereitung kann mit Auflagen nachgeholt werden. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Gate 1 / Prüfdimensionen" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-011 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-02 Entscheidungskriterien pro Gate" frage: "Welche Prüfdimensionen gelten für Gate 2 (Go-Live-Freigabe)?" entscheidung: | Fünf Prüfdimensionen: 1. SO-Readiness-Bestätigung (Showstopper) Kernfrage: "Hat der SO die Betriebsreife bestätigt?" 2. Betriebs-/Support-Dokumentation (Showstopper) Kernfrage: "Ist die Dokumentation vorhanden UND implementiert?" "Implementiert" bedeutet: verfügbar, bekannt, zugänglich 3. Portfolio-Passung (Showstopper) Kernfrage: "Kein Widerspruch zu bestehenden Services?" MVP-Interpretation: Minimale Prüfung (Variante A) 4. Ressourcen-Commitment (kein Showstopper) Kernfrage: "Haben Betrieb und Support die Kapazität bestätigt?" 5. Auflagen aus Gate 1 (Showstopper, falls vorhanden) Kernfrage: "Falls Auflagen existieren: Sind diese erfüllt?" Nachweisform: Teil des SOR-Protokolls begruendung: | Gate 2 hat mehr Showstopper, da es die finale Freigabe für das Portfolio ist. Insbesondere die Dokumentations-Dimension wurde geschärft: "vorhanden" reicht nicht, "implementiert" ist erforderlich. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Gate 2 / Prüfdimensionen" - dokument: "G-SOR Geschäftsordnung" abschnitt: "Go-Live-Entscheidung" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-012 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-02 Entscheidungskriterien pro Gate" frage: "Was bedeutet 'Portfolio-Passung' bei Gate 2?" entscheidung: | Variante A (minimale Prüfung): "Kein Widerspruch zu bestehenden Services" – im Zweifel passt es. Kein aktiver Strategie-Fit-Nachweis erforderlich, nur Abwesenheit von Konflikten. begruendung: | Für den MVP ist eine niedrige Hürde angemessen. Governance-Overhead gering halten. Variante B (aktive Strategie-Prüfung) macht Sinn, wenn das Portfolio wächst und Priorisierungskonflikte entstehen. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Gate 2 / Portfolio-Passung" status: "final" # ============================================================================= # ZUSAMMENFASSUNG # ============================================================================= zusammenfassung: anzahl_entscheidungen: 24 nach_arbeitspaket: ap_01: 8 ap_02: 4 ap_03: 4 ap_04: 5 ap_05: 3 ap_06: 4 nach_status: final: 24 draft: 0 offene_abhaengigkeiten: - id: "GOV-TR-003" abhaengigkeit: "Synchronisation mit P-03 Change Enablement (Major/Minor)" betroffene_module: - "konzept_service-transition.yaml" - "G-SOR Geschäftsordnung" - "R-SO Rollenbeschreibung" - "R-SPM Rollenbeschreibung" - "service-lifecycle_service-transition.yaml (Blueprint)" - "SPM Glossar" - "P-03 Change Enablement" entscheidungen_ap_03: # --------------------------------------------------------------------------- - id: GOV-TR-011 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-03 Entscheidungskompetenz (Governance)" frage: "Nach welchem Verfahren entscheidet die SOR bei Gate 2?" entscheidung: | Vereinfachtes Konsent-Verfahren: - Grundprinzip: Konsent (Beschluss gilt ohne schwerwiegenden Einwand) - Bei Einwand: Vertagung, SO muss Vorlage überarbeiten - Bei erneutem Einwand: SOR kann eskalieren (MB) oder ablehnen - Kein Alternativzwang für einwendende Rolle Das Verfahren gilt für alle SOR-Entscheidungen (Gate 2, Routing, Service-Anpassungen). begruendung: | Gate-2-Entscheidungen sind operativ-taktisch. Das DSR-Konsent-Verfahren mit iterativem Alternativzwang ist für Routinefreigaben überdimensioniert. Die Überarbeitungspflicht liegt beim SO (nicht bei der einwendenden Rolle), weil der SO für den Service accountable ist. Das vereinfacht das Verfahren und stärkt die SO-Verantwortung. auswirkung_auf: - dokument: "G-SOR Geschäftsordnung" abschnitt: "Entscheidungsverfahren" - dokument: "konzept_service-transition.yaml" abschnitt: "Quality Gates / Gate 2" status: "final" abgrenzung_zu_dsr: | Unterschied zur DSR-GO: Kein Alternativzwang, keine feste Iterationsgrenze. Gemeinsamkeit: Konsent als Grundprinzip, Eskalation an MB möglich. # --------------------------------------------------------------------------- - id: GOV-TR-012 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-03 Entscheidungskompetenz (Governance)" frage: "Wie werden Auflagen bei 'Freigabe mit Auflagen' gehandhabt?" entscheidung: | Protokoll-basiertes Tracking: 1. Formulierung: Gate-Keeper formuliert Auflagen (konkret, mit Frist, mit Verantwortlichem) 2. Dokumentation: Im Gate-Protokoll (SOR-Protokoll für Gate 2) 3. Tracking: - Gate-1-Auflagen: SO bestätigt Erfüllung in Gate-2-Vorlage, SOR prüft bei Gate 2 - Gate-2-Auflagen: SO dokumentiert im Steckbrief, SOR prüft bei ELS-Ende 4. Bei Nicht-Erfüllung: - Vor Folgegate: Gate kann nicht positiv entschieden werden - Im ELS: ELS kann nicht beendet werden begruendung: | Ein formales Auflagen-Register würde Overhead ohne nachgewiesenen Nutzen erzeugen. Das Protokoll-basierte Tracking nutzt bestehende Strukturen (SOR-Protokoll, Service-Steckbrief) und etabliert eine klare Prüflogik. Auflagen sind verbindlich (nicht nur Empfehlungen) – die Integration in die Gate-Logik sichert die Durchsetzung. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Quality Gates / Auflagen" - dokument: "G-SOR Geschäftsordnung" abschnitt: "Protokollierung" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-013 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-03 Entscheidungskompetenz (Governance)" frage: "Wie wird Gate 1 bei SO-Abwesenheit gehandhabt?" entscheidung: | Verschiebung mit Eskalationsoption: 1. Regelfall (kurzfristige Abwesenheit bis 4 Wochen): - Gate 1 wird verschoben bis SO verfügbar ist - Keine automatische Vertretung 2. Ausnahme bei Dringlichkeit: - SPM beurteilt, ob Verzögerung kritisch wäre - SPM kann an SOR eskalieren - SOR entscheidet dann Gate 1 + Gate 2 gemeinsam 3. Längere Vakanz (über 4 Wochen): - SOR entscheidet über Interim-SO oder Neubenennung - SPM bringt Vorschlag ein Keine Pflicht zur präventiven Stellvertreter-Benennung (nur Empfehlung). begruendung: | Der SO ist persönlich accountable für Gate-1-Entscheidungen. Eine automatische Stellvertretung würde diese Accountability verwässern. Die Verschiebung ist in den meisten Fällen unproblematisch. Die Eskalationsoption sichert Handlungsfähigkeit bei echten Dringlichkeiten, ohne eine Pflicht zur Stellvertreter-Benennung zu erzeugen. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Quality Gates / Gate 1 / Vertretung" - dokument: "R-SO Rollenbeschreibung" abschnitt: "Vertretung" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-014 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-03 Entscheidungskompetenz (Governance)" frage: "Wie werden Gate-Entscheidungen vorbereitet?" entscheidung: | Steckbrief-Integration mit Pflichtfeldern: 1. Vorlage-Dokument: Service-Steckbrief (erweitert um Gate-Readiness) 2. Verantwortlich: - Gate 1: PL erstellt, SO gibt frei - Gate 2: SO erstellt und reicht ein 3. Pflichtinhalte Gate 1: - Service-Bezeichnung und Version - Kurzbeschreibung des Service-Scopes - Benannter Service Owner - Abnahme durch Auftraggeber - Bekannte Einschränkungen oder Risiken - Pilot-Empfehlung 4. Pflichtinhalte Gate 2: - Erfüllung Gate-1-Auflagen - Betriebsbereitschaft (bestätigt) - Support-Bereitschaft (bestätigt) - Pilot-Ergebnis (falls durchgeführt) - SLA/SLO-Entwurf - Katalog-Eintrag-Entwurf 5. Einreichungsfrist: 3 Arbeitstage vor SOR-Sitzung 6. Vollständigkeitsprüfung durch SPM bei Einreichung begruendung: | Der Service-Steckbrief existiert bereits und wird ohnehin gepflegt. Die Integration vermeidet Doppelarbeit und stellt Konsistenz sicher. Die 3-Tage-Frist ermöglicht Tagesordnungs-Erstellung und Vorab-Prüfung. Unvollständige Vorlagen werden nicht in der Sitzung diskutiert, um Sitzungszeit zu schonen. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Gate-Vorbereitung" - dokument: "G-SOR Geschäftsordnung" abschnitt: "Sitzungsvorbereitung" - dokument: "spm_schema_service-steckbrief.yaml" abschnitt: "Gate-Readiness (neuer Abschnitt)" status: "final" - id: GOV-TR-013 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" frage: "Wie wird ELS zeitlich parametrisiert?" entscheidung: | Hybrid-Korridor mit drei Parametern: - Mindestdauer: 2 Wochen (verbindlich) - Regeldauer: 4 Wochen (Orientierung) - Maximaldauer: 8 Wochen (Eskalations-Trigger) Innerhalb des Korridors entscheidet SO zustandsbasiert anhand der Exit-Kriterien. Vor Ablauf der Mindestdauer ist kein Exit möglich, auch bei Stabilität. begruendung: | Der Hybrid-Ansatz balanciert SO-Ermessen (Governance-Prinzip "Informed Judgment") mit operativer Planbarkeit. Er vermeidet die Extreme von mechanischem Zeitablauf und völliger Beliebigkeit. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "ELS-Konzept" status: "final" validierungshinweis: | ACHTUNG: Alle Zeitwerte (2/4/8 Wochen) sind MVP-ANNAHMEN. Erforderlich: - Bestätigung vor MVP-Start mit DIGIT-Stakeholdern - Bewertung während MVP-Phase anhand konkreter Fälle - Ggf. Anpassung nach ersten operativen Erfahrungen # --------------------------------------------------------------------------- - id: GOV-TR-014 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" frage: "Wie ist die Projektverfügbarkeit während ELS geregelt?" entscheidung: | Gestaffelte Übergabe mit abnehmender Intensität: Phase 1 (ELS-Woche 1-2): - Verfügbarkeit: verpflichtend - Reaktionszeit: 4 Stunden (Geschäftszeiten) - Umfang: Troubleshooting, Wissenstransfer, Bug-Fixes Phase 2 (ab ELS-Woche 3): - Verfügbarkeit: auf Abruf - Reaktionszeit: 2 Arbeitstage - Umfang: Nur dokumentierte Eskalationsfälle (Severity 1-2) Projekt-Exit frühestens nach Mindestdauer (2 Wochen). Abruf-Verfügbarkeit für 4 Wochen nach Projekt-Exit. begruendung: | Realistischer Kompromiss zwischen Projekt-Abschlussdruck und Absicherung der kritischen Phase. Korrespondiert mit ELS-Dauer-Logik (Phase 1 = Mindestdauer). Verantwortung (A) bleibt beim SO. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "ELS-Konzept" status: "final" validierungshinweis: | ACHTUNG: Zeiträume und Reaktionszeiten sind MVP-ANNAHMEN. Erforderlich: - Prüfung der Kompatibilität mit DIGIT-Projektbudget-/Ressourcenlogik - Bestätigung vor MVP-Start - Bewertung anhand konkreter Fälle # --------------------------------------------------------------------------- - id: GOV-TR-015 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" frage: "Was ist eine 'kritische Störung' im ELS-Kontext?" entscheidung: | Minimaldefinition für ELS-Exit-Bewertung: Eine Störung gilt als kritisch, wenn BEIDE Kriterien erfüllt sind: (1) Nutzbarkeitseinschränkung: Service ist für wesentliche Nutzergruppe (>20% oder geschäftskritisch) nicht oder nur stark eingeschränkt nutzbar. (2) Kein Workaround: Es existiert kein praktikabler Workaround, der die Einschränkung kompensiert. Bei Grenzfällen entscheidet SO und dokumentiert Einschätzung. begruendung: | Operationalisierbar ohne vollständige Severity-Klassifikation. Vermeidet Abhängigkeit von SSM-Entwicklung. Anschlussfähig an spätere Severity-Klassifikation (entspricht dort Severity 1-2). auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "ELS-Konzept" - dokument: "SSM Incident Management" abschnitt: "Severity-Klassifikation" hinweis: "Konsistenzprüfung bei SSM-Finalisierung erforderlich" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-016 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" frage: "Wie wird das ELS-Ende dokumentiert?" entscheidung: | Leichtgewichtiger ELS-Vermerk im Service-Steckbrief. Kein separater Abschlussbericht erforderlich. Pflichtfelder: - els_start (Datum) - els_ende (Datum) - els_dauer_wochen (Zahl) - kritische_stoerungen_anzahl (Zahl) - exit_begruendung (Kurztext, max. 500 Zeichen) Optionales Feld: - lessons_learned (Kurztext) Erweiterung bei Auffälligkeiten (>6 Wochen ODER >2 krit. Störungen): - ursachenanalyse (Pflicht) - massnahmen_fuer_zukunft (Pflicht) begruendung: | Passt zu leichtgewichtiger Governance ("kein formales Gate"). Vermeidet Artefakt-Inflation durch Integration in Steckbrief. Stellt Nachweisbarkeit für ersten Service Review sicher. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "ELS-Konzept" - dokument: "spm_schema_service-steckbrief.yaml" abschnitt: "Neue Felder: els_verlauf" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-017 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-04 ELS-Konzept schärfen" frage: "Was passiert bei Überschreitung der ELS-Maximaldauer?" entscheidung: | Automatische Eskalation an SOR bei Überschreitung der Maximaldauer (8 Wochen). Mechanismus: - SPM überwacht ELS-Dauern - Bei Überschreitung: Pflicht-Agenda-Punkt in nächster SOR - SO bereitet Sachstandsbericht vor (Frist: 3 AT vor SOR) SOR-Entscheidungsoptionen: (1) ELS-Verlängerung (max. 4 Wochen, mit neuem Zieldatum) (2) Rückführung in Transition (neuer Gate-2-Antrag erforderlich) (3) Zwangs-Exit (mit dokumentierter Risiko-Akzeptanz durch SOR) (4) Service-Stilllegung (nur in Extremfällen) Bei erneuter Überschreitung nach Verlängerung: erneute Eskalation. begruendung: | Überschreitung der Maximaldauer signalisiert Problem, das SO-Kompetenz übersteigt. SOR als Portfolio-Governance ist richtiger Adressat. Definierte Optionen geben klaren Handlungsrahmen und vermeiden Endlos-Schleifen. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "ELS-Konzept" - dokument: "spm_sor-geschaeftsordnung.yaml" abschnitt: "Standard-Agenda-Punkte" hinweis: "ELS-Eskalation als möglichen Punkt aufnehmen" status: "final" - id: GOV-TR-018 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-05 Rollback- und Abbruch-Szenarien" frage: "Was bedeutet 'Zurück an Transition' bei Gate-2-Zurückweisung operativ?" entscheidung: | SO-Verantwortung mit Zeitrahmen: 1. Verantwortlichkeit: - SO verantwortet die Mängelbeseitigung - SO entscheidet über Wiedervorlage-Zeitpunkt - SPM überwacht Fristen 2. Zeitrahmen: - Standardfrist: 8 Wochen für Wiedervorlage - Verlängerung durch SOR möglich (begründeter Antrag) - Eskalation an SOR nach 10 Wochen ohne Wiedervorlage 3. Status: - Service bleibt in "in_transition" - Keine formale Statusänderung 4. Dokumentation: - Zurückweisungsgründe im SOR-Protokoll - Erwartete Wiedervorlage (Datum/KW) begruendung: | Schlanke Variante ohne Bürokratie-Overhead. Nutzt die bestehende SO-Accountability für den Service-Erfolg. Die Zeitbegrenzung verhindert "Zombie-Services", die endlos in der Transition-Schleife bleiben. Keine formale Statusänderung, da der Service konzeptionell weiterhin "in Transition" ist – nur mit identifizierten Nachbesserungsbedarfen. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Rollback-Szenarien / Gate-2-Zurückweisung" - dokument: "G-SOR Geschäftsordnung" abschnitt: "Protokollierung / Zurückweisungen" - dokument: "R-SO Rollenbeschreibung" abschnitt: "Verantwortlichkeiten / Nachbesserung" status: "final" confidence: "75%" unsicherheit: | Die 8-Wochen-Frist ist eine Orientierung. Je nach Art der Mängel kann mehr oder weniger Zeit erforderlich sein. Die Frist sollte als Richtwert, nicht als harter Constraint verstanden werden. # --------------------------------------------------------------------------- - id: GOV-TR-019 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-05 Rollback- und Abbruch-Szenarien" frage: "Wer kann während ELS einen Service stoppen, und wie?" entscheidung: | SO-Einzelentscheidung mit Informationspflicht: 1. Entscheidungskompetenz: - SO hat Mandat zur Einzelentscheidung "Service-Stopp" - Keine vorherige SOR-Abstimmung erforderlich - Begründung ist erforderlich 2. Kommunikationspflichten: Unverzüglich: - SPM (koordiniert SOR-Behandlung) - Support Manager (Nutzer-Kommunikation) - Operations Manager (technische Deaktivierung) Innerhalb 24h: - SOR (alle Mitglieder) per E-Mail 3. Folgezustand: - Service-Status wird "suspended" - Katalog zeigt "temporär nicht verfügbar" 4. Nächste Schritte: - SOR-Behandlung innerhalb 5 Werktagen - SOR entscheidet: Wiederaufnahme / Zurück an Transition / Ablehnung begruendung: | In einer Krisensituation muss jemand handlungsfähig sein – das ist der SO als Accountable für den Service-Erfolg. Die Informationspflicht stellt sicher, dass die SOR involviert wird, ohne dass sie zum Bottleneck wird. Wichtig: Ein Service-Stopp ist ein Qualitätssicherungsinstrument, keine Schuldzuweisung. SOs sollten diese Kompetenz bei Bedarf nutzen. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Rollback-Szenarien / ELS-Rollback" - dokument: "R-SO Rollenbeschreibung" abschnitt: "Entscheidungsbefugnisse / Service-Stopp" - dokument: "G-SOR Geschäftsordnung" abschnitt: "Außerordentliche Behandlung" status: "final" confidence: "70%" unsicherheit: | Die Governance allein löst nicht die Frage, ob SOs diese Kompetenz auch tatsächlich wahrnehmen werden. Es besteht das Risiko, dass SOs aus Angst vor Gesichtsverlust zu lange warten. Das ist eine kulturelle Frage, die das Modell nicht allein adressieren kann. abgrenzung: | Ein Service-Stopp ist NICHT die Reaktion auf einzelne Incidents. Incidents werden über das reguläre Incident Management behandelt. Ein Service-Stopp ist angezeigt, wenn der Service als Ganzes seinen Zweck nicht erfüllt und keine kurzfristige Lösung absehbar ist. # --------------------------------------------------------------------------- - id: GOV-TR-020 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-05 Rollback- und Abbruch-Szenarien" frage: "Gibt es eine formale Iterationsgrenze für Zurückweisungen bei Gate 2?" entscheidung: | MVP: Keine formale Grenze – situative SOR-Entscheidung. 1. Grundsatz: - Die SOR entscheidet bei jeder Zurückweisung situativ - Keine automatischen Trigger für Service-Ablehnung - Keine feste Anzahl erlaubter Iterationen 2. Orientierungshilfe für SOR: Bei jeder Zurückweisung sollte die SOR prüfen: - Sind die Probleme grundsätzlich lösbar? - Sind Ressourcen für weitere Iteration verfügbar? - Ist die strategische Passung noch gegeben? - Wie lange ist der Service schon in Transition? - Wie viele Zurückweisungen gab es bereits? 3. Empfehlung: Ab der dritten Zurückweisung sollte die SOR explizit begründen, warum eine Fortsetzung noch sinnvoll ist – oder Service-Ablehnung beschließen. begruendung: | Für den MVP ist eine situative Entscheidung angemessen. Die Praxis wird zeigen, ob und wann formale Grenzen nötig sind. Zu frühe Formalisierung könnte entweder zu starr sein (verhindert sinnvolle Fortsetzungen) oder zu weich (verhindert nötige Abbrüche). Das Risiko von "Zombie-Services" ist bekannt und muss von der SOR aktiv gemanagt werden. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Rollback-Szenarien / Projekt-Termination" - dokument: "G-SOR Geschäftsordnung" abschnitt: "Service-Ablehnung" status: "final" confidence: "65%" unsicherheit: | Ohne formale Grenzen besteht das Risiko von "Zombie-Services", die endlos in der Transition-Schleife bleiben. Die SOR muss dieses Risiko aktiv managen. evolutionspfad: | Bei Praxisproblemen (Zombie-Services, Willkür-Vorwürfe, Entscheidungs- Paralyse) sollte das Modell weiterentwickelt werden zu: "Option D: Kombiniertes Modell" - Nach 2. Zurückweisung: Pflicht-Analyse durch SPM - Nach 3. Zurückweisung ODER nach 6 Monaten: Default = Ablehnung - Fortsetzung nur durch expliziten SOR-Beschluss mit Begründung Indikatoren für Weiterentwicklung: - Services länger als 6 Monate in Transition ohne Fortschritt - SOR-Mitglieder beklagen fehlende Orientierung - Wahrnehmung von Willkür bei Ablehnungsentscheidungen - Ressourcenkonflikte durch zu viele parallele Transition-Services # ============================================================================= # GOVERNANCE-ENTSCHEIDUNGEN AUS AP-06: BEGRIFFLICHE HARMONISIERUNG # ============================================================================= entscheidungen_ap_06: # --------------------------------------------------------------------------- - id: GOV-TR-021 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-06 Begriffliche Harmonisierung" frage: "Was bedeutet 'Aktivierung' im Service-Transition-Kontext?" entscheidung: | Einheitsmodell: "Aktivierung" ist ein atomarer Akt, der durch die Go-Live-Freigabe (Gate 2) ausgelöst wird und gleichzeitig bewirkt: (1) Statusübergang des Services auf lifecycle_status = "aktiv" (2) Sichtbarkeit des Services im Service-Katalog (3) Bestellbarkeit/Nutzbarkeit des Services durch berechtigte Nutzer Es gibt KEINE Trennung zwischen "Portfolio-Aufnahme" und "Katalog-Aktivierung" bei Go-Live. begruendung: | Kein validierter Use Case für eine Trennung bei Aktivierung. MVP-Prinzip: Komplexität nur bei nachgewiesenem Bedarf. Die Governance ist klar: SOR entscheidet einmalig, alle Effekte folgen. abgrenzung: | "Aktivierung" bezeichnet nicht: - Die Gate-2-Entscheidung selbst (diese heißt "Go-Live-Freigabe") - Die technische Bereitstellung (diese heißt "Deployment" oder "Rollout") - Die Aufnahme in Governance-Strukturen (implizit durch Gate 2) auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Begriffsklärungen" - dokument: "service-lifecycle_service-transition.yaml" abschnitt: "st_04 Begrifflichkeit" status: "final" validierungsstatus: "MVP-Annahme, Workshop-Validierung empfohlen" # --------------------------------------------------------------------------- - id: GOV-TR-022 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-06 Begriffliche Harmonisierung" frage: "Wie wird der Service-Status modelliert?" entscheidung: | Zwei-Status-Modell: (1) Dokumenten-Status (metadata.status): entwurf / freigegeben / archiviert Beschreibt die Gültigkeit der Service-Definition als Dokument. (2) Lifecycle-Status (lifecycle.lifecycle_status): in_entwicklung / in_transition / aktiv / in_stilllegung / stillgelegt / abgebrochen Beschreibt die Phase des Services im Service-Lifecycle. Beide Status sind unabhängig, aber es gibt Korrelationsregeln (z.B. lifecycle_status = "aktiv" erfordert status = "freigegeben"). begruendung: | Die bisherige Vermischung von Dokumenten- und Lifecycle-Status führte zu semantischer Verwirrung. Das Zwei-Status-Modell trennt sauber: - Informationsmanagement-Perspektive (Dokument) - Lifecycle-Management-Perspektive (Service) auswirkung_auf: - dokument: "spm_schema_service-definition.yaml" abschnitt: "Neuer Abschnitt 'lifecycle'" - dokument: "service-lifecycle_service-transition.yaml" abschnitt: "Status-Referenzen korrigieren" status: "final" schema_patch: "Erforderlich – lifecycle-Abschnitt hinzufügen" # --------------------------------------------------------------------------- - id: GOV-TR-023 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-06 Begriffliche Harmonisierung" frage: "Wie verhalten sich Service-Portfolio und Service-Katalog zueinander?" entscheidung: | Hierarchisches Modell: Der Katalog ist eine Teilmenge des Portfolios. - Service-Portfolio: Gesamtheit aller Services in DIGIT-Verantwortung, unabhängig vom Lifecycle-Status. Governance-Objekt der SOR. - Service-Katalog: Gefilterte Sicht auf das Portfolio mit lifecycle_status = "aktiv". Für Kunden sichtbar. Der Katalog ist kein separates Register, sondern eine View auf das Portfolio. "Aufnahme ins Portfolio" und "Aktivierung im Katalog" sind bei Go-Live ein und derselbe Vorgang. Portfolio-Struktur: - Pipeline: lifecycle_status in (in_entwicklung, in_transition) - Katalog: lifecycle_status = aktiv - In Stilllegung: lifecycle_status = in_stilllegung - Retired: lifecycle_status = stillgelegt begruendung: | ITIL4-konforme Trennung wäre konzeptionell richtig, aber für MVP zu aufwändig. Das hierarchische Modell bietet konzeptionelle Klarheit bei operativer Einfachheit. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Begriffsklärungen" - dokument: "spm_practice_service-catalog-management.yaml" abschnitt: "Katalog-Definition" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-024 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-06 Begriffliche Harmonisierung" frage: "Werden die ITIL4-Begriffe 'Release' und 'Deployment' übernommen?" entscheidung: | Begriffe übernehmen, aber keine formale Prozess-Trennung im MVP. - Release: Versionspaket, das zur Bereitstellung vorbereitet wurde. Erstellung ist Teil der Service-Entwicklung (SE). - Deployment: Technischer Vorgang der Installation in Zielumgebung. Ist Aktivität in Service Transition (st_02). - Rollout: DIGITOM-Alltagsbegriff für die integrative Bereitstellung, die Release-Übergabe und Deployment umfasst. Im MVP werden Release Management und Deployment Management NICHT als separate Practices modelliert. begruendung: | Die ITIL4-Begriffe sind branchenetabliert – sie zu vermeiden erzeugt Reibung mit externen Stakeholdern. Eine formale Prozess-Trennung ist für DIGIT aktuell nicht erforderlich. Bei wachsender Komplexität kann später differenziert werden. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Begriffsklärungen / Glossar" status: "final" revisionshinweis: | Bei komplexeren Release-Zyklen (z.B. eigenentwickelte Fachverfahren) sollte die Entscheidung revidiert werden. # ============================================================================= # GOVERNANCE-ENTSCHEIDUNGEN AUS AP-07: TRANSITION-ARTEFAKTE # ============================================================================= # Zur Integration in: spm_governance-entscheidungen-log.yaml # Arbeitspaket: AP-07 Transition-Artefakte definieren # Datum: 2025-12-17 # ============================================================================= entscheidungen_ap_07: # --------------------------------------------------------------------------- - id: GOV-TR-025 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-07 Transition-Artefakte definieren" frage: "Wie werden die Transition-Artefakte dokumentiert – verteilt in verschiedenen Dokumenten oder konsolidiert?" entscheidung: | Einführung eines eigenständigen "Transition-Steckbriefs" als konsolidiertes Prozessdokument. Der Transition-Steckbrief: - Wird bei Übergabe aus Service-Entwicklung angelegt - Dokumentiert alle Gate-Entscheidungen (Gate 1, Gate 2) - Enthält Pilot-Entscheidung und -Ergebnisse (falls relevant) - Dokumentiert den ELS-Verlauf - Enthält eine Abschluss-Checkliste - Wird bei ELS-Exit abgeschlossen Der Transition-Steckbrief ersetzt die ursprünglich geplanten Schema-Erweiterungen für den Service-Steckbrief (gate_readiness, els_verlauf) sowie die separaten Artefakte "Transition-Checkliste", "Betriebsreife-Nachweis" und "ELS-Vermerk". begruendung: | Ein konsolidiertes Dokument bietet mehrere Vorteile: 1. Kohärenz: Alle Transition-Informationen an einem Ort statt verstreut über Steckbrief-Erweiterungen und Gate-Protokolle 2. Nachweisbarkeit: Vollständige Dokumentation des Transition- Prozesses für Service Review und Audit 3. Prozess-Analogie: Konsistent mit dem Bedarfs-Steckbrief im Demand-Lifecycle, der ebenfalls ein temporäres Prozessdokument ist und nach Abschluss überführt wird 4. Klarheit: Eliminiert Phantom-Artefakte und begriffliche Unschärfen (z.B. "Betriebsreife-Nachweis" vs. "SO-Readiness") auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Artefakte" aenderung: "Neuer Abschnitt 'Transition-Steckbrief' mit Verweis auf Schema" - dokument: "spm_schema_transition-steckbrief.yaml" abschnitt: "Gesamtes Dokument" aenderung: "Neues Schema-Dokument erstellen" - dokument: "AP-01 bis AP-06 (TMP-Files)" abschnitt: "Diverse" aenderung: "Begriffe werden bei Konsolidierung (AP-09) ersetzt" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-026 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-07 Transition-Artefakte definieren" frage: "Was passiert mit dem Transition-Steckbrief nach Abschluss der Transition?" entscheidung: | Nach Abschluss der Transition (ELS-Exit) wird der Transition- Steckbrief als Anhang in den Service-Steckbrief überführt. Überführungsprozess: 1. SO schließt Transition-Steckbrief ab (Status: "abgeschlossen") 2. Transition-Steckbrief wird als Anhang an Service-Steckbrief gehängt (Abschnitt: "transition_historie" oder als verlinktes Dokument) 3. Wesentliche Kennzahlen (ELS-Dauer, kritische Störungen) werden in Service-Steckbrief-Metadaten übernommen Der Transition-Steckbrief bleibt als historisches Dokument erhalten und wird nicht gelöscht. begruendung: | Die Überführung stellt sicher, dass: 1. Der Service-Steckbrief das "lebende Dokument" bleibt und nicht mit Prozess-Details überfrachtet wird 2. Die Transition-Historie für Service Review verfügbar ist 3. Bei späteren Änderungen (Re-Transition) ein neuer Transition- Steckbrief angelegt werden kann, ohne den alten zu überschreiben Das Muster entspricht dem Bedarfs-Steckbrief → Demand-Steckbrief Übergang im DPM. auswirkung_auf: - dokument: "spm_schema_service-steckbrief.yaml" abschnitt: "anhaenge oder transition_historie" aenderung: "Feld für Transition-Steckbrief-Referenz ergänzen" - dokument: "konzept_service-transition.yaml" abschnitt: "Artefakte > Lifecycle" aenderung: "Überführungsprozess dokumentieren" status: "final" # --------------------------------------------------------------------------- - id: GOV-TR-027 datum: "2025-12-17" quelle_modul: "K-TR Rahmenkonzept Service Transition" quelle_arbeitspaket: "AP-07 Transition-Artefakte definieren" frage: "Welche bisherigen Artefakt-Begriffe werden durch den Transition-Steckbrief ersetzt?" entscheidung: | Folgende Begriffe werden eliminiert bzw. ersetzt: ERSETZT DURCH TRANSITION-STECKBRIEF: - "Transition-Checkliste" → Transition-Steckbrief.abschluss_checkliste - "Betriebsreife-Nachweis" → Transition-Steckbrief.gate_2.so_readiness - "SO-Readiness-Bestätigung" → Transition-Steckbrief.gate_2.so_readiness - "ELS-Vermerk" → Transition-Steckbrief.els - "ELS-Abschlussbericht" → Transition-Steckbrief.els - "Gate-1-Nachweis" → Transition-Steckbrief.gate_1 - "Pilot-Entscheidung" → Transition-Steckbrief.gate_1.pilot_entscheidung - "Steckbrief.gate_readiness" → Transition-Steckbrief (separates Dokument) - "Steckbrief.els_verlauf" → Transition-Steckbrief.els BLEIBT UNVERÄNDERT: - "Go-Live-Protokoll" = Teil des SOR-Protokolls (kein separates Artefakt) - "Auflagen-Dokumentation" = Teil des jeweiligen Gate-Protokolls - "Sachstandsbericht" = Nur bei Eskalation, separate SOR-Vorlage EXTERNE ARTEFAKTE (nicht K-TR-Scope): - "Betriebshandbuch" → Input aus Service-Entwicklung - "Testprotokolle" → Input aus Service-Entwicklung - "SLA/SLO-Vereinbarung" → Definiert in P-02 SLM - "Katalog-Eintrag" → Definiert in P-01 SCM begruendung: | Die begriffliche Konsolidierung beseitigt Redundanzen und Phantom-Artefakte, die in der bisherigen Dokumentation entstanden sind. Ein klares Mapping erleichtert die Konsolidierung (AP-09) und verhindert Inkonsistenzen im finalen Konzept. auswirkung_auf: - dokument: "konzept_service-transition.yaml" abschnitt: "Gesamtes Dokument" aenderung: "Begriffe bei Konsolidierung ersetzen" - dokument: "AP-01 bis AP-06 (TMP-Files)" abschnitt: "Diverse" aenderung: "Mappings bei AP-09 berücksichtigen" konsolidierungshinweis: | Bei der YAML-Konsolidierung (AP-09) ist dieses Mapping als Referenz zu verwenden. Die TMP-Files werden nicht einzeln gepatcht, sondern die Begriffe werden bei der Überführung in das finale Konzept ersetzt. status: "final" # ============================================================================= # K-SR KONZEPT SERVICE-REVIEW # ============================================================================= entscheidungen_service_review: - id: GOV-SR-001 datum: "2025-12-17" quelle_modul: "K-SR Konzept Service-Review" frage: "Anhand welcher Dimensionen und mit welcher Methodik bewertet der SO den Service-Zustand?" entscheidung: | 4-Dimensionen-Modell mit qualitativer Ampelbewertung: - SR-D1: Leistungserbringung (Liefert der Service den erwarteten Nutzen?) - SR-D2: Betriebsstabilitaet (Laeuft der Service stoerungsarm?) - SR-D3: Nutzerzufriedenheit (Wie bewerten die Nutzer den Service?) - SR-D4: Zukunftsfaehigkeit (Ist der Service mittelfristig tragfaehig?) Bewertungsskala: Gruen (stabil) / Gelb (beobachten) / Rot (Handlungsbedarf) Keine mathematische Aggregation - SO fasst zu Gesamteinschaetzung zusammen. begruendung: | - Strukturelle Analogie zu SHM (VoC-Cluster D1-D4) schafft Modellkonsistenz - Qualitative Bewertung realistisch bei fehlender KPI-Infrastruktur - Ampellogik intuitiv und entscheidungsvorbereitend - SO kann Verfahren in 30-60 Min/Quartal durchfuehren - Erweiterbar: Spaetere KPIs koennen als Indikatoren einfliessen auswirkung_auf: - dokument: "spm_schema_service-steckbrief.yaml" abschnitt: "review_status" - dokument: "service-lifecycle_service-review.yaml" abschnitt: "sr_02" status: "final" confidence: "80%" # --------------------------------------------------------------------------- - id: GOV-SR-002 datum: "2025-12-17" quelle_modul: "K-SR Konzept Service-Review" frage: "In welchem Rhythmus findet der Service-Review statt und wie verhaelt er sich zu SOR?" entscheidung: | Hybridmodell: 1. SO fuehrt quartalsweise Selbst-Review durch (eigenstaendig) 2. SO aktualisiert Service-Definition mit Review-Ergebnis (Abschnitt 'service_review') 3. SO informiert SPM (alle Review-Berichte, unabhaengig vom Ergebnis) 4. SOR-Einbeziehung nur bei: - Mind. eine Dimension "Rot" - Handlungsempfehlung: IMPROVEMENT (ressourcenrelevant), REDESIGN, RETIRE - SO ist unsicher 5. Anlassbezogener Ad-hoc-Review bei Major Incident, SLA-Verletzung, Eskalation begruendung: | - Skaliert mit Portfolio-Groesse (nicht jeder Service braucht SOR-Zeit) - SO behaelt Eigenverantwortung (Subsidiaritaetsprinzip) - SPM hat Portfolio-Uebersicht fuer Aggregation und Muster-Erkennung - SOR fokussiert auf Ausnahmen (Management by Exception) - Konsistent mit E2-Quartalsrhythmus im SHM auswirkung_auf: - dokument: "spm_schema_service-definition.yaml" abschnitt: "service_review" - dokument: "rolle_service-owner.yaml" abschnitt: "verantwortlichkeiten" - dokument: "spm_rollen.yaml" abschnitt: "service_portfolio_manager" status: "final" confidence: "85%" # --------------------------------------------------------------------------- - id: GOV-SR-003 datum: "2025-12-17" quelle_modul: "K-SR Konzept Service-Review" frage: "Gibt es objektive Schwellenwerte fuer automatische Handlungen oder Eskalation?" entscheidung: | Orientierungskriterien mit Urteilsvorbehalt: - Kriterien definieren typische Konstellationen fuer jeden Entscheidungspfad - Keine automatischen Trigger - finales Urteil beim SO - Bei Abweichung von Orientierung: Begruendungspflicht (2-3 Saetze) Typische Konstellationen: - CONTINUE: Alle Gruen oder max. eine Gelb - IMPROVEMENT: Eine/mehrere Rot, im Service-Rahmen loesbar - REDESIGN: Mehrere Rot ueber Quartale, Architektur-Problem - RETIRE: Kaum genutzt, unverhaeltnismaessiger Aufwand begruendung: | - Konsistent mit SHM-Logik (qualitative Trigger mit Begruendungspflicht) - Vermeidet Schein-Objektivitaet durch nicht vorhandene Datenbasis - Erhaelt Flexibilitaet fuer Service-spezifische Kontexte - Begruendungspflicht bei Abweichung sichert Governance-Qualitaet auswirkung_auf: - dokument: "konzept_service-review.yaml" abschnitt: "entscheidungspfade" status: "final" confidence: "75%" # --------------------------------------------------------------------------- - id: GOV-SR-004 datum: "2025-12-17" quelle_modul: "K-SR Konzept Service-Review" frage: "Wie laeuft die SOR-Behandlung eines Service-Reviews konkret ab?" entscheidung: | Differenziertes Verfahren nach Handlungsempfehlung: 1. Kenntnisnahme (keine SOR-Agenda): - CONTINUE - IMPROVEMENT (SO-gefuehrt, ressourcenneutral) -> SO dokumentiert im Steckbrief, informiert SPM 2. Operative Entscheidung (SOR-Behandlung): - IMPROVEMENT (ressourcenrelevant) -> SO reicht Review-Vorlage ein, SOR entscheidet (Konsens) 3. Strategische Entscheidung (SOR-Behandlung): - REDESIGN, RETIRE -> SOR entscheidet, bei Freigabe Uebergabe an DPM -> Bei Dissens/Tragweite: Eskalation an MB Vorlage-Anforderungen: Einreichung 3 AT vor Sitzung an SPM begruendung: | - Fokussiert SOR-Zeit auf Entscheidungen, die Governance erfordern - CONTINUE und kleine IMPROVEMENTs sind SO-Verantwortung (Subsidiaritaet) - Nur ressourcen-/portfoliorelevante Entscheidungen brauchen Gremiumszeit auswirkung_auf: - dokument: "spm_sor-geschaeftsordnung.yaml" abschnitt: "entscheidungsgegenstaende" - dokument: "rolle_service-owner.yaml" abschnitt: "befugnisse" status: "final" confidence: "80%" # --------------------------------------------------------------------------- - id: GOV-SR-005 datum: "2025-12-17" quelle_modul: "K-SR Konzept Service-Review" frage: "Wie wird die Wirksamkeit von Improvement-Massnahmen nachgehalten?" entscheidung: | MVP-Loesung: Service-Definition-Tracking 1. Improvement-Massnahmen werden in der Service-Definition dokumentiert (Abschnitt "laufende_verbesserungen") 2. Pflichtfelder: ID, Beschreibung, Ziel-Dimension, Verantwortlich, Termin, Status 3. Im naechsten Quartals-Review: SO prueft Wirksamkeit (Hat sich betroffene Dimension verbessert?) 4. Keine separate CI-Infrastruktur im MVP Post-MVP: Dedizierte CI-Practice mit zentralem Improvement-Register begruendung: | - Minimal Viable: Kein neues Tooling/Practice erforderlich - Governance-Anker: Service-Definition + Review-Zyklus sichert Nachverfolgung - Erweiterbar: Bei CI-Practice-Etablierung kann migriert werden auswirkung_auf: - dokument: "spm_schema_service-definition.yaml" abschnitt: "laufende_verbesserungen" status: "final" confidence: "70%" - id: "GOV-CE-001" datum: "2025-12-17" quelle_modul: "P-03 Change Enablement" frage: "Wie werden Emergency Changes gehandhabt?" entscheidung: | Sofortumsetzung durch Betrieb/Support mit nachträglicher Dokumentation. Service Owner wird informiert, nicht um Genehmigung gefragt. Dokumentation innerhalb 24 Stunden. begruendung: | Bei kritischen Sicherheits- oder Verfügbarkeitsproblemen ist Geschwindigkeit entscheidend. Ein Genehmigungsprozess würde Schaden vergrößern. Die nachträgliche Dokumentation stellt Nachvollziehbarkeit sicher. auswirkung_auf: - dokument: "spm_practice_change-enablement.yaml" abschnitt: "change_typen.emergency_change" status: "final" - id: "GOV-CE-002" datum: "2025-12-17" quelle_modul: "P-03 Change Enablement" frage: "Gilt Change Enablement für Infrastruktur ohne Service-Bezug?" entscheidung: | Nein. Fokus auf Service-Changes. Infrastruktur ohne direkten Service-Bezug (z.B. Netzwerk-Basis) ist der Produkt-Ebene zuzuordnen und wird in dieser Phase nicht adressiert. begruendung: | Die aktuelle Projektphase priorisiert die Kunden-/Service-Sicht. Produkt-Management ist nicht im Fokus. Eine Vermischung würde den Scope aufblähen ohne Mehrwert für die priorisierten Ziele. auswirkung_auf: - dokument: "spm_practice_change-enablement.yaml" abschnitt: "einordnung.abgrenzung_produkt" vermerk: | Bei späterer Produkt-Konzeption: Change Enablement für Produkte/Infrastruktur ergänzen. status: "final" - id: "GOV-CE-003" datum: "2025-12-17" quelle_modul: "P-03 Change Enablement" frage: "Wie wird Cross-Service-Impact bei Normal Changes erkannt und behandelt?" entscheidung: | Service Owner ist verantwortlich für Erkennung von Cross-Service-Impact. SPM wird als "Zweite Augen" einbezogen bei Changes mit potenziellem Cross-Service-Impact. Schwellenwert: SO-Ermessen ("Im Zweifel SPM einbeziehen"). Keine formalen Schwellenwerte im MVP. begruendung: | Der SO kennt seinen Service und dessen Abhängigkeiten am besten. SPM bringt die Portfolio-Perspektive ein, ohne den SO zu entmündigen. Formale Schwellenwerte würden Gaming fördern und Bürokratie erzeugen. auswirkung_auf: - dokument: "spm_practice_change-enablement.yaml" abschnitt: "change_typen.normal_change.cross_service" status: "final" # =========================================================================== # INTERNE SERVICES – bestätigt März 2026 (PENDING-SPM-001) # =========================================================================== - id: "GOV-SPM-I-001" datum: "2026-03-09" quelle_modul: "SPM – Interne Services" frage: "Soll das Kategorienmodell um Interne Services erweitert werden?" entscheidung: | Das Kategorienmodell wird von drei auf vier Werte erweitert: - A: Basis-Services (Kundenservice, Katalog-sichtbar) - B: Erweiterte Services (Kundenservice, Katalog-sichtbar) - C: Spezial-Services (Kundenservice, Katalog-sichtbar) - I: Interne Services (kein Kundenservice, NICHT im Katalog) Interne Services sind vollwertige Governance-Objekte mit eigenem Service Owner, eigenem SLA-Typ (OLA), eigener Service-Definition und Teilnahme am Service-Lifecycle. begruendung: | Infrastruktur-Komponenten wie Active Directory oder der Netzwerk-Backbone sind für die Qualität von Kundenservices kritisch, werden aber bisher nicht systematisch gesteuert. Kategorie I ermöglicht Governance ohne Katalog-Überfrachtung. auswirkung_auf: - dokument: "spm_schema_service-definition.yaml" abschnitt: "identitaet.service_kategorie" - dokument: "service-portfolio-management_glossar.yaml" abschnitt: "Interner Service" - dokument: "spm_practice_service-catalog-management.yaml" abschnitt: "kategorien_logik" status: "final" bestaetigt_durch: "Steuerungsrunde (Michael)" pending_referenz: "PENDING-SPM-001, DC-001" # --------------------------------------------------------------------------- - id: "GOV-SPM-I-002" datum: "2026-03-09" quelle_modul: "SPM – Interne Services" frage: "Welcher SLA-Typ gilt für Interne Services?" entscheidung: | Für Interne Services (Kategorie I) gilt ein Operational Level Agreement (OLA) anstelle eines SLA. Das OLA-Feld bleibt während der Pilotphase leer (kein Placeholder-Wert). Die Begründung wird einmalig in der Pilot-Scope-Dokumentation festgehalten. begruendung: | ITIL4-konforme Terminologie. OLAs sind der etablierte Begriff für interne Leistungsvereinbarungen zwischen Betriebseinheiten. Trennung von SLA (extern) und OLA (intern) schafft konzeptionelle Klarheit ohne Mehraufwand. auswirkung_auf: - dokument: "spm_schema_service-definition.yaml" abschnitt: "qualitaet.service_level_referenz" - dokument: "spm_practice_service-level-management.yaml" abschnitt: "kernkonzepte.dokument_typen" - dokument: "service-portfolio-management_glossar.yaml" abschnitt: "OLA" status: "final" bestaetigt_durch: "Steuerungsrunde (Michael)" pending_referenz: "PENDING-SPM-001, DC-002" # --------------------------------------------------------------------------- - id: "GOV-SPM-I-003" datum: "2026-03-09" quelle_modul: "SPM – Interne Services" frage: "Soll service_sichtbarkeit als eigenständiges Attribut geführt werden?" entscheidung: | Das Attribut service_sichtbarkeit wird nicht eingeführt (bzw. ersatzlos gestrichen, falls vorhanden). Die Sichtbarkeit ist vollständig aus der service_kategorie ableitbar: - Kategorie A, B, C → im Katalog sichtbar - Kategorie I → NICHT im Katalog (per Definition) begruendung: | Designprinzip "Encode rationale once". Redundante Attribute erhöhen Pflegeaufwand und schaffen Widerspruchspotenzial. auswirkung_auf: - dokument: "spm_schema_service-definition.yaml" abschnitt: "identitaet (kein neues Attribut)" - dokument: "service-portfolio-management_glossar.yaml" abschnitt: "Service-Sichtbarkeit" status: "final" bestaetigt_durch: "Steuerungsrunde (Michael)" pending_referenz: "PENDING-SPM-001, DC-003" # --------------------------------------------------------------------------- - id: "GOV-SPM-I-004" datum: "2026-03-09" quelle_modul: "SPM – Interne Services" frage: "Soll ein eigenständiges Produkt-Konzept eingeführt werden?" entscheidung: | Das Konzept "Produkt" als eigenständige Kategorie oder Governance-Objekt wird nicht eingeführt. Infrastruktur-Komponenten werden entweder als Interne Services (Kategorie I) oder als passive Service-Komponenten behandelt. Die Abgrenzung erfolgt gemäß dem Sieben-Fragen-Leitfaden (GOV-SPM-I-005). begruendung: | Das Produkt-Konzept hätte eine dritte Governance-Ebene (neben Services und Komponenten) eingeführt ohne klaren Mehrwert gegenüber dem erweiterten Service-Modell. status: "final" bestaetigt_durch: "Steuerungsrunde (Michael)" pending_referenz: "PENDING-SPM-001, DC-004" # --------------------------------------------------------------------------- - id: "GOV-SPM-I-005" datum: "2026-03-09" quelle_modul: "SPM – Interne Services" frage: "Wie wird zwischen Internem Service und passiver Komponente abgegrenzt?" entscheidung: | Sieben-Fragen-Orientierungsleitfaden: 1. Gibt es einen identifizierbaren internen "Kunden"? 2. Gibt es eine verantwortliche Rolle für Service-Owner-Funktion? 3. Hat die Komponente eigene, unabhängig definierbare Qualitätsziele? 4. Kann die Komponente von mehreren Kundenservices genutzt werden? 5. Gibt es operative Steuerungsnotwendigkeit? 6. Ist die Komponente für Incident Management eigenständig relevant? 7. Würde eine Stilllegung eine eigene SOR-Entscheidung rechtfertigen? Auswertung: - 5+ Ja → Interner Service (Kategorie I) - 3-4 Ja → Grenzfall, Entscheidung durch SPM/SOR - 0-2 Ja → Passive Service-Komponente begruendung: | Ohne Leitfaden würde die Einordnung zu subjektiv und nicht reproduzierbar. Der Leitfaden ist Orientierung, kein Automatismus. status: "final" bestaetigt_durch: "Steuerungsrunde (Michael)" pending_referenz: "PENDING-SPM-001, DC-005" # --------------------------------------------------------------------------- - id: "GOV-SOR-006" datum: "2026-03-09" quelle_modul: "SPM – Interne Services / SOR-Governance" frage: "Wer hat Stimmrecht bei SOR-Entscheidungen zu Internen Services?" entscheidung: | Bei SOR-Entscheidungen, die Interne Services betreffen, haben Stimmrecht: 1. Der Service Owner des betroffenen Kundenservices (primär) 2. Die Service Owner aller Internen Services, die den Kundenservice maßgeblich beeinflussen Dies gilt für: Go-Live-Freigaben (Gate 2), Stilllegungsentscheidungen, SLA/OLA-Anpassungen mit Cross-Service-Impact. Verfahren: Consent-basiert (Konsent), analog zur bestehenden SOR-Geschäftsordnung. Operationalisierung: Die Aufnahme neuer Interner Services erfordert keinen formalen Antragsprozess. Ein regulärer Tagesordnungspunkt im SOR-Meeting ist ausreichend. begruendung: | Interne Services stehen nicht direkt im Kundenverhältnis, aber ihre Qualität bestimmt maßgeblich die Qualität der abhängigen Kundenservices. Ohne Stimmrecht wären betroffene Service Owner von relevanten Entscheidungen ausgeschlossen. Die Entscheidung für einen Tagesordnungspunkt (statt formalem Antragsprozess) vermeidet unnötige Bürokratie und nutzt die bestehende SOR-Meetingstruktur. auswirkung_auf: - dokument: "spm_sor_go.yaml" abschnitt: "Stimmrecht / Entscheidungsverfahren" status: "final" bestaetigt_durch: "Steuerungsrunde (Michael)" pending_referenz: "PENDING-SPM-001, DC-006"