init: DIGITOM Kernkonzept YAML-Dateien (initialer Import)

#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_design.yaml

@@ -0,0 +1,184 @@
+metadata:
+  name: "Design"
+  yasm_referenz: "LP2: Design new or changed services"
+  version: "3.0"
+  status: "draft"
+  erstellt: "2026-01-22"
+  aktualisiert: "2026-02-18"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+  beschreibung: >
+    Strategische und architektonische Gestaltung neuer oder wesentlich
+    geänderter Services. Umfasst Service-Definition, Architektur-Design
+    und Implementation Blueprint.
+
+    Diese Phase entspricht YASM LP2 (Design new or changed services) und
+    fokussiert auf die Planung und das Design, NICHT auf die Implementierung.
+
+  aenderungen:
+    - version: "3.0"
+      datum: "2026-02-18"
+      beschreibung: >
+        Gate 1 aus Design-Phase entfernt und an den Anfang der Transition-Phase
+        verschoben (neue ID: tr_01). Design-Phase endet nun mit ds_04. Gate 1
+        ist das Entry-Gate der Transition, nicht mehr das Exit-Gate von Design.
+
+    - version: "2.1"
+      datum: "2026-01-30"
+      beschreibung: >
+        Gate 1 (ds_05): Neue Prüfdimension "Betriebs- und Support-Bereitschaft"
+        (g1_dim_04) hinzugefügt. Grundsätzliches Ressourcen-Commitment muss VOR
+        Beginn der Transition geprüft werden, um Ressourcenverschwendung zu
+        vermeiden. Alle Prüfdimensionen nun explizit dokumentiert.
+
+    - version: "2.0"
+      datum: "2026-01-30"
+      beschreibung: >
+        Konsolidierung auf 5-Phasen-Modell: Aktivitäts-IDs von sd_ auf ds_
+        umgestellt. Gate sd_05 wird zu ds_05 (Gate 1). Englische Phasennamen.
+
+    - version: "1.0"
+      datum: "2026-01-22"
+      beschreibung: "Initiale Erstellung nach YASM LP2"
+
+  schnittstellen:
+    eingang:
+      - quelle: "Demand Lifecycle Phase 4"
+        artefakt: "Freigegebener Demand / Projektauftrag (nach DSR/MB Freigabe)"
+        beschreibung: "PPM hat Projektleitung benannt und Ressourcen mobilisiert"
+    ausgang:
+      - ziel: "Transition"
+        artefakt: "Service Design Document + Implementation Blueprint"
+        beschreibung: "Vollständiges Design als Input für Gate 1 (tr_01) in der Transition-Phase"
+
+  hinweis: >
+    Diese Phase trennt bewusst Design (WAS und WIE) von Build (Implementierung).
+    Nach YASM LP2 werden hier alle strategischen und architektonischen
+    Entscheidungen getroffen. Die Build/Configure-Entscheidung (Gate 1) erfolgt
+    als erste Aktivität der Transition-Phase (tr_01).
+
+# =============================================================================
+# AKTIVITÄTEN
+# =============================================================================
+
+aktivitaeten:
+
+  # ---------------------------------------------------------------------------
+  - id: ds_01
+    name: "Definieren der erforderlichen Service-Eigenschaften"
+    typ: aktivitaet
+    yasm_referenz: "LP2: Service Definition (Utility & Warranty)"
+    ehemals: "sd_01"
+
+    beschreibung: >
+      Grundlegende Definition des neuen oder geänderten Services aus
+      fachlicher Perspektive.
+
+    umfasst:
+      - "Definition von Zweck, Nutzen, Zielgruppen"
+      - "Definition der Utility & Warranty des Services"
+      - "Ableitung der SLA-/SLO-Anforderungen"
+      - "Ermittlung unterstützender Services und Abhängigkeiten"
+      - "Identifikation fachlicher und technischer Anforderungen"
+
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+      - rolle: projektleitung
+        raci: R
+      - rolle: betriebsteam
+        raci: C
+      - rolle: architektur
+        raci: C
+      - rolle: spm
+        raci: C
+
+  # ---------------------------------------------------------------------------
+  - id: ds_02
+    name: "Designen der erforderlichen Service- und Service-Management-Komponenten"
+    typ: aktivitaet
+    yasm_referenz: "LP2: Service Architecture Design"
+    ehemals: "sd_02"
+
+    beschreibung: >
+      Einarbeiten der Service-Eigenschaften in ein vollständiges Designmodell.
+
+    umfasst:
+      - "Servicearchitektur (Komponenten, Schnittstellen, Abhängigkeiten)"
+      - "Design der Betriebs- und Supportprozesse"
+      - "Sicherheits-, Compliance- und Datenschutzanforderungen"
+      - "Monitoring & Reporting-Anforderungen"
+      - "Tool-/Konfigurationsanforderungen"
+      - "Rollenmodell (Support, Betrieb, Governance)"
+
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+      - rolle: architektur
+        raci: R
+      - rolle: projektteam
+        raci: R
+      - rolle: spm
+        raci: I
+
+    hinweis: "Security / Datenschutz / Compliance werden als C einbezogen (nicht als separate Rolle modelliert)"
+
+  # ---------------------------------------------------------------------------
+  - id: ds_03
+    name: "Beschreiben des Vorgehens zur Implementierung"
+    typ: aktivitaet
+    yasm_referenz: "LP2: Implementation Blueprint"
+    ehemals: "sd_03"
+
+    beschreibung: >
+      Planen, WIE der Service organisatorisch eingeführt wird
+      (nicht technisch deployt wird).
+
+    umfasst:
+      - "Plan für organisatorische Integration"
+      - "Definition aller Rollenübergaben"
+      - "Anpassung von Richtlinien, Prozessen, Toolkonfiguration"
+      - "Definition benötigter Trainings / Kommunikation"
+      - "Bewertung von Time-to-Operate (Wann kann der Betrieb übernehmen?)"
+
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+      - rolle: projektleitung
+        raci: R
+      - rolle: betriebsteam
+        raci: C
+      - rolle: service_support_team
+        raci: C
+      - rolle: spm
+        raci: I
+
+  # ---------------------------------------------------------------------------
+  - id: ds_04
+    name: "Vorbereiten der Service-Implementierung"
+    typ: aktivitaet
+    yasm_referenz: "LP2: Organizational Integration Planning"
+    ehemals: "sd_04"
+
+    beschreibung: >
+      Finalisieren aller organisatorischen Voraussetzungen für die
+      spätere Übergabe in den Betrieb.
+
+    umfasst:
+      - "Abstimmung mit Betrieb & Support"
+      - "Sicherstellen, dass Prozesse, Tools, Strukturen vorbereitet sind"
+      - "Definition des ELS-Konzepts (Early Life Support) – falls gewünscht"
+      - "Validierung, dass der Service vollständig im Service-Portfolio erfasst ist"
+
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+      - rolle: projektleitung
+        raci: R
+      - rolle: betriebsteam
+        raci: C
+      - rolle: service_support_team
+        raci: C
+      - rolle: spm
+        raci: I
+

#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_operation.yaml

@@ -0,0 +1,277 @@
+metadata:
+  name: "Operation"
+  yasm_referenz: "LP4: Operate the services (LP4.1-LP4.5)"
+  version: "2.0"
+  status: "draft"
+  erstellt: "2025-11-26"
+  aktualisiert: "2026-01-30"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+  beschreibung: >
+    Laufender Betrieb eines aktivierten Services. Beginnt mit Early Life Support
+    (ELS) nach Go-Live und umfasst die strukturelle Grundlage (Leitlinien), 
+    operative Durchführung, Ressourcensteuerung, Monitoring, 
+    Qualitätsberichterstattung und proaktive Problemerkennung.
+
+  aenderungen:
+    - version: "2.0"
+      datum: "2026-01-30"
+      beschreibung: >
+        Konsolidierung auf 5-Phasen-Modell: Phase umbenannt von "Service Betrieb"
+        zu "Operation". Aktivitäts-IDs von sb_ auf op_ umgestellt. Early Life
+        Support (ehemals st_04) als op_01 integriert.
+
+    - version: "1.0"
+      datum: "2025-11-26"
+      beschreibung: "Initiale Erstellung"
+  
+  schnittstellen:
+    eingang:
+      - quelle: "Transition"
+        artefakt: "Aktivierter Service"
+        trigger: "SOR-Freigabe an Gate 3 (tr_11)"
+    ausgang:
+      - ziel: "Support"
+        artefakt: "Alarme, Events, Betriebsinformationen"
+      - ziel: "Review"
+        artefakt: "Service-Qualitätsbericht, Betriebsdaten"
+
+# =============================================================================
+# AKTIVITÄTEN
+# =============================================================================
+
+aktivitaeten:
+
+  # ---------------------------------------------------------------------------
+  - id: op_01
+    name: "Early Life Support (ELS)"
+    typ: aktivitaet
+    ehemals: "st_04"
+    
+    beschreibung: >
+      Phase erhöhter Aufmerksamkeit unmittelbar nach dem Go-Live.
+      Der Service ist produktiv, wird aber intensiver beobachtet und 
+      betreut als im Normalbetrieb.
+    
+    umfasst:
+      - "Erhöhte Monitoring-Bereitschaft"
+      - "Direkte Eskalationswege zum Projektteam (Phase 1: 4h Reaktionszeit)"
+      - "Schnelles Troubleshooting"
+      - "Aufarbeitung erster Incidents"
+      - "Feedback-Sammlung von Nutzern"
+      - "Stabilisierung bis zum Normalbetrieb"
+      - "ELS-Exit-Entscheidung (SO) nach Erfüllung der Exit-Kriterien"
+    
+    dauer:
+      mindestdauer: "2 Wochen"
+      regeldauer: "4 Wochen"
+      maximaldauer: "8 Wochen (Eskalations-Trigger)"
+
+    exit_kriterien:
+      - id: "EXIT-01"
+        name: "Stabilität"
+        beschreibung: "Keine kritischen Störungen in den letzten 2 Wochen"
+      - id: "EXIT-02"
+        name: "Support-Normalisierung"
+        beschreibung: "Ticket-Aufkommen auf erwartetem Normalniveau"
+      - id: "EXIT-03"
+        name: "Mängelfreiheit"
+        beschreibung: "Keine offenen fundamentalen Mängel"
+
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+        kontext: "Verantwortet ELS-Erfolg und ELS-Exit-Entscheidung"
+      - rolle: support_manager
+        raci: R
+      - rolle: operations_manager
+        raci: R
+      - rolle: projektteam
+        raci: C
+        kontext: "Während der ELS-Phase auf Abruf verfügbar"
+      - rolle: spm
+        raci: I
+        kontext: "Informiert über ELS-Ende"
+
+    hinweis: >
+      Der SO entscheidet eigenständig über den ELS-Exit (mit Informationspflicht
+      an SPM). Bei Überschreitung der Maximaldauer erfolgt automatische 
+      SOR-Eskalation.
+
+  # ---------------------------------------------------------------------------
+  - id: op_02
+    name: "Bereitstellen von Leitlinien für den Service-Betrieb"
+    typ: aktivitaet
+    ehemals: "sb_01"
+    
+    beschreibung: >
+      Dies ist die strukturelle Grundlage für den täglichen Servicebetrieb.
+    
+    umfasst:
+      - "Betriebshandbuch bereitstellen und pflegen"
+      - "Definition der Betriebsprozesse & Arbeitsanweisungen"
+      - "Sicherstellen, dass Rollen, Eskalationswege und Kommunikationsregeln klar sind"
+      - "Bereitstellen der notwendigen Informationen für die Betriebsführung (z.B. Standard Changes, Known Errors, Konfigurationsvorgaben)"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+        kontext: "Trägt die inhaltliche Verantwortung für funktionale Vorgaben"
+      - rolle: operations_manager
+        raci: R
+        kontext: "Führt aus, pflegt das Handbuch, operationalisiert Vorgaben"
+      - rolle: spm
+        raci: C/I
+        kontext: "Prüft Portfolio-Konsistenz"
+
+  # ---------------------------------------------------------------------------
+  - id: op_03
+    name: "Durchführen laufender Betriebsaufgaben"
+    typ: aktivitaet
+    ehemals: "sb_02"
+    
+    beschreibung: >
+      Dies sind die täglich wiederkehrenden Betriebsaktivitäten, die zur 
+      Erbringung des Services notwendig sind.
+    
+    umfasst:
+      - "Benutzerverwaltung & Berechtigungen"
+      - "Backup/Restore"
+      - "Technische Routineaufgaben"
+      - "Konfigurationspflege"
+      - "Pflege von Logs, Diensten und Überwachungsobjekten"
+      - "Einhaltung der Security- und Compliance-Anforderungen"
+      - "Umsetzung freigegebener Standard-Changes"
+    
+    mitarbeit:
+      - rolle: operations_manager
+        raci: A
+      - rolle: betriebsteam
+        raci: R
+        kontext: "Primär ausführend"
+      - rolle: service_owner
+        raci: C
+        kontext: "Fachliche Steuerung"
+      - rolle: lieferant
+        raci: C/I
+        kontext: "Wenn ausgelagerte Komponenten"
+      - rolle: spm
+        raci: I
+        kontext: "Transparenz im Portfolio"
+
+  # ---------------------------------------------------------------------------
+  - id: op_04
+    name: "Ressourcen, Dienstleister und Budget managen"
+    typ: aktivitaet
+    ehemals: "sb_03"
+    
+    beschreibung: >
+      Die Aktivität stellt sicher, dass der Servicebetrieb über die notwendigen 
+      Mittel verfügt, damit der Service stabil und wirtschaftlich erbracht 
+      werden kann.
+    
+    umfasst:
+      - "Sicherstellen, dass ausreichende personelle und technische Ressourcen für den Betrieb verfügbar sind"
+      - "Koordination mit externen Dienstleistern hinsichtlich vereinbarter Leistungen"
+      - "Überwachung des laufenden Betriebsbudgets und Kontrolle relevanter Kosten"
+      - "Abstimmung mit Supplier-, Finanz- und Vertragsmanagement bei Abweichungen"
+      - "Sicherstellen, dass notwendige Betriebsleistungen (z.B. Wartung, Bereitstellung von Lizenzen) erbracht werden"
+    
+    mitarbeit:
+      - rolle: operations_manager
+        raci: A
+      - rolle: betriebsteam
+        raci: R
+        kontext: "Steuert Ressourcen, überwacht Dienstleisterleistungen und kontrolliert Budgetverbrauch"
+      - rolle: service_owner
+        raci: C
+        kontext: "Definiert Bedarf, priorisiert Maßnahmen und bewertet Auswirkungen auf die Servicequalität"
+      - rolle: spm
+        raci: I
+        kontext: "Erhält Informationen zu Ressourcen-, Lieferanten- und Budgetlage für Portfolioentscheidungen"
+
+  # ---------------------------------------------------------------------------
+  - id: op_05
+    name: "Überwachen der Services"
+    typ: aktivitaet
+    ehemals: "sb_04"
+    
+    beschreibung: >
+      Strukturierte Überwachung des Services anhand definierter KPIs und Metriken.
+    
+    umfasst:
+      - "Überwachen der Verfügbarkeit, Performance, Auslastung"
+      - "Überwachen der Schnittstellen und Konfigurationsobjekte"
+      - "Identifikation von Trends oder drohenden Störungen"
+      - "Verknüpfung mit Events, Alerts, Dashboards"
+      - "Erstellen von Monitoring-Regeln im Betrieb"
+    
+    mitarbeit:
+      - rolle: operations_manager
+        raci: A
+      - rolle: betriebsteam
+        raci: R
+        kontext: "Laufendes Monitoring"
+      - rolle: service_owner
+        raci: C
+        kontext: "Definiert Metriken und Schwellenwerte"
+      - rolle: service_support_team
+        raci: I
+        kontext: "Reagiert auf Alarme in Ticketprozessen"
+      - rolle: spm
+        raci: I
+        kontext: "Erhält konsolidierte Daten für Portfolio-Steuerung"
+
+  # ---------------------------------------------------------------------------
+  - id: op_06
+    name: "Erstellen des Service-Qualitätsbericht"
+    typ: aktivitaet
+    ehemals: "sb_05"
+    
+    beschreibung: >
+      Regelmäßige Erstellung formaler Berichte über die erreichte Servicequalität.
+    
+    umfasst:
+      - "SLA-/SLO-Auswertung"
+      - "Auswertung technischer KPIs (Verfügbarkeit, Response Time etc.)"
+      - "Abgleich gegen definierte Qualitätsziele"
+      - "Identifikation von Verbesserungspotenzialen"
+      - "Zuarbeit für Service Review & SPM"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+        kontext: "Ist verantwortlich für Interpretation & Freigabe des Berichts"
+      - rolle: betriebsteam
+        raci: R
+        kontext: "Technische Daten sammeln, aufbereiten"
+      - rolle: spm
+        raci: C
+        kontext: "Nutzt die Daten für Portfolio-Steuerung"
+
+  # ---------------------------------------------------------------------------
+  - id: op_07
+    name: "Proaktive Problem Identifikation"
+    typ: aktivitaet
+    ehemals: "sb_06"
+    
+    beschreibung: >
+      Dies geht über Monitoring hinaus und ist die aktive Suche nach 
+      strukturellen Problemen.
+    
+    umfasst:
+      - "Trendanalysen aus Monitoringdaten"
+      - "Analyse von Engpässen, Ressourcenproblemen"
+      - "Technische Analyse von Systemmustern"
+      - "Erkennen potenzieller SLA-Verletzungen"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+        kontext: "Fachliche Priorisierung der Problemfelder"
+      - rolle: betriebsteam
+        raci: R
+        kontext: "Führt die proaktive Analyse durch"
+      - rolle: spm
+        raci: I
+        kontext: "Für strukturelle Portfolio-Entscheidungen"

#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_review.yaml

@@ -0,0 +1,268 @@
+metadata:
+  name: "Review"
+  yasm_referenz: "LP5: Improve the services"
+  version: "2.0"
+  status: "draft"
+  erstellt: "2025-11-26"
+  aktualisiert: "2026-01-30"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+  beschreibung: >
+    Periodische und anlassbezogene Bewertung der Service-Performance.
+    Umfasst taktische Analysen, Gremienentscheidungen und die Ableitung
+    von Verbesserungsmaßnahmen bis hin zur Stilllegung.
+
+  aenderungen:
+    - version: "2.0"
+      datum: "2026-01-30"
+      beschreibung: >
+        Konsolidierung auf 5-Phasen-Modell: Phase umbenannt von "Service Review"
+        zu "Review". Aktivitäts-IDs von sr_ auf rv_ umgestellt.
+
+    - version: "1.1"
+      datum: "2025-12-17"
+      beschreibung: |
+        - Referenz auf spm_konzept_service-review.yaml hinzugefügt
+        - Aktivität rv_02 um Bewertungsmethodik präzisiert (GOV-SR-001)
+        - Output-Präzisierung für Handlungsempfehlungen ergänzt
+
+    - version: "1.0"
+      datum: "2025-11-26"
+      beschreibung: "Initiale Erstellung"
+
+  referenzen:
+    konzept: "02a_lifecycle-konzepte/spm_konzept_service-review.yaml"
+    governance_entscheidungen: "GOV-SR-001 bis GOV-SR-005"
+  
+  schnittstellen:
+    eingang:
+      - quelle: "Operation"
+        artefakt: "Service-Qualitätsbericht, Monitoring-Daten"
+      - quelle: "Support"
+        artefakt: "Support-KPIs, Problem Records, Incident-Trends"
+    ausgang:
+      - ziel: "Operation"
+        artefakt: "Freigegebene Verbesserungsmaßnahmen"
+        bedingung: "Bei Service Improvement"
+      - ziel: "Demand-Lifecycle (DPM)"
+        artefakt: "Demand für strukturelle Änderung"
+        bedingung: "Bei Service Redesign / Erweiterung"
+      - ziel: "Demand-Lifecycle (DPM)"
+        artefakt: "Retirement-Plan, Decommissioning-Auftrag"
+        bedingung: "Bei Service außer Betrieb nehmen"
+
+# =============================================================================
+# AKTIVITÄTEN
+# =============================================================================
+
+aktivitaeten:
+
+  # ---------------------------------------------------------------------------
+  - id: rv_01
+    name: "Taktische Root-Cause-Analyse + Auswertung Support-KPIs"
+    typ: aktivitaet
+    ehemals: "sr_01"
+    
+    beschreibung: >
+      Strukturelle Analyse wiederkehrender Supportfälle und Betrachtung der KPIs, 
+      um mittelfristige Verbesserungen anzustoßen.
+    
+    umfasst:
+      - "KPI-Auswertung (Supportqualität, Trends, Belastungspunkte)"
+      - "Identifikation wiederkehrender Tickets und systemischer Ursachen"
+      - "Abgleich mit Problem Records"
+      - "Ableitung taktischer Verbesserungsmaßnahmen (z.B. Anpassungen im Service, Monitoring, Rollen, Prozessen)"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+        kontext: "Priorisiert und bestätigt Maßnahmen"
+      - rolle: problem_manager
+        raci: R
+        kontext: "Führt taktische Analyse durch"
+
+  # ---------------------------------------------------------------------------
+  - id: rv_02
+    name: "Service Performance & Improvement Review"
+    typ: aktivitaet
+    ehemals: "sr_02"
+
+    beschreibung: >
+      Operativer Review des Servicezustands basierend auf Qualitätsberichten,
+      Supportdaten und Problem-Analysen.
+
+    konzept_referenz: "spm_konzept_service-review.yaml -> bewertungsschema"
+    governance_referenz: "GOV-SR-001"
+
+    methodik:
+      beschreibung: "4-Dimensionen-Modell mit qualitativer Ampelbewertung"
+      dimensionen:
+        - "SR-D1: Leistungserbringung"
+        - "SR-D2: Betriebsstabilität"
+        - "SR-D3: Nutzerzufriedenheit"
+        - "SR-D4: Zukunftsfähigkeit"
+      bewertungsskala: "Grün / Gelb / Rot"
+
+    umfasst:
+      - "Abgleich der Service-Leistung gegen Ziele und SLAs"
+      - "Bewertung des Gesamterfüllungsgrades der Serviceerbringung"
+      - "Diskussion operativer Risiken, Störungen, Kapazitätsengpässe"
+      - "Identifikation von Maßnahmen zur Optimierung (kurz- und mittelfristig)"
+      - "Vorbereitung für SOR-Review"
+      - "Entscheidung, ob weitere Analyse / Verbesserung notwendig ist"
+
+    output_praezisierung:
+      handlungsempfehlung:
+        optionen: ["CONTINUE", "IMPROVEMENT", "REDESIGN", "RETIRE"]
+        dokumentation: "Service-Definition -> service_review"
+
+    mitarbeit:
+      - rolle: service_owner
+        raci: A/R
+        kontext: "Führt Review durch"
+      - rolle: spm
+        raci: I
+
+  # ---------------------------------------------------------------------------
+  - id: rv_03
+    name: "SOR: Periodischer Service Review"
+    typ: aktivitaet
+    ehemals: "sr_03"
+
+    beschreibung: >
+      Die SOR bewertet regelmäßig die Serviceleistung und trifft operative
+      Entscheidungen.
+    
+    umfasst:
+      - "Sichtung des Service Performance & Improvement Reviews"
+      - "Bewertung der Stabilität & Betriebsreife"
+      - "Priorisierung operativer Verbesserungen"
+      - "Freigabe kleinerer Verbesserungsmaßnahmen"
+      - "Entscheidung, ob eine tiefergehende Überarbeitung notwendig ist"
+      - "Schnittstelle zur Demand-/Portfolio-Steuerung bei größeren Änderungen"
+    
+    mitarbeit:
+      - rolle: sor
+        raci: A
+        kontext: "Trifft Entscheidungen"
+      - rolle: service_owner
+        raci: R
+        kontext: "Berichtet & präsentiert"
+    
+    entscheidungspfade:
+      - id: ep_weiter
+        name: "Weiter wie bisher"
+        bedingung: "Service stabil, keine Maßnahmen erforderlich"
+        ziel_aktivitaet: null
+        ziel_phase: "Operation"
+      
+      - id: ep_improvement
+        name: "Verbesserung nötig (klein)"
+        bedingung: "Optimierungsbedarf identifiziert, aber keine strukturelle Änderung"
+        ziel_aktivitaet: "rv_04"
+        ziel_phase: null
+      
+      - id: ep_redesign
+        name: "Strukturelle Überarbeitung nötig"
+        bedingung: "Tiefergehende Änderung erforderlich, die über Improvement hinausgeht"
+        ziel_aktivitaet: "rv_05"
+        ziel_phase: null
+      
+      - id: ep_retirement
+        name: "Service End-of-Life"
+        bedingung: "Service soll stillgelegt werden"
+        ziel_aktivitaet: "rv_06"
+        ziel_phase: null
+
+  # ---------------------------------------------------------------------------
+  - id: rv_04
+    name: "Service Improvement"
+    typ: aktivitaet
+    ehemals: "sr_04"
+    
+    beschreibung: >
+      Entscheidung aus der SOR: Planung und Steuerung von kleineren
+      Verbesserungsmaßnahmen innerhalb des Service.
+    
+    umfasst:
+      - "Umwandlung identifizierter Probleme in umsetzbare Verbesserungs-Initiativen"
+      - "Aufwandsschätzung und Priorisierung"
+      - "Festlegen der Zielmetriken für Verbesserung"
+      - "Zuweisung der Verantwortlichkeiten"
+      - "Sicherstellen, dass Verbesserungen im Service Portfolio sichtbar werden"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: A/R
+        kontext: "Führt Improvements, steuert Maßnahmen"
+      - rolle: spm
+        raci: C
+        kontext: "Für portfolio-relevante Anpassungen"
+      - rolle: problem_manager
+        raci: C
+        kontext: "Für Problem-bezogene Maßnahmen"
+    
+    ausgang:
+      ziel_phase: "Operation"
+      beschreibung: "Umsetzung der Verbesserungsmaßnahmen im laufenden Betrieb"
+
+  # ---------------------------------------------------------------------------
+  - id: rv_05
+    name: "Service Redesign / Erweiterung"
+    typ: aktivitaet
+    ehemals: "sr_05"
+    
+    beschreibung: >
+      Entscheidung aus der SOR: Strukturelle Weiterentwicklung des Service
+      auf Basis von SOR- oder Review-Entscheidungen.
+    
+    umfasst:
+      - "Überarbeitung der Service-Definitionen"
+      - "Anpassung von Komponenten, Prozessen oder Rollen"
+      - "Identifikation von Anforderungen für Entwicklungsprozess"
+      - "Übergabe an Demand-Lifecycle-Prozess"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+        kontext: "Verantwortet Redesign"
+      - rolle: spm
+        raci: C
+        kontext: "Prüft Portfolio-Anpassungen"
+    
+    ausgang:
+      ziel_phase: "Demand-Lifecycle (DPM)"
+      artefakt: "Neuer Demand"
+      beschreibung: "Strukturelle Änderung wird als Demand erfasst und durchläuft den Demand-Lifecycle"
+
+  # ---------------------------------------------------------------------------
+  - id: rv_06
+    name: "Service außer Betrieb nehmen"
+    typ: aktivitaet
+    ehemals: "sr_06"
+    
+    beschreibung: >
+      Strukturierte Entscheidung und kontrollierte Abschaltung eines Services.
+    
+    umfasst:
+      - "Auslöser definieren (z.B. niedrige Nutzung, zu hohe Kosten, technische Überalterung)"
+      - "Bewertung durch SOR"
+      - "Erstellen eines Retirement-Plans (Kommunikation, Migrationswege, Abschaltung)"
+      - "Koordination mit Portfolio (SPM)"
+      - "Übergabe an Projekt-/Transitionsthemen falls notwendig"
+    
+    mitarbeit:
+      - rolle: sor
+        raci: A
+        kontext: "Entscheidet"
+      - rolle: service_owner
+        raci: R
+        kontext: "Führt Retire-Plan aus"
+      - rolle: spm
+        raci: C
+        kontext: "Aktualisiert Portfolio"
+    
+    ausgang:
+      ziel_phase: "Demand-Lifecycle (DPM)"
+      artefakt: "Retirement-Plan / Decommissioning-Auftrag"
+      beschreibung: "Stilllegung wird als Demand/Projekt koordiniert"

#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_support.yaml

@@ -0,0 +1,367 @@
+metadata:
+  name: "Support"
+  yasm_referenz: "LP4: Operate the services (LP4.6-LP4.7)"
+  version: "2.0"
+  status: "draft"
+  erstellt: "2025-11-26"
+  aktualisiert: "2026-01-30"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+  beschreibung: >
+    Bearbeitung von Nutzeranfragen und Incidents im 1st/2nd Level, 
+    Wissensmanagement, Problemerkennung und Root-Cause-Analyse.
+    Bindeglied zwischen Anwendern, Betrieb und Problemmanagement.
+
+  aenderungen:
+    - version: "2.0"
+      datum: "2026-01-30"
+      beschreibung: >
+        Konsolidierung auf 5-Phasen-Modell: Phase umbenannt von "Service Support"
+        zu "Support". Aktivitäts-IDs von ss_ auf sp_ umgestellt.
+
+    - version: "1.0"
+      datum: "2025-11-26"
+      beschreibung: "Initiale Erstellung"
+  
+  schnittstellen:
+    eingang:
+      - quelle: "Transition"
+        artefakt: "Aktivierter Service"
+        trigger: "SOR-Freigabe an Gate 3 (tr_11)"
+      - quelle: "Nutzer/Anwender"
+        artefakt: "Incidents, Service Requests"
+      - quelle: "Operation"
+        artefakt: "Alerts, Events"
+    ausgang:
+      - ziel: "Review"
+        artefakt: "Support-KPIs, Incident-Trends"
+      - ziel: "Transition"
+        artefakt: "Change-Bedarf aus Problem Records"
+
+# =============================================================================
+# ARTEFAKTE
+# =============================================================================
+
+artefakte:
+
+  - id: problem_record
+    name: "Problem Record"
+    beschreibung: >
+      Der zentrale Container für alle Erkenntnisse der Problembehandlung.
+    inhalte:
+      - "Beschreibung des Problems"
+      - "Bekannte Workarounds"
+      - "Symptome und Diagnosewege"
+      - "Ursache (Root Cause), wenn gefunden"
+      - "Change-Bedarf"
+      - "Statusverfolgung und Priorisierung"
+    verantwortung:
+      - rolle: problem_manager
+        raci: A
+      - rolle: second_level_agent
+        raci: R
+      - rolle: service_owner
+        raci: I
+
+# =============================================================================
+# AKTIVITÄTEN
+# =============================================================================
+
+aktivitaeten:
+
+  # ---------------------------------------------------------------------------
+  - id: sp_01
+    name: "Bereitstellen von Leitlinien für den Service-Support"
+    typ: aktivitaet
+    ehemals: "ss_01"
+    
+    beschreibung: >
+      Dies umfasst das Bereitstellen aller strukturellen Rahmenbedingungen, 
+      damit Service-Support effizient arbeiten kann.
+    
+    umfasst:
+      - "Definition von Unterstützungsprozessen (z.B. Incident-Modell, Request-Modell)"
+      - "Vorgaben zu Eskalationen, Reaktionszeiten, Rollen"
+      - "Festlegung von Tool-Konfigurationen (Ticketklassen, Kategorien, Templates)"
+      - "Definition der Zugriffsmöglichkeiten (Remote-Zugänge, Adminrechte, Security-Policies)"
+      - "Sicherstellen eines konsistenten Wissensmanagements"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+        kontext: "Verantwortet fachliche Vorgaben"
+      - rolle: support_manager
+        raci: R
+        kontext: "Führt aus, pflegt Leitlinien"
+      - rolle: spm
+        raci: C/I
+        kontext: "Einbindung bei Portfolio-Relevanz"
+
+  # ---------------------------------------------------------------------------
+  - id: sp_02
+    name: "Wissensdatenbank"
+    typ: aktivitaet
+    ehemals: "ss_02"
+    
+    beschreibung: >
+      Ein strukturierter, gepflegter Wissensspeicher für Support-Lösungen, 
+      Betriebsinfos, Workarounds, Standardanfragen.
+    
+    umfasst:
+      - "Speichern von Lösungen zu Incidents"
+      - "Dokumentation von Workarounds (vom Problem Management)"
+      - "FAQ, Standard-Requests, Benutzeranleitungen"
+      - "Pflege & Aktualisierung bei Bedarf"
+      - "Bereitstellen als zentrales Arbeitsmittel für 1st & 2nd Level Support"
+    
+    mitarbeit:
+      - rolle: service_support_team
+        raci: R
+        kontext: "Pflegen Inhalte"
+      - rolle: service_owner
+        raci: A
+        kontext: "Verantwortet fachliche Richtigkeit"
+      - rolle: problem_manager
+        raci: C
+        kontext: "Liefert Workarounds / Known Errors"
+
+  # ---------------------------------------------------------------------------
+  - id: sp_03
+    name: "Überwachen / Verteilung von Incidents und Service Requests"
+    typ: aktivitaet
+    ehemals: "ss_03"
+    
+    beschreibung: >
+      Koordination der eingehenden Störungen/Anfragen, Priorisierung, Routing 
+      und Sicherstellen, dass Tickets korrekt aufgenommen und an zuständige 
+      Teams verteilt werden. Ticket-Queue Koordination.
+    
+    umfasst:
+      - "Sichtung neuer Tickets"
+      - "Automatisches Routing über Regeln oder manuelles Routing"
+      - "Prioritäts- und Impact-Bewertung"
+      - "Sicherstellung von SLA-Konformität (Reaktionszeiten)"
+      - "Eskalation bei Bedarf (funktional/zeitlich)"
+    
+    mitarbeit:
+      - rolle: queue_koordinator
+        raci: R
+        kontext: "Erledigt initiale Sichtung & Routing"
+      - rolle: support_manager
+        raci: A
+        kontext: "Organisatorische Verantwortung"
+
+  # ---------------------------------------------------------------------------
+  - id: sp_04
+    name: "Bearbeiten von Requests"
+    typ: aktivitaet
+    ehemals: "ss_04"
+    
+    beschreibung: >
+      Behandlung aller Standard-Serviceanfragen von Nutzern 
+      (z.B. Passwort zurücksetzen, Berechtigungen, Informationen).
+    
+    umfasst:
+      - "Klassifizierung und Bearbeitung gemäß Request-Katalog"
+      - "Prüfung von Berechtigungen"
+      - "Erfüllung standardisierter Anfragen"
+      - "Dokumentation der Erledigung"
+    
+    mitarbeit:
+      - rolle: first_level_agent
+        raci: R
+        kontext: "Bearbeitet einfache Standard-Requests"
+      - rolle: support_manager
+        raci: A
+        kontext: "Verantwortet Qualität & Prozess"
+
+  # ---------------------------------------------------------------------------
+  - id: sp_05
+    name: "Lösen von Incidents im 1st Level Support"
+    typ: aktivitaet
+    ehemals: "ss_05"
+    
+    beschreibung: >
+      Schnelle Lösung typischer Störungen, die mit bekanntem Wissen 
+      gelöst werden können.
+    
+    umfasst:
+      - "Erstdiagnose"
+      - "Nutzung der Wissensdatenbank"
+      - "Anwenderunterstützung"
+      - "Workarounds anwenden"
+      - "Dokumentieren der Lösung"
+      - "Entscheidung, ob Weiterleitung an 2nd Level nötig ist"
+    
+    mitarbeit:
+      - rolle: first_level_agent
+        raci: R
+        kontext: "Führt aus"
+      - rolle: support_manager
+        raci: A
+        kontext: "Stellt Leitlinien & Qualität sicher"
+
+  # ---------------------------------------------------------------------------
+  - id: sp_06
+    name: "Lösen von Incidents im 2nd Level Support"
+    typ: aktivitaet
+    ehemals: "ss_06"
+    
+    beschreibung: >
+      Bearbeitung aller Incidents, die nicht im 1st Level lösbar sind; 
+      tiefergehende Diagnostik und technische Lösung.
+    
+    umfasst:
+      - "Komplexe technische Diagnosen"
+      - "Enge Zusammenarbeit mit Betrieb, Fachverfahren, Lieferanten"
+      - "Ggf. Einbezug Spezialisten oder Hersteller"
+      - "Rückmeldung an 1st Level / Anwender"
+      - "Dokumentation der Lösung"
+      - "Entscheidung, ob Incident ungelöst → Problem Record"
+    
+    mitarbeit:
+      - rolle: second_level_agent
+        raci: R
+      - rolle: support_manager
+        raci: A
+      - rolle: lieferant
+        raci: C
+        kontext: "Bei externen Komponenten"
+      - rolle: service_owner
+        raci: I
+        kontext: "Informiert über schwerwiegende Incidents"
+
+  # ---------------------------------------------------------------------------
+  - id: sp_07
+    name: "Incident Record (Gelöst) / Request Record (Gelöst)"
+    typ: aktivitaet
+    ehemals: "ss_07"
+    
+    beschreibung: >
+      Abschluss der Bearbeitung eines Tickets inklusive Dokumentation 
+      und Qualitätssicherung.
+    
+    umfasst:
+      - "Validierung, ob Problem wirklich gelöst"
+      - "Kommunikation an den Endnutzer"
+      - "Aktualisieren der Dokumentationen / FAQs"
+      - "Klassifikation für Trendanalysen"
+      - "Übergabe an 'Schließen von Incidents'"
+    
+    mitarbeit:
+      - rolle: first_level_agent
+        raci: R
+      - rolle: second_level_agent
+        raci: R
+      - rolle: support_manager
+        raci: A
+
+  # ---------------------------------------------------------------------------
+  - id: sp_08
+    name: "Schließen von Incidents & Service Requests"
+    typ: aktivitaet
+    ehemals: "ss_08"
+    
+    beschreibung: >
+      Finaler Ticketabschluss inkl. Dokumentation, Reporting und 
+      Einordnung für spätere Verbesserungen.
+    
+    umfasst:
+      - "Ticket final schließen"
+      - "Prüfung vollständiger Dokumentation"
+      - "Ticketklassifizierung / Zuordnung von KPIs"
+      - "Rückmeldung an Monitoring/Reporting"
+      - "Identifikation wiederkehrender Incidents"
+    
+    mitarbeit:
+      - rolle: first_level_agent
+        raci: R
+      - rolle: second_level_agent
+        raci: R
+      - rolle: support_manager
+        raci: A
+
+  # ---------------------------------------------------------------------------
+  - id: sp_09
+    name: "Anlegen Problem Record für nicht lösbare Incidents"
+    typ: aktivitaet
+    ehemals: "ss_09"
+    
+    beschreibung: >
+      Wenn ein Incident auch im 2nd Level nicht lösbar ist, wird eine 
+      strukturelle Ursache vermutet.
+    
+    umfasst:
+      - "'Nicht lösbar'-Entscheidung"
+      - "Dokumentation der Symptome"
+      - "Eröffnen eines Problem Records"
+      - "Übergabe an Root-Cause-Analyse"
+    
+    erzeugt:
+      - artefakt: problem_record
+    
+    mitarbeit:
+      - rolle: second_level_agent
+        raci: R
+      - rolle: problem_manager
+        raci: A
+      - rolle: service_owner
+        raci: I
+
+  # ---------------------------------------------------------------------------
+  - id: sp_10
+    name: "Wiederkehrende Incidents analysieren & Problem Record anlegen"
+    typ: aktivitaet
+    ehemals: "ss_10"
+    
+    beschreibung: >
+      Ein reaktiver Weg, Probleme strukturiert zu erkennen, wenn dieselbe 
+      Störung mehrfach auftritt.
+    
+    umfasst:
+      - "Clustering wiederkehrender Incidents"
+      - "Analyse möglicher gemeinsamer Ursachen"
+      - "Entscheidung: Problem Record notwendig"
+      - "Übergabe an Problem Management"
+    
+    erzeugt:
+      - artefakt: problem_record
+    
+    mitarbeit:
+      - rolle: support_manager
+        raci: R
+      - rolle: problem_manager
+        raci: A
+      - rolle: second_level_agent
+        raci: C
+      - rolle: service_owner
+        raci: I
+
+  # ---------------------------------------------------------------------------
+  - id: sp_11
+    name: "Operative Root-Cause-Analyse durchführen & Workaround bereitstellen"
+    typ: aktivitaet
+    ehemals: "ss_11"
+    
+    beschreibung: >
+      Start der Problembehandlung zur Identifikation der eigentlichen 
+      Ursache und Schaffung eines Workarounds.
+    
+    umfasst:
+      - "Root-Cause-Analyse"
+      - "Erstellen eines Workarounds"
+      - "Eintrag in die Wissensdatenbank"
+      - "Entscheidung über Change-Bedarf"
+    
+    aktualisiert:
+      - artefakt: problem_record
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+      - rolle: problem_manager
+        raci: R
+      - rolle: second_level_agent
+        raci: C
+      - rolle: lieferant
+        raci: C/I

#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/service-lifecycle_transition.yaml

@@ -0,0 +1,578 @@
+metadata:
+  name: "Transition"
+  yasm_referenz: "LP3: Build new or changed services"
+  version: "2.0"
+  status: "draft"
+  erstellt: "2026-01-30"
+  aktualisiert: "2026-02-18"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+  beschreibung: >
+    Technische Realisierung und Überführung des Services in den produktiven
+    Betrieb. Umfasst Entry-Gate (Gate 1), Build/Konfiguration, Test,
+    Deployment und Go-Live-Freigabe.
+
+    Diese Phase konsolidiert die ehemaligen Phasen "Service Entwicklung" und
+    "Service Transition" und entspricht YASM LP3 (Build new or changed services).
+
+  aenderungen:
+    - version: "2.0"
+      datum: "2026-02-18"
+      beschreibung: >
+        Gate 1 aus Design-Phase hierher verschoben als tr_01 (Entry-Gate der
+        Transition). Alle Aktivitäts-IDs um +1 verschoben: ehemals tr_01-tr_11
+        wird zu tr_02-tr_12. Gate 2 ist nun tr_09 (ehemals tr_08), Gate 3 ist
+        nun tr_12 (ehemals tr_11). Die Transition-Phase enthält nun alle 3 Gates.
+
+    - version: "1.0"
+      datum: "2026-01-30"
+      beschreibung: >
+        Konsolidierung auf 5-Phasen-Modell: Zusammenführung von
+        "Service Entwicklung" (se_01-se_07) und "Service Transition" (st_01-st_04)
+        zu einer Phase "Transition" (tr_01-tr_11). Gate 2 (Entry-Prüfung) und
+        Gate 3 (Go-Live-Freigabe) integriert. ELS verschoben nach Operation.
+
+  schnittstellen:
+    eingang:
+      - quelle: "Design"
+        artefakt: "Service Design Document + Implementation Blueprint"
+        trigger: "Abschluss der Design-Phase (ds_04)"
+    ausgang:
+      - ziel: "Operation"
+        artefakt: "Aktivierter Service"
+        trigger: "SOR-Freigabe an Gate 3 (tr_12)"
+      - ziel: "Support"
+        artefakt: "Aktivierter Service mit Support-Dokumentation"
+        trigger: "SOR-Freigabe an Gate 3 (tr_12)"
+
+  hinweis: >
+    Die Transition-Phase enthält drei Gates: Gate 1 (tr_01) als Entry-Gate,
+    Gate 2 (tr_09) prüft die Übergabefähigkeit nach dem Build, Gate 3 (tr_12)
+    gibt den Go-Live frei. Early Life Support (ELS) wurde in die Operation-Phase
+    verschoben.
+
+# =============================================================================
+# GATE 1: ENTRY-GATE (TRANSITION ENTRY)
+# =============================================================================
+
+aktivitaeten:
+
+  # ---------------------------------------------------------------------------
+  - id: tr_01
+    name: "Gate 1: Entwicklung oder Konfiguration?"
+    typ: gate
+    gate_nummer: 1
+    yasm_referenz: "LP3 Entry Gate"
+    ehemals: "ds_05"
+
+    beschreibung: >
+      Entscheidung, ob die Service-Komponenten entwickelt oder nur
+      konfiguriert werden müssen. Dies ist Gate 1 im Service-Lifecycle:
+      das Entry-Gate der Transition-Phase.
+
+      WICHTIG: Diese Entscheidung erfordert SOR-Approval, da sie Budget-
+      und Ressourcenimplikationen hat.
+
+    umfasst:
+      - "Aufwandsschätzung (Build vs. Configure)"
+      - "Bewertung technischer Risiken"
+      - "Budget-Abgleich"
+      - "ggf. Lieferanten-Einbindung (Beschaffung)"
+      - "SOR-Vorlage für Gate-Freigabe"
+
+    entscheidungspfade:
+      - id: entwicklung
+        name: "Entwicklung"
+        beschreibung: "Neuentwicklung oder wesentliche Anpassung erforderlich"
+        folgeaktivitaet: tr_02
+        governance: "SOR-Approval erforderlich"
+
+      - id: konfiguration
+        name: "Konfiguration"
+        beschreibung: "Bestehende Komponenten werden konfiguriert/angepasst"
+        folgeaktivitaet: tr_05
+        governance: "SOR-Approval erforderlich"
+        hinweis: "Überspringt Entwicklungsaktivitäten (tr_02-tr_04), startet direkt bei Konfiguration"
+
+    mitarbeit:
+      - rolle: sor
+        raci: A
+        kontext: "Freigabe-Entscheidung für Eintritt in Transition"
+      - rolle: service_owner
+        raci: R
+        kontext: "Antragsteller und fachliche Empfehlung"
+      - rolle: projektleitung
+        raci: R
+        kontext: "Aufwandsschätzung und Ressourcenplanung"
+      - rolle: architektur
+        raci: R
+        kontext: "Technische Bewertung"
+      - rolle: spm
+        raci: C
+        kontext: "Portfolio-Perspektive"
+      - rolle: lieferant
+        raci: I
+        kontext: "Information für Beschaffungsplanung"
+
+    pruef_dimensionen:
+      - id: g1_dim_01
+        name: "Design-Vollständigkeit"
+        beschreibung: "Ist das Service Design Document vollständig und schlüssig?"
+        showstopper: true
+
+      - id: g1_dim_02
+        name: "Budget-Verfügbarkeit"
+        beschreibung: "Ist Budget für die gewählte Implementierungsstrategie verfügbar?"
+        showstopper: true
+
+      - id: g1_dim_03
+        name: "Projektressourcen"
+        beschreibung: "Können Ressourcen (intern/extern) für die Transition mobilisiert werden?"
+        showstopper: true
+
+      - id: g1_dim_04
+        name: "Betriebs- und Support-Bereitschaft"
+        beschreibung: >
+          Haben Betrieb und Support grundsätzlich die Kapazität und Bereitschaft,
+          diesen Service nach Abschluss der Transition zu übernehmen?
+
+          WICHTIG: Dies ist eine prinzipielle Prüfung VOR Beginn der Transition.
+          Ohne grundsätzliches Commitment darf die Transition nicht starten,
+          da sonst Ressourcen für einen Service aufgewendet werden, der nicht
+          betrieben werden kann.
+
+          Die operative Bestätigung (konkreter Termin, Personal eingeplant)
+          erfolgt an Gate 3.
+        showstopper: true
+        werte:
+          - "bestaetigt"
+          - "unter_vorbehalt"
+          - "nicht_gegeben"
+        hinweis: "Bei 'nicht_gegeben' ist Gate 1 nicht passierbar."
+
+      - id: g1_dim_05
+        name: "Risikobewertung"
+        beschreibung: "Sind Risiken identifiziert und bewertet?"
+        showstopper: false
+
+    governance_hinweis: >
+      Die SOR-Freigabe an Gate 1 stellt sicher, dass:
+      1. Das Design vollständig und schlüssig ist
+      2. Budget für die gewählte Implementierungsstrategie verfügbar ist
+      3. Ressourcen (intern/extern) für Transition mobilisiert werden können
+      4. Betrieb und Support grundsätzlich zur Übernahme bereit sind
+      5. Risiken identifiziert und bewertet sind
+
+# =============================================================================
+# AKTIVITÄTEN – BUILD (ehemals Service Entwicklung)
+# =============================================================================
+
+  # ---------------------------------------------------------------------------
+  - id: tr_02
+    name: "Koordinieren der Entwicklungs- und Beschaffungsaktivitäten"
+    typ: aktivitaet
+    yasm_referenz: "LP3.1: Coordinate build and acquisition activities"
+    ehemals: "se_01 / tr_01"
+
+    beschreibung: >
+      Steuern der Entwicklungsaktivitäten im Projekt.
+
+    umfasst:
+      - "Abstimmung mit Lieferanten"
+      - "Ressourcenplanung"
+      - "Termin- und Budgetnachführung"
+      - "Sicherstellung von Change-Kontrollen"
+      - "Definition von Build- und Konfigurationspaketen"
+
+    mitarbeit:
+      - rolle: projektleitung
+        raci: A
+      - rolle: architektur
+        raci: C
+      - rolle: service_owner
+        raci: I
+      - rolle: lieferant
+        raci: C/I
+
+  # ---------------------------------------------------------------------------
+  - id: tr_03
+    name: "Entwickeln von Anwendungen und Systemen"
+    typ: aktivitaet
+    yasm_referenz: "LP3.2: Develop applications and systems"
+    ehemals: "se_02 / tr_02"
+
+    beschreibung: >
+      Realisierung der technischen Service-Komponenten.
+
+    umfasst:
+      - "Softwareentwicklung"
+      - "Customizing"
+      - "Schnittstellenentwicklung"
+      - "Infrastrukturaufbau"
+      - "Versionierung & Dokumentation"
+      - "Testdaten & Migrationspfade vorbereiten"
+
+    mitarbeit:
+      - rolle: projektteam
+        raci: R
+        kontext: "Interne Entwicklung"
+      - rolle: lieferant
+        raci: R
+        kontext: "Externe Entwicklung"
+      - rolle: projektleitung
+        raci: A
+      - rolle: service_owner
+        raci: C
+      - rolle: architektur
+        raci: C
+
+  # ---------------------------------------------------------------------------
+  - id: tr_04
+    name: "Entgegennehmen der Service-Komponenten"
+    typ: aktivitaet
+    yasm_referenz: "LP3.3: Accept service components"
+    ehemals: "se_03 / tr_03"
+
+    beschreibung: >
+      Qualitätssicherung beim Übergang vom Entwicklungs- zur Testphase.
+
+    umfasst:
+      - "Eingangskontrolle"
+      - "Prüfung von Vollständigkeit / Qualität"
+      - "Sicherstellung der Dokumentationen"
+      - "Übergabe an Testmanagement"
+
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+      - rolle: projektleitung
+        raci: R
+      - rolle: testmanagement
+        raci: R
+      - rolle: lieferant
+        raci: C
+
+  # ---------------------------------------------------------------------------
+  - id: tr_05
+    name: "Konfiguration der Service-Komponenten"
+    typ: aktivitaet
+    yasm_referenz: "LP3.4: Configure service components"
+    ehemals: "se_04 / tr_04"
+
+    beschreibung: >
+      Einrichtung der Konfigurationsparameter, Settings, Rollen, Zugänge.
+
+    umfasst:
+      - "Setup von Parametern, Policies, Templates"
+      - "Toolkonfiguration (ITSM-Systeme, Monitoring)"
+      - "Anpassung bestehender Komponenten"
+      - "Verknüpfung mit Service-Katalog / Portfolio"
+
+    mitarbeit:
+      - rolle: projektteam
+        raci: R
+      - rolle: service_owner
+        raci: A
+      - rolle: betriebsteam
+        raci: C
+      - rolle: service_support_team
+        raci: C
+
+    hinweis: >
+      Diese Aktivität wird bei Gate-1-Entscheidung "Konfiguration"
+      als Einstiegspunkt verwendet (überspringt tr_02-tr_04).
+
+  # ---------------------------------------------------------------------------
+  - id: tr_06
+    name: "Erstellen oder Aktualisieren der Betriebs-Dokumentation"
+    typ: aktivitaet
+    yasm_referenz: "LP3.5: Document the services"
+    ehemals: "se_05 / tr_05"
+
+    beschreibung: >
+      Alle Betriebsunterlagen werden erstellt oder aktualisiert.
+
+    umfasst:
+      - "Service Operation Manual"
+      - "Supportanleitungen"
+      - "Monitoring-Spezifikationen"
+      - "Eskalationswege"
+      - "Standard Changes"
+      - "Konfigurations-/Betriebsrichtlinien"
+
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+      - rolle: projektteam
+        raci: R
+      - rolle: betriebsteam
+        raci: C
+      - rolle: service_support_team
+        raci: C
+
+  # ---------------------------------------------------------------------------
+  - id: tr_07
+    name: "Testen der Service-Komponenten"
+    typ: aktivitaet
+    yasm_referenz: "LP3.6: Test the services"
+    ehemals: "se_06 / tr_06"
+
+    beschreibung: >
+      Verifizierung, dass alle Servicekomponenten funktionsfähig und
+      bereit für den Betrieb sind.
+
+    umfasst:
+      - "Funktionstests"
+      - "Integrationstests"
+      - "Abnahmetests"
+      - "Nachweis der Betriebsreife"
+      - "Testprotokolle & Freigaben"
+
+    mitarbeit:
+      - rolle: testmanagement
+        raci: R
+      - rolle: projektleitung
+        raci: A
+      - rolle: service_owner
+        raci: C
+      - rolle: lieferant
+        raci: C/I
+
+  # ---------------------------------------------------------------------------
+  - id: tr_08
+    name: "Formale Übergabe (Build abgeschlossen)"
+    typ: aktivitaet
+    yasm_referenz: "LP3.7: Prepare for service activation"
+    ehemals: "se_07 / tr_07"
+
+    beschreibung: >
+      Der Build ist abgeschlossen. Alle Artefakte werden für die
+      Entry-Prüfung (Gate 2) bereitgestellt.
+
+    umfasst:
+      - "Bereitstellung aller Betriebsunterlagen"
+      - "Bereitstellung der Testprotokolle"
+      - "Dokumentierter Übergabe-Termin"
+      - "Vorbereitung Gate-2-Antrag"
+
+    mitarbeit:
+      - rolle: projektleitung
+        raci: A
+      - rolle: service_owner
+        raci: R
+        kontext: "Fachliche Freigabe"
+      - rolle: spm
+        raci: I
+        kontext: "Für Portfolio-Aktualisierung"
+      - rolle: betriebsteam
+        raci: C
+        kontext: "Übernahmebereitschaft prüfen"
+      - rolle: service_support_team
+        raci: C
+        kontext: "Support-Bereitschaft prüfen"
+
+# =============================================================================
+# GATE 2: ENTRY-PRÜFUNG
+# =============================================================================
+
+  # ---------------------------------------------------------------------------
+  - id: tr_09
+    name: "Gate 2: Entry-Prüfung nach Build"
+    typ: gate
+    gate_nummer: 2
+    ehemals: "tr_08"
+
+    beschreibung: >
+      Validierung der Übergabefähigkeit nach Abschluss des Builds.
+      Der Service Owner prüft, ob alle Voraussetzungen für die
+      Deploy-Aktivitäten erfüllt sind.
+
+      Dies ist eine SO-Einzelentscheidung (keine Gremienentscheidung).
+
+    umfasst:
+      - "Prüfung der Übergabe-Vollständigkeit (alle Artefakte vorhanden)"
+      - "Prüfung des Abnahme-Status (Auftraggeber-Abnahme liegt vor)"
+      - "Ressourcen-Outlook (Betrieb und Support prinzipiell vorbereitet)"
+      - "Pilot-Entscheidung (falls erforderlich)"
+      - "Dokumentation im Transition-Steckbrief"
+
+    entscheidungspfade:
+      - id: freigabe
+        name: "Freigabe"
+        beschreibung: "Weiter zu Deploy-Aktivitäten"
+        folgeaktivitaet: tr_10
+
+      - id: freigabe_mit_auflagen
+        name: "Freigabe mit Auflagen"
+        beschreibung: "Weiter, aber definierte Punkte müssen nachgearbeitet werden"
+        folgeaktivitaet: tr_10
+
+      - id: zurueck
+        name: "Zurück an Build"
+        beschreibung: "Nachbesserung erforderlich"
+        folgeaktivitaet: tr_02
+        hinweis: "Je nach Mängelart kann auch bei tr_05-tr_07 eingestiegen werden"
+
+      - id: ablehnung
+        name: "Ablehnung"
+        beschreibung: "Endgültige Ablehnung des Service-Vorhabens"
+        folgeaktivitaet: null
+        hinweis: "Erfordert SOR-Eskalation"
+
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+        kontext: "Gate-Keeper"
+      - rolle: projektleitung
+        raci: R
+        kontext: "Liefert Übergabe-Nachweis"
+      - rolle: betriebsteam
+        raci: C
+        kontext: "Bestätigt Übernahmebereitschaft"
+      - rolle: service_support_team
+        raci: C
+        kontext: "Bestätigt Support-Bereitschaft"
+      - rolle: spm
+        raci: I
+        kontext: "Bei Eskalation: Beratung"
+
+    governance_hinweis: >
+      Gate 2 ist eine operative Entscheidung des Service Owners.
+      Bei Unklarheit kann der SO das SPM zur Beratung hinzuziehen.
+      Ablehnung erfordert SOR-Eskalation.
+
+# =============================================================================
+# AKTIVITÄTEN – DEPLOY (ehemals Service Transition)
+# =============================================================================
+
+  # ---------------------------------------------------------------------------
+  - id: tr_10
+    name: "Ausrollen der Service-Komponenten"
+    typ: aktivitaet
+    ehemals: "st_02 / tr_09"
+
+    beschreibung: >
+      Technische Bereitstellung/Deployment des Services in die produktive Umgebung.
+
+    umfasst:
+      - "Deployment von Anwendungen, Systemen, Komponenten"
+      - "Konfiguration produktiver Systeme"
+      - "Migration von Daten"
+      - "Aktivierung von Monitoring"
+      - "Sicherstellen von Zugängen, Rollen, Berechtigungen"
+      - "Schnittstellen-Integration"
+      - "Technische Abnahmetests"
+
+    mitarbeit:
+      - rolle: betriebsteam
+        raci: R
+      - rolle: service_owner
+        raci: A
+      - rolle: spm
+        raci: C
+      - rolle: lieferant
+        raci: C/I
+
+  # ---------------------------------------------------------------------------
+  - id: tr_11
+    name: "Vorbereiten der Service-Aktivierung"
+    typ: aktivitaet
+    ehemals: "st_03 / tr_10"
+
+    beschreibung: >
+      Prüfung der Betriebsbereitschaft und Vorbereitung des Go-Live-Antrags
+      für Gate 3.
+
+    umfasst:
+      - "Review der Betriebsdokumentation"
+      - "Prüfung der Überwachungsregeln"
+      - "Prüfung der Rollen- und Eskalationswege"
+      - "Sicherstellen von Zugriffen & Toolanbindung"
+      - "Vorbereitung der Go-Live-Kommunikation"
+      - "Validierung der Service-Funktionalität mit Supportteams"
+      - "Vorbereitung Gate-3-Antrag (SOR-Vorlage)"
+
+    mitarbeit:
+      - rolle: betriebsteam
+        raci: R
+      - rolle: service_owner
+        raci: A
+        kontext: "Fachliche Freigabe"
+      - rolle: spm
+        raci: C
+
+# =============================================================================
+# GATE 3: GO-LIVE-FREIGABE
+# =============================================================================
+
+  # ---------------------------------------------------------------------------
+  - id: tr_12
+    name: "Gate 3: Go-Live-Freigabe"
+    typ: gate
+    gate_nummer: 3
+    ehemals: "st_01 / tr_11"
+
+    beschreibung: >
+      Portfolio-Freigabe und formale Aktivierung des Services.
+      Die SOR prüft die Betriebsreife aus Portfolio-Perspektive und
+      beschließt die Aufnahme ins Service-Portfolio.
+
+      Dies ist das Exit-Gate aus der Transition-Phase.
+
+    umfasst:
+      - "Prüfung der Portfolio-Konsistenz (strategische Ausrichtung)"
+      - "Prüfung der Betriebsreife (SO-Bestätigung)"
+      - "Prüfung der Support-Bereitschaft"
+      - "Prüfung der SLA/SLO-Vereinbarung"
+      - "Prüfung der Auflagen-Erfüllung aus Gate 2"
+      - "Bewertung der Geschäftskritikalität"
+      - "Beschluss: Go-Live / Go-Live mit Auflagen / Zurück / Ablehnung"
+      - "Formale Aufnahme ins Service-Portfolio"
+
+    entscheidungspfade:
+      - id: go_live
+        name: "Go-Live"
+        beschreibung: "Service wird aktiviert, Übergang zu Operation"
+        folgeaktivitaet: op_01
+        folge_phase: "Operation"
+
+      - id: go_live_mit_auflagen
+        name: "Go-Live mit Auflagen"
+        beschreibung: "Service wird aktiviert, definierte Punkte müssen nachgearbeitet werden"
+        folgeaktivitaet: op_01
+        folge_phase: "Operation"
+
+      - id: zurueck
+        name: "Zurück an Transition"
+        beschreibung: "Nachbesserung erforderlich"
+        folgeaktivitaet: tr_10
+        hinweis: "Je nach Mängelart kann auch bei tr_09 eingestiegen werden"
+
+      - id: ablehnung
+        name: "Ablehnung"
+        beschreibung: "Endgültige Ablehnung des Service-Vorhabens"
+        folgeaktivitaet: null
+
+    mitarbeit:
+      - rolle: sor
+        raci: A
+        kontext: "Endgültiger Beschluss (Konsent-Verfahren)"
+      - rolle: service_owner
+        raci: R
+        kontext: "Antragsteller"
+      - rolle: spm
+        raci: C
+        kontext: "Portfolio-Perspektive"
+      - rolle: projektleitung
+        raci: C
+      - rolle: operations_manager
+        raci: C
+      - rolle: support_manager
+        raci: C
+
+    governance_hinweis: >
+      Gate 3 ist eine SOR-Entscheidung nach dem Konsent-Prinzip.
+      Die SOR-Freigabe bewirkt gleichzeitig:
+      1. Aufnahme ins Service-Portfolio
+      2. Aktivierung des Katalog-Eintrags
+      3. Formale Bestätigung des Service Owners

#02_service-portfolio-management/02.1_spm_konzepte/02_spm_service-lifecycle-blueprint/spm_rollen.yaml

@@ -0,0 +1,407 @@
+metadata:
+  name: "Rollendefinitionen Service-Lifecycle"
+  version: "1.1"
+  status: "draft"
+  erstellt: "2025-11-26"
+  aktualisiert: "2026-01-31"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+  beschreibung: >
+    Definiert alle Rollen, die im Service-Lifecycle-Blueprint referenziert werden.
+    Dient als Single Source of Truth für Rollenbeschreibungen und RACI-Zuordnungen.
+  
+  aenderungshistorie:
+    - version: "1.1"
+      datum: "2026-01-31"
+      aenderung: "Operations Manager ersetzt durch AL Basis & Cloud und AL Applikationen"
+      governance_referenz: "GOV-SOR-005"
+      begruendung: "Anpassung an reale DIGIT-Organisationsstruktur, beide Betriebsperspektiven gleichwertig in SOR vertreten"
+
+# =============================================================================
+# RACI-Legende (für Referenz in Prozess-YAMLs)
+# =============================================================================
+raci_legende:
+  R: "Responsible – führt die Aktivität operativ aus"
+  A: "Accountable – trägt die Ergebnisverantwortung (genau eine Rolle pro Aktivität)"
+  C: "Consulted – wird vor Entscheidung/Durchführung einbezogen"
+  I: "Informed – wird über Ergebnis informiert"
+
+# =============================================================================
+# ROLLENKATEGORIEN
+# =============================================================================
+
+rollen:
+
+  # ---------------------------------------------------------------------------
+  # GOVERNANCE & STRATEGISCHE STEUERUNG
+  # ---------------------------------------------------------------------------
+  governance:
+
+    - id: spm
+      name: "Service-Portfolio-Manager"
+      kurzbezeichnung: "SPM"
+      typ: "Einzelrolle"
+      beschreibung: >
+        Steuert das gesamte Service-Portfolio, trifft Entscheidungen zu Aufnahme,
+        Aenderung und Stilllegung von Services. Sichert strategische Ausrichtung,
+        Priorisierung und Wirtschaftlichkeit.
+      verantwortlichkeiten:
+        - "Strategische Portfolio-Steuerung"
+        - "Entscheidungen zu Service-Aufnahme und -Stilllegung"
+        - "Sicherstellung der Wirtschaftlichkeit"
+        - "Portfolio-Konsistenz und Standards"
+        - "Erhalt und Aggregation aller Service-Review-Berichte (GOV-SR-002)"
+        - "Identifikation portfolio-uebergreifender Muster aus Reviews"
+        - "Koordination der SOR-Agenda fuer Review-Vorlagen (GOV-SR-004)"
+        - "Vollstaendigkeitspruefung der SOR-Vorlagen"
+      lifecycle_relevanz:
+        - "Service Entwicklung"
+        - "Service Transition"
+        - "Service Review"
+
+    - id: sor
+      name: "Service Operations Runde"
+      kurzbezeichnung: "SOR"
+      typ: "Gremium"
+      beschreibung: >
+        Gremium, das Service-Aktivierungen, Betriebsfreigaben und wesentliche 
+        Anpassungen bewertet und entscheidet. Sichert Betriebsreife, Risiken 
+        und organisatorische Abstimmung.
+      verantwortlichkeiten:
+        - "Freigabe von Service-Aktivierungen"
+        - "Bewertung der Betriebsreife"
+        - "Entscheidung über wesentliche Anpassungen"
+        - "Risikobewertung und organisatorische Abstimmung"
+      lifecycle_relevanz:
+        - "Service Transition"
+        - "Service Review"
+
+    - id: service_owner
+      name: "Service Owner"
+      kurzbezeichnung: "SO"
+      typ: "Einzelrolle"
+      beschreibung: >
+        Verantwortet fachlich einen Service ueber den gesamten Lifecycle, definiert
+        Anforderungen, Qualitaet und Weiterentwicklung. Primaerer Entscheider fuer
+        Service-Inhalt und -Wert.
+      verantwortlichkeiten:
+        - "End-to-End-Verantwortung fuer den Service"
+        - "Definition von Anforderungen und Qualitaetszielen"
+        - "Steuerung der Weiterentwicklung"
+        - "Fachliche Freigaben und Priorisierungen"
+        - "Quartalsweiser Service-Review (A/R) gemaess GOV-SR-002"
+        - "Improvement-Tracking in der Service-Definition (GOV-SR-005)"
+      lifecycle_relevanz:
+        - "Service Entwicklung"
+        - "Service Transition"
+        - "Service Betrieb"
+        - "Service Support"
+        - "Service Review"
+
+  # ---------------------------------------------------------------------------
+  # MANAGEMENT-ROLLEN (Operative Führung)
+  # ---------------------------------------------------------------------------
+  management:
+
+    - id: al_basis_cloud
+      name: "Abteilungsleitung Basis & Cloud"
+      kurzbezeichnung: "AL B&C"
+      typ: "Einzelrolle"
+      beschreibung: >
+        Verantwortet den stabilen, sicheren und effizienten Betrieb der 
+        Infrastruktur-Services (Netze, Server, Cloud-Plattformen). Koordiniert 
+        die Betriebsteams im Infrastrukturbereich und stellt die Einhaltung 
+        von SLAs und Policies sicher. Ständiges Mitglied der SOR.
+      verantwortlichkeiten:
+        - "Gesamtverantwortung für Infrastruktur-Betrieb"
+        - "Koordination der Betriebsteams (Netzwerk, Cloud, Deployment etc.)"
+        - "SLA- und Policy-Einhaltung im Infrastrukturbereich"
+        - "Ressourcenplanung und -priorisierung"
+        - "Betriebsreife-Bewertung für Infrastruktur-Services in der SOR"
+      themengruppen:
+        - "Netzwerk"
+        - "Cloud"
+        - "Deployment"
+        - "Infrastruktur-Betrieb"
+      lifecycle_relevanz:
+        - "Service Transition"
+        - "Service Betrieb"
+      gremien:
+        - gremium: "SOR"
+          funktion: "ständiges Mitglied"
+          stimmberechtigt: true
+          governance_referenz: "GOV-SOR-005"
+
+    - id: al_applikationen
+      name: "Abteilungsleitung Applikationen"
+      kurzbezeichnung: "AL App"
+      typ: "Einzelrolle"
+      beschreibung: >
+        Verantwortet den stabilen, sicheren und effizienten Betrieb der 
+        Anwendungs-Services (Fachverfahren, Standardsoftware, Eigenentwicklungen).
+        Koordiniert die Betriebsteams im Anwendungsbereich und stellt die 
+        Einhaltung von SLAs und Policies sicher. Ständiges Mitglied der SOR.
+      verantwortlichkeiten:
+        - "Gesamtverantwortung für Anwendungs-Betrieb"
+        - "Koordination der Betriebsteams (SAP, Ennaio, Fachverfahren etc.)"
+        - "SLA- und Policy-Einhaltung im Anwendungsbereich"
+        - "Ressourcenplanung und -priorisierung"
+        - "Betriebsreife-Bewertung für Anwendungs-Services in der SOR"
+      themengruppen:
+        - "SAP"
+        - "Ennaio"
+        - "Fachverfahren"
+        - "Anwendungs-Betrieb"
+      lifecycle_relevanz:
+        - "Service Transition"
+        - "Service Betrieb"
+      gremien:
+        - gremium: "SOR"
+          funktion: "ständiges Mitglied"
+          stimmberechtigt: true
+          governance_referenz: "GOV-SOR-005"
+
+    - id: support_manager
+      name: "Support Manager"
+      kurzbezeichnung: "Sup Mgr"
+      typ: "Einzelrolle"
+      beschreibung: >
+        Verantwortet Organisation und Qualität des Service-Supports (1st & 2nd Level). 
+        Sorgt für Prozesse, Leitlinien, Wissensmanagement und effizientes 
+        Incident/Request-Handling.
+      verantwortlichkeiten:
+        - "Organisation des Service-Supports"
+        - "Qualitätssicherung im Support"
+        - "Prozess- und Leitlinienentwicklung"
+        - "Wissensmanagement"
+      lifecycle_relevanz:
+        - "Service Transition"
+        - "Service Support"
+
+    - id: problem_manager
+      name: "Problem Manager"
+      kurzbezeichnung: "Prob Mgr"
+      typ: "Einzelrolle"
+      beschreibung: >
+        Identifiziert wiederkehrende oder strukturelle Störungen, führt 
+        Root-Cause-Analysen durch und steuert Problemlösungen. Sorgt für 
+        dauerhafte Fehlerbehebung und Workarounds.
+      verantwortlichkeiten:
+        - "Identifikation struktureller Störungen"
+        - "Durchführung von Root-Cause-Analysen"
+        - "Steuerung von Problemlösungen"
+        - "Bereitstellung von Workarounds"
+      lifecycle_relevanz:
+        - "Service Support"
+        - "Service Review"
+
+    - id: projektleitung
+      name: "Projektleitung"
+      kurzbezeichnung: "PL"
+      typ: "Einzelrolle"
+      beschreibung: >
+        Plant und steuert Service-Entwicklungsprojekte, koordiniert Ressourcen, 
+        Lieferanten und Umsetzungsaktivitäten. Gewährleistet termingerechte und 
+        qualitätsgesicherte Lieferung der Projektartefakte.
+      verantwortlichkeiten:
+        - "Planung und Steuerung von Entwicklungsprojekten"
+        - "Ressourcen- und Lieferantenkoordination"
+        - "Termin- und Qualitätssicherung"
+        - "Lieferung der Projektartefakte"
+      lifecycle_relevanz:
+        - "Service Entwicklung"
+        - "Service Transition"
+
+  # ---------------------------------------------------------------------------
+  # TEAMS (Kollektive Rollen)
+  # ---------------------------------------------------------------------------
+  teams:
+
+    - id: betriebsteam
+      name: "Betriebsteam"
+      kurzbezeichnung: "Betrieb"
+      typ: "Team"
+      beschreibung: >
+        Führt alle laufenden Betriebsaktivitäten für den Service aus - von
+        anwendungsnahen Routineaufgaben bis zur technischen Infrastrukturbetreuung.
+        Verantwortet Monitoring, Standard-Changes, Deployment, Systempflege und
+        tiefgehende Diagnosen. Sichert Stabilität, Verfügbarkeit und Qualität
+        des Betriebs.
+      verantwortlichkeiten:
+        - "Durchführung laufender Betriebsaufgaben"
+        - "Monitoring und Überwachung"
+        - "Ausführung von Standard-Changes"
+        - "Deployment und Rollout von Komponenten"
+        - "Betreuung technischer Infrastruktur"
+        - "Tiefgehende Diagnosen und Fehleranalyse"
+        - "Systempflege und -wartung"
+        - "Sicherstellung von Stabilität und Verfügbarkeit"
+      lifecycle_relevanz:
+        - "Service Entwicklung"
+        - "Service Transition"
+        - "Service Betrieb"
+
+    - id: service_support_team
+      name: "Service-Support Team"
+      kurzbezeichnung: "Support"
+      typ: "Team"
+      beschreibung: >
+        Bearbeitet Nutzeranfragen und Incidents im 1st/2nd Level, stellt schnelle 
+        Wiederherstellung und Nutzerunterstützung sicher. Bindeglied zwischen 
+        Anwendern, Betrieb und Problemmanagement.
+      verantwortlichkeiten:
+        - "Bearbeitung von Nutzeranfragen"
+        - "Incident-Bearbeitung (1st/2nd Level)"
+        - "Schnelle Wiederherstellung"
+        - "Schnittstelle zu Betrieb und Problemmanagement"
+      lifecycle_relevanz:
+        - "Service Entwicklung"
+        - "Service Support"
+
+    - id: projektteam
+      name: "Projektteam"
+      kurzbezeichnung: "Projekt"
+      typ: "Team"
+      beschreibung: >
+        Fachlich-technisches Team, das Entwicklung, Konfiguration, Tests und 
+        Dokumentation im Rahmen eines Projekts durchführt. Unterstützt Übergabe 
+        und Betriebsbefähigung.
+      verantwortlichkeiten:
+        - "Entwicklung und Konfiguration"
+        - "Testdurchführung"
+        - "Dokumentation"
+        - "Unterstützung bei Übergabe und Betriebsbefähigung"
+      lifecycle_relevanz:
+        - "Service Entwicklung"
+        - "Service Transition"
+
+  # ---------------------------------------------------------------------------
+  # INDIVIDUELLE OPERATIVE ROLLEN
+  # ---------------------------------------------------------------------------
+  operative_rollen:
+
+    - id: queue_koordinator
+      name: "Queue Koordinator"
+      kurzbezeichnung: "Queue Koord"
+      typ: "Einzelrolle"
+      beschreibung: >
+        Überwacht Ticketaufkommen, verteilt Tickets an richtige Bearbeitergruppen 
+        und sichert Priorisierung & SLA-Einhaltung. Stellt Transparenz und 
+        effizienten Ticketfluss sicher.
+      verantwortlichkeiten:
+        - "Überwachung des Ticketaufkommens"
+        - "Ticketverteilung und Routing"
+        - "Priorisierung und SLA-Überwachung"
+        - "Sicherstellung des Ticketflusses"
+      lifecycle_relevanz:
+        - "Service Support"
+
+    - id: first_level_agent
+      name: "1st Level Agent"
+      kurzbezeichnung: "L1"
+      typ: "Einzelrolle"
+      beschreibung: >
+        Erste Anlaufstelle für Nutzer, nimmt Incidents/Requests entgegen, löst 
+        Standardfälle und dokumentiert sauber. Eskaliert fachgerecht an den 
+        2nd Level bei Bedarf.
+      verantwortlichkeiten:
+        - "Entgegennahme von Incidents und Requests"
+        - "Lösung von Standardfällen"
+        - "Saubere Dokumentation"
+        - "Fachgerechte Eskalation"
+      lifecycle_relevanz:
+        - "Service Support"
+
+    - id: second_level_agent
+      name: "2nd Level Agent"
+      kurzbezeichnung: "L2"
+      typ: "Einzelrolle"
+      beschreibung: >
+        Bearbeitet komplexe Störungen und fachtechnische Anfragen, führt tiefere 
+        Analysen durch und stellt Lösungen bereit. Kooperiert mit Betrieb, 
+        Herstellern und Problemmanagement.
+      verantwortlichkeiten:
+        - "Bearbeitung komplexer Störungen"
+        - "Tiefere Analysen und Diagnosen"
+        - "Lösungsbereitstellung"
+        - "Kooperation mit Betrieb und Herstellern"
+      lifecycle_relevanz:
+        - "Service Support"
+
+    - id: testmanagement
+      name: "Testmanagement"
+      kurzbezeichnung: "Test Mgmt"
+      typ: "Einzelrolle"
+      beschreibung: >
+        Plant, organisiert und verantwortet Tests (Integration, Abnahme, Regression) 
+        während Service-Entwicklung und Transition. Sichert die Qualität und 
+        Betriebsreife neuer Service-Komponenten.
+      verantwortlichkeiten:
+        - "Testplanung und -organisation"
+        - "Verantwortung für Testdurchführung"
+        - "Qualitätssicherung neuer Komponenten"
+        - "Nachweis der Betriebsreife"
+      lifecycle_relevanz:
+        - "Service Entwicklung"
+
+    - id: architektur
+      name: "Architektur"
+      kurzbezeichnung: "Arch"
+      typ: "Einzelrolle"
+      beschreibung: >
+        Definiert technische Standards, Zielarchitekturen und Integrationsanforderungen; 
+        bewertet Designvarianten und Risiken. Sichert technische Konsistenz und 
+        Zukunftsfähigkeit des Service.
+      verantwortlichkeiten:
+        - "Definition technischer Standards"
+        - "Entwicklung von Zielarchitekturen"
+        - "Bewertung von Designvarianten und Risiken"
+        - "Sicherstellung technischer Konsistenz"
+      lifecycle_relevanz:
+        - "Service Entwicklung"
+
+  # ---------------------------------------------------------------------------
+  # EXTERNE ROLLEN
+  # ---------------------------------------------------------------------------
+  externe:
+
+    - id: lieferant
+      name: "Lieferant / Hersteller / Entwickler"
+      kurzbezeichnung: "Lieferant"
+      typ: "Externe Rolle"
+      beschreibung: >
+        Stellt externe System-, Software- oder Infrastrukturkomponenten bereit 
+        oder entwickelt spezifische Anpassungen. Wird bei Build, Fehleranalyse 
+        und Komponentensupport eingebunden.
+      verantwortlichkeiten:
+        - "Bereitstellung externer Komponenten"
+        - "Entwicklung spezifischer Anpassungen"
+        - "Unterstützung bei Fehleranalyse"
+        - "Komponentensupport"
+      lifecycle_relevanz:
+        - "Service Entwicklung"
+        - "Service Transition"
+        - "Service Support"
+
+# =============================================================================
+# ROLLEN-MAPPING (für schnelle Referenz)
+# =============================================================================
+rollen_index:
+  # Kurzreferenz: id -> name
+  spm: "Service-Portfolio-Manager"
+  sor: "Service Operations Runde"
+  service_owner: "Service Owner"
+  al_basis_cloud: "Abteilungsleitung Basis & Cloud"
+  al_applikationen: "Abteilungsleitung Applikationen"
+  support_manager: "Support Manager"
+  problem_manager: "Problem Manager"
+  projektleitung: "Projektleitung"
+  betriebsteam: "Betriebsteam"
+  service_support_team: "Service-Support Team"
+  projektteam: "Projektteam"
+  queue_koordinator: "Queue Koordinator"
+  first_level_agent: "1st Level Agent"
+  second_level_agent: "2nd Level Agent"
+  testmanagement: "Testmanagement"
+  architektur: "Architektur"
+  lieferant: "Lieferant / Hersteller / Entwickler"

#02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-betrieb-light.yaml

@@ -0,0 +1,104 @@
+# =============================================================================
+# KONZEPT: SERVICE-BETRIEB (LIGHT-WEIGHT)
+# =============================================================================
+
+metadata:
+  id: "K-BL"
+  name: "Service-Betrieb Light-Weight Konzept"
+  version: "0.1"
+  status: "placeholder"
+  erstellt: "2025-12-15"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+  dokumenttyp: "konzept"
+
+  beschreibung: >
+    Minimales Strukturkonzept für den Service-Betrieb. Definiert
+    Betriebsrollen und grundlegende Verantwortungsabgrenzungen,
+    um Anschlussfähigkeit an die operative Organisation herzustellen.
+
+  scope_hinweis: >
+    BEWUSST REDUZIERT: Dieses Konzept ist ein Strukturanker, keine
+    vollständige Betriebsprozess-Definition. Vertiefung in späterer Phase.
+
+  referenzen:
+    blueprint: "02_service-lifecycle-blueprint/service-lifecycle_service-betrieb.yaml"
+    rollen_kurzreferenz: "02_service-lifecycle-blueprint/spm_rollen.yaml"
+
+# =============================================================================
+# BEGRÜNDUNG
+# =============================================================================
+
+begruendung:
+  workshop_befund: >
+    Ohne minimale Strukturelemente für den Service-Betrieb fehlt die
+    Anschlussfähigkeit an die operative Organisation. Die Betriebsmannschaft
+    muss sich im Modell wiederfinden, sonst keine Legitimation.
+
+  systemtheoretisch: >
+    Das Konzept bleibt ohne operative Verankerung eine Parallelstruktur,
+    die von der Organisation als "Management-Theater" abgekoppelt wird.
+
+# =============================================================================
+# GLIEDERUNG (zu entwickeln)
+# =============================================================================
+
+gliederung:
+
+  - abschnitt: "Scope und Abgrenzung"
+    status: "ausstehend"
+    inhalte:
+      - "Was dieses Konzept ist (Strukturanker)"
+      - "Was dieses Konzept nicht ist (kein Betriebshandbuch)"
+      - "Verweis auf Blueprint für Aktivitäten"
+
+  - abschnitt: "Betriebsrollen (Minimum)"
+    status: "ausstehend"
+    inhalte:
+      - "Operations Manager"
+      - "Betriebsteam"
+      - "Technical Lead (optional)"
+    referenz: "spm_rollen.yaml → management, operativ"
+
+  - abschnitt: "Verantwortungsabgrenzung"
+    status: "ausstehend"
+    inhalte:
+      - "Service Owner vs. Operations Manager"
+      - "Betrieb vs. Support (Incident-Handling)"
+      - "Proaktiv vs. Reaktiv"
+
+  - abschnitt: "Schnittstelle zu Support"
+    status: "ausstehend"
+    inhalte:
+      - "Eskalationswege bei Incidents"
+      - "Problem-Identifikation"
+      - "Wissenstransfer"
+
+  - abschnitt: "Monitoring-Verantwortung"
+    status: "ausstehend"
+    inhalte:
+      - "Wer definiert Schwellwerte?"
+      - "Wer reagiert auf Alerts?"
+      - "Wer erstellt Qualitätsberichte?"
+
+# =============================================================================
+# EXPLIZITE NICHT-INHALTE
+# =============================================================================
+
+nicht_inhalte:
+  themen:
+    - "Detaillierte Betriebsprozesse"
+    - "Monitoring-Tool-Auswahl"
+    - "Kapazitätsplanung"
+    - "Change-Management im Betrieb"
+  hinweis: "Diese Themen werden in Phase X vertieft."
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+  - version: "0.1"
+    datum: "2025-12-15"
+    aenderung: "Placeholder erstellt mit Gliederungsskelett"
+    autor: "DIGITOM-Projekt"

#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_change-enablement.yaml

@@ -0,0 +1,844 @@
+# =============================================================================
+# KONZEPT: CHANGE ENABLEMENT (P-03)
+# =============================================================================
+# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/03_practices/
+# Dateiname: spm_practice_change-enablement.yaml
+# =============================================================================
+
+metadata:
+  id: "P-03"
+  name: "Change Enablement"
+  version: "1.3"
+  status: "draft"
+  erstellt: "2025-12-17"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+  dokumenttyp: "practice-konzept"
+  itil4_referenz: "Change Enablement Practice"
+  
+  beschreibung: |
+    Rahmenkonzept für die kontrollierte Durchführung von Service-Änderungen.
+    Definiert Change-Typen, Klassifizierungslogik, Autorisierungsverfahren
+    und Schnittstellen zu angrenzenden Prozessen.
+    
+    Ziel: Erfolgreiche Changes ermöglichen bei angemessener Risikokontrolle.
+    Prinzip: So wenig Governance wie nötig, so viel wie erforderlich.
+  
+  referenzen:
+    service_transition: "02a_lifecycle-konzepte/konzept_service-transition.yaml"
+    problem_management: "03_practices/spm_practice_service-support-management/sub-practice_problem-management.yaml"
+    shm_bedarfsbewertung: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml"
+    dpm_klassifizierung: "#01_demand-portfolio-management/#01.1_documentation/dpm_demand-klassifizierung.yaml"
+    governance_log: "spm_governance-entscheidungen-log.yaml"
+
+# =============================================================================
+# 1. EINORDNUNG UND SCOPE
+# =============================================================================
+
+einordnung:
+
+  zweck: |
+    Change Enablement stellt sicher, dass Service-Änderungen kontrolliert,
+    risikobewusst und effizient durchgeführt werden. Die Practice balanciert
+    zwischen Agilität (schnelle Umsetzung) und Stabilität (Schutz des Betriebs).
+  
+  itil4_definition: |
+    "The purpose of the change enablement practice is to maximize the number
+    of successful service and product changes by ensuring that risks have been
+    properly assessed, authorizing changes to proceed, and managing the
+    change schedule."
+
+  scope:
+    
+    in_scope:
+      - "Änderungen an bestehenden Services"
+      - "Service-Erweiterungen und -Optimierungen"
+      - "Technische Updates mit Service-Bezug"
+      - "Konfigurationsänderungen an Service-Komponenten"
+      - "Changes aus Problem Management (permanente Lösungen)"
+    
+    out_of_scope:
+      - typ: "Neue Services"
+        routing: "Service Transition (vollständiger Lifecycle)"
+        referenz: "konzept_service-transition.yaml"
+      
+      - typ: "Demands (neue Services / grundlegende Neugestaltung)"
+        routing: "Demand Portfolio Management"
+        referenz: "dpm_funktionsbeschreibung.yaml"
+      
+      - typ: "Service Requests"
+        routing: "Request Management (Katalog-basiert)"
+        referenz: "sub-practice_request-management.yaml"
+      
+      - typ: "Infrastruktur ohne Service-Bezug"
+        routing: "Produkt-Ebene (nicht in aktueller Phase)"
+        hinweis: "Siehe Abgrenzung Produkt"
+  
+  abgrenzung_produkt:
+    governance_referenz: "GOV-CE-002"
+    
+    vermerk: |
+      Infrastruktur-Änderungen ohne direkten Service-Bezug (z.B. Netzwerk-
+      Wartung, Basis-Infrastruktur) sind der Produkt-Ebene zuzuordnen.
+      
+      Da die Produkt-Konzeption in der aktuellen Projektphase nicht im Fokus
+      steht (Priorisierung Kunden-/Service-Sicht), wird dieser Bereich
+      bewusst ausgeklammert.
+      
+      Merke: Bei späterer Produkt-Konzeption ist Change Enablement für
+      Produkte/Infrastruktur zu ergänzen.
+    
+    praktische_regel: |
+      Frage: "Hat diese Änderung Auswirkungen auf einen Service im Katalog?"
+      - Ja → Change Enablement (dieses Konzept)
+      - Nein → Operativer Betrieb oder Produkt-Management
+
+# =============================================================================
+# 2. CHANGE-TYPEN
+# =============================================================================
+
+change_typen:
+
+  uebersicht:
+    beschreibung: |
+      DIGITOM unterscheidet vier Change-Typen, die sich in Risiko,
+      Autorisierungsverfahren und Dokumentationsaufwand unterscheiden.
+    
+    typen:
+      - "Standard Change (pre-authorized)"
+      - "Normal Change (SO-Entscheidung)"
+      - "Major Change (SOR-autorisierungspflichtig)"
+      - "Emergency Change (Sofortumsetzung)"
+
+  # ---------------------------------------------------------------------------
+  # STANDARD CHANGE
+  # ---------------------------------------------------------------------------
+  standard_change:
+    
+    definition: |
+      Ein Standard Change ist ein wiederkehrender, risikoarmer Change,
+      der vollständig dokumentiert ist und ohne zusätzliche Genehmigung
+      durchgeführt werden kann.
+    
+    merkmale:
+      - "Wiederkehrend und vorhersehbar"
+      - "Risiko bekannt und gering"
+      - "Ablauf standardisiert und dokumentiert"
+      - "Ergebnis vorhersehbar"
+    
+    voraussetzungen:
+      - "Change-Modell existiert und ist dokumentiert"
+      - "Change-Modell wurde einmalig durch SO genehmigt"
+      - "Rollback-Verfahren ist definiert"
+    
+    change_modell:
+      
+      beschreibung: |
+        Ein Change-Modell dokumentiert das Verfahren für einen Standard Change.
+        Es wird einmalig erstellt und genehmigt. Danach ist der Change
+        pre-authorized – jede Ausführung benötigt keine weitere Genehmigung.
+      
+      verantwortung_erstellung: "Service Owner"
+      verantwortung_genehmigung: "Service Owner"
+      
+      inhalt:
+        - name: "Change-Bezeichnung"
+          beschreibung: "Eindeutiger Name für den Standard Change"
+        - name: "Anwendungsbereich"
+          beschreibung: "Wann/wo wird dieser Change angewendet?"
+        - name: "Auslöser"
+          beschreibung: "Was triggert diesen Change?"
+        - name: "Durchführungsschritte"
+          beschreibung: "Schritt-für-Schritt-Anleitung"
+        - name: "Beteiligte Rollen"
+          beschreibung: "Wer führt durch, wer wird informiert?"
+        - name: "Risikobewertung"
+          beschreibung: "Bekannte Risiken und Mitigationen"
+        - name: "Rollback-Verfahren"
+          beschreibung: "Wie wird rückgängig gemacht?"
+        - name: "Erwartete Dauer"
+          beschreibung: "Typischer Zeitaufwand"
+      
+      transparenz: |
+        SO dokumentiert Change-Modelle für seinen Service.
+        SPM erhält Kopie zur Kenntnis (nicht zur Genehmigung).
+        Dies dient der Portfolio-Transparenz, nicht der Kontrolle.
+    
+    autorisierung: |
+      Keine weitere Genehmigung bei Ausführung erforderlich.
+      Die Genehmigung erfolgte einmalig bei Freigabe des Change-Modells.
+    
+    beispiele:
+      - "Passwort-Reset nach definiertem Verfahren"
+      - "Software-Update auf freigegebene Version"
+      - "Benutzer-Berechtigung gemäß Berechtigungskonzept"
+      - "Regelmäßige Wartungsarbeiten nach Wartungsplan"
+
+  # ---------------------------------------------------------------------------
+  # NORMAL CHANGE
+  # ---------------------------------------------------------------------------
+  normal_change:
+    
+    definition: |
+      Ein Normal Change ist eine Service-Änderung, die weder als Standard
+      Change pre-authorized ist, noch die Kriterien für einen Major Change
+      erfüllt. Er erfordert eine Einzelfallentscheidung durch den Service Owner.
+    
+    merkmale:
+      - "Nicht wiederkehrend oder nicht standardisierbar"
+      - "Risiko überschaubar, aber nicht trivial"
+      - "Service-Identität bleibt erhalten"
+      - "Keine Transition-Gates erforderlich"
+    
+    change_authority: "Service Owner"
+    
+    verfahren:
+      
+      schritte:
+        - schritt: 1
+          name: "Change Request"
+          beschreibung: "Anforderung wird dokumentiert (Ticket, E-Mail, etc.)"
+          verantwortlich: "Anfordernde Rolle"
+        
+        - schritt: 2
+          name: "Klassifizierung"
+          beschreibung: "SO prüft: Standard? Normal? Major?"
+          verantwortlich: "Service Owner"
+        
+        - schritt: 3
+          name: "Bewertung"
+          beschreibung: "SO bewertet Risiko, Aufwand, Auswirkungen"
+          verantwortlich: "Service Owner"
+        
+        - schritt: 4
+          name: "Entscheidung"
+          beschreibung: "SO entscheidet: Freigabe / Ablehnung / Rückfragen"
+          verantwortlich: "Service Owner"
+        
+        - schritt: 5
+          name: "Umsetzung"
+          beschreibung: "Change wird implementiert"
+          verantwortlich: "Betriebsteam / Projektteam"
+        
+        - schritt: 6
+          name: "Abschluss"
+          beschreibung: "SO bestätigt erfolgreiche Umsetzung"
+          verantwortlich: "Service Owner"
+    
+    cross_service:
+      governance_referenz: "GOV-CE-003"
+      
+      erkennung: |
+        Der Service Owner ist verantwortlich für die Erkennung von
+        Cross-Service-Impact. Er kennt seinen Service und dessen
+        Abhängigkeiten am besten.
+      
+      eskalation: |
+        Bei Normal Changes mit potenziellem Cross-Service-Impact
+        bezieht der SO den SPM als "Zweite Augen" ein.
+        
+        SPM prüft aus Portfolio-Perspektive:
+        - Gibt es Auswirkungen auf andere Services?
+        - Sind andere Service Owner zu informieren/einzubeziehen?
+        - Ist eine SOR-Befassung erforderlich?
+      
+      schwellenwert: |
+        SO-Ermessen: "Im Zweifel SPM einbeziehen."
+        
+        Keine formalen Schwellenwerte im MVP. Die operative Erfahrung
+        wird zeigen, ob Präzisierung nötig ist.
+      
+      verfahren_bei_cross_service:
+        - "SO identifiziert potenziellen Cross-Service-Impact"
+        - "SO informiert SPM (formlos, z.B. kurze E-Mail/Teams)"
+        - "SPM gibt Einschätzung: 'Go' oder 'Abstimmung mit SO X nötig'"
+        - "Bei Bedarf: Bilaterale Abstimmung zwischen betroffenen SOs"
+        - "Bei Dissens oder Unklarheit: Eskalation an SOR"
+
+  # ---------------------------------------------------------------------------
+  # MAJOR CHANGE
+  # ---------------------------------------------------------------------------
+  major_change:
+    
+    definition: |
+      Ein Major Change ist eine signifikante Service-Änderung, die die
+      Service-Identität berührt und daher eine SOR-Autorisierung erfordert.
+      Nach der Autorisierung durchläuft der Major Change den regulären
+      Service-Lifecycle (Design/Transition) je nach Einstiegspunkt.
+    
+    governance_referenz: "GOV-TR-003"
+    
+    merkmale:
+      - "Verändert wesentliche Service-Eigenschaften"
+      - "Höheres Risiko für Betrieb und Stakeholder"
+      - "Erfordert initiale Governance-Entscheidung durch SOR (Autorisierung)"
+      - "Durchläuft nach Autorisierung regulären Lifecycle (Design/Transition) je nach Einstiegspunkt"
+    
+    kriterien:
+      beschreibung: |
+        Ein Change gilt als Major, wenn mindestens eines der folgenden
+        Kriterien erfüllt ist. Die Bewertung erfolgt durch den SO nach
+        dem Prinzip "Informed Judgment".
+      
+      liste:
+        - id: "MAJ-01"
+          kriterium: "Änderung der Service-Definition"
+          beschreibung: "Der Scope, die Zielgruppe oder die Kernfunktionalität des Service ändert sich."
+          beispiele:
+            - "Service wird auf neue Nutzergruppe ausgeweitet"
+            - "Kernfunktion wird hinzugefügt oder entfernt"
+            - "Service-Scope wird signifikant erweitert/eingeschränkt"
+        
+        - id: "MAJ-02"
+          kriterium: "Änderung der SLA/SLO-Vereinbarungen"
+          beschreibung: "Die vereinbarten Service Levels ändern sich."
+          beispiele:
+            - "Verfügbarkeitsziel wird angepasst"
+            - "Support-Zeiten werden geändert"
+            - "Performance-Ziele werden neu definiert"
+        
+        - id: "MAJ-03"
+          kriterium: "Signifikante Architektur-Änderung"
+          beschreibung: "Die technische Grundstruktur des Service ändert sich wesentlich."
+          beispiele:
+            - "Wechsel der Basis-Plattform"
+            - "Neue kritische Abhängigkeit zu anderem System"
+            - "Grundlegende Änderung des Technologie-Stacks"
+          bei_unsicherheit: |
+            Bei Unsicherheit, ob eine Architektur-Änderung "signifikant" ist:
+            Architektur-Rolle konsultieren.
+        
+        - id: "MAJ-04"
+          kriterium: "DPM-Komplexität 'komplex' oder 'hochkomplex'"
+          beschreibung: |
+            Der Change resultiert aus einem Demand, der im DPM als
+            komplex oder hochkomplex klassifiziert wurde.
+          referenz: "dpm_demand-klassifizierung.yaml"
+          hinweis: |
+            Dieses Kriterium greift, wenn ein Demand durch DPM bearbeitet
+            wurde und als Umsetzungsauftrag an SPM übergeht.
+    
+    verfahren: |
+      Major Changes erfordern EINE SOR-Autorisierung. Danach durchlaufen
+      sie den regulären Service-Lifecycle. Der Ablauf ist:
+
+      1. SO klassifiziert Change als Major
+      2. SO stellt Major Change der SOR vor (Autorisierung)
+      3. SOR entscheidet: Autorisierung / Autorisierung mit Auflagen / Ablehnung
+         - Als Teil der Autorisierung legt SOR den Einstiegspunkt fest
+           (Design oder Transition), je nach Reifegrad der Änderung
+      4. Bei Autorisierung: Major Change durchläuft regulären Lifecycle
+         ab dem festgelegten Einstiegspunkt
+      5. Alle weiteren Gates (Gate 1, Gate 2, Gate 3) sind reguläre
+         Lifecycle-Gates – keine gesonderte Major-Change-Entscheidung
+
+      Wichtig: Die SOR hat bei einem Major Change genau EINE Entscheidung:
+      die initiale Autorisierung (oder Ablehnung). Danach ist der Major Change
+      eine Änderung an einem bestehenden Service und durchläuft als solcher
+      die vorgesehenen Lifecycle-Stufen und -Gates.
+      Dies unterscheidet ihn vom Normal Change, bei dem der SO allein entscheidet.
+
+      Details siehe konzept_service-transition.yaml
+    
+    referenz: "02a_lifecycle-konzepte/konzept_service-transition.yaml"
+
+  # ---------------------------------------------------------------------------
+  # EMERGENCY CHANGE
+  # ---------------------------------------------------------------------------
+  emergency_change:
+    governance_referenz: "GOV-CE-001"
+    
+    definition: |
+      Ein Emergency Change ist eine Änderung, die aufgrund kritischer
+      Sicherheits- oder Verfügbarkeitsprobleme sofort umgesetzt werden muss.
+      Das normale Genehmigungsverfahren wird zugunsten der Geschwindigkeit
+      verkürzt.
+    
+    merkmale:
+      - "Kritische Dringlichkeit (Sicherheit oder Verfügbarkeit)"
+      - "Sofortumsetzung erforderlich"
+      - "Dokumentation erfolgt nachträglich"
+      - "SO wird informiert, nicht um Genehmigung gefragt"
+    
+    ausloeser:
+      - "Kritische Sicherheitslücke (z.B. aktiv ausgenutzte Schwachstelle)"
+      - "Service-Ausfall mit hohem Business-Impact"
+      - "Datenverlust-Risiko"
+      - "Compliance-Verstoß mit sofortigem Handlungsbedarf"
+    
+    verfahren:
+      
+      autorisierung: |
+        Sofortumsetzung durch Betrieb/Support ohne vorherige Genehmigung.
+        Die Entscheidung zur Sofortumsetzung trifft die handelnde Rolle
+        (z.B. Operations Manager, Support Manager, L2-Agent).
+      
+      so_rolle: |
+        Der Service Owner wird informiert, nicht um Genehmigung gefragt.
+        Information erfolgt parallel zur oder unmittelbar nach der Umsetzung.
+      
+      dokumentation: |
+        Nachträgliche Dokumentation innerhalb von 24 Stunden:
+        - Was wurde geändert?
+        - Warum war Sofortumsetzung erforderlich?
+        - Wer hat entschieden/umgesetzt?
+        - Welche Auswirkungen hatte der Change?
+      
+      nachbereitung: |
+        Nach Abschluss des Emergency Change:
+        - SO prüft: Ist Nacharbeit erforderlich?
+        - Bei Bedarf: Normal Change für "saubere" Lösung
+        - Bei wiederkehrendem Muster: Problem Record erstellen
+    
+    abgrenzung: |
+      Nicht jeder dringende Change ist ein Emergency Change.
+      
+      Emergency = "Muss JETZT passieren, sonst kritischer Schaden"
+      Dringend = "Sollte schnell passieren" → Beschleunigter Normal Change
+
+# =============================================================================
+# 3. KLASSIFIZIERUNGSVERFAHREN
+# =============================================================================
+
+klassifizierung:
+
+  verantwortung: "Service Owner"
+  
+  prinzip: |
+    Die Klassifizierung erfolgt nach dem Prinzip "Informed Judgment".
+    Der SO trifft eine fachliche Einschätzung basierend auf seinem
+    Service-Wissen. Es gibt keine mechanischen Schwellenwerte.
+  
+  entscheidungslogik:
+    
+    beschreibung: |
+      Der SO durchläuft folgende Prüffragen, um den Change-Typ zu bestimmen.
+    
+    prueffragen:
+      - reihenfolge: 1
+        frage: "Ist das ein dokumentierter, pre-authorized Standard Change?"
+        wenn_ja: "→ Standard Change"
+        wenn_nein: "→ Weiter zu Frage 2"
+      
+      - reihenfolge: 2
+        frage: "Erfordert die Situation Sofortumsetzung (Sicherheit/Verfügbarkeit)?"
+        wenn_ja: "→ Emergency Change"
+        wenn_nein: "→ Weiter zu Frage 3"
+      
+      - reihenfolge: 3
+        frage: "Erfüllt der Change ein Major-Kriterium (MAJ-01 bis MAJ-04)?"
+        wenn_ja: "→ Major Change"
+        wenn_nein: "→ Normal Change"
+    
+    flussdiagramm: |
+      Change Request
+           │
+           ▼
+      ┌─────────────────────────────┐
+      │ Standard Change-Modell     │──► Ja ──► STANDARD
+      │ vorhanden?                 │
+      └─────────────────────────────┘
+           │ Nein
+           ▼
+      ┌─────────────────────────────┐
+      │ Kritische Dringlichkeit?   │──► Ja ──► EMERGENCY
+      │ (Sicherheit/Verfügbarkeit) │
+      └─────────────────────────────┘
+           │ Nein
+           ▼
+      ┌─────────────────────────────┐
+      │ Major-Kriterium erfüllt?   │──► Ja ──► MAJOR
+      │ (MAJ-01 bis MAJ-04)        │
+      └─────────────────────────────┘
+           │ Nein
+           ▼
+        NORMAL
+  
+  hochstufung:
+    beschreibung: |
+      Der SO kann einen Change jederzeit hochstufen, wenn sich während
+      der Bearbeitung herausstellt, dass die initiale Klassifizierung
+      nicht angemessen war.
+    
+    regel: |
+      - Normal → Major: SO stellt Change der SOR zur Autorisierung vor
+      - Standard → Normal: SO übernimmt Einzelfallentscheidung
+      - Jede Stufe → Emergency: Bei kritischem Sicherheits-/Verfügbarkeitsproblem
+    
+    dokumentation: |
+      Hochstufung wird im Change Request dokumentiert mit Begründung.
+  
+  dokumentation:
+    beschreibung: |
+      Die Klassifizierung wird im Change Request / Ticket dokumentiert.
+    
+    mindestangaben:
+      - "Change-Typ (Standard/Normal/Major/Emergency)"
+      - "Bei Normal/Major: Kurzbegründung"
+      - "Bei Major: Referenz auf erfülltes Kriterium (MAJ-01 bis MAJ-04)"
+
+# =============================================================================
+# 4. SCHNITTSTELLEN
+# =============================================================================
+
+schnittstellen:
+
+  # ---------------------------------------------------------------------------
+  # SCHNITTSTELLE: SHM-ROUTING
+  # ---------------------------------------------------------------------------
+  shm_routing:
+    
+    beschreibung: |
+      SHM führt eine Ersteinschätzung durch (Request / Change / Demand).
+      Diese Ersteinschätzung ist eine Orientierung, nicht verbindlich.
+      Die verbindliche Klassifizierung erfolgt durch den SO.
+    
+    zwei_stufen_modell:
+      stufe_1:
+        name: "SHM-Ersteinschätzung"
+        verantwortlich: "Stakeholder-Manager"
+        ergebnis: "Routing zu Service Desk / SO / DPM"
+        charakter: "Orientierung"
+      
+      stufe_2:
+        name: "SO-Klassifizierung"
+        verantwortlich: "Service Owner"
+        ergebnis: "Standard / Normal / Major / Emergency"
+        charakter: "Verbindlich"
+    
+    korrektur: |
+      Wenn SO feststellt, dass SHM-Routing nicht passt:
+      - Change ist eigentlich Demand → SO gibt zurück an SHM/DPM
+      - Demand ist eigentlich Change → SO übernimmt und klassifiziert
+    
+    referenz: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml"
+
+  # ---------------------------------------------------------------------------
+  # SCHNITTSTELLE: SERVICE TRANSITION
+  # ---------------------------------------------------------------------------
+  service_transition:
+    
+    beschreibung: |
+      Nach SOR-Autorisierung durchläuft ein Major Change den regulären
+      Service-Lifecycle ab dem von der SOR festgelegten Einstiegspunkt
+      (Design oder Transition). Die Lifecycle-Gates sind dabei reguläre
+      Gates – keine gesonderte Major-Change-Governance.
+
+    trigger: "SOR autorisiert Major Change und legt Einstiegspunkt fest"
+
+    uebergabe:
+      verantwortlich: "Service Owner"
+      aktion: "SO führt Major Change ab festgelegtem Einstiegspunkt im regulären Lifecycle durch"
+      artefakt: "Change Request wird zum Transition-/Design-Steckbrief erweitert"
+
+    rueckweg: |
+      Die regulären Lifecycle-Gates (Gate 1, 2, 3) gelten unverändert.
+      Bei Rückweisung an einem Gate: reguläres Gate-Verfahren.
+    
+    referenz: "02a_lifecycle-konzepte/konzept_service-transition.yaml"
+
+  # ---------------------------------------------------------------------------
+  # SCHNITTSTELLE: PROBLEM MANAGEMENT
+  # ---------------------------------------------------------------------------
+  problem_management:
+    
+    beschreibung: |
+      Problem Management identifiziert strukturelle Ursachen für Incidents.
+      Permanente Lösungen werden über Change Enablement umgesetzt.
+    
+    ablauf:
+      - schritt: 1
+        beschreibung: "Problem Manager identifiziert permanente Lösung"
+        verantwortlich: "Problem Manager / Service Owner"
+      
+      - schritt: 2
+        beschreibung: "Change Request wird erstellt"
+        verantwortlich: "Problem Manager"
+        inhalt:
+          - "Verweis auf Problem Record"
+          - "Beschreibung der Ursache"
+          - "Vorgeschlagene Lösung"
+      
+      - schritt: 3
+        beschreibung: "SO klassifiziert den Change"
+        verantwortlich: "Service Owner"
+      
+      - schritt: 4
+        beschreibung: "Change wird gemäß Typ bearbeitet"
+        verantwortlich: "Je nach Change-Typ"
+      
+      - schritt: 5
+        beschreibung: "Problem Record wird nach erfolgreicher Umsetzung geschlossen"
+        verantwortlich: "Problem Manager"
+    
+    referenz: "03_practices/spm_practice_service-support-management/sub-practice_problem-management.yaml"
+
+  # ---------------------------------------------------------------------------
+  # SCHNITTSTELLE: DPM (ABGRENZUNG CHANGE VS. DEMAND)
+  # ---------------------------------------------------------------------------
+  dpm_abgrenzung:
+    
+    beschreibung: |
+      Die Abgrenzung zwischen Change und Demand basiert auf der Frage:
+      "Bleibt der Service im Kern derselbe?"
+    
+    kriterium: "Service-Identität"
+    
+    proxy_fragen:
+      beschreibung: |
+        Da "Service-Identität" abstrakt ist, helfen folgende Proxy-Fragen:
+      
+      fragen:
+        - "Braucht es einen neuen Katalog-Eintrag?"
+        - "Ist ein neuer Service Owner erforderlich?"
+        - "Muss eine neue Service-Definition erstellt werden?"
+    
+    entscheidungsregel: |
+      - Mindestens eine Proxy-Frage mit "Ja" → Demand (→ DPM)
+      - Alle Proxy-Fragen mit "Nein" → Change (ggf. Major)
+    
+    grauzone: |
+      Bei Unsicherheit:
+      - SO bespricht mit SPM
+      - Im Zweifel: Als Major Change starten, bei Gate 1 kann SOR
+        entscheiden, ob Rückgabe an DPM erforderlich
+
+# =============================================================================
+# 5. GOVERNANCE
+# =============================================================================
+
+governance:
+
+  # ---------------------------------------------------------------------------
+  # CHANGE AUTHORITY MATRIX
+  # ---------------------------------------------------------------------------
+  change_authority_matrix:
+    
+    beschreibung: |
+      Die Change Authority ist die Rolle/Instanz, die einen Change autorisiert.
+      Sie variiert je nach Change-Typ und Risiko.
+    
+    matrix:
+      - change_typ: "Standard"
+        authority: "Pre-authorized (via Change-Modell)"
+        genehmigung_durch: "Entfällt (einmalig bei Modell-Freigabe)"
+        
+      - change_typ: "Normal"
+        authority: "Service Owner"
+        genehmigung_durch: "SO-Einzelentscheidung"
+        
+      - change_typ: "Normal (Cross-Service)"
+        authority: "Service Owner + SPM"
+        genehmigung_durch: "SO-Entscheidung nach SPM-Konsultation"
+        
+      - change_typ: "Major"
+        authority: "SOR"
+        genehmigung_durch: "SOR-Autorisierung (einmalig, inkl. Festlegung Einstiegspunkt)"
+        hinweis: "EIN Entscheidungspunkt: initiale Autorisierung. Danach regulärer Lifecycle mit regulären Gates."
+        
+      - change_typ: "Emergency"
+        authority: "Betrieb/Support"
+        genehmigung_durch: "Sofortumsetzung, nachträgliche Dokumentation"
+
+  # ---------------------------------------------------------------------------
+  # WARTUNGSFENSTER KRITISCHE SERVICES
+  # ---------------------------------------------------------------------------
+  wartungsfenster_kritische_services:
+    
+    governance_referenz: "GOV-CE-004"
+    
+    beschreibung: |
+      Für Services mit Kritikalitätsstufe 'geschaeftskritisch' (gemäß
+      Service-Definition) gelten besondere Anforderungen an die Change-Planung.
+    
+    referenz: "spm_schema_service-definition.yaml → geschaeftskritikalitaet"
+    
+    anforderungen:
+      - id: "WF-01"
+        beschreibung: "Wartungsarbeiten bevorzugt außerhalb der Kernarbeitszeiten"
+        hinweis: "Kernarbeitszeiten gemäß Service-Definition (verfuegbarkeit.servicezeit)"
+      
+      - id: "WF-02"
+        beschreibung: "Vorabkommunikation an betroffene Nutzergruppen (mind. 48h)"
+        ausnahme: "Emergency Changes sind hiervon ausgenommen"
+      
+      - id: "WF-03"
+        beschreibung: "Rollback-Plan muss vor Durchführung dokumentiert sein"
+        hinweis: "Gilt auch für Normal Changes an kritischen Services"
+      
+      - id: "WF-04"
+        beschreibung: "Bei Major Changes: Abstimmung mit Service Owner und ggf. Kundenvertretung"
+        hinweis: "Erhöhte Sorgfaltspflicht bei geschäftskritischen Services"
+    
+    impact_auf_klassifizierung: |
+      Die Geschäftskritikalität eines Services beeinflusst nicht die
+      Change-Typ-Klassifizierung (Standard/Normal/Major/Emergency),
+      sondern die Umsetzungsmodalitäten (Zeitfenster, Kommunikation, Rollback).
+
+  # ---------------------------------------------------------------------------
+  # ESKALATION
+  # ---------------------------------------------------------------------------
+  eskalation:
+    
+    bei_unsicherheit:
+      beschreibung: |
+        Wenn der SO bei der Klassifizierung oder Bewertung unsicher ist,
+        kann er formlos Rücksprache mit SPM halten.
+      verfahren: "Formlos (Gespräch, E-Mail, Teams)"
+      ergebnis: "SPM gibt Einschätzung, SO entscheidet"
+    
+    bei_cross_service:
+      beschreibung: |
+        Bei Changes mit Cross-Service-Impact wird SPM einbezogen.
+      verfahren: "SO informiert SPM, SPM gibt Einschätzung"
+      bei_dissens: "Eskalation an SOR"
+
+    bei_so_dpm_unklarheit:
+      beschreibung: |
+        Wenn unklar ist, ob etwas ein Change oder Demand ist.
+      verfahren: "SO bespricht mit SPM und/oder DPM (ROUTE-SO)"
+      bei_dissens: "Klärung bilateral mit Service Owner (GOV-SHM-029) oder Eskalation an DSR"
+
+  # ---------------------------------------------------------------------------
+  # TRANSPARENZ
+  # ---------------------------------------------------------------------------
+  transparenz:
+    
+    change_modelle:
+      regel: "SPM erhält Kopie aller Change-Modelle zur Kenntnis"
+      zweck: "Portfolio-Transparenz, nicht Genehmigung"
+      frequenz: "Bei Erstellung/Änderung eines Change-Modells"
+    
+    major_changes:
+      regel: "Alle Major Changes werden in SOR behandelt"
+      dokumentation: "SOR-Protokoll"
+    
+    reporting:
+      mvp_status: "Kein formales Change-Reporting im MVP"
+      hinweis: "Kann bei Bedarf später ergänzt werden"
+
+# =============================================================================
+# 6. ABSCHLUSS
+# =============================================================================
+
+abschluss:
+  
+  kriterium: |
+    Ein Change gilt als abgeschlossen, wenn der Service Owner die
+    erfolgreiche Umsetzung bestätigt hat.
+  
+  bestaetigung:
+    verantwortlich: "Service Owner"
+    form: "Dokumentiert im Change Request / Ticket"
+    inhalt:
+      - "Change wurde wie geplant umgesetzt"
+      - "Service funktioniert wie erwartet"
+      - "Keine unerwarteten Auswirkungen"
+  
+  bei_problemen: |
+    Wenn nach Umsetzung Probleme auftreten:
+    - Rollback prüfen (wenn möglich und sinnvoll)
+    - Incident erstellen (wenn Service-Störung)
+    - Ggf. weiteren Change initiieren (Korrektur)
+  
+  post_implementation_review:
+    mvp_status: "Nicht formalisiert"
+    beschreibung: |
+      Im MVP gibt es keinen formalen Post-Implementation-Review-Prozess.
+      Der SO bestätigt den Abschluss und beobachtet den Service.
+      
+      Bei wiederkehrenden Problemen nach Changes kann ein formaler
+      PIR-Prozess später ergänzt werden.
+
+# =============================================================================
+# 8. OFFENE PUNKTE / WEITERENTWICKLUNG
+# =============================================================================
+
+offene_punkte:
+  
+  - id: "OPEN-CE-001"
+    thema: "Change Schedule"
+    beschreibung: |
+      ITIL4 sieht einen Change Schedule zur Koordination vor.
+      Im MVP nicht implementiert.
+    prioritaet: "niedrig"
+    trigger_fuer_ergaenzung: "Wenn Koordinationsprobleme auftreten"
+  
+  - id: "OPEN-CE-002"
+    thema: "Post-Implementation Review"
+    beschreibung: |
+      Formaler PIR-Prozess ist im MVP nicht vorgesehen.
+    prioritaet: "niedrig"
+    trigger_fuer_ergaenzung: "Wenn wiederkehrende Probleme nach Changes auftreten"
+  
+  - id: "OPEN-CE-003"
+    thema: "Produkt/Infrastruktur-Changes"
+    beschreibung: |
+      Changes ohne Service-Bezug sind ausgeklammert (GOV-CE-002).
+    prioritaet: "mittel"
+    trigger_fuer_ergaenzung: "Bei Produkt-Konzeption in späterer Phase"
+  
+  - id: "OPEN-CE-004"
+    thema: "Formale Cross-Service-Schwellenwerte"
+    beschreibung: |
+      Aktuell SO-Ermessen. Ggf. später Präzisierung basierend auf Erfahrung.
+    prioritaet: "niedrig"
+    trigger_fuer_ergaenzung: "Wenn operative Probleme auftreten"
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+  
+  - version: "1.3"
+    datum: "2026-02-19"
+    aenderung: |
+      Major-Change-Governance vereinfacht (Kundenvorschlag):
+      - SOR hat bei Major Changes genau EINE Entscheidung (initiale Autorisierung)
+      - Bisheriges Zwei-Entscheidungspunkte-Modell (Entry + Gate 3) aufgelöst
+      - Nach SOR-Autorisierung: Major Change durchläuft regulären Lifecycle
+        (Design/Transition) je nach Einstiegspunkt
+      - SOR legt als Teil der Autorisierung den Einstiegspunkt fest
+      - Alle Lifecycle-Gates (Gate 1, 2, 3) sind reguläre Gates
+      - Change Authority Matrix, Verfahren, Schnittstelle Transition angepasst
+    autor: "DIGITOM-Projekt"
+    kontext: "Vereinfachung auf Basis Kunden-Annotation: Major Change kann diverse Wege nehmen"
+
+  - version: "1.2"
+    datum: "2026-01-31"
+    aenderung: |
+      Korrektur Major-Change-Routing:
+      - Verfahren präzisiert: SOR-Autorisierung vor Entry in Transition erforderlich
+      - Change Authority Matrix ergänzt: Zwei Entscheidungspunkte (Entry + Gate 3)
+      - Klarstellung: Major Change unterscheidet sich vom Normal Change durch
+        die obligatorische SOR-Autorisierung, nicht nur durch die Gate-3-Freigabe
+    autor: "DIGITOM-Projekt"
+    kontext: "Konzeptionelle Korrektur auf Basis Review"
+
+  - version: "1.1"
+    datum: "2026-01-28"
+    aenderung: |
+      Ergänzung Wartungsfenster kritische Services:
+      - Neuer Abschnitt 'wartungsfenster_kritische_services' (GOV-CE-004)
+      - Anforderungen WF-01 bis WF-04 für geschäftskritische Services
+      - Referenz auf Service-Kritikalität aus spm_schema_service-definition.yaml
+    autor: "DIGITOM-Projekt"
+    kontext: "Integration Geschäftskritikalität in Change-Planung"
+
+  - version: "1.0"
+    datum: "2025-12-17"
+    aenderung: |
+      Initiale Erstellung des Change Enablement Konzepts.
+      
+      Inhalt:
+      - Change-Typen (Standard, Normal, Major, Emergency)
+      - Klassifizierungsverfahren
+      - Change Authority Matrix
+      - Schnittstellen (SHM, Transition, Problem Management, DPM)
+      - Governance-Entscheidungen GOV-CE-001 bis GOV-CE-003
+      
+      Konsolidiert aus:
+      - GOV-TR-003 (Major-Kriterien)
+      - Klärungen CE-01 bis CE-03
+    autor: "DIGITOM-Projekt"

#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-catalog-management.yaml

@@ -0,0 +1,814 @@
+# =============================================================================
+# PRACTICE: SERVICE CATALOG MANAGEMENT
+# =============================================================================
+
+metadata:
+  id: "P-01"
+  name: "Service Catalog Management"
+  version: "0.2"
+  status: "draft"
+  erstellt: "2025-11-27"
+  aktualisiert: "2026-01-30"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+  dokumenttyp: "practice-konzept"
+  
+  funktion:
+    id: "SPM"
+    name: "Service-Portfolio-Management"
+  
+  taxonomie_referenz: "00_meta/digitom_taxonomie.yaml"
+  
+  beschreibung: >
+    Service Catalog Management stellt sicher, dass für jeden Service eine 
+    klare, aktuelle, vollständige und verlässliche Beschreibung existiert – 
+    und alle Stakeholder auf dieselbe Wahrheit zugreifen. Die Practice 
+    fungiert als Informations-Governance über alle Services und bildet die 
+    Brücke zwischen Service-Portfolio (strategisch), Service-Definition 
+    (operativ) und Service Level Management (qualitativ).
+  
+  itil4_referenz: "Service Catalogue Management Practice"
+  
+  lifecycle_phasen:
+    - design
+    - transition
+    - operation
+    - review
+  
+  practice_owner: "Service-Portfolio-Manager (SPM)"
+  
+  konsolidierung_hinweis: >
+    Im MVP ist die Practice Owner-Rolle für SCM mit der SPM-Rolle 
+    konsolidiert, um Rolleninflation zu vermeiden. Langfristig kann 
+    eine Trennung sinnvoll sein.
+  
+  schnittstellen:
+    intern:
+      - modul: "P-02 Service Level Management"
+        art: "erhält von"
+        beschreibung: "SLS/SLA-Referenzen zur Publikation im Katalog"
+      
+      - modul: "B-01 Service Transition"
+        art: "bidirektional"
+        beschreibung: "Katalogaufnahme als Teil des Transition-Prozesses"
+      
+      - modul: "B-03 Service Review"
+        art: "bidirektional"
+        beschreibung: "Review-Ergebnisse können Katalogänderungen triggern"
+    
+    extern:
+      - partner: "Stakeholder-Management (SHM)"
+        kontext: "Qualitätssicherung Kundenverständlichkeit"
+        status: "SHM-Modul in Entwicklung"
+      
+      - partner: "ITSM-Tool (Request-Katalog)"
+        kontext: "Stammdatenlieferung für Service-Requests"
+        status: "Tool-Auswahl ausstehend"
+
+# =============================================================================
+# KERNKONZEPTE
+# =============================================================================
+
+kernkonzepte:
+
+  # ---------------------------------------------------------------------------
+  # ZENTRALE ARTEFAKTE
+  # ---------------------------------------------------------------------------
+  artefakte:
+    beschreibung: >
+      SCM verwaltet zwei zentrale Artefakte, die in einer 
+      Master-Derivat-Beziehung stehen.
+    
+    artefakte:
+      - name: "Service-Definition"
+        typ: "Master-Dokument"
+        beschreibung: >
+          Internes Dokument mit allen relevanten Informationen zu einem 
+          Service. Single Source of Truth für DIGIT.
+        schema: "02.5_informationsmodell/spm_schema_service-definition.yaml"
+        verantwortung_erstellung: "Service Owner"
+        verantwortung_validierung: "SPM (als SCM Practice Owner)"
+      
+      - name: "Service-Steckbrief"
+        typ: "Derivat"
+        beschreibung: >
+          Kundenorientierter Auszug aus der Service-Definition. 
+          Wird im Service-Katalog publiziert.
+        schema: "02.5_informationsmodell/spm_schema_service-steckbrief.yaml"
+        verantwortung_ableitung: "Service Owner"
+        verantwortung_freigabe: "SPM"
+        verantwortung_publikation: "SPM"
+    
+    beziehung: >
+      Der Service-Steckbrief wird aus der Service-Definition abgeleitet.
+      Änderungen an der Service-Definition können Aktualisierungen des 
+      Steckbriefs erfordern. Das Mapping ist im Schema dokumentiert.
+
+  # ---------------------------------------------------------------------------
+  # SERVICE-KATALOG
+  # ---------------------------------------------------------------------------
+  service_katalog:
+    beschreibung: >
+      Der Service-Katalog ist kein einzelnes Tool, sondern ein logisches 
+      Konstrukt: die offizielle, konsolidierte Sicht auf alle angebotenen 
+      Services des DIGIT mit ihren wesentlichen Merkmalen. 
+      Diese Sicht wird in geeigneten Werkzeugen (z. B. Intranet-Portal, 
+      ITSM-Tool, Dokumentation) für unterschiedliche Zielgruppen 
+      bereitgestellt.
+      
+    inhalt: "Alle Service-Steckbriefe für Services im Status 'Live'"
+    
+    nicht_enthalten:
+      - "Services in der Pipeline (noch nicht live)"
+      - "Stillgelegte Services (retired)"
+      - "Interne Services (Kategorie I) – per Definition nicht im Katalog (GOV-SPM-I-001, GOV-SPM-I-003)"
+
+    ausschlussregel_kategorie_I:
+      beschreibung: |
+        Der Service-Katalog enthält ausschließlich Kundenservices der
+        Kategorien A, B und C. Interne Services (Kategorie I) werden
+        NICHT im Katalog publiziert. Die Sichtbarkeit ist vollständig
+        aus der Service-Kategorie ableitbar – ein separates Attribut
+        service_sichtbarkeit existiert nicht.
+      governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-003, VAL-007"
+    
+    publikationskanaele:
+      beschreibung: >
+        Der Katalog kann über verschiedene Kanäle zugänglich gemacht werden.
+        Die konkrete Implementierung ist nicht Teil dieser Practice-Definition.
+      
+    stakeholder_einbindung:
+      beschreibung: >
+        Das Stakeholder-Management (SHM) unterstützt bei der Formulierung 
+        kundenverständlicher Texte und bei der Priorisierung von 
+        Verbesserungsbedarfen aus Sicht der Ämter. 
+        Im MVP ist dies optional, im Zielbild standardmäßig vorgesehen.
+
+      anforderungen:
+        - "Barrierefreier Zugang für alle Zielgruppen"
+        - "Durchsuchbarkeit"
+        - "Aktualität (zeitnahe Publikation von Änderungen)"
+        - "Kategorie-basierte Sichtbarkeitssteuerung"
+      
+      moegliche_kanaele:
+        - "Intranet-Seite"
+        - "Self-Service-Portal"
+        - "ITSM-Tool (Request-Katalog-View)"
+        - "PDF-Export (für Offline-Nutzung)"
+      
+      verantwortung_inhalt: "SPM"
+      verantwortung_betrieb: "TBD (abhängig von Kanal)"
+
+  # ---------------------------------------------------------------------------
+  # KATALOG-VIEWS
+  # ---------------------------------------------------------------------------
+  katalog_views:
+    beschreibung: >
+      Der Katalog unterstützt unterschiedliche Sichten für 
+      unterschiedliche Zielgruppen.
+    
+    views:
+      - name: "Nutzer-View"
+        zielgruppe: "Alle Mitarbeitenden"
+        fokus: "Was gibt es? Was bekomme ich? Wie beantrage ich?"
+        inhalte:
+          - "Alle Basis-Services (Kategorie A)"
+          - "Alle Erweiterten Services (Kategorie B)"
+          - "Spezial-Services nur wenn berechtigt (Kategorie C)"
+      
+      - name: "Entscheider-View"
+        zielgruppe: "Amtsleitungen, Kundenvertretungen"
+        fokus: "Welche Services nutzt mein Amt? Welche Qualität? Welche Kosten?"
+        inhalte:
+          - "Alle Services mit SLA/SLS-Referenzen"
+          - "Service-Owner-Kontakte"
+          - "Berechtigungslogik"
+      
+      - name: "Request-View"
+        zielgruppe: "Mitarbeitende (im ITSM-Tool)"
+        fokus: "Was kann ich bestellen/beantragen?"
+        inhalte:
+          - "Bestellbare Services"
+          - "Beantragungswege"
+          - "Voraussetzungen"
+        hinweis: "Diese View wird im ITSM-Tool realisiert, nicht im Katalog selbst"
+
+  # ---------------------------------------------------------------------------
+  # KATEGORIEN IM KATALOG
+  # ---------------------------------------------------------------------------
+  kategorien_logik:
+    beschreibung: >
+      Die Service-Kategorien A/B/C (definiert in P-02 SLM) haben 
+      direkte Auswirkungen auf die Katalogdarstellung.
+    
+    kategorie_a:
+      name: "Basis-Services"
+      katalog_sichtbarkeit: "Für alle sichtbar"
+      katalog_darstellung: "Vollständiger Steckbrief"
+      service_level_anzeige: "SLS-Referenz"
+      beantragung_hinweis: "Automatische Bereitstellung, keine Beantragung nötig"
+    
+    kategorie_b:
+      name: "Erweiterte Services"
+      katalog_sichtbarkeit: "Für alle sichtbar"
+      katalog_darstellung: "Vollständiger Steckbrief"
+      service_level_anzeige: "SLS-Referenz"
+      beantragung_hinweis: "Beantragung über definierten Weg"
+    
+    kategorie_c:
+      name: "Spezial-Services"
+      katalog_sichtbarkeit: "Eingeschränkt (nur berechtigte Ämter)"
+      katalog_darstellung: "Reduzierter Steckbrief oder Verweis"
+      service_level_anzeige: "Verweis auf bilaterales SLA"
+      beantragung_hinweis: "Kontakt über Service Owner"
+
+    kategorie_i:
+      name: "Interne Services"
+      katalog_sichtbarkeit: "NICHT im Katalog (per Definition)"
+      katalog_darstellung: "Kein Steckbrief – nur Service-Definition (intern)"
+      service_level_anzeige: "OLA (intern, nicht publiziert)"
+      beantragung_hinweis: "Kein Beantragungsweg – rein interne Steuerung"
+      governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-003"
+
+  # ---------------------------------------------------------------------------
+  # ABGRENZUNG
+  # ---------------------------------------------------------------------------
+  abgrenzung:
+    beschreibung: "Was SCM NICHT ist"
+    
+    nicht_ziele:
+      - aspekt: "Request-Katalog / Ticketing"
+        abgrenzung: >
+          SCM liefert Stammdaten an das ITSM-Tool. 
+          Die Request-Abwicklung ist Aufgabe von P-05 Request Management.
+      
+      - aspekt: "IT-Serviceportal"
+        abgrenzung: >
+          SCM definiert Inhalte und Struktur. 
+          Der Portal-Betrieb ist eine separate Verantwortung.
+      
+      - aspekt: "Technische Dokumentation"
+        abgrenzung: >
+          SCM fokussiert auf kundenrelevante Informationen. 
+          Technische Details gehören in Betriebshandbücher.
+      
+      - aspekt: "Governance-Gremium"
+        abgrenzung: >
+          SCM ist ein Prozess, kein Gremium. 
+          Entscheidungen werden in SOR/MB getroffen.
+      
+      - aspekt: "Service-Portfolio-Steuerung"
+        abgrenzung: >
+          SCM publiziert den Katalog (Live-Services). 
+          Die Portfolio-Steuerung (Pipeline, Retire) liegt bei SPM.
+
+# =============================================================================
+# AKTIVITÄTEN – PHASE: TRANSITION
+# =============================================================================
+
+aktivitaeten_transition:
+  beschreibung: >
+    Aktivitäten zur Aufnahme neuer Services in den Katalog, 
+    typischerweise am Ende der Service-Transition-Phase.
+
+  aktivitaeten:
+    # -------------------------------------------------------------------------
+    - id: scm_01
+      name: "Service-Definition validieren"
+      
+      beschreibung: >
+        Prüfung der vom Service Owner erstellten Service-Definition 
+        auf Vollständigkeit, Konsistenz und Konformität mit dem Schema.
+      
+      ausloeser:
+        - "Neuer Service erreicht Transition-Phase"
+        - "Wesentliche Service-Änderung (aus Demand)"
+      
+      eingang:
+        - artefakt: "Service-Definition (Entwurf)"
+          quelle: "Service Owner"
+        - artefakt: "SLS/SLA-Referenz"
+          quelle: "P-02 Service Level Management"
+      
+      umfasst:
+        - "Prüfung gegen Schema (Pflichtfelder, Datentypen)"
+        - "Prüfung Konsistenz mit Service-Kategorie"
+        - "Prüfung SLS/SLA-Referenz vorhanden und korrekt"
+        - "Prüfung Abhängigkeiten dokumentiert"
+        - "Rückmeldung an Service Owner bei Mängeln"
+      
+      ausgang:
+        - artefakt: "Service-Definition (validiert)"
+          ziel: "scm_02"
+        - artefakt: "Validierungsprotokoll"
+          ziel: "Dokumentation"
+      
+      qualitaets_gate:
+        name: "Service-Definition vollständig"
+        kriterien:
+          - "Alle Pflichtfelder ausgefüllt"
+          - "Schema-Validierung erfolgreich"
+          - "SLS/SLA-Referenz vorhanden"
+      
+      raci:
+        - rolle: service_owner
+          raci: R
+          kontext: "Liefert Service-Definition, behebt Mängel"
+        - rolle: spm
+          raci: A
+          kontext: "Verantwortet Validierung (als SCM Practice Owner)"
+
+    # -------------------------------------------------------------------------
+    - id: scm_02
+      name: "Service-Steckbrief erstellen"
+      
+      beschreibung: >
+        Ableitung des kundenorientierten Service-Steckbriefs 
+        aus der validierten Service-Definition.
+      
+      eingang:
+        - artefakt: "Service-Definition (validiert)"
+          quelle: "scm_01"
+      
+      umfasst:
+        - "Extraktion der kundenrelevanten Attribute"
+        - "Transformation in kundenverständliche Sprache"
+        - "Ableitung kategorie-spezifischer Hinweise"
+        - "Erstellung Datenschutz-Hinweis"
+        - "Verknüpfung mit Dokumenten (SLS, Handbücher)"
+      
+      ausgang:
+        - artefakt: "Service-Steckbrief (Entwurf)"
+          ziel: "scm_03"
+      
+      raci:
+        - rolle: service_owner
+          raci: R
+          kontext: "Erstellt Steckbrief-Entwurf"
+        - rolle: spm
+          raci: A
+          kontext: "Verantwortet Prozess"
+        - rolle: shm
+          raci: C
+          kontext: "Prüft Kundenverständlichkeit (optional)"
+      
+      hinweis_shm: >
+        Die Einbindung von SHM zur Qualitätssicherung der 
+        Kundenverständlichkeit ist empfohlen, aber im MVP optional.
+
+    # -------------------------------------------------------------------------
+    - id: scm_03
+      name: "Service-Steckbrief freigeben"
+      
+      beschreibung: >
+        Formale Freigabe des Service-Steckbriefs zur Publikation.
+        Die Freigabe-Instanz hängt von der Art der Aufnahme ab.
+      
+      eingang:
+        - artefakt: "Service-Steckbrief (Entwurf)"
+          quelle: "scm_02"
+      
+      umfasst:
+        - "Finale Qualitätsprüfung"
+        - "Prüfung Konsistenz mit Service-Definition"
+        - "Freigabe-Entscheidung"
+      
+      freigabe_logik:
+        beschreibung: >
+          Die Freigabe des Steckbriefs ist Teil der Service-Transition-Freigabe.
+          Bei isolierten Steckbrief-Änderungen gilt die Änderungs-Governance.
+        
+        neuer_service: "SOR (als Teil der Transition-Freigabe)"
+        aenderung_major: "SOR"
+        aenderung_minor: "SPM"
+        aenderung_redaktionell: "SO"
+      
+      ausgang:
+        - artefakt: "Service-Steckbrief (freigegeben)"
+          ziel: "scm_04"
+      
+      raci:
+      - rolle: service_owner
+        raci: R
+        kontext: "Erstellt und pflegt Steckbrief"
+      - rolle: spm
+        raci: A
+        kontext: "Accountable für redaktionelle/minor-Freigaben und Governance-Konsistenz"
+      - rolle: sor
+        raci: A
+        kontext: "Accountable für Freigaben mit größerem Impact (z. B. neue Services, Major-Änderungen)"
+
+    # -------------------------------------------------------------------------
+    - id: scm_04
+      name: "Service-Steckbrief publizieren"
+      
+      beschreibung: >
+        Veröffentlichung des freigegebenen Service-Steckbriefs 
+        im Service-Katalog und ggf. im ITSM-Tool.
+      
+      eingang:
+        - artefakt: "Service-Steckbrief (freigegeben)"
+          quelle: "scm_03"
+      
+      umfasst:
+        - "Eintrag in Service-Katalog"
+        - "Konfiguration Sichtbarkeit (nach Kategorie)"
+        - "Synchronisation mit ITSM-Tool (falls vorhanden)"
+        - "Benachrichtigung relevanter Stakeholder"
+      
+      ausgang:
+        - artefakt: "Service-Steckbrief (publiziert)"
+          ziel: "Service-Katalog"
+      
+      raci:
+        - rolle: spm
+          raci: A/R
+          kontext: "Führt Publikation durch"
+        - rolle: service_owner
+          raci: I
+          kontext: "Wird über Publikation informiert"
+      
+      hinweis_itsm: >
+        Die Synchronisation mit dem ITSM-Tool ist abhängig von der 
+        Tool-Auswahl. Im MVP kann dies ein manueller Schritt sein.
+
+# =============================================================================
+# AKTIVITÄTEN – PHASE: BETRIEB
+# =============================================================================
+
+aktivitaeten_betrieb:
+  beschreibung: >
+    Aktivitäten zur laufenden Pflege des Service-Katalogs.
+
+  aktivitaeten:
+    # -------------------------------------------------------------------------
+    - id: scm_05
+      name: "Katalogänderung bearbeiten"
+      
+      beschreibung: >
+        Bearbeitung von Änderungsbedarfen an Service-Definitionen 
+        und Service-Steckbriefen.
+      
+      ausloeser:
+        - "Service Owner meldet Änderungsbedarf"
+        - "SLS/SLA-Änderung (aus P-02)"
+        - "Organisatorische Änderung (z.B. neuer Service Owner)"
+        - "Feedback von Nutzern/Kunden"
+      
+      umfasst:
+        - "Klassifikation der Änderung (redaktionell/minor/major)"
+        - "Aktualisierung Service-Definition"
+        - "Aktualisierung Service-Steckbrief"
+        - "Durchlaufen des Freigabeprozesses (nach Änderungstyp)"
+        - "Publikation der Änderung"
+      
+      aenderungstypen:
+        - typ: "redaktionell"
+          beispiele:
+            - "Korrektur Tippfehler"
+            - "Aktualisierung Kontaktdaten"
+            - "Formatierungsanpassung"
+          entscheidung: "Service Owner (autonom)"
+          freigabe: "Keine separate Freigabe nötig"
+        
+        - typ: "inhaltlich_minor"
+          beispiele:
+            - "Ergänzung FAQ oder Dokument-Link"
+            - "Klarstellung Leistungsumfang (ohne Änderung)"
+            - "Aktualisierung Voraussetzungen"
+          entscheidung: "Service Owner + SPM (bilateral)"
+          freigabe: "SPM"
+        
+        - typ: "inhaltlich_major"
+          beispiele:
+            - "Änderung Leistungsumfang"
+            - "Änderung Service Levels"
+            - "Änderung Zielgruppe oder Kategorie"
+          entscheidung: "SOR"
+          freigabe: "SOR"
+          hinweis: "Meist gekoppelt an Service-Definition-Änderung"
+      
+      raci:
+        - rolle: service_owner
+          raci: R
+          kontext: "Initiiert und beschreibt Änderungsbedarf"
+        - rolle: spm
+          raci: A
+          kontext: "Accountable für minor/standard-Kataloganpassungen und übergreifende Konsistenz"
+        - rolle: sor
+          raci: A
+          kontext: "Accountable für Major-Änderungen mit Portfolio-/Governance-Relevanz"
+
+    # -------------------------------------------------------------------------
+    - id: scm_06
+      name: "Service aus Katalog entfernen"
+      
+      beschreibung: >
+        Entfernung eines stillgelegten Services aus dem Katalog 
+        (Übergang von "Live" zu "Retired").
+      
+      ausloeser:
+        - "Service-Stilllegung beschlossen (B-03 Service Review)"
+      
+      eingang:
+        - artefakt: "Stilllegungsbeschluss"
+          quelle: "SOR oder Mission Board"
+      
+      umfasst:
+        - "Kennzeichnung als 'stillgelegt' im Katalog"
+        - "Kommunikation an betroffene Nutzer/Ämter"
+        - "Übergangszeit definieren (falls nötig)"
+        - "Endgültige Entfernung aus öffentlichem Katalog"
+        - "Archivierung der Service-Definition"
+      
+      ausgang:
+        - artefakt: "Service-Definition (archiviert)"
+          ziel: "Archiv"
+        - artefakt: "Katalog aktualisiert"
+      
+      raci:
+        - rolle: service_owner
+          raci: R
+          kontext: "Koordiniert Kommunikation"
+        - rolle: spm
+          raci: A
+          kontext: "Verantwortet Katalogaktualisierung"
+        - rolle: shm
+          raci: C
+          kontext: "Unterstützt Kundenkommunikation"
+
+# =============================================================================
+# AKTIVITÄTEN – PHASE: REVIEW
+# =============================================================================
+
+aktivitaeten_review:
+  beschreibung: >
+    Aktivitäten zur regelmäßigen Überprüfung des gesamten Katalogs.
+
+  aktivitaeten:
+    # -------------------------------------------------------------------------
+    - id: scm_07
+      name: "Jährlichen Katalog-Review durchführen"
+      
+      beschreibung: >
+        Systematische Überprüfung aller Service-Definitionen und 
+        Service-Steckbriefe auf Aktualität, Vollständigkeit und Konsistenz.
+      
+      frequenz: "Jährlich"
+      
+      ausloeser:
+        - "Jährlicher Review-Zyklus"
+        - "Wesentliche organisatorische Änderungen"
+        - "Neue Compliance-Anforderungen"
+      
+      umfasst:
+        - "Prüfung aller Service-Definitionen auf Aktualität"
+        - "Prüfung Konsistenz mit tatsächlicher Service-Erbringung"
+        - "Prüfung SLS/SLA-Referenzen aktuell"
+        - "Prüfung Kontaktdaten aktuell"
+        - "Identifikation verwaister Services (kein aktiver SO)"
+        - "Identifikation Inkonsistenzen"
+        - "Ableitung Maßnahmenliste"
+      
+      ausgang:
+        - artefakt: "Katalog-Review-Bericht"
+          ziel: "SOR / Mission Board"
+        - artefakt: "Maßnahmenliste"
+          ziel: "Service Owner (zur Umsetzung)"
+      
+      raci:
+        - rolle: spm
+          raci: A/R
+          kontext: "Führt Review durch, erstellt Bericht"
+        - rolle: service_owner
+          raci: C
+          kontext: "Liefert Informationen zu ihren Services"
+        - rolle: sor
+          raci: I
+          kontext: "Erhält Bericht, entscheidet bei Eskalation"
+
+# =============================================================================
+# GOVERNANCE-ENTSCHEIDUNGEN
+# =============================================================================
+
+governance_entscheidungen:
+
+  - id: "GOV-006"
+    datum: "2025-11-27"
+    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.
+    status: "final"
+
+  - id: "GOV-007"
+    datum: "2025-11-27"
+    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.
+    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.
+    status: "final"
+
+  - id: "GOV-008"
+    datum: "2025-11-27"
+    frage: "Wie wird die Freigabe von Katalogeinträgen gesteuert?"
+    entscheidung: |
+      Dreistufige Governance nach Impact:
+      1. Redaktionelle Änderungen: Service Owner (autonom)
+      2. Inhaltlich-minor: Service Owner + SPM (bilateral)
+      3. Inhaltlich-major / Neuaufnahme: SOR
+      
+      Strukturelle Änderungen (Kategorie-Wechsel, Stilllegung): Mission Board
+    begruendung: >
+      Vermeidet Überlastung des SOR/MB mit Kleinstthemen.
+      Operative Themen werden operativ gelöst.
+      Nur portfolio-relevante Entscheidungen eskalieren.
+    status: "final"
+
+  - id: "GOV-009"
+    datum: "2025-11-27"
+    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.
+    begruendung: >
+      SHM hat die Kompetenz für Kundenperspektive und -sprache.
+      Die Schnittstelle sollte etabliert werden, sobald SHM 
+      operativ ist.
+    status: "draft"
+    abhaengig_von: "Finalisierung SHM-Modul"
+
+  - id: "GOV-010"
+    datum: "2025-11-27"
+    frage: "Wer betreibt den Publikationskanal (Portal/Intranet)?"
+    entscheidung: >
+      SCM (SPM) verantwortet den Inhalt des Katalogs.
+      Der Betrieb des Publikationskanals ist eine separate Verantwortung,
+      die im MVP noch zu klären ist (Webteam, IT-Betrieb, o.ä.).
+    begruendung: >
+      Trennung von Inhalt (SCM) und Betrieb (Technik).
+      Vermeidet, dass SCM zur Portal-Betriebs-Instanz wird.
+    status: "draft"
+    offene_frage: "Wer ist konkret für Portal-Betrieb zuständig?"
+
+# =============================================================================
+# METRIKEN
+# =============================================================================
+
+metriken:
+
+  prozess_metriken:
+    - name: "Katalog-Abdeckung"
+      beschreibung: >-
+        Anteil der Live-Services, für die ein freigegebener Service-Steckbrief 
+        im Service-Katalog publiziert ist.
+      ziel: "100%"
+      messung: "Anzahl publizierte Steckbriefe / Anzahl Services mit Status 'Live'"
+    
+    - name: "Steckbrief-Aktualität"
+      beschreibung: "Anteil der Steckbriefe, die im letzten Jahr geprüft wurden"
+      ziel: "100%"
+      messung: "Anzahl Steckbriefe mit Review < 12 Monate / Gesamtanzahl"
+    
+    - name: "Durchlaufzeit Katalogaufnahme"
+      beschreibung: "Zeit von Transition-Start bis Katalogpublikation"
+      ziel: "< 10 Arbeitstage"
+      messung: "Durchschnitt über alle Neuaufnahmen"
+
+  qualitaets_metriken:
+    - name: "Schema-Konformität"
+      beschreibung: "Anteil der Service-Definitionen ohne Validierungsfehler"
+      ziel: "100%"
+    
+    - name: "Verständlichkeits-Score"
+      beschreibung: "Bewertung der Steckbriefe durch SHM/Nutzer"
+      ziel: "Definition ausstehend"
+      hinweis: "Einführung nach SHM-Operationalisierung"
+
+# =============================================================================
+# TOOLING-ANFORDERUNGEN
+# =============================================================================
+
+tooling:
+
+  service_katalog_ablage:
+    beschreibung: >
+      Speicherort für Service-Definitionen und Service-Steckbriefe.
+      Im MVP kann dies ein strukturiertes Verzeichnis sein.
+    
+    anforderungen:
+      - "Versionierung"
+      - "Zugriffssteuerung (SO kann eigene Services bearbeiten)"
+      - "Such- und Filterfunktion"
+    
+    optionen:
+      - "Confluence/Wiki"
+      - "SharePoint"
+      - "Git-Repository"
+      - "Dediziertes ITSM-/CMDB-Tool"
+    
+    mvp_loesung: "TBD"
+
+  itsm_integration:
+    beschreibung: >
+      Schnittstelle zum ITSM-Tool für den Request-Katalog.
+    
+    anforderungen:
+      - "Service-ID als eindeutiger Schlüssel"
+      - "Unidirektionale Synchronisation (SCM → ITSM)"
+      - "Kategorie-basierte Sichtbarkeitssteuerung"
+    
+    status: "Tool-Auswahl ausstehend"
+    
+    hinweis: >
+      Im MVP kann die Synchronisation manuell erfolgen.
+      Eine automatisierte Schnittstelle ist Ziel, aber nicht MVP-kritisch.
+
+  cmdb_integration:
+    beschreibung: >
+      Schnittstelle zur CMDB für Abhängigkeitsinformationen.
+    
+    status: "Placeholder"
+    
+    hinweis: >
+      CMDB ist nicht Teil des MVP. Abhängigkeiten werden manuell 
+      in der Service-Definition gepflegt. Langfristig sollte eine 
+      bidirektionale Synchronisation etabliert werden.
+
+# =============================================================================
+# OFFENE PUNKTE
+# =============================================================================
+
+offene_punkte:
+
+  - id: "OPEN-P01-001"
+    beschreibung: "Template Service-Definition erstellen (Markdown)"
+    prioritaet: "hoch"
+    ziel_ordner: "02.6_arbeitsmaterialien"
+    abhaengig_von: "Finalisierung Schema"
+  
+  - id: "OPEN-P01-002"
+    beschreibung: "Template Service-Steckbrief erstellen (Markdown/HTML)"
+    prioritaet: "hoch"
+    ziel_ordner: "02.6_arbeitsmaterialien"
+    abhaengig_von: "Finalisierung Schema"
+  
+  - id: "OPEN-P01-003"
+    beschreibung: "Checkliste Katalog-Review erstellen"
+    prioritaet: "mittel"
+    ziel_ordner: "02.6_arbeitsmaterialien"
+  
+  - id: "OPEN-P01-004"
+    beschreibung: "Klärung Publikationskanal und Betriebsverantwortung"
+    prioritaet: "mittel"
+    status: "Abstimmung mit IT-Betrieb/Webteam nötig"
+  
+  - id: "OPEN-P01-005"
+    beschreibung: "SHM-Einbindung operationalisieren"
+    prioritaet: "niedrig"
+    abhaengig_von: "Finalisierung SHM-Modul"
+  
+  - id: "OPEN-P01-006"
+    beschreibung: "ITSM-Tool-Integration spezifizieren"
+    prioritaet: "niedrig"
+    abhaengig_von: "Tool-Auswahl"
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+  - version: "0.4"
+    datum: "2026-03-09"
+    aenderung: |
+      - Kategorie I (Interne Services) in kategorien_logik und Katalog-Ausschlussregel ergänzt
+      - Expliziter Hinweis: Katalog enthält ausschließlich Kategorie A, B, C
+      - nicht_enthalten-Liste aktualisiert (Verweis auf GOV-SPM-I-001, GOV-SPM-I-003)
+    autor: "DIGITOM-Projekt"
+    referenz: "PENDING-SPM-001, DC-001, DC-003"
+
+  - version: "0.3"
+    datum: "2026-01-31"
+    aenderung: "Metrik 'Katalog-Abdeckung' präzisiert: Bezug auf Steckbriefe statt Definitionen"
+    autor: "DIGITOM-Projekt"
+    referenz: "Begriffskonsistenz Portfolio/Katalog vs. Definition/Steckbrief"
+
+  - version: "0.2"
+    datum: "2026-01-30"
+    aenderung: "Anpassung an Service-Lifecycle 3.0: Phasennamen (betrieb → operation)"
+    autor: "DIGITOM-Projekt"
+    referenz: "CHANGELOG_service-lifecycle-blueprint.md v3.0"
+
+  - version: "0.1"
+    datum: "2025-11-27"
+    aenderung: "Initiale Practice-Konzeption"
+    autor: "DIGITOM-Projekt"

#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-level-management.yaml

@@ -0,0 +1,832 @@
+# =============================================================================
+# PRACTICE: SERVICE LEVEL MANAGEMENT
+# =============================================================================
+
+metadata:
+  id: "P-02"
+  name: "Service Level Management"
+  version: "0.2"
+  status: "draft"
+  erstellt: "2025-11-26"
+  aktualisiert: "2026-01-30"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+  dokumenttyp: "practice-konzept"
+  
+  funktion:
+    id: "SPM"
+    name: "Service-Portfolio-Management"
+  
+  taxonomie_referenz: "00_meta/digitom_taxonomie.yaml"
+  
+  beschreibung: >
+    Etabliert ein gemeinsames Verständnis von Servicequalität zwischen 
+    DIGIT und seinen Kunden. Umfasst Definition, Vereinbarung, Überwachung 
+    und Review von Service Levels – differenziert nach Service-Kategorien.
+  
+  itil4_referenz: "Service Level Management Practice"
+  
+  lifecycle_phasen:
+    - design
+    - transition
+    - operation
+    - review
+  
+  schnittstellen:
+    intern:
+      - modul: "P-01 Service Catalog Management"
+        art: "liefert an"
+        beschreibung: "SLS wird im Service-Katalog publiziert"
+      
+      - modul: "P-07 Monitoring & Event Management"
+        art: "erhält von"
+        beschreibung: "Messdaten für Service-Level-Überwachung"
+      
+      - modul: "B-02 Service Betrieb"
+        art: "bidirektional"
+        beschreibung: "Qualitätsbericht als Input, SLA-Ziele als Vorgabe"
+      
+      - modul: "B-03 Service Review"
+        art: "bidirektional"
+        beschreibung: "Interner Review als Vorbereitung für externen SLA-Review"
+    
+    extern:
+      - partner: "Kundenvertretung Basisservices"
+        kontext: "SLA-Partner für Kategorie A"
+        zusammensetzung: "Amtsleitungen oder delegierte Vertreter"
+      
+      - partner: "Kundenvertretungen (servicespezifisch)"
+        kontext: "SLA-Partner für Kategorie B"
+        zusammensetzung: "Amtsleitungen nutzender Ämter oder delegierte Vertreter"
+      
+      - partner: "Amtsleitungen (bilateral)"
+        kontext: "SLA-Partner für Kategorie C"
+
+# =============================================================================
+# KERNKONZEPTE
+# =============================================================================
+
+kernkonzepte:
+
+  service_kategorien:
+    beschreibung: >
+      Das Service-Portfolio wird in drei Kategorien stratifiziert, 
+      die unterschiedliche SLA-Governance-Modelle erfordern.
+    
+    kategorien:
+      - id: "A"
+        name: "Basis-Services"
+        charakteristik: "Flächendeckend, umlagefinanziert, nicht abwählbar"
+        sla_partner: "Kundenvertretung Basisservices"
+        sla_partner_zusammensetzung: |
+          - Pflichtvertreter: Amtsleitungen strategischer Querschnittsämter
+          - Weitere Vertreter: Amtsleitungen oder delegierte Vertreter 
+            (Option: Rotation/Wahl)
+          - Mitglieder müssen Entscheidungsbefugnis haben oder diese 
+            dokumentiert delegiert bekommen haben
+        sla_typ: "Zentrales SLA + SLS je Service"
+        beispiele: "Arbeitsplatz, E-Mail, Netzwerk, zentrale Plattformen"
+      
+      - id: "B"
+        name: "Erweiterte Services"
+        charakteristik: "Optional, bedarfsgesteuert, erweiternd"
+        sla_partner: "Kundenvertretung [Servicename]"
+        sla_partner_zusammensetzung: |
+          - Mitglieder: Amtsleitungen der nutzenden Ämter oder deren 
+            delegierte Vertreter mit dokumentierter Entscheidungsbefugnis
+          - Jedes nutzende Amt hat Anspruch auf Vertretung
+        sla_typ: "SLA je Service mit Kundenvertretung + SLS"
+        beispiele: "DMS-Module, CMS, Workflow-Systeme"
+      
+      - id: "C"
+        name: "Spezial-Services"
+        charakteristik: "Individuell, hochgradig domänenspezifisch"
+        sla_partner: "Amtsleitung des nutzenden Amtes"
+        sla_partner_zusammensetzung: |
+          - Amtsleiter:in oder delegierte Person mit dokumentierter
+            Entscheidungsbefugnis
+        sla_typ: "Bilaterales SLA (ohne separates SLS)"
+        beispiele: "Kassensysteme, Fachverfahren, Speziallösungen"
+
+      - id: "I"
+        name: "Interne Services"
+        charakteristik: "Intern, kein direkter Kundenbezug, nicht im Katalog"
+        sla_partner: "Keine externe Kundenvertretung"
+        sla_partner_zusammensetzung: |
+          - Interne Vereinbarung zwischen DIGIT-Einheiten
+          - Service Owner des Internen Services + nutzende Einheit(en)
+        sla_typ: "OLA (Operational Level Agreement)"
+        beispiele: "Active Directory, Netzwerk-Backbone, zentrale Datenbanken"
+        governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-002"
+
+    governance:
+      verantwortlich: "Service-Portfolio-Manager (SLM Practice Owner)"
+      entscheidung: "Mission Board (finale Eskalations- und Portfoliosteuerung)"
+      referenz: "GOV-001"
+
+  dokument_typen:
+
+    ola:
+      name: "Operational Level Agreement (OLA)"
+      beschreibung: |
+        Interne Leistungsvereinbarung zwischen DIGIT-Einheiten für Interne
+        Services (Kategorie I). Funktionales Äquivalent eines SLA, jedoch
+        ohne externen Kundenbezug. Das OLA definiert Leistungsparameter,
+        Qualitätsziele und Verantwortlichkeiten zwischen internen
+        Betriebseinheiten.
+
+      abgrenzung_sla: |
+        - SLA: Vereinbarung zwischen DIGIT und externem Kunden-Gremium/Amt
+          (Kategorie A, B, C). Wird im Rahmen des Kundenforums reviewed.
+        - OLA: Vereinbarung zwischen DIGIT-internen Einheiten (Kategorie I).
+          Kein externer Kundenbezug, keine Katalog-Publikation.
+
+      inhalte:
+        - "Leistungsbeschreibung des Internen Services"
+        - "Qualitätsziele (Verfügbarkeit, Performance)"
+        - "Verantwortlichkeiten (liefernde und nutzende Einheit)"
+        - "Eskalationswege (intern)"
+        - "Review-Mechanismus"
+        - "Laufzeit und Änderungsverfahren"
+
+      pilotphase_hinweis: |
+        Während der Pilotphase bleibt das OLA-Feld in der Service-Definition
+        für Interne Services leer. Die Befüllung erfolgt nach Abschluss der
+        Pilotphase auf Basis operativer Erfahrungen. Die Begründung ist
+        einmalig in der Pilot-Scope-Dokumentation festgehalten.
+
+      governance_referenz: "GOV-SPM-I-002"
+
+    sla:
+      name: "Service Level Agreement"
+      beschreibung: >
+        Governance-Instrument zwischen DIGIT und Kunden-Gremium/Usergroup.
+        Definiert Rahmen, Verantwortlichkeiten, Eskalationswege, 
+        Review-Mechanismen. Kein Vertrag im juristischen Sinne, 
+        sondern formalisiertes Leistungsversprechen.
+      
+      inhalte:
+        - "Vertragsparteien und Geltungsbereich"
+        - "Referenzierte Services und SLS"
+        - "Rollen und Verantwortlichkeiten"
+        - "Kommunikations- und Eskalationswege"
+        - "Review- und Änderungsverfahren"
+        - "Laufzeit und Kündigungslogik"
+    
+    sls:
+      name: "Service Level Specification"
+      beschreibung: >
+        Öffentliche, servicebezogene Leistungsbeschreibung. 
+        Gilt für alle Nutzer des Services gleichermaßen.
+        Wird im Service-Katalog publiziert.
+        Bei Kategorie C kann die SLS in das bilaterale SLA integriert 
+        sein; in diesem Fall verweist der Service-Katalog auf das SLA 
+        als Quelle der Service-Levels.
+      
+      inhalte:
+        - "Service-Beschreibung und Leistungsumfang"
+        - "Zielgruppe und Voraussetzungen"
+        - "Verfügbarkeitszeiten und Service-Fenster"
+        - "Performance-Ziele (Reaktions-, Lösungszeiten)"
+        - "Qualitätsmetriken und Messmethodik"
+        - "Ausnahmen und Einschränkungen"
+        - "Support-Kanäle und Kontaktwege"
+      
+      template: "02.5_arbeitsmaterialien/template_sls.md"
+
+  kundenvertretung:
+    beschreibung: >
+      Formalisierte Vertretung der Kundenseite für SLA-Vereinbarungen.
+      Keine Anwendergruppe, sondern Entscheidungsgremium.
+    
+    grundsatz: |
+      Mitglieder der Kundenvertretung müssen Entscheidungsbefugnis 
+      für ihr Amt haben oder diese dokumentiert delegiert bekommen haben.
+    
+    berechtigte_personen:
+      primaer: "Amtsleiter:in"
+      alternativ: 
+        - "Abteilungsleiter:in (mit Delegation)"
+        - "Verwaltungsleiter:in des Amtes (mit Delegation)"
+        - "Andere Person mit dokumentierter Entscheidungsbefugnis"
+    
+    delegation:
+      anforderung: "Schriftliche Delegation durch Amtsleitung"
+      inhalt:
+        - "Name der delegierten Person"
+        - "Umfang der Entscheidungsbefugnis"
+        - "Gültigkeitszeitraum"
+      dokumentation: "Hinterlegung bei DIGIT (SPM)"
+    
+    typen:
+      - typ: "Kundenvertretung Basisservices"
+        kategorie: "A"
+        zusammensetzung:
+          pflicht: "Strategische Querschnittsämter (zu definieren)"
+          weitere: "Rotation oder Wahl aus Fachämtern"
+        entscheidungsmodus: "Konsens, bei Dissens qualifizierte Mehrheit"
+
+      - typ: "Kundenvertretung [Servicename]"
+        kategorie: "B"
+        zusammensetzung: "Alle nutzenden Ämter (oder deren Vertreter)"
+        entscheidungsmodus: "Qualifizierte Mehrheit"
+
+    integration_mit_shm:
+      beschreibung: |
+        Die Kundenvertretungen sind mit den Stakeholder-Management-Formaten
+        zu einem integrierten "Kundenforum"-Konzept zusammengeführt.
+
+        Das Kundenforum kombiniert:
+        - SLA-Review und Service-Kommunikation (SLM-Verantwortung)
+        - Beziehungspflege, Feedback und Bedarfssammlung (SHM-Verantwortung)
+
+        Die Moderation erfolgt gemeinsam durch Service Owner und
+        Stakeholder-Manager.
+
+      governance_referenz: "GOV-012"
+
+      verweis: |
+        Details zur Ausgestaltung siehe:
+        #03_stakeholder-management/#03.3_konzepte/shm_engagement-framework.yaml
+        Abschnitt: kollektive_formate.integriertes_kundenforum
+
+# =============================================================================
+# AKTIVITÄTEN – PHASE: TRANSITION
+# =============================================================================
+
+aktivitaeten_transition:
+
+  - id: slm_01
+    name: "Service-Level-Anforderungen erheben"
+    
+    beschreibung: >
+      Systematische Erfassung der Qualitätserwartungen aus Kundensicht 
+      als Grundlage für die SLS-Definition.
+    
+    ausloeser:
+      - "Neuer Service in Transition-Phase"
+      - "Wesentliche Service-Änderung (aus Demand)"
+    
+    umfasst:
+      - "Analyse der Anforderungen aus Service-Design/Demand"
+      - "Erhebung von Kundenerwartungen (Utility, Warranty, Experience)"
+      - "Abgleich mit bestehenden SLS-Standards (falls vorhanden)"
+      - "Identifikation kategorie-spezifischer Anforderungen"
+      - "Dokumentation der Anforderungen"
+    
+    eingang:
+      - artefakt: "Service-Design-Dokumentation"
+        quelle: "Service Entwicklung"
+      - artefakt: "Demand-Spezifikation"
+        quelle: "DPM"
+    
+    ausgang:
+      - artefakt: "Service-Level-Anforderungen (dokumentiert)"
+        ziel: "slm_02"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+        kontext: "Verantwortet die Anforderungserhebung"
+      - rolle: stakeholder_manager
+        raci: R
+        kontext: "Führt Erhebung mit Kunden durch"
+      - rolle: spm
+        raci: C
+        kontext: "Prüft Portfolio-Konsistenz"
+
+  # ---------------------------------------------------------------------------
+  - id: slm_02
+    name: "Service Level Specification (SLS) erstellen"
+    
+    beschreibung: >
+      Übersetzung der Anforderungen in eine formale, messbare 
+      Leistungsbeschreibung.
+    
+    umfasst:
+      - "Definition der Service Levels (Verfügbarkeit, Performance, etc.)"
+      - "Festlegung der Metriken und Messmethodik"
+      - "Abstimmung mit Betriebsteam zur Messbarkeit"
+      - "Erstellung des SLS-Dokuments nach Template"
+      - "Interne Qualitätssicherung"
+    
+    eingang:
+      - artefakt: "Service-Level-Anforderungen"
+        quelle: "slm_01"
+    
+    ausgang:
+      - artefakt: "SLS-Entwurf"
+        ziel: "slm_03"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+        kontext: "Verantwortet SLS-Inhalt"
+      - rolle: betriebsteam
+        raci: C
+        kontext: "Validiert technische Messbarkeit"
+      - rolle: spm
+        raci: C
+        kontext: "Prüft Konsistenz mit Portfolio-Standards"
+    
+    hinweis: >
+      Bei Kategorie C entfällt ein separates SLS-Dokument – die Service 
+      Levels werden direkt im bilateralen SLA definiert. Für Transparenz 
+      im Service-Katalog wird in diesem Fall auf das SLA als Quelle der 
+      Service-Levels verwiesen.
+
+  # ---------------------------------------------------------------------------
+  - id: slm_03
+    name: "SLA abstimmen und fixieren"
+    
+    beschreibung: >
+      Abstimmung des SLA mit dem relevanten Kunden-Gremium 
+      entsprechend der Service-Kategorie.
+    
+    umfasst:
+      - "Vorbereitung der SLA-Vorlage (kategorie-spezifisch)"
+      - "Vorstellung und Diskussion mit SLA-Partner"
+      - "Abstimmung bei Abweichungen von Standard-Levels"
+      - "Dokumentation von Sondervereinbarungen"
+      - "Einigung auf finale Fassung"
+    
+    differenzierung_nach_kategorie:
+      kategorie_a:
+        sla_partner: "Kundenvertretung Basisservices"
+        teilnehmer: "Amtsleitungen oder delegierte Vertreter mit Entscheidungsbefugnis"
+        modus: "Abstimmung im Gremium, Konsensprinzip"
+      kategorie_b:
+        sla_partner: "Kundenvertretung [Servicename]"
+        teilnehmer: "Amtsleitungen der nutzenden Ämter oder delegierte Vertreter"
+        modus: "Abstimmung in Kundenvertretung, qualifizierte Mehrheit"
+      kategorie_c:
+        sla_partner: "Amtsleitung des nutzenden Amtes"
+        teilnehmer: "Amtsleiter:in oder delegierte Person"
+        modus: "Bilaterale Verhandlung"
+    
+    eingang:
+      - artefakt: "SLS-Entwurf"
+        quelle: "slm_02"
+    
+    ausgang:
+      - artefakt: "Abgestimmter SLA-Entwurf"
+        ziel: "slm_04"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: R
+        kontext: "Führt Abstimmung, moderiert Usergroup"
+      - rolle: stakeholder_manager
+        raci: C
+        kontext: "Unterstützt bei Kundeninteraktion"
+      - rolle: spm
+        raci: A
+        kontext: "Verantwortet Governance-Konformität"
+
+  # ---------------------------------------------------------------------------
+  - id: slm_04
+    name: "SLA genehmigen und aktivieren"
+    
+    beschreibung: >
+      Formale Freigabe des SLA und Aktivierung der Service Levels 
+      für den produktiven Betrieb.
+    
+    umfasst:
+      - "Prüfung auf Vollständigkeit und Konsistenz"
+      - "Interne Freigabe (SOR)"
+      - "Unterzeichnung durch SLA-Partner"
+      - "Publikation der SLS im Service-Katalog"
+      - "Aktivierung des Monitorings"
+      - "Kommunikation an Stakeholder"
+    
+    governance:
+      standard_sla: "SOR-Freigabe (Accountable für Standard-SLAs)"
+      abweichung_von_standard: "Mission Board-Freigabe (Accountable für Major-/Abweichungs-SLAs)"
+      referenz: "GOV-001"
+    
+    eingang:
+      - artefakt: "Abgestimmter SLA-Entwurf"
+        quelle: "slm_03"
+    
+    ausgang:
+      - artefakt: "Aktives SLA"
+        ziel: "Service Betrieb"
+      - artefakt: "Publizierte SLS"
+        ziel: "Service-Katalog"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: R
+        kontext: "Bereitet Freigabe vor"
+      - rolle: sor
+        raci: A
+        kontext: "Genehmigt Standard-SLAs (standard_sla)"
+      - rolle: mission_board
+        raci: A
+        kontext: "Genehmigt Abweichungen/Major-SLAs (abweichung_von_standard)"
+      - rolle: spm
+        raci: R
+        kontext: "Koordiniert Freigabeprozess"
+
+# =============================================================================
+# AKTIVITÄTEN – PHASE: BETRIEB
+# =============================================================================
+
+aktivitaeten_betrieb:
+
+  - id: slm_05
+    name: "Service Levels messen und überwachen"
+    
+    beschreibung: >
+      Kontinuierliche Erfassung der vereinbarten Metriken und 
+      Vergleich mit den SLA-Zielen.
+    
+    umfasst:
+      - "Automatisierte Erfassung technischer Metriken"
+      - "Erhebung von Experience-Daten (wo definiert)"
+      - "Aggregation und Aufbereitung der Messwerte"
+      - "Abgleich mit SLA-Zielen"
+      - "Identifikation von Abweichungen und Trends"
+    
+    frequenz: "Kontinuierlich (automatisiert) + periodische Auswertung"
+    
+    schnittstelle:
+      - modul: "P-07 Monitoring & Event Management"
+        beschreibung: "Liefert technische Messdaten"
+    
+    mitarbeit:
+      - rolle: betriebsteam
+        raci: R
+        kontext: "Betreibt Monitoring, liefert Daten"
+      - rolle: service_owner
+        raci: A
+        kontext: "Verantwortet Interpretation"
+      - rolle: spm
+        raci: I
+        kontext: "Erhält aggregierte Daten für Portfolio"
+
+  # ---------------------------------------------------------------------------
+  - id: slm_06
+    name: "SLA-Performance reporten"
+    
+    beschreibung: >
+      Periodische Aufbereitung der Messergebnisse für interne 
+      und externe Stakeholder.
+    
+    umfasst:
+      - "Erstellung des Service-Qualitätsberichts"
+      - "Visualisierung der SLA-Zielerreichung"
+      - "Kommentierung von Abweichungen"
+      - "Ableitung von Handlungsempfehlungen"
+      - "Bereitstellung für Review-Prozesse"
+    
+    frequenz: "Monatlich (intern), Quartalsweise (extern)"
+    
+    report_typen:
+      - typ: "Interner Qualitätsbericht"
+        zielgruppe: "SOR, Service Owner"
+        frequenz: "Monatlich"
+      - typ: "Kunden-Report"
+        zielgruppe: "Usergroup, Kunden-Gremium"
+        frequenz: "Quartalsweise oder nach SLA-Vereinbarung"
+    
+    eingang:
+      - artefakt: "Monitoring-Daten"
+        quelle: "slm_05"
+    
+    ausgang:
+      - artefakt: "Service-Qualitätsbericht"
+        ziel: "Service Review (B-03)"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+        kontext: "Verantwortet Bericht und Interpretation"
+      - rolle: betriebsteam
+        raci: R
+        kontext: "Liefert Daten, erstellt technischen Teil"
+      - rolle: spm
+        raci: C
+        kontext: "Prüft Portfolio-Konsistenz"
+    
+    hinweis: >
+      Verknüpfung mit op_06 (Service-Qualitätsbericht) im Blueprint.
+
+  # ---------------------------------------------------------------------------
+  - id: slm_07
+    name: "SLA-Verletzung eskalieren"
+    
+    beschreibung: >
+      Definierter Umgang mit systematischen oder kritischen 
+      Abweichungen von vereinbarten Service Levels.
+    
+    ausloeser:
+      - "Systematische SLA-Verletzung (>X Monate)"
+      - "Kritische Einzelverletzung mit hohem Impact"
+      - "Kundenbeschwerde zu Servicequalität"
+    
+    umfasst:
+      - "Identifikation und Dokumentation der Verletzung"
+      - "Ursachenanalyse auf Service-Level (Abgleich mit bestehendem Problem-Management)"
+      - "Bewertung der Kundenauswirkung"
+      - "Eskalation gemäß Governance"
+      - "Definition von Sofortmaßnahmen"
+    
+    eskalationspfad:
+      stufe_1:
+        instanz: "Service Owner"
+        aktion: "Analyse, Sofortmaßnahmen"
+      stufe_2:
+        instanz: "SOR"
+        aktion: "Ressourcenentscheidung, Priorisierung"
+      stufe_3:
+        instanz: "Mission Board"
+        aktion: "Verpflichtende Verbesserungsmaßnahmen"
+      stufe_4:
+        instanz: "Amtsleitung → OB-Ebene"
+        aktion: "Politische Eskalation (ultima ratio)"
+    
+    governance_referenz: "GOV-002"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: R
+        kontext: "Identifiziert, analysiert, eskaliert"
+      - rolle: sor
+        raci: A
+        kontext: "Entscheidet über Maßnahmen"
+      - rolle: mission_board
+        raci: A
+        kontext: "Bei Eskalation Stufe 3"
+      - rolle: spm
+        raci: C
+        kontext: "Dokumentiert, tracked Maßnahmen"
+
+# =============================================================================
+# AKTIVITÄTEN – PHASE: REVIEW
+# =============================================================================
+
+aktivitaeten_review:
+
+  - id: slm_08
+    name: "Internen SLA-Review durchführen"
+    
+    beschreibung: >
+      DIGIT-interne Bewertung der SLA-Performance als Vorbereitung 
+      für den externen Review mit Kunden.
+    
+    umfasst:
+      - "Analyse der SLA-Zielerreichung über Review-Periode"
+      - "Bewertung von Trends und Mustern"
+      - "Identifikation von Anpassungsbedarf"
+      - "Vorbereitung von Änderungsvorschlägen"
+      - "Abstimmung in der SOR"
+    
+    frequenz: "Jährlich (oder nach SLA-Vereinbarung)"
+    
+    verknuepfung:
+      blueprint_aktivitaet: "rv_02 Service Performance & Improvement Review"
+      beschreibung: >
+        Der interne SLA-Review ist Teil des Service Reviews im Blueprint.
+        SLA-spezifische Aspekte werden hier detailliert.
+    
+    eingang:
+      - artefakt: "Service-Qualitätsberichte (kumuliert)"
+        quelle: "slm_06"
+      - artefakt: "Eskalations-Dokumentation"
+        quelle: "slm_07"
+    
+    ausgang:
+      - artefakt: "Interner Review-Bericht mit Änderungsvorschlägen"
+        ziel: "slm_09"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: A
+        kontext: "Verantwortet Review"
+      - rolle: sor
+        raci: C
+        kontext: "Validiert Bewertung und Vorschläge"
+      - rolle: spm
+        raci: R
+        kontext: "Konsolidiert Portfolio-Sicht"
+    
+    governance_referenz: "GOV-003"
+
+  # ---------------------------------------------------------------------------
+  - id: slm_09
+    name: "Externen SLA-Review mit Kunden durchführen"
+
+    beschreibung: >
+      Gemeinsamer Review mit dem SLA-Partner zur Validierung
+      der Servicequalität und Abstimmung von Anpassungen.
+
+    umfasst:
+      - "Präsentation der SLA-Performance"
+      - "Erhebung von Kundenfeedback"
+      - "Diskussion von Verbesserungsvorschlägen"
+      - "Abstimmung von SLA/SLS-Änderungen"
+      - "Dokumentation der Ergebnisse"
+
+    frequenz: "Jährlich (im Rahmen der Pilotierung zu validieren)"
+
+    integration_kundenforum: |
+      Diese Aktivität wird im Rahmen des integrierten Kundenforums
+      durchgeführt. Das Kundenforum kombiniert den SLA-Review mit
+      SHM-Themen (Beziehungspflege, Bedarfssammlung).
+
+      Für Kategorie A: Kundenforum Basisservices (jährlich)
+      Für Kategorie B: Kundenforum [Servicename] (jährlich)
+      Für Kategorie C: Bilaterales Format (unverändert)
+    
+    differenzierung_nach_kategorie:
+      kategorie_a:
+        format: "Review-Meeting der Kundenvertretung Basisservices"
+        teilnehmer: "Amtsleitungen oder delegierte Vertreter"
+        frequenz: "1x jährlich"
+      kategorie_b:
+        format: "Review-Meeting der Kundenvertretung [Servicename]"
+        teilnehmer: "Amtsleitungen der nutzenden Ämter oder delegierte Vertreter"
+        frequenz: "1x jährlich"
+      kategorie_c:
+        format: "Bilaterales Review-Gespräch"
+        teilnehmer: "Amtsleitung oder delegierte Person"
+        frequenz: "1x jährlich oder nach Bedarf"
+    
+    eingang:
+      - artefakt: "Interner Review-Bericht"
+        quelle: "slm_08"
+    
+    ausgang:
+      - artefakt: "Review-Protokoll mit vereinbarten Änderungen"
+        ziel: "slm_10"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: R
+        kontext: "Führt Review durch, moderiert"
+      - rolle: stakeholder_manager
+        raci: C
+        kontext: "Unterstützt Kundeninteraktion"
+      - rolle: spm
+        raci: A
+        kontext: "Verantwortet Governance-Konformität"
+    
+    governance_referenz: "GOV-003"
+    
+    hinweis: >
+      Diese Aktivität muss noch im Blueprint (B-03 service_review.yaml) 
+      als neue Aktivität ergänzt werden.
+
+  # ---------------------------------------------------------------------------
+  - id: slm_10
+    name: "SLA-Änderung durchführen"
+    
+    beschreibung: >
+      Formaler Prozess zur Anpassung bestehender SLAs und SLS 
+      basierend auf Review-Ergebnissen.
+    
+    ausloeser:
+      - "Review-Ergebnis mit Änderungsbedarf"
+      - "Wesentliche Service-Änderung"
+      - "Änderung der Kundenanforderungen"
+      - "Änderung der Service-Kategorie"
+    
+    umfasst:
+      - "Bewertung des Änderungsumfangs"
+      - "Erstellung der Änderungsdokumentation"
+      - "Genehmigung gemäß Governance"
+      - "Aktualisierung von SLA und SLS"
+      - "Kommunikation an Stakeholder"
+      - "Anpassung des Monitorings"
+    
+    klassifizierung:
+      minor:
+        beschreibung: "Redaktionelle Anpassungen, Klarstellungen"
+        genehmigung: "Service Owner"
+      standard:
+        beschreibung: "Anpassung innerhalb der Standard-Level-Bandbreite"
+        genehmigung: "SOR"
+      major:
+        beschreibung: "Abweichung von Standards, neue Service Levels"
+        genehmigung: "Mission Board"
+    
+    mitarbeit:
+      - rolle: service_owner
+        raci: R
+        kontext: "Erstellt Änderung, führt durch"
+      - rolle: sor
+        raci: A
+        kontext: "Genehmigt Standard-Änderungen"
+      - rolle: mission_board
+        raci: A
+        kontext: "Genehmigt Major-Änderungen"
+      - rolle: spm
+        raci: C
+        kontext: "Prüft Portfolio-Konsistenz"
+
+# =============================================================================
+# GOVERNANCE-REFERENZEN
+# =============================================================================
+
+governance_referenzen:
+  
+  - id: "GOV-001"
+    frage: "Wer entscheidet Service-Kategorisierung?"
+    kurzfassung: "R: SPM, A: Mission Board"
+  
+  - id: "GOV-002"
+    frage: "Eskalation bei SLA-Verletzung?"
+    kurzfassung: "SO → SOR → Mission Board → AL/OB"
+  
+  - id: "GOV-003"
+    frage: "Interner vs. externer Review?"
+    kurzfassung: "Zwei-Stufen-Logik: Intern (SOR) vor Extern (Kunde)"
+  
+  - id: "GOV-004"
+    frage: "SLA-Partner Kategorie A?"
+    kurzfassung: "Kundengremium Basisversorgung (Anforderung definiert)"
+
+  - id: "GOV-005"
+    frage: "Wer darf als SLA-Partner agieren?"
+    kurzfassung: "Amtsleitungen oder delegierte Vertreter mit dokumentierter Entscheidungsbefugnis"
+
+# =============================================================================
+# METRIKEN UND ERFOLGSKRITERIEN
+# =============================================================================
+
+metriken:
+
+  prozess_metriken:
+    - name: "SLA-Abdeckung"
+      beschreibung: "Anteil Services mit aktivem SLA/SLS"
+      ziel: "100% für Kategorie A und B"
+    
+    - name: "SLA-Review-Durchführung"
+      beschreibung: "Anteil durchgeführter Reviews im Zyklus"
+      ziel: "100%"
+    
+    - name: "Zeit bis SLA-Aktivierung"
+      beschreibung: "Durchlaufzeit von Transition-Start bis aktives SLA"
+      ziel: "Definition ausstehend"
+
+  ergebnis_metriken:
+    - name: "SLA-Zielerreichung"
+      beschreibung: "Anteil eingehaltener Service Levels"
+      ziel: "Definition je Service"
+    
+    - name: "Kundenzufriedenheit"
+      beschreibung: "Bewertung der Servicequalität durch Kunden"
+      ziel: "Definition ausstehend"
+
+# =============================================================================
+# OFFENE PUNKTE
+# =============================================================================
+
+offene_punkte:
+
+  - id: "OPEN-P02-001"
+    beschreibung: "Blueprint-Ergänzung: Aktivität 'Externer SLA-Review' in rv_xx"
+    prioritaet: "hoch"
+    abhaengig_von: "Finalisierung P-02"
+  
+  - id: "OPEN-P02-002"
+    beschreibung: "Template-Entwicklung: SLS, SLA Kat. A/B/C"
+    prioritaet: "mittel"
+    ziel_ordner: "02.5_arbeitsmaterialien"
+  
+  - id: "OPEN-P02-003"
+    beschreibung: "Metriken-Katalog: Standard-Service-Levels je Kategorie"
+    prioritaet: "mittel"
+  
+  - id: "OPEN-P02-004"
+    beschreibung: "Klärung: Konkrete Besetzung Kundengremium Basisversorgung"
+    prioritaet: "niedrig"
+    status: "Anforderung definiert, Abstimmung mit Verwaltung ausstehend"
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+  - version: "0.3"
+    datum: "2026-03-09"
+    aenderung: |
+      - OLA als neuer Dokumententyp unter dokument_typen ergänzt
+      - Abgrenzung SLA (extern) vs. OLA (intern) dokumentiert
+      - Kategorie I (Interne Services) in service_kategorien aufgenommen
+      - Pilotphase-Hinweis: OLA-Felder bleiben zunächst leer
+    autor: "DIGITOM-Projekt"
+    referenz: "PENDING-SPM-001, DC-002"
+
+  - version: "0.2"
+    datum: "2026-01-30"
+    aenderung: "Anpassung an Service-Lifecycle 3.0: Phasennamen (betrieb → operation), Aktivitäts-IDs (sb_05 → op_06, sr_02 → rv_02)"
+    autor: "DIGITOM-Projekt"
+    referenz: "CHANGELOG_service-lifecycle-blueprint.md v3.0"
+
+  - version: "0.1"
+    datum: "2025-11-26"
+    aenderung: "Initiale Practice-Konzeption"
+    autor: "DIGITOM-Projekt"
+

#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_design-zieldimensionen.yaml

@@ -0,0 +1,391 @@
+# =============================================================================
+# SERVICE-SUPPORT-MANAGEMENT: DESIGN-ZIELDIMENSIONEN
+# =============================================================================
+# Quelle: "Vorschläge Service Desk nach Lösungssäulen" (A3-Dokument)
+# Status: Abgestimmte Zieldimension für Konzeptentwicklung
+# =============================================================================
+
+metadata:
+  id: "SSM-DESIGN"
+  name: "Design-Zieldimensionen Service-Support-Management"
+  version: "0.2"
+  status: "referenz"
+  erstellt: "2025-12-07"
+  quelle: "Lösungssäulen-Vision (6 Seiten, A3)"
+
+  beschreibung: >
+    Dieses Dokument übersetzt die abgestimmte Vision für den Service Desk
+    in strukturierte Design-Anforderungen. Es dient als Leitplanke für
+    die Entwicklung der Sub-Practices und Governance-Regeln.
+
+# =============================================================================
+# LÖSUNGSSÄULE 1: GOVERNANCE & VERANTWORTLICHKEITEN
+# =============================================================================
+
+saeulen:
+
+  - id: LS-01
+    name: "Governance & Verantwortlichkeiten"
+    untertitel: "Schnittstellendefinitionen zum 2nd Level"
+
+    eskalationskriterien:
+      beschreibung: "Klare Kriterien, wann First Level an Second Level eskaliert"
+      kriterien:
+        - "Technische Berechtigungen fehlen"
+        - "Definierte Zeitgrenzen überschritten"
+        - "Spezialistenwissen erforderlich"
+        - "Kunde fordert Eskalation"
+
+    uebergabedokumentation:
+      beschreibung: "Pflichtinhalte bei Ticket-Übergabe an 2nd Level"
+      pflichtfelder:
+        - "Problembeschreibung"
+        - "Bereits durchgeführte Schritte"
+        - "Gesammelte Diagnosedaten"
+        - "Vermutete Ursache"
+        - "Kontaktdaten des Anwenders inkl. Geräte-IDs"
+
+    rueckgaberegeln:
+      beschreibung: "Wann darf 2nd Level Tickets zurückgeben?"
+      second_level_kann_zurueckgeben_bei:
+        - "Unvollständiger Übergabedokumentation"
+        - "Fehlendem Lösungsversuch First Level"
+        - "Falscher Kategorisierung"
+
+    entscheidungsverfahren:
+      service_owner_rolle: "Grenzwächter"
+      verantwortlichkeiten:
+        - "Monitoring der Service-bezogenen Tickets"
+        - "Identifikation von Umgehungsmustern"
+        - "Qualitätssicherung der Übergaben"
+        - "Mediation bei Schnittstellenkonflikten"
+      befugnisse:
+        - "Direkter Zugriff auf alle Service-Tickets"
+        - "Teilnahme an Eskalationsgesprächen"
+        - "Veto-Recht bei Prozessumgehungen"
+        - "Eskalation an SPM"
+
+# =============================================================================
+# LÖSUNGSSÄULE 2: ROLLENVERSTÄNDNIS UND VERANTWORTUNGSTIEFE
+# =============================================================================
+
+  - id: LS-02
+    name: "Rollenverständnis und Verantwortungstiefe"
+    untertitel: "Enablement und eigenverantwortliches Arbeiten"
+
+    enablement_philosophie:
+      bezeichnung: "Eigenverantwortliches Arbeiten"
+      beschreibung: |
+        Der First Level Agent ist ein eigenverantwortlicher Problemlöser,
+        kein "Ticket-Schubser". Der Agent entscheidet selbst über sein
+        Vorgehen, die SLA gibt den zeitlichen Rahmen vor.
+        
+        Version 0.2: Das bisherige "Explorationsbudget" als eigenständiges
+        Konzept entfällt. Die SLA gibt den Rahmen vor, innerhalb dessen
+        der Agent arbeitet. Die Enablement-Philosophie bleibt erhalten.
+      prinzipien:
+        - "Agent entscheidet eigenverantwortlich über sein Vorgehen"
+        - "Die SLA gibt den zeitlichen Rahmen vor"
+        - "Eskalation ist eine Option, keine Pflicht bei Unklarheit"
+        - "Dokumentation von Erkenntnissen ist erwünscht"
+
+    befaehigung_durch_service_owner:
+      beschreibung: >
+        Die Service Owner tragen die Verantwortung, den First Level
+        systematisch zu befähigen.
+      massnahmen:
+        - "Bereitstellung von Grundlagendokumentation"
+        - "Gemeinsame Erarbeitung von Arbeitsdokumentation"
+        - "Regelmäßige Schulungen und Updates"
+        - "Vergabe notwendiger Berechtigungen"
+        - "Kontinuierliche Weiterentwicklung der Service-spezifischen Kenntnisse"
+
+    hinweis_version_0_2: |
+      Das frühere Konzept "Exploration Budget" (definierte Zeiten für
+      tiefere Exploration, z.B. 10% der Arbeitszeit) wurde gestrichen.
+      
+      Begründung:
+      - Die SLA gibt bereits den zeitlichen Rahmen vor
+      - Ein separates Budget war redundant zur SLA-Steuerung
+      - Die Enablement-Philosophie erfordert keine eigene Zeitsteuerung
+      
+      Die kulturelle Botschaft (Agent darf eigenverantwortlich arbeiten)
+      bleibt erhalten, wird aber nicht mehr über ein separates
+      "Budget" operationalisiert."
+
+# =============================================================================
+# LÖSUNGSSÄULE 3: ORGANISATION & TEAMSTRUKTUR
+# =============================================================================
+
+  - id: LS-03
+    name: "Organisation & Teamstruktur"
+    untertitel: "Rollenübersicht"
+
+    rollenhierarchie:
+      ebene_service_management:
+        - "Service Portfolio Manager"
+        - "Service Owner"
+      ebene_service_desk:
+        - "Service Desk Manager"
+        - "Queue Koordinator"
+        - "1st Agent"
+        - "2nd Agent"
+
+    koordinator_rolle:
+      beschreibung: "Drei Ausprägungen der Koordinator-Rolle"
+
+      varianten:
+        - name: "Koordinator als Facilitator"
+          charakteristik:
+            - "Koordinator beobachtet nur und gibt Hinweise"
+            - "Keine Zuweisung, nur Bitten"
+            - "Team kann 'Nein' sagen"
+            - "Intervention nur mit Team-Konsens"
+
+        - name: "Koordinator als Controller"
+          charakteristik:
+            - "Koordinator weist zu, wenn nötig"
+            - "Team muss folgen (bis auf begründete Ausnahmen)"
+            - "Klare Hierarchie in Überlast-Situationen"
+            - "Koordinator = operative Führungskraft"
+
+        - name: "Koordinator mit situativer Macht"
+          charakteristik:
+            - "Normal: Koordinator als Facilitator"
+            - "Überlast: Koordinator bekommt Durchgriffsrechte"
+            - "Krise: Koordinator als direktiver Lead"
+
+# =============================================================================
+# LÖSUNGSSÄULE 4: TICKETSTEUERUNG & ARBEITSORGANISATION
+# =============================================================================
+
+  - id: LS-04
+    name: "Ticketsteuerung & Arbeitsorganisation"
+    untertitel: "Poolbasierte Steuerungslogik & Ticketübernahme"
+
+    pool_modell:
+      beschreibung: |
+        3 Pools zur Ticket-Steuerung. Die Pool-Zuordnung erfolgt primär
+        über die Priorität. Die SLA gibt den verbindlichen Zeitrahmen vor.
+        
+        Version 0.2: Reduktion von 4 auf 3 Pools. Der bisherige "Analyse-Pool"
+        entfällt – ANALYSE-Tickets werden im Standard-Pool bearbeitet.
+
+      pools:
+        - id: "POOL-1"
+          name: "Sofort-Pool"
+          eingang: "Priorität P1 (alle Charakteristiken)"
+          kriterien:
+            - "Kompletter Systemausfall"
+            - "Mehr als 10 Nutzer:innen betroffen"
+            - "Sicherheitsvorfälle"
+            - "Geschäftskritische Prozesse blockiert"
+          regel: "Muss innerhalb von 15 Minuten gezogen werden"
+          eskalation: "Nach 15 Minuten automatische Alarmierung des Queue-Koordinators"
+
+        - id: "POOL-2"
+          name: "Standard-Pool"
+          eingang: "Priorität P2/P3/P4 mit Charakteristik STANDARD oder ANALYSE"
+          typische_tickets:
+            - "Passwort-Resets (STANDARD)"
+            - "Berechtigungsanfragen (STANDARD)"
+            - "Account-Entsperrungen (STANDARD)"
+            - "Software-Installation aus Katalog (STANDARD)"
+            - "Drucker-Probleme (STANDARD)"
+            - "Unklare Fehlerbeschreibungen (ANALYSE)"
+            - "Intermittierende Probleme (ANALYSE)"
+            - "Performance-Beschwerden (ANALYSE)"
+          regel: "Maximal 30 Tickets im Pool, dann Kapazitätsalarm"
+          bearbeitung: "FIFO nach Priorität, SLA gibt Zeitrahmen vor"
+
+        - id: "POOL-3"
+          name: "Projekt-Pool"
+          eingang: "Charakteristik PROJEKT (unabhängig von Priorität)"
+          typische_aufgaben:
+            - "Neue Arbeitsplatz-Einrichtung"
+            - "Umzüge"
+            - "Komplexe Berechtigungsstrukturen"
+            - "Größere Software-Deployments"
+          regel: "Kann geplant und terminiert werden"
+          koordination: "Abstimmung mit betroffenen Stakeholdern"
+          kpi: "Aus operativen KPIs exkludiert"
+
+    commitment_prinzip:
+      grundregel: "Ticket gezogen = Ticket owned"
+      legitime_ausgaenge:
+        - ausgang: "gelöst"
+          beschreibung: "Ticket wird mit Lösung geschlossen"
+        - ausgang: "eskaliert"
+          beschreibung: "Formale Weitergabe mit dokumentierter Begründung"
+        - ausgang: "geparkt"
+          beschreibung: "Mit konkretem Grund (wartet auf Nutzer:in, wartet auf System, etc.)"
+
+# =============================================================================
+# LÖSUNGSSÄULE 5: WISSENSVERANTWORTUNG
+# =============================================================================
+
+  - id: LS-05
+    name: "Wissensverantwortung"
+    untertitel: "3-Schichten-Modell"
+
+    schichten:
+      - ebene: 1
+        name: "Grundlagendokumentation"
+        verantwortung: "Service Owner"
+        charakteristika:
+          - "Stabile, grundlegende Service-Dokumentation"
+          - "Beschreibt WAS der Service tut und WIE er funktioniert"
+          - "Änderungen nur bei Service-Updates oder strukturellen Anpassungen"
+          - "Qualitätsgesichert und verbindlich"
+        inhalte:
+          - "Service-Beschreibung und Scope"
+          - "Technische Architektur und Abhängigkeiten"
+          - "Basis-Troubleshooting-Prozesse"
+          - "Eskalationswege und Ansprechpartner"
+          - "SLAs und kritische Schwellwerte"
+        prozess:
+          - "Service Owner erstellt und pflegt diese Dokumentation"
+          - "Updates werden proaktiv an Service Desk kommuniziert"
+          - "Versionierung und Change-Log sind verpflichtend"
+
+      - ebene: 2
+        name: "Arbeitsdokumentation"
+        verantwortung: "Service Owner + Service Desk Team (Co-Creation)"
+        charakteristika:
+          - "Operative Übersetzung der Grundlagendokumentation"
+          - "Praxisorientierte Handlungsanweisungen"
+          - "Regelmäßige Updates basierend auf Erfahrungen"
+          - "Gemeinsam erarbeitet und validiert"
+        inhalte:
+          - "Step-by-Step Anleitungen für häufige Szenarien"
+          - "Checklisten und Entscheidungsbäume"
+          - "Workarounds für bekannte Probleme"
+          - "Quick-Reference-Guides"
+          - "Tool-spezifische Anleitungen"
+        prozess:
+          - "Quartalsweise gemeinsame Workshop-Sessions"
+          - "Service Owner moderiert, Service Desk bringt Praxiserfahrung ein"
+          - "Qualitätssicherung durch beide Seiten"
+          - "Direkte Integration in Ticketsystem wo möglich"
+
+      - ebene: 3
+        name: "Operative Erkenntnisse"
+        verantwortung: "Service Desk Team (Wiki-Prinzip)"
+        charakteristika:
+          - "Dynamische, schnell änderbare Wissensbasis"
+          - "Bottom-up aus täglicher Arbeit"
+          - "Peer-Review statt zentrale Kontrolle"
+          - "Experimenteller Charakter erlaubt"
+        inhalte:
+          - "Lösungen für spezielle Edge-Cases"
+          - "Tipps und Tricks aus der Praxis"
+          - "Temporäre Workarounds"
+          - "Beobachtungen und Muster"
+          - "'Lessons Learned' aus schwierigen Tickets"
+        prozess:
+          - "Jeder Service Agent kann Einträge erstellen/editieren"
+          - "Monatliches Review-Meeting zur Qualitätssicherung"
+          - "Bewährte Erkenntnisse wandern in Ebene 2"
+          - "Veraltete Einträge werden archiviert"
+
+# =============================================================================
+# LÖSUNGSSÄULE 6: QUALITÄT UND VERBESSERUNGSLOGIK
+# =============================================================================
+
+  - id: LS-06
+    name: "Qualität und Verbesserungslogik"
+    untertitel: "Hybrid-Modell mit Fokus Lernen"
+
+    kpis:
+      primaer:
+        - name: "First Contact Resolution Rate"
+          ziel_phase_1: ">40%"
+          ziel_phase_3: ">60%"
+        - name: "Durchschnittliche Lösungszeit nach Pool-Typ"
+        - name: "SLA-Erfüllungsgrad (wenn definiert)"
+        - name: "Tickets pro Agent und Tag"
+        - name: "Eskalationsrate"
+        - name: "Kundenzufriedenheit (wenn messbar)"
+
+      sekundaer:
+        - "Wiki-Beiträge pro Monat"
+        - "Peer-Support-Anfragen"
+        - "Wiederöffnungsrate"
+        - "Backlog-Entwicklung"
+
+      austauschformate:
+        - "Service Owner Reviews"
+        - "Team Retrospektiven"
+
+    kontinuierliche_verbesserung:
+      durch_service_owner:
+        beschreibung: "Service Owner tragen Verantwortung für:"
+        aufgaben:
+          - "Regelmäßige Qualitätssicherung der Dokumentation"
+          - "Identifikation von Automatisierungspotential"
+          - "Schulungsplanung basierend auf Fehlermustern"
+          - "Proaktive Service-Verbesserungen"
+
+      durch_fehlerkultur:
+        prinzipien:
+          - "Fehler sind Lernchancen"
+          - "Dokumentation statt Schuldzuweisung"
+          - "Systematische Ursachenanalyse"
+          - "Präventionsmaßnahmen entwickeln"
+
+        prozess_bei_kritischen_fehlern:
+          - schritt: 1
+            aktion: "Sofortige Schadensbegrenzung"
+          - schritt: 2
+            aktion: "Sachliche Dokumentation"
+          - schritt: 3
+            aktion: "Ursachenanalyse im Team"
+          - schritt: 4
+            aktion: "Maßnahmenableitung"
+          - schritt: 5
+            aktion: "Nachverfolgung der Wirksamkeit"
+
+# =============================================================================
+# MAPPING AUF SUB-PRACTICES
+# =============================================================================
+
+mapping_sub_practices:
+  beschreibung: >
+    Zuordnung der Lösungssäulen-Elemente zu den zu entwickelnden Sub-Practices
+
+  incident_management:
+    relevante_saeulen: [LS-01, LS-04, LS-06]
+    schwerpunkte:
+      - "Eskalationskriterien (LS-01)"
+      - "Pool-Modell für Incident-Priorisierung (LS-04)"
+      - "Commitment-Prinzip (LS-04)"
+      - "KPIs: Lösungszeit, Eskalationsrate (LS-06)"
+
+  request_management:
+    relevante_saeulen: [LS-04, LS-05]
+    schwerpunkte:
+      - "Standard Service-Pool (LS-04)"
+      - "Projektpool für komplexe Requests (LS-04)"
+      - "Arbeitsdokumentation für Request-Typen (LS-05)"
+
+  service_desk:
+    relevante_saeulen: [LS-02, LS-03, LS-05]
+    schwerpunkte:
+      - "Koordinator-Rolle und Modelle (LS-03)"
+      - "Enablement-Philosophie / Eigenverantwortliches Arbeiten (LS-02)"
+      - "3-Schichten-Wissensmodell (LS-05)"
+      - "Befähigung durch Service Owner (LS-02)"
+
+  problem_management:
+    relevante_saeulen: [LS-05, LS-06]
+    schwerpunkte:
+      - "Erkenntnisse aus Ebene 3 → Problem-Kandidaten (LS-05)"
+      - "Fehlerkultur und Ursachenanalyse (LS-06)"
+      - "Kontinuierliche Verbesserung (LS-06)"
+
+  governance_uebergreifend:
+    relevante_saeulen: [LS-01, LS-03]
+    schwerpunkte:
+      - "Service Owner als Grenzwächter (LS-01)"
+      - "Übergabe- und Rückgaberegeln (LS-01)"
+      - "Rollenhierarchie und Befugnisse (LS-03)"

#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_klassifikation-priorisierung.yaml

@@ -0,0 +1,960 @@
+# =============================================================================
+# SERVICE-SUPPORT-MANAGEMENT: KLASSIFIKATION & PRIORISIERUNG
+# =============================================================================
+
+metadata:
+  id: "SSM-KLASSIFIKATION"
+  name: "Ticket-Klassifikation und Priorisierung"
+  version: "0.4"
+  status: "draft"
+  erstellt: "2025-12-07"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+  
+  beschreibung: >
+    Querschnitts-Dokument für die Klassifikation und Priorisierung aller
+    Support-Tickets (Incidents und Requests). Definiert die Entscheidungslogik
+    für Prioritätszuweisung, Pool-Zuordnung sowie die zugehörigen SLA-Rahmen.
+    
+    Version 0.4: Überarbeitung der Impact- und Urgency-Kriterien.
+    Impact basiert nun primär auf qualitativen Kriterien (Sicherheit,
+    Kritikalitätsstufe, Bürger-Betroffenheit, Leitungsebene) statt auf
+    Nutzeranzahl. Urgency fokussiert auf zeitliche Aspekte mit präzisierten
+    Kriterien für externe Fristen und rechtliche Vorgaben.
+  
+  gilt_fuer:
+    - "sub-practice_incident-management.yaml"
+    - "sub-practice_request-management.yaml"
+  
+  design_referenz: "ssm_design-zieldimensionen.yaml"
+  relevante_saeulen: ["LS-01", "LS-04"]
+  
+  governance_referenz:
+    - "SSM-G-02: Priorisierungs-Autorität"
+    - "SSM-G-04: DoR-Verbindlichkeit"
+
+# =============================================================================
+# GRUNDPRINZIPIEN
+# =============================================================================
+
+grundprinzipien:
+  
+  beschreibung: >
+    Die Klassifikation und Priorisierung folgt einem klaren Modell:
+    Die Priorität (abgeleitet aus Impact × Urgency) bestimmt die 
+    SLA-Verbindlichkeit und die Pool-Zuordnung. Die Charakteristik
+    ist ein beschreibendes Attribut für Reporting und Analyse.
+  
+  steuerungslogik:
+    - dimension: "Priorität"
+      funktion: "SLA-Steuerung und Pool-Zuordnung"
+      beantwortet: "WANN muss reagiert/gelöst werden? In welchem Pool?"
+      basis: "Impact × Urgency"
+      
+    - dimension: "Charakteristik"
+      funktion: "Beschreibendes Attribut (Label)"
+      beantwortet: "Welche Art von Ticket ist es?"
+      nutzen:
+        - "Reporting (Anteil unklarer Tickets)"
+        - "Wissenslücken identifizieren"
+        - "Dokumentationsbedarf erkennen"
+      hinweis: "Keine Steuerungsfunktion für Pool-Zuordnung"
+  
+  autoritaet:
+    wer_priorisiert: "Service Desk (First Level)"
+    grundlage: "Impact-Urgency-Matrix (verbindlich)"
+    eskalation_bei_widerspruch: "Queue-Koordinator / Teamleitung"
+    kunde_kann: "Dringlichkeit melden"
+    kunde_kann_nicht: "Priorität festlegen"
+    
+    governance_entscheidung: "SSM-G-02"
+
+# =============================================================================
+# TICKET-TYPEN
+# =============================================================================
+
+ticket_typen:
+  
+  beschreibung: >
+    Grundlegende Unterscheidung der Ticket-Typen. Die Klassifikation erfolgt
+    bei Ticket-Erfassung und bestimmt den anzuwendenden Prozess.
+  
+  typen:
+    - id: "INCIDENT"
+      name: "Störung"
+      definition: >
+        Ungeplante Unterbrechung oder Qualitätsminderung eines IT-Services.
+        Der normale Betrieb ist beeinträchtigt.
+      beispiele:
+        - "Anwendung stürzt ab"
+        - "Drucker druckt nicht"
+        - "Kein Netzwerkzugang"
+        - "Performance-Probleme"
+        - "Fehlermeldungen"
+      prozess: "sub-practice_incident-management.yaml"
+      
+    - id: "REQUEST"
+      name: "Service-Anfrage"
+      definition: >
+        Formelle Anfrage eines Nutzers für etwas, das bereitgestellt werden
+        soll. Kein Ausfall oder Störung, sondern geplante Leistungserbringung.
+      beispiele:
+        - "Passwort zurücksetzen"
+        - "Neue Software installieren"
+        - "Berechtigung anfordern"
+        - "Hardware bestellen"
+        - "Informationsanfrage"
+      prozess: "sub-practice_request-management.yaml"
+      
+    - id: "PROJEKT"
+      name: "Projekt-Ticket"
+      definition: >
+        Planbare, umfangreiche Aufgabe, die nicht im normalen Support-Flow
+        bearbeitet werden kann. Erfordert Koordination und Terminierung.
+      beispiele:
+        - "Neuer Arbeitsplatz einrichten (komplett)"
+        - "Abteilungsumzug"
+        - "Komplexe Berechtigungsstruktur aufbauen"
+        - "Größeres Software-Deployment"
+      prozess: "Separater Prozess / Projektpool"
+      
+      hinweis: >
+        Projekt-Tickets werden NICHT in operativen KPIs (MTTR, FCR) gezählt.
+        Governance-Entscheidung SSM-G-07.
+  
+  entscheidungsbaum_typ:
+    frage_1: "Liegt eine Störung/Beeinträchtigung eines laufenden Services vor?"
+    wenn_ja: "→ INCIDENT"
+    wenn_nein:
+      frage_2: "Ist die Anfrage standardisiert und in absehbarer Zeit erledigbar?"
+      wenn_ja: "→ REQUEST"
+      wenn_nein:
+        frage_3: "Erfordert die Anfrage Planung, Koordination oder >1 Tag Aufwand?"
+        wenn_ja: "→ PROJEKT"
+        wenn_nein: "→ REQUEST"
+
+# =============================================================================
+# IMPACT-URGENCY-MATRIX
+# =============================================================================
+
+impact_urgency_matrix:
+  
+  beschreibung: >
+    Die Priorität ergibt sich aus der Kombination von Impact (Auswirkung)
+    und Urgency (Dringlichkeit). Die Matrix ist verbindlich anzuwenden.
+
+  # ---------------------------------------------------------------------------
+  # IMPACT-DEFINITION
+  # ---------------------------------------------------------------------------
+  impact:
+    beschreibung: "Ausmaß der Auswirkung auf den Geschäftsbetrieb"
+    
+    stufen:
+      - stufe: "HOCH"
+        code: "I-H"
+        beschreibung: "Mindestens eines der folgenden Kriterien erfüllt"
+        kriterien:
+          - "Sicherheitsvorfall (Datenverlust, Breach, Malware-Verdacht)"
+          - "ODER Service mit Kritikalitätsstufe 'geschaeftskritisch' betroffen"
+          - "ODER Bürger durch Ausfall direkt betroffen"
+          - "ODER definierte Leitungsebene betroffen"
+        beispiele:
+          - "Ransomware-Verdacht"
+          - "SAP nicht erreichbar"
+          - "freiburg.de nicht erreichbar"
+          - "Bürgerdienstleistung kann nicht erbracht werden"
+          - "Wartezeit am Schalter durch IT-Ausfall"
+          - "Netzwerk-Backbone ausgefallen"
+        hinweise:
+          buerger_kriterium: >
+            Bürger-Betroffenheit umfasst sowohl direkte Interaktion
+            (Schalter, Termin, telefonische Erreichbarkeit) als auch
+            Bürger-facing Services (Website, Online-Formulare, Portal).
+          leitungsebene: >
+            Die relevanten Leitungsebenen werden im lebenden Arbeitsdokument
+            für geschäftskritische Applikationen definiert. Dieses wird
+            regelmäßig geprüft und aktualisiert; Entscheidungen erfolgen
+            durch die SOR.
+      
+      - stufe: "NORMAL"
+        code: "I-N"
+        beschreibung: "Mindestens eines der folgenden Kriterien erfüllt"
+        kriterien:
+          - "Mehrere Nutzer betroffen (>1) oder ganze Teams/Bereiche"
+          - "ODER Service mit Kritikalitätsstufe 'wichtig' betroffen"
+        beispiele:
+          - "Outlook stürzt bei mehreren Nutzern ab"
+          - "Drucker für ganzes Team funktioniert nicht"
+          - "Fachverfahren mit Tagesgeschäft-Relevanz gestört"
+          - "E-Mail-System eingeschränkt verfügbar"
+      
+      - stufe: "NIEDRIG"
+        code: "I-L"
+        beschreibung: "Folgende Kriterien erfüllt"
+        kriterien:
+          - "Einzelner Nutzer betroffen ODER Service mit Kritikalitätsstufe 'unterstuetzend'"
+          - "Komforteinschränkung ohne Auswirkung auf Arbeitsfähigkeit"
+        beispiele:
+          - "Schriftart in Outlook zurückgesetzt"
+          - "Desktop-Hintergrund fehlt"
+          - "Nicht-kritische Funktion nicht verfügbar"
+          - "Raumbuchungssystem gestört"
+
+  # ---------------------------------------------------------------------------
+  # URGENCY-DEFINITION
+  # ---------------------------------------------------------------------------
+  urgency:
+    beschreibung: "Zeitliche Dringlichkeit der Lösung – wie schnell muss gelöst werden, um Schaden zu vermeiden?"
+    
+    stufen:
+      - stufe: "HOCH"
+        code: "U-H"
+        beschreibung: "Mindestens eines der folgenden Kriterien erfüllt"
+        kriterien:
+          - "Akute Auswirkung auf gesamte Arbeitsfähigkeit, kein Workaround möglich, sofortige Lösung erforderlich"
+          - "ODER zeitkritischer Prozess (externe Frist, rechtliche Vorgabe, Termin mit Bürger oder externen Partnern)"
+        beispiele:
+          - "Präsentation in 1 Stunde, Laptop startet nicht"
+          - "Fristgebundener Vorgang blockiert (rechtliche Frist)"
+          - "Bürger wartet am Schalter"
+          - "Termin mit externem Partner steht unmittelbar bevor"
+      
+      - stufe: "NORMAL"
+        code: "U-N"
+        beschreibung: "Mindestens eines der folgenden Kriterien erfüllt"
+        kriterien:
+          - "Keine unmittelbaren Auswirkungen auf Arbeitsfähigkeit"
+          - "ODER temporärer Workaround existiert"
+          - "ODER keine Deadline, aber zeitnahe Lösung notwendig"
+        beispiele:
+          - "Drucker defekt, anderer Drucker verfügbar"
+          - "Software benötigt, aber nicht heute"
+          - "Eingeschränkte Funktionalität, Kernarbeit möglich"
+      
+      - stufe: "NIEDRIG"
+        code: "U-L"
+        beschreibung: "Alle folgenden Kriterien erfüllt"
+        kriterien:
+          - "Keine Auswirkung auf Arbeitsfähigkeit"
+          - "Kann warten, Nutzer hat explizit keine Eile"
+        beispiele:
+          - "Verbesserungsvorschlag"
+          - "Langfristige Anfrage"
+          - "Kosmetische Anpassung ohne Dringlichkeit"
+
+  # ---------------------------------------------------------------------------
+  # MATRIX
+  # ---------------------------------------------------------------------------
+  matrix:
+    beschreibung: "Ableitung der Priorität aus Impact × Urgency"
+    
+    #                URGENCY
+    #           HOCH    NORMAL   NIEDRIG
+    # IMPACT
+    # HOCH      P1      P2       P3
+    # NORMAL    P2      P3       P4
+    # NIEDRIG   P3      P4       P4
+    
+    mapping:
+      - impact: "HOCH"
+        urgency: "HOCH"
+        prioritaet: "P1"
+        
+      - impact: "HOCH"
+        urgency: "NORMAL"
+        prioritaet: "P2"
+        
+      - impact: "HOCH"
+        urgency: "NIEDRIG"
+        prioritaet: "P3"
+        
+      - impact: "NORMAL"
+        urgency: "HOCH"
+        prioritaet: "P2"
+        
+      - impact: "NORMAL"
+        urgency: "NORMAL"
+        prioritaet: "P3"
+        
+      - impact: "NORMAL"
+        urgency: "NIEDRIG"
+        prioritaet: "P4"
+        
+      - impact: "NIEDRIG"
+        urgency: "HOCH"
+        prioritaet: "P3"
+        
+      - impact: "NIEDRIG"
+        urgency: "NORMAL"
+        prioritaet: "P4"
+        
+      - impact: "NIEDRIG"
+        urgency: "NIEDRIG"
+        prioritaet: "P4"
+
+# =============================================================================
+# SERVICE-KRITIKALITÄTS-MAPPING
+# =============================================================================
+
+service_kritikalitaet_mapping:
+  
+  beschreibung: >
+    Verknüpfung zwischen Service-Kritikalität (aus Service-Definition)
+    und Impact-Bewertung im Incident Management. Ermöglicht eine
+    konsistente, service-basierte Priorisierung.
+  
+  referenz: "spm_schema_service-definition.yaml → geschaeftskritikalitaet"
+  
+  grundprinzip: >
+    Die im Service-Portfolio hinterlegte Kritikalitätsstufe eines Services
+    dient als Vorschlagswert für die Impact-Bewertung bei Störungen.
+    Der Agent kann bei abweichender Einschätzung (z.B. nur Teilausfall,
+    Workaround verfügbar) manuell korrigieren.
+  
+  mapping:
+    - service_kritikalitaet: "geschaeftskritisch"
+      impact_vorschlag: "HOCH"
+      beschreibung: >
+        Bei Störung eines geschäftskritischen Services wird
+        Impact HOCH automatisch vorgeschlagen.
+      agent_aktion: "Prüfen, ob Totalausfall vorliegt. Bei Teilausfall ggf. Abstufung."
+    
+    - service_kritikalitaet: "wichtig"
+      impact_vorschlag: "NORMAL"
+      beschreibung: >
+        Bei Störung eines wichtigen Services wird Impact NORMAL
+        vorgeschlagen.
+      agent_aktion: "Prüfen, ob weitere HOCH-Kriterien vorliegen (Sicherheit, Bürger, Leitungsebene)."
+    
+    - service_kritikalitaet: "unterstuetzend"
+      impact_vorschlag: "NIEDRIG"
+      beschreibung: >
+        Bei Störung eines unterstützenden Services wird Impact NIEDRIG
+        vorgeschlagen, sofern keine anderen Faktoren vorliegen.
+      agent_aktion: "Standardfall, Hochstufung nur bei besonderen Umständen."
+  
+  hinweis_itsm: >
+    Im ITSM-Tool sollte der Impact basierend auf dem betroffenen Service
+    automatisch vorbelegt werden. Voraussetzung ist die Verknüpfung von
+    Tickets mit Service-Stammdaten (Service-Katalog-Integration).
+    Der Agent behält die Möglichkeit zur manuellen Korrektur mit Begründung.
+  
+  hinweis_unbekannter_service: >
+    Falls der betroffene Service nicht identifiziert werden kann oder
+    nicht im Katalog geführt wird, erfolgt die Impact-Bewertung
+    ausschließlich nach den Standard-Kriterien (Betroffenenzahl,
+    Prozessblockade, etc.).
+
+# =============================================================================
+# PRIORITÄTSSTUFEN
+# =============================================================================
+
+prioritaetsstufen:
+  
+  beschreibung: >
+    Definition der vier Prioritätsstufen mit SLA-Zielen. Die Priorität
+    bestimmt die verbindlichen Reaktions- und Lösungszeiten.
+  
+  stufen:
+    - id: "P1"
+      name: "Kritisch"
+      beschreibung: "Geschäftskritische Störung, sofortige Reaktion erforderlich"
+      
+      sla_ziele:
+        reaktionszeit: "15 Minuten"
+        loesungszeit_ziel: "4 Stunden"
+        loesungszeit_max: "8 Stunden"
+      
+      eskalation:
+        bei_ueberschreitung_reaktion: "Sofort an Queue-Koordinator"
+        bei_ueberschreitung_loesung_50: "Service Owner informieren"
+        bei_ueberschreitung_loesung_100: "Teamleitung + Service Owner"
+      
+      behandlung:
+        unterbrechung_erlaubt: true
+        dedizierte_bearbeitung: true
+        status_update_frequenz: "30 Minuten"
+    
+    - id: "P2"
+      name: "Hoch"
+      beschreibung: "Erhebliche Beeinträchtigung, zeitnahe Reaktion erforderlich"
+      
+      sla_ziele:
+        reaktionszeit: "1 Stunde"
+        loesungszeit_ziel: "8 Stunden"
+        loesungszeit_max: "16 Stunden (2 AT)"
+      
+      eskalation:
+        bei_ueberschreitung_reaktion: "Queue-Koordinator informieren"
+        bei_ueberschreitung_loesung_50: "Queue-Koordinator"
+        bei_ueberschreitung_loesung_100: "Teamleitung"
+      
+      behandlung:
+        unterbrechung_erlaubt: false
+        priorisierte_bearbeitung: true
+        status_update_frequenz: "2 Stunden"
+    
+    - id: "P3"
+      name: "Normal"
+      beschreibung: "Beeinträchtigung mit Workaround, normale Bearbeitung"
+      
+      sla_ziele:
+        reaktionszeit: "4 Stunden"
+        loesungszeit_ziel: "3 Arbeitstage"
+        loesungszeit_max: "5 Arbeitstage"
+      
+      eskalation:
+        bei_ueberschreitung_reaktion: "Automatische Queue-Warnung"
+        bei_ueberschreitung_loesung_50: "Keine automatische Eskalation"
+        bei_ueberschreitung_loesung_100: "Queue-Koordinator"
+      
+      behandlung:
+        unterbrechung_erlaubt: false
+        priorisierte_bearbeitung: false
+        status_update_frequenz: "1x täglich bei Nachfrage"
+    
+    - id: "P4"
+      name: "Niedrig"
+      beschreibung: "Geringe Auswirkung, Bearbeitung nach Kapazität"
+      
+      sla_ziele:
+        reaktionszeit: "1 Arbeitstag"
+        loesungszeit_ziel: "5 Arbeitstage"
+        loesungszeit_max: "10 Arbeitstage"
+      
+      eskalation:
+        bei_ueberschreitung_reaktion: "Keine automatische Eskalation"
+        bei_ueberschreitung_loesung_50: "Keine automatische Eskalation"
+        bei_ueberschreitung_loesung_100: "Automatische Queue-Warnung"
+      
+      behandlung:
+        unterbrechung_erlaubt: false
+        priorisierte_bearbeitung: false
+        status_update_frequenz: "Bei Abschluss"
+
+  hinweis_sla: >
+    Die SLA-Ziele sind Rahmenparameter. Verbindliche Service Levels werden
+    in SLAs/SLS je Service definiert und können abweichen. Bei Abweichung
+    gilt die service-spezifische Vereinbarung.
+  
+  referenz_slm: "spm_practice_service-level-management.yaml"
+
+# =============================================================================
+# TICKET-CHARAKTERISTIK
+# =============================================================================
+
+ticket_charakteristik:
+  
+  beschreibung: >
+    Die Ticket-Charakteristik ist ein beschreibendes Attribut (Label),
+    das die Art des Tickets dokumentiert. Sie dient dem Reporting und
+    der Identifikation von Wissenslücken, hat aber keine Steuerungsfunktion
+    für die Pool-Zuordnung.
+    
+    Die Pool-Zuordnung erfolgt ausschließlich über die Priorität.
+  
+  konzeptionelle_einordnung: |
+    Version 0.2: Die Charakteristik ANALYSE war ursprünglich als
+    Steuerungsgröße für einen separaten "Analyse-Pool" konzipiert.
+    Diese Trennung wurde aufgegeben, da die SLA bereits den zeitlichen
+    Rahmen vorgibt. Die Charakteristik bleibt als Label für Reporting erhalten.
+  
+  charakteristiken:
+    
+    - id: "STANDARD"
+      name: "Standard-Ticket"
+      beschreibung: >
+        Bekanntes Muster, klare Lösung dokumentiert. Kann nach 
+        Standardverfahren bearbeitet werden.
+      indikatoren:
+        - "Ähnliche Tickets wurden bereits gelöst"
+        - "Lösungsweg ist dokumentiert (Wissensdatenbank)"
+        - "Keine Diagnose erforderlich"
+        - "Aufwand schätzbar (<30 Min typisch)"
+      beispiele:
+        - "Passwort zurücksetzen"
+        - "Standard-Berechtigung vergeben"
+        - "Bekannter Drucker-Treiber-Reset"
+        - "Software aus Katalog installieren"
+    
+    - id: "ANALYSE"
+      name: "Analyse-Ticket"
+      beschreibung: >
+        Unklare Ursache, Diagnose erforderlich. Lösungsweg nicht 
+        unmittelbar erkennbar. Dieses Label kennzeichnet Tickets,
+        bei denen der Agent eigenständig Diagnosearbeit leisten muss.
+      indikatoren:
+        - "Ursache nicht sofort erkennbar"
+        - "Intermittierendes Problem"
+        - "Unspezifische Fehlerbeschreibung"
+        - "Kein bekanntes Muster"
+      beispiele:
+        - "Outlook stürzt manchmal ab"
+        - "PC ist langsam"
+        - "Irgendwas funktioniert nicht richtig"
+        - "Sporadische Fehlermeldung"
+      
+      reporting_nutzen:
+        - "Anteil unklarer Tickets messen"
+        - "Wissenslücken in Dokumentation erkennen"
+        - "Schulungsbedarf identifizieren"
+        - "Service-Owner auf Dokumentationsbedarf hinweisen"
+      
+      hinweis: |
+        Die Charakteristik ANALYSE führt NICHT zu einem separaten Pool.
+        ANALYSE-Tickets werden im Standard-Pool bearbeitet, die SLA gibt
+        den zeitlichen Rahmen vor. Der Agent entscheidet eigenverantwortlich
+        über sein Vorgehen (Enablement-Philosophie).
+    
+    - id: "PROJEKT"
+      name: "Projekt-Ticket"
+      beschreibung: >
+        Planbare, umfangreiche Aufgabe. Erfordert Koordination mit
+        Stakeholdern und kann terminiert werden.
+      indikatoren:
+        - "Aufwand >1 Arbeitstag"
+        - "Mehrere Beteiligte erforderlich"
+        - "Terminabstimmung notwendig"
+        - "Keine sofortige Bearbeitung erwartet"
+      beispiele:
+        - "Arbeitsplatz-Neueinrichtung"
+        - "Büroumzug"
+        - "Komplexe Berechtigungsstruktur"
+      
+      hinweis: >
+        Projekt-Tickets werden aus operativen KPIs exkludiert.
+        Schwelle für Umklassifikation: >20 Arbeitstage Laufzeit.
+
+# =============================================================================
+# POOL-MODELL
+# =============================================================================
+
+pool_modell:
+  
+  beschreibung: >
+    Drei Pools zur Steuerung der Arbeitsorganisation. Die Pool-Zuordnung
+    erfolgt primär über die Priorität. Die SLA gibt den verbindlichen
+    Zeitrahmen vor.
+    
+    Version 0.2: Reduktion von vier auf drei Pools. Der bisherige
+    "Analyse-Pool" entfällt – ANALYSE-Tickets werden im Standard-Pool
+    bearbeitet. Die Charakteristik ANALYSE bleibt als Label erhalten.
+  
+  referenz: "LS-04 (Design-Zieldimensionen)"
+  
+  design_entscheidung: |
+    Die Trennung in Standard- und Analyse-Pool wurde aufgegeben, da:
+    - Die SLA bereits den zeitlichen Rahmen vorgibt
+    - Ein separates "Explorationsbudget" redundant zur SLA ist
+    - Die Enablement-Philosophie (Agent darf eigenverantwortlich arbeiten)
+      keine Pool-Trennung erfordert
+    - Einfachere Steuerung mit weniger Pools
+  
+  pools:
+    
+    # -------------------------------------------------------------------------
+    - id: "POOL-SOFORT"
+      name: "Sofort-Pool"
+      
+      beschreibung: >
+        Kritische Tickets, die sofortige Aufmerksamkeit erfordern.
+        Unterbrechung laufender Arbeit ist legitimiert.
+      
+      eingangs_kriterien:
+        - "Priorität P1 (alle Charakteristiken)"
+        - "ODER Priorität P2 + Charakteristik STANDARD bei kritischer Queue-Lage"
+      
+      regeln:
+        max_liegezeit: "15 Minuten"
+        aktion_bei_ueberschreitung: "Automatische Alarmierung Queue-Koordinator"
+        bearbeitungsmodus: "Dediziert, keine parallele Arbeit"
+        unterbrechung_laufender_arbeit: true
+      
+      kapazitaet:
+        warnung_bei: ">2 Tickets gleichzeitig"
+        aktion: "Eskalation an Teamleitung, Ressourcen-Umverteilung"
+      
+      commitment:
+        grundregel: "Ticket gezogen = Ticket owned bis Lösung oder Eskalation"
+    
+    # -------------------------------------------------------------------------
+    - id: "POOL-STANDARD"
+      name: "Standard-Pool"
+      
+      beschreibung: >
+        Alle nicht-kritischen Tickets (P2/P3/P4), unabhängig von der
+        Charakteristik (STANDARD oder ANALYSE). Bearbeitung nach 
+        FIFO-Prinzip, priorisiert nach Prioritätsstufe. Die SLA gibt
+        den verbindlichen Zeitrahmen vor.
+      
+      eingangs_kriterien:
+        - "Priorität P2/P3/P4 (alle Charakteristiken außer PROJEKT)"
+      
+      typische_tickets:
+        - "Passwort-Resets (STANDARD)"
+        - "Standard-Berechtigungsanfragen (STANDARD)"
+        - "Account-Entsperrungen (STANDARD)"
+        - "Software-Installation aus Katalog (STANDARD)"
+        - "Drucker-Probleme mit bekannter Lösung (STANDARD)"
+        - "Unklare Fehlerbeschreibungen (ANALYSE)"
+        - "Intermittierende Probleme (ANALYSE)"
+        - "Performance-Beschwerden (ANALYSE)"
+      
+      regeln:
+        max_tickets_im_pool: 30
+        aktion_bei_ueberschreitung: "Kapazitätsalarm an Queue-Koordinator"
+        bearbeitungsmodus: "FIFO nach Priorität"
+        zeitrahmen: "SLA gibt Reaktions- und Lösungszeit vor"
+      
+      enablement_philosophie: |
+        Der Agent entscheidet eigenverantwortlich über sein Vorgehen:
+        - Bei STANDARD-Tickets: Dokumentierte Lösung anwenden
+        - Bei ANALYSE-Tickets: Eigenständige Diagnose, Eskalation wenn nötig
+        Die SLA gibt den Rahmen vor, innerhalb dessen der Agent arbeitet.
+      
+      commitment:
+        grundregel: "Ticket gezogen = Ticket owned"
+        legitime_ausgaenge:
+          - "gelöst: Ticket wird mit Lösung geschlossen"
+          - "eskaliert: Formale Weitergabe mit dokumentierter Begründung"
+          - "geparkt: Mit konkretem Grund (wartet auf Nutzer, wartet auf System)"
+    
+    # -------------------------------------------------------------------------
+    - id: "POOL-PROJEKT"
+      name: "Projekt-Pool"
+      
+      beschreibung: >
+        Planbare Aufgaben, die nicht im normalen Queue-Flow bearbeitet 
+        werden. Terminierung mit betroffenen Stakeholdern.
+      
+      eingangs_kriterien:
+        - "Charakteristik PROJEKT (unabhängig von Priorität)"
+        - "ODER Umklassifikation bei Laufzeit >20 Arbeitstage"
+      
+      typische_tickets:
+        - "Neue Arbeitsplatz-Einrichtung"
+        - "Umzüge"
+        - "Komplexe Berechtigungsstrukturen"
+        - "Größere Software-Deployments"
+      
+      regeln:
+        queue_steuerung: false
+        terminierung: "Abstimmung mit betroffenen Stakeholdern"
+        kapazitaetsplanung: "Durch Queue-Koordinator / Teamleitung"
+      
+      kpi_behandlung:
+        in_operativen_kpis: false
+        separate_auswertung: true
+        begruendung: "Verzerrt MTTR-Metriken, andere Steuerungslogik"
+
+# =============================================================================
+# ABLEITUNGSLOGIK: PRIORITÄT × CHARAKTERISTIK → POOL
+# =============================================================================
+
+ableitungslogik:
+  
+  beschreibung: >
+    Die Pool-Zuordnung erfolgt primär über die Priorität.
+    Die Charakteristik (STANDARD/ANALYSE) ist ein beschreibendes Label
+    ohne Einfluss auf die Pool-Zuordnung.
+    
+    Version 0.2: Vereinfachte Logik ohne Analyse-Pool.
+  
+  #                      TICKET-CHARAKTERISTIK
+  #                 STANDARD      ANALYSE       PROJEKT
+  # PRIORITÄT
+  # P1              SOFORT        SOFORT        (nicht möglich)
+  # P2              STANDARD      STANDARD      (nicht möglich)
+  # P3              STANDARD      STANDARD      PROJEKT
+  # P4              STANDARD      STANDARD      PROJEKT
+  
+  logik:
+    beschreibung: |
+      1. P1 → Sofort-Pool (unabhängig von Charakteristik)
+      2. P2/P3/P4 + PROJEKT → Projekt-Pool
+      3. P2/P3/P4 + STANDARD oder ANALYSE → Standard-Pool
+  
+  mapping:
+    - prioritaet: "P1"
+      pool: "POOL-SOFORT"
+      hinweis: "Alle P1-Tickets, unabhängig von Charakteristik"
+      
+    - prioritaet: "P2"
+      charakteristik: "STANDARD oder ANALYSE"
+      pool: "POOL-STANDARD"
+      
+    - prioritaet: "P2"
+      charakteristik: "PROJEKT"
+      pool: null
+      hinweis: "P2 + PROJEKT ist selten. Prüfen und ggf. umklassifizieren."
+      
+    - prioritaet: "P3"
+      charakteristik: "STANDARD oder ANALYSE"
+      pool: "POOL-STANDARD"
+      
+    - prioritaet: "P3"
+      charakteristik: "PROJEKT"
+      pool: "POOL-PROJEKT"
+      
+    - prioritaet: "P4"
+      charakteristik: "STANDARD oder ANALYSE"
+      pool: "POOL-STANDARD"
+      
+    - prioritaet: "P4"
+      charakteristik: "PROJEKT"
+      pool: "POOL-PROJEKT"
+
+# =============================================================================
+# KLASSIFIKATIONSPROZESS
+# =============================================================================
+
+klassifikationsprozess:
+  
+  beschreibung: >
+    Ablauf der Ticket-Klassifikation bei Erfassung. Der Prozess ist 
+    verbindlich für alle Tickets anzuwenden.
+  
+  schritte:
+    - schritt: 1
+      name: "Ticket-Typ bestimmen"
+      aktion: "Entscheidungsbaum Typ anwenden"
+      ergebnis: "INCIDENT / REQUEST / PROJEKT"
+      verantwortlich: "First Level Agent"
+      
+    - schritt: 2
+      name: "Impact bewerten"
+      aktion: "Impact-Kriterien prüfen"
+      ergebnis: "HOCH / NORMAL / NIEDRIG"
+      verantwortlich: "First Level Agent"
+      
+    - schritt: 3
+      name: "Urgency bewerten"
+      aktion: "Urgency-Kriterien prüfen"
+      ergebnis: "HOCH / NORMAL / NIEDRIG"
+      verantwortlich: "First Level Agent"
+      
+    - schritt: 4
+      name: "Priorität ableiten"
+      aktion: "Matrix anwenden"
+      ergebnis: "P1 / P2 / P3 / P4"
+      verantwortlich: "System (automatisch) oder First Level Agent"
+      
+    - schritt: 5
+      name: "Charakteristik bestimmen"
+      aktion: "Indikatoren prüfen"
+      ergebnis: "STANDARD / ANALYSE / PROJEKT"
+      verantwortlich: "First Level Agent"
+      
+    - schritt: 6
+      name: "Pool zuweisen"
+      aktion: "Ableitungslogik anwenden"
+      ergebnis: "Pool-Zuordnung"
+      verantwortlich: "System (automatisch) oder Queue-Koordinator"
+  
+  qualitaetssicherung:
+    stichproben: "Queue-Koordinator prüft stichprobenartig Klassifikationen"
+    korrektur: "Umklassifikation bei Fehlern, Feedback an Agent"
+    eskalation: "Bei systematischen Fehlern → Schulungsbedarf"
+
+# =============================================================================
+# UMKLASSIFIKATION
+# =============================================================================
+
+umklassifikation:
+  
+  beschreibung: >
+    Regeln für die nachträgliche Änderung von Klassifikationen.
+  
+  erlaubte_aenderungen:
+    - szenario: "Neue Informationen ändern Impact/Urgency"
+      aktion: "Priorität anpassen, Pool ggf. wechseln"
+      berechtigt: "Bearbeitender Agent, Queue-Koordinator"
+      dokumentation: "Grund im Ticket vermerken"
+      
+    - szenario: "Analyse ergibt bekanntes Muster"
+      aktion: "Charakteristik ANALYSE → STANDARD"
+      berechtigt: "Bearbeitender Agent"
+      dokumentation: "Nicht erforderlich"
+      
+    - szenario: "Ticket entwickelt sich zum Projekt"
+      aktion: "Charakteristik → PROJEKT, Pool-Wechsel"
+      berechtigt: "Queue-Koordinator, Teamleitung"
+      dokumentation: "Grund im Ticket vermerken"
+      
+    - szenario: "Langläufer (>20 AT)"
+      aktion: "Automatische Kennzeichnung als Langläufer"
+      berechtigt: "System (automatisch)"
+      konsequenz: "Aus operativen KPIs exkludiert"
+      governance: "SSM-G-07"
+
+# =============================================================================
+# GOVERNANCE
+# =============================================================================
+
+governance:
+  
+  entscheidungen:
+    - id: "KLASS-G-01"
+      thema: "Verbindlichkeit der Matrix"
+      entscheidung: >
+        Die Impact-Urgency-Matrix ist verbindlich anzuwenden. 
+        Abweichungen nur durch Queue-Koordinator oder Teamleitung.
+      status: "vorgeschlagen"
+      
+    - id: "KLASS-G-02"
+      thema: "Charakteristik ANALYSE als Label"
+      entscheidung: |
+        Die Charakteristik ANALYSE ist ein beschreibendes Attribut (Label)
+        ohne Steuerungsfunktion für die Pool-Zuordnung. ANALYSE-Tickets
+        werden im Standard-Pool bearbeitet.
+        
+        Nutzen des Labels:
+        - Reporting (Übersicht über Anteil unklarer Tickets)
+        - Identifikation von Wissenslücken
+        - Hinweis auf Dokumentationsbedarf
+      version: "0.2 - ersetzt bisherige Explorative-Diagnose-Regelung"
+      status: "vorgeschlagen"
+      
+    - id: "KLASS-G-03"
+      thema: "Drei-Pool-Modell"
+      entscheidung: |
+        Das Pool-Modell umfasst drei Pools:
+        - Sofort-Pool (P1)
+        - Standard-Pool (P2/P3/P4, alle Charakteristiken außer PROJEKT)
+        - Projekt-Pool (Charakteristik PROJEKT)
+        
+        Der bisherige Analyse-Pool entfällt. Die SLA gibt den zeitlichen
+        Rahmen vor, ein separates Explorationsbudget ist nicht erforderlich.
+      version: "0.2"
+      status: "vorgeschlagen"
+      
+    - id: "KLASS-G-04"
+      thema: "Projekt-Schwelle"
+      entscheidung: >
+        Tickets >20 Arbeitstage Laufzeit werden als Langläufer 
+        klassifiziert und aus operativen KPIs exkludiert.
+      referenz: "SSM-G-07"
+      status: "vorgeschlagen"
+  
+  raci:
+    - aktivitaet: "Klassifikation durchführen"
+      r: "First Level Agent"
+      a: "Queue-Koordinator"
+      c: "-"
+      i: "-"
+      
+    - aktivitaet: "Klassifikation prüfen/korrigieren"
+      r: "Queue-Koordinator"
+      a: "Service Desk Manager"
+      c: "First Level Agent"
+      i: "-"
+      
+    - aktivitaet: "Matrix pflegen/anpassen"
+      r: "Service Desk Manager"
+      a: "Service-Portfolio-Manager"
+      c: "Queue-Koordinator, Service Owner"
+      i: "First Level Agents"
+
+# =============================================================================
+# SCHNITTSTELLEN
+# =============================================================================
+
+schnittstellen:
+  
+  intern:
+    - modul: "sub-practice_incident-management.yaml"
+      art: "wird referenziert von"
+      beschreibung: "Incident-Prozess nutzt Klassifikation für Priorisierung und Pool-Zuweisung"
+      
+    - modul: "sub-practice_request-management.yaml"
+      art: "wird referenziert von"
+      beschreibung: "Request-Prozess nutzt Klassifikation für Priorisierung und Pool-Zuweisung"
+      
+    - modul: "spm_practice_service-level-management.yaml"
+      art: "liefert an"
+      beschreibung: "SLA-Rahmen für Prioritätsstufen"
+      
+    - modul: "ssm_schema_ticket.yaml"
+      art: "definiert Attribute für"
+      beschreibung: "Priorität, Charakteristik, Pool als Ticket-Attribute"
+
+    - modul: "sub-practice_service-desk.yaml"
+      art: "wird referenziert von"
+      beschreibung: "Triage-Prozess nutzt Klassifikation und Pool-Zuweisung"
+
+    - modul: "ssm_governance.yaml"
+      art: "wird referenziert von"
+      beschreibung: "Zeitbasierte Eskalation referenziert Pool-Schwellwerte"
+
+    - modul: "spm_schema_service-definition.yaml"
+      art: "erhält von"
+      beschreibung: "Service-Kritikalitätsstufe für Impact-Vorschlag bei Incidents"
+
+  extern:
+    - partner: "ITSM-Tool"
+      kontext: "Umsetzung der Matrix, automatische Pool-Zuweisung, Eskalations-Trigger"
+      status: "Tool-Auswahl ausstehend"
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+  - version: "0.4"
+    datum: "2026-01-29"
+    aenderung: |
+      Überarbeitung Impact- und Urgency-Kriterien:
+      
+      Impact HOCH:
+      - Entfernt: ">10 Nutzer" als eigenständiges Kriterium (Vertrauen auf Kritikalitätsstufe)
+      - Neu: "Bürger durch Ausfall direkt betroffen" mit Beispielen
+      - Präzisiert: Leitungsebene mit Verweis auf lebendes Arbeitsdokument (SOR-Entscheidung)
+      - Hinweise zu Bürger-Kriterium und Leitungsebene ergänzt
+      
+      Impact NORMAL:
+      - Geändert: ">1 Nutzer oder Teams/Bereiche" (statt 2-10)
+      - Neu: Kritikalitätsstufe 'wichtig' als Kriterium
+      
+      Impact NIEDRIG:
+      - Neu: Kritikalitätsstufe 'unterstuetzend' als Kriterium
+      - Konsolidiert: Komfort + Einzelnutzer
+      
+      Urgency HOCH:
+      - Konsolidiert: Arbeitsfähigkeit + Workaround in einem Kriterium
+      - Präzisiert: "externe Frist, rechtliche Vorgabe, Termin mit Externen"
+      
+      Urgency NIEDRIG:
+      - Entfernt: Komfort (nur noch bei Impact)
+      - Fokus auf zeitliche Aspekte
+      
+      Service-Kritikalitäts-Mapping:
+      - Angepasst: Entfernung ">10 Betroffene"-Hinweis bei 'wichtig'
+    autor: "DIGITOM-Projekt"
+    kontext: "Präzisierung der Priorisierungslogik für 1st Level Support"
+
+  - version: "0.3"
+    datum: "2026-01-28"
+    aenderung: |
+      Integration Service-Kritikalität:
+      - Impact-Kriterium HOCH: Ergänzung "Service mit Kritikalitätsstufe 'geschaeftskritisch'"
+      - Neuer Abschnitt 'service_kritikalitaet_mapping' für systematische Verknüpfung
+      - Schnittstelle zu spm_schema_service-definition.yaml dokumentiert
+    autor: "DIGITOM-Projekt"
+    kontext: "Konsistente Incident-Priorisierung basierend auf Service-Portfolio"
+
+  - version: "0.2"
+    datum: "2026-01-28"
+    aenderung: |
+      Vereinfachung des Pool-Modells:
+      - Reduktion von vier auf drei Pools (Analyse-Pool entfällt)
+      - Charakteristik ANALYSE wird zum beschreibenden Label (keine Pool-Steuerung)
+      - Explorationsbudget entfällt als eigenständiges Konzept (SLA gibt Rahmen vor)
+      - Pool-Zuordnung erfolgt primär über Priorität
+      - Enablement-Philosophie bleibt erhalten (Agent entscheidet eigenverantwortlich)
+    autor: "DIGITOM-Projekt"
+    governance: "Konzeptionelle Vereinfachung nach Review"
+    
+  - version: "0.1"
+    datum: "2025-12-07"
+    aenderung: "Initiale Erstellung"
+    autor: "DIGITOM-Projekt"

#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_rollen.yaml

@@ -0,0 +1,500 @@
+# =============================================================================
+# SERVICE-SUPPORT-MANAGEMENT: ROLLEN
+# =============================================================================
+
+metadata:
+  id: "SSM-ROLLEN"
+  name: "Rollen Service-Support-Management"
+  version: "0.2"
+  status: "draft"
+  erstellt: "2025-12-07"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+
+  beschreibung: |
+    Konsolidierte Rollendefinitionen für das Service-Support-Management.
+    Erweitert und konkretisiert die generischen Rollen aus
+    spm_rollen.yaml für den Support-Kontext.
+
+  referenz_basis: "02_spm_service-lifecycle-blueprint/spm_rollen.yaml"
+
+  design_referenz: "ssm_design-zieldimensionen.yaml"
+  relevante_saeulen: ["LS-03"]
+
+# =============================================================================
+# ROLLENKATEGORIEN
+# =============================================================================
+
+rollenkategorien:
+
+  - kategorie: "Operative Rollen"
+    beschreibung: "Rollen in der direkten Ticket-Bearbeitung"
+    rollen: ["first_level_agent", "second_level_agent"]
+
+  - kategorie: "Koordinations-Rollen"
+    beschreibung: "Rollen in der Steuerung und Koordination"
+    rollen: ["queue_koordinator"]
+
+  - kategorie: "Management-Rollen"
+    beschreibung: "Rollen mit Führungs- und Prozessverantwortung"
+    rollen: ["support_manager", "service_owner"]
+
+# =============================================================================
+# ROLLENDEFINITIONEN
+# =============================================================================
+
+rollen:
+
+  # ---------------------------------------------------------------------------
+  # OPERATIVE ROLLEN
+  # ---------------------------------------------------------------------------
+
+  - id: "first_level_agent"
+    name: "First Level Agent"
+    kurzform: "L1-Agent"
+    kategorie: "Operative Rollen"
+
+    beschreibung: |
+      Bearbeiter im First Level Support. Erster Ansprechpartner für
+      Nutzer, verantwortlich für Ticket-Erfassung, Erstdiagnose und
+      Lösung dokumentierter Störungen.
+
+    verantwortlichkeiten:
+      - "Ticket-Erfassung und Qualifizierung (DoR-Prüfung)"
+      - "Klassifikation und Priorisierung nach Matrix"
+      - "KB-Konsultation und Erstdiagnose"
+      - "Lösung von Incidents im L1-Scope"
+      - "Bearbeitung von Standard-Requests"
+      - "Dokumentation aller Aktivitäten im Ticket"
+      - "Eskalation an L2 mit vollständiger DoH"
+      - "Erstellung von KB-Artikeln (Ebene 3)"
+
+    befugnisse:
+      - "Ticket-Annahme und Selbstzuweisung (Standard-/Sofort-Pool)"
+      - "Priorisierung nach Impact-Urgency-Matrix"
+      - "Funktionale Eskalation an L2"
+      - "Änderung von KB-Artikeln Ebene 3"
+
+    einschraenkungen:
+      - "Keine Priorisierungs-Abweichung von Matrix ohne Genehmigung"
+      - "Keine Ticket-Rückgabe ohne Empfänger-Akzeptanz"
+      - "Keine Änderung von KB-Artikeln Ebene 1/2"
+
+    scope_definition:
+      kann_loesen_wenn:
+        - "KB-Artikel oder dokumentierte Lösung vorhanden"
+        - "Erforderliche technische Berechtigung vorhanden"
+        - "Lösung liegt im definierten L1-Scope"
+      eskaliert_wenn:
+        - "Keine passende Dokumentation vorhanden"
+        - "Berechtigung fehlt"
+        - "Explorative Diagnose (90-120 Min) ausgeschöpft ohne Fortschritt"
+        - "P1 nicht in 15 Min lösbar"
+
+    qualifikation:
+      - "Grundkenntnisse der unterstützten Services"
+      - "ITSM-Tool-Schulung"
+      - "Kommunikationsfähigkeit"
+      - "KB-Nutzung und -Pflege"
+
+    yasm_entsprechung: "1st Level Support"
+    itil4_entsprechung: "Service Desk Agent"
+
+  # ---------------------------------------------------------------------------
+
+  - id: "second_level_agent"
+    name: "Second Level Agent"
+    kurzform: "L2-Agent"
+    kategorie: "Operative Rollen"
+
+    beschreibung: |
+      Spezialist im Second Level Support. Bearbeitet komplexe
+      Incidents, die im L1 nicht lösbar sind. Tiefergehende
+      technische Diagnose und Lösung.
+
+    verantwortlichkeiten:
+      - "Bearbeitung eskalierter Incidents"
+      - "Tiefergehende technische Diagnose"
+      - "Lösung komplexer Störungen"
+      - "Zusammenarbeit mit Betrieb, Fachverfahren, Lieferanten"
+      - "Erstellung von Problem Records bei Bedarf"
+      - "Dokumentation von Lösungen und Workarounds"
+      - "Erstellung/Pflege von KB-Artikeln (Ebene 2 und 3)"
+      - "Unterstützung bei Major Incidents"
+      - "Problem Records erstellen (bei Erkennung in Incident-Bearbeitung)"
+      - "Root-Cause-Analyse durchführen (bei Delegation durch Service Owner)"
+      - "Known-Error-Artikel erstellen und pflegen"
+
+    befugnisse:
+      - "Ticket-Annahme aus L2-Pool"
+      - "Eskalation an L3/Externe"
+      - "Problem Record erstellen"
+      - "Change Request initiieren"
+      - "KB-Artikel Ebene 2 erstellen (mit SO-Freigabe)"
+      - "KB-Artikel Ebene 3 erstellen und ändern"
+
+    einschraenkungen:
+      - "Keine Ticket-Rückgabe an L1 ohne Akzeptanz + Begründung"
+      - "Keine Freigabe von KB-Artikeln Ebene 1"
+
+    qualifikation:
+      - "Vertiefte technische Kenntnisse in Fachgebiet"
+      - "Diagnose- und Problemlösungskompetenz"
+      - "Erfahrung mit Root-Cause-Analyse"
+
+    spezialisierungen:
+      beschreibung: |
+        L2-Agents können nach Fachgebiet spezialisiert sein.
+        Die Zuweisung erfolgt über Domain-Pools.
+      beispiele:
+        - "Netzwerk & Infrastruktur"
+        - "Client & Workplace"
+        - "Fachverfahren (SAP, GIS, etc.)"
+        - "E-Mail & Collaboration"
+
+    yasm_entsprechung: "2nd Level Support"
+    itil4_entsprechung: "Technical Support Specialist"
+
+  # ---------------------------------------------------------------------------
+  # KOORDINATIONS-ROLLEN
+  # ---------------------------------------------------------------------------
+
+  - id: "queue_koordinator"
+    name: "Queue-Koordinator"
+    kurzform: "QK"
+    kategorie: "Koordinations-Rollen"
+
+    beschreibung: |
+      Verantwortlich für die operative Steuerung der Ticket-Queues.
+      Überwacht Workload, priorisiert innerhalb der Pools und
+      koordiniert bei Engpässen oder Konflikten.
+
+    verantwortlichkeiten:
+      - "Überwachung der Ticket-Queues und SLA-Status"
+      - "Aktive Zuweisung im Analyse-Pool"
+      - "Priorisierung bei Konflikten innerhalb eines Pools"
+      - "Entscheidung bei Übergabe-Konflikten"
+      - "Erste Eskalationsstufe für operative Probleme"
+      - "Qualitätssicherung: Stichproben-Review von DoH und KB-Artikeln"
+      - "Koordination bei Kapazitätsengpässen"
+      - "Leitung des monatlichen KB-Reviews (Ebene 3)"
+      - "Wiederkehrende Incident-Muster in Queues erkennen"
+      - "Service Owner auf erkannte Muster hinweisen"
+
+    befugnisse:
+      - "Ticket-Umpriorisierung (mit Begründung)"
+      - "Ticket-Zuweisung und -Umzuweisung"
+      - "Eskalation an Teamleitung"
+      - "Wiedereröffnung geschlossener Tickets"
+      - "Freigabe von Abweichungen von Standard-Prozess"
+
+    einschraenkungen:
+      - "Keine eigene Ticket-Bearbeitung (Fokus auf Koordination)"
+      - "Keine SLA-Änderungen"
+
+    modelle:
+      beschreibung: |
+        Je nach Teamgröße und -struktur kann die Rolle unterschiedlich
+        besetzt werden.
+      varianten:
+        - modell: "Dediziert"
+          beschreibung: "Eigenständige Rolle, keine Ticket-Bearbeitung"
+          empfohlen_ab: "Team > 10 Agents"
+        - modell: "Rotierend"
+          beschreibung: "Wechselnde Besetzung durch erfahrene Agents"
+          empfohlen_fuer: "Kleinere Teams"
+        - modell: "Teilzeit"
+          beschreibung: "Kombiniert mit L2-Tätigkeit"
+          empfohlen_fuer: "Mittlere Teams"
+
+    design_referenz: "LS-03 (Organisation & Teamstruktur)"
+
+    qualifikation:
+      - "Erfahrung im First oder Second Level Support (mind. 2 Jahre)"
+      - "Überblick über alle unterstützten Services"
+      - "Priorisierungs- und Entscheidungskompetenz"
+      - "Kommunikationsfähigkeit und Durchsetzungsvermögen"
+      - "ITSM-Tool: Fortgeschrittene Kenntnisse (Reporting, Queue-Mgmt)"
+      - "Verständnis von SLA-Strukturen und Eskalationswegen"
+
+    yasm_entsprechung: "-"
+    itil4_entsprechung: "Queue Manager / Shift Lead"
+
+  # ---------------------------------------------------------------------------
+  # MANAGEMENT-ROLLEN
+  # ---------------------------------------------------------------------------
+
+  - id: "support_manager"
+    name: "Support Manager"
+    kurzform: "SM"
+    kategorie: "Management-Rollen"
+
+    beschreibung: |
+      Gesamtverantwortung für den Service-Support-Bereich.
+      Prozess-Owner für Incident, Request und Problem Management.
+      Führungsverantwortung für das Support-Team.
+
+    verantwortlichkeiten:
+      - "Prozess-Ownership für SSM-Practices"
+      - "Führung des Support-Teams"
+      - "Kapazitätsplanung und Ressourcenmanagement"
+      - "Eskalationsstufe für nicht lösbare Konflikte"
+      - "Reporting und KPI-Verantwortung"
+      - "Kontinuierliche Prozessverbesserung"
+      - "Schnittstelle zu Service Ownern"
+      - "Budget-Verantwortung für Support-Bereich"
+
+    befugnisse:
+      - "Prozess-Änderungen (mit Governance-Dokumentation)"
+      - "Ressourcen-Allokation"
+      - "SLA-Verhandlung (in Abstimmung mit Service Owner)"
+      - "Eskalation an Abteilungsleitung"
+
+    accountable_fuer:
+      - "Incident Management (P-04)"
+      - "Request Management (P-05)"
+      - "Problem Management (P-06)"
+      - "Service Desk (P-SD)"
+      - "KB Ebene 3 Qualität"
+
+    einschraenkungen:
+      - "Keine operative Ticket-Bearbeitung (Fokus auf Steuerung)"
+      - "SLA-Änderungen nur in Abstimmung mit Service Owner"
+      - "Prozess-Änderungen erfordern Governance-Dokumentation"
+      - "Budget-Entscheidungen über definiertem Schwellwert erfordern Genehmigung"
+
+    qualifikation:
+      - "Mehrjährige Erfahrung im IT-Service-Management"
+      - "Führungserfahrung (Team > 5 Personen)"
+      - "ITIL Foundation oder vergleichbare Zertifizierung"
+      - "Kenntnisse in Prozessmanagement und -optimierung"
+      - "Erfahrung mit KPI-Definition und Reporting"
+      - "Kommunikations- und Konfliktlösungskompetenz"
+
+    yasm_entsprechung: "Service Desk Manager"
+    itil4_entsprechung: "Service Desk Manager"
+
+  # ---------------------------------------------------------------------------
+
+  - id: "service_owner"
+    name: "Service Owner"
+    kurzform: "SO"
+    kategorie: "Management-Rollen"
+
+    beschreibung: |
+      End-to-End-Verantwortung für einen spezifischen Service.
+      Im Support-Kontext: Fachliche Eskalationsinstanz und
+      Verantwortlicher für Service-spezifische Dokumentation.
+
+    verantwortlichkeiten_support:
+      - "Fachliche Eskalationsinstanz bei Major Incidents"
+      - "Verantwortung für KB Ebene 1 (Grundlagendokumentation)"
+      - "Co-Creation KB Ebene 2 (Arbeitsdokumentation)"
+      - "SLA-Vereinbarung und -Überwachung für den Service"
+      - "Entscheidung bei Service-spezifischen Priorisierungskonflikten"
+      - "Kommunikation bei schwerwiegenden Service-Störungen"
+      - "Process Owner für Problem Management im eigenen Service-Bereich"
+      - "Koordination und ggf. Durchführung von Root-Cause-Analysen"
+      - "Sicherstellung der Workaround-Dokumentation"
+      - "Entscheidung über permanente Lösungen (Change-Initiierung)"
+      - "Problem-Priorisierung und -Überwachung"
+
+    befugnisse_support:
+      - "Fachliche Eskalationsentscheidung bei Major Incidents"
+      - "Freigabe von KB-Artikeln Ebene 1 und 2"
+      - "Priorisierungs-Override für Service-spezifische Tickets (mit Begründung)"
+      - "Change-Initiierung aus Problem Management"
+      - "SLA-Vereinbarung und -Anpassung für den Service"
+      - "Delegation von Problem-Management-Aufgaben an L2-Agents"
+      - "Problem Records priorisieren und schließen"
+
+    einschraenkungen_support:
+      - "Keine operative Ticket-Bearbeitung (außer im MVP als Teil des L2-Teams)"
+      - "Keine Pool-Steuerung (Verantwortung Queue-Koordinator)"
+      - "Keine Änderung von SSM-Prozessen ohne Abstimmung mit Support Manager"
+
+    qualifikation_support:
+      - "Tiefes Fachwissen zum verantworteten Service"
+      - "Verständnis der End-to-End-Servicekette"
+      - "Kommunikationsfähigkeit (intern und zu Kunden/Ämtern)"
+      - "Grundverständnis von ITSM-Prozessen"
+
+    schnittstelle_support:
+      von_support: "Eskalationen, Problem Records, Verbesserungsvorschläge"
+      an_support: "Service-Updates, Dokumentation, SLA-Änderungen"
+
+    referenz: "spm_rollen.yaml → service_owner"
+
+    yasm_entsprechung: "Service Owner"
+    itil4_entsprechung: "Service Owner"
+
+# =============================================================================
+# KONTEXTABHÄNGIGE FUNKTIONEN
+# =============================================================================
+
+kontextabhaengige_funktionen:
+
+  beschreibung: |
+    Folgende Funktionen erscheinen in RACI-Matrizen und Prozessbeschreibungen,
+    sind aber keine festen SSM-Rollen. Sie werden je Kontext oder
+    Katalog-Eintrag zugewiesen.
+
+  funktionen:
+
+    - funktion: "Genehmiger"
+      beschreibung: |
+        Zuständig für die Genehmigung von Service Requests. Wird je
+        Katalog-Eintrag definiert. Die Genehmiger-Zuordnung ist Teil
+        des Service-Katalogs, nicht der SSM-Rollendefinition.
+      typische_genehmiger:
+        - "Vorgesetzter des Antragstellers"
+        - "IT-Sicherheitsbeauftragter"
+        - "Amtsleitung / Budgetverantwortlicher"
+        - "Service Owner (für Service-spezifische Genehmigungen)"
+      referenz: "sub-practice_request-management.yaml → kernkonzepte.genehmigungsprinzipien"
+      governance: "SSM-G-15"
+
+    - funktion: "Lieferant / L3-Support"
+      beschreibung: |
+        Externe Hersteller oder Dienstleister für Eskalation bei
+        herstellerspezifischen Problemen oder vertraglich vereinbartem
+        Support.
+      einbindung:
+        - "Eskalation durch L2 bei Herstellerfehlern"
+        - "Vertraglich vereinbarter Support (SLA)"
+        - "Lizenz- oder Wartungsverträge"
+      referenz: "spm_rollen.yaml → externe.lieferant"
+
+  hinweis_teamleitung:
+    beschreibung: |
+      In Prozessbeschreibungen wird teilweise der Begriff "Teamleitung"
+      verwendet. Im SSM-Kontext ist dies kontextabhängig zu verstehen:
+
+    mapping:
+      - begriff: "Teamleitung"
+        kontext: "Hierarchische Eskalation im Service Desk"
+        entspricht: "Support Manager"
+
+      - begriff: "Gruppenleitung"
+        kontext: "Organisatorische Einheit Service Desk"
+        entspricht: "Support Manager oder dedizierte Gruppenleitung"
+
+    hinweis: |
+      Die konkrete Besetzung hängt von der Organisationsstruktur bei
+      DIGIT ab. Im MVP kann der Support Manager auch die Gruppenleitung sein.
+
+# =============================================================================
+# RACI-REFERENZ
+# =============================================================================
+
+raci_referenz:
+
+  beschreibung: |
+    Die konsolidierte RACI-Matrix für alle SSM-Aktivitäten ist in
+    ssm_governance.yaml → raci_konsolidiert definiert.
+
+    Dieses Dokument definiert die Rollen, nicht die Zuordnungen.
+
+  master_dokument: "ssm_governance.yaml"
+  abschnitt: "raci_konsolidiert"
+
+  bereiche:
+    - "incident_management"
+    - "request_management"
+    - "problem_management"
+    - "wissensmanagement"
+    - "service_desk"
+    - "eskalation"
+    - "reporting"
+
+# =============================================================================
+# SCHNITTSTELLEN
+# =============================================================================
+
+schnittstellen:
+
+  intern:
+    - modul: "spm_rollen.yaml"
+      art: "erweitert"
+      beschreibung: |
+        SSM-spezifische Konkretisierung der SPM-Basisrollen.
+        Übergeordnete Rollen (SPM, Mission Board) sind dort definiert
+        und werden in ssm_governance.yaml für die Eskalationskette
+        referenziert.
+
+    - modul: "sub-practice_incident-management.yaml"
+      art: "wird referenziert von"
+      beschreibung: "RACI-Zuordnungen in Incident-Aktivitäten"
+
+    - modul: "sub-practice_request-management.yaml"
+      art: "wird referenziert von"
+      beschreibung: "RACI-Zuordnungen in Request-Aktivitäten"
+
+    - modul: "ssm_wissensmanagement.yaml"
+      art: "wird referenziert von"
+      beschreibung: "KB-Governance je Ebene"
+
+    - modul: "sub-practice_service-desk.yaml"
+      art: "wird referenziert von"
+      beschreibung: "Service Desk Organisationsmodell nutzt Rollen"
+
+    - modul: "ssm_governance.yaml"
+      art: "wird referenziert von"
+      beschreibung: "Eskalationskette basiert auf Rollenmodell"
+
+  extern:
+    - partner: "Service-Portfolio-Management (SPM)"
+      kontext: "Übergeordnete Steuerung, strategische Entscheidungen"
+      rollen_dort: ["spm (Service-Portfolio-Manager)"]
+      referenz: "spm_rollen.yaml"
+
+    - partner: "Mission Board"
+      kontext: "Höchste Eskalationsstufe, strategische Grundsatzentscheidungen"
+      referenz: "spm_rollen.yaml → sor (Service Operations Runde)"
+
+# =============================================================================
+# OFFENE PUNKTE
+# =============================================================================
+
+offene_punkte:
+
+  - id: "OPEN-ROLLEN-001"
+    thema: "Queue-Koordinator-Modell für DIGIT"
+    beschreibung: "Welches Modell (dediziert/rotierend/teilzeit) passt für DIGIT?"
+    prioritaet: "hoch"
+    status: "Mit DIGIT abstimmen"
+
+  - id: "OPEN-ROLLEN-002"
+    thema: "L2-Spezialisierungen"
+    beschreibung: "Konkrete Domain-Pools für DIGIT definieren"
+    prioritaet: "mittel"
+    status: "Nach Service-Katalog-Analyse"
+
+  - id: "OPEN-ROLLEN-003"
+    thema: "Genehmiger-Zuordnung je Katalog-Eintrag"
+    beschreibung: |
+      Die konkreten Genehmiger für jeden Katalog-Eintrag müssen
+      im Rahmen der Service-Katalog-Implementierung definiert werden.
+    prioritaet: "mittel"
+    status: "Abhängig von SCM (P-01)"
+    abhaengig_von: "spm_practice_service-catalog-management.yaml"
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+  - version: "0.2"
+    datum: "2025-12-07"
+    aenderung: |
+      - Queue-Koordinator: Qualifikation ergänzt
+      - Support Manager: Einschränkungen und Qualifikation ergänzt
+      - Service Owner: Befugnisse und Einschränkungen für Support-Kontext ergänzt
+      - Neuer Abschnitt: Kontextabhängige Funktionen (Genehmiger, Lieferant, Teamleitung)
+      - Schnittstellen zu übergeordneten Rollen (SPM, MB) expliziert
+    autor: "DIGITOM-Projekt"
+
+  - version: "0.1"
+    datum: "2025-12-07"
+    aenderung: "Initiale Erstellung mit Minimal-Rollensatz"
+    autor: "DIGITOM-Projekt"

#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/ssm_schema_ticket.yaml

@@ -0,0 +1,990 @@
+# =============================================================================
+# SSM SCHEMA: TICKET
+# =============================================================================
+# Modul: Service-Support-Management (SSM)
+# Typ: Schema (Informationsmodell)
+# Version: 0.1
+# Datum: 2025-12-07
+# Status: draft
+# =============================================================================
+
+meta:
+  schema_id: "SSM-S-01"
+  name: "Ticket-Schema"
+  typ: "Schema"
+  
+  zweck: |
+    Definiert die Datenstruktur für Support-Tickets (Incidents und Requests).
+    Das Schema dient als Grundlage für:
+    - ITSM-Tool-Konfiguration (Pflichtfelder, Feldtypen)
+    - Definition of Ready (DoR) – Qualitätskriterien bei Ticket-Erfassung
+    - Reporting und KPI-Auswertung
+    - Prozess-Schnittstellen (Eskalation, Übergabe)
+  
+  gilt_fuer:
+    - "sub-practice_incident-management.yaml"
+    - "sub-practice_request-management.yaml"
+    - "sub-practice_service-desk.yaml"
+  
+  klassifikation_referenz: "ssm_klassifikation-priorisierung.yaml"
+  rollen_referenz: "ssm_rollen.yaml"
+  
+  design_prinzip: |
+    Das Schema unterscheidet drei Attribut-Kategorien:
+    1. Basis-Attribute: Für alle Ticket-Typen identisch
+    2. Typ-spezifische Attribute: Nur für Incident oder Request
+    3. Prozess-Attribute: Werden im Lifecycle befüllt (nicht bei Erfassung)
+    
+    Pflichtfelder sind so definiert, dass sie die DoR (Definition of Ready) 
+    erfüllen, ohne den Erfassungsprozess zu überlasten.
+
+# =============================================================================
+# BASIS-ATTRIBUTE (ALLE TICKET-TYPEN)
+# =============================================================================
+
+basis_attribute:
+  
+  beschreibung: |
+    Diese Attribute gelten für alle Ticket-Typen (Incident, Request, Projekt).
+    Sie werden bei Ticket-Erfassung oder im frühen Lifecycle befüllt.
+
+  # ---------------------------------------------------------------------------
+  # IDENTIFIKATION
+  # ---------------------------------------------------------------------------
+  identifikation:
+    
+    beschreibung: "Eindeutige Identifikation und Grunddaten"
+    
+    attribute:
+      
+      - name: "ticket_id"
+        typ: "string"
+        pflicht: true
+        erfassung: "automatisch"
+        beschreibung: "Eindeutiger Identifier, vom System vergeben"
+        format: "INC-YYYYMMDD-XXXXX oder REQ-YYYYMMDD-XXXXX"
+        beispiel: "INC-20251207-00423"
+      
+      - name: "ticket_typ"
+        typ: "enum"
+        pflicht: true
+        erfassung: "manuell"
+        beschreibung: "Grundlegende Ticket-Klassifikation"
+        werte:
+          - id: "INCIDENT"
+            name: "Störung"
+          - id: "REQUEST"
+            name: "Service-Anfrage"
+          - id: "PROJEKT"
+            name: "Projekt-Ticket"
+        referenz: "ssm_klassifikation-priorisierung.yaml → ticket_typen"
+      
+      - name: "titel"
+        typ: "string"
+        pflicht: true
+        erfassung: "manuell"
+        beschreibung: "Kurze, aussagekräftige Zusammenfassung"
+        max_laenge: 120
+        beispiel: "Outlook stürzt beim Öffnen von Anhängen ab"
+        qualitaetskriterium: |
+          Der Titel muss das Problem/die Anfrage erkennbar machen, 
+          ohne die Beschreibung lesen zu müssen.
+      
+      - name: "beschreibung"
+        typ: "text"
+        pflicht: true
+        erfassung: "manuell"
+        beschreibung: "Ausführliche Beschreibung des Problems oder der Anfrage"
+        min_laenge: 50
+        qualitaetskriterium: |
+          Die Beschreibung muss ausreichend Kontext liefern, um 
+          ohne Rückfrage mit der Bearbeitung beginnen zu können.
+
+  # ---------------------------------------------------------------------------
+  # MELDER & BETROFFENER
+  # ---------------------------------------------------------------------------
+  personen:
+    
+    beschreibung: "Beteiligte Personen"
+    
+    attribute:
+      
+      - name: "melder"
+        typ: "objekt"
+        pflicht: true
+        erfassung: "automatisch/manuell"
+        beschreibung: "Person, die das Ticket erstellt hat"
+        schema:
+          - name: "person_id"
+            typ: "string"
+            beschreibung: "Referenz auf Verzeichnisdienst (AD)"
+          - name: "name"
+            typ: "string"
+          - name: "email"
+            typ: "string"
+          - name: "telefon"
+            typ: "string"
+            pflicht: false
+          - name: "amt"
+            typ: "string"
+            beschreibung: "Organisationseinheit des Melders"
+          - name: "standort"
+            typ: "string"
+            pflicht: false
+      
+      - name: "betroffener"
+        typ: "objekt"
+        pflicht: true
+        erfassung: "manuell"
+        beschreibung: |
+          Person, die von der Störung betroffen ist oder die Anfrage stellt.
+          Kann identisch mit Melder sein (Standardfall).
+        schema:
+          - name: "person_id"
+            typ: "string"
+          - name: "name"
+            typ: "string"
+          - name: "amt"
+            typ: "string"
+        default: "Melder"
+      
+      - name: "vip_flag"
+        typ: "boolean"
+        pflicht: false
+        erfassung: "automatisch"
+        beschreibung: |
+          Kennzeichnung für besondere Behandlung (z.B. Amtsleitung, OB-Bereich).
+          Beeinflusst nicht die Priorität, aber die Kommunikation.
+        default: false
+
+  # ---------------------------------------------------------------------------
+  # KLASSIFIKATION
+  # ---------------------------------------------------------------------------
+  klassifikation:
+    
+    beschreibung: "Klassifikations-Attribute gemäß Priorisierungs-Framework"
+    referenz: "ssm_klassifikation-priorisierung.yaml"
+    
+    attribute:
+      
+      - name: "impact"
+        typ: "enum"
+        pflicht: true
+        erfassung: "manuell"
+        beschreibung: "Auswirkung auf den Geschäftsbetrieb"
+        werte:
+          - id: "HOCH"
+            code: "I-H"
+            kriterien: ">10 Nutzer, geschäftskritisch, Security"
+          - id: "NORMAL"
+            code: "I-N"
+            kriterien: "Einzelnutzer/kleine Gruppe, eingeschränkt"
+          - id: "NIEDRIG"
+            code: "I-L"
+            kriterien: "Komfort, Workaround verfügbar"
+      
+      - name: "urgency"
+        typ: "enum"
+        pflicht: true
+        erfassung: "manuell"
+        beschreibung: "Zeitliche Dringlichkeit"
+        werte:
+          - id: "HOCH"
+            code: "U-H"
+            kriterien: "Sofort, kein Workaround, Deadline"
+          - id: "NORMAL"
+            code: "U-N"
+            kriterien: "Zeitnah, temporärer Workaround"
+          - id: "NIEDRIG"
+            code: "U-L"
+            kriterien: "Kann warten"
+      
+      - name: "prioritaet"
+        typ: "enum"
+        pflicht: true
+        erfassung: "automatisch"
+        beschreibung: "Abgeleitet aus Impact × Urgency"
+        werte:
+          - id: "P1"
+            name: "Kritisch"
+          - id: "P2"
+            name: "Hoch"
+          - id: "P3"
+            name: "Normal"
+          - id: "P4"
+            name: "Niedrig"
+        ableitung: "ssm_klassifikation-priorisierung.yaml → impact_urgency_matrix"
+      
+      - name: "charakteristik"
+        typ: "enum"
+        pflicht: true
+        erfassung: "manuell"
+        beschreibung: "Bearbeitungscharakter des Tickets"
+        werte:
+          - id: "STANDARD"
+            name: "Standard-Ticket"
+            beschreibung: "Bekanntes Muster, klare Lösung"
+          - id: "ANALYSE"
+            name: "Analyse-Ticket"
+            beschreibung: "Unklare Ursache, Diagnose erforderlich"
+          - id: "PROJEKT"
+            name: "Projekt-Ticket"
+            beschreibung: "Planbar, umfangreich, Koordination nötig"
+      
+      - name: "pool"
+        typ: "enum"
+        pflicht: true
+        erfassung: "automatisch"
+        beschreibung: "Zugeordneter Bearbeitungs-Pool"
+        werte:
+          - id: "POOL-SOFORT"
+            name: "Sofort-Pool"
+          - id: "POOL-STANDARD"
+            name: "Standard Service-Pool"
+          - id: "POOL-ANALYSE"
+            name: "Analyse-Pool"
+          - id: "POOL-PROJEKT"
+            name: "Projekt-Pool"
+        ableitung: "ssm_klassifikation-priorisierung.yaml → ableitungslogik"
+
+  # ---------------------------------------------------------------------------
+  # SERVICE-ZUORDNUNG
+  # ---------------------------------------------------------------------------
+  service_zuordnung:
+    
+    beschreibung: "Verknüpfung mit Service-Portfolio"
+    
+    attribute:
+      
+      - name: "service_id"
+        typ: "string"
+        pflicht: false
+        erfassung: "manuell"
+        beschreibung: "Referenz auf betroffenen Service (aus Service-Katalog)"
+        referenz: "spm_schema_service-definition.yaml"
+        beispiel: "SVC-EMAIL-001"
+      
+      - name: "service_name"
+        typ: "string"
+        pflicht: false
+        erfassung: "automatisch"
+        beschreibung: "Name des Services (abgeleitet aus service_id)"
+      
+      - name: "service_komponente"
+        typ: "string"
+        pflicht: false
+        erfassung: "manuell"
+        beschreibung: "Betroffene Komponente innerhalb des Services"
+        beispiel: "Outlook Client"
+      
+      - name: "kategorie"
+        typ: "string"
+        pflicht: false
+        erfassung: "manuell"
+        beschreibung: "Thematische Kategorie (für Reporting)"
+        beispiel: "E-Mail / Netzwerk / Hardware / Software"
+      
+      - name: "unterkategorie"
+        typ: "string"
+        pflicht: false
+        erfassung: "manuell"
+        beschreibung: "Feingranulare Kategorie"
+        beispiel: "Outlook / Exchange / Spam"
+
+  # ---------------------------------------------------------------------------
+  # STATUS & WORKFLOW
+  # ---------------------------------------------------------------------------
+  status:
+    
+    beschreibung: "Status-Informationen und Workflow-Steuerung"
+    
+    attribute:
+      
+      - name: "status"
+        typ: "enum"
+        pflicht: true
+        erfassung: "automatisch"
+        beschreibung: "Aktueller Bearbeitungsstatus"
+        werte:
+          - id: "NEU"
+            name: "Neu"
+            beschreibung: "Ticket erfasst, noch nicht angenommen"
+          - id: "ANGENOMMEN"
+            name: "Angenommen"
+            beschreibung: "Ticket von Bearbeiter übernommen"
+          - id: "WARTEN_GENEHMIGUNG"
+            name: "Warten auf Genehmigung"
+            beschreibung: "Genehmigungsanfrage ausgelöst (nur bei Requests)"
+            request_spezifisch: true
+          - id: "IN_BEARBEITUNG"
+            name: "In Bearbeitung"
+            beschreibung: "Aktive Bearbeitung läuft"
+          - id: "WARTEN_NUTZER"
+            name: "Warten auf Nutzer"
+            beschreibung: "Rückfrage an Melder/Betroffenen"
+          - id: "WARTEN_EXTERN"
+            name: "Warten auf Externe"
+            beschreibung: "Warten auf Drittanbieter/Lieferant"
+          - id: "WARTEN_CHANGE"
+            name: "Warten auf Change"
+            beschreibung: "Lösung erfordert genehmigten Change"
+          - id: "GELOEST"
+            name: "Gelöst"
+            beschreibung: "Lösung implementiert, Bestätigung ausstehend"
+          - id: "GESCHLOSSEN"
+            name: "Geschlossen"
+            beschreibung: "Ticket abgeschlossen"
+          - id: "STORNIERT"
+            name: "Storniert"
+            beschreibung: "Ticket ohne Bearbeitung beendet"
+        default: "NEU"
+        hinweis: |
+          Der Status WARTEN_GENEHMIGUNG ist Request-spezifisch und wird
+          bei Incidents nicht verwendet.
+      
+      - name: "substatus"
+        typ: "string"
+        pflicht: false
+        erfassung: "manuell"
+        beschreibung: "Optionaler Detail-Status"
+        beispiel: "Wartet auf Rückruf / Termin vereinbart"
+      
+      - name: "langlaeufer_flag"
+        typ: "boolean"
+        pflicht: false
+        erfassung: "automatisch"
+        beschreibung: "Kennzeichnung für Tickets >20 AT Laufzeit"
+        default: false
+        governance: "SSM-G-04"
+
+  status_transitionen:
+
+    beschreibung: |
+      Erlaubte Status-Übergänge. Das ITSM-Tool sollte diese
+      Transitionen technisch durchsetzen.
+
+    referenz: "sub-practice_incident-management.yaml → status_lifecycle"
+
+    transitionen:
+      NEU: ["ANGENOMMEN", "STORNIERT"]
+      ANGENOMMEN: ["WARTEN_GENEHMIGUNG", "IN_BEARBEITUNG", "WARTEN_NUTZER", "STORNIERT"]
+      WARTEN_GENEHMIGUNG: ["IN_BEARBEITUNG", "STORNIERT"]
+      IN_BEARBEITUNG: ["WARTEN_NUTZER", "WARTEN_EXTERN", "WARTEN_CHANGE", "GELOEST"]
+      WARTEN_NUTZER: ["IN_BEARBEITUNG", "STORNIERT"]
+      WARTEN_EXTERN: ["IN_BEARBEITUNG"]
+      WARTEN_CHANGE: ["IN_BEARBEITUNG", "GELOEST"]
+      GELOEST: ["GESCHLOSSEN", "IN_BEARBEITUNG"]
+      GESCHLOSSEN: ["IN_BEARBEITUNG"]
+      STORNIERT: []
+
+    hinweis_request_spezifisch: |
+      Die Transition ANGENOMMEN → WARTEN_GENEHMIGUNG und alle Transitionen
+      von WARTEN_GENEHMIGUNG sind nur bei Requests relevant.
+
+    einbahnstrassen:
+      - von: "ANGENOMMEN"
+        nicht_nach: "NEU"
+        grund: "Ownership-Prinzip: Nach Annahme keine Rückgabe an Queue"
+
+  # ---------------------------------------------------------------------------
+  # ZEITEN
+  # ---------------------------------------------------------------------------
+  zeiten:
+    
+    beschreibung: "Zeitstempel für SLA-Messung und Reporting"
+    
+    attribute:
+      
+      - name: "erstellt_am"
+        typ: "datetime"
+        pflicht: true
+        erfassung: "automatisch"
+        beschreibung: "Zeitpunkt der Ticket-Erstellung"
+      
+      - name: "erste_reaktion_am"
+        typ: "datetime"
+        pflicht: false
+        erfassung: "automatisch"
+        beschreibung: "Zeitpunkt der ersten qualifizierten Reaktion"
+        sla_relevant: true
+      
+      - name: "angenommen_am"
+        typ: "datetime"
+        pflicht: false
+        erfassung: "automatisch"
+        beschreibung: "Zeitpunkt der Ticket-Übernahme"
+      
+      - name: "geloest_am"
+        typ: "datetime"
+        pflicht: false
+        erfassung: "automatisch"
+        beschreibung: "Zeitpunkt der Lösungsbereitstellung"
+        sla_relevant: true
+      
+      - name: "geschlossen_am"
+        typ: "datetime"
+        pflicht: false
+        erfassung: "automatisch"
+        beschreibung: "Zeitpunkt des Ticket-Abschlusses"
+      
+      - name: "sla_reaktion_ziel"
+        typ: "datetime"
+        pflicht: false
+        erfassung: "automatisch"
+        beschreibung: "Berechnetes SLA-Ziel für Reaktionszeit"
+      
+      - name: "sla_loesung_ziel"
+        typ: "datetime"
+        pflicht: false
+        erfassung: "automatisch"
+        beschreibung: "Berechnetes SLA-Ziel für Lösungszeit"
+      
+      - name: "wartezeit_gesamt"
+        typ: "duration"
+        pflicht: false
+        erfassung: "automatisch"
+        beschreibung: |
+          Summe aller Wartezeiten (WARTEN_NUTZER, WARTEN_EXTERN).
+          Wird von SLA-Zeit abgezogen ("Clock Stop").
+      
+      - name: "bearbeitungszeit_netto"
+        typ: "duration"
+        pflicht: false
+        erfassung: "automatisch"
+        beschreibung: "Tatsächliche Bearbeitungszeit ohne Wartezeiten"
+
+  # ---------------------------------------------------------------------------
+  # ZUWEISUNG
+  # ---------------------------------------------------------------------------
+  zuweisung:
+    
+    beschreibung: "Bearbeiter und Team-Zuordnung"
+    
+    attribute:
+      
+      - name: "zugewiesen_an"
+        typ: "objekt"
+        pflicht: false
+        erfassung: "manuell"
+        beschreibung: "Aktuell zuständiger Bearbeiter"
+        schema:
+          - name: "person_id"
+            typ: "string"
+          - name: "name"
+            typ: "string"
+          - name: "team"
+            typ: "string"
+      
+      - name: "support_team"
+        typ: "enum"
+        pflicht: false
+        erfassung: "manuell"
+        beschreibung: "Zuständiges Support-Team"
+        werte:
+          - id: "L1"
+            name: "First Level Support"
+          - id: "L2"
+            name: "Second Level Support"
+          - id: "L2-SPEC"
+            name: "Spezialistengruppe"
+          - id: "L3"
+            name: "Third Level / Extern"
+      
+      - name: "eskaliert_an"
+        typ: "objekt"
+        pflicht: false
+        erfassung: "manuell"
+        beschreibung: "Person/Gruppe bei Eskalation"
+        schema:
+          - name: "person_id"
+            typ: "string"
+          - name: "name"
+            typ: "string"
+          - name: "eskalationsgrund"
+            typ: "string"
+          - name: "eskaliert_am"
+            typ: "datetime"
+
+# =============================================================================
+# INCIDENT-SPEZIFISCHE ATTRIBUTE
+# =============================================================================
+
+incident_attribute:
+  
+  beschreibung: |
+    Zusätzliche Attribute, die nur für Incidents relevant sind.
+    Diese ergänzen die Basis-Attribute.
+  
+  gilt_fuer: "ticket_typ = INCIDENT"
+  
+  attribute:
+    
+    - name: "symptom"
+      typ: "text"
+      pflicht: false
+      erfassung: "manuell"
+      beschreibung: "Beobachtetes Symptom (was sieht der Nutzer?)"
+      beispiel: "Fehlermeldung 'Verbindung zum Server unterbrochen'"
+    
+    - name: "fehlermeldung"
+      typ: "text"
+      pflicht: false
+      erfassung: "manuell"
+      beschreibung: "Exakter Wortlaut der Fehlermeldung"
+    
+    - name: "reproduzierbar"
+      typ: "enum"
+      pflicht: false
+      erfassung: "manuell"
+      beschreibung: "Ist das Problem reproduzierbar?"
+      werte:
+        - id: "IMMER"
+          name: "Immer reproduzierbar"
+        - id: "MANCHMAL"
+          name: "Sporadisch"
+        - id: "EINMALIG"
+          name: "Bisher einmalig"
+        - id: "UNBEKANNT"
+          name: "Nicht getestet"
+    
+    - name: "workaround_vorhanden"
+      typ: "boolean"
+      pflicht: false
+      erfassung: "manuell"
+      beschreibung: "Existiert ein temporärer Workaround?"
+      default: false
+    
+    - name: "workaround_beschreibung"
+      typ: "text"
+      pflicht: false
+      erfassung: "manuell"
+      beschreibung: "Beschreibung des Workarounds (wenn vorhanden)"
+    
+    - name: "ursache"
+      typ: "text"
+      pflicht: false
+      erfassung: "manuell"
+      beschreibung: "Ermittelte Ursache (nach Diagnose)"
+    
+    - name: "loesung"
+      typ: "text"
+      pflicht: true
+      erfassung: "manuell"
+      beschreibung: "Beschreibung der durchgeführten Lösung"
+      bedingung: "Pflicht bei Status = GELOEST oder GESCHLOSSEN"
+    
+    - name: "first_call_resolution"
+      typ: "boolean"
+      pflicht: false
+      erfassung: "automatisch"
+      beschreibung: "Wurde das Ticket im Erstkontakt gelöst?"
+      kpi_relevant: true
+    
+    - name: "problem_referenz"
+      typ: "string"
+      pflicht: false
+      erfassung: "manuell"
+      beschreibung: "Verknüpfung zu Problem-Ticket (wenn vorhanden)"
+      beispiel: "PRB-20251207-00012"
+    
+    - name: "known_error_referenz"
+      typ: "string"
+      pflicht: false
+      erfassung: "manuell"
+      beschreibung: "Referenz auf Known Error Database (KEDB)"
+
+    # -------------------------------------------------------------------------
+    # FEEDBACK-FELDER
+    # -------------------------------------------------------------------------
+
+    - name: "nutzer_feedback"
+      beschreibung: |
+        Optionales Feedback des Nutzers zur Lösungsqualität und
+        Zufriedenheit mit der Bearbeitung. Wird bei Ticket-Abschluss
+        oder nach Auto-Close erhoben.
+
+      typ: "objekt"
+      pflicht: false
+      erfassung: "manuell"
+
+      unterfelder:
+
+        - name: "zufriedenheit"
+          typ: "enum"
+          pflicht: false
+          werte:
+            - id: "SEHR_ZUFRIEDEN"
+              name: "Sehr zufrieden"
+            - id: "ZUFRIEDEN"
+              name: "Zufrieden"
+            - id: "NEUTRAL"
+              name: "Neutral"
+            - id: "UNZUFRIEDEN"
+              name: "Unzufrieden"
+            - id: "SEHR_UNZUFRIEDEN"
+              name: "Sehr unzufrieden"
+
+        - name: "kommentar"
+          typ: "text"
+          pflicht: false
+          max_laenge: 1000
+          beschreibung: "Freitext-Feedback des Nutzers"
+
+        - name: "feedback_datum"
+          typ: "datetime"
+          pflicht: false
+          erfassung: "automatisch"
+          beschreibung: "Zeitpunkt der Feedback-Abgabe"
+
+      erhebung:
+        zeitpunkt: "Nach Ticket-Abschluss oder Auto-Close"
+        methode: "E-Mail mit Feedback-Link oder Portal-Popup"
+        erinnerung: "Optional nach 3 Tagen"
+
+      auswertung:
+        kpi: "Nutzerzufriedenheit (CSAT)"
+        aggregation: "Monatlich pro Service-Bereich"
+        reporting: "ssm_governance.yaml → reporting"
+
+      mvp_status: "OPTIONAL"
+      hinweis: |
+        Im MVP ist die Feedback-Erhebung optional und abhängig von
+        der Tool-Unterstützung. Die Struktur ist definiert, die
+        Implementierung kann nachgelagert erfolgen.
+
+# =============================================================================
+# REQUEST-SPEZIFISCHE ATTRIBUTE
+# =============================================================================
+
+request_attribute:
+  
+  beschreibung: |
+    Zusätzliche Attribute, die nur für Service Requests relevant sind.
+    Diese ergänzen die Basis-Attribute.
+  
+  gilt_fuer: "ticket_typ = REQUEST"
+  
+  attribute:
+    
+    - name: "request_typ"
+      typ: "enum"
+      pflicht: true
+      erfassung: "manuell"
+      beschreibung: "Art der Anfrage"
+      werte:
+        - id: "BERECHTIGUNG"
+          name: "Berechtigungsanfrage"
+        - id: "SOFTWARE"
+          name: "Software-Installation"
+        - id: "HARDWARE"
+          name: "Hardware-Anfrage"
+        - id: "ACCOUNT"
+          name: "Account-Management"
+        - id: "INFORMATION"
+          name: "Informationsanfrage"
+        - id: "AENDERUNG"
+          name: "Änderungsanfrage"
+        - id: "SONSTIGE"
+          name: "Sonstige Anfrage"
+    
+    - name: "request_katalog_id"
+      typ: "string"
+      pflicht: false
+      erfassung: "manuell"
+      beschreibung: "Referenz auf Standard-Request im Request-Katalog"
+      beispiel: "REQ-CAT-SW-001"
+    
+    - name: "genehmigung_erforderlich"
+      typ: "boolean"
+      pflicht: false
+      erfassung: "automatisch"
+      beschreibung: "Ist eine Genehmigung erforderlich?"
+      ableitung: "Basierend auf request_typ und Katalog-Definition"
+    
+    - name: "genehmiger"
+      typ: "objekt"
+      pflicht: false
+      erfassung: "manuell"
+      beschreibung: "Person, die die Genehmigung erteilt"
+      schema:
+        - name: "person_id"
+          typ: "string"
+        - name: "name"
+          typ: "string"
+        - name: "genehmigt_am"
+          typ: "datetime"
+        - name: "kommentar"
+          typ: "string"
+      bedingung: "Pflicht wenn genehmigung_erforderlich = true"
+    
+    - name: "genehmigung_status"
+      typ: "enum"
+      pflicht: false
+      erfassung: "manuell"
+      beschreibung: "Status des Genehmigungsprozesses"
+      werte:
+        - id: "OFFEN"
+          name: "Genehmigung ausstehend"
+        - id: "GENEHMIGT"
+          name: "Genehmigt"
+        - id: "ABGELEHNT"
+          name: "Abgelehnt"
+        - id: "NICHT_ERFORDERLICH"
+          name: "Keine Genehmigung erforderlich"
+    
+    - name: "wunschtermin"
+      typ: "date"
+      pflicht: false
+      erfassung: "manuell"
+      beschreibung: "Vom Nutzer gewünschter Erledigungstermin"
+    
+    - name: "kosten_relevant"
+      typ: "boolean"
+      pflicht: false
+      erfassung: "automatisch"
+      beschreibung: "Entstehen Kosten für das Amt?"
+      ableitung: "Basierend auf Service-Kategorie und Request-Typ"
+    
+    - name: "erfuellung"
+      typ: "text"
+      pflicht: true
+      erfassung: "manuell"
+      beschreibung: "Beschreibung der durchgeführten Erfüllung"
+      bedingung: "Pflicht bei Status = GELOEST oder GESCHLOSSEN"
+
+# =============================================================================
+# STATUS-MODELL
+# =============================================================================
+
+status_modell:
+
+  beschreibung: |
+    Definition der erlaubten Status-Übergänge. Nur die hier definierten
+    Transitionen sind im System erlaubt.
+
+  transitionen:
+
+    - von: "NEU"
+      nach: ["ANGENOMMEN", "STORNIERT"]
+      bedingung: null
+
+    - von: "ANGENOMMEN"
+      nach: ["WARTEN_GENEHMIGUNG", "IN_BEARBEITUNG", "WARTEN_NUTZER", "STORNIERT"]
+      bedingung: "zugewiesen_an muss gesetzt sein"
+      hinweis: "WARTEN_GENEHMIGUNG nur bei Requests"
+
+    - von: "WARTEN_GENEHMIGUNG"
+      nach: ["IN_BEARBEITUNG", "STORNIERT"]
+      bedingung: "Genehmigung erteilt → IN_BEARBEITUNG, abgelehnt → STORNIERT"
+      ticket_typ: "Nur für REQUEST"
+
+    - von: "IN_BEARBEITUNG"
+      nach: ["WARTEN_NUTZER", "WARTEN_EXTERN", "WARTEN_CHANGE", "GELOEST", "STORNIERT"]
+      bedingung: null
+
+    - von: "WARTEN_NUTZER"
+      nach: ["IN_BEARBEITUNG", "GELOEST", "STORNIERT"]
+      bedingung: null
+      timeout: "5 Arbeitstage"
+      timeout_aktion: "Automatische Erinnerung, nach weiteren 5 AT → STORNIERT"
+
+    - von: "WARTEN_EXTERN"
+      nach: ["IN_BEARBEITUNG", "GELOEST"]
+      bedingung: null
+
+    - von: "WARTEN_CHANGE"
+      nach: ["IN_BEARBEITUNG", "GELOEST"]
+      bedingung: "Change-Ticket muss verknüpft sein"
+
+    - von: "GELOEST"
+      nach: ["GESCHLOSSEN", "IN_BEARBEITUNG"]
+      bedingung: null
+      timeout: "3 Arbeitstage"
+      timeout_aktion: "Automatisch → GESCHLOSSEN"
+
+    - von: "GESCHLOSSEN"
+      nach: ["IN_BEARBEITUNG"]
+      bedingung: "Wiedereröffnung durch Queue-Koordinator, Begründung erforderlich"
+
+    - von: "STORNIERT"
+      nach: []
+      bedingung: "Endstatus, keine Wiedereröffnung"
+
+# =============================================================================
+# DEFINITION OF READY (DoR)
+# =============================================================================
+
+definition_of_ready:
+  
+  beschreibung: |
+    Mindestanforderungen, die ein Ticket erfüllen muss, bevor es zur 
+    Bearbeitung angenommen werden kann. Tickets, die die DoR nicht 
+    erfüllen, können zurückgewiesen werden.
+  
+  governance: "SSM-G-04 (DoR-Verbindlichkeit)"
+  
+  pflichtfelder_alle:
+    - "titel"
+    - "beschreibung"
+    - "melder"
+    - "betroffener"
+    - "ticket_typ"
+    - "impact"
+    - "urgency"
+    - "charakteristik"
+  
+  pflichtfelder_incident:
+    - "symptom ODER fehlermeldung"
+  
+  pflichtfelder_request:
+    - "request_typ"
+  
+  qualitaetskriterien:
+    
+    - id: "DoR-Q-01"
+      name: "Verständlicher Titel"
+      beschreibung: "Titel beschreibt Problem/Anfrage erkennbar (ohne Beschreibung lesen zu müssen)"
+      pruefung: "manuell"
+    
+    - id: "DoR-Q-02"
+      name: "Ausreichende Beschreibung"
+      beschreibung: "Beschreibung enthält genug Kontext für Bearbeitung ohne Rückfrage"
+      pruefung: "manuell"
+      mindestlaenge: "50 Zeichen"
+    
+    - id: "DoR-Q-03"
+      name: "Erreichbarkeit"
+      beschreibung: "Melder ist erreichbar (Telefon oder E-Mail dokumentiert)"
+      pruefung: "automatisch"
+    
+    - id: "DoR-Q-04"
+      name: "Service-Zuordnung (wenn möglich)"
+      beschreibung: "Betroffener Service ist identifiziert"
+      pruefung: "manuell"
+      verbindlichkeit: "empfohlen"
+  
+  rueckweisung:
+    beschreibung: |
+      Tickets, die die DoR nicht erfüllen, werden an den Melder 
+      zurückgewiesen mit der Aufforderung zur Nachbesserung.
+    verantwortlich: "First Level Agent"
+    dokumentation: "Rückweisungsgrund im Ticket vermerken"
+    status_bei_rueckweisung: "WARTEN_NUTZER"
+
+# =============================================================================
+# VALIDIERUNGSREGELN
+# =============================================================================
+
+validierung:
+  
+  regeln:
+    
+    - id: "VAL-T-001"
+      name: "Priorität-Pool-Konsistenz"
+      beschreibung: "Pool muss zur Priorität × Charakteristik passen"
+      regel: "Pool wird automatisch aus Ableitungslogik gesetzt"
+      referenz: "ssm_klassifikation-priorisierung.yaml"
+    
+    - id: "VAL-T-002"
+      name: "Lösungspflicht bei Abschluss"
+      beschreibung: "Vor Schließen muss Lösung/Erfüllung dokumentiert sein"
+      regel: |
+        Status = GESCHLOSSEN erfordert:
+        - Bei INCIDENT: loesung ist gesetzt
+        - Bei REQUEST: erfuellung ist gesetzt
+    
+    - id: "VAL-T-003"
+      name: "Genehmigung bei Genehmigungspflicht"
+      beschreibung: "Genehmigungspflichtige Requests brauchen Freigabe"
+      regel: |
+        Wenn genehmigung_erforderlich = true, dann 
+        genehmigung_status muss GENEHMIGT sein vor Status = IN_BEARBEITUNG
+    
+    - id: "VAL-T-004"
+      name: "SLA-Ziele bei Priorität"
+      beschreibung: "SLA-Zielzeiten werden aus Priorität abgeleitet"
+      regel: "Automatische Berechnung bei Ticket-Erstellung"
+      referenz: "ssm_klassifikation-priorisierung.yaml → prioritaetsstufen"
+    
+    - id: "VAL-T-005"
+      name: "Langläufer-Kennzeichnung"
+      beschreibung: "Tickets >20 AT werden automatisch gekennzeichnet"
+      regel: |
+        Wenn (geschlossen_am - erstellt_am) > 20 Arbeitstage
+        ODER aktuelles Datum - erstellt_am > 20 Arbeitstage,
+        dann langlaeufer_flag = true
+
+# =============================================================================
+# SCHNITTSTELLEN
+# =============================================================================
+
+schnittstellen:
+  
+  intern:
+    - modul: "ssm_klassifikation-priorisierung.yaml"
+      art: "referenziert"
+      beschreibung: "Prioritäts- und Pool-Logik, SLA-Ziele"
+    
+    - modul: "sub-practice_incident-management.yaml"
+      art: "wird verwendet von"
+      beschreibung: "Incident-Prozess arbeitet auf diesem Schema"
+    
+    - modul: "sub-practice_request-management.yaml"
+      art: "wird verwendet von"
+      beschreibung: "Request-Prozess arbeitet auf diesem Schema"
+    
+    - modul: "spm_schema_service-definition.yaml"
+      art: "referenziert"
+      beschreibung: "Service-Zuordnung über service_id"
+    
+    - modul: "ssm_rollen.yaml"
+      art: "referenziert"
+      beschreibung: "Bearbeiter-Zuordnung"
+  
+  extern:
+    - partner: "ITSM-Tool"
+      kontext: "Schema definiert Feldstruktur für Tool-Konfiguration"
+      status: "Tool-Auswahl ausstehend"
+    
+    - partner: "Active Directory"
+      kontext: "Personen-Lookup für Melder/Betroffener/Bearbeiter"
+
+# =============================================================================
+# OFFENE PUNKTE
+# =============================================================================
+
+offene_punkte:
+  
+  - id: "OPEN-SCHEMA-T-001"
+    beschreibung: "Request-Katalog-Struktur definieren (referenziert von request_katalog_id)"
+    prioritaet: "hoch"
+  
+  - id: "OPEN-SCHEMA-T-002"
+    beschreibung: "Kategorie/Unterkategorie-Taxonomie abstimmen"
+    prioritaet: "mittel"
+  
+  - id: "OPEN-SCHEMA-T-003"
+    beschreibung: "CMDB-Integration: CI-Verknüpfung als Attribut ergänzen?"
+    prioritaet: "niedrig"
+  
+  - id: "OPEN-SCHEMA-T-004"
+    beschreibung: "Attachment-Handling: Wie werden Screenshots, Logs etc. abgebildet?"
+    prioritaet: "mittel"
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+  - version: "0.2"
+    datum: "2025-12-07"
+    aenderung: |
+      - Feld 'nutzer_feedback' ergänzt (Zufriedenheit, Kommentar)
+      - MVP-Status: Optional, Tool-abhängig
+    autor: "DIGITOM-Projekt"
+    quelle: "Review-Finding K-03"
+
+  - version: "0.1"
+    datum: "2025-12-07"
+    aenderung: "Initiale Erstellung"
+    autor: "DIGITOM-Projekt"

#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/sub-practice_problem-management.yaml

@@ -0,0 +1,843 @@
+# =============================================================================
+# SUB-PRACTICE: PROBLEM MANAGEMENT
+# =============================================================================
+
+metadata:
+  id: "P-06"
+  name: "Problem Management"
+  version: "0.1"
+  status: "draft"
+  erstellt: "2025-12-07"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+
+  parent_practice: "practice_service-support-management"
+
+  itil4_referenz: "Problem Management Practice"
+  yasm_referenz: "LP4.7.2, LP4.7.3, LP4.7.4, LP4.7.5"
+  
+  hinweis_yasm: |
+    LP4.7.1 (Proaktives Identifizieren) ist im MVP nicht im Scope.
+    Nur reaktive Problem-Identifikation aus Incidents.
+
+  blueprint_referenz: "service-lifecycle_service-support.yaml"
+  relevante_aktivitaeten: ["ss_09", "ss_10", "ss_11"]
+
+  design_referenz: "ssm_design-zieldimensionen.yaml"
+  relevante_saeulen: ["LS-05", "LS-06"]
+
+  schema_referenz: "ssm_schema_ticket.yaml"
+  rollen_referenz: "ssm_rollen.yaml"
+  wissensmanagement_referenz: "ssm_wissensmanagement.yaml"
+
+# =============================================================================
+# ZWECK & SCOPE
+# =============================================================================
+
+zweck:
+
+  definition: |
+    Problem Management reduziert die Wahrscheinlichkeit und Auswirkungen
+    von Incidents durch Identifikation der zugrundeliegenden Ursachen,
+    Entwicklung von Workarounds und Initiierung nachhaltiger Lösungen.
+
+  ziele:
+    - "Identifikation der Ursachen wiederkehrender oder schwerwiegender Incidents"
+    - "Bereitstellung von Workarounds zur Reduktion von Incident-Auswirkungen"
+    - "Dokumentation von Known Errors für schnellere Incident-Bearbeitung"
+    - "Initiierung permanenter Lösungen über Change Management"
+    - "Reduktion der Gesamtzahl von Incidents durch Ursachenbeseitigung"
+
+  mvp_scope:
+    beschreibung: |
+      Im MVP ist Problem Management auf reaktive Identifikation aus
+      Incidents beschränkt. Proaktive Problem-Identifikation (Trend-Analyse,
+      Monitoring-basiert) ist nicht im Scope.
+    
+    im_scope:
+      - "Reaktive Problem-Identifikation aus Incidents"
+      - "Basis-Root-Cause-Analyse"
+      - "Workaround-Dokumentation als Known Error"
+      - "Change-Initiierung für permanente Lösungen"
+    
+    nicht_im_scope:
+      - "Proaktive Problem-Identifikation (LP4.7.1)"
+      - "Systematische Trend-Analyse"
+      - "Formale RCA-Methoden (5-Why, Ishikawa) – können genutzt werden, sind aber nicht vorgeschrieben"
+      - "Separate Known Error Database (KEDB)"
+    
+    governance: "SSM-G-19"
+
+  abgrenzung:
+
+    problem_vs_incident: |
+      Ein Incident ist eine ungeplante Unterbrechung, die schnellstmöglich
+      behoben werden muss (Symptombehandlung). Ein Problem ist die 
+      zugrundeliegende Ursache eines oder mehrerer Incidents.
+      
+      Incident Management: "Wie stelle ich den Service wieder her?"
+      Problem Management: "Warum ist der Service ausgefallen?"
+
+    problem_vs_change: |
+      Problem Management identifiziert Ursachen und entwickelt Lösungsvorschläge.
+      Die Implementierung permanenter Lösungen erfolgt über Change Enablement.
+      Problem Management initiiert Changes, implementiert sie aber nicht selbst.
+
+    problem_vs_known_error: |
+      Ein Problem ist eine identifizierte oder vermutete Ursache.
+      Ein Known Error ist ein Problem, dessen Ursache analysiert wurde
+      und für das ein dokumentierter Workaround existiert.
+
+# =============================================================================
+# KERNKONZEPTE
+# =============================================================================
+
+kernkonzepte:
+
+  # ---------------------------------------------------------------------------
+  # ROLLENMODELL
+  # ---------------------------------------------------------------------------
+  rollenmodell:
+
+    beschreibung: |
+      Im MVP gibt es keine dedizierte Problem-Manager-Rolle. Die Verantwortung
+      ist auf bestehende Rollen verteilt, mit dem Service Owner als 
+      Process Owner für Problem Management in seinem Service-Bereich.
+
+    governance: "SSM-G-18"
+
+    begruendung: |
+      ITIL4 warnt explizit davor, Problem Management als separate Funktion
+      aufzubauen: "If it is set up as a separate team or group, there is 
+      a danger it will just become a dumping ground for everything the 
+      other support staff find too difficult."
+      
+      Im MVP-Kontext von DIGIT ist der Service Owner ohnehin Teil des
+      operativen Teams und kann die Koordination übernehmen.
+
+    verantwortlichkeiten:
+
+      service_owner:
+        rolle: "Process Owner Problem Management (für seinen Service)"
+        aufgaben:
+          - "Wiederkehrende Muster im Blick behalten"
+          - "Root-Cause-Analyse koordinieren und ggf. durchführen"
+          - "Sicherstellen, dass Workarounds dokumentiert werden"
+          - "Entscheidung über permanente Lösungen (Change)"
+          - "Problem-Priorisierung und -Überwachung"
+          - "Problem-Abschluss"
+        kann_delegieren_an: "Second Level Agents (Experten)"
+
+      second_level_agent:
+        rolle: "Operative Durchführung"
+        aufgaben:
+          - "Problem Record erstellen (bei Erkennung in Incident-Bearbeitung)"
+          - "Root-Cause-Analyse durchführen (bei Delegation durch SO)"
+          - "Workaround entwickeln und dokumentieren"
+          - "Known-Error-Artikel erstellen"
+
+      queue_koordinator:
+        rolle: "Muster-Erkennung"
+        aufgaben:
+          - "Wiederkehrende Incidents in Queues erkennen"
+          - "Service Owner auf Muster hinweisen"
+          - "Problem-Record-Erstellung anstoßen (via INC-12)"
+
+      support_manager:
+        rolle: "Übergreifende Koordination"
+        aufgaben:
+          - "Koordination bei Service-übergreifenden Problemen"
+          - "Eskalation bei Ressourcen-Konflikten"
+          - "Reporting über Problem-Status"
+
+  # ---------------------------------------------------------------------------
+  # PROBLEM-IDENTIFIKATION (REAKTIV)
+  # ---------------------------------------------------------------------------
+  problem_identifikation:
+
+    beschreibung: |
+      Im MVP werden Probleme ausschließlich reaktiv aus dem Incident
+      Management identifiziert. Es gibt zwei definierte Trigger.
+
+    trigger:
+
+      - id: "TRIGGER-01"
+        name: "Nicht lösbarer Incident"
+        quelle: "INC-11"
+        beschreibung: |
+          Ein Incident kann im L2 nicht gelöst werden, obwohl Diagnose
+          durchgeführt wurde. Es wird eine strukturelle Ursache vermutet.
+        kriterien:
+          - "L2-Diagnose abgeschlossen ohne Lösung"
+          - "Workaround implementiert, aber Ursache unbekannt"
+          - "Strukturelle Ursache vermutet"
+
+      - id: "TRIGGER-02"
+        name: "Wiederkehrende Incidents"
+        quelle: "INC-12"
+        beschreibung: |
+          Mehrere ähnliche Incidents deuten auf ein zugrundeliegendes
+          Problem hin.
+        kriterien:
+          - "≥3 ähnliche Incidents innerhalb von 5 Arbeitstagen"
+          - "Gemeinsame Symptome oder betroffene Komponente"
+          - "Queue-Koordinator oder L2 erkennt Muster"
+
+    nicht_im_mvp_scope:
+      - "Proaktive Identifikation aus Monitoring-Daten"
+      - "Trend-Analyse über Incident-Statistiken"
+      - "Supplier- oder Partner-Informationen"
+      - "Erkenntnisse aus Testing oder Entwicklung"
+
+  # ---------------------------------------------------------------------------
+  # PRIORISIERUNG
+  # ---------------------------------------------------------------------------
+  priorisierung:
+
+    beschreibung: |
+      Problems werden nicht über eine eigene Prioritäts-Matrix bewertet,
+      sondern über eine einfache Ableitung aus Service-Kontext und
+      Incident-Auswirkung.
+
+    modellentscheidung: |
+      Diese Priorisierungslogik ist ein konzeptioneller Vorschlag für
+      den MVP. Bei steigender Problem-Anzahl kann eine differenziertere
+      Matrix erforderlich werden.
+
+    dringlichkeitsstufen:
+
+      - stufe: "HOCH"
+        kriterien:
+          - "Service-Kategorie C"
+          - "ODER >5 verknüpfte Incidents"
+          - "ODER kein Workaround verfügbar"
+        erwartung: "Sofortige Bearbeitung, RCA innerhalb 5 AT"
+
+      - stufe: "MITTEL"
+        kriterien:
+          - "Service-Kategorie B"
+          - "UND 3-5 verknüpfte Incidents"
+          - "UND Workaround vorhanden"
+        erwartung: "Bearbeitung innerhalb 10 AT"
+
+      - stufe: "NIEDRIG"
+        kriterien:
+          - "Service-Kategorie A"
+          - "ODER <3 verknüpfte Incidents"
+          - "UND Workaround vorhanden"
+        erwartung: "Bearbeitung nach Kapazität"
+
+    hinweis: |
+      Die Dringlichkeit kann vom Service Owner bei Bedarf angepasst
+      werden (z.B. bei politischer Relevanz oder Außenwirkung).
+
+  # ---------------------------------------------------------------------------
+  # KNOWN ERROR KONZEPT
+  # ---------------------------------------------------------------------------
+  known_error:
+
+    beschreibung: |
+      Ein Known Error ist ein Problem, dessen Ursache analysiert wurde
+      (auch wenn nicht vollständig verstanden) und für das ein
+      dokumentierter Workaround existiert.
+
+    governance: "SSM-G-20"
+
+    dokumentation:
+      beschreibung: |
+        Known Errors werden nicht in einer separaten KEDB geführt,
+        sondern als KB-Artikel mit speziellem Typ in der bestehenden
+        Wissensdatenbank dokumentiert.
+      
+      kb_integration:
+        artikel_typ: "KNOWN_ERROR"
+        kb_ebene: "Ebene 2 (Arbeitsdokumentation)"
+        referenz: "ssm_wissensmanagement.yaml"
+
+      pflichtfelder:
+        - feld: "symptome"
+          beschreibung: "Wie erkennt man das Problem? Wann tritt es auf?"
+        - feld: "workaround"
+          beschreibung: "Wie kann man das Problem umgehen oder die Auswirkung reduzieren?"
+        - feld: "root_cause"
+          beschreibung: "Was ist die Ursache? (kann 'unbekannt' sein)"
+        - feld: "problem_referenz"
+          beschreibung: "Verknüpfung zum Problem Record"
+        - feld: "status"
+          beschreibung: "AKTIV oder OBSOLET"
+          werte: ["AKTIV", "OBSOLET"]
+
+      optionale_felder:
+        - feld: "permanente_loesung"
+          beschreibung: "Geplante Lösung, wenn bekannt"
+        - feld: "change_referenz"
+          beschreibung: "Verknüpfung zu Change, wenn Lösung in Arbeit"
+        - feld: "betroffene_services"
+          beschreibung: "Liste der betroffenen Services"
+
+    lebenszyklus:
+      - "Problem wird als KNOWN_ERROR markiert, wenn Workaround dokumentiert"
+      - "Known-Error-Artikel wird erstellt/aktualisiert"
+      - "Bei Incident-Bearbeitung: KB-Suche findet Known Error"
+      - "Agent wendet Workaround an"
+      - "Nach permanenter Lösung: Artikel-Status auf OBSOLET"
+
+# =============================================================================
+# PROZESS-AKTIVITÄTEN
+# =============================================================================
+
+aktivitaeten_uebersicht: |
+  Problem Management im MVP besteht aus 4 Kernaktivitäten.
+  Der Prozess ist schlank gehalten und fokussiert auf die
+  wesentlichen Schritte von Erfassung bis Schließung.
+
+aktivitaeten:
+
+  # ---------------------------------------------------------------------------
+  # PRB-01: PROBLEM ERFASSEN
+  # ---------------------------------------------------------------------------
+  - id: "PRB-01"
+    name: "Problem erfassen"
+    phase: "Identifikation"
+    blueprint_referenz: "ss_09, ss_10"
+    yasm_referenz: "LP4.7.2"
+
+    beschreibung: |
+      Erstellung eines Problem Records basierend auf einem der
+      definierten Trigger. Dokumentation der Symptome und
+      Verknüpfung mit auslösenden Incidents.
+
+    trigger:
+      - "INC-11: Nicht lösbarer Incident"
+      - "INC-12: Wiederkehrende Incidents identifiziert"
+
+    aktivitaeten:
+      - "Problem Record im ITSM-Tool erstellen"
+      - "Symptome und Auswirkungen dokumentieren"
+      - "Auslösende Incidents verknüpfen"
+      - "Betroffenen Service identifizieren"
+      - "Service-Kategorie übernehmen"
+      - "Erste Hypothese zur Ursache (wenn vorhanden)"
+      - "Dringlichkeit ableiten"
+      - "Service Owner informieren"
+
+    problem_record_felder:
+      pflicht:
+        - "problem_id (automatisch)"
+        - "titel"
+        - "symptom_beschreibung"
+        - "betroffener_service"
+        - "service_kategorie"
+        - "verknuepfte_incidents (mindestens 1)"
+        - "erstellt_von"
+        - "erstellt_am"
+        - "status (NEU)"
+        - "dringlichkeit"
+      optional:
+        - "erste_hypothese"
+        - "bekannter_workaround"
+        - "betroffene_komponente"
+
+    output:
+      - "Problem Record mit Status NEU"
+      - "Verknüpfung zu auslösenden Incidents"
+      - "Service Owner informiert"
+
+    raci:
+      r: "Second Level Agent"
+      a: "Service Owner"
+      c: "Queue-Koordinator"
+      i: "-"
+
+  # ---------------------------------------------------------------------------
+  # PRB-02: PROBLEM ANALYSIEREN
+  # ---------------------------------------------------------------------------
+  - id: "PRB-02"
+    name: "Problem analysieren (Root-Cause-Analyse)"
+    phase: "Analyse"
+    blueprint_referenz: "ss_11"
+    yasm_referenz: "LP4.7.3"
+
+    beschreibung: |
+      Durchführung einer Root-Cause-Analyse zur Identifikation der
+      zugrundeliegenden Ursache. Entwicklung eines Workarounds,
+      wenn keine sofortige Lösung möglich ist.
+
+    vorbedingung: "Problem Record mit Status NEU"
+
+    aktivitaeten:
+      - "Status auf IN_ANALYSE setzen"
+      - "Verfügbare Informationen sammeln und sichten"
+      - "Verknüpfte Incidents analysieren (Gemeinsamkeiten)"
+      - "Hypothesen zur Ursache entwickeln"
+      - "Hypothesen systematisch prüfen"
+      - "Root Cause identifizieren oder eingrenzen"
+      - "Workaround entwickeln (wenn Ursache nicht sofort behebbar)"
+      - "Ergebnisse dokumentieren"
+
+    rca_methoden:
+      beschreibung: |
+        Im MVP sind keine formalen RCA-Methoden vorgeschrieben.
+        Folgende Ansätze können bei Bedarf genutzt werden:
+      optionale_methoden:
+        - "5-Why-Analyse"
+        - "Ishikawa-Diagramm (Fishbone)"
+        - "Timeline-Analyse"
+        - "Vergleichsanalyse (funktionierend vs. nicht funktionierend)"
+      hinweis: "Pragmatisches Vorgehen ist im MVP ausreichend."
+
+    ergebnis_varianten:
+
+      root_cause_gefunden:
+        beschreibung: "Ursache wurde identifiziert"
+        naechster_schritt:
+          workaround_reicht: "→ Status KNOWN_ERROR, KB-Artikel erstellen"
+          permanente_loesung_noetig: "→ PRB-03 (Lösung initiieren)"
+
+      root_cause_nicht_gefunden:
+        beschreibung: "Ursache konnte nicht eindeutig identifiziert werden"
+        naechster_schritt:
+          workaround_vorhanden: "→ Status KNOWN_ERROR, weiter beobachten"
+          kein_workaround: "→ Problem bleibt IN_ANALYSE, Eskalation prüfen"
+
+    workaround_dokumentation:
+      beschreibung: |
+        Wenn ein Workaround entwickelt wurde, muss dieser als
+        Known-Error-Artikel dokumentiert werden.
+      verantwortlich: "Second Level Agent"
+      freigabe: "Service Owner"
+      referenz: "kernkonzepte.known_error"
+
+    output:
+      - "Dokumentierte Analyseergebnisse"
+      - "Root Cause (wenn identifiziert)"
+      - "Workaround (wenn entwickelt)"
+      - "Known-Error-Artikel (wenn Workaround dokumentiert)"
+      - "Empfehlung für weiteres Vorgehen"
+
+    raci:
+      r: "Second Level Agent / Service Owner"
+      a: "Service Owner"
+      c: "Lieferant (bei externen Komponenten)"
+      i: "Support Manager"
+
+  # ---------------------------------------------------------------------------
+  # PRB-03: LÖSUNG INITIIEREN
+  # ---------------------------------------------------------------------------
+  - id: "PRB-03"
+    name: "Lösung initiieren"
+    phase: "Lösung"
+    blueprint_referenz: "ss_11"
+    yasm_referenz: "LP4.7.3, LP4.7.4"
+
+    beschreibung: |
+      Initiierung einer permanenten Lösung, wenn ein Workaround
+      nicht ausreicht oder die Ursache nachhaltig beseitigt werden soll.
+      Die Implementierung erfolgt über Change Enablement.
+
+    vorbedingung: |
+      - Root Cause identifiziert oder eingegrenzt
+      - Entscheidung: Permanente Lösung erforderlich/wirtschaftlich sinnvoll
+
+    entscheidungskriterien:
+      beschreibung: |
+        Der Service Owner entscheidet, ob eine permanente Lösung
+        angestrebt wird. Kriterien:
+      kriterien:
+        - "Workaround ist aufwändig oder fehleranfällig"
+        - "Incident-Häufigkeit rechtfertigt Investition"
+        - "Risiko bei Fortbestehen des Problems"
+        - "Kosten-Nutzen-Verhältnis einer permanenten Lösung"
+      hinweis: |
+        Nicht jedes Problem muss permanent gelöst werden. Ein stabiler
+        Workaround kann eine akzeptable Dauerlösung sein.
+
+    aktivitaeten:
+      - "Lösungsoptionen bewerten"
+      - "Kosten-Nutzen-Abschätzung (informell)"
+      - "Entscheidung: Change oder alternative Maßnahme"
+      - "Bei Change: Change Request erstellen"
+      - "Problem Record mit Change verknüpfen"
+      - "Status auf WARTEN_CHANGE setzen"
+      - "Problem-Überwachung während Change-Implementierung"
+
+    change_initiierung:
+      beschreibung: |
+        Die meisten permanenten Lösungen erfordern einen Change.
+        Problem Management erstellt den Change Request, die
+        Implementierung erfolgt über Change Enablement.
+      change_request_inhalt:
+        - "Verweis auf Problem Record"
+        - "Beschreibung der Ursache"
+        - "Vorgeschlagene Lösung"
+        - "Erwarteter Nutzen (reduzierte Incidents)"
+      schnittstelle: "practice_change-enablement.yaml (Platzhalter)"
+
+    alternative_massnahmen:
+      beschreibung: |
+        Nicht alle Lösungen erfordern einen formalen Change.
+      beispiele:
+        - "Konfigurationsanpassung im Standard-Scope"
+        - "Schulung/Kommunikation an Nutzer"
+        - "Prozessanpassung"
+        - "Lieferanten-Eskalation"
+
+    output:
+      - "Entscheidung dokumentiert"
+      - "Change Request (wenn erforderlich)"
+      - "Problem Record Status WARTEN_CHANGE oder KNOWN_ERROR"
+
+    raci:
+      r: "Service Owner"
+      a: "Service Owner"
+      c: "Support Manager"
+      i: "Second Level Agent"
+
+  # ---------------------------------------------------------------------------
+  # PRB-04: PROBLEM SCHLIESSEN
+  # ---------------------------------------------------------------------------
+  - id: "PRB-04"
+    name: "Problem schließen"
+    phase: "Abschluss"
+    yasm_referenz: "LP4.7.5"
+
+    beschreibung: |
+      Abschluss des Problem Records nach erfolgreicher Lösung
+      oder bewusster Entscheidung, das Problem nicht weiter zu verfolgen.
+
+    schliessungsgruende:
+
+      loesung_implementiert:
+        beschreibung: "Permanente Lösung wurde via Change implementiert"
+        aktivitaeten:
+          - "Validieren: Lösung wirksam? (keine neuen Incidents)"
+          - "Known-Error-Artikel auf OBSOLET setzen"
+          - "Verknüpfte Incidents prüfen"
+          - "Problem Record auf GESCHLOSSEN setzen"
+          - "Abschlussdokumentation"
+
+      workaround_akzeptiert:
+        beschreibung: "Workaround ist Dauerlösung, keine weitere Aktion geplant"
+        aktivitaeten:
+          - "Entscheidung dokumentieren (warum keine permanente Lösung)"
+          - "Known-Error-Artikel bleibt AKTIV"
+          - "Problem Record auf GESCHLOSSEN setzen"
+          - "Hinweis: Bei Änderung der Situation kann neu bewertet werden"
+
+      duplikat_oder_ungueltig:
+        beschreibung: "Problem ist Duplikat oder war kein echtes Problem"
+        aktivitaeten:
+          - "Begründung dokumentieren"
+          - "Ggf. mit anderem Problem Record verknüpfen"
+          - "Problem Record auf GESCHLOSSEN setzen"
+
+    validierung_bei_loesung:
+      beschreibung: |
+        Nach Implementierung einer permanenten Lösung muss validiert
+        werden, dass das Problem tatsächlich behoben ist.
+      methoden:
+        - "Monitoring der Incident-Rate für betroffenen Service"
+        - "Beobachtungszeitraum (empfohlen: 2-4 Wochen)"
+        - "Rückmeldung von L1/L2 zur Incident-Entwicklung"
+      bei_misserfolg: "Zurück zu IN_ANALYSE"
+
+    output:
+      - "Problem Record mit Status GESCHLOSSEN"
+      - "Abschlussdokumentation"
+      - "Known-Error-Artikel aktualisiert (OBSOLET wenn gelöst)"
+      - "Lessons Learned (optional)"
+
+    raci:
+      r: "Service Owner"
+      a: "Service Owner"
+      c: "-"
+      i: "Support Manager"
+
+# =============================================================================
+# STATUS-LIFECYCLE
+# =============================================================================
+
+status_lifecycle:
+
+  beschreibung: |
+    Vereinfachtes Status-Modell für Problem Records im MVP.
+    Analog zum Ticket-Schema, aber auf Problem-Spezifika angepasst.
+
+  status_werte:
+
+    - id: "NEU"
+      name: "Neu"
+      beschreibung: "Problem Record erstellt, noch nicht in Analyse"
+
+    - id: "IN_ANALYSE"
+      name: "In Analyse"
+      beschreibung: "Root-Cause-Analyse läuft"
+
+    - id: "KNOWN_ERROR"
+      name: "Known Error"
+      beschreibung: |
+        Ursache bekannt oder eingegrenzt, Workaround dokumentiert.
+        Keine permanente Lösung geplant oder in Bewertung.
+
+    - id: "WARTEN_CHANGE"
+      name: "Warten auf Change"
+      beschreibung: "Permanente Lösung via Change in Arbeit"
+
+    - id: "GELOEST"
+      name: "Gelöst"
+      beschreibung: "Lösung implementiert, Validierung läuft"
+
+    - id: "GESCHLOSSEN"
+      name: "Geschlossen"
+      beschreibung: "Problem final abgeschlossen"
+
+  transitionen:
+
+    - von: "NEU"
+      nach: ["IN_ANALYSE", "GESCHLOSSEN"]
+      beschreibung: "Analyse starten oder als Duplikat/ungültig schließen"
+
+    - von: "IN_ANALYSE"
+      nach: ["KNOWN_ERROR", "WARTEN_CHANGE", "GESCHLOSSEN"]
+      beschreibung: "Analyse abgeschlossen mit verschiedenen Ergebnissen"
+
+    - von: "KNOWN_ERROR"
+      nach: ["WARTEN_CHANGE", "IN_ANALYSE", "GESCHLOSSEN"]
+      beschreibung: "Change initiieren, neu analysieren oder akzeptieren"
+
+    - von: "WARTEN_CHANGE"
+      nach: ["GELOEST", "IN_ANALYSE"]
+      beschreibung: "Change erfolgreich oder gescheitert"
+
+    - von: "GELOEST"
+      nach: ["GESCHLOSSEN", "IN_ANALYSE"]
+      beschreibung: "Validierung erfolgreich oder Problem tritt erneut auf"
+
+    - von: "GESCHLOSSEN"
+      nach: ["IN_ANALYSE"]
+      beschreibung: "Wiedereröffnung bei erneutem Auftreten"
+      bedingung: "Nur mit Begründung durch Service Owner"
+
+# =============================================================================
+# RACI-REFERENZ
+# =============================================================================
+
+raci_referenz:
+
+  beschreibung: |
+    Die verbindliche RACI-Matrix für Problem Management ist in
+    ssm_governance.yaml → raci_konsolidiert.problem_management definiert.
+
+    Diese Kurzübersicht dient der schnellen Orientierung.
+
+  master_dokument: "ssm_governance.yaml"
+  abschnitt: "raci_konsolidiert.problem_management"
+
+  hinweis_service_owner: |
+    Der Service Owner ist Process Owner für Problem Management (SSM-G-18).
+    Er kann operative Tätigkeiten (R) an Second Level Agents delegieren,
+    bleibt aber immer Accountable (A).
+
+  kurzuebersicht:
+    #                              L2   QK   SM   SO
+    problem_erfassen:             "R    C    -    A"
+    problem_analysieren:          "R    -    I    A/R"
+    loesung_initiieren:           "I    -    C    A/R"
+    problem_schliessen:           "-    -    I    A/R"
+    known_error_erstellen:        "R    -    -    A"
+    muster_erkennen:              "C    R    -    A"
+
+  hinweis: "L1 ist im Problem Management nicht direkt beteiligt"
+
+# =============================================================================
+# KENNZAHLEN
+# =============================================================================
+
+kennzahlen:
+
+  beschreibung: |
+    Basis-KPIs für Problem Management im MVP. Fokus auf Wirksamkeit,
+    nicht auf Prozess-Compliance.
+
+  kpis:
+
+    - id: "KPI-PRB-01"
+      name: "Anzahl offener Probleme"
+      beschreibung: "Aktuelle Anzahl nicht geschlossener Problem Records"
+      messung: "Stichtag"
+      ziel: "Kein festes Ziel, Trend beobachten"
+
+    - id: "KPI-PRB-02"
+      name: "Problem-Lösungsrate"
+      beschreibung: "Anteil der Probleme mit permanenter Lösung (nicht nur Workaround)"
+      formel: "(Probleme mit Lösung) / (Geschlossene Probleme) × 100"
+      ziel: "tbd"
+      hinweis: "Nicht jedes Problem muss permanent gelöst werden"
+
+    - id: "KPI-PRB-03"
+      name: "Known Errors mit aktivem Workaround"
+      beschreibung: "Anzahl dokumentierter Known Errors"
+      messung: "Stichtag"
+      ziel: "Kein festes Ziel – zeigt Reife des Prozesses"
+
+    - id: "KPI-PRB-04"
+      name: "Incident-Reduktion nach Problem-Lösung"
+      beschreibung: "Reduktion der Incidents nach Implementierung einer Lösung"
+      messung: "Vergleich Incident-Rate vor/nach Lösung"
+      ziel: ">50% Reduktion"
+      hinweis: "Nur messbar bei ausreichender Datenbasis"
+
+  todo: |
+    - Zielwerte mit DIGIT abstimmen
+    - Reporting-Frequenz festlegen (empfohlen: monatlich)
+    - Baseline nach 3 Monaten Betrieb etablieren
+
+# =============================================================================
+# SCHNITTSTELLEN
+# =============================================================================
+
+schnittstellen:
+
+  intern:
+
+    - modul: "sub-practice_incident-management.yaml"
+      art: "erhält von"
+      beschreibung: "Problem Records aus INC-11 und INC-12"
+      aktivitaeten: ["INC-11", "INC-12"]
+
+    - modul: "ssm_wissensmanagement.yaml"
+      art: "liefert an"
+      beschreibung: "Known-Error-Artikel (Ebene 2)"
+      artikel_typ: "KNOWN_ERROR"
+
+    - modul: "ssm_schema_ticket.yaml"
+      art: "implementiert"
+      beschreibung: "Problem Record Datenstruktur (analog zu Ticket)"
+
+    - modul: "spm_practice_service-level-management.yaml"
+      art: "referenziert"
+      beschreibung: "Service-Kategorien für Priorisierung"
+
+    - modul: "sub-practice_service-desk.yaml"
+      art: "erhält von"
+      beschreibung: "Problem Records werden oft durch Service Desk (via L2) erstellt"
+
+    - modul: "ssm_governance.yaml"
+      art: "wird gesteuert durch"
+      beschreibung: "Reporting-Struktur, Service Owner Reviews"
+
+  extern:
+
+    - partner: "Change Enablement"
+      kontext: "Initiierung permanenter Lösungen via Change"
+      status: "Schnittstelle zu P-03 (Platzhalter)"
+      aktivitaet: "PRB-03"
+
+    - partner: "ITSM-Tool"
+      kontext: "Problem Record Lifecycle"
+      status: "Tool-Auswahl ausstehend"
+
+    - partner: "Lieferanten"
+      kontext: "RCA-Unterstützung bei externen Komponenten"
+      status: "Fallweise"
+
+# =============================================================================
+# GOVERNANCE-ENTSCHEIDUNGEN
+# =============================================================================
+
+governance:
+
+  beschreibung: |
+    Governance-Entscheidungen für Problem Management.
+    Zur Übertragung ins zentrale Log.
+
+  entscheidungen:
+
+    - id: "SSM-G-18"
+      name: "Keine 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.
+      status: "vorgeschlagen"
+
+    - id: "SSM-G-19"
+      name: "Problem Management nur reaktiv im MVP"
+      entscheidung: |
+        Problem-Identifikation erfolgt im MVP ausschließlich reaktiv
+        aus dem Incident Management (nicht lösbare oder wiederkehrende
+        Incidents). Proaktive Problem-Identifikation (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.
+      status: "vorgeschlagen"
+
+    - id: "SSM-G-20"
+      name: "Known Errors als KB-Artikel"
+      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.
+      status: "vorgeschlagen"
+
+# =============================================================================
+# OFFENE PUNKTE
+# =============================================================================
+
+offene_punkte:
+
+  - id: "OPEN-PRB-001"
+    thema: "Problem Record Schema"
+    beschreibung: |
+      Das Problem Record Schema muss analog zum Ticket Schema
+      definiert werden. Kann als Erweiterung von ssm_schema_ticket.yaml
+      oder als eigenes Schema erfolgen.
+    prioritaet: "mittel"
+    status: "Entscheidung ausstehend"
+
+  - id: "OPEN-PRB-002"
+    thema: "Change-Schnittstelle"
+    beschreibung: |
+      Detaillierte Schnittstelle zu Change Enablement (P-03) definieren,
+      sobald dieses Modul entwickelt ist.
+    prioritaet: "mittel"
+    status: "Abhängig von P-03 Entwicklung"
+    abhaengig_von: "practice_change-enablement.yaml"
+
+  - id: "OPEN-PRB-003"
+    thema: "Known-Error-Artikel-Template"
+    beschreibung: |
+      Template für Known-Error-Artikel in der KB erstellen und
+      in ssm_wissensmanagement.yaml integrieren.
+    prioritaet: "hoch"
+    status: "Bei KB-Implementierung"
+
+  - id: "OPEN-PRB-004"
+    thema: "Problem-Incident-Verknüpfung im Tool"
+    beschreibung: |
+      Technische Umsetzung der Verknüpfung zwischen Problem Records
+      und Incidents im ITSM-Tool.
+    prioritaet: "hoch"
+    status: "Tool-Auswahl ausstehend"
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+  - version: "0.1"
+    datum: "2025-12-07"
+    aenderung: "Initiale Erstellung als MVP-Version"
+    autor: "DIGITOM-Projekt"

#02_service-portfolio-management/02.1_spm_konzepte/03_spm_practices/spm_practice_service-support-management/sub-practice_service-desk.yaml

@@ -0,0 +1,790 @@
+# =============================================================================
+# SUB-PRACTICE: SERVICE DESK
+# =============================================================================
+
+metadata:
+  id: "SD"
+  name: "Service Desk"
+  version: "0.2"
+  status: "draft"
+  erstellt: "2025-12-07"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+
+  parent_practice: "practice_service-support-management"
+
+  itil4_referenz: "Service Desk Practice"
+  yasm_referenz: "LP4.6.1"
+
+  blueprint_referenz: "service-lifecycle_service-support.yaml"
+  relevante_aktivitaeten: ["ss_01", "ss_02", "ss_03"]
+
+  design_referenz: "ssm_design-zieldimensionen.yaml"
+  relevante_saeulen: ["LS-01", "LS-02", "LS-03", "LS-04"]
+
+  hinweis: |
+    Der Service Desk ist keine Prozess-Practice wie Incident oder Request
+    Management, sondern eine organisatorische Capability. Dieses Dokument
+    beschreibt die organisatorischen Rahmenbedingungen, nicht die Prozesse.
+
+# =============================================================================
+# ZWECK & SELBSTVERSTÄNDNIS
+# =============================================================================
+
+zweck:
+
+  definition: |
+    Der Service Desk ist der zentrale Zugangspunkt für alle IT-bezogenen
+    Anfragen und Störungsmeldungen. Er fungiert als Single Point of Contact
+    (SPOC) zwischen Nutzern und der IT-Organisation.
+
+  selbstverstaendnis:
+
+    enablement_paradigma:
+      beschreibung: |
+        Der Service Desk verfolgt ein Enablement-Paradigma: Der First Level
+        agiert als aktiver Problemlöser und Befähiger, nicht als reiner
+        Ticket-Verteiler ("Ticket-Schubser").
+      
+      prinzipien:
+        - "Agents gehen selbst auf Detektivsuche und schaffen Lösungen"
+        - "Enge Zusammenarbeit mit Second Level und Service Ownern"
+        - "Systematisches Lernen durch legitimierte Exploration"
+        - "Befähigung der Nutzer, nicht nur Symptombehandlung"
+      
+      governance: "SSM-G-03 (Explorative-Diagnose-Legitimation)"
+
+    kernfunktionen:
+      - "Zentrale Anlaufstelle für alle IT-Anfragen"
+      - "Qualifizierte Erstanalyse und Triage"
+      - "First-Level-Resolution für definierte Standardfälle"
+      - "Koordinierte Weiterleitung bei Eskalation"
+      - "Proaktive Kommunikation mit Nutzern"
+      - "Beitrag zum organisatorischen Wissensaufbau"
+
+  ziele:
+    - "Schnelle und kompetente Erstreaktion auf Nutzeranfragen"
+    - "Hohe First Contact Resolution Rate"
+    - "Transparente Kommunikation über Ticket-Status"
+    - "Kontinuierliche Befähigung des First Level"
+    - "Systematische Erfassung aller IT-Kontakte"
+
+# =============================================================================
+# SYSTEMGRENZE
+# =============================================================================
+
+systemgrenze:
+
+  beschreibung: |
+    Der Service Desk etabliert eine "harte Grenze" als formale Regel:
+    Alle IT-Anfragen müssen durch den Service Desk. Diese Grenze gilt
+    als Referenzpunkt, mit dem Verständnis, dass informelle Strukturen
+    existieren werden.
+
+  harte_grenze:
+    
+    prinzip: "Keine IT-Bearbeitung ohne Ticket"
+    
+    konsequenzen:
+      - "Alle Anfragen werden als Ticket erfasst"
+      - "Auch mündliche Anfragen führen zu Ticket-Erstellung"
+      - "Rückkanal immer über Ticketsystem"
+      - "Dokumentation aller Aktivitäten im Ticket"
+    
+    begruendung: |
+      Die harte Grenze ermöglicht:
+      - Vollständige Transparenz über IT-Aufwände
+      - Messbarkeit und Steuerbarkeit
+      - Nachvollziehbarkeit für Nutzer und IT
+      - Basis für kontinuierliche Verbesserung
+
+  umgang_informelle_strukturen:
+
+    akzeptanz_der_realitaet:
+      beschreibung: |
+        Informelle Strukturen werden existieren. "Lieblings-Admins" werden
+        direkt kontaktiert, VIPs werden Sonderwege suchen. Das Modell
+        akzeptiert diese Realität, etabliert aber einen Reflexionsmechanismus.
+      
+      beispiele:
+        - "Direkter Anruf bei bekanntem L2-Kollegen"
+        - "E-Mail direkt an Spezialisten statt Service Desk"
+        - "Flurfunk-Anfragen"
+
+    reflexionsmechanismus:
+      beschreibung: "Service Owner beobachten Umgehungen"
+      bewertung:
+        - "Einmalig oder systematisch?"
+        - "Verursacht das Probleme?"
+        - "Gibt es einen legitimen Grund?"
+      
+      intervention_nur_bei: "Problematischen Mustern"
+
+    interventionsstufen:
+      - stufe: 1
+        aktion: "Gespräch mit beteiligten Personen"
+      - stufe: 2
+        aktion: "Formale Erinnerung an Prozesse"
+      - stufe: 3
+        aktion: "Eskalation an Führungsebene"
+      - stufe: 4
+        aktion: "Anpassung der Prozesse (wenn sinnvoll)"
+
+# =============================================================================
+# KANALMANAGEMENT
+# =============================================================================
+
+kanalmanagement:
+
+  beschreibung: |
+    Definition der Eingangskanäle und wie Anfragen über diese Kanäle
+    in das Ticketsystem überführt werden.
+
+  eingangskanal:
+
+    - kanal: "Service Portal"
+      typ: "Self-Service"
+      beschreibung: "Webformular im Intranet"
+      ticket_erstellung: "Automatisch durch Nutzer"
+      empfohlen: true
+      vorteile:
+        - "Strukturierte Erfassung"
+        - "Reduziert Rückfragen"
+        - "24/7 verfügbar"
+
+    - kanal: "E-Mail"
+      typ: "Asynchron"
+      beschreibung: "E-Mail an zentrale Service-Desk-Adresse"
+      ticket_erstellung: "Automatisch oder durch Agent"
+      hinweis: |
+        E-Mails direkt an einzelne Agents sollen an die zentrale
+        Adresse weitergeleitet werden.
+
+    - kanal: "Telefon"
+      typ: "Synchron"
+      beschreibung: "Anruf bei Service-Desk-Hotline"
+      ticket_erstellung: "Durch Agent während/nach Gespräch"
+      hinweis: |
+        Agent erstellt Ticket während des Gesprächs oder unmittelbar
+        danach. Keine Bearbeitung ohne Ticket-Dokumentation.
+
+    - kanal: "Persönlich (Walk-in)"
+      typ: "Synchron"
+      beschreibung: "Direkter Besuch während Bürozeiten"
+      ticket_erstellung: "Durch Agent"
+      hinweis: "Nur während definierter Servicezeiten"
+
+  ticket_pflicht:
+    
+    regel: |
+      Jede Anfrage, unabhängig vom Kanal, führt zu einem Ticket.
+      Auch wenn die Lösung im Erstkontakt erfolgt, wird dokumentiert.
+    
+    ausnahmen:
+      - "Reine Informationsfragen, die in <2 Minuten beantwortet sind"
+      - "Weiterleitung an andere Stelle (kein IT-Thema)"
+    
+    bei_ausnahmen: "Kurze Notiz im Tagesprotokoll empfohlen"
+
+# =============================================================================
+# SERVICEZEITEN & ERREICHBARKEIT
+# =============================================================================
+
+servicezeiten:
+
+  status: "ANFORDERUNGEN"
+  
+  hinweis: |
+    Die konkreten Servicezeiten sind eine operative Entscheidung von DIGIT.
+    Dieses Dokument definiert die Anforderungen und Rahmenbedingungen.
+
+  anforderungen:
+
+    kernservicezeit:
+      beschreibung: "Zeitraum mit voller Service-Desk-Besetzung"
+      empfehlung: "Mindestens Kernarbeitszeit der Stadtverwaltung"
+      anforderung: "Telefonische Erreichbarkeit muss gewährleistet sein"
+
+    erweiterte_erreichbarkeit:
+      beschreibung: "Zeitraum mit eingeschränkter Erreichbarkeit"
+      optionen:
+        - "E-Mail-Monitoring außerhalb Kernzeit"
+        - "Rufbereitschaft für kritische Systeme"
+      status: "Mit DIGIT zu klären"
+
+    mindestbesetzung:
+      beschreibung: "Minimale Anzahl Agents während Kernzeit"
+      anforderung: |
+        Mindestens 2 Agents zur Abdeckung von:
+        - Telefonkanal
+        - Ticket-Bearbeitung
+        - Vertretung bei Kurzabwesenheit
+      
+      bei_unterschreitung: "Eskalation an Queue-Koordinator"
+
+  kommunikation:
+    
+    anforderung: |
+      Servicezeiten müssen den Nutzern klar kommuniziert werden.
+    
+    kanaele:
+      - "Intranet-Seite des Service Desk"
+      - "Automatische Antwort bei E-Mail außerhalb Servicezeiten"
+      - "Ansage bei Telefon außerhalb Servicezeiten"
+
+  offener_punkt: "OPEN-SD-001"
+
+# =============================================================================
+# EINGANGSSTEUERUNG (TRIAGE)
+# =============================================================================
+
+eingangssteuerung:
+
+  beschreibung: |
+    Die Eingangssteuerung (Triage) ist der erste Schritt bei jeder Anfrage.
+    Sie bestimmt den Ticket-Typ, die initiale Klassifikation und die
+    Pool-Zuweisung.
+
+  triage_prozess:
+
+    schritt_1_ticket_typ:
+      frage: "Um was für eine Anfrage handelt es sich?"
+      entscheidung:
+        stoerung: "→ Incident (P-04)"
+        anfrage_im_katalog: "→ Request (P-05)"
+        anfrage_nicht_im_katalog: "→ Demand (DPM)"
+        ungewiss: "→ Als Incident erfassen, später umklassifizieren"
+      
+      referenz: "ssm_klassifikation-priorisierung.yaml → ticket_typen"
+
+    schritt_2_klassifikation:
+      beschreibung: "Impact, Urgency und Priorität bestimmen"
+      
+      bei_incident:
+        - "Impact bewerten (Hoch/Normal/Niedrig)"
+        - "Urgency bewerten (Hoch/Normal/Niedrig)"
+        - "Priorität aus Matrix ableiten"
+      
+      bei_request:
+        - "Katalog-Eintrag identifizieren"
+        - "Service-Kategorie übernehmen"
+        - "Genehmigungsanforderung prüfen"
+      
+      referenz: "ssm_klassifikation-priorisierung.yaml"
+
+    schritt_3_pool_zuweisung:
+      beschreibung: "Ticket dem richtigen Pool zuweisen"
+      
+      pools:
+        - pool: "Sofort-Pool"
+          kriterien: "P1 (alle Charakteristiken)"
+          ziel: "Sofortige Bearbeitung"
+        
+        - pool: "Standard-Pool"
+          kriterien: "P2-P4 mit Charakteristik STANDARD oder ANALYSE"
+          ziel: "Bearbeitung gemäß SLA"
+        
+        - pool: "Projekt-Pool"
+          kriterien: "Charakteristik PROJEKT (planbar, >1 Tag Aufwand)"
+          ziel: "Koordinierte Bearbeitung"
+      
+      hinweis: |
+        Version 0.2: Der bisherige Analyse-Pool entfällt.
+        ANALYSE-Tickets werden im Standard-Pool bearbeitet.
+        Die Charakteristik ANALYSE bleibt als Label für Reporting erhalten.
+      
+      referenz: "ssm_klassifikation-priorisierung.yaml → pool_modell"
+
+    schritt_4_erste_reaktion:
+      beschreibung: "Nutzer über Ticket-Erstellung informieren"
+      inhalt:
+        - "Ticket-Nummer"
+        - "Kurze Bestätigung des Anliegens"
+        - "Erwartbare nächste Schritte"
+        - "Kontaktmöglichkeit bei Rückfragen"
+
+  qualitaetsanforderung:
+    
+    beschreibung: |
+      Die Triage-Qualität bestimmt maßgeblich die Effizienz der
+      nachfolgenden Bearbeitung. Fehlerhafte Klassifikation führt
+      zu Verzögerungen und Nacharbeit.
+    
+    schulungsbedarf: "Regelmäßige Schulung der Triage-Kriterien"
+    
+    feedback_loop: |
+      Bei häufigen Fehlklassifikationen: Anpassung der Kriterien
+      oder zusätzliche Schulung.
+
+# =============================================================================
+# QUEUE-KOORDINATION
+# =============================================================================
+
+queue_koordination:
+
+  beschreibung: |
+    Der Queue-Koordinator ist verantwortlich für die operative Steuerung
+    der Ticket-Queues. Er überwacht Workload, priorisiert innerhalb der
+    Pools und koordiniert bei Engpässen oder Konflikten.
+
+  rolle:
+    referenz: "ssm_rollen.yaml → queue_koordinator"
+    
+    besetzung:
+      primaer: "Definierte Person (z.B. Gruppenleiter)"
+      stellvertretung: "Muss für Abwesenheiten definiert sein"
+      modell: "Kann dediziert, rotierend oder in Teilzeit sein"
+      
+      offener_punkt: "OPEN-ROLLEN-001"
+
+  ueberwachungsaufgaben:
+
+    pool_monitoring:
+      beschreibung: "Kontinuierliche Überwachung aller Pools"
+      fokus:
+        - "Anzahl Tickets pro Pool"
+        - "Liegezeiten kritischer Tickets"
+        - "Verteilung auf Agents"
+      
+      werkzeug: "Dashboard (Echtzeit)"
+
+    kapazitaetssteuerung:
+      beschreibung: "Balance zwischen Pools und Agents"
+      aktivitaeten:
+        - "Erkennen von Kapazitätsengpässen"
+        - "Umverteilung bei Ungleichgewicht"
+        - "Eskalation bei Überlast"
+
+    sla_ueberwachung:
+      beschreibung: "Überwachung der SLA-Einhaltung"
+      aktivitaeten:
+        - "Frühwarnung bei SLA-Gefährdung"
+        - "Priorisierung gefährdeter Tickets"
+        - "Eskalation bei drohender Verletzung"
+
+  interventionsregeln:
+
+    beschreibung: |
+      Der Queue-Koordinator greift aktiv ein, wenn definierte
+      Schwellwerte erreicht werden.
+
+    trigger:
+
+      - situation: "Ticket >15 Min im Sofort-Pool"
+        aktion: "Sofortige Intervention, Zuweisung erzwingen"
+        eskalation: "Bei Ressourcenmangel → Support Manager"
+
+      - situation: "Ticket >30 Min im Sofort-Pool"
+        aktion: "Alarmierung Support Manager"
+        eskalation: "Automatisch"
+
+      - situation: "Agent hat 2 blockierte Tickets"
+        aktion: "Prüfung: Warum blockiert? Unterstützung anbieten"
+        eskalation: "Bei strukturellem Problem → Support Manager"
+
+      - situation: "Standard-Pool >20 Tickets"
+        aktion: "Kapazitätsalarm, Priorisierung, ggf. Umverteilung"
+        eskalation: "Bei anhaltendem Überlauf → Support Manager"
+
+      - situation: "Extreme Ungleichverteilung"
+        aktion: "Ausgleich zwischen Agents"
+        eskalation: "Keine, direkte Koordination"
+
+      - situation: "Übergabe nicht akzeptiert nach 4h"
+        aktion: "Klärung mit beteiligten Agents"
+        eskalation: "Bei Verweigerung → Support Manager"
+
+  interventionsstufen:
+
+    - stufe: 1
+      name: "Anfrage"
+      beschreibung: "Kannst du Ticket X übernehmen?"
+      anwendung: "Normalfall"
+
+    - stufe: 2
+      name: "Direktive Zuweisung"
+      beschreibung: "Bitte übernimm Ticket X, weil..."
+      anwendung: "Bei Dringlichkeit oder fehlender Reaktion"
+      dokumentation: "Begründung im Ticket"
+
+    - stufe: 3
+      name: "Eskalation"
+      beschreibung: "Weiterleitung an Support Manager"
+      anwendung: "Bei Verweigerung oder strukturellem Problem"
+
+  transparenz_dashboard:
+
+    beschreibung: |
+      Ein zentrales, für alle sichtbares Dashboard zeigt in Echtzeit
+      den Status der Queues und Agents.
+
+    inhalte:
+      - "Anzahl Tickets pro Pool"
+      - "Aktuelle Ticket-Verteilung pro Agent"
+      - "Liegezeiten kritischer Tickets"
+      - "Blockierte Tickets mit Grund"
+      - "Tages-Statistiken (geschlossen, neu, eskaliert)"
+
+    anforderung: "Muss im ITSM-Tool oder separat implementiert werden"
+    
+    offener_punkt: "OPEN-SD-002"
+
+# =============================================================================
+# ARBEITSORGANISATION
+# =============================================================================
+
+arbeitsorganisation:
+
+  # ---------------------------------------------------------------------------
+  # SINGLE-PIECE-FLOW
+  # ---------------------------------------------------------------------------
+  single_piece_flow:
+
+    beschreibung: |
+      Das Single-Piece-Flow-Prinzip begrenzt die gleichzeitige Bearbeitung
+      auf maximal 2 Tickets pro Agent. Dies reduziert Context-Switching
+      und verbessert Durchlaufzeiten.
+
+    regel:
+      primaer_ticket: "Hauptfokus (80% der Zeit)"
+      sekundaer_ticket: "Nur wenn Primär-Ticket blockiert ist"
+      maximum: "2 Tickets gleichzeitig"
+
+    begruendung:
+      - "Reduziert Context-Switching"
+      - "Verbessert Durchlaufzeiten"
+      - "Erhöht Lösungsqualität"
+      - "Macht Fortschritt sichtbar"
+
+    ausnahmen:
+      - "Kurzfristige Unterbrechung für P1-Ticket"
+      - "Warten auf Nutzer-Rückmeldung (Clock-Stop)"
+
+  # ---------------------------------------------------------------------------
+  # COMMITMENT-PRINZIP
+  # ---------------------------------------------------------------------------
+  commitment_prinzip:
+
+    beschreibung: |
+      Das Commitment-Prinzip etabliert klare Ownership: Ein gezogenes
+      Ticket gehört dem Agent bis zur Lösung oder formalen Übergabe.
+
+    grundregel: "Ticket gezogen = Ticket owned"
+
+    governance: "SSM-G-07"
+
+    legitime_ausgaenge:
+      - ausgang: "GELÖST"
+        beschreibung: "Ticket wird mit Lösung geschlossen"
+      
+      - ausgang: "ESKALIERT"
+        beschreibung: "Formale Weitergabe mit dokumentierter Begründung"
+        anforderung: "Definition of Handover (DoH) muss erfüllt sein"
+        referenz: "SSM-G-08"
+      
+      - ausgang: "GEPARKT"
+        beschreibung: "Wartet auf externe Aktion"
+        gruende:
+          - "WARTEN_NUTZER"
+          - "WARTEN_EXTERN"
+          - "WARTEN_CHANGE"
+
+    verboten:
+      - "Stille Rückgabe in den Pool"
+      - "Ownership-loses Ticket"
+      - "Weitergabe ohne Dokumentation"
+
+  # ---------------------------------------------------------------------------
+  # ENABLEMENT-PHILOSOPHIE (EIGENVERANTWORTLICHES ARBEITEN)
+  # ---------------------------------------------------------------------------
+  enablement_philosophie:
+
+    beschreibung: |
+      Der Service Desk verfolgt eine Enablement-Philosophie: Agents sind
+      eigenverantwortliche Problemlöser, nicht "Ticket-Schubser". Der Agent
+      entscheidet selbst über sein Vorgehen, die SLA gibt den Rahmen vor.
+
+    konzept:
+      - "Agent entscheidet eigenverantwortlich über sein Vorgehen"
+      - "Die SLA gibt den zeitlichen Rahmen vor"
+      - "Eskalation ist eine Option, keine Pflicht bei Unklarheit"
+      - "Dokumentation von Erkenntnissen ist erwünscht (nicht verpflichtend)"
+
+    bei_standard_tickets:
+      beschreibung: "Dokumentierte Lösung anwenden, schnelle Durchlaufzeit"
+      
+    bei_analyse_tickets:
+      beschreibung: |
+        Agent führt eigenständige Diagnose durch. Die SLA gibt den
+        zeitlichen Rahmen vor. Bei fehlender Lösung: Eskalation an L2.
+        
+        Die Charakteristik ANALYSE ist ein Label für Reporting,
+        keine Steuerungsgröße für einen separaten Pool.
+      
+    hinweis: |
+      Version 0.2: Das bisherige "Explorationsbudget" (90-120 Min) als
+      eigenständiges Konzept entfällt. Die SLA gibt den Zeitrahmen vor,
+      innerhalb dessen der Agent arbeitet. Die Enablement-Philosophie
+      (Agent darf eigenverantwortlich arbeiten) bleibt erhalten.
+
+    referenz: "ssm_design-zieldimensionen.yaml → LS-02"
+
+# =============================================================================
+# TEAM-ORGANISATION
+# =============================================================================
+
+team_organisation:
+
+  status: "EMPFEHLUNG"
+
+  hinweis: |
+    Die Team-Organisation ist eine operative Entscheidung von DIGIT.
+    Die folgenden Strukturen sind Empfehlungen basierend auf dem
+    Referenzmodell.
+
+  # ---------------------------------------------------------------------------
+  # MEETING-STRUKTUR
+  # ---------------------------------------------------------------------------
+  meeting_struktur:
+
+    taeglich:
+      name: "Stand-up"
+      dauer: "15 Minuten"
+      zeitpunkt: "Empfohlen: Beginn der Kernzeit"
+      teilnehmer: "Alle anwesenden Agents, Queue-Koordinator"
+      agenda:
+        - "Pool-Status Review"
+        - "Blockierte Tickets"
+        - "Kapazitäten des Tages"
+        - "Besondere Vorkommnisse"
+        - "Kurze Abstimmungen"
+
+    woechentlich:
+      name: "Team-Meeting"
+      dauer: "60 Minuten"
+      teilnehmer: "Gesamtes Team, Support Manager"
+      agenda:
+        - "Wochen-Review (Kennzahlen)"
+        - "Prozess-Verbesserungen"
+        - "Knowledge-Sharing"
+        - "Ankündigungen"
+        - "Team-Themen"
+
+    monatlich:
+      name: "Service Owner Review"
+      dauer: "2 Stunden"
+      teilnehmer: "Service Owner, First Level Vertreter, ggf. Second Level"
+      agenda:
+        - "Service-spezifische Themen"
+        - "Dokumentations-Review"
+        - "Verbesserungspotentiale"
+        - "Schulungsbedarfe"
+      
+      governance: "Pflicht, siehe ssm_governance.yaml"
+
+  # ---------------------------------------------------------------------------
+  # SCHICHTPLANUNG
+  # ---------------------------------------------------------------------------
+  schichtplanung:
+
+    status: "ANFORDERUNGEN"
+
+    anforderungen:
+
+      mindestbesetzung:
+        beschreibung: "Minimale Besetzung während Servicezeiten"
+        anforderung: "Mindestens 2 Agents"
+        begruendung: "Telefon + Ticket-Bearbeitung + Vertretung"
+
+      vertretungsregelung:
+        beschreibung: "Abdeckung bei Abwesenheit"
+        anforderungen:
+          - "Urlaub muss mit Mindestvorlauf angekündigt werden"
+          - "Krankheitsvertretung muss geregelt sein"
+          - "Queue-Koordinator-Stellvertretung muss definiert sein"
+
+      peak_zeiten:
+        beschreibung: "Erhöhte Besetzung zu Stoßzeiten"
+        empfehlung: "Identifikation typischer Peak-Zeiten aus Ticket-Daten"
+        anforderung: "Berücksichtigung bei Schichtplanung"
+
+    offener_punkt: "OPEN-SD-003"
+
+# =============================================================================
+# QUALITÄTSSTANDARDS
+# =============================================================================
+
+qualitaetsstandards:
+
+  status: "ANFORDERUNGEN"
+
+  # ---------------------------------------------------------------------------
+  # REAKTIONSZEITEN
+  # ---------------------------------------------------------------------------
+  reaktionszeiten:
+
+    beschreibung: |
+      Zielzeiten für die erste qualifizierte Reaktion auf Anfragen.
+      Konkrete Werte sind mit SLM abzustimmen.
+
+    anforderungen:
+      - kanal: "Telefon"
+        ziel: "Annahme innerhalb 30 Sekunden (während Servicezeit)"
+      
+      - kanal: "E-Mail"
+        ziel: "Erste Reaktion innerhalb SLA-Reaktionszeit"
+      
+      - kanal: "Portal"
+        ziel: "Automatische Bestätigung sofort, Bearbeitung gem. Priorität"
+
+    referenz: "spm_practice_service-level-management.yaml"
+
+  # ---------------------------------------------------------------------------
+  # KOMMUNIKATIONSSTANDARDS
+  # ---------------------------------------------------------------------------
+  kommunikationsstandards:
+
+    beschreibung: |
+      Qualitätsanforderungen an die Kommunikation mit Nutzern.
+
+    prinzipien:
+      - "Freundlich und professionell"
+      - "Verständliche Sprache (kein IT-Jargon)"
+      - "Proaktive Updates bei längerer Bearbeitung"
+      - "Klare Aussagen zu nächsten Schritten"
+      - "Erreichbarkeit für Rückfragen"
+
+    bei_eskalation:
+      - "Nutzer über Eskalation informieren"
+      - "Neuen Ansprechpartner nennen (wenn bekannt)"
+      - "Erwartbare Bearbeitungszeit kommunizieren"
+
+    bei_wartezeit:
+      - "Regelmäßige Status-Updates (mindestens alle 2 Arbeitstage)"
+      - "Proaktive Information bei Verzögerungen"
+      - "Transparenz über Gründe"
+
+  # ---------------------------------------------------------------------------
+  # DOKUMENTATIONSSTANDARDS
+  # ---------------------------------------------------------------------------
+  dokumentationsstandards:
+
+    beschreibung: |
+      Anforderungen an die Ticket-Dokumentation.
+
+    mindestanforderungen:
+      - "Vollständige Problembeschreibung"
+      - "Durchgeführte Diagnose-Schritte"
+      - "Lösung oder Eskalationsgrund"
+      - "Kommunikation mit Nutzer dokumentiert"
+
+    referenz: "ssm_schema_ticket.yaml"
+
+# =============================================================================
+# SCHNITTSTELLEN
+# =============================================================================
+
+schnittstellen:
+
+  intern:
+
+    - modul: "sub-practice_incident-management.yaml"
+      art: "führt aus"
+      beschreibung: "Service Desk führt Incident-Prozess operativ aus"
+
+    - modul: "sub-practice_request-management.yaml"
+      art: "führt aus"
+      beschreibung: "Service Desk führt Request-Prozess operativ aus"
+
+    - modul: "ssm_klassifikation-priorisierung.yaml"
+      art: "verwendet"
+      beschreibung: "Pool-System, Prioritäts-Matrix"
+
+    - modul: "ssm_rollen.yaml"
+      art: "implementiert"
+      beschreibung: "First Level Agent, Queue-Koordinator"
+
+    - modul: "ssm_wissensmanagement.yaml"
+      art: "nutzt und pflegt"
+      beschreibung: "KB-Nutzung und Ebene-3-Beiträge"
+
+    - modul: "ssm_governance.yaml"
+      art: "wird gesteuert durch"
+      beschreibung: "Eskalationslogik, Reporting"
+
+  extern:
+
+    - partner: "Second Level Support"
+      kontext: "Funktionale Eskalation"
+      schnittstelle: "Definition of Handover (DoH)"
+
+    - partner: "Service Owner"
+      kontext: "Befähigung, Dokumentation, Service-Reviews"
+      frequenz: "Monatlich"
+
+    - partner: "Nutzer / Anwender"
+      kontext: "Alle IT-Anfragen und Störungsmeldungen"
+      kanaele: ["Portal", "E-Mail", "Telefon", "Walk-in"]
+
+    - partner: "ITSM-Tool"
+      kontext: "Ticket-Erfassung, Queue-Management, Dashboard"
+      status: "Tool-Auswahl ausstehend"
+
+# =============================================================================
+# OFFENE PUNKTE
+# =============================================================================
+
+offene_punkte:
+
+  - id: "OPEN-SD-001"
+    thema: "Konkrete Servicezeiten"
+    beschreibung: |
+      Die konkreten Servicezeiten (Kernzeit, erweiterte Erreichbarkeit)
+      müssen mit DIGIT festgelegt werden.
+    prioritaet: "hoch"
+    status: "Mit DIGIT zu klären"
+
+  - id: "OPEN-SD-002"
+    thema: "Dashboard-Implementierung"
+    beschreibung: |
+      Das Transparenz-Dashboard muss im ITSM-Tool oder als separate
+      Lösung implementiert werden.
+    prioritaet: "mittel"
+    status: "Abhängig von Tool-Auswahl"
+
+  - id: "OPEN-SD-003"
+    thema: "Schichtplanung"
+    beschreibung: |
+      Konkrete Schichtplanung inkl. Vertretungsregelung muss mit
+      DIGIT erarbeitet werden.
+    prioritaet: "mittel"
+    status: "Operative Planung"
+
+  - id: "OPEN-SD-004"
+    thema: "Telefonie-Integration"
+    beschreibung: |
+      Integration der Telefonie (ACD, Warteschlange, Statistik) mit
+      dem ITSM-Tool.
+    prioritaet: "mittel"
+    status: "Technische Klärung"
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+  - version: "0.2"
+    datum: "2026-01-28"
+    aenderung: |
+      Anpassung an vereinfachtes Pool-Modell:
+      - Triage: Drei-Pool-Struktur (Sofort, Standard, Projekt)
+      - Analyse-Pool entfällt, ANALYSE-Tickets gehen in Standard-Pool
+      - "Indifferenzraum" umbenannt zu "Enablement-Philosophie"
+      - Explorationsbudget entfällt als eigenständiges Konzept
+      - SLA gibt Zeitrahmen vor, Agent arbeitet eigenverantwortlich
+    autor: "DIGITOM-Projekt"
+    
+  - version: "0.1"
+    datum: "2025-12-07"
+    aenderung: "Initiale Erstellung"
+    autor: "DIGITOM-Projekt"

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

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

#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_service-steckbrief.yaml

@@ -0,0 +1,657 @@
+# =============================================================================
+# SCHEMA: SERVICE-STECKBRIEF
+# =============================================================================
+#
+# Dieses Schema definiert die Struktur eines Service-Steckbriefs.
+# Der Service-Steckbrief ist die kundenorientierte Darstellung eines Services
+# im Service-Katalog – ein Auszug aus der Service-Definition.
+#
+# Abgrenzung:
+# - Service-Definition = internes Master-Dokument (spm_schema_service-definition.yaml)
+# - Service-Steckbrief = kundenorientierter Auszug (dieses Schema)
+#
+# Prinzip:
+# - Der Steckbrief enthält NUR Informationen, die für Kunden relevant sind
+# - Technische Details, interne Prozesse und Kostenstrukturen werden ausgeblendet
+# - Die Sprache ist bewusst nicht-technisch und verständlich
+#
+# =============================================================================
+
+schema:
+  name: "Service-Steckbrief"
+  version: "0.3"
+  status: "draft"
+  erstellt: "2025-11-27"
+  geaendert: "2026-01-31"
+  projekt: "DIGITOM"
+  
+  beschreibung: >
+    Der Service-Steckbrief ist die offizielle, kundenorientierte Beschreibung 
+    eines Services im Service-Katalog. Er beantwortet die Fragen, die Ämter 
+    und Mitarbeitende typischerweise haben: Was ist der Service? Was bekomme 
+    ich? Was bekomme ich nicht? Wie gut ist er? Wie beantrage ich ihn?
+  
+  ableitung_von: "spm_schema_service-definition.yaml"
+  
+  verantwortung:
+    inhalt: "Service Owner (liefert)"
+    qualitaetssicherung: "Service-Portfolio-Manager (prüft Konsistenz und Verständlichkeit)"
+    freigabe: "Service-Portfolio-Manager"
+    publikation: "Service-Portfolio-Manager"
+  
+  zielgruppe:
+    primaer: "Mitarbeitende der Stadtverwaltung (Nutzer)"
+    sekundaer: "Amtsleitungen und deren Delegierte (Kunden/Entscheider)"
+  
+  publikationsort:
+    beschreibung: >
+      Der Service-Steckbrief wird im Service-Katalog publiziert. 
+      Der konkrete Publikationskanal (Intranet, Self-Service-Portal) 
+      ist implementierungsabhängig.
+    anforderung: "Barrierefreier, durchsuchbarer Zugang für alle Zielgruppen"
+
+# =============================================================================
+# ATTRIBUT-DEFINITIONEN
+# =============================================================================
+
+attribute:
+
+  # ---------------------------------------------------------------------------
+  # IDENTIFIKATION
+  # ---------------------------------------------------------------------------
+  identifikation:
+    beschreibung: "Eindeutige Identifikation und Grundinformationen"
+    
+    attribute:
+      - name: "service_id"
+        typ: "string"
+        pflicht: true
+        beschreibung: "Eindeutiger Identifier (aus Service-Definition übernommen)"
+        quelle: "service-definition.metadaten.service_id"
+        sichtbarkeit: "Kann angezeigt werden, primär für Referenzzwecke"
+      
+      - name: "service_name"
+        typ: "string"
+        pflicht: true
+        beschreibung: "Offizieller Name des Services"
+        quelle: "service-definition.identitaet.service_name"
+        beispiel: "Digitaler Arbeitsplatz"
+      
+      - name: "service_name_kurz"
+        typ: "string"
+        pflicht: false
+        beschreibung: "Kurzbezeichnung oder Akronym (falls gebräuchlich)"
+        quelle: "service-definition.identitaet.service_name_kurz"
+        beispiel: "DAP"
+      
+      - name: "version"
+        typ: "string"
+        pflicht: true
+        beschreibung: "Version des Steckbriefs"
+        quelle: "service-definition.metadaten.version"
+      
+      - name: "stand"
+        typ: "date"
+        pflicht: true
+        beschreibung: "Datum der letzten Aktualisierung"
+        quelle: "service-definition.metadaten.geaendert_am"
+        anzeige_format: "TT.MM.JJJJ"
+
+  # ---------------------------------------------------------------------------
+  # ÜBERBLICK
+  # ---------------------------------------------------------------------------
+  ueberblick:
+    beschreibung: "Schnelle Orientierung: Was ist das? Für wen?"
+    
+    attribute:
+      - name: "kurzbeschreibung"
+        typ: "string"
+        pflicht: true
+        beschreibung: "Einzeilige Beschreibung (max. 200 Zeichen)"
+        quelle: "service-definition.identitaet.kurzbeschreibung"
+        hinweis: "Soll auch ohne Kontext verständlich sein"
+        beispiel: "Standardisierter PC-Arbeitsplatz mit Office-Anwendungen und E-Mail für alle Mitarbeitenden"
+      
+      - name: "nutzen"
+        typ: "text"
+        pflicht: true
+        beschreibung: >
+          Was bringt mir dieser Service? Welches Problem löst er?
+          Formulierung aus Kundenperspektive, nicht aus IT-Sicht.
+        quelle: "service-definition.identitaet.zweck"
+        transformation: "Ggf. Umformulierung in kundenorientierte Sprache"
+        beispiel: >
+          Mit dem Digitalen Arbeitsplatz können Sie Ihre täglichen 
+          Büroaufgaben erledigen: E-Mails schreiben, Dokumente erstellen, 
+          an Videokonferenzen teilnehmen und auf zentrale Anwendungen zugreifen.
+      
+      - name: "zielgruppe"
+        typ: "list[string]"
+        pflicht: true
+        beschreibung: "Für wen ist dieser Service gedacht?"
+        quelle: "service-definition.identitaet.zielgruppe"
+        beispiel:
+          - "Alle Mitarbeitenden der Stadtverwaltung"
+      
+      - name: "service_kategorie"
+        typ: "objekt"
+        pflicht: true
+        beschreibung: "Art des Services (beeinflusst Verfügbarkeit und Beantragung)"
+        quelle: "service-definition.identitaet.service_kategorie"
+        schema:
+          - name: "kategorie_id"
+            typ: "enum"
+            werte: ["A", "B", "C"]
+          - name: "kategorie_bezeichnung"
+            typ: "string"
+            beschreibung: "Kundenfreundliche Bezeichnung"
+            mapping:
+              A: "Basis-Service (für alle Mitarbeitenden)"
+              B: "Erweiterungs-Service (optional buchbar)"
+              C: "Spezial-Service (für bestimmte Ämter)"
+          - name: "hinweis"
+            typ: "string"
+            pflicht: false
+            beschreibung: "Zusatzinformation zur Kategorie"
+            beispiel_c: "Dieser Service ist exklusiv für das Amt für Soziales verfügbar."
+
+  # ---------------------------------------------------------------------------
+  # LEISTUNGSUMFANG
+  # ---------------------------------------------------------------------------
+  leistungsumfang:
+    beschreibung: "Was bekomme ich? Was bekomme ich nicht?"
+    
+    attribute:
+      - name: "das_ist_enthalten"
+        typ: "list[string]"
+        pflicht: true
+        beschreibung: "Konkrete Leistungen, die im Service enthalten sind"
+        quelle: "service-definition.leistungsumfang.leistungen_inkludiert"
+        hinweis: "Kundenverständlich formulieren, keine technischen Details"
+        beispiel:
+          - "Windows-PC oder Laptop"
+          - "Microsoft Office (Word, Excel, PowerPoint, Outlook)"
+          - "E-Mail-Postfach mit 5 GB Speicher"
+          - "Zugang zum städtischen Netzwerk"
+          - "Standarddrucker in Ihrem Gebäude"
+      
+      - name: "das_ist_nicht_enthalten"
+        typ: "list[string]"
+        pflicht: true
+        beschreibung: "Explizit nicht enthaltene Leistungen"
+        quelle: "service-definition.leistungsumfang.leistungen_exkludiert"
+        hinweis: "Vermeidet Missverständnisse und Enttäuschungen"
+        beispiel:
+          - "Spezialsoftware (z.B. CAD, Statistik) – siehe Erweiterungs-Services"
+          - "Diensthandy – siehe Service 'Mobile Endgeräte'"
+          - "Individuelle Software-Installationen"
+      
+      - name: "voraussetzungen"
+        typ: "list[string]"
+        pflicht: false
+        beschreibung: "Was muss gegeben sein, damit ich den Service nutzen kann?"
+        quelle: "service-definition.leistungsumfang.voraussetzungen"
+        beispiel:
+          - "Gültiger Benutzeraccount (wird bei Dienstantritt automatisch erstellt)"
+          - "Abgeschlossene IT-Sicherheitsunterweisung"
+
+  # ---------------------------------------------------------------------------
+  # SERVICEQUALITÄT
+  # ---------------------------------------------------------------------------
+  servicequalitaet:
+    beschreibung: "Wie gut ist der Service? Wann ist er verfügbar?"
+    
+    attribute:
+      - name: "verfuegbarkeit"
+        typ: "objekt"
+        pflicht: true
+        beschreibung: "Wann kann ich den Service nutzen?"
+        quelle: "service-definition.qualitaet.verfuegbarkeit"
+        schema:
+          - name: "servicezeit"
+            typ: "string"
+            beschreibung: "Wann ist der Service verfügbar?"
+            beispiel: "Montag bis Freitag, 6:00 bis 22:00 Uhr; Samstag 8:00 bis 14:00 Uhr"
+          - name: "wartungsfenster"
+            typ: "string"
+            beschreibung: "Wann finden geplante Wartungen statt?"
+            beispiel: "Sonntags zwischen 2:00 und 6:00 Uhr (der Service kann in dieser Zeit eingeschränkt sein)"
+      
+      - name: "service_level_dokument"
+        typ: "objekt"
+        pflicht: true
+        beschreibung: >
+          Verweis auf die detaillierten Qualitätszusagen.
+          Die Struktur unterscheidet sich je nach Service-Kategorie.
+        quelle: "service-definition.qualitaet.service_level_referenz"
+        schema:
+          - name: "typ"
+            typ: "enum"
+            werte:
+              - id: "SLS"
+                anzeige: "Service Level Specification"
+                beschreibung: "Detaillierte Qualitätsbeschreibung für diesen Service"
+              - id: "SLA_integriert"
+                anzeige: "Individuelle Vereinbarung"
+                beschreibung: "Die Qualitätszusagen sind Teil der bilateralen Vereinbarung mit Ihrem Amt"
+          - name: "dokument_titel"
+            typ: "string"
+            beschreibung: "Titel des referenzierten Dokuments"
+          - name: "dokument_link"
+            typ: "string"
+            pflicht: false
+            beschreibung: "Link zum Dokument (falls öffentlich zugänglich)"
+          - name: "hinweis"
+            typ: "string"
+            pflicht: false
+            beispiel_c: "Für Details wenden Sie sich an Ihre Amtsleitung oder den Service Owner."
+      
+      - name: "qualitaets_highlights"
+        typ: "list[string]"
+        pflicht: false
+        beschreibung: >
+          Ausgewählte, kundenrelevante Qualitätsmerkmale aus der SLS.
+          Keine vollständige Liste, sondern die wichtigsten Punkte.
+        transformation: "Extraktion aus SLS, kundenverständlich formuliert"
+        beispiel:
+          - "Verfügbarkeit: 99,5% während der Servicezeiten"
+          - "Bei Störungen: Reaktion innerhalb von 4 Stunden"
+          - "Geplante Wartungen werden mindestens 3 Tage vorher angekündigt"
+
+  # ---------------------------------------------------------------------------
+  # SUPPORT & KONTAKT
+  # ---------------------------------------------------------------------------
+  support:
+    beschreibung: "Wie bekomme ich Hilfe? An wen wende ich mich?"
+    
+    attribute:
+      - name: "supportzeiten"
+        typ: "string"
+        pflicht: true
+        beschreibung: "Wann ist der Support erreichbar?"
+        quelle: "service-definition.qualitaet.verfuegbarkeit.supportzeit"
+        beispiel: "Montag bis Freitag, 8:00 bis 17:00 Uhr"
+      
+      - name: "kontaktwege"
+        typ: "list[objekt]"
+        pflicht: true
+        beschreibung: "Wie erreiche ich den Support?"
+        schema:
+          - name: "kanal"
+            typ: "string"
+            beispiele: ["Telefon", "E-Mail", "Self-Service-Portal", "Vor Ort"]
+          - name: "details"
+            typ: "string"
+            beispiele: 
+              - "0761 / 201-XXXX"
+              - "servicedesk@digit.freiburg.de"
+              - "https://selfservice.digit.freiburg.de"
+          - name: "hinweis"
+            typ: "string"
+            pflicht: false
+            beispiel: "Für schnelle Hilfe bei Störungen"
+      
+      - name: "service_owner_kontakt"
+        typ: "objekt"
+        pflicht: true
+        beschreibung: "Ansprechperson für grundsätzliche Fragen zum Service"
+        quelle: "service-definition.verantwortlichkeiten.service_owner"
+        schema:
+          - name: "name"
+            typ: "string"
+            quelle: "service_owner.person_name"
+          - name: "rolle"
+            typ: "string"
+            wert: "Service Owner"
+          - name: "kontakt"
+            typ: "string"
+            pflicht: false
+            beschreibung: "E-Mail (nur wenn explizit freigegeben)"
+            hinweis: >
+              Im Regelfall sollten Anfragen über den Service Desk laufen.
+              Der direkte Kontakt zum SO ist für strategische Fragen 
+              und Amtsleitungen gedacht.
+
+  # ---------------------------------------------------------------------------
+  # BEANTRAGUNG
+  # ---------------------------------------------------------------------------
+  beantragung:
+    beschreibung: "Wie bekomme ich den Service?"
+    
+    attribute:
+      - name: "beantragungswege"
+        typ: "list[objekt]"
+        pflicht: true
+        beschreibung: "Wie kann ich den Service anfordern?"
+        quelle: "service-definition.betriebsmodell.request_wege"
+        schema:
+          - name: "weg"
+            typ: "string"
+            beispiele:
+              - "Self-Service-Portal"
+              - "Service Desk"
+              - "Über Ihre Amtsleitung"
+          - name: "link"
+            typ: "string"
+            pflicht: false
+          - name: "hinweis"
+            typ: "string"
+            pflicht: false
+            beispiel: "Für Basis-Services ist keine Beantragung nötig – Sie erhalten den Service automatisch."
+      
+      - name: "berechtigungslogik"
+        typ: "text"
+        pflicht: false
+        beschreibung: "Wer darf den Service beantragen/nutzen?"
+        transformation: "Ableitung aus service_kategorie und zielgruppe"
+        beispiele:
+          kategorie_a: "Alle Mitarbeitenden erhalten diesen Service automatisch bei Dienstantritt."
+          kategorie_b: "Die Beantragung erfolgt über Ihre Amtsleitung. Es können Kosten für Ihr Amt entstehen."
+          kategorie_c: "Dieser Service ist nur für berechtigte Ämter verfügbar. Bei Interesse wenden Sie sich an den Service Owner."
+
+  # ---------------------------------------------------------------------------
+  # DATENSCHUTZ & HINWEISE
+  # ---------------------------------------------------------------------------
+  hinweise:
+    beschreibung: "Wichtige Hinweise für Nutzer"
+    
+    attribute:
+      - name: "datenschutz_hinweis"
+        typ: "text"
+        pflicht: true
+        beschreibung: "Kundenverständlicher Hinweis zum Datenschutz"
+        quelle: "service-definition.compliance.datenschutz_klassifikation"
+        transformation:
+          keine_pbD: "In diesem Service werden keine personenbezogenen Daten verarbeitet."
+          pbD_normal: "In diesem Service werden personenbezogene Daten verarbeitet. Die Verarbeitung erfolgt gemäß DSGVO und LDSG BW."
+          pbD_hoch: "In diesem Service werden sensible personenbezogene Daten verarbeitet. Bitte beachten Sie die besonderen Schutzmaßnahmen in der Nutzungsanleitung."
+          besondere_kategorien: "In diesem Service werden besonders schützenswerte Daten verarbeitet (z.B. Gesundheitsdaten). Die Nutzung erfordert besondere Sorgfalt. Details finden Sie in der Datenschutzdokumentation."
+      
+      - name: "wichtige_hinweise"
+        typ: "list[string]"
+        pflicht: false
+        beschreibung: "Sonstige wichtige Hinweise für Nutzer"
+        beispiel:
+          - "Bitte melden Sie sich am Ende des Arbeitstages ab, um Sicherheitsrisiken zu vermeiden."
+          - "Private Nutzung ist nur im Rahmen der IT-Nutzungsrichtlinie gestattet."
+
+  # ---------------------------------------------------------------------------
+  # WEITERFÜHRENDE INFORMATIONEN
+  # ---------------------------------------------------------------------------
+  weiterführend:
+    beschreibung: "Links zu weiteren Dokumenten und Ressourcen"
+    
+    attribute:
+      - name: "dokumente"
+        typ: "list[objekt]"
+        pflicht: false
+        beschreibung: "Für Kunden relevante Dokumente"
+        quelle: "service-definition.dokumentation.dokumente (gefiltert)"
+        filter: "Nur Dokumente mit typ in ['sls', 'benutzerhandbuch', 'faq', 'schulungsunterlage']"
+        schema:
+          - name: "titel"
+            typ: "string"
+          - name: "typ"
+            typ: "enum"
+            werte:
+              - id: "sls"
+                anzeige: "Qualitätsbeschreibung"
+              - id: "benutzerhandbuch"
+                anzeige: "Benutzerhandbuch"
+              - id: "faq"
+                anzeige: "Häufige Fragen"
+              - id: "schulungsunterlage"
+                anzeige: "Schulungsmaterial"
+          - name: "link"
+            typ: "string"
+      
+      - name: "verwandte_services"
+        typ: "list[objekt]"
+        pflicht: false
+        beschreibung: "Services, die für Nutzer dieses Services relevant sein könnten"
+        schema:
+          - name: "service_id"
+            typ: "string"
+          - name: "service_name"
+            typ: "string"
+          - name: "beziehung"
+            typ: "string"
+            beispiele:
+              - "Ergänzend verfügbar"
+              - "Alternative für spezielle Anforderungen"
+              - "Wird für diesen Service benötigt"
+
+# =============================================================================
+# DARSTELLUNGSVARIANTEN (VIEWS)
+# =============================================================================
+
+views:
+  beschreibung: >
+    Der Service-Steckbrief kann in verschiedenen Kontexten unterschiedlich 
+    dargestellt werden. Die Views definieren, welche Attribute in welchem 
+    Kontext angezeigt werden.
+
+  varianten:
+    - name: "katalog_uebersicht"
+      beschreibung: "Listenansicht im Service-Katalog"
+      anzeige:
+        - service_name
+        - kurzbeschreibung
+        - service_kategorie.kategorie_bezeichnung
+        - zielgruppe (gekürzt)
+      
+    - name: "katalog_detail"
+      beschreibung: "Vollständige Detailansicht eines Services"
+      anzeige: "Alle Attribute"
+    
+    - name: "request_katalog"
+      beschreibung: "Ansicht im ITSM-Tool für Service-Anfragen"
+      anzeige:
+        - service_name
+        - kurzbeschreibung
+        - das_ist_enthalten
+        - das_ist_nicht_enthalten
+        - beantragungswege
+        - kontaktwege
+      hinweis: >
+        Diese View wird für die Integration mit dem ITSM-Tool benötigt.
+        Die konkrete Implementierung hängt vom gewählten Tool ab.
+    
+    - name: "entscheider_view"
+      beschreibung: "Ansicht für Amtsleitungen (Steuerungsperspektive)"
+      anzeige:
+        - service_name
+        - kurzbeschreibung
+        - service_kategorie
+        - service_level_dokument
+        - service_owner_kontakt
+        - berechtigungslogik
+      zusaetzlich:
+        - sla_referenz: "Link zum vollständigen SLA (falls vorhanden)"
+
+# =============================================================================
+# VALIDIERUNGSREGELN
+# =============================================================================
+
+validierung:
+
+  regeln:
+    - id: "VAL-STB-001"
+      beschreibung: "Kurzbeschreibung muss ohne Kontext verständlich sein"
+      typ: "qualitativ"
+      pruefung: "Review durch SHM oder SPM"
+    
+    - id: "VAL-STB-002"
+      beschreibung: "Keine technischen Fachbegriffe ohne Erklärung"
+      typ: "qualitativ"
+      pruefung: "Review durch SHM"
+    
+    - id: "VAL-STB-003"
+      beschreibung: "Mindestens ein Kontaktweg muss angegeben sein"
+      typ: "formal"
+      regel: "kontaktwege.length >= 1"
+    
+    - id: "VAL-STB-004"
+      beschreibung: "Bei Kategorie B/C muss Berechtigungslogik ausgefüllt sein"
+      typ: "formal"
+      regel: >
+        Wenn service_kategorie in ['B', 'C'], 
+        dann berechtigungslogik darf nicht leer sein.
+    
+    - id: "VAL-STB-005"
+      beschreibung: "Service-Level-Dokument muss referenziert sein"
+      typ: "formal"
+      regel: "service_level_dokument.typ ist gesetzt"
+
+  qualitaetskriterien:
+    beschreibung: >
+      Qualitative Kriterien, die vor Publikation geprüft werden sollten.
+      Verantwortung: SPM in Abstimmung mit SHM.
+    
+    kriterien:
+      - "Verständlichkeit: Ein fachfremder Mitarbeitender versteht den Steckbrief"
+      - "Vollständigkeit: Alle Pflichtfelder sind ausgefüllt"
+      - "Konsistenz: Informationen widersprechen nicht der Service-Definition"
+      - "Aktualität: Informationen entsprechen dem aktuellen Stand"
+      - "Barrierefreiheit: Texte sind in einfacher Sprache verfasst"
+
+# =============================================================================
+# PFLEGEPROZESS
+# =============================================================================
+
+pflege:
+
+  trigger:
+    beschreibung: "Wann muss der Steckbrief aktualisiert werden?"
+    ereignisse:
+      - trigger: "Änderung der Service-Definition"
+        aktion: "Prüfen, ob Steckbrief betroffen"
+        verantwortung: "Service Owner"
+      
+      - trigger: "SLS/SLA-Änderung"
+        aktion: "Qualitäts-Highlights und Referenzen aktualisieren"
+        verantwortung: "Service Owner"
+      
+      - trigger: "Änderung Kontaktdaten"
+        aktion: "Support-Abschnitt aktualisieren"
+        verantwortung: "Service Owner"
+      
+      - trigger: "Jährlicher Katalog-Review"
+        aktion: "Vollständige Prüfung aller Steckbriefe"
+        verantwortung: "SPM"
+
+  aenderungstypen:
+    beschreibung: "Klassifikation von Änderungen für Governance-Routing"
+    
+    typen:
+      - typ: "redaktionell"
+        beispiele:
+          - "Korrektur Tippfehler"
+          - "Aktualisierung Telefonnummer"
+          - "Umformulierung ohne inhaltliche Änderung"
+        entscheidung: "Service Owner (autonom)"
+        publikation: "sofort"
+      
+      - typ: "inhaltlich_minor"
+        beispiele:
+          - "Ergänzung FAQ-Link"
+          - "Klarstellung Leistungsumfang (ohne Änderung)"
+          - "Hinzufügen verwandter Service"
+        entscheidung: "Service Owner + SPM (bilateral)"
+        publikation: "nach Freigabe SPM"
+      
+      - typ: "inhaltlich_major"
+        beispiele:
+          - "Änderung Leistungsumfang"
+          - "Neue/geänderte Service Levels"
+          - "Änderung Zielgruppe"
+        entscheidung: "SOR"
+        publikation: "nach SOR-Freigabe"
+        hinweis: "Meist gekoppelt an Änderung der Service-Definition"
+
+# =============================================================================
+# SCHNITTSTELLE ZU ITSM-TOOL
+# =============================================================================
+
+itsm_integration:
+  beschreibung: >
+    Der Service-Steckbrief dient als Stammdatenquelle für den Request-Katalog 
+    im ITSM-Tool. Diese Sektion definiert die Anforderungen an die Integration.
+  
+  status: "Anforderungsdefinition (Tool noch nicht final)"
+  
+  anforderungen:
+    - id: "ITSM-REQ-001"
+      beschreibung: "Service-ID muss als eindeutiger Schlüssel dienen"
+    
+    - id: "ITSM-REQ-002"
+      beschreibung: "Beantragungswege müssen in Request-Formulare überführbar sein"
+    
+    - id: "ITSM-REQ-003"
+      beschreibung: "Änderungen am Steckbrief müssen in das ITSM-Tool synchronisiert werden"
+      hinweis: "Richtung: SCM → ITSM (unidirektional)"
+    
+    - id: "ITSM-REQ-004"
+      beschreibung: "Kategorie-basierte Sichtbarkeitssteuerung muss möglich sein"
+      detail: >
+        Kategorie A: Für alle sichtbar
+        Kategorie B: Für alle sichtbar, Beantragung eingeschränkt
+        Kategorie C: Nur für berechtigte Ämter sichtbar
+  
+  datenhoheit: "SCM (Service-Steckbrief ist führend)"
+
+# =============================================================================
+# OFFENE PUNKTE
+# =============================================================================
+
+offene_punkte:
+  - id: "OPEN-STB-001"
+    beschreibung: "Template für Service-Steckbrief erstellen (Markdown/HTML)"
+    prioritaet: "hoch"
+    ziel_ordner: "02.6_arbeitsmaterialien"
+  
+  - id: "OPEN-STB-002"
+    beschreibung: "Abstimmung mit SHM: Qualitätskriterien für Verständlichkeit"
+    prioritaet: "mittel"
+    abhaengig_von: "Finalisierung SHM-Rollenbeschreibung"
+  
+  - id: "OPEN-STB-003"
+    beschreibung: "ITSM-Tool-Auswahl: Konkrete Mapping-Spezifikation"
+    prioritaet: "niedrig"
+    status: "Wartet auf Tool-Entscheidung"
+  
+  - id: "OPEN-STB-004"
+    beschreibung: "Barrierefreiheit: Prüfung gegen BITV 2.0"
+    prioritaet: "mittel"
+    hinweis: "Relevant für Publikationsformat"
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+  - version: "0.1"
+    datum: "2025-11-27"
+    aenderung: "Initiale Version erstellt"
+    autor: "DIGITOM-Projekt"
+
+  - version: "0.2"
+    datum: "2025-12-17"
+    aenderung: |
+      - Neuer Abschnitt 'review_status' fuer Service-Review-Ergebnisse (GOV-SR-001)
+      - Neuer Abschnitt 'laufende_verbesserungen' fuer Improvement-Tracking (GOV-SR-005)
+      - Neuer Pflege-Trigger fuer quartalsweisen Service-Review
+    autor: "DIGITOM-Projekt"
+    referenz: "konzept_service-review.yaml"
+
+  - version: "0.3"
+    datum: "2026-01-31"
+    aenderung: |
+      - Abschnitt 'review_status' entfernt (verschoben nach Service-Definition)
+      - Abschnitt 'laufende_verbesserungen' entfernt (verschoben nach Service-Definition)
+      - Pflege-Trigger fuer quartalsweisen Service-Review entfernt
+      - Begruendung: Review- und Improvement-Informationen sind interne Steuerungsdaten,
+        nicht kundenrelevant. Sie gehoeren in die Service-Definition (Single Source of Truth),
+        nicht in den kundenorientierten Service-Steckbrief.
+    autor: "DIGITOM-Projekt"
+    referenz: "Begriffsbereinigung: Service-Steckbrief = Kundenansicht"

#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_transition-steckbrief.yaml

@@ -0,0 +1,633 @@
+# =============================================================================
+# SCHEMA: TRANSITION-STECKBRIEF
+# =============================================================================
+# Pfad: 02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/
+# Dateiname: spm_schema_transition-steckbrief.yaml
+# =============================================================================
+
+metadata:
+  id: "SCHEMA-TR-STECKBRIEF"
+  name: "Schema Transition-Steckbrief"
+  version: "0.3"
+  status: "draft"
+  erstellt: "2025-12-17"
+  aktualisiert: "2026-02-18"
+  projekt: "DIGITOM"
+  organisation: "Stadt Freiburg / DIGIT"
+  dokumenttyp: "schema"
+  
+  beschreibung: |
+    Schema-Definition für den Transition-Steckbrief. Der Transition-
+    Steckbrief ist ein temporäres Prozessdokument, das die Service 
+    Transition von Gate 1 (tr_01, Entry-Gate) bis zum ELS-Exit dokumentiert.
+    
+    Nach Abschluss wird er als Anhang in den Service-Steckbrief überführt.
+    
+    Hinweis zur Gate-Nummerierung: Gate 1 (tr_01) ist das Entry-Gate der
+    Transition-Phase. Gate 2 (tr_09) ist die Entry-Prüfung nach Build,
+    Gate 3 (tr_12) ist die Go-Live-Freigabe. Alle drei Gates gehören zur
+    Transition-Phase und werden im Transition-Steckbrief dokumentiert.
+  
+  mvp_hinweis: |
+    Dieses Schema folgt dem MVP-Ansatz: Minimale Pflichtfelder, 
+    Freitext wo sinnvoll, keine Über-Strukturierung. Erweiterungen 
+    basierend auf operativer Erfahrung sind explizit vorgesehen.
+  
+  referenzen:
+    governance:
+      - "GOV-TR-018: Einführung Transition-Steckbrief"
+      - "GOV-TR-019: Überführung in Service-Steckbrief"
+      - "GOV-TR-020: Begriffliches Mapping"
+    konzept: "02a_lifecycle-konzepte/konzept_service-transition.yaml"
+    verwandtes_schema: "spm_schema_service-steckbrief.yaml"
+    arbeitspakete:
+      - "AP-01: Gate-Struktur"
+      - "AP-02: Entscheidungskriterien"
+      - "AP-03: Governance-Verfahren"
+      - "AP-04: ELS-Konzept"
+      - "AP-05: Rollback-Szenarien"
+
+# =============================================================================
+# SCHEMA-DEFINITION
+# =============================================================================
+
+schema:
+
+  # ---------------------------------------------------------------------------
+  # HEADER
+  # ---------------------------------------------------------------------------
+  header:
+    beschreibung: "Identifikation und Statusverfolgung"
+    
+    felder:
+      
+      - name: "id"
+        typ: "string"
+        pflicht: true
+        beschreibung: "Eindeutige ID des Transition-Steckbriefs"
+        format: "TR-[SERVICE-ID]-[YYYY]"
+        beispiel: "TR-SVC-001-2025"
+      
+      - name: "service_referenz"
+        typ: "string"
+        pflicht: true
+        beschreibung: "ID des zugehörigen Service-Steckbriefs"
+        beispiel: "SVC-001"
+      
+      - name: "service_name"
+        typ: "string"
+        pflicht: true
+        beschreibung: "Name des Services (für Lesbarkeit)"
+        beispiel: "Dokumentenmanagement-System"
+      
+      - name: "transition_typ"
+        typ: "enum"
+        pflicht: true
+        beschreibung: "Art der Transition"
+        werte:
+          - "neuer_service"
+          - "wesentliche_aenderung"
+        mvp_hinweis: "Für MVP nur diese zwei Typen. Differenzierung nach Service-Kategorie kann später ergänzt werden."
+      
+      - name: "status"
+        typ: "enum"
+        pflicht: true
+        beschreibung: "Aktueller Status im Transition-Prozess"
+        werte:
+          - "angelegt"
+          - "gate_2_offen"
+          - "gate_2_passiert"
+          - "pilot_aktiv"
+          - "gate_3_offen"
+          - "go_live"
+          - "els_aktiv"
+          - "abgeschlossen"
+          - "abgebrochen"
+      
+      - name: "transition_start"
+        typ: "date"
+        pflicht: true
+        beschreibung: "Datum des Gate-1-Eintritts (tr_01) in die Transition-Phase"
+      
+      - name: "transition_ende"
+        typ: "date"
+        pflicht: false
+        beschreibung: "Datum des ELS-Exit (bei Abschluss)"
+
+  # ---------------------------------------------------------------------------
+  # GATE 2: ENTRY-PRÜFUNG NACH BUILD
+  # ---------------------------------------------------------------------------
+  gate_2:
+    beschreibung: "Dokumentation der Entry-Prüfung nach Build (Gate-Keeper: Service Owner)"
+    lifecycle_aktivitaet: "tr_09"
+    referenz: "AP-01, AP-02"
+    
+    felder:
+      
+      - name: "datum"
+        typ: "date"
+        pflicht: true
+        beschreibung: "Datum der Gate-2-Entscheidung"
+      
+      - name: "entscheidung"
+        typ: "enum"
+        pflicht: true
+        beschreibung: "Ergebnis der Gate-2-Prüfung"
+        werte:
+          - "freigabe"
+          - "freigabe_mit_auflagen"
+          - "zurueckweisung"
+          - "eskalation_an_sor"
+      
+      # --- Prüfdimensionen ---
+      - name: "pruefung_uebergabe_vollstaendigkeit"
+        typ: "enum"
+        pflicht: true
+        beschreibung: "Liegen alle Artefakte aus der Build-Phase vor? (Showstopper)"
+        werte:
+          - "erfuellt"
+          - "nicht_erfuellt"
+        referenz: "AP-02, G2-DIM-01"
+      
+      - name: "pruefung_betriebsvorbereitung"
+        typ: "enum"
+        pflicht: true
+        beschreibung: "Sind Betrieb und Support informiert/vorbereitet?"
+        werte:
+          - "erfuellt"
+          - "mit_auflagen"
+          - "nicht_erfuellt"
+        referenz: "AP-02, G2-DIM-02"
+      
+      # --- Pilot-Entscheidung ---
+      - name: "pilot_erforderlich"
+        typ: "boolean"
+        pflicht: true
+        beschreibung: "Ist ein Pilot vor Go-Live erforderlich?"
+        referenz: "AP-01, Pilot-Konzept"
+      
+      - name: "pilot_begruendung"
+        typ: "text"
+        pflicht: false
+        beschreibung: "Begründung für Pilot-Entscheidung (bei ja oder bei bewusstem Verzicht)"
+        max_zeichen: 500
+      
+      # --- Auflagen ---
+      - name: "auflagen"
+        typ: "text"
+        pflicht: false
+        beschreibung: "Auflagen bei 'freigabe_mit_auflagen' (Beschreibung, Frist, Verantwortlicher)"
+        hinweis: "Freitext für MVP. Strukturierte Auflagen-Liste kann später ergänzt werden."
+      
+      # --- Begründung ---
+      - name: "begruendung"
+        typ: "text"
+        pflicht: false
+        beschreibung: "Begründung bei Zurückweisung oder Eskalation"
+        max_zeichen: 500
+
+  # ---------------------------------------------------------------------------
+  # PILOT (optional)
+  # ---------------------------------------------------------------------------
+  pilot:
+    beschreibung: "Dokumentation der Pilot-Phase (nur wenn pilot_erforderlich = true)"
+    referenz: "AP-01, Teil C"
+    
+    felder:
+      
+      - name: "status"
+        typ: "enum"
+        pflicht: true
+        beschreibung: "Status der Pilot-Phase"
+        werte:
+          - "nicht_erforderlich"
+          - "geplant"
+          - "aktiv"
+          - "erfolgreich_abgeschlossen"
+          - "mit_einschraenkungen_abgeschlossen"
+          - "abgebrochen"
+      
+      - name: "start_datum"
+        typ: "date"
+        pflicht: false
+        beschreibung: "Start der Pilot-Phase"
+      
+      - name: "ende_datum"
+        typ: "date"
+        pflicht: false
+        beschreibung: "Ende der Pilot-Phase"
+      
+      - name: "scope"
+        typ: "text"
+        pflicht: false
+        beschreibung: "Pilot-Scope (Nutzergruppe, Funktionsumfang)"
+        max_zeichen: 300
+        mvp_hinweis: "Freitext für MVP. Strukturierte Scope-Definition kann später ergänzt werden."
+      
+      - name: "ergebnis_zusammenfassung"
+        typ: "text"
+        pflicht: false
+        beschreibung: "Zusammenfassung der Pilot-Ergebnisse"
+        max_zeichen: 500
+
+  # ---------------------------------------------------------------------------
+  # GATE 3: GO-LIVE-FREIGABE
+  # ---------------------------------------------------------------------------
+  gate_3:
+    beschreibung: "Dokumentation der Go-Live-Freigabe (Gate-Keeper: SOR)"
+    lifecycle_aktivitaet: "tr_12"
+    referenz: "AP-01, AP-02, AP-03"
+    
+    felder:
+      
+      - name: "datum"
+        typ: "date"
+        pflicht: true
+        beschreibung: "Datum der SOR-Sitzung mit Gate-2-Entscheidung"
+      
+      - name: "sor_protokoll_referenz"
+        typ: "string"
+        pflicht: true
+        beschreibung: "Referenz auf das SOR-Protokoll"
+        beispiel: "SOR-2025-03-15"
+      
+      - name: "entscheidung"
+        typ: "enum"
+        pflicht: true
+        beschreibung: "Ergebnis der Gate-3-Prüfung"
+        werte:
+          - "go_live"
+          - "go_live_mit_auflagen"
+          - "zurueck_an_transition"
+          - "ablehnung"
+      
+      # --- Prüfdimensionen ---
+      - name: "pruefung_so_readiness"
+        typ: "boolean"
+        pflicht: true
+        beschreibung: "Hat SO die Betriebsreife bestätigt? (Showstopper)"
+        referenz: "AP-02, G3-DIM-01"
+      
+      - name: "pruefung_dokumentation"
+        typ: "boolean"
+        pflicht: true
+        beschreibung: "Ist Dokumentation vorhanden UND implementiert? (Showstopper)"
+        referenz: "AP-02, G3-DIM-02"
+      
+      - name: "pruefung_portfolio_passung"
+        typ: "boolean"
+        pflicht: true
+        beschreibung: "Kein Widerspruch zu bestehenden Services? (Showstopper)"
+        referenz: "AP-02, G3-DIM-03"
+      
+      - name: "pruefung_ressourcen_commitment"
+        typ: "enum"
+        pflicht: true
+        beschreibung: |
+          Haben Betrieb und Support die OPERATIVE Übernahme für den 
+          Go-Live-Termin bestätigt?
+          
+          WICHTIG: Dies ist die operative Bestätigung (konkreter Termin, 
+          Personal eingeplant, Übergabe erfolgt). Die grundsätzliche 
+          Bereitschaft wurde bereits an Gate 1 geprüft.
+          
+          Falls hier "nicht_bestaetigt" ausgewählt wird, ist zu prüfen,
+          ob sich die Situation gegenüber Gate 1 verändert hat (z.B.
+          unerwarteter Personalabgang, Priorisierungsänderungen).
+        werte:
+          - "bestaetigt"
+          - "mit_auflagen"
+          - "nicht_bestaetigt"
+        referenz: "AP-02, G3-DIM-04"
+        abgrenzung_gate_1: |
+          Gate 1: Grundsätzliches Commitment ("Wir können/wollen diesen Service übernehmen")
+          Gate 3: Operatives Commitment ("Wir sind JETZT bereit für die Übernahme")
+      
+      - name: "pruefung_auflagen_gate_2"
+        typ: "enum"
+        pflicht: true
+        beschreibung: "Auflagen aus Gate 2 erfüllt? (Showstopper wenn vorhanden)"
+        werte:
+          - "erfuellt"
+          - "nicht_erfuellt"
+          - "keine_auflagen"
+        referenz: "AP-02, G3-DIM-05"
+      
+      # --- Formalia ---
+      - name: "so_bestaetigung_durch_sor"
+        typ: "boolean"
+        pflicht: true
+        beschreibung: "SO wurde durch SOR formal bestätigt"
+        referenz: "GOV-TR-004"
+      
+      # --- Auflagen ---
+      - name: "auflagen"
+        typ: "text"
+        pflicht: false
+        beschreibung: "Auflagen bei 'go_live_mit_auflagen' (Gate 3)"
+        max_zeichen: 500
+
+  # ---------------------------------------------------------------------------
+  # ELS: EARLY LIFE SUPPORT
+  # ---------------------------------------------------------------------------
+  els:
+    beschreibung: "Dokumentation der ELS-Phase"
+    referenz: "AP-04"
+    
+    felder:
+      
+      - name: "start"
+        typ: "date"
+        pflicht: true
+        beschreibung: "ELS-Start (= Go-Live-Datum)"
+      
+      - name: "ende"
+        typ: "date"
+        pflicht: false
+        beschreibung: "ELS-Ende (Datum der SO-Entscheidung)"
+      
+      - name: "dauer_wochen"
+        typ: "integer"
+        pflicht: false
+        beschreibung: "Tatsächliche ELS-Dauer in Wochen (gerundet)"
+        hinweis: "Wird bei Abschluss berechnet"
+      
+      - name: "kritische_stoerungen_anzahl"
+        typ: "integer"
+        pflicht: true
+        beschreibung: "Anzahl kritischer Störungen während ELS"
+        default: 0
+        referenz: "AP-04, Definition 'kritische Störung'"
+      
+      - name: "exit_begruendung"
+        typ: "text"
+        pflicht: true
+        beschreibung: "Begründung, warum Exit-Kriterien als erfüllt gelten"
+        max_zeichen: 500
+        beispiel: "Keine kritischen Störungen seit 3 Wochen, Support-Aufkommen normalisiert."
+      
+      - name: "lessons_learned"
+        typ: "text"
+        pflicht: false
+        beschreibung: "Wesentliche Erkenntnisse für Service Review"
+        max_zeichen: 500
+        mvp_hinweis: "Optional für MVP. Kann bei Bedarf verpflichtend werden."
+      
+      - name: "eskalation_erfolgt"
+        typ: "boolean"
+        pflicht: true
+        beschreibung: "Wurde an SOR eskaliert (bei Überschreitung Maximaldauer)?"
+        default: false
+      
+      - name: "eskalation_ergebnis"
+        typ: "text"
+        pflicht: false
+        beschreibung: "SOR-Entscheidung bei Eskalation"
+        max_zeichen: 300
+        hinweis: "Nur ausfüllen wenn eskalation_erfolgt = true"
+
+  # ---------------------------------------------------------------------------
+  # ABSCHLUSS-CHECKLISTE
+  # ---------------------------------------------------------------------------
+  abschluss_checkliste:
+    beschreibung: "Checkliste zur Sicherstellung der Vollständigkeit bei Abschluss"
+    referenz: "AP-07"
+    
+    mvp_hinweis: |
+      Für MVP als einfache Boolean-Checkliste. Kann später um 
+      Nachweise/Referenzen pro Punkt erweitert werden.
+    
+    felder:
+      
+      - name: "gate_2_passiert"
+        typ: "boolean"
+        pflicht: true
+        beschreibung: "Gate 2 (Entry-Prüfung nach Build) wurde erfolgreich passiert"
+      
+      - name: "pilot_abgeschlossen"
+        typ: "boolean"
+        pflicht: true
+        beschreibung: "Pilot abgeschlossen (oder nicht erforderlich)"
+      
+      - name: "gate_3_passiert"
+        typ: "boolean"
+        pflicht: true
+        beschreibung: "Gate 3 (Go-Live-Freigabe) wurde erfolgreich passiert"
+      
+      - name: "els_abgeschlossen"
+        typ: "boolean"
+        pflicht: true
+        beschreibung: "ELS wurde abgeschlossen"
+      
+      - name: "service_im_katalog"
+        typ: "boolean"
+        pflicht: true
+        beschreibung: "Service ist im Katalog aktiviert"
+      
+      - name: "so_bestaetigt"
+        typ: "boolean"
+        pflicht: true
+        beschreibung: "SO wurde durch SOR bestätigt"
+      
+      - name: "dokumentation_vollstaendig"
+        typ: "boolean"
+        pflicht: true
+        beschreibung: "Betriebsdokumentation ist vollständig und implementiert"
+
+  # ---------------------------------------------------------------------------
+  # SONDERFÄLLE: ABBRUCH / ROLLBACK
+  # ---------------------------------------------------------------------------
+  abbruch:
+    beschreibung: "Dokumentation bei Abbruch oder Rollback (nur bei negativem Ausgang)"
+    referenz: "AP-05"
+    
+    mvp_hinweis: |
+      Minimale Dokumentation für MVP. Detaillierte Abbruch-Analyse 
+      kann bei Bedarf ergänzt werden.
+    
+    felder:
+      
+      - name: "abbruch_erfolgt"
+        typ: "boolean"
+        pflicht: true
+        beschreibung: "Wurde die Transition abgebrochen?"
+        default: false
+      
+      - name: "abbruch_zeitpunkt"
+        typ: "enum"
+        pflicht: false
+        beschreibung: "In welcher Phase erfolgte der Abbruch?"
+        werte:
+          - "vor_gate_2"
+          - "nach_gate_2"
+          - "waehrend_pilot"
+          - "vor_gate_3"
+          - "nach_gate_3"
+          - "waehrend_els"
+      
+      - name: "abbruch_typ"
+        typ: "enum"
+        pflicht: false
+        beschreibung: "Art des Abbruchs"
+        werte:
+          - "zurueckweisung"
+          - "rollback"
+          - "termination"
+        referenz: "AP-05"
+      
+      - name: "abbruch_begruendung"
+        typ: "text"
+        pflicht: false
+        beschreibung: "Begründung für den Abbruch"
+        max_zeichen: 500
+      
+      - name: "entscheider"
+        typ: "string"
+        pflicht: false
+        beschreibung: "Wer hat den Abbruch entschieden (SO/SOR)"
+
+  # ---------------------------------------------------------------------------
+  # META
+  # ---------------------------------------------------------------------------
+  meta:
+    beschreibung: "Metadaten zur Dokumentenverwaltung"
+    
+    felder:
+      
+      - name: "erstellt_von"
+        typ: "string"
+        pflicht: true
+        beschreibung: "Wer hat den Steckbrief angelegt"
+      
+      - name: "erstellt_am"
+        typ: "date"
+        pflicht: true
+        beschreibung: "Erstellungsdatum"
+      
+      - name: "letzte_aenderung_von"
+        typ: "string"
+        pflicht: false
+        beschreibung: "Wer hat zuletzt geändert"
+      
+      - name: "letzte_aenderung_am"
+        typ: "date"
+        pflicht: false
+        beschreibung: "Datum der letzten Änderung"
+      
+      - name: "ueberfuehrt_am"
+        typ: "date"
+        pflicht: false
+        beschreibung: "Datum der Überführung in Service-Steckbrief"
+        hinweis: "Wird bei Status 'abgeschlossen' gesetzt"
+
+# =============================================================================
+# MVP-ENTSCHEIDUNGEN UND ERWEITERUNGSPOTENTIAL
+# =============================================================================
+
+mvp_entscheidungen:
+  
+  beschreibung: |
+    Folgende Vereinfachungen wurden für den MVP getroffen. Sie können 
+    basierend auf operativer Erfahrung angepasst werden.
+  
+  entscheidungen:
+    
+    - bereich: "Auflagen-Dokumentation"
+      mvp: "Freitext-Feld"
+      erweiterung: "Strukturierte Liste mit Auflagen-ID, Frist, Status, Verantwortlicher"
+      trigger: "Wenn Auflagen-Tracking systematisch nötig wird"
+    
+    - bereich: "Pilot-Scope"
+      mvp: "Freitext-Feld"
+      erweiterung: "Strukturiert: Nutzergruppe, Funktionsumfang, Erfolgskriterien, Exit-Kriterien"
+      trigger: "Wenn Pilots häufiger und komplexer werden"
+    
+    - bereich: "Abschluss-Checkliste"
+      mvp: "Boolean-Felder"
+      erweiterung: "Pro Punkt: Nachweis-Referenz, Datum, Prüfer"
+      trigger: "Wenn Audit-Anforderungen steigen"
+    
+    - bereich: "Kritische Störungen"
+      mvp: "Nur Anzahl"
+      erweiterung: "Liste mit Incident-IDs, Datum, Kurzbeschreibung"
+      trigger: "Wenn Detailanalyse für Service Review nötig wird"
+    
+    - bereich: "Transition-Typ"
+      mvp: "neuer_service | wesentliche_aenderung"
+      erweiterung: "Differenzierung nach Service-Kategorie (Basis, Standard, Premium)"
+      trigger: "Wenn Portfolio-Vielfalt zunimmt"
+    
+    - bereich: "Versionierung"
+      mvp: "Keine explizite Versionierung des Steckbriefs"
+      erweiterung: "Änderungshistorie mit Version, Datum, Autor, Änderung"
+      trigger: "Wenn Nachvollziehbarkeit von Änderungen relevant wird"
+
+# =============================================================================
+# VALIDIERUNGSREGELN
+# =============================================================================
+
+validierung:
+  
+  beschreibung: |
+    Regeln zur Konsistenzprüfung. Können bei Tool-Implementierung 
+    genutzt werden.
+  
+  regeln:
+    
+    - regel: "Gate-2-Vollständigkeit"
+      bedingung: "status != 'angelegt'"
+      pruefung: "gate_2.datum UND gate_2.entscheidung müssen gesetzt sein"
+    
+    - regel: "Pilot-Konsistenz"
+      bedingung: "gate_2.pilot_erforderlich = true"
+      pruefung: "pilot.status muss != 'nicht_erforderlich' sein"
+    
+    - regel: "Gate-3-nach-Gate-2"
+      bedingung: "gate_3.datum ist gesetzt"
+      pruefung: "gate_2.entscheidung muss 'freigabe' oder 'freigabe_mit_auflagen' sein"
+    
+    - regel: "ELS-nach-Gate-3"
+      bedingung: "els.start ist gesetzt"
+      pruefung: "gate_3.entscheidung muss 'go_live' oder 'go_live_mit_auflagen' sein"
+    
+    - regel: "Abschluss-Vollständigkeit"
+      bedingung: "status = 'abgeschlossen'"
+      pruefung: "Alle Felder in abschluss_checkliste müssen true sein"
+    
+    - regel: "Abbruch-Dokumentation"
+      bedingung: "abbruch.abbruch_erfolgt = true"
+      pruefung: "abbruch.abbruch_zeitpunkt UND abbruch.abbruch_begruendung müssen gesetzt sein"
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+  - version: "0.3"
+    datum: "2026-01-30"
+    aenderung: |
+      Präzisierung Ressourcen-Commitment: Klarstellung der Zwei-Stufen-Prüfung.
+      - Gate 1 (tr_01) prüft grundsätzliches Commitment (in service-lifecycle_transition.yaml)
+      - Gate 3 prüft operatives Commitment (Beschreibung präzisiert)
+      Hintergrund: Ressourcenfrage muss VOR Transition geklärt sein, um 
+      Ressourcenverschwendung zu vermeiden.
+    autor: "DIGITOM-Projekt"
+    referenz: "Konzeptionelle Überprüfung Ressourcenprüfung"
+
+  - version: "0.3"
+    datum: "2026-02-18"
+    aenderung: "Gate 1 in Transition verschoben (tr_01). Gate-IDs aktualisiert: Gate 2 = tr_09, Gate 3 = tr_12. Transition-Steckbrief dokumentiert nun alle 3 Gates."
+    autor: "DIGITOM-Projekt"
+    referenz: "service-lifecycle_transition.yaml v2.0"
+
+  - version: "0.2"
+    datum: "2026-01-30"
+    aenderung: "Anpassung an Service-Lifecycle 3.0 (5-Phasen-Konsolidierung): Gate-Nummerierung auf globale Nummerierung umgestellt (Gate 2 = tr_08, Gate 3 = tr_11). Terminologie aktualisiert (Design-Phase statt Service-Entwicklung)."
+    autor: "DIGITOM-Projekt"
+    referenz: "CHANGELOG_service-lifecycle-blueprint.md v3.0"
+
+  - version: "0.1"
+    datum: "2025-12-17"
+    aenderung: "Initiale Schema-Definition (MVP)"
+    autor: "DIGITOM-Projekt"
+    referenz: "AP-07, GOV-TR-018"

#02_service-portfolio-management/02.1_spm_konzepte/07_spm_arbeitsmaterialien/06_template_ola-kategorie-i.yaml

@@ -0,0 +1,165 @@
+# =============================================================================
+# OLA-TEMPLATE FÜR INTERNE SERVICES (KATEGORIE I)
+# =============================================================================
+#
+# Version:     1.0
+# Datum:       2026-03-09
+# Status:      Entwurf (Pilotphase)
+# Autor:       DIGITOM-Projekt
+# Governance:  GOV-SPM-I-002
+#
+# Zweck:
+#   Vorlage zur Erstellung eines Operational Level Agreements (OLA) für
+#   Interne Services der Kategorie I. Wird nach Abschluss der Pilotphase
+#   befüllt, wenn operative Erfahrungswerte vorliegen.
+#
+# Abgrenzung:
+#   - SLA: Vereinbarung zwischen DIGIT und externem Kunden (Kategorie A/B/C)
+#   - OLA: Vereinbarung zwischen DIGIT-internen Einheiten (Kategorie I)
+#
+# =============================================================================
+
+# -----------------------------------------------------------------------------
+# 1. IDENTIFIKATION
+# -----------------------------------------------------------------------------
+
+identifikation:
+  ola_id: ""                          # z.B. "OLA-INT-001"
+  ola_titel: ""                       # z.B. "OLA Active Directory Services"
+  version: ""                         # z.B. "1.0"
+  status: ""                          # Entwurf | Aktiv | In Review | Außer Kraft
+  erstellungsdatum: ""                # YYYY-MM-DD
+  letzte_aktualisierung: ""           # YYYY-MM-DD
+  naechster_review: ""                # YYYY-MM-DD
+
+  service_referenz:
+    service_name: ""                  # Name des Internen Services
+    service_id: ""                    # ID gemäß Service-Definition
+    service_kategorie: "I"            # Immer "I" für Interne Services
+    service_owner: ""                 # Name / Rolle
+
+# -----------------------------------------------------------------------------
+# 2. VERTRAGSPARTEIEN (INTERN)
+# -----------------------------------------------------------------------------
+
+vertragsparteien:
+
+  liefernde_einheit:
+    name: ""                          # z.B. "Team Infrastruktur"
+    verantwortlich: ""                # Name / Rolle des Ansprechpartners
+    kontakt: ""                       # E-Mail / Telefon
+
+  nutzende_einheiten:
+    - name: ""                        # z.B. "Team Applikationsbetrieb"
+      verantwortlich: ""
+      kontakt: ""
+      abhängige_kundenservices:       # Welche Kategorie A/B/C-Services hängen davon ab?
+        - ""
+
+  hinweis: |
+    Im Gegensatz zu einem SLA gibt es bei einem OLA keinen externen Kunden.
+    Die nutzenden Einheiten sind DIGIT-interne Teams, deren Kundenservices
+    (Kategorie A/B/C) vom Internen Service abhängen.
+
+# -----------------------------------------------------------------------------
+# 3. LEISTUNGSBESCHREIBUNG
+# -----------------------------------------------------------------------------
+
+leistungsbeschreibung:
+
+  kurzbeschreibung: ""                # 2-3 Sätze: Was leistet der Service?
+
+  leistungsumfang:
+    enthalten:
+      - ""                            # Auflistung der enthaltenen Leistungen
+    nicht_enthalten:
+      - ""                            # Explizite Ausschlüsse
+
+  betriebszeiten:
+    regulaer: ""                      # z.B. "Mo-Fr 07:00-18:00"
+    erweitert: ""                     # z.B. "24/7 für kritische Systeme"
+    wartungsfenster: ""               # z.B. "Sonntag 02:00-06:00"
+
+# -----------------------------------------------------------------------------
+# 4. QUALITÄTSZIELE
+# -----------------------------------------------------------------------------
+
+qualitaetsziele:
+
+  verfuegbarkeit:
+    zielwert: ""                      # z.B. "99,5 %"
+    messperiode: ""                   # z.B. "Kalendermonat"
+    messmethode: ""                   # z.B. "Monitoring-Tool X, Uptime-Berechnung"
+    ausnahmen: ""                     # z.B. "Geplante Wartung ausgenommen"
+
+  performance:
+    - metrik: ""                      # z.B. "Antwortzeit Authentifizierung"
+      zielwert: ""                    # z.B. "< 200 ms (95. Perzentil)"
+      messmethode: ""
+
+  kapazitaet:
+    aktuell: ""                       # z.B. "500 gleichzeitige Nutzer"
+    geplant: ""                       # z.B. "800 gleichzeitige Nutzer bis Q4/2026"
+
+# -----------------------------------------------------------------------------
+# 5. ESKALATIONSWEGE
+# -----------------------------------------------------------------------------
+
+eskalationswege:
+
+  stufe_1:
+    beschreibung: "Operativer Kontakt"
+    verantwortlich: ""
+    reaktionszeit: ""                 # z.B. "30 Minuten während Betriebszeiten"
+
+  stufe_2:
+    beschreibung: "Teamleitung / Service Owner"
+    verantwortlich: ""
+    reaktionszeit: ""
+
+  stufe_3:
+    beschreibung: "Eskalation an SOR / Mission Board"
+    ausloeser: |
+      - Wiederholte Verfehlung der Qualitätsziele
+      - Cross-Service-Impact auf Kundenservices
+    referenz: "GOV-SOR-006 (Abstimmungsrecht Interne Services im SOR)"
+
+# -----------------------------------------------------------------------------
+# 6. REVIEW-MECHANISMUS
+# -----------------------------------------------------------------------------
+
+review:
+
+  review_zyklus: ""                   # z.B. "Halbjährlich"
+  naechster_review: ""                # YYYY-MM-DD
+  review_teilnehmer:
+    - ""                              # Rollen / Namen
+
+  aenderungsverfahren: |
+    Änderungen am OLA werden vom Service Owner des Internen Services
+    initiiert und mit den nutzenden Einheiten abgestimmt. Bei Änderungen
+    mit Cross-Service-Impact ist eine SOR-Abstimmung erforderlich
+    (vgl. GOV-SOR-006).
+
+# -----------------------------------------------------------------------------
+# 7. LAUFZEIT UND KÜNDIGUNG
+# -----------------------------------------------------------------------------
+
+laufzeit:
+  beginn: ""                          # YYYY-MM-DD
+  laufzeit: ""                        # z.B. "Unbefristet, jährlicher Review"
+  kuendigungsfrist: ""                # z.B. "3 Monate zum Quartalsende"
+  kuendigungsbedingungen: |
+    Eine Kündigung des OLA setzt eine Stilllegungsentscheidung für den
+    Internen Service durch den SOR voraus (vgl. GOV-SOR-006).
+
+# -----------------------------------------------------------------------------
+# CHANGELOG
+# -----------------------------------------------------------------------------
+
+changelog:
+  - version: "1.0"
+    datum: "2026-03-09"
+    aenderung: "Erstfassung des OLA-Templates"
+    autor: "DIGITOM-Projekt"
+    referenz: "GOV-SPM-I-002, OQ-001"

#02_service-portfolio-management/02.1_spm_konzepte/07_spm_arbeitsmaterialien/07_leitfaden_sieben-fragen-orientierung.yaml

@@ -0,0 +1,186 @@
+# =============================================================================
+# SIEBEN-FRAGEN-ORIENTIERUNGSLEITFADEN
+# Abgrenzung: Interner Service (Kategorie I) vs. passive Service-Komponente
+# =============================================================================
+#
+# Version:     1.0
+# Datum:       2026-03-09
+# Status:      Final
+# Autor:       DIGITOM-Projekt
+# Governance:  GOV-SPM-I-005
+#
+# Zweck:
+#   Dieser Leitfaden unterstützt die systematische Einordnung von
+#   Infrastruktur-Komponenten als Interne Services (Kategorie I) oder
+#   als passive Service-Komponenten. Er ist eine Orientierungshilfe,
+#   kein Automatismus – die finale Entscheidung trifft das SPM/SOR.
+#
+# Kontext:
+#   Mit der Einführung der Kategorie I (Interne Services) entsteht die
+#   Frage, welche Infrastruktur-Komponenten als eigenständige Governance-
+#   Objekte geführt werden sollen. Der Leitfaden liefert reproduzierbare
+#   Kriterien für diese Abgrenzung.
+#
+# =============================================================================
+
+# -----------------------------------------------------------------------------
+# DIE SIEBEN FRAGEN
+# -----------------------------------------------------------------------------
+
+fragen:
+
+  - nr: 1
+    frage: "Gibt es einen identifizierbaren internen 'Kunden'?"
+    erlaeuterung: |
+      Nutzt eine andere DIGIT-Einheit oder ein anderes Team diese Komponente
+      als eigenständigen Dienst? Gibt es eine klar erkennbare Leistungs-
+      beziehung (Lieferant → Nutzer)?
+    beispiel_ja: "Active Directory wird von allen Applikationsteams genutzt"
+    beispiel_nein: "Ein Switch im Serverraum hat keine identifizierbare Nutzer-Einheit"
+
+  - nr: 2
+    frage: "Gibt es eine verantwortliche Rolle für die Service-Owner-Funktion?"
+    erlaeuterung: |
+      Kann eine Person oder Rolle die Gesamtverantwortung für Qualität,
+      Weiterentwicklung und Lifecycle dieser Komponente übernehmen? Ist
+      diese Verantwortung sinnvoll von der Infrastruktur-Betriebsrolle
+      abgrenzbar?
+    beispiel_ja: "Ein Teamleiter Netzwerk kann die Owner-Rolle für den Netzwerk-Backbone übernehmen"
+    beispiel_nein: "Für einzelne VLANs gibt es keine sinnvolle Owner-Abgrenzung"
+
+  - nr: 3
+    frage: "Hat die Komponente eigene, unabhängig definierbare Qualitätsziele?"
+    erlaeuterung: |
+      Können Verfügbarkeit, Performance oder andere Qualitätsmetriken
+      für diese Komponente eigenständig definiert und gemessen werden –
+      unabhängig von den darüberliegenden Kundenservices?
+    beispiel_ja: "Datenbank-Cluster: Verfügbarkeit 99,9 %, Antwortzeit < 50 ms"
+    beispiel_nein: "Ein Speicher-Volume hat keine eigenständigen Qualitätsziele"
+
+  - nr: 4
+    frage: "Kann die Komponente von mehreren Kundenservices genutzt werden?"
+    erlaeuterung: |
+      Wird die Komponente als Shared Service von mehr als einem
+      Kategorie-A/B/C-Service in Anspruch genommen? Gibt es einen
+      Mehrfachnutzungs-Charakter?
+    beispiel_ja: "Zentrales Monitoring-System wird von allen Services genutzt"
+    beispiel_nein: "Ein dedizierter Applikationsserver dient nur einem einzigen Service"
+
+  - nr: 5
+    frage: "Gibt es operative Steuerungsnotwendigkeit?"
+    erlaeuterung: |
+      Erfordert die Komponente regelmäßige operative Entscheidungen
+      (Kapazitätsplanung, Patch-Zyklen, Technologie-Roadmap), die über
+      den normalen Betrieb hinausgehen?
+    beispiel_ja: "E-Mail-Infrastruktur erfordert Migration zu neuer Plattform"
+    beispiel_nein: "Ein DNS-Eintrag erfordert keine eigenständige Steuerung"
+
+  - nr: 6
+    frage: "Ist die Komponente für Incident Management eigenständig relevant?"
+    erlaeuterung: |
+      Kann es Incidents geben, die primär dieser Komponente zugeordnet
+      werden und nicht sofort einem darüberliegenden Kundenservice?
+      Gibt es einen eigenen Incident-Kontext?
+    beispiel_ja: "Active-Directory-Ausfall ist ein eigenständiger Incident"
+    beispiel_nein: "Der Ausfall einer einzelnen Festplatte wird dem Storage-Service zugeordnet"
+
+  - nr: 7
+    frage: "Würde eine Stilllegung eine eigene SOR-Entscheidung rechtfertigen?"
+    erlaeuterung: |
+      Wäre die Außerbetriebnahme dieser Komponente eine Entscheidung mit
+      ausreichender Tragweite, um sie dem Service-Owner-Roundtable (SOR)
+      vorzulegen – analog zur Stilllegung eines Kundenservices?
+    beispiel_ja: "Ablösung des zentralen Virtualisierungs-Clusters ist SOR-relevant"
+    beispiel_nein: "Abschaltung eines Testservers erfordert keine SOR-Entscheidung"
+
+# -----------------------------------------------------------------------------
+# AUSWERTUNGSSCHEMA
+# -----------------------------------------------------------------------------
+
+auswertung:
+
+  schema:
+    - bereich: "5–7 × Ja"
+      ergebnis: "Interner Service (Kategorie I)"
+      beschreibung: |
+        Klare Empfehlung: Die Komponente erfüllt die wesentlichen Merkmale
+        eines eigenständigen Governance-Objekts und sollte als Interner
+        Service mit eigener Service-Definition geführt werden.
+
+    - bereich: "3–4 × Ja"
+      ergebnis: "Grenzfall – Entscheidung durch SPM/SOR"
+      beschreibung: |
+        Die Komponente zeigt einige Service-Merkmale, aber nicht alle.
+        Die Einordnung sollte im SPM-Team diskutiert und ggf. dem SOR
+        zur Entscheidung vorgelegt werden. Kriterien 1 (interner Kunde)
+        und 2 (Owner-Rolle) haben dabei besonderes Gewicht.
+
+    - bereich: "0–2 × Ja"
+      ergebnis: "Passive Service-Komponente"
+      beschreibung: |
+        Die Komponente ist ein Bestandteil eines übergeordneten Services
+        und wird nicht als eigenständiges Governance-Objekt geführt.
+        Sie erscheint ggf. als Abhängigkeit in der Service-Definition
+        des nutzenden Services.
+
+  hinweis_grenzfaelle: |
+    Der Leitfaden ist eine Orientierungshilfe, kein Automatismus.
+    Insbesondere bei Grenzfällen (3-4 × Ja) sollten folgende Aspekte
+    zusätzlich berücksichtigt werden:
+    - Strategische Bedeutung der Komponente für DIGIT
+    - Erwartete Entwicklung (wächst die Steuerungsnotwendigkeit?)
+    - Aufwand der Governance (steht der Verwaltungsaufwand im Verhältnis?)
+
+# -----------------------------------------------------------------------------
+# ANWENDUNGSBEISPIEL
+# -----------------------------------------------------------------------------
+
+anwendungsbeispiel:
+
+  komponente: "Active Directory Services"
+
+  bewertung:
+    - frage_nr: 1
+      antwort: "Ja"
+      begruendung: "Alle Applikationsteams nutzen AD als Authentifizierungsdienst"
+    - frage_nr: 2
+      antwort: "Ja"
+      begruendung: "Teamleiter Identity & Access kann Owner-Rolle übernehmen"
+    - frage_nr: 3
+      antwort: "Ja"
+      begruendung: "Verfügbarkeit 99,9 %, Antwortzeit < 200 ms eigenständig messbar"
+    - frage_nr: 4
+      antwort: "Ja"
+      begruendung: "Wird von >10 Kundenservices genutzt"
+    - frage_nr: 5
+      antwort: "Ja"
+      begruendung: "Migration zu Entra ID erfordert strategische Steuerung"
+    - frage_nr: 6
+      antwort: "Ja"
+      begruendung: "AD-Ausfall ist eigenständiger, kritischer Incident"
+    - frage_nr: 7
+      antwort: "Ja"
+      begruendung: "Ablösung durch Entra ID ist SOR-Entscheidung"
+
+  ergebnis: "7 × Ja → Klarer Interner Service (Kategorie I)"
+
+# -----------------------------------------------------------------------------
+# REFERENZEN
+# -----------------------------------------------------------------------------
+
+referenzen:
+  - "GOV-SPM-I-001: Einführung Kategorie I"
+  - "GOV-SPM-I-004: Kein eigenständiges Produkt-Konzept"
+  - "GOV-SPM-I-005: Sieben-Fragen-Leitfaden (Governance-Entscheidung)"
+  - "GOV-SOR-006: Abstimmungsrecht für Interne Services im SOR"
+
+# -----------------------------------------------------------------------------
+# CHANGELOG
+# -----------------------------------------------------------------------------
+
+changelog:
+  - version: "1.0"
+    datum: "2026-03-09"
+    aenderung: "Erstfassung als eigenständiges Arbeitsdokument"
+    autor: "DIGITOM-Projekt"
+    referenz: "GOV-SPM-I-005, OQ-003"