init: DIGITOM Kernkonzept YAML-Dateien (initialer Import)
This commit is contained in:
commit
f599c7ced7
91 changed files with 56355 additions and 0 deletions
|
|
@ -0,0 +1,567 @@
|
|||
# =============================================================================
|
||||
# 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"
|
||||
Loading…
Add table
Add a link
Reference in a new issue