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"

#02_service-portfolio-management/service-portfolio-management_glossar.yaml

@@ -0,0 +1,215 @@
+metadata:
+  version: "3.7"
+  datum: "2026-03-09"
+  quelle: "SPM_Glossar_v3_3.xlsx (Tab: Pilot-Glossar)"
+  basis: "ITIL4 / DIGITOM Begriffsüberleitung"
+  hinweis: >
+    Die Überleitungsentscheidung für jeden ITIL-Begriff basiert darauf,
+    ob sein fachlicher Kern (Semantik) und seine Prozess-Relevanz eins zu
+    eins in das DIGIT Service-Management Framework passen (Übernehmen),
+    ob sie nur teilweise passen und deshalb inhaltlich ergänzt oder
+    modifiziert werden müssen (Anpassen) oder ob sie im DIGIT-Kontext
+    keinen erkennbaren Mehrwert bieten (Weglassen).
+
+glossar:
+  - begriff: "Anforderung"
+    definition: "Spezifische, testbare Kriterien oder Bedingungen, die ein neues oder geändertes Produkt oder ein Service erfüllen muss. Sie umfassen Nutzungs- und Gewährleistungsanforderungen."
+    synonyme: ["Requirement", "Vorgabe"]
+
+  - begriff: "Anwender*in"
+    definition: "Die Person, die Services direkt nutzt, um ihre Aufgaben zu erfüllen. Die Perspektive des Anwenders auf den Wert konzentriert sich auf die Gebrauchstauglichkeit (Nutzen) und Zuverlässigkeit (Gewährleistung)."
+    synonyme: ["Nutzer*in", "User"]
+
+  - begriff: "Auftraggeber*in"
+    definition: "Die Person oder Gruppe, die die Anforderungen an einen Service definiert und die Verantwortung für die Ergebnisse des Serviceverbrauchs übernimmt. Der Auftraggeber ist primär an den Geschäftsergebnissen interessiert."
+
+  - begriff: "Bedarf"
+    definition: "Bedarf ist der unspezifischer Ausgangspunkt (Wunsch/Problem/Beobachtung) der Kund*innen. Daraus werden im Stakeholder-Mgmt die Ziele/Ergebnisse der Kund*innen herausgearbeitet und später zu einem Demand qualifiziert oder über die bestehenden Services bedient."
+
+  - begriff: "Change"
+    definition: "Die Hinzufügung, Modifikation oder Entfernung von allem, was eine direkte oder indirekte Auswirkung auf Services haben könnte. Das Ziel ist die Maximierung erfolgreicher Änderungen bei gleichzeitiger Risikobewertung. Es gibt vier Typen von Changes: Standard-Change, Normal-Change, Major Change und Emergency-Change."
+    synonyme: ["Änderung"]
+
+  - begriff: "Configuration Item (CI)"
+    definition: "Ein Configuration Item (CI) ist jede Komponente, die verwaltet werden muss, um eine IT-Dienstleistung zu erbringen. Jedes CI und seine wichtigen Beziehungen zu anderen CIs (z.B. welche Anwendung auf welchem Server läuft) werden in einem zentralen Verzeichnis, der Configuration Management Database (CMDB), erfasst und gepflegt."
+
+  - begriff: "Demand"
+    definition: "Demand ist ein qualifizierter Bedarf, der nicht über das bestehende Service-Portfolio bedient werden kann."
+
+  - begriff: "Demand-Steckbrief"
+    definition: |
+      Das DPM-Artefakt, das aus dem Bedarfssteckbrief (SHM) hervorgeht. DPM reichert
+      den Bedarfssteckbrief mit Klassifizierung, Analyse und Bewertung an. Der
+      Demand-Steckbrief wird nach DSR/MB-Freigabe an den Service Owner bzw. PPM übergeben.
+    abgrenzung:
+      - "Bedarfssteckbrief: SHM-Artefakt – dokumentiert den qualifizierten Bedarf zum Zeitpunkt der Übergabe"
+      - "Demand-Entscheidungsvorlage: DPM-Dokument für DSR/MB-Entscheidungen"
+
+  - begriff: "Emergency-Change"
+    definition: "Beschreibt einen kritischen Change, der unter Zeitdruck umgesetzt werden muss, um einen akuten Schaden zu verhindern oder eine schwerwiegende Störung zu beheben."
+
+  - begriff: "Ergebnis"
+    definition: "Die durch einen Service ermöglichten Resultate für einen Kunden. Sie sind der tatsächliche Nutzen oder Effekt, der durch die Service-Erbringung erzielt wird."
+    synonyme: ["Outcome"]
+
+  - begriff: "Gewährleistung"
+    definition: "Die Zusicherung, dass ein Produkt oder Service die vereinbarten Anforderungen erfüllt. Beschreibt, in welchem Maße der Service verlässlich, verfügbar und nutzbar bereitgestellt wird (\"fit for use\")."
+    synonyme: ["Qualitätszusage", "Warranty"]
+
+  - begriff: "Geschäftskritikalität"
+    definition: "Bewertung der Bedeutung eines Services für den Geschäftsbetrieb, abgeleitet aus einer vereinfachten Business Impact Analysis (BIA). Berücksichtigt Faktoren wie Recovery Time Objective (RTO), betroffene Kernprozesse und Nutzerreichweite. Dient als Grundlage für die Impact-Bewertung im Incident Management und für Wartungsfenster-Restriktionen im Change Enablement."
+    synonyme: ["Business Criticality", "Service-Kritikalität"]
+
+  - begriff: "Governance"
+    definition: "Das Mittel, mit dem eine Organisation gesteuert und koordiniert wird. Es stellt sicher, dass alle Services und Projekte im Einklang mit den städtischen Zielen entwickelt, betrieben und überwacht werden."
+
+  - begriff: "Incident"
+    definition: "Eine ungeplante Unterbrechung oder eine Reduzierung der Qualität eines Services. Das Ziel ist die schnellstmögliche Wiederherstellung des normalen Betriebs."
+    synonyme: ["Vorfall", "Störung"]
+
+  - begriff: "Interner Service"
+    definition: |
+      Ein vollwertiges Governance-Objekt der Service-Kategorie I, das intern zwischen
+      DIGIT-Einheiten erbracht wird und keinen direkten Kundenbezug hat. Interne Services
+      sind NICHT im Service-Katalog sichtbar und unterliegen einem Operational Level
+      Agreement (OLA) anstelle eines SLA. Sie verfügen über einen eigenen Service Owner,
+      eine eigene Service-Definition und nehmen am Service-Lifecycle teil.
+      Die Abgrenzung zu passiven Service-Komponenten erfolgt über den
+      Sieben-Fragen-Orientierungsleitfaden (GOV-SPM-I-005).
+    abgrenzung:
+      - "Kundenservice (Kategorie A/B/C): Hat direkten Kundenbezug, ist im Katalog sichtbar, unterliegt einem SLA"
+      - "Passive Service-Komponente: Kein eigenständiges Governance-Objekt, wird innerhalb eines Services verwaltet"
+    kategorie: "I"
+    governance_referenz: "GOV-SPM-I-001, GOV-SPM-I-005"
+
+  - begriff: "Initiative"
+    definition: "Initiative bezeichnet eine strategisch erkannte Möglichkeit zur Innovation, die noch nicht als konkreter Demand geäußert wurde. Sie wird vom Demand-Portfolio-Management aufgenommen, bewertet und ins Mission Board eingebracht."
+    synonyme: ["Chance", "Möglichkeit", "Opportunity"]
+
+  - begriff: "Key Performance Indicator (KPI)"
+    definition: "Ein Key Performance Indicator (KPI) ist eine messbare Kennzahl, die verwendet wird, um den Erfolg bei der Erreichung eines Ziels objektiv zu bewerten."
+
+  - begriff: "Kontinuierliche Verbesserung"
+    definition: "Kontinuierliche Verbesserung ist ein regelmäßiger, systematischer Zyklus, in dem anhand definierter Kennzahlen und aktiv eingeholtem Feedback Verbesserungspotenziale identifiziert und priorisiert werden. Anschließend werden Maßnahmen verantwortet, umgesetzt und deren Wirkung erneut bewertet."
+
+  - begriff: "Kundenservice"
+    definition: "Services, die Mitarbeitende und Ämter der Stadtverwaltung direkt nutzen, beauftragen oder wahrnehmen können. Sie haben eine erkennbare Schnittstelle zum Anwender und einen direkten Einfluss auf dessen Arbeit."
+
+  - begriff: "Kund*in"
+    definition: "Eine generische Rolle, die eine Organisation oder Person einnimmt, wenn sie Services empfängt. Diese Rolle umfasst die spezifischeren Rollen Anwender, Auftraggeber und Sponsor."
+    synonyme: ["Service-Konsument"]
+
+  - begriff: "Major-Change"
+    definition: "Ein Major Change ist eine Änderung, die die Service-Identität tangiert oder erhebliche Risiken birgt. Er erfordert die Genehmigung durch die SOR und durchläuft den Transition-Prozess."
+    synonyme: ["Wesentliche Änderung"]
+
+  - begriff: "Normal-Change"
+    definition: "Umfasst jeden Change, der kein Standard-, Major- oder Emergency-Change ist. Er erfordert eine individuelle Risiko- und Impact-Bewertung und eine Einzelfallgenehmigung."
+
+  - begriff: "Nutzen"
+    definition: "Die Funktionalität, die ein Produkt oder Service bietet, um ein bestimmtes Bedürfnis zu erfüllen. Beschreibt, was der Service leistet (\"fit for purpose\")."
+    synonyme: ["Utility"]
+
+  - begriff: "Problem (engl.)"
+    definition: "Eine Ursache oder potenzielle Ursache eines oder mehrerer Vorfälle. Das Ziel ist die Identifikation von Ursachen und die Empfehlung von langfristigen Lösungen."
+    synonyme: ["Ursache"]
+
+  - begriff: "Produkt"
+    definition: "Eine Konfiguration der Ressourcen einer Organisation, die darauf ausgelegt ist, Wert für Kund*innen zu bieten. Es ist die DIGIT-seitige Bündelung von Ressourcen und stellt eine potenzielle Wertquelle dar."
+    synonyme: ["Leistungsbaustein"]
+
+  - begriff: "Recovery Time Objective (RTO)"
+    definition: "Die maximale akzeptable Zeitspanne nach einer Service-Unterbrechung, bevor der Geschäftsbetrieb schwerwiegend beeinträchtigt wird. Gibt den Zeitrahmen vor, innerhalb dessen ein Service wiederhergestellt werden muss. Dient als objektiver Indikator für die Geschäftskritikalität."
+    synonyme: ["Wiederherstellungsziel", "Wiederanlaufzeit"]
+
+  - begriff: "Request-Katalog"
+    definition: "Eine Sicht auf den Service-Katalog, die Details zu Service-Anfragen für bestehende Services bereitstellt und die dem Anwender zur Verfügung gestellt wird."
+
+  - begriff: "Request for Change (RFC)"
+    definition: "Ein Request for Change (RFC) ist eine formale Anforderung, einen Change vorzunehmen. Jeder RFC wird einem der vier Change-Typen (Standard/Normal/Major/Emergency) zugeordnet. Die Change-Typen bestimmen Bewertungsweg, Genehmigungen und Umsetzungsmethode eines RFC."
+    synonyme: ["Change Request"]
+
+  - begriff: "Ressource"
+    definition: "Eine Person oder eine andere Entität (bspw. Infrastruktur, Software, Hardware, oder finanzielle Mittel), die für die Entwicklung oder Erbringung eines Services benötigt wird. Sie stellt das unkonfigurierte, rohe Potenzial einer Organisation dar."
+
+  - begriff: "Service"
+    definition: "Ein Service ist die Anwendung eines oder mehrerer Produkte im Rahmen einer Service-Beziehung. Ein Service ermöglicht Kund*innen, ihre Ergebnisse zu erreichen – ohne spezifische Kosten und Risiken verwalten zu müssen."
+    synonyme: ["Dienstleistung"]
+
+  - begriff: "Service Level"
+    definition: "Eine oder mehrere im SLA vereinbarte Metriken zur Definition der Qualität, Verfügbarkeit und Leistung eines Services aus Sicht der Auftraggeber*innen. Die Einhaltung der Service Levels wird kontinuierlich überwacht, berichtet und dient als Grundlage für Service Reviews und kontinuierliche Verbesserung."
+    synonyme: ["Service-Qualitätsniveau"]
+
+  - begriff: "Operational Level Agreement (OLA)"
+    definition: |
+      Eine interne Leistungsvereinbarung zwischen DIGIT-Einheiten für Interne Services
+      (Kategorie I). Das OLA ist das funktionale Äquivalent eines SLA für interne
+      Service-Beziehungen ohne externen Kundenbezug. Es definiert Leistungsparameter,
+      Qualitätsziele und Verantwortlichkeiten zwischen internen Betriebseinheiten.
+    abgrenzung:
+      - "SLA: Vereinbarung mit externem Kundenbezug (Kategorie A/B/C)"
+      - "OLA: Vereinbarung ohne externen Kundenbezug (Kategorie I)"
+    governance_referenz: "GOV-SPM-I-002"
+
+  - begriff: "Service-Sichtbarkeit"
+    definition: |
+      Die Sichtbarkeit eines Services im Service-Katalog ist vollständig aus der
+      Service-Kategorie ableitbar und wird NICHT als eigenständiges Attribut geführt.
+      Kategorie A, B, C: im Katalog sichtbar. Kategorie I: NICHT im Katalog sichtbar.
+      Ein separates Attribut wurde bewusst abgeschafft, um Redundanz und
+      Inkonsistenz-Risiken zu vermeiden (Designprinzip: „Encode rationale once").
+    governance_referenz: "GOV-SPM-I-003"
+
+  - begriff: "Service Level Agreement (SLA)"
+    definition: "Eine dokumentierte Vereinbarung zwischen Service-Anbieter und Auftraggeber*in, die sowohl die erforderlichen Services als auch das erwartete Service Level festlegt."
+    synonyme: ["Servicevereinbarung"]
+
+  - begriff: "Service Request"
+    definition: "Eine Anforderung eines Nutzenden, die eine vordefinierte Service-Aktion initiiert, die als normaler Teil der Service-Bereitstellung gilt. Sie ist keine Störung."
+    synonyme: ["Serviceanfrage"]
+
+  - begriff: "Service-Anbieter"
+    definition: "Eine Organisation, die Services für Kund*innen bereitstellt. Der Anbieter kann intern oder extern zur Organisation des Kunden sein."
+    synonyme: ["Dienstleister", "Service Provider"]
+
+  - begriff: "Service-Angebot"
+    definition: "Eine formale Beschreibung eines Service, die darauf ausgelegt ist, die Bedürfnisse einer Zielgruppe von Kund*innen zu adressieren. Es ist die Schnittstelle, die den Kund*innen präsentiert wird."
+    synonyme: ["Leistungsangebot"]
+
+  - begriff: "Service-Bereitstellung"
+    definition: "Operative Aktivitäten, die zur Bereitstellung von Services durchgeführt werden. Sie werden in Standard Operating Procedures (SOPs) dokumentiert, eindeutig Verantwortlichen zugewiesen und regelmäßig hinsichtlich Qualität und Effizienz überprüft. Sie können (teil-)automatisiert beansprucht und umgesetzt werden."
+    synonyme: ["Operative Tätigkeit", "Service-Aktivität", "Service-Aktion"]
+
+  - begriff: "Service-Beziehung"
+    definition: "Die Zusammenarbeit zwischen einem Service-Anbieter und einem Kunden, um gemeinsam Mehrwert zu schaffen. Dies umfasst Servicebereitstellung, Servicekonsum und proaktives Stakeholder Management."
+
+  - begriff: "Service-Katalog"
+    definition: "Eine strukturierte, für eine Zielgruppe relevante Informationsquelle über alle aktuell verfügbaren Services und Service-Angebote. Er ist die operative, kundenorientierte Sicht auf die Services."
+
+  - begriff: "Service-Portfolio"
+    definition: "Eine vollständige Sammlung aller Produkte und Services, die von einer Organisation während ihres gesamten Lebenszyklus verwaltet werden. Es ist ein strategisches Managementinstrument zur Steuerung von Ressourcen. Es wird regelmäßig hinsichtlich strategischer Ausrichtung, Nutzenbeitrag, Wirtschaftlichkeit und Investitionsentscheidungen überprüft und aktualisiert."
+    synonyme: ["IT-Service-Portfolio"]
+
+  - begriff: "Sponsor*in"
+    definition: "Die Person oder Gruppe, die das Budget für den Serviceverbrauch autorisiert. Der Sponsor ermöglicht die Service-Beziehung aus finanzieller Sicht."
+
+  - begriff: "Stakeholder"
+    definition: "Eine Person oder Organisation, die ein Interesse oder eine Beteiligung an einer Organisation, einem Produkt, einem Service oder einer anderen Entität hat. Ihre Bedürfnisse und Erwartungen sind relevant für die Wertschöpfung."
+    synonyme: ["Anspruchsgruppen"]
+
+  - begriff: "Standard Operating Procedures (SOPs)"
+    definition: "Standard Operating Procedures (SOPs) sind standardisierte, schriftlich festgelegte Anweisungen, die Schritt für Schritt beschreiben, wie eine bestimmte Aktivität der Service-Bereitstellung im Betrieb und Support durchgeführt werden muss. SOPs stellen sicher, dass Tätigkeiten konsistent, reproduzierbar und in gleichbleibend hoher Qualität ausgeführt werden. Sie definieren klare Schrittfolgen, Zuständigkeiten, erforderliche Werkzeuge und Zeitvorgaben, um eine konsistente und effiziente Service-Erbringung sicherzustellen."
+    synonyme: ["Standardvorgehensweise"]
+
+  - begriff: "Standard-Change"
+    definition: "Bezieht sich auf einen vorab bewerteten, risikoarmen, wiederkehrenden Change, dessen Ablauf vollständig vordefiniert und vorautorisiert ist."
+
+  - begriff: "Vital Business Function (VBF)"
+    definition: "Geschäftsprozess, dessen Ausfall unmittelbar existenzielle oder schwerwiegende Auswirkungen auf die Organisation hat. Services, die VBFs unterstützen, sind per Definition geschäftskritisch. Im kommunalen Kontext: Kernprozesse der Verwaltung wie Bürgerservice, Zahlungsverkehr oder hoheitliche Aufgaben."
+    synonyme: ["Kritischer Geschäftsprozess", "Kernprozess"]
+
+  - begriff: "Wert"
+    definition: "Wert bezeichnet den wahrgenommenen Nutzen, den Kund*innen aus einem Service ziehen. Wert entsteht, indem die Ergebnisse eines Services die Ziele und Bedarfe der Kund*innen unterstützen. Er wird in einem kollaborativen Prozess zwischen Anbieter und Kund*innen gemeinsam geschaffen."
+
+  - begriff: "Wissensmanagement"
+    definition: "Wissensmanagement ist der systematische Prozess zum Erfassen, Teilen, Nutzen und Pflegen von Wissen und Informationen in einer Organisation. Ziel von Wissensmanagement im DIGIT ist es, wiederkehrende Anfragen und Störungen schneller und konsistenter zu lösen, die Qualität der Services zu verbessern und die Einarbeitung von Mitarbeitenden zu erleichtern."