init: DIGITOM Kernkonzept YAML-Dateien (initialer Import)

#02_service-portfolio-management/02.1_spm_konzepte/04_rollen/rolle_service-owner.yaml

@@ -0,0 +1,952 @@
+# =============================================================================
+# ROLLENBESCHREIBUNG: SERVICE OWNER
+# =============================================================================
+# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/04_rollen/
+# Dateiname: rolle_service-owner.yaml
+# =============================================================================
+
+metadata:
+  id: "R-SO"
+  name: "Service Owner"
+  kurzform: "SO"
+  version: "1.0"
+  status: "entwurf"
+  erstellt: "2025-12-17"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+  dokumenttyp: "rollenbeschreibung"
+  
+  beschreibung: |
+    Vollständige Rollenbeschreibung für den Service Owner.
+    Konsolidiert Informationen aus Governance-Entscheidungen (GOV-TR-*, GOV-SR-*, 
+    GOV-007, GOV-008), Practice-Dokumenten (SLM, SCM, Change Enablement, SSM) 
+    und der Kurzreferenz in spm_rollen.yaml.
+  
+  referenzen:
+    kurzreferenz: "02_service-lifecycle-blueprint/spm_rollen.yaml -> service_owner"
+    support_kontext: "03_practices/spm_practice_service-support-management/ssm_rollen.yaml"
+    vorlage_struktur: "#03_stakeholder-management/#03.1_funktion/shm_rollen.yaml"
+    service_review: "02a_lifecycle-konzepte/spm_konzept_service-review.yaml"
+    service_transition: "02a_lifecycle-konzepte/spm_konzept_service-transition.yaml"
+    slm: "03_practices/spm_practice_service-level-management.yaml"
+    scm: "03_practices/spm_practice_service-catalog-management.yaml"
+    change_enablement: "03_practices/spm_practice_change-enablement.yaml"
+    governance_log: "spm_governance-entscheidungen-log.yaml"
+  
+  kontext_tags:
+    - "service-portfolio-management"
+    - "service-ownership"
+    - "lifecycle-management"
+    - "service-review"
+    - "change-authority"
+
+# =============================================================================
+# ROLLENZWECK
+# =============================================================================
+
+rollenzweck:
+  
+  kurz: |
+    Durchgängige Accountability für einen definierten Service über dessen 
+    gesamten Lifecycle – von der Übernahme in Transition bis zur Stilllegung.
+  
+  ausfuehrlich: |
+    Der Service Owner trägt die End-to-End-Verantwortung für seinen Service 
+    im Rahmen der definierten Governance-Strukturen. Diese Verantwortung 
+    bedeutet Lifecycle-Kontinuität, nicht Entscheidungsautonomie.
+    
+    Die Rolle umfasst:
+    - Fachliche Gesamtverantwortung für Service-Definition, -Qualität und -Entwicklung
+    - Accountability für Service-Performance und SLA-Einhaltung
+    - Change Authority für Normal Changes im eigenen Service-Scope
+    - Operative Accountability für Problem Management im Service-Kontext
+    - Vertretung des Service in Gremien (SOR, Kundenforum)
+    
+    Der Service Owner agiert als "Unternehmer für seinen Service" – 
+    allerdings eingebettet in die kollektive Governance-Architektur des DIGIT 
+    (SOR, Mission Board) und gebunden an Portfolio-Entscheidungen des SPM.
+  
+  itil4_referenz: |
+    "The owner of a service is accountable for the delivery of that service. 
+    Their accountability for the service extends from when the organization 
+    adds it to its portfolio until its eventual retirement."
+    (ITIL4 Direct, Plan and Improve, 7.3.1.4)
+  
+  verantwortung:
+    ab_wann: "Formale Übernahme bei Gate 1 (Entry Transition)"
+    fuer: "Service-Qualität, SLA-Einhaltung, Service-Weiterentwicklung"
+    bis: "Abschluss der Stilllegung (Retirement)"
+    governance_referenz: "GOV-TR-006"
+
+# =============================================================================
+# ORGANISATORISCHE EINORDNUNG
+# =============================================================================
+
+organisatorische_einordnung:
+  
+  zuordnung:
+    funktion: "Service-Portfolio-Management (SPM)"
+    hinweis: |
+      Die disziplinarische Zuordnung des SO ist kontextabhängig und 
+      nicht Gegenstand dieser Rollenbeschreibung. Der SO kann 
+      organisatorisch in verschiedenen Abteilungen angesiedelt sein.
+  
+  berichtslinie:
+    fachlich: "Service-Portfolio-Manager (SPM)"
+    disziplinarisch: "[Kontextabhängig – offener Punkt für MVP]"
+  
+  rollentyp:
+    typ: "Einzelrolle"
+    beschreibung: |
+      Jeder Service im Portfolio hat genau einen Service Owner.
+      Eine Person kann mehrere Services verantworten (Kapazitätsfrage).
+  
+  arbeitsmodell:
+    status: "Offener Punkt für MVP"
+    hinweis: |
+      Kapazitätsfragen (wie viele Services pro SO?) und Arbeitsmodell 
+      (Voll-/Teilzeit) sind nicht Teil des MVP und werden später geklärt.
+  
+  vertretung:
+    allgemein: |
+      Bei Abwesenheit ist für Vertretung zu sorgen. Kritische Entscheidungen 
+      (Gates, Eskalationen) können nicht ohne explizite Stellvertreter-Benennung 
+      delegiert werden.
+    transition_spezifisch: |
+      Gate-Entscheidungen können bei kurzfristiger SO-Abwesenheit verschoben 
+      werden. Bei Dringlichkeit: Eskalation an SOR.
+    governance_referenz: "GOV-TR-013"
+    annahme_markierung: "ANNAHME – Generelle Vertretungslogik abgeleitet aus GOV-TR-013"
+
+# =============================================================================
+# KERNAUFGABEN
+# =============================================================================
+
+kernaufgaben:
+
+  # ---------------------------------------------------------------------------
+  # SERVICE TRANSITION
+  # ---------------------------------------------------------------------------
+  service_transition:
+    
+    name: "Service Transition Management"
+    
+    beschreibung: |
+      Übernahme neuer oder wesentlich geänderter Services aus der 
+      Service-Entwicklung in den produktiven Betrieb.
+    
+    aktivitaeten:
+      
+      - aufgabe: "Gate 1 (Entry Transition) – SOR-Vorlage"
+        raci: "R"
+        beschreibung: "Vorbereitung und Einreichung der Gate-1-Vorlage bei SPM; Entscheidung liegt bei SOR"
+        governance_referenz: "GOV-TR-011"
+      
+      - aufgabe: "Accountability-Übernahme ab Gate 1"
+        beschreibung: |
+          Ab Gate 1 trägt SO die formale Accountability für den Service.
+          In der Phase bis Gate 2 besteht eine Überlappungszone mit der 
+          Projektleitung (gemeinsame Verantwortung).
+        governance_referenz: "GOV-TR-006"
+      
+      - aufgabe: "Service-Definition erstellen"
+        raci: "A/R"
+        beschreibung: "Erstellung der vollständigen Service-Definition nach Schema"
+        freigabe_durch: "SPM validiert, SOR gibt frei (bei Neuaufnahme)"
+        governance_referenz: "GOV-007"
+      
+      - aufgabe: "Gate 2 (Entry-Prüfung nach Build) – Entscheidung"
+        raci: "A (Einzelentscheidung)"
+        beschreibung: "SO prüft Übergabefähigkeit nach Build und entscheidet eigenständig über Freigabe/Zurückweisung"
+        governance_referenz: "GOV-TR-012"
+      
+      - aufgabe: "ELS-Management (Early Life Support)"
+        raci: "A"
+        beschreibung: |
+          Verantwortung für intensivierte Betreuung nach Go-Live.
+          Entscheidung über ELS-Exit als SO-Einzelentscheidung.
+        governance_referenz: "GOV-TR-021"
+      
+      - aufgabe: "Rollback-Entscheidung (ELS)"
+        raci: "A (Einzelentscheidung)"
+        beschreibung: |
+          Bei fundamentalen Problemen während ELS kann SO eigenständig 
+          Rollback entscheiden.
+        governance_referenz: "GOV-TR-029"
+    
+    referenz: "spm_konzept_service-transition.yaml"
+
+  # ---------------------------------------------------------------------------
+  # SERVICE REVIEW
+  # ---------------------------------------------------------------------------
+  service_review:
+    
+    name: "Quartalsweiser Service Review"
+    
+    beschreibung: |
+      Regelmäßige Selbstbewertung des Service anhand des 4-Dimensionen-Modells.
+      Ableitung von Handlungsempfehlungen und ggf. Einreichung bei SOR.
+    
+    aktivitaeten:
+      
+      - aufgabe: "Service-Review durchführen"
+        frequenz: "Quartalsweise"
+        raci: "A/R"
+        beschreibung: |
+          Bewertung des Service anhand der vier Dimensionen:
+          - SR-D1: Leistungserbringung (SLA-Erfüllung)
+          - SR-D2: Betriebsstabilität (Incidents, Verfügbarkeit)
+          - SR-D3: Nutzerzufriedenheit (Feedback, Beschwerden)
+          - SR-D4: Zukunftsfähigkeit (technisch, strategisch)
+        governance_referenz: "GOV-SR-001"
+      
+      - aufgabe: "Handlungsempfehlung ableiten"
+        raci: "A/R"
+        optionen:
+          - "CONTINUE – Service läuft wie geplant"
+          - "IMPROVEMENT – Verbesserungsmaßnahmen erforderlich"
+          - "REDESIGN – Grundlegende Überarbeitung nötig"
+          - "RETIRE – Stilllegung empfohlen"
+        governance_referenz: "GOV-SR-001"
+      
+      - aufgabe: "SPM informieren"
+        frequenz: "Nach jedem Review"
+        raci: "R"
+        beschreibung: "Informationspflicht an SPM über Review-Ergebnis"
+        governance_referenz: "GOV-SR-002"
+      
+      - aufgabe: "SOR-Vorlage einreichen (bei Bedarf)"
+        trigger:
+          - "Mindestens eine Dimension auf ROT"
+          - "IMPROVEMENT mit Ressourcenbedarf"
+          - "REDESIGN oder RETIRE"
+        raci: "R"
+        governance_referenz: "GOV-SR-003"
+      
+      - aufgabe: "Improvement-Maßnahmen definieren und tracken"
+        raci: "A/R"
+        beschreibung: "Dokumentation in der Service-Definition (Abschnitt 'laufende_verbesserungen')"
+        governance_referenz: "GOV-SR-005"
+      
+      - aufgabe: "Wirksamkeitsprüfung im Folge-Review"
+        raci: "A/R"
+        governance_referenz: "GOV-SR-005"
+    
+    referenz: "spm_konzept_service-review.yaml"
+
+  # ---------------------------------------------------------------------------
+  # SERVICE LEVEL MANAGEMENT
+  # ---------------------------------------------------------------------------
+  service_level_management:
+    
+    name: "Service Level Management"
+    
+    beschreibung: |
+      Verantwortung für Definition, Vereinbarung, Überwachung und 
+      Review der Service Levels.
+    
+    aktivitaeten:
+      
+      - aufgabe: "Service-Level-Anforderungen erheben"
+        phase: "Transition"
+        raci: "A"
+        beschreibung: "Verantwortet die Anforderungserhebung aus Kundensicht"
+        aktivitaets_id: "slm_01"
+      
+      - aufgabe: "Service Level Specification (SLS) erstellen"
+        phase: "Transition"
+        raci: "A"
+        beschreibung: "Verantwortet SLS-Inhalt (Übersetzung in messbare Levels)"
+        aktivitaets_id: "slm_02"
+      
+      - aufgabe: "SLA abstimmen und fixieren"
+        phase: "Transition"
+        raci: "R"
+        beschreibung: "Führt Abstimmung mit SLA-Partner, moderiert Usergroup"
+        aktivitaets_id: "slm_03"
+      
+      - aufgabe: "SLA-Freigabe vorbereiten"
+        phase: "Transition"
+        raci: "R"
+        beschreibung: "Bereitet SOR-/MB-Freigabe vor"
+        aktivitaets_id: "slm_04"
+      
+      - aufgabe: "Service Levels überwachen"
+        phase: "Betrieb"
+        raci: "A"
+        beschreibung: "Verantwortet Interpretation der Messergebnisse"
+        aktivitaets_id: "slm_05"
+      
+      - aufgabe: "SLA-Performance reporten"
+        phase: "Betrieb"
+        raci: "A"
+        frequenz: "Monatlich (intern), Quartalsweise (extern)"
+        beschreibung: "Verantwortet Bericht und Interpretation"
+        aktivitaets_id: "slm_06"
+      
+      - aufgabe: "SLA-Verletzung eskalieren"
+        phase: "Betrieb"
+        raci: "R"
+        beschreibung: "Identifiziert, analysiert, eskaliert (Stufe 1 im Eskalationspfad)"
+        aktivitaets_id: "slm_07"
+      
+      - aufgabe: "Internen SLA-Review durchführen"
+        phase: "Review"
+        raci: "A"
+        frequenz: "Jährlich"
+        aktivitaets_id: "slm_08"
+      
+      - aufgabe: "Externen SLA-Review mit Kunden durchführen"
+        phase: "Review"
+        raci: "R"
+        frequenz: "Jährlich"
+        beschreibung: "Führt Review durch, moderiert Kundenforum gemeinsam mit SHM"
+        aktivitaets_id: "slm_09"
+        governance_referenz: "GOV-012"
+    
+    referenz: "spm_practice_service-level-management.yaml"
+
+  # ---------------------------------------------------------------------------
+  # SERVICE CATALOG MANAGEMENT
+  # ---------------------------------------------------------------------------
+  service_catalog_management:
+    
+    name: "Service Catalog Management"
+    
+    beschreibung: |
+      Verantwortung für die inhaltliche Pflege der Service-Definition 
+      und des Service-Steckbriefs im Katalog.
+    
+    aktivitaeten:
+      
+      - aufgabe: "Service-Definition erstellen"
+        raci: "A/R"
+        beschreibung: "Inhaltliche Erstellung nach Schema"
+        governance_referenz: "GOV-007"
+      
+      - aufgabe: "Service-Definition zur Validierung einreichen"
+        raci: "R"
+        freigabe_durch: "SPM"
+        aktivitaets_id: "scm_01"
+      
+      - aufgabe: "Service-Steckbrief erstellen"
+        raci: "R"
+        beschreibung: "Ableitung des kundenorientierten Auszugs"
+        aktivitaets_id: "scm_02"
+      
+      - aufgabe: "Katalogänderungen initiieren"
+        raci: "R"
+        beschreibung: "Meldet Änderungsbedarf, beschreibt Änderung"
+        aktivitaets_id: "scm_05"
+      
+      - aufgabe: "Redaktionelle Katalogänderungen (autonom)"
+        raci: "A/R"
+        beispiele: ["Tippfehler", "Telefonnummer", "Formatierung"]
+        governance_referenz: "GOV-008"
+      
+      - aufgabe: "Service-Stilllegung koordinieren"
+        raci: "R"
+        beschreibung: "Koordiniert Kommunikation bei Stilllegung"
+        aktivitaets_id: "scm_06"
+      
+      - aufgabe: "Jährlicher Katalog-Review (Zulieferung)"
+        raci: "C"
+        beschreibung: "Liefert Informationen zu eigenen Services"
+        aktivitaets_id: "scm_07"
+    
+    referenz: "spm_practice_service-catalog-management.yaml"
+
+  # ---------------------------------------------------------------------------
+  # CHANGE ENABLEMENT
+  # ---------------------------------------------------------------------------
+  change_enablement:
+    
+    name: "Change Enablement"
+    
+    beschreibung: |
+      Change Authority für Normal Changes im eigenen Service-Scope.
+      Klassifizierung und Bewertung von Change Requests.
+    
+    aktivitaeten:
+      
+      - aufgabe: "Change Requests klassifizieren"
+        raci: "A/R"
+        beschreibung: "Prüfung: Standard? Normal? Major?"
+      
+      - aufgabe: "Normal Changes bewerten und entscheiden"
+        raci: "A (Change Authority)"
+        beschreibung: "Risiko-, Aufwand- und Auswirkungsbewertung; Freigabe/Ablehnung"
+      
+      - aufgabe: "Cross-Service-Impact erkennen"
+        raci: "R"
+        beschreibung: |
+          SO ist verantwortlich für Erkennung von Cross-Service-Auswirkungen.
+          Bei Cross-Service-Impact: SPM als "zweite Augen" einbeziehen.
+        governance_referenz: "GOV-CE-003"
+      
+      - aufgabe: "Standard Change-Modelle dokumentieren"
+        raci: "A/R"
+        beschreibung: |
+          Dokumentation wiederkehrender, risikoarmer Changes für den 
+          eigenen Service. SPM erhält Kopie zur Kenntnis.
+      
+      - aufgabe: "Change-Abschluss bestätigen"
+        raci: "A/R"
+        beschreibung: "Bestätigung der erfolgreichen Umsetzung"
+    
+    referenz: "spm_practice_change-enablement.yaml"
+
+  # ---------------------------------------------------------------------------
+  # PROBLEM MANAGEMENT
+  # ---------------------------------------------------------------------------
+  problem_management:
+    
+    name: "Problem Management (Service-Kontext)"
+    
+    beschreibung: |
+      Operative Accountability für Problem Management im eigenen Service-Scope.
+      Der SO ist NICHT Practice Owner (liegt beim SPM), sondern trägt die 
+      Verantwortung für die Durchführung im Service-Kontext.
+    
+    designentscheidung: "D-01"
+    
+    aktivitaeten:
+      
+      - aufgabe: "Problem-Analyse verantworten"
+        raci: "A"
+        beschreibung: "Accountable für Root-Cause-Analyse, kann an L2 delegieren"
+        aktivitaets_id: "PRB-02"
+      
+      - aufgabe: "Lösungsinitiierung entscheiden"
+        raci: "A/R"
+        beschreibung: |
+          Entscheidung: Permanente Lösung via Change oder alternative Maßnahme?
+          Kosten-Nutzen-Abwägung.
+        aktivitaets_id: "PRB-03"
+      
+      - aufgabe: "Change Request aus Problem erstellen"
+        raci: "A/R"
+        beschreibung: "Bei Bedarf: Change Request mit Problem-Verweis erstellen"
+        schnittstelle: "Change Enablement (P-03)"
+      
+      - aufgabe: "Problem schließen"
+        raci: "A/R"
+        beschreibung: "Abschluss nach Lösung oder bewusster Akzeptanz"
+        aktivitaets_id: "PRB-04"
+      
+      - aufgabe: "Known Error dokumentieren"
+        raci: "A"
+        beschreibung: "Verantwortet Known-Error-Dokumentation"
+      
+      - aufgabe: "Muster erkennen (Incident-Cluster)"
+        raci: "A"
+        beschreibung: "Verantwortet systematische Mustererkennung"
+    
+    referenz: "sub-practice_problem-management.yaml"
+    governance_referenz: "SSM-G-18"
+
+  # ---------------------------------------------------------------------------
+  # INCIDENT MANAGEMENT (ESKALATIONSROLLE)
+  # ---------------------------------------------------------------------------
+  incident_management:
+    
+    name: "Incident Management (Eskalationsrolle)"
+    
+    beschreibung: |
+      Fachliche Eskalationsinstanz bei Major Incidents und komplexen 
+      Störungen im eigenen Service-Bereich.
+    
+    aktivitaeten:
+      
+      - aufgabe: "Fachliche Eskalation annehmen"
+        raci: "A"
+        trigger: "Major Incident oder L2-Eskalation"
+        beschreibung: "Fachliche Klärung und Priorisierungsentscheidung"
+      
+      - aufgabe: "Hierarchische Eskalation initiieren"
+        raci: "R"
+        beschreibung: "Bei Bedarf Eskalation an SOR"
+    
+    referenz: "sub-practice_incident-management.yaml"
+
+  # ---------------------------------------------------------------------------
+  # WISSENSMANAGEMENT
+  # ---------------------------------------------------------------------------
+  wissensmanagement:
+    
+    name: "Wissensmanagement (Service-Kontext)"
+    
+    beschreibung: |
+      Verantwortung für service-spezifische Wissensdokumentation.
+    
+    aktivitaeten:
+      
+      - aufgabe: "KB Ebene 1 verantworten"
+        raci: "A"
+        beschreibung: "Grundlagendokumentation zum Service"
+      
+      - aufgabe: "KB Ebene 2 co-erstellen"
+        raci: "C"
+        beschreibung: "Arbeitsdokumentation gemeinsam mit Support-Team"
+    
+    referenz: "ssm_rollen.yaml"
+    governance_referenz: "SSM-G-09"
+
+# =============================================================================
+# BEFUGNISSE
+# =============================================================================
+
+befugnisse:
+
+  eigenstaendig:
+    
+    - befugnis: "Gate 2 (Entry-Prüfung nach Build) – Freigabe"
+      scope: "Eigener Service"
+      beschreibung: "Operative Einzelentscheidung über Übergabefähigkeit nach Build"
+      governance_referenz: "GOV-TR-012"
+    
+    - befugnis: "ELS-Exit-Entscheidung"
+      scope: "Eigener Service"
+      beschreibung: "Beendigung des Early Life Support"
+      mit_informationspflicht: "SPM"
+      governance_referenz: "GOV-TR-021"
+    
+    - befugnis: "Rollback während ELS"
+      scope: "Eigener Service"
+      beschreibung: "Bei fundamentalen Problemen"
+      governance_referenz: "GOV-TR-029"
+    
+    - befugnis: "Normal Changes genehmigen"
+      scope: "Eigener Service"
+      beschreibung: "Change Authority für Normal Changes"
+      governance_referenz: "GOV-CE-001"
+    
+    - befugnis: "Redaktionelle Katalogänderungen"
+      scope: "Eigener Service"
+      beispiele: ["Tippfehler", "Kontaktdaten"]
+      governance_referenz: "GOV-008"
+    
+    - befugnis: "Problem-Schließung"
+      scope: "Eigener Service"
+      beschreibung: "Abschluss von Problem Records"
+    
+    - befugnis: "Service-Review durchführen und bewerten"
+      scope: "Eigener Service"
+      frequenz: "Quartalsweise"
+      governance_referenz: "GOV-SR-001"
+
+  in_abstimmung:
+    
+    - befugnis: "Minor Katalogänderungen"
+      abstimmung_mit: "SPM (bilateral)"
+      governance_referenz: "GOV-008"
+    
+    - befugnis: "Cross-Service-Changes"
+      abstimmung_mit: "SPM als 'zweite Augen'"
+      governance_referenz: "GOV-CE-003"
+    
+    - befugnis: "SLS/SLA-Inhalte"
+      abstimmung_mit: "Betriebsteam (technische Messbarkeit), SPM (Portfolio-Konsistenz)"
+
+  ueber_gremien:
+    
+    - befugnis: "Gate 1 (Entry Transition) – Go/No-Go"
+      gremium: "SOR"
+      so_rolle: "Antragsteller, Vorlage-Einreichung"
+      governance_referenz: "GOV-TR-011"
+    
+    - befugnis: "Gate 3 (Go-Live-Freigabe)"
+      gremium: "SOR"
+      so_rolle: "Antragsteller, Nachweisführung"
+      governance_referenz: "GOV-TR-016"
+    
+    - befugnis: "Major Katalogänderungen / Neuaufnahme"
+      gremium: "SOR"
+      governance_referenz: "GOV-008"
+    
+    - befugnis: "SLA-Freigabe (Standard)"
+      gremium: "SOR"
+    
+    - befugnis: "SLA-Freigabe (Abweichungen/Major)"
+      gremium: "Mission Board"
+      governance_referenz: "GOV-001"
+    
+    - befugnis: "Strukturelle Katalogänderungen"
+      gremium: "Mission Board"
+      beispiele: ["Kategorie-Wechsel", "Stilllegung"]
+      governance_referenz: "GOV-008"
+
+# =============================================================================
+# EINSCHRÄNKUNGEN / NICHT-AUFGABEN
+# =============================================================================
+
+einschraenkungen:
+
+  nicht_aufgabe:
+    
+    - was: "Portfolio-Entscheidungen"
+      zustaendig: "SPM / SOR / Mission Board"
+      klarstellung: |
+        SO bringt Service-Perspektive ein, entscheidet aber nicht über 
+        Portfolio-Zusammensetzung, Service-Priorisierung oder Ressourcenallokation 
+        auf Portfolio-Ebene.
+    
+    - was: "Major Changes / Transition-pflichtige Änderungen"
+      zustaendig: "SOR (via Transition-Gates)"
+      klarstellung: |
+        Wenn eine Änderung die Service-Identität berührt oder Transition-Gates 
+        erfordert, liegt die Entscheidung bei SOR, nicht beim SO.
+      governance_referenz: "GOV-CE-004"
+    
+    - was: "Practice-Weiterentwicklung (methodisch)"
+      zustaendig: "SPM (als Practice Owner)"
+      klarstellung: |
+        SO führt Practices für seinen Service aus, entwickelt aber nicht 
+        die Methodik weiter. Practice Ownership liegt beim SPM.
+      designentscheidung: "D-01"
+    
+    - was: "L1/L2-Support-Aktivitäten"
+      zustaendig: "Service Desk, Support Manager, Support-Agenten"
+      klarstellung: |
+        SO ist Eskalationsinstanz, nicht operativer Support-Bearbeiter.
+    
+    - was: "Betriebsführung / technische Operations"
+      zustaendig: "Operations Manager, Betriebsteam"
+      klarstellung: |
+        SO verantwortet Service fachlich (Was wird geliefert?), 
+        nicht technisch-operativ (Wie wird es betrieben?).
+      hinweis: "Abgrenzung zu Operations Manager in separatem Dokument zu klären"
+    
+    - was: "SLA-Verhandlung (finale Entscheidung)"
+      zustaendig: "SOR / Mission Board"
+      klarstellung: |
+        SO moderiert SLA-Abstimmung mit Kunden, aber finale SLA-Freigabe 
+        erfolgt durch SOR (Standard) oder MB (Abweichungen).
+    
+    - was: "Budget-Entscheidungen über definierte Schwellwerte"
+      zustaendig: "[Zu klären – offener Punkt]"
+      status: "Offener Punkt für MVP"
+
+# =============================================================================
+# SCHNITTSTELLEN
+# =============================================================================
+
+schnittstellen:
+
+  intern:
+    
+    - partner: "Service-Portfolio-Manager (SPM)"
+      interaktion:
+        - "Fachliche Berichtslinie"
+        - "Service-Review-Ergebnisse kommunizieren"
+        - "Service-Definition zur Validierung einreichen"
+        - "Rücksprache bei Klassifizierungsfragen (Change/Demand)"
+        - "SPM als 'zweite Augen' bei Cross-Service-Changes"
+      frequenz: "Regelmäßig + bei Bedarf"
+    
+    - partner: "Support Manager"
+      interaktion:
+        - "Eskalationsempfang (fachlich)"
+        - "Abstimmung bei Problem Management"
+        - "Koordination L2-Aktivitäten"
+      frequenz: "Bei Bedarf"
+      referenz: "ssm_governance.yaml"
+    
+    - partner: "Operations Manager"
+      interaktion:
+        - "Abstimmung Service-Betrieb"
+        - "Monitoring-Anforderungen"
+        - "Kapazitäts- und Performance-Themen"
+      frequenz: "Bei Bedarf"
+      hinweis: "Detaillierte Abgrenzung in separatem Dokument zu klären"
+    
+    - partner: "Betriebsteam"
+      interaktion:
+        - "Koordination Betriebsaktivitäten"
+        - "Abstimmung bei SLS-Erstellung (technische Messbarkeit)"
+        - "Monitoring-Daten und Reports"
+      frequenz: "Laufend"
+      fuehrungsverhaeltnis: "[Offener Punkt – disziplinarische Einordnung ungeklärt]"
+    
+    - partner: "Projektleitung (in Transition)"
+      interaktion:
+        - "Überlappungszone Gate 1 bis Gate 2"
+        - "Übergabe der Service-Verantwortung"
+      frequenz: "Während Transition-Phase"
+      governance_referenz: "GOV-TR-006"
+
+  extern:
+    
+    - partner: "Stakeholder-Manager (SHM)"
+      interaktion:
+        - "Gemeinsame Moderation Kundenforum"
+        - "Abstimmung bei Kundenfeedback"
+        - "Unterstützung bei Kundeninteraktion (SLA-Review)"
+      frequenz: "Bei Bedarf, Kundenforum jährlich"
+      governance_referenz: "GOV-012"
+
+    - partner: "DIGIT-Mitarbeiter (interner Bedarf)"
+      interaktion:
+        - "Empfang interner Bedarfe für eigenen Service"
+        - "Change-Qualifizierung: Ist es ein Change oder Demand?"
+        - "Bei Change-Charakter: Bewertung und Umsetzung"
+        - "Bei Demand-Charakter: Rückverweis an SHM/DPM"
+      frequenz: "Bei Bedarf"
+      hinweis: |
+        Service Owner ist Ansprechpartner für interne Bedarfe, die einen
+        bestehenden Service betreffen. SO entscheidet, ob es ein Change
+        (SO-Verantwortung) oder Demand (DPM-Verantwortung) ist.
+
+        Der Eingang erfolgt über SHM Fast Track Routing (siehe
+        shm_bedarfsbewertung.yaml#schritt_0a_fast_track_intern).
+      referenz: "shm_bedarfsbewertung.yaml#schritt_0a_fast_track_intern"
+    
+    - partner: "DPM (Demand-Portfolio-Management)"
+      interaktion:
+        - "Konsultation in Service-Entwicklung (vor Gate 1)"
+        - "Rückfragen zu Demand-Spezifikationen"
+      frequenz: "Bei Bedarf"
+      hinweis: "Formale Accountability beginnt bei Gate 1, Einbindung vorher empfohlen"
+    
+    - partner: "Kunden / SLA-Partner"
+      interaktion:
+        - "SLA-Abstimmung (Moderation)"
+        - "Jährlicher externer SLA-Review"
+        - "Service-bezogene Kommunikation"
+      frequenz: "Jährlich (Review) + bei Bedarf"
+
+# =============================================================================
+# GREMIENROLLEN
+# =============================================================================
+
+gremienrollen:
+
+  - gremium: "SOR (Service Operations Runde)"
+    rolle: "Stimmberechtigtes Mitglied"
+    funktion: |
+      Vertretung des eigenen Service bei portfolio-relevanten Entscheidungen.
+      Stimmrecht bei Themen des eigenen Service.
+    befugnisse:
+      - "Stimmrecht bei Service-bezogenen Entscheidungen"
+      - "Einreichung von Vorlagen (Gate 2, Review-Eskalationen, Major Changes)"
+      - "Teilnahme an Portfolio-Diskussionen"
+    anwesenheit: "Bei Themen des eigenen Service (Details siehe G-SOR Geschäftsordnung)"
+    referenz: "G-SOR Geschäftsordnung (placeholder)"
+    hinweis: |
+      Portfolio-übergreifende Entscheidungen und Anwesenheitsregelung 
+      werden in der SOR-Geschäftsordnung definiert.
+
+  - gremium: "Mission Board"
+    rolle: "Bei Bedarf (Eskalation)"
+    funktion: "Eskalationsinstanz bei SOR-Dissens oder MB-pflichtigen Entscheidungen"
+    beispiele:
+      - "SLA-Abweichungen von Standard"
+      - "Strukturelle Katalogänderungen"
+      - "Ressourcenkonflikte"
+
+  - gremium: "Kundenforum"
+    rolle: "Moderator (gemeinsam mit SHM)"
+    funktion: |
+      Moderation des integrierten Kundenforums für Service-bezogene Themen.
+      SLM-Review + SHM-Beziehungspflege.
+    frequenz: "Jährlich"
+    governance_referenz: "GOV-012"
+
+# =============================================================================
+# ANFORDERUNGSPROFIL
+# =============================================================================
+
+anforderungsprofil:
+
+  fachlich:
+    - "Tiefes Verständnis des verantworteten Service (funktional und technisch)"
+    - "Kenntnisse des Service-Katalogs und der Service-Landschaft im DIGIT"
+    - "Grundverständnis ITIL4 Service Management Practices"
+    - "Verständnis des DIGITOM (SPM, DPM, SHM-Zusammenspiel)"
+    - "Kenntnisse der relevanten SLAs und Service Levels"
+
+  methodisch:
+    - "Service-Review und -Bewertung"
+    - "Risiko- und Impact-Bewertung (Change Enablement)"
+    - "Root-Cause-Analyse (Problem Management)"
+    - "Stakeholder-Kommunikation und Moderation"
+    - "Dokumentation und strukturierte Erfassung"
+
+  persoenlich:
+    - "Ownership-Mentalität und Ergebnisorientierung"
+    - "Entscheidungsfähigkeit unter Unsicherheit"
+    - "Kommunikationsstärke (intern und extern)"
+    - "Fähigkeit zur Priorisierung und zum Trade-off-Management"
+    - "Kooperationsfähigkeit in Gremienstrukturen"
+    - "Verbindlichkeit und Zuverlässigkeit"
+
+# =============================================================================
+# OFFENE PUNKTE (FÜR MVP NICHT ADRESSIERT)
+# =============================================================================
+
+offene_punkte:
+
+  - id: "OPEN-SO-001"
+    thema: "Budget-Verantwortung für laufenden Betrieb"
+    beschreibung: |
+      Welche Budget-Befugnisse hat der SO für den laufenden Service-Betrieb?
+      Gibt es Schwellwerte, ab denen Abstimmung/Eskalation erforderlich ist?
+    prioritaet: "mittel"
+    status: "Für MVP nicht adressiert"
+
+  - id: "OPEN-SO-002"
+    thema: "Disziplinarische Einordnung"
+    beschreibung: |
+      Wo ist der SO organisatorisch angesiedelt? Welche disziplinarische 
+      Berichtslinie gilt?
+    prioritaet: "mittel"
+    status: "Für MVP nicht adressiert"
+    hinweis: "Kontextabhängig je nach Service und Organisation"
+
+  - id: "OPEN-SO-003"
+    thema: "Arbeitsmodell / Kapazität"
+    beschreibung: |
+      Wie viele Services kann/soll ein SO verantworten? 
+      Ist SO Voll- oder Teilzeitrolle?
+    prioritaet: "mittel"
+    status: "Für MVP nicht adressiert"
+
+  - id: "OPEN-SO-004"
+    thema: "Abgrenzung zu Operations Manager"
+    beschreibung: |
+      Detaillierte Domänenabgrenzung zwischen SO (fachlich) und 
+      Operations Manager (technisch-operativ).
+    prioritaet: "hoch"
+    status: "Grundlogik klar, Details in separatem Dokument zu klären"
+    abhaengig_von: "Rolle Operations Manager"
+
+  - id: "OPEN-SO-005"
+    thema: "Führungsverantwortung Betriebsteam"
+    beschreibung: |
+      Hat der SO fachliche und/oder disziplinarische Führungsverantwortung 
+      für das Betriebsteam?
+    prioritaet: "mittel"
+    status: "Für MVP nicht adressiert"
+    zusammenhang: "OPEN-SO-002"
+
+# =============================================================================
+# DESIGNENTSCHEIDUNGEN (DOKUMENTIERT)
+# =============================================================================
+
+designentscheidungen:
+
+  - id: "D-01"
+    datum: "2025-12-17"
+    frage: "Ist SO Practice Owner für Problem Management?"
+    entscheidung: |
+      Nein. SO ist operativ accountable für Problem Management im eigenen 
+      Service-Scope, aber NICHT Practice Owner.
+      Practice Ownership für alle Practices liegt beim SPM.
+    begruendung: |
+      Konsistent mit Taxonomie-Logik: SPM verantwortet Practices methodisch, 
+      SO führt sie für seinen Service aus. Vermeidet Rolleninflation.
+    auswirkung_auf:
+      - dokument: "rolle_service-owner.yaml"
+        abschnitt: "kernaufgaben.problem_management"
+      - dokument: "rolle_service-portfolio-manager.yaml"
+        abschnitt: "practice_ownership"
+
+  - id: "D-02"
+    datum: "2025-12-17"
+    frage: "Wie wird 'End-to-End-Verantwortung' präzisiert?"
+    entscheidung: |
+      "Durchgängige Accountability über den Service-Lifecycle, im Rahmen 
+      der definierten Governance-Strukturen."
+    begruendung: |
+      Klarstellung, dass E2E Lifecycle-Kontinuität meint, nicht 
+      Entscheidungsautonomie. SO ist an Gates, Eskalationen und 
+      Portfolio-Governance gebunden.
+    auswirkung_auf:
+      - dokument: "rolle_service-owner.yaml"
+        abschnitt: "rollenzweck"
+
+  - id: "D-03"
+    datum: "2025-12-17"
+    frage: "Wie wird die generelle Vertretungsregelung formuliert?"
+    entscheidung: |
+      "Bei Abwesenheit ist für Vertretung zu sorgen. Kritische Entscheidungen 
+      (Gates, Eskalationen) können nicht ohne explizite Stellvertreter-Benennung 
+      delegiert werden."
+    begruendung: |
+      Pragmatische Lösung für MVP. Ableitung aus GOV-TR-013 (Transition-
+      spezifische Vertretung) auf allgemeine Ebene. Als Annahme markiert.
+    status: "ANNAHME"
+    auswirkung_auf:
+      - dokument: "rolle_service-owner.yaml"
+        abschnitt: "organisatorische_einordnung.vertretung"
+
+# =============================================================================
+# GOVERNANCE-REFERENZEN (KONSOLIDIERT)
+# =============================================================================
+
+governance_referenzen:
+
+  transition:
+    - "GOV-TR-011: Gate 1 als SOR-Entscheidung (Entry-Autorisierung)"
+    - "GOV-TR-012: Gate 2 als SO-Einzelentscheidung (Entry-Prüfung nach Build)"
+    - "GOV-TR-016: Gate 3 als SOR-Entscheidung (Go-Live-Freigabe)"
+    - "GOV-TR-004: SO-Benennung spätestens bei Gate 1"
+    - "GOV-TR-006: Accountability-Übernahme ab Gate 1"
+    - "GOV-TR-013: Vertretungsregelung (Transition)"
+    - "GOV-TR-021: ELS-Exit als SO-Einzelentscheidung"
+    - "GOV-TR-029: Rollback-Kompetenz während ELS"
+
+  review:
+    - "GOV-SR-001: Quartalsweiser Selbst-Review"
+    - "GOV-SR-002: SPM-Informationspflicht"
+    - "GOV-SR-003: SOR-Einbeziehung bei Auffälligkeiten"
+    - "GOV-SR-005: Improvement-Tracking in der Service-Definition"
+
+  catalog_und_level:
+    - "GOV-001: SLA-Freigabe-Governance"
+    - "GOV-007: SO erstellt Service-Definition"
+    - "GOV-008: Dreistufige Katalog-Änderungs-Governance"
+    - "GOV-012: Integriertes Kundenforum (SO + SHM)"
+
+  change_enablement:
+    - "GOV-CE-001: SO als Change Authority für Normal Changes"
+    - "GOV-CE-003: Cross-Service-Impact-Erkennung"
+    - "GOV-CE-004: Abgrenzung Change vs. Demand"
+
+  support:
+    - "SSM-G-18: SO als Process Owner für Problem Management"
+    - "SSM-G-09: KB-Verantwortung"
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+
+  - version: "0.1"
+    datum: "2025-12-15"
+    autor: "DIGITOM-Projekt"
+    aenderung: "Placeholder erstellt mit Gliederungsskelett"
+
+  - version: "1.0"
+    datum: "2025-12-17"
+    autor: "DIGITOM-Projekt"
+    aenderung: |
+      Vollständige Rollenbeschreibung erstellt:
+      - Konsolidierung aus Governance-Entscheidungen (GOV-TR-*, GOV-SR-*, etc.)
+      - Integration der Practice-Verantwortlichkeiten (SLM, SCM, CE, SSM)
+      - Dokumentation der Designentscheidungen D-01 bis D-03
+      - Definition der offenen Punkte für MVP
+      - Strukturierung analog SHM-Rollenbeschreibungen
+
+  - version: "1.1"
+    datum: "2026-01-22"
+    autor: "DIGITOM-Projekt"
+    aenderung: |
+      Erweiterung um interne Bedarfe:
+      - Neue Schnittstelle: "DIGIT-Mitarbeiter (interner Bedarf)"
+      - Beschreibung: Empfang interner Bedarfe für eigenen Service
+      - Change-Qualifizierung: SO entscheidet Change vs. Demand
+      - Verweis auf SHM Fast Track Routing
+      - Rückverweis an SHM/DPM bei Demand-Charakter
+    quelle: "Lösung für Ticket: Interne Bedarfe Routing-Unschärfe"