# ============================================================================= # SHM: ROUTING INTERNER DIGIT-BEDARFE # ============================================================================= # Modul: Stakeholder-Management (SHM) # Typ: Arbeitsmaterial / Übersicht # Version: 2.0 # Datum: 2025-01-29 # Status: Entwurf # ============================================================================= meta: modul_id: "SHM-AM-02" name: "Routing interner DIGIT-Bedarfe" typ: "Arbeitsmaterial" zweck: | Diese Übersicht klärt die drei unterschiedlichen Bedarfstypen und ihre jeweiligen Prozesswege. Sie dient als Entscheidungshilfe für SHM und als Orientierung für DIGIT-Mitarbeiter. **Kernaussage:** Es gibt drei Bedarfstypen mit unterschiedlichen Wegen: 1. Externe Stakeholder-Bedarfe → Regelweg (vollständige Bedarfsbewertung) 2. Interne DIGIT-Mitarbeiter-Bedarfe → Fast Track (10-15 min) 3. Service-Lifecycle-Bedarfe → Bypass (direkt in Demand-Lifecycle) referenzen: - dokument: "shm_bedarfsbewertung.yaml" abschnitt: "funktionale_herleitung.geltungsbereich" - dokument: "shm_bedarfsbewertung.yaml" abschnitt: "prozessablauf.schritt_0a_fast_track_intern" - dokument: "shm_d2p-integration.yaml" abschnitt: "abgrenzung_bedarfsquellen" - dokument: "PATCH_NOTES_interne_bedarfe_v1.1.md" beschreibung: "Konzeptdokumentation Fast Track" governance_referenz: "GOV-SHM-026" # ============================================================================= # ÜBERSICHT: DREI BEDARFSTYPEN # ============================================================================= bedarfstypen_uebersicht: visualisierung: | ┌─────────────────────────────────────────────────────────────────────────┐ │ BEDARFSTYPEN IM DIGIT │ └─────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐ │ TYP 1: EXTERN │ │ TYP 2: INTERN │ │ TYP 3: LIFECYCLE │ │ (Regelweg) │ │ (Fast Track) │ │ (Bypass) │ └──────────┬──────────┘ └──────────┬──────────┘ └──────────┬──────────┘ │ │ │ Bedarfsträger: Bedarfsträger: Bedarfsträger: Externe Ämter, DIGIT-Mitarbeiter Service Owner, Dienststellen als Nutzer ISB, SOR, Leitung │ │ │ ▼ ▼ ▼ ┌─────────────────────┐ ┌─────────────────────┐ ┌─────────────────────┐ │ SHM Bedarfsbewertung│ │ SHM Fast Track │ │ Direkt DPM/SOR │ │ - Schritt 0 │ │ - 3 Schritte │ │ - Kein SHM-Routing │ │ - Prüfungen 1-3 │ │ - 10-15 Minuten │ │ - SHM informiert │ │ - Vollständiger │ │ - Reduzierter │ │ bei Stakeholder- │ │ Steckbrief │ │ Steckbrief │ │ Auswirkungen │ └──────────┬──────────┘ └──────────┬──────────┘ └──────────┬──────────┘ │ │ │ └─────────────────────────┼─────────────────────────┘ │ ▼ ┌─────────────────────┐ │ DPM / DSR / MB │ │ (einheitliche │ │ Klassifizierung) │ └─────────────────────┘ zusammenfassung_tabelle: spalten: - "Bedarfstyp" - "Bedarfsträger" - "Eintrittskanal" - "Prozess" - "Aufwand SHM" - "Steckbrief" zeilen: - bedarfstyp: "Extern (Regelweg)" bedarfstraeger: "Ämter, Dienststellen außerhalb DIGIT" eintrittskanal: "SHM" prozess: "Schritt 0 + Prüfungen 1-3" aufwand_shm: "2-4 Stunden" steckbrief: "Vollständig (ROUTE-DPM)" - bedarfstyp: "Intern (Fast Track)" bedarfstraeger: "DIGIT-Mitarbeiter als Nutzer" eintrittskanal: "SHM (Self-Service-Portal)" prozess: "3-Schritte Fast Track" aufwand_shm: "10-15 Minuten" steckbrief: "Reduziert (ROUTE-DPM-INTERN)" - bedarfstyp: "Service-Lifecycle (Bypass)" bedarfstraeger: "SO, ISB, SOR, DIGIT-Leitung" eintrittskanal: "Direkt SOR/DPM" prozess: "Kein SHM-Routing" aufwand_shm: "0 (nur Information)" steckbrief: "Vom Bedarfsträger erstellt" # ============================================================================= # TYP 1: EXTERNE STAKEHOLDER-BEDARFE (REGELWEG) # ============================================================================= typ_1_externe_bedarfe: name: "Externe Stakeholder-Bedarfe" kurzbezeichnung: "Regelweg" definition: | Bedarfe, die von Stakeholdern außerhalb von DIGIT an DIGIT herangetragen werden. Der Stakeholder ist Bedarfsträger und Auftraggeber. bedarfstraeger: - "Städtische Ämter (z.B. Bauamt, Sozialamt, Ordnungsamt)" - "Städtische Dienststellen" - "Eigenbetriebe" - "Andere kommunale Einrichtungen" eintrittskanal: "SHM (Stakeholder-Management)" prozess: beschreibung: "Vollständige Bedarfsbewertung gemäß shm_bedarfsbewertung.yaml" schritte: - "Schritt 0: Bedarfserhebung (User Stories)" - "Prüfung 1: Service-Katalog-Check" - "Prüfung 2: Change-Qualifizierung" - "Prüfung 3: Demand-Indikation" aufwand: "2-4 Stunden" steckbrief: "Vollständig (Validierungsprofil ROUTE-DPM)" routing_optionen: - "ROUTE-REQ → Service Desk / Request Fulfilment" - "ROUTE-SPM → Service Owner (Change)" - "ROUTE-DPM → Demand Portfolio Management" - "ROUTE-SO → Service-Owner-Klärung (bei Unklarheit)" beispiele: - titel: "Bauamt benötigt neue Funktion im Fachverfahren" situation: | Das Bauamt meldet, dass im Bauantragsverfahren eine Funktion zur automatischen Flurstücksvalidierung fehlt. prozess: | SHM führt vollständige Bedarfsbewertung durch: - Schritt 0: User Stories mit Sachbearbeitern erarbeiten - Prüfung 1: Service existiert (Bauantragsverfahren) - Prüfung 2: Change am bestehenden Service → ROUTE-SPM ergebnis: "Vollständiger Bedarfssteckbrief an Service Owner" - titel: "Sozialamt möchte digitale Antragsstellung" situation: | Das Sozialamt möchte Bürgeranträge online entgegennehmen können. Aktuell existiert kein entsprechender Service. prozess: | SHM führt vollständige Bedarfsbewertung durch: - Schritt 0: User Stories und Anforderungen erheben - Prüfung 1: Kein passender Service im Katalog - Prüfung 3: Demand-Indikation positiv → ROUTE-DPM ergebnis: "Vollständiger Bedarfssteckbrief an DPM" # ============================================================================= # TYP 2: INTERNE DIGIT-MITARBEITER-BEDARFE (FAST TRACK) # ============================================================================= typ_2_interne_nutzer_bedarfe: name: "Interne DIGIT-Mitarbeiter-Bedarfe" kurzbezeichnung: "Fast Track" definition: | Bedarfe von DIGIT-Mitarbeitern, die als *Nutzer* von IT-Services auftreten – nicht in ihrer Funktion als Service Owner, ISB oder andere technische Rolle. bedarfstraeger: - "DIGIT-Personalabteilung" - "DIGIT-Sekretariat" - "DIGIT-Sachbearbeiter (als Nutzer)" - "Andere DIGIT-interne Organisationseinheiten" - "Ggf. Stabsstelle Digital Freiburg (als Nutzer)" abgrenzung_zu_service_lifecycle: | Der Fast Track gilt für DIGIT-Mitarbeiter als **Nutzer**. Wenn ein Service Owner einen Bedarf für seinen **eigenen Service** hat, ist das ein Service-Lifecycle-Bedarf (Typ 3), kein Fast-Track-Fall. Beispiel: - Personalabteilung braucht neue Zeiterfassung → Fast Track (Typ 2) - Service Owner DMS plant Redesign seines Service → Lifecycle (Typ 3) eintrittskanal: primaer: "Self-Service-Portal (ITSM-Tool)" mvp: "E-Mail-Template an SHM" prozess: beschreibung: "Vereinfachter 3-Schritte Fast Track (10-15 Minuten)" schritt_1: name: "Basistriage" dauer: "3-5 Minuten" frage: "Ist es ein valider Bedarf?" schritt_2: name: "Routing-Entscheidung" dauer: "5-7 Minuten" frage: "Wohin gehört der Bedarf?" optionen: - "Bestehender Service → Direkt an Service Owner" - "Neuer Service → ROUTE-DPM-INTERN" - "Unklar → ROUTE-SO" schritt_3: name: "Minimaldokumentation" dauer: "3-5 Minuten" bedingung: "Nur bei ROUTE-DPM-INTERN" aufwand: "10-15 Minuten" steckbrief: "Reduziert (Validierungsprofil ROUTE-DPM-INTERN)" routing_optionen: - "Direkt an Service Owner (kein Steckbrief)" - "ROUTE-DPM-INTERN (reduzierter Steckbrief)" - "ROUTE-SO (bei Unklarheit)" 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. prozess: 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" aufwand: "~12 Minuten" - titel: "Stabsstelle Digital möchte Miro (obwohl Conceptboard existiert)" situation: | Die Stabsstelle Digital Freiburg fragt nach einem Miro-Zugang für kollaborative Workshops. prozess: 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? - Fehlt eine Funktion? → Ggf. Change - Begründeter Mehrbedarf? → SO entscheidet aufwand: "~8 Minuten" - titel: "DIGIT-Sekretariat benötigt Terminplanungstool" situation: | Das Sekretariat möchte ein Tool zur vereinfachten Terminplanung mit externen Besuchern (Buchungslink-Funktion). prozess: schritt_1: "Valide – Bedarf verständlich, im Scope" schritt_2: "Prüfung: Kalendertool mit Buchungsfunktion vorhanden?" schritt_3: "Falls nein: ROUTE-DPM-INTERN mit Minimaldoku" ergebnis: "Abhängig von Service-Katalog-Prüfung" aufwand: "~10 Minuten" # ============================================================================= # TYP 3: SERVICE-LIFECYCLE-BEDARFE (BYPASS) # ============================================================================= typ_3_service_lifecycle_bedarfe: name: "Service-Lifecycle-Bedarfe" kurzbezeichnung: "Bypass" definition: | Bedarfe, die aus dem Service-Lifecycle oder aus technisch-strategischen Rollen heraus entstehen. Der Bedarfsträger ist eine DIGIT-interne Rolle mit fachlicher Expertise (Service Owner, ISB, SOR, DIGIT-Leitung). Diese Bedarfe durchlaufen die SHM-Triage NICHT, weil die fachliche Qualifizierung bereits durch den Bedarfsträger erfolgt ist. bedarfstraeger: - "Service Owner (für eigenen Service)" - "ISB / Compliance" - "SOR (strategische Entscheidungen)" - "DIGIT-Leitung / Mission Board" - "Technische Architektur-Rollen" eintrittskanal: "Direkt SOR / DPM (je nach Umfang)" shm_rolle: | SHM ist bei Service-Lifecycle-Bedarfen **nicht Routing-Instanz**, aber: - SHM wird **informiert**, wenn externe Stakeholder betroffen sind - SHM übernimmt dann die **Stakeholder-Kommunikation** - SHM kann **Stakeholder-Perspektive** in DSR/MB einbringen szenarien: # ------------------------------------------------------------------------- szenario_1_change_bedarf_so: name: "Service Owner identifiziert Change-Bedarf" beschreibung: | Der Service Owner erkennt im Rahmen seiner laufenden Arbeit oder aus dem Service Review, dass sein Service angepasst werden muss. ausloeser: - "Service Review (sr_02) zeigt Optimierungspotenzial" - "Technische Schulden müssen abgebaut werden" - "Performance-Verbesserung erforderlich" - "Nutzer-Feedback zeigt Verbesserungsbedarf" routing: "SO führt Change selbst durch (Normal Change Authority)" shm_information: "Nur bei Stakeholder-Auswirkungen" beispiel: titel: "Performance-Optimierung Ticketsystem" situation: "SO stellt fest, dass die Suche zu langsam ist." routing: "SO führt Datenbank-Tuning als Change durch" shm_information: "Nicht erforderlich (keine Nutzer-Auswirkung)" # ------------------------------------------------------------------------- szenario_2_redesign_bedarf_so: name: "Service Owner identifiziert Redesign-Bedarf" beschreibung: | Der Service Owner erkennt, dass sein Service grundlegend überarbeitet werden muss – die Änderung hat Projektcharakter. ausloeser: - "Service Review zeigt grundlegenden Modernisierungsbedarf" - "Technologie ist veraltet (End-of-Life)" - "Architektur-Änderung erforderlich" routing: "SO → SOR (REDESIGN) → DPM (Demand)" shm_information: "Ja, da Stakeholder betroffen" beispiel: titel: "Modernisierung Dokumentenmanagement" situation: "SO erkennt im Review: DMS technisch veraltet" routing: "SO → SOR bestätigt → DPM erhält Demand" shm_information: "SHM bereitet Stakeholder-Kommunikation vor" # ------------------------------------------------------------------------- szenario_3_service_abloesung: name: "Service-Ablösung / Retirement" beschreibung: | Ein Service soll nicht mehr weitergeführt werden – entweder ersatzlos oder durch einen anderen Service ersetzt. ausloeser: - "End-of-Life des Produkts/der Technologie" - "Strategische Konsolidierung" - "Service wird nicht mehr benötigt" routing: "SO → SOR (RETIRE) → DPM (Retirement-Projekt)" shm_information: "Ja, zwingend" beispiel: titel: "Ablösung Legacy-Mailsystem" situation: "DIGIT entscheidet strategisch: Mailsystem ersetzen" routing: "SO (alt) → SOR → DPM (Retirement + ggf. neues System)" shm_information: | SHM übernimmt komplette Stakeholder-Kommunikation: - Key-Stakeholder: Persönliche Gespräche - Aktiv-Stakeholder: Strukturierte Information - Standard/Basis: Schriftliche Ankündigung # ------------------------------------------------------------------------- szenario_4_sicherheit_compliance: name: "Sicherheits- oder Compliance-Anforderung" beschreibung: | Eine Änderung wird durch Sicherheitsvorgaben, Regulatorik oder Compliance-Anforderungen notwendig. ausloeser: - "Sicherheitsvorfall oder -erkenntnis" - "Neue gesetzliche Anforderung" - "Audit-Feststellung" - "BSI-Empfehlung" routing: "ISB → SOR/SO (je nach Umfang)" shm_information: "Bei Stakeholder-Auswirkungen" beispiel: titel: "Zwei-Faktor-Authentifizierung verpflichtend" situation: "Neue Sicherheitsrichtlinie erfordert 2FA" routing: "ISB → SOR → Umsetzung durch betroffene SOs" shm_information: | SHM übernimmt Stakeholder-Kommunikation: - Erklärung der Notwendigkeit - Zeitplan und Umstellungsprozess - Schulungs-/Support-Angebote # ------------------------------------------------------------------------- szenario_5_strategische_initiative: name: "Strategische DIGIT-Initiative" beschreibung: | DIGIT startet eine übergreifende Initiative, die mehrere Services betrifft oder neue Infrastruktur schafft. ausloeser: - "IT-Strategie-Umsetzung" - "Konsolidierungsprojekt" - "Infrastruktur-Modernisierung" - "Einführung neuer Basisdienste" routing: "DIGIT-Leitung → MB → DPM" shm_information: "Ja, bei Stakeholder-Auswirkungen" beispiel: titel: "Einführung zentrales Identity Management" situation: "DIGIT führt IAM-System ein (Single Sign-On)" routing: "DIGIT-Leitung → MB (Freigabe) → DPM (Programm)" shm_information: | SHM wird frühzeitig eingebunden: - Vorteile kommunizieren - Migrationsplanung je Amt - Schulungskonzept # ============================================================================= # ENTSCHEIDUNGSHILFE # ============================================================================= entscheidungshilfe: kernfragen: - frage: "Wer ist Bedarfsträger?" typ_1: "Externes Amt / Dienststelle" typ_2: "DIGIT-Mitarbeiter als Nutzer" typ_3: "SO, ISB, SOR, DIGIT-Leitung" - frage: "Woher kommt der Bedarf?" typ_1: "Stakeholder-Anfrage von außerhalb DIGIT" typ_2: "Interne Nutzer-Anforderung" typ_3: "Service-Lifecycle, Sicherheit, Strategie" - frage: "Hat der Bedarfsträger fachliche IT-Expertise?" typ_1: "Nein (fachliche Übersetzung durch SHM nötig)" typ_2: "Begrenzt (vereinfachte Prüfung ausreichend)" typ_3: "Ja (Bedarfsträger qualifiziert selbst)" grenzfaelle: - fall: "Stakeholder beschwert sich, SO erkennt daraus Redesign-Bedarf" einschaetzung: | Der initiale Bedarf war extern (Beschwerde) → Typ 1. Die Schlussfolgerung "Redesign nötig" ist SO-Erkenntnis → Typ 3. Routing: Beschwerde über SHM (Typ 1). Wenn SHM an SO routet und SO dann Redesign empfiehlt, geht der Demand direkt zu DPM (Typ 3). - fall: "SO möchte Feature, das Stakeholder auch wünschen" einschaetzung: | Entscheidend ist, wer den Bedarf zuerst artikuliert hat: - Stakeholder zuerst → Typ 1 (SHM-Regelweg) - SO zuerst → Typ 3 (Service-Lifecycle) In der Praxis: SO kann auf Stakeholder-Unterstützung verweisen. - fall: "DIGIT-Personalabteilung vs. Personalamt der Stadt" einschaetzung: | - DIGIT-Personalabteilung → Typ 2 (Fast Track) - Personalamt der Stadt (anderes Amt) → Typ 1 (Regelweg) Entscheidend ist die organisatorische Zugehörigkeit, nicht die funktionale Ähnlichkeit. - fall: "ISB fordert Änderung, die Stakeholder nicht wollen" einschaetzung: | Sicherheits-/Compliance-Anforderungen sind Typ 3, auch wenn sie Stakeholder-Widerstand erzeugen. SHM übernimmt die (ggf. schwierige) Stakeholder-Kommunikation, aber das Routing bleibt Typ 3 (ISB → SOR/SO). # ============================================================================= # ROUTING-MATRIX (KOMPAKT) # ============================================================================= routing_matrix_kompakt: zeilen: - bedarfstyp: "Extern (Typ 1)" beispiel: "Bauamt braucht neue Funktion" eintritt: "SHM" prozess: "Regelweg" aufwand: "2-4h" steckbrief: "Vollständig" - bedarfstyp: "Intern-Nutzer (Typ 2)" beispiel: "DIGIT-Personal braucht Zeiterfassung" eintritt: "SHM (Fast Track)" prozess: "3 Schritte" aufwand: "10-15min" steckbrief: "Reduziert" - bedarfstyp: "Service-Lifecycle (Typ 3)" beispiel: "SO plant DMS-Modernisierung" eintritt: "Direkt SOR/DPM" prozess: "Kein SHM" aufwand: "0 (SHM)" steckbrief: "Vom SO" # ============================================================================= # SHM-AUFGABEN JE BEDARFSTYP # ============================================================================= shm_aufgaben_je_typ: typ_1_extern: - "Vollständige Bedarfsbewertung (Schritt 0, Prüfungen 1-3)" - "User-Story-Erhebung mit Stakeholder" - "Bedarfssteckbrief erstellen und validieren" - "Routing-Entscheidung treffen" - "Stakeholder-Kommunikation im gesamten Prozess" typ_2_intern_nutzer: - "Fast Track Basistriage (3-5 min)" - "Schnelle Routing-Entscheidung (5-7 min)" - "Minimaldokumentation bei ROUTE-DPM-INTERN (3-5 min)" - "Weiterleitung an SO oder DPM" typ_3_service_lifecycle: - "Keine Routing-Aufgabe" - "Information bei Stakeholder-Auswirkungen entgegennehmen" - "Stakeholder-Kommunikation übernehmen (wenn informiert)" - "Stakeholder-Perspektive in DSR/MB einbringen" # ============================================================================= # ÄNDERUNGSHISTORIE # ============================================================================= aenderungshistorie: - version: "1.0" datum: "2025-01-29" aenderung: "Initiale Erstellung (Fokus auf Service-Lifecycle-Bedarfe)" autor: "DIGITOM-Projekt" quelle: "Chat-Session Konzeptprüfung" - version: "2.0" datum: "2025-01-29" aenderung: | Komplette Überarbeitung: Drei Bedarfstypen klar unterschieden - Typ 1: Externe Stakeholder-Bedarfe (Regelweg) - Typ 2: Interne DIGIT-Mitarbeiter-Bedarfe (Fast Track) - Typ 3: Service-Lifecycle-Bedarfe (Bypass) - Visualisierung und Routing-Matrix ergänzt - Entscheidungshilfe mit Grenzfällen - SHM-Aufgaben je Bedarfstyp - Synchronisierung mit shm_bedarfsbewertung.yaml v1.3 autor: "DIGITOM-Projekt" quelle: "Chat-Session Konzeptprüfung"