init: DIGITOM Kernkonzept YAML-Dateien (initialer Import)

#03_stakeholder-management/#03.3_konzepte/shm_lifecycle-blueprint.yaml

@@ -0,0 +1,20 @@
+# ========================================
+# SHM Lifecycle Blueprint
+# ========================================
+# Version: 0.1 (Platzhalter)
+# Datum: 2024-12-03
+# Status: Ausstehend
+# Entwicklungsphase: 3
+# ========================================
+
+# ITIL4-Referenz (falls zutreffend):
+# itil4_referenz:
+#   practice: "Customer Journey (DSV)"
+#   relevante_elemente: []
+#   adaption_fuer_digitom: ""
+
+# ========================================
+# INHALT
+# ========================================
+
+# [Inhalt folgt in Phase 3]

#03_stakeholder-management/#03.3_konzepte/shm_sims-konzept.yaml

@@ -0,0 +1,700 @@
+# =============================================================================
+# STAKEHOLDER-INFORMATIONS-MANAGEMENT-SYSTEM (SIMS)
+# =============================================================================
+# Modul: Stakeholder-Management (SHM)
+# Typ: Konzept (Informationsmanagement)
+# Version: 1.0
+# Datum: 2025-12-11
+# Status: Entwurf
+# Entwicklungsphase: 10
+# =============================================================================
+
+meta:
+  modul_id: "SHM-K-05"
+  name: "Stakeholder-Informations-Management-System (SIMS)"
+  typ: "Konzept"
+  
+  zweck: |
+    Das SIMS ist das zentrale Informationssystem für die SHM-Funktion. 
+    Es dient der strukturierten Erfassung, Pflege und Auswertung aller 
+    stakeholderbezogenen Informationen, die für die Betreuung und 
+    Steuerung des Stakeholder-Portfolios erforderlich sind.
+  
+  abgrenzung:
+    was_sims_ist:
+      - "Zentraler Ablageort für Stakeholder-Stammdaten"
+      - "Dokumentationssystem für Interaktionen und Bedarfe"
+      - "Grundlage für operative Steuerung und Reporting"
+    
+    was_sims_nicht_ist:
+      - "Kein Ticket-System (bleibt beim Service Desk)"
+      - "Kein Demand-Management-Tool (bleibt bei DPM)"
+      - "Kein CRM im vertrieblichen Sinne"
+  
+  design_prinzipien:
+    
+    - id: "DP-01"
+      name: "Entscheidungsorientierung"
+      beschreibung: |
+        Jedes erfasste Attribut muss mindestens eine der SHM-Kernentscheidungen 
+        unterstützen (Betreuungsallokation, Bedarfsrouting, Governance-Zuordnung).
+        Daten ohne Entscheidungsbezug werden nicht erfasst.
+    
+    - id: "DP-02"
+      name: "Single Source of Truth"
+      beschreibung: |
+        SIMS ist die führende Quelle für Stakeholder-Stammdaten innerhalb 
+        der SHM-Funktion. Redundante Datenhaltung ist zu vermeiden.
+    
+    - id: "DP-03"
+      name: "Minimale Komplexität"
+      beschreibung: |
+        Die Struktur wird so einfach wie möglich gehalten. Komplexität 
+        wird nur dort zugelassen, wo sie nachweislich Mehrwert schafft.
+    
+    - id: "DP-04"
+      name: "Plattformunabhängigkeit"
+      beschreibung: |
+        Das Konzept beschreibt fachliche Anforderungen, nicht technische 
+        Umsetzung. Die Wahl des Werkzeugs erfolgt separat.
+  
+  konzept_referenzen:
+    - dokument: "shm_schema_amtssteckbrief.yaml"
+      beschreibung: "Attribut-Schema für Stakeholder-Stammdaten"
+    - dokument: "shm_schema_bedarfssteckbrief.yaml"
+      beschreibung: "Attribut-Schema für Bedarfsdokumentation"
+    - dokument: "shm_engagement-framework.yaml"
+      beschreibung: "Interaktionsformate und Dokumentationsanforderungen"
+    - dokument: "shm_voice-of-customer.yaml"
+      beschreibung: "Feedback-Dimensionen und Aggregationslogik"
+    - dokument: "shm_koordinations-und-steuerungsstruktur.yaml"
+      beschreibung: "Review-Artefakte und Reporting-Anforderungen"
+
+# =============================================================================
+# INFORMATIONSOBJEKTE
+# =============================================================================
+
+informationsobjekte:
+  
+  beschreibung: |
+    Die folgenden Informationsobjekte bilden den Kern des SIMS. 
+    Sie stehen in definierten Beziehungen zueinander.
+  
+  objekte:
+    
+    # -------------------------------------------------------------------------
+    # AMTS-STECKBRIEF (Kernobjekt)
+    # -------------------------------------------------------------------------
+    
+    - id: "IO-01"
+      name: "Amts-Steckbrief"
+      
+      beschreibung: |
+        Zentrales Datenobjekt pro Stakeholder (Amt/Organisationseinheit). 
+        Enthält Stammdaten, Segmentierung, Priorisierung und Betreuungsstatus.
+      
+      schema_referenz: "shm_schema_amtssteckbrief.yaml"
+      
+      charakter: "Persistentes Stammdatenobjekt"
+      
+      lebenszyklus:
+        anlage: "Bei Aufnahme ins Portfolio"
+        pflege: "Laufend durch zugeordneten Stakeholder-Manager"
+        abschluss: "Bei Herauslösung aus Portfolio (selten)"
+      
+      untergeordnete_elemente:
+        - "Gesprächsprotokolle (als Anhänge/Untereinträge)"
+        - "Interventionsdokumentation"
+        - "VoC-Feedback-Einträge"
+    
+    # -------------------------------------------------------------------------
+    # BEDARFSSTECKBRIEF
+    # -------------------------------------------------------------------------
+    
+    - id: "IO-02"
+      name: "Bedarfssteckbrief"
+      
+      beschreibung: |
+        Dokumentation eines konkreten Stakeholder-Bedarfs. Entsteht aus 
+        der Bedarfsbewertung und dient als Übergabedokument an nachgelagerte 
+        Funktionen (Service Desk, SPM, DPM).
+      
+      schema_referenz: "shm_schema_bedarfssteckbrief.yaml"
+      
+      charakter: "Transaktionsobjekt mit Lebenszyklus"
+      
+      lebenszyklus:
+        anlage: "Bei Bedarfserfassung durch SHM"
+        pflege: "Status-Updates bei Bearbeitung"
+        abschluss: "Bei Erledigung oder Ablehnung"
+      
+      beziehung_zu_amt: |
+        Jeder Bedarfssteckbrief ist genau einem Amt zugeordnet. 
+        Ein Amt kann mehrere Bedarfssteckbriefe haben.
+    
+    # -------------------------------------------------------------------------
+    # GESPRÄCHSPROTOKOLL
+    # -------------------------------------------------------------------------
+    
+    - id: "IO-03"
+      name: "Gesprächsprotokoll"
+      
+      beschreibung: |
+        Dokumentation von Turnus-Gesprächen, Workshops und anderen 
+        Interaktionsformaten. Wird dem jeweiligen Amt zugeordnet.
+      
+      charakter: "Anhang/Untereintrag zum Amts-Steckbrief"
+      
+      mindestattribute:
+        - attribut: "datum"
+          beschreibung: "Datum des Gesprächs"
+        - attribut: "format"
+          beschreibung: "Art des Formats (TF-01, TF-02, SF-01, etc.)"
+          referenz: "shm_engagement-framework.yaml"
+        - attribut: "teilnehmer"
+          beschreibung: "Teilnehmer (DIGIT-seitig und Kundenseite)"
+        - attribut: "themen"
+          beschreibung: "Besprochene Themen (Stichworte)"
+        - attribut: "vereinbarungen"
+          beschreibung: "Konkrete Vereinbarungen mit Verantwortung/Termin"
+        - attribut: "feedback_notizen"
+          beschreibung: "VoC-relevante Aussagen (für Aggregation)"
+          referenz: "shm_voice-of-customer.yaml"
+      
+      aufbewahrung: |
+        Protokolle bleiben dauerhaft dem Amt zugeordnet und ermöglichen 
+        die Nachvollziehbarkeit der Betreuungshistorie.
+    
+    # -------------------------------------------------------------------------
+    # INTERVENTIONSDOKUMENTATION
+    # -------------------------------------------------------------------------
+    
+    - id: "IO-04"
+      name: "Interventionsdokumentation"
+      
+      beschreibung: |
+        Dokumentation von Interventionen bei angespannter oder kritischer 
+        Beziehungsqualität. Enthält Ursachenanalyse, Maßnahmenplan und 
+        Verlauf.
+      
+      charakter: "Anhang/Untereintrag zum Amts-Steckbrief"
+      
+      mindestattribute:
+        - attribut: "anlass"
+          beschreibung: "Auslöser der Intervention"
+        - attribut: "beziehungsqualitaet_start"
+          beschreibung: "Bewertung bei Interventionsbeginn"
+        - attribut: "ursachenanalyse"
+          beschreibung: "Identifizierte Ursachen"
+        - attribut: "massnahmen"
+          beschreibung: "Vereinbarte Maßnahmen mit Verantwortung/Termin"
+        - attribut: "status"
+          beschreibung: "Aktiv / Abgeschlossen / Abgebrochen"
+        - attribut: "ergebnis"
+          beschreibung: "Bewertung bei Abschluss"
+      
+      referenz: "shm_engagement-framework.yaml → beziehungsqualitaet"
+    
+    # -------------------------------------------------------------------------
+    # VOC-FEEDBACK-EINTRAG
+    # -------------------------------------------------------------------------
+    
+    - id: "IO-05"
+      name: "VoC-Feedback-Eintrag"
+      
+      beschreibung: |
+        Einzelnes Feedback-Element aus Stakeholder-Interaktionen. 
+        Wird aggregiert für Cluster-Analyse und Reporting.
+      
+      charakter: "Anhang/Untereintrag zum Amts-Steckbrief oder eigenständig"
+      
+      mindestattribute:
+        - attribut: "quelle"
+          beschreibung: "Feedback-Quelle (Q-01 bis Q-06)"
+          referenz: "shm_voice-of-customer.yaml"
+        - attribut: "datum"
+          beschreibung: "Erfassungsdatum"
+        - attribut: "dimension"
+          beschreibung: "Zuordnung zu D1-D4"
+        - attribut: "subdimension"
+          beschreibung: "Konkrete Subdimension"
+        - attribut: "tendenz"
+          beschreibung: "Positiv / Neutral / Negativ"
+        - attribut: "kernaussage"
+          beschreibung: "Zusammenfassung in 1-2 Sätzen"
+      
+      aggregationslogik: |
+        Einzelne Einträge werden gemäß shm_voice-of-customer.yaml 
+        zu Clustern aggregiert und in die Review-Struktur eingespeist.
+
+# =============================================================================
+# STRUKTURKONZEPT
+# =============================================================================
+
+strukturkonzept:
+  
+  beschreibung: |
+    Das SIMS gliedert sich in logische Bereiche, die unterschiedliche 
+    Informationstypen und Nutzungskontexte adressieren.
+  
+  bereiche:
+    
+    - id: "B-01"
+      name: "Stakeholder-Portfolio"
+      beschreibung: |
+        Zentrale Ablage aller Amts-Steckbriefe mit zugeordneten 
+        Untereinträgen (Protokolle, Interventionen, Feedback).
+      inhalt:
+        - "Amts-Steckbriefe (IO-01)"
+        - "Gesprächsprotokolle (IO-03)"
+        - "Interventionsdokumentation (IO-04)"
+        - "VoC-Feedback-Einträge (IO-05)"
+      primaere_nutzer: "Stakeholder-Manager (operativ)"
+    
+    - id: "B-02"
+      name: "Bedarfsdokumentation"
+      beschreibung: |
+        Ablage aller Bedarfssteckbriefe mit Verlinkung zum 
+        zugehörigen Amt.
+      inhalt:
+        - "Bedarfssteckbriefe (IO-02)"
+      primaere_nutzer: "Stakeholder-Manager, DPM (bei Übergabe)"
+    
+    - id: "B-03"
+      name: "Auswertungen und Reports"
+      beschreibung: |
+        Bereich für aggregierte Sichten, Dashboards und 
+        vorbereitete Reports (E1, E2).
+      inhalt:
+        - "Views (siehe Abschnitt views)"
+        - "Report-Vorlagen"
+      primaere_nutzer: "SHM-Leitung, Stakeholder-Manager"
+    
+    - id: "B-04"
+      name: "Arbeitsmaterialien"
+      beschreibung: |
+        Ablage für Templates, Leitfäden und Checklisten, 
+        die im SHM-Alltag verwendet werden.
+      inhalt:
+        - "Gesprächsvorlagen"
+        - "Checklisten"
+        - "Leitfäden"
+      primaere_nutzer: "Stakeholder-Manager"
+      referenz: "#03.7_arbeitsmaterialien/"
+  
+  beziehungen:
+    
+    beschreibung: |
+      Die Informationsobjekte stehen in folgenden Beziehungen zueinander.
+    
+    beziehungsmodell: |
+      
+      ┌─────────────────────────────────────────────────────────────┐
+      │                     AMTS-STECKBRIEF                         │
+      │                        (IO-01)                              │
+      │                                                             │
+      │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │
+      │  │ Gesprächs-  │  │Interventions│  │  VoC-Feedback-      │  │
+      │  │ protokolle  │  │dokumentation│  │  Einträge           │  │
+      │  │  (IO-03)    │  │   (IO-04)   │  │    (IO-05)          │  │
+      │  │    [0..*]   │  │    [0..*]   │  │     [0..*]          │  │
+      │  └─────────────┘  └─────────────┘  └─────────────────────┘  │
+      └───────────────────────────┬─────────────────────────────────┘
+                                  │
+                                  │ 1:n
+                                  ▼
+                    ┌─────────────────────────────┐
+                    │     BEDARFSSTECKBRIEF       │
+                    │          (IO-02)            │
+                    │           [0..*]            │
+                    └─────────────────────────────┘
+    
+    kardinalitaeten:
+      - "Amt 1 : n Bedarfssteckbrief"
+      - "Amt 1 : n Gesprächsprotokoll"
+      - "Amt 1 : n Interventionsdokumentation"
+      - "Amt 1 : n VoC-Feedback-Eintrag"
+
+# =============================================================================
+# VIEWS (AUSWERTUNGSPERSPEKTIVEN)
+# =============================================================================
+
+views:
+  
+  beschreibung: |
+    Views sind vordefinierte Auswertungsperspektiven auf die SIMS-Daten. 
+    Sie unterstützen die operative Arbeit und das Management-Reporting.
+  
+  hinweis: |
+    Die folgenden Views sind ein initialer Vorschlag basierend auf den 
+    identifizierten Nutzungsszenarien. Sie sind im Rahmen der Einführung 
+    zu validieren und nach Praxiserprobung anzupassen.
+  
+  kategorien:
+    
+    # -------------------------------------------------------------------------
+    # PORTFOLIO-MANAGEMENT
+    # -------------------------------------------------------------------------
+    
+    - kategorie: "Portfolio-Management"
+      beschreibung: "Überblick und Steuerung des Stakeholder-Portfolios"
+      
+      views:
+        
+        - id: "V-PF-01"
+          name: "Stakeholder nach Prio-Stufe"
+          zweck: "Überblick Portfolioverteilung"
+          filterkriterien: "Gruppierung nach Prio-Stufe (Key/Aktiv/Standard/Basis)"
+          primaerer_nutzer: "SHM-Leitung"
+        
+        - id: "V-PF-02"
+          name: "Meine Stakeholder"
+          zweck: "Persönliche Arbeitsliste"
+          filterkriterien: "Filter: Betreuungszuordnung = aktueller Nutzer"
+          primaerer_nutzer: "Stakeholder-Manager"
+        
+        - id: "V-PF-03"
+          name: "Stakeholder nach Dezernat"
+          zweck: "Organisatorische Cluster-Sicht"
+          filterkriterien: "Gruppierung nach Dezernat"
+          primaerer_nutzer: "SHM-Leitung"
+        
+        - id: "V-PF-04"
+          name: "Neuzugänge"
+          zweck: "Onboarding-Pipeline"
+          filterkriterien: "Filter: Anlage < 90 Tage oder Status = Neu"
+          primaerer_nutzer: "Stakeholder-Manager"
+    
+    # -------------------------------------------------------------------------
+    # BEZIEHUNGSQUALITÄT
+    # -------------------------------------------------------------------------
+    
+    - kategorie: "Beziehungsqualität"
+      beschreibung: "Monitoring der Beziehungsqualität und Interventionen"
+      
+      views:
+        
+        - id: "V-BQ-01"
+          name: "Beziehungs-Ampel"
+          zweck: "Gesamtübersicht Beziehungsqualität"
+          filterkriterien: "Alle Stakeholder mit Spalte Beziehungsqualität"
+          primaerer_nutzer: "SHM-Leitung"
+        
+        - id: "V-BQ-02"
+          name: "Interventionsbedarf"
+          zweck: "Fokus auf Problemfälle"
+          filterkriterien: "Filter: Beziehungsqualität = Angespannt ODER Kritisch"
+          primaerer_nutzer: "SHM-Leitung, Stakeholder-Manager"
+        
+        - id: "V-BQ-03"
+          name: "Aktive Maßnahmenpläne"
+          zweck: "Nachverfolgung laufender Interventionen"
+          filterkriterien: "Filter: Interventionsdokumentation.Status = Aktiv"
+          primaerer_nutzer: "SHM-Leitung"
+    
+    # -------------------------------------------------------------------------
+    # ENGAGEMENT / TURNUS
+    # -------------------------------------------------------------------------
+    
+    - kategorie: "Engagement und Turnus"
+      beschreibung: "Planung und Nachverfolgung von Stakeholder-Interaktionen"
+      
+      views:
+        
+        - id: "V-EN-01"
+          name: "Anstehende Turnus-Termine"
+          zweck: "Terminplanung"
+          filterkriterien: "Filter: Nächster Turnus ≤ 30 Tage"
+          primaerer_nutzer: "Stakeholder-Manager"
+        
+        - id: "V-EN-02"
+          name: "Überfällige Kontakte"
+          zweck: "Eskalations-Früherkennung"
+          filterkriterien: "Filter: Letzter Kontakt > Soll-Frequenz (abgeleitet aus Betreuungsmodus)"
+          primaerer_nutzer: "SHM-Leitung, Stakeholder-Manager"
+        
+        - id: "V-EN-03"
+          name: "Key-Stakeholder Jahresübersicht"
+          zweck: "Strategische Betreuungsplanung"
+          filterkriterien: "Filter: Prio = Key; Anzeige: alle geplanten Termine"
+          primaerer_nutzer: "SHM-Leitung"
+    
+    # -------------------------------------------------------------------------
+    # BEDARFSDOKUMENTATION
+    # -------------------------------------------------------------------------
+    
+    - kategorie: "Bedarfsdokumentation"
+      beschreibung: "Überblick und Nachverfolgung von Stakeholder-Bedarfen"
+      
+      views:
+        
+        - id: "V-BD-01"
+          name: "Offene Bedarfe pro Stakeholder"
+          zweck: "Gesprächsvorbereitung"
+          filterkriterien: "Gruppierung nach Amt; Filter: Status ≠ Abgeschlossen"
+          primaerer_nutzer: "Stakeholder-Manager"
+        
+        - id: "V-BD-02"
+          name: "Bedarfe nach Routing-Pfad"
+          zweck: "Prozess-Monitoring"
+          filterkriterien: "Gruppierung nach Routing (REQ/SPM/DPM/SOR)"
+          primaerer_nutzer: "SHM-Leitung"
+        
+        - id: "V-BD-03"
+          name: "Bedarfe in Wartestellung"
+          zweck: "Follow-up-Liste"
+          filterkriterien: "Filter: Status = Übergeben, wartend"
+          primaerer_nutzer: "Stakeholder-Manager"
+    
+    # -------------------------------------------------------------------------
+    # REVIEW / REPORTING
+    # -------------------------------------------------------------------------
+    
+    - kategorie: "Review und Reporting"
+      beschreibung: "Aggregierte Sichten für E1/E2-Reviews"
+      
+      views:
+        
+        - id: "V-RV-01"
+          name: "E2-Quartalsdaten"
+          zweck: "Vorbereitung Quartalsbericht"
+          filterkriterien: "Aggregation: Kontakte, Bedarfe, Interventionen im Quartal"
+          primaerer_nutzer: "SHM-Leitung"
+          referenz: "shm_koordinations-und-steuerungsstruktur.yaml → e2_quartals_review"
+        
+        - id: "V-RV-02"
+          name: "VoC-Cluster-Übersicht"
+          zweck: "Feedback-Aggregation"
+          filterkriterien: "Gruppierung nach Cluster; Anzeige: Ampel-Status"
+          primaerer_nutzer: "SHM-Leitung"
+          referenz: "shm_voice-of-customer.yaml → cluster"
+        
+        - id: "V-RV-03"
+          name: "E1-Jahresübersicht"
+          zweck: "Vorbereitung Jahresbericht"
+          filterkriterien: "Aggregation aller relevanten Metriken auf Jahresebene"
+          primaerer_nutzer: "SHM-Leitung"
+          referenz: "shm_koordinations-und-steuerungsstruktur.yaml → e1_jahres_review"
+
+# =============================================================================
+# SCHNITTSTELLEN
+# =============================================================================
+
+schnittstellen:
+  
+  beschreibung: |
+    SIMS steht nicht isoliert, sondern hat konzeptionelle Schnittstellen 
+    zu anderen Informationssystemen und Funktionen. Diese Schnittstellen 
+    sind zunächst als Informationsflüsse zu verstehen, nicht als 
+    technische Integrationen.
+  
+  schnittstellen:
+    
+    - id: "SS-01"
+      name: "DPM (Demand-Portfolio-Management)"
+      
+      richtung: "SIMS → DPM"
+      
+      beschreibung: |
+        Bei Routing-Entscheidung ROUTE-DPM wird der Bedarfssteckbrief 
+        an DPM übergeben. DPM übernimmt dann die weitere Bearbeitung 
+        im Demand-Lifecycle.
+      
+      uebergabeobjekt: "Bedarfssteckbrief (IO-02)"
+      
+      informationsfluss:
+        von_sims: 
+          - "Bedarfssteckbrief mit Stakeholder-Kontext"
+          - "User Stories (falls erhoben)"
+        von_dpm:
+          - "Status-Updates zum Demand"
+          - "Entscheidungen (DSR/MB)"
+      
+      governance_referenz: "shm_d2p-integration.yaml"
+    
+    - id: "SS-02"
+      name: "SPM (Service-Portfolio-Management)"
+      
+      richtung: "Bidirektional"
+      
+      beschreibung: |
+        SPM liefert Service-Performance-Daten, die für Turnus-Gespräche 
+        und Beziehungsqualitäts-Bewertung relevant sind. SHM liefert 
+        Kundenfeedback und Bedarfe im Service-Kontext.
+      
+      informationsfluss:
+        von_spm:
+          - "SLA-Einhaltung pro Amt/Service"
+          - "Bekannte Service-Probleme"
+          - "Service-Änderungen (für proaktive Kommunikation)"
+        von_sims:
+          - "VoC-Feedback zu Services"
+          - "Bedarfssteckbriefe (bei ROUTE-SPM)"
+      
+      hinweis: |
+        Der Informationsfluss erfolgt im MVP manuell (Abfrage vor 
+        Turnus-Gespräch). Eine technische Integration ist optional.
+    
+    - id: "SS-03"
+      name: "Ticket-System (Service Desk)"
+      
+      richtung: "Ticket-System → SIMS (lesend)"
+      
+      beschreibung: |
+        Für Turnus-Gespräche und Beziehungsqualitäts-Bewertung sind 
+        Informationen zu offenen Tickets pro Amt relevant.
+      
+      informationsfluss:
+        von_ticketsystem:
+          - "Anzahl offener Tickets pro Amt"
+          - "Eskalierte Tickets"
+          - "Wiederkehrende Probleme"
+        von_sims:
+          - "(kein direkter Rückfluss)"
+      
+      hinweis: |
+        Im MVP erfolgt die Abfrage manuell. Eine automatisierte 
+        Einspielung ist bei entsprechendem Tooling möglich.
+
+# =============================================================================
+# GOVERNANCE
+# =============================================================================
+
+governance:
+  
+  beschreibung: |
+    Regeln für Datenpflege, Qualitätssicherung und Verantwortlichkeiten 
+    im SIMS.
+  
+  datenpflege:
+    
+    prinzip: |
+      Jeder Datensatz hat genau einen Verantwortlichen für die Pflege. 
+      Die Verantwortung folgt der Betreuungszuordnung.
+    
+    verantwortlichkeiten:
+      
+      - objekt: "Amts-Steckbrief"
+        verantwortlich: "Zugeordneter Stakeholder-Manager"
+        aktualisierung: "Laufend, mindestens bei Turnus-Gespräch"
+      
+      - objekt: "Bedarfssteckbrief"
+        verantwortlich: "Erfassender Stakeholder-Manager"
+        aktualisierung: "Bei Status-Änderungen"
+      
+      - objekt: "Gesprächsprotokoll"
+        verantwortlich: "Durchführender Stakeholder-Manager"
+        aktualisierung: "Innerhalb von 5 Arbeitstagen nach Gespräch"
+      
+      - objekt: "Interventionsdokumentation"
+        verantwortlich: "Zugeordneter Stakeholder-Manager"
+        aktualisierung: "Laufend während Intervention"
+      
+      - objekt: "VoC-Feedback-Eintrag"
+        verantwortlich: "Erfassender Stakeholder-Manager"
+        aktualisierung: "Bei Erfassung (einmalig)"
+  
+  qualitaetssicherung:
+    
+    - id: "QS-01"
+      name: "Vollständigkeitsprüfung Stammdaten"
+      beschreibung: "Prüfung auf vollständige Pflichtfelder im Amts-Steckbrief"
+      frequenz: "Quartalsweise (im Rahmen E2)"
+      verantwortlich: "SHM-Leitung"
+      referenz: "shm_schema_amtssteckbrief.yaml → validierung"
+    
+    - id: "QS-02"
+      name: "Aktualitätsprüfung"
+      beschreibung: "Identifikation von Datensätzen ohne Aktualisierung > 12 Monate"
+      frequenz: "Halbjährlich"
+      verantwortlich: "SHM-Leitung"
+    
+    - id: "QS-03"
+      name: "Konsistenzprüfung Prio/Betreuungsmodus"
+      beschreibung: "Prüfung, ob Betreuungsmodus zur Prio-Stufe passt"
+      frequenz: "Quartalsweise (im Rahmen E2)"
+      verantwortlich: "SHM-Leitung"
+      referenz: "shm_schema_amtssteckbrief.yaml → validierung VAL-003"
+  
+  archivierung:
+    
+    prinzip: |
+      Abgeschlossene Objekte (erledigte Bedarfe, beendete Interventionen) 
+      werden nicht gelöscht, sondern archiviert. Sie bleiben für 
+      Nachvollziehbarkeit und Trendanalysen zugänglich.
+    
+    aufbewahrungsfristen:
+      - objekt: "Amts-Steckbrief"
+        frist: "Dauerhaft (solange Amt im Portfolio)"
+      - objekt: "Bedarfssteckbrief"
+        frist: "5 Jahre nach Abschluss"
+      - objekt: "Gesprächsprotokoll"
+        frist: "5 Jahre"
+      - objekt: "Interventionsdokumentation"
+        frist: "5 Jahre nach Abschluss"
+      - objekt: "VoC-Feedback-Eintrag"
+        frist: "3 Jahre"
+    
+    hinweis: |
+      Die Fristen sind initiale Vorschläge und ggf. an organisatorische 
+      oder rechtliche Vorgaben anzupassen.
+
+# =============================================================================
+# EINFÜHRUNGSHINWEISE
+# =============================================================================
+
+einfuehrung:
+  
+  beschreibung: |
+    Hinweise für die Einführung des SIMS in den operativen Betrieb.
+  
+  empfohlenes_vorgehen:
+    
+    - phase: "1. Toolauswahl"
+      beschreibung: |
+        Auswahl eines geeigneten Werkzeugs basierend auf den 
+        fachlichen Anforderungen dieses Konzepts.
+      kriterien:
+        - "Unterstützung strukturierter Datenerfassung"
+        - "Flexible View-/Filtermöglichkeiten"
+        - "Verlinkung zwischen Objekten"
+        - "Zugänglichkeit für alle SHM-Mitarbeitenden"
+    
+    - phase: "2. Pilotierung"
+      beschreibung: |
+        Erprobung mit einer Teilmenge des Portfolios (z.B. ein Dezernat) 
+        vor vollständigem Rollout.
+      ziel: "Validierung der Struktur und Views"
+    
+    - phase: "3. Initiale Befüllung"
+      beschreibung: |
+        Migration/Erfassung der Bestandsdaten für alle Stakeholder.
+      hinweis: "Qualität vor Vollständigkeit bei der Erstbefüllung"
+    
+    - phase: "4. Schulung"
+      beschreibung: |
+        Einweisung aller Stakeholder-Manager in Struktur und Nutzung.
+    
+    - phase: "5. Review und Anpassung"
+      beschreibung: |
+        Nach 6 Monaten Betrieb: Review der Views und Struktur, 
+        Anpassung basierend auf Praxiserfahrung.
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+  
+  - version: "1.0"
+    datum: "2025-12-11"
+    autor: "Konzept-Sprint Phase 10"
+    aenderung: |
+      Initiale Erstellung:
+      - Meta-Informationen und Design-Prinzipien
+      - Informationsobjekte IO-01 bis IO-05 definiert
+      - Strukturkonzept mit 4 Bereichen
+      - 16 Views in 5 Kategorien (als Vorschlag)
+      - Konzeptionelle Schnittstellen zu DPM, SPM, Ticket-System
+      - Governance (Datenpflege, QS, Archivierung)
+      - Einführungshinweise

