digitom_cc/#02_service-portfolio-management/02.1_spm_konzepte/spm_governance-entscheidungen-log.yaml

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"