# ============================================================================= # SHM GOVERNANCE-ENTSCHEIDUNGS-LOG # ============================================================================= # Version: 1.8 # Datum: 2026-01-23 # Letzte Änderung: Bedarfsrouting SO-Klärung (GOV-SHM-029) # Status: Final # Quelle: Chat-Session SHM-Konzeptentwicklung # ============================================================================= meta: beschreibung: | Dokumentation aller Governance-Entscheidungen, die während der Entwicklung des SHM Stakeholder-Portfolio-Konzepts getroffen wurden. kontext: | Diese Entscheidungen wurden in der Chat-Session zur Phase 1 (Stakeholder-Portfolio-Modellierung) erarbeitet und bilden die Grundlage für die MVP-Konzeption. referenz_arbeitsdokumente: - "[tmp]_shm_amtssteckbrief.yaml" - "[tmp]_shm_stakeholder-segmentierung.yaml" - "[tmp]_shm_stakeholder-priorisierung.yaml" # ============================================================================= # ENTSCHEIDUNGEN: GRUNDSTRUKTUR # ============================================================================= entscheidungen: # --------------------------------------------------------------------------- # PORTFOLIO-STRUKTUR # --------------------------------------------------------------------------- - id: GOV-SHM-001 datum: 2025-12-03 quelle_modul: "Stakeholder-Portfolio" frage: | Welche Grundstruktur hat das Stakeholder-Portfolio? entscheidung: | Drei-Ebenen-Modell: 1. Amts-Steckbrief (Datengrundlage pro Amt) 2. Segmentierung (Clustering nach zwei Dimensionen) 3. Priorisierung (Bewertung zur Betreuungsallokation) begruendung: | Das Portfolio muss drei Kernentscheidungen unterstützen: - E1: Betreuungsallokation (Wer wird wie intensiv betreut?) - E2: Bedarfsrouting (Wohin gehört dieser Bedarf?) - E3: Governance-Zuordnung (Wer sitzt in welchem Gremium?) Die drei Ebenen adressieren diese Entscheidungen systematisch. auswirkung_auf: - dokument: "shm_stakeholder-portfolio.yaml" abschnitt: "Gesamtstruktur" status: final # --------------------------------------------------------------------------- # SEGMENTIERUNG # --------------------------------------------------------------------------- - id: GOV-SHM-002 datum: 2025-12-03 quelle_modul: "Stakeholder-Portfolio / Segmentierung" frage: | Nach welcher Logik werden Ämter segmentiert? entscheidung: | Zweidimensionale Segmentierung: - Dimension 1: Funktion (organisatorische Rolle) - Dimension 2: IT-Anforderungsprofil (Bedarfskomplexität) Beide Dimensionen sind unabhängig. Jedes Amt erhält genau eine Ausprägung pro Dimension (keine Mehrfachzuordnung/Tags). begruendung: | Die ursprüngliche Drei-Cluster-Logik (Querschnitt, Bürgerkontakt, Technisch) vermischte verschiedene Dimensionen (Funktion, Arbeitsweise, Anforderungsniveau). Die zweidimensionale Struktur trennt diese sauber und ermöglicht differenziertere Zuordnung. verworfene_alternativen: - option: "Eindimensionale Cluster nach Bedarfsprofil" grund: "Nicht trennscharf, viele Überlappungen" - option: "Tagging statt exklusiver Zuordnung" grund: "Erhöht Komplexität ohne klaren Mehrwert" auswirkung_auf: - dokument: "shm_stakeholder-portfolio.yaml" abschnitt: "Segmentierung" - dokument: "[tmp]_shm_stakeholder-segmentierung.yaml" abschnitt: "grundkonzept" status: final # --------------------------------------------------------------------------- - id: GOV-SHM-003 datum: 2025-12-03 quelle_modul: "Stakeholder-Portfolio / Segmentierung" frage: | Welche Ausprägungen hat Dimension 1 (Funktion)? entscheidung: | Vier Ausprägungen mit Entscheidungsbaum-Logik: 1. Sondereinheit – Eigenbetriebe, Stabsstellen, Projektgruppen 2. Querschnitt – Verwaltungsinterne Unterstützungsfunktion 3. Bürgerservice – Direkter Bürgerkontakt als Kernaufgabe 4. Fachamt – Spezialisierte Fachaufgabe (Default) Zuordnungslogik (erste zutreffende Kategorie gewinnt): Sondereinheit → Querschnitt → Bürgerservice → Fachamt begruendung: | - "Sondereinheit" wurde ergänzt für Eigenbetriebe etc., die organisatorisch anders strukturiert sind - Entscheidungsbaum-Logik vermeidet Mehrdeutigkeiten - "Fachamt" als Default fängt alle nicht anderweitig zuordenbaren Ämter auswirkung_auf: - dokument: "shm_stakeholder-portfolio.yaml" abschnitt: "Segmentierung / Dimension 1" status: final # --------------------------------------------------------------------------- - id: GOV-SHM-004 datum: 2025-12-03 quelle_modul: "Stakeholder-Portfolio / Segmentierung" frage: | Welche Ausprägungen hat Dimension 2 (IT-Anforderungsprofil)? entscheidung: | Drei Ausprägungen (bedarfsorientiert, nicht nutzungsorientiert): 1. Basis – Standardbedarf, Grundausstattung reicht aus 2. Erweitert – Fachspezifische Bedarfe über Standard hinaus 3. Spezial – Individuelle Bedarfe, die nur für dieses Amt gelten Zuordnungslogik (Entscheidungsbaum): 1. Individuelle IT-Bedarfe nur für dieses Amt? → Spezial 2. Fachspezifische Bedarfe über Grundausstattung? → Erweitert 3. Sonst → Basis begruendung: | - Bedarfsorientiert (nicht nutzungsorientiert), um zukünftige Bedarfe vorherzusagen, nicht nur Status quo abzubilden - Terminologie harmonisiert mit SPM Service-Kategorien (siehe GOV-SHM-005) auswirkung_auf: - dokument: "shm_stakeholder-portfolio.yaml" abschnitt: "Segmentierung / Dimension 2" status: final # --------------------------------------------------------------------------- - id: GOV-SHM-005 datum: 2025-12-03 quelle_modul: "Stakeholder-Portfolio / SPM-Harmonisierung" frage: | Wie wird terminologische Konsistenz zwischen SHM und SPM hergestellt? entscheidung: | Harmonisierte Terminologie für IT-Profile (SHM) und Service-Kategorien (SPM): | SHM IT-Profil | SPM Service-Kategorie | |---------------|----------------------| | Basis | A – Basis-Services | | Erweitert | B – Erweiterte Services | | Spezial | C – Spezial-Services | Erforderliche Änderung im SPM: Kategorie B wird von "Modular-Services" zu "Erweiterte Services" umbenannt. begruendung: | - "Modular" beschreibt die Architektur des Services (zubuchbar) - "Erweitert" beschreibt die Beziehung zum Basis-Level - "Erweitert" funktioniert für beide Perspektiven (Service und Amt) auswirkung_auf: - dokument: "spm_practice_service-level-management.yaml" abschnitt: "Service-Kategorien" - dokument: "spm_practice_service-catalog-management.yaml" abschnitt: "Kategorien-Logik" - dokument: "spm_schema_service-definition.yaml" abschnitt: "Enum-Werte" status: draft # Umsetzung im SPM noch ausstehend offene_fragen: - "Governance-Entscheidung ins SPM-Log übertragen" - "Templates anpassen" # --------------------------------------------------------------------------- - id: GOV-SHM-006 datum: 2025-12-03 quelle_modul: "Stakeholder-Portfolio / Segmentierung" frage: | Haben Sondereinheiten (Eigenbetriebe etc.) auch ein IT-Anforderungsprofil? entscheidung: | Ja. Sondereinheiten sind eine Funktionskategorie, keine Ausnahme von der zweidimensionalen Logik. Sie werden wie alle anderen Ämter in die Matrix (Funktion × IT-Profil) eingeordnet. Beispiele: - Eigenbetrieb Stadtentwässerung → Sondereinheit + Spezial - Eigenbetrieb Theater → Sondereinheit + Basis begruendung: | Sondereinheiten sind organisatorisch anders, haben aber trotzdem IT-Bedarfe, die für Betreuung und Governance relevant sind. auswirkung_auf: - dokument: "shm_stakeholder-portfolio.yaml" abschnitt: "Matrix-Beschreibung" status: final # --------------------------------------------------------------------------- # PRIORISIERUNG # --------------------------------------------------------------------------- - id: GOV-SHM-007 datum: 2025-12-03 quelle_modul: "Stakeholder-Portfolio / Priorisierung" frage: | Nach welchen Dimensionen werden Stakeholder priorisiert? entscheidung: | Drei Dimensionen (binär bewertet): 1. Einfluss – Kann das Amt DIGIT-relevante Entscheidungen beeinflussen? Indikatoren: Entscheidungsbefugnis über IT-Budgets/Standards ODER Multiplikator-Rolle durch Größe/Querschnittsfunktion 2. Abhängigkeit – Steht das Amt ohne IT still? Indikatoren: Kernprozesse IT-abhängig ODER externe Schnittstellen setzen funktionierende IT voraus 3. Relevanz – Ist das Amt gerade besonders wichtig für die Gesamtverwaltung? Indikatoren: Hohe politische/öffentliche Sichtbarkeit ODER Beteiligung an strategischen Projekten begruendung: | - Basiert auf SALI-Modell aus Workshop, aber angepasst: - "Macht/Einfluss" → "Einfluss" (präzisiert) - "Legitimität" → größtenteils durch Scope-Definition abgedeckt - "Dringlichkeit" → aufgeteilt in "Abhängigkeit" und "Relevanz" - Binäre Bewertung (ja/nein) für Nachvollziehbarkeit - "Bedarfsvolumen" bewusst ausgeschlossen (ist Symptom, nicht Kriterium) verworfene_alternativen: - option: "SALI mit Legitimität" grund: "Legitimität teilweise durch Scope-Definition abgedeckt" - option: "Bedarfsvolumen als Dimension" grund: "Ist Symptom, nicht strategisches Kriterium" auswirkung_auf: - dokument: "shm_stakeholder-portfolio.yaml" abschnitt: "Priorisierung / Dimensionen" status: final # --------------------------------------------------------------------------- - id: GOV-SHM-008 datum: 2025-12-03 quelle_modul: "Stakeholder-Portfolio / Priorisierung" frage: | Wie werden die Priorisierungsdimensionen gewichtet? entscheidung: | Einfluss ist besonders gewichtet, da diese Ämter DIGIT direkt beeinflussen können. 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. auswirkung_auf: - dokument: "shm_stakeholder-portfolio.yaml" abschnitt: "Priorisierung / Kombinationslogik" status: final # --------------------------------------------------------------------------- - id: GOV-SHM-009 datum: 2025-12-03 quelle_modul: "Stakeholder-Portfolio / Priorisierung" frage: | Welche Prio-Stufen gibt es und wie ergeben sie sich aus den Dimensionen? entscheidung: | Vier Prio-Stufen mit folgender Kombinationslogik: | Prio-Stufe | Kombination | |------------|------------------------------------------| | Key | Alle drei ODER Einfluss + eine weitere | | Aktiv | Zwei (ohne Einfluss) ODER nur Einfluss | | Standard | Eine (Abhängigkeit oder Relevanz) | | Basis | Keine Dimension erfüllt | Vollständige Kombinationstabelle: | E | A | R | Prio-Stufe | |---|---|---|------------| | ✓ | ✓ | ✓ | Key | | ✓ | ✓ | – | Key | | ✓ | – | ✓ | Key | | – | ✓ | ✓ | Aktiv | | ✓ | – | – | Aktiv | | – | ✓ | – | Standard | | – | – | ✓ | Standard | | – | – | – | Basis | begruendung: | - Vier Stufen sind ausreichend differenziert für ~40-50 Ämter - Einfluss-Gewichtung spiegelt sich in Kombinationslogik wider - Sieben Prio-Stufen (wie im SALI-Original) wären zu granular auswirkung_auf: - dokument: "shm_stakeholder-portfolio.yaml" abschnitt: "Priorisierung / Kombinationslogik" status: final # --------------------------------------------------------------------------- - id: GOV-SHM-010 datum: 2025-12-03 quelle_modul: "Stakeholder-Portfolio / Priorisierung" frage: | Welcher Betreuungsmodus ergibt sich aus welcher Prio-Stufe? entscheidung: | | Prio-Stufe | Betreuungsmodus | Konkret | |------------|---------------------|--------------------------------------------------| | Key | Proaktiv/Dediziert | Turnusgespräche, dedizierter SM, aktive Bedarfserhebung | | Aktiv | Regelmäßig | Advisory Board, anlassbezogene Gespräche | | Standard | Eingebunden | Advisory Board, reaktiv bei Anfragen | | Basis | Reaktiv | Nur bei eingehenden Anfragen | begruendung: | Abstufung der Betreuungsintensität entsprechend der Ressourcenverfügbarkeit und strategischen Bedeutung. Key-Stakeholder erhalten dedizierte Betreuung, andere werden über Cluster-Formate (Advisory Boards) eingebunden. auswirkung_auf: - dokument: "shm_stakeholder-portfolio.yaml" abschnitt: "Priorisierung / Betreuungsmodus" - dokument: "shm_engagement-framework.yaml" abschnitt: "Betreuungskonzepte (noch zu entwickeln)" status: final # --------------------------------------------------------------------------- - id: GOV-SHM-011 datum: 2025-12-03 quelle_modul: "Stakeholder-Portfolio / Priorisierung" frage: | Gibt es eine Obergrenze für die Anzahl Key-Stakeholder? entscheidung: | Nein. Im ersten Schritt wird ohne Cap modelliert. begruendung: | - Die Kombinationslogik führt organisch zu einer begrenzten Anzahl - Ein künstliches Cap könnte relevante Stakeholder ausschließen - Nach empirischer Validierung kann ggf. nachjustiert werden auswirkung_auf: - dokument: "shm_stakeholder-portfolio.yaml" abschnitt: "Priorisierung" status: final offene_fragen: - "Nach empirischer Validierung prüfen, ob Anzahl Key-Stakeholder handhabbar ist" # --------------------------------------------------------------------------- - id: GOV-SHM-012 datum: 2025-12-03 quelle_modul: "Stakeholder-Portfolio / Priorisierung" frage: | Wie oft wird die Priorisierung überprüft? entscheidung: | Die Priorisierung wird periodisch im Rahmen der Koordinations- und Steuerungsstruktur überprüft (E2-Standard und E2-Erweitert Review-Zyklen). Insbesondere die Dimension "Relevanz" kann sich ändern (politische Themen kommen und gehen) und erfordert regelmäßige Aktualisierung. begruendung: | - Einfluss und Abhängigkeit sind relativ stabil - Relevanz ist dynamisch (politische Themen, strategische Projekte) - Integration in bestehenden Review-Prozess vermeidet Zusatzaufwand auswirkung_auf: - dokument: "shm_portfolio-review.yaml" abschnitt: "Review-Aktivitäten (noch zu entwickeln)" status: final # --------------------------------------------------------------------------- # AMTS-STECKBRIEF # --------------------------------------------------------------------------- - id: GOV-SHM-013 datum: 2025-12-03 quelle_modul: "Stakeholder-Portfolio / Amts-Steckbrief" frage: | Wer ist der primäre Ansprechpartner für SLA-Befugnis? entscheidung: | Analog zur SPM-Logik (P-02 SLM): - Primär: Amtsleitung - Alternativ: Delegierte Person mit dokumentierter Entscheidungsbefugnis Die Delegation muss dokumentiert sein. begruendung: | Konsistenz mit SPM-Governance. SLA-Partner müssen Entscheidungsbefugnis haben, nicht nur operative Ansprechpartner sein. auswirkung_auf: - dokument: "shm_stakeholder-portfolio.yaml" abschnitt: "Amts-Steckbrief / Stammdaten" referenz: - dokument: "spm_practice_service-level-management.yaml" entscheidung: "GOV-005" status: final # --------------------------------------------------------------------------- - id: GOV-SHM-014 datum: 2025-12-03 quelle_modul: "Stakeholder-Portfolio / Amts-Steckbrief" frage: | Welche Organisationseinheiten sind im Scope des Stakeholder-Portfolios? entscheidung: | Alle Einheiten im Dezernatsverteilungsplan: - Ämter - Eigenbetriebe - Referate - Stabsstellen - Projektgruppen begruendung: | Breiter Scope sichert vollständige Abdeckung. Die Segmentierung (insbesondere "Sondereinheit") ermöglicht differenzierte Behandlung. auswirkung_auf: - dokument: "shm_stakeholder-portfolio.yaml" abschnitt: "Scope" status: final # --------------------------------------------------------------------------- - id: GOV-SHM-015 datum: 2025-12-09 quelle_modul: "SHM Engagement-Framework (Phase 2)" frage: | Sollen die SHM-Advisory-Boards und die SLM-Kundenvertretungen als separate Gremien geführt werden? entscheidung: | Nein. Die Formate werden zu einem integrierten "Kundenforum"-Konzept konsolidiert: 1. Kundenforum Basisservices (für Kat. A): - Vereint SLA-Review (SLM) und Beziehungspflege/Bedarfssammlung (SHM) - Frequenz: Jährlich (Pilotierungs-Vorbehalt) - Gemeinsame Moderation: Service Owner + Stakeholder-Manager - Zusammensetzung: Pflichtvertreter (Querschnittsämter) + Rotation 2. Kundenforum [Service] (für Kat. B): - Primär SLA-Review, SHM-Beteiligung optional - Frequenz: Jährlich - Leitung: Service Owner 3. Bilaterale Formate (für Kat. C und Key-Stakeholder): - Kombination aus SLA-Themen und strategischen Themen - SO und SHM nach Bedarf gemeinsam oder getrennt begruendung: | - Vermeidung von Gremien-Redundanz (gleiche Teilnehmer, ähnliche Themen) - Ressourceneffizienz (weniger Termine für Ämter und DIGIT) - Stärkung der "One DIGIT"-Wahrnehmung - Natürliche Integration von Service-Qualität und Beziehungsqualität auswirkung_auf: - dokument: "shm_engagement-framework.yaml" abschnitt: "kollektive_formate" - dokument: "spm_practice_service-level-management.yaml" abschnitt: "kundenvertretung, slm_09" status: "final" offene_punkte: - "Konkrete Besetzung Pflichtvertreter (Abstimmung mit Verwaltung)" - "Frequenz-Validierung in Pilotierung" # --------------------------------------------------------------------------- - id: GOV-SHM-016 datum: 2025-12-09 quelle_modul: "Bedarfsbewertung (Phase 3)" frage: | Beeinflusst die Stakeholder-Priorität das Routing? entscheidung: | Nein. Das Routing basiert ausschließlich auf der Sachfrage "Was ist der Bedarf?". Die Stakeholder-Priorität beeinflusst die Bearbeitungsgeschwindigkeit, nicht das Ziel. begruendung: | Routing muss sachlogisch nachvollziehbar sein. Ein Demand bleibt ein Demand, unabhängig davon, wer ihn einreicht. auswirkung_auf: - dokument: "shm_bedarfsbewertung.yaml" abschnitt: "stakeholder_kontext" status: final # --------------------------------------------------------------------------- - id: GOV-SHM-017 datum: 2025-12-09 quelle_modul: "Bedarfsbewertung (Phase 3)" frage: | Welche Kriterien triggern eine Routing-Klärung? entscheidung: | Die Unsicherheit des Stakeholder-Managers reicht als Kriterium. Es gibt keine quantitativen Schwellenwerte. begruendung: | Objektivierte Kriterien würden zu Schein-Objektivität führen. Der Stakeholder-Manager ist qualifiziert, Unsicherheit zu erkennen und angemessen zu eskalieren. auswirkung_auf: - dokument: "shm_bedarfsbewertung.yaml" abschnitt: "dsr_routing_klaerung" status: final nachtrag: datum: "2025-12-17" aenderung: | Demand-Routing erfolgt direkt an DPM (nicht über DSR). Siehe GOV-SOR-001: Demand-Routing geht direkt an DPM. DSR nur für Portfolio-Governance. referenz: "GOV-SOR-001" # --------------------------------------------------------------------------- - id: GOV-SHM-018 datum: 2025-12-09 quelle_modul: "Bedarfsbewertung (Phase 3)" frage: | Prüft SHM die Service-Kategorie (A/B/C) bei der Bewertung? entscheidung: | Nein. Die Service-Kategorie ist informativ (aus Amts-Steckbrief), aber nicht entscheidungsrelevant für das Routing. begruendung: | Die konkrete Service-Kategorie-Zuordnung ist Aufgabe von SPM/SO. SHM prüft nur: "Ist der Bedarf katalog-abbildbar?" auswirkung_auf: - dokument: "shm_bedarfsbewertung.yaml" abschnitt: "abgrenzung" status: final # --------------------------------------------------------------------------- - id: GOV-SHM-019 datum: 2025-12-09 quelle_modul: "Bedarfsbewertung (Phase 3)" frage: | Ist eine Aufwandsschätzung routing-relevant? entscheidung: | Nein. Die Aufwandsschätzung im Bedarfssteckbrief ist informativ für den Empfänger, aber nicht entscheidungsrelevant für das Routing. begruendung: | Die Frage "Was ist es?" ist unabhängig von "Wie groß ist es?". Ein kleiner Demand bleibt ein Demand. auswirkung_auf: - dokument: "shm_bedarfsbewertung.yaml" abschnitt: "funktionale_herleitung" status: final # --------------------------------------------------------------------------- - id: GOV-SHM-020 datum: 2025-12-09 quelle_modul: "Bedarfsbewertung (Phase 3) / Bedarfssteckbrief-Schema" frage: | Welche Pflichtfelder gelten für welchen Routing-Pfad? entscheidung: | Die Validierungsanforderungen im Bedarfssteckbrief variieren je nach Routing-Ziel: 1. ROUTE-REQ: Kein Steckbrief erforderlich 2. ROUTE-SPM: Reduzierter Steckbrief (Basisdaten, Bedarfsbeschreibung, Service-Katalog-Prüfung). Keine Stakeholder-Freigabe erforderlich. 3. ROUTE-DPM: Demand geht direkt an DPM. Reduzierter Steckbrief + SHM-Einschätzung. Keine DSR-Bestätigung für Demands nötig. 4. ROUTE-DPM: Vollständiger Steckbrief inkl. User Stories, Abhängigkeiten, Größeneinschätzung. Stakeholder-Freigabe erforderlich (Quality Gate 1). Die Validierungsregel VAL-BED-004 wird entsprechend präzisiert. begruendung: | Nicht jeder Routing-Pfad erfordert den gleichen Dokumentationsaufwand. SPM-Changes können mit reduziertem Steckbrief erfolgen. Nur DPM-Übergaben erfordern die formale Stakeholder-Freigabe, da hier das Quality Gate 1 des Demand-to-Product-Prozesses greift. auswirkung_auf: - dokument: "shm_schema_bedarfssteckbrief.yaml" abschnitt: "validierungsprofile, validierung.regeln.VAL-BED-004" - dokument: "shm_bedarfsbewertung.yaml" abschnitt: "routing_pfade" status: final nachtrag: datum: "2025-12-17" aenderung: | ROUTE-DSR wurde zu ROUTE-DPM geändert (Demand direkt an DPM). Demand-Routing erfolgt direkt an DPM. DSR nur Portfolio-Governance. referenz: "GOV-SOR-001" # --------------------------------------------------------------------------- - id: GOV-SHM-021 datum: 2025-12-09 quelle_modul: "D2P-Integration (Phase 4)" frage: | Hat SHM Einwand-Recht beim Demand-Routing? entscheidung: | SHM bringt Perspektive bilateral ein. DPM nimmt Demands direkt entgegen. Dies ergibt sich bereits aus der bestehenden DSR-Geschäftsordnung. begruendung: | SHM vertritt die Stakeholder-Perspektive ("Kundenanwalt"). Ein Demand, der gegen fundamentale Stakeholder-Interessen verstößt, sollte nicht ohne SHM-Zustimmung freigegeben werden. Die DSR-GO regelt bereits: - SHM ist stimmberechtigtes Mitglied (Abschnitt 3.1) - Konsent-Prinzip gilt für alle Mitglieder (Abschnitt 5.1) - Bei Einwand muss einwendende Rolle Alternative einbringen Ein separater Patch ist nicht erforderlich – diese Governance- Entscheidung dokumentiert die Interpretation der bestehenden Regelung. auswirkung_auf: - dokument: "shm_d2p-integration.yaml" abschnitt: "shm_rolle_dsr.einwand_recht" typ: "Klarstellung" status: final # --------------------------------------------------------------------------- - id: GOV-SHM-022 datum: 2025-12-09 quelle_modul: "D2P-Integration (Phase 4)" frage: | Welche Rolle hat SHM bei Demand-Ablehnung durch DSR/MB? entscheidung: | Differenziert nach Stakeholder-Priorität: - Key-Stakeholder & Aktiv: Vermittlungsfunktion - Standard & Basis: Kommunikationsfunktion begruendung: | Ressourcenallokation entsprechend Betreuungsmodus. Bei Key/Aktiv besteht höheres Risiko für Beziehungsschäden, daher intensivere Begleitung. auswirkung_auf: - dokument: "shm_d2p-integration.yaml" abschnitt: "shm_rolle_bei_ablehnung" status: final # =========================================================================== # PHASE 5: KOORDINATIONS- UND STEUERUNGSSTRUKTUR # =========================================================================== - id: "GOV-SHM-023" datum: "2025-12-10" quelle_modul: "Koordinations- und Steuerungsstruktur (Phase 5)" urspruengliche_id: "GOV-KSS-001" frage: | Soll die SHM-Steuerung auf Prozess-Indikatoren (Aktivitäten) oder Ergebnis-Indikatoren (Wirkung) fokussieren? optionen: - option: "A" beschreibung: "Fokus auf Prozess-Indikatoren" beispiele: - "Anzahl durchgeführter Turnus-Gespräche" - "Anzahl Routing-Entscheidungen" - "Durchlaufzeit Bedarfssteckbrief" - option: "B" beschreibung: "Fokus auf Ergebnis-Indikatoren" beispiele: - "Beziehungsqualität im Portfolio" - "VoC-Cluster-Status" - "Stakeholder-Wahrnehmung" - option: "C" beschreibung: "Beides gleichwertig" entscheidung: "Option B – Fokus auf Ergebnis-Indikatoren" begruendung: | SHM ist eine beziehungsorientierte Funktion. Der Erfolg bemisst sich nicht daran, wie viele Gespräche geführt wurden, sondern ob die Stakeholder-Beziehungen gut sind und die Bedarfe erkannt werden. Prozess-Indikatoren können als operative Selbstvergewisserung dienen, sind aber nicht Gegenstand des formalen Reviews. Diese Entscheidung ist konsistent mit PRIN-03 ("Lernen vor Messen") und dem Verwaltungskontext, in dem qualitative Einschätzungen anschlussfähiger sind als quantifizierte Aktivitäts-KPIs. konsequenzen: - "Primäre Indikatoren: Beziehungsqualität, VoC-Cluster-Ampeln, Highlights" - "Sekundäre Indikatoren (nicht berichtet): Gesprächsquoten, Routing-Statistik" - "Review-Templates enthalten narrative Einschätzungen, keine Prozess-Metriken-Tabellen" auswirkung_auf: - dokument: "shm_koordinations-und-steuerungsstruktur.yaml" abschnitt: "review_formate" status: "final" - id: "GOV-SHM-024" datum: "2025-12-10" quelle_modul: "Koordinations- und Steuerungsstruktur (Phase 5)" urspruengliche_id: "GOV-KSS-002" frage: | Wie grenzen sich SHM-Reporting und SPM-Reporting voneinander ab, um Redundanz und Widersprüche zu vermeiden? kontext: | Beide Funktionen berichten über Aspekte der Kundenbeziehung: - SPM/SLM: Service-Qualität, SLA-Erfüllung, Kundenzufriedenheit mit Services - SHM: Beziehungsqualität, Bedarfserfüllung, strategische Passung entscheidung: | Klare Verantwortungstrennung nach Gegenstand: SHM verantwortet: - Beziehungsqualität (D1) - Bedarfserfüllung (D3) - Strategische Passung (D4) - Aggregierte Stakeholder-Sicht (Portfolio-Perspektive) SPM verantwortet: - Service-Qualität (D2) - SLA-Erfüllung - Einzelne Service-Performance (Service-Perspektive) Gemeinsame Verantwortung: - Kundenforum (integriertes Format) - Eskalationen, die beide Bereiche betreffen begruendung: | Die Trennung folgt der funktionalen Logik: SHM betreut Stakeholder, SPM betreut Services. Die Stakeholder-Zufriedenheit mit Services (D2) ist für SHM Kontext-Information, aber nicht Berichtsgegenstand. Diese Trennung vermeidet Doppel-Reporting, widersprüchliche Bewertungen und unklare Verantwortlichkeiten. konsequenzen: - "SHM-Review enthält keine SLA-Metriken" - "SPM-Review enthält keine Beziehungsbewertung" - "VoC-Dimension D2 wird als Kontext erfasst und an SPM weitergeleitet" - "Integriertes Reporting für Mission Board nur bei Bedarf (anlassbezogen)" schnittstellenregelung: - schnittstelle: "VoC-Feedback zu D2" von: "SHM" an: "SPM / Service Owner" - schnittstelle: "Service-Performance-Daten" von: "SPM" an: "SHM (Leserecht)" - schnittstelle: "Kundenforum" verantwortung: "Gemeinsam SHM + SPM" auswirkung_auf: - dokument: "shm_koordinations-und-steuerungsstruktur.yaml" abschnitt: "review_formate, voc_dimensionen" - dokument: "spm_practice_service-level-management.yaml" abschnitt: "slm_09" status: "final" # =========================================================================== # PHASE 6: ROLLENBESCHREIBUNGEN # =========================================================================== - id: "GOV-SHM-025" datum: "2025-12-10" quelle_modul: "Rollenbeschreibungen (Phase 6)" frage: | Ist die Leitung SHM Mitglied im Mission Board? optionen: - option: "A" beschreibung: "Nein – SHM bringt sich nur über DSR ein" - option: "B" beschreibung: "Ja – Leitung SHM ist vollwertiges MB-Mitglied" - option: "C" beschreibung: "Teilweise – Beobachterstatus ohne Stimmrecht" entscheidung: "Option B – Leitung SHM ist vollwertiges MB-Mitglied" begruendung: | Die Stakeholder-Perspektive muss auf strategisch-taktischer Ebene direkt vertreten sein. Während die operative DSR-Arbeit bei den Stakeholder-Manager:innen liegt, braucht das MB eine Person, die: - den Gesamt-Überblick über das Stakeholder-Portfolio hat - strategische Stakeholder-Themen einbringen kann - Entscheidungsauswirkungen auf Stakeholder bewerten kann Dies differenziert die Aussage aus GOV-SHM-022 / Phase 4: "SHM ist kein ständiges MB-Mitglied" bezog sich auf die operative Rolle (Stakeholder-Manager:in), nicht auf die Leitungsrolle. Die Entscheidung reflektiert die organisatorische Realität: Die Leitung SHM ist Abteilungsleitung und damit auf der gleichen Hierarchieebene wie andere MB-Mitglieder (z.B. AL Planung für DPM). konsequenzen: - "Leitung SHM nimmt regelmäßig an MB-Sitzungen teil" - "Stakeholder-Manager:in bringt sich weiterhin über DSR ein" - "shm_d2p-integration.yaml Abschnitt MB-Rolle wird präzisiert" auswirkung_auf: - dokument: "shm_rollen.yaml" abschnitt: "leitung_shm.gremienrollen" - dokument: "shm_d2p-integration.yaml" abschnitt: "shm_rolle_mission_board" aenderung: "Präzisierung: Differenzierung nach Rolle" status: "final" # --------------------------------------------------------------------------- - id: "GOV-SHM-026" datum: "2025-12-17" quelle_modul: "SOR-Geschäftsordnung / SHM-Patch" frage: | Wie erfolgt Demand-Routing? entscheidung: | Demands gehen direkt an DPM. Changes werden in der SOR bestätigt. Der bisherige Routing-Pfad "ROUTE-SOR" wird zu "ROUTE-DSR" geändert. Betroffene Dokumente wurden entsprechend gepatcht (siehe PATCH-SOR-001, PATCH-SOR-002 in spm_sor-geschaeftsordnung.yaml). begruendung: | In der DSR sind alle relevanten Perspektiven vertreten (SHM, DPM, SPM). Die Routing-Frage "Ist das ein Service-Change oder ein Demand?" ist ihrem Wesen nach eine Demand-Einordnungsfrage und gehört daher in die DSR. Die SOR konzentriert sich auf Service-Portfolio-Governance (Go-Live, Review, Major Changes). auswirkung_auf: - dokument: "shm_governance-framework.yaml" aenderung: "ROUTE-SOR → ROUTE-DSR, sor_eskalation → dsr_routing_klaerung" - dokument: "shm_bedarfsbewertung.yaml" aenderung: "ROUTE-SOR → ROUTE-DSR in routing_pfade und prozessablauf" - dokument: "shm_schema_bedarfssteckbrief.yaml" aenderung: "Validierungsprofil ROUTE-SOR → ROUTE-DSR" - dokument: "shm_raci.yaml" aenderung: "Aktivitäten GA-05, GA-06, BR-05, BR-06 angepasst" - dokument: "demand-lifecycle-blueprint_phase-1.yaml" aenderung: "routing_optionen ROUTE-SOR → ROUTE-DSR" querverweise: - "GOV-SOR-001 (SOR-Geschäftsordnung)" - "GOV-SHM-017 (Routing-Klärungskriterium - Nachtrag)" - "GOV-SHM-020 (Validierungsprofile - Nachtrag)" status: "final" # --------------------------------------------------------------------------- - id: "GOV-SHM-027" datum: "2026-01-23" quelle_modul: "Stakeholder-Portfolio / Funktionszuordnung" frage: | Wie wird bei Ämtern mit hybriden Funktionscharakteristika die Funktionszuordnung vorgenommen? kontext: | Manche Ämter (z.B. Stadtkämmerei) weisen Charakteristika mehrerer Funktionskategorien auf. Die bisherige Zuordnungslogik sah nur eine Primärfunktion vor, ohne Verfahren für Hybridfälle. entscheidung: | Einführung einer Primär-/Sekundärfunktionslogik: 1. Primärfunktion (steuernd): - Wird durch Entscheidungsbaum bestimmt (Dominanzprinzip) - Bestimmt Bedarfsrouting und Governance-Zuordnung - Pflichtfeld im Amts-Steckbrief 2. Sekundärfunktion (informierend): - Optionale zweite Funktionscharakteristik - Dokumentiert Kontext für differenzierte Betrachtung - Begründungspflicht bei Vergabe Steuerungsprinzip: "Primärfunktion steuert, Sekundärfunktion informiert." begruendung: | - Kundenwunsch: Transparenz über hybride Funktionscharakteristika - Praktischer Nutzen bei Bedarfsrouting (Bedarfe können eher zur Sekundärfunktion passen) - Governance-Relevanz (optionale Einbindung in Gremien der Sekundärkategorie) - Keine Verkomplizierung der Steuerungslogik (Primärfunktion bleibt maßgeblich) konsequenzen: - "Neues Attribut 'sekundaerfunktion' im Amts-Steckbrief-Schema" - "Erweiterter Entscheidungsbaum mit Entscheidungshilfe bei Mehrdeutigkeit" - "Dokumentationspflicht bei Sekundärfunktionsvergabe" - "Neue Validierungsregeln (VAL-007, VAL-008)" auswirkung_auf: - dokument: "shm_stakeholder-portfolio.yaml" abschnitt: "dimension_1_funktion.zuordnungslogik" aenderung: "Erweiterung um Primär-/Sekundärlogik" - dokument: "shm_schema_amtssteckbrief.yaml" abschnitt: "segmentierung.attribute" aenderung: "Neues Attribut sekundaerfunktion, Umbenennung funktion" status: "final" # --------------------------------------------------------------------------- - id: "GOV-SHM-028" datum: "2026-01-23" quelle_modul: "Stakeholder-Portfolio / Betreuungsstatus" frage: | Wie wird dokumentiert, ob eine Zusammenarbeit mit einem Amt überhaupt möglich ist – unabhängig von dessen Wichtigkeit? kontext: | Die Priorisierungsdimensionen (Einfluss, Abhängigkeit, Relevanz) beantworten die Frage "Wie wichtig ist das Amt?", nicht aber "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. entscheidung: | Einführung eines neuen Attributs "Betreuungsstatus" in den Stammdaten (nicht in der Priorisierung): 1. Drei Ausprägungen: - AKTIV: Zusammenarbeit möglich, normale Priorisierung greift - EINGESCHRÄNKT: Zusammenarbeit nur punktuell möglich - RUHEND: Aktuell keine Zusammenarbeit möglich 2. Begründungspflicht bei EINGESCHRÄNKT und RUHEND (min. 30 Zeichen) 3. Deckelungslogik bei EINGESCHRÄNKT: - Individueller maximaler Betreuungsmodus wird festgelegt - Effektiver Modus = MIN(aus Prio-Stufe, max. Betreuungsmodus) 4. Bei RUHEND: - Automatisch "Keine aktive Betreuung" - Priorisierung wird trotzdem erfasst (für Reaktivierung) 5. Entscheidungsbefugnis: Leitung SHM 6. Review: Im Portfolio-Review (E2-Standard/Erweitert) wird geprüft, ob Status noch aktuell ist begruendung: | - Priorisierung bleibt sauber (nur Wichtigkeit, nicht Machbarkeit) - Vollständigkeit des Portfolios bleibt erhalten - Transparente Dokumentation der Zusammenarbeitssituation - Flexibilität bei Statusänderungen (einfache Umstellung) - Reporting kann nach Status filtern ("aktiv betreute Ämter" vs. "Gesamtportfolio") - Individuelle Deckelung statt mechanischer Reduktion, da Einschränkungsgründe sehr unterschiedlich sein können ableitungslogik: | Effektiver Betreuungsmodus: WENN status == "RUHEND": effektiver_modus = "KEINE_AKTIVE_BETREUUNG" WENN status == "EINGESCHRAENKT": abgeleiteter_modus = aus_prio_stufe(prio_stufe) effektiver_modus = MIN(abgeleiteter_modus, max_betreuungsmodus) WENN status == "AKTIV": effektiver_modus = aus_prio_stufe(prio_stufe) konsequenzen: - "Neues Attribut 'betreuungsstatus' im Amts-Steckbrief-Schema (Stammdaten)" - "Neues abgeleitetes Attribut 'effektiver_betreuungsmodus'" - "Neue Validierungsregeln VAL-009, VAL-010, VAL-011" - "Erweiterung des Betreuungsmodus-Enums um 'KEINE_AKTIVE_BETREUUNG'" auswirkung_auf: - dokument: "shm_schema_amtssteckbrief.yaml" abschnitt: "stammdaten.attribute" aenderung: "Neues Attribut betreuungsstatus" - dokument: "shm_schema_amtssteckbrief.yaml" abschnitt: "priorisierung.attribute" aenderung: "Neues abgeleitetes Attribut effektiver_betreuungsmodus" - dokument: "shm_stakeholder-portfolio.yaml" abschnitt: "ebene_1_amtssteckbrief" aenderung: "Erläuterung des Betreuungsstatus-Konzepts" status: "final" # --------------------------------------------------------------------------- - id: "GOV-SHM-029" datum: "2026-03-04" quelle_modul: "SHM-Bedarfsbewertung / Bedarfsrouting" frage: | Wie wird ein Bedarf geroutet, wenn SHM nach der Bedarfsbewertung unsicher ist, ob es sich um einen bestehenden Service (RUN/Change) oder einen neuen Demand handelt? Wer trifft die Routing-Entscheidung? kontext: | Bisherige Regelung (GOV-SHM-026): Unklare Bedarfe wurden über ROUTE-DSR an das DSR-Gremium (DPM, SHM, SPM, PPM) weitergeleitet. Dort wurde kollektiv entschieden, ob ein Bedarf als RUN/Change oder Demand einzustufen ist. Workshop-Ergebnis vom 04.03.2026: Die bilaterale Klärung mit dem Service Owner ist schneller, fachlich näher am Thema und entlastet das DSR-Gremium von operativen Routing-Klärungen. Drei Varianten wurden im Vorfeld evaluiert: - Variante A: DSR-First (bisherige Regelung) - Variante B: SOR-First (ursprünglicher Blueprint) - Variante C: Hybrid mit Service-Owner als Entscheidungsträger Die Workshop-Entscheidung entspricht Variante C mit dem Service Owner als zentralem Entscheidungsträger. entscheidung: | Ablösung von ROUTE-DSR durch ROUTE-SO (Service-Owner-Klärung): 1. Neuer Routing-Pfad ROUTE-SO mit zwei Pfaden: Pfad A — Service Owner identifizierbar: SHM prüft Service-Portfolio → SO identifiziert → SHM kontaktiert SO bilateral → SO gibt Routing-Empfehlung ab: - RUN/Change → formelle Bestätigung durch SOR (Vorsitz SPM) - Demand → formelle Bestätigung durch DSR (Vorsitz DPM) Pfad B — Kein Service Owner identifizierbar: SHM kontaktiert SPM → SPM hilft bei Service-Identifikation → SO wird einbezogen → SO gibt Routing-Empfehlung ab (wie Pfad A) Fallback: Kein Service identifizierbar → automatisch Demand → DPM 2. Neuer Status "in_so_klaerung" ersetzt "bereit_fuer_dsr" 3. Eskalation: - Stufe 1: Leitung SHM / SPM bei Uneinigkeit - Stufe 2: Mission Board bei DPM-Ablehnung 4. DSR behält Governance-Rolle (Portfolio-Steuerung, Priorisierung), verliert aber die operative Routing-Klärungsfunktion 5. GOV-SOR-001 wird angepasst: SOR bestätigt formal RUN/Change-Routing-Empfehlungen des Service Owners (nicht mehr DSR-Routing-Klärungen) begruendung: | - Schnellere Klärung durch bilateralen Prozess statt Gremium - Service Owner hat fachliche Nähe und Entscheidungskompetenz - DSR-Gremium wird von operativen Einzelfall-Klärungen entlastet - SPM als Fallback gewährleistet Vollständigkeit der Portfolio-Abdeckung - Klare Eskalationskette bis zum Mission Board - Konsistent mit ITIL4-Prinzip der dezentralen Entscheidungsfindung - Workshop-Konsens aller Beteiligten (SHM, SPM, DPM) konsequenzen: - "ROUTE-DSR wird durch ROUTE-SO ersetzt (alle Routing-Pfade)" - "Neuer Status 'in_so_klaerung' im Bedarfssteckbrief-Schema" - "Service Owner gibt Routing-Empfehlung ab (keine endgültige Entscheidung)" - "Formelle Bestätigung durch Gremien: SOR (Vorsitz SPM) für Changes, DSR (Vorsitz DPM) für Demands" - "Weiterbearbeitung erfolgt 'als ob' bereits entschieden, während auf formelle Bestätigung im nächsten Takt gewartet wird" - "DSR-Rolle reduziert auf Portfolio-Governance (keine Einzelfall-Klärungen)" - "GOV-SOR-001 inhaltlich angepasst (SOR empfängt SO-Empfehlungen zur formellen Bestätigung)" - "Anpassung in 13 YAML-Dateien über SHM, SPM, DPM" auswirkung_auf: - dokument: "shm_bedarfsbewertung.yaml" abschnitt: "routing_pfade, entscheidungsbaum, so_routing_klaerung" aenderung: "Komplett-Überarbeitung: ROUTE-DSR → ROUTE-SO mit Pfad A/B" - dokument: "shm_governance-framework.yaml" abschnitt: "routing_pfade, eskalation" aenderung: "ROUTE-DSR → ROUTE-SO, Eskalationspfade aktualisiert" - dokument: "shm_raci.yaml" abschnitt: "bedarfsrouting-aktivitaeten" aenderung: "SO als Accountable für Routing-Entscheidung, DSR-Rolle reduziert" - dokument: "shm_schema_bedarfssteckbrief.yaml" abschnitt: "status_enum, validierung" aenderung: "bereit_fuer_dsr → in_so_klaerung" - dokument: "demand-lifecycle-blueprint_phase-1.yaml" abschnitt: "phase_1_schritt_1_7" aenderung: "ROUTE-DSR Routing-Option → ROUTE-SO" - dokument: "spm_sor_go.yaml" abschnitt: "GOV-SOR-001, aufgaben" aenderung: "SOR empfängt SO-Entscheidungen statt DSR-Routing-Klärungen" - dokument: "spm_governance_framework.yaml" abschnitt: "GOV-SOR-001 Referenz" aenderung: "Beschreibungstext aktualisiert" - dokument: "rolle_service-portfolio-manager.yaml" abschnitt: "routing-klaerung, dsr-beteiligung" aenderung: "Referenzen auf SO-basiertes Routing aktualisiert" - dokument: "spm_funktionsbeschreibung.yaml" abschnitt: "dsr_gremium Governance" aenderung: "Referenz auf GOV-SOR-001 aktualisiert" - dokument: "spm_practice_change-enablement.yaml" abschnitt: "bei_dissens" aenderung: "Referenz auf GOV-SOR-001 aktualisiert" - dokument: "shm_interne-bedarfe-routing.yaml" abschnitt: "routing-optionen" aenderung: "ROUTE-DSR → ROUTE-SO" - dokument: "spec_shm-dokumentation.yaml" abschnitt: "routing-referenzen" aenderung: "ROUTE-DSR → ROUTE-SO" status: "final" # ============================================================================= # OFFENE PUNKTE # ============================================================================= offene_punkte: - id: "OPEN-GOV-001" thema: "SPM-Terminologie-Umsetzung" beschreibung: | Die Entscheidung GOV-SHM-005 (Modular → Erweitert) muss im SPM umgesetzt und als Governance-Entscheidung dort dokumentiert werden. prioritaet: "mittel" status: "erledigt" erledigt_am: "2025-12-03" - id: "OPEN-GOV-002" thema: "Empirische Validierung" beschreibung: | Die Segmentierungs- und Priorisierungslogik muss gegen den vollständigen Dezernatsverteilungsplan validiert werden. prioritaet: "hoch" status: "erledigt" erledigt_am: "2025-12-03" anmerkung: "Validierung durchgeführt (verprobt)" - id: "OPEN-GOV-003" thema: "ITIL4-Referenz dokumentieren" beschreibung: | Abgleich des Portfolio-Konzepts mit ITIL4 Relationship Management Practice sollte dokumentiert werden. prioritaet: "niedrig" status: "gestrichen" begruendung: "Nicht erforderlich für MVP" # ============================================================================= # ÄNDERUNGSHISTORIE # ============================================================================= aenderungshistorie: - version: "0.1" datum: "2025-12-03" autor: "Chat-Session SHM-Konzeptentwicklung" aenderung: "Initiale Erstellung mit 14 Governance-Entscheidungen" - version: "1.0" datum: "2025-12-03" autor: "DIGITOM-Projekt" aenderung: "Phase 1 abgeschlossen, offene Punkte aktualisiert, Status auf Final" - version: "1.1" datum: "2025-12-09" autor: "DIGITOM-Projekt" aenderung: "Phase 3 (Bedarfsbewertung) Governance-Entscheidungen ergänzt (GOV-SHM-016 bis GOV-SHM-019)" - version: "1.2" datum: "2025-12-09" autor: "DIGITOM-Projekt" aenderung: "Phase 4 (D2P-Integration) Governance-Entscheidungen ergänzt (GOV-SHM-021, GOV-SHM-022)" - version: "1.3" datum: "2025-12-10" autor: "DIGITOM-Projekt" aenderung: "Phase 5 (Koordinations- und Steuerungsstruktur) Governance-Entscheidungen ergänzt (GOV-SHM-023, GOV-SHM-024)" - version: "1.4" datum: "2025-12-10" autor: "DIGITOM-Projekt" aenderung: "Phase 6 (Rollenbeschreibungen) Governance-Entscheidung ergänzt (GOV-SHM-025: MB-Mitgliedschaft Leitung SHM)" - version: "1.5" datum: "2025-12-10" autor: "DIGITOM-Projekt" aenderung: | Phase 7 (Governance-Framework + RACI) abgeschlossen: - shm_governance-framework.yaml erstellt (Konsolidierung GOV-SHM-001 bis GOV-SHM-025) - shm_raci.yaml erstellt (54 Aktivitäten in 6 Bereichen) - Governance-Prinzipien GP-SHM-01 bis GP-SHM-05 definiert - Entscheidungsmatrix mit 20 Entscheidungsgegenständen - Eskalationslogik mit 5 Pfaden dokumentiert - version: "1.6" datum: "2025-12-17" autor: "DIGITOM-Projekt" aenderung: | Patch ROUTE-SOR → ROUTE-DSR (GOV-SHM-026): - Routing-Klärungen werden nun in der DSR behandelt (nicht SOR) - Betroffene Dateien: shm_governance-framework.yaml, shm_bedarfsbewertung.yaml, shm_schema_bedarfssteckbrief.yaml, shm_raci.yaml, demand-lifecycle-blueprint_phase-1.yaml - Nachträge zu GOV-SHM-017 und GOV-SHM-020 hinzugefügt - Neue Governance-Entscheidung GOV-SHM-026 dokumentiert - Referenz: GOV-SOR-001 (SOR-Geschäftsordnung) - version: "1.7" datum: "2026-01-23" autor: "DIGITOM-Projekt" aenderung: | Primär-/Sekundärfunktionslogik (GOV-SHM-027): - Erweiterung der Funktionszuordnung für Ämter mit hybriden Charakteristika - Strukturierter Entscheidungsbaum für Primärfunktionsbestimmung - Verfahren zur Sekundärfunktionsbestimmung mit Vergabekriterien - Neues Attribut 'sekundaerfunktion' im Amts-Steckbrief-Schema - Neue Validierungsregeln VAL-007, VAL-008 - Steuerungsprinzip: "Primärfunktion steuert, Sekundärfunktion informiert" - version: "1.8" datum: "2026-01-23" autor: "DIGITOM-Projekt" aenderung: | Betreuungsstatus-Konzept (GOV-SHM-028): - Neues Attribut 'betreuungsstatus' in Stammdaten (nicht Priorisierung) - Drei Ausprägungen: AKTIV, EINGESCHRÄNKT, RUHEND - Begründungspflicht bei EINGESCHRÄNKT und RUHEND - Deckelungslogik für effektiven Betreuungsmodus bei EINGESCHRÄNKT - Neuer Betreuungsmodus 'KEINE_AKTIVE_BETREUUNG' für RUHEND - Entscheidungsbefugnis bei Leitung SHM - Review im Portfolio-Review (E2-Standard/Erweitert) - version: "1.9" datum: "2026-03-04" autor: "DIGITOM-Projekt" aenderung: | Bedarfsrouting SO-Klärung (GOV-SHM-029): - ROUTE-DSR durch ROUTE-SO (Service-Owner-Klärung) abgelöst - SO gibt Routing-Empfehlung ab (keine endgültige Entscheidung) - Bilaterale Klärung mit Service Owner, formelle Bestätigung durch SOR (Changes) bzw. DSR (Demands) - Pfad A (SO identifizierbar) und Pfad B (SPM hilft bei Identifikation) - Neuer Status 'in_so_klaerung' ersetzt 'bereit_fuer_dsr' - Weiterbearbeitung erfolgt 'als ob' bereits entschieden, Bestätigung im nächsten Takt - GOV-SOR-001 angepasst (SOR bestätigt formal SO-Routing-Empfehlungen) - Anpassungen in 13 YAML-Dateien über SHM, SPM, DPM - Workshop-Entscheidung vom 04.03.2026