# ============================================================================= # SHM BEDARFSBEWERTUNG: METHODIK # ============================================================================= # Modul: Stakeholder-Management (SHM) # Funktion: Methodik # Version: 1.3 # Datum: 2025-01-29 # Status: Entwurf # Entwicklungsphase: 3 # ============================================================================= meta: modul_id: "SHM-M-01" name: "Bedarfsbewertung" typ: "Methodik" zweck: | Die Bedarfsbewertung ist die methodische Handlungsanleitung für den Stakeholder-Manager zur Beantwortung der Kernfrage: "Wohin gehört dieser Bedarf?" Sie operationalisiert die Routing-Entscheidung (E2) aus dem Stakeholder-Portfolio und definiert, wie der Stakeholder-Manager von einem eingehenden Bedarf zu einer qualifizierten Übergabe kommt. abgrenzung: bedarfssteckbrief_schema: | Das Schema (shm_schema_bedarfssteckbrief.yaml) definiert WAS dokumentiert wird. Diese Methodik definiert WIE entschieden wird. dpm_klassifizierung: | Die DPM-Klassifizierung (dpm_demand-klassifizierung.yaml) greift NACH der SHM-Bewertung. SHM entscheidet OB etwas ein Demand ist, DPM klassifiziert WIE der Demand priorisiert und bearbeitet wird. service_desk: | Der Service Desk (L1) bearbeitet Standard-Requests und -Incidents. Bedarfe, die nicht über L1 lösbar sind oder komplexere Anforderungen darstellen, werden an SHM eskaliert. referenzen: - dokument: "shm_schema_bedarfssteckbrief.yaml" beschreibung: "Datenstruktur für die Bedarfsdokumentation" - dokument: "shm_stakeholder-portfolio.yaml" beschreibung: "Kernentscheidung E2 (Bedarfsrouting)" - dokument: "shm_engagement-framework.yaml" beschreibung: "Formate für Bedarfserhebung" - dokument: "dpm_demand-klassifizierung.yaml" beschreibung: "Nachgelagerte Demand-Klassifizierung im DPM" - dokument: "shm_interne-bedarfe-routing.yaml" beschreibung: "Routing und SHM-Rolle bei internen DIGIT-Bedarfen" pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/" itil4_referenz: practice: "Business Analysis" relevante_elemente: - "Requirement Gathering" - "Stakeholder Analysis" - "Solution Evaluation" adaption_fuer_digitom: | Die ITIL4-Business-Analysis-Practice liefert methodischen Input für die Bedarfserhebung (Schritt 0). Die Routing-Logik ist DIGITOM-spezifisch und bildet die Schnittstellen zwischen SHM, SPM und DPM ab. # ============================================================================= # FUNKTIONALE HERLEITUNG # ============================================================================= funktionale_herleitung: kernfrage: "Wohin gehört dieser Bedarf?" geltungsbereich: | Diese Bedarfsbewertung unterscheidet drei Bedarfstypen mit unterschiedlichen Prozesswegen: **1. Externe Stakeholder-Bedarfe (Regelweg)** Bedarfe von Ämtern und Dienststellen außerhalb von DIGIT durchlaufen die vollständige Bedarfsbewertung (Schritt 0, Prüfungen 1-3). Dies ist der Hauptanwendungsfall dieser Methodik. **2. Interne DIGIT-Mitarbeiter-Bedarfe (Fast Track)** Bedarfe von DIGIT-Mitarbeitern als Nutzer (z.B. Personalabteilung DIGIT, Sekretariat, Sachbearbeiter) durchlaufen einen vereinfachten Fast Track Prozess (10-15 Minuten). Siehe Abschnitt "Fast Track für interne Bedarfe". **3. Service-Lifecycle-Bedarfe (Bypass)** Bedarfe aus dem Service-Lifecycle (Service Owner identifiziert Redesign, ISB fordert Sicherheitsänderung, strategische Initiative) durchlaufen die SHM-Triage nicht, sondern treten direkt in den Demand-Lifecycle ein. SHM wird bei Stakeholder-Auswirkungen informiert. Siehe: shm_interne-bedarfe-routing.yaml (Arbeitsmaterial) Siehe: shm_d2p-integration.yaml#abgrenzung_bedarfsquellen (GOV-SHM-026) kontext: | Wenn ein Bedarf beim Stakeholder-Manager eingeht, muss dieser zwei Aufgaben erfüllen: 1. Den tatsächlichen Bedarf verstehen (nicht die vorgeschlagene Lösung) 2. Den Bedarf an die richtige Stelle im DIGIT-System routen Die Bewertung ist keine technische Analyse – diese erfolgt beim Empfänger. Die Bewertung ist eine Triage: Schnell, strukturiert, nachvollziehbar. routing_pfade: - id: "ROUTE-REQ" name: "Request Fulfilment" empfaenger: "Service Desk / Service Owner" trigger: "Bedarf ist durch bestehenden Katalog abbildbar" status_im_steckbrief: "n/a (kein Bedarfssteckbrief erforderlich)" beschreibung: | Standard-Anfragen, die über den Service-Katalog bedient werden können. Diese verlassen den SHM-Scope direkt und werden als Request behandelt. - id: "ROUTE-SPM" name: "Service Portfolio Management" empfaenger: "Service Owner (via SPM)" trigger: "Bedarf betrifft Änderung an bestehendem Service" status_im_steckbrief: "an_spm_uebergeben" beschreibung: | Changes an bestehenden Services, die vom zuständigen Service Owner bearbeitet werden. Der Bedarfssteckbrief wird an SPM übergeben. - id: "ROUTE-DPM" name: "Demand Portfolio Management" empfaenger: "DPM (Demand-to-Product-Prozess)" trigger: "Bedarf erfordert neuen Service oder grundlegende Neugestaltung" status_im_steckbrief: "an_dpm_uebergeben" beschreibung: | Neue Bedarfe mit Projektcharakter, die den Demand-to-Product-Prozess durchlaufen. Der qualifizierte Bedarf wird zum Demand. - id: "ROUTE-SO" name: "Service-Owner-Klärung" empfaenger: "Service Owner (über Service-Portfolio / SPM)" trigger: "Routing unklar – Klärung über Service Owner erforderlich" status_im_steckbrief: "in_so_klaerung" beschreibung: | Der SO gibt eine Routing-Empfehlung ab. Die formelle Entscheidung erfolgt in der SOR (Change); Demand geht direkt an DPM (nicht über DSR). Pfad A – SO identifizierbar: SHM prüft das Service-Portfolio und kontaktiert den identifizierten Service Owner direkt. Der SO prüft und gibt eine Empfehlung ab, ob der Bedarf als Change im RUN umsetzbar ist oder ob es sich um einen Demand handelt. Pfad B – Kein SO identifizierbar: SHM kontaktiert SPM zur Unterstützung bei der Service-Identifikation. SPM hilft, den betroffenen Service und zuständigen SO zu finden. Danach gibt der SO eine Empfehlung wie in Pfad A ab. Nach SO-Empfehlung (als ob-Weiterbearbeitung): - RUN/Change → Der Bedarf wird bereits bearbeitet; formelle Bestätigung in SOR - Demand → Der Bedarf wird bereits bearbeitet; direkte Übergabe an DPM (ohne DSR) Kleine Changes können vom SO direkt ohne SOR umgesetzt werden. Eskalation: Mission Board, falls Gremium die SO-Empfehlung überstimmt und diese Übersteuerung nicht formal begründet ist. referenz: "GOV-SHM-029" - id: "ROUTE-DPM-INTERN" name: "DPM (Interner Fast Track)" empfaenger: "DPM (Demand-to-Product-Prozess)" trigger: "Interner DIGIT-Bedarf erfordert neuen Service" status_im_steckbrief: "an_dpm_uebergeben_intern" beschreibung: | Interne Bedarfe von DIGIT-Mitarbeitern, die einen neuen Service erfordern, werden mit reduziertem Bedarfssteckbrief an DPM übergeben. DPM kann bei Bedarf Informationen nachfordern. validierungsprofil: "ROUTE-DPM-INTERN" # ============================================================================= # PROZESSABLAUF # ============================================================================= prozessablauf: beschreibung: | Der Prozess besteht aus einem vorgelagerten Schritt (Bedarfserhebung) und drei sequentiellen Prüfungen. Jede Prüfung führt entweder zu einem Routing-Ergebnis oder zur nächsten Prüfung. **Hinweis:** Für interne DIGIT-Mitarbeiter-Bedarfe gilt der vereinfachte Fast Track Prozess (siehe Abschnitt schritt_0a_fast_track_intern). # --------------------------------------------------------------------------- # SCHRITT 0a: FAST TRACK FÜR INTERNE DIGIT-BEDARFE # --------------------------------------------------------------------------- schritt_0a_fast_track_intern: name: "Fast Track für interne DIGIT-Bedarfe" leitfrage: "Ist der Bedarf durch einen bestehenden Service abdeckbar?" beschreibung: | Interne DIGIT-Mitarbeiter (z.B. Personalabteilung, Sekretariat, Sachbearbeiter in DIGIT) haben Bedarfe als Nutzer von IT-Services. Diese durchlaufen einen vereinfachten 3-Schritte-Prozess (10-15 Minuten), um SHM nicht unnötig zu belasten. **Abgrenzung:** Dieser Fast Track gilt für DIGIT-Mitarbeiter als *Nutzer*. Service Owner, die Bedarfe für ihren eigenen Service haben, nutzen die Service-Lifecycle-Wege (siehe shm_interne-bedarfe-routing.yaml). anwendungsbereich: gilt_fuer: - "DIGIT-Personalabteilung" - "DIGIT-Sekretariat" - "DIGIT-Sachbearbeiter (als Nutzer, nicht als SO)" - "Andere DIGIT-interne Organisationseinheiten" gilt_nicht_fuer: - "Service Owner (für eigenen Service) → Service-Lifecycle" - "ISB/Compliance → Sicherheits-/Compliance-Prozess" - "Externe Ämter → Regelweg (Schritt 0, Prüfungen 1-3)" eingangskanal: primaer: "Self-Service-Portal (ITSM-Tool)" mvp: "E-Mail-Template an SHM" pflichtfelder: - "Titel / Kurzbeschreibung" - "Kontaktperson und Abteilung" - "Problemstellung (2-3 Sätze)" - "Zielbild (1-2 Sätze)" - "Betroffene Systeme (falls bekannt)" - "Dringlichkeit (S/M/L)" prozess: schritt_1: name: "Basistriage" dauer: "3-5 Minuten" leitfrage: "Ist es ein valider Bedarf?" pruefungen: - "Ist der Bedarf verständlich formuliert?" - "Liegt er im Scope von DIGIT?" - "Ist die Kontaktperson erreichbar?" ergebnisse: - ergebnis: "valide" aktion: "Weiter zu Schritt 2" - ergebnis: "unklar" aktion: "Rückfrage an Einreichenden" status: "in_klaerung_intern" - ergebnis: "out_of_scope" aktion: "Ablehnung mit Begründung" schritt_2: name: "Routing-Entscheidung" dauer: "5-7 Minuten" leitfrage: "Wohin gehört der Bedarf?" pruefungen: - frage: "Gibt es einen bestehenden Service, der den Bedarf adressiert?" ja: "Direkt an Service Owner (kein Steckbrief)" nein: "Weiter prüfen" - frage: "Ist ein neuer Service oder grundlegende Änderung erforderlich?" ja: "ROUTE-DPM-INTERN (mit Minimaldoku)" nein: "Weiter prüfen" - frage: "Ist das Routing unklar?" ja: "ROUTE-SO (Service-Owner-Klärung)" ergebnisse: - ergebnis: "bestehender_service" routing: "Direkt an Service Owner" steckbrief_erforderlich: false beschreibung: "SO klärt: Change oder Ablehnung" - ergebnis: "neuer_service" routing: "ROUTE-DPM-INTERN" steckbrief_erforderlich: true profil: "ROUTE-DPM-INTERN (reduziert)" - ergebnis: "unklar" routing: "ROUTE-SO" steckbrief_erforderlich: true beschreibung: "Service-Owner-Klärung (bilateral)" schritt_3: name: "Minimaldokumentation" dauer: "3-5 Minuten" bedingung: "Nur bei ROUTE-DPM-INTERN" beschreibung: | SHM ergänzt eine kurze Einschätzung (2-3 Sätze) und übergibt an DPM. Der Bedarfssteckbrief ist reduziert (Profil ROUTE-DPM-INTERN). shm_einschaetzung_template: | - Quelle: Interner Bedarf aus Abt. [X] - Thema: [Kurzbeschreibung] - Service-Katalog: [Kein Service / Teilweise abgedeckt durch ...] - Größeneinschätzung: [S / M / L] - Besonderheiten: [Optional] validierungsprofil_route_dpm_intern: beschreibung: | Reduziertes Validierungsprofil für interne Bedarfe. DPM kann über die Rückkopplungsschleife Nachforderungen stellen. erforderlich: - "Basisdaten (vollständig)" - "Stakeholder-Kontext (automatisch: 'intern')" - "Bedarfsbeschreibung (Kernproblem + Zielbild)" - "Größeneinschätzung (S/M/L)" - "SHM-Einschätzung (2-3 Sätze)" - "Service-Katalog-Prüfung" nicht_erforderlich: - "User Stories (DPM fordert bei Bedarf nach)" - "Stakeholder-Freigabe (interner Mitarbeiter)" - "Detaillierte Abhängigkeiten (DPM fordert bei Bedarf nach)" - "Rahmenbedingungen (optional)" zeitrahmen: erstreaktion: "Innerhalb von 24-48 Stunden" gesamtdauer: "10-15 Minuten pro Bedarf" beispiele: - titel: "Personalabteilung DIGIT möchte neue Personalsoftware" situation: | Die Personalabteilung des DIGIT (als Nutzer) benötigt eine neue Software zur Zeiterfassung, da das aktuelle System nicht mehr den Anforderungen entspricht. fast_track_ablauf: schritt_1: "Valide – Bedarf verständlich, im Scope" schritt_2: "Kein bestehender Service → ROUTE-DPM-INTERN" schritt_3: "Minimaldoku: Interner Bedarf, neuer Service, Größe M" ergebnis: "An DPM mit reduziertem Steckbrief" - titel: "Stabsstelle Digital möchte Miro (obwohl Conceptboard existiert)" situation: | Die Stabsstelle Digital Freiburg fragt nach einem Miro-Zugang für kollaborative Workshops. fast_track_ablauf: schritt_1: "Valide – Bedarf verständlich" schritt_2: "Bestehender Service: Conceptboard → Direkt an SO" schritt_3: "Nicht erforderlich" ergebnis: | Direkt an Service Owner Conceptboard. SO klärt: Reicht Conceptboard aus oder fehlt eine Funktion (dann ggf. Change)? - titel: "DIGIT-Sekretariat benötigt Terminplanungstool" situation: | Das Sekretariat möchte ein Tool zur vereinfachten Terminplanung mit externen Besuchern. fast_track_ablauf: schritt_1: "Valide – Bedarf verständlich, im Scope" schritt_2: "Prüfung: Gibt es bereits ein Kalendertool mit Buchungsfunktion?" schritt_3: "Falls nein: ROUTE-DPM-INTERN mit Minimaldoku" ergebnis: "Abhängig von Service-Katalog-Prüfung" governance_referenz: "PATCH_NOTES_interne_bedarfe_v1.1.md" # --------------------------------------------------------------------------- # SCHRITT 0: BEDARFSERHEBUNG (REGELWEG FÜR EXTERNE STAKEHOLDER) # --------------------------------------------------------------------------- schritt_0: name: "Bedarfserhebung" leitfrage: "Was ist der tatsächliche Bedarf?" beschreibung: | Bevor geroutet werden kann, muss der Stakeholder-Manager den tatsächlichen Bedarf verstehen. Stakeholder formulieren oft Lösungen ("Wir brauchen eine Datenbank") statt Bedarfe ("Wir müssen Anträge zentral verwalten"). Die Kernaufgabe ist der Perspektivwechsel: Vom "Cheeseburger" zum "Hunger". methode: "User-Story-Erhebung" user_story_format: schema: "Als [Rolle] möchte ich [Funktionalität], um [Nutzen]" beispiel: rolle: "Sachbearbeiterin im Bauamt" funktionalitaet: "Bauanträge nach Flurstücknummer durchsuchen" nutzen: "zusammenhängende Anträge schnell identifizieren" leitfragen: - "Was möchten Sie in Ihrer täglichen Arbeit erreichen?" - "Beschreiben Sie einen typischen Arbeitsablauf, bei dem es hakt." - "Was würde Ihnen die Arbeit erleichtern?" - "Wobei verlieren Sie die meiste Zeit?" typische_uebersetzungen: - stakeholder_sagt: "Wir brauchen eine Datenbank" shm_fragt: "Was möchten Sie damit tun?" bedarf_wird: "Anträge zentral verwalten" - stakeholder_sagt: "Das System ist zu langsam" shm_fragt: "Wobei genau verlieren Sie Zeit?" bedarf_wird: "Suchergebnisse in unter 3 Sekunden erhalten" - stakeholder_sagt: "Wir wollen alles digitalisieren" shm_fragt: "Was genau soll digital werden?" bedarf_wird: "Anträge online einreichen können" output: "Qualifizierter Bedarf mit mindestens einer User Story" qualitaetskriterien: - "Rolle spezifisch identifiziert (nicht 'Nutzer')" - "Funktionalität klar beschrieben (keine Lösungsvorgabe)" - "Nutzen explizit gemacht" - "Mit Stakeholder validiert" arbeitsmaterial: dokument: "leitfaden_user-stories.md" pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/" status: "zu erstellen" # --------------------------------------------------------------------------- # PRÜFUNG 1: SERVICE-KATALOG-CHECK # --------------------------------------------------------------------------- pruefung_1: name: "Service-Katalog-Check" leitfrage: "Lässt sich der Bedarf mit dem bestehenden Katalog bedienen?" beschreibung: | Erste Triage: Ist der Bedarf bereits durch existierende Services abdeckbar? Diese Prüfung erfolgt auf Basis des Service-Katalogs und der dort definierten Leistungen. prueffragen: - id: "P1-Q1" frage: "Existiert ein Service im Katalog, der diesen Bedarf adressiert?" ja_bedeutet: "Potenziell abbildbar" nein_bedeutet: "Weiter zu P1-Q4" - id: "P1-Q2" frage: "Kann der Bedarf durch eine Standardleistung (Request) erfüllt werden?" ja_bedeutet: "Abbildbar → ROUTE-REQ" nein_bedeutet: "Weiter zu P1-Q3" - id: "P1-Q3" frage: "Liegt der Bedarf innerhalb der definierten Service-Parameter?" ja_bedeutet: "Teilweise abbildbar → Prüfung 2" nein_bedeutet: "Weiter zu P1-Q4" - id: "P1-Q4" frage: "Ist der Bedarf grundsätzlich neuartig für DIGIT?" ja_bedeutet: "Nicht abbildbar → Prüfung 3" nein_bedeutet: "Unklar → SOR-Eskalation erwägen" ergebnisse: - ergebnis: "abbildbar" routing: "ROUTE-REQ" aktion: "Weiterleitung an Service Desk / Request Fulfilment" steckbrief_erforderlich: false - ergebnis: "teilweise_abbildbar" routing: "Prüfung 2" aktion: "Change-Qualifizierung durchführen" steckbrief_erforderlich: true - ergebnis: "nicht_abbildbar" routing: "Prüfung 3" aktion: "Demand-Indikation prüfen" steckbrief_erforderlich: true dokumentation_im_steckbrief: feld: "servicekatalog_pruefung.pruefergebnis" begruendung_erforderlich_bei: "nicht_abbildbar" service_referenz_erforderlich_bei: ["abbildbar", "teilweise_abbildbar"] # --------------------------------------------------------------------------- # PRÜFUNG 2: CHANGE-QUALIFIZIERUNG # --------------------------------------------------------------------------- pruefung_2: name: "Change-Qualifizierung" leitfrage: "Ist ein bestehender Service betroffen und veränderbar?" vorbedingung: "Prüfung 1 ergab 'teilweise_abbildbar'" beschreibung: | Wenn ein bestehender Service den Bedarf teilweise adressiert, prüft der Stakeholder-Manager, ob es sich um einen Change an diesem Service handelt, der vom Service Owner bearbeitet werden kann. prueffragen: - id: "P2-Q1" frage: "Ist ein konkreter bestehender Service betroffen?" ja_bedeutet: "Weiter zu P2-Q2" nein_bedeutet: "Unklar → SOR" - id: "P2-Q2" frage: "Handelt es sich um eine Erweiterung/Anpassung innerhalb des Service-Scopes?" ja_bedeutet: "Weiter zu P2-Q3" nein_bedeutet: "Grundlegende Neugestaltung → Prüfung 3" - id: "P2-Q3" frage: "Ist der zuständige Service Owner identifizierbar?" ja_bedeutet: "Change → ROUTE-SPM" nein_bedeutet: "Unklar → Service-Owner-Klärung (ROUTE-SO)" ergebnisse: - ergebnis: "change_identifiziert" routing: "ROUTE-SPM" aktion: "Übergabe an Service Owner" status: "an_spm_uebergeben" - ergebnis: "kein_change" routing: "Prüfung 3" aktion: "Demand-Indikation prüfen" - ergebnis: "unklar" routing: "ROUTE-SO" aktion: "Service-Owner-Klärung einleiten (bilateral)" status: "in_so_klaerung" hinweis_abgrenzung: | Die Frage, ob der Change im Rahmen des Service Owners umsetzbar ist oder Projektcharakter hat, wird NICHT durch SHM bewertet. Diese Einschätzung trifft der Service Owner nach Übergabe. # --------------------------------------------------------------------------- # PRÜFUNG 3: DEMAND-INDIKATION # --------------------------------------------------------------------------- pruefung_3: name: "Demand-Indikation" leitfrage: "Handelt es sich um einen neuen Bedarf mit Projektcharakter?" vorbedingung: "Prüfung 1 ergab 'nicht_abbildbar' ODER Prüfung 2 ergab 'kein_change'" beschreibung: | Wenn der Bedarf weder über den Katalog noch als Change abbildbar ist, prüft der Stakeholder-Manager, ob die Voraussetzungen für eine Übergabe an DPM erfüllt sind. prueffragen: - id: "P3-Q1" frage: "Erfordert der Bedarf einen neuen Service oder eine grundlegende Neugestaltung?" ja_bedeutet: "Demand-Indikator positiv" nein_bedeutet: "Nochmal Prüfung 1/2 durchgehen oder ROUTE-SO" - id: "P3-Q2" frage: "Hat der Bedarf Projektcharakter (Einmaligkeit, definierter Scope)?" ja_bedeutet: "Demand-Indikator positiv" nein_bedeutet: "Möglicherweise wiederkehrender Prozess → ROUTE-SO" - id: "P3-Q3" frage: "Ist der Bedarfssteckbrief hinreichend befüllt für DPM-Übergabe?" ja_bedeutet: "Bereit für Übergabe → ROUTE-DPM" nein_bedeutet: "Nachqualifizierung erforderlich" demand_indikatoren: - "Neuer Service erforderlich (nicht im Katalog)" - "Grundlegende Neugestaltung eines bestehenden Service" - "Service-übergreifende Anforderung" - "Erheblicher Ressourcenbedarf (Projektcharakter)" - "Externe Abhängigkeiten (andere Behörden, Regulatorik)" ergebnisse: - ergebnis: "demand_bestaetigt" routing: "ROUTE-DPM" aktion: "Übergabe an DPM mit vollständigem Bedarfssteckbrief" status: "an_dpm_uebergeben" - ergebnis: "nachqualifizierung" routing: "Zurück zu Schritt 0" aktion: "Weitere Bedarfserhebung mit Stakeholder" - ergebnis: "unklar" routing: "ROUTE-SO" aktion: "Service-Owner-Klärung einleiten (bilateral)" status: "in_so_klaerung" # ============================================================================= # ROUTING-ENTSCHEIDUNGSBAUM (ÜBERSICHT) # ============================================================================= routing_entscheidungsbaum: visualisierung: | BEDARF GEHT EIN (roh) │ ▼ ┌─────────────────────────────────────┐ │ SCHRITT 0: Bedarfserhebung │ │ "Was ist der tatsächliche Bedarf?" │ │ → User Stories erarbeiten │ └─────────────────────────────────────┘ │ ▼ QUALIFIZIERTER BEDARF │ ▼ ┌─────────────────────────────────────┐ │ PRÜFUNG 1: Service-Katalog-Check │ │ "Lässt sich der Bedarf mit dem │ │ bestehenden Katalog bedienen?" │ └─────────────────────────────────────┘ │ ├── JA (abbildbar) ──────────────────► REQUEST FULFILMENT │ (Out of SHM Scope) │ ├── TEILWEISE ───────────────────────► PRÜFUNG 2 │ └── NEIN (nicht abbildbar) ──────────► PRÜFUNG 3 ┌─────────────────────────────────────┐ │ PRÜFUNG 2: Change-Qualifizierung │ │ "Ist ein bestehender Service │ │ betroffen und veränderbar?" │ └─────────────────────────────────────┘ │ ├── JA + Service Owner klar ─────────► SERVICE OWNER (SPM) │ Status: an_spm_uebergeben │ ├── NEIN (kein Change) ──────────────► PRÜFUNG 3 │ └── UNKLAR ──────────────────────────► SERVICE-OWNER-KLÄRUNG Status: in_so_klaerung (Pfad A: SO identifizierbar → direkt) (Pfad B: kein SO → SPM hilft → dann SO) │ SO-EMPFEHLUNG (keine Entscheidung) │ ├── RUN/Change ────► Parallel-Bearbeitung │ + formelle SOR-Bestätigung │ └── Demand ────────► Parallel-Bearbeitung + direkte DPM-Übergabe (kein DSR) ┌─────────────────────────────────────┐ │ PRÜFUNG 3: Demand-Indikation │ │ "Handelt es sich um einen neuen │ │ Bedarf mit Projektcharakter?" │ └─────────────────────────────────────┘ │ ├── JA + Steckbrief vollständig ─────► DPM │ Status: an_dpm_uebergeben │ ├── JA + Steckbrief unvollständig ───► NACHQUALIFIZIERUNG │ (zurück zu Schritt 0) │ └── UNKLAR ──────────────────────────► SERVICE-OWNER-KLÄRUNG Status: in_so_klaerung # ============================================================================= # SERVICE-OWNER-ROUTING-KLÄRUNG (ersetzt DSR-ROUTING-KLÄRUNG seit GOV-SHM-029) # ============================================================================= so_routing_klaerung: beschreibung: | Bei Routing-Unsicherheit erfolgt die Klärung bilateral über den zuständigen Service Owner. Der Service Owner gibt eine Empfehlung ab, ob der Bedarf als Change im bestehenden Service (RUN) umsetzbar ist oder ob es sich um einen neuen Demand handelt. Die SO-Empfehlung führt zu einer "als ob"-Weiterbearbeitung: Der Bedarf wird sofort und parallel bearbeitet, während die formelle Bestätigung in der nächsten SOR-Sitzung (Change) erfolgt; Demands gehen direkt an DPM. Dies gewährleistet Geschwindigkeit ohne Verzögerung durch Gremien-Rhythmen. Diese bilaterale Klärung ersetzt die bisherige direkte Eskalation direkt an den DPM und stellt sicher, dass die Service-Expertise frühzeitig eingebunden wird. referenz: "GOV-SHM-029" trigger_kriterien: beschreibung: | Service-Owner-Klärung ist angemessen, wenn der Stakeholder-Manager nach Durchlaufen der Prüfungen unsicher ist. Die Unsicherheit muss nicht objektiviert werden – das Urteil des Stakeholder-Managers reicht. typische_situationen: - "Service-Zuordnung nicht eindeutig (mehrere Services betroffen)" - "Unklar, ob Change oder neuer Demand" - "Bedarf liegt an Schnittstelle SPM/DPM" - "Stakeholder und SHM sind sich über Routing uneinig" ablauf: pfad_a: name: "Service Owner identifizierbar" beschreibung: | SHM prüft das Service-Portfolio und identifiziert einen zuständigen Service Owner. SHM kontaktiert den SO direkt und schildert den Bedarf. Der SO prüft und entscheidet. schritte: - schritt: 1 akteur: "SHM" aktion: "Service-Portfolio prüfen, zuständigen SO identifizieren" - schritt: 2 akteur: "SHM" aktion: "SO kontaktieren mit Bedarfsbeschreibung" - schritt: 3 akteur: "SO" aktion: "Prüfen und Routing-Empfehlung abgeben (RUN vs. Demand)" pfad_b: name: "Kein Service Owner identifizierbar" beschreibung: | SHM kann im Service-Portfolio keinen eindeutigen SO zuordnen. SHM kontaktiert SPM, um den betroffenen Service und den zuständigen SO zu identifizieren. Anschließend wird der SO einbezogen. schritte: - schritt: 1 akteur: "SHM" aktion: "SPM kontaktieren zur Service-Identifikation" - schritt: 2 akteur: "SPM" aktion: "Service identifizieren, zuständigen SO benennen" - schritt: 3 akteur: "SHM + SO" aktion: "SO einbeziehen, Bedarf besprechen" - schritt: 4 akteur: "SO" aktion: "Prüfen und Routing-Empfehlung abgeben (RUN vs. Demand)" fallback: | Wenn auch SPM keinen passenden Service identifizieren kann, ist dies ein starker Indikator für einen neuen Demand (ROUTE-DPM), da kein bestehender Service den Bedarf abdeckt. so_empfehlung: prozessmodell: | Die SO-Empfehlung folgt einem Drei-Schritt-Modell: 1. SO gibt Empfehlung ab (RUN/Change oder Demand) 2. Bedarf wird sofort "als ob" weiterbearbeitet (parallel-Bearbeitung) 3. Formelle Bestätigung: SOR (Change); Demand direkt an DPM Dies ermöglicht schnelle Weiterbearbeitung ohne Warten auf Gremium. optionen: - ergebnis: "RUN/Change" beschreibung: "Bedarf ist als Change im bestehenden Service umsetzbar" routing: "ROUTE-SPM" empfaenger: "SOR (Service Operations Runde) für Implementierung" status: "an_spm_uebergeben" als_ob_bearbeitung: "Der Change wird sofort im RUN-Prozess bearbeitet; formelle SOR-Bestätigung folgt" - ergebnis: "Demand" beschreibung: "Bedarf erfordert neuen Service oder grundlegende Neugestaltung" routing: "ROUTE-DPM" empfaenger: "DPM nimmt Demand direkt entgegen (kein DSR-Weg)" status: "an_dpm_uebergeben" als_ob_bearbeitung: "Der Demand wird sofort im DPM-Prozess bearbeitet; keine DSR-Bestätigung nötig" - ergebnis: "Kleine Changes (SO-direkt)" beschreibung: "Bedarf ist als kleine Change direkt umsetzbar (kein SOR nötig)" routing: "ROUTE-SO-DIREKT" empfaenger: "SO führt Change selbständig durch" status: "in_so_umsetzung" als_ob_bearbeitung: "SO umsetzt die kleine Change direkt; nachträgliche Dokumentation in nächster SOR" - ergebnis: "Rückgabe" beschreibung: "SO benötigt weitere Informationen" routing: "Zurück zu SHM" empfaenger: "SHM zur Nachqualifizierung" status: "in_qualifizierung" dokumentation: | Die SO-Routing-Empfehlung wird im Bedarfssteckbrief dokumentiert (Feld: so_routing_empfehlung) mit Angabe des SO, Datum, Empfehlung (RUN/Change oder Demand) und Begründung. formelle_bestaetigung: | Die formelle Bestätigung erfolgt in der nächsten zuständigen Gremium-Sitzung: - RUN/Change: SOR (Service Operations Runde) unter Vorsitz SPM - Demand: Direkt an DPM (kein DSR-Routing). DSR nur für Portfolio-Governance Das Gremium kann: - Die SO-Empfehlung bestätigen → Weiterbearbeitung wird formalisiert - Die SO-Empfehlung ablehnen → MUSS mit formal begründeten Argumenten erfolgen (kein "Bauchgefühl"), z.B. Ressourcen, Strategie, Abhängigkeiten Bei Ablehnung durch Gremium: SO oder SHM können zur Mission Board eskalieren und die Übersteuerung hinterfragen. eskalation: stufe_1: beschreibung: "SO und SHM können sich nicht einigen" aktion: "Einbindung der Leitung SHM und SPM" stufe_2: beschreibung: "Gremium (SOR) überstimmt SO-Empfehlung" aktion: | Übersteuerung MUSS formal begründet werden. Zulässige Begründungen: - Ressourcen-Constraints (z.B. SOR: Change passt zeitlich nicht) - Strategische Neugewichtung (z.B. DPM: andere Demands prioritärer) - Abhängigkeiten (z.B. andere Services betroffen) - Governance-Gründe (z.B. Eskalation im DPM erforderlich) NICHT zulässig: "Bauchgefühl", "war immer so", ohne Argumentation fallback: | Wenn Gremium-Ablehnung nicht begründet ist, oder wenn SO/SHM die Begründung nicht akzeptieren, können sie zur Mission Board eskalieren und die Übersteuerung anfechten. referenz: "GOV-MB-001" stufe_3: beschreibung: "Mission Board muss Gremium-Übersteuerung bewerten" aktion: "Eskalation an Mission Board" referenz: "GOV-MB-001" # ============================================================================= # STAKEHOLDER-KONTEXT # ============================================================================= stakeholder_kontext: beschreibung: | Der Stakeholder-Kontext aus dem Stakeholder-Portfolio liefert Hintergrundinformationen für die Bedarfsbewertung. Er beeinflusst NICHT das Routing, aber die Bearbeitungspriorität. relevante_attribute: - attribut: "stakeholder_prioritaet" quelle: "Amts-Steckbrief (automatisch)" werte: ["Key", "Aktiv", "Standard", "Basis"] routing_relevant: false priorisierung_relevant: true verwendung: | Die Priorität bestimmt, wie schnell der Bedarf bearbeitet wird und wie intensiv SHM im weiteren Prozess involviert bleibt (vgl. Engagement-Framework, Eskalationspfade). - attribut: "it_anforderungsprofil" quelle: "Amts-Steckbrief (automatisch)" werte: ["Basis", "Erweitert", "Spezial"] routing_relevant: false priorisierung_relevant: false verwendung: | Das IT-Anforderungsprofil gibt Kontext zur typischen Bedarfskomplexität des Stakeholders. Ein "Spezial"-Amt hat erwartbar komplexere Bedarfe als ein "Basis"-Amt. ergaenzung_bedarfssteckbrief: hinweis: | Diese Attribute sollten im Bedarfssteckbrief-Schema ergänzt werden (Abschnitt: Stakeholder-Kontext). Sie werden automatisch aus dem Amts-Steckbrief übernommen. schema_ergaenzung: - feld: "stakeholder_prioritaet" datentyp: "enum" quelle: "automatisch aus Amts-Steckbrief" - feld: "it_anforderungsprofil" datentyp: "enum" quelle: "automatisch aus Amts-Steckbrief" # ============================================================================= # PROZESSINTEGRATION # ============================================================================= prozessintegration: # --------------------------------------------------------------------------- # EINGANGSKANÄLE # --------------------------------------------------------------------------- eingangskanäle: beschreibung: | Die Bedarfsbewertung ist kanal-agnostisch. Der Prozess ist identisch, unabhängig davon, wie der Bedarf eingeht. kanäle: - kanal: "Turnusgespräch" typ: "proaktiv" beschreibung: "SHM erhebt Bedarfe aktiv im Rahmen der Regelkommunikation" - kanal: "Anfrage per E-Mail/Telefon" typ: "reaktiv" beschreibung: "Stakeholder meldet sich direkt beim Stakeholder-Manager" - kanal: "Weiterleitung vom Service Desk" typ: "eskaliert" beschreibung: "L1 kann Bedarf nicht lösen, eskaliert an SHM" - kanal: "Auftraggeber-Forum / Advisory Board" typ: "proaktiv" beschreibung: "Bedarfe werden in Cluster-Formaten identifiziert" eingangserfassung: | Unabhängig vom Kanal wird der Bedarf initial im Ticketsystem erfasst und erhält eine Bedarfs-ID. Der Bedarfssteckbrief wird angelegt. # --------------------------------------------------------------------------- # ZEITRAHMEN # --------------------------------------------------------------------------- zeitrahmen: beschreibung: | Es gibt keine harten SLA-Zeiten für die Bedarfsbewertung. Die Bearbeitungsgeschwindigkeit orientiert sich an der Stakeholder-Priorität. orientierungswerte: key_stakeholder: "Erstreaktion innerhalb 1 Arbeitstag" aktiv_stakeholder: "Erstreaktion innerhalb 2 Arbeitstagen" standard_basis_stakeholder: "Erstreaktion innerhalb 1 Woche" hinweis: | Diese Werte sind Orientierung, keine verbindlichen SLAs. Verbindliche Zeiten werden ggf. im Performance-Review (Phase 6) auf Basis empirischer Daten definiert. # --------------------------------------------------------------------------- # DOKUMENTATIONSPFLICHTEN # --------------------------------------------------------------------------- dokumentationspflichten: waehrend_bedarfserhebung: - "User Stories im Bedarfssteckbrief dokumentieren" - "Gesprächsprotokolle verlinken" - "Stakeholder-Validierung einholen" bei_routing_entscheidung: - "Prüfergebnis dokumentieren (Katalog-Check)" - "Begründung bei 'nicht_abbildbar'" - "Service-Referenz bei 'abbildbar' oder 'teilweise_abbildbar'" - "SHM-Einschätzung bei DPM-Übergabe" bei_so_routing_klaerung: - "Eigene Einschätzung dokumentieren" - "Service-Portfolio-Prüfung dokumentieren (SO identifiziert / nicht identifiziert)" - "SO-Routing-Entscheidung nachträglich eintragen (RUN vs. Demand)" - "Bei SPM-Einbindung (Pfad B): SPM-Rückmeldung dokumentieren" # ============================================================================= # ABGRENZUNG ZU ANDEREN FUNKTIONEN # ============================================================================= abgrenzung: service_desk: beschreibung: | Der Service Desk (L1) ist die erste Anlaufstelle für Standard-Anfragen. Er prüft, ob ein Request/Incident über den Katalog lösbar ist. schnittstelle: | Wenn der Service Desk einen Bedarf nicht lösen kann und dieser über einen einfachen Request hinausgeht, eskaliert er an SHM. abgrenzung: | Service Desk: "Kann ich das aus dem Katalog bedienen?" SHM: "Ist das ein Change, ein Demand, oder unklar?" service_owner: beschreibung: | Der Service Owner ist verantwortlich für einen konkreten Service. Er bearbeitet Changes an seinem Service. schnittstelle: | SHM übergibt Changes mit dem Bedarfssteckbrief an den Service Owner. Die technische Bewertung (Machbarkeit, Aufwand) erfolgt beim SO. abgrenzung: | SHM entscheidet: "Geht das zum Service Owner?" SO gibt Empfehlung ab: "Kann/will ich das umsetzen? (RUN/Change oder Demand?)" Formelle Entscheidung: SOR (RUN/Change); Demand direkt an DPM dpm: beschreibung: | Das Demand Portfolio Management bearbeitet qualifizierte Demands im Demand-to-Product-Prozess. schnittstelle: | SHM übergibt Demands mit vollständigem Bedarfssteckbrief. DPM klassifiziert und priorisiert den Demand intern. abgrenzung: | SHM entscheidet: "Ist das ein Demand?" DPM entscheidet: "Wie wird der Demand priorisiert und bearbeitet?" spm: beschreibung: | Das Service Portfolio Management steuert das Service-Portfolio. Es ist nicht operativ in die Bedarfsbewertung involviert. schnittstelle: | SPM stellt den Service-Katalog bereit, gegen den SHM prüft. Bei SOR-Eskalationen ist SPM im Gremium vertreten. abgrenzung: | SPM: "Welche Services gibt es?" SHM: "Passt dieser Bedarf zu einem Service?" # ============================================================================= # GOVERNANCE-ENTSCHEIDUNGEN # ============================================================================= governance_entscheidungen: beschreibung: | Die folgenden Governance-Entscheidungen wurden während der Entwicklung dieser Methodik getroffen und werden ins Governance-Entscheidungs-Log übertragen. entscheidungen: - id: GOV-SHM-016 datum: 2025-12-09 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. status: final - id: GOV-SHM-017 datum: 2025-12-09 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. status: final nachtrag: datum: "2025-12-17" hinweis: | Demand-Routing erfolgt direkt an DPM (GOV-SHM-029). Seit GOV-SHM-029 (2026-03-04) erfolgt die Routing-Klärung bilateral über den Service Owner (ROUTE-SO). nachtrag_2: datum: "2026-03-04" hinweis: | Routing-Klärung erfolgt jetzt bilateral über den Service Owner (nicht mehr über DSR). Siehe GOV-SHM-029. - id: GOV-SHM-029 datum: 2026-03-04 frage: "Wie wird bei Routing-Unsicherheit (Change vs. Demand) vorgegangen?" entscheidung: | Bei Routing-Unsicherheit prüft SHM zunächst das Service-Portfolio auf einen zuständigen Service Owner (SO). Pfad A: Wenn ein SO identifizierbar ist, wird dieser direkt kontaktiert. Der SO entscheidet, ob der Bedarf als Change im RUN umsetzbar ist oder als Demand weitergeleitet wird. Pfad B: Wenn kein SO identifizierbar ist, wird SPM eingebunden, um den betroffenen Service und den zuständigen SO zu finden. Anschließend entscheidet der SO wie in Pfad A. Nach SO-Entscheidung: - RUN/Change: SOR ist zuständig für die Implementierung. - Demand: DPM nimmt direkt entgegen (kein DSR-Umweg). Eskalation: Mission Board, falls DPM den Demand nicht akzeptiert. begruendung: | Die bisherige direkte Eskalation an die DSR (ROUTE-DSR) wurde als zu formalisiert bewertet. Der Service Owner hat die fachliche Expertise, um die Routing-Entscheidung zu treffen. Die bilaterale Klärung ist schneller und nutzt die vorhandene Service-Kompetenz. SPM dient als Brücke zum SO, wenn die Zuordnung nicht direkt möglich ist. ersetzt: "ROUTE-DSR (DSR als Routing-Klärungsgremium)" status: final quelle: "Workshop Bedarfsrouting-Klärung, 2026-03-04" - id: GOV-SHM-018 datum: 2025-12-09 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?" status: final - id: GOV-SHM-019 datum: 2025-12-09 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. status: final # ============================================================================= # OFFENE PUNKTE # ============================================================================= offene_punkte: - id: "OPEN-BEW-003" beschreibung: "Checkliste Bedarfsbewertung aus Prüffragen ableiten" prioritaet: "mittel" ziel_pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/checkliste_bedarfsbewertung.md" - id: "OPEN-BEW-004" beschreibung: "Integration mit DSR-Prozess für Routing-Klärung" prioritaet: "erledigt" erledigt_am: "2025-12-17" ergebnis: | Routing-Klärungen erfolgten zunächst über ROUTE-DSR (GOV-SOR-001). Seit 2026-03-04 ersetzt durch ROUTE-SO (Service-Owner-Klärung). Siehe GOV-SHM-029. nachtrag: datum: "2026-03-04" hinweis: "ROUTE-DSR durch ROUTE-SO ersetzt (GOV-SHM-029)" # ============================================================================= # ÄNDERUNGSHISTORIE # ============================================================================= aenderungshistorie: - version: "1.0" datum: "2025-12-09" aenderung: "Initiale Erstellung" autor: "DIGITOM-Projekt" quelle: "Chat-Session SHM Phase 3" - version: "1.1" datum: "2025-01-29" aenderung: | Geltungsbereich explizit gemacht (GOV-SHM-026): - Klarstellung: Bedarfsbewertung gilt für Stakeholder-initiierte Bedarfe - Querverweis auf shm_d2p-integration.yaml#abgrenzung_bedarfsquellen autor: "DIGITOM-Projekt" quelle: "Chat-Session Konzeptprüfung" - version: "1.2" datum: "2025-01-29" aenderung: | Ergänzung Klarstellung für Service Owner im Geltungsbereich: - Expliziter Hinweis: Service Owner mit eigenem Change-/Redesign-Bedarf nutzen interne Wege (SOR, DPM), nicht SHM-Bedarfsbewertung - SHM wird bei Stakeholder-Auswirkungen informiert autor: "DIGITOM-Projekt" quelle: "Chat-Session Konzeptprüfung" - version: "1.3" datum: "2025-01-29" aenderung: | Fast Track für interne DIGIT-Bedarfe implementiert: - Geltungsbereich: Drei Bedarfstypen unterschieden (extern, intern-Nutzer, Service-Lifecycle) - Neuer Abschnitt: schritt_0a_fast_track_intern (10-15 min Prozess) - Neuer Routing-Pfad: ROUTE-DPM-INTERN mit reduziertem Validierungsprofil - Neue Status-Werte: in_klaerung_intern, an_dpm_uebergeben_intern - Beispiele: Personalabteilung DIGIT, Stabsstelle Digital (Miro/Conceptboard) - Referenz: PATCH_NOTES_interne_bedarfe_v1.1.md autor: "DIGITOM-Projekt" quelle: "Chat-Session Konzeptprüfung" - version: "2.0" datum: "2026-03-05" aenderung: | Routing-Klärung bei Unsicherheit grundlegend überarbeitet (GOV-SHM-029): KONZEPTUELLE REFINEMENT: SO gibt Routing-EMPFEHLUNG, nicht finale Entscheidung - ROUTE-DSR durch ROUTE-SO (Service-Owner-Klärung) ersetzt - Neuer bilateraler Klärungsprozess über Service Owner: Pfad A: SO identifizierbar → direkt kontaktieren → SO gibt Empfehlung Pfad B: Kein SO identifizierbar → SPM einbinden → SO identifizieren → SO gibt Empfehlung - Drei-Schritt-Modell: 1. SO gibt Routing-Empfehlung ab (RUN/Change oder Demand) 2. Bedarf wird "als ob" sofort weiterbearbeitet (Parallel-Prozess) 3. Formelle Bestätigung: SOR (Change); Demand direkt an DPM - Formelle Entscheidung erfolgt in Gremien: RUN/Change → SOR (Service Operations Runde, Vorsitz SPM) Demand → DSR (Demand Screening Runde, Vorsitz DPM) - Kleine Changes können vom SO direkt ohne SOR durchgeführt werden - Gremium-Übersteuerung der SO-Empfehlung ist nur mit formal begründeten Argumenten zulässig - Eskalation: Mission Board bei nicht begründeter Gremium-Ablehnung oder bei Unstimmigkeiten - Status "bereit_fuer_dsr" durch "in_so_klaerung" ersetzt - Sektion "so_entscheidung" in "so_empfehlung" umbenannt - Neue Subsektionen: formelle_bestaetigung, erweiterte Eskalations-Stufen - GOV-SOR-001 wird durch GOV-SHM-029 ersetzt/ergänzt - Dokumentationspflichten angepasst autor: "DIGITOM-Projekt" quelle: "Workshop Bedarfsrouting-Klärung, 2026-03-05"