# ============================================================================= # 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"