1018 lines
No EOL
39 KiB
YAML
1018 lines
No EOL
39 KiB
YAML
# =============================================================================
|
||
# SHM D2P-INTEGRATION
|
||
# =============================================================================
|
||
# Modul: Stakeholder-Management (SHM)
|
||
# Typ: Schnittstelle
|
||
# Version: 1.2
|
||
# Datum: 2025-01-29
|
||
# Status: Entwurf
|
||
# Entwicklungsphase: 4
|
||
# Zielordner: #03_stakeholder-management/#03.5_schnittstellen/
|
||
# =============================================================================
|
||
|
||
meta:
|
||
modul_id: "SHM-S-01"
|
||
name: "D2P-Integration"
|
||
typ: "Schnittstelle"
|
||
|
||
zweck: |
|
||
Dieses Dokument formalisiert die Schnittstelle zwischen Stakeholder-Management
|
||
(SHM) und dem Demand-to-Project-Prozess (D2P). Es definiert:
|
||
|
||
1. Die Rolle von SHM im Demand-Lifecycle
|
||
2. Die Übergabeschnittstelle an DPM (Quality Gate 1)
|
||
3. Die SHM-Beteiligung in Entscheidungsgremien (DSR, MB)
|
||
4. Rückkopplungsschleifen und Eskalationspfade
|
||
|
||
kontext: |
|
||
SHM ist der Eintrittspunkt für Bedarfe ins DIGIT-System. Die Qualität der
|
||
SHM-Arbeit bestimmt maßgeblich die Effizienz des nachgelagerten D2P-Prozesses.
|
||
|
||
Diese Integration stellt sicher, dass:
|
||
- Bedarfe systematisch qualifiziert werden, bevor sie ins Portfolio gelangen
|
||
- Die Stakeholder-Perspektive in Entscheidungsprozessen vertreten ist
|
||
- Kommunikation mit Stakeholdern konsistent und beziehungswahrend erfolgt
|
||
|
||
referenzen:
|
||
dpm_dokumente:
|
||
- dokument: "Demand-Lifecycle-Blueprint Phase 1"
|
||
pfad: "#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-1.yaml"
|
||
beschreibung: "SHM als Akteur in Phase 1 definiert"
|
||
|
||
- dokument: "DSR-Geschäftsordnung"
|
||
pfad: "#01_demand-portfolio-management/#01.1_demand-portfolio-management_documentation/dpm_dsr-go.yaml"
|
||
beschreibung: "SHM als DSR-Mitglied"
|
||
|
||
- dokument: "Governance Rules Demand-Lifecycle"
|
||
pfad: "#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/governance_rules_demand-lifecycle-blueprint.md"
|
||
beschreibung: "Routing-Logik DSR vs. MB"
|
||
|
||
- dokument: "Glossar Demand-Lifecycle"
|
||
pfad: "#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/glossary_demand-lifecycle-blueprint.md"
|
||
beschreibung: "Begriffsdefinitionen"
|
||
|
||
shm_dokumente:
|
||
- dokument: "SHM Bedarfsbewertung"
|
||
pfad: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml"
|
||
beschreibung: "Routing-Logik und Entscheidungsbaum"
|
||
|
||
- dokument: "Bedarfssteckbrief-Schema"
|
||
pfad: "#03_stakeholder-management/#03.6_informationsmodell/shm_schema_bedarfssteckbrief.yaml"
|
||
beschreibung: "Datenstruktur und Validierungsprofile"
|
||
|
||
- dokument: "SHM Engagement-Framework"
|
||
pfad: "#03_stakeholder-management/#03.3_konzepte/shm_engagement-framework.yaml"
|
||
beschreibung: "Eskalationspfade, Betreuungsmodi"
|
||
|
||
- dokument: "SHM Stakeholder-Portfolio"
|
||
pfad: "#03_stakeholder-management/#03.3_konzepte/shm_stakeholder-portfolio.yaml"
|
||
beschreibung: "Priorisierung, Betreuungsallokation"
|
||
|
||
# =============================================================================
|
||
# SHM-PHASE IM DEMAND-LIFECYCLE
|
||
# =============================================================================
|
||
|
||
shm_phase_im_demand_lifecycle:
|
||
|
||
aequivalenz:
|
||
beschreibung: |
|
||
Die SHM-Bedarfsbewertung entspricht Phase 1 des DPM Demand-Lifecycle.
|
||
Die Terminologie unterscheidet sich, die Inhalte sind identisch.
|
||
|
||
mapping:
|
||
shm_bezeichnung: "Bedarfsbewertung"
|
||
dpm_bezeichnung: "Phase 1: Initiierung"
|
||
|
||
schritte:
|
||
- dpm_schritt: "1.1 Bedarfs-Triage"
|
||
shm_aktivitaet: "Eingangskanal-Verarbeitung"
|
||
beschreibung: "Erfassung und Ersteinschätzung eingehender Bedarfe"
|
||
|
||
- dpm_schritt: "1.2 Eingangsvalidierung"
|
||
shm_aktivitaet: "Triage"
|
||
beschreibung: "Prüfung auf Vollständigkeit und Zuständigkeit"
|
||
|
||
- dpm_schritt: "1.3 Triage & Qualifizierung"
|
||
shm_aktivitaet: "Prüfung 1: Service-Katalog-Check"
|
||
beschreibung: "Abgleich mit bestehendem Service-Katalog"
|
||
|
||
- dpm_schritt: "1.4 Bedarfserhebung"
|
||
shm_aktivitaet: "Schritt 0: Bedarfserhebung"
|
||
beschreibung: "Vertiefende Analyse des tatsächlichen Bedarfs"
|
||
|
||
- dpm_schritt: "1.5 Anforderungsdokumentation"
|
||
shm_aktivitaet: "Bedarfssteckbrief-Erstellung"
|
||
beschreibung: "Strukturierte Dokumentation"
|
||
|
||
- dpm_schritt: "1.6 User Story Erstellung"
|
||
shm_aktivitaet: "User-Story-Erhebung"
|
||
beschreibung: "Fachliche Perspektive in strukturierter Form"
|
||
|
||
- dpm_schritt: "1.7 Bedarfs-Routing (QG1)"
|
||
shm_aktivitaet: "Routing-Entscheidung"
|
||
beschreibung: "Zuweisung an korrekten Empfänger"
|
||
|
||
verantwortung:
|
||
prozess_owner: "SHM"
|
||
|
||
beschreibung: |
|
||
SHM ist verantwortlich für die gesamte Phase 1 des Demand-Lifecycle.
|
||
Das umfasst sowohl die operative Durchführung als auch die Qualitätssicherung
|
||
der Übergabe an nachgelagerte Funktionen.
|
||
|
||
kernaufgaben:
|
||
- "Bedarfe verstehen (nicht vorgeschlagene Lösungen übernehmen)"
|
||
- "Bedarfe qualifizieren (Request, Change, Demand, unklar)"
|
||
- "Bedarfe dokumentieren (Bedarfssteckbrief)"
|
||
- "Bedarfe routen (an korrekten Empfänger übergeben)"
|
||
|
||
# =============================================================================
|
||
# ÜBERGABESCHNITTSTELLE: SHM → DPM
|
||
# =============================================================================
|
||
|
||
uebergabeschnittstelle_shm_dpm:
|
||
|
||
quality_gate_1:
|
||
name: "Ready for Portfolio"
|
||
owner: "SHM"
|
||
|
||
beschreibung: |
|
||
Quality Gate 1 markiert den Übergang von der SHM-Bedarfsbewertung
|
||
zur DPM-Qualifizierung. SHM validiert die Übergabereife; DPM hat
|
||
das Recht, unvollständige Übergaben zurückzuweisen.
|
||
|
||
pruefkriterien:
|
||
- "Routing-Entscheidung ist getroffen (ROUTE-DPM)"
|
||
- "Bedarfssteckbrief entspricht Validierungsprofil ROUTE-DPM"
|
||
- "Stakeholder-Freigabe liegt vor"
|
||
- "User Stories sind dokumentiert"
|
||
|
||
ergebnis_optionen:
|
||
- ergebnis: "bestanden"
|
||
aktion: "Übergabe an DPM"
|
||
status: "an_dpm_uebergeben"
|
||
|
||
- ergebnis: "nicht_bestanden"
|
||
aktion: "Nachqualifizierung durch SHM"
|
||
status: "in_nachqualifizierung"
|
||
|
||
bedarfssteckbrief_anforderungen:
|
||
|
||
beschreibung: |
|
||
Für die Übergabe an DPM (ROUTE-DPM) gelten die vollständigen
|
||
Anforderungen des Bedarfssteckbrief-Schemas.
|
||
|
||
referenz: "shm_schema_bedarfssteckbrief.yaml#validierungsprofile#ROUTE-DPM"
|
||
|
||
pflichtabschnitte:
|
||
- abschnitt: "basisdaten"
|
||
vollstaendig: true
|
||
- abschnitt: "stakeholder_kontext"
|
||
vollstaendig: true
|
||
- abschnitt: "bedarfsbeschreibung"
|
||
vollstaendig: true
|
||
- abschnitt: "user_stories"
|
||
mindestens_eine: true
|
||
- abschnitt: "service_katalog_pruefung"
|
||
vollstaendig: true
|
||
- abschnitt: "rahmenbedingungen"
|
||
vollstaendig: true
|
||
- abschnitt: "abhaengigkeiten"
|
||
vollstaendig: true
|
||
- abschnitt: "groesseneinschaetzung"
|
||
vollstaendig: true
|
||
- abschnitt: "freigabe"
|
||
stakeholder_freigabe: true
|
||
|
||
qualitaetskriterien:
|
||
- "Problemverständnis: Kernproblem ist klar vom Symptom getrennt"
|
||
- "Stakeholder-Validierung: Steckbrief wurde mit Stakeholder besprochen"
|
||
- "User Stories: Mindestens eine User Story nach INVEST-Kriterien"
|
||
- "Vollständigkeit: Alle relevanten Abhängigkeiten identifiziert"
|
||
- "Konsistenz: Zielbild passt zu Problemstellung"
|
||
|
||
uebergabe_artefakte:
|
||
|
||
primaer:
|
||
- artefakt: "Bedarfssteckbrief"
|
||
format: "Strukturierte Daten (ITSM-Tool oder YAML)"
|
||
status: "an_dpm_uebergeben"
|
||
|
||
begleitend:
|
||
- artefakt: "Stakeholder-Kontext"
|
||
inhalt: "Priorität, IT-Anforderungsprofil, relevante Historie"
|
||
quelle: "Amts-Steckbrief"
|
||
|
||
- artefakt: "SHM-Einschätzung"
|
||
inhalt: "Routing-Begründung, Komplexitätshinweise, Risiken"
|
||
optional: false
|
||
|
||
# =============================================================================
|
||
# RÜCKKOPPLUNGSSCHLEIFE: DPM → SHM
|
||
# =============================================================================
|
||
|
||
rueckkopplungsschleife_dpm_shm:
|
||
|
||
quality_gate_2_rueckweisung:
|
||
name: "Rückweisung durch DPM"
|
||
|
||
beschreibung: |
|
||
DPM fungiert als zweites Quality Gate. Wenn bei der DPM-Klassifizierung
|
||
festgestellt wird, dass der Bedarfssteckbrief nicht den Anforderungen
|
||
entspricht oder die Routing-Entscheidung fehlerhaft war, kann DPM
|
||
den Bedarf an SHM zurückweisen.
|
||
|
||
trigger:
|
||
- trigger_id: "RUECK-01"
|
||
name: "Unvollständiger Steckbrief"
|
||
beschreibung: "Pflichtfelder fehlen oder sind unzureichend befüllt"
|
||
aktion: "Nachqualifizierung durch SHM"
|
||
|
||
- trigger_id: "RUECK-02"
|
||
name: "Routing-Korrektur"
|
||
beschreibung: "Bedarf ist kein Demand, sondern Change oder Request"
|
||
aktion: "SHM korrigiert Routing (ROUTE-SPM oder ROUTE-REQ)"
|
||
|
||
- trigger_id: "RUECK-03"
|
||
name: "Qualitätsmängel"
|
||
beschreibung: "User Stories unklar, Zielbild widersprüchlich"
|
||
aktion: "Nachqualifizierung durch SHM"
|
||
|
||
prozess:
|
||
- schritt: 1
|
||
akteur: "DPM"
|
||
aktion: "Dokumentiert Rückweisungsgrund im Ticketsystem"
|
||
|
||
- schritt: 2
|
||
akteur: "DPM"
|
||
aktion: "Informiert SHM über Rückweisung"
|
||
|
||
- schritt: 3
|
||
akteur: "SHM"
|
||
aktion: "Prüft Rückweisungsgrund und leitet Nachbearbeitung ein"
|
||
|
||
- schritt: 4
|
||
akteur: "SHM"
|
||
aktion: "Bei Routing-Korrektur: Leitet an korrekten Empfänger weiter"
|
||
|
||
- schritt: 5
|
||
akteur: "SHM"
|
||
aktion: "Bei Nachqualifizierung: Erneute Stakeholder-Abstimmung"
|
||
|
||
keine_pflicht_zur_nacharbeit: |
|
||
DPM hat das Recht, aber nicht die Pflicht, unvollständige Steckbriefe
|
||
nachzuarbeiten. Die Qualitätssicherung liegt bei SHM.
|
||
|
||
# =============================================================================
|
||
# SHM-ROLLE IN DER DSR
|
||
# =============================================================================
|
||
|
||
shm_rolle_dsr:
|
||
|
||
mitgliedschaft:
|
||
status: "Ständiges Mitglied"
|
||
referenz: "dpm_dsr-go.yaml#zusammensetzung"
|
||
|
||
beschreibung: |
|
||
SHM ist ständiges Mitglied der Demand & Stakeholder-Runde (DSR).
|
||
Die Bezeichnung "Stakeholder-Runde" reflektiert die zentrale Rolle
|
||
von SHM in diesem Gremium.
|
||
|
||
funktion:
|
||
|
||
primaer: "Vertretung der Stakeholder-Perspektive"
|
||
|
||
beschreibung: |
|
||
SHM agiert in der DSR als "Auftraggeber-Anwalt" – nicht als neutraler
|
||
Beobachter, sondern als aktiver Vertreter der Auftraggeber-Perspektive.
|
||
Dies entspricht dem Grundprinzip aus dem Engagement-Framework.
|
||
|
||
konkrete_aufgaben:
|
||
|
||
bei_demand_vorstellung:
|
||
- "Stakeholder-Kontext erläutern (Priorität, Historie, Beziehungsstatus)"
|
||
- "Fachliche Perspektive des Stakeholders vertreten"
|
||
- "Auf Risiken für Stakeholder-Beziehung hinweisen"
|
||
|
||
bei_entscheidungsfindung:
|
||
- "Einwände aus Stakeholder-Sicht einbringen"
|
||
- "Auswirkungen auf Stakeholder-Zufriedenheit bewerten"
|
||
- "Kommunikationsbedarfe identifizieren"
|
||
|
||
bei_ablehnung_oder_vertagung:
|
||
- "Kommunikationsstrategie mit DSR abstimmen"
|
||
- "Stakeholder-Reaktion antizipieren"
|
||
- "Vermittlungsoptionen prüfen (bei Key/Aktiv-Stakeholdern)"
|
||
|
||
einwand_recht:
|
||
|
||
status: "Volles Einwand-Recht"
|
||
|
||
beschreibung: |
|
||
SHM hat im Konsent-Verfahren der DSR volles Einwand-Recht.
|
||
Ein Demand, der gegen fundamentale Stakeholder-Interessen verstößt,
|
||
kann nicht ohne SHM-Zustimmung freigegeben werden.
|
||
|
||
herleitung: |
|
||
Das Einwand-Recht ergibt sich aus der bestehenden DSR-Geschäftsordnung:
|
||
1. SHM ist stimmberechtigtes Mitglied (Abschnitt 3.1)
|
||
2. Alle stimmberechtigten Mitglieder können Einwände erheben (Abschnitt 5.1)
|
||
3. Das Konsent-Prinzip gilt für alle Mitglieder gleichermaßen
|
||
|
||
Ein separater Patch der DSR-GO ist nicht erforderlich.
|
||
|
||
anwendung: |
|
||
Das Einwand-Recht sollte verantwortungsvoll genutzt werden.
|
||
SHM-Einwände müssen sachlich begründet sein und sich auf die
|
||
Stakeholder-Perspektive beziehen. Technische oder ressourcenbezogene
|
||
Einwände sind Domäne anderer DSR-Mitglieder (SPM, PPM).
|
||
|
||
governance_referenz: "GOV-SHM-021"
|
||
dokumentation_in: "DSR-Geschäftsordnung (Abschnitt 3.1 + 5.1)"
|
||
|
||
# =============================================================================
|
||
# SHM-ROLLE BEIM MISSION BOARD
|
||
# =============================================================================
|
||
|
||
shm_rolle_mission_board:
|
||
|
||
grundsatz:
|
||
|
||
beschreibung: |
|
||
Die MB-Mitgliedschaft ist nach Rolle differenziert:
|
||
|
||
- **Leitung Stakeholder Management**: Vollwertiges MB-Mitglied
|
||
- **Stakeholder-Manager:in (operativ)**: Kein ständiges MB-Mitglied
|
||
|
||
Die operative Stakeholder-Perspektive wird primär über die DSR
|
||
eingebracht. Die strategische Vertretung erfolgt durch die Leitung SHM
|
||
direkt im Mission Board.
|
||
|
||
begruendung: |
|
||
Das Mission Board ist ein strategisch-taktisches Entscheidungsgremium.
|
||
Die Leitung SHM muss dort vertreten sein, weil:
|
||
- Stakeholder-Portfolio-Gesamtsicht nur auf Leitungsebene vorliegt
|
||
- Strategische Stakeholder-Themen MB-relevant sind
|
||
- Entscheidungsauswirkungen auf Stakeholder bewertet werden müssen
|
||
|
||
Die operative Rolle (Stakeholder-Manager:in) bringt sich über die DSR ein,
|
||
die bei MB-Demands als "vorbereitendes und empfehlendes Gremium" fungiert.
|
||
|
||
governance_referenz: "GOV-SHM-025"
|
||
|
||
leitung_shm_im_mb:
|
||
|
||
status: "Vollwertiges Mitglied"
|
||
|
||
funktion: |
|
||
Vertretung der Stakeholder-Perspektive auf strategisch-taktischer Ebene.
|
||
Einbringung von Portfolio-Erkenntnissen und VoC-Trends.
|
||
|
||
befugnisse:
|
||
- "Stimmrecht"
|
||
- "Einbringung strategischer Stakeholder-Themen"
|
||
- "Bewertung von Demand-Auswirkungen auf Stakeholder-Beziehungen"
|
||
|
||
stakeholder_manager_und_mb:
|
||
|
||
status: "Kein ständiges Mitglied"
|
||
|
||
indirekte_beteiligung:
|
||
|
||
ueber_dsr:
|
||
beschreibung: |
|
||
Bei MB-Demands bringt SHM die Stakeholder-Perspektive in der
|
||
DSR-Vorbereitung ein. Die DSR formuliert eine Empfehlung, die
|
||
die SHM-Sicht berücksichtigt.
|
||
|
||
aktivitaeten:
|
||
- "Stakeholder-Kontext für MB-Vorlage liefern"
|
||
- "Risiken für Stakeholder-Beziehung dokumentieren"
|
||
- "Kommunikationsstrategie vorbereiten"
|
||
|
||
direkte_beteiligung:
|
||
|
||
auf_einladung:
|
||
beschreibung: |
|
||
DPM kann SHM bei Bedarf zur MB-Sitzung einladen, wenn die
|
||
Stakeholder-Perspektive für die Entscheidung zentral ist.
|
||
|
||
typische_faelle:
|
||
- "Demand betrifft Key-Stakeholder mit komplexer Beziehungshistorie"
|
||
- "Hohes Konfliktpotenzial mit betroffenen Ämtern"
|
||
- "Demand hat politische Dimension (unterhalb TRIG-E-Schwelle)"
|
||
|
||
rolle_im_mb: "Beratend, kein Stimmrecht"
|
||
|
||
information_nach_entscheidung:
|
||
|
||
beschreibung: |
|
||
SHM wird über MB-Entscheidungen informiert, die SHM-relevante
|
||
Stakeholder betreffen.
|
||
|
||
differenzierung:
|
||
|
||
key_stakeholder:
|
||
information: "Proaktiv durch DPM unmittelbar nach Entscheidung"
|
||
zweck: "SHM kann zeitnah Stakeholder-Kommunikation vorbereiten"
|
||
|
||
andere_stakeholder:
|
||
information: "Regulär über DSR-Protokoll"
|
||
zweck: "Information für Betreuungsplanung"
|
||
|
||
# =============================================================================
|
||
# SONDERFALL: POLITISCHE ESKALATION (TRIG-E)
|
||
# =============================================================================
|
||
|
||
sonderfall_politische_eskalation:
|
||
|
||
trigger_referenz: "shm_engagement-framework.yaml#eskalation#trigger_kategorien#TRIG-E"
|
||
|
||
beschreibung: |
|
||
Politische Eskalationen (TRIG-E) sind Sonderfälle, die einen Bypass
|
||
zum regulären D2P-Prozess erfordern. Wenn ein Amt politisch eskaliert
|
||
(z.B. Drohung, an Gemeinderat zu gehen), ist das kein normaler Demand mehr.
|
||
|
||
abgrenzung_zum_d2p:
|
||
|
||
parallel_nicht_ersetzend: |
|
||
TRIG-E-Fälle werden parallel zum D2P behandelt. Der reguläre
|
||
Demand-Prozess läuft nicht weiter, bis die Krise gelöst ist.
|
||
Ein eventuell resultierender Demand wird nachträglich ins
|
||
Portfolio aufgenommen.
|
||
|
||
shm_rolle: "Koordination der Sofortreaktion"
|
||
|
||
prozess:
|
||
|
||
- schritt: 1
|
||
akteur: "SHM"
|
||
aktion: "Erkennt TRIG-E-Situation und informiert sofort DIGIT-Amtsleitung"
|
||
zeitrahmen: "Innerhalb von Stunden"
|
||
|
||
- schritt: 2
|
||
akteur: "SHM + DIGIT-Amtsleitung"
|
||
aktion: "Gemeinsame Lageeinschätzung und Reaktionsstrategie"
|
||
|
||
- schritt: 3
|
||
akteur: "DIGIT-Amtsleitung"
|
||
aktion: "Entscheidung über Eskalation ans Mission Board (ggf. ad-hoc)"
|
||
|
||
- schritt: 4
|
||
akteur: "SHM"
|
||
aktion: "Umsetzung der Kommunikationsstrategie mit Stakeholder"
|
||
|
||
- schritt: 5
|
||
akteur: "SHM"
|
||
aktion: "Nach Krisenauflösung: Demand (falls vorhanden) regulär ins Portfolio"
|
||
|
||
keine_qg_anforderungen: |
|
||
Bei TRIG-E gelten die regulären Quality-Gate-Anforderungen nicht.
|
||
Die Krisenbewältigung hat Vorrang vor Prozesskonformität.
|
||
|
||
# =============================================================================
|
||
# SHM-ROLLE BEI DEMAND-ABLEHNUNG
|
||
# =============================================================================
|
||
|
||
shm_rolle_bei_ablehnung:
|
||
|
||
grundsatz:
|
||
|
||
beschreibung: |
|
||
Wenn die DSR oder das Mission Board einen Demand ablehnt, übernimmt
|
||
SHM die Kommunikation an den Stakeholder. Der Umfang dieser Rolle
|
||
variiert nach Stakeholder-Priorität.
|
||
|
||
governance_referenz: "GOV-SHM-022"
|
||
|
||
differenzierung_nach_prioritaet:
|
||
|
||
key_stakeholder:
|
||
rolle: "Vermittlungsfunktion"
|
||
|
||
aktivitaeten:
|
||
- "Persönliches Gespräch zur Erklärung der Entscheidung"
|
||
- "Prüfung, ob modifizierter Demand möglich wäre"
|
||
- "Dokumentation der Stakeholder-Reaktion"
|
||
- "Bei Bedarf: Wiedervorlage mit angepasstem Scope"
|
||
- "Aktive Beziehungspflege zur Schadensbegrenzung"
|
||
|
||
eskalation_bei_konflikt: |
|
||
Wenn Key-Stakeholder die Ablehnung nicht akzeptiert, prüft SHM
|
||
ob TRIG-D (Unzufriedenheits-Eskalation) oder TRIG-E (politische
|
||
Eskalation) vorliegt und handelt entsprechend.
|
||
|
||
aktiv_stakeholder:
|
||
rolle: "Vermittlungsfunktion"
|
||
|
||
aktivitaeten:
|
||
- "Strukturiertes Feedback-Gespräch"
|
||
- "Erklärung der Entscheidungsgründe"
|
||
- "Prüfung von Alternativoptionen"
|
||
- "Dokumentation für künftige Reviews"
|
||
|
||
abgrenzung_zu_key: |
|
||
Weniger proaktive Nachverfolgung als bei Key-Stakeholdern.
|
||
Wiedervorlage nur auf expliziten Stakeholder-Wunsch.
|
||
|
||
standard_stakeholder:
|
||
rolle: "Kommunikationsfunktion"
|
||
|
||
aktivitaeten:
|
||
- "Schriftliche Mitteilung der Entscheidung"
|
||
- "Erklärung der wesentlichen Gründe"
|
||
- "Hinweis auf Widerspruchsmöglichkeit (falls vorhanden)"
|
||
|
||
keine_aktive_vermittlung: |
|
||
Aktive Vermittlung nur auf explizite Anfrage des Stakeholders.
|
||
|
||
basis_stakeholder:
|
||
rolle: "Kommunikationsfunktion"
|
||
|
||
aktivitaeten:
|
||
- "Standardisierte Ablehnungsmitteilung"
|
||
- "Verweis auf Service-Katalog für alternative Optionen"
|
||
|
||
minimaler_aufwand: |
|
||
Ressourcen werden auf höher priorisierte Stakeholder fokussiert.
|
||
|
||
# =============================================================================
|
||
# ABGRENZUNG: EXTERNE VS. INTERNE BEDARFE
|
||
# =============================================================================
|
||
|
||
abgrenzung_bedarfsquellen:
|
||
|
||
grundsatz:
|
||
|
||
beschreibung: |
|
||
Das SHM-Routing (Bedarfsbewertung) gilt für **Stakeholder-initiierte Bedarfe**,
|
||
d.h. Bedarfe, die von externen Auftraggebern (Ämtern, Dienststellen) an DIGIT
|
||
herangetragen werden.
|
||
|
||
**Interne DIGIT-Bedarfe** – insbesondere solche, die aus dem Service-Lifecycle
|
||
entstehen – folgen einem anderen Eintrittskanal und durchlaufen die SHM-Triage
|
||
nicht.
|
||
|
||
governance_referenz: "GOV-SHM-026"
|
||
|
||
bedarfsquellen_uebersicht:
|
||
|
||
externe_bedarfe:
|
||
definition: |
|
||
Bedarfe, die von Stakeholdern außerhalb von DIGIT eingebracht werden.
|
||
Der Stakeholder ist Bedarfsträger und Auftraggeber.
|
||
|
||
eintrittskanal: "SHM (Stakeholder-Management)"
|
||
shm_involviert: true
|
||
|
||
beispiele:
|
||
- "Amt X benötigt neue Funktion im bestehenden Fachverfahren"
|
||
- "Dienststelle Y möchte von Outlook auf alternative Lösung wechseln"
|
||
- "Anfrage zur Erweiterung eines bestehenden Service"
|
||
|
||
routing_logik: |
|
||
→ SHM-Bedarfsbewertung (shm_bedarfsbewertung.yaml)
|
||
→ Prüfung 1: Service-Katalog-Check
|
||
→ Prüfung 2: Change-Qualifizierung (bei ROUTE-SPM)
|
||
→ Prüfung 3: Demand-Indikation (bei ROUTE-DPM)
|
||
|
||
interne_bedarfe:
|
||
definition: |
|
||
Bedarfe, die innerhalb von DIGIT entstehen – typischerweise aus dem
|
||
Service-Lifecycle (Service Review) oder aus technischen/strategischen
|
||
Notwendigkeiten. Der Service Owner oder eine andere DIGIT-Rolle ist
|
||
Bedarfsträger.
|
||
|
||
eintrittskanal: "Direkt DPM / SOR"
|
||
shm_involviert: false
|
||
shm_informiert: "Bei Stakeholder-Auswirkungen"
|
||
|
||
beispiele:
|
||
- "Service Owner identifiziert Redesign-Bedarf aus Service Review"
|
||
- "Technische Ablösung eines End-of-Life-Systems"
|
||
- "Sicherheitsbedingte Service-Änderung"
|
||
- "Konsolidierung mehrerer Services zu einem neuen Service"
|
||
|
||
routing_logik: |
|
||
→ Service Owner / DIGIT-Rolle erstellt Demand direkt
|
||
→ Eintritt in Demand-Lifecycle ohne SHM-Triage
|
||
→ Bei Stakeholder-Auswirkungen: SHM wird informiert (nicht involviert)
|
||
|
||
differenzierung_nach_szenarien:
|
||
|
||
# -------------------------------------------------------------------------
|
||
szenario_1_service_erweiterung:
|
||
name: "Service-Erweiterung (Feature-Request)"
|
||
|
||
beschreibung: |
|
||
Ein bestehender Service soll um Funktionalität erweitert werden.
|
||
Die Frage ist: Wer ist Bedarfsträger?
|
||
|
||
variante_a:
|
||
name: "Stakeholder-initiiert"
|
||
beispiel: "Amt X möchte im Ticketsystem eine neue Auswertung"
|
||
eintrittskanal: "SHM"
|
||
|
||
ablauf:
|
||
- schritt: 1
|
||
akteur: "Stakeholder"
|
||
aktion: "Meldet Bedarf bei SHM"
|
||
- schritt: 2
|
||
akteur: "SHM"
|
||
aktion: "Bedarfsbewertung: Prüfung 1 → teilweise abbildbar"
|
||
- schritt: 3
|
||
akteur: "SHM"
|
||
aktion: "Prüfung 2: Change-Qualifizierung → ROUTE-SPM"
|
||
- schritt: 4
|
||
akteur: "Service Owner"
|
||
aktion: "Entscheidet: Umsetzbar als Change oder Redesign nötig?"
|
||
- schritt: 5
|
||
akteur: "Service Owner"
|
||
aktion: "Bei Redesign: SO erstellt Demand für DPM"
|
||
|
||
shm_rolle: "Routing + Stakeholder-Kommunikation"
|
||
|
||
variante_b:
|
||
name: "Service-Owner-initiiert (aus Review)"
|
||
beispiel: "SO erkennt im Review: Service braucht Modernisierung"
|
||
eintrittskanal: "Direkt DPM"
|
||
|
||
ablauf:
|
||
- schritt: 1
|
||
akteur: "Service Owner"
|
||
aktion: "Identifiziert Erweiterungsbedarf im Service Review (sr_02)"
|
||
- schritt: 2
|
||
akteur: "SOR"
|
||
aktion: "Bestätigt Handlungsempfehlung REDESIGN (sr_03)"
|
||
- schritt: 3
|
||
akteur: "Service Owner"
|
||
aktion: "Erstellt Demand direkt für DPM (sr_05)"
|
||
- schritt: 4
|
||
akteur: "DPM"
|
||
aktion: "Klassifiziert und priorisiert Demand"
|
||
|
||
shm_rolle: "Keine (interner Bedarf)"
|
||
shm_information: "Bei Stakeholder-Auswirkungen durch DPM"
|
||
|
||
# -------------------------------------------------------------------------
|
||
szenario_2_service_ersetzung:
|
||
name: "Service-Ersetzung (Ablösung/Migration)"
|
||
|
||
beschreibung: |
|
||
Ein bestehender Service soll durch einen anderen ersetzt werden
|
||
(z.B. Outlook → Thunderbird, proprietäres System → Open Source).
|
||
Dies ist ein komplexes Szenario mit zwei möglichen Demand-Typen.
|
||
|
||
variante_a:
|
||
name: "Stakeholder-initiiert"
|
||
beispiel: "Amt X fordert: Wir wollen nicht mehr mit System Y arbeiten"
|
||
eintrittskanal: "SHM"
|
||
|
||
ablauf:
|
||
- schritt: 1
|
||
akteur: "Stakeholder"
|
||
aktion: "Meldet Ablösewunsch bei SHM"
|
||
- schritt: 2
|
||
akteur: "SHM"
|
||
aktion: "Bedarfsbewertung: Was ist der tatsächliche Bedarf?"
|
||
hinweis: "Trennung Symptom vs. Ursache (User Stories)"
|
||
- schritt: 3
|
||
akteur: "SHM"
|
||
aktion: "Prüfung 1: Nicht abbildbar (neuer Service) → Prüfung 3"
|
||
- schritt: 4
|
||
akteur: "SHM"
|
||
aktion: "ROUTE-DPM: Demand für neuen/alternativen Service"
|
||
- schritt: 5
|
||
akteur: "DPM"
|
||
aktion: "Klassifiziert Demand; prüft Abhängigkeit zum Altsystem"
|
||
- schritt: 6
|
||
akteur: "DPM/DSR"
|
||
aktion: "Entscheidet: Neuer Service UND Retirement des alten?"
|
||
|
||
shm_rolle: "Routing + Bedarfserhebung + Stakeholder-Kommunikation"
|
||
|
||
besonderheit: |
|
||
Bei Stakeholder-initiierter Ablösung ist der Stakeholder-Bedarf
|
||
der Treiber. Das Retirement des Altservice ist ggf. Konsequenz,
|
||
aber nicht der primäre Bedarf.
|
||
|
||
variante_b:
|
||
name: "Service-Owner-initiiert (End-of-Life)"
|
||
beispiel: "SO/SOR entscheidet: Service Y ist technisch obsolet"
|
||
eintrittskanal: "SOR → DPM"
|
||
|
||
ablauf:
|
||
- schritt: 1
|
||
akteur: "Service Owner"
|
||
aktion: "Identifiziert End-of-Life im Service Review (sr_02)"
|
||
- schritt: 2
|
||
akteur: "SOR"
|
||
aktion: "Bestätigt Handlungsempfehlung RETIRE (sr_03)"
|
||
- schritt: 3
|
||
akteur: "Service Owner"
|
||
aktion: "Erstellt Retirement-Plan (sr_06)"
|
||
- schritt: 4
|
||
akteur: "DPM"
|
||
aktion: "Koordiniert Retirement als Demand/Projekt"
|
||
- schritt: 5
|
||
akteur: "DPM"
|
||
aktion: "Prüft: Ist Ersatz-Service nötig? → Separater Demand"
|
||
|
||
shm_rolle: "Keine Triage (interner Bedarf)"
|
||
shm_information: "Proaktiv durch DPM wegen Stakeholder-Auswirkungen"
|
||
|
||
besonderheit: |
|
||
Bei technisch getriebener Ablösung entstehen potenziell zwei
|
||
separate Demands: (1) Retirement des Altservice, (2) Neuer Service.
|
||
SHM wird informiert, weil Stakeholder betroffen sind, aber SHM
|
||
ist nicht Bedarfsträger.
|
||
|
||
# -------------------------------------------------------------------------
|
||
szenario_3_sicherheit_compliance:
|
||
name: "Sicherheits- oder Compliance-bedingte Änderung"
|
||
|
||
beschreibung: |
|
||
Änderungen, die aus Sicherheitsanforderungen, Regulatorik oder
|
||
Compliance-Vorgaben resultieren.
|
||
|
||
eintrittskanal: "Direkt SOR/DPM (je nach Umfang)"
|
||
shm_involviert: false
|
||
|
||
ablauf:
|
||
- schritt: 1
|
||
akteur: "ISB / Compliance / SO"
|
||
aktion: "Identifiziert Handlungsbedarf"
|
||
- schritt: 2
|
||
akteur: "SOR"
|
||
aktion: "Bewertet Dringlichkeit und Scope"
|
||
- schritt: 3
|
||
akteur: "SO / DPM"
|
||
aktion: "Umsetzung als Change oder Demand"
|
||
|
||
shm_rolle: |
|
||
SHM wird informiert, wenn Stakeholder betroffen sind
|
||
(z.B. Funktionseinschränkungen, Migrationsaufwände).
|
||
SHM übernimmt dann die Stakeholder-Kommunikation.
|
||
|
||
shm_information_bei_internen_bedarfen:
|
||
|
||
grundsatz: |
|
||
Auch wenn SHM bei internen Bedarfen nicht als Routing-Instanz involviert
|
||
ist, muss SHM informiert werden, sobald externe Stakeholder von der
|
||
Änderung betroffen sind.
|
||
|
||
informationspflicht:
|
||
ausloeser:
|
||
- "Service-Änderung betrifft aktive Nutzer (Ämter/Dienststellen)"
|
||
- "Funktionsänderungen, Migrationen, Abschaltungen"
|
||
- "Änderungen an SLAs oder Service-Umfang"
|
||
|
||
informiert_durch: "DPM oder Service Owner"
|
||
|
||
shm_aufgabe: |
|
||
- Stakeholder-Kommunikation vorbereiten und durchführen
|
||
- Betroffene Stakeholder nach Priorität differenziert informieren
|
||
- Feedback und Bedenken aufnehmen und an DPM/SO zurückmelden
|
||
|
||
kommunikationsdifferenzierung:
|
||
key_stakeholder:
|
||
- "Proaktive persönliche Information vor Umsetzung"
|
||
- "Einholung von Feedback zu Auswirkungen"
|
||
aktiv_stakeholder:
|
||
- "Strukturierte Information im Rahmen der Regelkommunikation"
|
||
standard_basis_stakeholder:
|
||
- "Schriftliche Ankündigung über etablierte Kanäle"
|
||
|
||
visualisierung_eintrittsrouten:
|
||
|
||
diagramm: |
|
||
|
||
┌──────────────────────────────────────────────────────────────────────┐
|
||
│ BEDARFSQUELLEN → DEMAND-LIFECYCLE │
|
||
└──────────────────────────────────────────────────────────────────────┘
|
||
|
||
┌─────────────────────────┐ ┌─────────────────────────┐
|
||
│ EXTERNE BEDARFE │ │ INTERNE BEDARFE │
|
||
│ (Stakeholder-Kanal) │ │ (Service-Lifecycle) │
|
||
└───────────┬─────────────┘ └───────────┬─────────────┘
|
||
│ │
|
||
▼ ▼
|
||
┌───────────────────────┐ ┌───────────────────────────┐
|
||
│ SHM │ │ Service Owner / SOR │
|
||
│ Bedarfsbewertung │ │ (Service Review) │
|
||
│ - Prüfung 1-3 │ │ - sr_02: Performance │
|
||
│ - User Stories │ │ - sr_03: SOR-Entscheid │
|
||
│ - Bedarfssteckbrief │ │ - sr_05/06: Redesign/ │
|
||
└───────────┬───────────┘ │ Retire │
|
||
│ └───────────┬───────────────┘
|
||
│ │
|
||
├──────────────┬───────────────────┤
|
||
▼ ▼ ▼
|
||
┌─────────────┐ ┌─────────────┐ ┌─────────────────────────┐
|
||
│ ROUTE-REQ │ │ ROUTE-SPM │ │ ROUTE-DPM │
|
||
│ Service │ │ Service │ │ Demand-Lifecycle │
|
||
│ Desk │ │ Owner │ │ (DSR / MB) │
|
||
└─────────────┘ └──────┬──────┘ └───────────┬─────────────┘
|
||
│ │
|
||
│ ┌───────────────────┘
|
||
│ │
|
||
▼ ▼
|
||
┌────────────────────┐
|
||
│ DPM / DSR / MB │
|
||
│ Klassifizierung │
|
||
│ & Priorisierung │
|
||
└────────────────────┘
|
||
│
|
||
▼
|
||
┌────────────────────┐
|
||
│ SHM informiert │
|
||
│ bei Stakeholder- │
|
||
│ Auswirkungen │
|
||
└────────────────────┘
|
||
|
||
# =============================================================================
|
||
# GOVERNANCE-ENTSCHEIDUNGEN (PHASE 4)
|
||
# =============================================================================
|
||
|
||
governance_entscheidungen:
|
||
|
||
- id: GOV-SHM-021
|
||
datum: 2025-12-09
|
||
quelle_modul: "D2P-Integration (Phase 4)"
|
||
|
||
frage: |
|
||
Hat SHM volles Einwand-Recht in der DSR?
|
||
|
||
entscheidung: |
|
||
Ja. SHM hat im Konsent-Verfahren der DSR volles Einwand-Recht.
|
||
Dies ergibt sich bereits aus der bestehenden DSR-Geschäftsordnung.
|
||
|
||
begruendung: |
|
||
SHM vertritt die Stakeholder-Perspektive ("Auftraggeber-Anwalt").
|
||
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: "dpm_dsr-go.yaml"
|
||
abschnitt: "zusammensetzung (3.1), entscheidungsverfahren (5.1)"
|
||
aktion: "Keine Änderung erforderlich - bereits abgedeckt"
|
||
|
||
status: final
|
||
|
||
typ: "Klarstellung (keine Änderung bestehender Dokumente)"
|
||
|
||
- 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
|
||
|
||
- id: GOV-SHM-026
|
||
datum: 2025-01-29
|
||
quelle_modul: "D2P-Integration (Ergänzung)"
|
||
|
||
frage: |
|
||
Durchlaufen interne DIGIT-Bedarfe (aus dem Service-Lifecycle) die
|
||
SHM-Bedarfsbewertung?
|
||
|
||
entscheidung: |
|
||
Nein. Die SHM-Bedarfsbewertung gilt für Stakeholder-initiierte Bedarfe.
|
||
Interne Bedarfe (z.B. aus Service Review, technische Ablösungen,
|
||
Sicherheitsanforderungen) treten direkt in den Demand-Lifecycle ein.
|
||
|
||
SHM wird jedoch informiert, wenn externe Stakeholder von der Änderung
|
||
betroffen sind, und übernimmt dann die Stakeholder-Kommunikation.
|
||
|
||
begruendung: |
|
||
1. Die SHM-Bedarfsbewertung dient primär der Übersetzung von
|
||
Stakeholder-Bedarfen in qualifizierte Demands. Bei internen
|
||
Bedarfen ist diese Übersetzungsleistung nicht erforderlich,
|
||
da der Service Owner oder die technische Rolle den Bedarf
|
||
bereits fachlich qualifiziert hat.
|
||
|
||
2. Der Service-Lifecycle (insbesondere sr_05 "Service Redesign"
|
||
und sr_06 "Service außer Betrieb nehmen") definiert bereits
|
||
einen direkten Übergang zum Demand-Lifecycle.
|
||
|
||
3. SHM bleibt für die Stakeholder-Kommunikation verantwortlich,
|
||
auch wenn SHM nicht Bedarfsträger ist. Dies entspricht der
|
||
Rolle als "Auftraggeber-Anwalt".
|
||
|
||
auswirkung_auf:
|
||
- dokument: "shm_d2p-integration.yaml"
|
||
abschnitt: "abgrenzung_bedarfsquellen"
|
||
- dokument: "shm_bedarfsbewertung.yaml"
|
||
abschnitt: "funktionale_herleitung"
|
||
aktion: "Querverweis auf GOV-SHM-026 ergänzen"
|
||
- dokument: "service-lifecycle_service-review.yaml"
|
||
abschnitt: "sr_05, sr_06"
|
||
aktion: "Keine Änderung - bereits konsistent"
|
||
|
||
status: final
|
||
|
||
typ: "Klarstellung (explizite Dokumentation impliziter Logik)"
|
||
|
||
# =============================================================================
|
||
# ANNAHMEN
|
||
# =============================================================================
|
||
|
||
annahmen:
|
||
|
||
- id: "ANNAHME-D2P-001"
|
||
beschreibung: |
|
||
DPM kann bei der Klassifizierung feststellen, dass ein Bedarf
|
||
doch kein Demand ist (sondern Change oder Request).
|
||
auswirkung: "Rückkanal DPM → SHM mit Routing-Korrektur"
|
||
validierung: "Abstimmung mit DPM"
|
||
|
||
- id: "ANNAHME-D2P-002"
|
||
beschreibung: |
|
||
Das Einwand-Recht aller DSR-Mitglieder (inkl. SHM) ergibt sich
|
||
aus der bestehenden DSR-Geschäftsordnung (Abschnitt 3.1 + 5.1).
|
||
auswirkung: "Keine – bestehende Regelung ist ausreichend"
|
||
validierung: "Abgleich PDF vs. YAML am 2025-12-09 durchgeführt"
|
||
status: "validiert"
|
||
|
||
# =============================================================================
|
||
# OFFENE PUNKTE
|
||
# =============================================================================
|
||
|
||
offene_punkte:
|
||
|
||
- id: "OPEN-D2P-001"
|
||
beschreibung: "Abstimmung Rückkanal-Prozess mit DPM"
|
||
prioritaet: "mittel"
|
||
cross_functional: true
|
||
beteiligte: ["SHM", "DPM"]
|
||
hinweis: "Wie wird Rückweisung im Ticketsystem abgebildet?"
|
||
|
||
erledigte_punkte:
|
||
|
||
- id: "ERLEDIGT-D2P-001"
|
||
urspruenglich: "OPEN-D2P-001 (alt)"
|
||
beschreibung: "DSR-GO Patch: Einwand-Recht SHM explizit regeln"
|
||
erledigt_am: "2025-12-09"
|
||
ergebnis: |
|
||
Kein Patch erforderlich. Prüfung ergab, dass das Einwand-Recht
|
||
bereits durch DSR-GO Abschnitt 3.1 (Mitgliedschaft) und 5.1
|
||
(Konsent-Prinzip) abgedeckt ist.
|
||
referenz: "GOV-SHM-021"
|
||
|
||
# =============================================================================
|
||
# ÄNDERUNGSHISTORIE
|
||
# =============================================================================
|
||
|
||
aenderungshistorie:
|
||
|
||
- version: "1.0"
|
||
datum: "2025-12-09"
|
||
aenderung: "Initiale Erstellung"
|
||
autor: "DIGITOM-Projekt"
|
||
quelle: "Chat-Session SHM Phase 4"
|
||
|
||
- version: "1.1"
|
||
datum: "2025-12-10"
|
||
aenderung: |
|
||
Präzisierung MB-Mitgliedschaft (GOV-SHM-025):
|
||
- Leitung SHM ist vollwertiges MB-Mitglied
|
||
- Stakeholder-Manager:in (operativ) weiterhin kein ständiges Mitglied
|
||
- Abschnitt shm_rolle_mission_board entsprechend umstrukturiert
|
||
autor: "DIGITOM-Projekt"
|
||
quelle: "Chat-Session SHM Phase 6"
|
||
|
||
- version: "1.2"
|
||
datum: "2025-01-29"
|
||
aenderung: |
|
||
Neuer Abschnitt: Abgrenzung externe vs. interne Bedarfe (GOV-SHM-026):
|
||
- Klarstellung: SHM-Bedarfsbewertung gilt für Stakeholder-initiierte Bedarfe
|
||
- Interne Bedarfe (aus Service-Lifecycle) treten direkt in DPM ein
|
||
- Differenzierung nach Szenarien: Service-Erweiterung, Service-Ersetzung
|
||
- SHM-Information bei Stakeholder-Auswirkungen definiert
|
||
- Visualisierung der Eintrittsrouten ergänzt
|
||
autor: "DIGITOM-Projekt"
|
||
quelle: "Chat-Session Konzeptprüfung" |