567 lines
24 KiB
YAML
567 lines
24 KiB
YAML
# =============================================================================
|
||
# 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"
|