#03_stakeholder-management/#03.3_konzepte/shm_stakeholder-portfolio.yaml

@@ -0,0 +1,950 @@
+# =============================================================================
+# SHM STAKEHOLDER-PORTFOLIO: KONZEPT
+# =============================================================================
+# Modul: Stakeholder-Management (SHM)
+# Funktion: Konzepte
+# Version: 1.3
+# Datum: 2026-01-23
+# Status: Final
+# =============================================================================
+
+meta:
+  modul_id: "SHM-K-01"
+  name: "Stakeholder-Portfolio"
+  typ: "Konzept"
+  
+  zweck: |
+    Das Stakeholder-Portfolio ist das zentrale Steuerungsinstrument des 
+    Stakeholder-Managements. Es erfasst alle Organisationseinheiten im 
+    Kundenkreis von DIGIT, segmentiert sie nach relevanten Dimensionen 
+    und priorisiert sie für die Ressourcenallokation.
+    
+    Das Portfolio ist kein Selbstzweck, sondern ein Entscheidungsinstrument.
+    Seine Struktur folgt aus den Entscheidungen, die es unterstützen soll.
+  
+  scope: |
+    Alle Organisationseinheiten im Dezernatsverteilungsplan der Stadt:
+    - Ämter
+    - Eigenbetriebe
+    - Referate
+    - Stabsstellen
+    - Projektgruppen
+  
+  governance_referenzen:
+    - "GOV-SHM-001 bis GOV-SHM-014"
+    - "readme_shm_governance-entscheidungs-log.yaml"
+  
+  schema_referenz:
+    dokument: "shm_schema_amtssteckbrief.yaml"
+    beschreibung: "Technisches Attribut-Schema für die Datenerfassung pro Amt"
+
+# =============================================================================
+# FUNKTIONALE HERLEITUNG
+# =============================================================================
+
+funktionale_herleitung:
+  
+  leitfrage: |
+    Welche Entscheidungen soll das Stakeholder-Portfolio ermöglichen?
+  
+  kernentscheidungen:
+    
+    - id: PKE-1
+      name: "Betreuungsallokation"
+      leitfrage: "Wer wird wie intensiv betreut?"
+      kontext: |
+        Ressourcenknappheit erfordert Priorisierung. Nicht alle Ämter 
+        können gleich intensiv betreut werden. Das Portfolio muss helfen, 
+        die Betreuungsintensität systematisch zu differenzieren.
+      unterstuetzt_durch:
+        - "Priorisierung (Ebene 3)"
+        - "Betreuungsmodus-Ableitung"
+    
+    - id: PKE-2
+      name: "Bedarfsrouting"
+      leitfrage: "Wohin gehört dieser Bedarf?"
+      kontext: |
+        Wenn ein Bedarf eingeht, muss SHM entscheiden: Ist das ein 
+        Service-Request (→ Katalog), ein Change an bestehendem Service 
+        (→ Service Owner), oder ein neuer Demand (→ DPM)? Das Wissen 
+        über den Stakeholder und sein typisches Bedarfsprofil beeinflusst 
+        diese Einordnung.
+      unterstuetzt_durch:
+        - "Segmentierung (Ebene 2)"
+        - "Funktion + IT-Anforderungsprofil"
+    
+    - id: PKE-3
+      name: "Governance-Zuordnung"
+      leitfrage: "Wer sitzt in welchem Gremium?"
+      kontext: |
+        Für SLAs (Kundenvertretungen), für Bedarfspriorisierung (DSR), 
+        für strategische Abstimmung braucht es Zuordnungslogiken. 
+        Das IT-Anforderungsprofil korrespondiert mit den SPM-Service-
+        Kategorien und damit mit der Gremienstruktur.
+      unterstuetzt_durch:
+        - "IT-Anforderungsprofil → SPM-Kategorie-Mapping"
+        - "SLA-Befugnis im Amts-Steckbrief"
+
+# =============================================================================
+# DREI-EBENEN-MODELL
+# =============================================================================
+
+drei_ebenen_modell:
+  
+  beschreibung: |
+    Das Portfolio ist in drei Ebenen strukturiert, die aufeinander aufbauen:
+    
+    1. Amts-Steckbrief – Datengrundlage pro Organisationseinheit
+    2. Segmentierung – Clustering nach zwei unabhängigen Dimensionen
+    3. Priorisierung – Bewertung zur Ableitung des Betreuungsmodus
+    
+    Ergänzend: Der Betreuungsstatus (Stammdaten) dokumentiert, ob eine 
+    Zusammenarbeit mit dem Amt überhaupt möglich ist – unabhängig von 
+    dessen Wichtigkeit (Priorisierung).
+  
+  governance_referenz: "GOV-SHM-001"
+
+# =============================================================================
+# BETREUUNGSSTATUS-KONZEPT
+# =============================================================================
+
+betreuungsstatus_konzept:
+  
+  beschreibung: |
+    Der Betreuungsstatus ist ein Stammdatum (nicht Teil der Priorisierung),
+    das dokumentiert, ob eine Zusammenarbeit mit einem Amt möglich ist.
+    
+    Hintergrund:
+    Die Priorisierungsdimensionen (Einfluss, Abhängigkeit, Relevanz) 
+    beantworten die Frage "Wie wichtig ist das Amt?". Sie beantworten 
+    nicht "Können wir mit dem Amt zusammenarbeiten?"
+    
+    Beispiele für eingeschränkte Zusammenarbeit:
+    - Feuerwehr: Getrennte IT-Systeme, keine DIGIT-Betreuung
+    - Amt X: Schwierige Beziehung, Zugang erschwert
+    
+    Diese Ämter sollen im Portfolio dokumentiert bleiben (Vollständigkeit),
+    aber die Betreuungslogik muss die Realität abbilden.
+  
+  governance_referenz: "GOV-SHM-028"
+  schema_referenz: "shm_schema_amtssteckbrief.yaml → stammdaten.betreuungsstatus"
+  
+  auspraegungen:
+    
+    - id: "AKTIV"
+      name: "Aktiv"
+      beschreibung: |
+        Zusammenarbeit möglich. Normale Priorisierung greift,
+        Betreuungsmodus wird direkt aus Prio-Stufe abgeleitet.
+      konsequenz: "effektiver_betreuungsmodus = betreuungsmodus (aus Prio-Stufe)"
+    
+    - id: "EINGESCHRAENKT"
+      name: "Eingeschränkt"
+      beschreibung: |
+        Zusammenarbeit nur punktuell möglich. Priorisierung greift,
+        aber Betreuungsmodus wird auf individuell festgelegtes
+        Maximum gedeckelt.
+      konsequenz: |
+        effektiver_betreuungsmodus = MIN(betreuungsmodus, max_betreuungsmodus)
+        Beispiel: Key-Stakeholder mit max_betreuungsmodus REGELMAESSIG
+        → effektiver_betreuungsmodus = REGELMAESSIG (nicht PROAKTIV_DEDIZIERT)
+      pflichtfelder:
+        - "begruendung (min. 30 Zeichen)"
+        - "max_betreuungsmodus"
+        - "entschieden_von"
+        - "entschieden_am"
+    
+    - id: "RUHEND"
+      name: "Ruhend"
+      beschreibung: |
+        Aktuell keine Zusammenarbeit möglich. Amt bleibt im
+        Portfolio dokumentiert, aber außerhalb aktiver Betreuung.
+        Priorisierung wird trotzdem erfasst (für Reaktivierung).
+      konsequenz: "effektiver_betreuungsmodus = KEINE_AKTIVE_BETREUUNG"
+      pflichtfelder:
+        - "begruendung (min. 30 Zeichen)"
+        - "entschieden_von"
+        - "entschieden_am"
+  
+  vorteile:
+    - "Vollständigkeit: Alle Ämter bleiben im Portfolio dokumentiert"
+    - "Flexibilität: Bei Statusänderung einfache Umstellung"
+    - "Saubere Priorisierung: Nur Wichtigkeit, nicht Machbarkeit"
+    - "Reporting: Filter nach 'aktiv betreute Ämter' vs. 'Gesamtportfolio'"
+    - "Transparenz: Gründe für eingeschränkte Zusammenarbeit dokumentiert"
+  
+  entscheidungsbefugnis:
+    rolle: "Leitung SHM"
+    begruendung: |
+      Die Entscheidung, ein Amt als 'ruhend' oder 'eingeschränkt' zu 
+      klassifizieren, hat strategische Konsequenzen und sollte nicht 
+      willkürlich getroffen werden. Die Leitung SHM hat den Gesamtüberblick
+      über das Portfolio und kann die Entscheidung im Kontext bewerten.
+    dokumentation: |
+      Jede Entscheidung muss dokumentiert werden:
+      - Wer hat entschieden (entschieden_von)
+      - Wann wurde entschieden (entschieden_am)
+      - Warum (begruendung)
+      - Wann wird der Status überprüft (naechste_pruefung, empfohlen)
+  
+  review:
+    zyklus: "Im Portfolio-Review (E2-Standard/Erweitert)"
+    inhalt: |
+      Bei jedem Portfolio-Review wird geprüft:
+      - Sind EINGESCHRÄNKT- und RUHEND-Status noch aktuell?
+      - Haben sich Rahmenbedingungen geändert?
+      - Sollten Ämter reaktiviert werden?
+
+# =============================================================================
+# EBENE 1: AMTS-STECKBRIEF
+# =============================================================================
+
+ebene_1_amtssteckbrief:
+  
+  beschreibung: |
+    Jede Organisationseinheit im Scope erhält einen Amts-Steckbrief. 
+    Dieser enthält alle Informationen, die für die drei Kernentscheidungen 
+    (Betreuungsallokation, Bedarfsrouting, Governance-Zuordnung) benötigt 
+    werden.
+  
+  herleitung: |
+    Die Attribute des Steckbriefs sind nicht willkürlich gewählt, sondern 
+    leiten sich aus den Kernentscheidungen ab. Jedes Attribut muss 
+    mindestens eine der drei Entscheidungen unterstützen. Attribute ohne 
+    klaren Entscheidungsbezug werden nicht erfasst.
+  
+  attribut_kategorien:
+    
+    - kategorie: "Stammdaten"
+      zweck: "Identifikation und organisatorische Einordnung"
+      entscheidungsbezug: "Alle (PKE-1, PKE-2, PKE-3)"
+      beispiele:
+        - "Amt/Organisationseinheit"
+        - "Dezernat"
+        - "Amtsleitung"
+        - "SLA-Befugnis (wer hat Entscheidungsbefugnis)"
+    
+    - kategorie: "Segmentierung"
+      zweck: "Einordnung in die zweidimensionale Matrix"
+      entscheidungsbezug: "PKE-2 Bedarfsrouting, PKE-3 Governance"
+      beispiele:
+        - "Funktion (Sondereinheit/Querschnitt/Bürgerservice/Fachamt)"
+        - "IT-Anforderungsprofil (Basis/Erweitert/Spezial)"
+    
+    - kategorie: "Priorisierung"
+      zweck: "Bewertung für Betreuungsallokation"
+      entscheidungsbezug: "PKE-1 Betreuungsallokation"
+      beispiele:
+        - "Einfluss (boolean)"
+        - "Abhängigkeit (boolean)"
+        - "Relevanz (boolean)"
+        - "Prio-Stufe (abgeleitet)"
+        - "Betreuungsmodus (abgeleitet)"
+    
+    - kategorie: "Governance"
+      zweck: "Gremien-Zuordnung und Vertretungslogik"
+      entscheidungsbezug: "PKE-3 Governance-Zuordnung"
+      beispiele:
+        - "Gremien-Mitgliedschaften"
+    
+    - kategorie: "Betreuung"
+      zweck: "Operative Beziehungspflege"
+      entscheidungsbezug: "E1 Betreuungsallokation"
+      beispiele:
+        - "Zugeordneter Stakeholder-Manager"
+        - "Beziehungsqualität"
+        - "Aktive Themen"
+  
+  schema_verweis: |
+    Das vollständige Attribut-Schema mit Datentypen, Wertelisten und 
+    Validierungsregeln ist in shm_schema_amtssteckbrief.yaml dokumentiert.
+
+# =============================================================================
+# EBENE 2: SEGMENTIERUNG
+# =============================================================================
+
+ebene_2_segmentierung:
+  
+  beschreibung: |
+    Die Segmentierung erfolgt zweidimensional. Beide Dimensionen sind 
+    unabhängig voneinander. Jedes Amt erhält genau eine Ausprägung pro 
+    Dimension (keine Mehrfachzuordnung, keine Tags).
+  
+  governance_referenz: "GOV-SHM-002"
+  
+  # ---------------------------------------------------------------------------
+  # DIMENSION 1: FUNKTION
+  # ---------------------------------------------------------------------------
+  
+  dimension_1_funktion:
+    
+    name: "Funktion"
+    beschreibung: "Organisatorische Rolle des Amtes in der Stadtverwaltung"
+    
+    governance_referenz: "GOV-SHM-003"
+    
+    auspraegungen:
+      
+      - id: "SONDER"
+        name: "Sondereinheit"
+        charakteristik: |
+          Organisatorisch eigenständig, eigene Rechtsform oder 
+          Sonderstatus (Eigenbetriebe, Stabsstellen, Projektgruppen)
+        beispiele:
+          - "Eigenbetrieb Stadtentwässerung"
+          - "Eigenbetrieb Theater"
+          - "Stabsstelle Digitalisierung"
+      
+      - id: "QUER"
+        name: "Querschnittsamt"
+        charakteristik: |
+          Erbringt interne Dienstleistungen für andere Ämter, 
+          hat Multiplikator-Wirkung
+        beispiele:
+          - "Haupt- und Personalamt"
+          - "Stadtkämmerei"
+          - "Rechtsamt"
+      
+      - id: "BUERGER"
+        name: "Bürgerservice"
+        charakteristik: |
+          Direkter Bürgerkontakt als Kernaufgabe, 
+          hohe externe Sichtbarkeit
+        beispiele:
+          - "Amt für Bürgerservice"
+          - "Standesamt"
+          - "Amt für Soziales"
+      
+      - id: "FACH"
+        name: "Fachamt"
+        charakteristik: |
+          Spezialisierte Fachaufgaben, oft technisch geprägt, 
+          geringerer direkter Bürgerkontakt
+        beispiele:
+          - "Stadtplanungsamt"
+          - "Garten- und Tiefbauamt"
+          - "Umweltschutzamt"
+    
+    zuordnungslogik:
+      
+      grundprinzip: |
+        Die Funktionszuordnung unterscheidet zwischen Primärfunktion 
+        (steuernd) und Sekundärfunktion (informierend).
+        
+        - Primärfunktion: Bestimmt Bedarfsrouting und Governance-Zuordnung
+        - Sekundärfunktion: Dokumentiert Kontext für differenzierte Betrachtung
+        
+        Nicht jedes Amt hat eine Sekundärfunktion. Sie wird nur vergeben, 
+        wenn ein Amt deutlich erkennbare Charakteristika einer zweiten 
+        Funktionskategorie aufweist.
+      
+      governance_referenz: "GOV-SHM-027"
+      
+      # -----------------------------------------------------------------------
+      # PRIMÄRFUNKTIONSBESTIMMUNG
+      # -----------------------------------------------------------------------
+      
+      primaerfunktion:
+        
+        beschreibung: |
+          Die Primärfunktion wird durch einen Entscheidungsbaum bestimmt.
+          Die erste zutreffende Kategorie gewinnt (Dominanzprinzip).
+        
+        entscheidungsbaum:
+          
+          schritt_1:
+            frage: "Ist das Amt organisatorisch eigenständig?"
+            indikatoren:
+              - "Eigene Rechtsform (Eigenbetrieb)"
+              - "Sonderstatus (Stabsstelle, Projektgruppe)"
+              - "Nicht in regulärer Amtsstruktur eingegliedert"
+            ja: "SONDER (Sondereinheit)"
+            nein: "weiter zu Schritt 2"
+          
+          schritt_2:
+            frage: "Erbringt das Amt primär interne Dienstleistungen für andere Ämter?"
+            indikatoren:
+              - "Hauptaufgabe ist Unterstützung anderer Ämter"
+              - "Querschnittsfunktion (Personal, Finanzen, Recht, IT, Organisation)"
+              - "Multiplikator-Wirkung auf andere Ämter"
+            ja: "QUER (Querschnittsamt)"
+            nein: "weiter zu Schritt 3"
+          
+          schritt_3:
+            frage: "Hat das Amt direkten Bürgerkontakt als Kernaufgabe?"
+            indikatoren:
+              - "Publikumsverkehr ist zentrale Aufgabe"
+              - "Bürger:innen sind primäre Zielgruppe"
+              - "Hohe externe Sichtbarkeit durch Bürger-Interaktion"
+            ja: "BUERGER (Bürgerservice)"
+            nein: "FACH (Fachamt)"
+        
+        entscheidungshilfe_bei_mehrdeutigkeit: |
+          Wenn ein Amt mehrere Charakteristika erfüllt, gilt:
+          
+          1. Dominanzprinzip anwenden: Die erste zutreffende Kategorie 
+             im Entscheidungsbaum bestimmt die Primärfunktion.
+          
+          2. Hauptaufgabe identifizieren: Was ist der Kern-Auftrag des Amtes 
+             laut Dezernatsverteilungsplan oder Geschäftsverteilungsplan?
+          
+          3. Ressourcenallokation prüfen: Wohin fließen die meisten Ressourcen 
+             (Personal, Budget, Zeit)?
+          
+          4. Selbstverständnis einbeziehen: Wie beschreibt das Amt selbst 
+             seine Hauptaufgabe?
+          
+          Beispiel Stadtkämmerei:
+          - Erfüllt Querschnitts-Kriterien (Finanzdienstleistungen für alle Ämter)
+          - Hat auch Fachamt-Charakteristika (spezialisierte Haushaltsführung)
+          → Primärfunktion: QUER (Querschnittsamt), da interne Dienstleistung
+            die Kernaufgabe ist
+      
+      # -----------------------------------------------------------------------
+      # SEKUNDÄRFUNKTIONSBESTIMMUNG
+      # -----------------------------------------------------------------------
+      
+      sekundaerfunktion:
+        
+        beschreibung: |
+          Die Sekundärfunktion dokumentiert eine zusätzliche Funktions-
+          charakteristik, die für Kontext und differenzierte Betrachtung 
+          relevant ist.
+        
+        vergabe_kriterien: |
+          Eine Sekundärfunktion wird vergeben, wenn:
+          
+          1. Das Amt deutlich erkennbare Charakteristika einer zweiten 
+             Funktionskategorie aufweist (nicht nur marginal)
+          
+          2. Diese zweite Funktion für Bedarfsrouting oder Governance 
+             relevant sein kann (z.B. Bedarfe, die eher zur Sekundär-
+             funktion passen)
+          
+          3. Die Zuordnung nachvollziehbar begründet werden kann
+        
+        nicht_vergeben_wenn: |
+          Keine Sekundärfunktion, wenn:
+          
+          - Das Amt klar einer einzigen Kategorie zuzuordnen ist
+          - Die zweite Charakteristik nur marginal ausgeprägt ist
+          - Kein praktischer Nutzen für Routing oder Governance erkennbar ist
+        
+        moegliche_kombinationen:
+          
+          - primaer: "QUER"
+            sekundaer: "FACH"
+            typisch: true
+            beispiel: "Stadtkämmerei (Querschnitt + spezialisierte Haushaltsführung)"
+          
+          - primaer: "QUER"
+            sekundaer: "BUERGER"
+            typisch: false
+            beispiel: "Haupt- und Personalamt mit Bürgerbüro-Funktion"
+          
+          - primaer: "BUERGER"
+            sekundaer: "FACH"
+            typisch: true
+            beispiel: "Amt für Soziales (Bürgerservice + spezialisierte Sozialarbeit)"
+          
+          - primaer: "FACH"
+            sekundaer: "BUERGER"
+            typisch: true
+            beispiel: "Baurechtsamt (Fachamt + Bauberatung für Bürger:innen)"
+          
+          - primaer: "FACH"
+            sekundaer: "QUER"
+            typisch: false
+            beispiel: "IT-Amt mit internen Dienstleistungen (eher selten)"
+          
+          - primaer: "SONDER"
+            sekundaer: "beliebig"
+            typisch: true
+            beispiel: "Eigenbetrieb mit Bürgerservice-Anteil"
+        
+        ausgeschlossene_kombinationen:
+          - kombination: "gleiche Primär- und Sekundärfunktion"
+            grund: "Logisch unmöglich"
+      
+      # -----------------------------------------------------------------------
+      # OPERATIVE ANWENDUNG
+      # -----------------------------------------------------------------------
+      
+      operative_anwendung:
+        
+        verwendung_primaerfunktion:
+          - "Bedarfsrouting (PKE-2): Bestimmt typisches Bedarfsprofil"
+          - "Governance-Zuordnung (PKE-3): Bestimmt Gremien-Mitgliedschaften"
+          - "Betreuungsallokation (PKE-1): Kontextinformation für Priorisierung"
+        
+        verwendung_sekundaerfunktion:
+          - "Bedarfsrouting: Differenzierte Betrachtung bei Bedarfen, die eher 
+             zur Sekundärfunktion passen"
+          - "Governance: Optionale Einbindung in Gremien der Sekundärkategorie"
+          - "Bedarfsvorhersage: Vollständigeres Bild des typischen Bedarfsprofils"
+          - "Transparenz: Dokumentation für Nachvollziehbarkeit"
+        
+        steuerungsprinzip: |
+          Primärfunktion steuert, Sekundärfunktion informiert.
+          
+          Bei Entscheidungen (Routing, Governance) ist die Primärfunktion 
+          maßgeblich. Die Sekundärfunktion kann bei begründeten Ausnahmen 
+          herangezogen werden, überschreibt aber nie die Primärfunktion.
+        
+        dokumentationspflicht: |
+          Bei Vergabe einer Sekundärfunktion muss im Amts-Steckbrief eine 
+          Begründung dokumentiert werden, die erklärt:
+          - Warum das Amt Charakteristika der Sekundärkategorie aufweist
+          - Welche praktische Relevanz die Sekundärfunktion hat
+  
+  # ---------------------------------------------------------------------------
+  # DIMENSION 2: IT-ANFORDERUNGSPROFIL
+  # ---------------------------------------------------------------------------
+  
+  dimension_2_it_profil:
+    
+    name: "IT-Anforderungsprofil"
+    beschreibung: |
+      Komplexität der IT-Bedarfe des Amtes. Die Dimension ist 
+      bedarfsorientiert (nicht nutzungsorientiert), um zukünftige 
+      Bedarfe vorherzusagen, nicht nur den Status quo abzubilden.
+    
+    governance_referenz: "GOV-SHM-004"
+    
+    auspraegungen:
+      
+      - id: "BASIS"
+        name: "Basis"
+        charakteristik: |
+          Standardbedarf, Grundausstattung reicht aus, 
+          geringe IT-Komplexität
+        spm_korrespondenz: "Kategorie A – Basis-Services"
+        typische_services:
+          - "Standard-Arbeitsplatz (Büro-PC, Office-Anwendungen)"
+          - "E-Mail und Kalender"
+          - "Zugang zu zentralen Verwaltungssystemen"
+        beispiele:
+          - "Rechtsamt"
+          - "Rechnungsprüfungsamt"
+          - "Standesamt"
+      
+      - id: "ERWEITERT"
+        name: "Erweitert"
+        charakteristik: |
+          Fachspezifische Bedarfe über Standard hinaus, 
+          mittlere IT-Komplexität. Häufig: Benötigt Zugriff auf 
+          Daten im Außendienst – erbringt einen erheblichen Teil 
+          der Arbeit außerhalb des Bürostandorts und benötigt dabei 
+          Zugriff auf städtische oder weitere relevante Daten 
+          (Baupläne, Elektropläne, Meldedaten, KFZ-Daten etc.).
+        spm_korrespondenz: "Kategorie B – Erweiterte Services"
+        typische_services:
+          - "Mobile Hardware (VPN-Notebook, EC-Cash-Gerät etc.)"
+          - "Zugriffe auf interne Daten außerhalb vom Bürostandort"
+          - "Fachverfahren mit erweitertem Funktionsumfang"
+          - "DMS, Terminbuchung, Workflow-Systeme"
+        beispiele:
+          - "Haupt- und Personalamt"
+          - "Amt für Bürgerservice"
+          - "Umweltschutzamt"
+      
+      - id: "SPEZIAL"
+        name: "Spezial"
+        charakteristik: |
+          Individuelle Bedarfe, die nur für dieses Amt gelten, 
+          hohe IT-Komplexität, Spezialsoftware, bilaterale SLAs. 
+          Arbeiten aus dem Homeoffice oft nur durch besondere 
+          Lösungen möglich (Standard-Homeoffice-Lösungen greifen nicht).
+        spm_korrespondenz: "Kategorie C – Spezial-Services"
+        typische_services:
+          - "Exklusive Fachsoftware (CAD, GIS, Spezialsysteme)"
+          - "Spezialhardware (Plotter, Messgeräte, Spezialdrucker)"
+          - "Individuelle Schnittstellenlösungen"
+          - "Besondere Homeoffice-/Remote-Lösungen"
+        beispiele:
+          - "Stadtplanungsamt (CAD, GIS)"
+          - "Garten- und Tiefbauamt"
+          - "Immobilienmanagement (Eigenbetrieb)"
+    
+    zuordnungslogik: |
+      Entscheidungsbaum:
+      
+      1. Hat das Amt individuelle IT-Bedarfe, die NUR für dieses Amt 
+         gelten? (exklusive Fachsoftware, Spezialhardware, bilaterale SLAs)
+         → JA: Spezial
+         → NEIN: weiter zu 2.
+      
+      2. Hat das Amt fachspezifische IT-Bedarfe über die Grundausstattung 
+         hinaus? (DMS, Fachverfahren, Terminbuchung, Workflow-Systeme)
+         → JA: Erweitert
+         → NEIN: Basis
+  
+  # ---------------------------------------------------------------------------
+  # MATRIX
+  # ---------------------------------------------------------------------------
+  
+  matrix:
+    
+    beschreibung: |
+      Die Kombination der beiden Dimensionen ergibt eine 4×3-Matrix.
+      Jedes Amt wird genau einem Feld zugeordnet. Nicht alle 
+      Kombinationen sind gleich häufig oder wahrscheinlich.
+    
+    governance_referenz: "GOV-SHM-006"
+    
+    hinweis_sondereinheiten: |
+      Sondereinheiten sind eine Funktionskategorie, keine Ausnahme 
+      von der zweidimensionalen Logik. Sie haben wie alle anderen 
+      Ämter ein IT-Anforderungsprofil.
+    
+    unwahrscheinliche_kombinationen:
+      - kombination: "Querschnitt + Spezial"
+        begruendung: |
+          Querschnittsämter erbringen standardisierte interne Services. 
+          Hochspezialisierte IT-Bedarfe sind untypisch.
+      - kombination: "Bürgerservice + Spezial"
+        begruendung: |
+          Bürgerservice-Ämter nutzen typischerweise standardisierte 
+          Bürger-Fachverfahren, keine exklusiven Spezial-Lösungen.
+  
+  # ---------------------------------------------------------------------------
+  # VERKNÜPFUNG ZU ENTSCHEIDUNGEN
+  # ---------------------------------------------------------------------------
+  
+  verknuepfung_entscheidungen:
+    
+    bedarfsrouting_PKE2:
+      relevante_dimensionen: "Funktion + IT-Profil"
+      logik: |
+        Die Kombination hilft, typische Bedarfe vorherzusagen:
+        - Bürgerservice + Erweitert → Terminbuchung, Aufrufsysteme, DMS
+        - Fachamt + Spezial → CAD, GIS, Spezialhardware
+        - Querschnitt + Erweitert → Personalverwaltung, Finanz-Systeme
+    
+    governance_zuordnung_PKE3:
+      relevante_dimension: "IT-Anforderungsprofil"
+      logik: |
+        Das IT-Profil korrespondiert mit SPM-Kategorien und damit 
+        mit der SLA-Governance:
+        - Basis-Profil → primär in Kundenvertretung Basisservices (Kat. A)
+        - Erweitert-Profil → in servicespezifischen Kundenvertretungen (Kat. B)
+        - Spezial-Profil → bilaterale SLAs (Kat. C)
+
+# =============================================================================
+# EBENE 3: PRIORISIERUNG
+# =============================================================================
+
+ebene_3_priorisierung:
+  
+  beschreibung: |
+    Die Priorisierung identifiziert innerhalb der Segmente die 
+    Key-Stakeholder und leitet den Betreuungsmodus ab. Sie basiert 
+    auf drei Dimensionen, die binär (ja/nein) bewertet werden.
+  
+  # ---------------------------------------------------------------------------
+  # DIMENSIONEN
+  # ---------------------------------------------------------------------------
+  
+  dimensionen:
+    
+    governance_referenz: "GOV-SHM-007"
+    
+    bewertungslogik: |
+      Jede Dimension wird binär bewertet (ja/nein). Die Bewertung 
+      erfolgt durch den Stakeholder-Manager mit dokumentierter 
+      Begründung. Die Begründung macht die Einschätzung 
+      nachvollziehbar und überprüfbar.
+    
+    dimension_1_einfluss:
+      
+      id: "E"
+      name: "Einfluss"
+      leitfrage: "Kann das Amt DIGIT-relevante Entscheidungen beeinflussen?"
+      
+      indikatoren:
+        - "Entscheidungsbefugnis über IT-Budgets oder IT-Standards"
+        - "Multiplikator-Rolle durch Größe oder Querschnittsfunktion"
+        - "Politisches Gewicht in Verwaltungsgremien"
+      
+      beispiele_ja:
+        - "Haupt- und Personalamt (IT-Standards für alle)"
+        - "Stadtkämmerei (IT-Budget-Allokation)"
+      
+      beispiele_nein:
+        - "Standesamt (kein übergreifender Einfluss)"
+    
+    dimension_2_abhaengigkeit:
+      
+      id: "A"
+      name: "Abhängigkeit"
+      leitfrage: "Steht das Amt ohne IT still?"
+      
+      indikatoren:
+        - "Kernprozesse sind IT-abhängig"
+        - "Externe Schnittstellen setzen funktionierende IT voraus"
+        - "IT-Ausfall führt zu unmittelbarem Leistungsausfall"
+      
+      beispiele_ja:
+        - "Amt für Bürgerservice (alle Prozesse IT-basiert)"
+        - "Stadtkasse (Zahlungsverkehr)"
+      
+      beispiele_nein:
+        - "Kulturamt (kann temporär analog arbeiten)"
+    
+    dimension_3_relevanz:
+      
+      id: "R"
+      name: "Relevanz"
+      leitfrage: "Ist das Amt gerade besonders wichtig für die Gesamtverwaltung?"
+      
+      indikatoren:
+        - "Hohe politische oder öffentliche Sichtbarkeit"
+        - "Beteiligung an strategischen Projekten"
+        - "Aktuelle Krisensituation oder Transformationsphase"
+      
+      charakteristik: |
+        Diese Dimension ist dynamisch und kann sich über Zeit ändern. 
+        Sie erfordert regelmäßige Überprüfung im Portfolio-Review.
+      
+      beispiele_ja:
+        - "Amt für Digitalisierung (strategisches Projekt)"
+        - "Amt für öffentliche Ordnung (bei Großveranstaltungen)"
+      
+      beispiele_nein:
+        - "Forstamt (stabile Situation, geringe Sichtbarkeit)"
+  
+  # ---------------------------------------------------------------------------
+  # GEWICHTUNG
+  # ---------------------------------------------------------------------------
+  
+  gewichtung:
+    
+    governance_referenz: "GOV-SHM-008"
+    
+    logik: |
+      Einfluss ist besonders gewichtet, da diese Ämter DIGIT direkt 
+      beeinflussen können – sei es durch Budget-Entscheidungen, 
+      Standard-Setzung oder politisches Gewicht.
+      
+      Gewichtung: Einfluss > Abhängigkeit = Relevanz
+    
+    begruendung: |
+      Ämter mit Einfluss können Ressourcen, Standards und Entscheidungen 
+      von DIGIT beeinflussen. Eine gute Beziehung zu diesen Ämtern ist 
+      strategisch wichtiger als zu Ämtern, die "nur" abhängig sind.
+  
+  # ---------------------------------------------------------------------------
+  # KOMBINATIONSLOGIK
+  # ---------------------------------------------------------------------------
+  
+  kombinationslogik:
+    
+    governance_referenz: "GOV-SHM-009"
+    
+    prio_stufen:
+      
+      - stufe: "Key"
+        kombination: "Alle drei ODER Einfluss + eine weitere"
+        beschreibung: "Strategisch wichtigste Stakeholder"
+      
+      - stufe: "Aktiv"
+        kombination: "Zwei (ohne Einfluss) ODER nur Einfluss"
+        beschreibung: "Wichtige Stakeholder mit regelmäßiger Betreuung"
+      
+      - stufe: "Standard"
+        kombination: "Eine (Abhängigkeit oder Relevanz)"
+        beschreibung: "Stakeholder mit punktuellem Betreuungsbedarf"
+      
+      - stufe: "Basis"
+        kombination: "Keine Dimension erfüllt"
+        beschreibung: "Stakeholder mit reaktiver Betreuung"
+    
+    kombinationstabelle: |
+      
+      │ E │ A │ R │ Prio-Stufe │
+      ├───┼───┼───┼────────────┤
+      │ ✓ │ ✓ │ ✓ │ Key        │
+      │ ✓ │ ✓ │ – │ Key        │
+      │ ✓ │ – │ ✓ │ Key        │
+      │ – │ ✓ │ ✓ │ Aktiv      │
+      │ ✓ │ – │ – │ Aktiv      │
+      │ – │ ✓ │ – │ Standard   │
+      │ – │ – │ ✓ │ Standard   │
+      │ – │ – │ – │ Basis      │
+      
+      Legende: E = Einfluss, A = Abhängigkeit, R = Relevanz
+  
+  # ---------------------------------------------------------------------------
+  # BETREUUNGSMODUS
+  # ---------------------------------------------------------------------------
+  
+  betreuungsmodus:
+    
+    governance_referenz: "GOV-SHM-010"
+    
+    beschreibung: |
+      Der Betreuungsmodus wird aus der Prio-Stufe abgeleitet und 
+      definiert die Art und Intensität der Stakeholder-Betreuung.
+    
+    modi:
+      
+      - prio_stufe: "Key"
+        modus: "Proaktiv/Dediziert"
+        beschreibung: |
+          Regelmäßige Turnusgespräche (z.B. halbjährlich),
+          dedizierter Stakeholder-Manager,
+          aktive Bedarfserhebung,
+          Einladung zu strategischen Abstimmungen
+      
+      - prio_stufe: "Aktiv"
+        modus: "Regelmäßig"
+        beschreibung: |
+          Teilnahme am Cluster-Advisory-Board,
+          anlassbezogene Gespräche,
+          Einladung zu relevanten Themen
+      
+      - prio_stufe: "Standard"
+        modus: "Eingebunden"
+        beschreibung: |
+          Teilnahme am Cluster-Advisory-Board,
+          reaktive Betreuung bei Anfragen
+      
+      - prio_stufe: "Basis"
+        modus: "Reaktiv"
+        beschreibung: |
+          Keine proaktive Betreuung,
+          nur bei eingehenden Anfragen,
+          Information über allgemeine Kanäle
+  
+  # ---------------------------------------------------------------------------
+  # ÜBERPRÜFUNG
+  # ---------------------------------------------------------------------------
+  
+  ueberpruefung:
+
+    governance_referenz: "GOV-SHM-012"
+
+    beschreibung: |
+      Die Priorisierung wird periodisch überprüft, insbesondere
+      die Dimension "Relevanz", die sich über Zeit ändern kann.
+
+    zyklus: |
+      Im Rahmen der Koordinations- und Steuerungsstruktur
+      (shm_koordinations-und-steuerungsstruktur.yaml):
+      - REV-2-Standard (Q1/Q3): Portfolio-Analyse
+      - REV-2-Erweitert (Q2/Q4): Portfolio-Analyse + Verbesserungsplanung
+
+    voc_integration: |
+      Die Portfolio-Überprüfung nutzt VoC-Erkenntnisse (shm_voice-of-customer.yaml)
+      zu Beziehungsqualität, Zufriedenheit und Bedarfsentwicklung, um
+      Priorisierungen und Betreuungsmodi anzupassen.
+
+    stabilität_der_dimensionen:
+      einfluss: "Relativ stabil (Organisationsstruktur)"
+      abhaengigkeit: "Relativ stabil (Prozessstruktur)"
+      relevanz: "Dynamisch (politische Themen, strategische Projekte)"
+
+# =============================================================================
+# VERKNÜPFUNG SPM
+# =============================================================================
+
+verknuepfung_spm:
+  
+  beschreibung: |
+    Das SHM-Stakeholder-Portfolio ist mit dem SPM-Service-Portfolio 
+    über harmonisierte Terminologie und Governance-Brücken verknüpft.
+  
+  governance_referenz: "GOV-SHM-005"
+  
+  terminologie_mapping:
+    
+    beschreibung: |
+      Die IT-Anforderungsprofile im SHM korrespondieren mit den 
+      Service-Kategorien im SPM. Die Terminologie wurde bewusst 
+      harmonisiert.
+    
+    mapping:
+      - shm_profil: "Basis"
+        spm_kategorie: "A – Basis-Services"
+      - shm_profil: "Erweitert"
+        spm_kategorie: "B – Erweiterte Services"
+      - shm_profil: "Spezial"
+        spm_kategorie: "C – Spezial-Services"
+  
+  governance_bruecke: |
+    Die Verknüpfung ermöglicht eine systematische Governance-Zuordnung:
+    
+    SHM: Amt hat Profil "Erweitert"
+        ↓
+    SPM: Amt nutzt wahrscheinlich Kategorie-B-Services
+        ↓
+    Governance: Amt ist potenziell in Kundenvertretungen für B-Services
+  
+  sla_befugnis: |
+    Die SLA-Befugnis im Amts-Steckbrief folgt der gleichen Logik wie 
+    im SPM (P-02 SLM): Primär Amtsleitung, alternativ delegierte Person 
+    mit dokumentierter Entscheidungsbefugnis.
+    
+    Governance-Referenz: GOV-SHM-013
+
+# =============================================================================
+# ÄNDERUNGSHISTORIE
+# =============================================================================
+
+aenderungshistorie:
+  - version: "1.0"
+    datum: "2025-12-03"
+    autor: "DIGITOM-Projekt"
+    aenderung: "Initiale Erstellung basierend auf Phase-1-Konzeptentwicklung"
+    governance_basis: "GOV-SHM-001 bis GOV-SHM-014"
+
+  - version: "1.1"
+    datum: "2025-12-10"
+    autor: "Cross-Check Phase 5"
+    aenderung: |
+      - Überprüfungs-Abschnitt erweitert:
+        - Veraltete Phase-7-Referenz aktualisiert auf
+          shm_koordinations-und-steuerungsstruktur.yaml
+        - VoC-Integration ergänzt (Nutzung von VoC-Erkenntnissen für
+          Portfolio-Überprüfung)
+        - Zyklus präzisiert (E2-Standard und E2-Erweitert)
+
+  - version: "1.2"
+    datum: "2026-01-23"
+    autor: "DIGITOM-Projekt"
+    aenderung: |
+      - Dimension 1 (Funktion) erweitert um Primär-/Sekundärfunktionslogik:
+        - Strukturierter Entscheidungsbaum für Primärfunktionsbestimmung
+        - Entscheidungshilfe bei Mehrdeutigkeit
+        - Verfahren zur Sekundärfunktionsbestimmung mit Vergabekriterien
+        - Dokumentation möglicher und ausgeschlossener Kombinationen
+        - Operative Anwendung mit Steuerungsprinzip
+        - Dokumentationspflicht bei Sekundärfunktion
+    governance_referenz: "GOV-SHM-027"
+
+  - version: "1.3"
+    datum: "2026-01-23"
+    autor: "DIGITOM-Projekt"
+    aenderung: |
+      Betreuungsstatus-Konzept (GOV-SHM-028):
+      - Neuer Abschnitt 'betreuungsstatus_konzept' eingefügt
+      - Drei Ausprägungen: AKTIV, EINGESCHRÄNKT, RUHEND
+      - Dokumentation der Deckelungslogik für effektiven Betreuungsmodus
+      - Entscheidungsbefugnis bei Leitung SHM
+      - Review im Portfolio-Review (E2-Standard/Erweitert)
+      - Ergänzung im Drei-Ebenen-Modell
+    governance_referenz: "GOV-SHM-028"
+
+  - version: "1.4"
+    datum: "2026-01-26"
+    autor: "DIGITOM-Projekt"
+    aenderung: |
+      IT-Anforderungsprofil präzisiert (dimension_2_it_profil):
+      - Neues Attribut 'typische_services' bei allen drei Profilen ergänzt
+      - BASIS: Standard-Arbeitsplatz, E-Mail/Kalender, zentrale Systeme
+      - ERWEITERT: Mobile Hardware (VPN-Notebook, EC-Cash), Außendienst-
+        Zugriffe, Fachverfahren, DMS/Workflow
+      - SPEZIAL: Exklusive Fachsoftware, Spezialhardware, individuelle
+        Schnittstellen, besondere Homeoffice-Lösungen
+      - Charakteristik ERWEITERT ergänzt um Außendienst-Beschreibung
+      - Charakteristik SPEZIAL ergänzt um Homeoffice-Einschränkung