1361 lines
50 KiB
YAML
1361 lines
50 KiB
YAML
# =============================================================================
|
||
# 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
|