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,20 @@
|
|||
# ========================================
|
||||
# Funktionsbeschreibung Stakeholder-Management (SHM)
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 0, 10
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: ""
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 0 und 10]
|
||||
817
#03_stakeholder-management/#03.1_funktion/shm_rollen.yaml
Normal file
817
#03_stakeholder-management/#03.1_funktion/shm_rollen.yaml
Normal file
|
|
@ -0,0 +1,817 @@
|
|||
# =============================================================================
|
||||
# SHM ROLLENBESCHREIBUNGEN
|
||||
# =============================================================================
|
||||
# Modul: Stakeholder-Management (SHM)
|
||||
# Funktion: Rollen
|
||||
# Version: 1.0
|
||||
# Datum: 2025-12-10
|
||||
# Status: Entwurf
|
||||
# Entwicklungsphase: 6
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
dokument_id: "SHM-R-01"
|
||||
name: "SHM Rollenbeschreibungen"
|
||||
|
||||
enthaltene_rollen:
|
||||
- rolle_id: "shm-m"
|
||||
rolle_name: "Stakeholder-Manager:in"
|
||||
- rolle_id: "shm-l"
|
||||
rolle_name: "Leitung Stakeholder Management"
|
||||
|
||||
beziehung_rollen: |
|
||||
Die Leitung Stakeholder Management ist disziplinarische Führungskraft
|
||||
der Stakeholder-Manager:innen und gleichzeitig Abteilungsleitung.
|
||||
|
||||
Operative Kundenbetreuung liegt bei den Stakeholder-Manager:innen.
|
||||
Strategische Steuerung, Reporting und Gremienvertretung auf
|
||||
Leitungsebene (MB) liegt bei der Leitung.
|
||||
|
||||
# =============================================================================
|
||||
# ROLLE 1: STAKEHOLDER-MANAGER:IN
|
||||
# =============================================================================
|
||||
|
||||
stakeholder_manager:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# META
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "shm-m"
|
||||
rolle_name: "Stakeholder-Manager:in"
|
||||
aliases: ["SHM-Manager", "Kundenbetreuer:in"]
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Stakeholder-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: "[SHM-Leitung]"
|
||||
status: "entwurf"
|
||||
|
||||
kontext_tags:
|
||||
- "stakeholder-management"
|
||||
- "kundenbetreuung"
|
||||
- "bedarfserhebung"
|
||||
- "relationship-management"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ROLLENZWECK
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
rollenzweck:
|
||||
|
||||
kurz: |
|
||||
Zentrale Ansprechperson für zugewiesene Stakeholder (Ämter/Einheiten)
|
||||
und verantwortlich für Beziehungspflege, Bedarfserhebung und
|
||||
Interessenvertretung gegenüber DIGIT.
|
||||
|
||||
ausfuehrlich: |
|
||||
Der/die Stakeholder-Manager:in betreut einen definierten Kreis von
|
||||
Organisationseinheiten (Ämter, Eigenbetriebe, Referate etc.) und ist
|
||||
deren primäre Schnittstelle zu DIGIT. Die Rolle umfasst proaktive
|
||||
Beziehungspflege, systematische Bedarfserhebung, qualifiziertes
|
||||
Routing von Anforderungen sowie die Vertretung der Stakeholder-
|
||||
Perspektive in internen Gremien.
|
||||
|
||||
Der/die Stakeholder-Manager:in agiert als "Kundenanwalt" – nicht als
|
||||
neutraler Vermittler, sondern als aktiver Vertreter der
|
||||
Kundenperspektive innerhalb von DIGIT.
|
||||
|
||||
verantwortung:
|
||||
ab_wann: "Für alle Interaktionen mit zugewiesenen Stakeholdern"
|
||||
fuer: "Beziehungsqualität, Bedarfserfassung, Routing-Entscheidung"
|
||||
bis: "Übergabe qualifizierter Demands an DPM, Changes an SPM bzw. Abschluss Service-Request"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ORGANISATORISCHE EINORDNUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
organisatorische_einordnung:
|
||||
|
||||
zuordnung:
|
||||
abteilung: "Digitale Schulen / QM, Service- und Prozessgovernance"
|
||||
abteilungskuerzel: "[AL-DS/SPG]" # Kürzel zu bestätigen
|
||||
funktion: "Stakeholder-Management (SHM)"
|
||||
|
||||
berichtslinie:
|
||||
berichtet_an: "Leitung Stakeholder Management"
|
||||
berichtet_an_rolle_id: "shm-l"
|
||||
|
||||
arbeitsmodell:
|
||||
typ: "Vollzeitfunktion oder Teilfunktion"
|
||||
anmerkung: |
|
||||
Je nach Portfolio-Größe kann die Rolle auf mehrere Personen
|
||||
verteilt sein. Jede:r Stakeholder-Manager:in betreut einen
|
||||
definierten Kreis von Ämtern/Einheiten.
|
||||
vertretung: "Gegenseitige Vertretungsregelung zwischen Stakeholder-Manager:innen"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# KERNAUFGABEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
kernaufgaben:
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
beziehungspflege:
|
||||
|
||||
name: "Proaktive Beziehungspflege"
|
||||
|
||||
beschreibung: |
|
||||
Aufbau und Pflege stabiler, vertrauensvoller Beziehungen zu den
|
||||
zugewiesenen Stakeholdern. Der/die Stakeholder-Manager:in ist
|
||||
das "Gesicht von DIGIT" für diese Organisationseinheiten.
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Turnus-Gespräche durchführen"
|
||||
frequenz: "Gemäß Betreuungsmodus (monatlich bis jährlich)"
|
||||
referenz: "shm_engagement-framework.yaml"
|
||||
|
||||
- aufgabe: "Stakeholder-Steckbriefe pflegen"
|
||||
frequenz: "Laufend, mindestens jährliche Validierung"
|
||||
referenz: "shm_schema_amtssteckbrief.yaml"
|
||||
|
||||
- aufgabe: "Beziehungsqualität einschätzen und dokumentieren"
|
||||
frequenz: "Nach jedem Kontakt"
|
||||
referenz: "shm_stakeholder-portfolio.yaml"
|
||||
|
||||
- aufgabe: "Proaktive Kontaktaufnahme bei Veränderungen"
|
||||
trigger: "Neue Amtsleitung, Reorganisation, Projektstart"
|
||||
|
||||
ergebnis: |
|
||||
Stakeholder fühlen sich von DIGIT verstanden und gut betreut.
|
||||
Beziehungsqualität ist dokumentiert und steuerbar.
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
bedarfserhebung:
|
||||
|
||||
name: "Bedarfserhebung und -qualifizierung"
|
||||
|
||||
beschreibung: |
|
||||
Systematische Erfassung, Klärung und Dokumentation von
|
||||
Stakeholder-Bedarfen. Der/die Stakeholder-Manager:in trennt
|
||||
den eigentlichen Bedarf von vorgeschlagenen Lösungen.
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Bedarfe in Turnus-Gesprächen erheben"
|
||||
methode: "Aktives Zuhören, gezielte Fragen"
|
||||
|
||||
- aufgabe: "Bedarfssteckbrief erstellen"
|
||||
referenz: "shm_schema_bedarfssteckbrief.yaml"
|
||||
|
||||
- aufgabe: "User Stories erheben (bei komplexeren Bedarfen)"
|
||||
referenz: "leitfaden_user-stories.yaml"
|
||||
|
||||
- aufgabe: "Rückfragen klären, Nachforderungen einholen"
|
||||
bei: "Unvollständige oder unklare Bedarfsbeschreibung"
|
||||
|
||||
ergebnis: |
|
||||
Bedarfe sind verstanden, dokumentiert und für Routing vorbereitet.
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
routing:
|
||||
|
||||
name: "Bedarfs-Routing"
|
||||
|
||||
beschreibung: |
|
||||
Kernentscheidung E2: Wohin gehört dieser Bedarf? Der/die
|
||||
Stakeholder-Manager:in ordnet Bedarfe dem richtigen Pfad zu.
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Routing-Entscheidung treffen"
|
||||
pfade:
|
||||
- "Service-Katalog → Request an Service Desk"
|
||||
- "Change an bestehendem Service → Service Owner"
|
||||
- "Neuer Demand → DPM/DSR"
|
||||
- "Unklare Zuordnung → SOR"
|
||||
referenz: "shm_bedarfsbewertung.yaml"
|
||||
|
||||
- aufgabe: "Bedarfssteckbrief an Zielfunktion übergeben"
|
||||
validierung: "Gemäß Validierungsprofil des Routing-Pfads"
|
||||
|
||||
- aufgabe: "Stakeholder über Routing informieren"
|
||||
inhalt: "Wohin geht der Bedarf, was sind nächste Schritte"
|
||||
|
||||
ergebnis: |
|
||||
Bedarfe landen an der richtigen Stelle. Stakeholder wissen,
|
||||
was mit ihrem Anliegen passiert.
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
eskalationsbehandlung:
|
||||
|
||||
name: "Reaktive Bedarfsbehandlung und Eskalation"
|
||||
|
||||
beschreibung: |
|
||||
Behandlung von Beschwerden, Problemen und eskalierenden
|
||||
Situationen. Der/die Stakeholder-Manager:in ist Erstanlaufstelle
|
||||
für Unzufriedenheit.
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Beschwerden entgegennehmen und dokumentieren"
|
||||
haltung: "Sachlich, lösungsorientiert, Kundenperspektive ernst nehmen"
|
||||
|
||||
- aufgabe: "Eskalation an zuständige Funktion weiterleiten"
|
||||
pfade:
|
||||
- "Service-Qualität → Service Owner / SPM"
|
||||
- "Demand-Status → DPM"
|
||||
- "Projekt-Verzug → PPM"
|
||||
|
||||
- aufgabe: "Nachverfolgung und Statusupdate an Stakeholder"
|
||||
differenziert_nach: "Stakeholder-Priorität (Key/Aktiv vs. Standard/Basis)"
|
||||
|
||||
ergebnis: |
|
||||
Stakeholder-Anliegen werden ernst genommen und gelöst.
|
||||
Muster werden erkannt und aggregiert.
|
||||
|
||||
referenz: "shm_engagement-framework.yaml (Abschnitt Eskalation)"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
voc_dokumentation:
|
||||
|
||||
name: "Voice of Customer Dokumentation"
|
||||
|
||||
beschreibung: |
|
||||
Systematische Erfassung von Stakeholder-Feedback als Grundlage
|
||||
für die VoC-Aggregation durch die Leitung.
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Feedback in Turnus-Gesprächen dokumentieren"
|
||||
dimensionen:
|
||||
- "Zufriedenheit mit Services"
|
||||
- "Qualität der Zusammenarbeit"
|
||||
- "Bedarfserfüllung"
|
||||
- "Kommunikation"
|
||||
|
||||
- aufgabe: "Highlights identifizieren"
|
||||
typen: ["Lob", "Kritik", "Risiko", "Chance"]
|
||||
|
||||
- aufgabe: "Signale an Leitung SHM melden"
|
||||
bei: "Kritische Entwicklungen, eskalierende Unzufriedenheit"
|
||||
|
||||
ergebnis: |
|
||||
VoC-Datenbasis für Aggregation und Review ist gepflegt.
|
||||
|
||||
referenz: "shm_voice-of-customer.yaml"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
gremienarbeit:
|
||||
|
||||
name: "Gremienarbeit (DSR)"
|
||||
|
||||
beschreibung: |
|
||||
Vertretung der Stakeholder-Perspektive in der Demand &
|
||||
Stakeholder-Runde (DSR).
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "An DSR-Sitzungen teilnehmen"
|
||||
rolle: "Kundenanwalt"
|
||||
|
||||
- aufgabe: "Stakeholder-Kontext zu Demands einbringen"
|
||||
inhalt: "Priorität, Historie, Beziehungsstatus, fachliche Perspektive"
|
||||
|
||||
- aufgabe: "Einwand-Recht ausüben"
|
||||
bei: "Demands, die gegen fundamentale Stakeholder-Interessen verstoßen"
|
||||
referenz: "GOV-SHM-021"
|
||||
|
||||
- aufgabe: "Kommunikationsstrategie bei Ablehnung abstimmen"
|
||||
mit: "DSR-Mitgliedern"
|
||||
|
||||
ergebnis: |
|
||||
Stakeholder-Perspektive fließt in Demand-Entscheidungen ein.
|
||||
|
||||
referenz: "shm_d2p-integration.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ENTSCHEIDUNGSBEFUGNISSE
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
|
||||
eigenstaendig:
|
||||
- befugnis: "Routing-Entscheidung (E2)"
|
||||
beschreibung: "Zuordnung Bedarf → Pfad (Katalog/Change/Demand/SOR)"
|
||||
einschraenkung: "Bei Unklarheit Abstimmung mit Leitung oder SOR"
|
||||
|
||||
- befugnis: "Betreuungsintensität operativ anpassen"
|
||||
beschreibung: "Zusätzliche Kontakte bei Bedarf, Gesprächsfrequenz erhöhen"
|
||||
einschraenkung: "Strukturelle Änderung der Priorisierung über Leitung"
|
||||
|
||||
- befugnis: "Eskalationspfad wählen"
|
||||
beschreibung: "Entscheidung, an welche Funktion eskaliert wird"
|
||||
|
||||
- befugnis: "Einwand in DSR erheben"
|
||||
beschreibung: "Volles Einwand-Recht als stimmberechtigtes Mitglied"
|
||||
|
||||
in_abstimmung:
|
||||
- befugnis: "Stakeholder-Priorisierung ändern"
|
||||
abstimmung_mit: "Leitung SHM"
|
||||
kontext: "Änderung des Betreuungsmodus (z.B. Standard → Aktiv)"
|
||||
|
||||
- befugnis: "Neue Stakeholder ins Portfolio aufnehmen"
|
||||
abstimmung_mit: "Leitung SHM"
|
||||
|
||||
- befugnis: "Eskalation an Vision Board"
|
||||
abstimmung_mit: "Leitung SHM"
|
||||
kontext: "Nur Leitung eskaliert an VB"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHNITTSTELLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schnittstellen:
|
||||
|
||||
intern:
|
||||
- partner: "Leitung SHM"
|
||||
interaktion: "Berichtslinie, E3-Team-Sync, Eskalation, Abstimmung"
|
||||
frequenz: "Wöchentlich (E3) + laufend"
|
||||
|
||||
- partner: "DPM (Demand-Portfolio-Manager:in)"
|
||||
interaktion: "Demand-Übergabe, Klärungsschleifen, DSR-Zusammenarbeit"
|
||||
frequenz: "Laufend"
|
||||
referenz: "shm_d2p-integration.yaml"
|
||||
|
||||
- partner: "Service Owner / SPM"
|
||||
interaktion: "Change-Routing, Service-bezogene Rückfragen"
|
||||
frequenz: "Bei Bedarf"
|
||||
|
||||
- partner: "Service Desk"
|
||||
interaktion: "Request-Weiterleitung, Eskalationsempfang"
|
||||
frequenz: "Laufend"
|
||||
|
||||
extern:
|
||||
- partner: "Stakeholder (Ämter, Einheiten)"
|
||||
interaktion: "Turnus-Gespräche, Bedarfserhebung, Statusupdates"
|
||||
frequenz: "Gemäß Betreuungsmodus"
|
||||
|
||||
- partner: "Amtsleitungen / SLA-Partner"
|
||||
interaktion: "Strategische Abstimmung, SLA-bezogene Themen"
|
||||
frequenz: "Bei Bedarf, meist über Turnus-Gespräch"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# GREMIENROLLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
gremienrollen:
|
||||
|
||||
- gremium: "DSR (Demand & Stakeholder-Runde)"
|
||||
rolle: "Stimmberechtigtes Mitglied"
|
||||
funktion: "Kundenanwalt – Vertretung der Stakeholder-Perspektive"
|
||||
befugnisse: ["Einwand-Recht", "Kontextinformation einbringen"]
|
||||
referenz: "DSR-Geschäftsordnung, GOV-SHM-021"
|
||||
|
||||
- gremium: "SOR (Service Operations Review)"
|
||||
rolle: "Teilnehmer bei Bedarf"
|
||||
funktion: "Klärung von Routing-Grenzfällen"
|
||||
referenz: "shm_sor-integration.yaml (Phase 9)"
|
||||
|
||||
- gremium: "Kundenforum (KF-01/02/03)"
|
||||
rolle: "Teilnehmer / Moderationsunterstützung"
|
||||
funktion: "Stakeholder-Interaktion in kollektiven Formaten"
|
||||
referenz: "shm_engagement-framework.yaml"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ANFORDERUNGSPROFIL
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
anforderungsprofil:
|
||||
|
||||
fachlich:
|
||||
- "Kenntnisse der Verwaltungsstruktur der Stadt Freiburg"
|
||||
- "Grundverständnis der DIGIT-Services und des Service-Katalogs"
|
||||
- "Verständnis des DIGITOM (DPM, SPM, SHM-Zusammenspiel)"
|
||||
- "ITIL4-Grundlagen (wünschenswert)"
|
||||
|
||||
methodisch:
|
||||
- "Gesprächsführung und aktives Zuhören"
|
||||
- "Bedarfsanalyse und Anforderungserhebung"
|
||||
- "Dokumentation und strukturierte Erfassung"
|
||||
- "Konfliktmanagement und Deeskalation"
|
||||
|
||||
persoenlich:
|
||||
- "Kundenorientierung und Empathie"
|
||||
- "Kommunikationsstärke (mündlich und schriftlich)"
|
||||
- "Verbindlichkeit und Zuverlässigkeit"
|
||||
- "Fähigkeit, auch unangenehme Botschaften zu vermitteln"
|
||||
- "Netzwerk-Kompetenz (internes Beziehungsmanagement)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ABGRENZUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
abgrenzung:
|
||||
|
||||
nicht_aufgabe:
|
||||
- was: "Operative Problemlösung bei Incidents"
|
||||
zustaendig: "Service Desk / Service Owner"
|
||||
klarstellung: "SHM sorgt dafür, dass Probleme an der richtigen Stelle bearbeitet werden, löst sie aber nicht selbst."
|
||||
|
||||
- was: "Demand-Klassifizierung und -Priorisierung"
|
||||
zustaendig: "DPM"
|
||||
klarstellung: "SHM entscheidet OB etwas ein Demand ist, DPM WIE er priorisiert wird."
|
||||
|
||||
- was: "SLA-Verhandlung und -Abschluss"
|
||||
zustaendig: "SPM / Service Owner"
|
||||
klarstellung: "SHM kann Stakeholder-Perspektive einbringen, aber nicht verhandeln."
|
||||
|
||||
- was: "Strategische Portfolio-Steuerung"
|
||||
zustaendig: "Leitung SHM"
|
||||
klarstellung: "Operative Betreuung ja, strategische Weiterentwicklung liegt bei Leitung."
|
||||
|
||||
- was: "Vision Board / MB-Entscheidungen"
|
||||
zustaendig: "Leitung SHM (MB), Geschäftsführung (VB)"
|
||||
klarstellung: "Stakeholder-Manager:in bringt sich über DSR ein, nicht direkt in MB/VB."
|
||||
|
||||
# =============================================================================
|
||||
# ROLLE 2: LEITUNG STAKEHOLDER MANAGEMENT
|
||||
# =============================================================================
|
||||
|
||||
leitung_shm:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# META
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
meta:
|
||||
typ: "rollenbeschreibung"
|
||||
rolle_id: "shm-l"
|
||||
rolle_name: "Leitung Stakeholder Management"
|
||||
aliases: ["SHM-Leitung", "Abteilungsleitung SHM"]
|
||||
version: "1.0"
|
||||
gueltig_ab: "[Datum]"
|
||||
geltungsbereich: "DIGITOM / Stakeholder-Management"
|
||||
|
||||
status:
|
||||
inhaltlich_abgenommen_durch: "[DIGIT-Leitung]"
|
||||
status: "entwurf"
|
||||
|
||||
kontext_tags:
|
||||
- "stakeholder-management"
|
||||
- "fuehrung"
|
||||
- "abteilungsleitung"
|
||||
- "strategie"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ROLLENZWECK
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
rollenzweck:
|
||||
|
||||
kurz: |
|
||||
Abteilungsleitung und disziplinarische Führungskraft der SHM-Funktion.
|
||||
Verantwortlich für strategische Steuerung, Qualitätssicherung und
|
||||
Vertretung der Stakeholder-Perspektive auf Leitungsebene.
|
||||
|
||||
ausfuehrlich: |
|
||||
Die Leitung Stakeholder Management führt die Abteilung
|
||||
"Digitale Schulen / QM, Service- und Prozessgovernance" und ist
|
||||
verantwortlich für die Gesamtperformance der SHM-Funktion.
|
||||
|
||||
Die Rolle umfasst:
|
||||
- Disziplinarische Führung der Stakeholder-Manager:innen
|
||||
- Strategische Steuerung des Stakeholder-Portfolios
|
||||
- Qualitätssicherung der Stakeholder-Beziehungen (VoC-Aggregation)
|
||||
- Vertretung der Stakeholder-Perspektive im Mission Board
|
||||
- Reporting an das Vision Board
|
||||
|
||||
Die Leitung agiert als Brücke zwischen operativer Kundenbetreuung
|
||||
und strategischer DIGIT-Steuerung.
|
||||
|
||||
verantwortung:
|
||||
fuer: "Gesamtperformance SHM, Stakeholder-Beziehungsqualität, Abteilungsführung"
|
||||
gegenueber: "DIGIT-Leitung / Vision Board"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ORGANISATORISCHE EINORDNUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
organisatorische_einordnung:
|
||||
|
||||
zuordnung:
|
||||
abteilung: "Digitale Schulen / QM, Service- und Prozessgovernance"
|
||||
abteilungskuerzel: "[AL-DS/SPG]" # Kürzel zu bestätigen
|
||||
position: "Abteilungsleitung"
|
||||
|
||||
berichtslinie:
|
||||
berichtet_an: "DIGIT-Leitung / Vision Board"
|
||||
|
||||
fuehrt:
|
||||
- rolle_id: "shm-m"
|
||||
rolle_name: "Stakeholder-Manager:in"
|
||||
fuehrungsart: "Disziplinarisch und fachlich"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# KERNAUFGABEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
kernaufgaben:
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
fuehrung:
|
||||
|
||||
name: "Führung und Teamentwicklung"
|
||||
|
||||
aktivitaeten:
|
||||
- "Disziplinarische Führung der Stakeholder-Manager:innen"
|
||||
- "Ressourcenplanung und -allokation"
|
||||
- "Kompetenzentwicklung im Team"
|
||||
- "E3-Team-Sync leiten (zweiwöchentlich)"
|
||||
|
||||
referenz: "shm_koordinations-und-steuerungsstruktur.yaml"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
portfolio_steuerung:
|
||||
|
||||
name: "Strategische Portfolio-Steuerung"
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Portfolio-Gesamtverantwortung"
|
||||
beschreibung: "Sicherstellen, dass alle Stakeholder angemessen betreut werden"
|
||||
|
||||
- aufgabe: "Priorisierung validieren und anpassen"
|
||||
frequenz: "Im Rahmen E2-Review"
|
||||
|
||||
- aufgabe: "Segmentierungslogik weiterentwickeln"
|
||||
bei: "Strukturelle Änderungen, neue Stakeholder-Typen"
|
||||
|
||||
- aufgabe: "Betreuungszuordnung steuern"
|
||||
beschreibung: "Welche:r Stakeholder-Manager:in betreut welche Ämter"
|
||||
|
||||
referenz: "shm_stakeholder-portfolio.yaml"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
voc_aggregation:
|
||||
|
||||
name: "Voice of Customer Aggregation"
|
||||
|
||||
beschreibung: |
|
||||
Aggregation der VoC-Daten aus dem Team zu einem Gesamtbild.
|
||||
Identifikation von Mustern, Trends und Handlungsbedarf.
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "VoC-Cluster-Status bewerten"
|
||||
frequenz: "Quartalsweise (E2-Review)"
|
||||
output: "Ampel-Matrix pro Cluster"
|
||||
|
||||
- aufgabe: "Highlights konsolidieren"
|
||||
frequenz: "Quartalsweise"
|
||||
output: "Top-Highlights für Quartalsbericht"
|
||||
|
||||
- aufgabe: "Maßnahmen bei Cluster-Rot initiieren"
|
||||
mit: "Betroffene:r Stakeholder-Manager:in"
|
||||
|
||||
- aufgabe: "Strategische Erkenntnisse ableiten"
|
||||
frequenz: "Jährlich (E1-Review)"
|
||||
output: "Input für DIGIT-Strategie"
|
||||
|
||||
referenz: "shm_voice-of-customer.yaml"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
review_reporting:
|
||||
|
||||
name: "Review und Reporting"
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "E1-Jahresbericht erstellen"
|
||||
empfaenger: "Vision Board"
|
||||
inhalt: "SHM-Jahresbilanz, VoC-Gesamtbild, strategische Empfehlungen"
|
||||
referenz: "TPL-KSS-01"
|
||||
|
||||
- aufgabe: "E2-Quartals-Reviews leiten"
|
||||
frequenz: "Quartalsweise"
|
||||
varianten: ["Standard (Q1/Q3)", "Erweitert mit Retrospektive (Q2/Q4)"]
|
||||
referenz: "TPL-KSS-02"
|
||||
|
||||
- aufgabe: "E3-Team-Sync leiten"
|
||||
frequenz: "Zweiwöchentlich"
|
||||
referenz: "TPL-KSS-03"
|
||||
|
||||
referenz: "shm_koordinations-und-steuerungsstruktur.yaml"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
gremienarbeit:
|
||||
|
||||
name: "Gremienarbeit (MB, DSR, Kundenforum)"
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Mission Board Teilnahme"
|
||||
rolle: "Vollwertiges Mitglied"
|
||||
funktion: "Stakeholder-Perspektive auf strategisch-taktischer Ebene"
|
||||
|
||||
- aufgabe: "DSR-Teilnahme (optional)"
|
||||
rolle: "Bei Bedarf, Eskalation, strategische Themen"
|
||||
anmerkung: "Operative DSR-Arbeit liegt bei Stakeholder-Manager:innen"
|
||||
|
||||
- aufgabe: "Kundenforum verantworten"
|
||||
formate: ["KF-01 Basisservices", "KF-02 Fachverfahren", "KF-03 Basis-Puls-Check"]
|
||||
rolle: "Gesamtverantwortung, ggf. Moderation"
|
||||
|
||||
referenz: "shm_d2p-integration.yaml, shm_engagement-framework.yaml"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
qualitaetssicherung:
|
||||
|
||||
name: "Qualitätssicherung SHM"
|
||||
|
||||
aktivitaeten:
|
||||
- aufgabe: "Beziehungsqualität im Portfolio überwachen"
|
||||
indikator: "Aggregierte Beziehungsqualitäts-Verteilung"
|
||||
|
||||
- aufgabe: "Methodische Standards sichern"
|
||||
was: "Turnus-Gespräche, Bedarfssteckbriefe, VoC-Dokumentation"
|
||||
|
||||
- aufgabe: "Eskalationen nachverfolgen"
|
||||
was: "Kritische Fälle, Muster erkennen"
|
||||
|
||||
- aufgabe: "Verbesserungsmaßnahmen steuern"
|
||||
quelle: "E2-Erweitert Review (Q2/Q4)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ENTSCHEIDUNGSBEFUGNISSE
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
entscheidungsbefugnisse:
|
||||
|
||||
eigenstaendig:
|
||||
- befugnis: "Stakeholder-Priorisierung anpassen"
|
||||
beschreibung: "Änderung des Betreuungsmodus für einzelne Stakeholder"
|
||||
|
||||
- befugnis: "Betreuungszuordnung ändern"
|
||||
beschreibung: "Zuweisung Stakeholder → Stakeholder-Manager:in"
|
||||
|
||||
- befugnis: "Ressourcenallokation innerhalb SHM"
|
||||
beschreibung: "Verteilung der verfügbaren Kapazität"
|
||||
|
||||
- befugnis: "Maßnahmen bei VoC-Cluster-Rot"
|
||||
beschreibung: "Initiierung von Interventionen"
|
||||
|
||||
- befugnis: "E2-Review-Entscheidungen"
|
||||
beschreibung: "Anpassungen an SHM-Arbeitsweise, Priorisierung"
|
||||
|
||||
in_abstimmung:
|
||||
- befugnis: "Strukturelle SHM-Weiterentwicklung"
|
||||
abstimmung_mit: "Vision Board / DIGIT-Leitung"
|
||||
|
||||
- befugnis: "Ressourcenaufstockung"
|
||||
abstimmung_mit: "DIGIT-Leitung"
|
||||
|
||||
- befugnis: "Änderung der Segmentierungslogik"
|
||||
abstimmung_mit: "Vision Board (bei strategischer Relevanz)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHNITTSTELLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schnittstellen:
|
||||
|
||||
intern:
|
||||
- partner: "Stakeholder-Manager:innen"
|
||||
interaktion: "Führung, E3-Sync, Eskalationsempfang, Qualitätssicherung"
|
||||
frequenz: "Wöchentlich + laufend"
|
||||
|
||||
- partner: "Abteilungsleitung Planung (DPM)"
|
||||
interaktion: "Abstimmung SHM-DPM-Schnittstelle, DSR-Koordination"
|
||||
frequenz: "Bei Bedarf"
|
||||
|
||||
- partner: "SPM-Leitung"
|
||||
interaktion: "Kundenforum-Koordination, SLA-bezogene Themen"
|
||||
frequenz: "Bei Bedarf"
|
||||
|
||||
- partner: "DIGIT-Leitung"
|
||||
interaktion: "Berichtslinie, strategische Abstimmung"
|
||||
frequenz: "Regelmäßig"
|
||||
|
||||
extern:
|
||||
- partner: "Vision Board"
|
||||
interaktion: "E1-Jahresbericht, strategische Eskalation"
|
||||
frequenz: "Jährlich (E1) + bei Bedarf"
|
||||
|
||||
- partner: "Amtsleitungen (bei Eskalation)"
|
||||
interaktion: "Direkte Klärung kritischer Stakeholder-Situationen"
|
||||
frequenz: "Bei Bedarf"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# GREMIENROLLEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
gremienrollen:
|
||||
|
||||
- gremium: "Mission Board"
|
||||
rolle: "Vollwertiges Mitglied"
|
||||
funktion: "Vertretung der Stakeholder-Perspektive auf strategisch-taktischer Ebene"
|
||||
befugnisse: ["Stimmrecht", "Einbringung strategischer Stakeholder-Themen"]
|
||||
governance_referenz: "GOV-SHM-025"
|
||||
|
||||
- gremium: "DSR (Demand & Stakeholder-Runde)"
|
||||
rolle: "Optionale Teilnahme"
|
||||
funktion: "Bei Eskalation, strategischen Themen, Unterstützung"
|
||||
anmerkung: "Operative DSR-Arbeit liegt bei Stakeholder-Manager:innen"
|
||||
|
||||
- gremium: "Kundenforum (KF-01/02/03)"
|
||||
rolle: "Gesamtverantwortung"
|
||||
funktion: "Sicherstellung der Durchführung, ggf. Moderation"
|
||||
|
||||
- gremium: "Vision Board"
|
||||
rolle: "Berichterstatter (kein Mitglied)"
|
||||
funktion: "E1-Jahresbericht, strategische Eskalation"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ANFORDERUNGSPROFIL
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
anforderungsprofil:
|
||||
|
||||
fachlich:
|
||||
- "Tiefes Verständnis der Verwaltungsstruktur und -kultur"
|
||||
- "Umfassendes Verständnis des DIGITOM"
|
||||
- "Kenntnisse in Service Management / ITIL4"
|
||||
- "Erfahrung mit Stakeholder-/Kundenmanagement"
|
||||
|
||||
methodisch:
|
||||
- "Führungskompetenz"
|
||||
- "Strategisches Denken und Handeln"
|
||||
- "Reporting und Management-Kommunikation"
|
||||
- "Qualitätsmanagement"
|
||||
- "Moderation von Gremien und Workshops"
|
||||
|
||||
persoenlich:
|
||||
- "Souveränität auf Leitungsebene"
|
||||
- "Diplomatisches Geschick"
|
||||
- "Durchsetzungsfähigkeit bei Wahrung der Kundenorientierung"
|
||||
- "Analytische Stärke (Mustererkennung, Aggregation)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ABGRENZUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
abgrenzung:
|
||||
|
||||
nicht_aufgabe:
|
||||
- was: "Operative Stakeholder-Betreuung"
|
||||
zustaendig: "Stakeholder-Manager:in"
|
||||
klarstellung: "Leitung steuert, operative Betreuung liegt im Team."
|
||||
|
||||
- was: "DSR-Tagesgeschäft"
|
||||
zustaendig: "Stakeholder-Manager:in, DPM"
|
||||
klarstellung: "Leitung nimmt nur bei Bedarf teil."
|
||||
|
||||
- was: "Demand-Entscheidungen"
|
||||
zustaendig: "DSR, Mission Board"
|
||||
klarstellung: "Leitung bringt Stakeholder-Perspektive ein, entscheidet nicht über einzelne Demands."
|
||||
|
||||
# =============================================================================
|
||||
# GOVERNANCE-ENTSCHEIDUNGEN (NEU)
|
||||
# =============================================================================
|
||||
|
||||
governance_entscheidungen:
|
||||
|
||||
- id: "GOV-SHM-025"
|
||||
datum: "2025-12-10"
|
||||
quelle_modul: "Rollenbeschreibungen (Phase 6)"
|
||||
|
||||
frage: |
|
||||
Ist die Leitung SHM Mitglied im Mission Board?
|
||||
|
||||
entscheidung: |
|
||||
Ja. Die Leitung Stakeholder Management ist vollwertiges Mitglied
|
||||
im Mission Board.
|
||||
|
||||
begruendung: |
|
||||
Die Stakeholder-Perspektive muss auf strategisch-taktischer Ebene
|
||||
vertreten sein. Während die operative DSR-Arbeit bei den
|
||||
Stakeholder-Manager:innen liegt, braucht das MB eine Person, die:
|
||||
- den Gesamt-Überblick über das Stakeholder-Portfolio hat
|
||||
- strategische Stakeholder-Themen einbringen kann
|
||||
- Entscheidungsauswirkungen auf Stakeholder bewerten kann
|
||||
|
||||
Dies präzisiert GOV-SHM-022: "SHM ist kein ständiges MB-Mitglied"
|
||||
bezieht sich auf die operative Rolle (Stakeholder-Manager:in),
|
||||
nicht auf die Leitungsrolle.
|
||||
|
||||
auswirkung_auf:
|
||||
- dokument: "shm_rollen.yaml"
|
||||
abschnitt: "leitung_shm.gremienrollen"
|
||||
- dokument: "shm_d2p-integration.yaml"
|
||||
abschnitt: "shm_rolle_mission_board"
|
||||
aenderung: "Präzisierung erforderlich"
|
||||
|
||||
status: "final"
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.1"
|
||||
datum: "2024-12-03"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: "Platzhalter erstellt"
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-12-10"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: |
|
||||
Phase 6 abgeschlossen:
|
||||
- Rollenbeschreibung Stakeholder-Manager:in vollständig
|
||||
- Rollenbeschreibung Leitung SHM vollständig
|
||||
- Governance-Entscheidung GOV-SHM-025 (MB-Mitgliedschaft Leitung)
|
||||
File diff suppressed because it is too large
Load diff
1540
#03_stakeholder-management/#03.2_governance/shm_raci.yaml
Normal file
1540
#03_stakeholder-management/#03.2_governance/shm_raci.yaml
Normal file
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,20 @@
|
|||
# ========================================
|
||||
# SHM Lifecycle Blueprint
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 3
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: "Customer Journey (DSV)"
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 3]
|
||||
700
#03_stakeholder-management/#03.3_konzepte/shm_sims-konzept.yaml
Normal file
700
#03_stakeholder-management/#03.3_konzepte/shm_sims-konzept.yaml
Normal file
|
|
@ -0,0 +1,700 @@
|
|||
# =============================================================================
|
||||
# STAKEHOLDER-INFORMATIONS-MANAGEMENT-SYSTEM (SIMS)
|
||||
# =============================================================================
|
||||
# Modul: Stakeholder-Management (SHM)
|
||||
# Typ: Konzept (Informationsmanagement)
|
||||
# Version: 1.0
|
||||
# Datum: 2025-12-11
|
||||
# Status: Entwurf
|
||||
# Entwicklungsphase: 10
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
modul_id: "SHM-K-05"
|
||||
name: "Stakeholder-Informations-Management-System (SIMS)"
|
||||
typ: "Konzept"
|
||||
|
||||
zweck: |
|
||||
Das SIMS ist das zentrale Informationssystem für die SHM-Funktion.
|
||||
Es dient der strukturierten Erfassung, Pflege und Auswertung aller
|
||||
stakeholderbezogenen Informationen, die für die Betreuung und
|
||||
Steuerung des Stakeholder-Portfolios erforderlich sind.
|
||||
|
||||
abgrenzung:
|
||||
was_sims_ist:
|
||||
- "Zentraler Ablageort für Stakeholder-Stammdaten"
|
||||
- "Dokumentationssystem für Interaktionen und Bedarfe"
|
||||
- "Grundlage für operative Steuerung und Reporting"
|
||||
|
||||
was_sims_nicht_ist:
|
||||
- "Kein Ticket-System (bleibt beim Service Desk)"
|
||||
- "Kein Demand-Management-Tool (bleibt bei DPM)"
|
||||
- "Kein CRM im vertrieblichen Sinne"
|
||||
|
||||
design_prinzipien:
|
||||
|
||||
- id: "DP-01"
|
||||
name: "Entscheidungsorientierung"
|
||||
beschreibung: |
|
||||
Jedes erfasste Attribut muss mindestens eine der SHM-Kernentscheidungen
|
||||
unterstützen (Betreuungsallokation, Bedarfsrouting, Governance-Zuordnung).
|
||||
Daten ohne Entscheidungsbezug werden nicht erfasst.
|
||||
|
||||
- id: "DP-02"
|
||||
name: "Single Source of Truth"
|
||||
beschreibung: |
|
||||
SIMS ist die führende Quelle für Stakeholder-Stammdaten innerhalb
|
||||
der SHM-Funktion. Redundante Datenhaltung ist zu vermeiden.
|
||||
|
||||
- id: "DP-03"
|
||||
name: "Minimale Komplexität"
|
||||
beschreibung: |
|
||||
Die Struktur wird so einfach wie möglich gehalten. Komplexität
|
||||
wird nur dort zugelassen, wo sie nachweislich Mehrwert schafft.
|
||||
|
||||
- id: "DP-04"
|
||||
name: "Plattformunabhängigkeit"
|
||||
beschreibung: |
|
||||
Das Konzept beschreibt fachliche Anforderungen, nicht technische
|
||||
Umsetzung. Die Wahl des Werkzeugs erfolgt separat.
|
||||
|
||||
konzept_referenzen:
|
||||
- dokument: "shm_schema_amtssteckbrief.yaml"
|
||||
beschreibung: "Attribut-Schema für Stakeholder-Stammdaten"
|
||||
- dokument: "shm_schema_bedarfssteckbrief.yaml"
|
||||
beschreibung: "Attribut-Schema für Bedarfsdokumentation"
|
||||
- dokument: "shm_engagement-framework.yaml"
|
||||
beschreibung: "Interaktionsformate und Dokumentationsanforderungen"
|
||||
- dokument: "shm_voice-of-customer.yaml"
|
||||
beschreibung: "Feedback-Dimensionen und Aggregationslogik"
|
||||
- dokument: "shm_koordinations-und-steuerungsstruktur.yaml"
|
||||
beschreibung: "Review-Artefakte und Reporting-Anforderungen"
|
||||
|
||||
# =============================================================================
|
||||
# INFORMATIONSOBJEKTE
|
||||
# =============================================================================
|
||||
|
||||
informationsobjekte:
|
||||
|
||||
beschreibung: |
|
||||
Die folgenden Informationsobjekte bilden den Kern des SIMS.
|
||||
Sie stehen in definierten Beziehungen zueinander.
|
||||
|
||||
objekte:
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# AMTS-STECKBRIEF (Kernobjekt)
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "IO-01"
|
||||
name: "Amts-Steckbrief"
|
||||
|
||||
beschreibung: |
|
||||
Zentrales Datenobjekt pro Stakeholder (Amt/Organisationseinheit).
|
||||
Enthält Stammdaten, Segmentierung, Priorisierung und Betreuungsstatus.
|
||||
|
||||
schema_referenz: "shm_schema_amtssteckbrief.yaml"
|
||||
|
||||
charakter: "Persistentes Stammdatenobjekt"
|
||||
|
||||
lebenszyklus:
|
||||
anlage: "Bei Aufnahme ins Portfolio"
|
||||
pflege: "Laufend durch zugeordneten Stakeholder-Manager"
|
||||
abschluss: "Bei Herauslösung aus Portfolio (selten)"
|
||||
|
||||
untergeordnete_elemente:
|
||||
- "Gesprächsprotokolle (als Anhänge/Untereinträge)"
|
||||
- "Interventionsdokumentation"
|
||||
- "VoC-Feedback-Einträge"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# BEDARFSSTECKBRIEF
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "IO-02"
|
||||
name: "Bedarfssteckbrief"
|
||||
|
||||
beschreibung: |
|
||||
Dokumentation eines konkreten Stakeholder-Bedarfs. Entsteht aus
|
||||
der Bedarfsbewertung und dient als Übergabedokument an nachgelagerte
|
||||
Funktionen (Service Desk, SPM, DPM).
|
||||
|
||||
schema_referenz: "shm_schema_bedarfssteckbrief.yaml"
|
||||
|
||||
charakter: "Transaktionsobjekt mit Lebenszyklus"
|
||||
|
||||
lebenszyklus:
|
||||
anlage: "Bei Bedarfserfassung durch SHM"
|
||||
pflege: "Status-Updates bei Bearbeitung"
|
||||
abschluss: "Bei Erledigung oder Ablehnung"
|
||||
|
||||
beziehung_zu_amt: |
|
||||
Jeder Bedarfssteckbrief ist genau einem Amt zugeordnet.
|
||||
Ein Amt kann mehrere Bedarfssteckbriefe haben.
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# GESPRÄCHSPROTOKOLL
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "IO-03"
|
||||
name: "Gesprächsprotokoll"
|
||||
|
||||
beschreibung: |
|
||||
Dokumentation von Turnus-Gesprächen, Workshops und anderen
|
||||
Interaktionsformaten. Wird dem jeweiligen Amt zugeordnet.
|
||||
|
||||
charakter: "Anhang/Untereintrag zum Amts-Steckbrief"
|
||||
|
||||
mindestattribute:
|
||||
- attribut: "datum"
|
||||
beschreibung: "Datum des Gesprächs"
|
||||
- attribut: "format"
|
||||
beschreibung: "Art des Formats (TF-01, TF-02, SF-01, etc.)"
|
||||
referenz: "shm_engagement-framework.yaml"
|
||||
- attribut: "teilnehmer"
|
||||
beschreibung: "Teilnehmer (DIGIT-seitig und Kundenseite)"
|
||||
- attribut: "themen"
|
||||
beschreibung: "Besprochene Themen (Stichworte)"
|
||||
- attribut: "vereinbarungen"
|
||||
beschreibung: "Konkrete Vereinbarungen mit Verantwortung/Termin"
|
||||
- attribut: "feedback_notizen"
|
||||
beschreibung: "VoC-relevante Aussagen (für Aggregation)"
|
||||
referenz: "shm_voice-of-customer.yaml"
|
||||
|
||||
aufbewahrung: |
|
||||
Protokolle bleiben dauerhaft dem Amt zugeordnet und ermöglichen
|
||||
die Nachvollziehbarkeit der Betreuungshistorie.
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# INTERVENTIONSDOKUMENTATION
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "IO-04"
|
||||
name: "Interventionsdokumentation"
|
||||
|
||||
beschreibung: |
|
||||
Dokumentation von Interventionen bei angespannter oder kritischer
|
||||
Beziehungsqualität. Enthält Ursachenanalyse, Maßnahmenplan und
|
||||
Verlauf.
|
||||
|
||||
charakter: "Anhang/Untereintrag zum Amts-Steckbrief"
|
||||
|
||||
mindestattribute:
|
||||
- attribut: "anlass"
|
||||
beschreibung: "Auslöser der Intervention"
|
||||
- attribut: "beziehungsqualitaet_start"
|
||||
beschreibung: "Bewertung bei Interventionsbeginn"
|
||||
- attribut: "ursachenanalyse"
|
||||
beschreibung: "Identifizierte Ursachen"
|
||||
- attribut: "massnahmen"
|
||||
beschreibung: "Vereinbarte Maßnahmen mit Verantwortung/Termin"
|
||||
- attribut: "status"
|
||||
beschreibung: "Aktiv / Abgeschlossen / Abgebrochen"
|
||||
- attribut: "ergebnis"
|
||||
beschreibung: "Bewertung bei Abschluss"
|
||||
|
||||
referenz: "shm_engagement-framework.yaml → beziehungsqualitaet"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# VOC-FEEDBACK-EINTRAG
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "IO-05"
|
||||
name: "VoC-Feedback-Eintrag"
|
||||
|
||||
beschreibung: |
|
||||
Einzelnes Feedback-Element aus Stakeholder-Interaktionen.
|
||||
Wird aggregiert für Cluster-Analyse und Reporting.
|
||||
|
||||
charakter: "Anhang/Untereintrag zum Amts-Steckbrief oder eigenständig"
|
||||
|
||||
mindestattribute:
|
||||
- attribut: "quelle"
|
||||
beschreibung: "Feedback-Quelle (Q-01 bis Q-06)"
|
||||
referenz: "shm_voice-of-customer.yaml"
|
||||
- attribut: "datum"
|
||||
beschreibung: "Erfassungsdatum"
|
||||
- attribut: "dimension"
|
||||
beschreibung: "Zuordnung zu D1-D4"
|
||||
- attribut: "subdimension"
|
||||
beschreibung: "Konkrete Subdimension"
|
||||
- attribut: "tendenz"
|
||||
beschreibung: "Positiv / Neutral / Negativ"
|
||||
- attribut: "kernaussage"
|
||||
beschreibung: "Zusammenfassung in 1-2 Sätzen"
|
||||
|
||||
aggregationslogik: |
|
||||
Einzelne Einträge werden gemäß shm_voice-of-customer.yaml
|
||||
zu Clustern aggregiert und in die Review-Struktur eingespeist.
|
||||
|
||||
# =============================================================================
|
||||
# STRUKTURKONZEPT
|
||||
# =============================================================================
|
||||
|
||||
strukturkonzept:
|
||||
|
||||
beschreibung: |
|
||||
Das SIMS gliedert sich in logische Bereiche, die unterschiedliche
|
||||
Informationstypen und Nutzungskontexte adressieren.
|
||||
|
||||
bereiche:
|
||||
|
||||
- id: "B-01"
|
||||
name: "Stakeholder-Portfolio"
|
||||
beschreibung: |
|
||||
Zentrale Ablage aller Amts-Steckbriefe mit zugeordneten
|
||||
Untereinträgen (Protokolle, Interventionen, Feedback).
|
||||
inhalt:
|
||||
- "Amts-Steckbriefe (IO-01)"
|
||||
- "Gesprächsprotokolle (IO-03)"
|
||||
- "Interventionsdokumentation (IO-04)"
|
||||
- "VoC-Feedback-Einträge (IO-05)"
|
||||
primaere_nutzer: "Stakeholder-Manager (operativ)"
|
||||
|
||||
- id: "B-02"
|
||||
name: "Bedarfsdokumentation"
|
||||
beschreibung: |
|
||||
Ablage aller Bedarfssteckbriefe mit Verlinkung zum
|
||||
zugehörigen Amt.
|
||||
inhalt:
|
||||
- "Bedarfssteckbriefe (IO-02)"
|
||||
primaere_nutzer: "Stakeholder-Manager, DPM (bei Übergabe)"
|
||||
|
||||
- id: "B-03"
|
||||
name: "Auswertungen und Reports"
|
||||
beschreibung: |
|
||||
Bereich für aggregierte Sichten, Dashboards und
|
||||
vorbereitete Reports (E1, E2).
|
||||
inhalt:
|
||||
- "Views (siehe Abschnitt views)"
|
||||
- "Report-Vorlagen"
|
||||
primaere_nutzer: "SHM-Leitung, Stakeholder-Manager"
|
||||
|
||||
- id: "B-04"
|
||||
name: "Arbeitsmaterialien"
|
||||
beschreibung: |
|
||||
Ablage für Templates, Leitfäden und Checklisten,
|
||||
die im SHM-Alltag verwendet werden.
|
||||
inhalt:
|
||||
- "Gesprächsvorlagen"
|
||||
- "Checklisten"
|
||||
- "Leitfäden"
|
||||
primaere_nutzer: "Stakeholder-Manager"
|
||||
referenz: "#03.7_arbeitsmaterialien/"
|
||||
|
||||
beziehungen:
|
||||
|
||||
beschreibung: |
|
||||
Die Informationsobjekte stehen in folgenden Beziehungen zueinander.
|
||||
|
||||
beziehungsmodell: |
|
||||
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ AMTS-STECKBRIEF │
|
||||
│ (IO-01) │
|
||||
│ │
|
||||
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │
|
||||
│ │ Gesprächs- │ │Interventions│ │ VoC-Feedback- │ │
|
||||
│ │ protokolle │ │dokumentation│ │ Einträge │ │
|
||||
│ │ (IO-03) │ │ (IO-04) │ │ (IO-05) │ │
|
||||
│ │ [0..*] │ │ [0..*] │ │ [0..*] │ │
|
||||
│ └─────────────┘ └─────────────┘ └─────────────────────┘ │
|
||||
└───────────────────────────┬─────────────────────────────────┘
|
||||
│
|
||||
│ 1:n
|
||||
▼
|
||||
┌─────────────────────────────┐
|
||||
│ BEDARFSSTECKBRIEF │
|
||||
│ (IO-02) │
|
||||
│ [0..*] │
|
||||
└─────────────────────────────┘
|
||||
|
||||
kardinalitaeten:
|
||||
- "Amt 1 : n Bedarfssteckbrief"
|
||||
- "Amt 1 : n Gesprächsprotokoll"
|
||||
- "Amt 1 : n Interventionsdokumentation"
|
||||
- "Amt 1 : n VoC-Feedback-Eintrag"
|
||||
|
||||
# =============================================================================
|
||||
# VIEWS (AUSWERTUNGSPERSPEKTIVEN)
|
||||
# =============================================================================
|
||||
|
||||
views:
|
||||
|
||||
beschreibung: |
|
||||
Views sind vordefinierte Auswertungsperspektiven auf die SIMS-Daten.
|
||||
Sie unterstützen die operative Arbeit und das Management-Reporting.
|
||||
|
||||
hinweis: |
|
||||
Die folgenden Views sind ein initialer Vorschlag basierend auf den
|
||||
identifizierten Nutzungsszenarien. Sie sind im Rahmen der Einführung
|
||||
zu validieren und nach Praxiserprobung anzupassen.
|
||||
|
||||
kategorien:
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# PORTFOLIO-MANAGEMENT
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- kategorie: "Portfolio-Management"
|
||||
beschreibung: "Überblick und Steuerung des Stakeholder-Portfolios"
|
||||
|
||||
views:
|
||||
|
||||
- id: "V-PF-01"
|
||||
name: "Stakeholder nach Prio-Stufe"
|
||||
zweck: "Überblick Portfolioverteilung"
|
||||
filterkriterien: "Gruppierung nach Prio-Stufe (Key/Aktiv/Standard/Basis)"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
|
||||
- id: "V-PF-02"
|
||||
name: "Meine Stakeholder"
|
||||
zweck: "Persönliche Arbeitsliste"
|
||||
filterkriterien: "Filter: Betreuungszuordnung = aktueller Nutzer"
|
||||
primaerer_nutzer: "Stakeholder-Manager"
|
||||
|
||||
- id: "V-PF-03"
|
||||
name: "Stakeholder nach Dezernat"
|
||||
zweck: "Organisatorische Cluster-Sicht"
|
||||
filterkriterien: "Gruppierung nach Dezernat"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
|
||||
- id: "V-PF-04"
|
||||
name: "Neuzugänge"
|
||||
zweck: "Onboarding-Pipeline"
|
||||
filterkriterien: "Filter: Anlage < 90 Tage oder Status = Neu"
|
||||
primaerer_nutzer: "Stakeholder-Manager"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# BEZIEHUNGSQUALITÄT
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- kategorie: "Beziehungsqualität"
|
||||
beschreibung: "Monitoring der Beziehungsqualität und Interventionen"
|
||||
|
||||
views:
|
||||
|
||||
- id: "V-BQ-01"
|
||||
name: "Beziehungs-Ampel"
|
||||
zweck: "Gesamtübersicht Beziehungsqualität"
|
||||
filterkriterien: "Alle Stakeholder mit Spalte Beziehungsqualität"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
|
||||
- id: "V-BQ-02"
|
||||
name: "Interventionsbedarf"
|
||||
zweck: "Fokus auf Problemfälle"
|
||||
filterkriterien: "Filter: Beziehungsqualität = Angespannt ODER Kritisch"
|
||||
primaerer_nutzer: "SHM-Leitung, Stakeholder-Manager"
|
||||
|
||||
- id: "V-BQ-03"
|
||||
name: "Aktive Maßnahmenpläne"
|
||||
zweck: "Nachverfolgung laufender Interventionen"
|
||||
filterkriterien: "Filter: Interventionsdokumentation.Status = Aktiv"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# ENGAGEMENT / TURNUS
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- kategorie: "Engagement und Turnus"
|
||||
beschreibung: "Planung und Nachverfolgung von Stakeholder-Interaktionen"
|
||||
|
||||
views:
|
||||
|
||||
- id: "V-EN-01"
|
||||
name: "Anstehende Turnus-Termine"
|
||||
zweck: "Terminplanung"
|
||||
filterkriterien: "Filter: Nächster Turnus ≤ 30 Tage"
|
||||
primaerer_nutzer: "Stakeholder-Manager"
|
||||
|
||||
- id: "V-EN-02"
|
||||
name: "Überfällige Kontakte"
|
||||
zweck: "Eskalations-Früherkennung"
|
||||
filterkriterien: "Filter: Letzter Kontakt > Soll-Frequenz (abgeleitet aus Betreuungsmodus)"
|
||||
primaerer_nutzer: "SHM-Leitung, Stakeholder-Manager"
|
||||
|
||||
- id: "V-EN-03"
|
||||
name: "Key-Stakeholder Jahresübersicht"
|
||||
zweck: "Strategische Betreuungsplanung"
|
||||
filterkriterien: "Filter: Prio = Key; Anzeige: alle geplanten Termine"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# BEDARFSDOKUMENTATION
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- kategorie: "Bedarfsdokumentation"
|
||||
beschreibung: "Überblick und Nachverfolgung von Stakeholder-Bedarfen"
|
||||
|
||||
views:
|
||||
|
||||
- id: "V-BD-01"
|
||||
name: "Offene Bedarfe pro Stakeholder"
|
||||
zweck: "Gesprächsvorbereitung"
|
||||
filterkriterien: "Gruppierung nach Amt; Filter: Status ≠ Abgeschlossen"
|
||||
primaerer_nutzer: "Stakeholder-Manager"
|
||||
|
||||
- id: "V-BD-02"
|
||||
name: "Bedarfe nach Routing-Pfad"
|
||||
zweck: "Prozess-Monitoring"
|
||||
filterkriterien: "Gruppierung nach Routing (REQ/SPM/DPM/SOR)"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
|
||||
- id: "V-BD-03"
|
||||
name: "Bedarfe in Wartestellung"
|
||||
zweck: "Follow-up-Liste"
|
||||
filterkriterien: "Filter: Status = Übergeben, wartend"
|
||||
primaerer_nutzer: "Stakeholder-Manager"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# REVIEW / REPORTING
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- kategorie: "Review und Reporting"
|
||||
beschreibung: "Aggregierte Sichten für E1/E2-Reviews"
|
||||
|
||||
views:
|
||||
|
||||
- id: "V-RV-01"
|
||||
name: "E2-Quartalsdaten"
|
||||
zweck: "Vorbereitung Quartalsbericht"
|
||||
filterkriterien: "Aggregation: Kontakte, Bedarfe, Interventionen im Quartal"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
referenz: "shm_koordinations-und-steuerungsstruktur.yaml → e2_quartals_review"
|
||||
|
||||
- id: "V-RV-02"
|
||||
name: "VoC-Cluster-Übersicht"
|
||||
zweck: "Feedback-Aggregation"
|
||||
filterkriterien: "Gruppierung nach Cluster; Anzeige: Ampel-Status"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
referenz: "shm_voice-of-customer.yaml → cluster"
|
||||
|
||||
- id: "V-RV-03"
|
||||
name: "E1-Jahresübersicht"
|
||||
zweck: "Vorbereitung Jahresbericht"
|
||||
filterkriterien: "Aggregation aller relevanten Metriken auf Jahresebene"
|
||||
primaerer_nutzer: "SHM-Leitung"
|
||||
referenz: "shm_koordinations-und-steuerungsstruktur.yaml → e1_jahres_review"
|
||||
|
||||
# =============================================================================
|
||||
# SCHNITTSTELLEN
|
||||
# =============================================================================
|
||||
|
||||
schnittstellen:
|
||||
|
||||
beschreibung: |
|
||||
SIMS steht nicht isoliert, sondern hat konzeptionelle Schnittstellen
|
||||
zu anderen Informationssystemen und Funktionen. Diese Schnittstellen
|
||||
sind zunächst als Informationsflüsse zu verstehen, nicht als
|
||||
technische Integrationen.
|
||||
|
||||
schnittstellen:
|
||||
|
||||
- id: "SS-01"
|
||||
name: "DPM (Demand-Portfolio-Management)"
|
||||
|
||||
richtung: "SIMS → DPM"
|
||||
|
||||
beschreibung: |
|
||||
Bei Routing-Entscheidung ROUTE-DPM wird der Bedarfssteckbrief
|
||||
an DPM übergeben. DPM übernimmt dann die weitere Bearbeitung
|
||||
im Demand-Lifecycle.
|
||||
|
||||
uebergabeobjekt: "Bedarfssteckbrief (IO-02)"
|
||||
|
||||
informationsfluss:
|
||||
von_sims:
|
||||
- "Bedarfssteckbrief mit Stakeholder-Kontext"
|
||||
- "User Stories (falls erhoben)"
|
||||
von_dpm:
|
||||
- "Status-Updates zum Demand"
|
||||
- "Entscheidungen (DSR/MB)"
|
||||
|
||||
governance_referenz: "shm_d2p-integration.yaml"
|
||||
|
||||
- id: "SS-02"
|
||||
name: "SPM (Service-Portfolio-Management)"
|
||||
|
||||
richtung: "Bidirektional"
|
||||
|
||||
beschreibung: |
|
||||
SPM liefert Service-Performance-Daten, die für Turnus-Gespräche
|
||||
und Beziehungsqualitäts-Bewertung relevant sind. SHM liefert
|
||||
Kundenfeedback und Bedarfe im Service-Kontext.
|
||||
|
||||
informationsfluss:
|
||||
von_spm:
|
||||
- "SLA-Einhaltung pro Amt/Service"
|
||||
- "Bekannte Service-Probleme"
|
||||
- "Service-Änderungen (für proaktive Kommunikation)"
|
||||
von_sims:
|
||||
- "VoC-Feedback zu Services"
|
||||
- "Bedarfssteckbriefe (bei ROUTE-SPM)"
|
||||
|
||||
hinweis: |
|
||||
Der Informationsfluss erfolgt im MVP manuell (Abfrage vor
|
||||
Turnus-Gespräch). Eine technische Integration ist optional.
|
||||
|
||||
- id: "SS-03"
|
||||
name: "Ticket-System (Service Desk)"
|
||||
|
||||
richtung: "Ticket-System → SIMS (lesend)"
|
||||
|
||||
beschreibung: |
|
||||
Für Turnus-Gespräche und Beziehungsqualitäts-Bewertung sind
|
||||
Informationen zu offenen Tickets pro Amt relevant.
|
||||
|
||||
informationsfluss:
|
||||
von_ticketsystem:
|
||||
- "Anzahl offener Tickets pro Amt"
|
||||
- "Eskalierte Tickets"
|
||||
- "Wiederkehrende Probleme"
|
||||
von_sims:
|
||||
- "(kein direkter Rückfluss)"
|
||||
|
||||
hinweis: |
|
||||
Im MVP erfolgt die Abfrage manuell. Eine automatisierte
|
||||
Einspielung ist bei entsprechendem Tooling möglich.
|
||||
|
||||
# =============================================================================
|
||||
# GOVERNANCE
|
||||
# =============================================================================
|
||||
|
||||
governance:
|
||||
|
||||
beschreibung: |
|
||||
Regeln für Datenpflege, Qualitätssicherung und Verantwortlichkeiten
|
||||
im SIMS.
|
||||
|
||||
datenpflege:
|
||||
|
||||
prinzip: |
|
||||
Jeder Datensatz hat genau einen Verantwortlichen für die Pflege.
|
||||
Die Verantwortung folgt der Betreuungszuordnung.
|
||||
|
||||
verantwortlichkeiten:
|
||||
|
||||
- objekt: "Amts-Steckbrief"
|
||||
verantwortlich: "Zugeordneter Stakeholder-Manager"
|
||||
aktualisierung: "Laufend, mindestens bei Turnus-Gespräch"
|
||||
|
||||
- objekt: "Bedarfssteckbrief"
|
||||
verantwortlich: "Erfassender Stakeholder-Manager"
|
||||
aktualisierung: "Bei Status-Änderungen"
|
||||
|
||||
- objekt: "Gesprächsprotokoll"
|
||||
verantwortlich: "Durchführender Stakeholder-Manager"
|
||||
aktualisierung: "Innerhalb von 5 Arbeitstagen nach Gespräch"
|
||||
|
||||
- objekt: "Interventionsdokumentation"
|
||||
verantwortlich: "Zugeordneter Stakeholder-Manager"
|
||||
aktualisierung: "Laufend während Intervention"
|
||||
|
||||
- objekt: "VoC-Feedback-Eintrag"
|
||||
verantwortlich: "Erfassender Stakeholder-Manager"
|
||||
aktualisierung: "Bei Erfassung (einmalig)"
|
||||
|
||||
qualitaetssicherung:
|
||||
|
||||
- id: "QS-01"
|
||||
name: "Vollständigkeitsprüfung Stammdaten"
|
||||
beschreibung: "Prüfung auf vollständige Pflichtfelder im Amts-Steckbrief"
|
||||
frequenz: "Quartalsweise (im Rahmen E2)"
|
||||
verantwortlich: "SHM-Leitung"
|
||||
referenz: "shm_schema_amtssteckbrief.yaml → validierung"
|
||||
|
||||
- id: "QS-02"
|
||||
name: "Aktualitätsprüfung"
|
||||
beschreibung: "Identifikation von Datensätzen ohne Aktualisierung > 12 Monate"
|
||||
frequenz: "Halbjährlich"
|
||||
verantwortlich: "SHM-Leitung"
|
||||
|
||||
- id: "QS-03"
|
||||
name: "Konsistenzprüfung Prio/Betreuungsmodus"
|
||||
beschreibung: "Prüfung, ob Betreuungsmodus zur Prio-Stufe passt"
|
||||
frequenz: "Quartalsweise (im Rahmen E2)"
|
||||
verantwortlich: "SHM-Leitung"
|
||||
referenz: "shm_schema_amtssteckbrief.yaml → validierung VAL-003"
|
||||
|
||||
archivierung:
|
||||
|
||||
prinzip: |
|
||||
Abgeschlossene Objekte (erledigte Bedarfe, beendete Interventionen)
|
||||
werden nicht gelöscht, sondern archiviert. Sie bleiben für
|
||||
Nachvollziehbarkeit und Trendanalysen zugänglich.
|
||||
|
||||
aufbewahrungsfristen:
|
||||
- objekt: "Amts-Steckbrief"
|
||||
frist: "Dauerhaft (solange Amt im Portfolio)"
|
||||
- objekt: "Bedarfssteckbrief"
|
||||
frist: "5 Jahre nach Abschluss"
|
||||
- objekt: "Gesprächsprotokoll"
|
||||
frist: "5 Jahre"
|
||||
- objekt: "Interventionsdokumentation"
|
||||
frist: "5 Jahre nach Abschluss"
|
||||
- objekt: "VoC-Feedback-Eintrag"
|
||||
frist: "3 Jahre"
|
||||
|
||||
hinweis: |
|
||||
Die Fristen sind initiale Vorschläge und ggf. an organisatorische
|
||||
oder rechtliche Vorgaben anzupassen.
|
||||
|
||||
# =============================================================================
|
||||
# EINFÜHRUNGSHINWEISE
|
||||
# =============================================================================
|
||||
|
||||
einfuehrung:
|
||||
|
||||
beschreibung: |
|
||||
Hinweise für die Einführung des SIMS in den operativen Betrieb.
|
||||
|
||||
empfohlenes_vorgehen:
|
||||
|
||||
- phase: "1. Toolauswahl"
|
||||
beschreibung: |
|
||||
Auswahl eines geeigneten Werkzeugs basierend auf den
|
||||
fachlichen Anforderungen dieses Konzepts.
|
||||
kriterien:
|
||||
- "Unterstützung strukturierter Datenerfassung"
|
||||
- "Flexible View-/Filtermöglichkeiten"
|
||||
- "Verlinkung zwischen Objekten"
|
||||
- "Zugänglichkeit für alle SHM-Mitarbeitenden"
|
||||
|
||||
- phase: "2. Pilotierung"
|
||||
beschreibung: |
|
||||
Erprobung mit einer Teilmenge des Portfolios (z.B. ein Dezernat)
|
||||
vor vollständigem Rollout.
|
||||
ziel: "Validierung der Struktur und Views"
|
||||
|
||||
- phase: "3. Initiale Befüllung"
|
||||
beschreibung: |
|
||||
Migration/Erfassung der Bestandsdaten für alle Stakeholder.
|
||||
hinweis: "Qualität vor Vollständigkeit bei der Erstbefüllung"
|
||||
|
||||
- phase: "4. Schulung"
|
||||
beschreibung: |
|
||||
Einweisung aller Stakeholder-Manager in Struktur und Nutzung.
|
||||
|
||||
- phase: "5. Review und Anpassung"
|
||||
beschreibung: |
|
||||
Nach 6 Monaten Betrieb: Review der Views und Struktur,
|
||||
Anpassung basierend auf Praxiserfahrung.
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-12-11"
|
||||
autor: "Konzept-Sprint Phase 10"
|
||||
aenderung: |
|
||||
Initiale Erstellung:
|
||||
- Meta-Informationen und Design-Prinzipien
|
||||
- Informationsobjekte IO-01 bis IO-05 definiert
|
||||
- Strukturkonzept mit 4 Bereichen
|
||||
- 16 Views in 5 Kategorien (als Vorschlag)
|
||||
- Konzeptionelle Schnittstellen zu DPM, SPM, Ticket-System
|
||||
- Governance (Datenpflege, QS, Archivierung)
|
||||
- Einführungshinweise
|
||||
|
|
@ -0,0 +1,950 @@
|
|||
# =============================================================================
|
||||
# SHM STAKEHOLDER-PORTFOLIO: KONZEPT
|
||||
# =============================================================================
|
||||
# Modul: Stakeholder-Management (SHM)
|
||||
# Funktion: Konzepte
|
||||
# Version: 1.3
|
||||
# Datum: 2026-01-23
|
||||
# Status: Final
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
modul_id: "SHM-K-01"
|
||||
name: "Stakeholder-Portfolio"
|
||||
typ: "Konzept"
|
||||
|
||||
zweck: |
|
||||
Das Stakeholder-Portfolio ist das zentrale Steuerungsinstrument des
|
||||
Stakeholder-Managements. Es erfasst alle Organisationseinheiten im
|
||||
Kundenkreis von DIGIT, segmentiert sie nach relevanten Dimensionen
|
||||
und priorisiert sie für die Ressourcenallokation.
|
||||
|
||||
Das Portfolio ist kein Selbstzweck, sondern ein Entscheidungsinstrument.
|
||||
Seine Struktur folgt aus den Entscheidungen, die es unterstützen soll.
|
||||
|
||||
scope: |
|
||||
Alle Organisationseinheiten im Dezernatsverteilungsplan der Stadt:
|
||||
- Ämter
|
||||
- Eigenbetriebe
|
||||
- Referate
|
||||
- Stabsstellen
|
||||
- Projektgruppen
|
||||
|
||||
governance_referenzen:
|
||||
- "GOV-SHM-001 bis GOV-SHM-014"
|
||||
- "readme_shm_governance-entscheidungs-log.yaml"
|
||||
|
||||
schema_referenz:
|
||||
dokument: "shm_schema_amtssteckbrief.yaml"
|
||||
beschreibung: "Technisches Attribut-Schema für die Datenerfassung pro Amt"
|
||||
|
||||
# =============================================================================
|
||||
# FUNKTIONALE HERLEITUNG
|
||||
# =============================================================================
|
||||
|
||||
funktionale_herleitung:
|
||||
|
||||
leitfrage: |
|
||||
Welche Entscheidungen soll das Stakeholder-Portfolio ermöglichen?
|
||||
|
||||
kernentscheidungen:
|
||||
|
||||
- id: PKE-1
|
||||
name: "Betreuungsallokation"
|
||||
leitfrage: "Wer wird wie intensiv betreut?"
|
||||
kontext: |
|
||||
Ressourcenknappheit erfordert Priorisierung. Nicht alle Ämter
|
||||
können gleich intensiv betreut werden. Das Portfolio muss helfen,
|
||||
die Betreuungsintensität systematisch zu differenzieren.
|
||||
unterstuetzt_durch:
|
||||
- "Priorisierung (Ebene 3)"
|
||||
- "Betreuungsmodus-Ableitung"
|
||||
|
||||
- id: PKE-2
|
||||
name: "Bedarfsrouting"
|
||||
leitfrage: "Wohin gehört dieser Bedarf?"
|
||||
kontext: |
|
||||
Wenn ein Bedarf eingeht, muss SHM entscheiden: Ist das ein
|
||||
Service-Request (→ Katalog), ein Change an bestehendem Service
|
||||
(→ Service Owner), oder ein neuer Demand (→ DPM)? Das Wissen
|
||||
über den Stakeholder und sein typisches Bedarfsprofil beeinflusst
|
||||
diese Einordnung.
|
||||
unterstuetzt_durch:
|
||||
- "Segmentierung (Ebene 2)"
|
||||
- "Funktion + IT-Anforderungsprofil"
|
||||
|
||||
- id: PKE-3
|
||||
name: "Governance-Zuordnung"
|
||||
leitfrage: "Wer sitzt in welchem Gremium?"
|
||||
kontext: |
|
||||
Für SLAs (Kundenvertretungen), für Bedarfspriorisierung (DSR),
|
||||
für strategische Abstimmung braucht es Zuordnungslogiken.
|
||||
Das IT-Anforderungsprofil korrespondiert mit den SPM-Service-
|
||||
Kategorien und damit mit der Gremienstruktur.
|
||||
unterstuetzt_durch:
|
||||
- "IT-Anforderungsprofil → SPM-Kategorie-Mapping"
|
||||
- "SLA-Befugnis im Amts-Steckbrief"
|
||||
|
||||
# =============================================================================
|
||||
# DREI-EBENEN-MODELL
|
||||
# =============================================================================
|
||||
|
||||
drei_ebenen_modell:
|
||||
|
||||
beschreibung: |
|
||||
Das Portfolio ist in drei Ebenen strukturiert, die aufeinander aufbauen:
|
||||
|
||||
1. Amts-Steckbrief – Datengrundlage pro Organisationseinheit
|
||||
2. Segmentierung – Clustering nach zwei unabhängigen Dimensionen
|
||||
3. Priorisierung – Bewertung zur Ableitung des Betreuungsmodus
|
||||
|
||||
Ergänzend: Der Betreuungsstatus (Stammdaten) dokumentiert, ob eine
|
||||
Zusammenarbeit mit dem Amt überhaupt möglich ist – unabhängig von
|
||||
dessen Wichtigkeit (Priorisierung).
|
||||
|
||||
governance_referenz: "GOV-SHM-001"
|
||||
|
||||
# =============================================================================
|
||||
# BETREUUNGSSTATUS-KONZEPT
|
||||
# =============================================================================
|
||||
|
||||
betreuungsstatus_konzept:
|
||||
|
||||
beschreibung: |
|
||||
Der Betreuungsstatus ist ein Stammdatum (nicht Teil der Priorisierung),
|
||||
das dokumentiert, ob eine Zusammenarbeit mit einem Amt möglich ist.
|
||||
|
||||
Hintergrund:
|
||||
Die Priorisierungsdimensionen (Einfluss, Abhängigkeit, Relevanz)
|
||||
beantworten die Frage "Wie wichtig ist das Amt?". Sie beantworten
|
||||
nicht "Können wir mit dem Amt zusammenarbeiten?"
|
||||
|
||||
Beispiele für eingeschränkte Zusammenarbeit:
|
||||
- Feuerwehr: Getrennte IT-Systeme, keine DIGIT-Betreuung
|
||||
- Amt X: Schwierige Beziehung, Zugang erschwert
|
||||
|
||||
Diese Ämter sollen im Portfolio dokumentiert bleiben (Vollständigkeit),
|
||||
aber die Betreuungslogik muss die Realität abbilden.
|
||||
|
||||
governance_referenz: "GOV-SHM-028"
|
||||
schema_referenz: "shm_schema_amtssteckbrief.yaml → stammdaten.betreuungsstatus"
|
||||
|
||||
auspraegungen:
|
||||
|
||||
- id: "AKTIV"
|
||||
name: "Aktiv"
|
||||
beschreibung: |
|
||||
Zusammenarbeit möglich. Normale Priorisierung greift,
|
||||
Betreuungsmodus wird direkt aus Prio-Stufe abgeleitet.
|
||||
konsequenz: "effektiver_betreuungsmodus = betreuungsmodus (aus Prio-Stufe)"
|
||||
|
||||
- id: "EINGESCHRAENKT"
|
||||
name: "Eingeschränkt"
|
||||
beschreibung: |
|
||||
Zusammenarbeit nur punktuell möglich. Priorisierung greift,
|
||||
aber Betreuungsmodus wird auf individuell festgelegtes
|
||||
Maximum gedeckelt.
|
||||
konsequenz: |
|
||||
effektiver_betreuungsmodus = MIN(betreuungsmodus, max_betreuungsmodus)
|
||||
Beispiel: Key-Stakeholder mit max_betreuungsmodus REGELMAESSIG
|
||||
→ effektiver_betreuungsmodus = REGELMAESSIG (nicht PROAKTIV_DEDIZIERT)
|
||||
pflichtfelder:
|
||||
- "begruendung (min. 30 Zeichen)"
|
||||
- "max_betreuungsmodus"
|
||||
- "entschieden_von"
|
||||
- "entschieden_am"
|
||||
|
||||
- id: "RUHEND"
|
||||
name: "Ruhend"
|
||||
beschreibung: |
|
||||
Aktuell keine Zusammenarbeit möglich. Amt bleibt im
|
||||
Portfolio dokumentiert, aber außerhalb aktiver Betreuung.
|
||||
Priorisierung wird trotzdem erfasst (für Reaktivierung).
|
||||
konsequenz: "effektiver_betreuungsmodus = KEINE_AKTIVE_BETREUUNG"
|
||||
pflichtfelder:
|
||||
- "begruendung (min. 30 Zeichen)"
|
||||
- "entschieden_von"
|
||||
- "entschieden_am"
|
||||
|
||||
vorteile:
|
||||
- "Vollständigkeit: Alle Ämter bleiben im Portfolio dokumentiert"
|
||||
- "Flexibilität: Bei Statusänderung einfache Umstellung"
|
||||
- "Saubere Priorisierung: Nur Wichtigkeit, nicht Machbarkeit"
|
||||
- "Reporting: Filter nach 'aktiv betreute Ämter' vs. 'Gesamtportfolio'"
|
||||
- "Transparenz: Gründe für eingeschränkte Zusammenarbeit dokumentiert"
|
||||
|
||||
entscheidungsbefugnis:
|
||||
rolle: "Leitung SHM"
|
||||
begruendung: |
|
||||
Die Entscheidung, ein Amt als 'ruhend' oder 'eingeschränkt' zu
|
||||
klassifizieren, hat strategische Konsequenzen und sollte nicht
|
||||
willkürlich getroffen werden. Die Leitung SHM hat den Gesamtüberblick
|
||||
über das Portfolio und kann die Entscheidung im Kontext bewerten.
|
||||
dokumentation: |
|
||||
Jede Entscheidung muss dokumentiert werden:
|
||||
- Wer hat entschieden (entschieden_von)
|
||||
- Wann wurde entschieden (entschieden_am)
|
||||
- Warum (begruendung)
|
||||
- Wann wird der Status überprüft (naechste_pruefung, empfohlen)
|
||||
|
||||
review:
|
||||
zyklus: "Im Portfolio-Review (E2-Standard/Erweitert)"
|
||||
inhalt: |
|
||||
Bei jedem Portfolio-Review wird geprüft:
|
||||
- Sind EINGESCHRÄNKT- und RUHEND-Status noch aktuell?
|
||||
- Haben sich Rahmenbedingungen geändert?
|
||||
- Sollten Ämter reaktiviert werden?
|
||||
|
||||
# =============================================================================
|
||||
# EBENE 1: AMTS-STECKBRIEF
|
||||
# =============================================================================
|
||||
|
||||
ebene_1_amtssteckbrief:
|
||||
|
||||
beschreibung: |
|
||||
Jede Organisationseinheit im Scope erhält einen Amts-Steckbrief.
|
||||
Dieser enthält alle Informationen, die für die drei Kernentscheidungen
|
||||
(Betreuungsallokation, Bedarfsrouting, Governance-Zuordnung) benötigt
|
||||
werden.
|
||||
|
||||
herleitung: |
|
||||
Die Attribute des Steckbriefs sind nicht willkürlich gewählt, sondern
|
||||
leiten sich aus den Kernentscheidungen ab. Jedes Attribut muss
|
||||
mindestens eine der drei Entscheidungen unterstützen. Attribute ohne
|
||||
klaren Entscheidungsbezug werden nicht erfasst.
|
||||
|
||||
attribut_kategorien:
|
||||
|
||||
- kategorie: "Stammdaten"
|
||||
zweck: "Identifikation und organisatorische Einordnung"
|
||||
entscheidungsbezug: "Alle (PKE-1, PKE-2, PKE-3)"
|
||||
beispiele:
|
||||
- "Amt/Organisationseinheit"
|
||||
- "Dezernat"
|
||||
- "Amtsleitung"
|
||||
- "SLA-Befugnis (wer hat Entscheidungsbefugnis)"
|
||||
|
||||
- kategorie: "Segmentierung"
|
||||
zweck: "Einordnung in die zweidimensionale Matrix"
|
||||
entscheidungsbezug: "PKE-2 Bedarfsrouting, PKE-3 Governance"
|
||||
beispiele:
|
||||
- "Funktion (Sondereinheit/Querschnitt/Bürgerservice/Fachamt)"
|
||||
- "IT-Anforderungsprofil (Basis/Erweitert/Spezial)"
|
||||
|
||||
- kategorie: "Priorisierung"
|
||||
zweck: "Bewertung für Betreuungsallokation"
|
||||
entscheidungsbezug: "PKE-1 Betreuungsallokation"
|
||||
beispiele:
|
||||
- "Einfluss (boolean)"
|
||||
- "Abhängigkeit (boolean)"
|
||||
- "Relevanz (boolean)"
|
||||
- "Prio-Stufe (abgeleitet)"
|
||||
- "Betreuungsmodus (abgeleitet)"
|
||||
|
||||
- kategorie: "Governance"
|
||||
zweck: "Gremien-Zuordnung und Vertretungslogik"
|
||||
entscheidungsbezug: "PKE-3 Governance-Zuordnung"
|
||||
beispiele:
|
||||
- "Gremien-Mitgliedschaften"
|
||||
|
||||
- kategorie: "Betreuung"
|
||||
zweck: "Operative Beziehungspflege"
|
||||
entscheidungsbezug: "E1 Betreuungsallokation"
|
||||
beispiele:
|
||||
- "Zugeordneter Stakeholder-Manager"
|
||||
- "Beziehungsqualität"
|
||||
- "Aktive Themen"
|
||||
|
||||
schema_verweis: |
|
||||
Das vollständige Attribut-Schema mit Datentypen, Wertelisten und
|
||||
Validierungsregeln ist in shm_schema_amtssteckbrief.yaml dokumentiert.
|
||||
|
||||
# =============================================================================
|
||||
# EBENE 2: SEGMENTIERUNG
|
||||
# =============================================================================
|
||||
|
||||
ebene_2_segmentierung:
|
||||
|
||||
beschreibung: |
|
||||
Die Segmentierung erfolgt zweidimensional. Beide Dimensionen sind
|
||||
unabhängig voneinander. Jedes Amt erhält genau eine Ausprägung pro
|
||||
Dimension (keine Mehrfachzuordnung, keine Tags).
|
||||
|
||||
governance_referenz: "GOV-SHM-002"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# DIMENSION 1: FUNKTION
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
dimension_1_funktion:
|
||||
|
||||
name: "Funktion"
|
||||
beschreibung: "Organisatorische Rolle des Amtes in der Stadtverwaltung"
|
||||
|
||||
governance_referenz: "GOV-SHM-003"
|
||||
|
||||
auspraegungen:
|
||||
|
||||
- id: "SONDER"
|
||||
name: "Sondereinheit"
|
||||
charakteristik: |
|
||||
Organisatorisch eigenständig, eigene Rechtsform oder
|
||||
Sonderstatus (Eigenbetriebe, Stabsstellen, Projektgruppen)
|
||||
beispiele:
|
||||
- "Eigenbetrieb Stadtentwässerung"
|
||||
- "Eigenbetrieb Theater"
|
||||
- "Stabsstelle Digitalisierung"
|
||||
|
||||
- id: "QUER"
|
||||
name: "Querschnittsamt"
|
||||
charakteristik: |
|
||||
Erbringt interne Dienstleistungen für andere Ämter,
|
||||
hat Multiplikator-Wirkung
|
||||
beispiele:
|
||||
- "Haupt- und Personalamt"
|
||||
- "Stadtkämmerei"
|
||||
- "Rechtsamt"
|
||||
|
||||
- id: "BUERGER"
|
||||
name: "Bürgerservice"
|
||||
charakteristik: |
|
||||
Direkter Bürgerkontakt als Kernaufgabe,
|
||||
hohe externe Sichtbarkeit
|
||||
beispiele:
|
||||
- "Amt für Bürgerservice"
|
||||
- "Standesamt"
|
||||
- "Amt für Soziales"
|
||||
|
||||
- id: "FACH"
|
||||
name: "Fachamt"
|
||||
charakteristik: |
|
||||
Spezialisierte Fachaufgaben, oft technisch geprägt,
|
||||
geringerer direkter Bürgerkontakt
|
||||
beispiele:
|
||||
- "Stadtplanungsamt"
|
||||
- "Garten- und Tiefbauamt"
|
||||
- "Umweltschutzamt"
|
||||
|
||||
zuordnungslogik:
|
||||
|
||||
grundprinzip: |
|
||||
Die Funktionszuordnung unterscheidet zwischen Primärfunktion
|
||||
(steuernd) und Sekundärfunktion (informierend).
|
||||
|
||||
- Primärfunktion: Bestimmt Bedarfsrouting und Governance-Zuordnung
|
||||
- Sekundärfunktion: Dokumentiert Kontext für differenzierte Betrachtung
|
||||
|
||||
Nicht jedes Amt hat eine Sekundärfunktion. Sie wird nur vergeben,
|
||||
wenn ein Amt deutlich erkennbare Charakteristika einer zweiten
|
||||
Funktionskategorie aufweist.
|
||||
|
||||
governance_referenz: "GOV-SHM-027"
|
||||
|
||||
# -----------------------------------------------------------------------
|
||||
# PRIMÄRFUNKTIONSBESTIMMUNG
|
||||
# -----------------------------------------------------------------------
|
||||
|
||||
primaerfunktion:
|
||||
|
||||
beschreibung: |
|
||||
Die Primärfunktion wird durch einen Entscheidungsbaum bestimmt.
|
||||
Die erste zutreffende Kategorie gewinnt (Dominanzprinzip).
|
||||
|
||||
entscheidungsbaum:
|
||||
|
||||
schritt_1:
|
||||
frage: "Ist das Amt organisatorisch eigenständig?"
|
||||
indikatoren:
|
||||
- "Eigene Rechtsform (Eigenbetrieb)"
|
||||
- "Sonderstatus (Stabsstelle, Projektgruppe)"
|
||||
- "Nicht in regulärer Amtsstruktur eingegliedert"
|
||||
ja: "SONDER (Sondereinheit)"
|
||||
nein: "weiter zu Schritt 2"
|
||||
|
||||
schritt_2:
|
||||
frage: "Erbringt das Amt primär interne Dienstleistungen für andere Ämter?"
|
||||
indikatoren:
|
||||
- "Hauptaufgabe ist Unterstützung anderer Ämter"
|
||||
- "Querschnittsfunktion (Personal, Finanzen, Recht, IT, Organisation)"
|
||||
- "Multiplikator-Wirkung auf andere Ämter"
|
||||
ja: "QUER (Querschnittsamt)"
|
||||
nein: "weiter zu Schritt 3"
|
||||
|
||||
schritt_3:
|
||||
frage: "Hat das Amt direkten Bürgerkontakt als Kernaufgabe?"
|
||||
indikatoren:
|
||||
- "Publikumsverkehr ist zentrale Aufgabe"
|
||||
- "Bürger:innen sind primäre Zielgruppe"
|
||||
- "Hohe externe Sichtbarkeit durch Bürger-Interaktion"
|
||||
ja: "BUERGER (Bürgerservice)"
|
||||
nein: "FACH (Fachamt)"
|
||||
|
||||
entscheidungshilfe_bei_mehrdeutigkeit: |
|
||||
Wenn ein Amt mehrere Charakteristika erfüllt, gilt:
|
||||
|
||||
1. Dominanzprinzip anwenden: Die erste zutreffende Kategorie
|
||||
im Entscheidungsbaum bestimmt die Primärfunktion.
|
||||
|
||||
2. Hauptaufgabe identifizieren: Was ist der Kern-Auftrag des Amtes
|
||||
laut Dezernatsverteilungsplan oder Geschäftsverteilungsplan?
|
||||
|
||||
3. Ressourcenallokation prüfen: Wohin fließen die meisten Ressourcen
|
||||
(Personal, Budget, Zeit)?
|
||||
|
||||
4. Selbstverständnis einbeziehen: Wie beschreibt das Amt selbst
|
||||
seine Hauptaufgabe?
|
||||
|
||||
Beispiel Stadtkämmerei:
|
||||
- Erfüllt Querschnitts-Kriterien (Finanzdienstleistungen für alle Ämter)
|
||||
- Hat auch Fachamt-Charakteristika (spezialisierte Haushaltsführung)
|
||||
→ Primärfunktion: QUER (Querschnittsamt), da interne Dienstleistung
|
||||
die Kernaufgabe ist
|
||||
|
||||
# -----------------------------------------------------------------------
|
||||
# SEKUNDÄRFUNKTIONSBESTIMMUNG
|
||||
# -----------------------------------------------------------------------
|
||||
|
||||
sekundaerfunktion:
|
||||
|
||||
beschreibung: |
|
||||
Die Sekundärfunktion dokumentiert eine zusätzliche Funktions-
|
||||
charakteristik, die für Kontext und differenzierte Betrachtung
|
||||
relevant ist.
|
||||
|
||||
vergabe_kriterien: |
|
||||
Eine Sekundärfunktion wird vergeben, wenn:
|
||||
|
||||
1. Das Amt deutlich erkennbare Charakteristika einer zweiten
|
||||
Funktionskategorie aufweist (nicht nur marginal)
|
||||
|
||||
2. Diese zweite Funktion für Bedarfsrouting oder Governance
|
||||
relevant sein kann (z.B. Bedarfe, die eher zur Sekundär-
|
||||
funktion passen)
|
||||
|
||||
3. Die Zuordnung nachvollziehbar begründet werden kann
|
||||
|
||||
nicht_vergeben_wenn: |
|
||||
Keine Sekundärfunktion, wenn:
|
||||
|
||||
- Das Amt klar einer einzigen Kategorie zuzuordnen ist
|
||||
- Die zweite Charakteristik nur marginal ausgeprägt ist
|
||||
- Kein praktischer Nutzen für Routing oder Governance erkennbar ist
|
||||
|
||||
moegliche_kombinationen:
|
||||
|
||||
- primaer: "QUER"
|
||||
sekundaer: "FACH"
|
||||
typisch: true
|
||||
beispiel: "Stadtkämmerei (Querschnitt + spezialisierte Haushaltsführung)"
|
||||
|
||||
- primaer: "QUER"
|
||||
sekundaer: "BUERGER"
|
||||
typisch: false
|
||||
beispiel: "Haupt- und Personalamt mit Bürgerbüro-Funktion"
|
||||
|
||||
- primaer: "BUERGER"
|
||||
sekundaer: "FACH"
|
||||
typisch: true
|
||||
beispiel: "Amt für Soziales (Bürgerservice + spezialisierte Sozialarbeit)"
|
||||
|
||||
- primaer: "FACH"
|
||||
sekundaer: "BUERGER"
|
||||
typisch: true
|
||||
beispiel: "Baurechtsamt (Fachamt + Bauberatung für Bürger:innen)"
|
||||
|
||||
- primaer: "FACH"
|
||||
sekundaer: "QUER"
|
||||
typisch: false
|
||||
beispiel: "IT-Amt mit internen Dienstleistungen (eher selten)"
|
||||
|
||||
- primaer: "SONDER"
|
||||
sekundaer: "beliebig"
|
||||
typisch: true
|
||||
beispiel: "Eigenbetrieb mit Bürgerservice-Anteil"
|
||||
|
||||
ausgeschlossene_kombinationen:
|
||||
- kombination: "gleiche Primär- und Sekundärfunktion"
|
||||
grund: "Logisch unmöglich"
|
||||
|
||||
# -----------------------------------------------------------------------
|
||||
# OPERATIVE ANWENDUNG
|
||||
# -----------------------------------------------------------------------
|
||||
|
||||
operative_anwendung:
|
||||
|
||||
verwendung_primaerfunktion:
|
||||
- "Bedarfsrouting (PKE-2): Bestimmt typisches Bedarfsprofil"
|
||||
- "Governance-Zuordnung (PKE-3): Bestimmt Gremien-Mitgliedschaften"
|
||||
- "Betreuungsallokation (PKE-1): Kontextinformation für Priorisierung"
|
||||
|
||||
verwendung_sekundaerfunktion:
|
||||
- "Bedarfsrouting: Differenzierte Betrachtung bei Bedarfen, die eher
|
||||
zur Sekundärfunktion passen"
|
||||
- "Governance: Optionale Einbindung in Gremien der Sekundärkategorie"
|
||||
- "Bedarfsvorhersage: Vollständigeres Bild des typischen Bedarfsprofils"
|
||||
- "Transparenz: Dokumentation für Nachvollziehbarkeit"
|
||||
|
||||
steuerungsprinzip: |
|
||||
Primärfunktion steuert, Sekundärfunktion informiert.
|
||||
|
||||
Bei Entscheidungen (Routing, Governance) ist die Primärfunktion
|
||||
maßgeblich. Die Sekundärfunktion kann bei begründeten Ausnahmen
|
||||
herangezogen werden, überschreibt aber nie die Primärfunktion.
|
||||
|
||||
dokumentationspflicht: |
|
||||
Bei Vergabe einer Sekundärfunktion muss im Amts-Steckbrief eine
|
||||
Begründung dokumentiert werden, die erklärt:
|
||||
- Warum das Amt Charakteristika der Sekundärkategorie aufweist
|
||||
- Welche praktische Relevanz die Sekundärfunktion hat
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# DIMENSION 2: IT-ANFORDERUNGSPROFIL
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
dimension_2_it_profil:
|
||||
|
||||
name: "IT-Anforderungsprofil"
|
||||
beschreibung: |
|
||||
Komplexität der IT-Bedarfe des Amtes. Die Dimension ist
|
||||
bedarfsorientiert (nicht nutzungsorientiert), um zukünftige
|
||||
Bedarfe vorherzusagen, nicht nur den Status quo abzubilden.
|
||||
|
||||
governance_referenz: "GOV-SHM-004"
|
||||
|
||||
auspraegungen:
|
||||
|
||||
- id: "BASIS"
|
||||
name: "Basis"
|
||||
charakteristik: |
|
||||
Standardbedarf, Grundausstattung reicht aus,
|
||||
geringe IT-Komplexität
|
||||
spm_korrespondenz: "Kategorie A – Basis-Services"
|
||||
typische_services:
|
||||
- "Standard-Arbeitsplatz (Büro-PC, Office-Anwendungen)"
|
||||
- "E-Mail und Kalender"
|
||||
- "Zugang zu zentralen Verwaltungssystemen"
|
||||
beispiele:
|
||||
- "Rechtsamt"
|
||||
- "Rechnungsprüfungsamt"
|
||||
- "Standesamt"
|
||||
|
||||
- id: "ERWEITERT"
|
||||
name: "Erweitert"
|
||||
charakteristik: |
|
||||
Fachspezifische Bedarfe über Standard hinaus,
|
||||
mittlere IT-Komplexität. Häufig: Benötigt Zugriff auf
|
||||
Daten im Außendienst – erbringt einen erheblichen Teil
|
||||
der Arbeit außerhalb des Bürostandorts und benötigt dabei
|
||||
Zugriff auf städtische oder weitere relevante Daten
|
||||
(Baupläne, Elektropläne, Meldedaten, KFZ-Daten etc.).
|
||||
spm_korrespondenz: "Kategorie B – Erweiterte Services"
|
||||
typische_services:
|
||||
- "Mobile Hardware (VPN-Notebook, EC-Cash-Gerät etc.)"
|
||||
- "Zugriffe auf interne Daten außerhalb vom Bürostandort"
|
||||
- "Fachverfahren mit erweitertem Funktionsumfang"
|
||||
- "DMS, Terminbuchung, Workflow-Systeme"
|
||||
beispiele:
|
||||
- "Haupt- und Personalamt"
|
||||
- "Amt für Bürgerservice"
|
||||
- "Umweltschutzamt"
|
||||
|
||||
- id: "SPEZIAL"
|
||||
name: "Spezial"
|
||||
charakteristik: |
|
||||
Individuelle Bedarfe, die nur für dieses Amt gelten,
|
||||
hohe IT-Komplexität, Spezialsoftware, bilaterale SLAs.
|
||||
Arbeiten aus dem Homeoffice oft nur durch besondere
|
||||
Lösungen möglich (Standard-Homeoffice-Lösungen greifen nicht).
|
||||
spm_korrespondenz: "Kategorie C – Spezial-Services"
|
||||
typische_services:
|
||||
- "Exklusive Fachsoftware (CAD, GIS, Spezialsysteme)"
|
||||
- "Spezialhardware (Plotter, Messgeräte, Spezialdrucker)"
|
||||
- "Individuelle Schnittstellenlösungen"
|
||||
- "Besondere Homeoffice-/Remote-Lösungen"
|
||||
beispiele:
|
||||
- "Stadtplanungsamt (CAD, GIS)"
|
||||
- "Garten- und Tiefbauamt"
|
||||
- "Immobilienmanagement (Eigenbetrieb)"
|
||||
|
||||
zuordnungslogik: |
|
||||
Entscheidungsbaum:
|
||||
|
||||
1. Hat das Amt individuelle IT-Bedarfe, die NUR für dieses Amt
|
||||
gelten? (exklusive Fachsoftware, Spezialhardware, bilaterale SLAs)
|
||||
→ JA: Spezial
|
||||
→ NEIN: weiter zu 2.
|
||||
|
||||
2. Hat das Amt fachspezifische IT-Bedarfe über die Grundausstattung
|
||||
hinaus? (DMS, Fachverfahren, Terminbuchung, Workflow-Systeme)
|
||||
→ JA: Erweitert
|
||||
→ NEIN: Basis
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# MATRIX
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
matrix:
|
||||
|
||||
beschreibung: |
|
||||
Die Kombination der beiden Dimensionen ergibt eine 4×3-Matrix.
|
||||
Jedes Amt wird genau einem Feld zugeordnet. Nicht alle
|
||||
Kombinationen sind gleich häufig oder wahrscheinlich.
|
||||
|
||||
governance_referenz: "GOV-SHM-006"
|
||||
|
||||
hinweis_sondereinheiten: |
|
||||
Sondereinheiten sind eine Funktionskategorie, keine Ausnahme
|
||||
von der zweidimensionalen Logik. Sie haben wie alle anderen
|
||||
Ämter ein IT-Anforderungsprofil.
|
||||
|
||||
unwahrscheinliche_kombinationen:
|
||||
- kombination: "Querschnitt + Spezial"
|
||||
begruendung: |
|
||||
Querschnittsämter erbringen standardisierte interne Services.
|
||||
Hochspezialisierte IT-Bedarfe sind untypisch.
|
||||
- kombination: "Bürgerservice + Spezial"
|
||||
begruendung: |
|
||||
Bürgerservice-Ämter nutzen typischerweise standardisierte
|
||||
Bürger-Fachverfahren, keine exklusiven Spezial-Lösungen.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# VERKNÜPFUNG ZU ENTSCHEIDUNGEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
verknuepfung_entscheidungen:
|
||||
|
||||
bedarfsrouting_PKE2:
|
||||
relevante_dimensionen: "Funktion + IT-Profil"
|
||||
logik: |
|
||||
Die Kombination hilft, typische Bedarfe vorherzusagen:
|
||||
- Bürgerservice + Erweitert → Terminbuchung, Aufrufsysteme, DMS
|
||||
- Fachamt + Spezial → CAD, GIS, Spezialhardware
|
||||
- Querschnitt + Erweitert → Personalverwaltung, Finanz-Systeme
|
||||
|
||||
governance_zuordnung_PKE3:
|
||||
relevante_dimension: "IT-Anforderungsprofil"
|
||||
logik: |
|
||||
Das IT-Profil korrespondiert mit SPM-Kategorien und damit
|
||||
mit der SLA-Governance:
|
||||
- Basis-Profil → primär in Kundenvertretung Basisservices (Kat. A)
|
||||
- Erweitert-Profil → in servicespezifischen Kundenvertretungen (Kat. B)
|
||||
- Spezial-Profil → bilaterale SLAs (Kat. C)
|
||||
|
||||
# =============================================================================
|
||||
# EBENE 3: PRIORISIERUNG
|
||||
# =============================================================================
|
||||
|
||||
ebene_3_priorisierung:
|
||||
|
||||
beschreibung: |
|
||||
Die Priorisierung identifiziert innerhalb der Segmente die
|
||||
Key-Stakeholder und leitet den Betreuungsmodus ab. Sie basiert
|
||||
auf drei Dimensionen, die binär (ja/nein) bewertet werden.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# DIMENSIONEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
dimensionen:
|
||||
|
||||
governance_referenz: "GOV-SHM-007"
|
||||
|
||||
bewertungslogik: |
|
||||
Jede Dimension wird binär bewertet (ja/nein). Die Bewertung
|
||||
erfolgt durch den Stakeholder-Manager mit dokumentierter
|
||||
Begründung. Die Begründung macht die Einschätzung
|
||||
nachvollziehbar und überprüfbar.
|
||||
|
||||
dimension_1_einfluss:
|
||||
|
||||
id: "E"
|
||||
name: "Einfluss"
|
||||
leitfrage: "Kann das Amt DIGIT-relevante Entscheidungen beeinflussen?"
|
||||
|
||||
indikatoren:
|
||||
- "Entscheidungsbefugnis über IT-Budgets oder IT-Standards"
|
||||
- "Multiplikator-Rolle durch Größe oder Querschnittsfunktion"
|
||||
- "Politisches Gewicht in Verwaltungsgremien"
|
||||
|
||||
beispiele_ja:
|
||||
- "Haupt- und Personalamt (IT-Standards für alle)"
|
||||
- "Stadtkämmerei (IT-Budget-Allokation)"
|
||||
|
||||
beispiele_nein:
|
||||
- "Standesamt (kein übergreifender Einfluss)"
|
||||
|
||||
dimension_2_abhaengigkeit:
|
||||
|
||||
id: "A"
|
||||
name: "Abhängigkeit"
|
||||
leitfrage: "Steht das Amt ohne IT still?"
|
||||
|
||||
indikatoren:
|
||||
- "Kernprozesse sind IT-abhängig"
|
||||
- "Externe Schnittstellen setzen funktionierende IT voraus"
|
||||
- "IT-Ausfall führt zu unmittelbarem Leistungsausfall"
|
||||
|
||||
beispiele_ja:
|
||||
- "Amt für Bürgerservice (alle Prozesse IT-basiert)"
|
||||
- "Stadtkasse (Zahlungsverkehr)"
|
||||
|
||||
beispiele_nein:
|
||||
- "Kulturamt (kann temporär analog arbeiten)"
|
||||
|
||||
dimension_3_relevanz:
|
||||
|
||||
id: "R"
|
||||
name: "Relevanz"
|
||||
leitfrage: "Ist das Amt gerade besonders wichtig für die Gesamtverwaltung?"
|
||||
|
||||
indikatoren:
|
||||
- "Hohe politische oder öffentliche Sichtbarkeit"
|
||||
- "Beteiligung an strategischen Projekten"
|
||||
- "Aktuelle Krisensituation oder Transformationsphase"
|
||||
|
||||
charakteristik: |
|
||||
Diese Dimension ist dynamisch und kann sich über Zeit ändern.
|
||||
Sie erfordert regelmäßige Überprüfung im Portfolio-Review.
|
||||
|
||||
beispiele_ja:
|
||||
- "Amt für Digitalisierung (strategisches Projekt)"
|
||||
- "Amt für öffentliche Ordnung (bei Großveranstaltungen)"
|
||||
|
||||
beispiele_nein:
|
||||
- "Forstamt (stabile Situation, geringe Sichtbarkeit)"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# GEWICHTUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
gewichtung:
|
||||
|
||||
governance_referenz: "GOV-SHM-008"
|
||||
|
||||
logik: |
|
||||
Einfluss ist besonders gewichtet, da diese Ämter DIGIT direkt
|
||||
beeinflussen können – sei es durch Budget-Entscheidungen,
|
||||
Standard-Setzung oder politisches Gewicht.
|
||||
|
||||
Gewichtung: Einfluss > Abhängigkeit = Relevanz
|
||||
|
||||
begruendung: |
|
||||
Ämter mit Einfluss können Ressourcen, Standards und Entscheidungen
|
||||
von DIGIT beeinflussen. Eine gute Beziehung zu diesen Ämtern ist
|
||||
strategisch wichtiger als zu Ämtern, die "nur" abhängig sind.
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# KOMBINATIONSLOGIK
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
kombinationslogik:
|
||||
|
||||
governance_referenz: "GOV-SHM-009"
|
||||
|
||||
prio_stufen:
|
||||
|
||||
- stufe: "Key"
|
||||
kombination: "Alle drei ODER Einfluss + eine weitere"
|
||||
beschreibung: "Strategisch wichtigste Stakeholder"
|
||||
|
||||
- stufe: "Aktiv"
|
||||
kombination: "Zwei (ohne Einfluss) ODER nur Einfluss"
|
||||
beschreibung: "Wichtige Stakeholder mit regelmäßiger Betreuung"
|
||||
|
||||
- stufe: "Standard"
|
||||
kombination: "Eine (Abhängigkeit oder Relevanz)"
|
||||
beschreibung: "Stakeholder mit punktuellem Betreuungsbedarf"
|
||||
|
||||
- stufe: "Basis"
|
||||
kombination: "Keine Dimension erfüllt"
|
||||
beschreibung: "Stakeholder mit reaktiver Betreuung"
|
||||
|
||||
kombinationstabelle: |
|
||||
|
||||
│ E │ A │ R │ Prio-Stufe │
|
||||
├───┼───┼───┼────────────┤
|
||||
│ ✓ │ ✓ │ ✓ │ Key │
|
||||
│ ✓ │ ✓ │ – │ Key │
|
||||
│ ✓ │ – │ ✓ │ Key │
|
||||
│ – │ ✓ │ ✓ │ Aktiv │
|
||||
│ ✓ │ – │ – │ Aktiv │
|
||||
│ – │ ✓ │ – │ Standard │
|
||||
│ – │ – │ ✓ │ Standard │
|
||||
│ – │ – │ – │ Basis │
|
||||
|
||||
Legende: E = Einfluss, A = Abhängigkeit, R = Relevanz
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# BETREUUNGSMODUS
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
betreuungsmodus:
|
||||
|
||||
governance_referenz: "GOV-SHM-010"
|
||||
|
||||
beschreibung: |
|
||||
Der Betreuungsmodus wird aus der Prio-Stufe abgeleitet und
|
||||
definiert die Art und Intensität der Stakeholder-Betreuung.
|
||||
|
||||
modi:
|
||||
|
||||
- prio_stufe: "Key"
|
||||
modus: "Proaktiv/Dediziert"
|
||||
beschreibung: |
|
||||
Regelmäßige Turnusgespräche (z.B. halbjährlich),
|
||||
dedizierter Stakeholder-Manager,
|
||||
aktive Bedarfserhebung,
|
||||
Einladung zu strategischen Abstimmungen
|
||||
|
||||
- prio_stufe: "Aktiv"
|
||||
modus: "Regelmäßig"
|
||||
beschreibung: |
|
||||
Teilnahme am Cluster-Advisory-Board,
|
||||
anlassbezogene Gespräche,
|
||||
Einladung zu relevanten Themen
|
||||
|
||||
- prio_stufe: "Standard"
|
||||
modus: "Eingebunden"
|
||||
beschreibung: |
|
||||
Teilnahme am Cluster-Advisory-Board,
|
||||
reaktive Betreuung bei Anfragen
|
||||
|
||||
- prio_stufe: "Basis"
|
||||
modus: "Reaktiv"
|
||||
beschreibung: |
|
||||
Keine proaktive Betreuung,
|
||||
nur bei eingehenden Anfragen,
|
||||
Information über allgemeine Kanäle
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# ÜBERPRÜFUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
ueberpruefung:
|
||||
|
||||
governance_referenz: "GOV-SHM-012"
|
||||
|
||||
beschreibung: |
|
||||
Die Priorisierung wird periodisch überprüft, insbesondere
|
||||
die Dimension "Relevanz", die sich über Zeit ändern kann.
|
||||
|
||||
zyklus: |
|
||||
Im Rahmen der Koordinations- und Steuerungsstruktur
|
||||
(shm_koordinations-und-steuerungsstruktur.yaml):
|
||||
- REV-2-Standard (Q1/Q3): Portfolio-Analyse
|
||||
- REV-2-Erweitert (Q2/Q4): Portfolio-Analyse + Verbesserungsplanung
|
||||
|
||||
voc_integration: |
|
||||
Die Portfolio-Überprüfung nutzt VoC-Erkenntnisse (shm_voice-of-customer.yaml)
|
||||
zu Beziehungsqualität, Zufriedenheit und Bedarfsentwicklung, um
|
||||
Priorisierungen und Betreuungsmodi anzupassen.
|
||||
|
||||
stabilität_der_dimensionen:
|
||||
einfluss: "Relativ stabil (Organisationsstruktur)"
|
||||
abhaengigkeit: "Relativ stabil (Prozessstruktur)"
|
||||
relevanz: "Dynamisch (politische Themen, strategische Projekte)"
|
||||
|
||||
# =============================================================================
|
||||
# VERKNÜPFUNG SPM
|
||||
# =============================================================================
|
||||
|
||||
verknuepfung_spm:
|
||||
|
||||
beschreibung: |
|
||||
Das SHM-Stakeholder-Portfolio ist mit dem SPM-Service-Portfolio
|
||||
über harmonisierte Terminologie und Governance-Brücken verknüpft.
|
||||
|
||||
governance_referenz: "GOV-SHM-005"
|
||||
|
||||
terminologie_mapping:
|
||||
|
||||
beschreibung: |
|
||||
Die IT-Anforderungsprofile im SHM korrespondieren mit den
|
||||
Service-Kategorien im SPM. Die Terminologie wurde bewusst
|
||||
harmonisiert.
|
||||
|
||||
mapping:
|
||||
- shm_profil: "Basis"
|
||||
spm_kategorie: "A – Basis-Services"
|
||||
- shm_profil: "Erweitert"
|
||||
spm_kategorie: "B – Erweiterte Services"
|
||||
- shm_profil: "Spezial"
|
||||
spm_kategorie: "C – Spezial-Services"
|
||||
|
||||
governance_bruecke: |
|
||||
Die Verknüpfung ermöglicht eine systematische Governance-Zuordnung:
|
||||
|
||||
SHM: Amt hat Profil "Erweitert"
|
||||
↓
|
||||
SPM: Amt nutzt wahrscheinlich Kategorie-B-Services
|
||||
↓
|
||||
Governance: Amt ist potenziell in Kundenvertretungen für B-Services
|
||||
|
||||
sla_befugnis: |
|
||||
Die SLA-Befugnis im Amts-Steckbrief folgt der gleichen Logik wie
|
||||
im SPM (P-02 SLM): Primär Amtsleitung, alternativ delegierte Person
|
||||
mit dokumentierter Entscheidungsbefugnis.
|
||||
|
||||
Governance-Referenz: GOV-SHM-013
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "1.0"
|
||||
datum: "2025-12-03"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: "Initiale Erstellung basierend auf Phase-1-Konzeptentwicklung"
|
||||
governance_basis: "GOV-SHM-001 bis GOV-SHM-014"
|
||||
|
||||
- version: "1.1"
|
||||
datum: "2025-12-10"
|
||||
autor: "Cross-Check Phase 5"
|
||||
aenderung: |
|
||||
- Überprüfungs-Abschnitt erweitert:
|
||||
- Veraltete Phase-7-Referenz aktualisiert auf
|
||||
shm_koordinations-und-steuerungsstruktur.yaml
|
||||
- VoC-Integration ergänzt (Nutzung von VoC-Erkenntnissen für
|
||||
Portfolio-Überprüfung)
|
||||
- Zyklus präzisiert (E2-Standard und E2-Erweitert)
|
||||
|
||||
- version: "1.2"
|
||||
datum: "2026-01-23"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: |
|
||||
- Dimension 1 (Funktion) erweitert um Primär-/Sekundärfunktionslogik:
|
||||
- Strukturierter Entscheidungsbaum für Primärfunktionsbestimmung
|
||||
- Entscheidungshilfe bei Mehrdeutigkeit
|
||||
- Verfahren zur Sekundärfunktionsbestimmung mit Vergabekriterien
|
||||
- Dokumentation möglicher und ausgeschlossener Kombinationen
|
||||
- Operative Anwendung mit Steuerungsprinzip
|
||||
- Dokumentationspflicht bei Sekundärfunktion
|
||||
governance_referenz: "GOV-SHM-027"
|
||||
|
||||
- version: "1.3"
|
||||
datum: "2026-01-23"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: |
|
||||
Betreuungsstatus-Konzept (GOV-SHM-028):
|
||||
- Neuer Abschnitt 'betreuungsstatus_konzept' eingefügt
|
||||
- Drei Ausprägungen: AKTIV, EINGESCHRÄNKT, RUHEND
|
||||
- Dokumentation der Deckelungslogik für effektiven Betreuungsmodus
|
||||
- Entscheidungsbefugnis bei Leitung SHM
|
||||
- Review im Portfolio-Review (E2-Standard/Erweitert)
|
||||
- Ergänzung im Drei-Ebenen-Modell
|
||||
governance_referenz: "GOV-SHM-028"
|
||||
|
||||
- version: "1.4"
|
||||
datum: "2026-01-26"
|
||||
autor: "DIGITOM-Projekt"
|
||||
aenderung: |
|
||||
IT-Anforderungsprofil präzisiert (dimension_2_it_profil):
|
||||
- Neues Attribut 'typische_services' bei allen drei Profilen ergänzt
|
||||
- BASIS: Standard-Arbeitsplatz, E-Mail/Kalender, zentrale Systeme
|
||||
- ERWEITERT: Mobile Hardware (VPN-Notebook, EC-Cash), Außendienst-
|
||||
Zugriffe, Fachverfahren, DMS/Workflow
|
||||
- SPEZIAL: Exklusive Fachsoftware, Spezialhardware, individuelle
|
||||
Schnittstellen, besondere Homeoffice-Lösungen
|
||||
- Charakteristik ERWEITERT ergänzt um Außendienst-Beschreibung
|
||||
- Charakteristik SPEZIAL ergänzt um Homeoffice-Einschränkung
|
||||
1071
#03_stakeholder-management/#03.3_konzepte/shm_voice-of-customer.yaml
Normal file
1071
#03_stakeholder-management/#03.3_konzepte/shm_voice-of-customer.yaml
Normal file
File diff suppressed because it is too large
Load diff
1179
#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml
Normal file
1179
#03_stakeholder-management/#03.4_methodik/shm_bedarfsbewertung.yaml
Normal file
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,854 @@
|
|||
# =============================================================================
|
||||
# SHM KOORDINATIONS- UND STEUERUNGSSTRUKTUR
|
||||
# =============================================================================
|
||||
# Modul: Stakeholder-Management (SHM)
|
||||
# Typ: Methodik
|
||||
# Version: 1.0
|
||||
# Datum: 2025-12-10
|
||||
# Status: Final (Phase 5)
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
modul_id: "SHM-M-02"
|
||||
name: "Koordinations- und Steuerungsstruktur"
|
||||
typ: "Methodik"
|
||||
|
||||
vorheriger_name: "Performance & Review"
|
||||
|
||||
begruendung_umbenennung: |
|
||||
Der ursprüngliche Name "Performance & Review" war zu stark durch eine
|
||||
betriebswirtschaftliche Steuerungslogik geprägt (Effizienz, Kontrolle,
|
||||
quantifizierte KPIs). Für SHM im Verwaltungskontext ist das nicht passend.
|
||||
|
||||
Der neue Name "Koordinations- und Steuerungsstruktur" betont:
|
||||
- Koordination als zentralen Modus (nicht Kontrolle)
|
||||
- Steuerung als legitimer Verwaltungsbegriff
|
||||
- Struktur statt Framework (weniger technisch)
|
||||
|
||||
Die Integration von REV-3 (Operative Koordination) wird dadurch
|
||||
konzeptionell stimmig.
|
||||
|
||||
zweck: |
|
||||
Die Koordinations- und Steuerungsstruktur definiert, wie SHM seine
|
||||
Arbeit reflektiert, koordiniert und kontinuierlich verbessert. Sie
|
||||
verbindet operative Abstimmung mit taktischer Steuerung und
|
||||
strategischer Rechenschaft.
|
||||
|
||||
itil4_referenz:
|
||||
practice: "Continual Improvement"
|
||||
ergaenzende_konzepte:
|
||||
- konzept: "Voice of Customer"
|
||||
quelle: "ITIL 4 Drive Stakeholder Value (DSV)"
|
||||
- konzept: "Measurement and Reporting"
|
||||
quelle: "ITIL 4 Direct Plan Improve (DPI)"
|
||||
|
||||
governance_referenzen:
|
||||
- id: "GOV-SHM-023"
|
||||
thema: "Fokus auf Ergebnis-Indikatoren"
|
||||
dokument: "readme_shm_governance-entscheidungs-log.yaml"
|
||||
- id: "GOV-SHM-024"
|
||||
thema: "Abgrenzung SHM/SPM im Reporting"
|
||||
dokument: "readme_shm_governance-entscheidungs-log.yaml"
|
||||
|
||||
konzept_referenzen:
|
||||
- dokument: "shm_voice-of-customer.yaml"
|
||||
beschreibung: "VoC als zentraler Steuerungsindikator"
|
||||
- dokument: "shm_engagement-framework.yaml"
|
||||
beschreibung: "Interaktionsformate, die VoC-Quellen liefern"
|
||||
- dokument: "shm_stakeholder-portfolio.yaml"
|
||||
beschreibung: "Beziehungsqualität als Steuerungsindikator"
|
||||
|
||||
# =============================================================================
|
||||
# GRUNDPRINZIPIEN
|
||||
# =============================================================================
|
||||
|
||||
grundprinzipien:
|
||||
|
||||
beschreibung: |
|
||||
Die folgenden Prinzipien leiten die Gestaltung der Koordinations- und
|
||||
Steuerungsstruktur. Sie reflektieren den Charakter von SHM als
|
||||
beziehungsorientierte Funktion im Verwaltungskontext.
|
||||
|
||||
prinzipien:
|
||||
|
||||
- id: "PRIN-01"
|
||||
name: "Qualität vor Effizienz"
|
||||
beschreibung: |
|
||||
Die zentrale Frage ist nicht "Wie viel?" oder "Wie schnell?",
|
||||
sondern "Wie gut?". Die Qualität der Stakeholder-Beziehungen
|
||||
und die Wirksamkeit der Betreuung stehen im Vordergrund.
|
||||
implikation: |
|
||||
Review-Fragen fokussieren auf Beziehungsqualität und
|
||||
Stakeholder-Wahrnehmung, nicht auf Durchsatzzahlen.
|
||||
|
||||
- id: "PRIN-02"
|
||||
name: "Koordination vor Kontrolle"
|
||||
beschreibung: |
|
||||
SHM arbeitet mit Abstimmung, Austausch und gemeinsamer
|
||||
Problemlösung – nicht mit hierarchischer Überwachung.
|
||||
Die Steuerungsstruktur ermöglicht Koordination, nicht Kontrolle.
|
||||
implikation: |
|
||||
REV-3 (Team-Sync) ist ein Koordinationsformat, kein
|
||||
Kontroll-Meeting. Keine Rechenschaftspflicht nach oben.
|
||||
|
||||
- id: "PRIN-03"
|
||||
name: "Lernen vor Messen"
|
||||
beschreibung: |
|
||||
Ziel ist Erkenntnisgewinn und kontinuierliche Verbesserung,
|
||||
nicht das Erfüllen von Kennzahlen. Metriken dienen dem Lernen,
|
||||
nicht der Rechtfertigung.
|
||||
implikation: |
|
||||
Keine KPI-Dashboards mit Zielerreichungsquoten. Stattdessen
|
||||
qualitative Reflexion und Musteranalyse.
|
||||
|
||||
- id: "PRIN-04"
|
||||
name: "Qualitative Einschätzungen vor quantifizierten Kennzahlen"
|
||||
beschreibung: |
|
||||
Beziehungen sind mehrdimensional, kontextabhängig und dynamisch.
|
||||
Ihre Qualität lässt sich nicht sinnvoll auf eine Zahl reduzieren.
|
||||
Quantifizierung suggeriert eine Präzision, die bei Beziehungsarbeit
|
||||
nicht existiert – und erzeugt perverse Anreize: Was gemessen wird,
|
||||
wird optimiert, nicht notwendigerweise verbessert.
|
||||
implikation: |
|
||||
Berichte enthalten narrative Einschätzungen mit Kontext und
|
||||
Ursachenbezug. Zahlen werden nur dort verwendet, wo sie echten
|
||||
Informationsgewinn bieten (z.B. Verteilungen im Portfolio),
|
||||
nicht als Selbstzweck.
|
||||
beispiel:
|
||||
statt: "78% der Turnus-Gespräche durchgeführt"
|
||||
besser: |
|
||||
Turnus-Gespräche finden regelmäßig statt. Bei zwei Key-Stakeholdern
|
||||
kam es zu Verschiebungen wegen Personalwechsel auf Fachbereichsseite.
|
||||
abgrenzung: |
|
||||
Dies ist kein Plädoyer gegen jede Form von Strukturierung. Die
|
||||
Ampel-Matrix (VoC-Cluster) ist eine qualitative Verdichtung mit
|
||||
visuellem Ordnungsschema – keine Quantifizierung.
|
||||
|
||||
- id: "PRIN-05"
|
||||
name: "Stakeholder-Stimme als Kompass"
|
||||
beschreibung: |
|
||||
Die Wahrnehmung und das Feedback der Stakeholder sind der
|
||||
zentrale Gradmesser für den Erfolg von SHM. Das Voice-of-Customer-
|
||||
Konzept wird strukturell verankert.
|
||||
implikation: |
|
||||
VoC-Erkenntnisse sind Kernelement aller Review-Formate.
|
||||
Keine Bewertung ohne Stakeholder-Perspektive.
|
||||
referenz: "shm_voice-of-customer.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# STEUERUNGSINDIKATOREN
|
||||
# =============================================================================
|
||||
|
||||
steuerungsindikatoren:
|
||||
|
||||
beschreibung: |
|
||||
Basierend auf GOV-SHM-023 fokussiert die SHM-Steuerung auf
|
||||
Ergebnis-Indikatoren (Wirkung), nicht auf Prozess-Indikatoren
|
||||
(Aktivitäten).
|
||||
|
||||
primaere_indikatoren:
|
||||
|
||||
beschreibung: |
|
||||
Diese Indikatoren werden in den Reviews (REV-1, REV-2) systematisch
|
||||
betrachtet und berichtet.
|
||||
|
||||
indikatoren:
|
||||
|
||||
- id: "IND-P-01"
|
||||
name: "Beziehungsqualität"
|
||||
quelle: "shm_stakeholder-portfolio.yaml"
|
||||
beschreibung: |
|
||||
Verteilung der Beziehungsqualitäts-Stufen (Exzellent, Gut,
|
||||
Angespannt, Kritisch) im Portfolio.
|
||||
betrachtung: "Verteilung und Veränderung"
|
||||
|
||||
- id: "IND-P-02"
|
||||
name: "VoC-Cluster-Ampeln"
|
||||
quelle: "shm_voice-of-customer.yaml"
|
||||
beschreibung: |
|
||||
Kritikalitätsbewertung der thematischen Cluster (D1-D4)
|
||||
in der Ampel-Matrix.
|
||||
betrachtung: "Status und Trend"
|
||||
|
||||
- id: "IND-P-03"
|
||||
name: "VoC-Highlights"
|
||||
quelle: "shm_voice-of-customer.yaml"
|
||||
beschreibung: |
|
||||
Qualitative Erkenntnisse aus dem Stakeholder-Feedback
|
||||
(positiv, kritisch, insight, trend).
|
||||
betrachtung: "Narrative Auswertung"
|
||||
|
||||
sekundaere_indikatoren:
|
||||
|
||||
beschreibung: |
|
||||
Diese Indikatoren werden nicht im Review berichtet, können aber
|
||||
bei operativen Problemen intern herangezogen werden.
|
||||
|
||||
indikatoren:
|
||||
|
||||
- id: "IND-S-01"
|
||||
name: "Turnus-Gespräche Durchführungsquote"
|
||||
verwendung: "Nur bei Verdacht auf systematische Lücken"
|
||||
|
||||
- id: "IND-S-02"
|
||||
name: "Routing-Statistik"
|
||||
verwendung: "Nur bei Analyse von Bedarfsmustern"
|
||||
|
||||
- id: "IND-S-03"
|
||||
name: "Durchlaufzeiten Bedarfssteckbrief"
|
||||
verwendung: "Nur bei Engpass-Analyse"
|
||||
|
||||
# =============================================================================
|
||||
# ENTSCHEIDUNGSTYPEN
|
||||
# =============================================================================
|
||||
|
||||
entscheidungstypen:
|
||||
|
||||
beschreibung: |
|
||||
Die Koordinations- und Steuerungsstruktur unterstützt drei
|
||||
Entscheidungstypen auf unterschiedlichen Ebenen. Diese bilden
|
||||
das funktionale Fundament der Struktur.
|
||||
|
||||
Hinweis: Die ursprünglich separaten Typen (Portfolio-Qualität
|
||||
und Funktions-Weiterentwicklung) wurden zu einem konsolidierten
|
||||
REV-2-Format zusammengeführt (analog DPM-Portfolio-Review).
|
||||
|
||||
uebersicht:
|
||||
|
||||
- id: "REV-1"
|
||||
name: "Auftragserfüllung"
|
||||
ebene: "Strategisch"
|
||||
frequenz: "Jährlich + Halbjahres-Pulse"
|
||||
adressat: "Vision Board"
|
||||
|
||||
- id: "REV-2"
|
||||
name: "Portfolio-Qualität, Lernen & Verbesserung"
|
||||
ebene: "Taktisch"
|
||||
frequenz: "Quartalsweise"
|
||||
adressat: "SHM-Leitung, SHM-Team"
|
||||
|
||||
- id: "REV-3"
|
||||
name: "Operative Koordination"
|
||||
ebene: "Operativ"
|
||||
frequenz: "2-wöchentlich bis monatlich"
|
||||
adressat: "SHM-Leitung, SHM-Team"
|
||||
|
||||
typen:
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# REV-1: AUFTRAGSERFÜLLUNG
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "REV-1"
|
||||
name: "Auftragserfüllung"
|
||||
|
||||
kernfrage: "Leistet SHM, wofür es da ist?"
|
||||
|
||||
beschreibung: |
|
||||
Strategische Bewertung, ob die Funktion SHM ihren Zweck im
|
||||
DIGITOM-Gesamtkontext erfüllt. Die Stakeholder-Stimme (Voice
|
||||
of Customer) ist hier ein zentraler Input.
|
||||
|
||||
adressat: "DIGIT-Leitung, Vision Board"
|
||||
|
||||
charakter: "Strategisch-legitimatorisch"
|
||||
|
||||
frequenz: "Jährlich"
|
||||
|
||||
zusaetzlich:
|
||||
name: "Pulse-Update"
|
||||
frequenz: "Halbjährlich (Q2)"
|
||||
umfang: "Kurzform (max. 2 Seiten)"
|
||||
zweck: "Standortbestimmung zwischen Jahresberichten"
|
||||
|
||||
betrachtungsweise: |
|
||||
Qualitative Gesamteinschätzung mit narrativer Begründung.
|
||||
Keine Scorecard, sondern strukturierter Bericht mit
|
||||
Einordnung und Handlungsempfehlungen.
|
||||
|
||||
typische_fragestellungen:
|
||||
- "Werden die Stakeholder-Beziehungen professionell gepflegt?"
|
||||
- "Funktioniert die Bedarfserkennung und -weiterleitung?"
|
||||
- "Wie nehmen die Ämter DIGIT als Partner wahr?"
|
||||
- "Trägt SHM zur strategischen Ausrichtung von DIGIT bei?"
|
||||
|
||||
voc_relevanz: |
|
||||
REV-1 integriert die aggregierte Stakeholder-Stimme als
|
||||
zentralen Erfolgsindikator. Die Frage "Erfüllen wir unseren
|
||||
Auftrag?" wird wesentlich durch "Was sagen die Stakeholder?"
|
||||
beantwortet.
|
||||
|
||||
voc_output: "Verdichtung REV-1 (Jahres-Review)"
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# REV-2: PORTFOLIO-QUALITÄT, LERNEN & VERBESSERUNG
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "REV-2"
|
||||
name: "Portfolio-Qualität, Lernen & Verbesserung"
|
||||
|
||||
kernfrage: |
|
||||
Wie steht es um unsere Stakeholder-Beziehungen, was lernen wir
|
||||
daraus, und was müssen wir verbessern?
|
||||
|
||||
beschreibung: |
|
||||
Kombiniertes Format für Portfolio-Analyse und kontinuierliche
|
||||
Verbesserung. Quartalsweise Betrachtung des Stakeholder-Portfolios
|
||||
mit integrierter CI-Komponente. In Q2 und Q4 erweitertes Format
|
||||
mit Retrospektive und Verbesserungsplanung.
|
||||
|
||||
Diese Konsolidierung folgt dem bewährten Ansatz des DPM-Portfolio-
|
||||
Reviews, das Portfolio-Analyse und Prozessverbesserung ebenfalls
|
||||
in einem Format verbindet.
|
||||
|
||||
adressat: "SHM-Leitung, SHM-Team"
|
||||
|
||||
charakter: "Taktisch-reflexiv"
|
||||
|
||||
frequenz: "Quartalsweise"
|
||||
|
||||
varianten:
|
||||
|
||||
- variante: "Standard (Q1, Q3)"
|
||||
dauer: "60-90 Minuten"
|
||||
fokus: "Portfolio-Analyse, VoC-Status, Maßnahmen-Tracking"
|
||||
ci_anteil: "Kurz (15 Min): Status offener Maßnahmen, neue Themen sammeln"
|
||||
|
||||
- variante: "Erweitert (Q2, Q4)"
|
||||
dauer: "2-3 Stunden"
|
||||
fokus: "Portfolio-Analyse + Retrospektive + Verbesserungsplanung"
|
||||
ci_anteil: "Deep-Dive: Was lief gut/schlecht? Strukturelle Verbesserungen"
|
||||
zusatz_q4: "Vorbereitung REV-1-Jahresbericht"
|
||||
|
||||
inhaltliche_dimensionen:
|
||||
|
||||
portfolio_analyse:
|
||||
- dimension: "Beziehungsqualitäts-Verteilung"
|
||||
beschreibung: "Verteilung EX/GU/AN/KR im Portfolio"
|
||||
- dimension: "VoC-Cluster-Status"
|
||||
beschreibung: "Ampel-Matrix D1-D4"
|
||||
- dimension: "Veränderungen"
|
||||
beschreibung: "Entwicklung gegenüber Vorquartal"
|
||||
- dimension: "Highlights"
|
||||
beschreibung: "Relevante Einzelerkenntnisse"
|
||||
- dimension: "Interventionen"
|
||||
beschreibung: "Laufende und neue Interventionsfälle"
|
||||
|
||||
ci_komponente:
|
||||
- dimension: "Maßnahmen-Status"
|
||||
beschreibung: "Review offener Verbesserungsmaßnahmen"
|
||||
- dimension: "Wirksamkeit"
|
||||
beschreibung: "Wurden umgesetzte Maßnahmen wirksam?"
|
||||
- dimension: "Neue Themen"
|
||||
beschreibung: "Erkannte Verbesserungspotenziale"
|
||||
- dimension: "Retrospektive (nur Q2/Q4)"
|
||||
beschreibung: "Was lief gut? Was war schwierig?"
|
||||
- dimension: "Schnittstellen-Feedback (nur Q2/Q4)"
|
||||
beschreibung: "Rückmeldungen von DPM, SPM, Service Desk"
|
||||
|
||||
output:
|
||||
- "SHM-Quartalsbericht (inkl. Maßnahmen-Status)"
|
||||
- "Bei Q2/Q4: Aktualisierter Verbesserungsplan"
|
||||
- "Input für DPM-Portfolio-Review"
|
||||
- "Bei Q4: Vorarbeit für REV-1-Jahresbericht"
|
||||
|
||||
voc_relevanz: |
|
||||
VoC informiert sowohl die Portfolio-Betrachtung als auch die
|
||||
Verbesserungsplanung:
|
||||
- Portfolio: Welche Beziehungen sind belastet? Welche Muster?
|
||||
- CI: Systematische Muster, die auf Prozessprobleme hindeuten
|
||||
|
||||
voc_output: "Verdichtung REV-2 (Quartals-Review)"
|
||||
|
||||
konsolidierungshinweis: |
|
||||
Dieses Format ersetzt die ursprünglich separaten Entscheidungstypen
|
||||
(vormals E2 für Portfolio-Qualität & Lernen und E4 für Funktions-Weiterentwicklung).
|
||||
Die Zusammenlegung reduziert Overhead und ist konsistent mit dem
|
||||
DPM-Portfolio-Review-Ansatz.
|
||||
|
||||
# -------------------------------------------------------------------------
|
||||
# REV-3: OPERATIVE KOORDINATION
|
||||
# -------------------------------------------------------------------------
|
||||
|
||||
- id: "REV-3"
|
||||
name: "Operative Koordination"
|
||||
|
||||
kernfrage: "Welche laufenden Themen müssen wir im Team abstimmen?"
|
||||
|
||||
beschreibung: |
|
||||
Regelmäßiger Austausch im SHM-Team zu laufenden Stakeholder-
|
||||
Themen. Fokus auf kollegiale Beratung, Wissenstransfer und
|
||||
gemeinsame Problemlösung.
|
||||
|
||||
adressat: "SHM-Team (Stakeholder-Manager untereinander)"
|
||||
|
||||
charakter: "Operativ-koordinierend"
|
||||
|
||||
frequenz: "2-wöchentlich oder monatlich"
|
||||
|
||||
betrachtungsweise: |
|
||||
Fall-basiert und anlassbezogen. Kein formaler Review,
|
||||
sondern Arbeits-Meeting mit Koordinationsfunktion.
|
||||
|
||||
typische_inhalte:
|
||||
- "Aktuelle Interventionsfälle (Angespannt/Kritisch)"
|
||||
- "Komplexe Bedarfssituationen"
|
||||
- "Übergaben bei Zuständigkeitswechsel"
|
||||
- "Erkenntnisse aus Gesprächen, die für andere relevant sind"
|
||||
- "Status-Updates zu laufenden Demands/Projekten bei Key-Stakeholdern"
|
||||
|
||||
abgrenzung: |
|
||||
REV-3 ist kein Review im klassischen Sinne, sondern ein
|
||||
Koordinationsmechanismus. Die Integration in die Steuerungs-
|
||||
struktur stellt sicher, dass operative Erkenntnisse in die
|
||||
taktische (REV-2) und strategische (REV-1) Ebene einfließen.
|
||||
|
||||
format:
|
||||
name: "SHM Team-Sync"
|
||||
dauer: "45-60 Minuten"
|
||||
moderation: "Rotierend oder SHM-Leitung"
|
||||
dokumentation: "Kurzprotokoll mit Entscheidungen und Follow-ups"
|
||||
|
||||
voc_relevanz: |
|
||||
Aktuelle Highlights (insbesondere Kritik-Highlights) fließen
|
||||
in die Team-Koordination ein. Interventionsfälle werden auf
|
||||
Basis von VoC-Signalen identifiziert.
|
||||
|
||||
voc_output: "Highlights (laufend)"
|
||||
|
||||
# =============================================================================
|
||||
# EINBETTUNG IN DIGIT-ZYKLEN
|
||||
# =============================================================================
|
||||
|
||||
einbettung_digit_zyklen:
|
||||
|
||||
beschreibung: |
|
||||
Die SHM-Reviews sind nicht isoliert, sondern in die übergreifenden
|
||||
DIGIT-Governance-Zyklen eingebettet.
|
||||
|
||||
ebenen:
|
||||
|
||||
strategische_ebene:
|
||||
gremium: "Vision Board"
|
||||
rhythmus: "Quartalsweise"
|
||||
funktion: "Definiert Strategie und jährliche strategische Fokusthemen"
|
||||
shm_einbettung: |
|
||||
REV-1 (Auftragserfüllung) wird im Vision Board verankert:
|
||||
- Jährlich: Vollständiger SHM-Jahresbericht als Input für Strategieplanung
|
||||
- Halbjährlich: Pulse-Update (Kurzform) zur Standortbestimmung
|
||||
|
||||
taktische_ebene:
|
||||
gremium: "SHM-Leitung / SOR bei Bedarf"
|
||||
rhythmus: "Quartalsweise (REV-2)"
|
||||
shm_einbettung: |
|
||||
REV-2 (Portfolio-Qualität, Lernen & Verbesserung) liegt auf der
|
||||
taktischen Ebene und wird durch SHM-Leitung verantwortet.
|
||||
|
||||
operative_ebene:
|
||||
gremium: "SHM-Team"
|
||||
rhythmus: "2-wöchentlich bis monatlich (REV-3)"
|
||||
shm_einbettung: |
|
||||
REV-3 (Operative Koordination) ist ein internes Team-Format.
|
||||
|
||||
# =============================================================================
|
||||
# EINBETTUNG IN ÜBERGREIFENDE DIGIT-REVIEWS
|
||||
# =============================================================================
|
||||
|
||||
einbettung_digit_reviews:
|
||||
|
||||
beschreibung: |
|
||||
SHM ist Teilnehmer an übergreifenden DIGIT-Review-Formaten und
|
||||
liefert dort Input aus seiner Perspektive.
|
||||
|
||||
dpm_portfolio_review:
|
||||
|
||||
name: "Demand-Portfolio Review"
|
||||
charakter: "DIGIT-übergreifendes Quartals-Review"
|
||||
frequenz: "Quartalsweise"
|
||||
zeitpunkt: "Erste Monatshälfte nach Quartalsende (ca. T+10 bis T+14)"
|
||||
teilnehmer: "AL Planung (Leitung), DPM, PPM, SPM, SHM"
|
||||
|
||||
shm_rolle: |
|
||||
SHM ist Teilnehmer und Input-Lieferant. Der SHM-Beitrag umfasst:
|
||||
- Stakeholder-Trends (VoC-Cluster-Entwicklung)
|
||||
- Bedarfsmuster (Erkenntnisse aus D3, Routing-Erfahrungen)
|
||||
- Kommunikations-Feedback (Highlights, Beziehungsqualität)
|
||||
|
||||
shm_input_quelle: "REV-2 (SHM Quartals-Review)"
|
||||
|
||||
sequenzierung: |
|
||||
REV-2 muss vor dem DPM-Portfolio-Review stattfinden, damit SHM
|
||||
vorbereitet ist und konsolidierten Input liefern kann.
|
||||
|
||||
Empfohlene Sequenz:
|
||||
- REV-2: Erste Woche nach Quartalsende
|
||||
- DPM-Portfolio-Review: Zweite Woche nach Quartalsende
|
||||
|
||||
referenz_dokument: "Konzept_DPM – Demand-Portfolio Review Framework"
|
||||
|
||||
# =============================================================================
|
||||
# KASKADIERUNGSLOGIK
|
||||
# =============================================================================
|
||||
|
||||
kaskadierungslogik:
|
||||
|
||||
beschreibung: |
|
||||
Informationen und Erkenntnisse fließen zwischen den Ebenen in
|
||||
beide Richtungen.
|
||||
|
||||
aufwaertsfluss:
|
||||
|
||||
- von: "REV-3 (Team-Sync)"
|
||||
nach: "REV-2 (Quartals-Review)"
|
||||
inhalt:
|
||||
- "Interventionsfälle, die eskaliert oder dokumentiert werden müssen"
|
||||
- "Erkenntnisse aus Einzelgesprächen"
|
||||
- "Muster, die im Tagesgeschäft auffallen"
|
||||
|
||||
- von: "REV-2 (Quartals-Review)"
|
||||
nach: "REV-1 (Jahres-Review)"
|
||||
inhalt:
|
||||
- "Quartals-Status und Trends"
|
||||
- "Konsolidierte VoC-Erkenntnisse"
|
||||
- "Handlungsbedarfe mit strategischer Relevanz"
|
||||
|
||||
- von: "REV-2 (Quartals-Review)"
|
||||
nach: "REV-2 erweitert (Q2/Q4)"
|
||||
inhalt:
|
||||
- "Muster, die auf strukturelle Probleme hindeuten"
|
||||
- "Wiederkehrende Themen aus mehreren Quartalen"
|
||||
|
||||
abwaertsfluss:
|
||||
|
||||
- von: "REV-1 / Vision Board"
|
||||
nach: "REV-2 / REV-3"
|
||||
inhalt:
|
||||
- "Strategische Prioritäten"
|
||||
- "Fokusthemen für die Stakeholder-Betreuung"
|
||||
- "Ressourcenentscheidungen"
|
||||
|
||||
- von: "REV-2 erweitert (Q2/Q4)"
|
||||
nach: "REV-3 (Team-Sync)"
|
||||
inhalt:
|
||||
- "Angepasste Prozesse oder Vorgehensweisen"
|
||||
- "Maßnahmen aus Verbesserungsplanung"
|
||||
- "Veränderte Prioritäten"
|
||||
|
||||
# =============================================================================
|
||||
# REVIEW-FORMATE IM DETAIL
|
||||
# =============================================================================
|
||||
|
||||
review_formate:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# REV-1: JAHRES-REVIEW
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
rev1_jahres_review:
|
||||
|
||||
name: "SHM Jahres-Review"
|
||||
entscheidungstyp_referenz: "REV-1"
|
||||
zweck: "Strategische Bewertung der SHM-Funktion"
|
||||
frequenz: "Jährlich"
|
||||
zeitpunkt: "Q4 (vor Vision-Board-Strategieplanung)"
|
||||
|
||||
zusaetzlich_pulse_update:
|
||||
frequenz: "Halbjährlich"
|
||||
zeitpunkt: "Q2"
|
||||
umfang: "Kurzform (max. 2 Seiten)"
|
||||
|
||||
verantwortlichkeiten:
|
||||
erstellt: "SHM-Leitung"
|
||||
empfaengt: "Vision Board"
|
||||
|
||||
artefakt:
|
||||
name: "SHM-Jahresbericht"
|
||||
umfang: "Ca. 5-10 Seiten"
|
||||
gliederung:
|
||||
- abschnitt: "1. Management Summary"
|
||||
inhalt: "Kernaussagen, Gesamtbewertung"
|
||||
- abschnitt: "2. Stakeholder-Portfolio im Überblick"
|
||||
inhalt: "Bestandsübersicht, Beziehungsqualitäts-Verteilung"
|
||||
- abschnitt: "3. Voice of Customer – Gesamtbild"
|
||||
inhalt: "VoC-Cluster-Jahresübersicht, zentrale Erkenntnisse"
|
||||
- abschnitt: "4. Highlights des Jahres"
|
||||
inhalt: "Erfolge, Herausforderungen, besondere Fälle"
|
||||
- abschnitt: "5. Strategische Erkenntnisse"
|
||||
inhalt: "Implikationen für DIGIT-Strategie, Handlungsempfehlungen"
|
||||
- abschnitt: "6. Ausblick und Empfehlungen"
|
||||
inhalt: "Fokusthemen, Ressourcenbedarf, Risiken"
|
||||
|
||||
template_bedarf:
|
||||
id: "TPL-KSS-01"
|
||||
name: "Vorlage SHM-Jahresbericht"
|
||||
status: "Zu entwickeln in Phase 10"
|
||||
prioritaet: "Hoch"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# REV-2: QUARTALS-REVIEW
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
rev2_quartals_review:
|
||||
|
||||
name: "SHM Quartals-Review"
|
||||
entscheidungstyp_referenz: "REV-2"
|
||||
zweck: "Portfolio-Analyse + Kontinuierliche Verbesserung"
|
||||
frequenz: "Quartalsweise"
|
||||
zeitpunkt: "Erste Woche nach Quartalsende (vor DPM-Portfolio-Review)"
|
||||
|
||||
varianten:
|
||||
|
||||
standard_q1_q3:
|
||||
|
||||
name: "Standard-Review"
|
||||
anwendung: "Q1, Q3"
|
||||
dauer: "60-90 Minuten"
|
||||
teilnehmer: "SHM-Leitung + Stakeholder-Manager"
|
||||
|
||||
artefakt:
|
||||
name: "SHM-Quartalsbericht"
|
||||
umfang: "Ca. 2-4 Seiten"
|
||||
gliederung:
|
||||
- "1. VoC-Cluster-Status (Ampel-Matrix)"
|
||||
- "2. Veränderungen ggü. Vorquartal"
|
||||
- "3. Highlights"
|
||||
- "4. Interventionen"
|
||||
- "5. Maßnahmen-Status"
|
||||
- "6. Handlungsbedarf"
|
||||
|
||||
erweitert_q2_q4:
|
||||
|
||||
name: "Erweiterter Review"
|
||||
anwendung: "Q2, Q4"
|
||||
dauer: "2-3 Stunden"
|
||||
teilnehmer: "SHM-Leitung + Stakeholder-Manager"
|
||||
charakter: "Workshop mit Retrospektive"
|
||||
|
||||
artefakt:
|
||||
name: "SHM-Quartalsbericht erweitert"
|
||||
umfang: "Ca. 4-6 Seiten"
|
||||
zusaetzliche_abschnitte:
|
||||
- "7. Retrospektive (Was lief gut/schlecht?)"
|
||||
- "8. Schnittstellen-Feedback"
|
||||
- "9. Verbesserungsplan (aktualisiert)"
|
||||
- "10. Bei Q4: Vorarbeit REV-1"
|
||||
|
||||
template_bedarf:
|
||||
id: "TPL-KSS-02"
|
||||
name: "Vorlage SHM-Quartalsbericht"
|
||||
status: "Zu entwickeln in Phase 10"
|
||||
prioritaet: "Hoch"
|
||||
anforderungen:
|
||||
- "Modulare Struktur (Standard + Erweiterungs-Abschnitte)"
|
||||
- "VoC-Cluster-Matrix als visuelles Kernelement"
|
||||
- "Integrierter Maßnahmen-Tracker"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# REV-3: TEAM-SYNC
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
rev3_team_sync:
|
||||
|
||||
name: "SHM Team-Sync"
|
||||
entscheidungstyp_referenz: "REV-3"
|
||||
zweck: "Operative Koordination im Team"
|
||||
frequenz: "2-wöchentlich oder monatlich"
|
||||
dauer: "45-60 Minuten"
|
||||
|
||||
verantwortlichkeiten:
|
||||
moderation: "Rotierend oder SHM-Leitung"
|
||||
teilnehmer: "Alle Stakeholder-Manager"
|
||||
|
||||
typische_agenda:
|
||||
- punkt: "Check-in"
|
||||
dauer: "5 Min"
|
||||
beschreibung: "Kurze Runde: Wie geht's?"
|
||||
- punkt: "Interventionsfälle"
|
||||
dauer: "15-20 Min"
|
||||
beschreibung: "Akute Situationen, kollegiale Beratung"
|
||||
- punkt: "Komplexe Bedarfssituationen"
|
||||
dauer: "15-20 Min"
|
||||
beschreibung: "Routing-Fragen, Abstimmungsbedarf"
|
||||
- punkt: "Wissenstransfer"
|
||||
dauer: "10 Min"
|
||||
beschreibung: "Erkenntnisse teilen, Best Practices"
|
||||
- punkt: "Kurz-Updates"
|
||||
dauer: "5 Min"
|
||||
beschreibung: "Termine, Ankündigungen"
|
||||
|
||||
artefakt:
|
||||
name: "Team-Sync-Protokoll"
|
||||
umfang: "Max. 1 Seite"
|
||||
inhalt:
|
||||
- "Datum, Teilnehmer"
|
||||
- "Besprochene Fälle (Stichworte)"
|
||||
- "Entscheidungen / Verabredungen"
|
||||
- "Follow-ups mit Verantwortung"
|
||||
|
||||
template_bedarf:
|
||||
id: "TPL-KSS-03"
|
||||
name: "Vorlage Team-Sync-Protokoll"
|
||||
status: "Zu entwickeln in Phase 10"
|
||||
prioritaet: "Mittel"
|
||||
|
||||
# =============================================================================
|
||||
# TEMPLATE-ÜBERSICHT
|
||||
# =============================================================================
|
||||
|
||||
template_uebersicht:
|
||||
|
||||
beschreibung: |
|
||||
Die folgenden Templates werden für die Review-Struktur benötigt.
|
||||
Entwicklung erfolgt in Phase 10 (Arbeitsmaterialien).
|
||||
|
||||
templates:
|
||||
|
||||
- id: "TPL-KSS-01"
|
||||
name: "Vorlage SHM-Jahresbericht"
|
||||
fuer_format: "REV-1"
|
||||
prioritaet: "Hoch"
|
||||
ziel_ordner: "#03.7_arbeitsmaterialien/"
|
||||
|
||||
- id: "TPL-KSS-02"
|
||||
name: "Vorlage SHM-Quartalsbericht"
|
||||
fuer_format: "REV-2"
|
||||
prioritaet: "Hoch"
|
||||
hinweis: "Modulare Struktur für Standard + Erweitert"
|
||||
ziel_ordner: "#03.7_arbeitsmaterialien/"
|
||||
|
||||
- id: "TPL-KSS-03"
|
||||
name: "Vorlage Team-Sync-Protokoll"
|
||||
fuer_format: "REV-3"
|
||||
prioritaet: "Mittel"
|
||||
ziel_ordner: "#03.7_arbeitsmaterialien/"
|
||||
|
||||
# =============================================================================
|
||||
# JAHRESKALENDER
|
||||
# =============================================================================
|
||||
|
||||
jahreskalender:
|
||||
|
||||
beschreibung: |
|
||||
Übersicht der Review-Formate im Jahresverlauf.
|
||||
|
||||
quartale:
|
||||
|
||||
quartal_1:
|
||||
zeitraum: "Januar - März"
|
||||
formate:
|
||||
- "REV-2 Standard (Q4 Vorjahr auswerten)"
|
||||
- "REV-3 Team-Sync (laufend)"
|
||||
besonderheit: "Erster Review nach Jahreswechsel"
|
||||
|
||||
quartal_2:
|
||||
zeitraum: "April - Juni"
|
||||
formate:
|
||||
- "REV-2 Erweitert (Q1 + Retrospektive)"
|
||||
- "REV-1 Pulse-Update"
|
||||
- "REV-3 Team-Sync (laufend)"
|
||||
besonderheit: "Halbjahres-Standortbestimmung"
|
||||
|
||||
quartal_3:
|
||||
zeitraum: "Juli - September"
|
||||
formate:
|
||||
- "REV-2 Standard (Q2 auswerten)"
|
||||
- "REV-3 Team-Sync (laufend)"
|
||||
besonderheit: "-"
|
||||
|
||||
quartal_4:
|
||||
zeitraum: "Oktober - Dezember"
|
||||
formate:
|
||||
- "REV-2 Erweitert (Q3 + Retrospektive + REV-1-Vorbereitung)"
|
||||
- "REV-1 Jahres-Review"
|
||||
- "REV-3 Team-Sync (laufend)"
|
||||
besonderheit: "Jahresabschluss, Vorbereitung Strategieplanung"
|
||||
|
||||
visualisierung: |
|
||||
|
||||
┌─────────┬──────────────────────────────────────────────────────────┐
|
||||
│ Quartal │ Formate │
|
||||
├─────────┼──────────────────────────────────────────────────────────┤
|
||||
│ Q1 │ REV-2 Standard ──── REV-3 laufend ───────────────── │
|
||||
│ │ │
|
||||
│ Q2 │ REV-2 Erweitert ─ REV-1 Pulse ─ REV-3 laufend ───── │
|
||||
│ │ │
|
||||
│ Q3 │ REV-2 Standard ──── REV-3 laufend ───────────────── │
|
||||
│ │ │
|
||||
│ Q4 │ REV-2 Erweitert ─ REV-1 Jahres ─ REV-3 laufend ───── │
|
||||
└─────────┴──────────────────────────────────────────────────────────┘
|
||||
|
||||
# =============================================================================
|
||||
# ABGRENZUNG SHM / SPM IM REPORTING
|
||||
# =============================================================================
|
||||
|
||||
abgrenzung_spm:
|
||||
|
||||
beschreibung: |
|
||||
Basierend auf GOV-SHM-024 erfolgt eine klare Verantwortungstrennung
|
||||
zwischen SHM- und SPM-Reporting.
|
||||
|
||||
referenz: "readme_shm_governance-entscheidungs-log.yaml (GOV-SHM-024)"
|
||||
|
||||
shm_verantwortet:
|
||||
- dimension: "D1 – Beziehungsqualität"
|
||||
frage: "Wie läuft die Zusammenarbeit?"
|
||||
- dimension: "D3 – Bedarfserfüllung"
|
||||
frage: "Werden Anforderungen erkannt und bearbeitet?"
|
||||
- dimension: "D4 – Strategische Passung"
|
||||
frage: "Passt DIGIT zur Amtsstrategie?"
|
||||
- perspektive: "Portfolio-Perspektive"
|
||||
beschreibung: "Aggregierte Stakeholder-Sicht"
|
||||
|
||||
spm_verantwortet:
|
||||
- dimension: "D2 – Service-Qualität"
|
||||
frage: "Wie gut sind die Services?"
|
||||
- metrik: "SLA-Erfüllung"
|
||||
frage: "Werden vereinbarte Levels eingehalten?"
|
||||
- perspektive: "Service-Perspektive"
|
||||
beschreibung: "Einzelne Service-Performance"
|
||||
|
||||
gemeinsame_verantwortung:
|
||||
- format: "Auftraggeber-Forum"
|
||||
beschreibung: "Integriertes Format mit SHM- und SPM-Themen"
|
||||
- thema: "Eskalationen"
|
||||
beschreibung: "Wenn beide Bereiche betroffen sind"
|
||||
|
||||
schnittstellenregelung:
|
||||
|
||||
- schnittstelle: "VoC-Feedback zu D2"
|
||||
von: "SHM"
|
||||
an: "SPM / Service Owner"
|
||||
mechanismus: |
|
||||
SHM leitet D2-Feedback (Service-Qualität) an den zuständigen
|
||||
Service Owner weiter. Format: Kurz-Info mit Quelle und Kontext.
|
||||
|
||||
- schnittstelle: "Service-Performance-Daten"
|
||||
von: "SPM"
|
||||
an: "SHM"
|
||||
mechanismus: |
|
||||
SHM erhält Zugriff auf Service-Performance-Daten als Kontext
|
||||
für Stakeholder-Gespräche. Kein formaler Report, sondern
|
||||
Leserecht auf SLM-Dashboards/Berichte.
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-12-10"
|
||||
autor: "Konzept-Sprint Phase 5"
|
||||
aenderung: |
|
||||
Initiale Erstellung basierend auf Working Document:
|
||||
- Modulname festgelegt (Koordinations- und Steuerungsstruktur)
|
||||
- Grundprinzipien definiert (PRIN-01 bis PRIN-05)
|
||||
- Steuerungsindikatoren spezifiziert (primär/sekundär)
|
||||
- Entscheidungstypen REV-1, REV-2, REV-3 modelliert
|
||||
- Ursprüngliche E2 und E4 zu konsolidiertem REV-2-Format zusammengeführt
|
||||
- Review-Struktur vollständig dokumentiert
|
||||
- Einbettung in DIGIT-Zyklen und DPM-Portfolio-Review ergänzt
|
||||
- Kaskadierungslogik definiert
|
||||
- Template-Übersicht für Phase 10 erstellt
|
||||
- Jahreskalender hinzugefügt
|
||||
- Abgrenzung SHM/SPM dokumentiert
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
# =============================================================================
|
||||
# SHM VOICE-OF-CUSTOMER (VoC) KONZEPT
|
||||
# =============================================================================
|
||||
#
|
||||
# Voice-of-Customer Methodik im Stakeholder-Management.
|
||||
# Status: Placeholder mit SPM-Schnittstelle
|
||||
# =============================================================================
|
||||
|
||||
metadata:
|
||||
name: "Voice-of-Customer (VoC) Konzept"
|
||||
version: "0.1"
|
||||
status: "placeholder"
|
||||
erstellt: "2025-12-17"
|
||||
projekt: "DIGITOM"
|
||||
organisation: "Stadt Freiburg / DIGIT"
|
||||
|
||||
beschreibung: >
|
||||
Voice-of-Customer Methodik zur systematischen Erfassung und
|
||||
Aufbereitung von Kundenrueckmeldungen. Dieses Dokument ist ein
|
||||
Placeholder und enthaelt vorerst nur die SPM-Schnittstelle.
|
||||
|
||||
referenzen:
|
||||
service_review_konzept: "02_service-portfolio-management/02.1_spm_konzepte/02a_lifecycle-konzepte/spm_konzept_service-review.yaml"
|
||||
governance_entscheidungen: "GOV-SR-001"
|
||||
|
||||
# =============================================================================
|
||||
# SCHNITTSTELLE ZU SPM SERVICE-REVIEW
|
||||
# =============================================================================
|
||||
|
||||
spm_schnittstelle:
|
||||
|
||||
beschreibung: |
|
||||
Der VoC-Cluster D2 (Service-Qualitaet) liefert Input fuer die
|
||||
Service-Review-Dimension "Nutzerzufriedenheit" (SR-D3).
|
||||
|
||||
referenz: "spm_konzept_service-review.yaml -> bewertungsschema.dimensionen.SR-D3"
|
||||
governance_referenz: "GOV-SR-001"
|
||||
|
||||
nutzung_im_service_review:
|
||||
input_fuer_dimension: "SR-D3 Nutzerzufriedenheit"
|
||||
datenquelle: "VoC-Erkenntnisse aus SHM E2-Reports (Cluster D2)"
|
||||
verantwortlich: "SO bezieht SHM-Erkenntnisse in Review ein"
|
||||
|
||||
indikatoren_aus_shm:
|
||||
- "Support-Feedback (Zufriedenheit nach Ticket-Abschluss)"
|
||||
- "Beschwerden und Eskalationen"
|
||||
- "VoC-Signale aus Stakeholder-Gespraechen"
|
||||
- "Informelle Rueckmeldungen via SM"
|
||||
|
||||
synchronisation:
|
||||
beschreibung: |
|
||||
SHM E2-Review liefert VoC-Erkenntnisse als Input fuer den
|
||||
quartalsweisen Service-Review.
|
||||
sequenz: "SHM E2-Review -> VoC-Erkenntnisse -> Service-Review nutzt D2-Cluster"
|
||||
|
||||
# =============================================================================
|
||||
# AENDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
- version: "0.1"
|
||||
datum: "2025-12-17"
|
||||
aenderung: |
|
||||
- Placeholder erstellt mit SPM-Schnittstelle fuer Service-Review (GOV-SR-001)
|
||||
autor: "DIGITOM-Projekt"
|
||||
referenz: "spm_konzept_service-review.yaml"
|
||||
File diff suppressed because it is too large
Load diff
|
|
@ -0,0 +1,20 @@
|
|||
# ========================================
|
||||
# SHM-Integration in der Service-Operation-Runde
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 6
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: ""
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 6]
|
||||
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -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"
|
||||
|
|
@ -0,0 +1,470 @@
|
|||
# =============================================================================
|
||||
# SHM LEITFADEN: USER STORIES IM DIGIT AUFNEHMEN
|
||||
# =============================================================================
|
||||
# Modul: Stakeholder-Management (SHM)
|
||||
# Typ: Arbeitsmaterial (Leitfaden)
|
||||
# Version: 1.0
|
||||
# Datum: 2025-12-09
|
||||
# Status: Final
|
||||
# Quelle: Konzept_DPM_Abnahme20230925, Seiten 125-131
|
||||
# =============================================================================
|
||||
|
||||
meta:
|
||||
dokument_id: "SHM-A-01"
|
||||
name: "Leitfaden User Stories"
|
||||
typ: "Arbeitsmaterial"
|
||||
|
||||
zweck: |
|
||||
Dieser Leitfaden unterstützt Stakeholder-Manager dabei, Anforderungen
|
||||
aus Sicht der Nutzenden zu erheben. User Stories übersetzen abstrakte
|
||||
Bedarfe in konkrete, nachvollziehbare Funktionswünsche.
|
||||
|
||||
zielgruppe: "Stakeholder-Manager:innen"
|
||||
|
||||
kontext: |
|
||||
Im DIGIT-Kontext helfen User Stories, die Perspektive der
|
||||
Verwaltungsmitarbeitenden und Bürger*innen in den Mittelpunkt zu stellen.
|
||||
Der Leitfaden ist Teil der Bedarfserhebung (Schritt 0 der Bedarfsbewertung).
|
||||
|
||||
geltungsbereich: "DIGITOM / Demand-to-Project-Prozess"
|
||||
|
||||
status_dokument:
|
||||
abgestimmt_zwischen: ["human", "DPM-Teammitglied"]
|
||||
inhaltlich_abgenommen_durch:
|
||||
- person: "DPM-Teammitglied"
|
||||
datum: "2025-09-17"
|
||||
- person: "DPM-Leitung"
|
||||
datum: null
|
||||
abgenommen_in_gesamtkonzept: false
|
||||
|
||||
referenzen:
|
||||
- dokument: "shm_bedarfsbewertung.yaml"
|
||||
abschnitt: "schritt_0"
|
||||
beschreibung: "Integration in Bedarfsbewertungs-Prozess"
|
||||
- dokument: "shm_schema_bedarfssteckbrief.yaml"
|
||||
abschnitt: "user_stories"
|
||||
beschreibung: "Dokumentation der erhobenen User Stories"
|
||||
|
||||
# =============================================================================
|
||||
# GRUNDLAGEN
|
||||
# =============================================================================
|
||||
|
||||
grundlagen:
|
||||
|
||||
definition: |
|
||||
User Stories beschreiben Anforderungen aus Sicht der Nutzenden.
|
||||
Sie übersetzen abstrakte Bedarfe in konkrete, nachvollziehbare
|
||||
Funktionswünsche.
|
||||
|
||||
grundformat:
|
||||
schema: "Als [Rolle/Bereich] möchte ich [Funktionalität/Lösung], um [Nutzen/Ziel zu erreichen]"
|
||||
|
||||
elemente:
|
||||
- element: "Rolle"
|
||||
beschreibung: "Wer hat den Bedarf? (spezifisch, nicht 'Nutzer')"
|
||||
beispiele:
|
||||
- "Sachbearbeiter*in Bauamt"
|
||||
- "Abteilungsleitung"
|
||||
- "Bürger*in"
|
||||
- "Antragsteller*in"
|
||||
|
||||
- element: "Funktionalität"
|
||||
beschreibung: "Was soll ermöglicht werden? (keine technische Lösung)"
|
||||
beispiele:
|
||||
- "Bauanträge nach Flurstücknummer durchsuchen"
|
||||
- "Urlaubsanträge digital genehmigen"
|
||||
- "Bearbeitungsstatus online einsehen"
|
||||
|
||||
- element: "Nutzen"
|
||||
beschreibung: "Warum ist das wichtig? (konkreter Mehrwert)"
|
||||
beispiele:
|
||||
- "zusammenhängende Anträge schnell identifizieren"
|
||||
- "Prozess auch im Homeoffice funktioniert"
|
||||
- "nicht telefonisch nachfragen müssen"
|
||||
|
||||
mehrwert:
|
||||
- aspekt: "Perspektivwechsel"
|
||||
beschreibung: "Weg von technischen Spezifikationen, hin zum tatsächlichen Bedarf"
|
||||
|
||||
- aspekt: "Verständlichkeit"
|
||||
beschreibung: "Fachbereiche und IT sprechen dieselbe Sprache"
|
||||
|
||||
- aspekt: "Priorisierung"
|
||||
beschreibung: "Nutzen wird explizit und bewertbar"
|
||||
|
||||
- aspekt: "Validierung"
|
||||
beschreibung: "Stakeholder können bestätigen: 'Ja, genau das brauche ich'"
|
||||
|
||||
# =============================================================================
|
||||
# SCHRITT-FÜR-SCHRITT-ANLEITUNG
|
||||
# =============================================================================
|
||||
|
||||
anleitung:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 1: VORBEREITUNG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_1:
|
||||
name: "Vorbereitung des Gesprächs"
|
||||
|
||||
vor_dem_termin_klaeren:
|
||||
- "Wer sind die Hauptnutzenden? (Sachbearbeiter*innen, Führungskräfte, Bürger*innen?)"
|
||||
- "Welcher Prozess ist betroffen?"
|
||||
- "Gibt es Vorarbeiten oder Dokumentationen?"
|
||||
|
||||
materialien_bereithalten:
|
||||
- "Bedarfs-Steckbrief"
|
||||
- "Ggf. Prozessvisualisierung"
|
||||
- "Beispiel-User-Stories zur Illustration"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 2: EINSTIEG
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_2:
|
||||
name: "Einstieg ins Gespräch"
|
||||
|
||||
grundprinzip:
|
||||
falsch: "Welche User Stories haben Sie?"
|
||||
richtig: "Erzählen Sie mir, was Sie in Ihrer täglichen Arbeit erreichen möchten."
|
||||
|
||||
leitfragen_einstieg:
|
||||
- "Beschreiben Sie einen typischen Arbeitsablauf, bei dem es hakt."
|
||||
- "Was würde Ihnen die Arbeit erleichtern?"
|
||||
- "Wobei verlieren Sie die meiste Zeit?"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 3: ROLLEN IDENTIFIZIEREN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_3:
|
||||
name: "Die richtigen Rollen identifizieren"
|
||||
|
||||
typische_rollen:
|
||||
verwaltungsintern:
|
||||
- "Sachbearbeiter*in [Amt]"
|
||||
- "Abteilungsleitung"
|
||||
- "Verwaltungsmitarbeitende"
|
||||
- "Amtsleitung"
|
||||
- "Datenschutzbeauftragte*r"
|
||||
|
||||
verwaltungsextern:
|
||||
- "Bürger*in"
|
||||
- "Antragsteller*in"
|
||||
- "Unternehmen"
|
||||
- "Andere Institute"
|
||||
- "Dienstleister"
|
||||
|
||||
wichtiger_hinweis: |
|
||||
Spezifisch sein! Nicht "Nutzer", sondern "Sachbearbeiter*in Wohngeldstelle"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 4: FUNKTIONALITÄTEN HERAUSARBEITEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_4:
|
||||
name: "Funktionalitäten herausarbeiten"
|
||||
|
||||
prinzip: "Von der Lösung zum Bedarf"
|
||||
|
||||
uebersetzungen:
|
||||
- stakeholder_sagt: "Wir brauchen eine Datenbank"
|
||||
shm_fragt: "Was möchten Sie damit tun?"
|
||||
story_wird: "...möchte ich Anträge zentral verwalten..."
|
||||
|
||||
- stakeholder_sagt: "Das System ist zu langsam"
|
||||
shm_fragt: "Wobei genau verlieren Sie Zeit?"
|
||||
story_wird: "...möchte ich Suchergebnisse in unter 3 Sekunden..."
|
||||
|
||||
- stakeholder_sagt: "Wir wollen alles digitalisieren"
|
||||
shm_fragt: "Was genau soll digital werden?"
|
||||
story_wird: "...möchte ich Anträge online einreichen..."
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 5: NUTZEN EXPLIZIT MACHEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_5:
|
||||
name: "Den Nutzen explizit machen"
|
||||
|
||||
nachfragen:
|
||||
- "Warum ist das wichtig?"
|
||||
- "Was können Sie dann besser machen?"
|
||||
|
||||
nutzen_kategorien:
|
||||
- kategorie: "Effizienz"
|
||||
beispiel: "...damit ich mehr Anträge bearbeiten kann"
|
||||
|
||||
- kategorie: "Qualität"
|
||||
beispiel: "...damit weniger Fehler passieren"
|
||||
|
||||
- kategorie: "Service"
|
||||
beispiel: "...damit Bürger*innen schneller Antworten erhalten"
|
||||
|
||||
- kategorie: "Compliance"
|
||||
beispiel: "...damit wir gesetzeskonform arbeiten"
|
||||
|
||||
- kategorie: "Transparenz"
|
||||
beispiel: "...damit der Bearbeitungsstand nachvollziehbar ist"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 6: FORMULIEREN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_6:
|
||||
name: "User Stories formulieren"
|
||||
|
||||
beispiel_gut:
|
||||
rolle: "Sachbearbeiterin im Bauamt"
|
||||
funktionalitaet: "Bauanträge nach Flurstücknummer durchsuchen können"
|
||||
nutzen: "zusammenhängende Anträge schnell identifiziere"
|
||||
vollstaendig: |
|
||||
Als Sachbearbeiterin im Bauamt
|
||||
möchte ich Bauanträge nach Flurstücknummer durchsuchen können
|
||||
damit ich zusammenhängende Anträge schnell identifiziere
|
||||
|
||||
beispiel_schlecht:
|
||||
rolle: "Nutzer"
|
||||
funktionalitaet: "eine bessere Suche"
|
||||
nutzen: "es schneller geht"
|
||||
vollstaendig: |
|
||||
Als Nutzer
|
||||
möchte ich eine bessere Suche
|
||||
damit es schneller geht
|
||||
probleme:
|
||||
- "Rolle zu unspezifisch"
|
||||
- "Funktionalität zu vage"
|
||||
- "Nutzen nicht konkret"
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# SCHRITT 7: PRIORISIEREN UND VALIDIEREN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
schritt_7:
|
||||
name: "Stories priorisieren und validieren"
|
||||
|
||||
validierungsfragen:
|
||||
- "Habe ich Sie richtig verstanden?"
|
||||
- "Ist diese Reihenfolge nach Wichtigkeit korrekt?"
|
||||
- "Fehlt noch etwas Wesentliches?"
|
||||
|
||||
priorisierungsstufen:
|
||||
- stufe: "Kritisch"
|
||||
beschreibung: "Ohne geht es nicht"
|
||||
|
||||
- stufe: "Wichtig"
|
||||
beschreibung: "Deutliche Verbesserung"
|
||||
|
||||
- stufe: "Nützlich"
|
||||
beschreibung: "Wäre schön"
|
||||
|
||||
# =============================================================================
|
||||
# TYPISCHE HERAUSFORDERUNGEN
|
||||
# =============================================================================
|
||||
|
||||
herausforderungen:
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# HERAUSFORDERUNG 1: LÖSUNGSDENKEN
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
loesungsdenken:
|
||||
name: "Der Stakeholder denkt nur in Lösungen"
|
||||
|
||||
technik: "Die 5-Warum-Methode"
|
||||
|
||||
beispiel_dialog:
|
||||
- sprecher: "Stakeholder"
|
||||
aussage: "Wir brauchen ein Dashboard"
|
||||
- sprecher: "SHM"
|
||||
aussage: "Warum brauchen Sie ein Dashboard?"
|
||||
- sprecher: "Stakeholder"
|
||||
aussage: "Um die Zahlen zu sehen"
|
||||
- sprecher: "SHM"
|
||||
aussage: "Warum müssen Sie die Zahlen sehen?"
|
||||
- sprecher: "Stakeholder"
|
||||
aussage: "Um zu erkennen, wo sich Anträge stauen"
|
||||
|
||||
resultierende_story: |
|
||||
Als Abteilungsleitung
|
||||
möchte ich Engpässe im Antragsprozess erkennen
|
||||
damit ich Ressourcen umverteilen kann
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# HERAUSFORDERUNG 2: ALLES DRINGEND
|
||||
# ---------------------------------------------------------------------------
|
||||
|
||||
alles_dringend:
|
||||
name: "Alles ist wichtig und dringend"
|
||||
|
||||
technik: "Relatives Priorisieren"
|
||||
|
||||
hilfreiche_fragen:
|
||||
- "Wenn Sie nur eine Sache bekommen könnten, welche wäre es?"
|
||||
- "Was würde am meisten wehtun, wenn es fehlt?"
|
||||
- "Was nutzen Sie täglich vs. was nur monatlich?"
|
||||
|
||||
# =============================================================================
|
||||
# QUALITÄTSKRITERIEN
|
||||
# =============================================================================
|
||||
|
||||
qualitaetskriterien:
|
||||
|
||||
invest:
|
||||
name: "INVEST-Kriterien"
|
||||
beschreibung: "Qualitätsstandard für gute User Stories"
|
||||
|
||||
kriterien:
|
||||
- buchstabe: "I"
|
||||
name: "Independent"
|
||||
beschreibung: "Unabhängig von anderen Stories"
|
||||
|
||||
- buchstabe: "N"
|
||||
name: "Negotiable"
|
||||
beschreibung: "Nicht in Stein gemeißelt"
|
||||
|
||||
- buchstabe: "V"
|
||||
name: "Valuable"
|
||||
beschreibung: "Klarer Nutzen erkennbar"
|
||||
|
||||
- buchstabe: "E"
|
||||
name: "Estimable"
|
||||
beschreibung: "Größe grob einschätzbar"
|
||||
|
||||
- buchstabe: "S"
|
||||
name: "Small"
|
||||
beschreibung: "In überschaubarer Zeit umsetzbar"
|
||||
|
||||
- buchstabe: "T"
|
||||
name: "Testable"
|
||||
beschreibung: "Überprüfbare Erfolgskriterien"
|
||||
|
||||
# =============================================================================
|
||||
# BEISPIEL-STORIES
|
||||
# =============================================================================
|
||||
|
||||
beispiel_stories:
|
||||
|
||||
- bereich: "Bürgerservice"
|
||||
story:
|
||||
rolle: "Bürger*in"
|
||||
funktionalitaet: "den Bearbeitungsstatus meines Antrags online einsehen"
|
||||
nutzen: "ich nicht telefonisch nachfragen muss"
|
||||
volltext: |
|
||||
Als Bürger*in
|
||||
möchte ich den Bearbeitungsstatus meines Antrags online einsehen
|
||||
damit ich nicht telefonisch nachfragen muss
|
||||
|
||||
- bereich: "Interne Verwaltung"
|
||||
story:
|
||||
rolle: "Personalverantwortliche"
|
||||
funktionalitaet: "Urlaubsanträge digital genehmigen können"
|
||||
nutzen: "der Prozess auch im Homeoffice funktioniert"
|
||||
volltext: |
|
||||
Als Personalverantwortliche
|
||||
möchte ich Urlaubsanträge digital genehmigen können
|
||||
damit der Prozess auch im Homeoffice funktioniert
|
||||
|
||||
- bereich: "Schnittstellen"
|
||||
story:
|
||||
rolle: "Mitarbeitende im Einwohnermeldeamt"
|
||||
funktionalitaet: "Meldedaten automatisch ans Finanzamt übertragen"
|
||||
nutzen: "Bürger*innen sich nicht doppelt melden müssen"
|
||||
volltext: |
|
||||
Als Mitarbeitende im Einwohnermeldeamt
|
||||
möchte ich Meldedaten automatisch ans Finanzamt übertragen
|
||||
damit Bürger*innen sich nicht doppelt melden müssen
|
||||
|
||||
# =============================================================================
|
||||
# CHECKLISTE FÜR SHM
|
||||
# =============================================================================
|
||||
|
||||
checkliste:
|
||||
|
||||
name: "Checkliste für Stakeholder-Manager"
|
||||
|
||||
pruefpunkte:
|
||||
- id: "CK-01"
|
||||
pruefpunkt: "Rollen spezifisch identifiziert"
|
||||
beispiel: "Nicht 'Nutzer', sondern 'Sachbearbeiter*in Wohngeldstelle'"
|
||||
|
||||
- id: "CK-02"
|
||||
pruefpunkt: "Funktionalitäten klar beschrieben (keine Lösungen)"
|
||||
beispiel: "Nicht 'Datenbank', sondern 'Anträge zentral verwalten'"
|
||||
|
||||
- id: "CK-03"
|
||||
pruefpunkt: "Nutzen explizit gemacht"
|
||||
beispiel: "Konkrete Verbesserung benannt, nicht 'damit es besser wird'"
|
||||
|
||||
- id: "CK-04"
|
||||
pruefpunkt: "Stories mit Stakeholder validiert"
|
||||
beispiel: "Stakeholder hat bestätigt: 'Ja, das ist mein Bedarf'"
|
||||
|
||||
- id: "CK-05"
|
||||
pruefpunkt: "Prioritäten geklärt"
|
||||
beispiel: "Kritisch / Wichtig / Nützlich zugeordnet"
|
||||
|
||||
- id: "CK-06"
|
||||
pruefpunkt: "Zusammenhang zum Problem hergestellt"
|
||||
beispiel: "Story adressiert dokumentiertes Problem aus Situationsanalyse"
|
||||
|
||||
- id: "CK-07"
|
||||
pruefpunkt: "In Bedarfs-Steckbrief übertragen"
|
||||
beispiel: "Stories im Schema-konformen Format dokumentiert"
|
||||
|
||||
# =============================================================================
|
||||
# DOKUMENTATION
|
||||
# =============================================================================
|
||||
|
||||
dokumentation:
|
||||
|
||||
nach_dem_gespraech:
|
||||
- schritt: 1
|
||||
aktion: "Stories im Steckbrief sauber dokumentieren"
|
||||
- schritt: 2
|
||||
aktion: "Priorisierung vermerken"
|
||||
- schritt: 3
|
||||
aktion: "Offene Punkte notieren"
|
||||
- schritt: 4
|
||||
aktion: "Validierungstermin vereinbaren"
|
||||
|
||||
ablage:
|
||||
ziel_dokument: "Bedarfs-Steckbrief"
|
||||
ziel_abschnitt: "user_stories"
|
||||
schema_referenz: "shm_schema_bedarfssteckbrief.yaml"
|
||||
|
||||
# =============================================================================
|
||||
# HINWEISE
|
||||
# =============================================================================
|
||||
|
||||
hinweise:
|
||||
|
||||
- typ: "Tipp"
|
||||
text: |
|
||||
Die erste User Story ist die schwerste. Mit etwas Übung entwickeln
|
||||
Sie ein Gefühl dafür, die richtigen Fragen zu stellen und Bedarfe
|
||||
strukturiert zu erfassen.
|
||||
|
||||
- typ: "Warnung"
|
||||
text: |
|
||||
Vermeiden Sie es, selbst Lösungen vorzuschlagen. Ihre Aufgabe ist
|
||||
es, den Bedarf zu verstehen – nicht, ihn zu lösen.
|
||||
|
||||
- typ: "Best Practice"
|
||||
text: |
|
||||
Beginnen Sie mit offenen Fragen zum Arbeitsalltag, bevor Sie
|
||||
konkrete User Stories formulieren. Der Kontext hilft, die
|
||||
richtigen Fragen zu stellen.
|
||||
|
||||
# =============================================================================
|
||||
# ÄNDERUNGSHISTORIE
|
||||
# =============================================================================
|
||||
|
||||
aenderungshistorie:
|
||||
|
||||
- version: "1.0"
|
||||
datum: "2025-12-09"
|
||||
aenderung: "Initiale Erstellung aus PDF-Vorlage"
|
||||
autor: "DIGITOM-Projekt"
|
||||
quelle: "Konzept_DPM_Abnahme20230925, Seiten 125-131"
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
# ========================================
|
||||
# Stakeholder-Informations-Management-System (SIMS)
|
||||
# ========================================
|
||||
# Version: 0.1 (Platzhalter)
|
||||
# Datum: 2024-12-03
|
||||
# Status: Ausstehend
|
||||
# Entwicklungsphase: 11
|
||||
# ========================================
|
||||
|
||||
# ITIL4-Referenz (falls zutreffend):
|
||||
# itil4_referenz:
|
||||
# practice: ""
|
||||
# relevante_elemente: []
|
||||
# adaption_fuer_digitom: ""
|
||||
|
||||
# ========================================
|
||||
# INHALT
|
||||
# ========================================
|
||||
|
||||
# [Inhalt folgt in Phase 11]
|
||||
File diff suppressed because it is too large
Load diff
Loading…
Add table
Add a link
Reference in a new issue