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