# ============================================================================= # SCHEMA: BEDARFS-STECKBRIEF # ============================================================================= # # Dieses Schema definiert die Struktur eines Bedarfs-Steckbriefs. # Der Bedarfs-Steckbrief dokumentiert den qualifizierten Bedarf zum # Übergabezeitpunkt von SHM an DPM (oder SOR für Service-Routing). # # Verantwortung: # - Erstellung: Stakeholder-Management (SHM) # - Validierung: Stakeholder # - Empfänger: DPM (nach SOR-Entscheidung) oder SPM (bei Service-Routing) # # Abgrenzung: # - Bedarfs-Steckbrief = SHM-Verantwortung (Vorqualifizierung) # - Demand-Entscheidungsvorlage = DPM-Verantwortung (Qualifizierung) # # Quelle: Konzept_DPM_Abnahme20230925, Seiten 106-112 # ============================================================================= schema: name: "Bedarfs-Steckbrief" version: "1.3" status: "abgenommen" gueltig_ab: "[Datum]" geltungsbereich: "DIGITOM / Demand-to-Project-Prozess" status_dokument: ueberprueft_durch: "DPM-Teammitglied" ueberprueft_durch_shm: true feedback_eingeholt: - "stichprobenartig in Betrieb" - "in Abt. Planung" abgestimmt_zwischen: ["human", "DPM-Teammitglied"] inhaltlich_abgenommen_durch: ["DPM-Teammitglied", "DPM-Leitung"] abnahmedatum: "17.09.2025" zweck: | Dieser Steckbrief dokumentiert den qualifizierten Bedarf zum Übergabezeitpunkt. Die detaillierte Analyse erfolgt im DPM-Prozess. verantwortung: erstellung: "Stakeholder-Management (SHM)" qualitaetssicherung: "Stakeholder-Manager:in" validierung: "Stakeholder" freigabe: "Stakeholder + SHM" lifecycle_kontext: phase: "Phase 1 - Initiierung und Erfassung" erstellt_in: "Schritt 1.5 - Bedarfsklärungsgespräch" finalisiert_in: "Schritt 1.6 - User Story Erstellung" uebergabe_in: "Schritt 1.7 - Demand-Übergabe (Quality Gate 1)" referenz: "demand-lifecycle-blueprint_phase-1.yaml" # ============================================================================= # ABSCHNITT 1: BASISDATEN # ============================================================================= abschnitte: basisdaten: name: "Basisdaten" beschreibung: "Identifikation und Metadaten des Bedarfs" felder: - id: "bedarfs_id" name: "Bedarfs-ID" datentyp: "string" pflicht: true quelle: "automatisiert aus Ticketsystem" beispiel: "BED-2025-0042" hinweis: "Optimalerweise automatisiert vergeben" - id: "bedarfs_titel" name: "Bedarfs-Titel" datentyp: "string" pflicht: true max_laenge: 100 beispiel: "Digitalisierung Baugenehmigungsverfahren" - id: "kurzbeschreibung" name: "Kurzbeschreibung des Bedarfs" datentyp: "text" pflicht: true max_laenge: 500 hinweis: "Prägnante Zusammenfassung in 2-3 Sätzen" - id: "eingereicht_von" name: "Eingereicht von (Stakeholder)" datentyp: "object" pflicht: true struktur: - feld: "name" datentyp: "string" pflicht: true - feld: "amt" datentyp: "string" pflicht: true - feld: "abteilung" datentyp: "string" pflicht: false - id: "eingangsdatum" name: "Eingangsdatum" datentyp: "date" format: "tt.mm.jjjj" pflicht: true - id: "bearbeitender_shm" name: "Bearbeitende:r Stakeholdermanager:in" datentyp: "string" pflicht: true referenz: "shm_rolle" - id: "ticket_referenz" name: "Ticket-Referenz" datentyp: "url" pflicht: true hinweis: "Link zu Ticketsystem" - id: "status" name: "Status" datentyp: "enum" pflicht: true werteliste: - wert: "in_qualifizierung" label: "in Qualifizierung" beschreibung: "SHM arbeitet am Steckbrief" - wert: "in_so_klaerung" label: "in Service-Owner-Klärung" beschreibung: "Routing-Entscheidung Change vs. Demand steht aus – Service Owner klärt bilateral" - wert: "an_spm_uebergeben" label: "an Service-Portfolio-Management übergeben" beschreibung: "Change-Routing entschieden (SO oder direkt SHM)" - wert: "an_dpm_uebergeben" label: "an Demand-Portfolio-Management übergeben" beschreibung: "DSR hat Demand-Routing entschieden" default: "in_qualifizierung" - id: "shm_einschaetzung" name: "Stakeholdermanagement-Einschätzung / -Anmerkung" datentyp: "text" pflicht: true pflicht_bedingung: "status = 'an_dpm_uebergeben'" hinweis: "Kurze qualitative Einschätzung: Besonderheiten, Risiken und Empfehlung für DPM" max_laenge: 1000 # ============================================================================= # ABSCHNITT 1b: STAKEHOLDER-KONTEXT # ============================================================================= stakeholder_kontext: name: "Stakeholder-Kontext" beschreibung: "Informationen aus dem Stakeholder-Portfolio (automatisch übernommen)" referenz: "shm_schema_amtssteckbrief.yaml" felder: - id: "stakeholder_prioritaet" name: "Stakeholder-Priorität" datentyp: "enum" pflicht: true quelle: "automatisch aus Amts-Steckbrief" werteliste: - wert: "key" label: "Key" beschreibung: "Strategisch wichtigste Stakeholder" - wert: "aktiv" label: "Aktiv" beschreibung: "Wichtige Stakeholder mit regelmäßiger Betreuung" - wert: "standard" label: "Standard" beschreibung: "Stakeholder mit punktuellem Betreuungsbedarf" - wert: "basis" label: "Basis" beschreibung: "Stakeholder mit reaktiver Betreuung" routing_relevant: false priorisierung_relevant: true hinweis: "Beeinflusst Bearbeitungsgeschwindigkeit, nicht Routing-Ziel" - id: "it_anforderungsprofil" name: "IT-Anforderungsprofil" datentyp: "enum" pflicht: true quelle: "automatisch aus Amts-Steckbrief" werteliste: - wert: "basis" label: "Basis" beschreibung: "Standardbedarf, Grundausstattung reicht" spm_korrespondenz: "Kategorie A" - wert: "erweitert" label: "Erweitert" beschreibung: "Fachspezifische Bedarfe über Standard hinaus" spm_korrespondenz: "Kategorie B" - wert: "spezial" label: "Spezial" beschreibung: "Individuelle Bedarfe nur für dieses Amt" spm_korrespondenz: "Kategorie C" routing_relevant: false hinweis: "Gibt Kontext zur typischen Bedarfskomplexität des Stakeholders" # ============================================================================= # ABSCHNITT 2: BEDARFSBESCHREIBUNG # ============================================================================= bedarfsbeschreibung: name: "Bedarfsbeschreibung" beschreibung: "Situationsanalyse und Problemdefinition" unterabschnitte: situationsanalyse: name: "Situationsanalyse" felder: - id: "ausgangssituation" name: "Ausgangssituation" datentyp: "text" pflicht: true leitfragen: - "Wie ist der aktuelle Zustand?" - "Um was geht es?" - "Wie funktioniert es heute?" - id: "kernproblem" name: "Kernproblem" datentyp: "text" pflicht: true leitfragen: - "Was genau funktioniert nicht oder fehlt?" - "Worin besteht die Herausforderung?" - id: "auswirkungen" name: "Auswirkungen" datentyp: "text" pflicht: true leitfragen: - "Welche konkreten negativen Effekte entstehen durch das Problem?" - id: "zielbild" name: "Zielbild" datentyp: "text" pflicht: true hinweis: "Kurzfassung: Wie soll die Situation nach der Lösung aussehen?" # ============================================================================= # ABSCHNITT 3: NUTZEN # ============================================================================= nutzen: name: "Nutzen / Erwarteter Mehrwert / Public Value" beschreibung: "Erwartete Wertbeiträge des Bedarfs" felder: - id: "primaernutzen" name: "Primärnutzen" datentyp: "text" pflicht: true beschreibung: "Hauptnutzen für die anfragende Stelle" - id: "sekundaernutzen" name: "Sekundärnutzen" datentyp: "text" pflicht: false beschreibung: "Weitere positive Effekte oder andere Profiteure" beispiele: - "Auswirkung auf Mitarbeiterzufriedenheit" - "Effizienzgewinne in anderen Bereichen" - id: "public_value" name: "Public Value" datentyp: "text" pflicht: false beschreibung: "Nutzen für Bürger:innen oder Gemeinwohl" hinweis: "Falls relevant" - id: "innovationsbeitrag" name: "Innovationsbeitrag" datentyp: "object" pflicht: false struktur: - feld: "vorhanden" datentyp: "boolean" - feld: "beschreibung" datentyp: "text" pflicht_bedingung: "vorhanden = true" leitfrage: "Welche neuen Möglichkeiten ergeben sich?" # ============================================================================= # ABSCHNITT 4: USER STORIES # ============================================================================= user_stories: name: "User Stories" beschreibung: "Dokumentation der Bedarfe aus Nutzerperspektive" referenz_leitfaden: titel: "Leitfaden: User Stories im DIGIT aufnehmen" pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/leitfaden_user-stories.yaml" felder: - id: "stories" name: "User Stories" datentyp: "array" pflicht: true min_eintraege: 1 element_struktur: - feld: "rolle" name: "Als" datentyp: "string" pflicht: true beschreibung: "Rolle/Bereich des Nutzers" beispiel: "Sachbearbeiter:in Bauamt" - feld: "funktionalitaet" name: "möchte ich" datentyp: "string" pflicht: true beschreibung: "Gewünschte Funktionalität/Lösung" beispiel: "Bauanträge digital einreichen können" - feld: "nutzen" name: "um" datentyp: "string" pflicht: true beschreibung: "Nutzen/Ziel zu erreichen" beispiel: "Bearbeitungszeiten zu reduzieren" # ============================================================================= # ABSCHNITT 5: RAHMENBEDINGUNGEN # ============================================================================= rahmenbedingungen: name: "Rahmenbedingungen" beschreibung: "Zeitliche und organisatorische Randbedingungen" unterabschnitte: zeitliche_aspekte: name: "Zeitliche Aspekte" felder: - id: "harte_deadline" name: "Harte Deadline" datentyp: "object" pflicht: false struktur: - feld: "datum" datentyp: "date" format: "tt.mm.jjjj" - feld: "begruendung" datentyp: "text" pflicht: true hinweis: "Erläuterung / Begründung der Deadline" - id: "gewuenschter_termin" name: "Gewünschter Termin" datentyp: "object" pflicht: false struktur: - feld: "datum" datentyp: "date" format: "tt.mm.jjjj" - feld: "begruendung" datentyp: "text" hinweis: "Erläuterung / Begründung" - id: "zeitliche_begruendung" name: "Begründung" datentyp: "text" pflicht: false leitfrage: "Warum diese Einschätzung?" # ============================================================================= # ABSCHNITT 6: ABHÄNGIGKEITEN & CONSTRAINTS # ============================================================================= abhaengigkeiten: name: "Abhängigkeiten & Constraints/Auflagen" beschreibung: "Interne und externe Abhängigkeiten, betroffene Systeme" unterabschnitte: interne_beteiligte: name: "Interne Beteiligte / Abhängigkeiten" felder: - id: "dx_office_abstimmung" name: "Abstimmung mit DX-Office erforderlich" datentyp: "boolean" pflicht: true default: false - id: "digit_intern_beteiligte" name: "DIGIT-intern beteiligte/r Bereich/Funktionen" datentyp: "array" pflicht: false element_struktur: - feld: "bereich" name: "Name des Bereichs / der Funktion" datentyp: "string" pflicht: true - feld: "erlaeuterung" name: "Erläuterung der Beteiligung / Abhängigkeit" datentyp: "text" pflicht: true externe_beteiligte: name: "Externe Beteiligte / externe Abhängigkeiten" felder: - id: "datenschutz_beteiligung" name: "Beteiligung Datenschutz erforderlich" datentyp: "boolean" pflicht: true default: false - id: "stadtkaemmerei_beteiligung" name: "Beteiligung Stadtkämmerei erforderlich" datentyp: "boolean" pflicht: true default: false - id: "digit_externe_aemter" name: "DIGIT-externe Ämter/Funktionen" datentyp: "array" pflicht: false element_struktur: - feld: "amt" name: "Name des Amts / der Funktion" datentyp: "string" pflicht: true - feld: "erlaeuterung" name: "Erläuterung der Beteiligung / Abhängigkeit" datentyp: "text" pflicht: true - id: "andere_behoerden" name: "Andere Behörden" datentyp: "array" pflicht: false element_struktur: - feld: "behoerde" name: "Name der Behörde" datentyp: "string" pflicht: true - feld: "erlaeuterung" name: "Erläuterung der Beteiligung / Abhängigkeit" datentyp: "text" pflicht: true - id: "regulatorisch" name: "Regulatorisch" datentyp: "array" pflicht: false element_struktur: - feld: "vorgabe" name: "Bezeichnung der Regulatorischen Vorgabe / Abhängigkeit" datentyp: "string" pflicht: true - feld: "erlaeuterung" name: "Erläuterung der Abhängigkeit / Frist / Vorgabe" datentyp: "text" pflicht: true - id: "externe_dienstleister" name: "Externe Dienstleister / Lieferanten" datentyp: "array" pflicht: false element_struktur: - feld: "dienstleister" name: "Name des Dienstleisters / Lieferanten" datentyp: "string" pflicht: true - feld: "erlaeuterung" name: "Erläuterung der Beteiligung / Abhängigkeit" datentyp: "text" pflicht: true - id: "weitere_externe" name: "Weitere" datentyp: "array" pflicht: false element_struktur: - feld: "bezeichnung" name: "Bezeichnung des Beteiligten / der Abhängigkeit" datentyp: "string" pflicht: true - feld: "erlaeuterung" name: "Erläuterung der Beteiligung / Abhängigkeit" datentyp: "text" pflicht: true betroffene_systeme: name: "Betroffene Systeme" felder: - id: "systeme" name: "System / Komponente" datentyp: "array" pflicht: false element_struktur: - feld: "system" name: "Name des Systems / der Komponente" datentyp: "string" pflicht: true - feld: "erlaeuterung" name: "Erläuterung der Abhängigkeit / des Zusammenhangs" datentyp: "text" pflicht: true thematische_abhaengigkeiten: name: "Thematische Abhängigkeiten" felder: - id: "projekte_themen" name: "Projekte / Themen" datentyp: "array" pflicht: false element_struktur: - feld: "projekt" name: "Name des Projekts / Themas" datentyp: "string" pflicht: true - feld: "erlaeuterung" name: "Erläuterung der Abhängigkeit / des Zusammenhangs" datentyp: "text" pflicht: true # ============================================================================= # ABSCHNITT 7: ERSTE GRÖßENEINSCHÄTZUNG # ============================================================================= groesseneinschaetzung: name: "Erste Größeneinschätzung" beschreibung: "Initiale Aufwandsschätzung durch SHM" felder: - id: "geschaetzter_aufwand" name: "Geschätzter Aufwand" datentyp: "enum" pflicht: true werteliste: - wert: "gering" label: "GERING" beschreibung: "< 20 Personentage" pt_range: [0, 20] - wert: "mittel" label: "MITTEL" beschreibung: "20-50 Personentage" pt_range: [20, 50] - wert: "hoch" label: "HOCH" beschreibung: "> 50 Personentage" pt_range: [50, null] - wert: "analyse_erforderlich" label: "Analyse erforderlich" beschreibung: "Keine belastbare Schätzung möglich" icon: "?" - id: "begruendung_einschaetzung" name: "Begründung der Einschätzung" datentyp: "text" pflicht: true hinweis: "Kurze Erläuterung der Annahmen" # ============================================================================= # ABSCHNITT 8: LÖSUNGSDISKUSSION # ============================================================================= loesungsdiskussion: name: "Lösungsdiskussion" beschreibung: "Dokumentation der Lösungsideen (nicht Bewertung durch SHM)" hinweis: | SHM nimmt Lösungsvorschläge des Stakeholders auf, bewertet aber nicht technisch. Die technische Bewertung erfolgt durch DPM/SPM. felder: - id: "stakeholder_loesung" name: "Vom Stakeholder initial vorgeschlagene Lösung" datentyp: "text" pflicht: false hinweis: "Falls eine spezifische Lösung gewünscht wurde" - id: "diskutierte_alternativen" name: "Diskutierte Alternativen" datentyp: "array" pflicht: false element_struktur: - feld: "alternative" name: "Beschreibung" datentyp: "text" pflicht: true - feld: "bewertung" name: "Bewertung" datentyp: "text" pflicht: true hinweis: "Warum (nicht) geeignet?" - id: "praeferierte_loesungsrichtung" name: "Präferierte Lösungsrichtung" datentyp: "text" pflicht: false leitfrage: "Welche Richtung erscheint nach Diskussion am sinnvollsten?" # ============================================================================= # ABSCHNITT 9: FREIGABE ZUR DEMAND-TRANSFORMATION # ============================================================================= freigabe: name: "Freigabe zur Demand-Transformation" beschreibung: "Validierung und Freigabe durch Stakeholder" unterabschnitte: stakeholder_validierung: name: "Stakeholder-Validierung" felder: - id: "besprochen_am" name: "Steckbrief mit Stakeholder besprochen am" datentyp: "date" format: "tt.mm.jjjj" pflicht: true - id: "aenderungswuensche_eingearbeitet" name: "Änderungswünsche eingearbeitet" datentyp: "boolean" pflicht: true - id: "freigabe_erteilt" name: "Freigabe durch Stakeholder erteilt" datentyp: "boolean" pflicht: true validierung: "Muss 'true' sein für Status-Übergang zu 'bereit_fuer_sor'" # ============================================================================= # ABSCHNITT 10: SERVICE-KATALOG-PRÜFUNG # ============================================================================= service_katalog_pruefung: name: "Service-Katalog-Prüfung" beschreibung: "Abgleich mit bestehendem Service-Katalog" verantwortung: "SHM mit Unterstützung SPM" referenz: "demand-lifecycle-blueprint_phase-1.yaml, Schritt 1.4" felder: - id: "pruefergebnis" name: "Prüfergebnis" datentyp: "enum" pflicht: true werteliste: - wert: "nicht_abbildbar" label: "nicht abbildbar durch aktuellen Servicekatalog" erfordert: "begruendung" - wert: "teilweise_abbildbar" label: "teilweise abbildbar durch aktuellen Servicekatalog" erfordert: "service_referenz" - wert: "abbildbar" label: "abbildbar durch aktuellen Servicekatalog" erfordert: "service_referenz" hinweis: "Routing in Request Fulfilment (Out of Demand Scope)" - id: "begruendung" name: "Begründung" datentyp: "text" pflicht: true pflicht_bedingung: "pruefergebnis = 'nicht_abbildbar'" hinweis: "Prägnante Ausformulierung" - id: "service_referenz" name: "Service-Referenz" datentyp: "string" pflicht: true pflicht_bedingung: "pruefergebnis IN ('teilweise_abbildbar', 'abbildbar')" format: "Service-ID" beispiel: "SVC-CORE-042" # ============================================================================= # ABSCHNITT 11: ANLAGEN # ============================================================================= anlagen: name: "Anlagen" beschreibung: "Ergänzende Dokumente und Materialien" felder: - id: "unterstuetzende_dokumente" name: "Link zu unterstützenden Dokumenten" datentyp: "array" pflicht: false element_struktur: - feld: "titel" datentyp: "string" - feld: "url" datentyp: "url" - id: "gespraechsprotokolle" name: "Gesprächsprotokolle" datentyp: "array" pflicht: false element_struktur: - feld: "titel" datentyp: "string" - feld: "datum" datentyp: "date" - feld: "url" datentyp: "url" - id: "skizzen_mockups" name: "Skizzen/Mockups" datentyp: "array" pflicht: false hinweis: "Falls vorhanden" element_struktur: - feld: "titel" datentyp: "string" - feld: "url" datentyp: "url" # ============================================================================= # VALIDIERUNGSREGELN # ============================================================================= validierung: regeln: - id: "VAL-BED-001" name: "Pflichtfelder Basisdaten" beschreibung: "Alle Pflichtfelder in Basisdaten müssen gefüllt sein" typ: "formal" pruefung: "bedarfs_id, bedarfs_titel, kurzbeschreibung, eingereicht_von, eingangsdatum, bearbeitender_shm, ticket_referenz, status sind gefüllt" - id: "VAL-BED-002" name: "SHM-Einschätzung bei DPM-Übergabe" beschreibung: "Bei Status 'an_dpm_uebergeben' muss SHM-Einschätzung vorhanden sein" typ: "bedingt" pruefung: "WENN status = 'an_dpm_uebergeben' DANN shm_einschaetzung ist gefüllt" - id: "VAL-BED-003" name: "Mindestens eine User Story" beschreibung: "Es muss mindestens eine User Story dokumentiert sein" typ: "formal" pruefung: "user_stories.stories.length >= 1" - id: "VAL-BED-004" name: "Stakeholder-Freigabe vor Statuswechsel" beschreibung: "Freigabe muss erteilt sein für DPM-Übergabe" typ: "workflow" pruefung: "WENN status = 'an_dpm_uebergeben' DANN freigabe.freigabe_erteilt = true" hinweis: | Freigabe ist nur für DPM-Routing (Quality Gate 1) erforderlich. Für SOR-Eskalation und SPM-Routing ist keine formale Freigabe nötig. - id: "VAL-BED-005" name: "Service-Katalog-Prüfung vollständig" beschreibung: "Prüfergebnis muss mit passenden Detailfeldern dokumentiert sein" typ: "bedingt" pruefung: | WENN pruefergebnis = 'nicht_abbildbar' DANN begruendung ist gefüllt WENN pruefergebnis IN ('teilweise_abbildbar', 'abbildbar') DANN service_referenz ist gefüllt - id: "VAL-BED-006" name: "Aufwandsschätzung mit Begründung" beschreibung: "Jede Aufwandsschätzung muss begründet werden" typ: "formal" pruefung: "geschaetzter_aufwand ist gefüllt UND begruendung_einschaetzung ist gefüllt" qualitaetskriterien: beschreibung: "Qualitative Kriterien für Übergabereife" kriterien: - "Problemverständnis: Kernproblem ist klar vom Symptom getrennt" - "Stakeholder-Validierung: Steckbrief wurde mit Stakeholder besprochen" - "User Stories: Mindestens eine User Story nach Standard-Format" - "Vollständigkeit: Alle relevanten Abhängigkeiten identifiziert" - "Konsistenz: Zielbild passt zu Problemstellung" # ============================================================================= # VALIDIERUNGSPROFILE NACH ROUTING-PFAD # ============================================================================= validierungsprofile: beschreibung: | Die Pflichtfelder im Bedarfssteckbrief variieren je nach Routing-Ziel. Nicht jeder Routing-Pfad erfordert einen vollständig ausgefüllten Steckbrief. Diese Profile definieren, welche Abschnitte für welchen Routing-Pfad erforderlich sind. Sie ergänzen die allgemeinen Validierungsregeln. referenz: "shm_bedarfsbewertung.yaml" profile: - routing_id: "ROUTE-REQ" name: "Request Fulfilment" status: null steckbrief_erforderlich: false beschreibung: | Bedarf ist durch bestehenden Katalog abbildbar. Kein Bedarfssteckbrief erforderlich – direkte Weiterleitung an Service Desk / Request Fulfilment. - routing_id: "ROUTE-SPM" name: "Service Portfolio Management (Change)" status: "an_spm_uebergeben" steckbrief_erforderlich: true beschreibung: | Bedarf betrifft Änderung an bestehendem Service. Reduzierter Steckbrief ausreichend. erforderliche_abschnitte: - abschnitt: "basisdaten" vollstaendig: true - abschnitt: "stakeholder_kontext" vollstaendig: true - abschnitt: "bedarfsbeschreibung" vollstaendig: false erforderliche_felder: - "ausgangssituation" - "kernproblem" - abschnitt: "service_katalog_pruefung" vollstaendig: true hinweis: "Service-Referenz muss gefüllt sein" optionale_abschnitte: - "user_stories" - "rahmenbedingungen" - "abhaengigkeiten" - "groesseneinschaetzung" - "loesungsdiskussion" - "freigabe" anzuwendende_validierungsregeln: - "VAL-BED-001" - "VAL-BED-005" - routing_id: "ROUTE-SO" name: "Service-Owner-Klärung" status: "in_so_klaerung" steckbrief_erforderlich: true beschreibung: | Routing unklar – Service Owner klärt bilateral über Zuordnung. Wenn SO identifizierbar: direkte Klärung. Wenn nicht: SPM hilft bei Identifikation. SO entscheidet: RUN/Change → SOR; Demand → DPM/DSR. Steckbrief soweit wie möglich befüllen, aber Vollständigkeit keine Voraussetzung. referenz: "GOV-SHM-029" erforderliche_abschnitte: - abschnitt: "basisdaten" vollstaendig: true zusatz: "shm_einschaetzung muss eigene Einschätzung + Service-Portfolio-Prüfung dokumentieren" - abschnitt: "stakeholder_kontext" vollstaendig: true - abschnitt: "bedarfsbeschreibung" vollstaendig: false erforderliche_felder: - "ausgangssituation" - "kernproblem" - abschnitt: "service_katalog_pruefung" vollstaendig: true optionale_abschnitte: - "user_stories" - "rahmenbedingungen" - "abhaengigkeiten" - "groesseneinschaetzung" - "loesungsdiskussion" - "freigabe" anzuwendende_validierungsregeln: - "VAL-BED-001" - "VAL-BED-005" besonderheit: | Stakeholder-Freigabe (VAL-BED-004) ist für SO-Klärung NICHT erforderlich – SO kann auch ohne Stakeholder-Freigabe bilateral angerufen werden, wenn Klärungsbedarf besteht. - routing_id: "ROUTE-DPM-INTERN" name: "Demand Portfolio Management (Intern)" status: "an_dpm_uebergeben_intern" steckbrief_erforderlich: true beschreibung: | Bedarf von internem DIGIT-Mitarbeiter für neuen Service. Reduzierter Steckbrief ausreichend (Fast Track). DPM kann bei Bedarf Nachforderungen über Rückkopplungsschleife stellen. erforderliche_abschnitte: - abschnitt: "basisdaten" vollstaendig: true - abschnitt: "stakeholder_kontext" vollstaendig: false erforderliche_felder: - "stakeholder_prioritaet: 'intern'" hinweis: "Quelle ist intern, daher automatisch mit 'intern' befüllt" - abschnitt: "bedarfsbeschreibung" vollstaendig: false erforderliche_felder: - "kernproblem" - "zielbild" hinweis: "Ausgangssituation und Auswirkungen sind optional" - abschnitt: "groesseneinschaetzung" vollstaendig: true - abschnitt: "shm_einschaetzung" vollstaendig: true hinweis: "2-3 Sätze ausreichend. Siehe shm_bedarfsbewertung.yaml#schritt_0a_fast_track_intern" - abschnitt: "service_katalog_pruefung" vollstaendig: true optionale_abschnitte: - "user_stories" - "nutzen" - "rahmenbedingungen" - "abhaengigkeiten" - "loesungsdiskussion" - "freigabe" - "anlagen" anzuwendende_validierungsregeln: - "VAL-BED-001" - "VAL-BED-005" besonderheit: | Stakeholder-Freigabe (VAL-BED-004) ist für interne Demands NICHT erforderlich. DPM kann über Rückkopplungsschleife (shm_d2p-integration.yaml) Nachforderungen stellen, wenn für Klassifizierung zusätzliche Informationen benötigt werden. qualitaetssicherung: | SHM Fast Track Validation (10-15min) ist Quality Gate 1. DPM Quality Gate 2 prüft Klassifizierbarkeit und kann bei Bedarf zurückweisen. - routing_id: "ROUTE-DPM" name: "Demand Portfolio Management (Extern)" status: "an_dpm_uebergeben" steckbrief_erforderlich: true beschreibung: | Bedarf von externem Stakeholder (anderes Amt, Bürger, Politik) erfordert neuen Service oder grundlegende Neugestaltung. Vollständiger Steckbrief erforderlich für Quality Gate 1. erforderliche_abschnitte: - abschnitt: "basisdaten" vollstaendig: true - abschnitt: "stakeholder_kontext" vollstaendig: true - abschnitt: "bedarfsbeschreibung" vollstaendig: true - abschnitt: "user_stories" vollstaendig: true hinweis: "Mindestens eine User Story nach Standard-Format" - abschnitt: "rahmenbedingungen" vollstaendig: false erforderliche_felder: [] hinweis: "Harte Deadline oder gewünschter Termin falls relevant" - abschnitt: "abhaengigkeiten" vollstaendig: true - abschnitt: "groesseneinschaetzung" vollstaendig: true - abschnitt: "service_katalog_pruefung" vollstaendig: true - abschnitt: "freigabe" vollstaendig: true hinweis: "Stakeholder-Freigabe erforderlich" optionale_abschnitte: - "loesungsdiskussion" - "anlagen" anzuwendende_validierungsregeln: - "VAL-BED-001" - "VAL-BED-002" - "VAL-BED-003" - "VAL-BED-004" - "VAL-BED-005" - "VAL-BED-006" # ============================================================================= # SCHNITTSTELLEN # ============================================================================= schnittstellen: eingang: beschreibung: "Quellen für die Steckbrief-Erstellung" quellen: - quelle: "Stakeholder" artefakt: "Bedarfsmeldung (unqualifiziert)" kanal: "Ticketsystem / direkte Ansprache" - quelle: "Bedarfsklärungsgespräch" artefakt: "Protokollierte Anforderungen" ausgang: beschreibung: "Übergabe des finalen Steckbriefs" ziele: - ziel: "Service Owner (SO)" artefakt: "Bedarfs-Steckbrief (Final)" zweck: "Routing-Entscheidung Change vs. Demand" status_nach_uebergabe: "in_so_klaerung" - ziel: "DPM (externer Bedarf)" artefakt: "Bedarfs-Steckbrief (Final)" zweck: "Demand-Qualifizierung" status_nach_uebergabe: "an_dpm_uebergeben" bedingung: "Externer Stakeholder-Bedarf, Routing-Entscheidung = ROUTE-DPM" - ziel: "DPM (interner Fast-Track-Bedarf)" artefakt: "Bedarfs-Steckbrief (Reduziert, Profil ROUTE-DPM-INTERN)" zweck: "Demand-Qualifizierung interner Bedarf" status_nach_uebergabe: "an_dpm_uebergeben_intern" bedingung: "DIGIT-Mitarbeiter als Nutzer, Routing-Entscheidung = ROUTE-DPM-INTERN" hinweis: "Reduzierter Steckbrief, DPM kann über Rückkopplungsschleife nachfordern" - ziel: "SPM" artefakt: "Bedarfs-Steckbrief (Final)" zweck: "Change an bestehendem Service" status_nach_uebergabe: "an_spm_uebergeben" bedingung: "DSR-Entscheidung = Change" # ============================================================================= # REFERENZEN # ============================================================================= referenzen: prozess_kontext: - titel: "Demand-Lifecycle-Blueprint Phase 1" pfad: "#01_demand-portfolio-management/#01.2_demand-lifecycle-blueprint/demand-lifecycle-blueprint_phase-1.yaml" relevanz: "Prozesskontext für Steckbrief-Erstellung" - titel: "SHM Engagement-Framework" pfad: "#03_stakeholder-management/#03.3_konzepte/shm_engagement-framework.yaml" relevanz: "Formate für Bedarfserhebung" verwandte_schemas: - titel: "Amts-Steckbrief Schema" pfad: "#03_stakeholder-management/#03.6_informationsmodell/shm_schema_amtssteckbrief.yaml" relevanz: "Stakeholder-Stammdaten" - titel: "Service-Steckbrief Schema" pfad: "#02_service-portfolio-management/02.1_spm_konzepte/06_Informationsmodell/spm_schema_service-steckbrief.yaml" relevanz: "Analoges Schema im SPM-Kontext" arbeitsmaterialien: - titel: "Leitfaden User Stories" pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/leitfaden_user-stories.yaml" hinweis: "Referenziert im PDF auf Seite 108" - titel: "Template Bedarfs-Steckbrief" pfad: "#03_stakeholder-management/#03.7_arbeitsmaterialien/shm_template_bedarfssteckbrief.md" status: "abzuleiten aus diesem Schema" methodik_referenz: - dokument: "shm_bedarfsbewertung.yaml" pfad: "#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml" beschreibung: "Routing-Logik und Entscheidungsbaum für Bedarfsbewertung" - dokument: "shm_stakeholder-portfolio.yaml" pfad: "#03_stakeholder-management/#03.3_konzepte/shm_stakeholder-portfolio.yaml" beschreibung: "Stakeholder-Priorisierung und IT-Anforderungsprofil" # ============================================================================= # OFFENE PUNKTE # ============================================================================= offene_punkte: - id: "OPEN-BED-001" beschreibung: "Template (Markdown) aus Schema ableiten" prioritaet: "hoch" ziel_ordner: "#03_stakeholder-management/#03.7_arbeitsmaterialien/" - id: "OPEN-BED-002" beschreibung: "Leitfaden User Stories erstellen" prioritaet: "mittel" referenz: "PDF Seite 108" - id: "OPEN-BED-003" beschreibung: "ITSM-Tool-Mapping definieren" prioritaet: "niedrig" hinweis: "Wie wird der Steckbrief im Ticketsystem abgebildet?" - id: "OPEN-BED-004" beschreibung: "Abstimmung SOR-Integration" prioritaet: "mittel" hinweis: "SOR-Prozess noch nicht vollständig modelliert" # ============================================================================= # ÄNDERUNGSHISTORIE # ============================================================================= aenderungshistorie: - version: "1.1" datum: "2025-12-09" aenderung: | - Neuer Abschnitt: stakeholder_kontext (Integration Stakeholder-Portfolio) - Neuer Abschnitt: validierungsprofile (Routing-basierte Pflichtfelder) - Update: referenz_leitfaden auf YAML-Pfad - Update: VAL-BED-004 präzisiert (nur DPM erfordert Freigabe) - Neue Methodik-Referenzen ergänzt autor: "DIGITOM-Projekt" quelle: "SHM Phase 3 – Bedarfsbewertung" - version: "1.3" datum: "2026-03-07" aenderung: | - Schnittstellen.ausgang: DPM-Eintrag aufgeteilt in zwei Ziele (externer Bedarf ROUTE-DPM / interner Fast-Track ROUTE-DPM-INTERN) - Status "an_dpm_uebergeben_intern" in Ausgangs-Übersicht ergänzt - Bedingungsformulierung bei DPM-extern auf ROUTE-DPM-Terminologie präzisiert autor: "DIGITOM-Projekt" quelle: "Lückenanalyse Bedarfsrouting 2026-03-07" - version: "1.2" datum: "2026-01-22" aenderung: | - Neues Validierungsprofil: ROUTE-DPM-INTERN - Reduzierte Pflichtfelder für interne DIGIT-Bedarfe - Status: "an_dpm_uebergeben_intern" - Hinweis auf DPM Rückkopplungsschleife bei Nachforderungen - Umbenennung bestehendes Profil: ROUTE-DPM → ROUTE-DPM (Extern) zur Klarheit autor: "DIGITOM-Projekt" quelle: "Lösung für Ticket: Interne Bedarfe Routing-Unschärfe" - version: "1.0" datum: "2025-12-09" aenderung: "Initiale Schema-Erstellung aus PDF-Template" autor: "DIGITOM-Projekt" quelle: "Konzept_DPM_Abnahme20230925, Seiten 106-112"